First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names

For success from day-0 onwards of first-generation Horizon Cloud on Microsoft Azure deployments, you must ensure the host names described in this documentation page are resolvable and reachable from the management and tenant subnets using the specific ports and protocols identified in this page.

General Introduction to this Page

Note: Use this page solely when you have a first-gen tenant environment and have a Horizon Cloud on Microsoft Azure deployment in that first-gen environment. As of August 2022, Horizon Cloud is generally available and has its own Using Horizon Cloud Guide. An indication of which environment you have, Horizon Cloud or first-gen, is the pattern that appears in the browser's URL field after you log in to your environment and see the Horizon Universal Console label. For a Horizon Cloud environment, the console's URL address contains a portion like /hcsadmin/. The first-gen console's URL has a different section (/horizonadmin/).

The reason why this page includes the phrase DNS name along with the phrase host name is because DNS is a networking standard for resolving host names for communication between those host names to occur.

A host name is a unique name assigned to a machine instance on a given network. As described in the software networking industry, systems use Domain Name System (DNS) to resolve host names to their IP addresses for communication purposes.

The pod deployment process requires that the deployed instances have network communication over the deployment's selected VNet to the host names (DNS names) described in this page.

After the pod is successfully deployed in your subscription, various day-to-day service operations require network access to specific host names, as does the pod update process for updating the pod's software when new software is made available.

This page describes the requirements. At times, this page uses the phrases DNS name and host name interchangeably.

Some Overarching Key Points

• About these required DNS names

  Deploying and running a Horizon Cloud pod requires network access to specific DNS addresses over your Microsoft Azure VNets. For the pod deployer to work, you must configure your firewalls to allow the network access to those addresses. The purpose of each DNS address is stated in the following tables.

  In addition to allowing network communication to those DNS addresses, the DNS configuration on your VNet must resolve the names as described in this article.

  When you select the option to deploy the external gateway in its own VNet separate from the pod manager's VNet, that VNet's subnet must meet the same DNS requirements as the pod manager's VNet's management subnet.

  Besides the pod deployer and its workflows, various service features require access to specific DNS addresses for those features to work end to end. Those DNS names are also provided in the following tables.

  Some of these DNS names have a regional element to them.

  As described in Tight Integration Within the Ecosystem, you can use Horizon Cloud with other products available from the broader ecosystems of Omnissa, Horizon, Workspace ONE, and third-party vendors. Those other products might have additional DNS requirements. Such additional DNS requirements are not detailed here. For such DNS requirements, see the documentation set for the specific products that you will be integrating with your pod.

• About ports and protocols after a pod is deployed, for ongoing service-related operations

  After a pod is successfully deployed, specific ports and protocols are required for ongoing Horizon Cloud operations. See First-Gen Tenants - Horizon Cloud Pod - Ports and Protocols Requirements for details.

First-Gen Tenants - Regional Control Plane Endpoint Names

Your Welcome to Horizon Service email will indicate which regional control plane instance your tenant account was created in. Due to a known issue that existed when the welcome email was sent to you, the email you received might display the system string names used for the regions instead of human-friendly names. If you see a system string name in your welcome email, you can use the following table to relate what is shown in your email with the regional control plane DNS names.

Host Names, DNS Requirements for the Overarching Pod Deployment Process, Pod Updates, Activation of Various Service Features, and Ongoing Operations

For successful end-to-end use of the service's features, you must ensure the following host names are resolvable and reachable from the management and tenant subnets using the specific ports and protocols as indicated in the following tables. Some of the service features that require the ability to reach specific host names are:

• The pod deployer that automatically deploys a pod-manager-based pod into your Microsoft Azure subscription

• The pod update feature, that updates the pod's software to a more recent software version

• The import-image process that uses the Import from Marketplace wizard

• The agent-related features, such as automated agent update (AAU)

• Universal Broker

• Most especially for pod deployment and pod updates

  You must ensure the following host names are resolvable and reachable from the management and tenant subnets using the specific ports and protocols as indicated in the following tables. The appliances used in these workflows use specific outbound ports to securely download the software that these processes need into your Microsoft Azure environment. Those DNS names are also used so that the appropriate workflow-related appliances can communicate with the cloud control plane .

  For new pod deployments, you must configure your network firewall, network security group (NSG) rules, and proxy servers such that the key deployment-related appliances have the ability to contact the DNS addresses on the ports that they require. Otherwise, the pod deployment process will fail.

• When you are using the feature to deploy the external gateway into its own VNet

  The management subnet in that VNet must meet the same DNS requirements as stated in the table below for the management subnet in the pod's VNet. The external gateway VNet's back-end subnet and DMZ subnet do not have specific DNS requirements.

• When you are deploying the pod with either an external gateway, an internal gateway, or both

  You must upload a certificate that the pod deployer will configure in those gateway configurations. If the certificate or certificates that you supply for this purpose use CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) settings that refer to specific DNS names, then you must ensure outbound Internet access on the VNet to those DNS names is resolvable and reachable. During configuration of your supplied certificate in the Unified Access Gateway gateway configuration, the Unified Access Gateway software will reach out to those DNS names to check the certificate's revocation status. If those DNS names are not reachable, pod deployment will fail during its Connecting phase. These names are highly dependent on the CA that you used to obtain the certificates, and therefore are not in the Horizon Cloud service's control.

