If you are using a peered VNet, a best practice is to create the required subnets in advance of deploying the pod, to ensure that you have accounted for the address spaces your subnets need in the VNet prior to running the deployment wizard. Even when your VNet is not peered, instead of having the pod deployment process create the required subnets, you can create them in advance on your VNet.

Important: Starting with the September 2019 release's pod manifest version, both for pods newly deployed at that manifest version or later and for pods upgraded to that version or later versions, the pod's management subnet must also support network communication with the pod's Microsoft Azure Database for PostgreSQL service resource. Before deploying a new pod or upgrading an existing pod, the pod management subnet that you create must have the Microsoft.Sql service listed as a service endpoint. The deployment or upgrade process will check if the subnet has the endpoint and not proceed if the endpoint is not enabled on the subnet. For details, see When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure.

When you create the subnets in advance, you must ensure their address ranges, in classless interdomain routing (CIDR) notation, adhere to the pod deployment wizard's minimum requirements:

  • For the management subnet, a CIDR of /27 or more is required. This subnet is for IP addresses used by the VMs involved in management activities of the pod itself.
  • For the desktop tenant subnet, a CIDR of /27 or more is required. For production environments, a CIDR of /24 to /21 is recommended (256 addresses to 2048 addresses). This subnet is for IP addresses used for the RDSH server VMs and VDI desktop VMs on that subnet. The pod's manager VM uses an IP address from this subnet. If the pod will have an internal Unified Access Gateway configuration, those Unified Access Gateway VMs also use IP addresses from this subnet. If the pod will have an external gateway configuration that is deployed using the pod's VNet, that external gateway's Unified Access Gateway VMs also use IP addresses from this subnet.
    Important: The VMs for your VDI desktops, the RDS-capable images, and every RDSH VM in the pod's farms consume these IP addresses. Because this desktop subnet cannot be extended after the pod is deployed, ensure you set this range large enough to accommodate the number of desktops you anticipate you will want this pod to provide. For example, if you anticipate this pod should provide over 1000 desktops in the future, ensure this range provides for more than that number of IP addresses.
  • If you are going to have an external Unified Access Gateway configuration deployed into the pod's VNet, you need a DMZ subnet, with a CIDR of /28 or more. This subnet is for IP addresses used by the Unified Access Gateway VMs' NICs to communicate with this external gateway configuration's load balancer. If you want to keep the management and DMZ subnet ranges co-located, you could 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.
  • If you are going to have the external Unified Access Gateway configuration deployed into its own VNet, separate from the pod's, that VNet needs three subnets:
    • A management subnet, of a CIDR of /27 more is required. This subnet is for IP addresses used by the VMs involved in management activities of the external gateway overall, such as the gateway connector VM.
    • A back-end subnet, of a CIDR of /27 more is required. This subnet is for IP addresses used by the Unified Access Gateway VMs' NICs to communicate over the peered VNet with the pod's VNet.
    • A front-end (DMZ) subnet, of a CIDR of /28 or more. This subnet is for IP addresses used by the Unified Access Gateway VMs' NICs to communicate with the external gateway's load balancer. If you want to keep the management and front-end subnet ranges co-located in this VNet, you could 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 front-end subnet would be 192.168.8.32/27.
Important: For each CIDR, ensure 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.

Prerequisites

Ensure your Microsoft region has the VNet that you plan to use for your pod. See Configure the Required Virtual Network in Microsoft Azure.

Ensure the address ranges you plan to use for the subnets do not overlap. The pod deployment wizard will display an error if the subnet ranges overlap.

Procedure

  1. In the Microsoft Azure portal, navigate to the VNet for which you need to create the described subnets.
  2. Click Subnets.
  3. Click + Subnet.
    The Add subnet screen appears.
  4. Provide the information for the required fields.
    Option Description
    Name Specify a name for the subnet.
    Address range (CIDR block) Type a CIDR for the subnet.
  5. If this subnet is going to be the management subnet, in the Service endpoints section, select the Microsoft.Sql service.
  6. Click OK.
    The subnet is added to the VNet.
  7. Repeat steps 3 through 5 to add the remaining required subnets.
  8. If you are going to deploy the external gateway in its own VNet, repeat the steps for that VNet's subnets.

Results

Caution: The subnets you manually create on your VNet in advance for the pod deployment must remain empty. Do not put any resources on these 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.

What to do next

For any management subnets you created, ensure the Microsoft.Sql service is enabled as a service endpoint. See When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure. This service must be enabled on the pod's management subnet, and if you are deploying the external gateway in its own VNet, the service must be enabled on that gateway's management subnet also.