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.

This checklist is primarily for Horizon Cloud customer accounts that have never had a pod deployed from or cloud-connected to their tenant environment prior to the November 2021 service release date. Such environments might be referred to as clean-slate environments or greenfield environments. New pod deployments that happen after the cloud plane binaries and new pod manifest versions are pushed into the cloud plane on the service release date will deploy using the new pod manifest version. The requirements for a successful pod deployment are primarily determined by the pod manifest version. The cloud plane binaries that are in the production cloud plane might also determine requirements for a successful deployment.

Some of the sections listed below need decisions prior to deploying the core pod itself, while some are about optional items or those that can be decided after pod deployment.

For core pod deployment Can be done after core pod deployment
  • Control plane tenant account
  • Microsoft Azure subscription items
  • Networking
  • Ports and protocols
  • Optional Unified Access Gateway (in pod deployment)
  • Active Directory
  • Optional Unified Access Gateway (added post-deployment)
  • Universal Broker
  • DNS records
  • Golden images, desktop, farms capacities
  • Microsoft Windows operating system licenses
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 StorageV2 account type. Ensure that your Microsoft Azure Policies do not restrict or deny the creation of content requiring the Azure StorageV2 account type.
  • As part of the pod and gateway deployment processes, unless you specify custom resource tags in the deployment wizard, 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. As of the October 8, 2020 cloud plane refresh, the deployment wizard has a feature in which you can specify custom resource tags that you want applied to the deployer-created resource groups. If you do not specify custom resource tags and your Microsoft Azure subscription has any type of resource tag requirement, pod deployment will fail if 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. 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. 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

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.

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 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 you to use the Microsoft Azure portal during the deployment preparation steps.
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.)
Pod
  • Transient Pod Deployment Engine, also known as the Jump Box — 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
  • When your pod is ready to use, your capacity in Microsoft Azure cloud will have to also accommodate the imported VMs, golden images, virtual desktops, RDSH farms, and App Volumes app-capture VMs that you create in that pod. See the Horizon Cloud Base Images, Desktops, and Farms section below.
  • When your tenant account is enabled to use the Horizon Infrastructure Monitoring feature and you are planning to enable that feature on the pod after the pod is deployed, your capacity will have to also accommodate at that time the deployment of the Horizon Edge Virtual Appliance. See the Horizon Infrastructure Monitoring Requirements section below.
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.
External Unified Access Gateway in the pod's same VNet
2 x Standard_A4_v2 or 2 x Standard_F8s_v2
External Unified Access Gateway in its own VNet
  • 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 or 2 x Standard_F8s_v2.
Internal Unified Access Gateway
2 x Standard_A4_v2 or 2 x Standard_F8s_v2

If your subscription's region does not provide for the Standard_F8s_v2 VM sizes, the pod deployer wizard will not display that choice in the selector in the Specify Gateways wizard step.

Service principal and authentication key created for each subscription. See 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.
Important: The role must be assigned directly to the service principal used for Horizon Cloud. The use of a group-based assignment of a role to the service principal — in which the role is assigned to a group and the service principal is a member in that group — is unsupported.
Required resource providers registered in each Microsoft Azure subscription. See Resource Providers That Horizon Cloud Requires to Be in Registered Status in the Microsoft Azure Subscription.
Microsoft Azure subscription ID, directory ID, application ID and key identified.
Optional. If you will be deploying the 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 update 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 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.
  • Management subnet — /27 minimum
  • VM subnet - Primary (tenant) — /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.
Note: For pods deployed new at manifest 2298.0 or later, after the pod is deployed, you can edit the pod to add additional 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.
  • 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. In this use case, the back end subnet's purpose is similar to the purpose of the VM subnet (Primary) described in the preceding table row.
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 for a Horizon Cloud Pod in Microsoft and Related Service Features and Horizon Cloud Pod - Ports and Protocols Requirements - Manifests 1600 or Later.
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.

Ports and Protocols Requirements

Specific ports and protocols are required for onboarding pods and ongoing operations of your Horizon Cloud environment. See Horizon Cloud Pod - Ports and Protocols Requirements - Manifests 1600 or Later.

Unified Access Gateway Requirements

