So you’ve got a user reporting a connectivity problem to your XenDesktop infrastructure, which is published to the web via StoreFront and NetScaler Gateway. Here are the basic troubleshooting steps for moving forward when you don’t have nearly enough information.

Note that these steps are generally more useful for established, operational environments. If you’re troubleshooting a new environment, there are plenty of configuration points that you should validate first before blaming the users’ laptop.

• Check for errors on your StoreFront servers. Keep in mind that these are typically load-balanced, so the users’ connectivity could be starting on any of them. Check the Windows Application logs, the Windows System logs, and the Citrix Delivery Services logs (in event viewer, under “Applications and Services Logs”). Make sure you’re looking at the appropriate timeframe for the event that is being reported.
• Check for errors on the Delivery Controllers. These would just be in Windows Applicaton or Windows System logs – there’s no dedicated log for DDCs that’s worth reviewing.
• If the user already has a session established and is getting errors trying to reconnect (which you can determine using Director or Studio), check the event logs on the Terminal Server or virtual desktop that their session is on.

If you’re unable to come up with any indicators from these points, it’s possible that the problem is from outside your infrastructure and the client is having trouble calling back in to complete the brokering process. Especially for remote users, these sorts of errors can be caused by things outside of your control (the users’ internet connection at their house or hotel, the web browser that they’re using to access StoreFront, the clock on their laptop).

It’s always a good idea to make sure that they’re on a recent version of the Receiver Client. This is especially true for Mac clients – in my experience, the users aren’t pestered by the Mac client as frequently and subsequently it doesn’t get updated often.

If it’s only a single user reporting the problem, it is more worthwhile to start at the client and troubleshoot from there. If you have multiple users reporting connectivity issues at the same time, you might consider starting troubleshooting in your infrastructure instead.