Fix 0xC00002A7: No RIDs Allocated in Active Directory

Quick answer

Run repadmin /syncall /AdeP to force replication, then bump the RID pool using ntdsutil — if that fails, seize the RID master role or rebuild the DC.

What's actually happening here is your domain controller tried to hand out a new security identifier (SID) to a user, computer, or group, but the local RID pool is empty. Every object in AD gets a SID made of the domain SID plus a relative identifier (RID). Each DC keeps a block of RIDs it can use, allocated by the RID master FSMO role holder. When that block runs dry and no new one can be allocated, you hit 0xC00002A7 — typically right when you try to create a new object or promote another DC.

This error rarely appears out of nowhere. The usual trigger is a DC that was cloned from a snapshot or had its SID changed improperly — think a VM template restored or a failed dcpromo. The RID pool is tied to the DC's SID, so when that changes, the pool becomes unusable. In 2023 patches, Microsoft tightened validation, so even a stale pool entry can throw this error on a seemingly healthy DC.

Fix steps

1. Check replication health. Run repadmin /replsummary and dcdiag /test:replications. If replication is broken, fix that first — a RID pool request can't complete if the RID master is unreachable.
2. Force a RID pool refresh. On the affected DC, open an elevated command prompt and run:

   ntdsutil
   "rid pool"
   "set rid pool server" <DC_name>
   "connections"
   "connect to server <DC_name>"
   quit
   "rid pool"
   "get rid pool"
   

   The get rid pool shows the current range. If it's low (say below 500), you can bump it manually with "set rid pool" to a higher value. But honestly, ntdsutil only lets you set the pool size for the current DC, not the global pool. The real trick is to force the DC to request a new pool by deleting the local RID counter file.

3. Delete the RID counter file. Stop the NTDS service (net stop ntds), then delete C:\Windows\NTDS\edb.chk? No, that's the checkpoint file — don't touch that. The file you want is RID in the NTDS folder? Actually, there's no separate RID file. The RID pool is stored in the AD database itself, under the CN=RID Manager$ object. So this step isn't right — skip it.
4. Force replication from the RID master. On the RID master itself, run repadmin /syncall /AdeP. Then on the affected DC, run repadmin /sync /AdeP to pull the latest RID pool allocation.
5. Seize the RID master role. If the RID master is dead or unreachable, you'll need to seize the role. Run ntdsutil and use "roles" → "connections" → "connect to server <DC_name>" → quit, then "seize rid master". This is a last resort — only do it if the original RID master will never come back.
6. Rebuild the DC. If none of the above works, the DC's local RID pool is corrupt beyond repair. Demote the DC (dcpromo /forceremoval), clean up metadata, and re-promote it. This gives it a fresh DSID and a clean RID pool.

Alternative fixes

If the error shows up on a specific object creation, you might be able to sidestep it by creating the object on a different DC. That's not a fix, just a workaround — the underlying pool is still empty. Also, check the event log for event ID 16645 or 16646. Those point to the RID pool being low or exhausted. Sometimes simply increasing the pool size via the registry works:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
RID Available Pool = 2000 (DWORD)

But that's a band-aid, not a cure. The RID master still has to allocate a new block eventually.

Prevention

Never clone a DC from a snapshot without using the proper DC cloning process (the DcCloneConfig.xml file). If you're virtualizing, use the cloning feature in Hyper-V or VMware that runs the appropriate prep steps. Also, keep your domain at a functional level that supports cloning — Windows Server 2012 R2 or later. And monitor the RID pool size in perfmon (NTDS\RID Allocations). If it drops below 10% of the global pool, allocate a new block proactively.

The root cause of 0xC00002A7 is almost always a broken RID pool allocation chain. Fix the replication, reset the pool, and if that fails, don't waste hours — rebuild the DC. It's faster than chasing ghosts in the AD database.