User Connection Failures - Cloud Test

If a user complains that his/her connections to a desktop/application failed, then administrators must be able to quickly detect the failure and accurately zero-in on the reason for the failure, so that the problem can be fixed and the user connection can be restored. The User Connection Failures test helps administrators do just that! This test monitors the user connections to each delivery group in a site, promptly detects connection failures, and accurately indicates what caused the failure – is it due to a problem at the client side? is it owing to configuration errors? is it because of machine failures? is it due to the exhaustion of delivery group capacity? Or is it due to the absence of a license?

Target of the test : A Citrix Cloud Control Plane

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each delivery group configured in the control plane

Configurable parameters for the test
Parameter	Description
Test Period	How often should the test be executed.
Host	The IP address of the host for which this test is to be configured.
Port	Refers to the port at which the specified host listens to.
Customer ID	When configuring the Citrix Cloud service, you should have created an API client on the cloud, so that any external program can communicate with the cloud. This API client is tied to a customer ID. The Citrix Cloud API requires this customer ID, when calling REST APIs. To determine the customer ID that is mapped to the API client you created, refer to Determining the Customer ID Mapped to an API Client.
Secure Client File Path	When creating the API client on the cloud, you will be provided with an ID and a Secret for your client. Downloading this information saves a file named secureclient.csv. The eG agent uses the ID and Secret stored in this file to connect to the Citrix Cloud API. This is why, you will have to configure the Citrix Cloud Connectivity test with the full path to the secureclient.csv. Note: Before specifying the path of the secureclient.csv file, make sure that the API client is created and this file downloaded by a valid Citrix cloud user with Read-only administrator rights to virtual apps/desktops. To know how to create this user on the cloud, refer to theCreating a New Citrix Cloud User for Monitoring PurposestopicTo know how this user can create an API client on the cloud, refer to Creating API Client on the Citrix Cloud.
Proxy Host and Proxy Port	If the Citrix Cloud Connector communicates with the Citrix Cloud via a proxy, then, you also need to configure the eG agent on the connector with the proxy server details. This will enable the eG agent to connect to the Citrix cloud without a glitch, and pull metrics. To facilitate this communication. do the following: Specify the IP address/fully-qualified host name of the proxy server, against PROXY HOST. Specify the port at which the Proxy server listens for requests from the eG agent, against PROXY PORT. By default, both these parameters are set to none, indicating that the eG agent does not communicate with the Citrix Cloud via a proxy. Note: Before configuring these test parameters, make sure that the proxy server settings are imported to the eG agent side from the connector. To know how to achieve this, refer to Configuring the eG Agent with Proxy Server Settings. To know what values you should configure these parameters with, do the following: Login to the system hosting the Citrix Cloud Connector being monitored. Open the Internet Explorer browser on that system, and click on the icon provided at the right corner of that browser. Clicking the icon will invoke a menu. Choose Internet Optionsfrom the menu. Then, select the Connections tab in the Internet Options window that appears. Now, click the LAN Settings button. This will open the Local Area Network (LAN) Settings window. In the Proxy Server section of this window, you will find that the Use a proxy server for your LAN check box is enabled. Configure the PROXY HOST and PROXY PORT parameters with the IP address and port numbers displayed in the Address and Port text boxes (respectively) under that check box. If the Use a proxy server for your LAN check box is not enabled, then it means that the connector is not communicating with the cloud via a proxy. In this case, you need not change the default configuration for these parameters.
Report by Machine Type	By default, this flag is set to Yes indicating that the individual descriptors of this test - i.e., the delivery groups- are classified based on their machine type; in other words, the delivery groups will be listed either under Server OS Machines or Desktop OS Machines based on their machine type. If you do not want to group the delivery groups based on their machine types, set this flag to No.
Region Endpoint	By default, US is chosen from this list indicating that this test will report metrics for those organizations whose users and resources are located in the United States region. Sometimes, the eG agent may collect the required metrics with a minor time delay due to the users and resources being monitored are in a different region. To avoid such time delays and to ensure end-user proximity and offer the best user experience, administrators are allowed to change the region based on where most of the users and resources are located. For instance, if the users and resources are located in the Asia-Pacific South region or approximately nearer to the Asia-Pacific South region, then, administrators need to choose 'AP-S' from this list. However, from this list, administrators are required to choose only the region that they had chosen when they signed in for the first time after onboarding their organization to the target Citrix Cloud.
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

