When a PC lost its trust relationship with a domain controller: “The trust relationship between this workstation and the primary domain failed”
Posted by jpluimers on 2016/10/17
(Don’t ask for details; at a site with Microsoft Data Protection Manager an external company monitoring that DPM didn’t notice various backups – including the domain controller – were months old despite daily tape changes; so then the RAID fell out because multiple disks failed within hours, contingency aftermath took weeks)
When you logon to a client machine and get “The trust relationship between this workstation and the primary domain failed”
- do not rejoin your client machine to the domain
- ensure on the client machine:
- you can logon without a domain account (part of any contingency plan should be logging in with a local account or without a domain controller if you have the – potential risky – cached domain logon enabled, otherwise you’ve to do more nasty measures)
- you have PowerShell v3 or later on the client machine
- on the client machine
- Ensure it’s connected to the same network as the domain controller
- Ensure you can ping the domain controller
- Test with
Powershell Test-ComputerSecureChannel
to see if the connection is indeed lost:- if it returns
True
then you have a different problem (have not seen this, but just in case: this blog post won’t solve that) - if it returns
False
, then continue with the next step
- if it returns
- Run
Powershell Test-ComputerSecureChannel -Repair
and check if the output isTrue
(whenFalse
there )
Note there are various posts suggesting to use Powershell Reset-ComputerMachinePassword
and netdom.exe resetpwd /s:dc-hostname.domain /ud:domainadminusername /pd:*
. Though faster than rejoining the domain, the Powershell Test-ComputerSecureChannel
is even faster and easier.
–jeroen
via:
Leave a Reply