That Exchange 2010 and Active Directory share a very close relationship shouldn’t really comes as a surprise to you by now. The Active Directory Topology service, which is present on all Exchange servers, is responsible for discovering the Active Directory topology which contains (amongst other things) information about the Active Directory sites and services. Information that is discovered is immediately re-used within Exchange. For example, based on the Active Directory information, Exchange knows what servers reside in what Active Directory site and can therefore make certain routing and/or proxying decisions which are usually site-dependent. Whenever an Exchange Server 2010 starts, it will automatically bind to a random Domain Controller and Global Catalog within the same site.

It is, however, possible to configure an Exchange server to use static Domain Controllers or Global Catalogs using the Set-ExchangeServer cmdlet. Doing so will force the Exchange server to “bind” to particular Domain Controllers / Global Catalogs instead of binding to a random DC/GC.

To configure a static Global Catalog, you would use the following cmdlet:

Set-ExchangeServer –Identity <servername> –StaticGlobalCatalogs <FQDN_of_GC>

Now, imagine the following: You’ve configured a static Global Catalog, but – for whatever reason – it becomes unavailable for an extended period of time (or worse: someone decided to decommission the server without telling you (happens all the time!)). This would cause the Exchange Server to try binding to a non-existing DC/GC, resulting in the following errors:

Note   EventID 2080 could also be caused by numerous other problems.

If you have configured only a single static Global Catalog, Exchange will not try binding to another – available – Domain Controller. It would just “fail” binding to the configured one. Because the MS Exchange Active Directory Topology service would fail, other services will not be able to start either. Because of that, you will for example not be able to run the Exchange Management Shell while logged in onto the Exchange Server:

or

Even worse, logging into another Exchange server and using the Set-ExchangeServer cmdlet to reset the static configuration will not work either since the failing Exchange Server cannot contact AD, it does not know of any changes…

From what I found out, at that point you’ve got two options:

1. Reinstate the failed/removed Domain Controller/Global Catalog so that Exchange will be able to bind to it again  and remove the static configuration using Set-ExchangeServer cmdlet.

2. Exchange stores the static configuration in the server’s local registry at the following location:

HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\UserGC1

Remove the key and either reboot the Exchange Server or restart the MSExchange Active Directory Topology service.

After you did either of both, open the Exchange Management Shell. This time, the connection should succeed. If you run the Get-ExchangeServer cmdlet, you will see that the static configuration disappeared:

Get-ExchangeServer <servername> | Format-Table Name,*Static*

Conclusion

In the logic that you probably configured a static domain controller for a reason, I can understand why Exchange does not try binding to another Domain Controller. Nonetheless, in a situation where any statically configured DC (or multiple DCs) are not available, I’d rather have Exchange connect to a “random” other DC/GC than to notice that services fail. So, as you can see: configuring a static domain controller potentially creates a lot of issues... Why taking that risk? Exchange does a pretty good job at the Active Directory related stuff. In my opinion you should let it do what it’s best at and save yourself some troubleshooting down along the road. If you still have to configure static domain controllers, make sure they are not becoming the single point of failure for your messaging environment.

Until next time,

Cheers!

Michael