Solution

  • Horizon

Type

  • Document

Level

  • Overview

Category

  • Deployment Considerations

Product

  • Horizon 7

OS/Platform

  • Windows 10

Phase

  • Design
  • Deploy

Use-Case

  • Business Continuity
  • Secure Remote Access

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

VMware is well known for virtualization technologies, but VMware Horizon® 7 goes beyond brokering virtual machines. Although best known for its myriad 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 7 environment or with a new one. With minimal components required, this solution can be implemented quickly.

Connections are encrypted and Horizon 7 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 7 has the Horizon Help Desk Tool. This is a web application that you can use to get the status of Horizon 7 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 7

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

 

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

Versions

With Horizon 7 version 7.7, VMware introduced the ability to broker physical desktop machines running Windows 10 version 1803 and 1809 Enterprise Edition, via the Blast Extreme display protocol.

With Horizon 7 version 7.12, support for using Blast Extreme with Windows 10 versions 1903 and 1909 was added for physical desktop machines.

Earlier versions of Horizon 7, before version 7.7, can broker to physical desktop machines using the RDP protocol.

Notes:

  • Either the Blast Extreme or RDP protocol can be used with Horizon 7 version 7.7 and later, but Blast will give a better user experience. For more information on the key features see VMware Blast Extreme.
    • Non-Enterprise editions of Windows 10 (Pro, Education, etc.) do not support the Blast Extreme protocol.
    • The RDP protocol should be used, so that the display is not mirrored on the physical monitor.
    • If possible, change the license type used for Windows 10 to Enterprise edition.
  • Windows 7 physical machines will work with some caveats.
    • These can only use RDP as the display protocol.
    • The Horizon Client will need to be installed on the employee’s home device because HTML Access is not available for RDP connections.
    • Configure desktop pools that contain Windows 7 to use the RDP protocol.

Table 1: Windows and Horizon 7 Versions

Windows Version Horizon Version Protocol
Windows 10 Enterprise Edition 1903-1909 7.12 Blast or RDP
Windows 10 Enterprise 1803-1809 7.7 - 7.12 Blast or RDP
Windows 10 Enterprise 17xx 7.x

RDP only

Windows 10 (non-Enterprise) 7.x

RDP only

Windows 7 SP1 or later 7.x RDP only

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

Architecture and Design

Horizon 7 is a platform for managing and delivering virtualized, session-based, or physical desktops and applications to end users. Horizon 7 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 7 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 7 are described in the following table.

Table 2: Horizon 7 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 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 7 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, limits, and recommendations, see the VMware Knowledge Base article VMware Horizon 7 Sizing Limits and Recommendations (2150348).

Connection Server

A single Connection Server supports a maximum of 4,000 sessions, although 2,000 is recommended as a best practice. 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 7 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. A pod can broker up to 20,000 sessions (12,000 recommended), including desktop and RDSH sessions.

Up to seven Connection Servers are supported per pod with a recommendation of 12,000 desktop sessions in total per pod. Multiple pods can be interconnected using Cloud Pod Architecture (CPA).

For complete design guidance, see the Component Design: Horizon 7 Architecture section in VMware Workspace ONE and VMware Horizon Reference Architecture guide.

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 2,000 Horizon sessions.

For complete design guidance, see the Component Design: Unified Access Gateway Architecture section in VMware Workspace ONE and VMware Horizon Reference Architecture guide

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.

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 an F5 BIG-IP Local Traffic Manager (LTM), primary and secondary protocol traffic goes to the F5 LTM, 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:

Scaling

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

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

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.

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

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.

 

Design for Maximum Pod Scale Using Seven Unified Access Gateway Appliances and Seven Connection Servers

Figure 7: Design for Maximum Pod 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.

Multiple Horizon Pods Federated with Cloud Pod Architecture

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

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 new capability requires Horizon Connection Server 7.11 or 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 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 7 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 7.12 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.

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

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

Windows 7

  • Physical machines running Windows 7 will work with some caveats.
  • These can only use RDP as the display protocol.
  • The Horizon Client will need to be installed on the employee’s home device because HTML Access is not available for RDP connections.
  • Configure desktop pools that contain Windows 7 to use the RDP protocol.

