Home > Active Directory, Authentication, CMDlets, Networking, Powershell, Security, Windows Server, Windows Server 2012, Windows Server 2012 R2 > Fix: The trust relationship between this workstation and the primary domain failed
  1. June 20, 2013 at 20:41

    Reblogged this on TCAT Shelbyville – Technical Blog and commented:
    Excellent article.

  2. July 10, 2013 at 13:38

    Absolutely spot on. my dev sp2010 running under win2008R2 became accessible by domain admin . As aside, the snapshot hierarchy seems very brittle in win8 hyper-v/

  3. Shrimant Patel
    July 17, 2013 at 18:26

    Nothing above worked for me…but I figured it out the hard way…hope this helps others

    1/Turn Off Wifi
    2/Plug in a ethernet cable to the router/hub directly connecting the PC/laptop
    3/take the pc out of the domain and put is a temp workgroup then Restart.
    4/login with local admin, put the PC into the domain, then restart.
    5/login with a domain user or domain admin.

    Next time you shall never have a problem…

    The Wificard/Driver for 64 bit machines is the culprit.

    • Roopesh Chavan
      October 3, 2013 at 18:07

      Done twice, but error pops up again after a day or so. current workaround is to login without any network connectivity and after logged in then connect network cable or switch on wifi.

    • June 10, 2015 at 18:13

      Excuse me Mr. Einstein… but your discovery which you devised all by yourself IS actually mentioned by the author, who went on to say (and I agree) that it was a bit too risky. I find it hard to believe that his solution would not work for you when your ingenious solution did. So I hypothesise that you completed his steps using your Wifi card, which you found later on to be the cause of your issue. By the way, there’s no requirement to disconnect Wifi and connect via wired to rejoin a domain. It’s only because in your case, your WIfi card driver was failing to function properly in 64-bit mode.

      Here’s the evidence (end of 2nd paragraph):

      “The easiest or at least the quickest solution, is to have the server leave the domain by adding it to a workgroup, then joining it back to the domain again. But, this can sometimes be a bit risky…”

  4. Arnab Maitra
    August 23, 2013 at 10:45

    Thanks for the blog, thanks a lot…

  5. Erick Souza
    August 27, 2013 at 16:03

    Thanks for your help my friend….
    This is happened a lot!!!

  6. Faisal
    August 31, 2013 at 06:25


  7. Jason Hanson
    September 9, 2013 at 14:44

    If you change the password part to be /PasswordD:\* It will prompt you to enter your password, and it will not be shown in the CMD box.

  8. September 17, 2013 at 00:30

    Reblogged this on Just Fix IT and commented:
    Very clear guide on resetting trust relationships between workstations and domain controllers.

  9. September 20, 2013 at 22:01

    its done my friend, thanks for your support.

  10. Andrea_Vuoto
    September 24, 2013 at 11:51

    this fix works like a charm !

  11. Lacrima
    October 16, 2013 at 23:33

    “Then use the local server administrator account to logon to the server. (…), so I type the Servername, Backslash, Local Admin and hit Enter.”

    It’s way easier if you write “.” (dot) instead of typing the full local host name ie. .\Administrator.

  12. Gerrard
    November 6, 2013 at 14:08

    The asterix for the password command is slightly wrong – it should be “/PasswordD:*” (i.e., no backslash before the asterix)

  13. November 12, 2013 at 12:56

    I had this trouble in a clients office this morning, It was a simple fix. Disconnect workstation from the network, log in as normal, run system restore, reconnect network, reboot. Done. Might have just been lucky but it worked.

  14. klunde
    November 28, 2013 at 10:08

    The trailing D i in /PasswordD: is for “DOMAIN” /Password without D is local password.

    • November 29, 2013 at 10:43

      Thanks klunde, did not know that.
      Interesting that passwords are treated differently…

      // Thomas

  15. January 10, 2014 at 09:54

    Added a PowerShell method, for the modern man 🙂

  16. halloween
    January 17, 2014 at 02:58

    Fantastic approach to reset the password without disjoining and rejoining the server/client to domain. I applied the above fix in one of my T1 servers which shows the same error because of snaphot restoreation. It really worked !!!!! Thank you a lot for blogging this article.

  17. Jimmy Forth
    February 12, 2014 at 12:22

    Dude, you rock! I reverted to a four day old VM snapshot and the trust was already gone. The powershell step did not work because if the failed trust, BUT the “netdom” command was solid! Mucho gracias mi amigo!

  18. du
    February 22, 2014 at 01:18

    Nice.. this made my day . Was struggling with this issue for more than 3 hours

    Great Article/Approach

    May 14, 2014 at 16:35

    Thomas, Thank You for a well documented and workable solution. Just tired it and it worked great. Keep up the good work.

  20. Alain Freudiger
    July 14, 2014 at 06:37

    Monday morning 7 am… no connection to our terminal server. Booom:”The trust relationship between this…” thanks to you it only took me 5min to solve this! You are THE MAN!!! 🙂

  21. August 4, 2014 at 05:47

    userD , passwordD ==> D may be for DOMAIN… Domain User and Domain password

  22. Tom Rodgers
    August 19, 2014 at 15:03

    THANKS! Worked like a charm!

  23. Todd Bliven
    August 22, 2014 at 19:04

    Ok unplug the network cable log on with your id. Server 2008r2 will let you log in. Now drop the server from the domain, enter the user ID with rights to take it out or add it back to the domain. Reboot as required. Plug the network cable back in and log on as administrator, add it back to the domain, again with a domain admin ID reboot and you back on the domain. I just did this today.

    • August 22, 2014 at 22:35

      Yeah…but that is better/easier how? And, remember that most servers today don’t even have a network cable to unplug…virtualization…
      // Thomas

  24. Ali
    September 21, 2014 at 16:25

    You saved my ass, champ!

  25. Noah Silverguy
    October 3, 2014 at 08:35

    This totally saved me. The Hyper-V server, if disconnected from the domain, acted like it couldn’t see the DNS server in order to reconnect. After about 6 hours of using snapshots, trying to disconnect/reconnect to the domain, I was ready to restore the working configuration from an imaged backup. I don’t know how I finally stumbled upon your guide, but I’m very happy I did.
    Also, if it helps anyone out; I was able to recover having deleted the Computer Object from ADUC with the free Object Restore utility from Quest (http://www.quest.com/object-restore-for-active-directory/). Not having enabled AD Recycle Bin, this saved me from having to boot to DSRM to restore my Active Directory db.

  26. Jim
    October 6, 2014 at 17:32

    Get your admin to reset the computer account. Saw this here http://redmondmag.com/articles/2014/04/21/domain-trust-issues.aspx

    Thanks for the article.

  27. menino
    October 28, 2014 at 09:31

    Yeah this works using netdom for W2008 R2 , make sure you are typing /UserD and /PasswordD . there is a “D” at the end
    Simple Typo mistake

  28. Luis Olias
    November 26, 2014 at 14:52

    Thank you so much, it made the trick for me. Really grateful !! 🙂 !!

  29. November 29, 2014 at 11:41

    Reblogged this on WindowsTechBlog.nl and commented:
    Great solution! It prevent me hours of troubleshooting.

  30. B.Y
    December 3, 2014 at 09:11

    Works like magic. Thanks.

  31. December 15, 2014 at 22:09

    Great article! Solved the problem for me more than once by doing this! I hate rebuilding user profiles after a disjoin / rejoin… it is never fun.

    One thing I noticed that may or may not be just my interpretation:

    Next, we solve the problem by resetting the Computer password in Active Directory and on the Local machine, for this we use a PowerShell CMDlet called Reset-ComputerMachinePassword. Type in the following command:

    Reset-ComputerMachinePassword -Server -Credential

    Could be interpreted as having to run the above powershell command on both the domain controller (or PDC if only one DC) and the local server / workstation.

  32. February 2, 2015 at 00:55

    Thank you, saved me after a RAID crash. Appreciate you taking the time to post.

  33. DaTink
    May 13, 2015 at 16:07

    Saved my bacon.

  34. Tech Dude
    June 19, 2015 at 15:42

    You are Da’ Man!! You just fixed a problem I had for days. Thanks partner. You got me out of a major jam.

  35. Yudha
    June 22, 2015 at 02:04

    Thanks. Your information is good. My problem is clear.

  36. July 21, 2015 at 14:40

    It worked!!!!!!!! Thank you.

  37. JuanL
    August 10, 2015 at 10:36

    You can prevent the error “”The trust relationship between this….” with a GPO:


  38. Chris
    August 21, 2015 at 17:35

    Thanks so much, I converted a Citrix Machine to Virtual and this was not letting me log in! Your solution got me in. I used the netdom command.

  39. Matt
    November 19, 2015 at 07:50

    This is definitely the easiest / lowest risk approach to fixing these errors that I have ever seen. Great post!!

  1. March 25, 2013 at 10:04
  2. May 26, 2014 at 15:41
  3. August 27, 2014 at 18:20
  4. September 5, 2014 at 06:23
  5. January 21, 2015 at 03:19
  6. January 22, 2015 at 05:26
  7. April 28, 2015 at 21:21
  8. June 14, 2015 at 20:33

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: