This checklist will guide you to prepare your Microsoft Azure subscriptions and networks for the deployment of a pod from Horizon Cloud into Microsoft Azure. Ensuring that these requirements are fulfilled as described below will provide both for completing a successful new pod deployment and successfully completing those key tasks that are required to complete after a pod is deployed.

The sections in this documentation topic are:

This checklist is primarily for Horizon Cloud customer accounts that are created new after the March 2020 service release is made available and who have not yet deployed their first pod into Microsoft Azure. When such brand new accounts deploy their first pod, that pod deploys using the latest pod manifest version. The requirements for a successful pod deployment are primarily determined by the pod manifest version. The cloud control plane might also determine requirements for a successful deployment.

Some of the requirements listed below are the ones needed for pod deployment itself. Some requirements are those needed for the key tasks that are performed after pod deployment to get a productive tenant environment, able to provide pod-provisioned desktops and applications to your end users.

Requirements for pod deployment itself
Requirements for a productive environment after pod deployment
Important: Before launching the pod deployment wizard and starting to deploy your pod, in addition to the requirements below, you must be aware of the following key points:
  • Successful pod deployment requires that none of the Microsoft Azure Policies that you or your IT team have set in your Microsoft Azure environment block, deny, or restrict creation of the pod's components. Also you must verify that your Microsoft Azure Policies Built-in Policy definitions do not block, deny, or restrict creation of the pod's components. As an example, you and your IT team must verify that none of your Microsoft Azure Policies block, deny, or restrict creation of components on Azure storage account. For information about Azure Policies, see the Azure Policy documentation.
  • The pod deployer requires that your Azure storage account allow for the deployer to use the Azure StorageV1 and StorageV2 account types. Ensure that your Microsoft Azure Policies do not restrict or deny the creation of content requiring the Azure StorageV1 and StorageV2 account types.
  • As part of the pod and gateway deployment processes, Horizon Cloud creates resource groups (RGs) in your Microsoft Azure subscription that do not have tags on them, including the initial resource group that is created for the temporary jump box that orchestrates those deployment processes. Pod deployment will fail if you try to deploy a pod into a Microsoft Azure subscription that has any type of resource tag requirement at the time of deployment, or at the time of pod upgrades or adding a gateway configuration to a pod. You must verify that your Microsoft Azure Policies allows creation of the pod's untagged resource groups in the target subscription. For the list of RGs that the deployer creates, see the Administration Guide's Resource Groups Created For a Pod Deployed In Microsoft Azure topic.
  • All cloud-connected pods must have line-of-sight to the same set of Active Directory domains at the time you deploy those pods.

Horizon Cloud Control Plane Requirements

Active My VMware account to log in to the Horizon Cloud control plane.

Microsoft Azure Subscription Requirements

Valid Microsoft Azure subscription in a supported Microsoft Azure environment (Public Azure, Azure China, and Azure Government). If you will be deploying the optional external Unified Access Gateway in a separate VNet using its own subscription, then you need an additional valid Microsoft Azure subscription in the same Microsoft Azure environment.
Note: Horizon Cloud supports the majority of the Microsoft Azure regions. For the list of Microsoft Azure regions that are not currently supported, see VMware Knowledge Base article Microsoft Azure Regions with Horizon Cloud Service on Microsoft Azure (77121).
Valid Microsoft Azure administrative privileges in that Microsoft Azure subscription. For additional information, see Get Started with Role-Based Access Control in the Azure portal in the Microsoft documentation.
Minimum Microsoft Azure capacity available for Horizon Cloud infrastructure in addition to the expected desktop and app workload. Note that as long as this capacity is made available, Horizon Cloud will automatically deploy these VMs and no manual installation is required.
  • Pod Deployment Engine, also known as the Jump Box (transient) — 1 x Standard_F2
  • Pod/Pod Manager with High Availability enabled — 2 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 2 x Standard_D3_v2)
  • Pod/Pod Manager without High Availability enabled — 1 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 1 x Standard_D3_v2)
  • Microsoft Azure Database for PostgreSQL Service — Generation 5, Memory Optimized, 2 vCores, 10 GB Storage
  • External Unified Access Gateway (optional) — 2 x Standard_A4_v2
  • Internal Unified Access Gateway (optional) — 2 x Standard_A4_v2
Note: After pod deployment is finished, your capacity in Microsoft Azure cloud will have to also accommodate the base images, virtual desktops, and RDSH farms that you create in that pod. See the Horizon Cloud Base Images, Desktops, and Farms section below.

