‘The security database on the server does not have a computer account for this workstation trust relationship’ when trying to log on via RDP to a customized VM in Azure.

Last summer, our customized lab VM’s started having issues after updating from Windows Update and applying the latest fixes.

The error message received was ‘The security database on the server does not have a computer account for this workstation trust relationship’ when trying to log on via RDP.

After extensive troubleshooting we determined that this seems to have been caused by changes which renamed the VM internally, either in Azure Resource Manager, the Windows Update code or the version of the Azure IaaS agent running on the VM’s.

At any rate… as the server was a domain controller, when it renamed itself to match the external name of the VM it caused an identity crisis as it could no longer find itself.

Yes… the technically correct answer from the handbook is to Sysprep/Generalize any image/template VM that you deploy to Azure but for a lab scenario you sometimes want to have a specialized image that contains AD & Friends – and AD and Sysprep are just not friends as Sysprep will eat AD and not even leave a skeleton behind.

Prior to June this year, deploying a customized non-sysprepped VM from an image with a new name to Azure Resource Manager did not change the actual computer name inside the image if the VM was a domain controller.

This meant you could deploy the same lab image multiple times to Azure with a different external VM name but the name of the VM inside the OS would stay the same.

At some point between June and August this year there seems to have been a change to this which was affecting the image, after updating from Windows Update the name of the server inside the VM was now being changed to match the external name.

This in turn resulted in it being impossible to log on to the VM after rebooting, as the actual computer name of the domain controller VM in the AD that it hosts isn’t changed to the new name at the same time.

TLDR: Redeploy the VM using the original VM name, run Windows Update and update without problems.  Create a new image from the updated VHD as a new template VHD.

I’ve tested a couple of different deployments after updating the specialized image and it doesn’t look like there is an issue updating from Windows Update using the new template that contains the latest updates, even if deployed again using a different name.  Either the rename is dependent on a specific component being updated or possibly it’s related to the version of the Azure agent running on the VM.

Leave a Reply

Your email address will not be published.