This page is a reference for all of the possible ports and protocols used for communication within a typical first-generation Horizon Cloud Service on Microsoft Azure deployment. Use these tables to ensure your network configuration and firewalls will allow the communication traffic that is required for a successful pod deployment and day-to-day operations.

About This Page

Important: This information applies 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.
Note: As described in VMware KB article 93762, the Horizon Infrastructure Monitoring feature has been deprecated and first-gen tenants can no longer activate or use that feature. As of October 2023, the ports and protocols information related to that deprecated feature has been removed from this page.

The specific ports and protocols required for your particular deployment will in part depend on which features you select to use for your Horizon Cloud Service on Microsoft Azure deployment. If you plan to not use a specific component or protocol, then its required communication traffic is not necessary for your purposes, and you can ignore the ports associated with that component. As an example, if your end users will only use the Blast Extreme display protocol, then allowing the PCoIP ports is not a requirement.

Important: In addition to the ports and protocols described here, network traffic for pod deployments and day-to-day operations has specific host name requirements.

Network traffic must reach specific host names. If the deployment is configured to use a proxy, some network services are expected to use the proxy and other network services are expected to go direct. For details about network traffic to host names, see First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names.

For information about other ports supported for VMware products, go to VMware Ports and Protocols.

As part of the pod deployment process, the deployer creates network security groups (NSGs) on the network interfaces (NICs) on all of the deployed VMs. For details about the rules defined in those NSGs, see Default Network Security Group Rules for the VMs in a Horizon Cloud Pod.

Ports and Protocols Required by Key Pod Components for Ongoing Operations

In addition to the DNS requirements, the following tables list ports and protocols that are required for the pod to operate properly for ongoing operations after deployment. Some of these tables also list ports and protocols that are required for specific scenarios or when you have enabled particular features on the pod.

In the Microsoft Azure portal, the pod manager VMs have names that contains a part like vmw-hcs-podID, where podID is the pod's UUID, and a node part.

Note: Starting with the v2204 service release, new Horizon Cloud Service on Microsoft Azure deployments are deployed with high availability configured by default. The deployment has two pod manager VMs. In the tables below, wherever you see the phrase pod manager VM, that term applies to both pod manager VMs unless otherwise indicated.

The system's use of a Microsoft Azure load balancer with the pod manager VMs started from manifest 1600, at the September 2019 service release. Therefore, all pods deployed new from manifest 1600 onward have a pod Microsoft Azure load balancer. Pods that were first deployed prior to manifest 1600 and subsequently updated to later manifests also have a pod Microsoft Azure load balancer. The table rows that mention the pod's load balancer apply for all such pods.

Table 1. Pod Operations Ports and Protocols
Source Target Ports Protocol Purpose
Pod manager VM Pod's other pod manager VM 4101 TCP This traffic is JMS routing between the pod manager VMs.
Pod manager VM Unified Access Gateway VMs 9443 HTTPS This port is used by the pod manager VM over the management subnet to configure settings in the pod's Unified Access Gateway configuration. This port requirement applies when initially deploying a pod with a Unified Access Gateway configuration and when editing a pod to add a Unified Access Gateway configuration or update settings for that Unified Access Gateway configuration.
Pod's Microsoft Azure load balancer Pod manager VM 8080 HTTP Health checks of the VMs in the load balancer's backend pool.

For pods deployed prior to v2204 release on which the high-availability toggle was not set and high availability not yet added, the load balancer has one pod manager VM is its backend pool to check.

Pod manager VM Domain controller 389 TCP

UDP

Registering your Horizon Cloud tenant with an Active Directory is a requirement. The console's Register AD Domain workflow must be performed after onboarding your first pod.

This port is required for LDAP services when LDAP will be specified in that workflow. LDAP is the default for most tenants.

Target is the server that contains a domain controller role in the Active Directory configuration.

Pod manager VM Global catalog 3268 TCP Registering your Horizon Cloud tenant with an Active Directory is a requirement. The console's Register AD Domain workflow must be performed after onboarding your first pod.

This port is required for LDAP services when LDAP will be the specified protocol in that workflow. LDAP is the default for most tenants.

Target is the server that contains global catalog role in the Active Directory configuration.

Pod manager VM Domain controller 88 TCP

UDP

