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 2003 to Exchange 2010. If that organisation does not have any Exchange 2007 servers, you need to evaluate if there may be a future requirement for one in the future. Examples include:
Once that first Exchange 2010 server is installed it is way to late to go back and introduce Exchange 2007. Actually its before the installation, but hold that thought for now. The same is also true when upgrading from Exchange 2007 to Exchange 2013, if there are no Exchange 2010 servers in the organisation.
Let’s look at an example where we are upgrading from Exchange 2007 to Exchange 2013.
As mentioned above, it is not the act of installing the files onto the disk of the new Exchange 2013 server that blocks the installation of Exchange. Nor is it the act of extending the schema to support Exchange 20103. To be specific it is the /PrepareAD stage that is the critical point. This means once you’ve run Exchange 2013’s /PrepareAD command you cannot introduce a 2010 role if it did not exist before 2013’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 2007, Exchange 2010 and also Exchange 2013:
/PrepareAD prepares the local domain for Exchange.
Exchange 2013 does not have the /PrepareLegacy or /PL switch. This was required for legacy Exchange 2003 coexistence so the Recipient Update Service (RUS) could continue to function. Since Exchange 2013 has a hard requirement that Exchange 2003 has been removed from the organisation prior to starting its setup, this is no longer required. Thankfully that also means I don’t have to describe the public and private property sets in AD!
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 highly trusted administrator. Grant and revoke schema admin membership as needed. Less is more!
Running Exchange 2013 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:
To enhance search engine effectiveness, the above text is also pasted here:
Error:This computer requires the Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit. Please install the software from http://go.microsoft.com/fwlink/?LinkId=260990.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.UcmaRedistMsi.aspx
Warning:Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE12ServerWarning.aspx
Warning:Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareAD'. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.NoE14ServerWarning.aspx
Warning:This computer requires the Microsoft Office 2010 Filter Packs - Version 2.0. Please install the software from http://go.microsoft.com/fwlink/?LinkID=191548.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.MSFilterPackV2NotInstalled.aspx
Warning:This computer requires the Microsoft Office 2010 Filter Packs - Version 2.0 - Service Pack 1. Please install the software from http://go.microsoft.com/fwlink/?LinkId=262358.For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.MSFilterPackV2SP1NotInstalled.aspx
Stop! Hammer time!
What if I want to retain the ability to install an older version of Exchange, what do I need to do?
Taking the previous example where we are upgrading from Exchange 2007 to Exchange 2013, and there are no Exchange 2010 servers in the organisation, what do we have to do to retain the ability to add more Exchange 2010 servers at a future date?
The simplest solution is to deploy a virtual machine, install Exchange 2010 with all of the roles (yes that is required if you want to be able to install all 2010 roles in the future), and keep it patched and running. Should you ever need to install a production Exchange 2010 server, since there is still one Exchange 2010 in the organisation you are able to do so. Note this did say all the roles that you want in the future. Installing just the Exchange 2010 Mailbox role is not sufficient…
Should you reach the point where there are no business requirements for Exchange 2010, 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 were unable to go back and add it later.
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.
Point of no return - unless you have a AD back and restore at some point in time. Obviously not want to do on production but the @Exchange labs. Correct me if am wrong, having said that I didn't tested but just thought of mentioning it.
Hi Charles, That could be possible but it would be so painful that it would probably not happen in production. I'm wincing thinking about it! Another alternative would be to do a cross forest migration to a net new AD that has the relevant version, but
that would be a lot of time, effort and money to do so... Cheers, Rhoderick