The external Unified Access Gateway can be optionally deployed into its own Microsoft Azure Virtual Network (VNet), either using the same subscription as the pod or using a different subscription. When deploying the external Unified Access Gateway into its own VNet, the following capacity is needed in the subscription into which the external Unified Access Gateway is deployed:

  • External Unified Access Gateway Deployment Engine, also known as the Gateway Jump Box (transient) — 1 x Standard_F2
  • External Gateway Connector — 1 x Standard_A1_v2
  • External Unified Access Gateway — 2 x Standard_A4_v2
Service principal and authentication key created for each subscription. For additional details, see Use a portal to create an Azure Active Directory application and service principal that can access resources. See also Create the Required Service Principal Needed by the Horizon Cloud Pod Deployer by Creating an Application Registration.
Each service principal must be assigned the appropriate role that allows for the actions that Horizon Cloud must perform in the subscription. This role can be the Contributor role or a custom role with the required permitted actions at the subscription level. When you are deploying the external gateway configuration in an existing resource group in a separate subscription, more granular permissions can be set for that subscription's service principal. For additional details about the required role actions, see Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions.
Required resource providers registered in each Microsoft Azure subscription. See step 8.b in Create the Required Service Principal Needed by the Horizon Cloud Pod Deployer by Creating an Application Registration.
Microsoft Azure subscription ID, directory ID, application ID and key identified.
If you will be deploying the optional external Unified Access Gateway in a separate VNet using its own subscription, and your organization requires use of a resource group controlled by you and not created by the pod deployer, you would use the feature to deploy the external Unified Access Gateway into your own named resource group. Use of that feature requires you to create that resource group in that subscription before you run the pod deployer. You also need to ensure the necessary permissions are in place for the pod deployer to deploy the Unified Access Gateway configuration into that resource group, manage the configuration, and update the Unified Access Gateway software in the standard pod upgrade process. For details about the necessary permissions, see Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions.

Network Requirements

Microsoft Azure Virtual Network (VNet) created in desired Microsoft Azure region with applicable address space to cover required subnets. For additional details, see Azure Virtual Network.

When deploying the optional external Unified Access Gateway into its own VNet separate from the pod's VNet, create that Unified Access Gateway VNet in the same Microsoft Azure region as the pod's VNet with applicable address space to cover required subnets, and peer the two VNets.

3 non-overlapping address ranges in CIDR format in the pod's VNet, reserved for subnets.
  • Management subnet — 27 minimum
  • Tenant subnet — 27 minimum with /24 - /22 preferred, based on the number of desktops and RDS servers
  • DMZ subnet — /28 minimum when Unified Access Gateway is deployed in the pod's VNet (optional)
Subnets can either be created manually on the VNet or by Horizon Cloud during deployment. If using manually created subnets, no other resources can be attached.
When deploying the optional external Unified Access Gateway into its own VNet separate from the pod's VNet, 3 non-overlapping address ranges in CIDR format in the Unified Access Gateway's VNet, reserved for subnets.
  • Management subnet — 27 minimum
  • Back end subnet — 27 minimum with /24 - /22 preferred, based on the number of desktops and RDS servers
  • DMZ (front end) subnet — /28 minimum
Subnets can either be created manually on the VNet or by Horizon Cloud during deployment. If using manually created subnets, no other resources can be attached. For this use case, usually the subnets are created manually.
NTP server or servers available and accessible from the Horizon Cloud pod and Unified Access Gateway instances.
Configure the VNet (Virtual Network) DNS server, pointing to a valid DNS server that can resolve both internal machine names and external names.
Outbound internet access on the VNet to specific DNS names that must be resolvable and reachable using specific ports and protocols. This is required for deployment and ongoing operations, see DNS Requirements for a Horizon Cloud Pod in Microsoft Azure and Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.
Proxy server information if required for outbound internet access on the VNet that is used during deployment and ongoing operations of the Horizon Cloud environment (optional)
Microsoft Azure VPN/Express Route configured (optional)
FQDN for external and or internal user access (Required when deploying a pod with Unified Access Gateway).
Certificate or certificates for Unified Access Gateway in PEM format matching the FQDN (required when deploying a pod with Unified Access Gateway).
Two-factor authentication to an on-premises RADIUS authentication server (optional)
  • DNS Addresses for Unified Access Gateway to resolve the name of the authentication server
  • Routes for Unified Access Gateway to resolve network routing to the authentication server

Ports and Protocols Requirements

Specific ports and protocols are required for onboarding pods and ongoing operations of your Horizon Cloud environment. See Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.

Pod Deployment Workflow

The preceding items are the ones needed before you start the pod deployment wizard. After you ensure you have the preceding items, follow the pod deployment steps through step 4 in High-Level Workflow for When Your Very First Cloud-Connected Pod is from Deploying into Microsoft Azure to deploy your pod.

Then after the pod is successfully deployed, ensure you have the items described in the following section, so that you can complete the remaining key steps in that high-level workflow.

Active Directory Requirements

