First published on TechNet on Jan 27, 2010
here again with an interesting issue that causes the Advertising test in
to fail when verifying the role of a global catalog (GC).
A customer called Microsoft Product Support to determine why the Advertising test in
was reporting that the global catalog role was not working on a Windows Server 2008 Read-only domain controller (RODC) when all other indicators suggested it was functioning normally.
reported the DC was advertising as a GC but DCDiag couldn’t perform a search against the GC when the command was issued local to the server or remotely:
Dcdiag /test:advertising /v /s:RODC
Doing primary tests
Testing server: SITEZRODC01
Starting test: Advertising
The DC RODC01 is advertising itself as a DC and having a DS.
The DC RODC01 is advertising as an LDAP server
The DC RODC01 is not advertising as having a writeable directory because it is an RODC
The DC RODC01 is advertising as a Key Distribution Center
The DC RODC01 is advertising as a time server
Ldap search capabality attribute search failed on server RODC01,
return value = 81
Server RODC01 is advertising as a global catalog, but
it could not be verified that the server thought it was a GC.
......................... RODC01 failed test Advertising
Determine the health of the Global Catalog
There are some simple tests that can be done to verify the DC is advertising the Global Catalog role. First, make a connection to the W2K8 DC's ROOTDSE over port 389 or 3268 to determine if the DC has sourced and is advertising the global catalog:
Another useful test to verify the DC is advertising as a GC is to use the /GC parameter in
and observe that GC is listed in the Flags:
nltest /dsgetdc:contoso /force /gc
Dom Guid: a238ef59-eeef-11d2-a123-00805f9f123
Dom Name: CONTOSO
Forest Name: contoso.com
Dc Site Name: SITEX
Our Site Name: SITEX
Flags: GC DS LDAP KDC TIMESERV DNS_FOREST CLOSE_SITE PARTIAL_SECRET
The command completed successfully
The first two tests essentially confirm what dcdiag.exe already reports, namely that the server is advertising as a GC. The real question now is, “Do LDAP searches correctly retrieve objects from the global catalog?” Since the DC resides in contoso.com (the forest root domain) the search should be made to query an object from a different domain in the same forest over global catalog LDAP port 3268. The example below shows the GC successfully returns the child domain’s Administrator account:
Understanding why LDAP search in the Advertising test is failing
This problem occurs when an administrator removes a domain controller machine account using
fails to remove the objects from the Configuration partition
and then promotes a new DC with the same name into a different site.
Apparently an RODC account was pre-created in the wrong Active Directory site using the
Pre-created Read-only Domain Controller account...
. The Active Directory Promotion Wizard prompts the administrator to type the hostname and select the Site where the prospective DC will reside. The wizard uses this information to create the computer account and its corresponding NTDS Settings object. At some point, the unoccupied RODC machine account was deleted from the Domain Controllers OU using
but its corresponding NTDS Settings object was left in the Configuration partition. Eventually the server was promoted as a DC into the correct site and successfully promoted to be a GC.
It’s important to note that this condition isn’t specific to RODCs. The same issue occurs if a writable DC is removed from metadata in the same way and a server with the same name is later promoted into a different site.
All NTDS Settings objects have a parent server object named after the DC. This parent server object contains a
attribute that is populated with the fully qualified domain name of the DC. In this case the identically named stale and valid NTDS Settings objects in different sites have a dNSHostName attribute with the same FQDN.
The DCDIAG Advertising test searches the CN=Sites,CN=Configuration,
container for a Server object whose
attribute matches the fully qualified computer name of the DC being targeted. Once it finds the object with the matching
it retrieves the
of the subordinate NTDS Settings object and attempts to contact the target domain controller by its fully qualified CNAME which would normally be registered under the DNS zone “_msdcs.
If DCDIAG discovers a Server object whose
attribute matches the targeted DC but the
on the subordinate NTDS Settings object wasn't created by the last DCPROMO promotion or machine account pre-creation, then the LDAP bind to the targeted DC will fail with LDAP error 81. To get a better understanding of what this error means, download
and pass it the error code and you find it translates to "LDAP_SERVER_DOWN".
Identify Valid and Invalid NTDS Settings objects and clean up
1. Determine the
DSA object GUID
name that the DC is currently registering in DNS as a CNAME record by running this command:
C:>repadmin /showreps <name of dc> |more
<AD Site Name>RODC01
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 52399da1-87ba-4da6-bce3-71dcf0d85f34
DSA invocationID: 18bce5ac-d9f4-46dc-bccf-f3e39da103f9
2. Use the
command below to locate the Site that the invalid NTDS Settings object is in: