Unregistered Desktops Test

XenDesktop relies upon a software component installed on each virtual desktop (the Virtual Desktop Agent) being in communication with one of the controllers in a XenDesktop site. This state is referred to as the Virtual Desktop Agent being registered with a controller. If communication fails for any reason, the Virtual Desktop Agent is said to have failed to register with a controller. It is then not possible for XenDesktop to broker a connection to the virtual desktop in question, and the virtual desktop becomes a wasted resource.

If this is to be avoided, administrators should be able to quickly detect which virtual desktops are not registered with any controller in the farm, figure out the reasons for this condition, and fix the problem, so that the virtual desktop agent is able to communicate with the controller. This is where the Unregistered Desktops test helps!

Using this test, administrators can be instantly alerted to unregistered desktops in each desktop group in a broker farm. The detailed diagnosis of the test reveals the names of the unregistered desktops.

Note:

Since this test reports the number and names of unregistered desktops at the farm-level, it will report the same metrics when executed on any controller in a farm. Therefore, if you are monitoring multiple controllers in a farm, it is recommended that you run this test for only one controller, and disable this test for other controllers in that farm.

Target of the test : A Citrix Delivery Controller 5.x

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each desktop group managed by a desktop broker farm.

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 DDC listens to.
Detailed Diaganosis	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

Unregistered desktops

Indicates the number of unregistered desktops in this desktop group.

Number

A high value is indicative of too many unregistered desktops in a group.

Some of the common reasons for registration failures are as follows:

Reason	Resolution
Improper firewall configuration	If the firewall on the virtual desktop has not had the appropriate exclusions configured to enable communication with controllers, the registration fails. Reconfigure and re-enable the firewall.
Incorrect DNS configuration	If the virtual desktop or the controller sees an incorrect IP address for the other party, registration fails. In this case, fix the problem with your DNS configuration, and restart the virtual desktop, the controller, or both, as appropriate.
Time synchronization not properly configured	The communication between virtual desktops and controllers is secured using Kerberos. This relies on Tickets with a limited life span.
	If the difference in system time between the two ends of the communication is too great, the Tickets are always considered to have timed out when they are accessed and communication fails. Check that the system time on all systems is within a reasonably small margin (the default domain-wide Kerberos setting is five minutes).
Domain membership problems	Under some circumstances, it can appear that a machine (virtual desktop or controller) is a part of a domain, but in fact, it is not (for various reasons). This can cause problems with the secure communication between virtual desktops and controller. Try removing the machines in question from their domains (temporarily moving them into a workgroup, for example) and then subsequently rejoin them to their domains. When the subsequent system restart has completed, check to see if registration has been successful.
Service Principal Names (SPNs)	Communication between virtual desktops and controllers uses Microsoft’s Windows Communication Foundation (WCF). The services implementing the communication endpoints use the computer’s identity. Thus, WCF’s mutual authentication model uses the SPN associated with the respective computer accounts (by default, HOST/host’s-fully-qualified-domain-name). The controller determines the virtual desktop’s SPN after inspecting the servicePrincipalName attribute of the associated computer account in Active Directory. You can inspect the virtual desktop’s computer account using tools such as Active Directory Explorer. If the servicePrincipalName attribute does not include an entry with the computer’s fully qualified domain name, try editing it manually, and check to see if that fixes registration problems.
Multiple network adapters	If your virtual desktops contain multiple network adapters that can be used to communicate with the controllers, this might cause the security negotiation to fail.
Virtual desktop not added to the site	If you see Virtual Desktop Agent event log entries on the worker suggesting registration failure, complete the following steps: Check that the virtual desktop is correctly added to the correct XenDesktop site. This must be done from both the point of view of the virtual desktop and of the XenDesktop site itself. In Desktop Director, enter the name of the machine into the search box – the machine name must appear in the drop-down that appears below the search box as you type the name. If it does not, it means that the machine has not been added to the site correctly. Check that the machine in question is a member of the correct site, check that the list of controllers listed in the event log entry with Event ID = 1010 on the virtual desktop is correct for your XenDesktop site. If it does not, the virtual desktop has not been correctly configured to be part of the site.

Using the detailed diagnosis of this measure, you can identify the unregistered desktops, the virtual host on which these desktops are operating, when last these virtual desktops attempted to connect to the broker, and why that connection attempt failed. This way, administrators can quickly determine the reason for the ‘unregistered’ state of the desktops and endeavour to fix it, so that no desktop remains a wasted resource.

Figure 1 : Detailed diagnosis of Unregistered desktops measure