DC Replication not working

tdhaslett · 2024-08-21T17:52:05.705Z

Hey All,
This one’s a doozy (at least it feels like that right now).

I have a domain with 3 DCs that have not yet been migrated off of 2012 R2. Functional level is 2012 R2. It is also still using FRS for replication, which I have discovered was not working correctly when GPO changes were having issues.

I looked at the policies under sysvol and it looked like DC2 and DC3 were not getting updates from DC1 (the PDC Emulator). So, on DC2, I tried a non-authoritative restore by stopping the FRS service, changing BurFlags to D2, and then starting the service. It never completed. It is saying that it cannot enable replication from either DC1 or DC3 (Event ID 13508).

I went to look at DC1 and found that I am getting the JRNL_WRAP_ERROR. The solution seems to be to do a non-authoritative restore. If I do that on DC1, it won’t be able to pull from DC2, since the restore never completed. If it pulls from DC3 I will lose all policy changes made since DC3 last worked, correct? If it doesn’t, then both DC1 and 2 have no policies.

I’m not sure where to go from here. If possible, I would rather not lose the policies that I have on DC1, which seems to have the only up-to-date versions.

kwelch007 · 2024-08-21T20:32:12.889Z

Similar issue here:

DCDIAG FRS events 13508 and 13568 Windows

I have 2 domain controllers, one physical (physDC4) and one virtual (virtDC5), both are Server 2008 R2. I’m getting ready to replace the physical one with a VM. What I’m trying to understand is whether I should bother trying to fix the items below or just continue setting up the new DC and see if it works itself out after the physical one is removed. If I should fix them, then I’m wondering if these are directly related or not, and which one I should try to fix first. The event log on physDC4 …

Does dcdiag.exe tell you anything useful?

tb33t · 2024-08-21T20:48:12.088Z

Had a similar issue at my last position, although we were using DFSR for replication. I don’t recall the exact steps but had to go into ADSI Edit to make changes as our GPOs were not replicating across DCs also.

molan · 2024-08-21T21:31:13.441Z

kwelch007:

dcdiag.exe

this should always be the starting point for these types of issues

PatrickFarrell · 2024-08-22T06:45:07.834Z

The other starting point is DNS. Replication issues are almost always incorrect DNS setup.

Active Directory DNS Refresher Windows

It’s DNS. It’s always DNS. No, DNS is fine, it’s not DNS, trust me. It was DNS. I’m posting because in the last few weeks we’ve had a few posts that turned out to be misconfigurations with DNS in a domain environment. Things like Domain controllers pointing at themself first for DNS, or having a public DNS server on the NIC of the Domain Controller or the clients. Hopefully this will help some people get out in front of potential issues. The general rules for DNS in an AD E…

Forget the burflags fix.

On your good DC, go into group policy management and backup your GPOs.

On the non working DCs you can stop ntfrs, rename the c:\windows\ntfrs\jet folder and start it again. It will re-replicate, providing you are not having replication issues. Before you do that check your DNS as again these are almost always DNS problems. Do only 1 DC at a time.

Worst cast scenario demote a non working DC and promote it again. Once it’s replicating do the other one.

Clearing the jet folder however usually fixes this. I have done this dozens of times over the years.

adrian_ych · 2024-08-22T08:23:39.390Z

tdhaslett:

Hey All,
This one’s a doozy (at least it feels like that right now).

I have a domain with 3 DCs that have not yet been migrated off of 2012 R2. Functional level is 2012 R2. It is also still using FRS for replication, which I have discovered was not working correctly when GPO changes were having issues.

I looked at the policies under sysvol and it looked like DC2 and DC3 were not getting updates from DC1 (the PDC Emulator). So, on DC2, I tried a non-authoritative restore by stopping the FRS service, changing BurFlags to D2, and then starting the service. It never completed. It is saying that it cannot enable replication from either DC1 or DC3 (Event ID 13508).

I went to look at DC1 and found that I am getting the JRNL_WRAP_ERROR. The solution seems to be to do a non-authoritative restore. If I do that on DC1, it won’t be able to pull from DC2, since the restore never completed. If it pulls from DC3 I will lose all policy changes made since DC3 last worked, correct? If it doesn’t, then both DC1 and 2 have no policies.

I’m not sure where to go from here. If possible, I would rather not lose the policies that I have on DC1, which seems to have the only up-to-date versions.

Maybe here are a few steps to try

try to upgrade to using DFSR
confirm that the Domain level is at least Server 2012R2
Add in or change the IP address config of ALL the 3 DCs such that

DC1 uses DC2 IP as primary DNS server, uses DC3 IP address as secondary DNS server and 127.0.0.1 as 3rd DNS server IP
DC2 uses DC1 IP as primary DNS server, uses DC3 IP address as secondary DNS server and 127.0.0.1 as 3rd DNS server IP
DC3 uses DC1 IP as primary DNS server, uses DC2 IP address as secondary DNS server and 127.0.0.1 as 3rd DNS server IP

