Horizon on Azure VMware Solution Configuration
By: Date: 09/09/2022 Categories: VMware Tags:

Deploying Horizon with Azure VMware Solution

This section covers specific information for deploying Horizon on Azure VMware Solution.

Configuring Azure VMware Solution for Horizon Deployment

At a high-level, the following steps are required to deploy Horizon with Azure VMware Solution:

  1. Create a Private Cloud. See the Azure VMware Solution documentation. The recommendation for a production environment is to use a minimum of three hosts in a cluster.
  2. Deploy Horizon 8 on the Azure VMware Solution, following the architecture described in Scaling Deployments.
  3. Set up the Horizon environment on Azure VMware Solution.

Horizon Installation on Azure VMware Solution

When you set up the Horizon environment on Azure VMware Solution, you must install and configure the following components:

  1. Install Active Directory, DNS, DHCP, and KMS servers.
  2. Optionally, install RDS license servers.
  3. Install one or more Horizon Connector Servers. See Connection Server Deployment.
  4. Install a Horizon Cloud Connector. See Horizon Cloud Connector Deployment.
  5. Install one or more Unified Access Gateways. See Unified Access Gateway Deployment.


First gather the VMware vCenter® and VMware NSX® URLs and credentials.

  • In the Azure Portal, go to Azure VMware Solution.
  • Go to your AVS Private cloud, then select Identity under the Manage section of the middle menu.
  • Copy the vCenter Web Client URL, vCenter admin user, vCenter admin password, VMware NSX-T™ Data Center Manager URL, NSX-T Manager admin user, NSX-T Manager admin password.

Instance Types

The following table lists the Azure instances used based on a 2,000-desktop deployment example. Different Azure instance sizes can be used, although consideration should be given to the vCPU, memory and expected network bandwidth available on the different instance sizes. This can have an impact on the number of sessions a management component can support. See https://docs.microsoft.com/en-us/azure/virtual-machines/dv4-dsv4-series#dsv4-series for details on other Azure instance sizes.

For table below gives example sizing for the server components that were used at time of writing. For the latest guidance on sizing the Horizon Cloud Connector when deploying on AVS, see VMware Horizon Pods with Horizon Cloud Control Plane – Requirements Checklist.

Table 1: Horizon Component Instance Types on Azure (Example)

Horizon InfrastructureInstancevCPUMemoryAmount
Connection ServerD4s_v44161 per 2,000 sessions, +1
Unified Access GatewayD4s_v44161 per 2,000* sessions, +1
App Volumes ManagerD4s_v44161 per 2,000 sessions, +1
Horizon Cloud ConnectorD8_v38321
Domain Controller*D4s_v4416Minimum 2
MS-SQL Database*D4s_v4416Minimum 2
Windows file share*D4s_v4416Minimum 2

*Size according to your environment

Connection Server Deployment

Deploy a Horizon Connection Server and select Azure VMware Solution to indicate that the platform that this Horizon Pod is being deployed on. This choice is only made on the first Connection Server in a pod.

Figure 1: Horizon Connection Server Installation Platform Choice

  • Version 8 2006 or later should be used.
  • Deploy a load balancer if you are using two or more Connection Servers.
  • Optionally, install a Horizon event database on a Microsoft SQL Server.

Horizon Cloud Connector Deployment

One Horizon Cloud Connector is deployed per Horizon Pod. For more information, see Onboarding a Horizon Pod to Horizon Cloud Control Plane.

Unified Access Gateway Deployment

Deploy a Unified Access Gateway appliance and connect it to the Connection Server if your deployment supports remote users.

  • Use Unified Access Gateway version 20.06 or later.
  • Use the PowerShell script to include the password and encode special characters in the .INI configuration file. For more information, see the Unified Access Gateway documentation.
  • Specify static routes for the NIC connected to the Internal DMZ and specify all RFC1918 networks with the Internal DMZ gateway.
    • For example: routes1=,,
    • Where: is the Internal DMZ gateway.

Deploying Horizon over Hybrid Cloud

You might already have Horizon environments on-premises or on another cloud platform. The Horizon pod on-premises and your Horizon pod with Azure VMware Solution can be managed separately. Alternatively, you can extend your other Horizon environments by linking them with your Horizon with Azure VMware Solution environment using Cloud Pod Architecture (CPA). Deploying your Horizon over hybrid cloud enables you to manage your on-premises deployment and your cloud deployment in a single federated space.  