Kerberos services. Target is the server that contains a domain controller role in an Active Directory configuration. Registering the pod with an Active Directory is a requirement.
Pod manager VM Domain controller 636, 3269 TCP Registering your Horizon Cloud tenant with an Active Directory is a requirement. The console's Register AD Domain workflow must be performed after onboarding your first pod.

These ports are required for LDAP over SSL (LDAPS) services only when LDAPS will be the specified protocol in the configuration for that registered AD. LDAPS can only be specified for the registered AD when your tenant is enabled to use the service's LDAPS feature. Otherwise, LDAP is the requirement by default.

Pod manager VM DNS server 53 TCP

UDP

DNS services.
Pod manager VM NTP server 123 UDP NTP services. Server that provides NTP time synchronization.
Pod manager VM True SSO Enrollment Server 32111 TCP True SSO Enrollment Server. Required if you are using True SSO with your Horizon pods.

32111 is the default port used in the Enrollment Server installation. This port number can be configured during the Enrollment Server installation process per your requirements.

See also the True SSO and Certificate Management and Horizon Cloud on Microsoft Azure deployments section in this topic.

Pod manager VM Workspace ONE Access service 443 HTTPS
Note: This row is applicable to environments with a single-pod-broker configuration. This information is not for environments with a Universal Broker configuration. In a single-pod-broker configured environment, the Workspace ONE Access Connector communicates with a pod to obtain the end-user entitlements (the assignments).
Optional if you are not integrating Workspace ONE Access with the pod. In a single-pod-broker configured environment, this connection is used to create a trust relationship between the pod and the Workspace ONE Access service, where the Workspace ONE Access Connector is synched with the pod. Ensure that the pod can reach the Workspace ONE Access environment you are using on port 443. When you are using the Workspace ONE Access cloud service, see also the list of Workspace ONE Access service IP addresses to which the Workspace ONE Access Connector and the pod must have access in the VMware Knowledge Base article 2149884.

Gateway Connector VM Ports and Protocols Requirements

This table applies to the gateway's connector VM that is used when you have deployed the external gateway in a separate VNet. In addition to the DNS requirements, the ports and protocols in the following table are required for the external gateway to operate properly for ongoing operations after deployment.

In the table below, the term connector VM refers to the gateway's connector VM which manages the connection between the cloud management plane and the external gateway. In the Microsoft Azure portal, this VM has a name that contains a part like vmw-hcs-ID, where ID is the gateway's deployer ID, and a node part.

Table 2. Pod Operations Ports and Protocols
Source Target Ports Protocol Purpose
Connector VM DNS server 53 TCP

UDP

DNS services.
Connector VM NTP server 123 UDP NTP services. Server that provides NTP time synchronization.

Unified Access Gateway VM Ports and Protocols Requirements

In addition to the DNS and above primary ports and protocols requirements, the ports and protocols in the following tables are related to the gateways that you have configured on the pod to operate properly for ongoing operations after deployment.

For connections using a high-availability-enabled pod configured with Unified Access Gateway instances, traffic must be allowed from the pod's Unified Access Gateway instances to targets as listed in the table below. During pod deployment, a Network Security Group (NSG) is created in your Microsoft Azure environment for use by the pod's Unified Access Gateway instances.

Table 3. Port Requirements for Traffic from the Pod's Unified Access Gateway Instances
Source Target Port Protocol Purpose
Unified Access Gateway Pod's Microsoft Azure load balancer 8443 TCP Login authentication traffic. The traffic from the Unified Access Gateway instances reaches the pod manager VMs through the pod's load balancer.
Unified Access Gateway NTP server 123 UDP NTP services. Server that provides NTP time synchronization.

When your tenant is configured to use Universal Broker, ensure these points are met:

  • External Unified Access Gateway configuration must have connectivity to NTP servers from the DMZ subnet.
  • Internal Unified Access Gateway configurations must have connectivity to NTP servers from the tenant subnet.

The reason why is because if the service detects there is a time drift between the Unified Access Gateway appliances and the Universal Broker's NTP server that is running UTC (Coordinated Universal Time), an email will be sent to you to ask that you address the time drift. Time drifts between Universal Broker and the Unified Access Gateway appliances might result in failed end-user connections. When your internal Unified Access Gateway configurations are not connected to an NTP server from the tenant subnet, then they are more likely to experience such time drifts, because without an NTP server, those Unified Access Gateway appliances will be relying on the underlying VM's time.

