Using Horizon to Access Physical Windows Machines

Overview

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.

Figure 1: Securely Accessing Physical Office-Based PCs

Although best known for its myriad of benefits when implementing virtual desktops and application servers, Omnissa Horizon 8 goes beyond brokering virtual machines. Omnissa Horizon 8 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.

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

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

The Horizon Client authenticates to a Horizon Connection Server.
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/11 machines.
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 Horizon Client Documentation.

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

The Horizon Client authenticates to a Connection Server through the Unified Access Gateway.
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.

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 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

Versions

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

Table 1: OS Editions and Horizon 8 Versions

OS Edition	Horizon 8 Version	Protocol Supported
Windows 11 22H2 (Enterprise)	2206 and later	Blast or RDP
Windows 11 22H2 (Education and Pro)	2206 and later	Blast
Windows 11 21H2 (Enterprise)	2106 and later	Blast or RDP
Windows 11 21H2 (Education and Pro)	2106 and later	Blast
Windows 11 (non-Enterprise, Education or Pro)	2206 and later	RDP
Windows 10 1909 and later (Enterprise)	2006 and later	Blast or RDP
Windows 10 20H2 and later (Education and Pro)	2206 and later	Blast
Windows 10 (non-Enterprise, Education or Pro)	2006 and later	RDP
Linux RHEL 8.x and 9.x	2309 and later	Blast

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 Omnissa Horizon 8.x (2006 and Later) (78714).

For details on support for physical Linux machines, see Prepare a Physical Linux Machine for Desktop Deployment.

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

Architecture and design

Omnissa Horizon 8 is a platform for managing and delivering virtualized, session-based, or physical desktops and applications to end users. Horizon 8 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 8 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.

Components

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

Table 2: Horizon Components

Component	Description
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 virtual machines. 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	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.

Sizing

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 Omnissa Configuration Maximums.

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 8 Architecture chapter of the Workspace ONE and 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 Workspace ONE and 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 virtual machines or physical computers.

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.

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.

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.

If the chosen load balancer has the capability, the primary and the secondary traffic can be routed through the load balancer, if the chose load balancer has this capability. That ensures the correct routing of secondary protocol sessions by using source IP affinity and 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:

Unified Access Gateway High Availability
Unified Access Gateway Configured with Horizon
High Availability section in Unified Access Gateway Architecture.

Scaling

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.

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.

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.

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.

Figure 8: Multiple Horizon Pods Federated with Cloud Pod Architecture

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

Authentication

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.

Figure 9: Unified Access Gateway Pass-Through Authentication

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.

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 Tech Zone guide 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 Blast Extreme.

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

RDP

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 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 Horizon 8 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.

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.

Figure 13: RDP Network Ports

The Network Ports in Horizon 8 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

Source	Destination	Network Protocol	Destination Port	Details
Horizon Client	Unified Access Gateway	TCP	443	Login traffic. Can also carry tunneled RDP, client-drive redirection, and USB redirection traffic.
		UDP	443	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.
		TCP	8443	Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (performant channel).
		UDP	8443	Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (adaptive transport).
		TCP	443	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	TCP	8443 Or 443	Horizon HTML Access (web-based client). 8443 is the default but can be changed to 443 on Unified Access Gateway.

Notes:

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

Source	Destination	Network Protocol	Destination Port	Details
Unified Access Gateway	Horizon Connection Server	TCP	443	Login.
	Horizon Agent	TCP	22443	Blast Extreme.
		UDP	22443	Blast Extreme.
		TCP	3389	RDP.
		TCP	9427	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.
		TCP	32111	Optional for USB redirection. USB traffic can also be side-channelled in the Blast Extreme ports indicated previously. See note below.

Note: With the Horizon 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

Source	Destination	Network Protocol	Destination Port	Details
Horizon Agent	Horizon Connection Server	TCP	4002	Java Message Service (JMS) when using enhanced security (default).
		TCP	4001	JMS (legacy).
		TCP	389	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.

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.

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.

Figure 16: Double DMZ Deployment with Minimal Network Ports

For more information, see Double DMZ Deployment.

Implementation

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:

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

Considerations

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 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.

NVIDIA GPU

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.

OpenGL

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 https://developer.nvidia.com/designworks for more detail and to download the tool. This should be installed on the physical PC.

