Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 96
  • Last Modified:

Continue to get Event ID 1055 after forceful removal of old domain controller, and running metadata cleanup.

I came into an environment where after some digging appeared to have physically removed an old domain controller from the environment, without first  releasing the FSMO roles.  After finding this, I seized all FSMO roles sucessfully on the server, then completed a metadata cleanup.  However, even after a reboot of the current now (and only) domain controller, I still have clients showing Event ID 1055 errors in the event viewer, indicating that they are not able to authenticate with the domain controller?

I am struggling with finding a solution...
0
ITGUY-17
Asked:
ITGUY-17
1 Solution
 
WalkaboutTiggerCommented:
Check DNS for lingering records to the domain  - from a client machine, ping the domain name.

HOSTS or LMHOSTS file has bad static records?  I have seen this in the past where a novice admin "fixed" issues by pushing changes out to all workstation HOSTS file (located in C:\Windows\System32\Devices\ETC\).

Legacy domain replication connections not deleted as part of metadata cleanup - open ADSS and check replication connectors.
0
 
Hypercat (Deb)Commented:
Did you makes sure that the OLD DC was not longer listed as a global catalog?  What about DNS - are all workstations pointing to the current server? Is time synch working on the domain?

Have you checked and either reset the computer accounts or removed and rejoined the domain to see if that fixes the issue?
1
 
FOXActive Directory/Exchange EngineerCommented:
Is the current DC set up with DHCP?  If so make sure all the workstations are pointing the the domain controllers online.
Open DHCP>expand your Domain Controller>expand IPv4>right-click Server Options>select options...scroll down to DNS servers, put a check inside DNS servers....at the bottom add the ip(s) of your DNS server(s).

YOur workstations will now automatically point the the dns of your Domain controllers
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
ITGUY-17Author Commented:
"WalkaboutTigger"- I checked the DNS records, and do show that there is still a Name Server (NS) record for the decommissioned server, and also an Alias listed.  Also there is still a "Host (A)" record still listed.  I should remove all three of these records, correct?

"Hypercat (Deb)"- Yes, I removed the old DC from ADSS, and also from ADUC.  I had not yet unjoined and re-joined the pcs from the network.  It's a network of about 11 workstaitons, so not to big of a time grabber if I have to do this.

"Fox"- Yes, the current (and only) DC is also the netowkrs DHCP.  The only DNS servers confiugered for the scope are the current server, and the netwoork firewall.
0
 
WalkaboutTiggerCommented:
Yes, DNS MUST be scrubbed of records pointing to the decommissioned server.  This is the most likely cause of these errors.
0
 
ITGUY-17Author Commented:
After the removal of these records, I rebooted client machines, and did not receive these event errors upon reboot.  Communication to the DC seems to be working as expected.

Thanks for all the help!
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now