The VCSA 5.1 (vCenter Server Appliance) is provided as single virtual appliance that is pre-installed with all the components needed to run a vCenter Server. These components include vCenter SSO (Single Sign-on), Lookup Service, Inventory Service, vSphere Web Client and the vCenter Server itself. In the Windows installer for vCenter Server 5.1, there is an option to install each individual component on a separate machine. How would you go about doing that for the VCSA as all the components are installed on a single machine?

The answer is actually quite simple, you just need to deploy additional VCSA systems and enable the specific component service on each of the VCSA's. I have already written articles covering some of these use cases such as deploying additional vCenter Servers leveraging a common vCenter SSO Server as well as deploying additional vSphere Web Client Servers. The one particular use case that I have not covered is running just the vCenter SSO Server on the VCSA and with this configuration, there is a minor tweak that is required to get things working correctly.Disclaimer: This may not be officially supported by VMware, please use at your own risk.

If you have attempted to configure the VCSA to run just the vCenter SSO service, then you may have seen the following error message "Could not connect to one or more vCenter Server systems" when logging into the vSphere Web Client.

The reason you are seeing this error is due to an invalid configuration found in the vCenter SSO Server and specifically with something called the Lookup Service. The Lookup Service is installed with the vCenter SSO service which can be thought of as a DNS lookup for vSphere components so they can securely find and communicate with each other. Since each VCSA component is registered with the Lookup Service as part of their initial installation and when you only enable the vCenter SSO service, the remainder services will become invalid as they are not running on the same VCSA system.

Un-Registering Services from Lookup Service:

To fix this problem, we just need to identify the services that should not be registered to the Lookup Service in the vCenter SSO Server and unregister them. To view the list of registered services to a particular Lookup Service endpoint, you can use the /usr/lib/vmware-sso/bin/vi_regtool utility with the listServices option found on the VCSA.
To use the utility, you will need to specify either the IP Address and/or Hostname of the vCenter SSO Server which runs the Lookup Service. Here is an example:

/usr/lib/vmware-sso/bin/vi_regtool listServices

If the command is successful, you should see a list of service endpoints such as the following:

Service 1
description=vSphere Web Client at
ownerId=vsphere[email protected]System-Domain

A default VCSA installation contains the following 6 services:

  • vSphere Web Client
  • Security Token Service
  • VMware Log Browser
  • SSO Group Check Service
  • vpxd (vCenter Server)
  • SSO Administration Service

We will need to identify the serviceId which starts with local:# and unregister the vSphere Web Client, VMware Log Browser and the vpxd service which is not running locally on our vCenter SSO Server. To unregister a service, you will need to create a temporarily file which contains the serviceId and use the unregisterService option with the vi_regtool.

Note: Please make sure you identify the correct serviceId before unregistering, else you may potentially run into issues with your VCSA.

Let's say we want to unregister the service that we showed earlier local:7, we would need to run the following two commands:

echo "local:7" > /tmp/serviceid
/usr/lib/vmware-sso/bin/vi_regtool unregisterService -d -u root -p vmware -si /tmp/serviceid

The first command will "echo" the serviceId into a temporarily file called /tmp/serviceid and the second command will perform the actual un-registration and you will need to specify the root credentials. You will need to repeat this for the other two services and once you have finished un-registering the three services, you can now log back into the vSphere Web Client and the error message should go away (a service restart is not necessary).

Now that you have some background on how to run a standalone vCenter SSO on the VCSA and the minor tweak that is required, how do we go about automating all of this during deployment? For those of you who know me, know that I would not leave my readers hanging without some scripts to assist with this manual work.

Automating Deployment of vCenter SSO, vSphere Web Client & vCenter Server Component:

The following section will describe how to completely automate the deployment of 3 separate VCSA running vCenter SSO + Lookup Service, vSphere Web Client and vCenter Server + Inventory Service as seen in the diagram above.

Step 1 - Deploy 3 VCSA 5.1 and configure basic network connectivity. In my example, I have the following setup:

Component Hostname IP Address
vCenter SSO + LS
vSphere Web Client
vCenter Server + IS

Step 2 - Configure the vCenter SSO by creating the following shell script called

The only user configuration that is required is to update the SSO_IP_ADDRESS variable in the script to the IP Address of the vCenter SSO Server. You can execute the script via SSH without having to copy the script to the VCSA system, here is an example execution:

We can see from the screenshot above, we automatically look for the 3 services mentioned earlier and unregister it from the vCenter SSO Server running the Lookup Service. You can easily confirm this by re-running the listServices operation with the vi_regtool.

Step 3 - Configure the vSphere Web Client Server and you can use the script noted in this article. The only user configuration that is required is to update the VCENTER_SSO_IPADDRESS variable in the script to point to the IP Address of your vCenter SSO Server. Here is an example execution:

Step 4 - Finally, the last step is to configure the vCenter Server and you can use the script noted in this article. The only user configuration that is required is to update the PRIMARY_VC variable in the script to point to the IP Address of your vCenter SSO Server. Here is an example execution:

Once the vCenter Server has successfully started, then you are now done with seperating out the three components of the vCenter Server using the VCSA. You can confirm additionally by logging back into the vCenter SSO Server and run the listServices and you should now see the IP Address or Hostname of your vSphere Web Client Server and vCenter Server being registered to the Lookup Service from the separate VCSA's. You can now login to the vSphere Web Client server and make sure you specify the full URL which should be https://[hostname-or-ipaddress]:9443/vsphere-client and you should be able to see your vCenter Server.

Note: Steps 3 and 4 can be interchange as the order does not matter, as long as vCenter SSO system is setup first.

12 thoughts on “Seperating Out the vCenter SSO, vSphere Web Client and vCenter Server Services Using the VCSA

  1. Hi William,
    Just want to say thanks for this blog. I installed VC Appliance 5.1.0b, connecting to VC Appliance SSO 5.1.0a. I kept getting error on Inventory services. I tried different thing. The solution was to remove all the services using the command you provided here. I found 7 services that I had to remove. Did that, and re-point the SSO again from my 5.1.0b VC, and it worked!
    Thanks for sharing all these. I now have 5 vCenters fronted by 1 SSO. Definitely beats logging 5x, not to mention I can work “across” vCenters.

    Have a blessed Christmas.

    • np! I’m not sure if combining different version of the appliance would work (5.1.0a / b) … maybe that’s causing some issues. I know that if you used the same appliance build, the steps above should work and you should not need to remove all the services (only the ones that were self-registered on the SSO host, you could break other things if you remove ALL services such as the ones related to SSO)

  2. William,
    Thanks for the post. I only had to unregister the vpxd service (local:5) for this error message to go away. Should I also unregister the other services too? (local:6 & 7)


  3. Hello William,

    I still cannot access the script “” from this article. It will be great help if you can point it out for me!!

Thanks for the comment!

This site uses Akismet to reduce spam. Learn how your comment data is processed.