If the NTP server you want to use is an internal NTP server and unallowed to communicate from the DMZ interface, please open an SR so that the VMware Horizon Cloud Service team can assist in adding routes to the Unified Access Gateway configuration after deployment so that the Unified Access Gateway can talk to your NTP server. The VMware Horizon Cloud Service team has API calls to add the routes for you.

Tip: When your tenant is configured to use single-pod brokering, the above points are considered best practices, because in the single-pod broker scenario, the time drift with the Unified Access Gateway appliances does not impact end-user connections.
Unified Access Gateway Horizon agent in the desktop or farm RDSH VMs 4172 TCP

UDP

PCoIP
Unified Access Gateway Horizon agent in the desktop or farm RDSH VMs 22443 TCP

UDP

Blast Extreme

By default, when using Blast Extreme, client-drive redirection (CDR) traffic and USB traffic is side-channeled in this port. If you prefer instead, the CDR traffic can be separated onto the TCP 9427 port and the USB redirection traffic can be separated onto the TCP 32111 port.

Unified Access Gateway Horizon agent in the desktop or farm RDSH VMs 9427 TCP Optional for client driver redirection (CDR) and multimedia redirection (MMR) traffic.
Unified Access Gateway Horizon agent in the desktop or farm RDSH VMs 32111 TCP Optional for USB redirection traffic.
Unified Access Gateway Your RADIUS instance 1812 UDP When using RADIUS two-factor authentication with that Unified Access Gateway configuration. The default value for RADIUS is shown here.
Unified Access Gateway Your RSA SecurID Authentication Manager server 5555 TCP When using RSA SecurID two-factor authentication with that Unified Access Gateway configuration. Shown here is the default value used for the communication port for RSA SecurID Authentication API agents for agent authentication.

Ports and Protocols Required by Universal Broker

To support the use of Universal Broker for the brokering of end-user assignments from a pod, you must configure port 443 as described in the following table. The active pod manager establishes a persistent WebSocket connection with the Universal Broker service through port 443 and receives connection requests from the Universal Broker service through a randomly selected port.

Table 4. Port Requirements for Universal Broker
Source Source Port Target Target Port Protocol Purpose
Active pod manager Randomly selected from available ports Universal Broker service 443 HTTPS initially, then WebSocket Establishes a persistent WebSocket connection with the Universal Broker service

End-User Connection Traffic Ports and Protocols Requirements

To connect to their pod-provisioned virtual desktops and remote applications from their devices, your end users use a compatible installed VMware Horizon Client or their browser (known as the Horizon HTML Access client). The ports which must be opened for traffic from the end users' clients to reach their pod-provisioned virtual desktops and remote applications depends on the choice you make for how your end users will connect:

