Relationships are built upon trust! As an AD administrator, there is no relationship more important than the one between Domain Controllers and workstations. We have all dealt with errors like “The trust relationship between this workstation and the primary domain failed.” But why does this occur? In short, the secure channel has been broken and we need to fix it. Here is how:

“Why can’t you look me in the eyes without crying?”*

As you probably know, computer accounts have passwords. When the computer account is first configured, it’s default password is COMPUTERNAME$. It will change the password and continue changing the password every 30 days. But what happens if a computer is offline for more than 30 days?

To quote Microsoft:

Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.



If password expiration isn’t the issue, why would a trust relationship be broken? Here is a nice starter list for you:

Duplicate Computer Names: If you have two physical computers with the same name, you are going to have problems. You can use this script to help find potential duplicates.

Resetting the AD Account: For clarification purposes, this is not a fancy “Restart Computer button”. That fancy button can be found here.

Duplicate SIDS: This last reason is still in question. If you are properly imaging your machines, you won’t have any issues here though.

Infidelity: Some have reported that repeatedly joining/unjoining different domains can cause this issues – why they were even trying this, I do not know.

“How can I move on with my life?”*

Remote Desktop is your best friend on this problem! Connect to the computer as the local administrator. Because local users do not authenticate against the domain, you should not have any issues logging in. If you are unable to resolve the name of the computer, you can use DHCP to locate the IP address.

Once connected, just open System Properties and proceed through the Network ID Wizard. If you are using PowerShell 3.0+, you can use the Test-ComputerSecureChannel cmdlet. Here is an example:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose 1 Test-ComputerSecureChannel -Repair -Credential ( Get-Credential ) -Verbose

Hopefully, this post will give you some closure on why your trust relationships sometimes fail. If you have any questions (or tips on troubleshooting this problem), please let me know in the comments below! If you want to learn more and learn how to make your IT life easier, then subscribe to DeployHappiness. As a bonus, you will get a free guide on making your own Windows 8 administrative menu!

*All sub-headings are strictly fictional and are in no way taken from 2:00 AM fights that my neighbors regularly have.