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:
- 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.
- Deploy Horizon 8 on the Azure VMware Solution, following the architecture described in Scaling Deployments.
- See the Horizon documentation and Horizon Installation and Configuration.
- See the VMware Knowledge Base article VMware Horizon on Azure VMware Solution (AVS) Support (80850) for features and versions supported on AVS.
- 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:
- Install Active Directory, DNS, DHCP, and KMS servers.
- Optionally, install RDS license servers.
- Install one or more Horizon Connector Servers. See Connection Server Deployment.
- Install a Horizon Cloud Connector. See Horizon Cloud Connector Deployment.
- Install one or more Unified Access Gateways. See Unified Access Gateway Deployment.
Preparation
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 Infrastructure | Instance | vCPU | Memory | Amount |
| Connection Server | D4s_v4 | 4 | 16 | 1 per 2,000 sessions, +1 |
| Unified Access Gateway | D4s_v4 | 4 | 16 | 1 per 2,000* sessions, +1 |
| App Volumes Manager | D4s_v4 | 4 | 16 | 1 per 2,000 sessions, +1 |
| Horizon Cloud Connector | D8_v3 | 8 | 32 | 1 |
| Domain Controller* | D4s_v4 | 4 | 16 | Minimum 2 |
| MS-SQL Database* | D4s_v4 | 4 | 16 | Minimum 2 |
| Windows file share* | D4s_v4 | 4 | 16 | Minimum 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=10.0.0.0/8 10.6.4.1,172.16.0.0/12 10.6.4.1,192.168.0.0/16 10.6.4.1
- Where: 10.6.4.1 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.
- Configure ExpressRoute and firewall rules to enable the Connection Server instance with Azure VMware Solution to communicate with the Connection Server instance on-premises.
- Prepare Microsoft Active Directory (AD) and choose to set up a one-way trust or a two-way trust.
- 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. - Use Cloud Pod Architecture to connect the other Horizon pods against the Horizon pod with Azure VMware Solution.
- For easy sharing of VM images and ISO images, you can use the vCenter Content Library on each vCenter Server.
- 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:
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 Name | Port | Protocol | Source | Destination | Action |
| Allow-UAG-CS-XML_API | 443 | TCP | Unified Access Gateway Internal – Application Security Group | Connection Servers – Application Security Group | Allow |
| Allow_443-CS | 443,8443 | Any | Any | Connection Servers – Application Security Group | Allow |
| Allow_AVSDesktop-AVM | 443 | TCP | VDI Subnet | AppVolumes Managers – Application Security Group | Allow |
| Allow_DomainControllerInbound | Any | Any | Horizon Management Subnet,VDI Subnet,On-premises Management Subnet | Domain Controllers – Application Security Group | Allow |
| Allow_AVM-MGMT-DC | 443 | TCP | Horizon Management Subnet | AppVolumes Managers – Application Security Group | Allow |
| Allow_LDAP_Replication-CS-CS | 22389,22636,49152-65535,389,135,32111,4100,4101 | TCP | Connection Servers – Application Security Group | Connection Servers – Application Security Group | Allow |
| Allow_InterPODCommunication | 8472,22389,22636,49152-65535,135 | TCP | On-premises Management Subnet | Connection Servers – Application Security Group | Allow |
| Allow_CloudConnector-CS | 443,4002 | TCP | Cloud Connector – Application Security Group | Connection Servers – Application Security Group | Allow |
| Allow_WorkspaceONEConnector-CS | 443,389 | TCP | WS ONE Access Connector – Application Security Group | Connection Servers – Application Security Group | Allow |
| Allow_AVM-DB | 1433 | TCP | AppVolumes Managers – Application Security Group | SQL Database – Application Security Group | Allow |
| Allow_AVSDesktop-CS | 4001,4002,389 | TCP | VDI Subnet | Connection Servers – Application Security Group | Allow |
| Allow_DFS_FileServerAccess | 135,137,138,139,445,5445,5722 | Any | Horizon Management Subnet,VDI Subnet,On-premises Management Subnet | File Server – Application Security Group | Allow |
| Allow_UAG-DNSonDC | 53 | Any | Unified Access Gateway Internal – Application Security Group | Domain Controllers – Application Security Group | Allow |
| Allow_CloudConnectorMgmt | 443 | TCP | Horizon Management Subnet | Cloud Connector – Application Security Group | Allow |
| Allow_ALB-AVM | 443 | TCP | AzureLoadBalancer | AppVolumes Managers – Application Security Group | Allow |
| Allow_ALB-CS | 443,8443 | TCP | AzureLoadBalancer | Connection Servers – Application Security Group | Allow |
| Deny_All | Any | Any | Any | Any | Deny |
| AllowVnetInBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| AllowAzureLoadBalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow |
| DenyAllInBound | Any | Any | Any | Any | Deny |
Table 3: Management and Internal DMZ Outbound Security Rules
| Rule Name | Port | Protocol | Source | Destination | Action |
| AllowVnetOutBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| AllowInternetOutBound | Any | Any | Any | Internet | Allow |
| DenyAllOutBound | Any | Any | Any | Any | Deny |
Table 4: Internal DMZ Inbound Security Rules
| Rule Name | Port | Protocol | Source | Destination | Action |
| Allow_UAG-Management | 9443 | TCP | Horizon Management Subnet | Unified Access Gateway Internal – Application Security Group | Allow |
| Deny_All | Any | Any | Any | Any | Deny |
| AllowVnetInBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| AllowAzureLoadBalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow |
| DenyAllInBound | Any | Any | Any | Any | Deny |
Table 5: External Inbound Security Rules
| Rule Name | Port | Protocol | Source | Destination | Action |
| Port_443 | 443 | TCP | Any | Unified Access Gateway External – Application Security Group | Allow |
| BLAST_TCP | 8443 | TCP | Any | Unified Access Gateway External – Application Security Group | Allow |
| BLAST_UDP | 8443 | UDP | Any | Unified Access Gateway External – Application Security Group | Allow |
| UDP_Tunnel | 443 | UDP | Any | Unified Access Gateway External – Application Security Group | Allow |
| PCoIP_TCP | 4172 | TCP | Any | Unified Access Gateway External – Application Security Group | Allow |
| PCoIP_UDP | 4172 | UDP | Any | Unified Access Gateway External – Application Security Group | Allow |
| Allow_ALB-UAG-EXT | 443 | TCP | AzureLoadBalancer | Unified Access Gateway External – Application Security Group | Allow |
| AllowVnetInBound | Any | Any | VirtualNetwork | VirtualNetwork | Allow |
| AllowAzureLoadBalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow |
| DenyAllInBound | Any | Any | Any | Any | Deny |
Table 6: External DMZ Outbound Security Rules
| Rule Name | Port | Protocol | Source | Destination | Action |
| AllowInternetOutBound | Any | Any | Any | Internet | Allow |
| DenyAllOutBound | Any | Any | Any | Any | Deny |
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
| Name | UAG | CS | AVM | Outbound Internet |
| SKU | Public Standard | Internal Standard | Internal Standard | Public Standard |
| Protocol | TCP | TCP | TCP | All |
| Port | 443 | 443 | 443 | na |
| Backend port | 443 | 443 | 443 | na |
| Backend Pool | Unified Access Gateways | Connection Servers | App Volumes Managers | Connection Servers, App Volumes Managers |
| Health Probe | HTTPS:443/favicon.ico | HTTPS:443/favicon.ico | HTTPS:443/health_check | na |
| Session Persistence | Client IP | Client IP | Client IP | na |
| Floating IP | Disabled | Disabled | Disabled | na |
| TCP reset | Disabled | Disabled | Disabled | na |
| SNAT | Use outbound rules | Use outbound rules | Use outbound rules | na |
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
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
Table 1: Networking to On-Premises
| Decision | A single SDDC was deployed in Azure VMware Solution.The Horizon managements servers were located in Azure. |
| Justification | Locating the management servers in Azure allows the deployment to scale beyond the limits of a single SDDC. |
Table 2: Connection Server Strategy
| Decision | Two Horizon Connection Servers were deployed.These ran on dedicated Windows 2019 VMs, located in the Azure vNet. |
| Justification | One Connection Server supports a maximum of 4,000 sessions.A second server provides redundancy and availability (n+1). |
Table 3: Unified Access Gateway Strategy
| Decision | Two standard-size Unified Access Gateway appliances were deployed.These were located in the Azure DMZ network. |
| Justification | 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.A second UAG provides redundancy and availability (n+1). |
Table 4: App Volumes Manager Strategy
| Decision | Two App Volumes Managers were deployed, located in the Azure vNet.The two App Volumes Managers are load balanced with a third-party load balancer. |
| Justification | App 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
| Decision | One Horizon Cloud Connector was deployed in licensing only mode and located in the Azure vNet. |
| Justification | The 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
| Decision | One Workspace ONE Access Connector was deployed into the Azure vNet |
| Justification | The 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
| Decision | Dynamic Environment Manager (DEM) was deployed on the File Server. |
| Justification | DEM 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
| Decision | A SQL server was deployed. |
| Justification | The 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
