Xendesktop VDA Registration in an AD MultiForest Environment - One Way Trust
Article ID: CTX213546
Updated On:
Description
While attempting to register a Virtual Desktop Agent to a Broker in the trusted domain, registration might fail and you will encounter the following error messages on the VDA side:
Event 1017
Citrix Desktop Service
The Citrix Desktop Service failed to register with any delivery controller.
The service will retry registering with controllers in approximately 14 seconds.
Please ensure that at least one delivery controller is available for Virtual Desktop Agents to register with. Refer to Citrix Knowledge Base article CTX117248 for further information.
Event 1002
Citrix Desktop Service
The Citrix Desktop Service cannot connect to the delivery controller 'http://DDC.B.lab:80/Citrix/CdsController/IRegistrar' (IP Address '10.107.83.175')
Check that the system clock is in sync between this machine and the delivery controller. If this does not resolve the problem, please refer to Citrix Knowledge Base article CTX117248 for further information.
Error Details:
Exception 'Fail worker callback using SPN HOST/MIWindows7.A.lab and IP address 10.107.83.168' of type 'System.ServiceModel.FaultException`1[Citrix.Cds.Protocol.Controller.Fault]'..
Event 1017
Citrix Desktop Service
The Citrix Desktop Service failed to register with any delivery controller.
The service will retry registering with controllers in approximately 14 seconds.
Please ensure that at least one delivery controller is available for Virtual Desktop Agents to register with. Refer to Citrix Knowledge Base article CTX117248 for further information.
Resolution
Collected Broker Logs using the article http://support.citrix.com/article/CTX127492
Broker learns the SID of the VDA and starts registration process
From this SID we identify the address of the VDA
Later, we try to Bind to AD object
BrokerController:TryBind failed: path=LDAP://10.107.83.186/<SID=010500000000000515000000F9ADB5917A9D8E1B5185351050040000>, type=PDC specific: There is no such object on the server.
BrokerController:TryBind failed: path=LDAP://B.lab/<SID=010500000000000515000000F9ADB5917A9D8E1B5185351050040000>, type=domain specific: There is no such object on the server.
Further, broker begins testing Worker’s communication which is where it actually fails –
It also looks similar to the event reported above that says Fail worker call back
At this point, the registration attempt is noted as a failure in the VDA event logs + the broker events.
Why it fails?
> While the broker is attempting to access the VDA using its own account, it is failing to do so.
The above information would be visible in a Wireshark traces as a Internal Server 500 error while communicating over HTTP protocol in the IRegistrar routine.
Since the broker is unable to access the VDA, it does interpret that the Access permission is an issue here. At this point, we need to verify the trust settings and validate the Trust between the two domains.
VDAs parent domain trusting the Broker domain --> This resulted in the registration to go through successfully.
While going through the logs of this scenario, we could see that the Broker was able to access the VDA successfully.
26/05/16 20:18:39.8989 : BrokerDAL:Completed on demand name lookup: Worker SID(S-1-5-21-2444602873-462331258-271942993-1104)
26/05/16 20:18:39.8989 : BrokerController:TryBind failed: path=LDAP://10.107.83.186/<SID=010500000000000515000000F9ADB5917A9D8E1B5185351050040000>, type=PDC specific: There is no such object on the server.
26/05/16 20:18:39.8989 : BrokerController:TryBind failed: path=LDAP://B.lab/<SID=010500000000000515000000F9ADB5917A9D8E1B5185351050040000>, type=domain specific: There is no such object on the server.
26/05/16 20:18:39.8989 : BrokerController:GetForestFromSid entry with sid S-1-5-21-2444602873-462331258-271942993-1104
26/05/16 20:18:39.8989 : BrokerController:GetForestFromSid exit with forest A.lab
26/05/16 20:18:39.8989 : BrokerController:TryBind succeeded: path=LDAP://10.107.83.163/<SID=010500000000000515000000F9ADB5917A9D8E1B5185351050040000>, type=forest global cache specific
26/05/16 20:18:39.8989 : BrokerController:BindToADObject exit: succeeded
26/05/16 20:18:39.9145 : BrokerController:FindContainerCanonicalName exit: SID=S-1-5-21-2444602873-462331258-271942993-1104, CanonicalName=(Object=Child.A.lab/Computers/MIWINDOWS7, Parent=Child.A.lab/Computers),
26/05/16 20:18:39.9145 : BrokerDAL:DAL >>> RemotePCRegistration(S-1-5-21-2444602873-462331258-271942993-1104, Child.A.lab/Computers, CHILD\MIWINDOWS7)
26/05/16 20:18:40.0862 : BrokerDAL:DAL <<< RemotePCRegistration(, , , , , , 05/26/2016 14:48:39, False, False)
26/05/16 20:18:40.1018 : BrokerOpEvent:2016-05-26T14:48:40.1000000Z:EndWorkerRegistration(S-1-5-21-2444602873-462331258-271942993-1104, 10.107.83.168, CHILD\MIWINDOWS7, MIWINDOWS7.Child.A.lab, Windows 7 Service Pack 1, VDA=7.6.300.7020, L7_6, MultiSession=False, Hard=False[OK], Fault=None, Broker=DDC.B.lab)
26/05/16 20:18:40.1018 : BrokerComponent:IRegistrar.Register exit: result True
Problem Cause
Transitive One way forest trust will work if the VDA domain trusts the Broker domain.Example:
> BROKER domain B.lab has an Incoming trust from A.lab.
If Two way trust is an option – that would definitely work.
Ref: http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-8/technical-overview/active-directory.html
Deploy in a multiple Active Directory forest environment
Note: This information applies to minimum version XenDesktop 7.1 and XenApp 7.5. It does not apply to earlier versions of XenDesktop or XenApp.
The following table lists the supported trust types:
| Trust type | Transitivity | Direction | Supported in this release |
|---|---|---|---|
| Parent and child | Transitive | Two-way | Yes |
| Tree-root | Transitive | Two-way | Yes |
| External | Nontransitive | One-way or two-way | Yes |
| Forest | Transitive | One-way or two-way | Yes |
| Shortcut | Transitive | One-way or two-way | Yes |
| Realm | Transitive or nontransitive | One-way or two-way | No |
