Horizon Architecture

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions. This chapter provides information about architecting VMware Horizon for vSphere and applies to both Horizon 8 and 7.


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

This chapter of the reference architecture covers the architecture and design considerations for Horizon for vSphere and applies to both Horizon 8 and 7. Horizon can be deployed on-premises or on other supported cloud platforms. This chapter covers the foundational and common architectural information for deploying Horizon and is applicable across all supported platforms. Separate chapters will be added to give the specific design considerations for a given cloud platform, including VMware Cloud on AWS, Azure VMware Solution, and Google Cloud VMware Engine.

Although Horizon Cloud delivers the same resources as Horizon, it uses a different architecture than is being discussed in this chapter and runs natively on Azure. The architecture of Horizon Cloud on Microsoft Azure is covered separately in Horizon Cloud on Microsoft Azure Architecture.

Table 1: Horizon Environment Setup Strategy


A Horizon deployment was designed, deployed, and integrated with the VMware Workspace ONE® platform.

The environment was designed to be capable of scaling to 8,000 concurrent connections for users.


This strategy allowed the design, deployment, and integration to be validated and documented.


Architectural Overview

The core components of Horizon include a VMware Horizon® Client™ authenticating to a Connection Server, which brokers connections to virtual desktops and apps. The Horizon Client then forms a protocol session connection to a Horizon Agent running in a virtual desktop, RDSH server, or physical machine. The protocol session can also be configured to be tunneled via the Connection Server, although this is not generally recommended as it makes the ongoing session dependent on the Connection Server.

Figure 1: Horizon Core Components

External access includes the use of VMware Unified Access Gateway™ 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 a Horizon Agent running in a virtual desktop or RDSH server. This process is covered in more detail in External Access.

Figure 2: Horizon Core Components for External Access

For more detail on how a Horizon connection is formed between the components, see Understand and Troubleshoot Horizon Connections.


The following figure shows the high-level logical architecture of the Horizon components with other Horizon components shown for illustrative purposes.

Figure 3: Horizon Logical Components

The components and features of Horizon are described in the following table.

Table 2: Components of Horizon



Connection Server

The Horizon Connection Server securely brokers and connects users to the Horizon Agent that has been installed in the desktops and RDS Hosts.

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 VM or system. This agent allows the machine to be managed by Connection Servers and allows a Horizon Client to form a protocol session to the machine.

Machines can be virtual desktops, Remote Desktop Session Hosts (RDS Host), physical desktops PCs.

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.

When providing access to internal resources, Unified Access Gateway can be deployed within the corporate DMZ or internal network, and acts as a reverse 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.

(See Unified Access Gateway Architecture for design and implementation details.)

Horizon Console

A web application that is part of the Connection Server, allowing administrators to configure the server, deploy and manage desktops, control user authentication, initiate and examine system and user events, carry out end-user support, and perform analytical activities.

VMware Instant Clone Technology

VMware technology that provides single-image management with automation capabilities. You can rapidly create automated pools or farms of instant-clone desktops or RDSH servers from a golden image VM.

The technology reduces storage costs and streamlines desktop management by enabling easy updating and patching of hundreds or thousands of images from the golden image VM.

See the Instant Clone Smart Provisioning section for more information.

RDSH servers

Microsoft Windows Servers that provide published applications and session-based remote desktops to end users.

Enrollment Server

Server that delivers True SSO functionality by ensuring a user can single-sign-on to a Horizon resource when launched from Workspace ONE Access™, or through Unified Access Gateway, regardless of the authentication method.

See the True SSO section for more information.

Horizon Cloud Connector

The Horizon Cloud Connector is required to use with Horizon subscription licenses, services and management features hosted in the Horizon Cloud Service.

The Horizon Cloud Connector is a virtual appliance that connects a Connection Server in a pod with the Horizon Cloud Service.

You must have an active My VMware account to purchase a Horizon license from https://my.vmware.com.


The vSphere product family includes VMware ESXi™ and VMware vCenter Server®, and it is designed for building and managing virtual infrastructures. The vCenter Server system provides key administrative and operational functions, such as provisioning, cloning, and VM management features, which are essential for VDI.

From a data center perspective, several components and servers must be deployed to create a functioning Horizon environment to deliver the desired services.

Figure 4: Horizon Logical Architecture

In addition to the core components and features, other products can be used in a Horizon deployment to enhance and optimize the overall solution:

  • Workspace ONE Access – Provides enterprise single sign-on (SSO), securing and simplifying access to apps with the included identity provider or by integrating with existing identity providers. It provides application provisioning, a self-service catalog, conditional access controls, and SSO for SaaS, web, cloud, and native mobile applications. See Workspace ONE Access Architecture for design and implementation details.
  • App Volumes Manager – Orchestrates application delivery by managing assignments of application volumes (packages and writable volumes) to users, groups, and target computers. See App Volumes Architecture for design and implementation details.
  • Dynamic Environment Manager – Provides profile management by capturing user settings for the operating system and applications. See Dynamic Environment Manager Architecture for design and implementation details.
  • VMware vSAN storage – Delivers high-performance, flash-optimized, hyper-converged storage using server-attached flash devices or hard disks to provide a flash-optimized, highly resilient, shared datastore.
  • VMware NSX-T Data Center – Provides network-based services such as security, virtualized networking, routing, and switching in a single platform. With micro-segmentation, you can set application-level security policies based on groupings of individual workloads, and you can isolate each virtual desktop from all other desktops as well as protecting the Horizon management servers.
  • Microsoft SQL Servers – Microsoft SQL database servers are used to host event databases used by the Connection Servers.

Note: VMware NSX-T Data Center is licensed separately from Horizon.

Pod and Block

One key concept in a Horizon environment design is the use of pods and blocks, which gives us a repeatable and scalable approach.

The numbers, limits, and recommendations given in this section were correct at time of writing. For the most current numbers for Horizon 8, see the Horizon 8 2006 Configuration Limits. For Horizon 7, see the VMware Knowledge Base article VMware Horizon 7 Sizing Limits and Recommendations (2150348).

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.
  • Multiple pods can be interconnected by either using the Universal Broker or by using Cloud Pod Architecture (CPA).
  • A single Cloud Pod Architecture can scale to a maximum of 250,000 sessions. For numbers above that, separate CPAs can be deployed.

A pod is divided into multiple blocks to provide scalability. Each block is made up of one or more resource vSphere clusters, and each block has its own vCenter Server. The number of virtual machines (VMs) a block can typically host depends on the type of Horizon VMs used. See vCenter Server for details.

Figure 5: Horizon Pod and Block Design

To add more resource capacity, we simply add more resource blocks. We also add additional Connection Servers to add the capability for more session connections within the pod.

Depending on the types of VMs (instant clones, full clones, and if using App Volumes), a resource block could host a different number of VMs (see Scalability and Availability). Typically, we have multiple resource blocks and up to seven Connection Servers in a pod capable of hosting 12,000 sessions. For numbers above that, we deploy additional pods.

As you can see, this approach allows us to design a single block capable of thousands of sessions that can then be repeated to create a pod capable of handling 12,000 sessions. Multiple pods grouped using either the Universal Broker or Cloud Pod Architecture can then be used to scale the environment as large as needed.

Important: A single pod and the Connection Servers in it must be located within a single data center and cannot span locations.

Options regarding the location of management components, such as Connection Servers, include:

  • Co-located on the same vSphere hosts as the desktops and RDSH servers that will serve end-users
  • On a separate vSphere cluster
  • On separate cloud compute resources, in line with the recommendations of the given cloud platform.

In large environments, for scalability and operational efficiency, it is normally best practice to have a separate vSphere cluster to host the management components. This keeps the VMs that run services such as Connection Server, Unified Access Gateway, vCenter Server, and databases separate from the desktop and RDSH server VMs.

Management components can be co-hosted on the same vSphere cluster as the end-user resources, if desired. This architecture is more typical in smaller environments or where the use of converged hardware is used and the cost of providing dedicated hosts for management is too high. If you place everything on the same vSphere cluster, you must configure the setup to ensure resource prioritization for the management components. Sizing of resources (for example, virtual desktops) must also take into account the overhead of the management servers. See vSphere Resource Management for more information.

