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.