Desktop Director 2.x, included with Citrix XenDesktop 5.x, is an incredibly useful tool for Operations staff. As a matter of fact, it is even more useful than Desktop Studio, and that is because it not only includes information provided by the VDA, it also includes information from the Windows Remote Management (WinRM) service.
When WinRM is not functional, Desktop Director is unable to provide information that is extremely useful to Operations staff, including metrics for:
- Hard disk,
- personal vDisk profile size,
- personal vDisk apps size,
- ICA latency,
- Citrix policies, and
- Overall Activity.
Is WinRM configured?
- winrm get winrm/config
Is WinRM listening for connections?
- netstat -ano | findstr 5985
Is the WinRM service running?
- Get-Service WinRM
… and of course I check Windows Firewall with Advanced Security Inbound Rules for all Windows Remote Management (HTTP-In) being enabled.
But for one particular client, those troubleshooting steps were not enough and Desktop Director was failing to connect to every single virtual desktop’s WinRM service in the Site. All the commands yielded information indicating that the WinRM service was functional. Specifically, this is the error that Desktop Director reported:
Failed to retrieve data: Machine unresponsive or reported an error (error code 105). View server event logs for further information.
CTX131197 documents this issue, however, I felt it was extremely unlikely that every virtual desktop had a corrupt WinRM listener. I was fairly certain the issue was not a Citrix issue, so I started from the beginning and asked myself, “How does a server establish a remote connection with an endpoint using WinRM?” Before any remote connection can be established, the server must know how to resolve the endpoint’s address. In the case of WinRM, the Service Principal Name (SPN) is what is used to resolved the endpoint’s address through Kerberos name-suffix routing.
A disjoint suffix used by domain members matches an Active Directory domain name in this or another forest. This breaks Kerberos name-suffix routing.
How to check if the WinRM SPN is configured properly:
- setspn -L hostname
I looked for two entries starting with WSMAN/… and found that both entries were there. However, I noticed that the FQDN entry had a different domain name than the Forest that the virtual desktop was joined to. All the virtual desktops in the XenDesktop Site had this mismatch, which led me to this Microsoft article. While Disjoint Namespaces are supported by Microsoft technologies (like WinRM), it is only supported under specific situations. Unfortunately, the DNS Namespace these virtual desktops were assigned to was a shared DNS namespace with desktops in a different Forest.
Once I determined the root cause, and realized the problem was 100% due to architecture, I could only submit my findings and propose a change be made to the architecture. I can only wonder why that architecture decision was made in the first place, but I have a feeling I will come across it again!