The purpose of this checklist is to inform you about the required elements for a Horizon Cloud on Microsoft Azure deployment. Following this checklist provides for successfully running the pod deployer and completing the day-1 tasks.
Checklist Audience
This checklist is primarily for Horizon Cloud customer accounts that have never had a Horizon Cloud on Microsoft Azure deployment in their tenant environment prior to the service release date on October 20, 2022. You might hear such tenants referred to as clean-slate environments or greenfield environments.
The set described here is primarily for production deployments. Trials and most proof-of-concept deployments can usually be handled with a subset, such as illustrated in a simplified proof-of-concept deployment.
Some of the sections listed below must be put into place prior to running the New Pod deployment wizard.
Some items can be deferred until after the deployment is completed and running.
Some items are listed as optional, because they relate to choices you make for your Horizon Cloud on Microsoft Azuredeployment.
For example, you can run the New Pod wizard without choosing a Unified Access Gateway configuration and add the gateway configuration later. In this case, you wouldn't need to fulfill the Unified Access Gateway requirements until that later time.
Fulfill these before running the New Pod wizard | Can be done after the pod is deployed |
---|---|
|
|
Some Key Considerations
When you are doing a trial or proof-of-concept Horizon Cloud on Microsoft Azure deployment, you might be the owner of the Microsoft Azure subscription that you will be using for the deployment or you might be doing the proof-of-concept on behalf of an organization that owns the subscription.
The owner of the subscription must ensure that none of the Microsoft Azure Policies that are in effect in the pod's subscription would block, deny, or restrict creation of the pod's components.
The reason for ensuring that is because during the pod deployment process, the pod deployer uses API calls to create resources within the subscription specified in the New Pod wizard. If that subscription has Microsoft Azure Policies in effect that would block, deny, or restrict creation of the pod's components, the deployment will be unsuccessful and require a support request to VMware support.
One example is the pod deployer requires that none of the Microsoft Azure Policies that are in effect in the pod's subscription are blocking, denying, or restricting creation of components on Azure storage account.
Before running the New Pod wizard, verify with the subscription's owner that the Microsoft Azure Policies Built-in Policy definitions do not block, deny, or restrict creation of the pod's components.
Horizon Cloud Control Plane Requirements
☐ | VMware Customer Connect account that has been configured by VMware to log in to the Horizon Cloud control plane. For an overview of the relationship of this account to your Horizon Cloud tenant account, you can refer to the page Horizon Service Deployments and Onboarding Pods. |
Microsoft Azure Subscription Requirements
☐ | Valid Microsoft Azure subscription in a supported Microsoft Azure environment (Azure Commercial, Azure China, or Azure Government). If you will be deploying the external Unified Access Gateway in a separate VNet using its own subscription, then obtain 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 you to use the Microsoft Azure portal and perform the pod deployment preparation steps. |
☐ | Horizon Cloud app registration and client secret key created in the pod's subscription. See Create a Horizon Cloud App Registration in the Pod's Subscription. When you or your organization will be using the feature to deploy the external gateway configuration in a subscription separate from the pod's subscription, that gateway subscription also needs a Horizon Cloud app registration and a client secret key. |
☐ | Creating the Horizon Cloud app registration in a subscription automatically creates a service principal, by standard Microsoft Azure behavior. To this service principal, assign a role that allows for Horizon Cloud to make API calls in the pod's subscription. Usually the Alternatively, the role can be custom role assigned at the pod's subscription level. When you are deploying the external gateway configuration in an existing resource group in a separate subscription, you can assign either a custom role or the When you or your organization want the Horizon Cloud app registration to use a custom role, see the following page that describes the actions that custom role must have — When Your Organization Prefers to Use a Custom Role.
Note: The role must be assigned directly to the
Horizon Cloud app registration's service principal. The use of a group-based assignment of a role to this service principal is unsupported.
|
☐ | Required resource providers registered in each Microsoft Azure subscription. See Register Resource Providers. |
☐ | Subscription ID, directory ID, application ID and key identified for the subscription that you will specify in the deployment wizard. |
☐ | The subscription must allow use of the Azure StorageV2 account type. Ensure that the subscription's Microsoft Azure Policies do not restrict or deny creation of content that requires the Azure StorageV2 account type. |
☐ | The subscription must allow creation of resource groups that do not have tags on them, unless you specify custom resource tags in the pod deployment wizard. The pod deployment process creates resource groups in the pod's subscription without tags on them unless you specify custom resource tags in the wizard. If you are not planning to use the deployment wizard's custom resource tags feature, you must verify that your Microsoft Azure Policies allows creation of the pod's untagged resource groups in the target subscription. If you do not specify custom resource tags in the wizard and your Microsoft Azure subscription has any type of resource tag requirement, pod deployment will fail when you try to deploy a pod into that subscription, or it will fail at the time of pod updates or adding a gateway configuration to a pod. For the names of the deployer-created resource groups, refer to Resource Groups that the Pod Deployer Creates. |
☐ | Optional. Your organization might specify that they require you use a specific, pre-created resource group named by the organization for the external Unified Access Gateway, in a separate VNet and subscription from the pod's subscription, and your organization requires use of a specific, pre-created resource group named by the organization, you would use the feature to deploy the external Unified Access Gateway into your own named resource group. Without using that feature, the pod deployer automatically creates a resource group with its own naming convention. Use of the feature to use a requires you to create that resource group in that subscription before you run the pod deployer. You also must 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 update process. For details about the necessary permissions to include in the custom role, see When Your Organization Prefers to Use a Custom Role. |
Microsoft Azure Capacity Requirements
Where the following table refers to Microsoft Azure capacity, no manual installation is required. As long as the stated capacities are available in the subscription, the pod deployer will automatically instantiate the described VMs.
For capacity involving VM families, the Microsoft Azure portal also uses the term quota.
☐ | Microsoft Azure capacity for the core Horizon Cloud pod artifacts to deploy into that subscription. (This list excludes the capacities needed for the optional Unified Access Gateway configurations and for your anticipated desktop and app workloads.)
|
☐ | Optional. Capacity required when specifying use of Unified Access Gateway for the pod.
Note: The
A4_v2 VM model is only sufficient for proofs-of-concept (PoCs), pilots, or smaller environments where you know that you will not exceed 1,000 active sessions on the pod.
If your subscription's region does not provide for the |
Network Requirements
☐ | Microsoft Azure Virtual Network (VNet) created in your target Microsoft Azure region with applicable address space to cover required subnets. See Configure the Required Virtual Network in Microsoft Azure. When deploying the 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.
Tip: After the pod is deployed, you can edit the pod to add tenant subnets for use with the VMs in your farms and desktop assignments. The additional tenant subnets can be in the same VNet into which the pod is deployed or in a peered VNet. For details, see
Overview of Using Multiple Tenant Subnets.
|
☐ | When deploying the 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.
|
☐ | 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 VNets you are using for the pod and gateway deployment must resolve and reach specific DNS names using specific ports and protocols. This is required for deployment and ongoing operations. For the list of DNS names and ports, see DNS Requirements and Ports and Protocol Requirements. |
☐ | Optional. 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, when you want networking between the VNet and your on-premises corporate network. |
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. |
Unified Access Gateway Requirements
You can run the New Pod wizard without choosing a Unified Access Gateway configuration and add the gateway configuration later. In this case, you wouldn't need to fulfill the Unified Access Gateway requirements until that later time. By definition, an external Unified Access Gateway enables clients on external networks to launch the virtual desktops and apps, while an internal Unified Access Gateway enables clients on internal networks to have trusted HTML Access (Blast) connections. To support end-user connections from the Internet and launching their virtual desktops and apps, the pod must have an external Unified Access Gateway configured.
If you do select the Unified Access Gateway options within the New Pod wizard, the wizard mandates specific items below.
☐ | FQDN for the Unified Access Gateway configuration. |
☐ | Certificate or certificates for the Unified Access Gateway in PEM format matching the FQDN.
Note: If the certificate or certificates that you supply for this purpose use CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) settings that refer to specific DNS names, then you must ensure outbound Internet access on the VNet to those DNS names is resolvable and reachable. During configuration of your supplied certificate in the
Unified Access Gateway gateway configuration, the
Unified Access Gateway software will reach out to those DNS names to check the certificate's revocation status. If those DNS names are not reachable, pod deployment will fail during its
Connecting phase. These names are highly dependent on the CA that you used to obtain the certificates, and therefore are not in VMware's control.
|
☐ | Optional, except when you want your end users to use two-factor authentication. In that case, the Unified Access Gateway must be configured for two-factor authentication with one of the authentication system types supported for use with Horizon Cloud on Microsoft Azure deployments. The configuration should include:
Note: After the pod is deployed and you have configured two-factor authentication in the
Universal Broker settings, some additional configuration is needed when you want to also have your internal end users skip using that two-factor authentication. When a pod has an internal
Unified Access Gateway configuration, that configuration routes the connection requests to virtual desktops and apps for such internal end users. When you want
Universal Broker to skip the two-factor authentication step for your internal end users, then after the pod is deployed and
Universal Broker is configured, enter the ranges of egress NAT addresses that correspond to your internal end-user traffic. Those ranges let
Universal Broker identify client traffic from the internal end users distinct from the external end users for the purposes of skipping the two-factor authentication. For details, see the documentation topic
Define Internal Network Ranges for Universal Broker
|
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 Horizon Cloud on Microsoft Azure - First Pod Deployment - High-Level Workflow 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 console's Active Directory registration workflow mandates the following items. For full 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:
|
☐ | Supported Microsoft Windows Active Directory Domain Services (AD DS) domain functional levels:
|
☐ | 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 Horizon pods that are cloud-connected to the same customer account using the Horizon Cloud Connector. |
☐ |
Reference: Service Accounts That Horizon Cloud Requires for Its Operations |
☐ |
Reference: Service Accounts That Horizon Cloud Requires for Its Operations |
☐ |
For more details, see Service Accounts That Horizon Cloud Requires for Its Operations In Microsoft Active Directory, when you create a new OU, the system might automatically set the |
☐ |
For more details, see Service Accounts That Horizon Cloud Requires for Its Operations In Microsoft Active Directory, when you create a new OU, the system might automatically set the |
☐ | Active Directory groups
Horizon Cloud supports use of Active Directory security groups for both administrator logins and end user entitlements. Nested groups are supported. Group membership is evaluated by requesting the tokenGroups computed attribute, meaning that Horizon Cloud has no nesting depth limitations but supports whatever is set in your Active Directory. When asked if there are additional considerations or additional limitations in the context of Active Directory groups and the combination of Horizon Cloud plus Universal Broker plus Workspace ONE Access Cloud, the answer to that question is no, none. If your tenant environment has any Horizon Cloud pods in Microsoft Azure running manifests older than manifest 1600.0, the domain join account and any auxiliary domain join accounts must also be in Horizon Cloud Administrators group — or in an Active Directory group which is granted the Super Administrator role in Horizon Cloud. |
☐ | Active Directory organizational unit (OU) or units (OUs) for virtual desktops and RDS session-based desktops or published applications or both. In Microsoft Active Directory, when you create a new OU, the system might automatically set the |
If you want to use an Active Directory configured for LDAPS, you must request enablement of the LDAPS supported features with your Horizon Cloud tenant. For more details, see Using Active Directory Environments Configured for LDAPS.
Universal Broker Configuration
For the Universal Broker configuration, ensure you fulfill the items from the following table that are applicable to your desired options. For full details, see Configure Universal Broker.
☐ | Outbound Internet access on the VNets you are using for the pod must resolve and reach specific DNS names using specific ports and protocols. This is required for Universal Broker configuration and ongoing operations. For the list of DNS names and ports, see Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names and Horizon Cloud Pod - Ports and Protocols Requirements. |
☐ | Depending on the types of end-user connections you want to provide for:
|
☐ | Optional. When you want Universal Broker to enforce two-factor authentication, pods must have an external Unified Access Gateway configured for two-factor authentication with one of the authentication system types supported for use with Horizon Cloud on Microsoft Azure deployments. Universal Broker passes the authentication request to Unified Access Gateway, which communicates with the authentication server, and then relays the response back to Universal Broker. That external Unified Access Gateway configuration requires the following items:
|
☐ | Optional: A custom FQDN that your end users will use to access the Universal Broker service and the certificate based on that FQDN. If you want to use the VMware-provided brokering FQDN, a custom FQDN is not required. |
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. For background information about DNS record mapping, see the Microsoft cloud services documentation page Configuring a custom domain name for an Azure cloud service.
- When you configure the tenant's Universal Broker with a custom FQDN
-
☐ Create a public DNS record that maps your custom FQDN to the VMware-provided brokering FQDN in your Universal Broker configuration. See Configure Universal Broker. - When the pod has an external Unified Access Gateway
-
☐ Create a public DNS record for external end-user access that matches the FQDN on the external gateway configuration. This DNS record points that FQDN to the Microsoft Azure external load balancer in the pod's external Unified Access Gateway configuration. For background information about DNS record mapping, see the Microsoft documentation page Configuring a custom domain name for an Azure cloud service.
- When the pod has an internal Unified Access Gateway
-
☐ Create an internal DNS record for internal end-user access that matches the FQDN on the internal gateway configuration. This DNS record paints that FQDN to the Microsoft Azure internal load balancer in the pod's internal Unified Access Gateway configuration.
Horizon Cloud Golden Images, Desktops, and Farms
Your Microsoft Azure subscription must accommodate the following requirements depending on the types of golden images, VDI desktops, and RDS farms you want to provision from the deployed pod.
Also, please note the following support matrix for use of Microsoft Azure VM models Generation 1 VM, Generation 2 VM, with respect to guest operating systems Windows 10 and Windows 11.
Azure VM Model | Windows 10 | Windows 11 |
---|---|---|
Generation 1 VM | Supported | Unsupported |
Generation 2 VM | Unsupported | Supported |
☐ | Base for the golden image — one or more of the supported Microsoft Azure VM configurations.
When using the console's 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 its internal settings and the specific operating system (OS). The system uses the models as indicated for both single-pod images and multi-pod images. |
☐ | 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 configurations 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 configurations not compatible with Horizon Cloud RDS farm operations. This requirement also applies to a VM running Microsoft Windows 10 Enterprise multi-session or Windows 11 Enterprise multi-session when that VM is used with Horizon Cloud. As described in the Microsoft Windows Enterprise multi-session FAQ in the Microsoft Azure Virtual Desktop documentation, Microsoft Windows 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 Enterprise multi-session. For production environments, VMware scale testing recommends using models that have a minimum of 2 CPUs or larger. |
Image Management Service (IMS) Requirements
Starting with the July 2021 release, when your Horizon Cloud pods are all running manifest 2632 or later and your tenant has Universal Broker enabled, the Horizon Image Management Service features are available to use with those pods. Use of the multi-pod image features provided by the service has additional requirements. For full details of the system requirements for use of those features, see the Microsoft Azure section of Horizon Image Management Service System Requirements. An outline of the additional requirements on the pod's subscription and that subscription's Horizon Cloud app registration and its service principal when using multi-pod images are outlined in the following table.
☐ | The subscriptions used by those pods that are participating in multi-pod images must be within a single Microsoft Azure Active Directory (AAD) tenant. |
☐ | The Horizon Cloud app registration's service principal used by those pods that are participating in multi-pod images must meet one of the following requirements:
Because the pods are likely to be in different subscriptions, the read-access requirement enables each participating pod's subscription to have line of sight to the other participating pods' subscriptions. This line of sight is needed for the service to use the features of Azure Shared Image Gallery for creating the multi-pod images. |
☐ | Any custom roles that are used by the participating pods' service principals must include the following permissions related to use of Azure Shared Image Gallery.
|
Licensing for the Microsoft Windows Operating Systems
The items are related to the Microsoft Windows operating systems in your imported VMs, golden 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.
☐ | Licensing for one or more of the following types: Microsoft Windows 7 Enterprise, Microsoft Windows 10, Microsoft Windows 11 (single-session, VDI client types) |
☐ | Licensing for Microsoft Windows 10 Enterprise multi-session or Microsoft Windows 11 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 |
Horizon Infrastructure Monitoring Requirements
If your Horizon Cloud tenant is enabled to use Horizon Infrastructure Monitoring , you can use the Horizon Universal Console to activate that feature on your choice of pods. When you choose to activate that feature on a pod, the system automatically builds a virtual appliance into the same Microsoft Azure subscription where that pod resides, and configures that appliance to collect the infrastructure data. Before you can activate this monitoring feature, your tenant must be onboarded to VMware Cloud Services. See Onboard Your Horizon Cloud Tenant to VMware Cloud Services and Horizon Infrastructure Monitoring and the Pods in Your Horizon Cloud Environment.
Horizon Infrastructure Monitoring is currently unsupported for use with pods where proxy is configured. The scenario of using a proxy with this feature's Horizon Edge Virtual Appliance has not been qualified.
☐ | Onboard your tenant to VMware Cloud Services. |
☐ | For each pod on which you will activate the Horizon Infrastructure Monitoring feature, the pod's Microsoft Azure subscription must accommodate these additional requirements.
|
Reference Architecture
Use the architecture diagrams below for reference.

