VMware Horizon Cloud Service on Microsoft Azure Requirements Checklist For New Pod Deployments Starting From the Service Release on October 20, 2022

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
Control plane tenant account Microsoft Azure subscription items Networking Ports and protocols Optional Unified Access Gateway items	Active Directory Optional Unified Access Gateway (added post-deployment) Universal Broker DNS records Golden images, desktop, farms capacities Microsoft Windows operating system licenses

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 Contributor role is assigned at the pod's subscription level. 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 Contributor role for that gateway subscription's service principal. 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.) Pod Pod Managers — 2 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 2 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. In a special circumstance where you open a support request and VMware Support determines the way to service that request is to temporarily deploy a support-related jump box VM, your capacity will have to accommodate the deployment of a Standard_F2 model VM at that time.

☐

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 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.

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. 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. 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 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: 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, applied to the Computers OU, or to the OU that you will enter into the console's Domain Join UI. Read All Properties - this object only Create Computer Objects - this object and all descendant objects Delete Computer Objects - this object and all descendant objects Write All Properties - Descendant Computer objects Reset Password - Descendant Computer objects 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, applied to the Computers OU, or to the OU that you will enter into the console's Domain Join UI. Read All Properties - this object only Create Computer Objects - this object and all descendant objects Delete Computer Objects - this object and all descendant objects Write All Properties - Descendant Computer objects Reset Password - Descendant Computer objects 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. 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 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.

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: 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 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: 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.

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. Standard_DS2_v2 Standard_NV12s_v3 (for the service's automated Import VM from Marketplace wizard or manual import, and NVIDIA GRID graphics driver), Standard_NV8as_v4 (for the manual import method and AMD graphics driver) Standard_D4s_v3 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. Import VM from Marketplace wizard creates: Non-GPU, non-Windows 11, a Standard_DS2_v2 VM Non-GPU using Windows 11, a Standard_D4s_v3 VM GPU-capable, a Standard_NV12s_v3 VM
☐	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: 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.
☐	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. 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 specific to Windows 11 Enterprise multi-session, 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, 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.

Note: Horizon Infrastructure Monitoring is currently unsupported for use with Horizon Cloud on Microsoft Azure pods in Azure China regions because access to the required packages.cloud.google.com site is disallowed from Azure China regions at this time.

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. 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 where the Pod has 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

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