Windows 2012 Server keeps losing trust relationship with DC

Question

Hi, I have a Windows server 2012 that keeps losing trust with the domain Controller.

I have removed it, readded it, ran the netdom resetpwd to no avail and the problem comes back.

There is good network connectivity with the DC (Windows 2008, yeah I know really old) but the problem keeps happening. I even went and installed a new Windows Server 2019 to join the domain and after a few hours got the same message again on a new server.

How can I make sure the trust relationship stays up all the time without having to run any commands. I use this server for RDP access and users get locked out of the application because of this.

Thanks in advance.

Teo

Answer 1

Actually, that does not sound good. You can try the steps here.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/recovering-missing-frs-objects-attributes-ad#detecting-null-server-reference-attributes

but I'm afraid this issue may have exceeded the tombstone lifetime and rebuilding it from scratch may be the better option. This isn't that difficult. After removing it from the network you can perform cleanup. I believe HYPNOS is already the role holder but you can check by running netdom /query fsmo (on HYPNOS) Then do cleanup to remove the remnants of failed one.

Clean up Active Directory Domain Controller server metadata

Step-By-Step: Manually Removing A Domain Controller Server

After doing so it is important that after a reboot HYPNOS is 100% error free in system and FRS Replication event logs. Then you can begin the rebuild process of HERACLES.

I'd use dcdiag / repadmin tools to verify health correcting all errors found before starting any operations. Then stand up the new 2008, patch it fully, license it, join existing domain, add active directory domain services, promote it also making it a GC (recommended), use dcdiag / repadmin tools to again verify health, check again both are error free in system and FRS Replication event logs.

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 2

Please run;

Dcdiag /v /c /d /e /s:%computername% >C:\dcdiag.log (run on PDC emulator)
repadmin /showrepl >C:\repl.txt (run on any domain controller)
ipconfig /all > C:\%computername%.txt (run on EVERY domain controller)
ipconfig /all > C:\problemRDS.txt (run on problem machine)

Also check the domain controller System and Replication (DFS or FRS) event logs for errors since last boot. Post the Event Source and Event IDs of any found. (no evtx files)

then put unzipped text files up on OneDrive and share a link.

Answer 3

Hi Dave,

Thank you so much for your feedback.

I am going out of my mind trying to find the error.
Files shared here with this link:

https://1drv.ms/f/s!Au5lKmHvk4bgg2YsXORs5C7kDXDt?e=THLk9N

Errors found in Domain controller DFS and Replication:

DFS logs: no errors

System: Event ID 36886: No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this.

Answer 4

Sorry here are the files for the secondary domain controller I missed it on the previous reply:

https://1drv.ms/f/s!Au5lKmHvk4bgg2oukxg3KFEJky24?e=ffeIto

Answer 5

So the problem is a JRNL_WRAP_ERROR. which is a problem with replication between HYPNOS and HERACLES. You can work through the steps here to perform a nonauthoritative restore on HERACLES

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/use-burflags-to-reinitialize-frs#nonauthoritative-restore

After this is completed then check event 13516 is logged to signal that FRS is operational.

Also, (and not a showstopper) each domain controller should have (at minimum) its own static ip address and loopback 127.0.0.1 listed for DNS so I'd add DCs own static address, then do ipconfig /flushdns, ipconfig /registerdns, then restart the netlogon service. On both.

Then if you wanted you could put up new files to look at for confirmation.

--please don't forget to upvote and Accept as answer if the reply is helpful--