When you choose the deployer option for having an external gateway configuration in the pod's own VNet
The deployer deploys Unified Access Gateway instances in your Microsoft Azure environment, along with a Microsoft Azure load balancer resource to those instances in that load balancer's backend pool. That load balancer communicates with those instances' NICs on the DMZ subnet, and is configured as a public load balancer in Microsoft Azure. The diagram Illustration of the Horizon Cloud Pod Architecture where the Pod has Both External and Internal Gateway Configurations, the External Gateway Deployed into the Same VNet as the Pod, Three NICs on the External Gateway VMs, Two NICs on the Internal Gateway VMs, and a Public IP Enabled for the External Gateway's Load Balancer depicts the location of this public load balancer and the Unified Access Gateway instances. When your pod has this configuration, traffic from your end users on the Internet goes to that load balancer, which distributes the requests to the Unified Access Gateway instances. For this configuration, you must ensure that those end-user connections can reach that load balancer using the ports and protocols listed below. Post-deployment, the external gateway's load balancer is located in the resource group named vmw-hcs-podID-uag, where podID is the pod's UUID.
When you choose the deployer option for having an internal Unified Access Gateway configuration
An internal gateway configuration is deployed into the pod's own VNet by default. The deployer deploys Unified Access Gateway instances in your Microsoft Azure environment, along with a Microsoft Azure load balancer resource to those instances in its backend pool. That load balancer communicates with those instances' NICs on the tenant subnet, and is configured as an internal load balancer in Microsoft Azure. The diagram Illustration of the Horizon Cloud Pod Architecture where the Pod has Both External and Internal Gateway Configurations, the External Gateway Deployed into the Same VNet as the Pod, Three NICs on the External Gateway VMs, Two NICs on the Internal Gateway VMs, and a Public IP Enabled for the External Gateway's Load Balancer depicts the location of this internal load balancer and the Unified Access Gateway instances. When your pod has this configuration, traffic from your end users in your corporate network goes to that load balancer, which distributes the requests to the Unified Access Gateway instances. For this configuration, you must ensure that those end-user connections can reach that load balancer using the ports and protocols listed below. Post-deployment, the internal gateway's load balancer is located in the resource group named vmw-hcs-podID-uag-internal, where podID is the pod's UUID.
When you choose the deployer options either for having an external gateway configuration in its own VNet and not the pods, or the option to use its own subscription (which is a special sub-case of using its own VNet because VNets do not span subscriptions)
The deployer deploys Unified Access Gateway instances in your Microsoft Azure environment, along with a Microsoft Azure load balancer resource to those instances in that load balancer's backend pool. That load balancer communicates with those instances' NICs on the DMZ subnet, and is configured as a public load balancer in Microsoft Azure. The diagram Illustration of the External Gateway's Architecture Elements When the External Gateway is Deployed into Its Own VNet, Separate from the Pod's VNet depicts the location of this public load balancer and the Unified Access Gateway instances in the gateway's own VNet. When your pod has this configuration, traffic from your end users on the Internet goes to that load balancer, which distributes the requests to the Unified Access Gateway instances. For this configuration, you must ensure that those end-user connections can reach that load balancer using the ports and protocols listed below. Post-deployment, the external gateway's load balancer is located in the resource group named vmw-hcs-ID-uag, where ID is the value show in the Deployer ID field of the pod's details page. As described in the Administration Guide, you get to the pod's details page from the console's Capacity page.
When you have no Unified Access Gateway configurations on the pod
Note: For production environments where the tenant is configured to use single-pod brokering, the best practice for internal end-user connections is to use an internal Unified Access Gateway gateway configuration on the pod. Those connections would go to that gateway configuration in the single-pod brokering scenario.
In a configuration where you have single-pod brokering and Workspace ONE Access integrated with the pod, you typically have your end users connect through Workspace ONE Access. In this scenario, you must configure Workspace ONE Access and the Workspace ONE Access Connector pointing directly to the pod. Your end users are connecting to their pod-provisioned resources using Workspace ONE Access. For this configuration, you upload an SSL certificate to the pod manager VMs using the pod's summary page in the console, as described in the VMware Horizon Cloud Service Administration Guide. Then you complete the steps to integrate Workspace ONE Access with the pod.
Table 5. External End User Connections Ports and Protocols when the Pod Configuration has External Unified Access Gateway instances
Source Target Port Protocol Purpose
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 443 TCP Login authentication traffic. Can also carry client-drive redirection (CDR), multimedia redirection (MMR), USB redirection, and tunneled RDP traffic.

SSL (HTTPS access) is enabled by default for client connections. Port 80 (HTTP access) can be used in some cases.

Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 4172 TCP

UDP

PCoIP via PCoIP Secure Gateway on Unified Access Gateway
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 8443 or 443, depending on what is set in your deployment TCP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic from as Horizon Client. For a Horizon Cloud pod, this port is selected using the Blast Extreme TCP Port menu in the deployment wizard. Ensure that your networking allows the clients the outbound access to whichever one you specified for the external gateway. This URL is used by the clients to establish the Horizon Blast session to the Unified Access Gateway instances, through the load balancer that sits in front of those instances.

Starting with the October 2021 service release, for new deployments of a gateway configuration, the deployer provides the ability select either 8443 or 443 for the Blast Extreme TCP port that the deployer will configure in the corresponding Unified Access Gateway configuration. Previously, the deployer configured 443 by default without providing a choice. If your gateway configuration was deployed prior to the date of the October 2021 service release, that configuration typically has 443 port set in the Blast External URL field in its Unified Access Gateway administration settings.

Note: Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. Port 443, is less efficient and less performant. Using port 443 will result in CPU congestion in the instances. Port 443 would be used in your deployment only if your organization has set client-side restrictions, such as your organization only permits 443 outbound and not 8443.
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 443 UDP Blast Extreme via the Unified Access Gateway for data traffic.
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 8443 UDP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (adaptive transport).
Browser Microsoft Azure load balancer for these Unified Access Gateway instances 443 TCP Login authentication traffic. Can also carry client-drive redirection (CDR), multimedia redirection (MMR), USB redirection, and tunneled RDP traffic.

SSL (HTTPS access) is enabled by default for client connections. Port 80 (HTTP access) can be used in some cases.

