Portal is the new version of VMware’s Workspace, a complementary interface to gather and display all the desktop pools, applications and files for enterprise users. This version is much smaller, one VM rather than a five or six (if redundant gateways were used) VM vApp.
When VMware abandoned Horizon Files to concentrate on vSAN, it purchased AirWatch’s SCL (Secure Content Locker) to take its place. With the files part out of the way, Workspace Portal’s job is much simpler. There isn’t a direct upgrade path from 2.0 to 2.1 because the structure has changed so much. The resource recovery is substantial. A full Workspace 1.5, 1.8 or 2.0 installation with redundant gateways took 11 vCPUs and 17 Gb of RAM. The 2.1 Portal VM wants 2 vCPUs and 6 GB RAM. Of course, if high availability is needed, you’ll give some of that back.
There is support for migrating the existing 2.0 or older database to 2.1 and is documented in the installation manual. It will involve command line database adjustments and replication setup.
Migrating Files from Horizon Files to AirWatch SCL
VMware provides a script to copy the files off of an existing data-va. They don’t provide a script for importing the same files in to the new AirWatch SCL infrastructure. According to VMware, the third party vendor is responsible for the import script. But, what if VMware owns the third party vendor software? Your guess is as good as mine. All I know is, as of this writing, there wasn’t a reliable way to finish the migration if keeping user files was a requirement. I decided not to keep them and just start over. The rationale being, the Workspace local client sync’d the files and, as a department, notified the user base that Horizon Files was not a backed-up document repository.
Activation Code needed with Internal Database Deployment
This error popped up after the initial deployment and during the second step of configuration. The fix from VMware Support? Redeploy, making sure the FULL FQDN was used during the OVA setup, and make sure the OVA is deployed through vCenter and not an ESXi host. I had done both of those and still got the error anyway. A redeployment did fix the problem.
Internal Database Support
VMware Support confirmed with me that they will support the internal database configuration in 2.1, even though the install document strictly forbids it. They recommend having an external database to replicate with. I don’t have any external PostgreSQL or Oracle databases lying around and I’m not convinced this is even necessary because…
High Availability Options
This VMware blog post outlines the steps to clone a master Portal and set replication between the internal PostgreSQL databases. Clone replication will negate the need for an external database, right?
This option is available for environments with more than one domain in the forest.
DO NOT USE CAPITAL LETTERS IN THE FQDN
This is where things get a bit ugly and there is no documentation specifically forbidding the use of capital letters in the FQDN setup of the 2.1 VM. There is however, several angry blog entries out there suggesting that this should be in the install documents or just fix the code.
Here’s the problem: the FQDN is literal, because, you know, the VM is Linux. The web interface will respond to any combination (caps or small) of the FQDN and present the login. You can even go through the entire configuration without a problem, until you try to login to the Connector Interface, which is the portal entrance the users have access to. The Connector uses SAML to pass the authentication from itself to the domain controller. If the Portal FQDN is “AAA.DOMAIN.COM” and it is accessed via https ://aaa.domain.com , the authentication will fail because “aaa.domain.com” can’t issue a SAML request to the domain controller, only “AAA.DOMAIN.COM” can. Thus, the following error will appear:
To fix this problem, REDEPLOY the VM and use small letters in the FQDN portion of the OVA setup. Or, instruct everyone to use capital letters when typing the URL in their web browser.
I tried logging into the Portal console and use YaST to change the hostname, but it never did work. Every time the VM rebooted, the old hostname in CAPS would be back at the console screen regardless of the changes made with YaST.
Configuring this version of Workspace isn’t much different than any previous one. The connectors are the same as outlined here. The main problem with the configuration was changing the external FQDN from the appliance name, or in 2.1, the VM name, to the external URL used with a load balancer.
– Remember to set up DNS and reverse-DNS entries prior to deploying the OVA.
– The domain account used to access Active Directory becomes the default administrator account to the portal. You’ll need to login as this user to change permissions and add other admins.