STATUS_DS_RIDMGR_INIT_ERROR 0xC00002AA: RID Master Fix

You reboot a domain controller after patching and it hangs at the Windows splash screen, then throws a blue screen with STATUS_DS_RIDMGR_INIT_ERROR (0XC00002AA). Or maybe LSASS dies on boot and the box drops into Directory Services Restore Mode on its own. Either way, the message is the same: the RID Manager couldn't initialize.

Quick background on what that means. Every security principal in AD — users, groups, computers — gets a SID. The last chunk of that SID is a RID, and RIDs come out of a pool of 500 that each DC claims from the RID Master FSMO holder. When a DC boots, LSASS asks the RID Manager to initialize that subsystem. If the DC can't reach the RID Master, or its own RID pool metadata is corrupt, LSASS can't start and you get 0xC00002AA. That's the whole story.

Here's how to fix it, in order of likelihood.

Cause 1: The RID Master FSMO holder is down, offline, or unreachable

Nine out of ten times this is your problem. The failed DC can't talk to the RID Master, so it can't renew its RID pool, so LSASS bails on boot.

Confirm the role holder

From any working DC or a management workstation with RSAT:

netdom query fsmo
Get-ADDomain | Select-Object RIDMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Now check whether that server is actually up. Ping it, RDP to it, check health with dcdiag /s:RIDMASTERDC /test:ridmanager. If the RID Master is a VM that got snapshotted back to last week, or a physical box that's been powered off since Friday, that's your smoking gun.

The real fix

Bring the RID Master back online, or if it's dead and not coming back, seize the role to a healthy DC. Don't transfer, seize — the old holder isn't coming back.

ntdsutil
activate instance ntds
roles
connections
connect to server HEALTHYDC.corp.local
quit
seize rid master
quit
quit

Then reboot the broken DC. It should boot clean. If it doesn't, move to cause 2.

Don't skip the metadata cleanup afterward. If the old RID Master is gone forever, clean its NTDS Settings object out of Sites and Services, or you'll trip over this again.

Cause 2: Corrupted or missing RID Set on the failing DC

Every DC has an object in AD called a RID Set, stored under the DC's NTDS Settings. It tracks which RID pool the DC currently owns and how many IDs it's burned through. If that object gets mangled — usually after a bad restore, a failed replication, or an aggressive antivirus quarantine on NTDS.dit — the DC can't establish its RID state at boot.

Spot it

Search Event Viewer for these on the failed DC (from DSRM, or from a remote pull of the event log):

• Event ID 16650 — "The directory service failed to initialize the RID Manager"
• Event ID 16645 — "The maximum account identifier allocated to this domain controller has been assigned"
• Event ID 1168 — internal processing error referencing RID allocation

You can also query AD directly from another DC for the RID Set object:

Get-ADObject -SearchBase "CN=NTDS Settings,CN=FAILEDDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=local" -Filter * -Properties *

If the RID Set object is missing, or its rIDAllocationPool / rIDPreviousAllocationPool attributes look wrong (all zeros, or referencing RIDs outside the domain's range), that's the corruption.

The fix

The cleanest path is to invalidate the RID pool so the DC re-requests a fresh one. You do that by setting the rIDSetReferences attribute to null, or more simply, by forcing the DC to rebuild its RID Set on next boot.

Boot into DSRM. Then:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "RID Set Rebuild" /t REG_DWORD /d 1 /f

Reboot into normal mode. NTDS will discard the corrupt RID Set and pull a new pool from the RID Master. You'll see event 16651 confirm the new pool was allocated.

If DSRM isn't available either, you're looking at an authoritative restore or, worst case, a metadata cleanup and re-promote.

Cause 3: Time skew breaking Kerberos to the RID Master

Less common but sneaky. RID pool requests ride on authenticated RPC. If the DC's clock has drifted more than 5 minutes from the RID Master, Kerberos fails, and the RID Manager can't authenticate the request. You'll get 0xC00002AA with no obvious corruption anywhere.

Check it

w32tm /query /status
w32tm /stripchart /computer:RIDMASTERDC /dataonly /samples:5

If the offset is more than a few seconds, fix the time source. On a VM, this is almost always because the hypervisor is injecting time and fighting w32time. Disable host time sync in the VM settings, or configure w32time properly:

w32tm /config /manualpeerlist:"time.windows.com,0x8 ntp.corp.local,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /force

Reboot the failed DC after time is synced. It should come up clean once Kerberos can authenticate to the RID Master.

What NOT to do

• Don't try to hand-edit RID attributes in ADSI Edit unless you know exactly what you're doing. You'll break the domain's SID space and spend a weekend on the phone with Microsoft.
• Don't restore the DC from a snapshot older than the tombstone lifetime. You'll resurrect deleted objects and trigger a forest-wide replication storm.
• Don't seize the RID Master role to a broken DC. Test the target DC's health first with dcdiag /v /c /d /e.
• Don't assume it's a hardware issue. 0xC00002AA is almost never disk or RAM — it's an AD topology or state problem.

Quick reference

Start with cause 1. It's right 90% of the time, and it takes five minutes to check. If the RID Master is healthy and reachable, look at the RID Set. Time skew is the long shot but it's cheap to rule out. And if all three check out clean, you're looking at a restore — at which point call Microsoft and don't wing it.