From: Jorge de Almeida Pinto [MVP] on
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
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Carl" <Carl(a)discussions.microsoft.com> wrote in message
news:24FB4F92-8008-4DB1-9845-9678E83FC5DC(a)microsoft.com...
> 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
>
> "Ryan Hanisco" wrote:
>
>> 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
>>
>> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
>> news:5249F8B0-E4B2-4C8E-AFE9-AC17EF4E416C(a)microsoft.com:
>>
>> > 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.
>>
>>


From: Carl on
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

"Jorge de Almeida Pinto [MVP]" wrote:

> 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
> -----------------------------------------------------------------------------
> * This posting is provided "AS IS" with no warranties and confers no rights!
> * Always test before implementing!
> -----------------------------------------------------------------------------
>
>
> -----------------------------------------------------------------------------
> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> news:24FB4F92-8008-4DB1-9845-9678E83FC5DC(a)microsoft.com...
> > 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
> >
> > "Ryan Hanisco" wrote:
> >
> >> 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
> >>
> >> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> >> news:5249F8B0-E4B2-4C8E-AFE9-AC17EF4E416C(a)microsoft.com:
> >>
> >> > 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.
> >>
> >>
>
>
>
From: Jorge de Almeida Pinto [MVP] on
can you tell if something has happened with the RID FSMO or someone has done
something with it recently?

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Carl" <Carl(a)discussions.microsoft.com> wrote in message
news:25AC191E-6A31-4B21-B7F1-B1809D56E62D(a)microsoft.com...
>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
>
> "Jorge de Almeida Pinto [MVP]" wrote:
>
>> 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
>> -----------------------------------------------------------------------------
>> * This posting is provided "AS IS" with no warranties and confers no
>> rights!
>> * Always test before implementing!
>> -----------------------------------------------------------------------------
>>
>>
>> -----------------------------------------------------------------------------
>> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
>> news:24FB4F92-8008-4DB1-9845-9678E83FC5DC(a)microsoft.com...
>> > 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
>> >
>> > "Ryan Hanisco" wrote:
>> >
>> >> 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
>> >>
>> >> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
>> >> news:5249F8B0-E4B2-4C8E-AFE9-AC17EF4E416C(a)microsoft.com:
>> >>
>> >> > 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.
>> >>
>> >>
>>
>>
>>


From: Jorge de Almeida Pinto [MVP] on
can you copy the message from the event ID 16650 and post it?

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Jorge de Almeida Pinto [MVP]"
<SubstituteThisWithMyFullNameSeparatedByDots(a)gmail.com> wrote in message
news:eTC4WyAJGHA.3752(a)TK2MSFTNGP11.phx.gbl...
> can you tell if something has happened with the RID FSMO or someone has
> done something with it recently?
>
> --
>
> Cheers,
> (HOPEFULLY THIS INFORMATION HELPS YOU!)
> # Jorge de Almeida Pinto #
> MVP Windows Server - Directory Services
> BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
> -----------------------------------------------------------------------------
> * This posting is provided "AS IS" with no warranties and confers no
> rights!
> * Always test before implementing!
> -----------------------------------------------------------------------------
>
>
> -----------------------------------------------------------------------------
> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> news:25AC191E-6A31-4B21-B7F1-B1809D56E62D(a)microsoft.com...
>>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
>>
>> "Jorge de Almeida Pinto [MVP]" wrote:
>>
>>> 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
>>> -----------------------------------------------------------------------------
>>> * This posting is provided "AS IS" with no warranties and confers no
>>> rights!
>>> * Always test before implementing!
>>> -----------------------------------------------------------------------------
>>>
>>>
>>> -----------------------------------------------------------------------------
>>> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
>>> news:24FB4F92-8008-4DB1-9845-9678E83FC5DC(a)microsoft.com...
>>> > 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
>>> >
>>> > "Ryan Hanisco" wrote:
>>> >
>>> >> 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
>>> >>
>>> >> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
>>> >> news:5249F8B0-E4B2-4C8E-AFE9-AC17EF4E416C(a)microsoft.com:
>>> >>
>>> >> > 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.
>>> >>
>>> >>
>>>
>>>
>>>
>
>


From: Carl on
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 de Almeida Pinto [MVP]" wrote:

> can you copy the message from the event ID 16650 and post it?
>
> --
>
> Cheers,
> (HOPEFULLY THIS INFORMATION HELPS YOU!)
> # Jorge de Almeida Pinto #
> MVP Windows Server - Directory Services
> BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
> -----------------------------------------------------------------------------
> * This posting is provided "AS IS" with no warranties and confers no rights!
> * Always test before implementing!
> -----------------------------------------------------------------------------
>
>
> -----------------------------------------------------------------------------
> "Jorge de Almeida Pinto [MVP]"
> <SubstituteThisWithMyFullNameSeparatedByDots(a)gmail.com> wrote in message
> news:eTC4WyAJGHA.3752(a)TK2MSFTNGP11.phx.gbl...
> > can you tell if something has happened with the RID FSMO or someone has
> > done something with it recently?
> >
> > --
> >
> > Cheers,
> > (HOPEFULLY THIS INFORMATION HELPS YOU!)
> > # Jorge de Almeida Pinto #
> > MVP Windows Server - Directory Services
> > BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
> > -----------------------------------------------------------------------------
> > * This posting is provided "AS IS" with no warranties and confers no
> > rights!
> > * Always test before implementing!
> > -----------------------------------------------------------------------------
> >
> >
> > -----------------------------------------------------------------------------
> > "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> > news:25AC191E-6A31-4B21-B7F1-B1809D56E62D(a)microsoft.com...
> >>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
> >>
> >> "Jorge de Almeida Pinto [MVP]" wrote:
> >>
> >>> 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
> >>> -----------------------------------------------------------------------------
> >>> * This posting is provided "AS IS" with no warranties and confers no
> >>> rights!
> >>> * Always test before implementing!
> >>> -----------------------------------------------------------------------------
> >>>
> >>>
> >>> -----------------------------------------------------------------------------
> >>> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> >>> news:24FB4F92-8008-4DB1-9845-9678E83FC5DC(a)microsoft.com...
> >>> > 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
> >>> >
> >>> > "Ryan Hanisco" wrote:
> >>> >
> >>> >> 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
> >>> >>
> >>> >> "Carl" <Carl(a)discussions.microsoft.com> wrote in message
> >>> >> news:5249F8B0-E4B2-4C8E-AFE9-AC17EF4E416C(a)microsoft.com:
> >>> >>
> >>> >> > 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.
> >>> >>
> >>> >>
> >>>
> >>>
> >>>
> >
> >
>
>
>