Merging SSO Domains in vCenter Server 5.5 pt 2: How?

VMware

In part 1 of my discussion about Merging SSO Domains I discussed why I was required to make that change. To recap: Enhanced Linked Mode is a business requirement in 6.0 and that requires all vCenters to belong to the same SSO Domain. You can’t merge SSO domains in 6.0 so we need to do it before the upgrade.

While the concept sounds simple enough execution gets a bit complicated. There are a lot of services that need to be modified and some architectural decisions to make.

The wonderful blog article covering this topic from v-front.de was the source used to figure out the work. This guide was based off of the VMware article KB2033620. Both of which are important sources to keep around during implementation.

I like bullet points so here is the flow of work in brief:

  • Designate one SSO server as the “primary”. No changes are made on this server
  • Take Snapshots of EVERYTHING vCenter related.
  • Deploy new SSO servers in the other datacenters, configured as new sites in the existing “primary” SSO domain
  • Run scripts to repoint Inventory services
  • Run scripts to repoint vCenter Server Service and vCenter Web Management service
  • Run scripts to repoint vSphere Web Client service
  • Stop the Single Sign On services on the old SSO server and disable them.

Sounds simple, right? I may have been too cautious with the excessive snapshots but I wanted to use them as a fast rollback plan. I know logically that only two or three servers are really impacted by this but it felt better to snap the syslog server and Update Management server.

Some additional words of advice: Make sure you know where each of your services sit. In vCenter 5.5 it was possible to install Inventory, vCenter Server Service, and Web Client on different servers. You need to run the commands on the appropriate server. Also make certain you know if some services were installed on extra drives. Occasionally vCenter Server Service could be installed on a data drive separate from the C drive. It’s possible to adapt the scripts to that situation but by default they assume the services run on the C drive.

Without further ado, you can find a summary of the process on GitHub