Jump to content

Recommended Posts

Posted

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

Posted (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 by DMcCoy
  • Thanks 4
Posted
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!

Posted

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

Posted

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.

  • Thanks 1
Posted

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

  • Thanks 1
Posted
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.

  • Thanks 1
Posted
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.

Posted
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?

Posted
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 :)

Posted

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?

Posted
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?

  • Thanks 1
Posted
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

  • Thanks 4
  • 3 months later...
Posted
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.
Posted

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

Posted

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.

Posted

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.

  • 2 weeks later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...