RID Master: "Next rid pool not allocated" DNS problem
Dan Mellem
We migrated from NT4 to Windows2000+AD several months ago. Yesterday we
were suddenly unable to create new accounts. When creating an account we
get "Windows cannot create the object because: The directory service has
exhausted the pool of relative identifiers."
We use BIND9 for DNS and have the DNS domain pusd.org and the NT domain
POMONAUSD. We created a DNS domain on POMONAUSD that delegates _tcp,
_udp, _sites, and _msdcs to the PDC (pusd-ad). This is based on the KB
article at http://support.microsoft.com/default.aspx?scid=kb;en-us;q255913.
Troubleshooting:
=================================
>netdom query fsmo
Schema owner pusd-ad.pomonausd
Domain role owner pusd-ad.pomonausd
PDC role pusd-ad.pomonausd
RID pool manager pusd-ad.pomonausd
Infrastructure owner pusd-ad.pomonausd
The command completed successfully.
=================================
"Netdiag /fix" - everything passed with one warning:
[WARNING] Cannot find a primary authoritative DNS server for the name
'pusd-ad.pomonausd.'. [RCODE_SERVER_FAILURE]
PASS - All the DNS entries for DC are registered on DNS server
'10.1.1.88' and other DCs also have some of the names registered.
But DCDIAG shows no RIDs left:
=================================
>dcdiag /v /test:ridmanager
Domain Controller Diagnosis
Performing initial setup:
* Verifying that the local machine pusd-ad, is a DC.
* Connecting to directory service on server pusd-ad.
* Collecting site info.
* Identifying all servers.
* Found 16 DC(s). Testing 1 of them.
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-Name\PUSD-AD
Starting test: Connectivity
* Active Directory LDAP Services Check
* Active Directory RPC Services Check
......................... PUSD-AD passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\PUSD-AD
Test omitted by user request: Replications
[...]
Test omitted by user request: KnowsOfRoleHolders
Starting test: RidManager
* Available RID Pool for the Domain is 18866 to 1073741823
* pusd-ad.pomonausd is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 10366 to 10865
* rIDNextRID: 10865
* rIDPreviousAllocationPool is 10366 to 10865
* Warning :Next rid pool not allocated
* Warning :There is less than 0% available RIDs in the current
pool
......................... PUSD-AD passed test RidManager
Test omitted by user request: MachineAccount
[...]
Test omitted by user request: systemlog
Running enterprise tests on : pomonausd
Test omitted by user request: Intersite
Test omitted by user request: FsmoCheck
=================================
BIND has the following in named.conf:
zone "pomonausd" {
type master;
file "pomonausd";
};
And "pomonausd" has:
=================================
$TTL 3D
@ IN SOA curly.pusd.org. system.pusd.org. (
2004091309 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
NS curly.pusd.org.
;
pomonausd. 600 IN A 10.1.1.3
pusd-ad A 10.1.1.3
pusd-bdc A 10.1.1.4
(other DCs are here)
;
; Delegation
;
_tcp NS pusd-ad.pomonausd.
_udp NS pusd-ad.pomonausd.
_sites NS pusd-ad.pomonausd.
_msdcs NS pusd-ad.pomonausd.
=================================
All of the important records, such as the "gc._msdcs.pomonausd." A
record and all the different SRV records (including the ones in
netlogon.dns) have shown up in the delegated DNS domains on PUSD-AD.
I've also looked in the directory:
rIDAvailablePool: 4611686014132439474 (high=1073741823, low=18866)
rIDAllocationPool: 46664819681406 (high=10865, low=10366)
rIDNextRID: 10865
And, of course, IP connectivity isn't a problem, and I can ping
"pusd-ad.pomonausd" and other hosts from PUSD-AD and they resolve correctly.
What am I missing?
Thanks a lot.
-Dan
Ace Fekay [MVP]
Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I commented
below
Apparently your domain is a single label name, such as "pomonausd", rather
than the required pomonausd.com or pomonausd.net or pomonausd.corp or
pomonausd.dan, etc. Not good at all. This is an issue that is difficult to
get around. Reason why is AD is DNS based, and DNS is hierarchal based. A
single label domain name has no hierarchy. Honestly, the best bet is to
resintall the domain (I know you didn;'t want to hear that) or upgrade to
Windows 2003 and use the domain rename tool.
Give you an example, when a client needs to logon on and its GetGpoList
function runs to connect to the DC to grab GPO's, it connects with this
name:
\\domain.com\sysvol\domain.com\policies\{GUIDofPolicyNumber...etc}
But in your case, it is connecting to:
\\pomonausd\sysvol\pomonausd\policies\{GUIDofPolicyNumber...etc}
You can see above in the first part of your UNC above:
\\{GUIDofPolicyNumber...etc}that it appears to the machine to be a computer
name instead of a domain name
--
Regards,
Ace
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.
This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services
Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
--
=================================
Ace Fekay [MVP]
Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I commented
below
> Hi,
>
Accidentally hit send too soon. To finish...
\\pomonausd\sysvol\pomonausd\policies\{Guid..etc}
The aboce first part looks like a computer name instead of a DNS name
\\pomonausd\sysvol
So the client machine will be looking for a computer called "pomonausd, but
it doesn;t exist. The same functionality works when a DC is contacting any
other service in the domain, such as trying to find the RID master to
replenish the pool. DFS is also affected, as well as replication to an
extent.
See if this helps:
826743 - Clients cannot dynamically register DNS records in a single-label
forward lookup zone:
http://support.microsoft.com/default.aspx?scid=kb;en-us;826743
300684 - Information About Configuring Windows 2000 for Domains with
Single-Label DNS Names [needs the domain.com name and cannot be
just --domain--]:
http://support.microsoft.com/?id=300684
Honestly, if you can plan a reinstall, that would be highly to your benefit.
Ace
Dan Mellem
Ace Fekay [MVP] wrote:
> In news:Ol0mHXom...@tk2msftngp13.phx.gbl,
> Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I commented
> below
>
>>Hi,
>>
>
> Apparently your domain is a single label name, such as "pomonausd",
> rather than the required pomonausd.com or pomonausd.net or
> pomonausd.corp or pomonausd.dan, etc. Not good at all. This is an
> issue that is difficult to get around. Reason why is AD is DNS based,
> and DNS is hierarchal based. A single label domain name has no
> hierarchy. Honestly, the best bet is to resintall the domain (I know
> you didn;'t want to hear that) or upgrade to Windows 2003 and use the
> domain rename tool.
Yes, that's right. We kept the same name as our prior domain and didn't
want to co-mingle our DNS domain with the Microsoft naming. We had
thought about doing pomonausd.pusd.org and delegating pomonausd but
thought the name was too long. Reinstalling isn't practical since we
have thousands of accounts tied to e-mail and file shares.
> <snip>
>
> Accidentally hit send too soon. To finish...
>
> \\pomonausd\sysvol\pomonausd\policies\{Guid..etc}
>
> The aboce first part looks like a computer name instead of a DNS name
> \\pomonausd\sysvol
Hm, very interesting. I didn't think about it trying to connect to a
computer with that name. However, there is an A record for POMONAUSD
which does point to the FDC so this should still resolve to the right
host for this but I'll have to make sure it's in WINS as well.
> So the client machine will be looking for a computer called "pomonausd, but
> it doesn;t exist. The same functionality works when a DC is contacting any
> other service in the domain, such as trying to find the RID master to
> replenish the pool. DFS is also affected, as well as replication to an
> extent.
Replication is working OK. Someone suggested moving the five FSMO roles
and the GC to another DC which worked fine. We're also able to create
accounts again. There was an old replication partner (our prior BDC)
that will still in the directory (but had died in January) that I had
forgotten about. We've also removed that. I'm going to play with this
configuration for a while (and perhaps create 250+ account and see if it
requests the next RID pool) and see if it's something with the DC.
> See if this helps:
> 826743 - Clients cannot dynamically register DNS records in a single-label
> forward lookup zone:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;826743
>
> 300684 - Information About Configuring Windows 2000 for Domains with
> Single-Label DNS Names [needs the domain.com name and cannot be
> just --domain--]:
> http://support.microsoft.com/?id=300684
>
> Honestly, if you can plan a reinstall, that would be highly to your benefit.
>
> Ace
Good KB articles. Fortunately for us we have few devices in the domain
and they're all added in the POMONAUSD DNS domain manually and have
reserved IP addresses so we haven't yet run in to the DDNS problem. Good
to know.
Thanks again for your help.
-Dan
Ace Fekay [MVP]
In news:4149DB6...@REMOVEpomona.k12.ca.us,
Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I commented
below
> Thanks a lot, Ace.
>
> Ace Fekay [MVP] wrote:
>> In news:Ol0mHXom...@tk2msftngp13.phx.gbl,
>> Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I
>> commented below
>>
>>> Hi,
>>>
>>
>> Apparently your domain is a single label name, such as "pomonausd",
>> rather than the required pomonausd.com or pomonausd.net or
>> pomonausd.corp or pomonausd.dan, etc. Not good at all. This is an
>> issue that is difficult to get around. Reason why is AD is DNS based,
>> and DNS is hierarchal based. A single label domain name has no
>> hierarchy. Honestly, the best bet is to resintall the domain (I know
>> you didn;'t want to hear that) or upgrade to Windows 2003 and use the
>> domain rename tool.
>
> Yes, that's right. We kept the same name as our prior domain and
> didn't want to co-mingle our DNS domain with the Microsoft naming. We
> had thought about doing pomonausd.pusd.org and delegating pomonausd
> but thought the name was too long. Reinstalling isn't practical since
> we have thousands of accounts tied to e-mail and file shares.
I can't see that name being too long. For NetBIOS domain communication, its
one "pomonausd" and not the whole FQDN. Its just that AD requires the TLD.
>> <snip>
>>
>> Accidentally hit send too soon. To finish...
>>
>> \\pomonausd\sysvol\pomonausd\policies\{Guid..etc}
>>
>> The aboce first part looks like a computer name instead of a DNS name
>> \\pomonausd\sysvol
>
> Hm, very interesting. I didn't think about it trying to connect to a
> computer with that name. However, there is an A record for POMONAUSD
> which does point to the FDC so this should still resolve to the right
> host for this but I'll have to make sure it's in WINS as well.
You'll need multiple names, actually one for each DC, since they all
normally register their LdapIpAddress record in DNS (the one that looks like
(same as parent), which is what it *normally* looks for when applying that
data I mentioned. I haven't heard of anyone trying to circumvent this
function with WINS entries.
Let me know if it works.
Its to your benefit to plan on somehow renaming the domain properly.
Otherwise, it will seem to be a cat and mouse game when issues arise!
Ace
Dan Mellem
Ace Fekay [MVP] wrote:
> Inline below...
>
> In news:4149DB6...@REMOVEpomona.k12.ca.us,
> Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I commented
> below
>>>In news:Ol0mHXom...@tk2msftngp13.phx.gbl,
>>>Dan Mellem <dan.m...@REMOVEpomona.k12.ca.us> made a post then I
>>>commented below
>>>
>>>and DNS is hierarchal based. A single label domain name has no
>>>hierarchy. Honestly, the best bet is to resintall the domain (I know
>>>you didn;'t want to hear that) or upgrade to Windows 2003 and use the
>>>domain rename tool.
>>
>>Yes, that's right. We kept the same name as our prior domain and
>>didn't want to co-mingle our DNS domain with the Microsoft naming. We
>>had thought about doing pomonausd.pusd.org and delegating pomonausd
>>but thought the name was too long. Reinstalling isn't practical since
>>we have thousands of accounts tied to e-mail and file shares.
>
>
> I can't see that name being too long. For NetBIOS domain communication, its
> one "pomonausd" and not the whole FQDN. Its just that AD requires the TLD.
Too long for our users, not technologically. Some user's usernames are
20 characters long so they may find themselves logging in as:
somelongus...@pomonausd.pusd.org
>
>>><snip>
[...]
>>Hm, very interesting. I didn't think about it trying to connect to a
>>computer with that name. However, there is an A record for POMONAUSD
>>which does point to the FDC so this should still resolve to the right
>>host for this but I'll have to make sure it's in WINS as well.
>
>
>
> You'll need multiple names, actually one for each DC, since they all
> normally register their LdapIpAddress record in DNS (the one that looks like
> (same as parent), which is what it *normally* looks for when applying that
> data I mentioned. I haven't heard of anyone trying to circumvent this
> function with WINS entries.
>
> Let me know if it works.
We do have a search domain for pusd.org set up and all of the DCs are in
DNS plus the same entries in WINS. So, if it looks for a DC, it can try
to get it from *.pomonausd, *.pusd.org, or WINS.
>
>
>
[...]
>>
>>Thanks again for your help.
>>
>>-Dan
>
>
> Its to your benefit to plan on somehow renaming the domain properly.
> Otherwise, it will seem to be a cat and mouse game when issues arise!
>
> Ace
I'll have to keep that in mind. Thanks again.
-Dan
Ace Fekay [MVP]
>> communication, its one "pomonausd" and not the whole FQDN. Its just
>> that AD requires the TLD.
>
> Too long for our users, not technologically. Some user's usernames are
> 20 characters long so they may find themselves logging in as:
>
> somelongus...@pomonausd.pusd.org
> [...]
>>> Hm, very interesting. I didn't think about it trying to connect to a
>>> computer with that name. However, there is an A record for POMONAUSD
>>> which does point to the FDC so this should still resolve to the
>>> right host for this but I'll have to make sure it's in WINS as well.
>>
>>
>>
>> You'll need multiple names, actually one for each DC, since they all
>> normally register their LdapIpAddress record in DNS (the one that
>> looks like (same as parent), which is what it *normally* looks for
>> when applying that data I mentioned. I haven't heard of anyone
>> trying to circumvent this function with WINS entries.
>>
>> Let me know if it works.
>
> We do have a search domain for pusd.org set up and all of the DCs are
> in DNS plus the same entries in WINS. So, if it looks for a DC, it
> can try to get it from *.pomonausd, *.pusd.org, or WINS.
>
>>
>>
>>
> [...]
>
>>>
>>> Thanks again for your help.
>>>
>>> -Dan
>>
>>
>> Its to your benefit to plan on somehow renaming the domain properly.
>> Otherwise, it will seem to be a cat and mouse game when issues arise!
>>
>> Ace
>
> I'll have to keep that in mind. Thanks again.
>
> -Dan
No problem for the suggestions. As for logon names, they can still select
the legacy method to logon, just supplying their usernames, password and
selecting their domain from the drop-down box instead of the UPN method
(which I realize is long and not too many people use it anyway due to that
reason). DNS is used for logon, but WINS would be used to connect by
NetBIOS.
Let me know, curious how you'll procede.
Ace