Configuring Horizon for Avi Load Balancing

This is a continuation of my last post where we configured Avi to perform basic load balancing for VMware Horizon Connection Servers. The below information is relevant for any load balancer used in the same way for Horizon.

Now that we have Avi configured to support load balancing for the Horizon connection servers we need to make a few changes on the Horizon side. The Horizon connection servers shown below are running Horizon 2111. Keep in mind this is a basic configuration of Horizon and assumes internal LAN user sessions with only self-signed certificates. Best for a lab or demo environment.

Disable the Connection Server Tunnels

First, we should disable the tunnels (gateways) on the connection servers, although this is optional. When brokering internal (LAN) connections it’s best not to have the tunnels enabled. If the tunnels are enabled the connection servers will act as proxies for the user sessions which means additional overhead and if a connection server goes down the sessions are dropped. Most environments won’t find this beneficial to have on, but be sure to review any documentation before making a design decision for your environment. It’s best to add Unified Access Gateways (UAGs) to act as your tunnel/proxy for external WAN users’ sessions. I won’t be covering UAGs here.

To get started log into the Horizon Admin web portal.

Navigate to Inventory > Servers > Connection Servers. Then select one of the connections servers (A) and click Edit (B).

Unselect all of the tunnels unless you have a requirement in your environment to have one or more enabled.

By default when the Horizon Connection server is installed the HTTP(S) Secure Tunnel and Blast Secure Gateway are enabled by default. Here we are disabling both.

The screenshot below shows all 3 tunnels/gateways disabled. Click Ok once you’ve done that.

Now repeat those steps to disable the gateway services for any other Connection Servers in the load-balanced group.

Allow HTML to use the Load Balanced VIP

Next, we need to let the connection servers know what the load-balanced Virtual IP (VIP) is. Otherwise, HTML access won’t work. The official documentation for this step can be found here.

To do this we need to log into each connection server and create or edit the locked.properties file. It can be found in install_directory\VMware\VMware View\Server\sslgateway\conf\locked.properties. If this is a fresh Horizon install the locked.properties file won’t exist, but in some environments, you may already have it for other customization. Either way, navigate to the folder where it should be. In the below screenshot the file does not exist so we will create one.

I like to copy the path to the conf folder to use later as the save location.

Open up a new Notepad within the Connection Server. Enter the following: balancedHost=VIP where you replace VIP with your VIP FQDN previously configured in Avi. For example balancedHost=Horizon.iron.man in my lab environment.

From Notepad go to File > Save As and paste the path to the conf file location into the address bar (A) and press enter for Notepad to change the save directory. Then type the File name: locked.properties (B). Before saving be sure to change the Save as type to All Files (C). Click Save.

You can close Notepad now. You should see the locked.properties file as shown below.

For the change to apply you need to restart the Connection Server service or reboot the server. If you want to restart the service only just Run: services.msc or navigate to Windows services using Computer Management. Then locate the VMware Horizon View Connection Server service and right click it followed by Restart. It should take a few seconds to complete.

Click the Refresh icon to ensure the services shows the Status Running.

Now repeat these steps for your other Connection Servers behind the load balancer.

You should be all set to connect to your Horizon desktops or apps using the load-balanced VIP. If you’re still running self-signed certs you will get an extra prompt to accept that cert. It’s best practice for security and user experience to replace those certs with properly signed certificates.

Thanks for reading!

Leave a Reply

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