The following items are needed for the Active Directory registration workflow. For understanding of that workflow, see Performing Your First Active Directory Domain Registration in the Horizon Cloud Environment.

One of the following supported Active Directory configurations:
  • On-premises Active Directory Server connected via VPN/Express Route
  • Active Directory Server located in Microsoft Azure
  • Microsoft Azure Active Directory Domain Services
Supported Microsoft Windows Active Directory Domain Services (AD DS) domain functional levels:
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
All cloud-connected pods in the same Horizon Cloud customer account must have line-of-sight to the same set of Active Directory domains at the time you deploy those pods. This requirement applies not only to additional pods that you subsequently deploy into Microsoft Azure after the first pod, but also to any on-premises or in-AWS Horizon pods that are cloud-connected to the same customer account using the Horizon Cloud Connector. You can see the checklist for such Horizon pods at VMware Horizon 7 with Horizon Cloud Requirements Checklist - Updated for the March 2020 Service Release.
Domain bind account
  • Active Directory domain bind account (a standard user with read access) that has the following permissions:
    • List Contents
    • Read All Properties
    • Read Permissions
    • Read tokenGroupsGlobalAndUniversal (implied by Read All Properties)
    Note: If you are familiar with the VMware Horizon on-premises offering, the above permissions are the same set that are required for the Horizon on-premises offering's secondary credential accounts, stated in this Horizon on-premises documentation topic.

You should also set the account password to Never Expire to ensure continued access to log in to your Horizon Cloud environment.

For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations

Auxiliary domain bind account — cannot use the same account as above
  • Active Directory domain bind account (a standard user with read access) that has the following permissions:
    • List Contents
    • Read All Properties
    • Read Permissions
    • Read tokenGroupsGlobalAndUniversal (implied by Read All Properties)
    Note: If you are familiar with the VMware Horizon on-premises offering, the above permissions are the same set that are required for the Horizon on-premises offering's secondary credential accounts, stated in this Horizon on-premises documentation topic.

You should also set the account password to Never Expire to ensure continued access to log in to your Horizon Cloud environment.

For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations

Domain join account
  • Active Directory domain join account which can be used by the system to perform Sysprep operations and join computers to the domain, typically a new account (domain join user account)
  • Is a member of the Horizon Cloud Administrators Group
  • Set account password to Never Expire
  • This account requires the following Active Directory permissions: List Contents, Read All Properties, Read Permissions, Reset Password, Create Computer Objects, Delete Computer Objects.
  • This account also requires the Active Directory permission named Write All Properties on all descendant objects of the target Organizational Unit (OU) that you plan to use for farms and VDI desktop assignments.
  • For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations
Auxiliary domain join account (Optional, cannot use the same account as above)
  • Active Directory domain join account which can be used by the system to perform Sysprep operations and join computers to the domain, typically a new account (domain join user account)
  • Is a member of the Horizon Cloud Administrators Group
  • Set account password to Never Expire
  • This account requires the following Active Directory permissions: List Contents, Read All Properties, Read Permissions, Reset Password, Create Computer Objects, Delete Computer Objects.
  • This account also requires the Active Directory permission named Write All Properties on the all descendant objects of the target Organizational Unit (OU) that you plan to use for farms and VDI virtual desktops.
  • For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations
Active Directory groups
  • Horizon Cloud Administrators — Active Directory security group for Horizon Cloud administrators. Contains the Horizon Cloud administrative users and domain join account. This group is added to the Super Administrators role in Horizon Cloud.
  • Horizon Cloud Users — Active Directory security group for the users which will have access to virtual desktops and RDS session-based desktops and published applications in Horizon Cloud.
Active Directory organizational unit (OU) or units (OUs) for virtual desktops and RDS session-based desktops or published applications or both.

DNS Record Requirements

After the pod is deployed into the Microsoft Azure cloud and depending on your business situation and the features you want to leverage, it is important to set up records in your DNS server that map fully qualified domain names (FQDNs) to pod-related IP addresses.

Public DNS record created for external end-user access that matches the FQDN, pointing to Microsoft Azure external load balancer in the pod's external Unified Access Gateway configuration (required when the deployed pod has that configuration). For additional details, see Configuring a custom domain name for an Azure cloud service.
Internal DNS record created for internal end-user access that matches the FQDN, pointing to the Microsoft Azure internal load balancer in the pod's internal Unified Access Gateway configuration (required when the deployed pod has that configuration).
Internal DNS record created for VMware Workspace ONE Access connections to the pod that matches the certificate that you will upload to the pod itself, pointing to the pod manager's Microsoft Azure internal load balancer. Required when you want to use VMware Workspace ONE Access with the pod.
Note: This internal DNS record and a certificate that matches and is uploaded to the pod itself are also used in the rare, atypical use case when you would tell internal end users to directly connect to the pod, instead of telling them to connect to an internal Unified Access Gateway configuration on the pod. Such direct connections are an unsual use case. Typically an internal Unified Access Gateway is used instead.
Certificate chain (CA certificate, SSL certificate, SSL key file) that matches the above internal DNS record created for VMware Workspace ONE Access connections to the pod. For additional details, see Upload SSL Certificates to a Horizon Cloud Pod for Direct Connections. (Also required if you are using the atypical use case of having internal end users connect directly to the pod. Direct connections are a rare, unusual usage. Typically an internal Unified Access Gateway is used instead.)

