Windows 7 Trust relationship

[Sunderwood]

Hi,

 

Not sure if anyone has seen this issue before?

 

We run a windows 7 domain here with everyone having a laptop device.. We do have a few desktops on windows 7 but not many. So all students have a laptop and now and again some students come to us and sometimes its the same ones complaining their laptop won't let them logon and its says "The Trust relationship between the primary domain failed"

 

I've searched the internet and found a couple of posts saying that remove the PC from the domain and rejoin it. This i admit works but i don't feel it is a log term fix. The PC's in question have all updates installed.

 

Anyone seen this before and have a fix?

[FN-GM]

I have noticed this happens with Windows 7. I left before i got around to fixing the issue.

[januttall]

in AD on right clicking the machines theres an option to reset the computer account does this help or not. and is it repetadly doing this or is it sorted once its rejoined ? there was one day we had to run round the school doing it will all machines (re joining) but that was down to a server issue we had faures on the hdd and lost entire sections of AD.

[irsprint84]

I had this issue alot when I first installed windows 7 site wise (I was one of the first) the issue has gone away though I installed latest drivers and sp1 + updates

[glennda]

I had this issue alot when I first installed windows 7 site wise (I was one of the first) the issue has gone away though I installed latest drivers and sp1 + updates

 

Same here - in the first couple of weeks after i rolled out 7 i was rejoining 2/3 to the domain a day (out of 900). After all the updates from when i made the image had been deployed and Sp1 it seems to have sorted itself.

[irsprint84]

Same here - in the first couple of weeks after i rolled out 7 i was rejoining 2/3 to the domain a day (out of 900). After all the updates from when i made the image had been deployed and Sp1 it seems to have sorted itself.

 

If I recall there was a hotfix for sp0, which was rolled into Sp1

[sted]

ive had it a few times but in every case the pc/laptop has had a realtek nic in it and not had it for a while

[Ashm]

Yes we have been having same issue with some of our staff & student laptops (running Windows 7 x86 with SP1) every now and again.

 

I'm fairly sure the problem is when someone turns off the laptop while it's loading windows, the next time they boot the laptop it gives them the option to boot into repair mode or boot normally. By default it's set to boot to repair mode (so most people will select it or let it time out), I've found that in repair mode Windows will give user the option to use system restore to restore to a previous restore point that could end up being before the last time the computer account password has been changed (I think by default it's 30 days). If that's the case it will come up with the trust relationship error the next time it boots and someone tries to log in (rejoining it to the domain fixes it but like you I wanted a more long term fix).

 

What I've done is created a group policy startup script to disable start up repair by default and to ignore all boot errors with the following commands:

bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

 

I've only deployed this fix about a week ago but I'm hoping it resolves it.

[FN-GM]

Yes we have been having same issue with some of our staff & student laptops (running Windows 7 x86 with SP1) every now and again.

 

I'm fairly sure the problem is when someone turns off the laptop while it's loading windows, the next time they boot the laptop it gives them the option to boot into repair mode or boot normally. By default it's set to boot to repair mode (so most people will select it or let it time out), I've found that in repair mode Windows will give user the option to use system restore to restore to a previous restore point that could end up being before the last time the computer account password has been changed (I think by default it's 30 days). If that's the case it will come up with the trust relationship error the next time it boots and someone tries to log in (rejoining it to the domain fixes it but like you I wanted a more long term fix).

 

What I've done is created a group policy startup script to disable start up repair by default and to ignore all boot errors with the following commands:

bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

 

I've only deployed this fix about a week ago but I'm hoping it resolves it.

 

Is that a batch file please?

[SYNACK]

Here are some methods that should allow you to track down the actual cause of the issue and probably fix it.

 

This is usually to do with the machine account change process, sometimes it seems to fail in the background leaving the machine account still in active directory but not able to logon with the domain trust error. The other thing that can cause this is machines with duplicate SPNs.

 

To deal initially with the auto change on the machine account passwords (which fail to update to the server) you should be able to just disable the autochange:

How to disable automatic machine account password changes

1. Start Registry Editor. To do so, click Start, click Run, type regedit in the Open box, and then click OK.
   
2. Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
   
3. In the right pane, click the DisablePasswordChange
   entry.
   
4. On the Edit menu, click Modify.
   
5. In the Value data box, type a value of 1, and then click OK.
   
6. Quit Registry Editor.
   

 

You can also reset the connection password using a netdom command but that does not always work:

Netdom reset

netdom reset /d:myDomain.contoso.com myWorkstation

Not sure if it is run from the client or the DC as I tried it both ways each time

 

I tended to unjoin/rejoin the workstations when they became a problem as I only had a couple pull this kind of stunt every 3-4 months.

 

As to the SPNs this can easily happen if you accidentally name a workstation the same as another recently joined one (that has not reset the machine password yet. This can cause duplicate SPNs in AD which toasts the accounts in the short or long term.

This person had some luck with finding and removing them using the setSPN.exe tool along with ADSI edit to give them the proper level of kill:

The trust relationship between this workstation and the primary domain failed | Daily Tweak

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.

 

The linked thread also has lots of other possible solutions too.

 

This thread is the last discussion on here about this fault.

 

http://www.edugeek.net/forums/windows-7/81544-trust-relationship-error-windows-7-a-3.html

[plexer]

Started experiencing this today with our win 7 machines.

 

Grr.

 

Ben

[adamchapman]

Hi,

 

Not sure if anyone has seen this issue before?

 

We run a windows 7 domain here with everyone having a laptop device.. We do have a few desktops on windows 7 but not many. So all students have a laptop and now and again some students come to us and sometimes its the same ones complaining their laptop won't let them logon and its says "The Trust relationship between the primary domain failed"

 

I've searched the internet and found a couple of posts saying that remove the PC from the domain and rejoin it. This i admit works but i don't feel it is a log term fix. The PC's in question have all updates installed.

 

Anyone seen this before and have a fix?

 

We've had this a few times when a user tries to run the start up repair or system restore in windows 7. I think its something to to with the Active Directory computer account passwords being mixed up if the machine is taken back too far.

Our usual fix is just to re-join the domain manually.

[irsprint84]

do you have SP1? also at the time I had w2k3 DC's though it stopped after a while while on 2k3 so maybe do windows updates for those servers I m now on 2008 r2 DCs

[Michael]

This is the hotfix that addresses this issue. This is included in Service Pack 1. If you click 'View and request hotfix downloads' at the top left, it states 'Release SP1'.

 

I've used 7 SP1 for a while now and it does fix a lot of issues. I think re-imaging is probably the quickest way of deploying it, along with other software updates.

[MarkBerridge]

I have also been having this problem now alot, even with clients upgraded to SP1. What I have found out is that the DNS forward lookup records are pointing to the wrong place. What I have to do is to delete the computers forward and reverse records in DNS and also the DHCP record. I then have to remove and re add the computer to the domain. I also delete the computer account so i can keep the same name. This is becoming a little tedious now and would like to know why this is happeneing?

 

This is an example of 1 computer we have that is doing this:

 

Netbook101(Computer Name) - 10.5.91.191 (DNS Forward)

 

Netbook101(Computer Name) - 10.5.91.145 (DNS Reverse)

10.5.91.191 - netbook030(Computer Name) (DNS Reverse)

 

ipconfig on local machine - 10.5.91.145

 

10.5.91.191 - Does not exist (DHCP)

Netbook101 - 10.5.91.145 (DHCP)

 

I think that made sense above...

[todd]

We've seen the same thing and it's usually because two computers have the same name.

[Arthur]

@Synack. Regarding post #10. Try this instead...

 

netdom resetpwd /server:domaincontroller /userd:domain\administrator /passwordd *

 

You can find a copy of NetDom.exe in the Remote Server Administration Tools if you want to run it from a Windows 7 PC. More details here.

[ihaveaproblem]

We've seen the same thing and it's usually because two computers have the same name.

 

Same. Happened to me when accidentally had two computers with the same name.

[kennysarmy]

We have laptops on Win7 SP1 which this happens on.

 

I am going to push out a GPO which disables machine account password changes and will see how it goes....

[FN-GM]

Disabling startup repair did the trick for me.

[adamf]

I've also been experencing this alot since we moved to Windows 7. I've got a case open with Microsoft because I am fed up with re-joining machines to the domain when they loose the trust relationship. They think it's something to do with the way we imaged the machines using SCCM, but i'm not so sure as out of 1000 or so machines not every machine has expererienced the problem (and they were all imaged the same way), they also will just loose the relationship randomly so I don't the issue is being caused by duplicate names (in this instance anyway....)

 

Will update you all if I get anything meaningful...

[Ashm]

Disabling startup repair did the trick for me.

Yep same here, after deploying the fix mentioned here we haven't had the issue occur again.

[Michael]

There's a good article here that describes why it happens.

 

Up until now I've demoted the machine from the domain and then re-promoted, it always works.

 

Interestingly in every case, this trust issue happens only with wireless netbooks/notebooks and not wired desktops.

 

I believe it probably may have something to do with Windows 7 repairing itself or something along these lines.

[Arthur]

Up until now I've demoted the machine from the domain and then re-promoted, it always works.

Have you ever tried using the NLTest command? Unlike NetDom.exe, it is included with Windows 7 as standard and is a bit quicker than re-joining the computer to the domain.

 

nltest /sc_verify:YourDomain

 

http://i.imgur.com/Vwe86.png

[burgemaster]

We have regular powercuts, occasionally leading to win7 machines deciding to repair themselves at startup!

 

This as a computer startup script sorted it for us:

 

Disbale_Repair_Win7.bat

 

bcdedit /set {default} bootstatuspolicy ignoreallfailures

Edited March 6, 2012 by burgemaster