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
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