Active Directory RID Pool Init Failure: 0x00002013 Fix

Cause #1: The DC was restored from an old backup or VM snapshot

What's actually happening here is that the domain controller thinks its invocation ID changed, but the RID pool values on the RID master don't match what this DC expects. If you've ever restored a DC from a snapshot taken weeks ago, or cloned a VM improperly, the RID pool information gets out of sync. The DC tries to request a new RID pool from the RID master, but the master sees an invocation ID mismatch and refuses to hand one out. That's when you see the dreaded 0x00002013 in the event log.

You'll usually spot this right after a restore when you try to create a new user or group. The operation fails with the error, and the Directory Services event log on the DC shows event ID 16650 with the message "The directory service was unable to initialize the subsystem that allocates relative identifiers."

The fix: Force a new invocation ID and reset the RID pool

Skip the temptation to reboot and hope it goes away. Instead, you need to tell this DC to forget its old identity and start fresh. The official way is to use the ntdsutil tool:

ntdsutil
"metadata cleanup"
"select operation target"
"list roles for connected server"
"quit"
"quit"

But that only confirms which DC holds the RID master role. The real fix is to reset the invocation ID, which you do like this:

ntdsutil
"metadata cleanup"
"select operation target"
"list sites"
"select site 0"
"list domains in site"
"select domain 0"
"list servers for domain in site"
"select server <DCName>"
"quit"
"quit"
"reset invocation ID"
"quit"

After you run that, restart the NTDS service on the DC. Now the DC will replicate with its replication partners and pick up a new invocation ID. The RID pool will be renegotiated from scratch. I've seen this clear the error in under five minutes on Server 2016 and 2019.

Note: Only do this on a DC that you've intentionally restored. If you run it on a healthy DC, you'll force a full sync and possibly cause a brief outage.

Cause #2: RID pool values are corrupt or exhausted on the RID master

Another common trigger: the RID master's own RID pool is either empty or has corrupted entries. This happens more often than people think, especially on domains that have been running for years and have gone through many DC additions and removals. The RID master allocates RID pools to itself and all other DCs from a global counter. If that counter gets mangled (say, by a failed DCPromo or a rogue third-party tool), the master can't allocate the next pool to itself, and every DC that asks for a pool gets the same 0x00002013.

The fix: Extend the RID pool on the RID master

First, confirm which DC holds the RID master role:

netdom query fsmo

Then, on that DC, open an elevated PowerShell or CMD and run these commands to bump the RID pool size:

repadmin /removelingeringobjects <RIDMaster> <domain> /advisory_mode

That's only a diagnostic step. The actual fix is to adjust the rIDAvailablePool attribute. You'll need ADSI Edit or PowerShell with the AD module:

Import-Module ActiveDirectory
Get-ADDomain | Select-Object RIDMaster

Then use ADSI Edit to navigate to the domain NC, find the RID Manager object (CN=RID Manager$,CN=System), and open its attributes. Look for rIDAvailablePool. The value is a large number like 4611686018427387903. If it's lower than expected, you can manually raise it, but do so carefully — you're editing the source of truth for RID allocation. Set it to 4611686018427387903 if it's below a few million, then restart the NTDS service on the RID master.

What's actually happening here is that the pool counter is stored as a 64-bit number. The high 32 bits hold the next pool ID, and the low 32 bits hold the number of RIDs left in the current pool. If the low part is zero, the master thinks it's out of RIDs even though the global pool has plenty. Resetting the high part to a safe value forces the master to allocate a fresh block.

Cause #3: Time skew or replication failure between DCs

Less common but just as nasty: the DCs are out of time sync or replication has been broken for so long that the RID master's changes never reached the local DC. Active Directory is extremely sensitive to time differences — if the DC asking for a RID pool is more than five minutes off from the RID master, Kerberos and replication both fail, and the RID manager initialization fails with 0x00002013.

You'll see this if the error appears on a secondary DC but not the primary, and event 16650 is accompanied by event 1925 or similar replication warnings.

The fix: Fix time sync and force replication

First, verify the time on each DC:

w32tm /query /status

If it's off, reconfigure the time source. On the PDC emulator, set it to sync with an external time source:

w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
restart w32time

On other DCs, make sure they sync from the domain hierarchy:

w32tm /config /syncfromflags:domhier /update
restart w32time

Then force replication from the RID master to the affected DC:

repadmin /syncall /AdeP

If replication has been failing for a while, you might need to run repadmin /rehost to force a full sync from scratch. Once replication catches up and time is sorted, the RID manager usually initializes without further fuss.

Quick reference summary

One more thing: if you're still stuck after trying all three, run dcdiag /test:ridmanager on the RID master. That test will tell you exactly what's broken. I've seen cases where a rogue antivirus blocked the NTDS service from writing to the RID pool file, which showed up as a permissions error in the test output — that's a different beast entirely, but the test points you there.