Citrix HDX Desktop Users Test

To ensure that users are able to access desktops on-demand, administrators must closely track that user’s accesses, promptly detect probable access latencies, diagnose its root-cause, and take steps to avert it, well before that user notices and complains. To achieve this, administrators can use the Citrix HDX Desktop Users test. This test automatically discovers the users who are currently accessing virtual desktops in a XenDesktop infrastructure, and for each user, reports the latencies that user experienced when interacting with the desktops. This way, the test quickly and accurately points administrators to those desktop users who are experiencing slowness, and also leads them to what is causing the slowness – the network? or the server hosting the desktops? If a latent network is causing the slowness, then the test provides administrators with detailed insights into network performance and enables them to rapidly figure out where the bottleneck lies - on the client-side network? or on the server-side network?

Target of the test : An AppFlow-enabled ADC Appliance

Agent deploying the test : A remote agent

Outputs of the test : One set of results for every user who is currently connected to an virtual desktop

Configurable parameters for the test
Parameter	Description
Test period	How often should the test be executed. It is recommended that you set the test period to 5 minutes. This is because, the eG AppFlow Collector is capable of capturing and aggregating AppFlow data related to the last 5 minutes only.
Host	The host for which the test is to be configured.
Cluster IPs	This parameter applies only if the ADC appliance being monitored is part of a ADCcluster. In this case, configure this parameter with a comma-separated list of IP addresses of all other nodes in that cluster. If the monitored ADC appliance is down/unreachable, then the eG AppFlow Collector uses the Cluster IPs configuration to figure out which other node in the cluster it should connect to for pulling AppFlow statistics. Typically, the collector attempts to connect to every IP address that is configured against Cluster IPs, in the same sequence in which they are specified. Metrics are pulled from the first cluster node that the collector successfully establishes a connection with.
Enable Logs	This flag is set to No by default. This means that, by default, the eG agent does not create AppFlow logs. You can set this flag to Yes to enable AppFlow logging. If this is done, then the eG agent automatically writes the raw AppFlow records it reads from the collector into individual CSV files. These CSV files are stored in the <EG_AGENT_INSTALL_DIR>\NetFlow\data\<IP_of_Monitored_NetScaler>\hdxappflow\actual_csv folder on the eG agent host. These CSV files provide administrators with granular insights into the HDX appflows, thereby enabling effective troubleshooting. Note: By default, the eG agent creates a maximum of 10 CSV files in the actual_csv folder. Beyond this point, the older CSV files will be automatically deleted by the eG agent to accommodate new files with current data. Likewise, a single CSV file can by default contain a maximum of 99999 records only. If the records to be written exceed this default value, then the eG agent automatically creates another CSV file to write the data. If required, you can overwrite these default settings . For this, do the following: Login to the eG agent host. Edit the Netflow.Properties file in the <EG_AGENT_INSTALL_DIR>\NetFlow\config directory. In the file, look for the parameter, csv_file_retention_count. This is the parameter that governs the maximum number of CSV files that can be created in the auto_csv folder. By default, this parameter is set to 10. If you want to retain more number of CSV files at any given point in time, you can increase the value of this parameter. If you want to retain only a few CSV files, then decrease the value of this parameter. Next, look for the parameter, csv_max_flow_record_per_file. This is the parameter that governs the number of flow records that can be written to a single CSV. By default, this parameter is set to 99999. If you want a single file to accommodate more records, so that the creation of new CSVs is delayed, then increase the value of this parameter. On the other hand, if you want to reduce the capacity of a CSV file, so that new CSVs are quickly created, then decrease the value of this parameter. Finally, save the file.
DD Frequency	Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement

Description

Measurement Unit

Interpretation

Desktop launches

Indicates the number of desktops launched by this user.

Number

To know which desktops were launched by this user, use the detailed diagnosis of this measure.

Session status

Indicates the current status of this user's sessions.

The values that this measure can take and the numeric values that correspond to each measure value are listed in the table below:

Measure Value	Numeric Value
Active	0
SR successful	1000
Existing ICA session got terminated	1001
Existing ICA connection got terminated and SR failed	1002
Existing ICA connection terminated and SR failed and client is trying to do ACR and is successful	1003

