Before you log in to the Horizon Universal Console and run the pod deployment wizard for the first time, you must perform these preparatory tasks. This pod deployment wizard deploys the pod-manager-based type of pod.

Remember: This wizard deploys the pod-manager-based type of pod into Microsoft Azure. The console currently does not provide a deployment wizard to automate a Horizon pod in Azure VMware Solution (AVS), which uses the Horizon Connection Server technology.
  1. Fulfill the prerequisites described in the prerequisites checklist, especially:
    • Ensure your Microsoft Azure account and subscription encompasses the pod's required number and sizes of virtual machines, including the optional Unified Access Gateway configurations if you plan to deploy those. See Microsoft Azure Virtual Machine Requirements for a Horizon Cloud Pod in Microsoft Azure.

      If you plan to deploy the pod with an external gateway configuration that uses its own subscription, separate from the pod's subscription, ensure that other subscription encompasses the external gateway's required number and sizes of virtual machines. For this use case, that separate subscription will need its own VNet, because VNets do not span subscriptions. Also, this subscription must be in the same region as the pod's subscription because the supported VNet topology is connecting VNets within the same Microsoft Azure region.

    • As described in that the prerequisites checklist:
      • Ensure that your subscription does not restrict use of Azure StorageV2 account type.
      • If you are not planning to specify custom resource tags in the pod deployment wizard, ensure that your subscription does not restrict creation of untagged resource groups or require specific tags on its resource groups.
      • Ensure that your subscription does not have Azure Policies on it that would block, deny, or restrict creation of the pod's components in that subscription.
      Caution: The pod deployment process will fail early on if your subscription does not match those preceding items, because the first step of creating the temporary jump box's resource group and deploying the jump box will fail to complete. Therefore, if your pod deployment process times out after two hours, first check if your subscription has Azure Policies in place that would block, deny, or restrict creation of resource groups based on particular criteria.
    • Ensure a virtual network (VNet) exists in the region in which you are going to deploy the pod and that virtual network meets the requirements for a Horizon Cloud pod. If you do not have an existing VNet, create one that meets the requirements. See Configure the Required Virtual Network in Microsoft Azure.

      If you plan to deploy the pod with an external gateway configuration that uses its own VNet, separate from the pod's VNet — or that uses its own subscription separate from the pod's subscription, ensure that VNet exists in the same region as the pod's VNet, and that it meets the documented Horizon Cloud VNet requirements. For this use case, those two VNets must be peered.

      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 VM types that you want to use and which are supported in this Horizon Cloud release. See the Microsoft documentation at for details.
    • If you want to manually create the subnets for the pod on your VNet in advance of deploying the pod, ensure that the required number of subnets is created on the VNet, that their address spaces meet the documented Horizon Cloud VNet requirements, and that they are empty of resources. In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure.
      Caution: These subnets you create on your VNet for a pod deployment must be empty. You can create the subnets prior to deploying the pod, but do not put any resources on those subnets or otherwise use any of the IP addresses. If an IP address is already in use on the subnets, the pod might fail to deploy.

      If you do not want to create the subnets in advance, the pod deployment process will create them using the CIDR information you enter into the on-screen wizard.

    • Ensure that virtual network is configured to point to a valid Domain Name Services (DNS) server that is resolving external names. See Configure the DNS Server Settings Needed by the VNet Topology You Will Use for Your Horizon Cloud Pods in Microsoft Azure.
      Important: The pod deployment process requires external and internal name resolution. If the VNet points to a DNS server that cannot resolve external names, the deployment process will fail.
    • If you plan to deploy the pod with an external gateway configuration into an existing resource group that you create in a subscription separate from the pod's subscription — instead of having the deployer auto-create that resource group — ensure that resource group exists in that subscription before you start the pod deployment wizard. Decide whether to set the permissions that Horizon Cloud needs at the resource-group level or at the subscription level. See Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions.
    • Ensure you have an Active Directory setup that is supported for use with this release, your virtual network can reach it, and the DNS server can resolve its name. See Active Directory Domain Configurations.
  2. Create the required number of service principals, according to your planned deployment options. If you are deploying the pod's external gateway configuration into its own subscription, then you need a service principal for that subscription as well as for the subscription used for the pod itself. For detailed steps, see Create the Required Service Principal Needed by the Horizon Cloud Pod Deployer by Creating an Application Registration.
    Important: Each service principal that you configure for Horizon Cloud's use must be assigned an appropriate role in that service principal's associated subscription. The role to a service principal must allow the actions required by Horizon Cloud to operate on the Horizon Cloud managed resources in that service principal's associated Microsoft Azure subscription. The service principal for the pod's subscription needs a role that allows for actions to successfully deploy the pod, to operate on the pod and the pod-managed resources to fulfill the administrator workflows initiated using the administrative console, and to maintain the pod over time. When using a separate subscription for the pod's external Unified Access Gateway configuration, the service principal for that subscription needs a role that allows for actions to successfully deploy the resources needed for that gateway configuration, to operate on those Horizon Cloud-managed resources to fulfill the administrator workflows, and to maintain those gateway-related resources over time.

    As described in Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions, the service principal must be granted access using one of the following methods:

    • At the subscription level, assign the Contributor role. The Contributor role is one of the Microsoft Azure built-in roles. The Contributor role is described in Built-in roles for Azure resources in the Microsoft Azure documentation.
    • At the subscription level, assign a custom role that you have set up to provide the service principal with the minimum set of permitted actions that Horizon Cloud needs for deployment of the pod-related resources and for ongoing administrator-initiated workflows and pod maintenance operations.
    • When using a separate subscription for the external Unified Access Gateway configuration and deploying into an existing resource group, an valid combination is to grant access to the service principal to access that resource group and associated VNet using a role that provides narrow-scope permissions plus grant access for the service principal to access the subscription using the built-in Reader role.

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

  3. Verify that the resource providers that Horizon Cloud requires are all showing Registered status, as described in Resource Providers That Horizon Cloud Requires to Be in Registered Status in the Microsoft Azure Subscription.
  4. From the Microsoft Azure portal, for the pod's subscription and the subscription for its external gateway (if using that deployment option), get the values for the Microsoft Azure subscription ID, application ID, application authentication key, and Microsoft Azure AD Directory ID from the Microsoft Azure portal. These resources are used by Horizon Cloud to perform its operations in your Microsoft Azure subscription. See Subscription-Related Information for the Horizon Cloud Pod Deployment Wizard.
  5. If you are deploying the pod with a Unified Access Gateway configuration, obtain the signed TLS/SSL server certificate that can allow your end users' clients to trust connections to the desktops and remote applications. This certificate should match your FQDN that your end users will use in their clients and be signed by a trusted Certificate Authority (CA). Also, all certificates in the certificate chain must have valid time frames, including any intermediate certificates. If any certificate in the chain is expired, unexpected failures can occur later in the pod onboarding process.

    Unified Access Gateway presents your CA-signed certificate, so that the end users' clients can trust the connections. To support trusted access from the Internet, you deploy an external Unified Access Gateway configuration for the pod. To support trusted access within your corporate network, you use an internal Unified Access Gateway configuration. Both configuration types can be deployed during the initial pod deployment process or post-pod deployment using the Edit Pod workflow.

    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
  6. If your signed SSL server certificate that you will use with the Unified Access Gateway configuration is not in PEM format or is not a single PEM file containing the full entire certificate chain with the private key, convert the certificate information to the required PEM format. See the steps in Convert a Certificate File to the PEM Format Required for Pod Deployment.
  7. If you are not already registered for access to Horizon Cloud, verify that one of these two items is in place:
    • Obtain a My VMware account and register Horizon Cloud access with that account.
    • If your group or organization used the VMware Cloud Services Engagement Platform to register for Horizon Cloud or they registered for use of Horizon Cloud using VMware Cloud services or Workspace ONE, you would have received an invitation email with an activation link when they invited you to join their VMware Cloud services org space in, as described in the VMware Cloud services documentation topic Add Users to Your Organization. If you received such an email, complete the email's instructions before trying to access Horizon Cloud.

After you have completed those preparatory tasks, use one of these two ways to access the Horizon Cloud environment:

  • Enter My VMware credentials at, when that specific account is registered for Horizon Cloud.
  • Take the single sign-on with VMware Cloud Services path from, when Horizon Cloud is registered for your use through your group's org as described in the preceding paragraph.

After logging in, you'll see the Add Cloud Capacity area on the screen and can click Manage > Add Pod to start the pod deployment wizard. Complete the wizard by entering the required information in each screen. For detailed steps, see Using the Horizon Universal Console to Perform an Automated Deployment of a Pod into Microsoft Azure.

Note: Login authentication into the cloud-based console relies on authenticating account credentials either with the My VMware account system or VMware Cloud Services system. If those systems are experiencing a system outage and cannot take authentication requests, you will not be able to log in to the console during that time period. If you encounter issues logging in to the console's first login screen, check the Horizon Cloud System Status page at to see the latest system status. On that page, you can also subscribe to receive updates.