First, let me say… I get about 100 unique hits on this post every day. We are not alone! Below, I describe a fix to the relationship. But I want to know THE CAUSE of the broken relationship! If you can help, please post a comment. -Thank you
Added post – 11/17/2015
Wow. This is an old issue… Win 7 on a 2012 Domain now. At the client, simply disconnect the client Ethernet or WiFi connection. Log in with your Domain credentials (they are cached). Re-connect the network connection. Re-join the domain in Computer Properties. I do this by using the simple Domain name as opposed to the fully qualified .com. Roboot, done.
Added post – 2/5/2010
OK, now I’ve got it on Windows 7!
Win7 has been running flawlessly for about three months. I was in the middle of testing various Antivirus solutions… I uninstalled Microsoft Security Essentials, and attempted to install Symantec Endpoint Protection. The setup cursed me, saying a previous operation required a reboot before I could install SEP. I rebooted, logged in, and was presented with a “Temporary Profile” error. I rebooted and the Log in gave me, “The security database on the server does not have a computer account for this workstation trust relationship”
One Solution:
Now, I know from previous experience (below) I could disconnect from the network (Cable and WiFi) and fix it like I did in Vista. But this time I got a quick fix with F8, Safe Mode (without network), System Restore. All is good.
Some info I liked from a TechNet post:
“First some basics you most likely already know.
1. Computers are security principals just like users
2. Computers authenticate to the domain on startup
3. Computers change their password every 30 days by default
4. Restore Points restore the computer password present at the time of the restore point
5. If the local password and the domain password are not the same the computer must re-join the domain”
Older Vista Solution:
The Vista user can log onto the machine with cached credentials (NIC disconnected and WiFi off), but not when connected to the LAN. ERR, It worked for the last year, just fine. Oh well…
You may also get this error: “The security database on the server does not have a computer account for this workstation trust relationship.”
As the error indicates, the relationship between the client/server is broken. Let’s fix the relationship.
Kill and rejoin the Domain… (with PC rename in between)
On the DC:
Delete the offending Computer Account that resides in Active Directory.
Delete the Computer’s IP Lease(s) in DHCP
On the client (with no connection to LAN):
Log onto the local machine (not the Domain) as an Admin.
Unjoin the Domain by joining a “TEMP” workgroup. Reboot required. Log into TEMP workgroup as the Admin.
Rename the Computer. Reboot required.
Log into the Local Machine, now rejoin the Domain. Reboot required. Login into the Domain.
Test network access and life is good. The Computer exists in AD and DHCP.
Rename the Computer back to what I originally wanted. Reboot required.
Test network access and life is still good. The new Computer name is in AD and DHCP, as expected.
Come on people, this post gets tons of views. Give me some feedback!
Solution by robertoLB. And confirmed by funflex.
How To Use Netdom.exe to Reset Machine Account Passwords
http://support.microsoft.com/kb/260575
Solution from DailyAdminLife?
Solutionfrom Paul?
Daily Tweak 
Pingback: DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed – The Implbits team blog | Process Studio
I trust the Time Sync is bringing on the trust relationship issue. Subsequent to rebooting servers, it doesn’t synchronize to the opportune time and date. In summon brief, wrote in w23tm/resync then gives us a blunder message. Need assistance!
Kind of interesting that you posted your question on Dec 20, but I just got the notification, like, 40 days later. So this might be a tad late, and you might have figured this out already but just so you don’t think that your question landed on deaf ears, it just didn’t land. The command should be:
w32tm /resync (with the digits switched and a space in between).
Use w32tm /? for more info.
Of course, that presumes that you have all systems in the network syncing to a reliable internal source, and that internal source syncing to a reliable external source.
Brother, you saved my life, it was a financial server (virtual) cloning it, booting the clone and renaming it, (clone) caused the AD account mess.
Because the computer has a password like an user. And the password is changing pretty often.
When you cloned it, the password did not match anymore.
no. it’s machine password
I’m happy I came across this helpful post. I remedied a “trust relationship issue” yesterday (after a harddrive crash and replacement), but after one day of operating correctly I lost trust and now I continue to login to a temporary domain. I reset the computer on the active directory and also deleted and added the user, but I haven’t tried disconnecting the network cable… Just out of curiosity and “learning to fish” what does that do? Is it a registry or settings fix? Thanks for your help!
disconnecting the cable is a temporary fix. without the domain server available (cable disconnected), the pc uses cached credentials on the local system just to get you up and running.
To be honest I still learning here. My issue started when I applied new policies to the domain and then tried to pull them from the DC. I kept getting an error stating that it was not able to authenticate the computer. I played around with it trying different things to get it to update using gpupdate /force but it would not. I am not sure how I got to the next issue I am currently dealing with right now which is I get the message upon attempting to login “The Security database on the server does not have a computer account for this workstation trust relationship”.
I am not sure what I did to have this happen, but I have tried to disjoin from the domain and rejoin the domain several times and I have not been successful with getting past this error. Lack of knowledge on my part I am sure is also to blame here. I have been poking around on the web to see if I can find information about this issue and what to do to fix it. It is drving me nuts because it is recgonized in DNS I can ping from the DC and the client they can talk but it just will not allow me to log in with my domain accounts. Anyway I appreciate the info from this blog and I will carry on in hopes that I will figure this out.
Did you try my step?
1. unjoin the domain then login as the local admin- go into regedit- find HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\ProfileList-
2. Under ProfileList delete all users who reference the old domain- Before hand, go into C:\Users and delete their folders.
3. What I would assume is happening is that since win7 uses C:/Users instead of C:/Documents and Settings there is a problem with the NTData file.
Remember this is deleting their user information so make sure all data is backed up. Afterwards, reboot and rejoin the domain- Bam! Should be good!
I believe the Time Sync is causing the trust relationship issue. After rebooting servers, it does not sync to the right time and date. In command prompt, typed in w23tm /resync then gives us an error message. Need help!
When I initially commented I clicked the “Notify me when new comments are added” checkbox
and now each time a comment is added I get three e-mails with the same comment.
Is there any way you can remove people from that service?
Thanks a lot!
You can “Manage Subscription” from the link on the bottom of the email you receive.
Pingback: DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed – The Implbits team blog « woo.da.way.spaces.live.com
I found this. It documents a way to fix it without unjoining from the domain. Also in the comments section a guy noted a different way.
“I’ve been finding the machine name in AD and right-clicking > ‘reset account’…that seems to do the trick in 1 of 1 test case for me on our domain.”
http://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
I LIKE THIS! RobertoLB did mention this above.
Pingback: Windows 2012 : the trust relationship between this workstation and the primary domain failed « SharePoint by Asipe (Benoît Jester)
Tried it but after a week the error repeated.
Try the advice from “DailyAdminLife” or “Paul” on my post. Let us know what gets you a permanent fix.
One thing I have noticed is you do not have to remove the PC from the domain if you use the “Network ID” function on the client, following the wizard it comes up with something along the lines of “this pc account already exists, do you want to use it” click yes, complete out of the wizard (making sure you do not add a user to the domain as its not necessary) restart and there you have it
Thank you!!!!! This did it. I appreciate you posting the solution!
Thank you very much for this post! It is not something that happens often, but this happened at my workplace where a PC had a system restore carried out without informing me. Following this info, I was able to resolve the issue in about 15 minutes.
thanks, you’re a god! 4 hours to solve this problem!!
I resolved this problem by performing the following steps:
> Open ADSIEdit.msc (on one of the DC’s)
> Edit the following entries on the computer object
>> dNSHostName – with the FQDN of the object – for example server01.contoso.com
>> servicePrincipalName – added HOST/Server01 and HOST/Server01.contoso.com (edit to match your server/domain)
Interesting. I have not personally experienced the trust relationship error for some time. My ADSI Edit settings are as you suggest. Perhaps it is the reason I running without error. Have you tried reversing your change to prove your theory? Or are you confident in some other way? What was the original setting that was creating the trouble?
We saw the issue with one of the servers (2003 R2). On more digging we are getting this when we try to access the shared resources from this server using an IP, but everything works when access using the hostnames.
This happened to only one of a group of Windows 7 Pro PCs whose group policy was removed. Your blog helped. Did not have to rename the PC, it had static ip. Thanks.
Does anybody know what causes the trust relationship to fail in the first place?
Never had this issue with XP…
Try the suggestion by DailyAdminLife or Paul at the end of my post. Let us know which one fixes you.
Leaving feedback because this helped me. Thank you
I May not be able to prevent the problem (seems that nobody can) but this should speed up the recovery from it. We use altiris for management and it is able to still communicate with clients that have dropped off the domain and run commands using the system account. Using it, I can send these two commands via cmd script and have it remove the old computer account and rejoin without having to logon. The semicolons designate where normally the next line of powershell code would start and allow for a single command to be used instead.
Powershell -command $pass = convertto-securestring “PlainTextPW” -asplaintext -force;$domaincred = new-object system.management.automation.pscredential ‘d204\d204joiner’,$pass;remove-computer -credential $domaincred -force
Powershell -command $pass = convertto-securestring “PlainTextPW” -asplaintext -force;$domaincred = new-object system.management.automation.pscredential ‘d204\d204joiner’,$pass;add-computer -credential $domaincred -domainname ‘d204.ipsd.net’
Hi,
I had about 40 clients drop off my domain with this issue, after Windows Updates!?
I’ve been releasing them in stages, updating a group of computers each day, waiting for updates to apply and then checking all is alright until moving on.
Suddenly on day 4 of the release cycle from my WSUS server the previous working groups of computers start to fail: “the trust relationship between this workstation and the primary domain failed”.
Had to do the whole, unjoin, rename, delete old computer account, rejoin fix. Checking my AD event viewer in Directory Services I had a heap of error 5772 “access dennied”.
I too am looking for the root cause.
Oddly enough, I seem to be having the opposite problem….
I’m working on labs for a cert exam and trying to reproduce the trust relationship failed error so I can go through the steps to fix it. I deleted the computer account from AD (~24 hours ago) yet the trust relationship error does not show up on domain login and the user is still able to access shared resources. There are trust relationship failed errors in event viewer (time sync fails, computer node of GP is not applied, no ldap connection to DC created) but I was also expecting the error to prevent logon.
If anyone could explain why this happens or point to some relevant documentation I’d be interested.
I have 3 or 4 computers in my domain that have lost their trust relationship that I need to rejoin, but I am not going to until I know how to do it without the system creating the new profiles.
Try the Safe Mode/System Restore method. That certainly will not create a new user profile.
1. In AD Management Console, right-click on the computer account and choose Reset
2. On the computer that can’t log in, disconnect the network cable then log in normally
3. Reconnect the network cable after log in
4. On Computer properties page, go to computer name tab and then use the domain join wizard (the Network ID button) to re-join the PC to the domain without un-joining first
This refreshes the computer account and sets up communication again between the AD server and the client.
I LIKE THE SOUND OF THIS! Simplist solution, yet. I will try it. To others, be sure to let us know if this works for you…
I just ran into this problem again on our domain. Only this time I was manually installing 5 failed updates for office 2007. after restarting I got the error. I was able to log in as the local admin and remove the updates and restart and login to the domain. I had another user also login to test the domain relationship. However I am now paranoid that other microsoft updates could have this effect. If you can’t trust microsoft updates who can you trust.
Safe Mode / System Restore is good place to start when a Software/Hardware Install/Update causes an issue.
Hello dailytweak,
I have this issue repeatedly and I can rejoin the computer to the domain, but when a user re-logs into the machine a new account is created and I need to copy all the users data to the new account. I do not see anywhere below any way to attack this issue. I do see one other post by Kieth Gardner with the same issue about the new account having the .000 on the end of the user account. I also do not see anything in regards to why this happens and what can be done do ensure it does not keep happening.
Thanks
i dont know why you are creating a new user account. none of my suggestions include that. you must be following a different path… the netdom command may be a better solution for you… follow paul’s advice or dailyadminlife’s advice to stop it from happening in the future. let us know what worked for you.
That is just it, I don’t create a new account the user is logging in using the same name and password but the computer creates a new profile on the computer. I am sorry I guess I was using wrong terminology, because a new account is not created, it is a profile on the computer not in the domain. I use exactly the steps outlined about removing the computer from the domain and then re-adding it back to the domain.
Be sure to see Robert’s (dailytweak) response, as well as mine. I want to make it clear that the situation of the .000 account was created by me in performing an unnecessary step that was NOT called for in the related article. It was rather the result of deleting and re-adding the USER account from Active Directory server. Had I left that alone, and instead deleted and then added the COMPUTER account, as the article calls for, I would not have had the problem.
I never deleted a user account anywhere. all I did was leave the domain and rejoin the domain. after rejoining the domain I logged onto the computer with admin account and the system built a new user profile which was named the .000
Are we ever going to get an answer???
as an administrator I should know better…BUT, a user was getting a new computer and I inadvertently gave the new computer the same name as his current computer and joined it to the domain without first renaming the old or removing the old. that is how I lost trust relationship with the domain
I can’t believe there’s no mention of the fact that this process does not allow the user to sit back down and pick up where they left off. Rather, it creates a plain vanilla user space on the computer! You’re not enabling the previous user to access his files the same as they were before, you have to do almost all the stuff you have to do when setting up a new computer. There are now two users in the Users folder: username, and username.000. As you know, they are not the same! You have to copy all the user files, set up Outlook data files and accounts and addressee shortcuts, any customizations to any programs, Excel, third party programs, etc., reinstall all certificates and options in IE. This is NOT TRIVIAL! It’s a major ordeal that takes at least an hour more to do, so should be at least mentioned in the “by the way” of this process!!
So while I do applaud (very much!) the explanation of what caused the problem (the “Some info I liked from a TechNet post” which really explained all I needed to know about the “why”), and the process of correcting it was also well thought out and explained just enough to be able to do it. But leaving out the fact that you would wind up with a NEW user account on the computer seems a major omission.
Which solution did you use? I have not experienced the issue (i.e. new user account created on the workstation) you describe. Thousands have read this post and you are the first to raise the issue.
I think if you use the netdom resetpwd… command you wouldnt be creating another computer account. It only re-authenticate the current account. I did this and it worked for me like magic.
I used the “Kill and rejoin the domain/Rename the computer” solution. However I have replayed my own steps and I believe I created the condition by a previous change I had made in which I had deleted and re-added the user account in AD. The reason I did this is that on the given workstation, I was able to log in as administrator but not as regular user. I thought this would cure it but is probably what caused the bigger mess I described. Right?
It has happened to me several times. It appears that a user logs off and when trying to log back in they are no longer on the domain, the computer name is back to default. I have to rename the computer, add it to the domain and copy all the files, programs to a new profile.
In the other senario, a user logs on using the same credentials as always and a new profile (same as the old profile with… at the end. I have to copy all files/folders to the newly created profile as well as reload all the software. uggghhh
your fix is much harder than it has to be. use one of the fixes in my posting. also, you should try some of the solutions provided to prevent it from happening again.
Hi Angel, If you look at my post from 27MAR2012 I addressed this issue, and no one has posted an actual way to get the old users profile reconnected to AD. the only way is to do what you did, by copying and pasting all the users data into the new profile.
Followed the restore instruction on here and it worked perfectly! Thanks for saving me a lot of time!
Hi all, i am writing from Lagos Nigeria. I have decided to comment since this thread saved me a great deal. I have a VM server that acts as the domain anti-virus server. Sometime last week, i noticed the VM wouldn’t start up as it was failing for some reason. The first reason that came to my mind was to revert to a particular snapshot. That i did and everything was fine until today i came in and found out i couldn’t log on to the server with domain account except local account. I followed the instruction out here and it worked for me like magic. Thank you all.
I show a couple methods. Which method worked for you?
netcom resetpwd /s:ADserver /ud:domain\username /pd:*
OK, let say how I fixed it.
In one case, the error had recurred everyday, and the solution was to recreate the computer account in Active Directory, by erasing it and re-joining the computer to the domain. That was easy, and the computer never complained again. But, look, in the properties dialog of the computer in ActiveDirectory, there was a tab with some words: “Owner of the computer: ldsurname”, or something like that. When the account get recreated, there was nothing seemed.
Beyond that, we have the everybody’s daily nightmare of “trust relationship error”, in a percentage of our Win7 computers.
Also easy to fix. Just tell the user to add the complete domain to the username, like that:
username@domain.edu.ar
domain.edu.ar\username
Microsoft sucks!
Bet for Linux!
Greetings from Argentina,
Emmanuel
in http://communities.vmware.com/message/1589604 :
netdom resetpwd /s:activedirectoryservername /ud:domain\User /pd:*
Did this work for you?
My brother suggested I may like this website. He was entirely right. This put up actually made my day. You can not believe just how so much time I had spent for this info! Thanks!
I work in IT and just ran into this issue with a VP’s laptop. his W7 machine has been working fine since he got it. Today he had no problems until he came back from lunch, which is when the trust relationship was gone. He always works wired too. Now yesterday I had been cleaning AD, specifically disablling some old machine that weren’t properly removed from the domain. I looked at every machine account in my company (over 1000). Today after the error, his machine name has a lot of characters and symbols added to the name, and the Pre-Windows 2000 name indicates “Duplicate”. What?? His machine was fine all morning, and he locked it for lunch. I found this article after the fact, but the fix was exactly as you describe – change the name, remove from domain, reboot, re-add to domain, reboot. Windows 7 even loaded his previous profile, unlike Windows XP where you had to redirect the new to the old. My question, how does a machine work fine for a year, everyday, then one day you go to lunch and the trust relationship breaks when nobody is using the laptop?
I work at a college where this happens to instructor PCs in the classrooms. We use a product called deep freeze that holds everything in the desired state and refreshes upon reboot. No changes can be made to the local device without first thawing. I suspect it has something to do with the longstanding habit of skipping sysprep when imaging these machines. They are all based on the same image which was usually joined to the domain first. I think that they are ending up with duplicate SIDs or machine IDs on the DC, or something to that effect. We usually fix it by thawing the device, logging in as a local admin, and removing and re-adding it to the domain. This has worked every time but it continues to recur. It usually happens in groups about every year or so. I’m not in charge of the imaging of those computers so I can’t say exactly what is going on, but it doesn’t happen to my computers in my library or labs (around 300 computers and laptops). I am about to start adding sysprep as a step when imaging because I want to do things correctly. Did you fresh install or image your laptop? And did you sysprep?
All local installs in my case. No imaging
Interesting — this site/page is absolutely the only hit I found when I looked up “the trust relationship between this workstation and the primary domain has failed”. Good instructions, but more than I can do to fix, but at least I know what’s wrong
Well here is an interesting twist on this issue. I have a very very simple domain, windows server 2008, two windows 7 workstations. Nothing fancy at all. One PC has started having this problem.. all.. the.. time… My nasty twist is, when it happens, I can rename the computer, but it won’t let me disjoint the domain, won’t let me switch to a work group, so there is no way of implementing the easy fix. If I try to do those things, its just it prompts me for credentials, the wheel spins a few seconds, and then it acts as if I did nothing. It don’t take me back to the PC properties screen and prompt me to reboot, just stays on the rename screen. If I pull the network cable, I get the “no available authentication servers” error. If I delete the PC in AD, same problem. I sync the time, same problem. Only viable solution I have found – reload windows. Delete the PC from the AD. Then join the network as a new PC. This has happened several times now. No idea what else to try, I am stumped.
had issue with Win7 ‘The trust relationship between this workstation and the primary domain failed’. This happened when a user tried restoring to earlier point and the process became corrupted (so I was told). All users were unable to login to network except administrator. I think an impatient user aborted by hard restart. Resolved by taking off domain, reboot and adding back. Final reboot and all worked.
Heres some more information that might be helpful,
Windows – “The trust relationship between this workstation and the primary domain
failed”
Pete
PeteNetLive
Pingback: Trust relationship error on Windows 7 - Page 3
An excellent read to a known issue. I have experienced this issue on a few Windows 7 Enterprise machines in a network with one DC. Simply putting it on a workgroup and back to domain was not the solution. In the end deleting the computer object and giving it a brand new name solved the issue.
Thank you all for your input, very useful for someone like me to stumble upon,
Jay
Deleting the object and rejoining usually works without rename
ONE SOLUTION: (Or at least what worked for us.) We had a workstation with the exact same error message. Rejoining the domain did not correct the issue. The only thing which worked was to use an entirely different computer name, which was not our preferred solution. After much searching (including finding this page) and gnashing of teeth I finally found the problem in our domain.
There was a duplicate SPN (Service Principal Name) registered on another computer account. For some reason setspn -X was NOT finding the duplicate entries. Instead I ran setspn -Q */hostname* where hostname was name of the computer. (not the FQDN)
This turned up another computer account with a duplicate SPN:
C:\Users\tblackerby>setspn -Q */hostname1*
Checking domain DC=mydomain,DC=edu
CN=EDBB9F19DB3E435,OU=Other Computer Objects,DC=mydomain,DC=edu
HOST/EDBB9F19DB3E435
HOST/hostname1.mydomain.edu
CN=hostname1,OU=Lab Workstations,OU=Workstations,DC=mydomain,DC=edu
TERMSRV/hostname1.mydomain.edu
RestrictedKrbHost/hostname1.mydomain.edu
HOST/hostname1.mydomain.edu
HOST/hostname1
RestrictedKrbHost/hostname1
TERMSRV/hostname1
Existing SPN found!
I used ADSIEdit to remove the SPN off of the conflicting account, waited for replication, and was finally able to login to hostname1 without the error!
To verify I can recreate the problem by putting the duplicate SPN back on the other computer account, which immediately causes the error again.
Awesome. Will do some research. Thank you.
Tom B.,
Can you walk through the process of using ADSIEdit to remove SPN? I see the command line process which might work but i would really like know each process so the next time i run into this issue i can have resolutions in place ☺
My issue regards the same trust issue and after a handful of tries of removing and adding pc to domain it worked! But i soon realized that we would get the trust issue again when trying to RDP into the machine.
Thanks,
LC3
This may be a potential cause/fix. Still pending verification. 30 days issue-free.
http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/
It has been some time now. Do you believe your solution has resolved this issue?
I have not seen this issue since I implemented this change on all my 2008 servers. It seems to have been the root cause, in my case.
I had this issue at a site with multiple domain controllers and two physical locations, however I believe the issue turned out to be rather simple. We had 2 new laptops that were not named differently when we joined them to the domain. PC1 was setup on one day, then 2 weeks later, we setup PC2, that very afternoon PC1 lost it’s trust relationship, it was easy to fix but we didn’t know why it happened. Then a few more weeks later PC2 lost it’s trust relationship, fixed it again but still didn’t make the connection.
1 week later again, PC1 lost it’s trust relationship. Went onsite and in event log found an NetBt error that said something along the lines of could not register “User-HP :0” at ip xxx.xxx.xxx.16 because it is already registered at ip xxx.xxx.xxx.36
It finally dawned on me that the other tech that setup each laptop didn’t bother changing the name before joining the domain. What I can’t figure out is why there wasn’t some kind of notification that a name conflicted. It could be due to the other laptop being offsite or turned off. I’d always thought you can’t join with a name already in use.
Anyway I’m pretty confident this will fix the issue, but time will tell.
Yes, typically the DC will curse you when you attempt to join with a name already in use. While your Trust error message may be the same. I am sure it is not the same cause/solution we are discussing elsewhere in this thread. Thanks for the input. Hundreds read this thread each day. Some may find it usefull.
I made an account just to post my solution, and usually I never respond. But to see so many conflicting reports on how to fix this, I wanted to throw in my helpful fix that finally worked for me under WinXP and Win2003 DC. Thanks to woodmouze and JelloIR from http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/8f614ca0-0a83-4ebc-a936-d8b669ef52e9/
1. Unplugged the network cable, so it logged on with (the same) cached credentials. I logged on as the Local Administrator.
2. Under System Properties, under Computer Name, goto Network ID.
3. Ran the network wizard with the network cable still unplugged.
4. Right after you type in your credentials under the User Account and Domain Information screen, I plugged the network cable back in.
5. It asked me to verify again with my Administrative account to my domain, it took it!
6. Rebooted, and everything worked again! Reconnected to Domain without any issue.
Great solution, worked for me with Windows 7 Workstation and SBS 2003!
lots of suggestions here. which one worked for you?
Brilliant – Thank you. Worked on Win7 and SBS 2003. 🙂
Perfect, perfect, perfect. Those five steps fixed the trust problem for me. Thanks!
Window 7 workstation.
Right so i have AD set to Server 2008 R2 funcional Level, and while tring to add a nother server 2008 r2 to the domain I’m getting this error. Tried everything mentioned here, nothing works. When joining the domain it allows me to join however throws up and error “unable to change primary dns name” sigh ….
Fixed it. Right clicked the computer account in AD and selected “reset”. From the other server I logged in as local box admin and ran “nltest /sc_change_pwd:mydomain”
Thanks for the input
I am having this issue as well on 2008R2. My issue is a bit more sensitive, as it is happening on my exchange 2010 server. Rejoining to the domain is not an option. Currently, I am able to restart the server in order to resolve the issue, but I am concerned on how long this will work before it doesn’t anymore. I have a handful of 2008R2 servers as well and Windows 7 clients. It does the same thing, although less often on the clients.
I have been able to successfully log into a server that is actively having this issue by using the UPN name (nate@domain.com) and password. Using the short name (domain\nate) will throw the error of the trust relationship.
20110624 update.
As I mentioned in my post from yesterday, we had a system that had a broken trust relationship condition because it was offline when a major Domain change took place (basically, it’s domain disappeared).
By setting up a temporary workgroup of one, we were able to remove it from the old domain that persisted on this system. I want to caution all that you should NOT do this without first verifying that you have a local user account that is enabled. If you go from a domain, into a workgroup without an enabled Administrator account, or any other account for that matter, you are basically UCNP (up creek- no paddle)- none of the domain profiles in Users will work. Now, if you don’t heed this, there is a fix, w/o having to do a rebuild, but I digress.
Restart after making the change into the workgroup. Log back in as local Admin, and Go into Cmptr Prpt., Computer Name tab, and run the network ID wizard. After we did that, our log-on dilema was fixed. Thanks to you @ DailyTweak for the guidance!
Our server was upgraded from 2003 32-bit to 2008 64-bit. We also got rid of all the “child domains” and now have one big domain with groups. The last time that this Dell Tablet was on it was a member of the old stucture. The next time it was turned on the whole network had changed. We got the error, we can only log on locally and cannot see any network shares. In computer properties, we see the old domain name, and have tried to change it, however, the problem recurs. I tried ipconfig with the release/renew switches, no-go. We also thought it might be a profile issue, but I’m thinking that rip van winkle here has just had a rude awakening not getting the memo about the major network changes, and it just needs to be “refreshed”. So no need to redo the profile which is a major PNA. I’ll present your suggested procedure to our admin, and see if he concurs, then I’ll let you know how it goes
I have been insisting on XP downgrades but could not avoid it in our recent new laptops purchase. This error has been occurring for us too and I have followed all the early advice: remove device from AD, rename machine, rejoin domain, etc. We also do not have Exchange running (Google Apps, thank goodness) but this problem seems to occur when bring the machine out of sleep mode. It does not always work to remove the network connection either (damnit!), a restart is necessary.
Not very keen on the dumping registry setting though – imagine telling users to go that route!
Still need to try the AD Group Policy corruption work around.
Hi!
I’m having the same problem, cause i’ve cloned systems. I temporarly solved this as mentioned below, so I hope it’ll help someone.
1. unplug the network cable (preventing the server for checking credentials)
2. login to your pc with your server credentials
3. plug the network cable – now all is working except the internet
4. instal the fix from microsoft http://support.microsoft.com/kb/976494 – internet is working
5. you msut do this steps everytime you turn on your pc or log on 😦
Note, that this is just a temp solution. When I found the permanent and simple solution, i’ll post it here.
Worked for me. Thanks
I have been havining this issue ramdomly at the school where I work. Unfortunately, local admin accounts are renamed, have their names changed, and passwords are changed. Consequently I have no way to log into the computer once it has this issue. I guess that I am stuck reimaging the computer.
When one of the users in my domain were trying to login to their windows 7 OS, they were getting this error. I came by this blog and tried your steps and This worked like a charm!! thank you!!
This seems kind of long. I get what he is doing though. What I would do instead is unjoin the domain then login as the local admin- go into regedit- find HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\ProfileList- Under ProfileList delete all users who reference the old domain- go into C:\Users and delete their folders. What I would assume is happening is that since win7 uses C:/Users instead of C:/Documents and Settings there is a problem with the NTData file. Remember this is deleting their user information so make sure all data is backed up. Afterwards, reboot and rejoin the domain- Bam! Should be good!
Unfortunately I haven’t yet found a solution to this, but I know how to reproduce it without fail.
In our environment we have Win7 connected to a DC with 2003 Standard. It also has an Exchange 2003 installed on it (its a test env). To get the trust error message all you have to do is disconnect the network by any means. (pull the cable, disable the adapter, restart the computer, let the computer sleep, etc). As soon as I reconnect it I get the trust error. I can only ever log in after reconnecting to the domain up until the network connection is cut.
I have a feeling Exchange is involved since lots of people seem to have the issue with SBS server. Has anyone seen this issue with a 2003 domain controller that dose not have Exchange installed??
Okay, looks like we found our problem. It was to do with group policy. One of our policys appears to be corrupt. Disabling it lets the system work. We worked through it removing changes one by one but couldn’t find a specific setting that caused it. So we deleted is and are rebuilding a new policy which appears to be working.
This is easy to test in anyones environment. Simply disable all of your policys and test to see if the issue occurs. Then re-enable them one by one until you find the culprit. I really hope this is the cause for other people.
Thanks!
Paul:
You said that you found a way to reproduce the problem without fail. And your “test procedure” makes a lot of sense and my experience fits into your description.
A tightly defined bug is much easier to fix than a bug with a “fuzzy” description. And so I would think that MS would be able to fix the bug that you have described. If they have a fix, then I’m wondering why we are still seeing the problem.
Since we’re still seeing the problem, I’m wondering if there are any additional ways of producing the problem.
I don’t know, what do you think? Have you found a solution for the bug you described?
I tried every remedy listed here before I found this site that instructs how to run netdom locally with a specified partner. Doing so confirms the connectivity between computers and then allows the newly-reset machine account password to propogate to all others.
Note that the title is a bit misleading and that the advice will work for systems other than domain controllers.
http://support.microsoft.com/kb/325850/en-us
thanks. i will check it out.
Verified that your Microsoft support link using the netdom command works in resolving broken computer object password issue – which shows up as the symptom as described in this thread/article. I just repaired a Windows 2008 R2 server using it. Did not require reboot. Did not require removing/rejoining to domain like we had done before in the past when this problem showed up.
FYI, this article displays why machines lose the trust relationship, and how to prevent Active Directory from doing it. It creates a security risk though:
http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
had not seen this technet article. nice.
Strangley enough guys this seems on my side as if all my service pack 1 windows 7 machine have this random issue. I have applied a hotfix from MS that claims to resolve this, hope it works as I cannot have users calling me every few hours with the same problem.
Has anyone found any reason for this issue.
I am running sbs 2008, 56 windows 7 64 bit sp1 network, 6 app servers with sdc for replication and dns backup.
can you point us to the specific hotfix?
At one point I saw a post concerning system restore and issues with the trust. Here is what I found worked for us for that Specific issue:
Background:
1. By default a computer will change its computer password every 30 days.
2. By using System Restore at a point after the password change period expired twice and restoring to a point before the password changes, domain user accounts on the machine are disabled and they will receive an error message when trying to logon.
a. This occurs because there is no locally stored password that matches the machine account password in Active Directory.
3. By using System Restore at a point after the password change period expired once and restoring to a point before the password changes, the next password change may not occur when it should. (Netlogon errors)
a. This delay occurs because System Restore rewrites the LSA (local security authority) secret with a password with the same values. This updates the time stamp on the secret that the Netlogon service uses to determine when to change the password.
Source:
“Issues with domain membership after a system restore.” Microsoft Support. March 30, 2005 – Revision: 4.1., Web. http://support.microsoft.com/kb/295049/
Cause: When you join a computer to the domain, a computername$ account is created and a password is shared between the local computer and the domain. So both the local computer and the domain have the same password for the same computer. This is a good thing.
System Restore only rolls back the local computer state, and thus only the local computer password. The information about the computer in Active Directory is not changed with System Restore, creating a password mismatch. This is a bad thing.
To ensure the System Restore process does not create a domain issue, both points brought up in 2 and 3 above should be addressed.
Resolution:
To fix symptom 2: Move the computer into workgroup, reboot, re-add to domain, reboot
To fix symptom 3 (force reset of computer password): Run the following command: nltest /sc_change_pwd:domain then press enter.
We are a software company that uses many servers in a test environment. This has been a problem for us with the servers that have been imaged and restored. One of our engineers found this on a website:
Trust Relationship Between Workstation and Domain Fails after you restore to a previous snapshot for either VMware or Hyper. This is because by default every 30 days the Active Directory(AD) server will change the machine key for each of its members. In a development environment where security is not important. This can cause a headache, causing you to unjoin then rejoin servers back to the domain. The other option is to disable this function.
1.On the Domain Controller : Launch Group Policy Management -> Control PanelSystem and SecurityAdministrative ToolsGroup Policy Management
2.Edit the default group policy or edit the GPO of your choice.
3.Edit “Domain member: Maximum machine account password age” = 999 Located -> Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options
4.Edit “Domain member: Disable machine account password changes” = Enabled Located -> Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options
5.Edit “Domain controller: Refuse machine account password changes” = Enabled Located -> Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options
6.Lastly run “gpupdate /force” on all servers that need this change.
Hope some of you find ths useful.
This looks great! Thank you
Didn’t work for this Windows 7 Pro box, I have a samba domain, and have applied the same patches all over the office today. This one is giving me fits.
Has anyone noticed what type of network the users selected when they were having the problem? I just had the first issue with this on a Windows 7 Pro machine and saw it was using Public, rather than Work, in Network and Sharing Center. After changing that it worked, but I also had gone through and wiped out the computer object from AD, DHCP, and DNS and re-added the machine using a new name at the same time. After running across this I was curious about the network type though and if that possibly had anything to do with it
This works. Add for newbies that you have to delete the computer from
DNS as well.
Great thread. I work in a large environment with multiple DC’s. I am experincing the same issues as everyone else. However, there is no rhyme or reason for the errors. Example: A machine that was receiving the trust issue on a friday afternoon, is now able to login on Monday morning. Nothing has been done on the front/backend. It just simply started working. I have many machines with this issue, and for me the quickest way to fix it is to remove it from the domain and add it again. This has been a giant pain for all involved. All machines have been win7 so far.
I’m getting this error when using sysprep and win7. I’m using sysprep to join the computer to the domain. The OS does show that it’s joined, but there isn’t a computer account in AD. Simply unjoining/rejoining the domain fixes the problem, but when you’re doing this in a lab of 25 computers, that’s a time killer. I’ve tried using the FQDN and the short name, neither of those will allow it to join correctly. Any ideas?
justncase97 gave me this a while back. Any help?
I worked at a couple places having this issue. We were able to solve it at both. At one place we had to set the domain suffix in the gpo local.yourdomain.com or whatever yours is.
If that does work I found this other solution that helped.
On your Domain Controller:
A) Start > Run > ADSIEDIT.MSC
B) Go to Domain Partition and find the affected computer
C) Rightclick and Properties.
D) Doubleclick ServicePrincipalName
E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.
Hope that helps.
Actually, I figured out what was happening. When removing the section in the sysprep xml file, that allows a prompt for a computer name to appear. This is critical in our environment. The problem is, when you remove that section, you get the name prompt, but only AFTER the computer has been joined to the domain. Since the PC is joining the domain BEFORE you’ve named it, sysprep automatically names the PC, then it’s joined to the domain. It’s after that process that you name the PC, but you’re naming it something different because of a naming scheme, whatever. This causes the trust relationship to break.
I’ve fixed my problem by following this really helpful info: http://blog.doah.org/http:/blog.doah.org/my-experience-with-windows-7-sysprep/
Thanks for the feedback. We are helping hundreds of others
yea, that did the trick, thanks for the help
pretty certain that fixed it, its about 180 gigs and im just over halfway, as for what caused it this time around?
i think it’s due to shutting down the pc before it gets to back up, so when it boots it says hey we were supposed to backup on the network and then the nas said sorry too late, and then my computer said “what do you mean? you dont trust me?” HAHHAHAHA, i hate this problem.
ok so i rejoined the domain now and renamed my computer and reset its account on our server, if this doesn’t work i’m gonna be pretty irritated. currently in progress…
aw, major bummer, i just got the popup again, backup has failed, suppose i’ll go with the rejoining the domain technique instead
huh, disconnected network cable, reconnected, backup in progress, i think it was that easy, i hope, will update
changed my mind before i do that i am going to disconnect the NAS and reconnect it, if that doesn’t work then i’ll actually put in work…
similar issue, windows 7, using windows backup.
error message reads: Check your backup
the trust relationship between this workstation and the primary domain failed.
i run win 7 pro
we have 2 servers, we log in to windows on one and we log into our autodesk vault on the other. they are both running windows server. the windows login is server 2008 std and the vault is running 2003 standard. (dont think the vault server even matters)
i also have a Netgear Ready NAS 4 bay, i have 4 workstations that backup to the NAS routinely, two have no problems, 2 do. i dont know why.
i have tried a manual backup and an automatic backup, neither work.
first,i am going to remove myself from the domain and rejoin, i expect that to work, by the way i have had this problem for years too and usually the fix is rejoining the domain, however sometimes i changed out the mobo and it fixed the problem, wierd i know.
02/02/2011 and Microsoft STILL has not fixed this issue!!!
Running Windows 7 Ultimate with all the latest & so-called greatest service packs etc, Windows Server 2008R2 current patch level as of yesterday and low and behold for no damm reason, I get the dreaded “trust relationship between this workstation and the primary domain failed.” error and the fix of deleting workstating from AD and re-adding it was what worked, yet have no WHY THE F…. this b.s. continues to happen after two-plus fricking years… OSX and *.NiX is starting to look pretty good with Microsofts Three-Peat of Windows ME, Windows Vista and Windows 7 (all being ULTIMATE CRAP)
I worked at a couple places having this issue. We were able to solve it at both. At one place we had to set the domain suffix in the gpo local.yourdomain.com or whatever yours is.
If that does work I found this other solution that helped.
On your Domain Controller:
A) Start > Run > ADSIEDIT.MSC
B) Go to Domain Partition and find the affected computer
C) Rightclick and Properties.
D) Doubleclick ServicePrincipalName
E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.
Hope that helps.
Now I have cronic problem between 2 domans with the “no logon servers available to handle..bla bla bla”…and the PC’s have SID trust issues now and can’t re-join doman because of the above DC problems. Ran DCDIAG /fix and only system logs bomb tests. Checked DNS up and down and all entries in foward and reverse are correct. Stopped and started Netlogon and even forced dependentcies to WINS and DNS to kill the NETLOGON event errors. Can do trust setup but cant validate between trusts but can map to cross-domain resouces from one side and back except with the Main server to Trusted Domain Sites resources. Everything shows up on Network for all PC’s and Servers in both domains but the NLSATHR problem happens now on both Servers in both domains if I unjoin and PC’s and SID filtering is ON. Would like to know how to get my DC’s to stop acting like they can’t see themselves to let other DOMAIN DC’s see them! H-E-L-P!!!!!!! :o(
If I were you, I would open a ticket with Microsoft. It’s worth the fee. They will stick with you until the issue is resolved. If you have a TechNet membership, two support calls are included.
I’m getting this error on Win7, but also, the admin account is disabled because of it. There is no way to log in. Cached credentials yield same message. This happened after a a restore point execution.
What now? Rebuld image from scratch?
Really? With wired and wireless disconnected, you can’t log in? Wow. How about trying an older Restore Point? If not, I would log in to the local machine and rejoin the domain with the other tip I describe…
I had this message on a W2008 r2 VM. We do create a local account, but the password was different than what we knew. I was able to pull the virtual network from the VM and then remove/re-add the Active Directory membership using my cached AD credentials.
It’s been a long time since I’ve seen this one.
Just had this issue with Win7 64 bit after an AVG antivirus upgrade reboot.
System restore fixed it. Yet to find out if it happens again next time avg upgrades itself.
I had this problem as well… mine appeared after Live Messenger requred me to install “Onecare Safety Scanner” to transfer a zip my coworker was sending me (a perfectly safe file…) and then I locked the computer overnight… when I came in the next morning, the trust relationship had failed.
Also, while fixing the issue, I’ve uninstalled the Safety Scanner, and installed the Hotfix that *might* be related: http://support.microsoft.com/kb/97649
That link should be: http://support.microsoft.com/kb/976494
It’s the same KB article the person above me linked to, which I missed before posting.
i would immediately try System Restore. and remember in a pinch you can get to the desktop on cached credentials by disconnecting from the network.
OK, after trying all the suggestions, I found this which applies to my situation and fixed the problem immediately.
http://support.microsoft.com/?id=976494
I’ve had this problem off and on since I deployed Windows 7 to 600 PCs last August, but now it seems to be happening a good amount to people who had their laptops over the summer, I’m concerned that its going to end up being 100 machines or something. If that happens, I’m using my Technet cases.
Found this link, but haven’t tried it…
http://www.windowsitpro.com/article/john-savills-windows-faqs/q-why-do-i-get-logon-errors-while-i-migrate-windows-vista-sp1-boxes-to-a-new-domain-.aspx
In any case, if you get a solution, please let us know.
Thank you SO much. I’ve experiencing this problem after adding a Windows 7 client to our Domain and it’s been driving me nuts. I’ve tried numerous other “fixes” that I found through Google without success, so it’s a real relief to have stumbled across this site.
Found this link, but haven’t tried it…
http://www.windowsitpro.com/article/john-savills-windows-faqs/q-why-do-i-get-logon-errors-while-i-migrate-windows-vista-sp1-boxes-to-a-new-domain-.aspx
Found this link, but haven’t tried it…
http://www.windowsitpro.com/article/john-savills-windows-faqs/q-why-do-i-get-logon-errors-while-i-migrate-windows-vista-sp1-boxes-to-a-new-domain-.aspx
Thanks for the info. We have two DC’s and have just starting using Win7.
Joining a workgroup (while renaming) and rejoining the domain worked.
I’ve run into the exact same problem and thank god i’ve bumped into this site cause I thought at first there was an issue on my server setup side or something real strange, I did keep in mind that I was dealing with Microsoft Desktop clients and anything was possible. With XP it happens ALOT less, Vista and Windows 7 are becoming a pain, I have about 4200 desktops and I get maybe 2 a week with this issue but the end user insists its a server issue.
I also thought it was a duplicate hostname issue which would cause this issue, however hostname’s are unique in most instances, something in the OS must be changing the SID but the mystery question is what could be causing it!? Well I bet Microsoft haven’t replied to many of you guys because they don’t know either.
The Workstation –> Server “trust” issue has me bummed. I’ve been hacking on trying to get two brand new Win7 PCs to join our domain (on SBS2003) for three days. I put two identical PCs on two weeks ago without a hitch. I’ve done hundreds of “joins” in my career. If we could determine the cause, we could devise a cure.
I’ve tried most of the “fixes” I’ve seen posted, but none seem to work for me. It is SO frustrating because these two have never yet been a member of our domain, so it is not like a simple “rename” issue or something.
make sure you have a unique hostname and time and time zone match the server. let me know how you make out. thanks
I am also running into the trust relationship issue with the two Windows 7 Pro workstations on my network. The issue ONLY comes up when you lock the Windows 7 workstation. It will happen pretty much every time.
The strange part is that if you logout/power down, the issue does not happen.
It has something to do with locking the workstaiton…
The network here has a single Windows 2000 PDC (Soon to be updated to 2008 R2).
Thanks for the input. Its always useful info if you know how to repeat it.
Bad news = I got the broken trust in my home test network between my Win7 Ultimate PC by my left foot and my 2008 SBS server (the only DC in my network) beside my right foot. Both are connected to a single network switch. Both are all updated. The Win7 PC is joined to the SBS domain and has been running OK for months.
I had Firefox open on my Win7 PC watching the Pocono race on Nascar.com. The PC went into screen saver mode and locked. When I tried to unlock it, I got the ‘trust relationship broken’ message. I found this thread, restarted the server but that didn’t help, restarted the PC but that didn’t help, deleted the PC in ADUC, logged into the PC as Admin and changed it to a workgroup PC, restarted it, then joined it to the domain again. After restarting the PC again, all was good.
thanks for the contribution. is the client checking with the DC for time? do the time, date and time zones match on the client and server?
I have not done anything to set up or modify time synchronizing. Both systems are in the Pacific Time Zone, and the times are identical.
For what it is worth, I had a vista business machine w/ the “trust” error and placing it on a work group, then renaming the machine and re-joining the domain did the trick! Thanks.
Hello,
I came accross this post as I have been dealing with this “mysterious” issue for over a year. The issue on our site is with XP Pro, Vista and WIN7 clients. The WIN7 clients are new additions to our infrastructure, so originally this was with XP Pro and Vista clients. I quickly discovered the temporary solution is to just re-join the clients to our DOMAIN as an easy fix, though when dealing with our remote users that VPN into the network it is not as easy. Oftentimes it isn’t even necessary to remove the hostname from AD-just join it back as if it was a new machine. After a year of this and using up hours with Microsoft (who no NOTHING about their own products except hey install procmon and send me the logs) and the headache of dealing with the remote users experiencing the client and upgrading to Server 2008 R2 from 2003, I have to wonder if it is just the Windows family of OSs. They were alright in the early 90’s but have they been much good past Win98?
I like the idea of going to a UNIX based MAC and Linux environment. Has anyone put that into production?
Has anyone found a reason WHY this happens?
Thank you. No experience with UNIX. Look through these posts. Someone said something about UNIX… Seems to me, I had to remove the Computer from AD. But heck, anthing to simplify… Next time this happens to me, I WAS going to look at DC replication… But not now. I had someone have it appear with only one DC on their network. I think I would explore the time sync issue, now… Thanks again.
Active Directory has some issues and the complexity of connectivity workstation to server have left me gasping for more hours in every day.
I first noticed this issue in a wide scale. We thought we’d be smart and cover a server drive failure with a twice yearly ghost image to a spare drive. On the day of the server crash we smuggly told the client we would be back up in a couple of hours. We installed the drive and in minutes the server was up. All the software license numbers and registry changes were on and its was all go. The backup restored the data from tape and all looked good.
Except not one worsktation logged in. We had to rejoin the domain on eachworkstation and reconnect the client profile etc, so everything would work. Each machine took about 30 minutes, 50 workstations later, well! To rejoin the domain we in logged in locally to the workstation as adminsitrator connected to the domain using the domain.local instead of domain or vice-a-versa, this saved time. Then apply full access rigths to the target user profile for the current user. Then we login as the user, loggoff and on as administrator, regedit and Winnt\profiles change the name on the profile to the current user.
Reboot and its on. We now using imaging software to backup an image daily, a tool that wasnt available years ago.
I have tried all the solutions above and other work arounds too but the problem does not go away. When my Windows 7 users go for lunch or even just a 15 minute break or a meeting, they have to lock their computer and when they log back in, this trust relationship issue kicks in. I have 18 WIndows 7 W/S in my network and there are 2 desktops that are having this issue. Also, hibernation is off. I tried to compare config between those that do not have the issue and those that are experiencing this noisance and I can not find any difference in the setup/config. These computers are also of the same brand and specs. The fastest solution is the last one above – take the network cable out login to the computer then plug the cable back in.
You’ve got a good scenario to open a ticket with Microsoft. I never had a repeatable situation or I would have done it myself. If you are a TechNet member, you’ve got a couple support calls included. If not, its still worth the fee to get it licked. We would all like to hear the solution. PUT A STAKE THROUGH THIS ONE! Please remark when you get it. 1-800-MICROSOFT
Curious… Compare the Time, Date, Time Zone and DST setting between the troublesome Workstations and authenticating server. In a domain, they should be syncing with the server…
I’m not alone – that’s good. Bad news is that this has happened in just about the simplest network environment possible.
I have a client who has 2 Windows 7 laptops, and only a single Windows 2008 server acting as DC/File server and so on. 1 domain. The client machine was off the domain for a couple of weeks, and on logging on this morning, needed to change their password. They did this, then got the trust relationship message. My thoughts were to take off domain and rejoin; my only nervousness (haven’t done this yet) is that I’ve seen duplicate network accounts created in XP when this happens (eg Firstname.Lastname in Documents and Settings and then Firstname.Lastname.Domain when reconnected). Not normally a problem, but in this case, the user has encrypted their offline files, done a tonne of work whilst away which is not locked out. I’m worried I’m about to lose this… Will update on outcome and route forwards.
Log into the machine with the ethernet and wifi diconnected from the domain. Make a backup of offline stuff before proceeding. we really have three solutions in this thread. System Restore, Rejoin domain and the one right above this comment sounds cool… Reset the computer account in ADUC.
this is an issue that will happen with NT/2000/XP/VISTA/win7. before users can log on to domains , the computer must log in first. that password is changed every 30 (i think ) days, if the computer was not there when the password expired ( laptop off to florida, computer off ) it will have a short grace period and than that computer account will not be trusted again. you can reset that password by going to the computers section in ADUC, right click the computer object and choose reset. you than need to log on again. for what ever reason( i have yet to find out why) this does not always work. but this is the WHY – its not vista related its that family of OSs.
i sure wish MS would find an easy reset option through the domain
@ boo, this is not the issue here. A common incident that this issue will occur is for example, the user just went out for a smoke or lunch break or even just went to restroom, after the user went back, and tried to unlock the computer, the trust relationship will appear. We are talking about new users not even reaching the 30 days limit. IT will just lose it’s relationship to the domain for no reason.
@ dailytweak, I am administering 3000 workstations on three different sites. Never had an issue like this when I was still with XP. Never tried Vista though, but due to company wide policy, we have to upgrade to Win 7. Since the upgrade (2 months ago), we are experiencing the “trust relationship failed” on a daily basis of at least 10 PCs (roughly). Tried sending a mail to Microsoft but still no response.
I have this happening on one Windows 7 Machine now. In my opinion I think the problem was carried over from Vista to 7, they are quite similar as far as the code goes despite what you want to believe.
This “domain trust” issue is not particular to duplicated machines or sysprepped boxes. I have encountered this issue on a Vista Ultimate laptop that is part of an otherwise happily running Samba-based PDC.
My situation: Wireless laptop; when on the domain, all is well; when taken out of campus, a login attempt following a reboot gives the evil “trust relationship lost” message. When this last occurred, I was able to fix it WITHOUT removing and rejoining the machine to the domain. As odd as this sounds, I overcame this issue by resyncying the laptop’s local clock to the common time server in our domain once the box was back on campus. Once the clock was resynced, the trust error message did not recur.
When the Vista box realizes there is no domain available, but also realizes there are valid cached credentials available, I don’t understand why Vista even does anything that would try to touch the domain at all….either machine or user authentication….
I have a feeling part of this issue may stem from brining a laptop out of sleep outside the domain, but I haven’t done enough work to explore that theory.
Thank you. I have not had this pop up since moving to Win7 (others have, though). If it does, I WAS going to look at DC replication… But not now. I had someone have it appear with only one DC on there network. I think I would explore the time sync issue, now… Thanks again. I will open a trouble ticket with Microsoft when it does come up.
I just ran across a Windows 7 Professional “trust issue” with one of my PC’s after months of using the pre-release evaluation version and the recent production release.
1). I used the Alt-Ctrl-Del to lock my computer for several hours.
2). When I returned, it would not recognize the user sign-on and indicated that the trust relationship between the computer and the Domain was broken.
3). I performed the following steps to re-establish trust:
a). In AD, Delete the Computer
b). In AD, Add the Computer back
c). In AD, in the Computer properties, click “member of’ tab and add the computer to the Administrator group – click on the Operating System tab, it should not show an OS.
d). On the Computer, click on control panel, system, advanced system settings, computer name, and network name tabs
e). On the Computer, run the Network ID domain wizard and use the Administrator sign on – it will prompt you to use a ‘User’ account after accepting the Administrator sign on.
f). On the Computer, it will ask you to reboot – reboot and let it finish the shut-down / restart cycle
g). Sign on using the ‘User” account.
h). Go back to AD, validate that the Computer name, properties, computer name tab – it should show the correct OS of your machine.
i). All should be good.
This is what worked for me on a Windows 7 Professional PC running in a AD 2003 environment. If someone runs across a similar issue, please confirm this works for you or add to resolution.
Thanks.
Do you have more than one DC?
No – just one. It’s been running flawlessly since 2004.
Thank you. I have not had this pop up since moving to Win7. If it does, I WAS going to look at DC replication… But not now. You only one DC on your network. I think I would explore the time sync issue, now… If you read Whitlney’s post, you will understand. Thanks again. I will open a trouble ticket with Microsoft when it does come up, so check back once in a while.
I have the same issue with Server R2 running a physical DC and a virtual SDC with 2 Windows7 Pro boxes in the network. Day one the first Win7 box has the trust issue at logon but I was able to log on locally and remove and rejion the domain. Day 2 the second Win7 box has the same issue but the local admin account is disabled immediatly. worked around this buy unplugging the network cable and logging to the domain account, this appears to bypass the trust issue and the domain desktop opens and after about 3 minutes with the network cable reconnected all network resources reconnect. Removed the box from the domain and rejioned and the problem appears to be resolved for now. Strange how just unplugging the network cable by passes the domain trust issue and log on the user to his domain account, this situation is repeatable reguardless of logging off, rebooting or completely shutting the box down and restarting it still gets you in.
Thats server 2008 R2
I just saw this today on Windows 7 FYI.
Brett, do you have more than one DC?
Hello,
This article should also work for Windows 7 Professional acceded / logging to a Samba domain (3.4.3) that already has Windows XP / Vista machines logging and running?
I followed step by step and did not work for my case, any other suggestions?
I have no experience with Samba/Unix environment. Short answer… I would try naming (hostname) the client something different then rejoin. If it keeps happening, I would look for Replication issues between DCs. Fingers crossed, I haven’t seen this since moving from Vista to 7.
Ricardo, do you have more than one DC?
The two big causes of this problem are disk imaging software and AD replication problems. Use disk imaging software to clone or build new workstations can cause duplicate SIDs. You must use something like newsid or ghost walker to change them after imaging.
AD replication problems can also cause the computer account credentials to not get synchronized between controllers or sites. Use the AD diag tools to check for this. (The workstations change their credentials every 30 – 90 days depending upon policy settings and OS versions.)
Thanks. Sounds plausible. Not imaging in my case, but will look at replication.
JimL, do you have more than one DC?
You’ll be pleased to know the issue exists in Windows 7. I am the IT Manager in a group of companies that have 6 locations. We have resisted going to Vista because every experience we ever had with it was a nightmare and we could see Microsoft didn’t really have any interest in actually fixing the issues (which would take an entire rebuild and culture change at Microsoft). So, I see Windows 7…. I think… Hey, let’s give em one more chance. Not bad… everything seems cleaner, it runs fast again (like Windows XP Pro) and I can find everything again without 7 clicks to get there. There are still issues, but even though they don’t deserve any understanding after the disaster that was Vista, I’m trying to be patient. Every couple of days my Windows 7 computer looses it’s connection to the domain. It has that famous “The trust relationship between this workstation and the primary domain failed” message. So, it’s still an issue and that’s not okay. Oh… and for those people out there who claim they don’t have problems with Vista… ummm… “problems” is a pretty relative term. Relative to disaster you may have been able to do a bit of work, but relative to an actual working operating system that doesn’t get in the way and basically allows applications to make use of our RAM, CPU and Graphics card rather than the OS hi-jacking all the resources, provides reliable network connectivity and is resistant to the most basic hacks and viruses. Windows is failing us miserably. And guess what? There are other options. I’m converting many of our sales PCs to Macs now. Other computers will be running Ubuntu, and the rest will stay with Windows XP Pro. Windows 7? No way it’s getting in this environment. If they eventually fix their problems, I might get generous and consider them again. But for now… not a chance.
yikes. i was hoping this issue would be isolated to Vista. I now have 3 boxes running 7 and 120 on XP Pro. The Win7 boxes have only really been in production environment for about a month and have not seen the “relationship” issue… yet. If one does, I will open a ticket with Microsoft, myself. This is to cookoo. NO ONE HAS AN ANSWER TO THIS! If it wasn’t for all the hits I get on this issue, i would think I was the only one…
JimmyBaby, do you have more than one DC?
I saw this in XP once. Was a PC that had not been on the network in a long time. Not sure what exactly happened. Now I have an XP laptop that has a virus/trojan/malware that is doing it. I think I cleaned the bad stuff out but now I get trust relationship errors. Something might have been corrupted or maybe there’s a root kit hiding somewhere.
try scanning the pc with malwarebytes (free). had good experince with this product. won’t help with the “relationship”, but great antimalware.
Benson, do you have more than one DC?
Yes. WHY does this happen? And how can I prevent it from happening in the future?
Never saw this in like 10 years of XP. Only in my limited exposure to Vista. Now I have moved Vista machines to 7. Hope I never see it again. So far, 7 is perfect.
I recently had the same issue. Is it possible that another computer joined your network with the same host name? If so that will cause the issue.
The hostname is unique and had been a member for about a year when this came out of the blue. Only thing interesting was that it authenticated with a different DC than ussual (diff office, same domain, site to site vpn). Although it had successfully authenticated a dozen times over a year previous with no incident.
Aaron, do you have more than one DC?
Yes, this does work, I’ve done it numerous times, not from reading this article but just from trial and error in my own enterprise environment. The actual question is, WHY does this happen? nothing changes on the computer, nothing changes in AD, nothing changes in DHCP, nothing changes on my domain controller, i do not change any GPO’s. To cut a long story short, i change NOTHING. yet it still happens. Thousands to millions of people have this exact problem with vista. I have a total of 4 vista machines in my enterprise of around 250, this has happened on all of them in random intervals with no reason. If this happens in Windows 7 i will not be continuing on an IT career path and possibly become some sort of tramp who wonders the street preaching about Apple MACs.
Well put. I am in the same boat. Nothing much changes. 120 clients, only 2 Vista (one desktop and one notebook). Never saw this error until the typically PA notebook flew to our FL office. It made this move a half dozen other times with no event. The offices are on the same Domain connected via Cisco site to site VPN. DCs at each site. Something broke when it tried to authenticate on the FL DC, this particular time. When it came back, it was still broken.
This blog post gets about 10 to 20 unique reads a day. We are not alone.