Fix ERROR_DS_DRA_BUSY (0X000020F6) in Active Directory replication
This error means the domain controller is too busy to replicate. Here are the three most common causes and how to fix each one fast.
Cause 1: Replication backlog – too many pending changes
This is the most common reason you’ll see error 0X000020F6. Your domain controller just can’t keep up with the number of changes waiting to replicate. Maybe you added hundreds of users at once, or a large Group Policy update hit all DCs simultaneously. The replication queue fills up, and the busy DC starts rejecting incoming replication requests.
The fix: First, confirm the backlog. Open an elevated command prompt and run:
repadmin /queue *
Look for any DC with a queue length above 100. That’s your problem child. Then run:
repadmin /replsummary
This shows replication failures across all DCs. Identify the source DC and the destination DC that are failing.
Now, force replication manually from the source to the destination to empty the queue faster:
repadmin /syncall /AdeP <DestinationDCName> <NamingContext>
Replace <DestinationDCName> with the actual DC hostname and <NamingContext> with the partition (like DC=domain,DC=com). Repeat for each naming context if needed. I’ve seen this clear a backlog of 500+ changes in under 10 minutes.
If the queue won’t drain, check if the DC is stuck in a loop. Run:
repadmin /showrepl * /csv > repl.csv
Open that CSV and look for any 0X000020F6 errors. If you find them, the DC may need a restart of the Active Directory Domain Services service. That’s rare but happens.
Cause 2: A backup or antivirus scan is hogging the DC
This one tripped me up the first time too. A scheduled backup job (like Windows Server Backup or a third-party agent) or a full antivirus scan can lock the NTDS database, making the DC think it’s too busy to replicate. The error pops up during the backup window.
The fix: Check your backup schedule. If the error appears at the same time every day, that’s your culprit. You have two options:
- Move the backup window to off-peak hours, like 2 AM on weekends.
- Use a snapshot-based backup (like VSS) instead of a file-level backup that locks the database. Most enterprise backup tools support this.
For antivirus, exclude the NTDS folder and the SYSVOL folder from real-time scanning. On Windows Server 2016 and later, the default paths are:
C:\Windows\NTDS\
C:\Windows\SYSVOL\
Also exclude these processes: lsass.exe, ntfrs.exe, and dfsrs.exe. After making those changes, restart the Active Directory Domain Services service on the affected DC. Then verify replication with:
repadmin /replsummary
Cause 3: Network latency or packet loss between DCs
This one’s sneaky because the event log doesn’t always scream “network issue.” The DC sees the replication request but can’t respond fast enough due to high latency or packet loss, so it throws ERROR_DS_DRA_BUSY. This happens most often in hybrid environments with a VPN tunnel between sites, or when a site link is misconfigured with a low cost but terrible bandwidth.
The fix: First, test latency between the two affected DCs using a simple ping:
ping <DestinationDC> -n 10
If response times are over 50 ms or you see any packet loss (even 1%), that’s your problem. Also run:
tracert <DestinationDC>
Look for hops with high latency or timeouts. Those are the trouble spots.
Now, check your site link configuration. Open Active Directory Sites and Services, expand Inter-Site Transports, and pick IP. Double-click the site link that connects those DCs. If the Cost is below 100 but the link is slow (say, a 1 Mbps VPN), you need to either raise the cost or change replication options. I usually set the cost to 200+ for slow links and check the Ignore schedules checkbox so replication happens whenever possible.
If you can’t improve the link, adjust the replication interval. In the same properties window, change the Replicate every setting from 180 minutes (default) to something shorter like 60 minutes. That gives the DC more breathing room.
Still broken? Consider adding a bridgehead server in the remote site. In Active Directory Sites and Services, right-click the server, go to Properties, and under Transport, check This server is a preferred bridgehead server for the following transports. Pick IP. That forces replication through a designated DC, often clearing the busy error.
Quick-reference summary
Here’s a table of the three causes, their symptoms, and the immediate fix:
| Cause | Symptom | Fix |
|---|---|---|
| Replication backlog | Queue length > 100 in repadmin /queue * | Force sync with repadmin /syncall |
| Backup or antivirus locking NTDS | Error occurs during backup window | Move backup time or exclude NTDS/SYSVOL from AV |
| Network latency/packet loss | Ping > 50 ms or packet loss | Raise site link cost or add bridgehead server |
Was this solution helpful?