Installing vCenter SSO 5.5 in a vCenter 5.1 Environment

Chris Wahl · Posted on

I’ve worked with a number of folks who are on the fence about 5.5 – perhaps it doesn’t quite check a box somewhere on their warm and fuzzy list –  but want to get off their vSphere 4.x or 5.0 environment and start taking advantage of many of the features included with 5.1. For those in this boat, I’d suggest making the move but skipping SSO 5.1 in favor of SSO 5.5.

The Hybrid Approach

I’ve gone through this hybrid upgrade for a handful of clients due to the nature of their business, and can say that the general process is relatively unchanged. You’d still want to make sure to follow all of the standard pre-installation checks and prepare for a 5.1 upgrade, along with rollback plans and backups, as if nothing were out of the ordinary.

The supported 5.5 and 5.1 combination
The supported 5.5 and 5.1 combination

There’s a significant reduction in work involved when using vCenter SSO 5.5, on top of other juicy tidbits:

  • SSO 5.5 does not require an external database. Many of the people I’ve worked with who deployed SSO 5.1 had a lot of headache around the “RSA” database and required RSA_USER and RSA_DBA accounts. This is completely eliminated with SSO 5.5.
  • The SSO 5.1 account, [email protected], does not follow the typical distinguished name format. It’s also deprecated the moment you move to SSO 5.5, which uses [email protected]. By avoiding a leapfrog of 5.1 to 5.5, you keep all that system-domain nonsense out of your SSO environment.
  • SSO 5.1 presented several challenges when trying to do high availability and multi-site deployments. I ran into many of them myself. SSO 5.5 is incredibly easy to cluster, both within a single site and across sites, without any manual intervention or scripts to run.

I’m Ready To Upgrade

That’s great! I’d suggest deploying SSO 5.5 into a test environment so you can feel it out a bit, first. SSO doesn’t require you to tie it into a vCenter system during the install, so you can plop it onto a generic Windows Server template just to see the steps involved before pulling the trigger on it within your production setup. For those using SSO 5.5 in production, VMware generally is OK with using a single server that holds all of the roles (vCenter Server, Identity Service, and SSO) unless you plan on scaling out beyond 5 vCenter Servers inside of a single data center. At that point, having a separate SSO server would start to make sense.

A word of caution: SSO hates “weird” non-ASCII characters in the name and password. I’ve found that the user name of the service you use to install vCenter should be devoid of special characters (if possible). The SSO password chokes on all sorts of special characters, so I typically limit myself to using the exclamation mark (!) to meet the complexity requirement. If you run into a situation where everything seems correct but you still can’t install vCenter, make sure it’s not because of your service account name or SSO password.

Make sure to use the 5.5 vCenter Web Client service to manage your SSO 5.5 instance.

The SSO URL KB

I’d also advise that you look carefully at the SSO URL being used with each vCenter Server installation, especially if you have multiple SSO servers. I’ve found situations where the installer will auto fill out a URL from a remote SSO server, rather than the local one, and cause issues as prescribed with KB 2058080 entitled VMware vCenter Server 5.x fails to start after upgrading Single Sign-On configuration from vSphere 5.1 to vSphere 5.5.

The SSO URI inside of the vpxd.cfg file
The SSO URI inside of the vpxd.cfg file

The workaround is simple enough – just edit the vpxd.cfg file with the correct SSO server – but can be frustrating if you’re trying to get the vCenter service(s) to start and they fail.

Thoughts

I’m glad that VMware supports a hybrid architecture of vCenter 5.1 with SSO 5.5, as it allows people who can’t quite make the jump all the way up to a full 5.5 environment to still take advantage of the enhanced SSO 5.5 experience. There are times where the reality is that vCenter 5.5 would break some sort of support model or cause a hiccup with a dependency chain, such as a piece of software that is critical to the business but is not yet supported with 5.5, making this a nice middle ground approach. Best of luck on your upgrade!