As a Technical Relationship Manager within Enterprise Support Services at Citrix, I have seen my share of questions and cases where the Virtual Desktop Agent (VDA) is not able to communicate with the Delivery Controller (DDC). As with other products (Citrix or other vendors), there is a wide variety of possible causes of these communication problems. My intention with this blog post is to create a single resource that you can use to start your troubleshooting in order to resolve your issue as quickly as possible.
Yes, at some point in time, everyone will forget some of the basic settings and that can happen to even the most experienced admins. Here are the top five common mistakes listed and how to resolve them:
1. Wrong list of DDCs:
When observing errors in the event log telling you that the Desktop Service is unable to contact the Desktop Delivery Controller (DDC), this usually points to a misconfigured VDA and/or its inability to receive the correct list of DDCs.
Currently there are multiple ways to provide the list of DDCs to the VDA:
- Through a policy;
- Adding the list during the configuration of the VDA (GUI or command line);
- When using MCS let MCS handle this automagically;
- Active Directory OU based (legacy option).
All these options have their pros and cons. My recommendation is to set the names of the delivery controllers using a policy (By specifying the ‘Do it later (Advanced)’ option during the installation of the VDA) and use the auto update Citrix policy (which is enabled by default) to keep the list up to date. This configuration allows for flexibility and centralized management.
2. Communication ports blocked:
In situations where the VDA’s status shows as Unregistered in Studio and the VDA’s event log contains messages telling you the Desktop Service is unable to register with the DDC, you will need to check if the firewall (both the Windows firewall on the VDA and any other firewall between the VDA and the DDC) is correctly configured.
The VDA needs port 80 or 443 and for communication with the Receiver ports 1494 and/or 2598 (for session reliability, enabled by default) open for communication.
- Verify that no other application uses the ports needed for the VDA (80, 1494, 2598), using the netstat -aon command in an elevated command prompt window.
- For complete port information, see Communication Ports Used by Citrix Technologies
DNS resolution related issues occur frequently and are often overlooked because DNS is already set up and configured beforehand DNS issues can be spotted easily and resolved quickly. Just ping the DDC’s FQDN from the VDA and check if it can be resolved and vice versa from the DDC (ping the VDA FQDN).
4. Desktop Service service
In some cases, the Desktop Service fails to start due to a time-out. In this situation, you can set the startup type to Delayed auto start instead of Automatic Startup. Another reason for the service not starting is that the startup type is set to Manual. In this case, change the startup type to Automatic startup.
The root cause of the Desktop Service service timing out is related to the design of Microsoft’s Service Control Manager (SCM) not allowing enough time for services to start up. This can affect the services that use the Microsoft .NET Framework in particular. By design, Microsoft.NET processes require additional overhead to start the process. These include:
- Just In Time (JIT) compilation to generate native code for the executable.
- Creating a sand box environment for the process.
- Parsing and processing configuration files.
You can set the following registry entry (on the VDA) to allow more time for services to start and initialize.
Example registry file with value set to 45 seconds:
|Windows Registry Editor Version 5.00
5. Time sync
Time skew may cause VDAs not to register with the DDC and can be easily checked/tested by verifying 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 the VDA is registering correctly.
When using a pooled random catalog, correct the issue with the Windows Time Service on the master image and update the catalogue’s master image. Additionally, verify if the pooled desktops join the domain correctly after boot.
Note: The default domain-wide Kerberos time skew allowance is set to five minutes.
6. “Access this computer from the network” permissions (additional setting seen in secure conscious environments)
Modifying permissions in the “access the computer from the network“-policy (Microsoft GPO → Computer settings → policies → Windows settings → security settings → local policies/user rights assignments) and removing the NT AUTHORITYNETWORK account from this list, can break the registration process.
In this case, event ID’s 1002 / 1207 / 1221 / 1223) can be triggered on the VDA.
If these errors occur, make sure to check for any applied GPO that modifies this setting. Using gpresult, verify if the NT AUTHORITYNETWORK account is still listed as a user that can access the computer (VDA) from the network.
1. Citrix health assistant
This is a very useful tool to check for the most common issues described earlier in this article and should be one of the first tools to use for troubleshooting VDA registration issues.
2. Citrix Supportability pack
This is a more generic toolkit that every Citrix admin should have at hand in their environment. With an easy to use update tool included, you will always have the best and latest troubleshooting toolkit at your disposal. From PVS to Optimization Pack tools to the more complex CDF control utility to troubleshoot all kinds of Citrix related software, it is all in there.
If you like this article and would like to see some more troubleshooting blogs, drop your suggestion for a topic in a comment below and we’ll try to cover it in a future article .