DCDIAG Advertising test with error 81
David Everett here again with an interesting issue that causes the Advertising test in DCdiag.exe to fail when verifying the role of a global catalog (GC).
A customer called Microsoft Product Support to determine why the Advertising test in dcdiag.exe 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. DCDiag.exe 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
<..snip..>
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:
isGlobalCatalogReady: TRUE;
isSynchronized: TRUE;
Another useful test to verify the DC is advertising as a GC is to use the /GC parameter in nltest.exe and observe that GC is listed in the Flags:
nltest /dsgetdc:contoso /force /gc
DC: \RODC01
Address: \11.11.11.25
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:
repadmin.exe /showattr RODC01 “DC=child,DC=contoso,DC=com” /subtree /filter:“(&(objectClass=user)(name=Administrator))” /atts:name /gc
DN: CN=Administrator,CN=users,DC=child,DC=contoso,DC=com
1> name: Administrator
Understanding why LDAP search in the Advertising test is failing
This problem occurs when an administrator removes a domain controller machine account using adsiedit.msc but 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... option in DSA.MSC. 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 adsiedit.msc 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 dNSHostName 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,DC=Contoso,DC=Com container for a Server object whose dNSHostName attribute matches the fully qualified computer name of the DC being targeted. Once it finds the object with the matching dNSHostname it retrieves the objectGUID 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.contoso.com”.
If DCDIAG discovers a Server object whose dNSHostName attribute matches the targeted DC but the ObjectGUID 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 Err.exe 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 and Site 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 repadmin.exe command below to locate the Site that the invalid NTDS Settings object is in:
C:>repadmin.exe /showattr RODC01 “CN=Sites,CN=Configuration,DC=contoso,DC=com” /subtree /filter:“(&(objectClass=server)(name=RODC01))” /atts:name
DN: CN=RODC01,CN=Servers,CN=SITE-A,CN=Sites,DC=Configuration,DC=contoso,DC=com
1> name: RODC01
DN: CN=RODC01,CN=Servers,CN=SITE-Z,CN=Sites,DC=Configuration,DC=contoso,DC=com
1> name: RODC01
3. Verify the wrong server object in the undesirable site is causing the failure:
a. Open adsiedit.msc and view the Properties of the invalid Server object.
b. Select the Attribute Editor tab and Edit the dNSHostName attribute.
c. Click Clear, OK and Apply to remove the FQDN of the RODC from the invalid object.
d. Once AD replication of this change makes it to the RODC run:
dcdiag /test:advertising /v /s:RODC01
e. Verify the DC is now advertising as a GC.
4. Now that DCdiag is free of errors delete the invalid server object using the preferred method of metadata cleanup.
a. Right-click the NTDS Settings object of the invalid RODC in Active Directory Sites and Services and select Delete
b. Click Yes at the Active Directory Domain Services prompt to delete the NTDS Settings object
c. Uncheck all three boxes in the Deleting Domain Controller window and click Delete
d. Once the subordinate NTDS Settings object has been removed, delete the invalid server object that is just superior to the NTDS Settings object that was just deleted.
NOTE: Because the serverReference attribute is NULL on the invalid NTDS Settings object the corresponding DC object in the domain partition will not be removed.
One way to ensure you never encounter this issue with dcdiag.exe is to start using this last step to remove a domain controller from the metadata instead of adsiedit.msc.
David “Mad Men” Everett