It seems that the organizations who are still using on-premises Exchange fall into a couple of categories; ones where there is too much legacy infrastructure in place and ones where perceived regulatory constraints have prevented the move.

Here we want to take a look at organizations that really want to make the move but aren’t sure about the path forward. We here at Verinext have recently done several migrations that fall under this category and each one presented a challenge in terms of the order of operations before the implementation of the Hybrid Exchange portion could be successfully completed.

Active Directory

It’s not just Exchange that is in play in this game of cards. Sometimes IT can be tempted to take the easy steps to bring themselves up to a supported AD level so that other applications, or at least the security features contained within it, can take advantage. That has historically been an issue because Exchange 2010 SP3 (RU5 to RU21), and there is far more of that out there than you might imagine, cannot properly coexist in an AD environment beyond Windows Server 2012 R2.

To get an Exchange 2010 environment into a position where it can coexist with Windows Server 2016 an upgrade to Exchange 2010 SP3 RU22 needs to be done. Conducting upgrades of Exchange servers that are several years out of support appeals to absolutely nobody.

In essence, if you’re running Exchange 2010 you really ought to hope that the Active Directory is firmly at the 2016 level and that the Exchange server is fully patched.

For those environments on Exchange 2013 there is a simple path which is to get to Exchange 2013 CU23. That lets you introduce higher Active Directory and Exchange Server versions with far less fuss.

Looking at Exchange 2016 and beyond the picture becomes easier. As long as the Active Directory is at the 2016 level you can take the Exchange straight through to 2019.

To get a full breakdown of every nuance of the situation take a look at: Exchange Server supportability matrix | Microsoft Learn.

Legacy Exchange

Keeping all of the moving parts straight with the Active Directory infrastructure is one thing but what about Exchange Server itself? Consideration must be given to how the upgrade is approached, particularly with respect to public folders.

Public Folders

Simply put, moving to Exchange Online means that it’s time to get rid of public folders. It’s not a requirement, except that really, it is. They’ve had their day. Do this before approaching the upgrade process to Exchange Online. The removal of public folders should be taken as a separate, preliminary, project. Recently Verinext encountered an environment where an Exchange 2007 server still existed in the environment because a legacy application was communicating with it, and the IT organization didn’t have all of the necessary tribal knowledge on hand to remove it without risk to other parts of the business.

Public folders are not inherently complicated because they were never gifted with rich functionality. Over time development-led organizations introduced workflow components and infrastructure-led organizations implemented shared calendars such as companywide holidays and events, early resource/room booking solutions, and much else besides. There is nothing in a legacy public folder structure that has not been replaced by a far more functional service within Exchange and SharePoint Online.

Move all of the calendaring components to Exchange resource and room mailboxes and educate the users on how things will be done going forwards. This will take some time so if you have a public folder infrastructure do not assume that you migration to Microsoft 365 will be done at quite the pace you first anticipate.

Once the public folder infrastructure has been replaced by other functionality then it is time to execute on your plan to migrate to Exchange Online.

Exchange Versions

Are you on Exchange 2010 still? That’s going to present the biggest challenge to you. Here’s what you need to know.

  • Highest operating system – Windows Server 2012 R2
  • Highest domain functional level – Windows 2012 R2 (to Exchange 2010 Roll Up (RU) 21) or Windows 2016 (for RU 22 & later)
  • Highest Exchange Server version that may be introduced – Exchange Server 2016

That configuration is perfectly fine for a migration to Exchange Online. The hybrid server can be the Exchange Server 2016 and the Exchange Server 2010 can be decommissioned when the task is complete. The 2016 server will be the one you configure to accept email from Exchange Online (or the Internet if you have yet to change the MX record), send email to act as the interface Exchange Online and generally between Microsoft 365 and On-premises Exchange.

Are you on Exchange 2013? You can introduce a Windows Server 2016 server for your Exchange 2016 hybrid server but you must install 2016 CU3 or later. That will give you a good springboard because here is where you can host Windows Server 2016 domain controllers and then, following the migration and decommissioning of the Exchange 2013 servers, upgrade the domain functional level to Windows server 2016.

Once you have got the mailboxes migrated to Exchange Online you can then plan on getting the Exchange 2016 phased out in favor of Exchange 2019 which is the route to get to the latest version of Windows Server and domain functional level.

If you choose, for the short term at any rate, to stay on Exchange Server 2016 you can make sure you are at Cumulative Update (CU) 23 which will permit Windows Server 2022 domain controllers.

When you are ready to put the current version of Exchange (2019 at the time of writing) into the environment you will make sure you start out at CU12 or later because CU11 and earlier is not supported with Windows Server 2022 domain controllers – CU11 tops out at Windows Server 2019 domain controllers.

Summary

As you have seen, it matters what version of Exchange you start with, what version of Windows is installed on the domain controllers, and also the domain functional levels. You can have a higher version of Windows, but you must be careful about what domain functional level is configured. Throughout the whole exercise, you will have decisions to make on the timing of the three upgrade processes. This guide should help in that journey when taken in conjunction with the Microsoft published article.

Learn more on how Verinext can assist you in your migration or contact us today.