Problem: In the past 3 years I've run into the "The Trust Relationship between this workstation and the primary domain has failed" less than 3 times. Those cases were all laptops that hadn't been connected to the network for a long time. Now within the last 3 months I've had 6 incidents, 1 on a desktop always connected to the network and 1 on a virtual server of ours.

Usually the fix is unjoining and rejoining them to the domain. If this issue becomes more prevalent the fix is inconvenient at best and nearly impossible if you have to walk someone through it remotely who is not tech savvy. I'd like to get out in front of this issue if possible.

The cause, I've read, is when either of the machine account (on the computer) passwords (2 are stored) don't match up with the password stored for the machine account in AD. I can see this happening if the machine hasn't been on the network in a while, but this is happening to computers and servers that are plugged into the network 100% of the time or on wireless for very short periods of time.

I'm trying to diagnose if there's a problem with the way our machines and servers are talking to one another that's causing this error to pop up on machines that are always plugged into the network or plugged in frequently enough that passwords between machine and server shouldn't be that out of sync.

Background: Mixed 2003 and 2008 R2 servers, Mixed XP and Windows 7 machines. 3 physical locations split out into seperate OUs.

Research: New machines are not cloned from one image that could cause "same name" conflicts on the network. This is not specific to one OU or another. This is not specific to one OS or another.

I've dipped into system event logs and turned on netlogon debugging with no specific items jump out on my but my Windows Server Log knowledge is fairly limited.

Any help is appreciated.

  • Are the DC's physical or virtual? Was any of the DC's reverted to an older snapshot or restored from a backup?
    – Rex
    Jun 25 '14 at 20:24
  • You can use netdom to resolve the trust issue (to avoid the unjoin/rejoin method), but that doesn't resolve the underlying cause.
    – joeqwerty
    Jun 25 '14 at 20:38
  • @Rex Your question is correct only if the stations who had the problem were random. If they are always the same stations, than that means the problem is on there side. @ joeqwerty How can you solve this with netdom?
    – EliadTech
    Jun 25 '14 at 20:53
  • @EliadTech You can use netdom to reset the computer account password - run the following on the system that needs the password reset: netdom resetpwd /s:<dc_server_name> /ud:<domain\username> /pd:<password of user specified in /ud>(note: username/password are to authenticate to the domain. You can use * for the /pd field to be prompted for a password.
    – Rex
    Jun 25 '14 at 21:43
  • @Rex None of the DCs are virtual. DCs at 2 locations are 2008. The 2 other locations are 2003. No DCs or workstations were reverted to older snapshots/restored from a backup. Jun 26 '14 at 13:56

Have you looked at the File Replication Service/ DFSR logs to see if there are errors there? I have seen instances where corruptions/errors in the USNJournal will cause these types of problems.

  • What? A problem with FRS shouldn't have anything to do with member computer domain trust relationships. That's between the password hash stored in the Directory and obfuscated in the member computer's registry. Jun 25 '14 at 21:07
  • Sounds weird, but I had a situation where we were getting a lot of the Trust issues at a remote site. Investigated and found one of the DCs there had USNJournal issues causing objects to not replicate properly. My guess is that the PCs were updating on one DC, then eventually trying to auth on another that hadn't replicated the new password. When we DCpromo'ed the server out, then back in, no more issues.
    – HostBits
    Jun 25 '14 at 21:34
  • @Cheekaleak Nothing in the DFSR logs, but I did find an error in the FRS that may be related. "The File Replication Service is no longer preventing the computer <our primary domain controller> from becoming a domain controller." Error 13516. I'm researching it currently. Jun 26 '14 at 20:48

I've seen this fairly often when someone shuts the computer down incorrectly (held power button) after the machine password has been reset. The startup repair runs at next boot and restores the computer to a prior state (before the password change) causing this error. The easiest way to fix this that I have found is to log in or remote in as a local admin and run the following in powershell. The credential should be an account with appropriate permissions on the domain.

Reset-ComputerMachinePassword -Credential (Get-Credential)

See the documentation for details.

  • This might be possible for some cases, less likely for one of the laptops this happened to based on the user and highly unlikely for the virtual server this happened to. Jun 26 '14 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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