AD Replication - DNS Issue?

[Halo12]

Hello everyone. I'm hoping I've come to the right place. We are having AD replication errors to one of our locations (replication from this location appears to be working). There is a long line of errors (4013, 4000, 1925, 2054, 1311, 1865, 1566 - event viewer IDs).

I'm trying to wade through each one but unfortunately I don't know how to implement a fix. Some key points:

 

 

• When running repadmin /showrepl it tells me that it cannot replicate via RPC to our other site because the remote site is unavailable. Firewall access isn't blocking any of the needed ports and I can see that our firewall is passing the traffic through
  
• Running dcdiag shows up errors about the target principle name being incorrect
  
• When I run net view using the other server's name it errors out but when I do it via IP it works
  
• When I try to manually replicate I get an error that says the naming context is in the process of being removed or is not being replicated from the specified server
  
• Looking in the _msdcs folder on the DNS console I saw that the NS was listed as an old DC that hasn't been connected for over 2 years. I have removed that entry and added our current domain controllers to it in the hope that it might help
  

 

I can't even add a new DC at the site because it errored out: 'This wizard cannot access the list of domains in the forest. The specified network name is no longer available'

 

Then there are errors around Kerberos. A commonly suggested fix of running the netdom /resetpwd command doesn't work when I try the FQDN of the server (specified network name is no longer available) but the command works when I use its IP. However, Kerberos errors are still there.

 

I'm completely at a loss of what the cause of this (and fix) is. If anybody here has an idea of what might be happening then I'd be incredibly grateful.

[DavR]

The fact that you can't resolve names of some of the servers suggests there's definitely a DNS problem. Without DNS working, there is no AD replication.

 

Can you ping DC1 > DC2 by name, and vice versa?

 

What DNS server is each DC looking at? I've always had each DC as a DNS server, with the NIC settings pointing first to itself, to ensure a reliable DNS connection.

 

In your DNS zone, both DCs should be name servers, and be listed name > IP in the zone.

[Halo12]

Hello there. Yes I'm able to ping both DCs and all DCs are in the DNS zone as name servers. Each site has 2 DCs with DNS installed on it. The primary DNS is set to the other server with the secondary DNS server set to itself.

[DavR]

Is replication between the 2 x DCs on each site working OK?

 

I wonder what would happen if you pointed NIC DNS from a DC on site 1 to point to a DC on site 2, and vice versa, to try and force a zone replication between the two?

 

Although is sounds like potentially your replication situation is already beyond that trick :/

[Halo12]

When we first noticed the issues replication was failing between the 2 DCs on site, but after running the klist purge command when doing the netdom /resetpwd process there were no longer any errors. Is our situation beyond help do you think?

[chaplic]

Cant make my mind up if it's connectivity or a logical AD thing. Connecting to things via IP \\10.1.2.3 is going to use different protocols to \\dc2

 

You say you are confident about the firewall what about local firewall. Has the server decided it's not on a domain network and through the FW up?

 

I would also be looking in DNS very carefully tho ensure every record is tehre and expected and not pointing at wrong IP.

 

I'd also definetly fiddle with DNS settings on various DCs as DavRs suggestion

 

edit: no-one tried something daft with hosts?

BTW I had thee seperate sites each with a DC disconnected for several weeks/months (wan bill was not paid!) and much to my pleasant surprise it all sorted itself out with very few issues.

[psydii]

BTW I had thee separate sites each with a DC disconnected for several weeks/months (wan bill was not paid!) and much to my pleasant surprise it all sorted itself out with very few issues.

 

That is a very relevant anecdote. As long as it's less than 180 Days, and no one does anything daft like grabbing the FSMO roles you should be good!

 

 

"The primary DNS is set to the other server with the secondary DNS server set to itself."

 

As has already been mentioned (and assuming you've not been in this state more than 3 months) this might well be the source of the problems.

On the DC's NICs TCP/IP settings set the primary DNS server to be 127.0.0.1 and the secondary to be another DC (perhaps a working one at a remote site if the can communicate over TCP 53)

Try it on one DC first and then REBOOT IT. This should allow it to re-initialise itself properly.

 

If that doesn't cure it for that DC, then follow the diagnostic steps in this document:

https://learn.microsoft.com/en-GB/troubleshoot/windows-server/identity/active-directory-replication-event-id-2087

 

While you've not listed that event id as present in your logs, documents on learn.microsoft... relating to event ID's you have reported refer back to this document as steps you can follow to get to the bottom of DNS problems.

[timbo343]

Have you checked to make sure the Automatic services are running in services.msc?

 

One of the DCs might have tombstoned so you'll need to give the out of sync server a kick.

 

Run "netdom query fsmo" on your DC to see where the FSMO roles are stored and go from there.

 

You might have to seize the FSMO roles and force them to another DC to make the domain reside on a "live" DC.

Edited April 20, 2023 by timbo343