Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop

Citrix Virtual Apps and Desktops, formerly XenDesktop, fits the enterprise need to bring both VDI and apps into a user-centric experience.

This article contains information about Troubleshooting Virtual Delivery Agent Registration with Controllers in XenDesktop.

Background

XenDesktop relies upon a software component installed on each virtual desktop (the Virtual Delivery Agent) being in communication with one of the controllers in your XenDesktop site. This state is referred to as the VDA being registered with a controller. If communication fails for any reason, the VDA 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.



The VDA logs problems with registration in its event log, as shown in the following example: 

A custom view can be created by selecting Citrix Desktop Service and Citrix ICA service as Source. Alternatively, these events can be found in Application event long.

The details of the four most recent event log entries are:
 

Level	Date and Time	Source	Event ID
Warning	12/8/2010 10:03:59 AM	Citrix Desktop Service	1022	"The Citrix Desktop Service failed to register with any controllers in the last 2 minutes.  The service now tries to register with controllers at a reduced rate of every 2 minutes."
Warning	12/8/2010 10:01:55 AM	Citrix Desktop Service	1017	"The Citrix Desktop Service failed to register with any delivery controller.  The service retries registering with controllers in approximately 8 seconds.  Please ensure that at least one delivery controller is available for Virtual Desktop Agents to register with. Refer CTX117248 for further information."
Warning	12/8/2010 10:01:55 AM	Citrix Desktop Service	1002	"The Citrix Desktop Service cannot connect to the delivery controller 'http://DDCXD501.demo.net:80/Citrix/CdsController/IRegistrar' (IP Address '10.10.220.10') Check that the system clock is in sync between this machine and the delivery controller. If this does not resolve the problem, refer to  CTX117248 for further information. Error Details: Exception 'An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.' of type 'System.ServiceModel.Security.MessageSecurityException'.."
Information	12/8/2010 10:01:55 AM	Citrix Desktop Service	1010	The Citrix Desktop Service successfully obtained the following list of 1 delivery controller(s) with which to register: 'DDCXD501.demo.net (10.10.220.10)'.

 
If the virtual desktop in question has been added to a desktop group in your XenDesktop site, you will also see evidence of the VDA's failure to register with any controllers in the site, in the administration consoles. The following screen shot shows how this looks in Citrix Director.
Here, the State column provides information about the registration state of the desktop machine. A value of UnRegistered indicates that registration has not successfully completed.

Troubleshooting Registration Problems

Virtual Desktop not Added to the Correct Site

If you see VDA event log entries on the worker suggesting registration failure, complete the following steps:

1. 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.
2. 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.
3. 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.

Note: There are three ways of configuring site membership on a virtual desktop: registry-based (default), and active-directory-based and Auto Discovery of Controllers. For further details, see http://support.citrix.com/proddocs/topic/xendesktop/xd-library-wrapper.html.

Virtual Desktop Firewall not Properly Configured

If the firewall on the virtual desktop has not had the appropriate exclusions configured to enable communication with controllers, the registration fails. As an experiment, try disabling all firewall software on the virtual desktop and restart it. If registration now succeeds, the problem points to misconfiguration of the firewall; reconfigure it and re-enable it.
Note: It is not advisable to run with the firewall permanently disabled on virtual desktops.

Domain Name Services (DNS) not Properly Configured

If the virtual desktop or the controller sees an incorrect IP address for the other party, registration fails. To see if this is an issue, try the following: on both machines, start a command shell window and run the following commands:

ipconfig
ping <othermachine.domain.com>

Both machines must be able to ping each other successfully with DNS name (using the fully qualified domain name (FQDN) including the domain.com bit and not the simple NetBIOS name). It is important that, the IP address reported for the remote machine using the ping command in each case must match the IP address reported using ipconfig command on the relevant machine.
If there is any discrepancy, 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).
Note: Check the Windows Time Service is running on the VDA, if the service is in stopped state, try starting the service and check if this has fixed the Time Sync issue and VDA is registered now.
If this is the issue, for pooled random catalog correct the Windows Time Service on the master image and update the VDAs.

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. In that case, try disabling all network adapters except for the one used to communicate with the controllers.

"Access this computer from the network" rights

By default, this should work, but if your environment is more secured, you can run into an issue when controller is not able to access VDA. This behavior is described in  CTX117449.

The Flowchart here will help you to troubleshoot VDA registration:

If the above approach does not help, you may download the Citrix Health Assistant utility and run it on the VDA which is not registering from CTX207624 -  Citrix Health Assistant - Troubleshoot VDA Registration.

Additional Resources:

Citrix Blog - XenDesktop Brokering Process, Knowledge Center Highlights: App Virtualization & VDI (July Edition)

XenDesktop Registration Failure when Microsoft Global Catalog Port 3268 is Blocked

VDA's do not register with XenDesktop controllers when there is NAT in place between VDA and DDC