vCenter Server High Availability with Microsoft Failover Cluster and DFS (Unsupported)

As on the first week of June sadly vCenter Server Heartbeat end of sale has been announced and customers whom have it already will still get their support till 2018 but for those who need to protect their vCenter Server with such a technology don’t have an official alternative from VMware yet.

Its worth mentioning that Neverfail IT continuity suite can be purchased and you can pull of something with it but it will cost you a lot of money.

I’ve been working on this since Heartbeat was announced end of sale and last night it all came together and the results were satisfying to a certain extent, here is a diagram of what this will look like at the end:

vCenter Server Protection


As you can see we require:

  1. A cluster to protect the MSSQL database but it can be done with a single MSSQL server but since we’re going to HA then we must have it from end to end.
  2. Two Windows Server 2012 servers (virtual/physical).

Where we will be utilizing Microsoft’s Failover Cluster Manager and DFS, now enough of the design talk and lets get into details:

  • MSSQL Cluster:
  1. Place the MSSQL databases on a Microsoft SQL Server 2012 AlwaysOn cluster, this will relief you from creating the traditional cluster where a shared storage is required .
  2. Create a database for the vCenter Server.
  3. Create the security log-in account that you will be using with the DSN.
  • vCenter Server (Prior to clustering):
  1. Create a Windows Server 2012 R2 virtual/physical machine and name it vCenterServer.domain.tlds (this name and IP address will become the cluster role that will be floating between the nodes).
  2. Install vCenter Server components one at a time and not in simple mode so that to be able to point the vCenter Server to the MSSQL AlwaysOn listener.
  3. When you’re installing the vCenter Server the option to run the vCenter Server services using the local system account will be dimmed, just use you’re account and later on you can change it from the service itself.
  4. Once the vCenter Server is installed, verify that the installation successful.
  • vCenter Server (Preparation for clustering):
  1. Place these services into manual start-up:
    1. VMware vSphere Profile-Driven Storage Service
    2. VMware VirtualCenter Server
    3. VMware VirtualCenter Management Webservices
    4. VMware vCenter Inventory Service
  2. Now shutdown the virtual/physical machine and clone it.
  3. Power on the cloned virtual/physical machine, change its name and IP address (e.g vcenterhost2.domain.tlds).
  4. Power on the original virtual/physical machine, change it to a work group, change its name and IP address and rejoin it to the domain (eg. vcenterhost1.domain.tlds).
  5. Verify both machines are up and can communicate with each other without any problems.
  6. Add the failover cluster manager feature to both servers.
  • vCenter Server (The cluster):
  1. Open failover cluster manager and create a new cluster, add the nodes to it, give it a name  (e.g vCenterCluster) and separate IP address.
  2. Right-click on Roles -> Configure role -> Next -> Generic Service -> Next -> chose VMware VirtualCenter Server -> give it the same name as the original vCenter Server was named prior to cloning it along with the same IP address -> Next all the way with defaults till you’re done.
  3. Now we need to add the rest of the services to the same role.
  4. Right-click on the vCenterServer -> Add Resource -> Generic Service -> chose VMware vSphere Profile-Driven Storage Service -> Next till you’re done and then do the same for VMware vCenter Inventory Service and VMware VirtualCenter Management Webservices.
  5. Now we need to configure the dependencies of these services so that to prioritize the way they start.
  6. In the role pane: right-click on the VMware VirtualCenter Server service -> Properties -> Dependencies tab -> Add these services as AND (VMware vSphere Profile-Driven Storage and VMware vCenter Inventory Service) they can be selected from the drop down menu -> click Ok.
  7. In the role pane: right-click on the VMware VirtualCenter Management Webservices service -> Properties -> Dependencies tab -> Add the VMware VirtualCenter Server as a dependency and click Ok.
  8. Now right-click on the vCenterServer -> click Start role and after all the services start you should have something that looks like this:


  • vCenter Server Cluster (considering modifications):

Since we might have new components introduced to the vCenter Server in the future, we need to replicate these changes to the passive node as well, the only two things that I remember from heartbeat being replicated was the registry and vCenter Server files/directories found on the installation path.

  1. Registry:
    1. On the failover cluster manager right click on the VMware VirtualCenter Server service -> Registry Replication Tab
    2. Add these keys SOFTWARE\VMware and SOFTWARE\VMware, Inc. and SOFTWARE\Wow6432Node\VMware, Inc.
    3. The bad thing about registry replication is that it doesn’t take place until you failover to the second node, so whenever you do a change on the vCenter Server regarding VMware products always make sure you failover, verify the changes and then failback.vCenterCluster2
  2. File and folder:
    1. Add the DFS Replication role on both servers, it can be find within the file server role.
    2. Open DFS Management.
    3. On the Replication -> right click -> New replication group -> Multipurpose Replication Group -> chose a name for it -> add the servers -> Toplogy full mesh -> bandwidth full -> primary chose the one currently holding the vCenterServer role -> add these folders to replication:
      1. C:\ProgramData\MIT
      2. C:\ProgramData\VMware
      3. C:\Program Files\VMware
      4. C:\Program Files (x86)\VMware
    4. Add the same folders as destination and you should have something like this:


For sure this is not supported by VMware but it can be a feasible way to make the vCenter Server High Available whether its:

  1. Virtual protecting virtual.
  2. Virtual protecting physical.
  3. Physical protecting physical.
  4. Physical protecting virtual.

Finally I am still speculating whether these are the only directories and registry keys that needs to be replicated, if you have anything to add please do tell me so that to update the blog.

Hopefully you’ll benefit from this ^_^.

16831 Total Views 57 Views Today


Knowledge is limitless.

14 Responses

  1. Ibrahim says:

    Thanks Abdullah for the nice post, keep it up.

  2. Justin King says:

    thanks for your time and effort Abdullah, I have shared this with VMware engineering to understand any gotchas you may have with this setup.

  3. Matt Dreyer says:

    Very nice work!

    Have you tested this and what are you seeing as a RTO or failover time? We have observed Inventory Service restart times in the range of 5 minutes to 45 minutes depending on the size of the environment being managed.

    • doOdzZZ says:

      Hello Matt,
      Thank you, in my test environment the VMware VirtualCenter Service takes around 8-12 minutes to shutdown when doing a failover or a failback, other services maxed out to 1-2 minutes.

  4. gans says:

    Have you tried connecting the ESX and fail-over the services from one node to another , During my test ESX got disconnected and have to connect it manually on each fail-over of the services in cluster..

  5. vCenterGuy says:

    this has now been turned into a support configuration, thanks for your work Abdullah. Personally I am not a fan of Microsoft Failover Clustering but it is another supported configuration in place of heartbeats departure.

    FYI you can update the title

  6. Rodrigo says:

    Hi, congrats, great post. I’m was deploy vcenter 6.0.0b and i not find the VMware VirtualCenter Management Webservices and the VMware vCenter Inventory Service was renamed to Vmware Inventory service. can u say what are the new name for management webservice? Thanks!

Leave a Reply

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