Versions of Horizon 7 prior to version 7.7 will not support the use of Blast, but can broker to physical machines using the RDP display protocol. Ideally, upgrade the Connection Servers to version 7.12 or later and use Horizon Agent version 7.12 or later and Horizon Client version 5.4 or later to allow the use of the Blast display protocol. While not supported for an extended period, it may be possible to use the newer versions of the Agent and Client while remaining on the existing version of Connection Servers.

Network Ports

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

 

Blast Extreme Network Ports

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.

RDP Network Ports

Figure 13: RDP Network Ports

The Network Ports in VMware Horizon 7 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 see the external connection table and the External Connection diagram.

Connection Server

The following table lists network ports for external connections from a client device to Horizon 7 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 7 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 adjusts to network conditions such as varying speeds and packet loss. In Unified Access Gateway, you can configure the ports used by the BEAT 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 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 7 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.

Single DMZ Deployment

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.

Double DMZ Deployment

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.

Double DMZ Deployment with Minimal Network Ports

Figure 16: Double DMZ Deployment with Minimal Network Ports

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

Implementation

This section provides an overview of the Horizon 7 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 7 environment in place. If an existing Horizon 7 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.

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 VMware Knowledge Base articles Remote Desktop connection with NLA is not supported in Horizon View (67832) and Connecting to View desktops using RDP protocol fails with the error code 2825 (1034158) 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 7 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 Matrix for Mac Client.

Windows Patches

If the physical PCs are running Windows 10 version 1903, ensure that they are patched with KB4517211 and KB4520390. This resolves an issue where a black screen is encountered when connecting using Blast Extreme.

OpenGL and NVIDIA GPU-acceleration

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 7 requires a Microsoft Active Directory infrastructure for user authentication and management. Supported Active Directory Domain Services (AD DS) domain functional levels are:

  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows Server 2008

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 2019, 2016, or 2012 R2 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 7 documentation. Follow the relevant sections of the Horizon 7 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 Install the Product License Key.
  2. Configure event reporting – See Configuring Event Reporting.
  3. Assign administrators and roles – See Configuring Role-Based Delegated Administration.

When you first install a Connection Server, it uses self-signed 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 7 to use the signed certificate.

For the full process, see Configuring TLS Certificates for Horizon 7 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.

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 Configuring Unified Access Gateway Using TLS/SSL Certificates and Update SSL Server Signed 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 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 Install Horizon Agent on an Unmanaged Machine, which is part of the chapter Preparing Unmanaged Machines, in the Setting Up Virtual Desktops in Horizon 7 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, cs1.domain.com. 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-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, VMware Blast, PCoIP, Virtual video driver, Unity Touch, PSG), and optional features USB redirection, 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-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,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 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 VMware Global Support Services (GSS). 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.

Group Policy to Disable Direct RDP Connections

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

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

Prerequisites:

  1. Initialize the Cloud Pod Architecture feature. See Initialize the Cloud Pod Architecture Feature in Horizon Console.
  2. 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 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 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.

  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 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 from VMware, at https://www.vmware.com/go/viewclients. 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 7 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 Configure the VMware Horizon Web Portal Page for End Users.

Figure 18: Horizon 7 User Portal

If the physical machine being connected to is using Windows 10 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 5.3 Feature Matrix with Horizon 7 (76919) for details.

To access Windows 7 physical PCs using the RDP protocol, you must install the Horizon Client.

Changelog

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 have been changed to Horizon 7 version 7.12 and Unified Access Gateway version 3.9.

Author and Contributors

Author

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

Contributors

  • Chris Halstead is a Staff End-User-Computing Architect, End-User-Computing Technical Marketing, 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.

Reviewers

  • Josh Spencer is a Staff End-User-Computing Architect, End-User-Computing Technical Marketing, 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 euc_tech_content_feedback@vmware.com.

Filter Tags

  • Horizon
  • Overview
  • Deployment Considerations
  • Document
  • Horizon 7
  • Windows 10
  • Design
  • Deploy
  • Business Continuity
  • Secure Remote Access