MrPstv Posted October 11, 2013 Posted October 11, 2013 Afternoon all, Has anyone got a permanent fix for this please: "The trust relationship between this workstation and primary domain failed." I know it's a matter of re-connecting to the domain. This happens on a regular basis with our netbooks and trawling through the tintaweb i came across an article which advises disabling system restore via group policy. Has anyone experienced this same problem and if they did how did you resolve it? Thanks yall
DMcCoy Posted October 11, 2013 Posted October 11, 2013 (edited) bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures from an elevated command prompt. Edit: Stops the startup repair from running on a failed boot Edited October 11, 2013 by DMcCoy 4
FN-GM Posted October 11, 2013 Posted October 11, 2013 bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures from an elevated command prompt. Edit: Stops the startup repair from running on a failed boot @DMcCoy is bang on the money, fixed it for us!
free780 Posted October 11, 2013 Posted October 11, 2013 I thought you just reset the computer password in AD.
plexer Posted October 11, 2013 Posted October 11, 2013 You can use netdom to reset the machine account password rather than disjoin and rejoin but the way to stop it in the first place is to disable the startup repair. Ben
mhundley Posted October 11, 2013 Posted October 11, 2013 I am making an assumption here but I believe you may be deploying using MDT. If you are using MDT 2012 Update 1 it includes a section in the task sequence called Install Windows Recovery mode (WinRE) or words to that effect, this is the bit which installs the startup mode on your clients. We found this hapening in many schools, every time it was on Netbooks or laptops which were not being shut down properly, because Windows is detecting the dirty shutdown it sets the repair mode to be the default which in turn attempts to restore to a recovery point, the machine password stored here is not current, or even the previous one for the machine, either of which will work on a domain. Since removing this entry from our task sequences we have seen a much smaller number of reports of this, presumably it is happening on machines we have not rebuilt with the new task sequence. 1
witch Posted October 11, 2013 Posted October 11, 2013 We dont deploy using MDT and it happens all the time here. It has improved since there are notices everywhere telling the children to shut down properly but we still get a few. I am very interested in the fix and will try it as soon as I can! Thanks 1
TheScarfedOne Posted October 11, 2013 Posted October 11, 2013 We dont deploy using MDT and it happens all the time here. It has improved since there are notices everywhere telling the children to shut down properly but we still get a few. I am very interested in the fix and will try it as soon as I can! Thanks I've got a script which will stop this for you, just be careful you don't use bitlocker as this will cause it to get upset. Will post later when I've remoted in to get it. 1
free780 Posted October 11, 2013 Posted October 11, 2013 I am making an assumption here but I believe you may be deploying using MDT. If you are using MDT 2012 Update 1 it includes a section in the task sequence called Install Windows Recovery mode (WinRE) or words to that effect, this is the bit which installs the startup mode on your clients. We found this hapening in many schools, every time it was on Netbooks or laptops which were not being shut down properly, because Windows is detecting the dirty shutdown it sets the repair mode to be the default which in turn attempts to restore to a recovery point, the machine password stored here is not current, or even the previous one for the machine, either of which will work on a domain. Since removing this entry from our task sequences we have seen a much smaller number of reports of this, presumably it is happening on machines we have not rebuilt with the new task sequence. I thought mdt disabled sr by default in the answer file.
FN-GM Posted October 11, 2013 Posted October 11, 2013 I've got a script which will stop this for you, just be careful you don't use bitlocker as this will cause it to get upset. Will post later when I've remoted in to get it. If you bit locker after running it is all ok?
TheScarfedOne Posted October 11, 2013 Posted October 11, 2013 If you bit locker after running it is all ok? Yes, it's only if you start the bitlocker process first = issues as it's a mod to the bootloader
FN-GM Posted October 12, 2013 Posted October 12, 2013 Yes, it's only if you start the bitlocker process first = issues as it's a mod to the bootloader Thought so, just double checking Thanks
jmak Posted October 13, 2013 Posted October 13, 2013 Our machines are imaged with FOG and I've had this issue quite a number of times - usually I clusters from the same classroom, so I guessed it was something triggered by user behaviour. I have disabled machine password changes on the laptops that have encountered the problem (suggested on another thread on here) and I haven't had any of the "treated" machines back. This sounds like a better solution. If I continue using FOG (MDT is a learning project for me ATM ), will disabling the system recovery using the cmd prompt instructions in dmccoys post on my master machine cure the problem going forwards?
MrPstv Posted October 14, 2013 Author Posted October 14, 2013 bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures from an elevated command prompt. Edit: Stops the startup repair from running on a failed boot How would you guys apply this over 90 netbooks? Group policy? 1
sted Posted October 14, 2013 Posted October 14, 2013 How would you guys apply this over 90 netbooks? Group policy? batch file as a startup (not logn) script if exist c:\suroff.txt goto end bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures copy \\server\share$\suroff.txt c:\suroff.txt :end 4
MrPstv Posted October 14, 2013 Author Posted October 14, 2013 i say that was a speedy reply chap. Thank you
sted Posted October 14, 2013 Posted October 14, 2013 i say that was a speedy reply chap. Thank you im just doing it myself to some netbooks lol
MrPstv Posted October 14, 2013 Author Posted October 14, 2013 Thanks again chap, Off to my other school and roll this puppy out,it has been a complete pain in the donkey.
RichSouth Posted January 21, 2014 Posted January 21, 2014 Thanks for this. It's be plaguing me at a school where we imaged a whole load of laptops, hoping this fixes the issue (usually get 1 or 2 a week minimum) so it will be good to not have to deal with this anymore. I'll give it a go when I'm in on Friday.
Meldrew Posted January 21, 2014 Posted January 21, 2014 Hi, I'd say is be careful with the suggested answer. Windows is doing what its supposed to do - fixing a problem caused by the user forcibly halting the PC. The better answer is to stop them from being abused in the first place. You'll still probably find that the next logon takes absolutely ages as Windows is fixing WMI. Windows XP's used to just bluescreen when forcibly shutdown too many times - maybe 7 will just do this instead as it can't repair itself if you've disabled system restore. I think 7's solution is way better - at least you can RDP into the machine as local admin and re-domain the PC remotely rather than having to rebuild PCs instead. Meldrew
Garacesh Posted January 24, 2014 Posted January 24, 2014 Since this issue is primarily lazy children not wanting to wait 30 seconds for it to shut down, it manifests mostly on laptops (as they can just walk away from a PC no problem, but have to wait with the laptop and put it back into the trolley) Force shutdown is going to damage the disk platters long before it does any irreparable damage to the OS. Another vote for disabling it startup repair (it never actually repairs anything anyway, always says it was unable to), we have the bcdedit script as an application that we tick during deployment (MDT) and it sorts the problem out. You're right @Meldrew, it's certainly a squishy issue rather than a technical issue, but there's no way to stop the kids from doing it, this is the next best option.
gavins38 Posted January 24, 2014 Posted January 24, 2014 Thank you so much for finally ending my misery with trust relationships! This problem has been plaguing me since Windows 7 was released!
JonDaviesBourne Posted January 24, 2014 Posted January 24, 2014 Test-ComputerSecureChannel -Repair in Powershell 2.0 repairs trust failures.
cooka Posted January 26, 2014 Posted January 26, 2014 Although resetting the secure channel can sort some trust issues, I found that it didn't work very often for me. Have just tried that batch on some machines at work. The PCs kept having issues with trust relationships as I believe that people weren't shutting them down properly. Just flicking the power switch. Sounds like this will fix my issue. Thanks.
Ed_Pinkman_13 Posted February 6, 2014 Posted February 6, 2014 (edited) How would you guys apply this over 90 netbooks? Group policy? we have 90 netbooks too! ARGH! Please be a group policy option!!! Edited February 6, 2014 by Ed_Pinkman_13
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now