Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop
Created
On: May 19, 2008 / Updated On: Jun 12, 2012
Average Rating: 
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.
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).
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:
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.
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.
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.
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.
No comments:
Post a Comment