Upgrade Linked Mode vCenter 5.5 Servers to Enhanced Linked Mode vCSA 6.5

While vSphere 6.5 have been released for some while ago, you should have already know about the vCenter Server Appliance migration function. There are a lot of blogs discussed about what it did and what it supports. In this post, I would like to share one use case which is to migrate Linked Mode venter 5.5 servers. In vSphere 5.5, it’s likely that one uses Windows Based vCenter Servers, and for Linked Mode vCenter actually you have to use Windows Based one ONLY. But as vCSA becomes more scalable and function rich in version 6.0 and 6.5, we don’t need Windows Based version vCenter to support Linked Mode. However how you should migrate a existing Linked Mode? Let me illustrate why it’s not that trivial and let me show you how actually the migration can be performed.

vSphere 5.5 environment

I prepared a three Linked vCenter Servers environment, while each of the nodes is with All In One Deployment. So the High Level Logical Diagram is as follows:

As the vCenter Servers are linked, you can see the inventories from other vCenter Instances both from the C# thick client and Web Client. Just to remind, when you upgraded to either 6.0 or 6.5 version, this will not be the same, as you can only see the Enhanced Linked vCenter Server from the Web Client but not the Thick Client anymore.

Challenge in Upgrade

When we are trying to upgrade the above environment, actually you would find it not that straight forward, let me quote the VMware KB Supported and deprecated topologies for VMware vSphere 6.5 (2147672) HERE to illustrate the problem we face.  Actually the problem comes with the following supported architecture for deploying Enhanced Linked mode.

Simply assume the new Platform Services Controller (PSC) as the SSO server in the <6.0 vSphere Version. So you can see actually VMware doesn’t support All In One Deployment if you are using enhanced Linked Mode. We have to deploy a (simplified) architecture as following for a vSphere 6.5 environment.

So, in simply words we need to break down the AIO vCenter Server into two tier deployment to ensure the end state architecture is of a supported configuration.

What we needa do?

This is why before the upgrade, still in the vSphere 5.5 environment, we actually have to deprecate the existing SSO server which is embedded in the AIO vCenter Server. And create a separate tier SSO server. After that, we need to repoint the vCenter Server to the new SSO server correspondingly. Yes, you may ask why not we do this after the upgrade, but the point is SSO/PSC repointing is not being supported in version 6.5. This is why we have to do it before the upgrade.

So to setup the new SSO Server groups is relatively easy, we just need to deploy SSO Server as a Standalone SSO server for the 1st Node, and Setup 2nd and 3rd Nodes as the MultiSite SSO Server.

After setting up all three SSO server, for my case, sso1.vmware.lab, sso2.vmware.lab and sso3.vmware.lab, we have to configure the vCenter Server nodes to point to the corresponding SSO servers.

Repointing the SSO Server

Thanks for the VMware KB HERE How to repoint and re-register vCenter Server 5.1 / 5.5 and components (2033620), we don’t need to reinvent the wheel to repoint the SSO server. Following the steps in the KB, which is:

  1. Re-register vCenter Inventory Service with vCenter Single Sign-On
  2. Register vCenter Server with a different vCenter Single Sign-On instance
  3. Re-register vCenter Server with the Inventory Service
  4. Register the vSphere Web Client with a different vCenter Single Sign-On instance

Detail Steps as follows:

Using the Command Prompt and Change Directory to C:\Program Files\VMware\Infrastructure\Inventory Service\scripts

is-change-sso.bat https://sso3.vmware.lab:7444/lookupservice/sdk “administrator@vSphere.local” “P@ssw0rd”

Restart the Inventory Services

net stop vimQueryService
net start vimQueryService

Then Change Directory to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool

repoint.cmd configure-vc –lookup-server https://sso3.vmware.lab:7444/lookupservice/sdk –user “administrator@vSphere.local” –password “P@ssw0rd” –openssl-path “C:\Program Files\VMware\Infrastructure\Inventory Service\bin/”

Then you have to restart the vCenter Server Service and vCenter Management Service in the services.msc

Change Directory to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\isregtool

register-is.bat https://sso3.vmware.lab:443/sdk https://sso3.vmware.lab:10443 https://sso3.vmware.lab:7444/lookupservice/sdk

Finally Change Director to C:\Program Files\VMware\Infrastructure\vSphereWebClient\scripts

client-repoint.bat https://sso3.vmware.lab:7444/lookupservice/sdk “administrator@vSphere.local” “P@ssw0rd”

Repeat the above steps for all the three vCenter Server Nodes to repoint them to different SSO Servers, in success repointing you should able to see the Linked Mode working still. You may lose the user, user right and permission of the vSphere.local directory. If you are using AD users, you should still see the user permissions.

So finally, we got the supported architecture and we can use the vCSA 6.5 installer to migrate the SSO and vCenter Server nodes into Virtual Appliances.

Migration Upgrade the SSO Server Nodes

After repointing the SSO, we need to upgrade all the SSO server Nodes first before upgrading the vCenter Server nodes. Steps are comparatively trivial, the wizard will help converting your Windows Based SSO server into VCSA with PSC 6.5 service enabled. Following you can refer to the steps:

Kick Start the vCSA installer

Click Next to Proceed

Accept the EULA

Here You need to input the Migration Assistant Information (You would have to copy the migration assistant binary to the Windows Based SSO/PSC server or vCenter server for Conversion)

Here is what you should see in starting the Migration Assistant on the SSO/PSC Server or vCenter Server

Input the ESXi Host information or vCenter one to deploy the vCSA into

Give the new PSC VCSA the VM name, remember that the host name is NOT this one, the host name will be the existing SSO server hostname. For my case, it would be sso1.vmware.lab, sso2.vmware.lab and sso3.vmware.lab.

Choose the storage information

Provide the TEMP IP information for conversion. This IP will be destroyed on completion of conversion

Kick Start the Appliance deployment

Let me Deployment running

Confirm the Completion of Deployment

Then you will be brought to another wizard for configuration setup

Input the AD username and password as the wizard detected my existing SSO server is domain joint

Choose if you would like to join the CEIP

Confirm the Wizard to kick off the configuration migration from the existing SSO server to the new PSC 6.5 server

Click OK to confirm the prompt

Wait Until the Data Transfer tasks complete

When all the steps are done, the you can proceed to covert another SSO server and repeatedly doing these until all the SSO servers are being converted. The existing SSO servers will be powered off to avoid network conflict during the conversion stage.

Migration Upgrade the vCenter Server Nodes

After all the SSO servers are converted and upgraded to the VCSA 6.5, you can proceed to the Conversion of vCenter Servers Nodes. One Point to remind, you should remove the deprecated SSO service in your AIO vCenter Server to avoid the Migration Assistant misinterpret your machine as an AIO server.

So after removing the SSO Server (GREY one), let’s convert the vCenter Server into VCSA 6.5. You actually leverage the same tool as how you covert the PSC. And steps are really similar, but this time, place to information with the vCenter ones

Unlike the PSC, for vCenter Deployment you can select the deployment size

Actually you are recommended to break the linked mode before the migration, but actually it’s okay even you didn’t and you can see the prompt will warn you on migrating the vCenter from windows to vCSA 6.5 you are bringing the corresponding node away from the existing linked mode which is OKAY.

You can choose what to convert, it’s useful if performance, events or tasks are not necessary but usually these make up a large use of the database which can be skipped to speed up the conversion

You then completed the conversion of the vCenter node, continue and repeat the conversion on other vCenter Nodes.


You are all done!!! You can then check the Enhanced Linked mode status after the migration and upgrade, OF COX, from the HTML5 client too!

Linked vCenters are Shown, folders are there and user permission are all there. We Done!

I wish this is helpful for you and i would like to call out again! TIME to change to vCSA and vSphere 6.5, they are all READY and Lock and Loaded!



Horizon 7.1 unauthenticated access Horizon App
Replicating App Volume AppStacks Across vSAN / vCenter

Leave a Reply

Your email address will not be published / Required fields are marked *