Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Like many people my network has been getting the dreaded "The trust relationship between this workstation and the primary domain failed" error. I remove the computer from the domain rejoin it to the domain after changing the computer name and everything is back working. I have a 2008 R2 DC, how can I prevent this from happening? Is there a group policy or script i can push?

share|improve this question
Why did you change the computer name? – Greg Askew Jun 19 '12 at 21:06
up vote 6 down vote accepted

There are a few common reasons why this happens.

  1. A computer with a duplicate name was joined to the domain. This will cause the original to no longer have a trust relationship with the domain, since its computer account is now effectively the account for the new machine with the duplicate name.

  2. Time sync is screwed up. You won't be able to log in if the time is more than 5 minute off. Kerberos relies on time being at least in the same ballpark on the clients and servers. Make sure that your DC holding the PDC Emulator role is set as a reliable time source and that all of your other DCs sync from it. Also make sure that there are no alternate time sources configured for your clients via GPO or local policy. The clients should sync time from the logon server.

  3. The computer account was reset or the password came out of sync. Computers log into AD just like users do, and they have a password. This password is changed at a regular interval behind the scenes. If you have replication problems and a computer changes the password on one DC and then later tries to log into another and replication failed for whatever reason, your machine won't be trusted for logon on, since the computer password differs between the client and logon server.

There are, of course, other edge cases why this happens. These are the most common and are where your troubleshooting should begin. There's no script, GPO, or magic fairy dust to sprinkle, since there isn't a normal reason for this to happen.

share|improve this answer
Another common reason: the network is broken. (You'd think this was self-evident, but apparently not.) – Harry Johnston Jul 18 '12 at 3:02

If it happens more than every once in a blue moon, you need to track down the root cause to determine what's breaking the trust relationship. There's no magic policy or script to do it for you.

You'll want to make sure it's not some script or other administrator deleting these machines form the domain, that the machines aren't being "tombstoned," and that your AD is healthy (dcdiag, etc). Your basic AD administration/troubleshooting steps, in other words.

share|improve this answer
Tombstoned objects would have nothing to do with this. When an object is "deleted" from AD, what actually happens is that most of its attributes are removed abd it is moved to CN=Deleted and renamed. That object is now a tombstone. There is a job that periodically runs (every 30 days, I believe - maybe longer) that removes tombstoned objects from the directory. Tombstone lifetime really doesn't factor into this question at all. – MDMarra Jun 19 '12 at 20:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.