For hybrid cloud deployment, follow these steps.

  1. Configure ExpressRoute and firewall rules to enable the Connection Server instance with Azure VMware Solution to communicate with the Connection Server instance on-premises.
  2. Prepare Microsoft Active Directory (AD) and choose to set up a one-way trust or a two-way trust.
  3. Ensure that your on-premises Horizon version is 7.5 or later.  
    Note: The Horizon version deployed on-premises does not have to match the Horizon version deployed on Azure VMware Solution. However, you cannot mix a Horizon 7.4 pod (or lower) with a Horizon 8 or 7 pod within the same CPA.
  4. Use Cloud Pod Architecture to connect the other Horizon pods against the Horizon pod with Azure VMware Solution.
  5. For easy sharing of VM images and ISO images, you can use the vCenter Content Library on each vCenter Server.
  6. For outbound Internet access on the AVS Private Cloud (SDDC), go to AVS SDDC from Azure Portal > Connectivity > Settings > Internet Enabled and set this to Enabled:
Afbeelding met tekst

Automatisch gegenereerde beschrijving

Figure 2: Enable Internet Access for the SDDC

Connection, Firewall and Load Balancer Configuration

To set up a successful hybrid cloud deployment, you must follow these connection and firewall rules.

Connection Rules

Use the Azure portal to create an ExpressRoute in the vNet to connect to your on-premises management network. Finally, specify DNS server addresses for the management network.

Firewall Rules

The following table describes firewall rules for the Azure vNet.

Table 2: Management Inbound Security Rules

Rule NamePortProtocolSourceDestinationAction
Allow-UAG-CS-XML_API443TCPUnified Access Gateway Internal – Application Security GroupConnection Servers – Application Security GroupAllow
Allow_443-CS443,8443AnyAnyConnection Servers – Application Security GroupAllow
Allow_AVSDesktop-AVM443TCPVDI SubnetAppVolumes Managers – Application Security GroupAllow
Allow_DomainControllerInboundAnyAnyHorizon Management Subnet,VDI Subnet,On-premises Management SubnetDomain Controllers – Application Security GroupAllow
Allow_AVM-MGMT-DC443TCPHorizon Management SubnetAppVolumes Managers – Application Security GroupAllow
Allow_LDAP_Replication-CS-CS22389,22636,49152-65535,389,135,32111,4100,4101TCPConnection Servers – Application Security GroupConnection Servers – Application Security GroupAllow
Allow_InterPODCommunication8472,22389,22636,49152-65535,135TCPOn-premises Management SubnetConnection Servers – Application Security GroupAllow
Allow_CloudConnector-CS443,4002TCPCloud Connector – Application Security GroupConnection Servers – Application Security GroupAllow
Allow_WorkspaceONEConnector-CS443,389TCPWS ONE Access Connector – Application Security GroupConnection Servers – Application Security GroupAllow
Allow_AVM-DB1433TCPAppVolumes Managers – Application Security GroupSQL Database – Application Security GroupAllow
Allow_AVSDesktop-CS4001,4002,389TCPVDI SubnetConnection Servers – Application Security GroupAllow
Allow_DFS_FileServerAccess135,137,138,139,445,5445,5722AnyHorizon Management Subnet,VDI Subnet,On-premises Management SubnetFile Server – Application Security GroupAllow
Allow_UAG-DNSonDC53AnyUnified Access Gateway Internal – Application Security GroupDomain Controllers – Application Security GroupAllow
Allow_CloudConnectorMgmt443TCPHorizon Management SubnetCloud Connector – Application Security GroupAllow
Allow_ALB-AVM443TCPAzureLoadBalancerAppVolumes Managers – Application Security GroupAllow
Allow_ALB-CS443,8443TCPAzureLoadBalancerConnection Servers – Application Security GroupAllow

Table 3: Management and Internal DMZ Outbound Security Rules

Rule NamePortProtocolSourceDestinationAction

Table 4: Internal DMZ Inbound Security Rules

Rule NamePortProtocolSourceDestinationAction
Allow_UAG-Management9443TCPHorizon Management SubnetUnified Access Gateway Internal – Application Security GroupAllow

Table 5: External Inbound Security Rules

