Event id 16650

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have a mixture of 2003 and 2k servers that are domain controllers on our
network. I recently installed a copy of 2k server on a spare machine, put
sp4 on it, grabbed all the updates from our SUS server and then I promoted it
to become a domain controller. Everything seems to be working fine, except
in the event logs, it keeps logging event id 16650 with the description of
"The account-identifier allocator failed to initialize properly. The record
data contains the NT error code that caused the failure. Windows 2000 will
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." I did a google
search on this particular event id, the kb article (839879) that talks about
this refers to a RID master which is not the case with this server. The RID
master is installed on a different server, a 2003 server. I don't have any
problems with creating object in AD on any other server on the network except
for this new one.
 
first....
check the RID Master itself as it could have a problem

on the RID MASTER run:

DCDIAG /D /C /V
NETDIAG /DEBUG /V

to see if something is wrong

also make sure ALL DCs in the domain can communicate with the RID master

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
Carl,

While not common, this can also be a DNS problem where the domain
controller cannot find all of the srv records that it is expecting.
Make sure that you can ping the domain by FQDN from the problem server
and that it has all of its DNS correctly pointed.

Jorge's advice is solid as well. I just like to always start with DNS
for these kinds of problems.

Ryan Hanisco
 
Checked DNS, everything seems to be working fine. I ran the dcdiag test per
Jorge's suggestion on both the RID master and the problem server. The test
results for the RID master server were good. For the problem server, the
following error appeared:

Starting test: RidManager
* Available RID Pool for the Domain is 142606 to 1073741823
* faxsvr0903.rrins.dom is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 142106 to 142605
No rids allocated -- please check eventlog.
......................... FORTDC2006 passed test RidManager

I also ran the same test on other DCs on the network, none has the same
error under "RidManager". I even tried to transfer the RID role to other DCs
including to this problem server and after transfering the role, no DC had
any problems creating new objects except for the same problem server (even
when it is the RID master).

Carl
 
Carl said:
We have a mixture of 2003 and 2k servers that are domain controllers on our
network. I recently installed a copy of 2k server on a spare machine, put
sp4 on it, grabbed all the updates from our SUS server and then I promoted it
to become a domain controller. Everything seems to be working fine, except
in the event logs, it keeps logging event id 16650 with the description of
"The account-identifier allocator failed to initialize properly. The record
data contains the NT error code that caused the failure. Windows 2000 will
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." I did a google
search on this particular event id, the kb article (839879) that talks about
this refers to a RID master which is not the case with this server. The RID
master is installed on a different server, a 2003 server. I don't have any
problems with creating object in AD on any other server on the network except
for this new one.
Click to expand...

What is the error code ?
 
RIDs are is requested and distributed in blocks of 500 RIDs. Each DC has at
least one block (RidpreviousAllocationpool). When that block has been
exhausted for 50% of its RIDs, the DC will ask a new block and store that in
the attribute called Ridallocationpool. When that block
(RidpreviousAllocationpool) is empty (exhausted for 100%) the block stored
in Ridallocationpool attribute will be moved to the
RidpreviousAllocationpool attribute and at that moment the RidAllocationpool
attribute will be empty. It will we used again when the
RidpreviousAllocationpool has been exhausted for 50%.

When you run:
DCDIAG /TEST:RIDMANAGER /V

This will show amongst other info:
* The available RID pool for the domain
* Who is the Rid master
* If a bind with the Rid master is successful
* Ridallocationpool (= the second pool of RIDs a DC has. A DC gets a second
pool when the first pool has passed 50%)
* RidpreviousAllocationpool (=the first pool used by the DC)
* RidNextRid (= the last used RID from the first pool)(and not the next rid
to be used as it looks like)

What is strange in your case is that it looks like it is not "moving" the
"rIDAllocationPool" to the "rIDPreviousAllocationPool".

