Citrix VDA: The trust relationship between this workstation and the primary domain failed

The trust relationship between this workstation and the primary domain failed

If you get this error for non-persistent RDSH/VDI provisioned using PVS, it could well be that there is a conflict in managing “machine account password” on your computer objects in AD between PVS and Netlogon. 

Machine account password for non-persistent machines provisioned with PVS should be only managed via PVS.

First things first

In a scenario when you have hundreds of machines; proactively catch and fix machines can come handy.

First, we need to make sure Netlogon service on the target machine is not negotiating machine passwords. This can be done by the Group Policy

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Disable machine account password changes – Enabled. 

Now we need to make sure PVS side is configured properly. You will also need to shutdown affected machines and reset their computer account as explained in this Citrix article.

Troubleshoot faster with PowerShell

Luckily, we can interrogate the event logs across all non-persistent machines and proactively find out which ones are going to lose trust with the domain.

Below I list the Event IDs that I look for and what they mean

Event ID






“The system successfully changed its password on the domain controller <Domain Controller Name>



This is a symptom of the problem. PVS is not managing the account password and Netlogon service is stepping in and changing the password.


Unable to negotiate new machine password



PVS is trying to change the password but failing. The password that the PVS is injecting in the target device is not in sync with the one AD has.


Updating machine account password – Client Service



This the the expected behavior when PVS is configured properly.


New machine account password negotiated – Client Service



PVS injects the machine identity (name and password) upon boot, then while the machine is running, PVS software can negotiate a new password on a set intervals. Once negotiated successfully, PVS keeps a record of the new password so it can be injected the next time the target device reboots.

If another service e.g. Netlogon negotiated a new password with Active Directory, PVS will not know about this change and will inject an old password when the target device is rebooted.

To discover which service is changing the password, a script can run across the all target devices to match the password negotiation time with the lastpasswordset value in AD for each computer object.

I use Invoke-parallel to “fan” the script across all machines. You will need to download and import the module as shown below

Example of results – in this example we can see that the password negotiation was sucessful and was initiated by PVS service (BNDevice). We can also see that the timestamp of the password change in Active Directory corresponds to the event on the target device.

2019-09-20 17_09_00-Capture

Monitor and proactively act with PowerShell!

The following script would try and remotely connect to a machine and check the secure channel between the machine and the domain. if the machine is not contactable, that could be an indication of a failure in trust relationship.

The script also checks if the machine is already in maintenance mode or not

Example of the output: 

2019-09-20 18_07_08-Capture3
Citrix VDA: The trust relationship between this workstation and the primary domain failed

2 thoughts on “Citrix VDA: The trust relationship between this workstation and the primary domain failed

  • August 6, 2021 at 2:33 pm

    bndevice tells NetLogon to do its work so event ID 5823 is likely expected for all change attempts. Because bndevice kicked off NetLogon it knows to look for a response from the DC on the password change. If successful it commits the values to its DB that of the values passed to NetLogon when telling the DC its new password. If BNdevice hadnt called NetLogon and Netlogon changed the password because of some domain setting or third party, PVS doesnt know to look out for that new password, now AD and PVS SQL are mismatched. Nice doc. thanks!

    • August 6, 2021 at 3:02 pm

      Thank you Chris – glad you found it useful!


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: