The vSphere 6.0 Web Client has been greatly improved with the release of vSphere 6.0 which includes a number of performance and UX enhancements. If you are interested in some of the details, be sure to check out this blog post by Dennis Lu, Product Manager of the vSphere Web Client. To really get the best possible user experience and to take advantage of all the new performance enhancements, it is recommend that you upgrade your entire vSphere environment which includes vCenter Server to vSphere 6.0. Having said that, I know this may not be possible for everyone immediately and it will take some time depending on your organizations software upgrade cycles and procedures, qualifications, burn in time, comfort left, etc. with vSphere 6.0 before completely moving over.

Over the last couple of weeks, I have seen quite a few requests from customers who have expressed interest in being able to just use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment as they make their transition over to vSphere 6.0. I can definitely understand where these customers are coming from and honestly, the vSphere Web Client should just be that, a UI Client. We should be able to decouple it from vCenter Server and be able to iterate on it based on feedback from our customers and partners. I did some investigation and I actually discovered that we in fact support something called Mixed-Version Transitional Environment in vCenter Server for Windows Upgrade. This is a bit of a mouth full but basically you can have a hybrid vCenter Server environment that consists of both vSphere 5.5 and 6.0 as you upgrade to full a full vSphere 6.0 environment.

I spent a couple of days researching this topic a bit more to see if I can come up with a solution that would ideally reduce number of changes introduced to a customers existing vSphere 5.5 environment while being able to leverage the new vSphere 6.0 Web Client. After many discussions, prototyping, snapshot reverts and with the help of one of my good GSS buddy G. Blair Fritz, we have come up with a very cool solution using the VCSA 6.0 as a "thin" vSphere 6.0 Web Client Server. The overall goal is to provide a period of time in which customers can use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment and when the time comes for a complete vSphere 6.0 upgrade, this "thin" vSphere 6.0 Web Client can be decommissioned and removed.

Disclaimer: Though this hybrid configuration is supported, using the VCSA as a "thin" vSphere Web Client Server is not officially supported. Please use at your own risk. It is still recommended that you upgrade your existing vSphere 5.5 environment to vSphere 6.0 as soon as possible to get the full benefits of the enhancements made to the vSphere 6.0 Web Client.


  • vSphere 5.5 running Windows using an External SSO Server
  • At least one vCenter Server 5.5 pointing to the External SSO Server

Here is the high level workflow as well as a diagram to help you visualize the process:

  • Step 1 - Upgrade your external SSO from vSphere 5.5 to new PSC 6.0
  • Step 2 - Deploy VCSA 6.0 and configure it to point the newly upgraded PSC 6.0
  • Step 3 - Running a configuration script within the VCSA 6.0 to optimize it as a "thin" vSphere Web Client Server

In my test environment, I have deployed a vCenter Server 5.5 which points to an external SSO (also running vSphere 5.5).

Step 1 - The first step is to upgrade the SSO server to the new PSC 6.0, you will follow the existing procedure by mounting the ISO and going through the guided installation. At this point, you can continue logging into the existing vSphere 5.5 Web Client and access your vCenter Server and its hosts and VMs.

Step 2 - Next, you will need to deploy a new Embedded VCSA 6.0 using either the Guided or Scripted Installation. You will need to make sure that it is joining to an existing SSO Domain by specifying the upgraded Windows PSC that you performed in step one. The SSO Domain Name should be vsphere.local as this was not a configurable option in earlier vSphere releases. At this point, you can now login to the VCSA 6.0 which provides the vSphere 6.0 Web Client but you will notice that you only see an empty inventory of the new vCenter Server 6.0 as well as an error message stating "Login failed due to invalid credentials for one or more vCenter Server systems"

The reason for this is that you need to restart the vpxd service on your vCenter Server 5.5 for it to be visible in the new vSphere 6.0 Web Client.

Note: It is important that if your external PSC is joined to an Active Directory Domain that you ensure the NTP Server specified in the VCSA 6.0 deployment also points to the same AD Server for the time source to be synchronized else you will run into problems later.

Step 3 - Login to your vCenter Server 5.5 and restart the vCenter Server service using the Services utility.

Step 4 - Once the vCenter Server service has restarted, you can now open a browser to the Hostname/IP Address of the VCSA 6.0 and you will see both vCenter Servers. You can now manage your vSphere 5.5 environment using the vSphere 6.0 Web Client.

I was pretty happy when I got this solution working but I was still not content. The smallest deployment size for an Embedded VCSA requires 8GB of memory, which is still a considerable amount of resources in my opinion. I wanted to optimize it further by turning off unnecessary services, modify the memory requirements for the unused services as well as un-registering the vCenter Server 6.0 endpoint so that you only see your vSphere 5.5 vCenter Servers only. Surprisingly, this took up the bulk of our research to figure out what could be turned off, how to properly turn it off and then un-registering the VC endpoint.

I have created the following shell script called which needs to be uploaded to the VCSA (need to enable Bash shell on the VCSA). The following three variables must be updated prior to running:

  • PSC_SERVER - The Hostname/IP Address of your external PSC
  • SSO_USERNAME - The SSO Administrator account
  • SSO_PASSWORD - The SSO Administrator password