The pod deployment wizard mandates specific items below when you select to have a Unified Access Gateway configuration on the pod. 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.

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 to a RADIUS authentication server, including:
  • DNS Addresses for Unified Access Gateway to resolve the name of that authentication server
  • Routes for Unified Access Gateway to resolve network routing to that authentication server
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:
  • 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 Horizon pods that are cloud-connected to the same customer account using the Horizon Cloud Connector.
Domain Bind Account
Active Directory domain bind account (a standard user with read access) that has the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >

The account must have the following permissions:

  • List Contents
  • Read All Properties
  • Read Permissions
  • Read tokenGroupsGlobalAndUniversal (implied by Read All Properties)

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

  • 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.
  • Generally speaking, the domain bind accounts should be granted the default out-of-the-box read-access-related permissions typically granted to Authenticated Users in a Microsoft Active Directory deployment. However, if your organization's AD administrators have chosen to lock down read-access-related permissions for regular users, you must request those AD administrators preserve the Authenticated Users standard defaults for the domain bind accounts you will use for Horizon Cloud.

Reference: Service Accounts That Horizon Cloud Requires for Its Operations

Auxiliary Domain Bind Account
Must be separate from the main domain bind account. The UI will prevent re-using the same account in both fields.

Active Directory domain bind account (a standard user with read access) that has the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >

The account must have the following permissions:

  • List Contents
  • Read All Properties
  • Read Permissions
  • Read tokenGroupsGlobalAndUniversal (implied by Read All Properties)

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

  • 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.
  • Generally speaking, the domain bind accounts should be granted the default out-of-the-box read-access-related permissions typically granted to Authenticated Users in a Microsoft Active Directory deployment. However, if your organization's AD administrators have chosen to lock down read-access-related permissions for regular users, you must request those AD administrators preserve the Authenticated Users standard defaults for the domain bind accounts you will use for Horizon Cloud.

Reference: 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 the virtual computers to the domain. Typically a new account that you create for this express purpose. (A domain join user account)

The account must have the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >

The use of white spaces in the account's user name is currently unsupported.

You should also set the account password to Never Expire to ensure continued ability for Horizon Cloud to perform the Sysprep operations and join the virtual computers to the domain.

This account requires the following Active Directory permissions: Read All Properties, Reset Password, Create Computer Objects, Delete Computer Objects, Write All Properties. 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.

Note: As of pod manifest 2474.0, the required permissions for the domain join account are reduced from the previous set used for manifests prior to 2474 and now include Write All Properties on Descendent Computer objects. Pods running prior manifests still require the previous set of permissions. See Service Accounts That Horizon Cloud Requires for Its Operations for details.

Regarding the target Organizational Unit (OU) that you plan to use for farms and VDI desktop assignments, this account also requires the Active Directory permission named Write All Properties on all descendant objects of that target Organizational Unit (OU).

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 Prevent Accidental Deletion attribute which applies a Deny to the Delete All Child Objects permission for the newly created OU and all descendant objects. As a result, if you explicitly assigned the Delete Computer Objects permission to the domain join account, in the case of a newly created OU, Active Directory might have applied an override to that explicitly assigned Delete Computer Objects permission. Because clearing the Prevent Accidental Deletion flag might not automatically clear the Deny that Active Directory applied to the Delete All Child Objects permission, in the case of a newly added OU, you might have to verify and manually clear the Deny permission set for Delete All Child Objects in the OU and all child OUs before using the domain join account in the Horizon Cloud console.

Optional Auxiliary Domain Join Account
Active Directory domain join account which can be used by the system to perform Sysprep operations and join the virtual computers to the domain. Typically a new account that you create for this express purpose. (A domain join user account)

The account must have the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >

The use of white spaces in the account's user name is currently unsupported.

You should also set the account password to Never Expire to ensure continued ability for Horizon Cloud to perform the Sysprep operations and join the virtual computers to the domain.

This account requires the following Active Directory permissions: Read All Properties, Reset Password, Create Computer Objects, Delete Computer Objects, Write All Properties. 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.

Note: As of pod manifest 2474.0, the required permissions for the domain join account are reduced from the previous set used for manifests prior to 2474 and now include Write All Properties on Descendent Computer objects. Pods running prior manifests still require the previous set of permissions. See Service Accounts That Horizon Cloud Requires for Its Operations for details.

Regarding the target Organizational Unit (OU) that you plan to use for farms and VDI desktop assignments, this account also requires the Active Directory permission named Write All Properties on all descendant objects of that target Organizational Unit (OU).

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 Prevent Accidental Deletion attribute which applies a Deny to the Delete All Child Objects permission for the newly created OU and all descendant objects. As a result, if you explicitly assigned the Delete Computer Objects permission to the domain join account, in the case of a newly created OU, Active Directory might have applied an override to that explicitly assigned Delete Computer Objects permission. Because clearing the Prevent Accidental Deletion flag might not automatically clear the Deny that Active Directory applied to the Delete All Child Objects permission, in the case of a newly added OU, you might have to verify and manually clear the Deny permission set for Delete All Child Objects in the OU and all child OUs before using the domain join account in the Horizon Cloud console.

Active Directory groups
  • Horizon Cloud Administrators — Active Directory security group for Horizon Cloud administrators. Contains the Horizon Cloud administrative users. This group is granted the Super Administrator 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.

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 Prevent Accidental Deletion attribute which applies a Deny to the Delete All Child Objects permission for the newly created OU and all descendant objects. As a result, if you explicitly assigned the Delete Computer Objects permission to the domain join account, in the case of a newly created OU, Active Directory might have applied an override to that explicitly assigned Delete Computer Objects permission. Because clearing the Prevent Accidental Deletion flag might not automatically clear the Deny that Active Directory applied to the Delete All Child Objects permission, in the case of a newly added OU, you might have to verify and manually clear the Deny permission set for Delete All Child Objects in the OU and all child OUs before using the domain join account in the Horizon Cloud console.

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 DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features and Horizon Cloud Pod - Ports and Protocols Requirements - Manifests 1600 or Later.
Depending on the types of end-user connections you want to provide for:
  • For end-user connections from the Internet and launching their virtual desktops and apps, a pod must have an external Unified Access Gateway configured.
  • If all of your end-user connections will be always from your internal network, no Unified Access Gateway is required on the pod — except when you want Universal Broker to enforce two-factor authentication with those internal end-user connections.
Optional. When you want Universal Broker to enforce two-factor authentication, pods must have an external Unified Access Gateway configured for two-factor authentication to a RADIUS authentication server. Universal Broker passes the authentication request to Unified Access Gateway, which communicates with the RADIUS server, and then relays the response back to Universal Broker. That external Unified Access Gateway configuration requires the following items:
  • 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
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

Note: If you deployed the pod with the external and internal gateway configurations having the same FQDN, then after pod deployment, configure Split DNS (Split Domain Name System) to resolve the gateway address either to the external gateway or internal gateway depending on the origin network of the end-user client's DNS query.
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.

Note: When your account is enabled to use the App Volumes features and you use the console's Capture action to add App Volumes applications to your inventory, the system generates a desktop assignment of two desktop VMs to support that capturing workflow. Your capacity will have to also accommodate creating those desktops while you are performing the capturing workflow. You can delete that desktop assignment when you are finished capturing applications for your environment.
Base for the golden image — one or more of the supported Microsoft Azure VM configurations.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6

When using the Images page'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 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.

Note: Starting with the July 2021 release, when your Horizon Cloud pods are all running manifest 2632 or later and your tenant environment has Universal Broker enabled, the Horizon Image Management Service features for multi-pod images are available for creating golden images for single-session VDI desktops. Running the New Image workflow from the Multi-Pod Images page will create a VM of Standard_D2_v2 by default. When the toggle for GPU is enabled, running the New Image workflow from the Multi-Pod Images page will create a VM of Standard_NV6 by default.
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 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 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 subscription and 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.
Service principal used by those pods that are participating in multi-pod images must meet one of the following requirements:
  • Same service principal used across all those participating pods and subscriptions.
  • Each service principal must have read access to every Microsoft Azure subscription used by those participating pods.

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.

The custom roles used by the participating pods' service principals must include the following permissions related to use of Azure Shared Image Gallery.
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*

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.

Tip: For information about Microsoft Azure Virtual Desktop licensing for Windows 10 Enterprise multi-session and Windows 7 Enterprise, see the Microsoft Azure documentation topic Azure 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

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.

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.
  • Horizon Edge Virtual Appliance — 1 x Standard_D4_v3

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, Three NICs on the External Gateway VMs, Two NICs on the Internal Gateway VMs, 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, with Three NICS, 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.