Many enterprises are moving forward with their digital transformation plans, and as part of this and server updates Domain Controllers are being updated to newer versions. The Windows Server 2008 and Windows Server 2008 R2 end of support in January 2020 is also a business driver.
DC upgrades can happen independently of the Exchange team. In many cases the Exchange admins are not notified of the planned changes to AD until they notice an issue. Effective change management processes would ensure that all the relevant teams are notified of related changes. In such an environment, Exchange should not be surprised by changes to the directory servers.
Note that this post uses Exchange 2010 based screen shots but little has changed in this process since Exchange 2003 SP2.
If the Exchange admins proactively monitor for DC usage, they can see this is a couple of places.
For example, running Get-ExchangeServer –Status <ExchangeServername> would show the current list of DCs.
Get-ExchangeServer –Status | FL Name, *controller*
Monitoring the application event log on Exchange would also show the MSExchange ADAccess EventID 2080 which lists the in-site and out-of-site DCs Exchange has detected and tested.
DCs Gone Bad
If everything went well, then life would not be so interesting. What would happen if I said that the previous screenshot was not complete? Only two DCs are listed. Why are none of the Exchange servers using the new Windows Server 2016 DC that was recently installed? Exchange us using the older DCs in the forest. All of these DCs are in the same AD site.
If we look at the aforementioned MSExchange ADAccess EventID 2080 we can see more information. Note that the DCs are listed along with the characteristics of each of the servers. This is represented in the string:
Tail-CA-DC-2-Tailspintoys.ca CDG 177101171
Note that the newest DC, the 2016 server, has a different set of numeric values. The Netlogon attribute is set to zero, whereas the original servers have Netlogon set to 1.
What has Exchange done to cause this?
Exchange the Canary
The short answer is nothing. Exchange in this case is merely noting that there is an issue with AD. It has done this very well over the last couple of decades and mimics the role of a canary in a coalmine. Was AD replicating to the new DC? The AD Replication Status Monitor was used to ensure AD was replicating. It was found to be replicating and up to date.
Did the Netlogon share actually exist on the 2016 DC?
Checking for a Netlogon shared folder on the 2016 DC was a fruitless search. The Netlogon share was not present. There were also multiple issues in the AD event logs due to pre-existing DFSR issues.
KB 2218556 was used to resolve this particular issue. Note that this was an environment with multiple DCs and the PDC emulator was found to have the correct and latest information. If you are not 100% familiar with these steps or the risk associated, please open up a support ticket to obtain assistance.
Please note that since this was a Windows Server 2016 DC, it was necessary to perform the steps in Install dfsrdiag on Windows 2012 R2 and Windows 2016 to install the required tools.
Exchange the Happy Canary
Now that the underlying issue with AD was corrected, how does Exchange perceive the 2016 DC? Is it happy?
As you can see below in the EventID 2080, the Netlogon flag is now set to a 7 which is the same as the other DCs.
If we also look at the domain controllers detected by Exchange, we can see that the new DC is now included in the list. There are three domain controllers in total, this matches the number of DCs present. If you recall, these initial results only showed two DCs.
Get-ExchangeServer –Status | FL Name, *controller*
Cheers,
Rhoderick