Rule NamePortProtocolSourceDestinationAction
Port_443443TCPAnyUnified Access Gateway External – Application Security GroupAllow
BLAST_TCP8443TCPAnyUnified Access Gateway External – Application Security GroupAllow
BLAST_UDP8443UDPAnyUnified Access Gateway External – Application Security GroupAllow
UDP_Tunnel443UDPAnyUnified Access Gateway External – Application Security GroupAllow
PCoIP_TCP4172TCPAnyUnified Access Gateway External – Application Security GroupAllow
PCoIP_UDP4172UDPAnyUnified Access Gateway External – Application Security GroupAllow
Allow_ALB-UAG-EXT443TCPAzureLoadBalancerUnified Access Gateway External – Application Security GroupAllow

Table 6: External DMZ Outbound Security Rules

Rule NamePortProtocolSourceDestinationAction

Load Balancers

For redundancy, load balancers are used for Unified Access Gateways, Connection Servers, and App Volumes Managers. In Azure, when adding a load balancer outbound NAT is no longer working for internal load balancers, as such every component behind a load balancer also gets connected to an outbound only load balancer for Internet access. Internet access is useful for certificate revocation list checking and updates.

Table 7: Load Balancers

NameUAGCSAVMOutbound Internet
SKUPublic StandardInternal StandardInternal StandardPublic Standard
Backend port443443443na
Backend PoolUnified Access GatewaysConnection ServersApp Volumes Managers Connection Servers, App Volumes Managers
Health ProbeHTTPS:443/favicon.icoHTTPS:443/favicon.icoHTTPS:443/health_checkna
Session PersistenceClient IPClient IPClient IPna
Floating IPDisabledDisabledDisabledna
TCP resetDisabledDisabledDisabledna
SNATUse outbound rulesUse outbound rulesUse outbound rulesna

Azure Components

  • vNet and subnets for Management and DMZ networks. See Network Configuration.
  • Express Route Gateway for Connecting AVS SDDC to VNET
  • Azure Load Balancer (ALB) for External /internal Load Balancing
  • Azure Traffic Manager (ATM) for Global Load Balancing

Horizon Management Components

To allow scaling beyond a single SDDC, the recommended deployment of Horizon in Azure VMware Solution locates the management components in Azure and not within the SDDCs. By locating the management components, such as the Unified Access Gateways, outside of the SDDC, only network traffic intended for a particular SDDC is routed towards that SDDC.

This includes the following management components:

  • Horizon Connection Servers
  • Unified Access Gateway appliances
  • VMware App Volumes™ Managers
  • Load balancer
  • Horizon Cloud Connector
  • File shares for user data and VMware Dynamic Environment Manager™ configuration data
  • Database Server for App Volumes and Horizon events
Horizon Components and Logical Architecture

NSX-T Components

VMware NSX-T™ Data Center is the network virtualization platform for the Software-Defined Data Center (SDDC), delivering networking and security entirely in software, abstracted from the underlying physical infrastructure. See the Understand NSX-T activity path for more information.

The maximum number of ports per logical network is 1000, you can also use multiple logical networks per pool with Horizon by leveraging the Multi VLAN functionality.

  • Tier-0 router – Handles Internet, route or policy based IPSEC VPN, and serves as an edge firewall for the Tier-1 Compute Gateway (CGW).
  • Tier-1 Compute Gateway (CGW) – Serves as a distributed firewall for all customer internal networks.
  • The Tier-1 Management Gateway (MGW) – Serves as a firewall for the Microsoft maintained components like vCenter and NSX.

NSX Edge virtual appliances are automatically deployed to run the Tier-0 and Tier-1 gateways when the SDDC is created.

Cloud Pod Architecture for Azure VMware Solution

Cloud Pod Architecture (CPA) is a standard Horizon feature that allows you to connect your Horizon deployment across multiple pods and sites for federated management. It can be used to scale up your deployment, to build hybrid cloud, and to provide redundancy for business continuity and disaster recovery. CPA introduces the concept of a global entitlement (GE) that spans the federation of multiple Horizon pods and sites.  Any users or user groups belonging to the global entitlement are entitled to access virtual desktops and RDS published apps on multiple Horizon pods that are part of the CPA.

