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 March 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 March 2021 quarterly 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 requirements listed below are the ones needed for pod deployment itself. Some requirements are those needed for the key tasks that are performed after pod deployment to get a productive tenant environment, able to provide pod-provisioned desktops and applications to your end users.

Requirements for pod deployment itself
Requirements for a productive environment after pod deployment
Important: Before launching the pod deployment wizard and starting to deploy your pod, in addition to the requirements below, you must be aware of the following key points:
  • Starting with the July 2020 service release, in brand new environments, new pods are required to deploy with at least one gateway configuration. If your customer account was created prior to the July 2020 release, but you have not yet deployed your first pod, deployment of that first pod will require configuring at least one gateway configuration at the time of pod deployment.
  • Successful pod deployment requires that none of the Microsoft Azure Policies that you or your IT team have set in your Microsoft Azure environment block, deny, or restrict creation of the pod's components. Also you must verify that your Microsoft Azure Policies Built-in Policy definitions do not block, deny, or restrict creation of the pod's components. As an example, you and your IT team must verify that none of your Microsoft Azure Policies block, deny, or restrict creation of components on Azure storage account. For information about Azure Policies, see the Azure Policy documentation.
  • The pod deployer requires that your Azure storage account allow for the deployer to use the Azure StorageV1 and StorageV2 account types. Ensure that your Microsoft Azure Policies do not restrict or deny the creation of content requiring the Azure StorageV1 and StorageV2 account types.
  • As part of the pod and gateway deployment processes, 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

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 additional information, see Get Started with Role-Based Access Control in the Azure portal in the Microsoft documentation.
Minimum Microsoft Azure capacity available for Horizon Cloud infrastructure in addition to the expected desktop and app workload. Note that as long as this capacity is made available, Horizon Cloud will automatically deploy these VMs and no manual installation is required.
  • Pod Deployment Engine, also known as the Jump Box (transient) — 1 x Standard_F2
  • Pod/Pod Manager with High Availability enabled — 2 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 2 x Standard_D3_v2)
  • Pod/Pod Manager without High Availability enabled — 1 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 1 x Standard_D3_v2)
  • Microsoft Azure Database for PostgreSQL Service — Generation 5, Memory Optimized, 2 vCores, 10 GB Storage
  • External Unified Access Gateway (optional, unless no internal gateway is specified) — 2 x Standard_A4_v2 or 2 x Standard_F8s_v2
  • Internal Unified Access Gateway (optional, unless no external gateway is specified) — 2 x Standard_A4_v2 or 2 x Standard_F8s_v2
Note:
  • Starting with the July 2020 service release, in clean-slate environments, new pods are required to deploy with at least one gateway configuration. If your customer account was created prior to the July 2020 release, but you have not yet deployed your first pod, deployment of that first pod will require configuring at least one gateway configuration at the time of pod deployment. As a result, your minimum Microsoft Azure capacity available must accommodate the VMs for one of the gateway configurations, as described in the preceding list.
  • If your subscription's region does not provide for the Standard_F8s_v2 VM sizes, the pod deployer wizard does not display that choice in the selector in the Specify Gateways wizard step.
  • After pod deployment is finished, your capacity in Microsoft Azure cloud will have to also accommodate the imported VMs, golden images, virtual desktops, and RDSH farms that you create in that pod. When your account is enabled to use the App Volumes features and you use the console's applications capturing workflow, your capacity will have to also accommodate the VMs in the system-generated desktop assignment used for that capturing process. 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.

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

  • External Unified Access Gateway Deployment Engine, also known as the Gateway Jump Box (transient) — 1 x Standard_F2
  • External Gateway Connector — 1 x Standard_A1_v2
  • External Unified Access Gateway — 2 x Standard_A4_v2 or 2 x Standard_F8s_v2.
Service principal and authentication key created for each subscription. For additional details, see Use a portal to create an Azure Active Directory application and service principal that can access resources. See also Create the Required Service Principal Needed by the Horizon Cloud Pod Deployer by Creating an Application Registration.
Each service principal must be assigned the appropriate role that allows for the actions that Horizon Cloud must perform in the subscription. This role can be the Contributor role or a custom role with the required permitted actions at the subscription level. When you are deploying the external gateway configuration in an existing resource group in a separate subscription, more granular permissions can be set for that subscription's service principal. For additional details about the required role actions, see Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions.
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 step 8.b in Create the Required Service Principal Needed by the Horizon Cloud Pod Deployer by Creating an Application Registration.
Microsoft Azure subscription ID, directory ID, application ID and key identified.
If you will be deploying the 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 desired Microsoft Azure region with applicable address space to cover required subnets. For additional details, see Azure Virtual Network.

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 the Administration Guide.
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 Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.
Proxy server information if required for outbound internet access on the VNet that is used during deployment and ongoing operations of the Horizon Cloud environment (optional)
Microsoft Azure VPN/Express Route configured (optional)
FQDN for external user access, internal user access, or both (Required when deploying a pod with Unified Access Gateway).
Note: As of the December 15, 2020 cloud plane refresh, having different FQDNs for the pod's external gateway and internal gateway configurations is supported. Prior to December 15, 2020, the system enforced having the same FQDN for a pod of manifest 2298 and later. Now it is your choice if you want the pod's gateways to use different FQDNs or the same FQDN. If you want to use the same FQDN on both gateways, after pod deployment, you would 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. Then the same FQDN used in the end-user client can route to the external gateway when the client is on the Internet and route to the internal gateway when the client is on your internal network.
Certificate or certificates for Unified Access Gateway in PEM format matching the FQDN (required when deploying a pod with Unified Access Gateway).
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.
Two-factor authentication to an on-premises RADIUS authentication server (optional)
  • DNS Addresses for Unified Access Gateway to resolve the name of the authentication server
  • Routes for Unified Access Gateway to resolve network routing to the authentication server
