Omnissa Horizon Client Default Server

Omnissa Horizon Client Default Server
Omnissa Horizon Client Default Server

There are a few ways to preload the Omnissa Horizon client (formerly the VMware Horizon client) with a default Horizon Connection Server.

One method is to deploy the Horizon prefs.txt file with the Horizon connection server. For more information about the prefs.txt file method, my blog post, Omnissa Horizon Client prefs.txt, goes into detail.

Another method is the VDM_SERVER property. When you install the Horizon client, you can define the VDM_SERVER property. Omnissa does have some documentation about the VDM_Server property. However, it only says that you can use it to set a default horizon connection server for the users. It doesn’t go into detail on how it works. If you run the help command on the Horizon client installer, it doesn’t go into much more detail either.

Horizon client installer help dialog

Given that there isn’t a lot of info about the VDM_Server property, I needed to know more, and down the rabbit hole I went.

How does the VDM_Server property work, and is it better than using the prefs.txt file to preload the Horizon connection server? If the VDM_Server property works better, it could simplify how I’ve been deploying the Horizon client. I also needed to know if it works only for the user that installed the Horizon client or all users. I wanted to see if it did the same thing I did manually with the prefs.txt file.

If you install the Horizon client using the logging command /l or /log, everything the Horizon client install does is logged to a log file.

With logging enabled, I ran the Horizon client install with a value for the VDM_SERVER property. The command I ran was

.\Omnissa-Horizon-Client.exe VDM_SERVER="Horizon.1company.com;Horizon.2company.com" /l C:\temp\HorizonInstall.logCode language: PowerShell (powershell)

If you look at the log file that ends with the name ViewClientx64.log and look for the value you provided for the VDM_SERVER property, you will find that vdmInstUtil performed a custom action named VMWriteRegistryValues and created the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Omnissa\Horizon\Client\MRBrokerCode language: plaintext (plaintext)

with the value of the horizon connection server you entered.

I found Horizon.1company.com;Horizon.2company.com on lines 1771 and 1772 in the file HorizonInstall_003_ViewClientx64.log.

The Horizon client install log file ending with ViewClientx64.log

If you go into the registry and double-check, you will see a registry string named MRBroker with the value of the horizon connection servers you provided.

I was looking for Horizon.1company.com;Horizon.2company.com.

The MRBroker registry string in HKLM:\SOFTWARE\Omnissa\Horizon\Client

I found nothing in Omnissa’s documentation about the MRBroker registry key. Further down the rabbit hole I went.

Because the registry key MRBroker is in HKLM:\SOFTWARE\Omnissa\Horizon\Client, which is part of the local system registry, we know that the value is system-wide and not just for the user that installed the Horizon client.

Now I have more questions. What happens when a user launches the Horizon client? How does the Horizon client know that something is in that registry key, and what does it do with that information?

If you open up ProcMon (Process Monitor) and launch the Horizon client, you will notice that the Horizon client queries the registry for the registry key HKLM:\SOFTWARE\Omnissa\Horizon\Client\MRBroker then it creates the prefs.txt file.

ProcMon capture when launching the Horizon client

If you look at the resultant prefs.txt file, it will look something like this.

<?xml version="1.0" encoding="utf-8"?>
<Root>
  <RecentServer serverName="horizon.1company.com" />
  <RecentServer serverName="horizon.2company.com" />
  <GlobalDefaultServer serverName="Horizon.1company.com;Horizon.2company.com" />
</Root>Code language: HTML, XML (xml)

The prefs.txt file has an XML element named GlobalDefaultServer, which contains the value of the HKLM:\SOFTWARE\Omnissa\Horizon\Client\MRBroker registry key.

If a user already has an existing prefs.txt file, the registry value of MRBroker is added to the existing prefs.txt file, and everything else is left intact.

Horizon client has the default servers and a non-default server.

If you alter the value of MRBroker, the Horizon client will ensure the prefs.txt file contains the correct value.

We now know that the VDM_Server property is directly related to the registry value of MRBroker. With this information, we can predictably alter the value of MRBroker to have the Horizon client use a default connection server without needing to reinstall the Horizon client to use or change the VDM_Server installation property.

You can deploy the MRBroker registry key in many ways, and one method is with my PowerShell script called Registry Check Setter. To do so, you run it using the following command.

reg-check-set -reg_path "HKLM:\SOFTWARE\Omnissa\Horizon\Client" -reg_name "MRBroker" -reg_type string -reg_value "Horizon.1company.com;Horizon.2company.com"Code language: PowerShell (powershell)

That’s what I figured out about the Horizon client VDM_Server installation property and how you can preload the default Horizon connection server with the MRBroker registry key.

If you want to read more about the Horizon client installation properties, here is the Omnissa documentation.

Leave a comment

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