VMware Workspace Portal 2.1 Installation Notes and Solutions

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?

Connector-Only Installation
This option is available for environments with more than one domain in the forest.

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:
SAML Error

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.
small fqdn
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.

The Setup
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.

This VMware blog entry reviews the steps needed to change the external URL.

– 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.


Categories: VMware

Tags: , , , ,

1 reply


  1. The Joy and Woe of Six – Initial Problems and Improvements with VMware’s Horizon 6 and Workspace 2.1 |

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Brad Hedlund

stuff and nonsense


Every cloud has a silver lining.

Live Virtually

A Storage and Virtualization Blog

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video


Just another WordPress.com site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments


Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

%d bloggers like this: