Using Horizon to Access Physical Windows Machines


When faced with unpredictable events like natural disasters, emergencies, or public health outbreaks, organizations are being asked to take action and enable their workforce to access corporate resources remotely. In many cases, the user has a physical Windows machine located in their normal place of work, the office. That machine has all the applications, access to data, and tools that the user needs to do their work. The challenge is that the user is unable to physically get to their machine.

What is needed is a solution to enable working from home that gives users secure remote access to their work machine, and the solution needs to be quick and easy to deploy.


Description automatically generated

Figure 1: Securely Accessing Physical Office-Based PCs

VMware is well known for virtualization technologies, but VMware Horizon® goes beyond brokering virtual machines. Although best known for its myriad of benefits when implementing virtual desktops and application servers, Horizon also offers the option to broker access to physical machines. This provides an excellent and familiar experience for employees.

Brokering to physical machines can be implemented either with an existing Horizon environment or with a new one. With minimal components required, this solution can be implemented quickly.

Connections are encrypted and Horizon supports multiple authentication options including SAML, RADIUS, RSA SecurID, and certificates, including smart cards. Authentication can be carried out in the DMZ at the Unified Access Gateway, before passing authenticated traffic through to the internal resource.

To provide support to users, Horizon has the Horizon Help Desk Tool. This is a web application that you can use to get the status of Horizon user sessions and to perform troubleshooting and maintenance operations. See Using Horizon Help Desk Tool in Horizon Console.

This guide gives technical detail, with design and implementation considerations and guidance, on how to achieve this.


Description automatically generated

Figure 2: Securely Accessing Physical Office-Based PCs with Horizon

Horizon enables access to office-based physical machines by using just a few core Horizon components:

  1. The VMware Horizon® Client authenticates to a Horizon Connection Server.
  2. The Connection Server brokers a connection to a Horizon Agent running on a Horizon-managed desktop or server. For this use case, the Horizon Agent is installed on physical Windows 10 machines.
  3. The Horizon Client then forms a protocol session connection to a Horizon Agent in the physical machine.

The Horizon Client is available for all major OS platforms including Windows, Mac, Linux, iOS, Android, Chrome OS and also as HTML Access. HTML Access allows users to use a web browser to act as the Horizon Client, where installation of the client software is not possible. See VMware Horizon Client Documentation.

To provide secure access from external locations and over the Internet, VMware Unified Access Gateway™ is deployed to provide secure edge services.

  1. The Horizon Client authenticates to a Connection Server through the Unified Access Gateway.
  2. The Horizon Client then forms a protocol session connection, through the gateway service on the Unified Access Gateway, to the Horizon Agent running in the physical desktop.


Description automatically generated

Figure 3: Secure External Access with Authentication Through Unified Access Gateway

User authentication can be configured in various ways. By default, Active Directory credentials are used, but this can be enhanced with two-factor or alternative authentication initiated from Unified Access Gateway. See the section on Authentication later in this guide.

You can quickly set up and configure Horizon for use as an interim solution to broker access to physical machines. This setup also creates an excellent foundation that can be built on, at a later date, to realize the full benefits of the complete Horizon and VMware Workspace ONE® platform. These include:

  • Delivering pristine high-performance personalized desktops to end users every time they log in
  • Scaling published applications effortlessly at the push of a button while deploying them faster and eliminating image sprawl
  • Reducing endpoint security concerns by destroying desktops as soon as users log off
  • Drastically lowering costs by pooling required infrastructure components and providing a truly stateless desktop that still delivers the personalization end users expect


Horizon 8 can be used to broker to physical desktop machines using both Blast Extreme and RDP display protocols.

Table 1: Windows and Horizon Versions

Windows Version

Horizon Version


Windows 11 22H2 (Enterprise)

8 (2206 and later)

Blast or RDP

Windows 11 22H2 (Education and Pro)

8 (2206 and later)

Blast only

Windows 11 21H2 (Enterprise)

8 (2106 and later)

Blast or RDP

Windows 11 21H2 (Education and Pro)

8 (2106 and later)

Blast only

Windows 11 (non-Enterprise, Education or Pro)

8 (2206 and later)

RDP only

Windows 10 1909 and later (Enterprise)

8 (2006 and later)

Blast or RDP

Windows 10 20H2 and later (Education and Pro)

8 (2206 and later)

Blast only

Windows 10 (non-Enterprise, Education or Pro)

8 (2006 and later)

RDP only

For full details on which versions of Windows 10 and Windows 11 are supported with which version of Horizon, see Supported Windows 10 and Windows 11 Guest Operating Systems for Horizon Agent and Remote Experience, for VMware Horizon 8.x (2006 and Later) (78714)

See Display Protocols for more information on Blast Extreme and RDP.

Architecture and Design

Horizon is a platform for managing and delivering virtualized, session-based, or physical desktops and applications to end users. Horizon allows you to create and broker connections to Windows virtual desktops, Linux virtual desktops, Remote Desktop Server (RDS)–published applications and desktops, and physical machines.

A successful deployment of Horizon depends on good planning and a robust understanding of the platform. This section focuses on the main design topics required for a Horizon environment brokering connections to physical desktops.


The required core components of Horizon are described in the following table.

Table 2: Horizon Components



Connection Server

The Horizon Connection Server securely brokers and connects users to desktops and published applications running on physical PCs, blade PCs, RDSH servers, or VMware vSphere® VMs.

The Connection Server authenticates users through Active Directory and directs the request to the appropriate and entitled resource.

Horizon Agent

The Horizon Agent is installed on the guest OS of target physical systems or VMs. This agent allows the machine to be managed by Connection Servers and allows a Horizon Client to form a protocol session to the machine.

Horizon Client

The Horizon Client is installed on a client device to access a Horizon-managed system that has the Horizon Agent installed.

You can optionally use a web browser as an HTML client for devices on which installing client software is not possible.

Unified Access Gateway

VMware Unified Access Gateway is a virtual appliance that enables secure remote access from an external network to a variety of internal resources, including Horizon-managed resources.

Unified Access Gateway supports multiple use cases, but for the purposes of this guide, we will focus on providing secure external access to desktops managed by Horizon on-premises.

When providing access to internal resources, Unified Access Gateway can be deployed within the corporate DMZ or internal network, and acts as a proxy host for connections to your company’s resources. Unified Access Gateway directs authenticated requests to the appropriate resource and discards any unauthenticated requests. It also can perform the authentication itself, leveraging an additional layer of authentication when enabled.


This section gives guidance on the recommended sizing and load for each of the required components. For the most current numbers for Horizon 8, see the Horizon 8 2012 Configuration Limits.

Connection Server

A single Connection Server supports a maximum of 4,000 sessions. To ensure that the environment includes redundancy and is able to handle failure, deploy one more server than is required for the number of connections (n+1).

One key concept in a Horizon environment design is the use of pods and blocks, which gives us a repeatable and scalable approach. When we are brokering connections only to physical desktops, we need focus only on the pod construct and can ignore the block construct.

  • A pod is made up of a group of interconnected Connection Servers that broker connections to desktops or published applications.
  • Up to seven Connection Servers are supported per pod.
  • A pod can broker up to 20,000 sessions, including desktop and RDSH sessions.
  • Multiple pods can be interconnected using Cloud Pod Architecture (CPA).

For complete design guidance, see the Horizon Architecture chapter of the VMware Workspace ONE and VMware Horizon Reference Architecture.

Unified Access Gateway

Unified Access Gateway gives three sizing options during deployment: standard, large, and extra-large. When deploying to provide secure edge services for Horizon, the standard size should be used.

A standard-sized Unified Access Gateway supports up to 2,000 Horizon sessions.

For complete design guidance, see the Unified Access Gateway Architecture chapter of the VMware Workspace ONE and VMware Horizon Reference Architecture.

Desktop Pools

Desktop pools are required to allow management, entitlement, and user assignment to the desktop objects within Horizon. There are two main types of virtual desktop pools: automated and manual. Manual desktop pools are a collection of existing VMware vCenter Server® virtual machines, physical computers, or third-party virtual machines.

An individual pool should contain no more than 2,000 desktops.

For the use case of managing physical desktops, manual pools are used. Manual assignment is made to the individual desktops to ensure that each employee gets connected to their own familiar physical machine.

Load Balancing 

It is strongly recommended that end users connect to Unified Access Gateway using a load-balanced virtual IP (VIP). This ensures that user load is evenly distributed across all available Unified Access Gateway appliances. Using a load balancer also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and configuration changes while minimizing impact to users. An existing load balancer can be used, or a new one such as VMware Avi Vantage can be deployed. See Configure Avi Vantage for VMware Horizon for more details.

When load balancing Horizon traffic to multiple Unified Access Gateway appliances, the initial XML-API connection (authentication, authorization, and session management) needs to be load balanced. The secondary Horizon protocols must be routed to the same Unified Access Gateway appliance to which the primary Horizon XML-API protocol was routed. This allows the Unified Access Gateway to authorize the secondary protocols based on the authenticated user session.

If the secondary protocol session is misrouted to a different Unified Access Gateway appliance from the primary protocol one, the session will not be authorized. The connection would therefore be dropped in the DMZ, and the protocol connection would fail. Misrouting secondary protocol sessions is a common problem if the load balancer is not configured correctly.

The load balancer affinity must ensure that XML-API connections made for the whole duration of a session (with a default maximum of 10 hours) continue to be routed to the same Unified Access Gateway appliance.

With the use case of providing secure, external access to resources, there is no need to provide a single namespace to the Horizon Connection Servers because only external users will be connecting. This means that there is no need to provide a load balancer VIP in front of the Connection Servers.


Description automatically generated

Figure 4: Load Balancer Required for Unified Access Gateway Appliances but Not for Connection Servers

Although the secondary protocol session must be routed to the same Unified Access Gateway appliance as was used for the primary XML-API connection, there is a choice of whether the secondary protocol session is routed through the load balancer or not. This normally depends on the capabilities of the load balancer.

For example, with a VMware NSX Advanced Load Balancer (formerly Avi), primary and secondary protocol traffic goes through the Avi Service Engines, and that ensures the correct routing of secondary protocol sessions by using source IP affinity. This has the advantage that there needs to be only a single public IP address. Where the load balancer does not have this capability, another option is to dedicate additional IP addresses for each Unified Access Gateway appliance so that the secondary protocol session can bypass the load balancer.

For more detail on load balancing of Unified Access Gateway appliances, see:

High Availability

As an alternative to using an external load balancer, Unified Access Gateway provides, out-of-the-box, a high-availability solution for the Unified Access Gateway edge services. The solution supports up to 10,000 concurrent connections in a high-availability (HA) cluster and simplifies HA deployment and configuration of the services.

For more information on the Unified Access Gateway High Availability component and configuration of edge services in HA, see the following resources:


Designing to the recommended sizing of up to 2,000 Horizon sessions per Unified Access Gateway appliance and 2,000 sessions per Connection Server, a minimal deployment would have one of each server type.


Description automatically generated

Figure 5: Minimal Design with Only One Unified Access Gateway Appliance and One Connection Server

But as mentioned earlier, we should design for availability and deploy at least one additional Unified Access Gateway and one additional Connection Server. As an additional Unified Access Gateway is added:

  • It is added to the load balancer VIP.
  • It uses the new Connection Server, deployed at the same time, as a Connection Server URL target.


Description automatically generated

Figure 6: Design for High Availability Using Two Unified Access Gateway Appliances and Two Connection Servers

As we scale up the environment to cater to an increasing number of connections, we can add up to seven Connection Servers in the pod.


Description automatically generated

Figure 7: Design for Maximum Scale Using Seven Unified Access Gateway Appliances and Seven Connection Servers

To scale higher than a single pod, multiple pods can be deployed and can be interconnected using Cloud Pod Architecture (CPA). Pods can be deployed on the same site or on different sites. Using Cloud Pod Architecture gives the option of global entitlements. A user can be connected to any Connection Server from any Horizon Pod that is part of the same Cloud Pod Architecture and will be directed and connected to the correct desktop, even if this is managed by another Pod.


Description automatically generated

Figure 8: Multiple Horizon Pods Federated with Cloud Pod Architecture

For the full documentation on how to set up and configure CPA, refer to Administering Cloud Pod Architecture in Horizon.


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 internal server or resource. Other authentication types enable authentication at the Unified Access Gateway, before passing authenticated traffic through to the internal resource.

These options are depicted in the following diagrams.


Description automatically generated

Figure 9: Unified Access Gateway Pass-Through Authentication


Description automatically generated

Figure 10: Unified Access Gateway Two-Factor Authentication

You can also use SAML to authenticate Horizon users against a third-party identity provider (IdP), leveraging Unified Access Gateway as the service provider (SP). This capability requires Horizon Connection Server version 8 2006 and later, and user authentication must go through Unified Access Gateway.

The authentication sequence can be configured as SAML and Passthrough or as just SAML:

  • When Auth Methods is set to SAML and Passthrough, the SAML assertion is validated by Unified Access Gateway, and Connection Server authenticates the user against Active Directory when launching remote desktops and applications.
  • When Auth Methods is set to SAML, the SAML assertion is validated by Unified Access Gateway and passed to the backend. Users single sign-on, leveraging the Horizon True SSO feature, to the remote desktops and applications.

In both authentication methods, the user will be redirected to the IdP for SAML authentication. Both SP- and IdP-initiated flows are supported.


Description automatically generated

Figure 11: Unified Access Gateway SAML Authentication

For general information and configuration of SAML and Unified Access Gateway support for Horizon, see Configuring Horizon for Unified Access Gateway and Third-Party Identity Provider Integration.

For detailed information and step-by-step guidance on how to integrate Okta and Unified Access Gateway for Horizon authentication, see the VMware Tech Zone Operational Tutorial Enabling SAML 2.0 Authentication for Horizon with Unified Access Gateway and Okta.

For guidance on how to set up authentication in the DMZ, see Configuring Authentication in DMZ.

Display Protocols

Horizon is a multi-protocol solution, with three remoting protocols available when creating desktop pools or RDSH-published applications: Blast Extreme, PCoIP, and RDP. When connecting to physical machines, Blast Extreme or RDP can be used.  PCoIP cannot be used with physical desktop machines.

Blast Extreme

Where possible, it is recommended to use Blast Extreme because it provides a much richer user experience. Use the Horizon Agent version 8 2006, or later with the Horizon Client version 5.4 or later, as these introduce many optimizations and better performance for Blast. For more information on the key features, see VMware Blast Extreme.

See the VMware Blast Extreme Optimization guide for more information, including optimization tips and how to configure Blast Extreme for certain network conditions.


Some versions of Windows will not support the use of Blast as a display protocol. For these, use RDP.

Non-Enterprise Editions of Windows 10 and Windows 11

  • The only supported editions of Windows 10 and Windows 11 are Enterprise, Education, and Pro. Other editions of Windows may work with a few caveats.
  • Where possible, change the license type used for Windows to a supported edition to allow the use of the Blast display protocol.
  • On non-Enterprise, Education, or Pro editions of Windows, the RDP protocol should be used, so that the display is not mirrored on the physical monitor. See Versions.

While not supported, it may be possible to use newer versions of the Agent and Client while remaining on the older version of Connection Servers. This should be used as a proof of concept, as a test, to confirm functionality before proceeding with full component upgrade. If the newer agent does not successfully appear in the broker due to the version, you can use the direct access plugin to bypass the broker for testing.

Please refer to the Compatibility Matrix for Various Versions of VMware Horizon 8 Components - Upgrade Only for limitations in terms of component interoperability. You should factor in server component upgrades, as a crucial step in your onsite plans, to bring the whole environment up to the same version level. See VMware Horizon Upgrade Overview

Network Ports

To ensure correct communication between the components, it is important to understand the network port requirements for connectivity in a Horizon deployment. The following diagram shows the ports required to allow a Blast Extreme connection.

<p>Description automatically generated

Figure 12: Blast Extreme Network Ports

The network ports shown are destination ports. The tables that follow show more detail and indicate the source, destination, and the direction of traffic initiation. Horizon UDP protocols are bidirectional. Stateful firewalls should be configured to accept UDP reply datagrams.

The following diagram shows the ports required to allow an RDP connection.

<p>Description automatically generated with medium confidence

Figure 13: RDP Network Ports

The Network Ports in VMware Horizon guide has more detail, along with diagrams illustrating the traffic. It even has specific sections and diagrams on internal, external, and tunnelled connections. To see more detail on the network ports required for an external connection, see the External Connection section and the External Connection diagram.

Connection Server

The following table lists network ports for external connections from a client device to Horizon components.

Table 3: Network Ports for External Connections to Horizon Components



Network Protocol

Destination Port


Horizon Client


Unified Access Gateway



Login traffic.

Can also carry tunneled RDP, client-drive redirection, and USB redirection traffic.



Optional for login traffic. Blast Extreme tries a UDP login connection if the client experiences difficulty making a TCP connection to the Unified Access Gateway appliance.



Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (performant channel).



Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (adaptive transport).



Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic where port sharing is used. This would be instead of TCP 8443.

Browser for HTML Access

Unified Access Gateway



Or 443

Horizon HTML Access (web-based client).

8443 is the default but can be changed to 443 on Unified Access Gateway.


The Blast Secure Gateway on Unified Access Gateway can dynamically adjust to network conditions such as varying speeds and packet loss. In Unified Access Gateway, you can configure the ports used by the Blast protocol.

  • By default, Blast Extreme uses the standard ports TCP 8443 and UDP 8443.
  • However, port 443 can also be configured for Blast TCP.
  • Port configuration is set through the Unified Access Gateway Blast External URL property. See Blast TCP and UDP External URL Configuration Options.

Unified Access Gateway

The following table lists network ports for connections from a Unified Access Gateway to the Connection Server and the Horizon Agent.

Table 4: Network Ports for Connections Among Horizon Components



Network Protocol

Destination Port


Unified Access Gateway

Horizon Connection Server




Horizon Agent




Blast Extreme.



Blast Extreme.






Optional for client-drive redirection (CDR) and multi-media redirection (MMR).

By default, when using Blast Extreme, CDR traffic is side-channelled in the Blast Extreme ports indicated previously. If desired, this traffic can be separated onto the port indicated here.



Optional for USB redirection.

USB traffic can also be side-channelled in the Blast Extreme ports indicated previously. See note below.

Note: With the VMware Blast display protocol, you can configure features, such as USB redirection, and client drive redirection, to send side channel traffic over a Blast Extreme ports. See:

Horizon Agent

The following table lists network ports for connections from a physical, virtual desktop, or RDSH server to other Horizon components.

Table 5: Network Port Connections Between Horizon Agent and Connection Server



Network Protocol

Destination Port


Horizon Agent

Horizon Connection Server




Java Message Service (JMS) when using enhanced security (default).



JMS (legacy).



Required when doing an unmanaged agent registration; as is the case for physical machines.

Single DMZ

For on-premises deployment of Horizon within a data center of an organization, it is common to install Unified Access Gateway appliances in a single DMZ, which provides a network isolation layer between the internet and the customer data center.


Description automatically generated

Figure 14: Single DMZ Deployment

Unified Access Gateway has built-in security mechanisms for all the Horizon protocols to ensure that the only network traffic entering the data center is traffic on behalf of an authenticated user. Any unauthenticated traffic is discarded in the DMZ.

Double DMZ

Some organizations have two DMZs (often called a double DMZ or a double-hop DMZ) that are sometimes used to provide an extra layer of security protection between the Internet and the internal network. In a double DMZ, traffic has to be passed through a specific reverse proxy in each DMZ layer. Traffic cannot simply bypass a DMZ layer.

Note that in a Horizon deployment, a double DMZ is not required, but for environments where a double DMZ is mandated, an extra Unified Access Gateway appliance acting as a Web Reverse Proxy can be deployed in the outer DMZ.


Description automatically generated with medium confidence

Figure 15: Double DMZ Deployment

It is also possible to configure a double DMZ configuration for Horizon with minimal port requirements.  This will not be as performant as a deployment with full Horizon protocol and port support as depicted above.


Description automatically generated

Figure 16: Double DMZ Deployment with Minimal Network Ports

For more information, see Unified Access Gateway Double DMZ Deployment for Horizon.


This section provides an overview of the Horizon deployment process, points to specific documents for detailed instructions, and lists certain settings that were used in this guide. This assumes that you do not already have a Horizon environment in place. If an existing Horizon environment exists, you might be able to use that instead of setting up a separate environment.

At a high-level, the steps involved are:

  1. Install and configure Horizon Connection Servers.
  2. Install and configure Unified Access Gateways.
  3. Install the Horizon Agent on the physical machines.
  4. Configure the desktop pool – Add physical machines, entitle and assign the users.


Before deploying and configuring the solution, consider the following and adjust the configuration of the solution accordingly.

Machine Settings

Evaluate the power policies for the physical machines and make changes to minimize the possibility of physical machines being shut down.

  • All power saving options on physical machines should be disabled. This can be done by the use of a group policy (GPO).
  • If a physical machine crashes or is shuts down, no remote access will be possible to it until it is restarted.
  • Group Policies can be used to disable the shutdown option for users to minimize the risk of this.
  • The use of Wake-On-LAN could also be considered to ensure that machines are powered on.

User Assignment

Understand how users normally use their desktops, what type of desktop pool is best suited and how users should be assigned access.

One user per physical PC

  • In this use case, each physical machine has a single primary user.
  • Manual desktop pools will be used.
  • Dedicated user assignment will be used.
  • Users will be assigned to their specific physical desktop within the pool.

Pooled physical PCs

  • This is typical in a hot desk or shared environment where users can use any one of a pool of physical PCs.
  • In environments like these, good profile management and application deployment systems are usually already in place.
  • Manual desktop pools will be used.
  • Floating user assignment will be used. This ensures that a user is not assigned permanent ownership of any particular physical machine, which would exclude other users from using it even when it was available.

It has been reported that in some environments, physical desktop pools with floating assignment has resulted in two users being allocated the same machine which results in the first user getting disconnected.

If this behavior is observed, apply the following workaround. On the physical PCs, set the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Name: MaxInstanceCount
Value: 1

RDP and Network Level Authentication

If using RDP protocol, ensure that Network Level Authentication (NLA) is disabled in Windows. See the VMware Knowledge Base article Remote Desktop connection with NLA is not supported in Horizon View (67832) for details.

Mac Client

The Horizon Client for Mac does not support the use of the RDP display protocol. If Mac devices are used as clients, check that the combination of the version of Windows on the physical PC and version of Horizon support the use of Blast. Configure the desktop pool to use the Blast protocol and have users install the Horizon Client for Mac on their device.

For a full list of supported features on Mac Clients, see Feature Support for Mac Client.


Horizon 8 2106 introduced physical PC support for NVIDIA GPUs and encoders. With this, physical PC can directly leverage the GPU capability available to the Horizon Agent operating system. For a list of tested NVIDIA series, see Manual Pool of Registered Physical Machines.


With certain GPUs, physical PCs can use the Direct3D and OpenGL capabilities of the card can be utilized in remote sessions. See OpenGL Support in Horizon when using Physical Agent Desktops and Workstations (78690)

Where the physical PCs have NVIDIA GeForce GPU cards and are being used with OpenGL applications, NVIDIA have created a tool to accelerate Windows remote desktop use of these applications. See for more detail and to download the tool. This should be installed on the physical PC.


This solution considers the customers’ existing Active Directory, DHCP, File Server, user profile management and any other associated infrastructure is already in-place to server the physical PCs.

Horizon requires a Microsoft Active Directory infrastructure for user authentication and management. Horizon supports certain Active Directory Domain Services (AD DS) domain functional levels. For more information, see

The WAN connection is a critical dependency on the usability of this solution.  Adding thousands of instances of remote desktop protocols to a WAN link will require a large amount of bandwidth.

Connection Servers

The Horizon Connection Server software must be installed on Microsoft Windows Servers. These should be dedicated servers with no other enterprise software installed. Windows Server 2022, or 2019 is supported.

It is recommended that these Windows Servers be allocated at least 4 vCPU and at least 10 GB of RAM. As with any other infrastructure components, these servers should be monitored to ensure they have sufficient resources. See Horizon Connection Server Requirements for more details.


This guide is not intended to replace the VMware Horizon Documentation. Follow the relevant sections of the Horizon Installation documentation to install the following components in the following order:

  1. Install the first standard Connection Server – See Install Horizon Connection Server with a New Configuration.
  2. Install a second Connection Server – See Install a Replicated Instance of Horizon Connection Server.
  3. Repeat step 2 for all other required Connection Servers.

Post-Installation Configuration

Connect to the first Connection Server and perform the following tasks in the following order:

  1. Apply a license key – See Enabling VMware Horizon 8 for Subscription Licenses and Horizon Control Plane Services.
  2. Configure event reporting – See Configuring Event Reporting in Horizon Console.
  3. Assign administrators and roles – See Configuring Role-Based Delegated Administration.

When you first install a Connection Server, it uses self-signed TLS server certificates. VMware does not recommend that you use these in production. At a high level, the steps for replacing the certificates on the Connection Servers are:

  1. Create a certificate signing request (CSR) configuration file. This file is used to generate the CSR to request a certificate.
  2. Once you receive the signed certificate, import it.
  3. Configure Horizon to use the signed certificate.

For the full process, see Configuring TLS Certificates for VMware Horizon Servers.

Unified Access Gateways

A Unified Access Gateway is a hardened Linux appliance that is available as a downloadable OVF (Open Virtualization Format) file. When deploying to provide secure edge services for Horizon, the standard size should be used. This allocates 2 vCPU and 4 GB of RAM to the appliance.

A Unified Access Gateway can be deployed with one, two, or three network interface controllers (NICs). The choice is determined by your network requirements and discussions with your security teams to ensure compliance with company policy.

Network Routing

During Unified Access Gateway deployment it is common to specify a default gateway. In complex environments involving multiple NICs and routing through more than one gateway, Unified Access Gateway also supports the ability to specify static IP routes. These are routes that don't use the default gateway.

Ensure that the network configuration allows for the proper routing of traffic from the Unified Access Gateway appliances to the Connection Servers and the Horizon Agents, as shown in Network Ports. Where necessary, add static routes to Unified Access Gateway.

See DMZ Design for VMware Unified Access Gateway and the use of Multiple NICs.


TLS/SSL certificates are used to secure communications for the user between the Horizon Client and the Unified Access Gateway and between the Unified Access Gateway and internal resources.

Although Unified Access Gateway can generate default self-signed certificates during deployment, for production use, you should replace the default certificates with certificates that have been signed by a trusted certificate authority (CA-signed certificates).  You can replace certificates either during deployment or as part of the initial configuration. The same certificate or separate certificates can be used for the user and the administrative interfaces, as desired.

The following types of certificates are supported:

  • Single-server-name certificates, which means using a unique server certificate for each Unified Access Gateway appliance
  • Subject alternate name (SAN) certificates
  • Wildcard certificates

Certificate files can be provided in either PFX or PEM format.

For guidance on how to configure and update Unified Access Gateway to use TLS/SSL for the Admin UI, Horizon and Web Reverse Proxy edge services, see Configuring Unified Access Gateway Using TLS/SSL Certificates and Update TLS Server Signed Certificates.


There are two supported methods of deploying Unified Access Gateway.

  • Use a PowerShell script with a settings file.
  • Deploy an OVF template using the vSphere Client.

The recommendation is to use the PowerShell script method. This has several advantages, including the ability to fully configure the appliance at deployment time with all services configured and certificates applied.

More information on using the PowerShell method is available on the Using PowerShell to Deploy VMware Unified Access Gateway community page. The PowerShell script and sample INI files can be downloaded from the Unified Access Gateway product download page. For step-by-step instructions on how to deploy Unified Access Gateway, see the following articles on Tech Zone:

Specific guides have been released covering the deployment of Unified Access Gateway with the Horizon edge service:

Post-Installation Configuration

If you are using a load balancer, the Unified Access Gateways should be added to the server pool for the virtual IP (VIP).

To give administrative visibility into the status of the Unified Access Gateways in the Horizon Console dashboard, be sure to register the appliances. See Monitoring Unified Access Gateway in Horizon Console.

Horizon Agent Installation

You must install Horizon Agent on the physical machines to register them with the Connection Servers, so that you can then add them of a manual desktop pool. For instructions, see Prepare a non-vSphere Machine For Horizon 8 Management, which is part the Setting Up Virtual Desktops in Horizon guide.

Command Line

To install Horizon Agent on multiple machines without having to respond to wizard prompts, you can install Horizon Agent silently using a command-line command. See Install Horizon Agent Silently.

The following example installs Horizon Agent on an unmanaged computer and registers the desktop with the specified Connection Server, Note that while you register with a specific Connection Server, this registers it with all Connection Servers in the pod.

VMware-Horizon-Agent-x86_64-zzxx-y.y.y-xxxxxx.exe /s /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER_USERNAME=domain\username VDM_SERVER_PASSWORD=password REBOOT=Reallysuppress"

The following example installs Horizon Agent on an unmanaged computer and registers the desktop with the specified Connection Server, In addition, the installer installs the default features (Core, VMware Blast, PCoIP, Virtual video driver, Unity Touch, PSG), and optional features USB redirection, Audio, Real-Time Audio-Video, Client Drive Redirection, VMware Virtualization Pack for Skype for Business, Horizon Performance Tracker, Horizon Help Desk Tool, and VMware Integrated Printing.

VMware-Horizon-Agent-x86_64-zzxx-y.y.y-xxxxxx.exe /s /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER_USERNAME=domain\username VDM_SERVER_PASSWORD=password ADDLOCAL=Core,USB,VmwVaudio,RTAV,ClientDriveRedirection,VMWMediaProviderProxy,PerfTracker,HelpDesk,PrintRedir REBOOT=Reallysuppress"

For more command-line options, see Microsoft Windows Installer Command-Line Options and Silent Installation Properties for Horizon Agent.

Automation Script

To automate silent installation and more, a PowerShell script has been developed that remotely and silently deploys the Horizon agent. This can be downloaded at

As well as remotely deploying the Horizon Agent, this will script will:

  • Set the power policy to maximum performance.
  • Determine the primary user of the machine based on which user has logged in most frequently.
  • Determine the operating system, version, and edition.
  • Return all of these details (along with the exit code and version of the installed agent).

This script will also create a CSV mapping file that lists the machine name and the user name. This CSV mapping file can be used in the automation of the next step of configuring the Desktop Pool.

Important: This PowerShell script is supplied as-is and is not supported by VMware Global Support (GS). All tasks that it assists with can also be achieved manually without the use of the script.

It is advisable to configure a group policy (GPO) to ensure that the power management settings are not overridden. See Managing Power with Group Policy.

Prevent RDP Direct Access

Remote Desktop Services must be enabled on the physical PCs and is configured by default when installing the Horizon Agent. Remote Desktop Services are required for the Horizon Agent installation, single-sign-on, and other Horizon session-management operations.

In some environments, it may be desirable to prohibit direct access to the physical PCs through the RDP display protocol. To disable RDP access, create and apply a group policy setting to the physical PCs to disable AllowDirectRDP.

Graphical user interface, text

Description automatically generated

Figure 17: Group Policy to Disable Direct RDP Connections

For instructions on creating the group policy with this setting, see VMware View Agent Configuration ADMX Template Settings. Additionally, see Prevent Access to VMware Horizon Desktops Through RDP.

This applies the following registry setting to the Physical PCs.

HKEY_LOCAL_MACHINE\Software\Policies\VMware, Inc.\VMware VDM\Agent\Configuration
Type = String
Name: AllowDirectRDP
Value: false

When using the RDP protocol for Horizon connections do not disable the AllowDirectRDP setting. If this setting is disabled, RDP connections will be blocked and connections will fail with an Access is denied error.

To provide a better user experience and avoid users choosing the RDP protocol, configure the Remote Display Protocol settings in the Desktop Pool as follows:

  • Default Display Protocol set to VMware Blast.
  • Allow Users to Choose Protocol set to No.

Desktop Pool

A manual desktop pool needs to be created to contain the registered physical machines that have had the Horizon Agent installed.

When defining the desktop pool, use the following settings:

Table 6: Desktop Pool Settings


One User per Physical PC

Pooled Physical PCs


Manual desktop pool

Machine Source

Other Sources

User Assignment


Disable automatic assignment


Once the pool is created, three steps are required to add and make a physical machine ready for the user to connect to.

  1. Add – The physical machine is added to desktop pool.
  2. Entitle – The user is entitled to use the desktop pool, either through a user or a group entitlement. This step is not required if using Global Entitlements as part of a Cloud Pod Architecture. See below.
  3. Assign – If the use case is One User per Physical PC and the desktop pool is using dedicated assignments, the user should be assigned to the correct desktop. This step is not necessary for pooled physical PCs.

See Creating and Managing Manual Desktop Pools for more detail.

Automation Tool

A tool has been written to automate this task. This can be downloaded at Instructions on how to use the tool are included at that location.

The tool uses a CSV mapping file to add a list of machines to a pool. The tool then entitles the user and then assigns the user to their desktop. The CSV mapping file can be manually or automatically created by the PowerShell script described in the previous step of Horizon Agent Installation.

The CSV mapping file has two columns of data: machine and user name. The following example shows the format:


The tool will also assist in the creation of manual pools.

Important: This tool is supplied as-is and is not supported by VMware GSS. All tasks that it assists with can also be achieved manually without the use of the tool.

Global Entitlements

Global entitlements entitle users and groups to their desktops, when there are multiple Horizon Pods in a Cloud Pod Architecture federation. Global entitlements provide the link between users and their desktops, regardless of where the desktops reside in the pod federation.


  1. Initialize the Cloud Pod Architecture feature. See Initialize the Cloud Pod Architecture Feature.
  2. Join any additional Horizon pods into the federation. See Join a Pod to the Pod Federation.

When defining a global entitlement for physical desktops, use the following settings:

Table 7: Global Entitlement Settings


One User per Physical PC

Pooled Physical PCs


Desktop Entitlement

User Assignment



Default Display Protocol

VMware Blast or Microsoft RDP

Allow Users to Reset/Restart their Machines

Do not select

HTML Access

Select if web browser-based access is to be allowed

Display Assigned Machine Name

Optional but provides better user experience


Once the global entitlement is created, the following steps are required to add the local desktop pools to it and to entitle the users.

  1. Entitle Users and Groups – The user is entitled to use the global entitlement, either through a user or a group entitlement. This can also be done as part of the global entitlement creation.
  2. Add Local Pools – From each Horizon Pod, add the Local Pool to the Global Entitlement.

See Create and Configure a Global Entitlement for more detail.

Horizon Client

Ideally, users should install the Horizon Client on their home computer or personal device.

The client can be downloaded in a variety of ways. Clients can be downloaded from VMware, at If the endpoint device is Android or iOS, the Horizon Client can also be found in the Google Play Store and the Apple App Store.

Perhaps the easiest method for a user is to use a web browser and go to the user portal for Horizon after this has been installed and configured. The URL for the user portal uses the following format: https://<>/portal/.

The user portal detects the platform the endpoint device is running and presents the option to download the appropriate Horizon Client. For configuration instructions, see Configure the VMware Horizon 8 Web Portal Page for End Users.

A picture containing text

Description automatically generated

Figure 18: Horizon User Portal

If the physical machine being connected to is using Windows 10 or Windows 11, and the Blast Extreme protocol, end users can use the browser-based HTML Access client, which does not require the installation of any software. This web-based client is not as feature rich as the installed software client, as the features on each platform vary. See the pdf attachment in the VMware Knowledge Base article Horizon Client Feature Matrix for Horizon 8 and Horizon Cloud on Azure (80386) for details.


This section lists the changes made to this document.




Remove references to Horizon 7.

Remove references to older versions of Windows, including Windows 7.

Update Horizon Agent Installation to add VmwVaudio to command line example.


Added rows to the Versions table for Windows 10 and 11 Education and Pro.


New detail on NVIDIA GPU support added in Horizon 8 2106.

Added more info on OpenGL.


Added link to recommended patch when using Windows 10 version 1903.


Fixed incorrect data on versions of Windows 10 supported with Horizon 8 2006 and later in the Versions section.

Added link to new KB on supported Windows 10 versions with Horizon 8.


Updated to also cover Horizon 8.

All links updated to Horizon 8 version 2006 and Unified Access Gateway version 2009.


Clarifying language about the versions of Horizon and editions of Windows 10 that can be used.

Considerations on Windows patches for Windows 10 version 1903.

Link to NVIDIA tool when using OpenGL applications with NVIDIA GeForce GPUs.


Reorganized and expanded the Blast Extreme protocol into a section on display protocols, covering both Blast and RDP.

Ports diagram for RDP connections

Added networking routing considerations to the Unified Access Gateway implementation section.

New section preventing RDP direct access


Added section on single and double DMZ deployments

Added section on configuring global entitlements

Added list of contributors


Added more detail and examples on using the command-line to install the Horizon Agent.

Detail on using floating pools where there is a pool of hot desk or shared physical PCs.

Clearer detail on the versions of Windows and Horizon that can be used.


A new section was added to more clearly show the versions of Horizon 7 that can be used along with the detail on what functionality this delivers dependent on the version of Windows.

More detail on the use of Cloud Pod Architecture and global entitlements was added along with a diagram illustrating the architecture.

All documentation links updated to Horizon 7 version 7.12 and Unified Access Gateway version 3.9.

Author and Contributors


Graeme Gordon is a Senior Staff End-User-Computing Architect, End-User-Computing Technical Marketing, VMware.


  • Chris Halstead is a Senior Staff Technical Product Manager, VMware. He wrote the tool to automate the creation of a desktop pool, entitlement and assignment of the user.
  • Andrew Morgan is a Staff Engineer, End-User-Computing CTO Office, VMware. He wrote PowerShell script to automate the deployment of the Horizon Agent to physical PCs.


  • Josh Spencer is a Group Product Line Manager, VMware.
  • Rick Terlep is a Senior Technical Marketing Architect, End User Computing Technical Marketing, VMware.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at

Associated Content

home-carousel-icon From the action bar MORE button.

Filter Tags

Horizon Horizon Document Deployment Considerations Overview Win10 and Windows Desktop Design Deploy Business Continuity Secure Remote Access