Important: CPA is not a stretched deployment; each Horizon pod is distinct and all Connection Servers belonging to each of the individual pods are required to be located in a single location and run on the same broadcast domain from a network perspective.

Here is a logical overview of a basic two site/two pod CPA implementation.  For Azure VMware Solution, Site 1 and Site 2 might be different AVS Regions, or Site 1 might be on-premises or another supported cloud provider and Site 2 might be on Azure VMware Solution.

Linking Horizon Pods on Azure VMware Solution

You can use the Cloud Pod Architecture feature to connect Horizon pods regardless of whether the pods are on-premises or on Azure VMware Solution. When you deploy two or more Horizon pods on Azure VMware Solution, you can manage them independently or manage them together by linking them with Cloud Pod Architecture.

  • On one Connection Server, initialize Cloud Pod Architecture and join the Connection Server to a pod federation.
  • After CPA is initialized, you can create a global entitlement across your Horizon pods on-premises and on Azure VMware Solution.
  • Optionally, when you use Cloud Pod Architecture, you can deploy a global load balancer (such as Azure Traffic Manager, AVI, F5, or others) between the pods. The global load balancer provides a single-namespace capability that allows the use of a common global namespace when referring to Horizon CPA. Using CPA with a global load balancer provides your end users with a single connection method and desktop icon in their Horizon Client or Workspace ONE console.  

Scaling Deployments

In this section, we will discuss scaling options for scaling out Horizon on AVS. Following are the design decisions for a single SDDC and for multiple SDCCs.

Single SDDC

In a single SDDC deployment, it is recommended to locate the Horizon Management components in the Azure vNet, outside of the SDDC. This allows easier future scaling of capacity through the addition of more SDDCs to the pod, without having to relocate the management components.

Logical Architecture of a Single SDDC Deployment

Logical Architecture of a Single SDDC Deployment

Table 1: Networking to On-Premises

DecisionA single SDDC was deployed in Azure VMware Solution.The Horizon managements servers were located in Azure.
JustificationLocating the management servers in Azure allows the deployment to scale beyond the limits of a single SDDC.

Table 2: Connection Server Strategy

DecisionTwo Horizon Connection Servers were deployed.These ran on dedicated Windows 2019 VMs, located in the Azure vNet.
JustificationOne Connection Server supports a maximum of 4,000 sessions.A second server provides redundancy and availability (n+1).

Table 3: Unified Access Gateway Strategy

DecisionTwo standard-size Unified Access Gateway appliances were deployed.These were located in the Azure DMZ network.
JustificationUAG 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.A second UAG provides redundancy and availability (n+1).

Table 4: App Volumes Manager Strategy

DecisionTwo App Volumes Managers were deployed, located in the Azure vNet.The two App Volumes Managers are load balanced with a third-party load balancer.
JustificationApp Volumes is used to deliver applications to the virtual desktops and RDS Hosts.Two App Volumes Managers provide scale and redundancy and meets the target scale of the environment.

Table 5: Horizon Cloud Connector Strategy

DecisionOne Horizon Cloud Connector was deployed in licensing only mode and located in the Azure vNet.
JustificationThe Horizon Cloud Connector is required to license Horizon with subscription licensing.Control plane services beyond licensing are not supported at this time.

Table 6: Workspace ONE Access Connector Strategy

DecisionOne Workspace ONE Access Connector was deployed into the Azure vNet
JustificationThe connector enables the synchronization of Horizon entitlements into Workspace ONE Access.The use of Workspace ONE Access allow for seamless brokering into desktops and applications.Locating a connector locally in Azure ensure that resource synchronization does not rely on connectors in other locations and any dependency they may include.

Table 7: Dynamic Environment Manager Strategy

DecisionDynamic Environment Manager (DEM) was deployed on the File Server.
JustificationDEM provides configuration and personalization of the users Horizon desktops and published applications.Locating a file server for DEM data in Azure brings this data local to the Horizon desktops and published applications and reduces latency.

Table 8: SQL Server Strategy

DecisionA SQL server was deployed.
JustificationThe SQL server was used for the Horizon Events database and the App Volumes database.

Connecting to On-Premises

If you already have an on-premises environment, you can scale out this environment by adding one or more SDDCs on Azure VMware Solution and forming a new Horizon Pod.

AVS Deployment with Networking to On-Premises

AVS Deployment with Networking to On-Premises