Browser Microsoft Azure load balancer for these Unified Access Gateway instances 8443 or 443, depending on what was set in your deployment TCP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic from the Horizon HTML Access client (web client). For a Horizon Cloud pod, this port is selected using the Blast Extreme TCP Port menu in the deployment wizard. Ensure that your networking allows the clients the outbound access to whichever one you specified for the external gateway. This URL is used by the Horizon HTML Access client in the browser to establish the Horizon Blast session to the Unified Access Gateway instances, through the load balancer that sits in front of those instances.

Starting with the October 2021 service release, for new deployments of a gateway configuration, the deployer provides the ability select either 8443 or 443 for the Blast Extreme TCP port that the deployer will configure in the corresponding Unified Access Gateway configuration. Previously, the deployer configured 443 by default without providing a choice. If your gateway configuration was deployed prior to the date of the October 2021 service release, that configuration typically has 443 port set in the Blast External URL field in its Unified Access Gateway administration settings.

Note: Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. Port 443, is less efficient and less performant. Using port 443 will result in CPU congestion in the instances. Port 443 would be used in your deployment only if your organization has set client-side restrictions, such as your organization only permits 443 outbound and not 8443.
Table 6. Internal End User Connections Ports and Protocols when the Pod Configuration has Internal Unified Access Gateway instances
Source Target Port Protocol Purpose
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 443 TCP Login authentication traffic. Can also carry client-drive redirection (CDR), multimedia redirection (MMR), USB redirection, and tunneled RDP traffic.

SSL (HTTPS access) is enabled by default for client connections. Port 80 (HTTP access) can be used in some cases. See the topic Understanding What URL Content Redirection Is in the VMware Horizon Cloud Service Administration Guide.

Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 4172 TCP

UDP

PCoIP via PCoIP Secure Gateway on Unified Access Gateway
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 8443 or 443, depending on what was set in your deployment TCP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic from as Horizon Client. For a Horizon Cloud pod, this port is selected using the Blast Extreme TCP Port menu in the deployment wizard. Ensure that your networking allows the clients the outbound access to whichever one you specified for the external gateway. This URL is used by the clients to establish the Horizon Blast session to the Unified Access Gateway instances, through the load balancer that sits in front of those instances.

Starting with the October 2021 service release, for new deployments of a gateway configuration, the deployer provides the ability select either 8443 or 443 for the Blast Extreme TCP port that the deployer will configure in the corresponding Unified Access Gateway configuration. Previously, the deployer configured 443 by default without providing a choice. If your gateway configuration was deployed prior to the date of the October 2021 service release, that configuration typically has 443 port set in the Blast External URL field in its Unified Access Gateway administration settings.

Note: Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. Port 443, is less efficient and less performant. Using port 443 will result in CPU congestion in the instances. Port 443 would be used in your deployment only if your organization has set client-side restrictions, such as your organization only permits 443 outbound and not 8443.
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 443 UDP Blast Extreme via the Unified Access Gateway for data traffic.
Horizon Client Microsoft Azure load balancer for these Unified Access Gateway instances 8443 UDP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic (adaptive transport).
Browser Microsoft Azure load balancer for these Unified Access Gateway instances 443 TCP Login authentication traffic. Can also carry client-drive redirection (CDR), multimedia redirection (MMR), USB redirection, and tunneled RDP traffic.

SSL (HTTPS access) is enabled by default for client connections. Port 80 (HTTP access) can be used in some cases.

Browser Microsoft Azure load balancer for these Unified Access Gateway instances 8443 or 443, depending on what was set in your deployment TCP Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic from the Horizon HTML Access client (web client). For a Horizon Cloud pod, this port is selected using the Blast Extreme TCP Port menu in the deployment wizard. Ensure that your networking allows the clients the outbound access to whichever one you specified for the external gateway. This URL is used by the Horizon HTML Access client in the browser to establish the Horizon Blast session to the Unified Access Gateway instances, through the load balancer that sits in front of those instances.

Starting with the October 2021 service release, for new deployments of a gateway configuration, the deployer provides the ability select either 8443 or 443 for the Blast Extreme TCP port that the deployer will configure in the corresponding Unified Access Gateway configuration. Previously, the deployer configured 443 by default without providing a choice. If your gateway configuration was deployed prior to the date of the October 2021 service release, that configuration typically has 443 port set in the Blast External URL field in its Unified Access Gateway administration settings.

