vCenter 5.1 – Configuring vCenter Linked Mode

One thing we have been meaning to do for a while but haven’t got round to is getting our Virtual Center Servers into “Linked” mode – essentially to provide a single pane of glass view of our entire virtual estate. One vCenter resides on the other side of our DMZ and manages hosts isolated for security purposes. I’ve created an IPSec server-to-server connection and allowed that through the firewall to secure traffic between the DMZ VC and LAN VC.

For the purposes of this, let’s call them and DefinIT-VC02.definit.test.

Linked Mode Pre-requisites

As well as the normal vCenter Server pre-requisites, there are certain criteria you have to fulfil to be able to use linked mode too. These are taken from the docs here:

Linked Mode groups that contain both vCenter Server 5.x and versions of vCenter Server earlier than 5.0 are not supported. The vSphere Client does not function correctly with vCenter Servers in groups that have both version 5.x and pre-5.0 versions of vCenter Server. Do not join a version 5.x vCenter Server to pre-5.0 versions of vCenter Server, or pre-5.0 version of vCenter Server to a version 5.x vCenter Server. Upgrade any vCenter Server instance to version 5.0 or later before joining it to a version 5.x vCenter Server.

Easy one to start with, both my vCenter Servers are 5.1!

Make sure that all vCenter Servers in a Linked Mode group are registered to the same vCenter Single Sign On server.

Not so easy – I need to register DefinIT-VC02 with DefinIT-VC01’s Single Sign On service. This is possible using Repointing and reregistering VMware vCenter Server 5.1.x and components, however if your install path is not the default the scripts do not work. There are references all over the place to “c:\Program Files” hard coded – even editing them as best I could I couldn’t get it to work. In the end I removed everything from DefinIT-VC02 and reinstalled each component, skipping the SSO and pointing the Inventory Service, vCenter Server and WebClient to DefinIT-VC01.

To join a Linked Mode group the vCenter Server must be in evaluation mode or licensed as a Standard edition. vCenter Server Foundation and vCenter Server Essentials editions do not support Linked Mode.

Both VCs are installed with a vCenter Server Standard License.

DNS must be operational for Linked Mode replication to work.

Both VCs can resolve their own and each other’s DNS names.

The vCenter Server instances in a Linked Mode group can be in different domains if the domains have a two-way trust relationship. Each domain must trust the other domains on which vCenter Server instances are installed.

The two domains do trust each other.

When adding a vCenter Server instance to a Linked Mode group, the installer must be run by a domain user who is an administrator on both the machine where vCenter Server is installed and the target machine of the Linked Mode group.

Both vCenter Servers are run using the same service account, and the Linked Mode Configuration will be run from this context.

All vCenter Server instances must have network time synchronization. The vCenter Server installer validates that the machine clocks are not more than five minutes apart. See Synchronizing Clocks on the vSphere Network.

Finally, check you’re in time sync – 5 minutes is a big difference though, more tolerant than most applications!

Configuring Linked Mode

Running the Linked Mode Configuration tool was pretty straightforward, though it did get confused in the middle reporting errors that didn’t exist. The steps are self-explanatory:



CC BY-SA 4.0
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.


  1. Sjoerd Hooft says

    Hi Sam, I’ve got a question about vCenter in linked mode. What if one of them would fail, would you still be able to manage the hosts and VMs that are managed by that vCenter? I’d love to hear that from you. Thanx

    • says

      Hi Sjoerd, thanks for the question – Linked Mode is a way of managing multiple vCenter Servers as a single pane of glass, it won’t allow you to manage hosts and VMs if the vCenter server they are managed by is down.

      The best definition I’ve found in the docs is from the 4.1 document, but it’s not changed in funtion:

      When vCenter Server systems are connected in Linked Mode, you can perform the following actions:

      • Log in simultaneously to vCenter Server systems for which you have valid credentials.
      • Search the inventories of the vCenter Server systems in the group.
      • View the inventories of the vCenter Server systems in the group in a single inventory view.
  2. Thomas Brown says

    Excellent post! I have been trying to find a definitive answer for if 5.1 vCenters in linked mode have to be on the same SSO instance and I stumbled across your post. Also I have been searching for how to re-register vCenter with a different SSO instance. Thank you for sharing!

  3. Ian says

    Hi Sam,

    Great article! Wonder if you could help answer a question. I have 2 sites aswell. I need to manage the 2 instances of vCenter (5.1) using linked mode but was wondering if I only installed the first site using simple install method (which includes the installation of SSO) then on the 2nd site I pointed the 2nd vCenter server back to the first instance of SSO (i.e not install SSO on the 2nd site). If the first site went down completely would I be able to manage the 2nd site with out any issues? My first thought would be no as the only instance of SSO is installed on the 1st site and it is down. Since the 2nd site doesn’t have SSO and is pointing to the 1st then it would also fail with authentication so I would also not be able to manage the 2nd site. Can you confirm this?
    If this is the case then I will have to set them up using the multisite method right?

    • says

      Hi Ian,

      Yes you are spot on there – if the SSO in the first site is unavailable then the second site will not be able to authenticate and you won’t be able to manage it. This is the reason why I have used the multi-site SSO rather than a single SSO instance. Another option would be to install SSO on a single server seperate from the two vCenter servers and then point both at the seperate SSO instance, but again this is a single point of failure. It’s worth weighing up the chances of losing the 1st site server against the complexity of the multi-site setup, but for my environment it was worth it.

      Thanks for the comment and question!


      • Ian says

        Thanks Sam.

        I unfortunately installed the 1st site using simple install mode so I guess I’m going to have to install it from scratch again. Would you know if I only need to re-install the SSO portion or do I need to install all the components from scratch (i.e. vCenter, inventory service, VUM web client etc)?


        • says

          Unfortunately the simplest way is to uninstall the whole lot and install again component by component – you can keep the DB in place, but appart from that it’s just easier and quicker than attempting to re-point everything.

  4. Pascal says

    Trying to link 2 sites, 1 fst site was installed using simple install . If I reinstall the first site and keep the DB in place. What custom configuration I’m gonnal lose? Permissions on VMs , Custom alerts in vcenter? , roles? Thanks

    • says

      If you’re keeping the vCenter database then you will not lose any custom alerts – you might lose some custom permissions *if* the SSO instance you install doesn’t recognise those users – e.g. you have added an LDAP source that won’t be detected by the new SSO automatically. The best thing to do is to make sure you have documented any custom roles and permissions (probably could do that by PowerCLI) and then once you’ve installed the new SSO, jump straight to the Web Client install, then make sure the identity sources are correct before proceeding to the Inventory Service and vCenter server. The installer will warn you if it sees permissions for roles and users that it doesn’t recognise before it deletes any.



Leave a Reply