Breaking down problems

When troubleshooting difficult cases, after making sure you have understood the problem (and that the information provided is correct and relevant), you must ensure a systematic approach to problem solving.

One strategy that can be used is divide and conquer, where you break down a problem into individual, easily solvable problems.

Considering the previous example where a user calls the helpdesk, one way of breaking down the problem is testing each sub-system individually, for example:

• Are the Citrix servers online and healthy? Check the monitoring systems.
• Is the network link reliable? Run a continuous ping and check whether websites load correctly.
• Is the problem easy to reproduce on any machine or does the problem follow the user?

For instance, in the case of XenApp 7.5/7.6, the following components can be considered:

• Server/desktop operating system machines and virtual delivery agents
• Delivery controller
• StoreFront
• Citrix receiver
• NetScaler Gateway

Going back to our example, one or more components can be causing a problem. For instance, there might be a problem with the Virtual Delivery Agent (VDA) on the server/servers hosting the finance application. This prevents the controller from being able to use the broker agent part of the VDA to communicate with the server.

Another possibility is that the issue is related to authentication. The StoreFront or the NetScaler Gateway (if the user is outside the corporate network) might have problems authenticating users to site resources.

It is important to quickly rule out as many components as possible. For instance, we could quickly test if the Citrix web page is accessible internally (where only the StoreFront component is used) and externally (where we might be reaching a NetScaler Gateway first). If the webpage is accessible internally but not externally, we would need to focus our attention on the NetScaler Gateway.

Alternatively, if, in both scenarios, the webpage does not load, we might focus our attention on the actual servers and/or delivery controllers.

Let's take another example: several users complain that during the day, applications published in XenApp start to become slow every morning.

The users mention that the slowness has been happening for some time, but it has only started to impact them recently.

Consider the following questions:

• How long has the initial slowness been observed (several weeks or months)?
• Around what hour is the impact noticeable?
• How long is the impact—several hours or the entire day?
• How often does the problem occur—on a daily basis or only on specific days?

Answers to the these questions can be tremendously important when dealing with performance-related issues. For example, it is important to establish whether the performance is affected during specific hours/days (to help to isolate whether a scheduled operation is causing the issue) and whether it is consistent (for example, happens every day of the week or happens only on specific dates/days).

Further breaking down the problem could consist of:

• Determining whether there is any correlation between systems tasks (antivirus, backup, web filtering, and so on) and the start of the slowness
• Determining whether the impacted application(s) can be tied to a group of servers, users, or user locations
• Analyzing past monitoring data for any negative performance trends

  Tip

  Use NetScaler Insight Center to collect information about traffic, performance data, and session information for NetScaler Gateway.