Run “ipconfig /registerDNS” on ALL the DCs
** Note that step 3 & 4 may take up to 72 hours to propagate (these are not instant as there are quite a few processes and data replications to take effect).
Try to move the 5 FMSO roles around (after step 3 & 4 completes).
Try to add 2 modern DCs like Server 2022 or Server 2019 then use it to replicate against all 3 DCs and then demote DC2012s ??

techcreeb · 2024-08-22T08:33:48.534Z

Anytime you have issues with DC not wanting to Rep,it is always a DNS bottleneck.Usually these sorts of issues are related to DNS in some way. I would start by verifying the Client DNS settings on both DCs and making sure you can ping both ways between DC-01 & DC-03 . Then I’d try restarting both the Netlogon & FRS services on both DC-01 & DC-03 and then Verify that restarting netlogon has re-registered the DCs SRV records in DNS (under _msdcs, _sites, _tcp, _udp, etc).

You can also check the following:

Check the Server’s Computer object in Active Directory to ensure it has a child object, called NTDS-Settings.
Verify that the SYSVOL share has been created and is active
Use “net share” in the command prompt to see if “SYSVOL” is listed.

Verify the Domain Membership of the DC.

Use “netdiag /test:member” and verify the test passes.

Verify the DC can communicate with other DCs.

Use “netdiag /test:dsgetdc and verify the test passes.

Verify the DC can replicate with other DCs.

Use “netdiag /test:replications and verify the test passes.

Verify the replication permissions are correct.

Use “dcdiag /test:netlogons and verify the test passes.

adrian_ych · 2024-08-22T09:22:27.743Z

Techcreeb:

You can also check the following:

Verify that the SYSVOL share has been created and is active

Use “net share” in the command prompt to see if “SYSVOL” is listed.

Verify the Domain Membership of the DC.

But do note that you should not manipulate SYSVOL. When a server is successfully promoted to a DC, the sysvol is created and also shared out automatically. Sometimes it may take up to 72 hours for that to happen (after certain replication processes complete).

molan · 2024-08-22T13:08:46.225Z

PatrickFarrell:

The other starting point is DNS. Replication issues are almost always incorrect DNS setup.

running DCDiag.exe will tell you if its DNS and a host of other issues.

I wouldn’t apply any of the suggested fixes without running DCDiag first to see what errors its listing or you risk making a bigger issue

tdhaslett · 2024-08-22T13:50:22.806Z

Wow, I came here to update this morning and found all of these great replies. Thanks all!

Before I found these replies, I did an authoritative restore from DC1 and that seems to have fixed it. I had already searched for that option, but I kept finding instructions for DFSR authoritative restores, so thought there was not an option for it with NTFRS.

Now to move replication to DFSR and then migrate to 2022 in the near future.

I was fairly certain that it was not a DNS issue. The DNS settings on the three DCs were already set as @adrian_ych recommends. Pinging by name worked in all directions without issue.

jarmbrister · 2024-08-22T13:50:46.382Z

PatrickFarrell:

On your good DC, go into group policy management and backup your GPOs.

I’ve nothing to add but came here to suggest this as a first step also.

PatrickFarrell · 2024-08-22T14:41:27.702Z

molan:

PatrickFarrell:

The other starting point is DNS. Replication issues are almost always incorrect DNS setup.

running DCDiag.exe will tell you if its DNS and a host of other issues.

I wouldn’t apply any of the suggested fixes without running DCDiag first to see what errors its listing or you risk making a bigger issue

dcdiag will run just fine if a DC points to itself first and another second. It will not flag that as a problem and it will cause these issues. I’m not saying don’t run dcdiag, you absolutely should but you have to look at DNS manually.

Source: Managed an environment of over 1000 domain controllers for years. Ever single time I saw a jrnl_wrap it’s because DNS was misconfigured at the local site pointing at itself first. Every time. 100%.

adrian_ych · 2024-08-23T04:31:05.497Z

tdhaslett:

Wow, I came here to update this morning and found all of these great replies. Thanks all!

Before I found these replies, I did an authoritative restore from DC1 and that seems to have fixed it. I had already searched for that option, but I kept finding instructions for DFSR authoritative restores, so thought there was not an option for it with NTFRS.

Now to move replication to DFSR and then migrate to 2022 in the near future.

I was fairly certain that it was not a DNS issue. The DNS settings on the three DCs were already set as @adrian_ych recommends. Pinging by name worked in all directions without issue.

But there are 3 steps to “solving DNS issue” which involves

round robin DNS IP addresses (need to wait 24-72 hrs)
registering the DCs in all the DNS server & also registering the Domain name in the DNS servers
negating firewalls (windows or AV etc) that may block ports used by the DCs.

But with using authoritative restore or non-authoritative restore, there is a best practice of “never restore DCs”. One of the main uses of DC backups are to restore Domain Objects instead of recovery of the DC.