Active Directory (AD) objects must all have an identifier that is unique within the domain. This identifier, called a security ID (SID), is a combination of a domain-wide identification number and a unique, per-object relative identifier (RID). Because every domain controller in a domain can create new objects, the possibility exists for duplicate RIDs, which would be a problem. To prevent that, each domain controller is only permitted to issue RIDs from a pool, and that pool is assigned by the RID master, a special Flexible Single Master Operations (FSMOs) role held by one domain controller in each domain.
Normally, when a domain controller runs out of RIDs, it contacts the RID master for a new pool. The RID master ensures that each domain controller receives a unique pool, preserving the uniqueness of the object SIDs in the domain. However, sometimes a domain controller uses up RIDs faster than it can get them. This situation can happen more frequently in a domain that is receiving migrated user accounts, each of which needs a RID. Automated migration tools can create new user accounts more quickly than a domain controller can get more RIDs.
You'll see evidence of this in the Directory Services event log on the affected domain controller. The event ID to look for is 16645, which reads:
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 master domain controller.
Account creation on this domain controller will fail until a new pool has been allocated. There may be network or connectivity problems in the domain, or the master domain controller may be offline or missing from the domain. Verify that the master domain controller is running and connected to the domain.
The event itself gives good advice: Make sure that the RID master is online, and if it isn't consider transferring the role to another domain controller.
You can verify that the RID pool is the problem by connecting directly to another domain controller and attempting to create a new user or group. If that domain controller is able to create the object, the problem is confined to the domain controller on which the event appeared. Once the RID master is back online, the affected domain controller will eventually request a new pool (there's no way to force the process), and start working again.
If you know you're going be using up RIDs quickly, consider expanding the size of the RID pool allocated to each domain controller. Doing so requires a registry hack on the domain controller that's playing RID master: Locate the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values. Modify the RID Block Size value from its default of 0 to a higher number. The default value of 0 is treated internally as 500, which is the default RID pool size.
Prior to Service Pack 4 (SP4), values beyond 500 are treated as 500, meaning there's effectively no way to increase the pool size. SP4 corrects this problem. However, 500 is still the minimum size you can configure; setting the value to 400 will still be treated as 500.
Be sure to remember your change; if you ever decommission that domain controller or move the RID master role to another one, you will have to modify the new RID master's registry. You can safely modify this value on all domain controllers, if you like, to make this possibility less of a concern.
For more details, refer to the Microsoft article "RID Pool Allocation and Sizing Changes in Windows 2000 SP4."
Worried about using up all the RIDs? Don't. It's possible, but there are about 2^30 RIDs available in a domain, which represents millions and millions of objects.
Domain controllers are designed to request a new RID pool when they've exhausted 80 percent of their current pool. At a fast rate of consumption, especially when the domain's RID master is across a WAN link (as might be the case when migrating a field office), the remaining 20 percent of the RID pool is used up before the domain controller can snag a new pool.
Under Win2K Server SP4 and later, this threshold was changed to 50 percent. This decreases the chances of RID pool exhaustion becoming a problem, unless you're creating new objects at a truly breakneck pace.