As with many software nowadays, XenApp requires minimal configuration and installation decisions, and an experienced administrator can configure the infrastructure in a matter of hours.
Particularly because the installation is a simple process, it is the troubleshooting that sometimes becomes difficult.
It is important to note that a solid grasp of XenApp components, interaction, and workflow is needed before performing troubleshooting.
Most times troubleshooting can be easy, either the solution is straightforward, perhaps because the administrator has experienced this problem in the past, or a simple Internet search for the particular error message will yield a Citrix knowledge-based article or blog post for that particular problem.
In all other cases, troubleshooting needs to be performed in an organized fashion so the solution is reached in the shortest amount of time possible, since many times the problem could involve downtime for a large number of users.
Although seemingly unimportant, one of the most important aspects of troubleshooting is producing a comprehensible problem statement:
How is the problem manifesting itself?
Who is facing the issue?
When did the issue start?
Without clear answers to these questions, an ambiguous problem can undermine efforts for a solution.
Consider the fact that most of the time an issue is generally logged by a service desk or call center (first line of support), who might escalate it to a desktop support team (second line of support), and who will in turn escalate it to a Citrix team (third line of support).
If any piece of information is misunderstood by the analyst logging the incident, this in turn can be propagated to the Citrix team with the information being completely irrelevant to the troubleshooting process or even incorrect.
Consider the following scenario: a user working in the finance department calls the helpdesk and complains that an accounting application stopped working in Citrix. The application was working fine last week. The help desk agent performs a series of basic troubleshooting steps and escalates the problem to the next line of support without requesting additional information.
Consider the following questions:
How many users are affected? Has the application stopped working for other users?
What is the expected behavior of the application?
Are you in the same location as last week or a new office?
Is the application being used by a small or large number of users?
Can the issue be reproduced on a different machine or in a different office?
While each question in itself might not directly lead to a solution, it can narrow down the problem considerably.
For instance, a positive answer to the first question might indicate this is a server or network issue as it affects multiple users.
A positive answer to the third question might indicate this is a network error; the next logical step would be to check whether there are any networking restrictions applied to subnets or IP addresses in the current location.
The fifth question is meant to check whether the issue is specific to a user, machine, or location.
