Powershell – Bacon saving…

Even though I don’t run a production network anymore; I do still maintain my own Virtual network for demonstrations and testing product features for the day job. I do remember getting the issue Im going to cover today though a while ago when I did run a School Network!. So, what is this issue? How many of you have seen the dreaded “the trust relationship between this workstation and the primary domain failed” message? A quick Google (or other search engine of your choice) will get you plenty of information from support blogs and Microsoft articles. The problem is, many of them ask you to rejoin your machine to the domain. That’s not always possible – nor desirable, particularly in my case, where Id got it on my Exchange Server VM in my demo network. Id left it paused for too long.

The cause, the real technical cause…

The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined. The machine’s private secret is not set to the same value store in the domain controller. You can think of this secret as a password but in actual fact – its a Kerberos keytab. When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally. You may have also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller.

The original fix…

This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before. When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months. The password changes are required to maintain the security integrity of the domain.

Support blogs and Microsoft will generally tell you to rejoin the domain to restore the trust relationship. Another option they will give is to delete the computer object and recreate it without a password and rejoin as discussed here http://support.microsoft.com/kb/162797

The “new” fix…

Just change your computer password using the Reset-ComputerMachinePassword cmdlet – all you need to do is log on locally to the affected machine. Simple. It doesn’t seem to do a lot, but it works

Reset-ComputerMachinePassword [-Credential <PSCredential>] [-Server <String>]

If you thought I was done there, there is another way too. This is the one I used on my Exchange VM…and it just came back to life

Test-ComputerSecureChannel -Repair

Job done…one of the many reasons I love PowerShell….


Leave a Reply

Your email address will not be published. Required fields are marked *