Fix ERROR_DS_DRA_REPL_PENDING (0X0000211D) on Windows Server
This error appears during Active Directory replication when a DC hasn't replied yet. It's a delay, not a failure. You wait or force replication again.
When does this error show up?
You're running repadmin /syncall or repadmin /replicate on a Windows Server 2016 or 2019 domain controller. The command finishes, but instead of a success message you see:
ERROR_DS_DRA_REPL_PENDING (0x0000211D)
The replication request has been posted; waiting for a replyThis usually happens when you try to sync a busy DC that's already processing other replication requests. For example, after promoting a new DC, or when you manually force replication during a heavy sync window. The source DC hasn't answered yet because it's busy or the network is slow.
What's actually happening here?
Active Directory replication uses a store-and-forward model. Your local DC sends a request to the source DC. The source DC receives it, adds it to its queue, and says "I'll get back to you." The error code 0X0000211D means the request was accepted but not processed yet. It's not a failure — the replication will happen eventually.
The reason step 3 works is because you're manually triggering a new attempt. Sometimes the previous request gets stuck in a queue that's too long. A fresh attempt can bypass the backlog if the source DC freed up resources.
The fix: three things to try
1. Wait and check the queue
First, don't panic. Run this command on the source DC:
repadmin /queue *This shows how many replication requests are pending. If the number is under 10, wait 30 seconds and run your sync again. The original request probably completed. If the queue is above 50, the source DC is overloaded. Move to step 2.
2. Force replication with /async
Use the /async flag to send the request without waiting for a reply. This tells the local DC to just post the request and move on:
repadmin /syncall /AdeP /asyncThe error disappears because you're not blocking the command. The replication still happens in the background. Check it later with repadmin /showrepl.
3. Clear the queue and try again
If the queue is huge and nothing moves, you can force a specific replication to skip the queue. On the source DC, run:
repadmin /syncall /AdeP /forceThe /force flag pushes the replication even if the source DC is busy. It's like yelling at the DC to do it now. This works when the queue is stuck on a previous failed request. I've seen this fix it on Server 2019 with a backlog of 200+ items.
If it still fails
Check two things:
- Network latency between the DCs. Ping the source DC from the target. Anything above 200ms can cause timeouts that look like this error. Use
pathpingto spot packet loss. - The source DC's event log for error 1925 or 1988. These mean the source DC can't replicate because of schema conflicts. If you see them, fix the schema mismatch first.
You don't need to restart the DC or the service. The error is just a status, not a crash. Most of the time, waiting 30 seconds and retrying clears it. If not, the /force trick almost always works.
Was this solution helpful?