i had one today on a dual boot imacQuote:
Originally Posted by techie08
removed from doman then added again fixed the issue
Printable View
i had one today on a dual boot imacQuote:
Originally Posted by techie08
removed from doman then added again fixed the issue
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.
4 PCs have gone this afternoon after about a week of it no happening!
Another 3 today!! Its doing my head in now!
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
You can also reset the connection password using a netdom command but that does not always work:Quote:
- Start Registry Editor. To do so, click Start, click Run, type regedit in the Open box, and then click OK.
- Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Netlogon\Parameters
- In the right pane, click the DisablePasswordChange
entry.- On the Edit menu, click Modify.
- In the Value data box, type a value of 1, and then click OK.
- Quit Registry Editor.
Netdom reset
Not sure if it is run from the client or the DC as I tried it both ways each timeQuote:
netdom reset /d:myDomain.contoso.com myWorkstation
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
The linked thread also has lots of other possible solutions too.Quote:
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.
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.
ive just had a look at types of pc that have done it to me and they all have realtek gb cards onboard
We've just lost 3 of the "working" Veritons. :(
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.
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)
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!
I think @TheLibrarian has done something similar here