Source

Level

Description

The account-identifier allocator failed to initialize properly. The record data contains the NT error code that caused the failure. Windows 2000 may retry the initialization until it succeeds; until that time, account creation will be denied on this Domain Controller. Please look for other SAM event logs that may indicate the exact reason for the failure.

Comments

 

This problem can occur because Windows Server 2003 Service Pack 1-based computers add hard-coded prefixes to Active Directory. Typically, these prefixes are not outgoing-replicated to partner domain controllers. See ME913539 for information on solving this problem.

Aa per Microsoft: "When you use Dcpromo.exe to create a new domain controller replica in a forest consisting of a single domain and one existing domain controller, you may receive an "Access Denied" error message when you use Dssite.msc to replicate from the new domain controller to the existing one. In addition, the new domain controller's Directory Service log may record Error 16650". See ME285836, ME839879, and ME822053 to resolve this problem.

From a newsgroup post: "I just had this situation last week and I got out of it successfully. It sounds like you took the route I did when retiring my old server. This is to say that you most likely never demoted the old server gracefully and it still appears in you AD database. There is no need to worry. If you are no longer planning to have the retired server in your domain, transfer the FSMO roles to the new server and then use ntdsutil.exe to cleanup the Metadata of the outgoing server. Read these three articles closely: ME216498, ME223787 and ME298450.
If you did demote the old machine before reinstalling, run "netdom query fsmo" from the command prompt to determine who owns the RID master role. Netdom.exe is part of the support tools that comes with your server media. Sometimes FSMO roles do not transfer gracefully to another replica when you demote a DC that holds a role. In that, case you will need to seize the role".

From a newsgroup post: "Check and make sure that the FSMO role RID Master is available and operational in the domain. By default, this is created on the first DC that was created in the domain. You can determine who the RID Master is supposed to be by bringing up AD Users and Computers and right clicking on the domain and selecting Operations Masters. The RID role should be on a DC in your domain. If it is not, you may have removed the DC that it was originally on, but did not transfer it before the removal. In this case, you will have to use ntdsutil to seize the role to a current operational DC".

From a newsgroup post: "In case you encounter this error after you performed a backup restore, as you may know each DC has a pool of RIDs to create security principals (users, groups, and computers). When a DC is restored, an old RID pool might also be restored. To make sure it is not re-used, the DC dumps it and request a new one. The FSMO role that hands out RID pools is the RID master. Your RID master MUST be available as the first DC in your recovery steps. Read “Active Directory Forest Recovery“ for information on AD recovery".

ME234790 shows information on how to find servers that hold Flexible Single Master Operations Roles.

This happened to me when I added 2 domain controllers to an existing domain with 2 separate sites. I forced a replication and it resolved the issue.

I had this error after promoting an NT PDC to Windows 2000. This created a new domain in an existing forest. I could not replicate the connection in Active Directory Sites and Services; an "access denied" message was generated every time I tried. I followed Microsoft ME285836 article with one exception being that since this was a child domain there is no Enterprise Admin group. I added the DC to the "Access this computer from the network" group policy setting and everything is ok now.

I just cleared this error for one of my colleagues after he ran a DCPROMO to create a 2nd DC for a Win2k Domain. I am not sure what he saw when he did the DCPromo but it appeared the process never completed and these SAM and related errors were logged repeatedly. The DCDiag /v errors seemed obvious, but I believe the cause was the domain FQDN being a "single-label DNS name" as Microsoft refers to it. Information about configuring Windows for domains with single-label DNS names can be found in ME300684. I have added the value 1 to UpdateTopLevelDomainZones in the following registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters. I have added this value for both the first AD DC and the failing 2nd DC. Rebooted both and everything is ok.

I found that one of my Domain Controller which was Infrastucture Master was also a Global Catalogue. One I disable GC on Inf Master DC and forced replication to other DC, all was fine.

As per Microsoft: This behavior can occur because the RID Master FSMO is unavailable or fails to replicate. The Domain Controller cannot obtain and initialize the RID pool. This behavior can also occur when the User Right "Access this computer from the network" has not been given to the appropriate groups such as "Enterprise Domain Controllers" or "Authenticated Users". See the link below for more details.

I have encountered this  issue when I have multiple domains represented in the same site. Replication choose by the KCC is arbitrary.

I had this error occur on two of five new domain controller installations. Both DCs were at branch offices with extremely limited bandwidth (approx 64Kpbs) back to the main office. After about 30 minutes, the problem resolved itself after the branch DC was able to fully replicate and find the RID Master.

See ME255504 for instructions on using NDSUTIL.