Before you run the pod deployment wizard, verify that your environment satisfies these prerequisites. You must have the following items so that you can provide the requested values in the pod deployment wizard and proceed through the wizard.

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 two examples of items that must be allowed, 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 and must verify that your Microsoft Azure Policies allow resourceType of Microsoft.MarketplaceOrdering/*. The pod deployment process relies on accepting Azure Marketplace offers from VMware's vmware-inc publisherID. For information about Azure Policies, see the Azure Policy documentation. For information about how the service uses the Microsoft.MarketplaceOrdering/* resource type, see When Your IT or Security Organization Has Restrictions on Use of Azure Marketplace Offers or Marketplace Ordering.
  • The pod deployer requires that your Azure storage account allow for the deployer to create the Azure StorageV2 account type in the pod's resource group in the subscription. This storage account is used for the pod's App Volumes features. During the pod deployment process, ensure that your Microsoft Azure Policies do not restrict or deny the creation of content requiring the Azure StorageV2 account type.
  • All cloud-connected pods must have line-of-sight to the same set of Active Directory domains at the time you deploy those pods.

Prerequisites for All Deployments

  • Verify that all of the preparatory tasks are completed, as described in Preparing to Deploy a Horizon Cloud Pod on Microsoft Azure.
  • Verify that you have the subscription information, as described in Subscription-Related Information for the Horizon Cloud Pod Deployment Wizard.
  • Verify that you have an existing virtual network in your Microsoft Azure subscription, and in the region in which you are deploying the pod, as described in Configure the Required Virtual Network in Microsoft Azure.
    Important: Not all Microsoft Azure regions support GPU-enabled virtual machines. If you want to use the pod for GPU-capable desktops or remote applications, ensure that the Microsoft Azure region you select for the pod provides for those NV-series, NVv4-series, and NCv2-series VM types that you want to use and which are supported in this Horizon Cloud release. See the Microsoft documentation at https://azure.microsoft.com/en-us/regions/services/ for details.
  • Verify that your VNet is configured to point to a DNS that can resolve external addresses. The pod deployer must be able to reach external addresses in the Horizon Cloud control plane to securely download the pod software into your Microsoft Azure environment.
  • Verify that the pod deployer's DNS, ports, and protocols requirements are met, as described in First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names and Horizon Cloud Pod - Ports and Protocols Requirements.
  • If you require use of a proxy for outbound Internet access, verify you have the networking information for your proxy configuration and the authentication credentials it requires, if any. The pod deployment process requires outbound Internet access.
    Important: Editing or updating of the proxy settings on a pod after the pod is deployed in Microsoft Azure is currently unsupported. Also, adding a proxy configuration to a deployed pod that was deployed without proxy settings is currently unsupported.
  • Verify that you have the information for at least one NTP server that you want the pod manager instances and Unified Access Gateway instances to use for time synchronization. The NTP server can be a public NTP server or your own NTP server that you set up for this purpose. The NTP server you specify must be reachable from the virtual networks in which you plan to deploy the pod manager instances and Unified Access Gateway instances. When you plan to use an NTP server using its domain name instead of a numeric IP address, also ensure that the DNS configured for the virtual network can resolve the NTP server's name.
    Note: Using the same NTP server for the pod manager instances, Unified Access Gateway instances, and your Active Directory servers is a best practice. Time skews can result when these instances use different NTP servers. Such time skews can later result in failures when the gateway attempts to authenticate end user sessions to their desktops and applications.
  • If you do not want the deployer to automatically create the subnets it needs, verify that the required subnets have been created in advance and exist on the VNet. For the steps to create the required subnets in advance, see In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure and When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure.
    Caution: The subnets you manually create on your VNet in advance for the pod deployment must remain empty. Do not reuse existing subnets that already have items that are using IP addresses on those subnets. If an IP address is already in use on the subnets, issues such as the pod failing to deploy and other downstream IP-conflict issues have a high likelihood of occurring. Do not put any resources on these subnets or otherwise use any of the IP addresses. This caution notice includes pods deployed from Horizon Cloud — do not reuse subnets on which you already have a deployed pod.
  • If you are going to have the deployer create the required subnets, verify that you know the address ranges you are going to enter into the wizard for the management subnet, desktop subnet, and DMZ subnet. The DMZ subnet is required when you want the external Unified Access Gateway configuration. Also verify that those ranges do not overlap. You enter the address ranges using CIDR notation (classless inter-domain routing notation). The wizard will display an error if the entered subnet ranges overlap. For the management subnet range, a CIDR of at least /27 is required. For the DMZ subnet range, a CIDR of at least /28 is required. If you want to keep the management and DMZ subnet ranges co-located, you can specify the DMZ subnet range similar to the management subnet with an IP specified. For example, if the management subnet is 192.168.8.0/27, a matching DMZ subnet would be 192.168.8.32/27.
    Important: The CIDRs you enter in the wizard's fields must be defined so that each combination of prefix and bit mask results in an IP address range having the prefix as the starting IP address. Microsoft Azure requires that the CIDR prefix be the start of the range. For example, a correct CIDR of 192.168.182.48/28 would result in an IP range of 192.168.182.48 to 192.168.182.63, and the prefix is the same as the starting IP address (192.168.182.48). However, an incorrect CIDR of 192.168.182.60/28 would result in an IP range of 192.168.182.48 to 192.168.182.63, where the starting IP address is not the same as the prefix of 192.168.182.60. Ensure that your CIDRs result in IP address ranges where the starting IP address matches the CIDR prefix.
  • If you are going to have the deployer create the required subnets, verify that subnets with those address ranges do not already exist on the VNet. In this scenario, the deployer itself will automatically create the subnets using the address ranges you provide in the wizard. If the wizard detects subnets with those ranges already exist, the wizard will display an error about overlapping addresses and will not proceed further. If your VNet is peered, also verify that the CIDR address spaces that you plan to enter in the wizard are already contained in the VNet's address space.

Prerequisites for the Unified Access Gateway Configurations

If you are planning to have the pod use a Unified Access Gateway configuration, you must provide:

  • The fully qualified domain name (FQDN) which your end users will use to access the service. If you are planning to use the same FQDN for both the external and internal gateway configurations, after the pod is deployed, you must configure the incoming end-user client traffic to route to the appropriate gateway load balancer. The goal is to set up the routing so that client traffic from the Internet is routed to the external gateway's Microsoft Azure Public Load Balancer and client traffic from your intranet is routed to the internal gateway's Microsoft Azure Internal Load Balancer. In this scenario where both gateways will have the same FQDN, you 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.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
  • A signed SSL server certificate (in PEM format) based on that FQDN. The Unified Access Gateway capabilities require SSL for client connections, as described in the Unified Access Gateway product documentation. The certificate must be signed by a trusted Certificate Authority (CA). The single PEM file must contain the full entire certificate chain with the private key. For example, the single PEM file must contain the SSL server certificate, any necessary intermediate CA certificates, the root CA certificate, and private key. OpenSSL is a tool you can use to create the PEM file.
    Important: All certificates in the certificate chain must have valid time frames. The Unified Access Gateway VMs require that all of the certificates in the chain, including any intermediate certificates, have valid time frames. If any certificate in the chain is expired, unexpected failures can occur later as the certificate is uploaded to the Unified Access Gateway configuration.
  • If you are deploying with an external Unified Access Gateway configuration, you must specify a DMZ (demilitarized zone) subnet. You can provide for this DMZ subnet by one of two ways:
    • Creating the DMZ subnet in advance on the VNet. With this method, you also have to create the management and desktop tenant subnets in advance. See the steps in In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure.
    • Having the deployer automatically create the DMZ subnet during deployment. With this method, you must have the address range you are going to enter into the wizard for the DMZ subnet and verify that the range does not overlap with the ranges for the management and desktop tenant subnets. You enter the address ranges using CIDR notation (classless inter-domain routing notation). The wizard will display an error if the entered subnet ranges overlap. For the DMZ subnet range, a CIDR of at least /28 is required. If you want to keep the management and DMZ subnet ranges co-located, you can specify the DMZ subnet range the same as the management subnet with an IP specified. For example, if the management subnet is 192.168.8.0/27, a matching DMZ subnet would be 192.168.8.32/27. Also see the important note in Prerequisites for All Deployments about ensuring the IP address range has a combination of prefix and bit mask that results in the range having the prefix as the starting IP address.
  • If you are deploying with an external Unified Access Gateway configuration and you want to prevent having a public IP address for the configuration's load balancer, you must specify an IP address that you have mapped in your DNS settings to the FQDN which your end users will use for PCoIP connections in their Horizon clients.

For more information about the PEM file considerations required by Unified Access Gateway, see Convert a Certificate File to the PEM Format Required for Pod Deployment.

Prerequisites When Deploying With an External Unified Access Gateway Configuration Using its Own VNet or Subscription Separate from the Pod's VNet or Subscription

Note: Deploying an external gateway using its own VNet will deploy a gateway connector VM. In Ports and Protocols Requirements for a Horizon Cloud Pod, the section that describes the gateway connector VM's ports and protocols also has a description of this gateway connector VM, which states this gateway connector VM has a name that contains a part like vmw-hcs-ID, where ID is the gateway's deployer ID, and a node part.

Along with the above prerequisites when deploying with a Unified Access Gateway configuration, these prerequisites are specific to the use case of deploying the external gateway in its own VNet or own subscription. Using its own subscription is a special case of using its own VNet, because the separate subscription must have its own VNet, because VNets are scoped to a subscription.

Prerequisites When Deploying With a Two-Factor Authentication Configuration

If you are planning to use the two-factor authentication capability, or use it with an on-premises two-factor authentication server, verify that you have the following information from your authentication server's configuration, so that you can provide it in the Add Pod wizard's required fields.

Obtain the following listed information, according to the type you have.

RADIUS

If you are configuring settings for both a primary and auxiliary RADIUS server, obtain the information for each of them.

  • IP address or DNS name of the authentication server
  • The shared secret that is used for encryption and decryption in the authentication server's protocol messages
  • Authentication port numbers, typically 1812/UDP for RADIUS.
  • Authentication protocol type. The authentication types include PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, version 1 and 2).
    Note: Check your RADIUS vendor's documentation for the authentication protocol that your RADIUS vendor recommends and follow their indicated protocol type. The pod's capability to support two-factor authentication with RADIUS is provided by the Unified Access Gateway instances, and Unified Access Gateway supports PAP, CHAP, MSCHAP1, and MSCHAP2. PAP is generally less secure than MSCHAP2. PAP is also a simpler protocol than MSCHAP2. As a result, even though most RADIUS vendors are compatible with the simpler PAP protocol, some RADIUS vendors are not as compatible with the more secure MSCHAP2.
RSA SecurID
Note: The RSA SecurID type is supported with Horizon Cloud on Microsoft Azure deployments that are running manifest 3139.x or later. The UI option to specify the RSA SecurID type in the Add Pod and Edit Pod wizards will become visible to select in the wizards starting in mid-March 2022.
  • Access key from the RSA SecurID authentication manager server.
  • RSA SecurID communication port number. Typically 5555, as set in the RSA Authentication Manager system settings for RSA SecurID Authentication API.
  • Host name of the RSA SecurID authentication manager server.
  • IP address of that RSA SecurID authentication manager server.
  • If the RSA SecurID authentication manager server or its load balancer server has a self-signed certificate, you will need the CA certificate to provide in the Add Pod wizard. The certificate should be in PEM format (file types .cer or .cert or .pem)