Updated 2014-01-10 : Finally added a PowerShell method
| This guide is using the PowerShell or NETDOM tool and does not require rejoining the domain |
Have you seen this? ‘The trust relationship between this workstation and the primary domain failed’
Or this? ‘The security database on the server does not have a computer account for this workstation trust relationship.’ Same issue, different symptom.
I have on multiple occasions beeing a heavy Hyper-V user for my labs…
There are apparently a number of reasons why this happens, but the main reason seems to be lost connection between the ‘client/server’ and the Domain controllers. If the scheduled password change occurs while the server or client is unavailable or has been shut down, then the passwords stored in the server/client and the domain controllers for the computer account mismatch, and you will end up getting this error when trying to logon to the server. It can also appear differently, like if all service accounts stop functioning with events logged as a result, or similar that happens when the server is still running and you have been able to logon or simply never logged off.
The real question…How do we fix it? There are a number of TechNet forum threads on this(added one below as references) and many blog posts allready written, but since I’m always having difficulty finding them myself when I need them, I’ll make my own. Please feel free to borrow this knowledge and reblog/repost it yourself 🙂 (The guide however, is my own creation…)
The easiest or at least the quickest solution, is to have the server leave the doamin by adding it to a workgroup, then joining it back to the domain again. But, this can sometimes be a bit risky, you may have lots of service account running as domain users and so on, you don’t feel like uncoupling the server from the domain at all, then do this instead.
| This guide is taking for granted that you prior to following these steps, have restored network connectivity between the server/client and the domain controllers, else this will fail. Resetting the computer password can not be done offline. |
–
| The following steps are performed on a Windows Server 2008 R2 machine, but the same steps apply to Windows Server 2012 |
Ok, I’ll do as I’m used to and describe what to do in a step by step guide, like this:
You log on to your server like you are used to, using your personal domain account:
You type the password and hit enter, then, BAM! This, instead of the normal logon procedure…what a start on a monday morning…
No good…if you don’t like to meddle with server affairs and are the kind of person who likes to stick to your apps once logged into the server, copy the link to this blogpost and send it to someone who can fix it…else, keep reading.
Press OK and then Switch user.
Then use the local server administrator account to logon to the server.
In my case it is one of my SQL boxes, so I type the Servername, Backslash, Local Admin and hit Enter.
| The Username can just as well be in the form: ‘.\administrator’, with the single dot replacing the servername |
PowerShell Method
New Method, steps performed on Windows Server 2012 but are valid on Win7, Win8x, WS2008 and WS2012R2
Once logged in, you will want to start a PowerShell prompt or PowerShell ISE with administrative privilieges, ‘as administrator’.
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 <Name of any domain controller> -Credential <domain admin account>
In my environment it looks like this:
Hit Enter, you will then be prompted for the Domain Administrator accounts password
Type in the password and hit OK. It will take between 2 to 10 seconds to complete Yoy will then, if everything works, see this:
Yup, nothing overwelming like ‘Succeeded’ or OK…just the released prompt. It is a success though 🙂
Now, we have to do one more thing before order is restored completely, we have to reboot the server. If you don’t, you will still not be able to logon using the domain account.
Use PowerShell…
Or the GUI if you prefer
After the server has rebooted, you are good to go, logon using your regular personal domain account.
Done!
NETDOM Method
Old method, performed on Windows Server 2008R2, but are valid also on WS2012 and WS2012R2, not however on Win7 or Win8X
Once logged in, you will want to start a PowerShell prompt or a Command prompt with administrative privilieges, ‘as administrator’.
Next, we solve the problem by resetting the Computer password in Active Directory and on the Local machine, for this we use a commande called NETDOM.
Type in the following command:
NETDOM RESETPWD /Server:<name of any domain controller> /UserD:<domain admin account> /PasswordD:<password>
(Yes, the trailing D’s are supposed to be there, don’t ask me why…)
In my prompt it looks a bit like this:
| Important! Unlike in this Picture, the domain administrators password will be visible in cleartext, so be careful and close the prompt after you are done! 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. (Thanks to Jason Hanson for the tip, and Gerrard Singleton) |
Hit Enter and if everything works, you should see this:
Now, we have to do one more thing before order is restored completely, we have to reboot the server. If you don’t, you will still not be able to logon using the domain account.
After the server has rebooted, you are good to go, logon using your regular personal domain account.
Done!
If this did not work out for you, perhaps any of these reference links can be of use for you with additional steps and alternate solutions?
Good luck!
References
NETDOM
http://technet.microsoft.com/en-us/library/cc772217(v=ws.10).aspx
Netdom Overview
http://technet.microsoft.com/sv-se/library/cc737599(v=ws.10).aspx
How to use Netdom.exe to reset machine account passwords of a Windows Server domain controller
http://support.microsoft.com/kb/325850
Reset-ComputerMachinePassword
http://technet.microsoft.com/en-us/library/hh849751.aspx
Don’t rejoin to fix
http://www.implbits.com/about/blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/default.aspx
TechNet Forum: The trust relationship between this workstation and the primary domain failed – Windows 7 Enterprise joining 2008 Domain, Error 5722
http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/8155d5ea-a5c2-4306-8d2b-be3464234460/
TechNet Wiki: Trust Relationship between Workstation and Primary Domain failed
http://social.technet.microsoft.com/wiki/contents/articles/9157.trust-relationship-between-workstation-and-primary-domain-failed.aspx
Enjoy!
Regards
blksthl 
Reblogged this on TCAT Shelbyville – Technical Blog and commented:
Excellent article.
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/
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.
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.
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…”
Thanks for the blog, thanks a lot…
Thanks for your help my friend….
This is happened a lot!!!
thanks
Glad if I could help 🙂
Regards
// Thomas
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.
Perfect, thanks! (Adding that…)
Regards
// Thomas
Updated! 🙂
// Thomas
Reblogged this on Just Fix IT and commented:
Very clear guide on resetting trust relationships between workstations and domain controllers.
its done my friend, thanks for your support.
this fix works like a charm !
😉
“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.
Hi.
You are correct, I’ll make an update.
Regards
// Thomas
Done, thanks.
Regards
// Thomas
The asterix for the password command is slightly wrong – it should be “/PasswordD:*” (i.e., no backslash before the asterix)
Hi Gerrard. You are correct, I have updated the post and I have given you due credit.
Thanks
// Thomas
or, alternatively, you can just use /pd:*
Good page for reference: http://support.microsoft.com/kb/325850
🙂
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.
The trailing D i in /PasswordD: is for “DOMAIN” /Password without D is local password.
Thanks klunde, did not know that.
Interesting that passwords are treated differently…
Rgds
// Thomas
Added a PowerShell method, for the modern man 🙂
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.
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!
De nada 🙂
Glad I could help Jimmy.
// Thomas
Nice.. this made my day . Was struggling with this issue for more than 3 hours
Great Article/Approach
Thomas, Thank You for a well documented and workable solution. Just tired it and it worked great. Keep up the good work.
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!!! 🙂
Thanks for the feedback Alain.
Regards
// Thomas
userD , passwordD ==> D may be for DOMAIN… Domain User and Domain password
THANKS! Worked like a charm!
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.
Yeah…but that is better/easier how? And, remember that most servers today don’t even have a network cable to unplug…virtualization…
Regards
// Thomas
You saved my ass, champ!
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.
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.
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
Thank you so much, it made the trick for me. Really grateful !! 🙂 !!
Reblogged this on WindowsTechBlog.nl and commented:
Great solution! It prevent me hours of troubleshooting.
Works like magic. Thanks.
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.
Thank you, saved me after a RAID crash. Appreciate you taking the time to post.
Saved my bacon.
You are Da’ Man!! You just fixed a problem I had for days. Thanks partner. You got me out of a major jam.
Thanks. Your information is good. My problem is clear.
It worked!!!!!!!! Thank you.
You can prevent the error “”The trust relationship between this….” with a GPO:
http://www.sysadmit.com/2015/08/mware-y-ad-la-relacion-de-confianza-entre-esta-estacion-de-trabajo-y-el-dominio-principal-fallo.html
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.
This is definitely the easiest / lowest risk approach to fixing these errors that I have ever seen. Great post!!