Upgrading Horizon from Security Servers to Unified Access Gateways
This guide gives an overview of how to update a VMware Horizon® deployment to use VMware Unified Access Gateways™ instead of security servers.
The Unified Access Gateway has many benefits over the legacy security server. Unified Access Gateway does not require a Windows license as it is built on Photon OS and is distributed as a hardened virtual appliance.
With Unified Access Gateway, the Horizon protocol session is not tunneled through a Connection Server. This allows for a simplified architecture, fewer Connection Servers, and less resources for the management components.
The Unified Access Gateway can utilize multiple forms of multi-factor authentication (MFA), including RSA, RADIUS, and SAML-based solutions. Multi-factor authentication is first validated on the Unified Access Gateway, in the DMZ, ensuring that only authenticated traffic is allowed into the internal network and the Horizon Connection Servers.
With the release of VMware Horizon 8, several legacy components were removed or deprecated. This includes security servers, which are no longer supported from Horizon 8 2012 and later. Before upgrading to Horizon 8, you should replace any security servers with Unified Access Gateways.
A typical deployment of Horizon with security servers has two sets of Connection Servers in the pod. One set is used for internal connections, whereas the second set are paired with the security servers for external connections. When paired with a security server, a Connection Server must have the Blast and PCoIP gateways enabled. This effectively tunnels sessions through the Connection Server. For internal sessions, you would not normally want to tunnel sessions through the Connection Server.
Figure 1: Security Server Logical Architecture (Typical)
Replacing the security servers with Unified Access Gateways allow us to simplify this architecture. When using Unified Access Gateway to provide external access to Horizon, the same Connection Servers can be used for both external and internal connections.
Figure 2: Unified Access Gateway Logical Architecture
With the preferred architecture for traffic flow and load balancing of Unified Access Gateways and Connection Servers, a load balancer is not placed in-line between the Unified Access Gateways and the Connection Servers. The architecture simplifies the design and makes it easier to troubleshoot.
Even though Figure 2 depicts the preferred architecture, it is also possible to place a load balancer between the Unified Access Gateways and the Connection Servers, for example, when there are unequal amounts of Unified Access Gateways and Connection Servers.
See External Access Architecture in the Reference Architecture for more guidance on designing Unified Access Gateway deployments for Horizon. See the Unified Access Gateway documentation for an overview of .
This guide helps you to update a Horizon deployment, replacing legacy security servers with new Unified Access Gateways. At a high-level, the steps involved are:
- Deploy the Unified Access Gateways.
- Set up a new load balancer virtual service for the new Unified Access Gateways.
- Test user access.
- Changeover - Change access to use the new Unified Access Gateways.
- Cleanup - Remove any old servers and components no longer required.
In the example environment there are two security servers, each of which is paired with a dedicated Connection Servers. There is a load balancer in front of the security servers and an external listener on the firewall that is redirecting traffic to the load balancer virtual IP address for the security servers.
Figure 3: Initial Environment with Security Servers
Deploy two new Unified Access Gateways, which will replace the old security servers. Also, set up a new load balancer virtual service and IP address, for those Unified Access Gateways.
This allows you to set up the new Unified Access Gateways in parallel to the security servers and not disrupt user access. It also permits the testing of access through the new Unified Access Gateways before changing user access to use them.
Figure 4: Interim Environment with New Unified Access Gateways
There are two ways to deploy a Unified Access Gateway. You can do a manual deployment where the OVA file is imported with the vSphere Client, and then the settings are manually configured through the admin console. The second, and preferred, option is the PowerShell deployment method. A PowerShell script and the are used to automatically deploy a Unified Access Gateway appliance from the OVA file, with the configuration getting applied from an INI settings file during that deployment.
The PowerShell method is very straightforward, you do not need to know any PowerShell; this just requires you to run a single PowerShell command feeding in a setting file that defines how the Unified Access Gateway is deployed and configured. The PowerShell method also means that the Unified Access Gateway is fully configured and operational as part of the deployment.
A Unified Access Gateway can be deployed with 1, 2, or 3 network cards to allow you to match your DMZ networking requirements. This allows separation of external, internal, and management traffic as required. See for more detail.
Review and , to understand the traffic flow and ports required. Pay attention to any network routing required from the Unified Access Gateway to the network segments where the Connection Servers and the Horizon Agents reside.
With Unified Access Gateways, you also have an alternative to use the built-in high availability (HA) feature. One consideration with HA is that you require N+1 public IP addresses; one for the virtual IP address, and one per Unified Access Gateway appliance. See and .
Regardless of which method you choose, you should set up a new virtual IP address for the Unified Access Gateways. Keeping this separate from the security servers and their virtual IP address allows the new deployment of Unified Access Gateways to be tested without interfering with the existing infrastructure.
With multiple Connection Servers fronted by a virtual IP address and common FQDN, it is necessary to change origin checking on each Connection Server. If origin checking is left enabled, the load balanced name used to initiate a connection would not match the actual Connection Server name. This can cause the Connection Server to reject the request. See the Origin checking section of .
Unified Access Gateway supports multiple authentication options, for example, pass-through, RSA SecurID, RADIUS, SAML, and certificates, including smart cards. Pass-through authentication forwards the request to the Connection Server. Other authentication types enable authentication at the Unified Access Gateway, before passing authenticated traffic through to the Connection Server. For more information, see the Authentication section of the .
This is different from how the security server architecture implemented other authentication types such as smart card, or 2-factor with RSA SecurID or RADIUS. With security servers, this was configured on the paired Connection Servers.
Authentication settings can be configured at deployment time if using the PowerShell method for installing Unified Access Gateways.
Register Unified Access Gateways with Connection Servers
After you have the Unified Access Gateways deployed and configured, with a virtual IP address provided by either a load balancer or the built-in high availability, you can plan for switching user access to use these instead of the old security servers.
As part of switching the environment, you should complete the following steps:
- Test access to Horizon desktops and apps through the Unified Access Gateways.
- Changeover - Change the firewall redirection to forward traffic to the load balancer virtual IP address for the Unified Access Gateways.
- Cleanup - Remove security servers and any unneeded Connection Servers
Before altering any of the active traffic configuration and directing real user sessions to the Unified Access Gateways, you should test access to Horizon desktops and apps through them.
If possible, set up a second firewall listener that forwards traffic to the virtual IP address for the Unified Access Gateways. This allows you to test truly external connections. If that is not possible, use a temporary machine located in the DMZ to launch Horizon sessions and test connectivity.
When you are satisfied that you can access Horizon resources through the Unified Access Gateways, you can change over to using them instead of the security servers. This can be achieved by changing the target for the listener on the firewall. Instead of sending traffic to the load balancer virtual IP address for the security server, change it to now send traffic to the virtual IP address for the Unified Access Gateways.
Figure 5: Changing over to Use the Unified Access Gateways
After completing the changeover as described previously, test access again and satisfy yourself that everything is working as planned.
The final step is to clean up the environment and remove any unneeded components, including the security servers and the Connection Servers that they were paired with. You might also want to clean up the old load balancer virtual service that you had for the security servers.
- Remove the security servers from the environment following the instructions in steps 1 and 2 of .
- To remove Connection Servers previously used with security servers, see the following KB:
Figure 6: Final Architecture with Unified Access Gateways
Summary and Additional Resources
The following updates were made to this guide:
Description of Changes
About the Author
is a Senior Staff End User Computing Architect in the EUC Technical Marketing team. He leads the development of deep dive technical content for VMware customers, partners, and the VMware technical community to be effective in understanding VMware EUC solutions. This includes leading the design and writing of Reference Architecture papers, guides, and development of tools that assist in the design, deployment, management, and monitoring of VMware EUC products.
Your feedback is valuable.