I’m working on a nice Login VSI benchmarking project at a customer. This is an VDI environment of 1500 machines on vSphere hosts (FlexPod hardware which has Cisco UCS Servers, Cisco Nexus switches and NetApp storage built in). We’ll be using the NetApp Rapid Cloning functionality instead of XenDesktop Machine Creation Services. I probably will blog about it when we used it and have a decent overview.
The broker software of choice is XenDesktop 5.6. Now, I did some XenDesktop installations before, but never on this scale. XenDesktop is a relative next-next-finish install, so I didn’t think I would run into problems at the installation stage of the Desktop Delivery Controllers (DDC’s). Well… I was mistaken.
The installation of the DDC’s went in a breeze, no issues (ok, the installation of XD is slooooow… but that’s not really a big problem). There were 2 machines designed to be dedicated DDC’s. Another 2 machines were inteded to have the Desktop Studio and Desktop Director installed. Since you need the Desktop Studio to configure the DDC’s, I logged in to one of the servers which was hosting the Desktop Studio. First thing I noticed when I first launched the Desktop Studio, was that I couldn’t use the “Desktop Deployment” option. It was grayed out. In fact, the only option available was “Join existing deployment”. Obviously, there was no connection to the DDC.
There’s a nice troubleshooting tool out there called XDPing. It helps you troubleshoot connectivity issues in a XenDesktop environment. I ran this tool on the server which was hosting the Desktop Studio.
Service = Invalid response <HTTP/1.1 503 Service > ERROR
This was the response of XDPing. Hmmm, looks like the broker service (or another XenDesktop-related service) was not running or someting? So I ran the tool on one of the DDC’s. Exactly the same error. It showed me that the server itself was pingable, the services were running. I enabled logging on the broker, but that didn’t shine much light on the problem.
All of a sudden, after a couple of hours troubleshooting, I remembered that I had this issue before in my lab environment. It was with an older version of XenDesktop, but I remembered that it had to do something with DNS configuration.
Now, since this environment is just a proof-of-concept, all infrastructure servers (like AD, DNS, DHCP, SQL, etc.) were built in a separated environment. So DNS and AD have been built up from scratch. I checked DNS and came to the conclusion that there was no reverse lookup zone for the network that these machines were in. So I created the reversed lookup zones and re-installed the DDC software (I actually don’t know if a complete reinstallation was needed, but simply restarting the services didn’t help). After the reinstallation, configuration worked like a breeze. (by the way, the uninstall of the DDC software didn’t really go without problems, but I will blog about this in another post)
Long story short: make sure you have your reverse lookup zones configured prior to installing the DDC software. You could also note this as a RTFM for me… As stated in the XenDesktop 5 documentation:
Configure Active Directory to include a DNS server, which must be configured to have both forward and reverse look-up zones.