The VNets that your Horizon Cloud pods are deployed into must have the ability to resolve both internal machine names and external names. During the pod deployment process, the deployer securely downloads the pod software into your Microsoft Azure environment from external addresses in the Horizon Cloud control plane. The ability to resolve internal virtual machine (VM) names is needed for the pod's Horizon Cloud Active Directory domain-join operations with the VMs that get deployed in your Microsoft Azure environment.

Important: Ultimately, the key requirement is that the pod-related VMs that need to reach specific DNS names are able to do that. That you have your VNet topology configured so that both internal machine names and external names can be resolved by the pod-related VMs that need to do that. You need to ensure that whatever VNet topology you are using in Microsoft Azure that you want to deploy the pod into will allow the pod VMs deployed onto the relevant required subnets can get that DNS name resolution. For specifics on the DNS resolution requirements, see DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features.

If you are going to use the feature to have the external gateway deployed into its own VNet separate from the pod's VNet, those VNets must be peered and you and your networking team must ensure that your peered VNets topology provides for that topology's DNS settings to meet the pod's key DNS requirements, as described in the previous paragraph. The Horizon Cloud documentation set is not covering details of such advanced VNet topologies that your networking team might have customized for your use.

In a Microsoft Azure subscription, internal network connectivity is not set up by default. For production environments, you or your networking team would typically configure the virtual network's DNS settings to point at a valid DNS server that can resolve external names as well as work in Microsoft Azure for your corporate machines. For example, you might want to deploy a Microsoft Windows Server 2016 virtual machine in that virtual network to act as the DNS server, and configure the virtual network's DNS setting to point to the IP address of that deployed DNS server.

For proof-of-concept environments, if your organization's privacy and security policies allow, you can configure the internal DNS to delegate to an external public DNS for external name resolution. Some organizations and ISPs provide public recursive name servers to use for such purposes, such as OpenDNS at or Google Public DNS at For a sample list of public recursive name servers, see the Wikipedia article Public recursive name server.


Ensure your Microsoft Azure region has the VNet topology that you plan to specify in the pod deployer wizard. See Configure the Required Virtual Network in Microsoft Azure.

Ensure that the DNS server settings that you or your networking team are going to configure for that VNet topology can reach and resolve the specific external names required for a successful pod deployment. For details, see DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features.


  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 the virtual network that you are going to use for your pod.
  2. Display the virtual network's DNS server settings by clicking DNS servers.

    In the Microsoft Azure portal, the Settings list for the virtual network

  3. Using the Custom option, add the address of the DNS server you want to use for name resolution and click Save.

What to do next

Ensure the pod deployer's access requirements for DNS, ports, and protocols are met from your VNet topology. See DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features and Horizon Cloud Pod - Ports and Protocols Requirements - Manifests 1600 or Later.