Note:

Typically, this test reports the Measure Values in the table above to indicate session status. In the graph of this measure however, the same is indicated using the numeric equivalents only.

RTT

Indicates the screen lag experienced by this user while interacting with desktops.

Msecs

A high value for this measure is indicative of the poor quality of a user’s experience with desktops.

To know the reason for this below-par UX, compare the value of the WAN latency, DC latency, and Host delay measures of that user.

WAN latency

Indicates the average latency experienced by this user due to problems with the client side network.

Msecs

A high value for this measure indicates that the client side network is slow.

If the value of the RTT measure is abnormally high for a user, you can compare the value of this measure with that of the DC latency and Host delay, and measures of that user to know what is causing the slowness – is it the client side network? the server side network? or the server hosting the desktops?

DC latency

Indicates the average latency experienced by this user due to problems with the server side network.

Msecs

A high value for this measure indicates that the server side network is slow.

If the value of the RTT measure is abnormally high for a user, you can compare the value of this measure with that of the WAN latency and Host delay measures of that user to know what is causing the slowness – is it the client side network? the server side network? or the server hosting the desktops?

Host delay

Indicates the delay that this user experienced when waiting for the host to process the packets.

Msecs

A high value for this measure indicates a processing bottleneck with the server hosting the desktops.

If the value of the RTT measure is abnormally high for a user, you can compare the value of this measure with that of the WAN latency and DC latency, measures to know what is causing the slowness – is it the client side network? the server side network? or the server hosting the desktops?

Bandwidth

Indicates the bandwidth used by this user.

Kbps

Ideally, the value of this measure should be low.

A high value indicates excessive bandwidth usage by the user.

Compare the value of this measure across users to know which user is consuming bandwidth excessively.

Bytes

Indicates the total bytes consumed by this user's sessions.

Bytes

Compare the value of this measure across users to know which user has the maximum throughput and which has the least.

Client side retransmits

Indicates the number of packets retransmitted on the client side connection during the last measurement period.

Number

Ideally, the value of these measures should be 0.

Server side retransmits

Indicates the number of packets retransmitted on the server side connection during the last measurement period.

Number

ACR counts

Indicates the total number of times the client automatically reconnected this user to sessions.

Number

The Automatic Client Reconnect (ACR) policy setting, when enabled, allows automatic reconnection by the same client after a connection has been interrupted. Allowing automatic client reconnect allows users to resume working where they were interrupted when a connection was broken. Automatic reconnection detects broken connections and then reconnects the users to their sessions.

Session reconnects

Indicates the number of times this user's sessions reconnected.

Number

This measure includes only those times a user reconnected to a disconnected session by mechanisms other than the ACR setting.

Client side NS delay

Indicates the average latency experienced by this user, which was caused by the ADCappliance when ICA traffic flowed from client network to server network.

Msecs

A high value for these measures indicates a processing bottleneck with the ADCappliance.

If the value of the WAN latency measure is abnormally high for a desktop user, you can check the value of the Client side NS delay measure to determine if the network delays noticed on the client side were caused by the NetScaler's lethargy in processing traffic from the client.

If the value of the DC latency measure is abnormally high for a desktop user, you can check the value of the Server side NS delay measure to determine if the network delays noticed on the server side were caused by the NetScaler's lethargy in processing traffic from the server.

Server side NS delay

Indicates the average latency experienced by this session, which was caused by the ADCappliance when ICA traffic flowed from server network to client network.

Msecs

The detailed diagnosis of the Session status measure provides additional details of a user. If the status of a user's sessions is abnormal, you can use these details to know from which client the user is connecting, the client type and version, which desktop the user is connecting to, the start time, and the uptime of the session. This will help in troubleshooting the abnormal session status.

Figure 5 : The detailed diagnosis of the Session status measure reported by the Citrix HDX Desktop Users test

Use the detailed diagnosis of the Desktop launches measure to know which desktop(s) was recently launched by the user.

Figure 6 : The detailed diagnosis of the Desktop launches measure of the Citrix HDX Desktop Users test