After your first-gen Horizon Cloud tenant's pod fleet has at least one pod and the Active Directory domain registration steps are completed, then the Capacity page is available with menu options for adding more pods to your pod fleet. This specific workflow applies to Horizon Cloud pods. Such pods are based on the Horizon Cloud pod-manager technology, which runs solely in a Microsoft Azure subscription and does not require a VMware SDDC.

Note: As indicated in KB-92424, the New action is available only when you have an approved exception from the first-gen control plane's end of availability (EOA).

For an overview about adding pods to your fleet of various pod types, see First-Gen Tenants - About the First-Gen Horizon Universal Console Capacity Page and Adding Pods to Your Horizon Cloud Pod Fleet.

Important: The workflow here is inapplicable for a Horizon pod on Azure VMware Solution (AVS). This specific workflow applies to Horizon Cloud pods. Horizon Cloud pods are based on the Horizon Cloud pod-manager technology, while a Horizon pod is based on the Connection Server technology.
Caution: The IP addresses mentioned in these steps are examples. You should use the address ranges that meet your organization's needs. For each step that mentions an IP address range, substitute ones that are applicable for your organization.

The wizard has multiple steps. After specifying the information in a step, click Next to move to the next step.

Prerequisites

Before you start the pod deployment wizard, verify that you have the required items. The items you need to provide in the wizard vary according to the pod configuration options you want. See the list in First-Gen Tenants - Prerequisites for Running the First-Gen Pod Deployment Wizard.

In addition to the items required by the configuration you want for an additional pod, your first cloud-connected pod must be completely deployed and the Active Directory domain-bind and domain-join steps completed before you can deploy additional pods. All cloud-connected pods within your customer account record share the same Active Directory information, and each cloud-connected pod must have line-of-sight to all of the cloud-configured Active Directory domains. For more information, see First-Gen Tenants - Perform the First Required Active Directory Domain Registration for Your Horizon Cloud Control Plane Tenant.

If your tenant is configured with Universal Broker and the broker settings have two-factor authentication enabled, you must have an external Unified Access Gateway with two-factor authentication settings and using the same two-factor authentication type.