Once everything completes successfully, you should turn off your VCSA and modify the memory from 8GB to 3GB. From my limited amount of testing, the overall memory utilization was sitting around ~2-2.5GB of memory, so I think configuring it to 3GB should be plenty and you can always adjust accordingly. Since we have disabled all the unnecessary services, the VCSA boot time should be pretty quick and now when you login to the vSphere Web Client, you should only see your vSphere 5.5 vCenter Servers and nothing else.

When the time comes and you are ready to fully upgrade your vSphere 5.5 environment to vSphere 6.0, you can decommission and remove this "thin" vSphere Web Client Server by following the procedure outlined in this VMware KB 2106736. I think it would be really nice to be able to update the vSphere Web Client outside of updating vCenter Server and truly providing a "client" that is decoupled. What do you think?

11 thoughts on “Configuring VCSA 6.0 as vSphere Web Client Server for vSphere 5.5

  1. Just checking, can the initial SSO 5.5 system be a full vCSA or is the initial requirement “vSphere 5.5 running Windows using an External SSO Server” *is* the SSO server?

    As in, does both the SSO 5.5 and vCenter 5.5 need to be running Windows or can you use SSO on vCSA 5.5 and primary vCenter on Windows?

  2. External SSO was only supported on Windows in vSphere 5.5, so not something I’ve tested. If you had VCSA 5.5 pointed to Windows SSO, then yes that would work else you could re-point to a Windows based SSO which there’s a VMware KB for

  3. Very interesting article William. I don’t suppose there’s any way a thin web client server 6 could be made to work with vCenter 5.1? I can see that the completely different SSO mechanism would be a show stopper.

  4. William, This is a great process to use the new web client. I have a question or two though that I need some assistance on for this. Our environment started out small but has expanded exponentially recently. Right now all our vCenter services are on one windows server (SSO, vCenter, VUM and we know this is not the best but we grew horribly fast and now we are paying for that). Our SSO was installed to allow for additional SSO servers but I think it is just for HA. If we were to add an external SSO server, which option would be the one to use?
    1. vCenter Single Sign-On for your first vCenter Server.
    2. vCenter Single Sign-On for an additional vCenter Server in an existing site.
    3. vCenter Single Sign-On for an additional vCenter server with a new site.

    I believe that we would need to select option #3 and then re-point all our services (Inventory, vCenter and Webclient) to the new SSO correct? There are some other blogs that help cover that (no free advertising for them from me).

    I know there are also options to uninstall and re-install but that seems a bit drastic to me.

    Thank you.


  5. Hello,

    please help me with one problem that I have after updating from 5.5 to 6.

    I have the following issue, when I access the ip http://<&gt; of the vCenter the main page loads ok but when I click on Login to Web Client the url is wrong https://vcenter/websso/SAML2…..

    I have tried a lot of things without success as changing the vcenter hostname, modifying some sso files. the vCenter was updated from v 5.5

    Best regards, Ionut

  6. I had this configuration working like a charm with 2 other vC’s @5.5 connected in until 6.0u1 update on the web client which looks like it went smooth but the inventory is now only the vCSA web client inventory (blank). I didn’t have more time to troubleshoot before reverting back to the working config but I did try and restart vpxd services on the 2 vC @5.5 and gave them a good few minutes to maybe sync back up. Nothing. The web client on one of the 5.5 vC’s can still see the other 5.5vC and SSO is still working between all (updated PSC/SSO to 6.0u1 first). Sorry I didn’t pull a support bundle through the new VAMI with the broken config, it was getting huge and I gave up waiting for it to finish.

    I didn’t have any other vC 6.0 connected because of the 5.5 vCSA couldn’t upgrade to 6.0GA with an external SSO (now fixed in 6.0u1, that upgrade will be coming up next).

    I might try a fresh vCSA 6.0u1 as webclient and see how that goes but the upgrade 6.0->6.0u1 maybe doesn’t work with this config or there’s extra step(s) involved.

    • Fresh vCSA 6.0u1 pointing at centralized external PSC and can confirm that the web client installed on that vCSA is only showing the other 6.0 vC’s and not the 5.5’s that still show up under the 6.0GA web client. I’m really bummed that this arch doesn’t work anymore. I’m not moving one of the 5.5 vCs to 6 anytime soon…

  7. Thanks William for this article.
    I’m looking for a solution for allowing “external connections” (from public ip, outside my lan) to my vSphere 6 Web Client.
    I tried to use an apache server as a reverse proxy, but I got a redirection problem: every time I try to access the url “https://[WAN_IP]/vphere-client”, I got redirected to “https://[VCENTER_LOCAL_DNS_NAME]/vphere-client” which cannot be resolved outside my lan…
    I remembered that vSphere 5.5 allowed to install a “standalone web client server”, but this is no more the case in version 6.0.
    Is your solution the only alternative ?
    Best regards,


  8. Hi William,

    Thanks for your blogs ! They are very useful.
    I have a need to expose the vcenter server(6.0 U2) access, ‘https://[vcenter_server_ip]/vsphere-client’ through a reverse proxy server. I tried to use nginx. Based on direct access to the vcenter server through web client and capturing the requests and responses, I find that, nginx has to be configured to handle HTTP 302 redirect from vcenter and also has to handle ‘wss’. Is there a recommended reverse proxy configuration for enabling this access ?

    Thanks for your help !

Thanks for the comment!