The trust relationship between this workstation and the primary domain failed - Windows 7 Enterprise joining 2008 Domain, Error 5722.
-
Friday, January 20, 2012 3:37 PM
We have been getting sporadic reports from our users of the error, "The trust relationship between this workstation and the primary domain failed." The workaround has been to dejoin and rejoin the domain, but it keeps happening and we need a permanent fix. We are primarily a laptop shop.
It has been suggested we disable the automatic machine accouint password change on our domain members in GPO. While this may be a viable option with relatively low security risks, I'd really like to figure out why it's happening and try to fix it.
The machines can lose the trust relationship at random. It can happen overnight, or after going into hibernation. I've had it happen to me a few times. The DCs (we have 2) both show error 5722, but one is spitting out a specific Kerberos error that the other one is not:
While processing an AS request for target service krbtgt, the account kriegesh did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 2). The requested etypes : 18. The accounts available etypes : 23 -133 -128 3 1. Changing or resetting the password of kriegesh will generate a proper key.My main issue is trying to determine why this continues happening and if we can resolve it without disabling the account password. If that IS our best option, then so be it. Any thoughts are welcome.
Thank you very much in advance! ~Sarah
All Replies
-
Tuesday, January 24, 2012 8:32 AM Log on locally as a local administrator. In the Network tool of Control Panel, select Change and enter a Workgroup name, leaving the domain. Restart the computer and log on locally as a local administrator.
There are two methods to rejoin the domain:- You can join the domain from the client if at the same time you can provide an administrator username and password on the domain.
-or- - You can delete the existing computer account in Server Manager, recreate the computer account, synchronize the domain, and then on the client rejoin the domain.
Regards, Kalyan.- Proposed As Answer by foot doc marc Saturday, May 18, 2013 11:33 AM
- You can join the domain from the client if at the same time you can provide an administrator username and password on the domain.
-
Tuesday, January 24, 2012 3:06 PM
This solves the problem for each individual machine but does not really address the issue requested. GP wants to know why it keeps happening to different machines. The machines were joined successfully. They worked. Then they stopped and gave these errors. They can be "fixed" individually, but unless we know why they broke, they may (and do...) break again.
What causes a broken trust relationship?
-
Tuesday, January 24, 2012 3:14 PM
Exactly. We can fix it for individual machines, but not on a large-scale. It keeps happening at random. There seems to be no solid reason why the machines in question are being affected, i.e. some particular reason they get this trust issue. They can go into hibernation, be locked (not logged off) overnight, or logged off the domain for maybe a week - nowhere near the 30 day expiration MS puts on the system password.
Thanks for the feedback. ~Sarah
-
Tuesday, January 24, 2012 3:24 PM
This article seems to answer your question about how machine account passwords are used and the ramifications of not having them change frequently.
http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
I am having the same problem. I believe that the problem arises from using imaging software (Ghost in our case). Windows relies on the fact that either the current OR the previous password will be right. If an old image has a "wrong" password for a previous password, this might be the problem. In this case, an image older than 30 days could be considered old...
I am currently experimenting with setting the password age to a long duration (365+ days) as we rarely use images older than this.
If anyone can confirm whether this was likely to work, I'd take any information...
-
Wednesday, January 25, 2012 10:06 AM
Hi there we are having the same issue but it isn't only on Windows 7 machines. It happened on my win 7 laptop but also on a win2008 server we have. Also a number of employees with win 7 laptops are reporting this issue too. Again we have done what you suggested dejoin and rejoin and it resolves the issue but really need to find out if it is a different issue that is causing it. The only thing that I can think of that we have done recently is to apply the latest round of MS patches maybe it was one of these that caused it ?? any thoughts would be very helpful ??
regards
Jodie
-
Wednesday, January 25, 2012 5:13 PM
I am also using Ghost. I am using the same password and my image is only a day old. Every time I join a laptop to the domain, it joins fine, restarts, and I go about installed the final software. Then when I need to restart again, the relationship is suddenly broken. I can't figure out why or whats doing it. The only solution is to unjoin the laptop, delete its object in AD, add a new object, and rejoin it. Then all seems fine.
-
Friday, January 27, 2012 1:11 AM
I have the same issue happening on my network. I am also using ghost. It happened to my laptop and now to a workstation that I restored via a ghost image. The laptop however had not been restored from an image. The trust relationship was just broken from one day to the next. It is very annoying and I would like to know what exactly is causing this issue.
-
Thursday, February 16, 2012 3:16 PM
We are seeing this issue randomly as well. Can anyone report the status of IPv6 on both the clients and the domain controllers? We have IPv6 enabled on the clients, but disabled on the DC's, and we're starting to wonder if that is possibly causing issues.
-
Friday, March 16, 2012 6:26 PMwe are getting the same error. We do not use Ghost. The error started appearing after a windows security update which caused problems with RDP connections as well. After we went back to a restore point to fix the RDP issue, the Trust error continues
-
Tuesday, March 20, 2012 6:04 PM
We are running into those issues too.
We are using MS Solutions as WDS, WAIK and then all new computers are Syspreped before being joined to our domain for the first time so I don't think it is related to duplicate SID like we can see more often when using Ghost without Syspreping the machine before joining it to the domain.
I also found this link posted by Mr._Seven above by investigating on my own. It is really interresting so I went through it but that Registry Key they are talking about (ScavengeInterval) does not exist in Windows 7. So I wonder if everything in this article is up to date and can also be applied to W7/W2008.
For us it seems like the computers are more at risk to loose there trust relationship with the domain when they are working remotely by VPN. We noted, by running a tool/powershell that scans all computers machine password age in AD, that some Windows 7 computers (XP computers too for the record) had exceeded our MAX Machine Password Age policy of 60 days (default is 30). They are connecting by VPN every day for more than an hour and their machine password is not renewed. It should based on the article.
Some problematic computers are recent, some have been deployed 1 or 2 months ago but we haven't got any machine loosing their trust relashionship once they succesfuly changed it through the normal process of logging into Windows while on the network after the 60 days password age variable. But this is not a good information since we have started migrating to Windows 7 only 120 days ago so the majority of them have not renewed their machine password more than once. We will see soon if it can happen after the computer has maintained his synch with AD by itself...
We were wondering if the users could do something that would make the computer loose it's trust relationship. Like what will happen if an expired user logged on by VPN then lock his session to go take a coffee and comes back to log in. Then the password is automatically synch with AD and the user gets a "Wrong user name or password" message. If he does not read the message carefully and tries to log in 50 times, will something happens, like will the computer be rejected since too many attempts would have been done from it? We noted that those who got their trust relationship lost have dome more than 20 logon attempts.
I'll try to be careful at the event viewer next time it happens on the client computer to see if i can find more detials.
-
Monday, March 26, 2012 3:21 PM
I have run into this error on a brand new computer that has not been imaged or ghosted. Freash install, added to the domain and as I'm sure most of you have experienced... my priorities changed and I was unable to work on this computer for over a week. I have not installed any of the corp. software, i'm not sure if I did windows update, I might have installed office... this is the first I've seen it...
-
Tuesday, March 27, 2012 12:40 PMSame issue happening on our network (Win 7 Pro, no imaging - OEM installation). Only one system reported so far, I find it quite coincidental that the issue starts getting reported so frequently on numerous networks as it appears in this thread. I've seen this happen in the past, albiet rarely, and local login is the only remedy. U
-
Wednesday, March 28, 2012 2:08 PM
We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along. I will report back on any we try.
1. Some people believe that there is an issue with an imaging process, creating duplicate SIDs. Sysinternals used to have a tool called "NewSID" but it was retired a couple of years ago. Here's a blog post on it:
http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx
2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs.
a. GPEdit.msc
b. Computer Configuration Windows Settings Security Settings Local Policies Security Options
c. "Network Security: Configure encryption types allowed for Kerberos"
d. Check all of the boxes and reboot
Your mileage of course may vary.
3. One possible solution is making sure the "Provider Order" in network settings is set to "Microsoft Networks." Here is a blog post on it:
http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed
4. Some people have been able to successfully re-enable the trust without leaving and rejoining the domain by running the "Join a Domain or Workgroup wizard." I know this won't fix the root cause, but it may keep it from happening again and it is an easier fix than having to rebuild local profiles.
http://windows.microsoft.com/en-IN/windows7/What-happened-to-the-Network-Identification-Wizard
NOTE: You may need to unplug the machines from the network to use the cached credentials first.
5. Symantec and other anti-virus solutions may be the problem, but obviously this creates its own security issues if you have to disable them.
6. You can disable the machine account passwords as instructed per your Microsoft ticket. Most people believe that removing the passwords won't be a huge security risk, but it will however remove one layer of protection from the equation.Please let us all know if you have any luck.
~Sarah
-
Monday, April 23, 2012 12:21 PM
This is happening on well over 140 PCs on one floor in our building. The other floors are fine, however the floor with the problems was recently imaged (using ghost) and all the windows updates were up to date on the image.
Other floors are not affected, yet this trust relationship is coming up randomly on that single floor of 140 pcs.
Its a complete pain manually going to each PC to rejoin the domain, but having kept logs, some of the ones we have fixed are again coming up with the trust relationship error....
Nothing in the pc logs, nothing server side. DHCP is the same for all floors, so not that. The client PCs all have a unique SID which is done as part of the sysprep process, so its not that.
Only thing I can think of is a recent rogue windows update, but i'm getting it in the neck for all these broken PCs.
Any word from the Microsoft people on this issue? I can't even test any theories on this because of the complete randomness of this error occuring....
-
Wednesday, April 25, 2012 1:30 PM
We are experiencing the same thing with sporadic machines losing their trust relationship periodically. Our "solution" is to have the users back up their data, and reimage them. It is absolutely NOT an ideal solution, but it's working for our sporadic problem.
Has anyone found a real solution to this, or a cause??
-
Wednesday, April 25, 2012 2:02 PM
Make sure that you Domain Controller running PDC FSMO role is set to sync the time with reliable time source. Kerbors will always have problem if the computer and DC have time off by more than 5 minutes.
http://support.microsoft.com/kb/816042
http://support.microsoft.com/kb/307897
-
Thursday, April 26, 2012 3:28 AM
I am getting the same issue.
Mainly running Windows 7, original deployments are done using SCCM 2007 R3. So no SID issues to get in the way. I am about to do a full review of the GPOs for the workstations so will have to see what is happening.
Does anyone have some hints where to look to see what is causing the errors?
-
Saturday, May 05, 2012 6:58 PM
Is there anymore info on this?
I have just started to have the exact same issue.
If a Windows Update issue should I be looking on PDC or client?
We havent changed our GPOs for a while so why would one become corrupt all of a sudden?
-
Monday, May 07, 2012 6:36 PM
I am dealing with the same issue as well for the last 5 months. It seems to happen every time a users password expires they get the trust realtionship error, we also get it randomly as well. I have been just taking the computer off of the domain and deleting their computer account and re adding the computer back to the domain, Its really a pain in the butt. This is not a real solution.
You can check out this article to see if this will help
http://portal.sivarajan.com/2010/05/workstation-trust-relationship-issue.html
I just tried it out on a couple of my computers today. I will just have to wait to see if we get the error again.
-
Thursday, May 10, 2012 11:29 AM
We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync.
When the time is out of sync between client and server you then get problems with the password age for machine accounts.
ref:
http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx
Also we now have disabled system restore by policy, but it is not stopping restore by startup repair.
We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449.
This will probably help if you have this issue on wireless clients that rarely connects on LAN.
- Proposed As Answer by Erich Wehrmann Monday, August 06, 2012 4:46 PM
- Unproposed As Answer by Erich Wehrmann Monday, August 06, 2012 4:46 PM
-
Thursday, May 24, 2012 12:48 AM
i have the same issue too but i know what i just did!
active directory users and computers> computers> then right click in my clone7(my computer joined to my domain) then I clicked in reset account.
now when i try to login in that windows 7 pc, it says the same>> the trusts relationship between this workstation and ....
but i use the local adminsitrator in that pc i still can see that compyter joined to the domain... any one knows how can i login in the domain with my other user?...reset the pc, the server, disable and enable that pc in the server, still...
-
Tuesday, May 29, 2012 9:19 AM
hi,
this isn't a lasting solution, but at least you don't have to resoft the computer each time it happens:
undock and/or disconnect the computer from any network connection and then log in. after you have logged in you can reconnect the computer to any network, cable or wireless.
e.g. if you have a laptop, make sure to switch the wireless button off as well as undocking it from any cable.
regards,
untz
-
Thursday, May 31, 2012 2:19 AMWe are having the trust relationship error on our Windows 7 machines only. XP machines don't have the problem. Both XP and Win7 laptops are on the same domain.
-
Monday, June 11, 2012 2:38 PM
hi,
this isn't a lasting solution, but at least you don't have to resoft the computer each time it happens:
undock and/or disconnect the computer from any network connection and then log in. after you have logged in you can reconnect the computer to any network, cable or wireless.
e.g. if you have a laptop, make sure to switch the wireless button off as well as undocking it from any cable.
regards,
untz
Same solution here. Laptops only affected, unplug, logon, plug back in. Win 7 only, XP fine.
-
Wednesday, June 20, 2012 8:55 PM
We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along. I will report back on any we try.
"2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs.
a. GPEdit.msc
b. Computer Configuration Windows Settings Security Settings Local Policies Security Options
c. "Network Security: Configure encryption types allowed for Kerberos"
d. Check all of the boxes and reboot
Your mileage of course may vary. Please let us all know if you have any luck. ~Sarah"Hi Everyone, Same issues here but a hybrid 2k3 and 2k8 R2 environment where Win7 client and several of the 2k3 servers have the above issues! I think the Win7 x64 client is pointing me in the right direction in that it is a Kerberos authentication mismatch that occurs. Win 7 error: "cannot change password, the encryption type specified is not supported on the KDC." above is the info Sarah G. posted on Mar 28, 2012 the key is SPECIFICALLY - 2 c. Not necessarily a corrupt policy, but a new default that turns off DES for authentication on the new 2k8 R2 DC's!
i have found through several tech articles that Win 7 (vista) and 2k8 and up(?) use AES encryption and disable DES encryption by default, but 2k3's use DES and cannot run AES for login/DC access. Sarah's tech may be on track w/ #2c, but may not be the complete solution. Any info anyone can add would be appreciated, not a guru on this subject at all. ~R.Bman *going to try adding DES to 2k8r2's and Win7 to see what happens.
- Edited by R.Bman Wednesday, June 20, 2012 9:46 PM incorrect info
-
Thursday, June 28, 2012 1:06 AM
I manage several networks both 2008 DC and SBS 2008 and mix of windows xp and windows 7.
This is getting out of hand.
Over the last 4 weeks I have had 5 businesses call be up with atleast one machine doing this at each network.
-
Friday, June 29, 2012 6:07 PM
I'm not sure this fix will work for everyone. Still have to do the domain off, domain on to get it to connect. But to get it to stop I un-checked the "allow the computer to turn off this device to save power" on the network adapter. I think this is the default value for Windows 7.
- Proposed As Answer by RoufChicago Saturday, June 30, 2012 7:24 PM
- Unproposed As Answer by RoufChicago Saturday, June 30, 2012 7:24 PM
-
Saturday, June 30, 2012 7:27 PM
Hi, I tried to use the method of unplug the network cable, restart the computer and login with user credentials. It fixed the issue of logging. Rejoin domain after that. But here is the other solution to perform at Win 7 machines. Just go to control panel, then users and click on Manage your credentials. Create/ reset / your user credentials there and you will be able to logon.
Thanks
-
Thursday, July 05, 2012 2:16 PM
I have seen this issue happen with systems which have identical machine names, you may want to check this and see if this is causing your trust relationship failures. I Hope this helps you.
- Proposed As Answer by TheComputerRepairGuy Thursday, July 05, 2012 2:17 PM
- Edited by TheComputerRepairGuy Wednesday, July 18, 2012 4:14 PM grammer
-
Saturday, July 07, 2012 5:59 AM
Check to see that these machines do not share a common computername, this has been known to cause trust issues with the server. Click start, right click computer, click properties, click change settings, and change the computername to something unique, you will still have to exit and rejoin the domain but at least you will stop this from happening in the future. Please let me know if you have success with this. Cheers.
- Proposed As Answer by TheComputerRepairGuy Saturday, July 07, 2012 5:59 AM
- Edited by TheComputerRepairGuy Wednesday, July 18, 2012 4:16 PM pour grammer
-
Sunday, July 22, 2012 5:12 AM
I have posted the solution on my website: you have to log in with a local user, leave the domain, and rejoin it. It's not as hard as it sounds, I assure you. http://nuangel.net/?p=931 - full disclosure: yes, it is my website, but I have gotten very positive feedback that the solution works. You can see it for yourself in the comment, and if it helps you, don't be afraid to let me know!
NuAngel
Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
NuAngel.net- Proposed As Answer by Garrett NuAngel.net Culver Sunday, July 22, 2012 5:12 AM
-
Monday, July 23, 2012 2:35 PM
Hi R.Bman
I also have a hybrid domain enviroment.
I use landesk to copy the netdom files required to reset the machine account password, reboot the machine and the PC can log back in as per normal.
I agree with your thinking regarding the various authentication types, have you found out any more information on this?
Cheers
Chris
-
Tuesday, August 07, 2012 2:49 PM
Garrett,
Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue.
Jeff Speirs
-
Tuesday, August 07, 2012 2:55 PM
So Microsoft . . . any thoughts? Want to admit this might be an error or issue and give us an answer?
Everyone, your ideas are much appreciated, thank you.
-
Wednesday, August 08, 2012 12:27 PM
Garrett,
Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue.
Jeff Speirs
With all due respect, that article is and has been the most popular on my website for months... and I can even see that at least 10-20 people a day tend to click the link to read the steps, to mention the plethora that come from Bing and Google. I wouldn't say that "everyone here knows how." I'm just offering some help to people finding their way in to this thread.
As far as "why" it happens, I've developed a long list of potential reasons since first running in to the issue several years ago, but I do not think there is any sure fire reason. If you have a computer that was recently imaged and keeps losing the trust relationship, sysprep it. If you have a computer that has changed names, delete the old name from the Computers OU in Active Directory. If you've activated a new domain controller, did you properly DCPromo it or demote the other? And other times people have sworn to me that absolutely nothing changed... it's just one of those issues... like why do I have to restart my print spooler from time to time? Haha...
-Garrett
Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
NuAngel.net -
Wednesday, August 08, 2012 12:37 PM
Has anybody tried this?
Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/?id=976494-Garrett
Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
NuAngel.net -
Friday, August 10, 2012 7:39 AM
Hi Sarah
In the middle of a MS support case, with a similar problem (not excatly the same as yours).
I got the important information, that AES is per default enabled on Win 7 Machine Accounts.
This mean that if you have defined allowed kerberos types, and have not enabled AES128 and 256 as trusted types the you are asking for trouble. Authentication rejection wil happen at random.
So... If you have defined allowed kerberos types, and have windows 7 in your domain, then make sure you also allow AES 128 and 256
Regards
Claus
-
Tuesday, August 14, 2012 7:39 AM
Hi Guys,
I think this has already been posted on here but I found if you login to the local machine (not a domain user) > disconnect from the domain > rename the local machine to something unique > restart as required > log back in to the local machine and join the domain > restart > log in as any domain user. This worked for a problematic windows 7 machine as a permanent fix for me.
It seemed like it was because this host name had been used on the domain before as an XP machine and only started to happen after the machine had been wiped with Win7 and then named to what it was previous. I think that there may have been something on the DC side that had been missed out before the wipe like the Host had not been removed from the domain before the wipe and the DC was not allowing it to register because it was using a different SID, but this is only a theory I may be worng.
Thanks
Anthony-b
-
Tuesday, August 21, 2012 7:36 PM
I believe the general consensus is to disjoin and rejoin the PC to the domain to correct the issue, but I think I've found the way to prevent this from happening anymore. You can check out the details here: http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/ but I created a script that does what this article says to do. The only problem is that you need to do this on all systems that have Win7 or 2008 Server on them. Another option would be to add this script to a GPO as a login script (just comment out the msgbox lines and remove the comment character on the "On Error Resume Next" line so the users don't call and ask you about the messages). The code is below, just copy it into notepad and save it as "ProviderOrder.vbs" (with quotes). *NOTE: You must be logged in as an Admin to run it as a standalone, but it should work in a GPO for anyone who authenticates to the domain.
'On Error Resume Nextconst HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")
strKeyPath = "SYSTEM\CurrentControlSet\Control\NetworkProvider\Order"
strValueName = "ProviderOrder"
oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
arrList = Split(strValue, ",")
strSelection = False
If LCase(arrList(0)) <> "lanmanworkstation" Then
For i = 0 to UBound(arrList)
If LCase(arrList(i)) <> "lanmanworkstation" Then
strOther = strOther & "," & arrList(i)
Else
strSelection = True
End If
Next
If strSelection = True Then
strChange = "LanmanWorkstation" & strOther
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strChange
msgbox "Modification Complete!", vbokonly + vbinformation, "Complete"
Else
msgbox Chr(34) & "Microsoft Windows Network" & Chr(34) & " is not available on this system", _
vbokonly + vbcritical, "Invalid"
End If
Else
msgbox "This computer does not need this modification", vbokonly + vbinformation, "Not Needed"
End If- Proposed As Answer by dustnc Tuesday, August 21, 2012 7:38 PM
-
Wednesday, August 29, 2012 8:28 PM
Just a question to pose an observation to this thread group - I am performing an Active Directory migration for a enterprise-class client. This isn't my first migration, and I doubt it will be my last. The client AD is 2003 Forest and Domain Functional Levels comprised of both Windows Server 2003 and Server 2008 R2 DCs globally. Client provides both DNS and WINS name resolution. DNS is AD-Integrated for forward lookup and BIND for Reverse lookup.
Name resolution is always a challange to reach the workstations from our Migration Consoles, but we manage.
Here's the rub - With every AD Migration I've done, I've seen some fallout. When the Computer joins the Target Domain, sometimes it thinks it's there, but it's like Secure Channel gets hosed and we get a machine with trust relationship issues. Like many on here, our remediation has been to remove the host from the Domain and rejoin it manually. Works like a charm. The problem we're seeing with this migration is that the rate of incident for this is abnormally high. We've got Sites in Canada we're migrating from where the rate of incident is Approx 80%.
Clients are primarily Win7 with some XP mixed in.
So, here's what we've observed - If we select the option to "Enable NetBIOS over TCP/IP" the Domain Joins (via Quest RUM Move) are much more reliable. Has anybody else experienced this? (Can I get a witness?)
Realizing that WINS is theoretically a dated technique for Name Resolution, it appears to me that the Join operation are more reliable when NetBIOS is involved. Now, I've done a bit of reading here at the Microsoft Sites. I found a thread or a Technet Article that mentioned NetBIOS over TCP/IP relies on the standard Windows RPC ports (137, 138, and 139) while operations over "pure" TCP/IP use port 445. I've always understood 445 to be used for file transfer operations, but is SMB traffic used for Domain Joins as well? Is it as reliable a mechanism as RPCs? Am I off-base here?
Any takers who can explain to me the Domain Join process from a networking level and what implications are added by enabling or disabling NetBIOS over TCP/IP?
Thanks in advance!
Kind Regards,
- Rick Gregson
-
Thursday, August 30, 2012 8:02 AM
We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync.
When the time is out of sync between client and server you then get problems with the password age for machine accounts.
ref:
http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx
Also we now have disabled system restore by policy, but it is not stopping restore by startup repair.
We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449.
This will probably help if you have this issue on wireless clients that rarely connects on LAN.
We had Microsoft to look into the case and they agreed it was the best solution to avoid the problem.
Ref:
"Hi,
I have gathered more information about startup repair, I have seen cases where it brings the system to an old system state , this happens in the background and it is not noticed by the users.
If repairs are not successful, you'll see a summary of the problem and links to contact information for support. Your computer manufacturer might include additional assistance information. Did you see this when it breaks the secure channel?
I still think that disabling startup repair is the best way to go in this case
Best Regards,
<u5:p> </u5:p>
Microsoft Premier Platform Desktop Engineer "In other words, this is a design failure of win7 because there are no fix to the problem and it's only related to clients in domain.
Therefore we are now depolying a program to disable startup repair on all our 24.000 Win7 clients.
Make a package without source files.
Programs are as follows:
Command line for x86 without Bitlocker:
bcdedit /set {default} bootstatuspolicy ignoreallfailures
x64 without Bitlocker:
%windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures
With Bitlocker x86 run 3 steps:
1. manage-bde -protectors -disable C: (deactivates bitlocker protection)
2. bcdedit /set {default} bootstatuspolicy ignoreallfailures (disable startup rapair) run with dependency to step 1.
3.manage-bde -protectors -enable C: (enables bitlocker protection) run with dependency to step 2.
With Bitlocker x64, 3 steps:
1. %windir%\sysnative\manage-bde -protectors -disable C:
2. %windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures (run with dependency to step 1.)
3. %windir%\sysnative\manage-bde -protectors -enable C: (run with dependency to step 2)
Program settings:
specify plattforms on respective clients
run wheter or not a user is logged on
with admin rights
unc name
Collections:
You need to find and sort all the clients in the above 4 groups
Advertisement settings:
Mandatory, scheduled
When on LAN
Run the program from distribution point
When unreliable
Run the program from distribution point
Allow users to run independently
Allow clients to fall back to unprotected dps when connection is not available
I hope this will finally put rest to your minds (and bosses).
Good luck!
-Fowler
-
Friday, September 14, 2012 3:09 PM
Hey Everyone, I thought I could give a little insight. I ran into this problem recently. However, we can certainly rule out with 100% accuracy any software installs, updates, upgrades etc. The reason I know this is because I have a test server that this just happened to. The good news is that this server is a virtual server, that being said, I just reverted back to a clean server state, with a snapshot after joining the domain.
Hmmm, still getting the error. Although not resolved, I have eliminated all the above. What I believe it is, is another DC on the domain has lost its trust. This has nothing to do with the PC giving the error, but rather the PDC.
Thoughts?
PaulDuramaxster
-
Thursday, September 20, 2012 10:35 AM
Hi,
How can a DC with lost trust communicate at all? Do you perhaps mean that the client has run into a DC that is corrupt? Then you have to look into the clients eventvwr and know exactly when and which DC.
It has to be related to the PC because the error rate has decreased dramatically in our environment. But as I stated earlier, this is an abnormal symptom. You will always get this error if you have duplicate clients etc.
Another proof is that we discovered policies run on our clients, was wiped away after the automatic startup repair had run.
That means that startup repair is wiping and resetting vital elements in order for the client to communicate ok with the DCs.
Rod
-
Tuesday, September 25, 2012 12:41 PMJust a note, if it were useful, some manufactures non Microsoft use 445 port as RPC port. I think that, since W2K, Windows uses port 445 for RPC and SMB also, obvius when NetBIOS is not used.
-
Tuesday, September 25, 2012 12:50 PM
We are running into those issues too. The last two cases: Windows 7, change computername in Active Directory and in client. Everything all right, user is working OK. The client is power down for the ninght. Next day trust relationship with domain is failed: rejoin and OK. In one client the issue run twice.
-
Friday, October 05, 2012 6:44 AM
In my Organization we have insolated and solved the problem: we have a disjoint domain, the problem arises when computer dnshostname is not the same than domain acount dnshostname.
I think it is a problem with Kerberos and Service Principal Name.
- Proposed As Answer by Baterias Friday, October 05, 2012 7:01 AM
-
Tuesday, October 09, 2012 2:30 PM
Reset the machine password...I bet if you look at the machine accounts in LDAP/AD the machine account password has recently been updated.
- Proposed As Answer by Thomas BalkeståhlMVP Wednesday, October 10, 2012 8:36 AM
-
Tuesday, October 09, 2012 9:15 PM
We also tried to reset the machine account without success.
This week we had only 1 case with trust relationship and again, the computer had run startup repair.
We found the minidumpfiles and prooved it again.
-
Wednesday, October 10, 2012 8:40 AM
The Rich Master!
This solved it for me, failed at first, when I ran the command against DC1, failed to logon again, then ran it against DC2, worked! Success!
Regards
Thomas Balkeståhl - Technical Specialist - SharePoint - http://blog.blksthl.com
Download 'The SharePoint Branding Project' here
Download 'The final guide to SharePoint 2010 Site Settings' free whitepaper here
Download 'The final Kerberos guide for SharePoint technicians' free whitepaper here -
Saturday, October 13, 2012 10:06 PM
Rich Meister, thanks. I've used netdom in the past using the /reset switch to reset the secure channel, but that hasn't worked when I've had this problem in recent years. Also, using "Reset Account" in ADUC hasn't worked often and as far as I know, that is the same as using netdom /reset.
The problem is that netdom /resetpwd must be run locally. Because for us this problem almost always happens on regular users' workstations, it means every time this problem occurs, you need to download and install RSAT (or Admimpak). For this reason, I wouldn't call it "easy peasy". In fact, you might as well just remove/rejoin after using "Reset Account" (to keep the SID from changing) because that will probably take less time.
Even though that may still be helpful to know, I am more interested in solving the cause of this issue in the first place. We recently had a very angry director due to about 20 machines in his department having this problem all within a short time.
Baterias, I'm interested in hearing more about the DNS issue. It seems to me that I've noticed over the years that when we have this problem, the workstation's DNS record usually is different than the SAM account name in AD. I need a description of the process and where it is failing, if it's possible to provide that, because our DNS setup is unusual in and how it relates to AD. If I know where in the AD authentication process the failure occurs, I'll be better able to tell if it's due to our DNS setup.
-
Monday, October 15, 2012 11:05 AM
The issue for us was that the internal whole name of computer, for example: mycomputer.microsoft.com, not be the same name than Active directory DNSHostname attribute, for example: mycomputer.london.microsoft.com.
If this names are not identicals then the attribute ServicePrincipalName is wrong also. This atribute is very important for kerberos.
Whe I correct the atributes in AD, then Windows 7 computer be able to logon in domain, without reboot computer.
-
Tuesday, October 16, 2012 2:11 AM
Baterias, thanks for the reply. I think our problem is different
than the problem you describe. I believe the DNSHostname attribute
always matches the SAM account name in our environment because we only
have one domain, and as far as I know, the DNSHostname is simply the SAM
account name with the domain name appended to it.In our domain, we just seem to randomly have workstations lose their trust with the domain.
The workstations themselves have DNS A records on our BIND DNS servers and these records often do
not match the workstations SAM account names. These clients resolve names using BIND DNS and there is a delegation in BIND to our AD integrated DNS servers for AD SRV record queries.I don't see how the incorrect A records in BIND should cause any problems for the workstations that have these incorrect records. Can anyone confirm whether or not I am correct that this should not be the cause of the problem?
Thanks
-
Tuesday, October 16, 2012 8:46 PM
Really struggling with this issue and it's causing a serious impact to my productivity.
First of all, I'm aware of the "fix" that is being recommded. I've contact our CenterBeam tech support center 3 times now over the past 6 months and blown an hour each instance to have someone with network admin rights take me off the domain and rejoin me. But that is only a temporary fix because the problem keeps recurring.
Here's what's triggering the recurrence:
Enterring my domain password incorreclty over a WiFi network. Once I do this, I get the "trust relationship failed" error even when I enter the password correctly on subsequent logins. I've repeated this test multiple times and can state with certainty that this is the trigger.
This error occurs imeddiately after the failed password entry and then every time the computer is locked.
If I go into sleep and unsleep via the power button, I can circumvent the error. But that increases my startup time and is not an ideal solution.
So, any suggestions from Microsoft?
-
Wednesday, October 17, 2012 1:46 AM
I don't see any way mistyping the password for your account can possibly cause the machine's account to lose trust with the domain. I think what you are seeing is that your machine has already lost the trust with the domain and as long as you type your password correctly, you can log on via cached credentials. Once you typo on your password, the machine cannot log you on with cached credentials, it tries to check with AD to see if your password has been changed, and that's when it lets you know that the computer has lost its trust with the domain.
If you want to see when the computer has lost its trust, just check the System Event log for NetLogon errors. If you read those (and they will always be there after a reboot), you'll see that the trust is broken. In fact, look backwards in the System Event Log over time and you may be able to tell how long it took for the errors to begin again after the domain rejoin.
The goal, which seems to be difficult to achieve, is to find out why this happens in the first place even in a healthy AD domain. This does kill productivity, as you have seen, but you need to be careful about making assumptions about what the cause is.
-
Wednesday, October 17, 2012 12:52 PM
We ran into a similar issue, with a couple of machines recently. We simply unplugged them (physically) from the network, had the user login and then plugged them back in.
The user was able to login fine after that.
-
Friday, October 19, 2012 5:56 PM
we had to do the same thing and the user had no issues after eitherWe ran into a similar issue, with a couple of machines recently. We simply unplugged them (physically) from the network, had the user login and then plugged them back in.
The user was able to login fine after that.
-
Tuesday, October 23, 2012 12:54 PM
This pops up for us from time to time, it seems when an end user gets a new computer and we wish to reuse the old name. I have made sure that the old PC's name is out of the way (change it, or leave the domain) then go into AD and make sure it is nowhere to be found, then join the new PC with the recycled name.
This morning I had it happen again. Everything was fine on Friday but the user reported today that they got the "trust" error msg. I looked in AD and the name was gone, but I'm 100% positive that I'd seen it Friday and put it in the right container.
I don't know what's going on. Just did the leave/rejoin domain thing and all is well now. Thankfully here it has been an uncommon issue, maybe 5-6 in a year.
-
Wednesday, October 24, 2012 1:05 AM
The case you describe is a little different. You said that the computer object was gone. (I assume you meant gone from the domain, not just moved to a different container.) If the computer object is actually gone, then someone or something had to have deleted it. In that case, it's very much expected that the trust would be lost. Most of the posts above describe where the computer object still exists in AD, but for some reason the trust is still lost.
Cheers
-
Wednesday, October 24, 2012 9:56 PM
A computer object can just "disappear" when a new computer is deployed into the domain with the same SID e.g. when an un-syspreped image is deployed.
-
Thursday, October 25, 2012 3:28 AM
Yes, multiple computers having the same SID is a real problem. But are
you saying that if computer1 is a domain member and computer2, which is a
clone of computer1 is joined to the domain later, that the computer
object named computer1 will be renamed to computer2? We are so careful
to use Sysprep, I don't think I've ever actually seen what happens when
you don't use it in an AD scenario. -
Tuesday, November 13, 2012 12:22 PM
This doesnt work when you've got a domain which holds up to 10,000 workstations and 10+ PC's show these trust issues every day..
Please do not propose as answer, because its not.
-
Tuesday, November 13, 2012 11:53 PM
We have about 30 machines, laptops and desktops, connected to AD. We have only recently implemented AD....had it for a couple months....and I'm now seeing this error manifest on one workstation. The user in question switched from a laptop, to a temporary desktop, and then to a new replacement laptop. The user name in AD didn't change. Her password has changed multiple times in the span of a couple weeks due to all the computer switching, temp logins, etc. It seems that this is clearly part of the problem. She can rejoin the domain by unplugging, logging in, and plugging back in. Obviously, this is less than ideal.
Any new insights on this??
-
Friday, November 16, 2012 2:14 PM
Sarah- Thank you for this information. We are a mixed 2003 and 2008 AD schema and this issue has happened only on our W7's and 2008 server installs.
We have GFI MailArchive installed on one of our 2008 boxes and this issue was really causing a problem with LDAP auth to our DC's.
I followed option #2 above and as of now have not had the issue reoccur.
Thank you again.
-Derrick
-
Sunday, November 18, 2012 10:18 PM
Hello,
"we disable the automatic machine accouint password change" Alone with a different password than the first time, you can come back from the backup. What you should do:Problemin temel kaynağı olan (computer account password) makine hesabı şifresi ile problemli makinede kayıtlı şifrenin eşleşmemesidir.
Aktif dizin’de makine hesabı (computer account) şifresi varsayılan olarak 30 günde bir değiştirilir. Aynı kullanıcı hesaplarında olduğu logon esnasında hesabın bu 30 gün süreyi doldurup doldurmadığı kontrol edilir. Kullanıcılar için şifre değiştirme ekranı gelirken makine hesapları şifresi netlogon servisi tarafından otomatik olarak güncellenir. 30 gün süresi dolan ve aktif olamayan hesaplar, aktif olduğunda güncellenir.
Problemin temek kaynakları için birkaç örnek:
1.Durum: Birden fazla DC'niz var ise ve bunlar arasında replikasyon sorunları var ise olabilir.
2.Durum: Etki alanı (active directory) ‘de yaşanan bir problem sebebiyle yedekten dönme işlemi yapılmış olabilir.
3.Durum: Makinenizde yaşanan bir problem sebebiyle yedekten dönme işlemi yapılmış olabilir.
Her iki durumda da yedekten dönme zamanı, şifre değişim zamanına denk gelmiş olanlar makineler problemden etkilenecektir.
4.Durum: DC üzeriden veya RSAT üzerinden makine hesabı resetlenmiş olabilir.
Sorunu asagidaki komut ile giderebilirsiniz. Yalniz "netdom.exe" 'yi bilgisayarına ya RSAT kurarak yada asagidaki linkten download edebilirsin. Netdom.exe sadece windows'un sunucu versiyonlarında yüklü olarak bulunur.
netdom.exe resetpwd /s:[server] /ud:[user] /pd:[password]
[etkialan] = Etki alanı (active directory) adınız veya IP adresi Ör: “Test.com” veya “192.168.100.1″
[user] = Etki alanı (active directory) yetkili bir kullanıcı. Ör: “sisyon” veya “Administrator”
[password] = Kullanıcıya ait şifre. Ör: “Aa12345″ veya “*”
Download netdom.exe and script: http://siberblog.org/wp-content/uploads/2012/10/netdom_trust_script.rar
Ayrıntılı olarak incelemek istersen: http://siberblog.org/index.php/the-trust-relationship-between-this-domain-and-the-primary-domain-failed/
Daha da ayrıntılı analiz etmek ve tüm dc üzerinde sorunlu makineleri tespit etmek istersen:
http://siberblog.org/index.php/active-directory-analysis-the-trust-relationship-between-this-domain-and-the-primary-domain-failed/
- Edited by Bekir Yalçın Monday, November 19, 2012 5:45 PM
-
Friday, November 30, 2012 1:47 PMMy department is dealing with a very similar incarnation of this issue. We manage hundreds of Dell Latitude laptops that are doing this same thing. The problem machines are E5410s, E5420s and E5430s running Windows 7 Enterprise 32-bit connecting to a 2008 domain. We are coming across machines regularly that are giving the "The trust relationship between this workstation and the primary domain failed".
I've been keeping a list of the machines that do it and so far there have been no repeat offenders. In keeping with what others have said, unjoining and rejoining to the domain clears up the issue.
One thing we've also been doing is checking the registry key HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC\OupdTime
This gives the time the machine thinks it last set it's AD password. I just got done checking one that was imaged on 9/27/12 and shows the password set on the same date, which is to be expected. AD, however, shows the password was changed on 10/30/12. Despite this discrepancy, the machine was logged into regularly up until 11/14/12. I didn't get the call to come check the machine until 11/29/12. So 30 days after it was imaged, it tried to reset it's password. AD shows that the change completed successfully, yet the machine shows a password set date from when it was imaged. I don't know where machine AD passwords are stored locally, but I suspect something is making the machine restore a backup copy of the registry or go back to a restore point or something. Just a hunch, not sure how I can reproduce it...
This is where we are with trying to figure this problem out. Just thought I'd contribute. -
Wednesday, December 12, 2012 1:15 PM
Hi
Re startup repair
"I have seen cases where it brings the system to an old system state , this happens in the background and it is not noticed by the users"
Are you saying startup repair can run while the system is in use and without user knowing? I though it only run at boot time.
-
Tuesday, December 18, 2012 5:30 PM
Try this GPO.. It resolved my issues.. There seems to be an issue with DeepFreeze too. But this GPO should take care of it.
Computer Config | Windows Settings | Security Settings | Local Policies | Security Options | Domain member: Disable machine account password changes - Enable this policy.
This will not resolve the issues for machine already having trust issues but will prevent future one.
Thanks : \ Shah
-
Tuesday, December 18, 2012 6:00 PM
That certainly should solve the problem going forward, but what about the security risk of having member computers that never change their passwords?
-
Tuesday, December 18, 2012 10:47 PM
Indeed. But it all depends on the environment and its requirements. This technet article talks about the security risk you broughtup and also talks about when you might consider this "solution'.
Thanks: \ Shah
-
Tuesday, January 22, 2013 5:10 PM
There may be numerous reasons why this error occurs but I believe one of them is a timing issue, which has been mentioned that wireless devices seem to be more susceptible and this could be during a reset of the computer account password. I just had a customer call with this issue, although she had two issues, the primary being her display was only showing a black background and her white mouse pointer.
Display issue resolved, she could not login to the domain because of a lost trust relationship. As has been suggested, we turned off the wireless switch, logged in, turned it back on and everything was fine.
I have done what others have done in the past, removed the workstation from the domain and added it back and of course, you then deal with profile issues. However a trick has been used to rejoin using the NetBIOS domain name instead of the DNS domain name.
Ex. domain and domain.local
Whichever was set previously, use the other one and you would be reconnected and not have to deal with profiles.
I'm wondering if the issue is the password being changed on the DC and then trying to re-establish from the workstation with the new password and because of a timing/communication issue, not able to connect and thus the infamous error message. It appears once this happens, it appears to cache it so you cannot recover and by disconnecting from the network so the DC cannot respond, the workstation is forced to use the cached account.
Maybe someone at Microsoft could confirm the new password is not permanent or will rollback once the user has authenticated with the cached account and perhaps the computer account password is then retried or ignored until the next time it attempts it again.
It could even be simpler, timing is off and you get the error because it cannot communicate properly with the DC. Once authenticated via cached account, it gets what it needs to connect and sync with the domain. I'm throwing out possibilities but if logging into the cached account re-establishes the connection, there doesn't appear to be a permanent fix, without compromising security.
-
Tuesday, January 22, 2013 9:33 PM
At this point I am throwing in my lot with the idea put forth by Fowler. I don't know if it has to do with the fact that Startup Repair recovers some backup of the registry and that throws it out of whack, but this only happens with Windows 7 and it seems to happen on machines that have gone through Startup Repair.
-
Wednesday, January 23, 2013 4:32 PM
I would love to hear any further news on this thread as we are having the same issue with Windows 7 machines imaged via SCCM 2007r3 (so no sysprep problems)
And it seems random - machines working fine one day and not the next. I'd like to think MS would have picked up on this thread now as it's still current.
Chris Bilsborough UK NHS Support Technician
-
Wednesday, March 06, 2013 7:43 AM
We've been seeing this issue sporadically too with our Windows 7 machines (machines "imaged" using OSD in SCCM 2007 R3). The event log typically shows that after a startup repair has been initiated, the machine then loses the trust relationship. I've also not been able to logon to the machine using the user's UPN (user@domain) as I've read on a few online articles.
The Help Desk team used to do the re-join domain trick and then having to fix up the profiles afterwards, but it would also screw up the SCCM client as they were not getting any apps being deployed (that's how the issue got my attention) and they would eventually swap out or rebuild the machine.
I've only just started investigating this and have used the netdom.exe resetpwd solution and that has worked. I've not yet tried the unplug network cable trick to confirm that it has worked in our environment (I will try that with the next one I get). I will also be trying the bcdedit /set {default} bootstatuspolicy ignoreallfailures command too, and will report the findings in a week or so.
-
Monday, March 18, 2013 3:05 PM
Just to throw in another fix I've used successfully with this annoying issue. Unfortunately you need to log in as local admin and have a Domain Admin account ready.
1. Control Panel - System
2. 'Change Settings' under Computer Name, domain, and workgroup settings
3. In System Properties, click 'Network ID...'
4. 'This computer is part of a business network...'. Next
5. 'My company uses a network with a domain'. Next. Next
6. Type in Domain Admin credentials
6a. You should see a dialog that the computer account has been found in domain...'would you like to use this'? Yes.
7. Do not add any accounts
8. Finish and restartThis just indicates the lost connection between machine and AD object. Hope it helps in future troubleshooting.
I check one of the problematic machines with ADSIEdit and found that badPasswordTime was set to 50 minutes after lastLogonTimestamp and badPwdCount was at 20.
Windows 7 x64, Forest/Domain 2003, mix 2k3, 2k8 DCs, imaged with SCCM2007- Edited by DanArseneau Monday, March 18, 2013 5:54 PM Forgotten details
-
Saturday, March 30, 2013 3:09 PM
Dear All,
I have faced this issue and came to know that this is happening due to Bios conflicts of pc's within the same network. if the Host name names are matching within the same network then the conflict will raise and it will temporarily resolve when we dis join and rejoin to domain but the permanent solution is to change the host name and make sure that the new name is not matching with any other pc's. hope this will be helpful for you all.
Thanks & Regards,
Roopesh
-
Monday, April 01, 2013 12:38 PM
When you say "BIOS conflicts", what exactly do you mean? I think you are referring to a similar practice in the organization I work at. Our machines pick up their computer names for the domain from the Dell Service Tag in the BIOS. We came across two laptops that were exhibiting symptoms of this trust relationship problem that happened to have duplicate names. However, this has not turned out to be a prevalent cause of the issue in our case. It could be that it was in that case, but we have lots of machines that do this without any relation to duplicate machine names.Dear All,
I have faced this issue and came to know that this is happening due to Bios conflicts of pc's within the same network. if the Host name names are matching within the same network then the conflict will raise and it will temporarily resolve when we dis join and rejoin to domain but the permanent solution is to change the host name and make sure that the new name is not matching with any other pc's. hope this will be helpful for you all.
Thanks & Regards,
Roopesh
-
Thursday, April 18, 2013 2:13 AM
Went through prolonged troubleshooting porcess and ended up running bcdedit /set {default} bootstatuspolicy ignoreallfailures against all Win7 PCs.
The issue has not happened since then.
Troubleshooting steps
For each PC that had this symptom, logged on as local admin and checked hklm\security\policy\secrets\$machine.acc\OupdTime and CupdTime.
N.B. where value is converted using nltest.exe e.g. OupdTime = 57 ca e6 71 60 39 ce 01 convert with nltest /time:71e6ca57 01ce3960
Checked the values against PwdLastSet on AD object (use adsiedit to view).
In all cases OupdTime\Cupdtime was about 30 days behind PwdLastSet
Next checked $windir\system32\LogFiles\Srt on problem PC and saw that in most cases there was SRT activity around the time the trust relationship issue started.
By chance I was told about another problem of Win7 machines spontaneously reverting to their SCCM deployment names(minint-xxxxxxx) shortly after they were renamed to "corporate names" - names for corresponding AD objects reverted too.
Found SRT activity at time machine names rolled back but all affected machines had been deployed within 30 days of problem. All such incidents stopped after deploying bcdedit /set {default} bootstatuspolicy ignoreallfailures
My take on all this is that SRT ran for some reason and reverted to previous system backup. Where the local machine password did not match machine password in AD, the "...trust relationship between this workstation..." issue occurred.
Where the local machine password still matched machine password in AD, the machines were effectively renamed to the original machine name at the time the system backup was taken.
Where the local machine password still matched machine password in AD, and a system backup was taken after the machine acquired its "corporate name", no one even noticed that anything unusual had happened.
-
Thursday, April 18, 2013 5:00 AM
We are using a vb script to set the bootstatuspolicy and recoveryenabled settings:
On Error Resume Next Set WshShell = WScript.CreateObject("WScript.Shell") intReturn = WshShell.Run("bcdedit /set {default} bootstatuspolicy IgnoreAllFailures", 0, True) intReturn = WshShell.Run("bcdedit /set {default} recoveryenabled No", 0, True)We realised that this issue mainly occured when a users laptop had ran out of battery and just shut down (not a clean shutdown). On next boot up, it would detect that the previous shutdown was not successful, it would then boot into Windows Recovery Environment. Users would generally call the Help Desk and at the time, the Desk would run through the recovery which would roll back the system to it's last restore point. In our environment, we disable restore points by GPO, so it's last restore point would have been made when software updates was last run while GPO was not applied, which for us is during SCCM OSD. This causes the mismatch in machine password and thus trust relationship issue would appear. -
Monday, April 22, 2013 5:36 PMDoesn't work with win7 virtual machines. I can't even log on with the local admin you just get the same message.
-
Monday, April 22, 2013 7:09 PM
Bit hard to do with a virtual machine. Starting and stopping through the Hyper V console doesn't have the same 'reset' ability as with real machines.
I've been bashing my head off this most of this afternoon and I think it has something to do with 'identity'. I've just built a nest of 10 VMs, then they were lost before I could back up [don't ask] so I'm thinking ok at least I know now how to do it and have learned lots so I'll be back up in no time. I don't use sysprep. I use the hyper v to create a new image from a fresh install then just copy and re-do that. It worked fine before I just took the new machine off the domain then renamed it and added it back. No problems and no error messages until today and this afternoon. I'd built up to number 6 yesterday and today I was going to get through to 10. So I copied [as usual the vhdx file from VM6 into a folder called [imaginatively] VM7 and then pointed the wizard at it when creating a new VM. All fine. I do all the twiddly bits and check various things [nothing major] and then I have cause to go back to VM6 to check something. That's when the trouble started. Try to connect to it and bang the error message.
Ultimately I'm going to have to use a much earlier image to create the next few which means that maybe something in the things that have slowly changed over the last couple of days have caused this. Maybe the last updates to the MS security essentials? Maybe the the last windows updates [8 as I recall], but it wasn't to do with the method or the image per se. Somehow when renaming the machine it hasn't forgotten its previous identity is my guess [yes I know it is a non technical guess but really I haven't the time for in depth 12 month research, I need to know NOW how to get further along].
I will report back tomorrow when I've tried an earlier image, now I'm going to soak my head in a barrel of cider.
- Edited by jake6257 Monday, April 22, 2013 7:11 PM typo
-
Tuesday, April 23, 2013 9:20 PMI am having the same problem but this happened after I had run system recovery when a user downloaded multiple viruses. I had a recovery point from 2 days ago so password is still good but now I am unable to login with user nor admin. Have tried to rejoin domain from but also unsuccessful. Any ideas?
-
Tuesday, April 23, 2013 10:39 PM
Is it a VM Cindy? If so I just detached the virtual hard drive, deleted it and used an earlier version. It was a pain to do the updates etc but better than starting from scratch.
If it is a real machine I can only suggest you power down and unplug the the network cable, then boot back up to force it to use the cached passwords.
I meant to comment today on how I did fighting the dreaded 'untrustworthy domain monster'. I managed to get all my VMs back but as I said just using an earlier image. I'm sure if I had the time, budget and resources [like microsoft] I could be definitive but I haven't. What I am pretty damn sure of is that it is either the SSID or some other identity criteria that doesn't get forgotten/deleted. I'm near certain it is duplicate identity of some kind.
This may be significant [if using VMs] but I'm also getting the 14050 error VMMS admin now, this too dates back to when I first started with the domain error.
Pretty certain that if I had a brain I'd be able to work it out but we can't have everything we want can we?
-
Wednesday, April 24, 2013 2:55 PM
It isn't a VM and I tried unplugging the network cable and rebooting - no go. It is a laptop for one of our employees who is having some medical issues so it contects to the network using Remote Access most of the time. My system recovery point was right after the Microsoft update that ran 4/16 so I am a little suspicious that something in that update may be contributing to the problems but this machine was pretty bad when I got ahold of it (24 suspect programs downloaded in a 2 day period). I will probably have to wipe it clean and rebuild the dumb thing - don't like the fact that the admin account was also disabled. Users - can't live with them, don't have a job without them.
-
Wednesday, April 24, 2013 4:18 PM
Well good luck Cindy.
I have come across some clever viruses and trojans recently. They close down your anti-virus, switch off the firewall then won't allow you to switch them back on or update. a lot come in the sneaky toolbars that every site wants people to download and if you aren't careful and tick some obscure box you get the toolbar and then a load of trash with it. I did come across one that disabled the admin account too but that was some time ago. I seem to remember we got around that by having another admin account but named rescue or something. It didn't shut that down.
-
Friday, April 26, 2013 8:56 AM
Ok guys hopefully the end to you misery, I support over 30 different domains on a weekly basis and this problem has occurred in a few of them. The problem is caused by dns records not updating them selves properly let me explain. A computer account needs to update it's self with the domain at a certain number of days. The password for the computer account is changed and the domain controller needs to pass this information back to the work station. This is where it fails as the DC will talk to the wrong workstation. Log on to your machine locally and take a look at the IP address, then log on to a dns server in your domain and you will see that more than likely the dns A record is different from what you are showing. To stop it happening again you will need to look at the dns server and set scavaging and make sure DHCP is automatically updating DNS dynamically. If you want to prove it delete all the A for workstation records from the server once every 25 days and the problem will go away. Then you can take a look at what is causing the problem.
Once the pc has lost its trust it will need adding manually.
- Proposed As Answer by mick-uk Friday, April 26, 2013 8:56 AM
-
Friday, April 26, 2013 9:35 AMIt's weird but I went to the DNS server for something else yesterday and thought I'd clear a few of the old A entries off that were no longer used. I also wondered breifly what would happen if I deleted them all. I didn't have time to experiment then but I can see that from what you've said they are all going to be re-created when the workstation logs on again. Correct?
-
Saturday, April 27, 2013 4:25 AM
We have a convoluted method of dynamic DNS on our network and I have told people that this does seem more likely to happen when the DNS name doesn't match the NetBIOS/SAM account name on our workstations, and what you're saying seems consistent with that. However, this is the first time I have heard that a DC needs to initiate a connection to a client. Are you certain that this happens? Are there any MS articles that describe this? I have never heard that DNS records are a requirement for AD clients, but they would be necessary in this scenario. If you or someone from MS can confirm this, it would be great.
Thanks.
-
Saturday, April 27, 2013 5:31 AM
Machine account password process:
http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
-
Tuesday, May 21, 2013 1:07 AMThanks for the link. There is nothing in the article that says the DC needs to initiate a connection to the client in the password change process.
.png)
