When This Error Shows Up
You're running repadmin /syncall or watching Event ID 1925 in the Directory Services log, and there it is — 0x000020F4 (DS_DRA_GENERIC). The error message reads: "The replication operation failed." It usually hits when you've added a new domain controller (DC) or changed IPs on an existing one, but the existing DCs can't reach it. I've seen it most often in multi-site setups where a new DC in a remote site tries to replicate back to the hub site but DNS records haven't updated yet. Another common trigger: a firewall rule blocks RPC traffic or port 135 (RPC Endpoint Mapper) between DCs.
Root Cause in Plain English
Active Directory replication relies heavily on DNS to locate other DCs. When you get 0x000020F4, it's almost always one of three things:
- DNS misconfiguration — The source DC can't resolve the destination DC's GUID-based SRV record (or the hostname).
- Network connectivity — RPC ports (135, 49152–65535 on modern Windows Server) are blocked between the two DCs.
- Time skew — Kerberos authentication fails if the clocks between DCs drift more than 5 minutes. This one is rarer but I've seen it bite people who forgot to sync time on a VM DC.
The error itself is a catch-all "something went wrong during replication" — it doesn't tell you exactly what. Think of it as AD's way of saying "I tried to replicate and gave up."
How to Fix It
Skip the generic advice about restarting the NTDS service — it won't help here. The real fix is systematic. Start with these steps in order.
Step 1: Check DNS Resolution
On the destination DC (the one failing to replicate), run this command to see if it can find the source DC:
nslookup -type=srv _ldap._tcp.dc._msdcs. 127.0.0.1 Replace <your_domain> with your AD domain (e.g., contoso.com). If the output shows only one DC (usually itself), that's your problem — the source DC's SRV record is missing or stale. Go to Step 2. If you see multiple DCs, move to Step 3.
Step 2: Register Missing SRV Records
On the source DC (the one you're trying to replicate from), run these commands as Administrator:
net stop netlogon
net start netlogon
ipconfig /registerdnsThis forces the Netlogon service to re-register all SRV records. Wait 5 minutes, then run the nslookup command from Step 1 again. If records still don't show up, check that the source DC's DNS zone is configured to allow dynamic updates (it should be set to "Secure only" for AD-integrated zones).
Step 3: Verify Network Connectivity
From the destination DC, test basic connectivity to the source DC:
Test-NetConnection -ComputerName -Port 135 If this fails (TcpTestSucceeded is False), you've got a firewall or routing issue. Open the Windows Firewall on both DCs and make sure the inbound rule "Active Directory Domain Controller" is enabled. For third-party firewalls, allow RPC dynamic ports (TCP 49152–65535 on Windows Server 2012 and later) and TCP 135, 389, 445, 464, 636, 3268, 3269.
Step 4: Check Time Synchronization
Run this on both DCs:
w32tm /query /statusCompare the "Stratum" and "Source" values. On the PDC Emulator (usually the first DC in the forest root), the source should be an external time server like pool.ntp.org. All other DCs should sync from the PDC Emulator. If the time difference between two DCs is over 5 minutes, run w32tm /resync /nowait on the lagging DC.
Step 5: Force Replication with Repadmin
Once you've fixed DNS and connectivity, force replication from the source DC:
repadmin /syncall /AdeP Replace <DestinationDC> with the DC that had the error, and <SourceDC> with its replication partner. The /AdeP flags tell repadmin to show errors, skip offline DCs, and push changes. You should see a green "Synced" message — no more 0x000020F4.
What to Check If It Still Fails
If the error persists after the steps above, you've got something deeper. Check for duplicate IP addresses on the network — I've seen a case where a printer took the same IP as a DC and caused this exact error. Also, run dcdiag /test:replications /v — it'll highlight any lingering object issues or tombstone lifetime mismatches. A rare cause: the "File Replication Service" (FRS) or DFSR service isn't running on the source DC. Finally, verify the source DC's event logs (Directory Services, System) for any other Event IDs like 1926 or 2108 — they'll point you to the exact failure point.