VMware Horizon Make Replica Connection Server Standard
In most architecture, you never want to have a “single” of anything. You want to make sure you have multiple resources to perform a certain role in case you have one of those resources fail for some reason. This is true with VMware Horizon. As most who have any experience with VMware Horizon know, you want to have multiple connection servers installed so that if one of your connection servers goes down, you have another connection server that can serve the purpose of getting users connected to their end-user desktops. A question can come up, though – how do you promote the replica server to a standard server? Let’s explore the topic – VMware Horizon make replica connection server standard.
What is the Horizon Connection Server Replica and how does it work?
Horizon Connection Servers function in a high-availability and load balancing configuration when there are multiple Connection Servers provisioned. Multiple Connection Servers replicate data between them using an AD LDS LDAP configuration. When a change is made in one instance (Connection Server AD LDS), these changes are replicated to the other Connection Servers.
Additionally, if a Connection Server instance fails, the other instances in the group continue to function. After the failed instance is brought back up, the changes are replicated back to the server. You will see the AD LDS instance installed on each Connection Server listed in the programs and features.
Below are the Programs and Features from a Windows Server 2019 VMware Horizon Connection Server. You will see the AD LDS Instance VMwareVDMDS entry listed.
VMware Horizon Make Replica Connection Server Standard
The question arises, what steps need to be taken to make a VMware Horizon Replica Connection Server a standard Connection Server or master connection server?
VMware Horizon does a good job at handling failures when they arise, including the Connection Server. The only difference between the standard server and the replica Connection Servers is the FSMO role holder for LDAP operations.
How do you check and see which Connection Server owns the role of the schema master? You can do this using the LDP utility.
Finding the FSMO Role Holder
It is fairly straightforward to find the schema owner using the LDP utility. Launch LDP.exe. The below instructions follow what is documented in the official VMware KB article:
Initiate a new connection from the LDP utility.
I am on the Horizon Connection Server itself, so I am choosing to connect to the loopback address 127.0.0.1.
Next, you need to bind the credentials for accessing LDAP.
Most likely, you will be able to Bind as currently logged on user.
Select Tree under the View menu.
Select the Schema entry under the Tree View dialog box.
You will see the server that is listed as the FSMO role owner in the output. Below, HZCON02 is a dead connection server that is offline.
Seizing the FSMO Roles
If something bad happens in the Horizon environment where the FSMO role is assigned to a Connection Server that no longer exists, you need to go in and seize the role from the Connection Server.
This often happens when someone removes a Connection Server replica server from the cluster incorrectly without stopping replication. The process to seize the FSMO roles is fairly easy. If you have done this with an Active Directory server, the process feels very similar.
As you can see below, the FSMO roles are now assigned to HZCON01.
Properly stop replication before removing a Connection Server
Before you uninstall a VMware Horizon Connection Server, you want to properly stop replication from replicating changes to the server you intend to remove. This is a simple command that you run from another Connection Server.
- vdmadmin -S -r -s <connection_server_to_remove>
Once you have ran the command, you are safe to uninstall the Connection Server installation.
Wrapping Up
VMware Horizon Make Replica Connection Server Standard is a fairly straightforward process once you understand the pieces and parts of how the connection servers communicate. You always want to have multiple Connection Servers as this allows for redundancy and load balancing of connections. If you have a Connection Server go down for whatever reason, you will still have a Connection Server up and running to service connection requests.
