Share via

GlobalCatalog not being Recognized as a Global Catalog by Exchange

  • Article

A few days ago one of my colleagues had managed to reproduce an issue our customer was seeing and wanted me to take a look.
We connected to an Exchange lab running Exchange 2013 where my colleague showed me the following:

We ran:

 Get-ExchangeServer -Identity $env:COMPUTERNAME -Status | fl *CURR*,*STAT*

StaticDomainControllers         : {}

StaticGlobalCatalogs            : {SiteXE15DC.contoso.local}

StaticConfigDomainController    : SiteXE15DC.contoso.local

StaticExcludedDomainControllers : {}

CurrentDomainControllers        : {SiteXE15DC.contoso.local, SiteBDC.contoso.local}

CurrentGlobalCatalogs           : {CentralDC.contoso.local}

CurrentConfigDomainController   : SiteXE15DC.contoso.local

Can you spot the problem?

That's interesting, the StaticGlobalCatalogs were set to a specific server, but the CurrentGlobalCatalogs is a different server!

First thing I did was to make sure the registry data is correct. A quick check with process monitor showed me the following:

 

15:57:32.7497060 Microsoft.Exchange.Directory.TopologyService.exe 15672 RegQueryValue HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\UserGC1\HostName SUCCESS Type: REG_SZ, Length: 42, Data: SiteXE15DC.gtk.local
15:57:32.7497126 Microsoft.Exchange.Directory.TopologyService.exe 15672 RegQueryValue HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\UserGC1\HostName SUCCESS Type: REG_SZ, Length: 42, Data: SiteXE15DC.gtk.local
15:57:32.7497192 Microsoft.Exchange.Directory.TopologyService.exe 15672 RegQueryValue HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\UserGC1\IsGC SUCCESS Type: REG_DWORD, Length: 4, Data: 1
15:57:32.7497250 Microsoft.Exchange.Directory.TopologyService.exe 15672 RegQueryValue HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\UserGC1\IsGC SUCCESS Type: REG_DWORD, Length: 4, Data: 1

So, the server is clearly being read correctly from the registry.

 

Next I took a look at the 2080 event and saw the following:

 CentralDC.gtk.local CDG 1 7 7 1 0 1 1 7 1,
SiteXE15DC.gtk.local CD- 1 6 7 1 0 1 1 7 1,
SiteBDC.gtk.local CD- 1 6 7 1 0 1 1 7 1

The important part here is the CD* notation.
This article gives a pretty good explanation on how to read this.

Roles: The second column shows whether or not the particular server can be used as a configuration domain controller (column value C), a domain controller (column value D), or a global catalog server (column value G) for this particular Exchange server. A letter in this column means that the server can be used for the designated function, and a hyphen (-) means that the server cannot be used for that function. In the example that is described earlier in this article, the Roles column contains the value CDG to show that the service can use the server for all three functions.

That explains the reason the Statically set global catalog wasn't being treated as one, both SiteXE15DC and SiteBDC weren't GlobalCatalogs.

But... I'm sure all 3 of these servers are Global Catalogs! I confirmed that looking at the NTDS data too.

When the MSExchangeADTopologyService starts or when an event 2080 is recorded we reevaluate the ability of servers in our environment to be used for Configuration/DC or GlobalCatalog.

All I had to do is put a breakpoint into the code where we do the TopologyDiscovery and see exactly how this gets evaluated.
The first thing we do to see if a server is evaluated as a GC or not, is look at the NTDS Options.
These are stored at:
CN=NTDS Settings,CN=,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=...

I printed out the value we were getting during loading the servers and found the following:

 
"CentralDC.gtk.local" IsGC
"SiteBDC.gtk.local" 9
"SiteXE15DC.gtk.local" 9

9? That means the 1st bit for GC is turned on and then the bit for 8 is turned on.
I thought we might be querying AD in a weird way, so I just queried it with PowerShell:

 
Get-ADObject -LdapFilter "(&(hasMasterNCs=*)(!(msExchCU=*))(|(objectCategory=ntdsDsa)(objectCategory=ntdsDsaRo)))" -Server $env:COMPUTERNAME -SearchBase "CN=Sites,CN=Configuration,DC=gtk,DC=local" -Properties Options | fl Distinguishedname,Name,options


Distinguishedname : CN=NTDS Settings,CN=CENTRALDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gt
                    k,DC=local
Name              : NTDS Settings
options           : 1

Distinguishedname : CN=NTDS Settings,CN=SITEBDC,CN=Servers,CN=SiteB,CN=Sites,CN=Configuration,DC=gtk,DC=local
Name              : NTDS Settings
options           : 9

Distinguishedname : CN=NTDS Settings,CN=SITEXE15DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=g
                    tk,DC=local
Name              : NTDS Settings
options           : 9

The reason it was set to 9 was because someone ran the following commands:

 
Repadmin /options  +disable_ntdsconn_xlate
Repadmin /add    [/readonly] [/selsecrets]

Excellent explanation about this value and when to use it here.

Like explained in the article above, this is not a value which is usually used for a lengthy period of time in a production environment.
We changed this back to 1 on our affected servers and our next event 2080 was back to normal.

Lessons Learned:

For a Domain Controller to be recognized as a GlobalCatalog from an Exchange perspective the options property for the NTDS Settings must be set to 1.
Any other value other than 1 will cause the server to not be detected as a GlobalCatalog.
If you look at what the other Options values do - stop inbound replication, stop outbound replication - you'll probably come to the conclusion that you don't want to use that server as a GlobalCatalog either.

That's it!