Fix AD admin limit exceeded 0XC00002C1 on Windows Server

When does this error show up?

You're trying to run an Active Directory task — maybe a replication check with repadmin /syncall, a bulk user import, or a big LDAP query from a management tool. Suddenly you get the error STATUS_DS_ADMIN_LIMIT_EXCEEDED (0XC00002C1). The operation stops cold. You might see it in Event Viewer as well, under Directory Services, with event ID 1644.

This usually happens when a domain controller has too many pending operations at once, or a single LDAP query is pulling more data than the server's configured limits allow. I've seen it most often during migrations when someone runs a script that fires off hundreds of admin requests per second.

Root cause in plain English

Active Directory has safety valves — hard limits on how many administrative operations (like AddUser, Modify, Replicate) can run at the same time. These limits are there to keep the server from falling over under heavy load. When you hit 0XC00002C1, one of these limits got hit:

LDAP admin timeout — a single request took too long (default is 120 seconds).
Maximum concurrent LDAP admin operations — too many admin tasks running at once (default is 50 per thread).
Replication backlog — too many pending replication requests stacked up.

The real fix isn't just ignoring the error or waiting. You need to adjust the limits or reduce the load. In my experience, the most common culprit is a misbehaving script or tool that opens hundreds of LDAP connections and never closes them properly.

The fix: step by step

Identify what operation triggered the error.
Open Event Viewer on the domain controller that gave the error. Go to Applications and Services Logs > Directory Service. Look for event ID 1644. The event details will tell you the exact LDAP query or operation that exceeded the limit. Write down the client IP and the LDAP filter used.
Check current LDAP admin limit settings.
Open a command prompt as Administrator on the domain controller. Run:
```
ntdsutil
LDAP policies
connections
connect to server localhost
quit
show values
```
You'll see something like MaxPoolThreads = 4, MaxDatagramRecv = 1024, MaxReceiveBuffer = 10485760. Look for MaxConnections and MaxActiveQueries. The defaults are usually fine, but if you see a custom low value, that's your bottleneck.
Increase the admin limit if needed.
Still in ntdsutil, run:
```
set MaxActiveQueries to 40
set MaxConnections to 1000
commit changes
quit
quit
```
These values are safe for a domain controller that has 8 GB RAM or more. MaxActiveQueries default is 20 — bumping it to 40 lets more admin operations run concurrently. MaxConnections default is 500, but 1000 handles heavy scripts better. After you commit, restart the Active Directory Domain Services service:
```
net stop ntds && net start ntds
```
Important: This restart disconnects all clients for a few seconds. Do it during a maintenance window.
Audit the offending client or script.
The client IP from event ID 1644 is your target. Check that machine for a runaway script, a misconfigured sync tool, or an old management utility. Common culprits: ADSI Edit with a large filter, PowerShell scripts that don't close System.DirectoryServices connections, or legacy backup software. I've fixed this more than once by simply updating a vendor's agent.
Clear the replication queue if replication is stuck.
If the error showed up during replication, run:
```
repadmin /showrepl * /csv > replication.csv
```
Look for partners with high failure counts. Then force replication with:
```
repadmin /syncall /AdeP
```
If that still fails, check the queue depth:
```
repadmin /queue *
```
Anything over 100 pending objects means you need to wait or increase replication interval temporarily.

What if it still fails?

If the error comes back after you've adjusted limits and fixed the script, you're looking at a deeper resource problem. Check these:

Memory pressure — open Task Manager on the DC. If lsass.exe is using over 4 GB, the server needs more RAM. Active Directory eats memory for caching, and when it's starved, admin limits get hit faster.
Duplicate SPNs or bad DNS — run dcdiag /test:dns on the DC. DNS issues can cause replication to retry constantly, flooding the admin queue.
Third-party agents — antivirus, backup, or monitoring tools that hook into Active Directory can trigger this. Disable them one by one (temporarily) to see if the error stops.

I've never seen this error on a properly sized DC with current patches. If you're on Server 2008 R2 or older, consider upgrading — those versions had tighter default limits that were bumped in later releases.