• When you plan to use App Volumes on Azure features

  The pod deployer provisions an Azure storage account for use by the pod's App Volumes on Azure features, in the pod managers' resource group. When provisioned, Azure Cloud assigns a fully qualified domain name (FQDN) to that storage account that has the pattern *.file.core.windows.net, where * is the Azure generated name of the storage account. This FQDN must be resolvable by your DNS server so that App Volumes can access and mount the fileshares underlying that storage account and deliver the App Volumes functionality. You must ensure that your DNS server resolves that FQDN at all times for the App Volumes Manager processes that run inside the pod manager instances and for the App Volumes Agent that runs in the VDI desktops. This endpoint is a Microsoft Azure endpoint, within your Microsoft Azure cloud environment, and the connection goes direct within the Microsoft Azure cloud space.

DNS Requirements for New Pod Deployment, Pod Updates, and Service Operations that Apply on a Tenant-Wide Basis

The following table describes the DNS requirements for a new pod deployment, pod updates, and service operations that are applicable on a tenant-wide basis.

Note: This table's Proxy Traffic column indicates yes or no whether network traffic goes through the proxy when the Horizon Cloud on Microsoft Azure deployment's configuration includes a proxy. Where the Proxy Traffic column states no, network traffic to those host names indicated in the table must be allowed, even when the deployment's configuration includes a proxy.

Mandatory Horizon Cloud System Monitoring Requirement

The mandatory requirement described in this section enables the service's monitoring system to detect security events on the service-managed instances that are deployed in the management, tenant, and DMZ subnets of the Horizon Cloud on Microsoft Azure deployment.

For a Horizon Cloud on Microsoft Azure deployment, Horizon Cloud controls and manages these resources in the deployment: pod manager instances, Unified Access Gateway instances, Azure files related to App Volumes, Azure PostgreSQL Service, and, when needed for troubleshooting situations, the support-related jump box instance.

The service's management responsibility for the deployed instances requires mandatory system monitoring of those instances.

This mandatory system monitoring requires you to meet the requirements described below.

In terms of a high-level description, the deployment's instances must outbound reach the following endpoints on port 1514 (TCP and UDP) and on port 1515 (TCP and UDP).

• monitor.horizon.omnissa.com

Note: The external gateway configuration's Unified Access Gateway instances must resolve these endpoints from the DMZ network:

• monitor.horizon.omnissa.com

Important: It is necessary to be able to communicate with these endpoints without going through a proxy, if proxy traffic is configured on the Horizon Cloud on Microsoft Azure deployment. This statement means the endpoints:

• monitor.horizon.omnissa.com:1514 TCP/UDP and monitor.horizon.omnissa.com:1515 TCP/UDP

  See the text below that follows the heading 'Requirement applicable when you are using proxy or firewall for outbound communication'.

• Requirement applicable when your network has SSL inspection enabled

  When SSL inspection is enabled on the network, you must specify to exclude the host names:

  • monitor.horizon.omnissa.com

• Requirement applicable when the deployment has an internal gateway configuration

  You must establish outbound communication for the internal gateway configuration by following all of the steps and information in KB article 90145. Follow the KB article as described, including the final notes at the end of the KB article. Note: As of this writing, the KB is not yet updated with the new additional endpoint, monitor.horizon.omnissa.com, so include that also.

  Then, if you are additionally using proxy or firewall for outbound communication, you must fulfill the following requirement that is applicable when using proxy or firewall for outbound communication.

• Requirement applicable when you are using proxy or firewall for outbound communication

  When you use proxy or firewall for your outbound communication, you must allow communication on the proxy or firewall as follows:

  • Commercial environments - Allow host name monitor.horizon.omnissa.com on 1514 (TCP and UDP) and 1515 (TCP and UDP)

  • US Federal environments - Please open a case with Horizon Cloud Federal Support to request the monitoring system host name. In such environments, you must allow that aforementioned communication for these sources:

  • Management - the pod manager instances

  • DMZ - the external gateway configuration's Unified Access Gateway instances

  • Tenant - the internal gateway configuration's Unified Access Gateway instances

    Note: When the deployment has an internal gateway configuration, you must fulfill the previously described requirement that is applicable to the internal gateway configuration, the steps in KB article 90145. As of this writing, the KB is not yet updated with the new additional endpoint, monitor.horizon.omnissa.com, so include that also.

If Required for An Active Support Request, Temporary Jump Box Ports and Protocols

If you make a support request to the Horizon Cloud team and the support team determines the way to service that request is to deploy a temporary jump box VM for SSH communication with the service-managed appliances, that jump box requires the ports and protocols described here.

Permission will be requested from you for a support-related jump box deployment. The support team will inform you of any requirements, as appropriate for any support situation.

This support-related jump box VM is designed to communicate as a source to the following destinations:

• The pod's pod manager VMs' port 22 using SSH and port 22.
• The Unified Access Gateway VMs' port 9443 using HTTPS.
• The gateway connector VM's port 22 using SSH, in a deployment where the external gateway is deployed in its own VNet.

Because these VMs are assigned IP addresses dynamically, the following network rules can provide for the described communications. During the support-request activities, always seek guidance and supervision from the support team for requirements for the support-related jump box deployment.

• The management subnet CIDR as both the source and destination, with destination port 22, source port any, and protocol TCP.
• The management subnet CIDR as both the source and destination, with destination port 9443, source port any, and protocol TCP, when a Unified Access Gateway configuration is involved.