Configure the Required Virtual Network in Microsoft Azure

When deploying a pod with the external gateway using the pod’s VNet

For this configuration, you can either create subnets in advance on the VNet and specify those subnets in the pod deployment wizard, or directly type into the wizard the address spaces for the needed subnets and the pod deployer will create the subnets in the VNet.

Important:

If your existing VNet is peered, the deployer cannot automatically update the VNet’s address space. If the VNet is peered, the best practice is to create the subnets in advance as described in

If your existing VNet is peered, the deployer cannot automatically update the VNet’s address space. If the VNet is peered, the best practice is to create the subnets in advance as described in In Advance of Pod Deployment, Create the Horizon Cloud Pod’s Required Subnets on your VNet in Microsoft Azure . If you do not want to create the subnets in advance and you enter subnet CIDRs in the deployment wizard that are not contained within the VNet’s existing address space, the wizard will display an error message and you will need to specify valid subnet address spaces to proceed, or use an unpeered virtual network.

Pod deployment using this configuration requires following subnets:

• Management subnet, for IP addresses used by the VMs involved in management activities of the pod itself.
• Primary VM subnet — also known as the tenant subnet or the desktop subnet. This subnet provides IP addresses used for the RDSH server VMs and VDI desktop VMs on that subnet. When the internal

  Unified Access Gateway

  configuration is specified in the deployment wizard, the

  Unified Access Gateway

  VMs also consume 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 primary VM 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 might 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. Starting in the July 2020 release, a new feature allows you to later edit the pod and add additional VM subnets for use by your farm VMs and VDI desktop VMs. That new feature gives you the flexibility to add VM subnets over time to accommodate growth in your farms and VDI desktop assignments. Because the system will default to using this primary VM subnet unless you expressly specify those additional subnets in the definitions of your farms and VDI desktop assignments, it is a best practice to ensure the range for this primary VM subnet to be large enough to accommodate your anticipated number of farm VMs and desktops.

• DMZ subnet, for IP addresses used by the optional external

  Unified Access Gateway

  configuration.

When you have the deployer automatically create the subnets, the deployer always creates the new subnets in the corresponding VNet. In terms of the VNet’s address space, the deployer handles the subnet address spaces you enter into the wizard as follows:

• If you specify address spaces in the wizard that are not already in the VNet’s address space, the deployer automatically updates the VNet’s configuration to add those address spaces. Then it creates the new subnets in the VNet.
• If the address spaces specified in the wizard are already contained within the VNet’s existing address space, the deployer creates the new subnets in the VNet using the specified address spaces.