Jump to content

Recommended Posts

Guest TheLibrarian
Posted
@TheLibrarian

 

We are running at 2003 functional level ;)

 

I couldn't remember what we were at; guess I should have turned round and asked you. :rolleyes:

Guest TheLibrarian
Posted

I could well be jumping the gun; network card drivers...

 

The latest set from Realtek seem (so far he says typing with crossed fingers) to have solved the issue.

 

Watch this thread for much gnashing of teeth and wailing etc. if it all goes wrong again.

Posted
Touch wood we haven't had any of our PCs come up with problem for a week or so now but the dual macs, we had 3 of today!

i had one today on a dual boot imac

removed from doman then added again fixed the issue

Posted

A random few of our computers display this problem when Windows has failed to boot. 'Startup Repair' was run (by users - as they did this before the problem was reported) and we do not know what repair method they selected. It appears that something performed in Startup Repair caused the relationship to fail.

 

This is only when it's not something obvious such as two computers with same name, account deleted, etc.

Posted

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.

  • Thanks 1
Guest TheLibrarian
Posted
It looks fairly definite for us now that the issue was the Realtek driver from ~2010 (supplied by Acer) and the driver that works (so far) is "Realtek 8168 Driver_Win7_7045_05202011" from the Realtek site Realtek.
Guest TheLibrarian
Posted
We've just lost 3 of the "working" Veritons. :(
Guest TheLibrarian
Posted

Very latest drivers make no difference.

 

We're now looking at going back to XP on most of the PC's.

 

@sister_annex; is now looking into possible time related issues; never been a problem with XP but it could be that 7 is much less tolerant.

Posted (edited)

Time issues are apparent - the w32time service should try and sync with a local DC (if the DC is advertising as a time source)

 

A DC will not advertise as a time source if it is not syncing with the PDC correctly (or if the PDC is not working correctly)

Edited by sister_annex
spelling....
Posted

We made a change to the station GPO to disable the computer changing its password every 30 days. So far we haven't had one go down since i last posted.

 

I Hope i haven't spoke too soon!

  • Thanks 1

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...