Table 3: Pod and Block Design for This Reference Architecture


A pod was formed in each site.

Each pod contained one or more resource blocks.


This allowed the design, deployment of the block and pod architecture to be validated and documented.

Cloud Pod Architecture

Cloud Pod Architecture (CPA) introduces the concept of a global entitlement (GE) through joining multiple Horizon pods together into a federation. Pods can be located in the same physical site or location or in different sites and locations.

This feature allows you to provide users and groups with a global entitlement that can contain desktop pools or RDSH-published applications from multiple different pods that are members of this federation construct.

The following figure shows a logical overview of a basic two-site CPA implementation.

Cloud Pod Architecture

Figure 6: Cloud Pod Architecture

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

Important: This type of deployment is not a stretched deployment. Each pod is distinct, and all Connection Servers belong to a specific pod and are required to reside in a single location and run on the same broadcast domain from a network perspective.

As well as being able to have desktop pool members or published applications from different pods in a global entitlement, this architecture allows for a property called scope. Scope allows us to define where new sessions should or could be placed and also allows users to connect to existing sessions (that are in a disconnected state) when connecting to any of the pod members in the federation.

CPA can also be used within a site:

  • To use global entitlements that span multiple resource blocks and pools
  • To federate multiple pods on the same site, when scaling above the capabilities of a single pod

Table 4: Implementation Strategy for Using Cloud Pod Architecture


Separate pods were deployed in separate sites.

Cloud Pod Architecture was used to federate the pods.


This provides site redundancy and allows an equivalent service to delivered to the user from an alternate location.


Scalability and Availability

One key design principle is to remove single points of failure in the deployment. The numbers, limits and recommendations given in this section were correct at time of writing. For the most current numbers for Horizon 8, see the Horizon 8 2006 Configuration Limits. For Horizon 7, 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. Up to seven Connection Servers are supported per pod with a recommendation of 12,000 active sessions in total per pod.

To satisfy the requirements that the proposed solution be robust and able to handle failure, deploy one more server than is required for the number of connections (n+1).

Table 5: Strategy for Deploying Connection Servers


Five Horizon Connection Servers were deployed.

These ran on dedicated Windows 2019 VMs located in the internal network.


One Connection Server is recommended per 2,000 concurrent connections.

Four Connection Servers are required to handle the load of the target 8,000 users.

A fifth server provides redundancy and availability (n+1).

For more information, see Horizon Configuration.

vCenter Server

vCenter Server is the delimiter of a resource block.

The recommended number of VMs that a vCenter Server can typically host depends on the type of Horizon VMs used. The following limits have been tested.

  • 12,000 instant-clone VMs
  • 4,000 full-clone VMs

Just because VMware publishes these configuration maximums does not mean you should necessarily design to them. Using a single vCenter Server does introduce a single point of failure that could affect too large a percentage of the VMs in your environment. Therefore, carefully consider the size of the failure domain and the impact should a vCenter Server become unavailable.

A single vCenter Server might be capable of supporting your whole environment, but to reduce risk and minimize the impact of an outage, you will probably want to include more than one vCenter Server in your design. You can increase the availability of vCenter Server by using VMware vSphere® High Availability (HA), which restarts the vCenter Server VM in the case of a vSphere host outage. vCenter High Availability can also be used to provide an active-passive deployment of vCenter Server appliances, although caution should be used to weigh the benefits against the added complexity of management.

Sizing can also have performance implications because a single vCenter Server could become a bottleneck if too many provisioning tasks run at the same time. Do not just size for normal operations but also understand the impact of provisioning tasks and their frequency.

