vCenter Server provides several ways to deploy vCenter Single Sign-On to best serve your vSphere environment

You can deploy vCenter Single Sign-On in one of three modes.


Basic mode installs a standalone version of vCenter Single Sign-On. Multiple vCenter Server and Inventory Service instances can point to it. If the Single Sign-On server or the virtual machine hosting the server fails, administrators cannot access vCenter Server, but ESXi hosts continue to function normally. Multiple Active Directory and OpenLDAP instances can be added as identity sources.

High Availability Cluster

Cluster mode installs two or more vCenter Single Sign-On instances in high availability mode. All instances use the same database and point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, will see the primary Single Sign-On instance.


Multisite mode is designed for deployments with multiple physical locations. Installing a Single Sign-On instance at each site allows fast access to local authentication-related services. Each Single Sign-On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups. In each datacenter, you can install Single Sign-On in standalone or clustered mode, pointing to the identity sources in that location.

Multisite deployment is useful when a single administrator needs to administer vCenter Server instances that are deployed on geographically dispersed sites, with separate vCenter Single Sign-On instances for each site.To view all such vCenter Server instances from a single vSphere Client or vSphere Web Client, you must configure the vCenter Server instances in Linked Mode.


Multisite Single Sign-On deployment is designed only for faster local access to authentication-related services. It does not provide failover between Single Sign-On servers on different sites. When the Single Sign-On instance on one site fails, its role is not taken over by a peer Single Sign-On instance on another site. All authentication requests on the failed site will fail, even if peer sites are fully functional.

In multisite Single Sign-On deployments, each site is represented by one Single Sign-On server. The Single Sign-On site entry point is the machine that other sites communicate with. This is the only machine that needs to be visible from the other sites.

You can install the Single Sign-On nodes in a multisite deployment in any order. The Single Sign-On installer uses the terms primary and secondary only to distinguish between the node that is installed first and any node that is installed later and points to a previously installed node. Any node that is installed after the primary node can point to any node that is already installed. For example, the third node can point to either the first or second node.

For example, consider a corporation MyCompany, with offices in San Francisco, New York, and London. The New York site is the headquarters and connects with both the London and San Francisco sites. The London and San Francisco sites do not connect with each other. The MyCompany multisite Single Sign-On deployment would proceed in the following steps.


The administrators in London set up the first Single Sign-On instance.


The New York IT team sets up the second Single Sign-On instance, pointing it to the London instance.


The San Francisco IT team sets up the third Single Sign-On instance, pointing it to the New York instance.

vCenter Server instances in linked mode can be connected to different physical Single Sign-On servers, but must be connected to a single logical Single Sign-On server. A single logical Single Sign-On server can take any of the following forms.

A single physical Single Sign-On server.

Two nodes of a cluster. Effectively this is the same as a single physical Single Sign-On server because the nodes use the same Single Sign-On database.

Two nodes in multisite mode.