When designing an upgrade strategy from an older version of Exchange to a newer one, a question that needs to be addressed is do we need to introduce a version of Exchange that may not currently be present? This may be when upgrading from Exchange 2013 to Exchange 2019. If that organisation currently does not have any Exchange 2016 servers, you need to evaluate if there may be a future requirement for one in the future. Examples include:
Application specific requirements
Client versions in use
Backup/Restore software requirements (though can be met with a separate recovery forest)
Once that first Exchange 2019 server is installed it is way to late to go back and introduce Exchange 2016. Actually its before the installation, but hold that thought for now. The same is also true when upgrading from Exchange 2010 to Exchange 2016, if there are no Exchange 2013 servers in the organisation.
The Point Of No Return
As mentioned above, it is not the act of installing the files onto the disk of the new Exchange 2019 server that blocks the installation of Exchange. Nor is it the act of extending the schema to support Exchange 2019. To be specific it is the /PrepareAD stage that is the critical point. This means once you’ve run Exchange 2019’s /PrepareAD command you cannot introduce a 2016 role if it did not exist before 2019’s /PrepareAD was executed.
The individual steps to manually prepare the AD infrastructure for Exchange are listed in the Prepare Active Directory and Domains documentation for Exchange 2013, Exchange 2016 and also Exchange 2019.
setup.exe /PrepareDomain or setup /PrepareAllDomains
/PrepareAD prepares the local domain for Exchange.
Also note that the setup command line options changed with Exchange 2019 CU11.
NOTE: If you run the Exchange Setup wizard with an account that has the permissions required (Schema Admins, Domain Admins, and Enterprise Admins) to prepare Active Directory and the domain, the wizard will automatically prepare Active Directory and the domain.
You say this would never happen? Let me give you the following scenario. Assume you get a shiny new administrator workstation that has the latest version of Windows installed. In order to install the Exchange management tools you need to install the management tools from the latest build of Exchange. If you then logon with a domain admin/schema admin level of account to install the management tools, setup will check the AD versioning information and run the /PrepareSchema, /PrepareAD steps.
Morale of the story? You should not need schema admin permissions for your day to day role, even for a highly trusted administrator. Grant and revoke schema admin membership as needed. Less is more!
Running Exchange 2019 setup checks the current status of Active Directory and the Exchange organisation. Besides warning that some infrastructure bits are missing, it does warn that if you continue with this course of action, you will be unable to introduce older versions of Exchange if they are not currently present. In the below example, this is a fresh AD 2016 forest with no existing Exchange organisation. Since no organization currently exists, the name of the new organization must be specified:
setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD /OrganizationName:Wingtiptoys
For the Search Engines:
Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis 100%
Setup will prepare the organization for Exchange Server 2019 by using 'Setup /PrepareAD'. No Exchange Server 2016 roles have been detected in this topology. After this operation, you will not be able to install any Exchange Server 2016 roles.
Stop! Hammer time!
What if I want to retain the ability to install an older version of Exchange, what do I need to do?
Retain Ability To Install Down Level Exchange Version
Taking the example where we are upgrading from Exchange 2013 to Exchange 2019, and there are no Exchange 2016 servers in the organisation, what do we have to do to retain the ability to add Exchange 2016 servers at a future date?
The simplest solution is to properly deploy a virtual machine, install Exchange 2016, configure it and keep it patched and running. Should you ever need to install a production Exchange 2016 server, since there is still an existing Exchange 2016 mailbox server in the organisation you are able to do so.
Should you reach the point where there are no business requirements for Exchange 2016, Exchange can then be gracefully uninstalled from the virtual machine and life continues.
The same rules applied when upgrading Exchange 2003 to Exchange 2010 where there are no Exchange 2007 servers in that organisation. If an Exchange 2007 server was not introduced prior to Exchange 2010, then you are unable to go back and add it later. Same also for Exchange 2010 to Exchange 2016.