Over the last few months, many customers have been testing and familiarizing themselves with vSphere 5.5 however deployment into a production environment is usually stalled until the availability of the first update or service pack. As we are nearing the typical time frame of when such an update or service pack may become available, I wanted to share some findings that may affect your deployment selection of vCenter Single Sign-On when deploying or upgrading to vCenter Server 5.5

During the installation of vCenter Single Sign-On server you are asked on the deployment option of the vCenter Single Sign-On instance. Below is the intended use case for each deployment option.

Deployment Option #1: vCenter Single Sign-On server for your first vCenter Server

If you are running an environment with a single vCenter Server, the first option, vCenter Single Sign-On server for your first vCenter Server will always be the correct selection.

If however you have an environment that has multiple vCenter Servers, on the first vCenter Server to be upgraded or installed you would still select the first option , vCenter Single Sign-On server for your first vCenter Server. On the second, third, fourth vCenter Servers etc it may require a different than expected selection. The descriptions used for each deployment selection (as well as a following deployment screen) will mention the use of sites and site names within SSO and its best to understand the true intention of these before making your deployment decision. vCenter Single Sign-On sites and site names are to provide a logical grouping of vCenter Single Sign-On resources and today the logical groupings only offer value when placing multiple vCenter Single Sign-On servers behind a network load balancer.

Deployment Option #2: vCenter Single Sign-On for an additional vCenter Server instance in an existing site

If you were deploying two vCenter servers side by side in the same datacenter you may be inclined to choose to deployment option #2 vCenter Single Sign-On for an additional vCenter Server instance in an existing site for the second vCenter Server instance. The mention of existing site would indicates this is the correct option for the second instance however when you select the vCenter Single Sign-On for an additional vCenter Server instance in an existing site, you will actually be configuring a dependency on the first vCenter Single Sign-On instance for registration and object look-up. If that first instance was to become unavailable, all local resources registered with any vCenter Single Sign-On configured with same site will be unable to authenticate regardless of the number of vCenter Single Sign-On instances deployed within the same vCenter Single Sign-On site.

The intend use case for this deployment option is to deploy dedicated instances of vCenter Single Sign-On servers separate to vCenter Server that will be updated and placed behind a network load balancer. The vCenter Single Sign-On site name will define the logical group or pool of vCenter Single Sign-On instances that are configured for the network load balancer.

NOTE: If you have already deployed this configuration with vCenter Single Sign-On servers that are not behind a network load balancer, please contact VMware support Services to remediate the configuration and remove the first deployed instance dependency (if required).

Deployment Option #3: vCenter Single Sign-On for an additional vCenter Server instance with a new site

Deploying multiple vCenter Servers either local to each other or geographically separated, say for use with Linked Mode or to maintain a single point of administration of the vCenter Single Sign-On security authentication domain and have no intention of utilizing a network load balancer. Each vCenter Server will require its vCenter Single Sign-On deployment option to utilize a unique vCenter Single Sign-On site name by selecting deployment option #3 vCenter Single Sign-On for an additional vCenter Server instance with a new site. This selection will create a replication partner and have no dependency on the first vCenter Single Sign-On server deployed.