For example, consider a user case with non-persistent, parent-based, instant-clone desktops, which are deleted after a user logs off and are provisioned when replacements are required. Although a non-persistent, floating desktop pool can be pre-populated with spare desktops, it is important to understand how often replacement VMs would need to be generated and when that happens. Are user logoff and the demand for new desktops spread throughout the day? Or are desktop deletion and replacement operations clustered at certain times of day? If these events are clustered, can the number of spare desktops satisfy the demand, or do replacements need to be provisioned? How long does provisioning desktops take, and is there a potential delay for users?

Understanding provisioning tasks, like this, helps understand the demand placed on the vCenter Server and whether it is better to scale out rather than scale up.

Table 6: Implementation Strategy for vCenter Server


Two resource blocks were deployed per site, each with their own vCenter Server virtual appliance, located in the internal network.


A single resource block and a single vCenter Server are supported for the intended target of 8,000 instant-clone VMs; however, having a single vCenter Server for the entire user environment presents too large a failure domain.

Splitting the environment across two resource blocks, and therefore over two vCenter Servers reduces the impact of any potential outage.

This approach also allows each resource block to scale to a higher number of VMs and allow for growth, up to the pod recommendation, without requiring us to rearchitect the resource blocks.

Horizon Cloud Connector

The Horizon Cloud Connector is deployed as a virtual appliance from VMware vSphere® Web Client and paired to one of the Connection Servers in the pod. As part of the pairing process, the Horizon Cloud Connector virtual appliance connects the Connection Server to the Horizon Cloud Service to manage the subscription license. With a subscription license for Horizon, you do not need to retrieve or manually enter a license key for Horizon product activation. However, license keys are still required for supporting the components, which include vSphere, vSAN, and vCenter Server. These keys are emailed to the https://my.vmware.com contact.

You must have an active My VMware® account to purchase a Horizon license from https://my.vmware.com. You then receive a subscription email with the link to download the Horizon Cloud Connector as an OVA (Open Virtual Appliance) file.

A single Cloud Connector VM is supported per pod. High availability is provided by vSphere HA, which restarts the Cloud Connector VM in the case of a vSphere host outage.

Table 7: Implementation Strategy for the Horizon Cloud Connector


One Cloud Connector per pod was deployed in the internal network.


The environment uses subscription licensing.

Load Balancing Connection Servers

For high availability and scalability, VMware recommends that multiple Connection Servers be deployed in a load-balanced replication cluster. This ensures that user load is evenly distributed across all available servers and a single namespace can be used by end users. Using a load balancer also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and configuration changes while minimizing impact to users.

Connection Servers broker client connections, authenticate users, and direct incoming requests to the correct agent resource. Although the Connection Server helps form the connection for authentication, it typically does not act as part of the data path after a protocol session has been established.

The load balancer serves as a central aggregation point for traffic flow between clients and Connection Servers, sending clients to the best-performing and most available Connection Server instance. Using a load balancer with multiple Connection Servers also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and changes in the configuration without impacting users. To ensure that the load balancer itself does not become a point of failure, most load balancers allow for setup of multiple nodes in an HA or active/passive configuration.

Figure 7: Connection Server Load Balancing

Connection Servers require the load balancer to have a session persistence setting. This is sometimes referred to as persistent connections or sticky connections, and ensures data stays directed to the relevant Connection Server. For more information, see the VMware Knowledge Base article Load Balancing for VMware Horizon View (2146312).

An existing load balancer can be used, or a new one such as the VMware NSX Advanced Load Balancer (formerly Avi Vantage) can be deployed. See Configure Avi Vantage for VMware Horizon for more details.

Table 8: Strategy for Using Load Balancers with Connection Servers


An NSX Advanced load balancer was used in front of the Connection Servers.

Source IP was configured for the persistence or affinity type.


This provides a common namespace for the Connection Servers, which allows for ease of scale and redundancy.


External Access

Secure, external access for users accessing resources is provided through the integration of Unified Access Gateway (UAG) appliances. We also use load balancers to provide scalability and allow for redundancy. A Unified Access Gateway appliance can be used in front of Connection Servers to provide access to on-premises Horizon desktops and published applications.

External Access Architecture

When using Unified Access Gateway to provide external access to Horizon, the same Connection Servers can be used for both external and internal connections.

Figure 8: Unified Access Gateway and Connection Server Architecture