Note: Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. Port 443, is less efficient and less performant. Using port 443 will result in CPU congestion in the instances. Port 443 would be used in your deployment only if your organization has set client-side restrictions, such as your organization only permits 443 outbound and not 8443.
Table 7. Internal End User Connections Ports and Protocols when using Direct Connections, Such as Over VPN
Source Target Port Protocol Purpose
Horizon Client Pod's Microsoft Azure load balancer 443 TCP Login authentication traffic. The traffic from the clients reaches the pod manager VMs through the pod's load balancer.
Horizon Client Horizon agent in the desktop or farm RDSH VMs 4172 TCP

UDP

PCoIP
Horizon Client Horizon agent in the desktop or farm RDSH VMs 22443 TCP

UDP

Blast Extreme
Horizon Client Horizon agent in the desktop or farm RDSH VMs 32111 TCP USB redirection
Horizon Client Horizon agent in the desktop or farm RDSH VMs 9427 TCP Client-drive redirection (CDR) and multimedia redirection (MMR)
Browser Horizon agent in the desktop or farm RDSH VMs 443 TCP HTML Access

Ports and Protocols Requirements for Traffic from Agents Installed in the Base VM, VDI Desktop VMs, and Farm RDSH VMs

The following ports must allow traffic between the agent-related software that is installed in the base VMs, desktop VMs, and farm RDSH VMs and the pod manager VMs.

Source Target Port Protocol Purpose
Horizon agent in the base imported VM, golden images, desktop VMs, farm RDSH VMs Pod manager VM 4001 TCP Java Message Service (JMS, non-SSL), used by the agent in the VM to communicate with the pod as part of the certificate thumbprint verification and exchange to secure an SSL connection to the pod. After the keys are negotiated and exchanged between the VM and the pod manager, the agent uses port 4002 to create a secured SSL connection. For example, the Reset Agent Pairing action on the Imported VMs page requires communication over port 4001 for that agent pairing workflow between the base imported VM and the pod.
Note: Both ports 4001 and 4002 are required for steady-state operations. There are times when the agent might need to re-key with the pod, so port 4001 must be kept open.
Horizon agent in the base imported VM, the golden images, desktop VMs, farm RDSH VMs Pod manager VM 4002 TCP Java Message Service (JMS, SSL), used by the agent in these VMs to communicate with the pod using a secured SSL connection.
Horizon agent in the desktop VMs, farm RDSH VMs VMware Cloud Services host name scapi.vmware.com 443 TCP Used for the VMware Service Usage Data Program. Outbound from the tenant subnet, traffic from the Horizon agent sent to VMware Cloud Services host name scapi.vmware.com.
FlexEngine agent (the agent for VMware Dynamic Environment Manager) in the desktop or farm RDSH VMs Those file shares that you set up for use by the FlexEngine agent that runs in the desktop or farm RDSH VMs 445 TCP FlexEngine agent access to your SMB file shares, if you are using VMware Dynamic Environment Manager capabilities.

Ports and Protocols Required by App Volumes Features

As stated in App Volumes Applications for Horizon Cloud on Microsoft Azure - Overview and Prerequisites, to support the use of the App Volumes features that are supported for use with a Horizon Cloud pod, you must configure port 445 for TCP protocol traffic on the pod's tenant subnet. Port 445 is the standard SMB port for accessing an SMB file share on Microsoft Windows. The AppStacks are stored in an SMB file share located in the same resource group as the pod manager VMs.

Also, as described in First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names, when Azure Cloud provisions that SMB file share, Azure Cloud assigns a fully qualified domain name (FQDN) in the pattern *.file.core.windows.net, where * is the Azure generated name of the SMB file share's storage account. This FQDN must be resolvable by your DNS server so that App Volumes can access and mount those fileshares and retrieve the AppStacks. 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.

Important: If you intend to integrate your Horizon Cloud pod and NSX Cloud version 3.1.1 and later, and you want to use App Volumes assignments, you must manually open this port 445/TCP for the pod's tenant subnet in your NSX firewall rules after you deploy the NSX PCG and before you create your first App Volumes assignment using that pod.
Table 8. Port Requirements for App Volumes
Source Target Port Protocol Purpose
App Volumes agent in the base imported VM, the golden images, desktop VMs, farm RDSH VMs SMB file share in the pod manager's resource group 445 TCP On the pod's tenant subnet, for access to the App Volumes AppStacks that are stored in the SMB file share.

