0XC00002A5

STATUS_DS_BUSY (0xC00002A5) – Directory Service Busy Fix

Server & Cloud Intermediate 👁 6 views 📅 Jun 23, 2026

Domain controller rejecting LDAP binds or queries. Almost always a resource bottleneck or replication backlog. Restarting Netlogon or clearing pending operations usually clears it.

Quick Answer for Advanced Users

Check memory/CPU on the DC, force replication with repadmin /syncall, then restart the Netlogon service. If that doesn't help, look at the NTDS database size and pending operations in ntdsutil.

Why You Get This Error

This error shows up when a domain controller (DC) can't handle incoming LDAP requests — think of it like a server that's overwhelmed. The culprit here is almost always one of three things:

  • A memory or CPU spike (common on older DCs with 4GB RAM or less)
  • A replication backlog where pending changes pile up
  • A corrupted or bloated NTDS database (rare, but happens after a bad backup restore)

I've seen this most often after a Windows update reboot on a DC with 2012 R2 or 2016 — the server comes back, but replication hangs and LDAP queries time out with this code.

Step-by-Step Fix

Step 1: Check Basic Resources

Open Task Manager or run tasklist on the DC. If memory usage is above 90% or CPU is pegged at 100%, you've found the bottleneck. Common cause: a rogue backup agent or antivirus scanning AD logs. Kill the process eating resources — that alone sometimes fixes it.

Step 2: Force Replication

Open an elevated command prompt and run:

repadmin /syncall /AdeP

Wait for it to finish. If it hangs or errors out, you've got a replication link problem. Check with repadmin /showrepl for stuck connections. A single stuck inbound replication can saturate the LDAP queue.

Step 3: Restart Netlogon and NTDS Services

This is the fast fix I use probably once a month. Run these in order:

net stop netlogon
net stop ntds
net start ntds
net start netlogon

After restart, test an LDAP bind from another machine. If it works, you're done. If not, proceed.

Step 4: Check Pending Operations in ntdsutil

This will show you if the directory service is genuinely stuck on something:

ntdsutil
set ds root
list pending operations

If you see a long list of tasks stuck in 'waiting' state, you can try aborting them with cancel pending operation (use carefully). But honestly, if you're here and replication won't sync, a reboot is often the faster choice.

Step 5: Reboot the DC

I know it's boring, but when everything else fails, a clean reboot clears all pending operations and resets the LDAP stack. Schedule it during low usage if you can.

Alternative Fixes If the Main One Fails

Increase LDAP Query Timeout

If the DC is just slow (not totally saturated), you can give clients more time. On the DC, open Registry Editor and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Create a DWORD LDAPQueryTimeout and set it to 120 (seconds). Reboot the server. This doesn't fix the root cause but buys you time.

Move FSMO Roles Off a Struggling DC

If this DC holds the PDC or RID master role, it's under extra load. Move the roles to another DC using ntdsutil (the 'roles' command). After moving, the busy server often calms down.

Check for Malware or Ransomware

I've seen this error twice from crypto mining malware running on a DC. The miner spikes CPU to 100%, and LDAP fails. Run a full Defender scan offline or use a rescue disk.

Prevention Tips

Once you've fixed it, do these to keep it from coming back:

  • Monitor DC memory — if it's below 8GB, upgrade. I won't run a DC with less than 8GB anymore.
  • Set up replication monitoring with repadmin /showrepl in a scheduled task daily.
  • Don't install backup agents or antivirus on the same DC — use a dedicated management server.
A quick note for juniors: don't bother rebuilding the NTDS database (ntdsutil compact) unless you've ruled out the other steps — it takes hours and rarely fixes a transient busy error.

Was this solution helpful?