Although the previous diagram shows a load balancer between the Unified Access Gateway appliances and Connection Servers, it is also supported to have these as 1:1 connection with no load balancer. High availability is still maintained as the Internet-facing load balancer will still detect failure in any component.

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 9: Single DMZ Deployment showing Blast Extreme ports

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 10: Double DMZ Deployment showing Blast Extreme ports

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

Unified Access Gateway Scaling

For information on scaling and the design of Unified Access Gateway, see Unified Access Gateway Architecture.

Figure 11: External Access Through Unified Access Gateway

Table 9: Implementation Strategy for External Access


Five standard-size Unified Access Gateway appliances were deployed as part of the Horizon solution.

These were located in the DMZ network.


UAG provides secure external access to internally hosted Horizon desktops and applications.

One standard UAG appliance is recommended for up to 2,000 concurrent Horizon connections.

Four UAG appliances are required to handle the load of the target 8,000 users.

A fifth UAG provides redundancy and availability (n+1).

Load Balancing Unified Access Gateway

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

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

Display Protocol

Horizon is a multi-protocol solution. Three remoting protocols are available when creating desktop pools or RDSH-published applications: Blast Extreme, PCoIP, and RDP.

Table 10: Display Protocol for Virtual Desktops and RDSH-Published Apps


For this design, we leveraged Blast Extreme.


This display protocol supports multiple codecs, both TCP and UDP from a transport protocol perspective, and the ability to do hardware encoding with NVIDIA GRID vGPU.

Blast Extreme is configured through Horizon when creating a pool. The display protocol can also be selected directly on the Horizon Client side when a user selects a desktop pool.

See the following guides for more information, including optimization tips:

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 Network Ports in VMware Horizon guide has more detail, and includes diagrams illustrating the traffic. It has specific sections and diagrams on internal, external, and tunneled connections.


  • The network ports shown are destination ports.
  • The arrows indicate the direction of traffic initiation (source to destination).
  • Horizon UDP protocols are bidirectional, so stateful firewalls should be configured to accept UDP reply datagrams.

Internal Connections

The following diagram shows the ports required to allow an internal Blast Extreme connection.

Figure 12: Internal Connection with Blast Extreme Network Ports

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

Figure 13: Internal Connection with PCoIP Network Ports

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

Figure 14: Internal Connection with RDP Network Ports

External Connections

The following diagram shows the ports required to allow an external Blast Extreme connection.

Figure 15: External Connection with Blast Extreme Network Ports

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

Figure 16: External Connection with PCoIP Network Ports

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

Figure 17: External Connection with RDP Network Ports

Instant Clone Smart Provisioning

An automated instant clone pool or farm is created from a golden image VM using the vSphere instant clone API. Instant clone technology replaces View Composer linked clone as the process for creating automated farms in Horizon.

Horizon creates several types of internal VMs (Internal Template, Replica VM, and Parent VM) to manage these clones in a more scalable way. Instant clones share the virtual disk of the replica VM and therefore consume less storage than full VMs. In addition, instant clones share the memory of the parent VM when they are first created, which contributes to fast provisioning. After the instant clone VM is provisioned and the machine starts to be used, additional memory is utilized. After it is provisioned, the clone is no longer linked to the parent VM.

Figure 18: Instant Clones with Parent VMs

Although helpful in speeding up the provisioning speed, the use of parent VM does increase the memory requirement across the cluster. When there is a low density of VM clones per host, either with small desktop pools or with RDS Host farms, the benefit of having more memory outweighs the increase in provisioning speed. In this case, Horizon can automatically choose to provision instant clones directly from replica VM, without creating any parent VM.

This feature is called Smart Provisioning and an overview is given in Instant Clone Smart Provisioning. The key differences include:

  • No running parent VMs are created on the vSphere hosts.
  • Each clone has a vSphere snapshot taken, after cloning from the replica, which it is reverted to at logoff.

Figure 19: Instant Clones without Parent VMs

A single instant clone pool or farm can have both instant clones that are created with parent VMs or without parent VMs. The default behavior is listed as follows but can be overridden at a pool or farm level.

