Planning and migrating a small organization from Exchange 2007 to 2013 (Part 8)

If you would like to read the other parts in this article series please go to:


In the previous parts to this series we began our journey to migrate from Exchange 2007 to Exchange 2013, and completed the sizing of our new environment, finishing with getting the hardware ready to roll. We’ll now focus on getting ready to deploy Exchange by first ensuring issues within the current environment are corrected, and then install Exchange 2013 pre-requisites.

Pre-Deployment Remediation

While a bit of a mouthful, pre-deployment remediation could be explained better as “things we need to sort out before we install Exchange”. We’ll explain some of these below.

Exchange Server Patching

As we’ve mentioned before, you must patch Exchange 2007 to the very latest Service Pack and Update Rollup before you attempt to do anything with Exchange 2013.

Download and install these patches from here:

As with all patches, ensure you read the release notes before implementation.

Configuring the Offline Address Book setting on existing Mailbox Databases

If you’ve got any Mailbox Databases that look like the example shown below, you’ll need to make sure they’ve got the current default Offline Address Book for your organization hard configured against each database. This is because Exchange 2013 will install a new default Offline Address Book, forcing clients that don’t have this value configured to perform a full Offline Address Book download before we’re actually ready to introduce Exchange 2013 to clients.

Figure 1: Public Folder Database with no Offline Address Book specified

You can correct this against the individual database by selecting the default Offline Address Book by choosing Browse in the Client Settings tab in the window shown above.

As you might expect, the Exchange Management Shell is also a great tool to use to quickly correct this across all databases. You can use the following command to perform this change:

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $null} | Set-MailboxDatabase -OfflineAddressBook (Get-OfflineAddressBook | Where {$_.IsDefault -eq $True})

You’ll see this command in action below:

Figure 2: Automating configuring the Default Offline Address Book

Active Directory Forest and Domain Level Changes

If you haven’t already, you’ll need to raise the forest and domain functional levels of your Active Directory to a minimum of Windows 2003 for both.

Exchange 2007’s minimum forest and domain functional levels are just Windows 2000 – so it’s reasonable to expect you might need to raise this. Before you do so, make sure you ensure your Active Directory is in good health (for example by using dcdiag), backed up and any Windows 2000 Domain Controllers are gone and were correctly removed.

We can raise the Domain Functional Level by opening Active Directory Users and Computers and right clicking the domain, and choosing Raise Domain Functional Level:

Figure 3: Raising the Domain Functional Level

You’ll find the option to Raise Forest Functional Level over in Active Directory Domains and Trusts. The option is found by right-clicking the root node, as shown below:

Figure 4:
Raising the Forest Functional Level

Updating Outlook 2010 and 2007 Clients

In part three and part four of this series we looked at the methods available to identify existing clients, and if you haven’t updated clients now is the time to do so. AutoDiscover responses from Exchange 2013 contain new methods to support internal Outlook Anywhere, and these updates ensure support for this in addition to other fixes.

To recap, the update levels we’ll need to achieve are as follows:

  • Outlook 2010 Service Pack 1 with at least the November 2012 update (Build 14.0.6126.5000 or higher)
  • Outlook 2007 Service Pack 3 with at least the November 2012 update (Build 12.0.6665.5000 or higher)

Naturally if you can update clients to Outlook 2013, that’s even better as your users will be able to benefit from new features, such as Apps for OWA and Outlook 2013; otherwise use tools like Windows Server Update Services (as mentioned in part four of this series) to ensure clients meet minimum update levels or higher. With the recent release of Outlook 2010 Service Pack 2, there’s even more reason to get clients updated.

Removing unsupported clients

If your client discovery identified any clients that aren’t supported with Exchange 2013, then you’ll need to start replacing these now. Remember – Outlook 2003 and below aren’t supported so if you’re using this within your organization upgrade these clients to at least the above versions of Outlook before we start the upgrade.

Configuring Outlook Anywhere

If you’ve not enabled Outlook Anywhere already, you certainly will want to consider enabling it for Exchange 2007 at this point to smooth migration and coexistence.

If you’ve already enabled Outlook Anywhere and used Basic authentication then you’ll also need to make another change on Exchange 2007 Client Access Servers, within the IIS configuration. Exchange 2013 can accept Outlook Anywhere connections for Exchange 2007 mailboxes, but it will proxy connections to Outlook Anywhere running on the Exchange 2007 Client Access Servers. If Basic Authentication is in use, it will also need Windows Authentication enabled to allow Exchange 2013 to pass authenticated requests on.

We can accomplish this by opening IIS Manager and navigating to Sites>Default Website>rpc and then choosing Authentication. Right Click Windows Authentication and choose Enable:

Figure 5:
Enabling Windows Authentication for Outlook Anywhere on Exchange 2007

Third Party Software

As well as upgrading Microsoft software to support Exchange 2013, we’ll also need to upgrade third-party software to support the product too.

In our example organization, we know we’ve got to upgrade our BES Server, so we’ll ensure the pre-requisites are fulfilled in advance.

The key to ensuring that you receive support from the third party vendor during your upgrade is to ensure that if a change needs to be made before you implement Exchange 2013, you follow those steps as per the third party vendor’s requirements.

Installing Exchange 2013 Pre-requisites

We’re finally ready to begin the installation of pre-requisites for Exchange Server 2013, after what must seem like a lot of preparation. However that preparation should be worthwhile as we’ll now expect the installation to progress pretty smoothly.

We’ll be installing Exchange onto Windows Server 2012. If you’re given the choice between Server 2012 and 2008 R2 SP1 the former does ensure that less pre-requisites are required, and even Standard Edition supports Clustering (and thus the ability to smoothly upgrade to a Database Availability Group at a later date).