Horizon Cloud Base Image, Desktops, and Farms

Your Microsoft Azure subscription must accommodate the following requirements depending on the types of master images, VDI desktops, and RDS farms you want to provision from the deployed pod.

Base for the master image — one of the supported Microsoft Azure VM configurations.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6
Note: When using the automated Import VM from Marketplace wizard to create a base VM, the system automatically uses one of the above VM sizes by default. The system's default choice is based on internal algorithms that including checking what sizes are available in the pod's Microsoft Azure region. When using the wizard to create a GPU-enabled VM, the Standard_NV6 size VM is created by default. When using the wizard to create a server OS-based VM, a VM of either Standard_D2_v2 or Standard_D2_v3 is created. When creating a client OS-based VM or a Windows 10 multi-session VM, a VM of either Standard_D3_v2 or Standard_D4_v3 is created.
Model selection for the desktop VMs in VDI desktop assignments — any of the Microsoft Azure VM configurations available in the Microsoft Azure region, except for those not compatible with Horizon Cloud desktop operations.

For production environments, VMware scale testing recommends using models that have a minimum of 2 CPUs or larger.

Model selection for the RDSH VMs in farms — any of the Microsoft Azure VM configurations available in the Microsoft Azure region, except for those not compatible with Horizon Cloud RDS farm operations.

This requirement also applies to a VM running Microsoft Windows 10 Enterprise multi-session when that VM is used with Horizon Cloud. As described in the Microsoft Windows 10 Enterprise multi-session FAQ in the Microsoft Azure Windows Virtual Desktop documentation, Microsoft Windows 10 Enterprise multi-session is a Remote Desktop Session Host (RDSH) type that allows multiple concurrent interactive sessions, which previously only Microsoft Windows Server operating systems could provide. The Horizon Cloud workflows that apply to RDS servers are applicable to Microsoft Windows 10 multi-session.

For production environments, VMware scale testing recommends using models that have a minimum of 2 CPUs or larger.

Licensing for the Microsoft Windows Operating Systems

The items are related to the Microsoft Windows operating systems in your base master images, RDSH-capable farm VMs, and virtual desktop VMs. For the list of Microsoft Windows operating systems that Horizon Cloud supports, see VMware Knowledge Base article 78170 and VMware Knowledge Base article 70965.

Horizon Cloud does not provide any guest operating system licensing required for use of Microsoft Windows operating systems that you use in the course of using the Horizon Cloud workflows. You, the customer, have the responsibility to have valid and eligible Microsoft licenses that entitle you to create, perform workflows on, and operate the Windows-based desktop VMs and RDSH VMs that you choose to use in your Horizon Cloud tenant environment. The required licensing depends on your intended use.

Tip: For information about Microsoft Windows Virtual Desktop licensing for Windows 10 Enterprise multi-session and Windows 7 Enterprise, see the Microsoft Azure documentation topic Windows Virtual Desktop pricing.
Licensing for one or more of the following types: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (client types)
Licensing for Microsoft Windows 10 Enterprise multi-session
Licensing for one or more of the following types: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019
Microsoft Windows RDS Licensing Servers — for high availability, redundant licensing servers are recommended
Microsoft RDS User or Device CALs or both

Reference Architecture

Use the architecture diagrams below for reference.

Figure 1. Illustration of the Horizon Cloud Pod Architecture for a Pod with High Availability Enabled and Configured with Both External and Internal Gateway Configurations, the External Gateway Deployed into the Same VNet as the Pod, and a Public IP Enabled for the External Gateway's Load Balancer

Architecture illustration of the pod's resource groups, VMs, and subnets for a pod that has high availability enabled and both types of Unified Access Gateway configurations, with the external gateway residing in the same VNet as the pod.

Figure 2. Illustration of the External Gateway's Architecture Elements When the External Gateway is Deployed into Its Own VNet, Separate from the Pod's VNet, and into a Resource Group Created by the Pod Deployer

Illustration of the External Gateway's Architecture Elements When the External Gateway is Deployed into Its Own VNet, Separate from the Pod's VNet, and into a Resource Group Created by the Pod Deployer

Resources

See the following resources for additional information.