This is a second part of blog post series about Virtual Delivery Agent (VDA) Registration configuration: VDA Configuration Options – Part 1
The first blog post was focused on the various methods that controllers can be configured (answering the “Where” question); this post will focus on the possible values (answering the “What” question). Do you use load balanced IP, DNS names, alias or some special format that you are not even aware of?
What is NOT going to be covered
As it doesn’t apply to majority of the deployments, I’m not going to describe the complex multi-domain or multi-forest implementations. If you have a complex Active Directory environment and would like to see a third post to cover this topic, make sure to leave a comment. If I see a lot of demand, I will write a follow up blog post about this topic.
Role of ListOfSIDs
As you should already know after reading the first post, list of controllers identifies which controllers are going to be used for registration with the FMA site; this configuration is also known as ListOfDDCs. During the first stage, list of controllers is obtained from this configuration and resolved by DNS. There is also a second stage that has been (mostly) a secret so far.
Virtual Desktop Agents (VDAs) not only need to know which controllers to contact, but they also need to know which controllers to trust – and they do not automatically trust the controllers from ListOfDDCs. To identify the controllers that are trusted, configuration called ListOfSIDs is being used.
Registration fail because CTX-XDC-001.cdz.lan is not a trusted machine.
In almost every environment, this list of trusted controllers is automatically generated from your ListOfDDCs and you can find how it’s populated by reading a CDF trace. I have only seen few cases when we had to manually modify the ListOfSIDs (and I will share those few examples with you in the following paragraphs).
- Separated Roles for Controllers – Prior to Zones, we would configure ListOfSIDs if only a subset of controllers was used for registration. If that’s the case (e.g. using XDC-001 and XDC-002 as XML brokers, while using XDC-003 and XDC-004 for registration), you have to specify all controllers in ListOfSIDs and XDC-003\XDC-004 in ListOfDDCs. This is not a typical (or recommended) configuration and should not be used in newer environments (use zones instead).
- Reducing AD Load – We have also used ListOfSIDs to reduce the load on domain controllers. With pre-populated ListOfSIDs, the resolution from DNS names to SIDs can be skipped. This is however no longer needed (or recommended) with auto-update feature (described in the previous blog post), because this persistent cache now contains SIDs as well. Another reason why to keep the auto-update feature enabled!
- Security – Finally, in some highly secured environments, we have manually configured the SIDs of trusted controllers to avoid possible security threats from a compromised DNS server. However, if you do this, you also need to disable the auto-update feature, otherwise the configuration from cache is being used.
With introduction of auto-update feature, most of these reasons are no longer valid. Unless you have a very specific reason to do so, do not modify the ListOfSIDs. If you needed to modify ListOfSIDs in your environment, please leave a comment, I would love to know the reason why. If you really need to modify this value, create a registry key called ListOfSIDs (REG_SZ) under HKLM\Software\Citrix\VirtualDesktopAgent. Value is a list of trusted SIDs, divided by spaces if you have more than one.
Example configuration for ListOfSIDs. Only one controller is used for registration (ListOfDDCs),
but two controllers are trusted for brokering (ListOfSIDs).
Can I use an IP address instead of DNS name?
We typically recommend to use an FQDN addresses for all controllers. An IP address is not considered a trusted configuration, as it’s easier to compromise an IP than a DNS record. There is however method that you could use – if you populate the ListOfSIDs manually, you can use an IP in a ListOfDDCs. Personally, I have never seen any need for this configuration and have never used it.
Should I use a network load balancer?
No, you cannot use a network load balancer (such as NetScaler) for security reasons. VDA registration is using a Kerberos for authentication. To be more precise – it’s using Kerberos mutual authentication, where client (VDA) must prove its identity to service (XDC), but also service (XDC) must prove its identity to client (VDA). What this means is that VDA and XDC are both acting as a server and client at the same time.
One of the key components in this process is called Service Principal Name (SPN), stored as a property in an AD computer object. When your client connects to the service, it has to specify “who” it wants to communicate to – and this address is an SPN. If you use a load balanced IP, mutual Kerberos authentication will correctly recognize that the IP does not belong to the expected service (XDC). If you want to better understand the reasons behind, I can recommend this introduction to Kerberos and this MSDN article about mutual authentication using Kerberos. Sorry if it’s confusing, but Kerberos is not easy to understand or explain (at least without a whiteboard).
Using load balanced address for ListOfDDCs has never been considered as a major problem, since the failover\load balancing functionality is built into the CBP (Citrix Brokering Protocol). If you specify multiple controllers in your configuration, registration will automatically fail over between them if needed. With auto-update feature, this is now done automatically for all VDAs.
Didn’t you recommend to use DNS aliases previously?
Ah, someone remembered this article. Yes, I have been using CNAMEs (DNS aliases) for a long time and I’m still a huge fan. However, this was written in 2012 and we didn’t have an auto-update feature back in those days. CNAME functionality has been disabled in XD 7.0 release, but you can enable it by following the steps outlined in CTX137960. My personal recommendation would be to use auto-update instead and do not use CNAME for registration anymore.
Can I specify groups of controllers?
There is one special type of configuration that I was not talking about yet – the grouping of controllers. In certain scenarios, you might want to process controllers in groups – with one group being preferred and the other group used for a failover if all controllers failed.
To specify groups of controllers, all you need to do is to include parenthesis in your ListOfDDCs value. For example, if I have 4 controllers (two primary and two backup), this is the configuration that I would use:
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)
In this case, all controllers in group A (001 and 002) are being processed first, if both of them fail, controllers in group B are being processed (003 and 004). Don’t forget that controllers are randomly selected from the list, so grouping makes a lot of sense if you want to have preferential usage of controllers.
What should I do if I have multiple zones?
You finally have a pretty good idea where and how to configure the controllers in your site, only to realize that Citrix has changed everything with introduction of zones, right? No need to worry, we have you covered. When zones are detected, grouping feature is used internally by the auto-update feature (described in the previous blog post).
For all machines that are in the satellite zone, auto-update will automatically cache all local controllers first (group A) and all controllers in primary zones are stored in backup group (group B). If none of the local controllers is available, registration will be attempted against the controllers in primary zone.
- Single zone: use Group Policy for initial configuration (with at least 2 controllers) and auto-update to keep the list up to date (enabled by default)
- Multiple zones: use Group Policy for initial configuration (with at least 2 controllers), ideally point VDAs to controllers that are local to their specific zone. To keep both lists (satellite controllers and central controllers) up to date, just use the auto-update feature (enabled by default)
- Use FQDN format when configuring the list of controllers (initial config)
- ListOfSIDs is automatically generated. To not configure it manually unless you have a good reason to do so
- Auto-update will automatically optimize the list of controllers for satellite zones
If you have any reason that this doesn’t work for you, I would appreciate feedback in comments.
Martin Zugec (@MartinZugec)