RID Pool Exhaustion — Cannot Create New AD Objects

Introduction

A helpdesk ticket comes in: a new starter cannot be onboarded because the account creation wizard fails partway through. Someone retries it, and it fails again, with a message that says almost nothing – just that the directory service could not allocate an identifier. Nothing about disk space, permissions, or replication. The next attempt, on a different object, in a different OU, produces the exact same failure.

This is what RID exhaustion looks like from the front line: a single generic error that can mean three very different things underneath, each with a different fix. Getting it wrong wastes a maintenance window solving a problem the domain doesn’t actually have.

What the Error Looks Like

Whatever tool triggers the object creation – Active Directory Users and Computers, New-ADUser, a provisioning script, a domain join – the failure surfaces as the same directory service error:

Windows cannot create the object because:
The directory service was unable to allocate a relative identifier.

On the domain controller that attempted the creation, the System event log records a companion event from source SAM:

Log Name:      System
Source:        SAM
Event ID:      16645
Level:         Error
Description:
The maximum account identifier allocated to this domain controller has been
assigned. The domain controller has failed to obtain a new identifier pool.
A possible reason for this is that the domain controller has been unable to
contact the RID master domain controller. Account creation on this
controller will fail until a new pool has been allocated. There may be
network or connectivity problems in the domain, or the RID master domain
controller may be offline or missing from the domain. Verify that the RID
master domain controller is running and connected to the domain.

If the RID master itself was recently restored from backup or a snapshot and failed to reinitialize its own allocator, it logs a different event instead:

Log Name:      System
Source:        SAM
Event ID:      16650
Level:         Error
Description:
The account-identifier allocator failed to initialize properly. The record
data contains the NT error code that caused the failure. Windows will retry
the initialization until it succeeds; until that time, account creation
will be denied on this Domain Controller.

What It Actually Means

Every security principal – user, group, or computer – gets a SID made of a domain identifier plus a relative identifier (RID), a monotonically increasing number unique within that domain. Domain controllers don’t hand out RIDs from a shared live counter; each DC is issued its own block, by default 500 RIDs at a time, by whichever domain controller holds the RID master FSMO role. A DC creates objects locally from its own block until that block runs out, then requests another from the RID master.

The domain as a whole only has so many RIDs to give out. RIDs are 30 bits wide by default, capping a domain at roughly 1.07 billion security principals over its entire lifetime – not concurrently, cumulatively, including every object ever deleted. Windows Server 2012 added the option to unlock a 31st bit, roughly doubling that ceiling to about 2.15 billion, but only as a last resort.

Since Windows Server 2012, the RID master also enforces an artificial safety ceiling at 90 percent of the global RID space consumed – 10 percent remaining. Crossing it sets msDS-RIDPoolAllocationEnabled to FALSE on the CN=RID Manager$ object and blocks further pool issuance domain-wide until an administrator explicitly re-enables it. This is a deliberate circuit breaker: it exists to force someone to investigate why a domain that should last decades is suddenly running low, rather than let it run to zero silently.

How to Diagnose

Work from cheapest check to deepest. Most RID failures turn out to be reachability or replication problems, not real exhaustion.

# 1. Confirm which DC holds the RID master role
netdom query fsmo

# 2. Ask the domain controller having the problem for its own
#    view of the RID pool and RID master connectivity
Dcdiag /test:ridmanager /v

# 3. Read just the current available pool ceiling from that output
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

# 4. Check the System event log for the events above
Get-WinEvent -LogName System | Where-Object { $_.Id -in 16642,16645,16650,16656,16657 } |
  Select-Object -First 10 TimeCreated, Id, Message

# 5. Confirm AD replication is healthy between this DC and the RID master
#    (a stuck replication link is a common reason a fresh pool never arrives)
repadmin /showrepl
repadmin /replsummary

Common Causes

Working Through a Fix

Identify which of the three scenarios above applies before changing anything – the wrong fix for the wrong scenario either does nothing or, in the case of the 31-bit unlock, permanently changes the domain.

If the RID master is simply unreachable and cannot be brought back online in a reasonable time, transfer the role to a healthy domain controller. If the original holder is gone for good, seize it instead – but only after confirming it will never come back onto the network, since a resurrected former RID master that doesn’t know it lost the role can double-issue RID pools:

ntdsutil
roles
connections
connect to server dc02.corp.example.com
quit
transfer rid master
q
q

If the domain has hit the 90 percent artificial ceiling (event 16657), investigate the consumption pattern first – this protection exists precisely so nobody re-enables allocation on autopilot. Once satisfied it’s safe to continue, remove the block from the RID master, which must be a Windows Server 2012 or later domain controller:

# In LDP.exe, connected and bound to the RID master on port 389:
# Browse > Modify
#   Dn:                    cn=RID Manager$,cn=System,dc=corp,dc=example,dc=com
#   Edit Entry Attribute:  MsDS-RidPoolAllocationEnabled
#   Values:                TRUE
#   Operation:             Replace
# Select Synchronous and Extended, then Run.

If the global RID space is genuinely close to exhausted – not just past the 90 percent ceiling, but confirmed by rIDAvailablePool showing a small remaining count – unlock the 31-bit space to roughly double the domain’s total capacity. This requires the RID master to be running Windows Server 2012 or later, and every domain controller in the domain must be Windows Server 2012 or later, or Windows Server 2008 R2 with KB2642658 installed; unpatched Windows Server 2003 or 2008 DCs simply stop being able to issue RIDs once this is set:

# In LDP.exe, connected and bound to the RID master on port 389:
# Browse > Modify
#   Dn:                    (leave blank - this is a rootDSE attribute)
#   Edit Entry Attribute:  SidCompatibilityVersion
#   Values:                1
#   Operation:             Add
# Select Synchronous and Extended, then Run.

Confirm any of these fixes worked from the affected domain controller with Dcdiag /test:ridmanager /v, then retry the object creation that originally failed.

How to Prevent It

Treat the periodic RID consumption events as monitored signals, not background noise. Events 16656 (1 percent from ceiling), 16657 (ceiling reached), and 16658 (100-million-RID milestone warnings) should all page someone – by the time 16657 fires, account creation across the entire domain is already blocked.

Leave RID Block Size at its default unless there’s a specific, measured reason to change it, and never set it above the Windows Server 2012+ enforced cap of 15,000. Audit provisioning scripts and bulk-import jobs for retry logic that silently recreates failed objects – a failed account creation still consumes a RID, so a script that retries a validation failure in a loop can burn through blocks far faster than real object growth would suggest. After any forest recovery, domain controller demotion, or metadata cleanup, re-run Dcdiag /test:ridmanager /v as a sanity check rather than waiting for the next ceiling warning to prove the domain is healthy.

Quick Reference

Final Thoughts

RID exhaustion is rarely about a domain actually running out of a billion identifiers. Almost every real-world case is a RID master that’s unreachable, a restore that didn’t reinitialize the allocator cleanly, or the Windows Server 2012 safety ceiling doing exactly what it was designed to do – stopping account creation until someone confirms the consumption pattern is expected.

The generic client-facing error gives no hint which of those it is. The event log on the domain controller that failed, and on the RID master itself, is where the real diagnosis happens.