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.
About this Page
An indication of which environment you have, next-gen 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 next-gen environment, the console's URL address contains a portion like /hcsadmin/. The first-gen console's URL has a different section (/horizonadmin/).
Brief Introduction
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.
The activation of Horizon Infrastructure Monitoring on a pod will automatically instantiate the Horizon Edge Virtual Appliance in the pod manager's VNet and management subnet. The Horizon Edge Virtual Appliance has its own DNS name requirements. Therefore, before you activate Horizon Infrastructure Monitoring on a pod, ensure you meet the DNS requirements of the Horizon Edge Virtual Appliance as indicated in the following tables.
As described in Tight Integration Within the VMware Ecosystem, you can use Horizon Cloud with other products available from the broader VMware ecosystem. 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 Horizon Cloud Pod - Ports and Protocols Requirements for details.
First-Gen Tenants - Regional Control Plane DNS 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.
| Your welcome email says | Regional DNS Name |
|---|---|
USA |
cloud.horizon.vmware.com |
EU_CENTRAL_1 or Europe |
cloud-eu-central-1.horizon.vmware.com |
AP_SOUTHEAST_2 or Australia |
cloud-ap-southeast-2.horizon.vmware.com |
PROD1_NORTHCENTRALUS2_CP1 or USA-2 |
cloud-us-2.horizon.vmware.com |
PROD1_NORTHEUROPE_CP1 or Europe-2 |
cloud-eu-2.horizon.vmware.com |
PROD1_AUSTRALIAEAST_CP1 or Australia-2 |
cloud-ap-2.horizon.vmware.com |
Japan |
cloud-jp.horizon.vmware.com |
UK |
cloud-uk.horizon.vmware.com |
Europe-3 |
cloud-de.horizon.vmware.com |
For the regional DNS addresses listed in the following tables for the Horizon Edge Virtual Appliance, those addresses use the same regions as 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
- Horizon Infrastructure Monitoring and its Horizon Edge Virtual Appliance
- Features related to the Cloud Management Service (CMS)
- Most especially for pod deployment, pod updates, and when activating the Horizon Infrastructure Monitoring on a pod
-
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.
Activating Horizon Infrastructure Monitoring on a pod will instantiate the Horizon Edge Virtual Appliance into the same VNet and management subnet as that pod's pod-manager appliances. You must ensure the configuration your network firewall, NSG rules, and proxy servers allows the Horizon Edge Virtual Appliance to contact the host names on the ports that it requires. Otherwise, deployment of that appliance will fail.
Note: Horizon Infrastructure Monitoring is currently unsupported for use with Horizon Cloud on Microsoft Azure pods in Azure China regions because access to the required packages.cloud.google.com site is disallowed from Azure China regions at this time. - 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 VMware'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.
For Horizon Infrastructure Monitoring activation and Horizon Edge Virtual Appliance DNS requirements, see the section after this one. Because the Horizon Infrastructure Monitoring feature is optional and activated on a per-pod basis, its host name requirements warrant their own descriptive table.
Starting in early 2021, as a result of an upgrade to the service's regional control plane instances, the d1mes20qfad06k.cloudfront.net DNS name is no longer required for any of the regional control plane instances. All of the regional control plane instances now use the hydra-softwarelib-cdn.azureedge.net DNS name. The following table's contents is aligned with that current reality.
| Subnet Source | Destination (DNS name) | Port | Protocol | Proxy Traffic (if configured on the deployment) | Purpose |
|---|---|---|---|---|---|
| Management | One of the following names, depending on which regional control plane instance is specified in your Horizon Cloud tenant account. The regional instance is set when the account is created, as described in Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.
|
443 | TCP | Yes | Regional control plane instance
|
| Management | softwareupdate.vmware.com | 443 | TCP | Yes | VMware software package server. Used for downloading updates of the agent-related software used in the system's image-related operations. |
| Management | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | No The pod manager and Unified Access Gateway binary manifests are stored here and served from here. These manifests are used solely during times of pod and gateway deployments and upgrades. This connection to this endpoint is configured to go direct and not through a proxy. |
Horizon Cloud content delivery server. On the management subnet, this site is used by the service for downloading necessary binaries used by the pod infrastructure. |
| Management | packages.microsoft.com | 443 and 11371 | TCP | No This site is outside of the application and service. Therefore, the connection does not use the configured proxy. This endpoint is a Microsoft Azure endpoint, within your Microsoft Azure cloud environment, and the connection goes direct within the Microsoft Azure cloud space. |
Microsoft software package server. Used to securely download the Microsoft Azure Command Line Interface (CLI) software. |
| Management | azure.archive.ubuntu.com | 80 | TCP | No This site is outside of the application and service. Therefore, the connection does not use the configured proxy. This endpoint is a Microsoft Azure endpoint, within your Microsoft Azure cloud environment, and the connection goes direct within the Microsoft Azure cloud space. |
Ubuntu software package server. Used by the pod-related Linux-based VMs for Ubuntu operating system updates. |
| Management | api.snapcraft.io | 443 | TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Ubuntu software package server. The pod manager and Unified Access Gateway instances run Ubuntu operating systems. Those Ubuntu operating systems are configured to obtain updates of those Ubuntu operating systems from this Ubuntu site. |
| Management | archive.ubuntu.com | 80 | TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Ubuntu software package server. The pod manager and Unified Access Gateway instances run Ubuntu operating systems. Those Ubuntu operating systems are configured to obtain updates of those Ubuntu operating systems from this Ubuntu site. |
| Management | changelogs.ubuntu.com | 80 | TCP | No This site is outside of the application and service. Therefore, the connection does not use the configured proxy. |
Ubuntu software package server. The pod manager and Unified Access Gateway instances run Ubuntu operating systems. Those Ubuntu operating systems are configured to use this Ubuntu site for tracking Ubuntu operating system updates. |
| Management | security.ubuntu.com | 80 | TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Ubuntu software package server. The pod manager and Unified Access Gateway instances run Ubuntu operating systems. Those Ubuntu operating systems are configured to use this Ubuntu site for security-related Ubuntu operating system updates. |
| Management | esm.ubuntu.com | 80 and 443 | TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Ubuntu software package server. The pod manager and Unified Access Gateway instances run Ubuntu operating systems. Those Ubuntu operating systems are configured to use this Ubuntu site for tracking security updates for high and critical CVEs (Common Vulnerabilities and Exposures) in the Ubuntu base OS and scale-out infrastructure. |
| Management | One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
|
443 | TCP | Yes | This web address is generally used by applications to authenticate against Microsoft Azure services. For some descriptions in the Microsoft Azure documentation, see OAuth 2.0 authorization code flow, Azure Active Directory v2.0 and the OpenID Connect protocol, and National clouds. The National clouds topic describes how there are different Azure AD authentication endpoints for each Microsoft Azure national cloud. |
| Management | One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
|
443 | TCP | Yes | Used for pod API requests to the Microsoft Azure Resource Manager endpoints for using Microsoft Azure Resource Manager services. Microsoft Azure Resource Manager provides a consistent management layer to perform tasks through Azure PowerShell, Azure CLI, Azure portal, REST API, and client SDKs. |
| Management | One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
|
443 | TCP | Yes | Access to the Azure Active Directory (Azure AD) Graph API, which is used for the pod's programmatic access to Azure Active Directory (Azure AD) through OData REST API endpoints. |
| Management | If your firewall or network security group (NSG) supports the use of service tags, one of the following:
If your firewall or network security group (NSG) does not support the use of service tags, you can use the host name of the database. This name follows the pattern *.postgres.database.azure.com. |
5432 | TCP | No This endpoint is the Microsoft Azure PostgreSQL database service within your Microsoft Azure cloud environment. The connection goes direct within the Microsoft Azure cloud space. |
Used for pod communication to the Microsoft Azure PostgreSQL database service which is configured for this Horizon Cloud on Microsoft Azure deployment. For information about service tags in security groups, see the Microsoft Azure documentation topic at Service tags. |
| Management | One of the following names, depending on which regional control plane instance is specified in your Horizon Cloud tenant account. The regional instance is set when the account is created, as described in Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.
|
443 | TCP | Yes | Regional instance of the Universal Broker service
|
| Management | Depending on which regional control plane applies to your Horizon Cloud account:
|
443 | TCP | Yes | Cloud Monitoring Service (CMS) |
| Management |
|
443 | TCP | No | The *.blob.core.windows.net endpoint is used for programmatic access to the Azure Blob Storage. This endpoint is a Microsoft Azure endpoint, within your Microsoft Azure cloud environment, and communication to that endpoint goes direct within the Microsoft Azure cloud space. The sauron-jp.horizon.vmware.com endpoint enables VMware monitoring system to detect security events on the VMware managed instances. Enables VMware's management responsibility for the deployed instances which requires mandatory VMware system monitoring of those instances. |
| Tenant | hydra-softwarelib-cdn.azureedge.net | 443 | TCP | No | Horizon Cloud content delivery server. On the tenant subnet, this site is used by various system image-related processes, including processes involved in the system's automated Import Image from Marketplace workflow and agent pairing workflow. |
| Tenant | scapi.vmware.com | 443 | TCP | No | VMware Cloud Services, used for the VMware Service Usage Data Program. Outbound from the tenant subnet, the Horizon agent in the pod-provisioned desktop instances and farm server instances sends agent-related configuration information. |
| Tenant | *.file.core.windows.net | 445 | TCP | No This endpoint is the Microsoft Azure File Storage service within your Microsoft Azure cloud environment. The connection goes direct within the Microsoft Azure cloud space. |
Used for App Volumes on Azure functionality. Used for programmatic access to the SMB fileshare in the pod manager's resource group for access to the App Volumes AppStacks that are stored in that SMB file share. |
Mandatory VMware System Monitoring Requirement - monitor.horizon.vmware.com
The mandatory requirement described in this section enables VMware monitoring system to detect security events on the VMware 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, VMware controls and manages these resources in the deployment: pod manager instances, Unified Access Gateway instances, Azure files related to App Volumes, Azure PostgreSQL Service, Horizon Edge Virtual Appliance, and, when needed for troubleshooting situations, the support-related jump box instance.
VMware's management responsibility for the deployed instances requires mandatory VMware system monitoring of those instances.
This mandatory VMware system monitoring requires you to meet the requirements described below.
In terms of a high-level description, the deployment's instances must outbound reach host name monitor.horizon.vmware.com on port 1514 (TCP and UDP) and on port 1515 (TCP and UDP).
- Requirement applicable when your network has SSL inspection enabled
- When SSL inspection is enabled on the network, you must specify to exclude the host monitor.horizon.vmware.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.
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.vmware.com on 1514 (TCP and UDP) and 1515 (TCP and UDP)
- US Federal environments - Please open a case with VMware 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.
First-Gen - Horizon Infrastructure Monitoring - DNS Requirements
Activating Horizon Infrastructure Monitoring on a pod in a first-gen Horizon Cloud tenant will instantiate the Linux-based Horizon Edge Virtual Appliance in your Microsoft Azure subscription. The Horizon Edge Virtual Appliance is deployed into the pod's subscription with a NIC on the pod's management subnet — the same management subnet as that pod's pod-manager appliances. In the following table, the listed purposes are in context of this virtual appliance.
uk in this table like there are in the preceding table. As stated in the Release Notes, this
Horizon Infrastructure Monitoring feature is not available in the
uk control plane.
As stated in page Horizon Infrastructure Monitoring and the Pods in Your Horizon Cloud Environment, this entire feature of Horizon Infrastructure Monitoring is unsupported for use when there is a proxy between the management network and the Internet.
As a result, adding Horizon Infrastructure Monitoring to pod deployments involving proxy traffic is discouraged.
Unless you ensure the endpoints in the following table are reachable and you allow communication to them without going through your configured proxy, any attempts to add on the Horizon Infrastructure Monitoring feature to your pods when your pods are configured for proxy traffic, deployment of this feature's Horizon Edge Virtual Appliance will fail.
In the following table, the inclusion of the column Proxy Traffic shall not be construed as official support for the uncertified configuration of adding Horizon Infrastructure Monitoring when proxy is configured on the Horizon Cloud pod. Inclusion of this column in this documentation page is only to mitigate the feature's Horizon Edge Virtual Appliance deployment for organizations that choose to adopt the configuration given the preceding notices.
| Subnet Source | Destination/Endpoint (DNS name) | Port/Protocol | Proxy Traffic (if configured on the pod deployment) | Purpose |
|---|---|---|---|---|
| Management |
|
80 and 443 / TCP | No These endpoints are outside of the application and service. Therefore, these connections do not use the configured proxy. The azure.archive.ubuntu.com endpoint is a Microsoft Azure endpoint, within your Microsoft Azure cloud environment, and that connection goes direct within the Microsoft Azure cloud space. |
Ubuntu software package server. Used by the Linux-based appliance for Ubuntu operating system updates. |
| Management | esm.ubuntu.com | 80 and 443 / TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Ubuntu software package server. Used by the Linux-based appliance for tracking security updates for high and critical CVEs (Common Vulnerabilities and Exposures) in the Ubuntu base OS and scale-out infrastructure. |
| Management |
|
443 / TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Used for programmatic access to the Azure Blob Storage. Used to download the Docker images from those DNS addresses that the appliance's module requires. |
| Management | *.azure-devices.net, or one of the region-specific names below, depending on which regional control plane applies to your tenant account: North America:
Europe:
Australia:
Japan:
|
443 / TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Used to connect the appliance to the Horizon Cloud control plane, to download configurations for the appliance's module, and to update the appliance's module's runtime status. |
| Management |
|
443 / TCP | No This endpoint is outside of the application and service. The connection does not use the configured proxy. |
Used to download Docker binaries and Kubernetes binaries that the appliance needs.
Important: As of April 17, 2023, required URLs are added to this list that are required to download the WeaveNet configuration to be used in the appliance's Kubernetes network:
Please note that the YAML file exists in a specific path that includes a specific release number that is determined at each specific release. As of this writing on April 17, 2023, the release portion of the path is v2.8.1, and is reflected in this table's Destination column. Because updated versions of this YAML file might be released in the future, the specific file path might be updated over time, because the release number is codified in the destination path. |
| Management | Depending on which regional control plane applies to your tenant account: North America:
Europe:
Australia:
Japan:
|
443 / TCP | No | Used to send the pod monitoring data collected by the appliance to the Horizon Cloud control plane. |
| Management | If your firewall or network security group (NSG) supports the use of service tags, apply Azure service tag AzureCloud. If your firewall or NSG does not support the use of service tags, use the host name:
|
1514 and 1515 (TCP and UDP) | No The proxy information for these endpoints is described within the preceding section named Mandatory VMware System Monitoring Requirement - monitor.horizon.vmware.com. |
Used for system monitoring. |
If Required for An Active Support Request, Temporary Jump Box Ports and Protocols
If you make a support request to VMware and the support team determines the way to service that request is to deploy a temporary jump box VM for SSH communication with the VMware-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 VMware 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.
- The Horizon Edge Virtual Appliance port 22 using SSH, in a deployment with Horizon Infrastructure Monitoring configured.
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 VMware Support 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.