Requirements

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 Supported Operating Systems, Microsoft Active Directory Domain Functional Levels, and Events Databases for Omnissa Horizon 8 (78652.

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.

Installation

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

Install the first standard Connection Server – See Install Horizon Connection Server with a New Configuration.
Install a second Connection Server – See Install a Replicated Instance of Horizon Connection Server.
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:

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

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

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

For the full process, see Configuring TLS Certificates for Horizon 8 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 Secure DMZ design with multiple network interfaces.

Certificates

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 TLS/SSL certificates.

Installation

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 Unified Access Gateway. 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:

A specific guide has been released covering the deployment of Unified Access Gateway with the Horizon edge service:

Configuring the Horizon Edge Service in Unified Access Gateway - shows how to use the PowerShell deployment method to install 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.

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 Installing Horizon Agent for Windows Silently.

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

Omnissa-Horizon-Agent-x86_64-zzxx-y.y.y-xxxxxx.exe /s /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER_NAME=cs1.domain.com 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, cs1.domain.com. In addition, the installer installs the default features (Core, Blast, PCoIP, Virtual video driver, Unity Touch, PSG), and optional features USB redirection, Audio, Real-Time Audio-Video, Client Drive Redirection, Horizon Performance Tracker, Horizon Help Desk Tool, and Integrated Printing.

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

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

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 https://github.com/andyjmorgan/HorizonRemotePCHelperScripts

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 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.

Figure 17: Group Policy to Disable Direct RDP Connections

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

This applies the following registry setting to the Physical PCs.

HKEY_LOCAL_MACHINE\Software\Policies\Omnissa\Horizon\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 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
Type	Manual desktop pool
Machine Source	Other Sources
User Assignment	Dedicated Disable automatic assignment	Floating

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

Add – The physical machine is added to desktop pool.
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.
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 https://github.com/chrisdhalstead/horizon-physical-machines. 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:

Machine,Username
machine1,domain\user1
machine2,domain\user2

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

Important: This tool is supplied as-is and is not supported by Global Support (GS). 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.

Prerequisites:

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

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
Type	Desktop Entitlement
User Assignment	Dedicated	Floating
Default Display Protocol	Horizon 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	N/A

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

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.
Add Local Pools – From each Horizon Pod, add the Local Pool to the Global Entitlement.

See How do I Create and Configure a Global Entitlement in Horizon Console? 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 Omnissa Customer Connect. 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://<horizon.domain.com>/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 Configuring HTML Access for End Users.

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 Knowledge Base article Horizon Client Feature Matrix for Horizon 8 and Horizon Cloud on Azure (80386) for details.

Summary and additional resources

Changelog

This section lists the changes made to this document.

Date	Changes
2025-01-15	Graphics updated for Omnissa branding.
2024-05-16	Updated for Omnissa docs, KB, and Tech Zone links,
2024-04-03	Added Linux RHEL to list of OS in Versions.
2023-03-15	Remove references to Horizon 7. Remove references to older versions of Windows, including Windows 7. Update Horizon Agent Installation to add HznVaudio to command line example.
2022-07-19	Added rows to the Versions table for Windows 10 and 11 Education and Pro.
2021-06-23	New detail on NVIDIA GPU support added in Horizon 8 2106. Added more info on OpenGL.
2021-03-22	Added link to recommended patch when using Windows 10 version 1903.
2021-03-02	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.
2020-09-24	Updated to also cover Horizon 8. All links updated to Horizon 8 version 2006 and Unified Access Gateway version 2009.
2020-04-16	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.
2020-03-31	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
2020-03-25	Added section on single and double DMZ deployments Added section on configuring global entitlements Added list of contributors
2020-03-20	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.
2020-03-19	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

This guide was written by:

Graeme Gordon is a Senior Staff Architect, Omnissa.

Contributors

Chris Halstead, Senior Staff Product Manager, Omnissa, wrote the tool to automate the creation of a desktop pool, entitlement and assignment of the user.
Andrew Morgan, Alumni, wrote PowerShell script to automate the deployment of the Horizon Agent to physical PCs.

Reviewers

Josh Spencer, Group Product Line Manager, Omnissa.
Rick Terlep, Staff Architect, Omnissa.

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.