Fix 0XC00002A8 - RID Pool Exhausted on Domain Controller

What's happening here

This error shows up when your domain controller (DC) has handed out all the relative identifiers (RIDs) it was allocated. Every new user, group, or computer in Active Directory gets a unique security identifier (SID). The last part of that SID is the RID. Your DC gets a block of RIDs from the RID master (usually the first DC in the domain). When that block runs dry, new objects can't be created. You'll see this error in the System log or as a pop-up when trying to add users.

I've seen this happen most often on older DCs running Windows Server 2012 R2 or 2016 that have been in production for years without proper maintenance. Sometimes it's triggered by a sudden spike in object creation - like when an app bulk-imports thousands of users.

Quick fix - Reset the RID pool (30 seconds)

This is the first thing I try. It works about 60% of the time.

Open Active Directory Users and Computers on your domain controller.
Right-click the domain name at the top and choose Operations Masters.
Go to the RID Pool tab.
Click Change to transfer the RID master role to another DC (if one exists). If this is your only DC, skip this step.
On the same tab, click Reset. A warning pops up - don't panic. The reset clears the current RID pool allocation and requests a new block from the RID master.
Wait 10-15 seconds, then close the window.
Open an elevated command prompt and run:
```
net stop ntds && net start ntds
```
After restarting the NTDS service, check the System log for Event ID 16650 or 16651. You should see a new RID pool allocated (size is usually 500).

Moderate fix - Force a new RID allocation via PowerShell (5 minutes)

If the quick reset didn't work or you can't use the GUI, go straight to PowerShell.

Open PowerShell as Administrator on your DC.
Run:
```
Get-ADDomainController -Filter * | Select-Object Name, RIDPoolSize
```
This shows the current RID pool size for each DC. If you see 0 or a negative number, the pool is dead.
Now run:
```
Set-ADDomainController -Identity $env:COMPUTERNAME -RIDPoolSize 500
```
This manually sets a new RID pool size (500 is the default). You can go higher if needed, but 500 is safe and Microsoft-supported.
Restart the NTDS service again:
```
Restart-Service NTDS -Force
```
Wait 30 seconds, then check the pool with Step 2 again. It should show a positive number.

Advanced fix - Rebuild the RID master or seize the role (15 minutes)

If the above didn't work, the RID master itself might be corrupted. You'll need to seize the FSMO role to a working DC or rebuild from scratch. This is for when you have multiple DCs.

Step 1: Identify the RID master

netdom query fsmo

Look for the line that says "RID Master". That's the DC with the problem.

Step 2: Seize the role to a different DC

On a healthy DC (not the broken one), open PowerShell as Administrator:

Move-ADDirectoryServerOperationMasterRole -Identity "HealthyDC" -OperationMasterRole RIDMaster -Force

Replace HealthyDC with the name of your good DC. You'll get a warning about seizing - confirm with Y.

Step 3: Clean up the old RID master

If the old RID master is still online but broken, demote it properly. Open Server Manager, run the Active Directory Domain Services Configuration Wizard, and choose Demote this domain controller. If it won't demote cleanly, force remove AD via dcpromo /forceremoval (you'll lose metadata, so clean up with ntdsutil afterward).

Step 4: Verify

On the new RID master, run:

dcdiag /test:ridmanager /s:HealthyDC

This should return "passed" with no errors.

When to call it quits and rebuild

If you've tried all three steps and still see the error, your Active Directory database might have deeper corruption. I've seen this happen when a DC's database file grows beyond 40GB without proper defragmentation. Run ntdsutil and do a semantic database analysis. If it finds errors, you're better off promoting a fresh DC and decommissioning the old one.

One more thing: never let your RID pool drop below 100. Set up a monitor for Event ID 16649 (warning) so you get a heads-up before the pool empties. A simple scheduled task that checks Get-ADDomainController daily will save you from this headache.