Your Microsoft Azure environment must have an existing virtual network before you can deploy the Horizon Cloud pod into the environment. If you do not already have a virtual network (VNet) in the region into which you are deploying, you must create the virtual network. If you want to have the pod's external gateway deployed into its own VNet — separate from the pod's VNet, you must create that VNet also and then peer the two VNets. If you want to have the pod's external gateway using its own subscription, separate from the pod's, then you must create a separate VNet to use for that external gateway and peer the two VNets. Because a single VNet does not span subscriptions, choosing to deploy an external gateway into its own subscription also will require the external gateway to use a VNet that is separate from and peered with the pod's VNet.

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

This configuration relies having the following subnets:

  • Management subnet, for IP addresses used by the VMs involved in management activities of the pod itself
  • Desktop subnet, for 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 use IP addresses from this subnet.
    Important: The VMs for your VDI desktops, the RDS images, and every server in the pod's RDS 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.
  • 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 simply creates the new subnets in the VNet using the specified address spaces.
When deploying a pod with the choice to have the external gateway using its own VNet or subscription, separate from the pod's VNet or subscription
For this configuration, because there are two VNets involved and these VNets must be peered, the best practice is to create the subnets in advance on the VNet and specify those in the pod deployment wizard. 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. Even though the deployment wizard gives you the option of directly typing into the wizard the address spaces for the needed subnets to have the deployer create the subnets for you, if you specify address spaces that are not already in the VNet's address space, the deployer will not be able to add them to the VNet because it is a peered VNet.

In this case, one VNet will have the subnets for the pod and one VNet will have the subnets for the external gateway. Those two VNets must be peered. Let's refer to the pod's VNet as VNet-1 and the external gateway's VNet as VNet-2. For each of these VNets, you can either specify the address spaces for the subnets that the pod deployer will automatically create or specify subnets that you have created in advance.

In this type of deployment, the pod's VNet (VNet-1) gets a management subnet and a desktop subnet, used for the same purposes as described for when the external gateway is in the pod's own VNet. However, the pod's VNet does not get a DMZ subnet in this configuration because the DMZ subnet would be used by the external Unified Access Gateway configuration, which is in the other VNet (VNet-2) in this configuration. In this deployment configuration, the external gateway's VNet gets the following subnets:

  • Management subnet, for IP addresses used by the VMs involved in management activities of the external gateway itself (the temporary jump box, the gateway's connector VM, and the external gateway's Unified Access Gateway instances)
  • Back-end subnet used by the external gateway's Unified Access Gateway instances
  • DMZ subnet used by the external gateway's Unified Access Gateway instances

You perform these steps using the Microsoft Azure portal appropriate for your registered account. For example, there are specific portal endpoints for these Microsoft Azure clouds.

  • Microsoft Azure (standard global)
  • Microsoft Azure Germany
  • Microsoft Azure China
  • Microsoft Azure US Government

Log in to the portal using the URL appropriate for your account.

Procedure

  1. From the Microsoft Azure portal's left navigation bar, click Microsoft Azure Virtual Networks menu item in the Microsoft Azure portal's main menu (Virtual networks) and then click Add.
    The Create virtual network screen appears.
  2. Provide the information for the required fields.
    Option Description
    Name Specify a name for the VNet.
    Address space Specify the VNet's address space.
    Subscription Select the same subscription that you are planning to use when you deploy the pod.
    Resource Group You can either choose an existing resource group or have a new one created when the virtual network is created.
    Location Select the same region into which you are planning to deploy the pod.

    Subnet and Address range

    Microsoft Azure requires creating one subnet when creating a VNet. You can either retain the default values or customize the name and range. If you want to use this subnet for one of the pod's required subnets, specify the appropriate address range according to the pod deployer requirements. As an example, if you want to use this subnet for the pod's tenant subnet, ensure it has an IP address range to match the /27 minimum that the deployment wizard requires. See In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure.
    Important: If you use this subnet for one of the pod's required subnets, you cannot also use it for other resources.
    Retain the default values for the optional settings.
    Create Virtual Network screen in the Microsoft Azure portal

  3. Click Create.

Results

The virtual network (VNet) is created in your Microsoft Azure account.

What to do next

If you are manually creating the required subnets instead of having the pod deployment process create them, configure the newly created VNet with the subnets you will use for the pod. See the steps in In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure and When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure.

Configure the newly created VNet with a working DNS service and connectivity to the Active Directory service you will use with your pod. See the steps in Configure the DNS Server Settings Needed by the VNet Topology You Will Use for Your Horizon Cloud Pods in Microsoft Azure.

Ensure your VNet configuration, in terms of your firewalls and other network behavior, adheres to the pod deployment DNS, ports, and protocols requirements described in DNS Requirements for a Horizon Cloud Pod in Microsoft Azure and Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.

Important: The pod's temporary jump box VM and pod's manager VM require outbound Internet access on your Microsoft Azure VNet. If you are deploying an external gateway in its own VNet, that VNet must support the external gateway's temporary jump box and gateway connector VM having outbound Internet access. If you require proxy-based outbound Internet access, you will need to specify the proxy server information as you complete the fields in the pod deployment wizard.