How to configure and troubleshoot VDA registration to Delivery Controllers

There are a couple of ways to configure VDAs so that they can register with Delivery Controllers in your Citrix Site. Registration from a VDA perspective is a sensitive process, and one you want to get right from the beginning. Also, it is good to know some of the things which can cause registration to fail at any point in time. If VDAs are not registered against a Delivery Controller, they won’t be considered by a Delivery Controller when brokering connections.

There are multiple ways to provide the list of DDCs to a VDA. This step allows the VDA to become aware of which DDCs it must attempt registration against:

1. Through Group Policy.
2. Specifying the FQDN of Controllers manually during installation of the VDA.
3. Letting Machine Creation Services automatically configure Delivery Controller addresses on the VDAs it provisions.
4. Active Directory OU based (legacy option).

Citrix recommend that we use Group Policy to configure the Controller addresses, as this allows the most flexible way to manage the list of DDCs at any time.

When a VDA powers on initially for the first time, it somehow has to determine which Delivery Controller(s) it should make a registration attempt against. If you are using the Group Policy method or you have manually specified controllers during VDA installation, this forms what we call the ListOfDDCs. The DNS names from the initial discovery process are kept in the ListofDDCs, which is a registry string on each VDA. Moving forward, in order to keep the cache up-to-date, a Citrix Studio policy named Enable auto update of Controllers is enabled by default to keep the list of DDCs fresh. The information from auto-update is kept on a persistent cache within each VDA and the VDA uses that cache for future registrations. If a Delivery Controller is added or removed from the Site, auto-update keeps the cache updated.

The registration process itself uses Kerberos, and it is two-way, so the connection from the VDA also ends up routing in the opposite direction. Given that Kerberos is used in the registration process, load balanced addresses front-ending Controllers which sit behind a NetSclaer cannot be used. Time is also important as by default Kerberos cannot handle anymore than 5 minutes of time skew.

To get a feel for each method of configuring Delivery Controller addresses on VDAs, I have explained each method below in brief detail.

Contents:

• Group Policy
• Manually during VDA installation
• Machine Creation Services
• Active Directory OU based (legacy)
• Troubleshooting Registration

Group Policy:

When you are installing the VDA, on the Delivery Controller section choose Do it later (Advanced).

You then use Group Policy to initially configure the ListOfDDCs registry string and auto-update (enabled by default) keeps the cache up-to-date.

If you do not wish to use auto-update and disable it via policy, you’ll have to modify Group Policy if a Controller is added or removed from your Citrix Site before VDAs will become aware of it.

Open Group Policy and the Citrix Policies extension. Create a new Citrix Computer Policy.

Search for the Controllers setting and click Add. Note that as mentioned Enable auto update of Controllers is enabled by default.

Specify one or more FQDNs for each Delivery Controller in your Citrix Site and click OK.

After the VDA picks up the new policy, the ListOfDDCs string will be populated with the values you specified during policy creation. This string exists under HKLM\SOFTWARE\Policies\Citrix\VirtualDesktopAgent for 64-bit systems.

Note that it would also be possible to create this string manually. When doing so, each Delivery Controller name in the string value should be separated with a space.

This forms the foundations for a VDA to initially register with a Delivery Controller, and then auto-update generates a cache in a persistent location which holds the most up-to-date Controller list going forward.

Manually during VDA installation:

When you are installing the VDA, on the Delivery Controller section choose Do it manually.

Enter one or more Delivery Controller addresses and complete the VDA installation. Again, these values form the ListOfDDCs and auto-update keeps the list of Controllers up-to-date in a persistent location.

To find the persistent location, on a VDA launch PowerShell and run command Get-CimInstance -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” | select PersistentDataLocation

The persistent data location is only accessible from the SYSTEM account. For this, we can use PsExec. Launch PsExec as SYSTEM and browse to %ProgramData%\Citrix\PvsAgent\LocallyPersistedData\BrokerAgentInfo and open the XML file SavedListOfDdcsSids.xml.

To confirm, auto-update has updated the cache with a second Controller not specified during VDA install, ddc02.jgspiers.com

Machine Creation Services:

When you are installing the VDA, on the Delivery Controller section choose Let Machine Creation Services do it automatically.

Once machines have been provisioned by MCS, there will be a Personality.ini file on the root of C:\ on each VDA.

It is in this file that the Delivery Controller list is kept.

Active Directory OU based (legacy):

I’ll not touch on this method too much. Basically, Citrix don’t recommend you use it anymore. The recommended approach is to use a mixture of Group Policy for initial configuration and auto-update to keep the list updated.

Troubleshooting Registration:

• By default, VDA registration occurs over port 80. If you have not changed this default port, then verify that no process on your VDA machine is listening on port 80 other than SYSTEM. You can use netstat -aon -p tcp to confirm.
• Make sure the VDA and Delivery Controller times are in sync. Since registration uses Kerberos, time is important.
• If you are running in a secure environment that makes use of the Access this computer from the network policy, make sure that VDAs are able to communicate with Delivery Controllers and vice-versa using this policy setting.
• Make sure you are not trying to point VDAs to a load balanced address for the DDCs, this will not work.
• Make sure no typos exist in the DDC names when specified via Group Policy for example.