Link to home
Start Free TrialLog in
Avatar of jnordeng

asked on

Cleaning up DC errors

Hello. Our AD Domain is running Windows 2008 R2 at the Forest and Functional level.  Our primary DC's containing the FSMO rules live on the 2008 R2 servers.  We have Windows 2016 DC's in the mix and are preparing to move the FSMO roles to the Windows 2016 servers.

So, in DCDiag, I have 2 servers I cannot get rid of.  Combed through all of DNS in Windows and Bind (We have both), not there, Checked AD, not there, Ran through with powershell to look at inactive systems.. these are not in the list.  How do I get rid of these entries to clean this up?

      Starting test: SystemLog
         An error event occurred.  EventID: 0x0000165B
            Time Generated: 05/04/2021   09:26:43
            Event String:
            The session setup from computer 'WWW2R' failed because the security
database does not contain a trust account 'WWW2R$' referenced by the specified c
         An error event occurred.  EventID: 0x000016AD
            Time Generated: 05/04/2021   09:29:30
            Event String:
            The session setup from the computer WWW2R failed to authenticate. Th
e following error occurred:
         A warning event occurred.  EventID: 0x0000045A
            Time Generated: 05/04/2021   09:31:20
            Event String:
            Error communicating with the Spooler system service.  Open the Servi
ces snap-in and confirm that the Print Spooler service is running.

Avatar of Scott Silva
Scott Silva
Flag of United States of America image

You might have to dig around in ADSI Edit and look for the bad entries.
Avatar of jnordeng


Oh boy, fun ;)  Or I can ignore in DCDiag ;)
remove WWW2R from domain, and rejoin it
Thanks David but www2r does not exist as a VM, Physical nor is in DNS anywhere.

Avatar of Kaffiend
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for the feedback, I did find that though they were not in the domain or DNS, they still lingered in VMWare.. so found the culprit.  We have removed from there, and wolla.  Thanks.