Note: After the pod is deployed, when you plan to set the environment to use Universal Broker to broker the desktops to your end users, some additional configuration is needed when you want to skip two-factor authentication for end users on your internal network. The pod's internal Unified Access Gateway instances route the connection requests to virtual desktops and apps for such internal end users. When you will have an internal gateway configuration on the pod, you plan to set the environment to use Universal Broker, and you want two-factor authentication for your external end users but skip two-factor authentication for your internal end users, then after the pod is deployed, you will want to enter IP ranges for the Universal Broker to use to identify the internal end users from the external end users for the purposes of skipping the two-factor authentication. For details, see the documentation topic Setting Up a Brokering Method and End-User Assignments in Your Horizon Cloud Tenant Environment and its subtopics.

Ports and Protocols Requirements

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

Pod Deployment Workflow

The preceding items are the ones needed before you start the pod deployment wizard. After you ensure you have the preceding items, follow the pod deployment steps through step 4 in High-Level Workflow for Adding a Horizon Pod on Microsoft Azure as Your First Pod to Your Horizon Cloud Tenant Environment to deploy your pod.

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

Active Directory Requirements

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

One of the following supported Active Directory configurations:
  • On-premises Active Directory Server connected via VPN/Express Route
  • Active Directory Server located in Microsoft Azure
  • Microsoft Azure Active Directory Domain Services
Supported Microsoft Windows Active Directory Domain Services (AD DS) domain functional levels:
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
All cloud-connected pods in the same Horizon Cloud customer account must have line-of-sight to the same set of Active Directory domains at the time you deploy those pods. This requirement applies not only to additional pods that you subsequently deploy into Microsoft Azure after the first pod, but also to any Horizon pods that are cloud-connected to the same customer account using the Horizon Cloud Connector. You can see the checklist for such Horizon pods at VMware Horizon Pods with Horizon Cloud - Requirements Checklist - Updated as Appropriate for Connecting Pods Starting from the March 2021 Service Release.
Important: Read Service Accounts That Horizon Cloud Requires for Its Operations for the key characteristics this account must have.

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)
    Note:
    • If you are familiar with the VMware Horizon on-premises offering, the above permissions are the same set that are required for the Horizon on-premises offering's secondary credential accounts, stated in this Horizon on-premises documentation topic.
    • 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.

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

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

Important: Read Service Accounts That Horizon Cloud Requires for Its Operations for the key characteristics this account must have.

Auxiliary domain bind account — cannot use the same account as above

  • Active Directory domain bind account (a standard user with read access) that has the 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)
    Note:
    • If you are familiar with the VMware Horizon on-premises offering, the above permissions are the same set that are required for the Horizon on-premises offering's secondary credential accounts, stated in this Horizon on-premises documentation topic.
    • 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.

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

Important: Read Service Accounts That Horizon Cloud Requires for Its Operations for the key characteristics this account must have.

Domain join account

  • Active Directory domain join account which can be used by the system to perform Sysprep operations and join computers to the domain, typically a new account (domain join user account)
  • The account must have the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >
  • Set account password to Never Expire
  • This account requires the following Active Directory permissions: Read All Properties, Reset Password, Create Computer Objects, Delete Computer Objects, Write All Properties
    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.
  • This account also requires the Active Directory permission named Write All Properties on all descendant objects of the target Organizational Unit (OU) that you plan to use for farms and VDI desktop assignments.
  • For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations
Note:
  • The use of white spaces in the account's user name is currently not supported. If name contains a white space, unexpected results will occur in the system operations that rely on that account.
  • 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.
  • Prior to manifest 1600.0, this account required the permissions of the system's Super Administrator role. If your tenant environment has any Horizon Cloud pods in Microsoft Azure running manifests older than manifest 1600.0, the domain join account must be in the described Horizon Cloud Administrators group. The system uses this domain join account with all of your tenant's Horizon Cloud pods in Microsoft Azure. When your tenant has existing pods of manifests older than 1600.0, the domain join account must meet this requirement. For details, see Service Accounts That Horizon Cloud Requires for Its Operations.
Important: Read Service Accounts That Horizon Cloud Requires for Its Operations for the key characteristics this account must have.

Auxiliary domain join account (Optional, cannot use the same account as above)

  • Active Directory domain join account which can be used by the system to perform Sysprep operations and join computers to the domain, typically a new account (domain join user account)
  • The account must have the sAMAccountName attribute. The sAMAccountName attribute must be 20 characters or less and cannot contain any of the following characters: "/ \ [ ] : ; | = , + * ? < >
  • Set account password to Never Expire
  • This account requires the following Active Directory permissions: Read All Properties, Reset Password, Create Computer Objects, Delete Computer Objects, Write All Properties
    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.
  • This account also requires the Active Directory permission named Write All Properties on the all descendant objects of the target Organizational Unit (OU) that you plan to use for farms and VDI virtual desktops.
  • For additional details and requirements, see Service Accounts That Horizon Cloud Requires for Its Operations
Note:
  • The use of white spaces in the account's user name is currently not supported. If name contains a white space, unexpected results will occur in the system operations that rely on that account.
  • 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.
  • Prior to manifest 1600.0, this account required the permissions of the system's Super Administrator role. If your tenant environment has any Horizon Cloud pods in Microsoft Azure running manifests older than manifest 1600.0, the domain join account must be in the described Horizon Cloud Administrators group. The system uses this domain join account with all of your tenant's Horizon Cloud pods in Microsoft Azure. When your tenant has existing pods of manifests older than 1600.0, the domain join account must meet this requirement. For details, see Service Accounts That Horizon Cloud Requires for Its Operations.
Active Directory groups
  • Horizon Cloud Administrators — Active Directory security group for Horizon Cloud administrators. Contains the Horizon Cloud administrative users. 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.
Note: 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.
Note: 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 Requirements

Starting with the July 2020 release, when your Horizon Cloud tenant environment is a brand new account starting from that date and you have just completed deploying your first pod into Microsoft Azure, you can choose to use Universal Broker as the brokering method for your environment. When you choose to configure Universal Broker for your environment, the following items are needed. 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 Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.
Optional: Configure your pod's gateways for two-factor authentication to a RADIUS authentication server, if you want Universal Broker to use two-factor authentication for the pod.
  • 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 (optional)

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.

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.
If you configured 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.
Public DNS record created for external end-user access that matches the FQDN on the external gateway configuration, pointing to the Microsoft Azure external load balancer in the pod's external Unified Access Gateway configuration (required when the deployed pod has that configuration). For additional details, see Configuring a custom domain name for an Azure cloud service.
Internal DNS record created for internal end-user access that matches the FQDN on the internal gateway configuration, pointing to the Microsoft Azure internal load balancer in the pod's internal Unified Access Gateway configuration (required when the deployed pod has that configuration).
Internal DNS record created when you plan to choose single-pod brokering for your deployment and you will be integrating the deployment with VMware Workspace ONE Access. In this scenario, this internal DNS record supports the VMware Workspace ONE Access connections to the pod, in which the VMware Workspace ONE Access Connector synchs the information about user assignments from the pod. This internal DNS record matches the FQDN in the certificate that you will upload to the pod itself and points to the pod manager's Microsoft Azure internal load balancer. Required when you want to use VMware Workspace ONE Access with a pod in an environment configured for single-pod brokering.
Note: This internal DNS record and a certificate that matches and is uploaded to the pod itself are also used in the rare, atypical use case when you would tell internal end users to directly connect to the pod, instead of telling them to connect to an internal Unified Access Gateway configuration on the pod. Such direct connections are an unusual use case. Typically an internal Unified Access Gateway is used instead.
Certificate chain (CA certificate, SSL certificate, SSL key file) that matches the above internal DNS record created for VMware Workspace ONE Access connections to the pod. For additional details, see Upload SSL Certificates to a Horizon Cloud Pod for Direct Connections. (Also required if you are using the atypical use case of having internal end users connect directly to the pod. Direct connections are a rare, unusual usage. Typically an internal Unified Access Gateway is used instead.)

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

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

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

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

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

Licensing for the Microsoft Windows Operating Systems

The items are related to the Microsoft Windows operating systems in your 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 Windows Virtual Desktop licensing for Windows 10 Enterprise multi-session and Windows 7 Enterprise, see the Microsoft Azure documentation topic Windows Virtual Desktop pricing.
Licensing for one or more of the following types: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (client types)
Licensing for Microsoft Windows 10 Enterprise multi-session
Licensing for one or more of the following types: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019
Microsoft Windows RDS Licensing Servers — for high availability, redundant licensing servers are recommended
Microsoft RDS User or Device CALs or both

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.