While working on the CXD-302 Advanced Troubleshooting course (if you haven’t yet, you should really go and take it right away), I started looking at data from Citrix Support. Before starting to teach how to troubleshoot problems, it helps to know which are the most common.
I found that VDA registration has been in the top 5 issues reported to Citrix Support, and in CXD-302 we’ve dedicated one whole module just to troubleshooting of VDA registration.
Why is it such a big issue? The reason is that registration is a very sensitive operation from a security perspective – you’re effectively establishing a connection between master (controller) and slave (VDA). And with such a sensitive operation, expected behavior is to reject the connection if everything is not in perfect shape. You are effectively establishing two separate communication channels – VDA to XenApp/XenDesktop Delivery Controller (XDC) and separate channel for XDC to VDA communication. Kerberos is used, so time synchronization or domain membership issues are unforgiving. Service Principal Names (SPN) are used by Kerberos, so you cannot use load balanced IP\hostname.
We have published various articles (including, Troubleshooting XenDesktop registration process) and have provided tools (including Citrix Health Assistant that was updated just a few days ago).
We’ve made it easier to configure the controller and included additional checks during configuration. For example, in XenApp and XenDesktop 7.9 we are automatically testing the connectivity of the controller during VDA installation; in the past this was optional. We will display an error if the controller is not reachable and an additional pop-up message if you ignore this warning.
But when I was thinking what else we could do to make this easier for our partners and customers, I realized that we never provided you with any guidance about the first step – where and how to configure the controller address. We have been adding more options and features, but have not summarized them in one article.
What do you need to know?
When dealing with VDA configuration of the controller, there are three important questions you have to answer during the design phase. In this blog post, we will cover the first two questions.
- Where do you configure the settings (configuration delivery method)?
- How do you keep those settings up to date (moving VDA between sites, adding\removing controllers)?
- How do you configure the settings (the configuration values, like IP, hostname, grouping, alias, etc.)?
Configuration Options
There are many different ways you can configure the controller (XDC) address on VDA. You may be familiar with Group Policy configuration and manual entry during VDA installation, but there are a few more options available.
Below are five configuration options that are available to you. We are going to shortly explain each of those options next. These options are sorted by their priority (auto-update has higher priority than policy – more about this later).
- Auto-Update Method
- Policy-based Method (LGPO or GPO)
- Registry-based Method (Manual, GPP, specified during installation)
- AD-based Method (Legacy OU discovery)
- MCS-based Method (Personality.ini)
Auto-Update Method
This is one of the hidden gems in FMA that went under the radar of most people. It was first introduced in XenApp and XenDesktop 7.6 and is enabled by default, so you’re probably already using it even without knowing about it.
Auto-Update is not dealing with initial configuration, but it’s solving the problem of keeping your environment up to date when controllers are added or removed. After initial registration, auto-update functionality will download the list of all available controllers and store this in a persistent cache – this is done separately for each VM. This feature supports all provisioning methods (including MCS and PVS) with the exception of server-side cache with PVS (which is not a very common scenario).
Whenever VDA re-registers, for example after reboot, this cache is updated with the latest changes. Below is an example of the format of this cache file – it’s not only caching the hostnames, but also SIDs (it’s a ListOfSIDs that is internally more important than ListOfDDCs, but that’s a story for another time). As a nice side effect, VDA doesn’t have to query SID anymore, so this is reducing the load on Active Directory, as well.
Location of this file can be retrieved through WMI call, but it’s stored in a location that’s readable by SYSTEM account only and any modification with it would be unsupported:
Get-WmiObject -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” -Property “PersistentDataLocation”
This feature can be controlled through Citrix Policy with a setting called “Enable auto update of Controllers” under “Virtual Delivery Agent Settings.”
If you were reading the previous text carefully, you may have noticed something strange. Auto-update is the highest priority of all and overrides all other settings, so what would happen if you need to move VDA to another site (think about disaster recovery scenario)? There is a neat sub-feature in auto-update that takes care of this scenario. In the above screenshot you may have noticed a ‘NonAutoListOfDDCs’ elements (initial configuration option). Auto-update monitors this location and if there are any changes (e.g. initial method has been updated), it will skip the auto-update and move on to the next method.
Policy-based Method (LGPO\GPO)
This is probably my favorite method for initial configuration. Centralizing the configuration gives you all the advantages of using Group Policy (pretty much standard across enterprises for configuration) and allows you to override auto-update cache in case if you needed.
Simply use the Group Policy (or local GPO in those rare cases where it is required) and find the policy called “Controllers” (or if security is your top priority, “Controller SIDs”). You can find these settings under “Virtual Delivery Agent Settings.”
These settings are then stored together with other policy settings under HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs). The reason we recommend using GPO for initial configuration is that it’s highest in the hierarchy of all the options, with the exception of auto-update, and configuration for all VDAs can be centralized.
Registry-based method
This is the method that is used if you specify controller address during the VDA installation. These settings are stored in registry value ListOfDDCs under registry key HKLM\Software\Citrix\VirtualDesktopAgent. And if you cannot find it (and are running 64-bit Windows), you might have a look at HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent as well.
You can also configure this registry key manually or using Group Policy Preferences. I have seen a few situations where this method is preferred to using Group Policy – for example if you want to have conditional processing of different controllers (e.g. use XDC-001 for computer names that being with XDW-001- etc.)
AD-based method (legacy)
This method is supported primarily for backward compatibility and is not recommended and if you’re still using it, we suggest to switch over to another method. To enable this method, you have to use Set-ADControllerDiscovery.ps1 script (available on every controller) and also configure ‘FarmGuid’ registry entry on each VDA to point to the right OU. This setting can be configured using Group Policy.
As mentioned before, this is a legacy method and we do not recommend using it. You can find more details here if you’re interested.
MCS-based method
If you are planning to only use MCS, you can also consider leaving it up to the MCS to inject the list of controllers. This feature is working together with auto-update, e.g. MCS will inject the list of controllers to Personality.ini file during initial provisioning, but auto-update will make sure to keep this list up to date.
This list is currently injected during catalog creation time. If your environment is small, no need to move VDAs between sites, you’re using MCS and don’t want to deal with Group Policy for whatever reason, this might be a good option for you. However, we don’t recommend using this for large environments.
Summary
- VDA Registration process is super-secure.
- Group Policy configuration is recommended method for initial configuration
- It allows you to override configuration if needed
- Its high priority makes troubleshooting easier
- Its high priority makes it hard to override
- Auto-update feature is enabled by default and is the recommended method to keep your list of controllers up to date
Still don’t have enough? Make sure to read the part 2 of this blog series here. This time we’re going to discuss allowed values, SIDs, load balancing and zones.
Special thanks
I would like to thank William Charnell that has done a tremendous job supporting me and providing me with a great feedback.
Martin Zugec (@MartinZugec)
