Citrix PVS and Logon Errors With Disjointed Namespace


Today I experienced an issue with a client who uses a disjointed namespace whilst configuring PVS. After installing my Citrix 7.6 provisioning services severs and converted my gold image to a vDisk, domain authentication failed for all PVS streamed target devices with the following error:

The security database on the server does not have a computer account for this workstation trust relationship

the security database on the server does not have a computer account for this workstation trust relationship

The gold master virtual machine used to create the vDisk for PVS did not have this issue. The server OS was Windows Server 2008R2 SP1, devices were using BDM for their bootstrap information. Browsing the Internet brought up two Citrix threads and a Microsoft article that reported either similar issues or potential resolutions, but they did not help. These pages are here, here and here. Interestingly it appears other users have had issues since PVS 5.6.


The system event logs on a streamed virtual machine in question gave clues to the eventual error being DNS related, reporting it could not find the domain controller.

After some investigation and head-scratching I noticed the attribute properties of the machine account did not contain the correct ‘dNSHostName’ value – it was using the incorrect DNS suffix, not the one I expected or had assigned in the original gold master.

When PVS creates the computer object in AD, it populates various attributes into the object automatically; this includes the ‘dNSHostName’ attribute. But in my case it filled this with an incorrect value.

You could manually change the value to represent the correct DNS suffix needed, but having to do this for more than a handful of machines is not practical, even with scripting. If the machine account ever needs to be reset via the PVS console in the future, the computer object will revert back to the incorrect settings.

On target device boot I would have expected the computer to automatically update this value, but by default AD does not give enough permissions for it to update its own ‘dNSHostName’ attribute. You need to set this elevated privilege manually.

To change the required permission to a single computer object (i.e. for testing), the specific security permission required is: ‘Write DNS host name attributes’. Ensure the ‘SELF’ security principal is selected.

computer object security

It would make more sense to apply the setting to an OU where your computer accounts reside so they all get the required security changes, so edit the OU properties for the ‘SELF’ security principal. Select ‘Write all properties‘.OU Security

Once implemented, reboot your target devices – fingers crossed you can logon with your domain credentials!

Additional reading on disjoint namespaces.


About Author

A Citrix & Microsoft Solution Architect based in the UK. Citrix qualifications include CCE-V, CCP-N and CCP-M certifications. Also holds an MCSE in Windows Server 2016 and an MCSA in Office 365. Likes golf and cats.

Leave a Reply...