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 in that subscription and peer the two VNets. Because a single VNet does not span subscriptions, when you deploy an external gateway into its own subscription, that deployment also requires the external gateway to use a VNet that is separate from and peered with the pod's VNet.
Important: Use this page solely when you have access to a first-gen tenant environment in the first-gen control plane. As described in KB-92424, the first-gen control plane has reached end of availability (EOA). See that article for details.
CAUTION:
The subnets you manually create on your VNet in advance for the pod deployment must remain empty. Do not reuse existing subnets that already have items that are using IP addresses on those subnets. If an IP address is already in use on the subnets, issues such as the pod failing to deploy and other downstream IP-conflict issues have a high likelihood of occurring. Do not put any resources on these subnets or otherwise use any of the IP addresses. This caution notice includes pods deployed from Horizon Cloud — do not reuse subnets on which you already have a deployed pod.
| Into which VNet are you deploying the external gateway? | Subnet creation | Subnets needed |
|---|---|---|
| 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 First-Gen Tenants - Create the Required Subnets. 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:
|
| 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 subnets in the pod deployment wizard. Create the subnets in advance as described in First-Gen Tenants - Create the Required Subnets. 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 is intended for use 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:
|
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 Commercial (standard global regions)
- Microsoft Azure China
- Microsoft Azure US Government
Log in to the portal using the URL appropriate for your account.
Procedure
-
In the Microsoft Azure portal, navigate to the Virtual Networks pane by using the portal's search bar to search for
virtual networksand selecting the corresponding virtual networks result. -
In the Virtual Networks pane, start the VNet creation wizard by clicking Create.
-
In the wizard, specify the following information in the on-screen wizard steps.
Option Description Subscription Select the same subscription that you are planning to use when you deploy the pod. Resource Group You can either select an existing resource group or have a new one created when the virtual network is created. Name Specify a name for the VNet. Region Select the same Microsoft Azure region into which you are planning to deploy the pod. Address space Specify the VNet's address space. 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 First-Gen Tenants - Create the Required Subnets. 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.
-
Proceed to the review step and then 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 First-Gen Tenants - In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure and First-Gen Tenants - 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 First-Gen Tenants - 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 First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names and First-Gen Tenants - Horizon Cloud Pod - Ports and Protocols Requirements.
Important: The pod manager VMs 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 gateway connector VM having outbound Internet access. If you require proxy-based outbound Internet access, you must specify the proxy server information as you complete the fields in the pod deployment wizard.
Was this page helpful?