Considering updating your Domain functional level from Windows 2003? Read this!


Now that Windows Server 2003 end of life (July 14th, 2015) is on the horizon, many customers are updating their Active Directory (AD) Domain Controllers (DC) from 2003. The first item to consider is which Windows Server Operating System (OS) you will be moving to for your DC’s. There are several options to consider today: 2008, 2008R2, 2012, or 2012R2 operating systems. However, no matter which newer OS you move your DC’s to, coming from 2003, the krbtgt account will reset its’ password when you update the Domain Functional Level (DFL), which is the concern that could break Exchange.

Note: If your DFL is already set to 2008 or higher, then you do not need to worry about this article.

It is a good idea to know that during the process of raising the Domain Functional Level (DFL) of your Active Directory structure from 2003, the krbtgt account password gets changed. This password replication is a separate change within AD and occurs after the DFL has been raised. This change should have no impact on any applications that depend on Active Directory, but sometimes it does cause applications to stop authenticating, one of them being Exchange.

Since raising functional levels is an irreversible operation (in many situations, but not always anymore), it should be planned with care and only after having verified that it will not impact any applications that rely heavily on Directory Services. Mostly any in-house written and/or third party products are the main concern. A lab environment for testing the applications would be the best option, which is why we recommend a lab for Exchange.

After you’ve made the DFL change from 2003, then you’ll want to watch for any Event ID 14 or Event ID 10 errors in the System Event Viewer on the DC’s.

If you do see these events appear after the DFL has been raised, then there are a couple of options available to resolve the authentication error.

Option 1: Restart the Kerberos Key Distribution Center service on all DC’s (short impact, service restart)

  • Command line option steps:
    • SC \\ComputerName Stop kdc
    • SC \\ComputerName Start kdc
  • Active Directory PowerShell module steps:
    • $DC=Get-ADDomainController
    • Get-Service KDC –ComputerName $DC | Restart-Service
  • GUI steps:
    • Open the Services mmc (services.msc) on the DC’s
    • Select the Kerberos Key Distribution Center service and click the restart button

image

Option 2: Restart all DC’s in the Forest (greatest impact, restarting of servers could take time)

  • Manually log into each DC and restart them all, OR
  • Within the Active Directory PowerShell module:
    • $DC=Get-ADDomainController
    • Restart-Computer $DC

Why is this important?

While there should be zero impact to applications, the fact that the krbtgt account password does get reset and it could impact the speed in which Exchange (or other applications) waits for that accounts’ password to be updated via the normal AD replication process. We are recommending that you know how to perform the given resolution steps and that you do this change during a change notification process.

Why does this happen only during the 2003 DFL change?

The underlying issue is due to the addition of the AES hashes (128 and 256) introduced. The changes only add the AES hashes during the one DFL change from 2003 to any higher level (’08, ‘08R2, ’12, ‘12R2) domain functional level. The potential to implement other newer/updated encryption types in future OS versions does exist and we once again could run into this issue. 

Knowing is half the battle. It is very unlikely that you’ll run into this issue, but now that you know how to solve it and be prepared IF you run into it, you now have easy and quick solutions at the ready. Plan your change, move up to the newer version OS/AD functional levels, enjoy the new features that are available today, and don’t let this change break Exchange.

Mike O'Neill

Comments (8)
  1. Many thanks Mike for sharing this great article.

    Cheers !

  2. Mike_O'Neill says:

    Any currently supported version could be impacted, since this is an AD issue that could prevent an Exchange server from authenticating. Thus any LDAP query could fail. And without proper answers from AD, Exchange would start to fail.

    Again, this is a very rare issue, but one that has not been well documented until now.

  3. Anonymous says:

    Thanks for this article, but which versions of Exchange are impacted ?

  4. Nick Barsotti says:

    Does a similar issue happen when raising the Forest Function Level? All of our Domains are 2008 or 2008 R2, but our Forest Functional Level is still 2003 and we about about to raise it to 2008 R2. Is this a concern?

  5. stan says:

    Hello,
    Thanks for this alert.
    What are precisely the impacts on Exchange ?
    Regards.

  6. MK says:

    Thanks Mike. When you run those PS commands to bounce all of your DC’s, does that happen in a staggered fashion or do all DC’s reboot simultaneously?

  7. joseph says:

    Interesting detail, but why is it rare? Is it just when authentication requests hit before AD had a chance to fully replicate?

  8. Garry Trinder says:

    After raising domain and forest functional levels from 2003 to Server 2008 R2 we started to get a few Event ID 15 on the domain controllers for a couple of service accounts. Restarted KDC service on all the domain controllers and still had a couple of
    Event ID 15’s come through. To be safe, we restarted all the domain controllers since we were in a maintenance window. No more Event ID 15’s yet, but still monitoring as it’s only been one hour so far. Appreciate this article and the comments posted too.

Comments are closed.

Skip to main content