Make sure you have correct domain controllers for your Exchange version

Active Directory plays a big role in how Microsoft Exchange functions. Active Directory and Exchange work very closely with each other and if the domain controller becomes unavailable, Exchange will stop working because of its dependencies. In smaller environments this can lead to issues when only one domain controller has been set up — when any maintenance happens, it basically makes Exchange unavailable during the maintenance.

I advise having two or more domain controllers. If your environment is virtualized, it might be better to have one physical domain controller and the other one virtualized. It can happen that the domain controller that is virtualized does not want to start because of resources or another problem, but at least you will have a physical server to handle the login requests as well as servicing Exchange or if the physical machine does not want to start, you have the virtual machine to handle requests and Exchange.

Sometimes, new Exchange is not better

exchange domain controllers

As Microsoft releases new versions of its operating systems, it is very tempting for an IT admin to have the latest and greatest installed, but they don’t realize that Exchange (your version) will only work with what is supported. Before we jump into what is and isn’t supported, it is recommended that you refer to Microsoft’s documentation of which Active Directory servers will work with your version. In this case, the version is Exchange 2016 RU11 or Exchange 2010 SP3 RU23. I am just using these examples.

Let’s say you have an Exchange 2016 environment on RU11. If you head over to the documentation, you will notice that Active Directory 2019 servers are not supported because you need to be on rollup 12 and higher to support them. If you do go and introduce new domain controllers, you might end up with Exchange services stopping or not servicing requests or losing access to Exchange. I have seen some strange events in my lab as I test these kinds of things.


The results can be unspeakable. I had my Exchange server rebooting, blue-screening, and refusing to do things in Exchange. Please note this is a test lab. I had to rebuild my lab. In a live environment, it won’t be possible to just rebuild a solution because of data loss and downtime for the company.

As an admin, you need to take care and read carefully what is recommended by Microsoft as they know better and you shouldn’t have to go through the pain of trying to recover an environment. To dive into this deeper, there are a few things that you need to look at first:

  • Forest and domain functional level.
  • Which legacy domain controllers you have.
  • Preparing Exchange for new domain controllers.

Before you can introduce your new domain controller, the first thing to ensure is that you bring up new domain controllers to replace the legacy domain controllers. For example, if you have 2003 domain controllers or 2008/R2 domain controllers, you need to introduce 2012/R2 and move the FSMO roles. Then you can decommission the legacy ones. Once you decommission them, this leads to point No. 1 above: You will then be able to upgrade your forest and functional levels.

Now don’t go and rush into this. Once you move the FSMO roles, wait for replication. Depending on the size of your environment, it can take a while for the changes to be reflected.

One domain controller at a time


I normally leave it a day and then commence with the demoting of the legacy domain controllers. Again, I do this one domain controller at a time so that objects are cleaned up properly and the server can be removed cleanly. You don’t want to have to do a metadata cleanup if you don’t have to. Patience is key here when dealing with Exchange and also with Active Directory.

Now that you have decommissioned all your legacy servers and upgraded your forest and functional levels, it is now time to look at Exchange.

If you are running Exchange 2010 SP3, to be able to have Windows Server 2016 domain controllers, you need to be on a minimum of RU22 or higher in your environment. If you are on lower versions, you will need to first upgrade all Exchange servers to the latest rollup (RU) to have the 2016 domain controllers work in your environment. Sadly, Exchange 2010 SP3 won’t work with 2019 domain controllers as per the support matrix that Microsoft releases.

If you are running Exchange 2013, you will also only be able to go up to Windows 2016 domain controllers. If you are running Exchange 2016 — and this was only recently changed — you need to be running Exchange 2016 CU12 or later to be able to have 2019 domain controllers in your environment.

Lastly, if you are running Exchange 2019 then it won’t be an issue as 2019 domain controllers are supported. Take note here, however, you have to have a minimum of Windows Server 2012 R2 Active Directory servers as Exchange 2019 does not support pre-server 2012 R2. As you can see, there is a lot that is not supported. This is because Exchange 2010 will be retired in October 2020 and Exchange 2013 will probably be retired a few years after that.

If you adhere to the matrix and support from Microsoft, you shouldn’t have any issues.

Keep your bosses informed

A last note: Always prepare your change controls and inform your change advisory board or whatever oversight setup you have in your organization about what you plan on doing. You might have legacy applications that won’t work with a newer forest or domain functional level.

Featured image: Shutterstock

About The Author

13 thoughts on “Make sure you have correct domain controllers for your Exchange version”

  1. Hi, I have 2 domain controllers in my topology if the primary goes down exchange 2013 automatically not sync with 2nd what I have to do without a restart.

  2. Edward van Biljon

    Are they 2012, 2012 R2, 2016 or 2019 dc’s?
    Are they both global catalogs? Is DNS on the exchange server pointing to both?
    Did you set specific domain controllers in exchange or not?

  3. Hello Guys

    We are going to upgrade on our Domain Controllers OS 2008 R2 to 2012 R2
    Will it impact Exchange 2010 services and also we have exchange server 2010 to Office 365 connectors will they impact.
    We have few services like LDAP for authentication for Oracle EBS and Linux services.
    Please advise

  4. Edward van Biljon

    Hi Murali, Exchange 2010 SP3 RU5 and above support 2012 R2 domain controllers, nothing wrong with bringing up new servers, transferring the FSMO roles and then decommissioning the 2008 R2 domain controllers.

    You will also need to check with your vendor Oracle if they okay with the newer domain controllers.

  5. Hi Edward
    I am upgrading Exchange from 2013 to 2019 but I have a problem:

    Exchange 2013 is still available in the windows server 2019 environment active directory even though it says it doesn’t support it?why

    1. hi Edward
      I installed CU23,but says it doesn’t support Exchange 2013 sp1 and laster,So should I continue to install it or not and if I install it, will my system be affected or may die?pls
      thanks you!

  6. If you referring to active directory, yes Server 2019 domain controllers are not supported in this case. only Exchange 2016 CU12 and higher support windows server 2019 domain controllres.

  7. Impact of ADMT 3.2
    Hi everyone, i have some important questions for my customer case. Here is it
    In AD i have 1 forest/ 3 child domain. User is in 3 child domain. We use hybrid AD with password hash sync. AD connect is synchronization user in 3 child domain depent OU. Hybrid Exchange but all user have all mailbox in Exchange online. We plan to move all user in 3 child domain to root domain use ADMT 3.2
    – Question 1. I think when i migrate user from child to root. I know when migrate user between domain, there are many attribute is exclude by ADMT 3.2. But i think if i can migrate two important attribute is UPN and SourchAnchor. There is no impact to AD connect, to Azure AD, and to Office 365. Am I right? Can anyone have experience about this? Are there more important attribute?
    – Question 2. One more two important attribute is Mail and ProxyAddresses can be migrate when migrate user. But attribute legacyExchangeDN is exclude by ADMT 3.2. So if legacyExchangeDN is lost, user cannot receive mail, so user AD connect don't see that attribute to synchronization, user in Exchange online cannot receive mail. If i export before migrate and import legacyExchangeDN after migrate. It's OK, but cannot do that with thousand users. My question is are there any attribute have to migrate for NO IMPACT to Hybrid Exchange. And anyone have solution for migrate attribute legacyexchangedn?

  8. Hi all,

    I have installed Exchange Server 2016 and Active Directory on different servers. I have configured both and working perfect.

    Issue is , i recently installed additional Domain controller as Secondary Domain controller .
    If any issue happen to my primary , secondary will be used .

    After installing secondary domain controller , it replicate to both DC and show all new created users, GP. But my exchange server stop working .

    After turn off Secondary DC , exchange server work perfect. i have checked all configuration , and found no issue in configuration. I also check Exchange server configuration , with my knowledge i found no issue.

    Need your help to sort out this issue. I tried it 2 times ,but still the same.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top