VMware Horizon 7.4 Network Ports for Cloud Pod Architecture

Earlier this month (January 2018) VMware released Horizon 7.4, and with that I wanted to share some updates in regard to the network port requirements. My good colleagues over in the EUC Technical Marketing team are doing a fine job of maintaining the diagram and have recently published a white paper PDF which you’ll find here. It’s a beast of a document and highly recommended if you are deploying a VMware Horizon architecture in your environment.

An important consideration when using this network ports diagram, is that it doesn’t necessarily contain all non-VMware related ports such as Active Directory, DNS, NTP, SMB and so on. In fact one of my colleagues in the Office of the CTO mentioned this, since one of his customers ran into an issue where TCP port 135 was blocked, but this was required when joining a Pod to a federation (Cloud Pod Architecture). I thought this would be a good opportunity to describe what Cloud Pod Architecture is doing behind the scenes and provide some updates.

Cloud Pod Architecture (Global LDAP Replication)

By default when you install VMware Horizon, a local (intra-Pod) LDAP instance is created. I’m showing my age now, but if like me you have worked with VMware Horizon for a long time you may remember this being known as ADAM (Active Directory Application Mode). These days we refer to this as Active Directory Lightweight Directory Services (AD LDS). This local LDAP replication instance LDAP (TCP 389) and LDAPS (TCP 636) to communicate between Connection Servers in the same Pod. This isn’t the only communication mechanism, since it also uses Java Message Service (JMS), but that isn’t used for Cloud Pod Architecture.

In order to support Cloud Pod Architecture (CPA), VMware Horizon uses an additional (Global) LDAP replication instance that communicates across all Connection Servers in all Pods (inter-Pod communication). This secondary LDAP replication layer, which we refer to as Global LDAP Replication, uses port 22389 (see the table below), and replicates global objects, such as global entitlements, to all Connection Servers in all Pods.

I mentioned that the local LDAP instance is installed by default, but the Global LDAP instance is not created until the Horizon administrator initiates a Horizon Cloud Pod federation. This can be done from the Horizon Administrator UI or using the lmvutil command. In fact this can be initialized on a single Pod, no need for multiple Pods (Horizon instances). Once this process completes it will have created the Global LDAP instance (VMwareVDMDSG). In fact you can see this in Programs and Features. The actual database is installed to C:\ProgramData\VMware\VDM\ldap\data\VMwareVDMDSG.

Additional Ports (RPC Endpoint Mapper)

When a Pod is joined to a Cloud Pod federation, Horizon uses the Global LDAP instance to establish communication to a Connection server in the other Pod. LDAP replication uses Remote Procedure Call (RPC), and it needs to establish an initial connection on port 135 to communicate with the Endpoint Mapper (EPM). This is part of a 3-way handshake that is used by RPC, and if successful it will then establish communications on the specified port, for Global LDAP replication is 22636. If port 135 is blocked, then the task in Horizon to join the federation will stall. You can read more detail RPC endpoint mapping in an article from 2009 where Michael Platts runs a network trace.

It is also worth noting that Horizon will automatically configure the Windows Firewall to allow Inbound rules for 389, 636, 22389, 22636, and additionally the RPC Endpoint Mapper (135). See the screenshot below (click to enlarge):

If you have a firewall between Horizon Pods then please make sure these ports are open.

The post VMware Horizon 7.4 Network Ports for Cloud Pod Architecture appeared first on Ray Heffer.