Procedure

  1. In the console, start the pod deployment wizard by navigating to Settings > Capacity, clicking New > Microsoft Azure.
    The wizard opens to its first step.
    Screenshot of the wizard's Subscription step.

  2. On the wizard's first step, specify the subscription to use for this pod by selecting the name of a previously entered subscription or entering new subscription information.
    If you select an existing subscription, the step is populated with that subscription's information that was previously entered into the system.
    Important: If you are entering new information, you must ensure the subscription information you enter meets the subscription requirements described in the prerequisites, especially that the service principal has the role permissions it needs.
    Option Description
    Apply Subscription Select the name of a previously entered subscription or select Add New to enter new subscription information.
    Subscription Name When providing new subscription information, enter a friendly name so you can identify this subscription from other previously entered subscriptions.

    The name must start with a letter and contain only letters, dashes, and numbers.

    Environment Select the cloud environment associated with your subscription, for example:
    • Azure - Commercial, for the standard global Microsoft Azure cloud regions
    • Azure - China, for the Microsoft Azure in China cloud
    • Azure - US Government, for the Microsoft Azure US Government cloud
    Subscription ID Enter your cloud capacity subscription ID (in UUID form). This subscription ID must be valid for the environment you selected. For Microsoft Azure, you can obtain this UUID from your Microsoft Azure portal's Subscriptions area.
    Directory ID Enter your Microsoft Azure AD Directory ID (in UUID form). For Microsoft Azure, you can obtain this UUID from your Microsoft Azure Active Directory properties in the Microsoft Azure portal.
    Application ID Enter the application ID (in UUID form) associated with the service principal you created in the Microsoft Azure portal. Creating an application registration and its associated service principal in your Microsoft Azure Active Directory is a prerequisite.
    Application Key Enter the key value for the service principal's authentication key that you created in the Microsoft Azure portal. Creating this key is a prerequisite.
    Use a Different Subscription for External Gateway Enable this toggle when you want to deploy an external Unified Access Gateway configuration into its own subscription, separate from the pod's subscription. Using separate subscriptions for the external gateway gives your organization the flexibility to assign separate teams control over those subscriptions, depending on their area of expertise. It allows for more granular access control for which people in your organization can access the pod's assets in its subscription's resource groups and which people can access the gateway's assets.

    When this toggle is turned on, the fields for entering the gateway's subscription information are displayed. Specify the information in those fields as you did for the pod's subscription.

  3. Proceed to the next step by clicking Next.
    When you click Next, in the case where you added a new subscription, the system verifies the validity of all of the specified values and whether they are appropriately related to each other, such as:

    If you see an error message about checking values, at least one of the values is invalid either by not existing in your subscription or not having a valid relationship with another of the values. For example, if you specified a Directory ID that is in your subscription but you specified an Application ID value that is in a different directory, the error message will display.

    More than one value might be invalid if that error message appears. If you see that error message, verify the subscription-related information that you collected and the configuration of the service principal.

  4. In this wizard step, specify details such as the name of the pod, as well as networking information.
    Option Description
    Site The wizard displays Site when your tenant environment is configured to use Universal Broker for your pods in Microsoft Azure and you are deploying additional pods. You associate the pod with a site. You can either select an existing site or with the Default-Site or specify the name of a new one. The Capacity page's Sites tab lists the sites that are already configured in your environment.
    Pod Name Enter a friendly name for this pod. This name is used in the administrative console to identify this pod from your other pods.
    Note: This name must be unique among your existing pods in your Horizon Cloud customer account. The name cannot match the name of one of the pods listed in the Capacity page.
    Location Select an existing city name or click Add to specify a new city.

    The system groups your pods according to city name, and depicts them on the console's Dashboard page's Horizon Global Footprint map.

    When you click Add, start typing the name of a city. The system automatically displays world city names in its backend geography lookup table that match your entered characters, and you can choose a city from that list.

    Note: You must select a city from the system's autocomplete list. Currently, due to a known issue, the location names are not localized.
    Microsoft Azure Region Select the physical geographic Microsoft Azure region into which you want the pod to be deployed. The available regions are determined by the previously selected Microsoft Azure environment.

    Consider choosing the region based on its proximity to the end users you intend to serve with this pod. Nearer proximity would provide lower latency.

    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.
    Description Optional: Enter a description for this pod.
    Azure Resource Tags

    Optional: Create custom tags to be applied to Azure resource groups. Azure resource tags are only applied to the resource groups, and are not inherited by the resources in the groups.

    To create the first tag, enter information in the Name and Value fields. To create an additional tag, click + and then enter information in the Name and Value fields that appear below the existing ones.

    • You can create a maximum of 10 tags.
    • The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
    • Tag names cannot contain the following characters:

      < > % & \ ? /

    • Tag names cannot contain these case-insensitive strings:

      ‘azure’, ‘windows’, ‘microsoft’

    • Tag names and tag values can only contain ASCII characters. Blank spaces and characters outside the standard 128-character ASCII set (also known as high ASCII or extended ASCII characters) are not allowed.
    Virtual Network Select a virtual network from the list.

    Only virtual networks (VNets) that exist in the region selected in the Microsoft Azure Region field are shown here. You must have already created the VNet you want to use in that region in your Microsoft Azure subscription.

    Use Existing Subnet Enable this toggle if you have created subnets in advance to meet the pod's subnet requirements. When this toggle is set to Yes, the wizard's fields for specifying subnets change to drop-down selection menus.
    Important: The wizard does not support using an existing subnet for one of the required subnets and also entering CIDR addresses for the other required subnets. When this toggle is set to Yes, you must select from existing subnets for all the pod's required subnets.
    Management Subnet

    Management Subnet (CIDR)

    When Use Existing Subnet is enabled, this menu lists the subnets available on the VNet selected for Virtual Network. Select the existing subnet that you want to use for the pod's management subnet.
    Important:
    • Select a subnet that has the Microsoft.SQL service configured as a service endpoint for that subnet. This service endpoint supports the required communication between the pod manager VMs and the pod's Azure Postgres database over the management subnet.

      Select an empty subnet, one that has no other resources attached to it. If the subnet is not empty, unexpected results might occur during the deployment process or pod operations.

    When Use Existing Subnet is switched off, enter a subnet address range (in CIDR notation) for the deployer to create a subnet to which the pod and Unified Access Gateway instances will get connected, such as 192.168.8.0/27. For the management subnet, a CIDR of at least /27 is required.

    Caution: When you do not select the wizard option to use existing subnets, the subnet must not already exist in your Microsoft Azure environment. If it already exists, you will get an error when you try to proceed to the next wizard step.
    VM Subnet - Primary

    VM Subnet (CIDR) - Primary

    This field relates to the subnet used for those VMs that the pod provisions to provide your end-user desktops and applications. Such VMs include the golden image VMs, the farms' RDSH-capable VMs, and the VDI desktop VMs.

    When Use Existing Subnet is enabled, this menu lists the subnets available on the VNet selected for Virtual Network. Select the existing subnet that you want used for those VMs.

    Important: Select an empty subnet, one that has no other resources attached to it. If the subnet is not empty, unexpected results might occur during the deployment process or pod operations.

    When Use Existing Subnet is switched off, enter a subnet address range (in CIDR notation) for the deployer to create this subnet as the pod is deployed, such as 192.168.12.0/22. For the desktop subnet, a CIDR of at least /27 is required, and a CIDR of /22 is recommended.

    Important: Ensure the range that you enter is large enough to allow for accommodating the number of VMs you anticipate you will want this pod to provision to provide your farms' RDSH-capable VMs and the VDI desktop VMs for your end users. This desktop subnet cannot be extended after the pod is deployed.
    Caution: When you do not select the wizard option to use existing subnets, the subnet must not already exist in your Microsoft Azure environment. If it already exists, you will get an error when you try to proceed to the next wizard step.
    NTP Servers Enter the list of NTP servers you want to use for time synchronization, separated by commas.

    An NTP server you enter here can be a public NTP server or your own NTP server that you set up for providing time synchronization. The NTP servers you specify here must be reachable from the virtual network you selected in the Virtual Network field for the pod to use. In this field, you can specify each NTP server either by its numeric IP address or its domain name. When you provide a domain name in this field instead of a numeric IP address, you must ensure that the DNS configured for your virtual network can resolve the specified name.

    Examples of public NTP server domain names are time.windows.com, us.pool.ntp.org, time.google.com.

    Use Proxy If you require a proxy for outbound Internet connectivity, enable this toggle and complete the associated displayed fields.

    The pod deployer requires outbound access to the Internet to securely download software into the Microsoft Azure cloud environment and connect back to the Horizon Cloud cloud control plane. To enable the pod to use your proxy configuration, you must provide the following information after enabling the toggle.

    • Proxy (required): Type the hostname or IP address for your proxy server.
    • Port (required): Type the port number that is specified in your proxy server configuration.

    If your proxy server configuration requires a user name and password for authentication, provide those credentials also.

    The required proxy-related fields filled in
  5. Proceed to the next step by clicking Next.

    The following screenshot is an example of the next step when it is initially displayed. Some controls are displayed only when you selected at the first wizard step to use a different subscription for the external Unified Access Gateway gateway configuration.


    Screenshot depicting the wizard's Gateway Settings step when it is first displayed.

  6. Specify the information for the gateway configuration you want, and optionally a two-factor authentication configuration on that gateway. If your tenant is configured with Universal Broker that already has two-factor authentication configured in the Universal Broker settings, you must select an external Unified Access Gateway and specify the same two-factor authentication type on the gateway.
    Note: In this step, you can choose whether to have the gateway resource groups inherit the same custom tags that you specified for the pod or specify different ones. Both gateway types will use the same set of specified tags.
  7. Click Validate & Proceed.
    When you click Validate & Proceed, the system verifies the validity and appropriateness of your specified values, such as:
    • Are the subnets valid and non-overlapping with other networks in the selected region within your subscription.
    • Are there enough virtual machine (VM) and cores in your subscription's quota to build out the pod.
    • Is the certificate in the correct PEM format.

    If you see an error message about overlapping networks, verify whether you have existing subnets using the same values already in your subscription.

    If everything validates OK, the summary page displays.

  8. Review the summarized information and click Submit
    The system starts deploying the pod into your Microsoft Azure environment.

Results

Deploying the pod can take up to an hour. Until the pod is successfully deployed, a progress icon is displayed for that pod. You might need to refresh the screen in your browser to see the updating progress.

Important: When deploying additional pods in Microsoft Azure China cloud, the process can take longer than an hour to complete. The process is subject to geographic network issues that can cause slow download speeds as the binaries are downloaded from the cloud control plane.

What to do next

If you specified two-factor authentication for the pod's gateway configurations, you must complete the following tasks.
  • If the pod's external gateway has two-factor authentication configured and the two-factor authentication server is not reachable within the same VNet topology into which the gateway's Unified Access Gateway instances are deployed, configure that two-factor authentication server to allow communication from the IP address of the external gateway's load balancer.

    In this scenario where the two-factor authentication server is not reachable within the same VNet topology as the gateway deployment, the Unified Access Gateway instances attempt contact with that server using that load balancer address. To allow that communication traffic, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client or a registered agent in your two-factor authentication server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

  • If your two-factor authentication server is reachable within the same VNet topology, configure the two-factor authentication server to allow communication from the appropriate NICs that were created for the deployment's Unified Access Gateway instances in Microsoft Azure.

    Your network administrator determines the two-factor authentication server's network visibility to the Azure VNet topology and its subnets used for the deployment. The two-factor authentication server must allow communication from the IP addresses of the Unified Access Gateway instances' NICs that correspond to the subnet for which your network administrator has given network visibility to the two-factor authentication server.

    The gateway's resource group in Microsoft Azure has four NICs that correspond to that subnet, two that are currently active for the two Unified Access Gateway instances and two that are idle and will become the active ones after the pod and its gateways go through an update.

    To support communication traffic between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients or as registered agents in that server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

If you specified having a Unified Access Gateway configuration, ensure you set up the appropriate CNAME records in your DNS server according to the type of configuration you specified.
  • For an external Unified Access Gateway configuration, map the FQDN that you entered in the deployment wizard to the pod's Microsoft Azure public load balancer's auto-generated FQDN.
  • For an internal Unified Access Gateway configuration, map the FQDN that you entered in the deployment wizard to the pod's Microsoft Azure internal load balancer's private IP address.

See How to Obtain the Horizon Cloud Pod Gateway's Load Balancer Information to Map in Your DNS Server for the steps to locate the load balancer information in the pod's details page.