XenDesktop Virtual Desktop Agent (VDA) un-registers at the start of the session, if the XenDesktop Broker (DDC) is not in the ListOfDDCs registry value.
The following are the symptoms of this behavior:

• The Web Interface displays the following error message when the user starts a session:
  %Desktop Name% is currently unavailable. Try reconnecting and, if the problem persists, contact your system administrator.
• In Desktop Studio, the Desktop Assignment for the affected desktop shows as Registered before starting the session, and changes to Unregistered after attempting to start the session.
• The application event log on the XML Broker DDC reports Error Event IDs 1060, 1039, 2103, and 1101

Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

To prevent this issue from occurring, all registration brokers and XML brokers must be added to the VDA’s ListOfDDCs registry value. In XenDesktop 5.5 and later, you can configure theVDAs to register to one subset of DDCs, and allow sessions to be brokered by another subset of DDCs by grouping the DDC FQDNs in the ListOfDDCs registry value.
For example, the following REGEDIT value would be required if a VDA should register with DDC1 or DDC2, but DDC3 and DDC4 are XML brokers:
Example for 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\VirtualDesktopAgent - REG_SZ: “ListOfDDCs” = ”(DDC1.local.domain DDC2.local.domain) (DDC3.local.domain DDC4.local.domain)”

In this configuration, the DDCs in the first group are used for registration unless all DDCs in that group are unavailable, at which point the VDA attempts to register to brokers in the second group. All DDCs in this value are trusted for registration and session launch.
If the XML brokers are in a different domain, ListOfSIDs can be used to specify a space delimited list of trusted broker SIDs. It must be noted that if one DDC’s SID is added to ListOfSIDs, all brokering server SIDs must also be added to the list.

For example,

If you want to use DDC.DomainA for registration, but use DDC.DomainB as the XML broker, DDC.DomainA must be in ListOfDDCs, and both DDC’s domain SIDs must be added to the ListOfSIDs registry value
Example for 64-bit Windows - HKLM\Software\WOW6432Node\Citrix\VirtualDesktopAgent REG_SZ ListOfSIDs = “space separated list of domain SIDs”

XenDesktop 5.6 Behavior requires the “ListOfSids” key to be populated if using the grouping in “ListOfDDCs” key to separate DDCs for registration and XML.

---

Problem Cause

When an untrusted broker initiates a session logon request, the workstation agent deregisters for one minute, after which it re-registers.
Note: If the BrokerDesktopGroup disconnect action is configured with no timeout, the broker treats the worker as disconnected, and executes the specified power action.
In both XenDesktop 4 and 5, the VDA only accepts XenDesktop session logon credentials from a DDC that it trusts. VDA controls this authorization behavior. In XenDesktop 4, XML broker session forwards logon credentials to the DDC that the VDA had registered with. In other words, all brokered logon credentials (non-SSO) are sent from the same DDC that the VDA had registered with.
XenDesktop 5 was designed to store and send session logon credentials from the DDC that receives the XML RequestAddress from the Web Interface server (specified in the XML failover list). The logonticket credentials are then stored on the DDC that brokers the session logon credentials for the automatic logon session.
In the scenarios where XenDesktop workers are partitioned into separate registration groups, sessions logon credentials provided by a DDC in other registration groups (or are only used for XML brokering), causes this session launch failure.
Example
In the following workstation agent trace, the untrusted session preparation was invalidated because the agent did not recognize the DDC03 as a trusted DDC.
Workstation Agent:ProcessListOfDDCs: found hard-coded list of DDCs: 2, DDC01.domain, DDC02.domain
Workstation Agent:CheckAccessCore: Calling delegate to provide SID list
Workstation Agent:CheckAccessCore: entered, have 2 trusted DDCs
Workstation Agent:UserAllowed: found no matching controllers, access not allowed for user DOMAIN\DDC03$ S-#-#-##-##########-##########-##########-####
Workstation Agent:CheckAccessCore: exited
Workstation Agent:Heartbeat to http://DDC01.domain:80/Citrix/CdsController/IRegistrar rejected

When desktops in a XenDesktop deployment do not have all brokers added to the ‘ListOfDDCs’ and/or ‘ListOfSIDs’ registry values, the Citrix Desktop Service will ‘invalidate’ incoming launch requests that are made from brokers that are not in the lists. After invalidating the session, the desktop will deregister from the site, until the Citrix Desktop Service is restarted

CTX123730 - Error: Found no matching controllers
CTX117248 - Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop