The directory service has exhausted the pool of relative identifiers

While testing a script to create ~800 AD acocunts on a Windows 2008 server the following Error came up:

The directory service has exhausted the pool of relative identifiers

After this all dsadd attempts result in a pause of ~10 seconds and dsadd failed:The specified domain either does not exist or could not be contacted.

After restarting the server the first dsadd gives the "exhausted the pool" message, followed by the "does not exist or could not be contacted"

In the event logs I see

The maximum account identifier allocated to this domain controller has been assigned. The domain controller has failed to obtain a new identifier pool.

And

The request for a new account-identifier pool failed. The operation will be retried until the request succeeds. The error is " The requested FSMO operation failed. The current FSMO holder could not be contacted. "

Checking RID/PDC/infrastructure FSMO roles shows them all assigned to this server (it is a single server AD domain) so what else could be causing this problem? I've restarted the server, but the issue persists.

From serverfault DrStalker

• New RIDs appear not to be being generated.

  This suggests either the RID service is broken, or the RID master role is not correctly asigned to this server, regardless of what your checks indicate.

  I'd suggest running 'netdom query fsmo' to double check the RID master role holder

  Are there any errors in the event logs for services failing to start?

  From xenny

• It's definitely telling you that it can't access the RID Master as xenny has said. DCDiag will run a set of tests that will give you a better idea of what is going on:

  dcdiag /v /test:ridmanager

  This will give you output similar to the following if things are OK:

  Starting test: RidManager
  * Available RID Pool for the Domain is 8604 to 1073741823
  * mydc1.mydomain.com is the RID Master
  * DsBind with RID Master was successful
  * rIDAllocationPool is 7604 to 8103
  * rIDPreviousAllocationPool is 7604 to 8103
  * rIDNextRID: 7768
  ......................... MYDC1 passed test RidManager

  From Helvick

• Eventually traced this down - there were stray SRV records in the DNS for _ldap._tcp.domain.com that were pointing to an old, removed, AD controller - they hadn't properly auto-updated, and the DC was going to them and then not contacting itself when that timed out.

  Manually deleting the records fixed the issue.

  The environment had worked for nine months after the old AD's removal, with no time outs or delays, so it wasn't something I thought of to check when running through recent changes that may have caused the issue.

  From DrStalker