In the previous part of this series we defined the specifications for our server, E15M01 and created the supporting virtual machine.

After installing Windows Server 2012, joining the server to the domain and installing Windows updates, we’ll open a PowerShell window as an Administrator and use the following command to install the Operating System pre-requisites:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, RSAT-ADDS-Tools

Figure 6:
Installing OS Pre requisites

On Windows Server 2012, our only other operating system pre-requisite is the Microsoft Unified Communications Managed API 4.0 Runtime, available for download from the Microsoft Download website. Install this using the defaults:

Figure 7:
Installing Unified Messaging Pre requisites

After installation of the above, our server has the required pre-requisites needed before we can install Exchange, and as we’ll see next, prepare Active Directory for Exchange 2013.

Exchange 2013 Active Directory Preparation

Before installing Exchange itself, we’ll also need to prepare Active Directory. Strictly speaking this will be performed automatically if we simply run the Exchange setup; however downloading and unpacking the Exchange setup files ensures we’ve got pre-requisites available for JetStress testing; and because the Exchange 2013 Schema update is an irreversible change that may cause large amounts of Active Directory replication, we’ll perform the Active Directory prep separately.

First we need the Exchange 2013 installation files. The latest Exchange 2013 Cumulative Update is always the installation source you should use for installation. This is firstly because the update is actually a slipstreamed installer which includes all files required for initial installation; and secondly because installing the RTM version of Exchange 2013 into an Exchange 2007 environment is not supported. The Cumulative Update is the same download for all customers – whether it’s a trial, TechNet or MSDN subscription, retail licence or volume licence code.

At the time of writing, the current update is Cumulative Update 2, which can be downloaded from the Microsoft download site. After download, execute the compressed installer to extract the files to a suitable location. As we’ll be accessing the download from the command line, we’ll use the easy to navigate to location C:\Exchange2013:

Figure 8:
Extracting Exchange Setup files

Considerations before installing schema updates and altering Active Directory

Before we continue and implement the schema updates let’s stress something important again – the Schema Update to Active Directory is an irreversible change. You cannot uninstall it, or delete the changes it makes. If you need to revert back to an earlier point in time, you would need to roll-back your Active Directory environment – no simple task.

Therefore before you continue, make sure you’re confident that you are happy to continue. You may want to perform a health check against your existing Active Directory environment and before the point of implementing the changes we’ll make, perform a full backup of Active Directory.

There’s one other Exchange related consideration to be aware of – once these changes are in place, we can’t install any Exchange 2010 servers into the environment. If you’ve skipped to this part in the series because you just want to get to the good stuff, bear this in mind; if you find you’ve got incompatible clients or applications and need to upgrade to Exchange 2010 instead performing Exchange 2013 Active Directory prep will prevent you from being able to install an Exchange 2010 server.

If you think you might need to install an Exchange 2010 server at a later date, then there is a workaround. We can first of all download and extract the Exchange 2010 SP3 setup files and perform the Schema, Active Directory and Domain preparation for Exchange 2010 first, then carry on and implement the below steps for Exchange 2013. If you need an Exchange 2010 server later, you’ll be able to install one.

Installing the Schema update

After reading the hard-hitting section above you might be worried about running the schema preparation. Well, don’t worry too much because once you’ve protected yourself against anything possibly going wrong, running the schema preparation is actually very simply.

Logged on as a domain user that’s a member of the Enterprise Admins and Schema Admins, we’ll launch an elevated command prompt and change directory into the location we’ve extracted the Exchange setup files. We’ll then execute the following command:

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Figure 9:
Preparing AD Schema

The schema update should then proceed – and usually takes between 5 and 15 minutes to execute successfully.

Long term Exchange admins will recognise the command from previous versions – and no, using setup.exe rather than isn’t a mistake. What you’ll notice is new is the mouthful of a parameter /IAcceptExchangeServerLicenseTerms which you’ll now need to confirm each time you execute setup.exe from the command line.

Preparing Active Directory

Next we’ll prepare Active Directory. In particular, this will prepare the Configuration Container of our Active Directory forest effectively upgrading the AD objects that support the Exchange Organization. We’ll perform this preparation using the following command:

setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Figure 10:
Preparing the AD Forest

You’ll notice at this point you’ll see confirmation (as mentioned above) that once this step has completed no Exchange 2010 servers can be installed; so heed that warning if you think you may in fact need one.

Preparing Domains

Our final preparation step is to prepare the domains. Exchange is installed into a Forest rather than a domain and we must ensure that each domain that hosts any sort of Exchange object – be that contacts, mailboxes, distribution groups or Exchange Server – is properly prepared. For many organizations this means all domains.

Our smaller organization is comprised of a single domain, and therefore we can run the following command:

setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

Figure 11:
Preparing Domains

If you’ve got multiple domains within the same forest, you might want to consider running the command with the switch /PrepareAllDomains to ensure all domains within the forest are properly prepared. This will save you the effort of manually executing the command from a server and login within each domain one by one.


In this part in the series we’ve performed two major steps – we’ve ensured that before introducing any aspect of Exchange 2013 into the environment we’ve made sure any necessary work to bring our organization to a supported level has been completed. Finally we’ve prepared our new Exchange 2013 server by installing the pre-requisites for installation, and finally prepared Active Directory so that it’s ready for Exchange install. In the next part in this series, we’ll get our storage ready for Exchange and begin testing to ensure it meets requirements.

If you would like to read the other parts in this article series please go to:

About The Author

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