Client connection failures

Indicates the number of connections to this delivery group that failed due to a problem at the client side.

Number

A high value for this measure is a cause for concern. In such situations, use the table below to understand the common causes for these failures:

Cause	Description
Connection timeout	The client did not connect to the VDA after the VDA was prepared for session launch. The session was successfully brokered, but a timeout occurred while waiting for the client to connect to the VDA. This could be caused by issues that prevent the client from effectively connecting to the VDA, such as firewall settings, network interruptions, or settings that prevent remote connections.
Ticketing	Failure occurred during ticketing, indicating that the client connection to the VDA does not match the brokered request. A launch request ticket is prepared by the broker and delivered in the ICA file. When the user attempts to launch a session, the VDA will validate the launch ticket in the ICA file with the broker. A failure can occur if ICA file corruption occurs or if a user is attempting to make an unauthorized connection.
Active Session Reconnect Disabled	The specific application or desktop session that the user attempted to launch is active and connected to a different endpoint. However, the user’s current endpoint is unable to connect to the active session.

To know what action to take against each of the causes discussed above, use the table below:

Cause	Action
Connection timeout	Check in the Director console to see if the client currently has an active connection, which means no user would be currently impacted. If no session exists, review the event logs on the client and VDA for any errors. Resolve any issues with network connectivity between the client and VDA
Ticketing	Verify that the user should have access to the application or desktop based on the user groups defined in the delivery group(s). Instruct the user to attempt to re-launch the application or desktop to determine whether this is a one-off issue. If the issue recurs, review the client device event logs for errors. Verify that the VDA to which the user is attempting to connect is registered. If unregistered, review the event logs on the VDA and resolve any issues with registration.
Active Session Reconnect Disabled	On the controllers, verify that Active Session Reconnection is enabled via the DisableActiveSessionReconnect in the registry, by setting value to 0 under HKLM/Software/Citrix/Desktop/Server

Configuration errors

Indicates the number of connections to this delivery group that failed due to configuration errors.

Number

A high value for this measure is a cause for concern. In such situations, use the table below to understand the common causes for these errors:

Cause	Description
Application Disabled	The application has been disabled by the administrator and thus cannot be accessed by end users.
Maintenance Mode	The VDA, or the delivery group to which the VDA belongs, is set in maintenance mode.
Resource Unavailable	The application or desktop to which the user is attempting to connect is not available. This application or desktop may no longer exist, or there are no VDAs available to run it. This can be caused if the application or desktop has since been unpublished, or if the VDAs hosting the application or desktop have reached maximum load or are set in maintenance mode.
Disallowed Protocol	The ICA and/or RDP protocols are not allowed.

To know what action to take against each of the causes discussed above, use the table below:

Cause	Action
Application Disabled	Enable the relevant application and instruct the user to attempt to reconnect if the application is intended to be available for production use.
Maintenance Mode	Determine whether maintenance mode is required. Disable maintenance mode on the delivery group or machine in question if it is not needed and instruct the user to attempt to reconnect.
Resource Unavailable	Verify that the application or desktop is still published and that the VDAs are not in maintenance mode. Verify whether the server OS VDAs are at full load. Provision additional server OS VDAs if necessary. Verify whether there are desktop OS VDAs available for connections. Provision additional desktop OS VDAs if necessary.
Disallowed Protocol	Run the Get-BrokerAccessPolicyRule PowerShell command on a Delivery Controller and validate that the “AllowedProtocols” value has all the desired protocols listed. This should only occur in case of a misconfiguration.

Machine failures

Indicates the number of connections to this delivery group that failed due to machine failures.

Number

A high value for this measure is a cause for concern. In such situations, use the table below to understand the common causes for these failures:

Cause	Description
Spin Up Failed	VDA could not be powered-on for session launch. This is a hypervisor-reported issue.
No Session to Reconnect	The client attempted to reconnect to a specific session, but the session has been terminated.
Registration Timeout	The VDA was powered on, but a timeout occurred while it was attempting to register with the Controllers.
Communication Error	The Controller attempted to send information to the VDA, such as a request to prepare for a connection, but an error occurred in the communication attempt. This may be caused by network disruptions.
Refused	The Controller sends a request to the VDA to prepare for a connection from an end user, but the VDA actively refuses this request.
Session Preparation	Session prepare request from the Controller to the VDA failed. This may be caused by communication issues between the Controller and the VDA, issues experienced by the Broker service while creating a prepare request, or the VDA’s inability to accept the request due to reasons such as network issues.
Configuration Set Failure	The Controller failed to send required configuration data, such as policy settings and session information, to VDA during session launch. This may be caused by communication issues between the Controller and the VDA, issues experienced by the Broker service while creating a configuration set request, or the VDA’s inability to accept the request due to reasons such as network issues.
Machine Not Functional	The VDA is not functional. Some causes of this failure include: the VDA was removed from the delivery group, the VDA is unregistered, the VDA power state is unavailable, or the VDA is experiencing internal issues.

To know what action to take against each of the causes discussed above, use the table below:

Cause	Action
Spin Up Failed	Validate the machine is still powered off. Attempt to start the machine through Studio. Review hypervisor connectivity and permissions if this fails. If the VDA is a PVS-provisioned machine, verify the machine is up in the PVS console. If not, validate the machine is assigned a vDisk and log into hypervisor to reset the VM.
No Session to Reconnect	Retry the workspace control reconnection
Registration Timeout	Verify that the Citrix Broker service is running on the DDC and the Desktop Service is running on the VDA. Start each if stopped. If already started, restart the Desktop Service on the VDA to restart the registration process and validate the VDA registers successfully. Confirm the DDCs configured for the VDA are accurate via the details in the Application event log. Verify the DDC and VDA can successfully communicate via ping. If not, resolve any firewall or network routing issues.
Communication Error
Refused
Session Preparation
Configuration Set Failure
Machine Not Functional	Verify that the VDA is in a delivery group. If not, add it to the appropriate delivery group. Verify that the VDA shows as powered on in the Studio console. If power state is Unknown for several machines, resolve any issues with connectivity to hypervisor or host failures. Verify that the hypervisor hosting the VDA is not in maintenance mode. Restart the VDA once the above items have been addressed.

Unavailable capacity

Indicates the number of connections to this delivery group that failed because the configured capacity of the machines was consumed.

Number

A high value for this measure is a cause for concern. In such situations, use the table below to understand the common causes for these failures:

Cause	Description
Session Limit Reached	All VDAs are in use and there is no capacity to host additional sessions. This may occur if all VDAs are in use (for desktop OS VDAs), or all VDAs have reached the configured maximum concurrent sessions allowed (for server VDAs).
Max Concurrent Instances Exceeded	The maximum number of instances of an application has been reached. No additional instances of the application can be open on the VDA. This issue is generally related to the application limits feature.
Max Instances Per User Exceeded	The user is attempting to open more than one instance of an application, but the application is configured to allow only a single instance of the application per user. This issue is generally related to the applications limits feature.

To know what action to take against each of the causes discussed above, use the table below:

Cause	Action
Session Limit Reached	Verify whether there are any VDAs in maintenance mode and disable maintenance mode if it is not needed to free up additional capacity. Consider increasing the Maximum Number of Sessions Citrix policy setting, which will allow more sessions per server VDA. Consider adding additional server OS VDAs. Consider adding more desktop OS VDAs.
Max Concurrent Instances Exceeded	Consider increasing Limit the number of instances running at the same time to application setting to a higher value if licensing permits.
Max Instances Per User Exceeded	Only one instance of the application is allowed per user by design. If multiple instances per user are required, consider de-selecting the Limit to one instance per user setting in order to allow users to open more than one instance of an application.

Unavailable licenses

Indicates the number of connections to this delivery group that failed because of the absence of a license.

Number

A high value for this measure is a cause for concern. In such situations, use the table below to understand the common causes for these failures:

Cause	Description
Licensing	The licensing request failed. This could be caused by issues such as insufficient number of licenses, or the license server has been down for more than 30 days.
License Feature Refused	The feature being used is not covered in the existing licenses.

To know what action to take against each of the causes discussed above, use the table below:

Cause	Description
Licensing	Determine whether the license server is online and reachable. Resolve any network connectivity issues to the license server and/or reboot the license server if it appears to be malfunctioning. Determine whether there are sufficient licenses in the environment and allocate more if necessary.
License Feature Refused	Contact a Citrix sales representative to verify the features that are covered by the existing Virtual Apps/Desktop license edition and type.