Any other messages in the event log?

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
I ran the "DCDIAG /TEST:RIDMANAGER /V" command and it showed similar result
as the main dcdiag command I ran before i.e.

* rIDAllocationPool is 207606 to 208105
No rids allocated -- please check eventlog.
......................... FORTDC2006 passed test RidManager

Event id 16650 is the only thing we got on that problem DC.

Carl
 
The current RID master has been on the network for years and no other DCs has
any problems with creating new objects. Only two people have access to the
DCs collectively and neither has done anything to it nor has had the need for
any kind of restore from backup (Microsoft's article mentioned id 16650 is
related to after bring a RID master from backups). As far as the message
from 16650 was posted with the initial message, but here it is again:

The account-identifier allocator failed to initialize properly. The record
data contains the NT error code that caused the failure. Windows 2000 will
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.

Carl
 
Jorge,

I saw on one of the postings in this news group Janaka, Paul Bergson and you
were talking about a RID master issue and Paul had email you a too -
lookupdomaininfo.exe. Do you think that's something that I might want to
try? If so, can you please email it to me also?

Carl
 
Sorry, but no.

I don't know what that tool does, I asked Paul to see what it does.
Unfortunately I have not had the time to look at it. So, if you would not
mind, ask Paul for it as he is the one that distributed it in the first
place.

At this moment it looks like everything is tried just to make it work, while
the cause or the situation IMO is still unclear why it happened.
You are mentioning that object creation is OK. Yes, as long as the RID pool
of a certain DC is valid it will create security principals. BUT, what
happens if another DCs ask for a new RID pool because its current RID pool
is exhausted. I'm interested WHY the DC does not receive a new RID pool from
the RID FSMO.

Did this problem occur right after the promotion to DC? Have you ever been
able to create security principals on that DC?

Check the following on the RID Master...
REPADMIN /OPTION <FQDN RID MASTER FSMO>

post the output.

the reason I ask if something happened with the RID Master is to try to
determine if the cause is related to initial sync requirements as mentioned
in:

uInitial synchronization requirements for Windows 2000 Server and Windows
Server 2003 operations master role holders
..http://support.microsoft.com/?id=305476

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
Yes the problem started as soon as I promoted the server to become a DC. I
even tried to demote the DC and re-promote it, but no luck. I have not been
able to create new objects on this DC at all except for new contacts. The
dcdiag ridmanager test result I posted previously shows that the DC was able
to obtain a pool of rids, however no rids allocated was the actual error.

Here is the Repadmin output: "Current DC Options: IS_GC". This was the only
result I got after I ran "repadmin /options <fqdn rid server name>.

Carl
 
just checking the RID FSMO does not have OUTBOUND replication disabled. If
it was disabled it would not be able to distribute RID pools to DCs

on the RID master run:
REPADMIN /SHOWREPL <FQDN RID FSMO>

what is the output?

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
Actually I did run the command you suggested and the results were fine. Here
is what I've done yesterday. I demoted the problem server, I installed
Windows server 2003 on another computer and promoted it to become a DC in the
same domain, and this 2003 server has no problems with obtaining RIDs. I
also created a brand new forest/domain with the problem server (2k server)
and it didn't have any issues with issuing RIDs to itself (I did this just to
check if something went wrong with the OS installation itself). I don't know
what to do at this point. Do you know of any known issues with a 2k server
being a DC on the same network with other 2003 servers? Then again, I do
already have 4 other 2k servers on my production network and they don't have
any problems...

Carl
 
I have exactly the same issue with a Win2kSP4 DC promoted into a Domain whose
FSMO role holders are all Win2k3x64 Sp1 and it is driving me mad as I have
also carried out all the tests you have tried and the only anomily is the "No
rids allocated -- please check eventlog." after doing the DCDIAG
/test:RIDMANAGER /v.

Has anybody found a fix or a reason for this problem.

Carl H (spookily the same name as the originator of this thread).
 
Back
Top