Summary
The Desktop Delivery Controller (DDC) relies upon a software component
installed upon each Virtual Desktop Machine (VDM) - the Virtual Desktop Agent
(VDA) - being in communication with one of the controllers in your XenDesktop
farm. This state of being in communication is referred to the VDA as being
registered with the controller. If communication fails for any reason, it means
that the VDA has failed to register with a controller and it would not be
possible for the DDC to broker a connection to the VDM in question; and the VDM
becomes an unusable resource.
The VDA logs issues with registration in the event log, as displayed in
the following example:
The following screen shot displays the three most recent event log
entries in this example, that is, Information, Warning, and Error:
If the VDM has been added to a desktop group in your DDC farm, you can
also see evidence of the VDA failing to register with any controllers in the
farm in the Access Management Console's Virtual Desktops view. The
Desktop
State column provides information about the registration state of the
desktop machine; values of
Not Registered or
Pending indicate that
registration has not successfully completed. The following screen shot
highlights an example of this (highlighted in yellow):
Troubleshooting Registration
Problems
CTX123278 –
XDPing Tool is a support diagnostic tool which has
been designed to troubleshoot VDA registration issues. It runs through a number
of systematic checks to verify and detect a number of common problems typically
associated with the VDA registration issues.
Virtual Desktop not added to the correct
farm
Whenever you notice VDA event log entries on the worker suggestion
registration failure, ensure to that the VDM is properly added to the correct
DDC farm. This needs to be done from both the point of view of the virtual
desktop system and of the DDC farm itself.
- 1. Check in the Access Management Console for the farm that the
virtual desktop’s machine name is in one of the desktop groups.
- 2. Check that the VDA is a member of the correct farm. You can get
this information from the event log entry that gives the Globally Unique
Identifier (GUID) of the base Organizational Unit (OU) the VDA
uses:
- 3. Check in the Access Management Console for the farm that the
value of the GUID shown matches with the farm’s read-only
properties:
Note: If the GUID on the VDA does not match the GUID in the
Access Management Console of the farm, the VDA is configured to be in a
different farm. A VDA’s farm membership can be set through group policy (using
the ADM template file FarmGUID.adm supplied in the installation media), or
during installation (in which case the value is written into the registry string
HKLM\SOFTWARE\Citrix\VirtualDesktopAgent\FarmGUID).
- Correct the farm setting of the VDA and restart it to see if
registration is now possible.
Virtual Desktop Firewall not properly
configured
Registration fails if the firewall on the Virtual Desktop Machine has
not had the appropriate exclusions configured to enable DDC’s communication. As
an experiment, you should try disabling all firewall software on the VDM and
restart it. If registration now succeeds, the problem points to misconfiguration
of the firewall; reconfigure it as explained in the Knowledge Centre article
CTX116843 –
Desktop Delivery Controller 2.0 Administrator's
Guide and re-enable it.
Note: It is not advisable to run with the
firewall that is permanently disabled on Virtual Desktop Machines.
Domain Name Services (DNS) not properly
configured
Registration fails if the VDM or the DDC controller sees an incorrect
IP address for the other party. Complete the following experiment to see if this
is an issue:
- On both machines, start a command shell window and run the following
commands:
ipconfig
ping <othermachine.domain.com>
- Both machines should be able to ping each other successfully by DNS
name (this means using the fully qualified domain name (FQDN) including the
domain.com bit and not the simple NetBIOS name).
Crucially, the IP address
reported for the remote machine by the ping command in each case should match
the IP address reported by the ipconfig command on the relevant
machine.
- If there is any discrepancy, fix the problem with your DNS
configuration and restart either the VDM and or the DDC controller, as
appropriate.
Time Synchronization not properly
configured
Secure the communication between the VDMs and DDC controllers using
Kerberos. This relies upon tickets with a limited life span. If the difference
in system time between the two ends of the communication is too great, the
tickets will always be considered to have timed out when they are accessed and
then the communication fails.
Check that the system time on all systems are within a reasonably small
margin (the default domain-wide Kerberos setting is 5 minutes).
XenDesktop 5 Controller VDA Registry
Key
Verify that the following registry key has correct
information:
(x86) HKEY_Local_Machine\Software\Citrix\VirtualDesktopAgent
(x64) HKEY_Local_Machine
\Software\Wow6432Node\Citrix\VirtualDesktopAgent
ListOfDDCs REG_SZ
Also view event log entries from Citrix Desktop Service for related
information
Powershell example on local VDA Machine
Get-EventLog -Log Application -Source 'Citrix Desktop Service' |
fl
Powershell example on remote computer
Get-WinEvent -Computer <machine-name> -Old -Prov 'Citrix Desktop
Service' | fl
Where <machine-name> is the DNS name of the Virtual
Machine.
Domain Membership problems
Under some circumstances, it appears that the machine (VDM or DDC
controller) is a part of the domain, but in fact, it is not (for various
reasons). This can cause problems with the secure communication between the VDMs
and the DDC controller.
Try removing the machines in question from their domains (by
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 is successful.
Service Principal Names
(SPNs)
Communication between Virtual Desktop Machines and DDC 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 DDC
determines the virtual desktop’s SPN by 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 FQDN, try editing it manually and check
to see if that fixes registration problems.
Multiple Network Adapters
If the virtual desktops contain multiple network adapters that can be
used to communicate with the DDC, 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 DDC.
Local Security Policy
Settings
In case of some images, especially military images, the restrictive
security policy settings might prevent the VDA from registering. See
http://helpdeskgeek.com/how-to/reset-local-security-policy/ for details on how to reset security
policy settings to their defaults.
![clip_image002[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsLZq2feVeNxB2YrSeZEBA_LxsqBdM0Jq8-6IdN4XjWQ7jAj1m8aBpTEyjFZIBbTyYnank5u0or3IU_CbEBSQeKos1tLW9WScIqbnkL1pblVxWW0a1zGX60aqSQ9nMQko7BSNTiWmacMcI/s1600-h/clip_image00262.jpg "clip_image002[6]")
![clip_image002[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgK1xVlEFn5EXokN-qU7tdKKDfRdR9fkake5m1G_lhjzdiHTx2yHGx8tZwLs5Xo6FcMek4enN1VsW-DvYjjPN3fm2pfwAd0vWdbySPK905PGv6WjDImn1oh86XZ-pPXmIA0RxhBoZVfKoHP/s1600-h/clip_image00242.jpg "clip_image002[4]")
