In this article we will migrate from Exchange 2010 to Exchange 2016. In this short series we’ll be focusing on the implementation and migration steps to move from Exchange 2010 to Exchange 2016, rather than implementing features like Database Availability Groups or configuring load balancing. Therefore, we’ll focus on a smaller organization with a relatively simple deployment.
The latest version of Exchange Server brings the latest cloud-based developments and reliability improvements to on-premises Exchange. In this series we will walk through the steps required to implement Exchange 2016 into your current Exchange 2010 organization and migrate mailboxes across.
Planning for Deployment
Before you begin it’s important to understand that a key architectural change has been made in Exchange 2016. Exchange 2010 had a number of separate roles; Client Access, Hub Transport, Mailbox and Unified Messaging.
In Exchange 2016 only a single role is used, the Mailbox role. This contains all necessary components required.
Our example organization is Goodman Industries, who have a single Exchange 2010 multi-role server and will migrate over to a single Exchange 2016 mailbox server.
In the example above, you’ll see our source server EX1401 running Exchange 2010. Our target server will be EX1601. In a larger organization this would most likely be highly available, so we’d have multiple domain controllers (rather than just AD01) and use Database Availability Groups on the source and target.
Naming and Services
Our first step is to define names used by clients to access Exchange. Co-existence with Exchange 2010, 2013 and 2016 allows sharing of the same HTTPS names for Autodiscover, OWA, ActiveSync and other services, making it easy to transition across and reduce the risk of implementing co-existence.
|Old Exchange 2010 Namespaces||New Exchange 2016 Namespaces|
Exchange Server SizingThe environment we’ll be implementing Exchange 2016 on is virtualised, running Hyper-V in our example.
|CPUs||Cores||SPECint_rate2006 score||Host RAM||Disks Available|
|2 x Intel Xeon||12||367||256GB||24 x 4TB 3.5” 7.2K RPM SAS (RAID 10)|
We have also collected statistics from the existing environment:
|Number of mailboxes||Average Message Size||Average Received||Average Sent||Average Mailbox Size|
To calculate the requirements, we’ll use version 7.8 or higher of the Exchange Server Role Requirements Calculator. This supports both Exchange 2013 and Exchange 2016, so be sure to select the correct version when using the tool.
- The solution will not have high availability and instead will use Hyper-V for high availability.
- The Exchange 2016 environment will provide quota limits of 5GB per user.
- We’ll configure the maximum number of databases to be 5.
- We’ll use a VSS-based backup solution rather than Exchange Native Protection – simply because it’s a non-HA simple environment.
|Hostname||Virtual CPU||RAM||OS Disk||Page file Disk||Physical disks required||Database virtual disks||Log virtual disks||Restore LUN|
|EX1601||1 x vCPU||16GB||100GB||20GB||4 x 4TB||5 x 291GB||5 x 5GB||1 x 213GB|
The Virtual CPU specifies how many CPU cores should be assigned to the Virtual Machine used, as does the RAM. The OS disk will hold both Operating System Exchange install and transport databases.
The Physical Disks represents how many of the available physical disks are needed to actually support the deployment and meet requirements for performance and space. In the virtual environment, these will be presented as virtual disks and will be used for database and log files respectively.
You'll note that we're still splitting databases and logs. For an implementation making use of Exchange Native Protection we wouldn't look to do this, but for an implementation in a virtual environment that takes advantage of backups this is still required. We've also included an additional virtual disk to use as a restore LUN.
Splitting Databases from logs ensure that in the scenario of a log disk filling up, databases will not be corrupted. We also ensure that losing or the corruption of a virtual disk doesn't result in a full restore of Exchange.
Updating the environment
Updating Exchange Server 2010
The minimum supported patch level for Exchange Server 2010 is Service Pack three with Update Rollup 11.
Exchange 2010 Service Pack 3 is available here. Exchange 2010 SP3 Update Rollup 11 is available here. Install it, or a newer version if it is available.
Directory Service Requirements
The last few versions of Exchange had reasonably light requirements on AD functional levels. Now Windows 2003 R2 has finally went out of support the minimum Forest Functional Level and Domain Functional Level has been changed from 2003 and above. The minimum support FFL/DFL is now a minimum of Windows 2008 or above.
Updating Outlook Clients
Exchange 2016 supports Outlook 2010 and above on Windows, and on the Mac Outlook 2011 and higher. Outlook 2007 is no longer supported, but may work.
All versions of Outlook 2016 and Outlook 2013 are supported. Outlook 2010 is supported with the April 2015 update (KB2965295).
Update clients to the minimum supported version required before implementing Exchange 2016. Newer versions of Outlook will work with Exchange 2010 without issue.
Preparing the server for Exchange 2016
Exchange 2016 supports Windows 2012 and Windows 2012 R2. In our series we'll use Windows 2012 R2.
We'll be using physical disks to support Exchange 2016 and then creating virtual disks atop our Hyper-V environment. In Hyper-V, our new VM looks like this:
We'll then proceed and install Windows Server 2012 R2 on the virtual machine used for Exchange 2016, then configure it with correct network settings, install the latest Windows updates and join it to our domain.
Exchange Server 2016 supports NTFS and ReFS for Exchange databases and log files, and supports NTFS for operating system and Exchange binaries.
ReFS is recommended, with data integrity features switched off; therefore, we’ll format all Exchange database and log disks using this filesystem.
In addition to making sure we're using the recommended filesystem, we will create mount points to represent the disks and their purpose:
|Database 1 Log||C:\ExchangeDatabases\DB01_Log|
|Database 2 Log||C:\ExchangeDatabases\DB02_Log|
|Database 3 Log||C:\ExchangeDatabases\DB03_Log|
|Database 4 Log||C:\ExchangeDatabases\DB04_Log|
We will then bring storage online, initialize and then format and mount the storage. Launch Disk Management by right-clicking the Start Button:
Within Server Manager, navigate to Disk Management. We will see in the upper panel the system disk, C: and the System Reserved Partition. These also display in the lower page, contained as partitions within the primary disk.
All newly added disks will typically be shown as offline. We'll need to first change each of these disks to an online state before we prepare them. This is accomplished by right clicking each disk and simply choosing online. Perform this step, as shown below, across all new disks before proceeding:
After bringing the disks online, we will now select one of the disks, right click and choose Initialize Disk:
This will allow us to initialize all new disks in a single operation. We'll ensure all disks are selected (in our case all 12 additional disks), then select GPT (GUID Partition Table), which is recommended for Exchange and supports disk sizes over 2TB, should they be required:
Preparing the server for Exchange 2016
Configuring disksWe’ll now create our first volume for the Page File. In our design, this is not to be located on a mount point, so we don’t need to create a folder structure to support it. We can simple right click and choose New Simple Volume:
The New Simple Volume Wizard will launch. We’ll be provided with the opportunity to assign our drive letter, mount in an empty folder (which we will use for the database and log volumes) or not to assign a drive letter or path. We’ll choose a drive letter, in this case, D:
After choosing the drive letter, we’ll then move on to formatting our first disk.
After formatting the page file volume, we will format and mount our database and log volumes.
The process to create the ReFS volume with the correct settings requires PowerShell. An example function is shown below that we will use to create the mount point, create a partition and format the volume with the right setting.
|function Format-ExchangeDisk |
param($Disk, $Label, $BaseDirectory="C:\ExchangeDatabases")
New-Item -ItemType Directory -Path "$($BaseDirectory)\$($Label)"
$Partition = Get-Disk -Number $Disk | New-Partition -UseMaximumSize
$Partition | Format-Volume -FileSystem ReFS -NewFileSystemLabel $Label -SetIntegrityStreams:$False
$Partition | Add-PartitionAccessPath -AccessPath "$($BaseDirectory)\$($Label)"
Check and alter the script for your needs. To use the function, paste the script into a PowerShell prompt. The new function will be available as a cmdlet, Format-ExchangeDisk. Before using the script we need to know which disks to format. In Disk Management examine the list of disks. We’ll see the first one to format as ReFS is Disk 2:
Format the disk using the PowerShell function we’ve created above:
After formatting all disks, they should show with correct corresponding labels:
Configuring Page file sizesPage file sizes for each Exchange Server must be configured correctly. Each server should have the page file configured to be the amount of RAM, plus 10MB, up to a maximum of 32GB + 10MB.
To configure the Page file size, right click on the Start Menu and choose System:
The system information window should open within the control panel. Choose Advanced system settings, as shown below:
Next, the System Properties window will appear with the Advanced tab selected. Within Performance, choose Settings:
We will then adjust the Virtual Memory settings and perform the following actions:
- Unselect Automatically manage paging file size for all drives
- Set a page file size to match the current virtual machine RAM, plus 10MB, for example:
- 8GB RAM = 8192MB RAM = 8202MB page file
- 16GB RAM = 16384MB RAM = 16394MB page file
After making this change you may be asked to reboot.
You don’t need to do so at this stage as we will be installing some pre-requisites to support the Exchange installation.
Configuring Exchange 2016 prerequisitesTo install the pre-requisites, launch an elevated PowerShell prompt, and execute the following command:
|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|
After installation of the components a reboot is required before we can install the other pre-requisites needed for Exchange 2016 installation.
First we’ll install the .Net Framework 4.5.2.
Next, install the Microsoft Unified Communications Managed API Core Runtime, version 4.0.
After download, launch the installer. After copying a number of files required, the installer provides information about the components it will install as part of the Core Runtime setup:
No special configuration is needed after install as it’s a supporting component used by Unified Messaging.
Our final pre-requisite is to download and extract the Exchange 2016 installation files themselves.
At the time of writing, the latest version of Exchange 2016 is the RTM version.
Note that because each Cumulative Update and Service Pack for Exchange 2016, you do not need to install the RTM version and update if a CU/SP has been released. Download the latest version available.
After download, run the self-extracting executable and choose an appropriate location to extract files to:
Installing Exchange Server 2016We will install Exchange Server 2016 via the command line. It’s also possible to perform the setup using the GUI, however the command line options allow us to perform each critical component, such as schema updates, step-by-step.
Installation LocationsAs recommended by the Exchange 2016 Role Requirements Calculator, we will be placing the Transport Database - the part of Exchange that temporarily stores in-transit messages - on the system drive, therefore it makes a lot of sense to use the default locations for Exchange installation.
The default installation location for Exchange 2016 is within C:\Program Files\Microsoft\Exchange Server\V15.
Preparing Active DirectoryOur first part of the Exchange 2016 installation is to perform the Schema update. This step is irreversible; therefore, it is essential that a full backup of Active Directory is performed before we perform this step.
While logged on as a domain user that's a member of the Enterprise Admins and Schema Admins, launch an elevated command prompt and change directory into the location we've extracted the Exchange setup files, C:\Exchange2016.
Execute setup.exe with the following switches to prepare the Active Directory schema:
setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Expect the schema update to take between 5 and 15 minutes to execute.
Next prepare Active Directory. This will prepare the Configuration Container of our Active Directory forest, upgrading the AD objects that support the Exchange Organization. We'll perform this preparation using the following command:
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Our final step to prepare Active Directory is to run the domain preparation.
Our smaller organization is comprised of a single domain, and therefore we can run the following command:
setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms
If you have more than one domain within the same Active Directory forest with mail-enabled users, then you will need to prepare each domain. The easiest way to prepare multiple domains is to replace the /PrepareDomain switch with /PrepareAllDomains.
Performing Exchange 2016 SetupTo install Exchange 2016 via setup.exe we will use the /Mode switch to specify that we will be performing an Install. In addition to the /Mode switch we need to specify the role that we’ll install, the Mailbox role.
setup.exe /Mode:Install /Roles:Mailbox /IAcceptExchangeServerLicenseTerms
After a successful installation, reboot the server.
Post-Installation Configuration Changes
Checking Exchange After InstallationAfter installation completes we will ensure that the new Exchange Server is available.
Choose Start and launch the Exchange Administrative Center from the menu, or navigate using Internet Explorer to https://servername/ecp/?ClientVersion=15:
When launching via a localhost URL and because we haven’t installed the real SSL certificate we will see a certificate warning, as shown below. Click Continue to this website to access the EAC login form:
You should see the Exchange Admin Center login form. Login using an organization admin credentials:
After you successfully login, take a moment to navigate around each section of the EAC to familiarise yourself with the new interface.
You’ll notice that the EAC is very different in layout to Exchange Server 2010’s Exchange Management Console. In Exchange 2010 and 2007, the focus was based on the organization, servers and recipients with distinct sections for each. Exchange 2013 and 2016 move to a more task-oriented view. For example, Send and Receive connectors are both managed from the Mail Flow section rather than hidden within respective Organization and Server sections.
However even with those changes, very similar commands are used within the Exchange Management Shell and you will be able to re-purpose any Exchange 2010 PowerShell skills learnt.
Updating the Service Connection Point for AutodiscoverAfter successfully installing Exchange Server 2016, a change worth making is to update the Service Connection Point (SCP).
The SCP is registered in Active Directory and used, alongside the Exchange 2010 SCP, as a location Domain-Joined clients can utilize to find their mailbox on the Exchange Server.
By default, the SCP will be in the form https://ServerFQDN /Autodiscover/Autodiscover.xml; for example https://EX1601.goodmanindustries.com/Autodiscover/Autodiscover.xml.
The name above however won't be suitable for two reasons - firstly, no trusted SSL certificate is currently installed on the new Exchange 2016 server, and the SSL certificate we'll replace it with in the next section won't have the actual full name of the server.
This can cause certificate errors on domain-joined clients, most commonly with Outlook showing the end user a certificate warning shortly after you install a new Exchange Server.
Therefore, we will update the Service Connection Point to use the same name as the Exchange 2010 uses for its Service Connection Point. This is also the same name we’ll move across to Exchange 2016 later on.
To accomplish this, launch the Exchange Management Shell from the Start Menu on the Exchange 2016 server:
To update the Service Connection Point, we'll use the Set-ClientAccessService cmdlet from the Exchange Server 2016 Management Shell, using the AutodiscoverServiceInternalURI parameter to update the actual SCP within Active Directory:
Set-ClientAccessService -Identity EX1601 -AutodiscoverServiceInternalURI https://autodiscover.goodmanindustries.com/Autodiscover/Autodiscover.xml
After making this change, any clients attempting to use the Exchange 2016 Service Connection Point before we implement co-existence will be directed to use Exchange 2010.
Exporting the certificate as PFX format from Exchange 2010Because we will migrate the HTTPS name from Exchange 2010 to Exchange 2016 we can re-use the same SSL certificate by exporting it from the existing Exchange server.
To perform this step, log in to the Exchange 2010 server and launch the Exchange Admin Console. Navigate to Server Configuration in the Exchange Management Console, select the valid SSL certificate with the correct name, then select Export Exchange Certificate from the Actions pane on the right hand side.
The Export Exchange Certificate wizard should open. Select a location to save the Personal Information Exchange (PFX) file and an appropriate strong password, then choose Export:
Make a note of this location, as we’ll use it in the next step.
Importing the Certificate PFX FileBack over on the Exchange 2016 server, open the Exchange Admin Center and navigate to Servers>Certificates. Within the more (…) menu choose Import Exchange Certificate:
In the Import Exchange Certificate wizard we’ll now need to enter a full UNC path to the location of the exported PFX file, along with the correct password used when exporting the certificate from Exchange 2010:
After entering the location and password, we’ll then choose Add (+) to select our Exchange 2016 server, EX1601, as the server to apply this certificate to. We’ll then choose Finish to import the certificate:
Assigning the SSL certificate to servicesAlthough we now have the SAN SSL certificate installed on the Exchange 2016 server it is not automatically used by services such as IIS, SMTP, POP/IMAP or Unified Messaging. We’ll need to specify which services we want to allow it to be used with.
To perform this step, within Certificates select the certificate and then choose Edit:
Next, choose the Services tab in the Exchange Certificate window and select the same services chosen for Exchange 2010. In this example, we’re only enabling the SSL certificate for IIS (Internet Information Services):
After the certificate is assigned, ensure it is applied to IIS by running the following command:
Configuring Exchange URLs using the Exchange Management ShellThe Exchange Management Shell also provides the functionality to change the Exchange URLs for each virtual directory, however unless you know the syntax it can be a little intimidating - and even if you do know the relevant syntax, typing each URL can be a little time consuming too.
We can use a PowerShell script to make this process simpler.
The first two lines of the script are used to specify the name of the Exchange 2016 server, in the $Server variable, and the HTTPS name used across all services in the $HTTPS_FQDN variable.
The subsequent lines use this information to correctly set the Internal and External URLs for each virtual directory:
|$Server = "ServerName" |
$HTTPS_FQDN = "mail.domain.com"
Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/owa" -ExternalURL "https://$($HTTPS_FQDN)/owa"
Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/ecp" -ExternalURL "https://$($HTTPS_FQDN)/ecp"
Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/oab" -ExternalURL "https://$($HTTPS_FQDN)/oab"
Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync" -ExternalURL "https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync"
Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/EWS/Exchange.asmx" -ExternalURL "https://$($HTTPS_FQDN)/EWS/Exchange.asmx"
Get-MapiVirtualDirectory -Server $Server | Set-MapiVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/mapi" -ExternalURL https://$($HTTPS_FQDN)/mapi
In the example below, we've specified both our server name EX1601 and HTTPS name mail.goodmanindustries.com and then updated each Virtual Directory accordingly:
Configuring Outlook AnywhereAfter updating the Virtual Directories for Exchange, we'll also update the HTTPS name and authentication method specified for Outlook Anywhere.
As Outlook Anywhere is the protocol Outlook clients will use by default to communicate with Exchange Server 2016, replacing MAPI/RPC within the LAN, it's important that these settings are correct - even if you are not publishing Outlook Anywhere externally.
During co-existence it's also important to ensure that the default Authentication Method, Negotiate, is updated to NTLM to ensure client compatibility when Exchange 2016 proxies Outlook Anywhere connections to the Exchange 2010 server.
To update these values, navigate to Servers and then choose Edit against the Exchange 2016 server:
In the Exchange Server properties window choose the Outlook Anywhere tab. Update the External Host Name, Internal Host Name and Authentication Method as shown below:
Naturally you can also accomplish this with PowerShell, however it's just as quick to use the Exchange Admin Center for a single server.
With these settings configured, along with iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2016. Before we do that we will first make some additional configuration changes.
SummaryWe’ve performed the first basic configuration required for our Exchange 2016 server post-installation. In next part we will complete the post-installation configuration and begin preparation for migration.
To Be Continued!