User Connection Failures

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 XenDesktop Director

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each delivery group configured in the site.

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 the test is being configured.

Port

The port number at which the specified Host listens to. By default, this is 80.

Controller IP Address

To monitor a site and pull metrics on its performance, the eG agent communicates with a delivery controller in that site. If the target site contains only one controller, then, you need to configure the Controller IP Address parameter with the IP address of that controller, so that the eG agent can use that controller for monitoring the site. Note that in this case, if the controller stops functioning for any reason, the eG agent will not be able to monitor the site any longer. Some sites may be configured with multiple delivery controllers to ensure high-availability, and to optimize and load-balance user connections. When monitoring such a site, you have the option of configuring the Controller IP Address parameter with a comma-separated list of controllers. For instance, the list should be in the following format: 192.160.1.10,198.160.1.11,198.160.1.12. In this case, the eG agent checks the availability of each configured controller at run time, picks the controller that is up and running at that time, and communicates with that controller for collecting metrics on site performance. This way, you can ensure that the non-availability of a single controller, does not impact site monitoring.

Controller Port

Specify the port number of the delivery controller in the site with which the eG agent should communicate for collecting performance metrics.

Username
and Password

To connect to a delivery controller and pull out metrics from it, the eG agent requires Farm Administrator rights. In order to configure the eG agent with Farm Administrator privileges, specify the credentials of the Farm Administrator in the Username and Password text boxes. This user should also be assigned the Allow log on locally privilege on the Citrix Virtual Apps/Desktops Site 7.x host. The steps for assigning the Allow log on locally privilege are explained in the Pre-requisites for monitoring the Citrix Virtual Apps/Desktops Site 7.x topic.

Confirm Password

Confirm the Password by retyping it here.

Fully Qualified Domain Name

Here, specify the fully-qualified name of the domain to which the specified controller belongs.

SSL

Indicate whether/not the controller used for metrics collection  is SSL-enabled. By default, this flag is set to Yes.

Report by Machine Type

If you want the results of this test to be grouped by machine type then set this flag to Yes. In this case therefore, the machine types (desktop or server OS machines) will be the primary descriptors of this test; expanding them will reveal the secondary descriptors – i.e., the delivery groups containing machines of each type. If you want the results of this test to be indexed only by the names of delivery groups, then set this flag to No.

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 XenApp/XenDesktop license edition and type.