Some Citrix XenDesktop Troubleshooting Tips

I have recently had to build a new Citrix XenDesktop environment for some testing which included Citrix Provisioning Server and Citrix XenServer. Along the way, I had various issues and struggled to find a single, comprehensive, troubleshooting article so I am going to have a stab at it here since I had to go through various tests in order to sort my issues. Having said this, there are some very good technotes on the Citrix web site here – http://support.citrix.com/product/xd/v3.0/technote/

1. Enable logging for the Workstation Agent and ensure that access to the C$ share of the master XenDesktop image is enabled, including a firewall exception for file sharing. This is so that you can get at the log file without having to log on interactively to the image. See this article for how to enable the logging by a simple edit to the WorkstationAgent.exe.config file:  http://support.citrix.com/article/CTX117452 

   Obviously ensure that the Workstation Agent (Citrix Desktop Service) is successfully starting, as are other Citrix services, and the log shows it registering with the DDC.

2. The event logs are also obviously another place to look when things fail although this can be tricky if your VM has been connected enough to want to reboot when the connection attempt has failed.
3. You can also enable logging for the Desktop Delivery Controller service which is detailed in the link above. Ensure that the DDC service and other Citrix ones start successfully.
4. PortICA logging can be enabled – http://support.citrix.com/article/CTX118837 – which could show potential ICA problems. It didn’t for me but will stay enabled in my base image whilst I am still testing.
5. Citrix tracing tool (CDF – Citrix Diagnostic Facility) – this didn’t help me as it only currently supports a small number of client side features such as USB. It can also be run on the machine running the Workstation Agent but I didn’t do this.  http://support.citrix.com/article/CTX120269
6. I did have some errors when using the XenDesktop Setup Wizard so I followed the steps to get a log file for this. I couldn’t get the log produced via the command line so ended up modifying the .config file as described here: http://support.citrix.com/article/CTX118278 

   My issues actually turned out, I think, to do with the fact that the template I was specifying in the wizard had an 8GB disk attached (it was my Gold Build VM that was booting off the PvS disk but still had the original hard drive in case I needed to rebuild the PvS disk) so each new VM created by the wizard was creating a new 8GB disk and I simply didn’t have the storage for it (not that I got an error suggesting this). I therefore created a new VM in XenServer that had the memory, NIC and CPUs I wanted but had no hard disk so actually didn’t have an OS installed (it never even got booted). This doesn’t matter since the OS comes from the vdisk/vhd you specify, separately, in the wizard.

7. Check that you can logon with the required accounts to the VMs in your XenCenter/XenServer console. This should show any domain joining or account issues, e.g. expiry or permissions. Also check network connectivity to/from them.
8. Fire up your gold image VM, since it should be on a standard image disk so the changes will be lost when it shuts down, add it to a new desktop group without a hosting infrastructure so that you just use the name of the VM in the group. This should tell you if the problem was something funny about the desktop group or the VMs that comprised it.
9. My issue was that I was launching the connection from Web Interface but I wasn’t getting a session, just a failure popup – “Unable to connect to the desktop. This may be a temporary problem. Click OK and then try starting the desktop again. If the problem persists, contact your system administrator”. Before acknowledging the failure popup, look in your %temp% folder for the ICA file that it dynamically created. It won’t be a .ica file but instead will most likely be a .tmp file although will probably start “ica*”– easily spotted by modification time, particularly if you sort on modification time. It is actually the argument to cdsbar.exe if you look in Task Manger on Vista or with SysInternals/Microsoft Process Explorer. Open the ica file in notepad and check that it makes sense – e.g. is connecting to the right thing (“Address=”) and that the entity can be resolved/contacted. Note that the ica file, in best Mission Impossible style, will self destruct, i.e. be deleted, when you ok the failure popup thanks to the “RemoveICAFile=On” line. Note also that there is little point in saving the ica file for later use since it has a logon ticket in there which most likely will have expired.
10. This leads on to checking that port 1494 is accessible in the virtual desktop by telnetting to it. However, port 1494 is only alive for a brief while after the connection is initiated so wait a few seconds after you have clicked on the icon to launch the session in Web Interface, or Program Neighborhood, before trying the telnet. When accessing a pool, look at the temporary ICA file to figure out which machine to check or reduce the pool to a single machine. We are not really looking for anything here other than the connection succeeds although you will probably see the characters “ICA” displayed.
11. As by this stage all logs were looking fine and port 1494 was working, I put on a network monitor, in this case SysInternals/Microsoft Process Monitor, on my client machine (the one accessing Web Interface) and filtered on wfica32.exe. This is when I found that some traffic was going through my proxy that I hadn’t allowed for – bingo, problem solved when the proxy was disabled. In my defence, I had tried accessing from a different client (this should probably be a separate line item in this troubleshooting “guide”) but that had also failed, albeit probably for different reasons as it wasn’t using a proxy.
12. Watch for proxies! Obviously configure them as necessary or disable them.
13. I did have some “funnies” with my XP VMs created by the XenDesktop Setup Wizard and running off PvS. I think they were because after creation I had switched the master disk away from Standard Image mode. My excuse is that you have to manually hit F5 to do a refresh after changing vDisk properties and I didn’t! I was actually getting the error described here: http://forums.citrix.com/message.jspa?messageID=1393521 

    Sometimes the streaming console (StreamConsole.exe) on the PvS box can help diagnose these kinds of issue. Unfortunately it didn’t in this case.

14. I also got caught by my base image having miniscule event log sizes (64KB) so even though they weren’t up for long, it was enough for them to fill up and not to overwrite so it was back to the base image to set larger sizes and set them to overwrite as needed.