J003-Content-Windows-2003_SQ-Updated2Why Exchange Admins Should Care!

Just in case you missed it, Windows 2003 goes EOL (End of Life) on the 14th of July 2015. While by now I trust that none of the Exchange admins reading this post are still running Exchange 2003, which went EOL last year, odds are that there are still plenty of domain controllers still running Windows 2003. At this point your Active Directory admins are working diligently to deprecate them and replace them with 2008 R2 (or later) DCs.

AD admins replace domain controllers all the time. As long as they don’t alter Active Directory site topology, or reduce/remove the availability of Global Catalog servers, Exchange shouldn’t be affected by this at all. Neither the AD admins, nor you, probably need to worry too much about talking to one another about pending changes. Exchange depends upon AD, but does not rule AD, and things usually remain happy. However, once the AD team removes the last 2003 DC, they may do something that could wind up causing you to have a very bad day. That is why you should care.

Active Directory domains have a domain functional level, and forests have a forest functional level, and these are generally constrained by the lowest revision domain controller in the domain, or the lowest revision domain in the forest. Any domain that has a 2003 DC is stuck at domain functional level 2003, and any forest that has a domain stuck at 2003 DFL is stuck at 2003 forest functional level. Once the last 2003 DC is gone, the AD admins will likely bump the DFL up.

There are many advantages to raising the DFL which will appeal to AD admins. Simply going from 2003 to 2008 gives domain admins the following:

  • Distributed File System (DFS) replication support for the Windows Server 2003 System Volume (SYSVOL),
  • Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability,
  • Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol,*
  • Last Interactive Logon Information,
  • Fine-grained password policies,
  • Personal Virtual Desktops.

If they go to 2008 R2, then admin can also get:

  • Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token, and
  • Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes.

If they make the jump to 2012, AD admins can really tighten up Kerberos security with:

  • The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level.

Finally, making the jump to 2012 R2 brings with it:

  • DC-side protections for Protected Users, which disables legacy authentication protocols for specific privileged or other high-value accounts,
  • Authentication Policies, and
  • Authentication Policy Silos.

The above is condensed from https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx.

When they make the switch, a key thing happens that could affect Exchange. To enable the new AES encryption protocols available in Kerberos, the KRBTGT account password is changed. This account password change can cause authentication problems for Exchange – as well as other third party applications. If this happens, you will need to know how to recognize the symptoms and how to resolve them.

Once the DFL is raised, AD admins should monitor their domain controllers’ system event logs for Event 10 and Event 14. If these start to appear, admins will need to restart the Key Distribution Service (KDC) on all domain controllers. Using PowerShell, this is fairly easy to do regardless of the number of DCs.

A domain admin should open an administrative PowerShell prompt and run the following from a domain controller or a workstation with the AD PowerShell module already imported.

$DC=Get-ADDomainController

Get-Service KDC –ComputerName $DC | Restart-Service

A quick restart of the KDC on all of the domain controllers will resolve this and enable Exchange to function without further impact. This is just a service restart, so you don’t even have to deal with reboots.

Work with your AD team now so that they are aware of the need to coordinate any raising of the DFL with you, and to be prepared to resolve authentication issues in case they do occur.

 *This is the big one for Exchange Admins!