When troubleshooting View Cloud POD environments a few approaches can first be checked if there is a self-evident issue. Most of the time when I see sync issues in Cloud POD environments it has to do with the Windows Firewall. Verify your customer doesn’t have a GPO forcing the Windows Firewall Service to a disabled state, if so, I would recommend excluding the connection brokers from that policy. Check your ports! Verify nothing is blocking communication with the connection brokers on the LAN and between the sites.
- CP 8472: View Interpod API (Cloud Pod Architecture) – NEW
- TCP 22389: Global ADLDS (Cloud Pod Architecture) – NEW
- HTTPS (443): Horizon Client access, authentication and RDP tunnel (HTTPS Secure Gateway)
- HTTPS (8443): Used by HTML Access (Blast)
- HTTPS (22443): HTML Access (Blast) to Virtual Desktops
- TCP 9427: Used by Windows multimedia redirection (MMR)
- TCP 32111: USB Redirection
- ESP (Protocol 50) used for Security Server and Connection Server IPSEC communication (requires Windows firewall with Advanced Security to be enabled)
- UDP 500: IPsec negotiation for Security Server and Connection Server communication and pairing.
The first approach I’d like to talk about is simply checking your View Admin Dashboard. Shown below is a screenshot of what you should see in a healthy View Cloud POD environment. If there is any sync issues between sites the “Cluster-VCE2-CS01″, “Connection Servers”, and problem connection broker(s) would show as red. If the problem is isolated to just one broker you can follow the repair steps I mention in this article just for that broker.
The second method to determine if a replica server is out of sync is running the repadmin command on the troubled server.
“repadmin.exe /showrepl localhost:22389 DC=vdiglobal,DC=vmware,DC=int”
The third approach is a little more complicated but I’ve found has the best success for isolating the problem. For this troubleshooting step we will connect to the Global ADLDS database and determine if anything is out of sync, and if so, what server is the culprit.
- Log in to one of the View Connection Servers as Domain Administrator.
- Click Start > Administrative Tools > ADSI Edit.
- In the console window, right-click ADSI Edit and Click Connect to.
- In the Name field type:
View Global ADLDS
- Select “Select a well known Naming Context”
- In the field below “Select a well known Naming Context” select:
View Global ADLDS
- Select “Select or type a domain or server.”
- In the field below “Select or type a domain or server”, type:
- Click OK.
- Click “View Global ADLDS [localhost:22389]” to expand.
- Click “Configuration [localhost:22389]” to expand.
- Click “CN=Sites” to expand.
- Click “CN=Default-First-Site-Name” to expand.
- Click “CN=Servers” to expand.
- You should see now a list of connection brokers.
If you cannot expand any of the connection brokers (as shown above) it means it is out of sync. Notice in the above screenshot the names. “VCE1″ is Site 1, “VCE2″ is Site 2. With this customer there is two sites, i.e. one POD per site. To repair an out of sync connection broker you can simply rebuild it.
- Rebuild Replica (Reference KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2014488)
- Login to the problem connection broker
- Uninstall the local ADAM instance
- Uninstall View
- Re-install View. Once reinstalled the replica should re-join automatically the Cloud POD