In the Pod Setup step of the pod deployment wizard, you specify details such as the name of the pod, as well as networking information.
Verify that you have met the prerequisites described in Prerequisites for Running the Pod Deployment Wizard.
If you are going to have the deployment process automatically create the required subnets, verify that the CIDR address ranges that you plan to specify in the wizard fields for those subnets are not already being used by existing subnets on your VNet in Microsoft Azure.
If you have created subnets in advance for use with this pod, verify that those subnets have no resources attached to them and verify that the subnet you created to use for the management subnet has the Microsoft.SQL service configured as a service endpoint for that subnet. The pod deployment wizard will validate that the Microsoft.SQL service is configured as a service endpoint on the management subnet.
- In this step of the wizard, provide details about the pod and the required networking information.
The following screenshot is an example of the step when it is initially displayed.
Option Description 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. 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 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.
High Availability This toggle determines whether the deployed pod has two pod manager VMs. In the deployed pod, one pod manager VM is the active one and the other is ready to handle failover if the active one goes offline, which provides high availability for the pod. For details about high availability and the pod, see High Availability and Your Horizon Cloud Pod in Microsoft Azure
If you switch off this toggle, the pod is deployed with a single pod manager VM. If that pod manager VM goes offline, there is no second one ready to handle the failover.Note: Even when this toggle is switched off, the pod still deploys with the pod architecture that has the memory-optimized, Gen 5, Microsoft Azure Database for PostgreSQL server and a Microsoft Azure load balancer in front of the pod manager VM. When you see this toggle displayed in the pod deployment wizard, its presence indicates that the pod deployer will deploy a pod using the pod architecture that has those items. A pod deployed with this toggle turned on will have a second pod manager VM, while a pod deployed with this toggle turned off will have a single pod manager VM.
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
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 following screenshot is an example with this step completed when having the deployment process automatically create the subnets and with High Availability enabled. In this example, a proxy was not needed to meet the outbound Internet connectivity requirement.
- Proceed to the next step by clicking Next.
- Specify details for the pod to have a Unified Access Gateway configuration by following the steps in Specify the Horizon Cloud Pod's Gateway Configuration. For the ability to have your end users access their desktops and remote applications over the Internet, an external Unified Access Gateway configuration is required.