Instant clone pools and farms are created with Parent VMs, when:

Instant clone pools and farms are created without Parent VMs, when:

  • The density is less than or equal to 12 VMs per host on the selected cluster
  • Horizon is deployed on Azure VMware Solution.
  • vCenter permission.
  • vCenter and vSphere are using mixed versions.

See the Horizon documentation Instant-Clone Desktop Pools and Creating an Automated Instant-Clone Farm.


There are a variety of methods for authenticating users in Horizon to control access to desktops and published applications.

Workspace ONE Access Authentication

One of the methods of accessing Horizon desktops and applications is through Workspace ONE Access. This requires integration between Connection Servers and Workspace ONE Access using the SAML 2.0 standard to establish mutual trust, which is essential for single sign-on (SSO) functionality.

When SSO is enabled, users who log in to Workspace ONE Access with Active Directory credentials can launch remote desktops and applications without having to go through a second login procedure. If you set up the True SSO feature, users can log in using authentication mechanisms other than AD credentials. See Using SAML Authentication and see Setting Up True SSO.

When defining the SAML authenticator on the Connection Servers, you can choose to set the delegation of authentication to allowed or required. Allowed makes this optional, whereas required enforces the use of the SAML authentication source. When configure as required you can also enable Workspace ONE which redirects any direct authentication attempts into Workspace ONE Access. See Configure Workspace ONE Access Policies in Horizon Console.

For details on Horizon and Workspace ONE Access Integration see the Platform Integration chapter.

Table 11: Strategy for Authenticating Users Through Workspace ONE Access


A SAML authenticator for Workspace ONE was configured to be required on the Connection Servers.

Workspace ONE mode was enabled on the Connection Servers.


With this configuration, Connection Servers allow Workspace ONE Access to be a dynamic SAML authenticator. This strategy facilitates the launch of Horizon resources only from Workspace ONE Access and to redirect any attempts to authenticate directly to Horizon back to Workspace ONE Access.

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

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 requires Horizon Connection Server 7.11 or later, and user authentication must go through Unified Access Gateway.

See Authentication options in Unified Access Gateway Architecture.

Table 12: Strategy for Authenticating Users Through Unified Access Gateway


Unified Access Gateway was left with the default pass-through authentication and no additional authentication methods were implemented on Unified Access Gateway.


With this configuration facilitates the launch of Horizon resources from Workspace ONE Access and will use that as the user authentication point.

To implement further authentication on the Unified Access Gateway would force users to have to authenticate twice.


True SSO

Many user authentication options are available for user logging into Horizon including using Workspace ONE Access or Unified Access Gateway. Active Directory credentials are only one of these many authentication options. Ordinarily, using anything other than AD credentials would prevent a user from being able to single-sign-on to a Horizon virtual desktop or published application. After selecting the desktop or published application from the catalog, the user would be prompted to authenticate again, this time with AD credentials.

True SSO provides users with SSO to Horizon desktops and applications regardless of the authentication mechanism used. True SSO uses SAML, where Workspace ONE is the Identity Provider (IdP) and the Horizon Connection Server is the Service Provider (SP). True SSO generates unique, short-lived certificates to manage the login process.

Figure 20: True SSO Logical Architecture

Table 13: Implementation Strategy for SSO


True SSO was configured and enabled.


This feature allows SSO to Horizon resources when launched from Workspace ONE Access, even when the user does not authenticate with Active Directory credentials.

True SSO requires the Enrollment Server service to be installed using the Horizon installation media.

True SSO Components

For True SSO to function, several components must be installed and configured within the environment. This section discusses the design options and details the design decisions that satisfy the requirements.

Note: For more information on how to install and configure True SSO, see Setting Up True SSO in the Horizon Administration documentation and the Setting Up True SSO section in Horizon Configuration.

The Enrollment Server is responsible for receiving certificate signing requests (CSRs) from the Connection Server. The enrolment server then passes the CSRs to the Microsoft Certificate Authority to sign using the relevant certificate template. The Enrollment Server is a lightweight service that can be installed on a dedicated Windows Server 2019 instance, or it can co-exist with the MS Certificate Authority service. It cannot be co-located on a Connection Server.

The components of Horizon True SSO are described in the following table.

Table 14: Components of Horizon True SSO



Enrollment Server

Server that delivers True SSO functionality by ensuring a user can single-sign-on to a Horizon resource when launched from Workspace ONE Access, regardless of the authentication method.

The Enrollment Server is responsible for receiving certificate signing requests from the Connection Server and then passing them to the Certificate Authority to sign.

True SSO requires Microsoft Certificate Authority services, which it uses to generate unique, short-lived certificates to manage the login process.

Certificate Authority

Active Directory Certificate Services (AD CS) role running on a Windows server.

Certificate Template

Used for issuing short-lived certificates that are used as part of the SSO process.

True SSO Scalability

A single Enrollment Server can handle all the requests from a single Horizon pod. The constraining factor is usually the Certificate Authority (CA). A single CA can generate approximately 70 certificates per second (based on a single vCPU). This usually increases to over 100 when multiple vCPUs are assigned to the CA VM.

To ensure availability, a second Enrollment Server should be deployed per pod (n+1). Additionally, ensure that the certificate authority service is deployed in a highly available manner, to ensure complete solution redundancy.

Figure 21: True SSO High Availability

With two Enrollment Servers, and to achieve high availability, it is recommended to:

  • Co-host the Enrollment Server service with a Certificate Authority service on the same machine.
  • Configure the Enrollment Server to prefer to use the local Certificate Authority service.
  • Configure the Connection Servers to load-balance requests between the two Enrollment Servers.

Table 15: Implementation Strategy for Enrollment Servers


Two Enrollment Servers were deployed per Pod.

These ran on dedicated Windows Server 2019 VMs located in the internal network.

These servers also had the Microsoft Certificate Authority service installed.


One Enrollment Server is capable of supporting a pod of 12,000 sessions.

A second server provides availability (n+1).

Figure 22: True SSO High Availability Co-located

Load Balancing of Enrollment Servers

Two Enrollment Servers were deployed in the environment, and the Connection Servers were configured to communicate with both deployed Enrollment Servers. The Enrollment Servers can be configured to communicate with two Certificate Authorities.

By default, the Enrollment Servers use an Active/Failover method of load balancing. It is recommended to change this to round robin when configuring two Enrollment Servers per pod to achieve high availability.

Table 16: Strategy for Load Balancing Between the Enrollment Servers


The Connection Server were configured to load balance requests using round robin between the two Enrollment Servers.


With two Enrollment Servers per pod, this is the recommendation when designing for availability.

vSphere HA and VMware vSphere® Storage DRS™ can be used to ensure the maximum availability of the Enrollment Servers. DRS rules are configured to ensure that the devices do not reside on the same vSphere host.

Scaled Single-Site Architecture

The following diagram shows the server components and the logical architecture for a single-site deployment of Horizon. For clarity, the focus in this diagram is to illustrate the core Horizon server components, so it does not include additional and optional components such as App Volumes, Dynamic Environment Manager, and Workspace ONE Access.

Note: In addition to Horizon server components, the following diagram shows database components, including Microsoft availability group (AG) listeners.

Figure 23: Single-Site Scaled Horizon Pod

Multi-site Architecture

This reference architecture documents and validates the deployment of all features of Horizon across two data centers.

The architecture has the following primary tenets:

  • Site redundancy – Eliminate any single point of failure that can cause an outage in the service.
  • Data replication – Ensure that every layer of the stack is configured with built-in redundancy or high availability so that the failure of one component does not affect the overall availability of the desktop service.

To achieve site redundancy, 

  • Services built using Horizon are available in two data centers that are capable of operating independently.
  • Users are entitled to equivalent resources from both the primary and the secondary data centers.
  • Some services are available from both data centers (active/active).
  • Some services require failover steps to make the secondary data center the live service (active/passive).

To achieve data replication, 

  • Any component, application, or data required to deliver the service in the second data center is replicated to a secondary site.
  • The service can be reconstructed using the replicated components.
  • The type of replication depends on the type of components and data, and the service being delivered.
  • The mode of the secondary copy (active or passive) depends on the data replication and service type.


Active-passive architecture uses two or more pods of Connection Servers, with at least one pod located in each data center. Pods are joined together using Cloud Pod Architecture configured with global entitlements.

Active-passive service consumption should be viewed from the perspective of the user. A user is assigned to a given data center with global entitlements, and user home sites are configured. The user actively consumes Horizon resources from that pod and site and will only consume from the other site in the event that their primary site becomes unavailable.

Figure 24: Active-Passive Architecture


Active-active architecture also uses two or more pods of Connection Servers, with at least one pod located in each data center. The pods are joined using Cloud Pod Architecture, which is configured with global entitlements.

As with an active-passive architecture, active-active service consumption should also be viewed from the perspective of the user. A user is assigned global entitlements that allow the user to consume Horizon resources from either pod and site. No preference is given to which pod or site they consume from. The challenges with this approach are usually related to replication of user data between sites.

Figure 25: Active-Active Architecture

Stretched Active-Active - Unsupported

This architecture is unsupported and is only shown here to stress why it is not supported. Connection Servers within a given site must always run on a well-connected LAN segment and therefore cannot be running actively in multiple geographical locations at the same time.

Figure 26: Unsupported Stretched Pod Architecture

Multi-site Global Server Load Balancing

A common approach is to provide a single namespace for users to access Horizon pods deployed in separate locations. A Global Server Load Balancer (GSLB) or DNS load balancer solution can provide this functionality and can use placement logic to direct traffic to the local load balancer in an individual site. Some GSLBs can use information such as the user’s location to determine connection placement.

The use of a single namespace makes access simpler for users and allows for administrative changes or implementation of disaster recovery and failover without requiring users to change the way they access the environment.

Note the following features of a GSLB:

  • GSLB is similar to a Domain Name System (DNS) service in that it resolves a name to an IP address and directs traffic.
  • Compared to a DNS service, GSLB can usually apply additional criteria when resolving a name query.
  • Traffic does not actually flow through the GSLB to the end server.
  • Similar to a DNS server, the GLSB does not provide any port information in its resolution.
  • GSLB should be deployed in multiple nodes in an HA or active/passive configuration to ensure that the GSLB itself does not become a point of failure.

Table 17: Strategy for Global Load Balancing


A global server load balancer was deployed.


This provides a common namespace so that users can access both sites.

Multi-site Architecture Diagram

The following diagram shows the server components and the logical architecture for a multi-site deployment of Horizon. For clarity, the focus in this diagram is to illustrate the core Horizon server components, so it does not include additional and optional components such as App Volumes, Dynamic Environment Manager, and Workspace ONE Access.

Figure 27: Multi-site Horizon Architecture

Composer Server

The Composer server is only required when using linked clones and is considered the legacy method for creating clones, is deprecated in Horizon 8 2006, and will be removed in the future. Instant clones do not require a Composer server. The recommendation is to use instant clones in preference to linked clones.

See the Modernizing VDI for a New Horizon guide for options and guidance for migrating from legacy components such as View Composer, persistent disks, and Persona Management to modern alternatives.

The Composer service works with the Connection Servers and a vCenter Server. Each Composer server is paired with a vCenter Server in a one-to-one relationship. For example, in a block architecture where we have one vCenter Server per 4,000 linked-clone VMs, we would also have one Composer server.

High availability is provided by vSphere HA, which restarts the Composer VM in the case of a vSphere host outage. VM monitoring with vSphere HA can also attempt to restart the VM in the case of an operating system crash.

If the VMware View Composer service becomes unavailable, all existing desktops can continue to work just fine. While vSphere HA is restarting the Composer VM, the only impact is on any provisioning tasks within that block, such as image refreshes or recomposes, or creating new linked-clone pools.

What's Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more. 

Filter Tags

Horizon Horizon Document Reference Architecture Advanced Design Windows Delivery