Integration with Workspace ONE Assist for Horizon - DNS, Ports, and Protocol Requirements

Workspace ONE Assist for Horizon is a product in the Workspace ONE UEM line of products. As of the August 2021 Horizon Cloud release, when specific requirements are met, you can integrate use of that product with VDI desktops provisioned from your Horizon Cloud tenant's pods. For full details of the requirements, see the VMware Workspace ONE Assist for Horizon guide located within the VMware Workspace ONE Assist Documentation area.

Use of the assistance features requires outbound communication between the VDI desktop VMs and the Workspace ONE Assist server which supports the integration with your Horizon Cloud tenant.

DNS Requirements
Ensure that the DNS name of your Workspace ONE Assist server is resolvable and reachable from the pod's tenant subnets on which the VDI desktop VMs will reside. The previously mentioned VMware Workspace ONE Assist for Horizon guide provides the DNS names of the Workspace ONE Assist servers.
Ports and Protocol Requirements
Outbound traffic using port 443, TCP and HTTPS, must be allowed from the VDI desktop VMs on which the Workspace ONE Assist for Horizon application is installed.

When 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 the communication 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 nature of the support request and the appliances used in the deployment determine which specific VMware-managed appliance or appliances must be allowed as the target for the communication.

Table 9. Support-Related Jump Box Ports and Protocols
Source Target Ports Protocol Purpose
Jump box VM
  • Pod manager VMs
  • Gateway connector VM
22 SSH If VMware Support requires this communication to one or more of the listed appliances to fulfill your support request, the jump box VM communicates over the management subnet to port 22 on the target appliance.
Jump box VM Unified Access Gateway VMs 9443 HTTPS If VMware Support requires this communication to fulfill your support request, the jump box VM communicates over the management subnet to configure settings in the Unified Access Gateway configuration.

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.

True SSO and Certificate Management and Horizon Cloud on Microsoft Azure deployments

The Horizon Cloud pod-provisioned desktop VMs do not communicate directly with the Enrollment Server. The Horizon Cloud on Microsoft Azure deployment's active pod manager VM relays the certificate requests to the Enrollment Server. Once the certificate is obtained, the Horizon agent in the desktop VMs uses that certificate to perform the Certificate Logon operation on behalf of the desktop user.

The request-response architecture is the same for a Horizon Cloud on Microsoft Azure deployment's pod manager VM as it is for a Horizon deployment's Horizon Connection Server. In a Horizon Cloud on Microsoft Azure deployment, the pod manager VMs have connections to the desktop VMs on the primary VM subnet (also called the tenant subnet), and on any additional VM subnets that the VDI administrator might have added using the Edit Pod workflow.

Two classes of certificate will be validated by various components: user certificates and channel certificates. True SSO adds a user certificate that is validated by the authentication server. In this case of a Horizon Cloud on Microsoft Azure deployment, that authentication server is a Microsoft Active Directory server. Because the Microsoft architecture determines which port numbers can be used for this certificate validation, a wide range of port numbers can be used for this validation since the ports are part of the Microsoft architecture itself and not specific to the Horizon Cloud on Microsoft Azure deployment itself.

When using True SSO in a Horizon Cloud on Microsoft Azure deployment, the Horizon agent generates a CSR and sends it to the deployment's active pod manager VM over the communication channel already in place between that pod manager VM and that Horizon agent. The pod manager VM relays the request to the Enrollment Server over a secure SSL-encrypted TCP channel (port 32111 or the port configured by the customer in the Enrollment Server installation). The Enrollment Server generates a CMC request, appends the CSR and the user name as provided by the Pod Manager, signs the CMC using the Enrollment Agent Certificate, and submits it to the Certificate Authority using the MS-DCOM (RPC) protocol.

The Horizon agent receives the certificate, serializes it as a logon credential, and submits it to the Windows logon process. The LSASS Windows component receives the certificate, validates it (checks that it is valid and trusted, and that the local machine holds the private key for the certificate) and then sends it to a Domain Controller (DC). The DC may choose to check the CRL as specified in the user certificate.

Visually Rich Networking Diagrams

For a visually rich depiction of the relationships between these components, ports, and protocols, see the VMware Digital Workspace Tech Zone's network diagrams and descriptions at https://techzone.vmware.com/resource/vmware-horizon-cloud-service-microsoft-azure-network-ports-diagrams.