Migrating a small organization from Exchange 2010 to Exchange 2016

Introduction

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

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.

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.

Image
Figure 1: An overview of our topology

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
mail.goodmanindustries.comautodiscover.goodmanindustries.com mail.goodmanindustries.comautodiscover.goodmanindustries.com

Table 1

Exchange Server Sizing

The 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)

Table 2

We have also collected statistics from the existing environment:

Number of mailboxes Average Message Size Average Received Average Sent Average Mailbox Size
150 75KB 30 15 1GB

Table 3

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.

When sizing the solution two important factors will form design constraints:

  • 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.

Our output from the role requirements calculator results in the following server specification:

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

Table 4

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:

Image
Figure 2: Hyper-V Configuration for our Virtual Machine

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.

Storage Overview

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:

Disk Mount Point
Page file E:
Database 1 C:\ExchangeDatabases\DB01
Database 2 C:\ExchangeDatabases\DB02
Database 3 C:\ExchangeDatabases\DB03
Database 4 C:\ExchangeDatabases\DB04
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
Restore LUN C:\ExchangeDatabases\Restore

Table 5

Initializing Disks

We will then bring storage online, initialize and then format and mount the storage. Launch Disk Management by right-clicking the Start Button:

Image
Figure 3: Opening Disk Management

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:

Image
Figure 4: Using Disk Management to bring a disk online

After bringing the disks online, we will now select one of the disks, right click and choose Initialize Disk:

Image
Figure 5: Initializing disks for Exchange use

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:

Image
Figure 6: Selecting the GPT partition type

Summary

In part one of this series we have planned our simple deployment, ensured our Exchange environment and clients are up to date and started the preparation of the virtual machine for Exchange 2016. In the next part of this series, we will complete the virtual machine configuration and install Exchange 2016.

Preparing the server for Exchange 2016

Configuring disks

We’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:

Image
Figure 1: Creating a new volume for the page file

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:

Image
Figure 2: Assigning a drive letter to our page file disk

After choosing the drive letter, we’ll then move on to formatting our first disk.

Image
Figure 3: Formatting our page file 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

if ($Partition)

{

$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:

Image
Figure 4: Checking the first disk number to use for Exchange data

Format the disk using the PowerShell function we’ve created above:

Image
Figure 5: Formatting an Exchange data disk using ReFS

After formatting all disks, they should show with correct corresponding labels:

Image
Figure 6: Viewing disks after formatting as ReFS

Configuring Page file sizes

Page 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:

Image
Figure 7: Accessing system settings

The system information window should open within the control panel. Choose Advanced system settings, as shown below:

Image
Figure 8: Navigating to Advanced system settings

Next, the System Properties window will appear with the Advanced tab selected. Within Performance, choose Settings:

Image
Figure 9: Opening Performance 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

You’ll see the result of this for our virtual machine illustrated below:

Image
Figure 10: Configuring the page file size

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 prerequisites

To 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.

Image
Figure 11: Installing .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:

Image
Figure 12: Installing the Unified Comms Managed API

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:

Image
Figure 13: Extracting the files for Exchange 2016

Installing Exchange Server 2016

We 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 Locations

As 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 Directory

Our 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

Image
Figure 14: Preparing the schema for Exchange 2016

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

Image
Figure 15: Preparing Active Directory for Exchange 2016

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

Image
Figure 16: Preparing the domain for Exchange 2016

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 Setup

To 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

Image
Figure 17: Installing Exchange 2016 server

After a successful installation, reboot the server.

Summary

In part two of this series we have completed the server preparation and then installed Exchange Server 2016. In the next part of this series we will perform post installation checks and configuration.

Post-Installation Configuration Changes

Checking Exchange After Installation

After 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:

Image
Figure 1: Launching the EAC

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:

Image
Figure 2: First login to the EAC

You should see the Exchange Admin Center login form. Login using an organization admin credentials:

Image
Figure 3: Login as an Admin to the EAC

After you successfully login, take a moment to navigate around each section of the EAC to familiarise yourself with the new interface.

Image
Figure 4: Exploring the Exchange 2016 EAC

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 Autodiscover

After 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:

Image
Figure 5: Launch the EMS

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

Image
Figure 6: Updating the SCP

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 2010

Because 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.

Image
Figure 7: Exporting the Exchange 2010 SSL cert

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:

Image
Figure 8: Specifying an export directory and password

Make a note of this location, as we’ll use it in the next step.

Importing the Certificate PFX File

Back over on the Exchange 2016 server, open the Exchange Admin Center and navigate to Servers>Certificates. Within the more (…) menu choose Import Exchange Certificate:

Image
Figure 9: Importing the SSL certificate to Exchange 2016

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:

Image
Figure 10: Specifying the path to the Exchange 2010 server

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:

Image
Figure 11: Selecting appropriate servers to import the certificate to

Assigning the SSL certificate to services

Although 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:

Image
Figure 12: Assigning SSL certificates for use

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):

Image
Figure 13: Selecting services to assign the SSL cert to

After the certificate is assigned, ensure it is applied to IIS by running the following command:

iisreset /noforce

Configuring Exchange URLs using the Exchange Management Shell

The 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:

Image
Figure 14: Updating URL values

Configuring Outlook Anywhere

After 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:

Image
Figure 15: Locating Outlook Anywhere settings

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:

Image
Figure 16: Updating Outlook Anywhere configuration

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.

Summary

In part three of this series, we’ve performed the first basic configuration required for our Exchange 2016 server post-installation. In part four we will complete the post-installation configuration and begin preparation for migration.

Completing Post Installation Configuration

Configuring Receive Connectors

We’ll need to ensure that the same settings are applied to Receive Connectors on Exchange 2016 as per Exchange 2010. Default and Client connectors are already created and do not typically need to be altered. The defaults for Exchange Server 2016 allow email from the internet or spam filter to be delivered without adding an additional permission.

Many organizations do allow users to relay mail through Exchange from application servers, so we will use this as an example to illustrate how the process is slightly different when compared to Exchange 2010.

To begin, launch the Exchange Admin Center and navigate to Mail Flow>Receive Connectors and after selecting the Exchange 2016 server from the list, then choose Add (+) to create a new Receive Connector:

Image
Figure 1: Creating a new Receive Connector

On the first page of the wizard, enter the name for the receive connector. For consistency we’ve specified the server name after entering Anonymous Relay.

Select Frontend Transport as the role and choose Custom as the type:

Image
Figure 2: Naming the connector and specifying core options

On the next page, we’ll be provided with the opportunity to specify Network Adapter Bindings – the IP address and TCP/IP port that the receive connector will listen on. Our example receive connector will listen on the standard port for SMTP, port 25:

Image
Figure 3: Leaving TCP/IP listener settings as default

On the final page of the wizard, we’ll choose which IP addresses that the receive connector will accept mail for.

This allows multiple receive connectors to listen on the same TCP/IP port and IP address and perform an action depending on the remote IP address of a client.

As an example, if our anonymous connector on Exchange 2010 only allowed mail relay from the IP addresses 192.168.15.1-20, we’ll specify that range here:

Image
Figure 4: Specifying IP addresses that can use this connector

After completing the wizard, we will then open the new Receive Connector’s properties page by selecting it from the list, then choosing Edit, as shown below:

Image
Figure 5: Editing connector settings after creation

In the Exchange Receive Connector window, select the Security tab. Then within the Authentication section select Externally secured to indicate our anonymous relay is from secure IPs; then under Permission Groups, choose Exchange Servers and Anonymous users:

Image
Figure 6: Allowing anonymous relay

Moving Default Mailbox Databases

We will move the initial database created by Exchange Server 2016 setup and make it our first Mailbox Database.

To perform this action, we will perform a two-step process using the Exchange Management Shell.

First, launch the Exchange Management Shell and use the following command to rename the database to DB01:

Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -Name DB01

 

Image
Figure 7:
Renaming the default database

In the example above you’ll see that by executing the Get-MailboxDatabase cmdlet before making the change we see its default name – “Mailbox Database” with a random suffix. After making the change, the name is changed to something more appropriate.

With the database name changed, it still remains in the same location. Move both the Database file and the associated log files to their respective final destinations using the Move-DatabasePath cmdlet with the -EdbFilePath and -LogFolderPath parameters:

Move-DatabasePath -Identity DB01 -EdbFilePath C:\ExchangeDatabases\DB01\DB01.EDB -LogFolderPath C:\ExchangeDatabases\DB01_Log

 

Image
Figure 8: Moving the default database path

When moving the database, it will be dismounted. The files will then be moved to the new location and the database and log locations updated in Active Directory. Finally the database will be re-mounted.

Creating Additional Mailbox Databases

Next, create additional Mailbox Databases to match our design specifications. We can create the mailbox databases using either the Exchange Admin Center or the Exchange Management Shell.

In this example we will use the Exchange Management Shell, which for a larger number of databases will be faster and more accurate.

The cmdlets used are New-MailboxDatabase, Restart-Service, Get-MailboxDatabase and Mount-Database.

In the example shown below we will use the first cmdlet to create the databases, restart the Information Store to ensure it allocates the correct amount of RAM, then after retrieving a list of all databases we will ensure they are mounted:

New-MailboxDatabase -Name DB02 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB02\DB02.EDB -LogFolderPath C:\ExchangeDatabases\DB02_Log

 

New-MailboxDatabase -Name DB03 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB03\DB03.EDB -LogFolderPath C:\ExchangeDatabases\DB03_Log

 

New-MailboxDatabase -Name DB04 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB04\DB04.EDB -LogFolderPath C:\ExchangeDatabases\DB04_Log

 

Restart-Service MSExchangeIS

 

Get-MailboxDatabase -Server <Server>| Mount-Database

 

Image
Figure 9: Creating additional databases

Configuring Mailbox Database Settings

After we have moved our first Mailbox Database and created our additional mailbox databases, we will now need to configure each database with the correct limits.

The limits chosen for our example environment are shown below, along with retention settings for mailboxes:

Warning Limit – 4.8GB

Prohibit Send Limit – 4.9GB

Prohibit Send/Receive Limit – 5GB

Keep Deleted Items for (days) – 14

Keep Deleted Mailboxes for (days) – 30

 

It’s possible to configure this using the Exchange Admin Center, but for multiple databases, use Exchange Management Shell to ensure consistency. Using a combination of the Get-MailboxDatabase cmdlet and Set-MailboxDatabase cmdlet make the changes, using the values from the table above:

Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -IssueWarningQuota 4.8GB -ProhibitSendQuota 4.9GB -ProhibitSendReceiveQuota 5GB -DeletedItemRetention « 14:00:00 » -MailboxRetention « 30:00:00 »

 

Image
Figure 10: Updating mailbox database settings

Preparing for Exchange 2016 Migration

Testing base functionality

Before we can move namespaces and mailboxes across to Exchange Server 2016 we need to test that the new server is fully functional.

We’ll start by creating a test mailbox to use on Exchange 2016. To do this, navigate to the Exchange Admin Center and within Recipients choose Add, then User Mailbox:

Image
Figure 11: Creating a test mailbox

There is no prescriptive name for a basic test account, so enter suitable unique and identifiable details:

Image
Figure 12: Specifying test mailbox settings

After creating our test mailbox we’ll now need to test that they are functional from a client perspective.

Navigate to OWA via the server’s name. As a minimum test mail flow works correctly between our new Exchange 2016 test user and existing Exchange 2010 users.

Image
Figure 13: Testing OWA and other services

Updating Exchange 2010 Virtual Directory URLs

Exchange 2016 supports acting as a proxy for Exchange 2010 services. This means that it is easy to allow Exchange 2010 and Exchange 2016 to co-exist using the same URLs.

We decided earlier in this guide that we would use the same names for both Exchange 2016 and 2010.

It is now time to move the autodiscover.goodmanindustries.com and mail.goodmanindustries.com names across from Exchange 2010 to Exchange 2016.

This, along with the respective DNS / firewall changes, will result in HTTPS client traffic for Exchange 2010 going via the Exchange 2016 server.

We will update our core URLs for Exchange 2010 to remove the ExternalURL value. We’ll also enable Outlook Anywhere, configuring it with the HTTPS name that will move to Exchange 2016.

To do this we will login to the Exchange 2010 server and launch the Exchange Management Shell. Enter the following PowerShell commands, substituting the $Server and $HTTPS_FQDN variables for appropriate values.

$Server = « EX1401 »

 

$HTTPS_FQDN = « mail.goodmanindustries.com »

 

Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -ExternalURL $null

 

Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -ExternalURL $null

 

Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -ExternalURL $null

 

Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory  -ExternalURL $null

 

Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory  -ExternalURL $null

 

Enable-OutlookAnywhere -Server $Server -ClientAuthenticationMethod Basic -SSLOffloading $False -ExternalHostName $HTTPS_FQDN -IISAuthenticationMethods NTLM, Basic

 

Image
Figure 14: Updating Exchange 2010 URL and Outlook Anywhere configuration

From a client perspective this should not have any immediate effect. The Exchange 2016 server will provide External URL values via Autodiscover, but in the meantime client traffic will still be directed at the Exchange 2010 staging server.

Updating Internal DNS records and switching external HTTPS connectivity

To direct traffic internally at the Exchange 2016 server we need to change internal DNS records so that both the Autodiscover name and HTTPS namespace (in our case, mail.goodmanindustries.com) are configured with the IP address of the new Exchange 2016 server.

On a server with access to DNS Manager, such as an Active Directory domain controller, update both records from the IP address of the Exchange 2010 server to the Exchange 2016 server:

Image
Figure 15: Updating internal DNS entries

Clients will not be immediately redirected to use the Exchange 2016 server as the proxy for client access, and instead will do so once their cached records expire. As soon as clients can access the server retry login and client access to ensure no issues exist.

If internal access works without issue, update the external HTTPS publishing – which in our example organization is a NAT rule configured via the router.

Summary

In part four of this series, we’ve completed the post-install configuration and began preparation for the migration. Base functionality has been tested and we have updated records to direct client access to the server. In the next part of this series we’ll begin by updating mail flow.

Introduction – Last Part

During the last part in this series we completed the post installation configuration of Exchange Server 2016 and configured it as per our basic design, then performed some basic tests to ensure it functions correctly. We’re now ready to update the mail routing to the Exchange 2016 server in preparation for the migration. We’ll also integrate with an Office Online Server as an optional step before migration to allow documents to be previewed within Outlook Web App.

Migrating Mail Routing

Updating Inbound Mail Routing

In the previous article, we tested to ensure that our Exchange 2016 server can receive mail and deliver it to Exchange 2010 users. By default, Exchange Server 2016 is already configured to receive email from the Internet using Anonymous permissions on the default receive connector.

If this hasn’t been changed from the defaults, update either firewall rules to direct traffic on SMTP port 25 to the Exchange 2016 server, or update your spam filter appliance to do so.

After this change has been applied ensure that inbound mail flow is not interrupted before moving on to migrating outbound mail flow.

Updating Outbound Mail Routing

With incoming mail now flowing through Exchange 2016, our next step is to make the changes required to allow and then reconfigure Exchange Server 2016 to be responsible for outbound mail flow rather than via the Exchange 2010 server.

In our example environment our mail flow is direct to the Internet, but in your organization you might use a spam filter appliance. Therefore, make sure if you use a smart host for relay, ensure the IP address of the new Exchange 2016 server is added as a server allowed to relay outbound messages.

Likewise, if you email direct to recipients then ensure the Firewall rules allow the Exchange 2016 server IP address to initiate connections to Internet hosts on TCP port 25 without tampering (such as SMTP Fixup).

After ensuring that the Exchange 2016 server is allowed to relay outbound mail, we are ready to update the Send Connector. To perform this step, open the Exchange Admin Center and navigate to Mail Flow and then choose Send Connectors. You should see the Send Connector used for outbound mail flow within the list:

Image
Figure 1: Locating the primary Send Connector for outbound email

Open the properties for the Send Connector used for outbound mail flow.

Navigate to the Scoping tab and locate the Source server section. The Exchange 2010 server should be listed. Choose Add (+) and select the Exchange 2016 server, then select the Exchange 2010 and choose Remove (-); leaving only the Exchange 2016 server within the server list:

Image
Figure 2: Updating send connector settings

After verifying both the server IP address is listed as able to relay, and that the correct Exchange 2016 server has been selected, choose Save to apply the configuration.

As with updating inbound mail routing, ensure you test outbound mail flow is unaffected before continuing.

Installing Office Online Server

Optionally, before migrating mailboxes we can install Office Online Server. At the time of writing, this is still in preview and is expected to reach general availability (GA) around the same time SharePoint Server 2016 is launched.

The Office Online Server is required for viewing and editing attachments within a web browser, so for our small organization we will walk through the installation of a single server farm. For larger organizations, high availability may be required.

Installation of Office Online Server

The current version of Office Online Server, the preview version, can be downloaded from this Microsoft link.

This must be installed on a standalone Windows 2012 R2 virtual machine or server. Before commencing the install we must also install a number of pre-requisites. First install the Visual Studio 2015 runtime from this link.

Next, install the .Net Framework 4.5.2, then install all available Windows Updates.

Finally, before commencing the installation, use the following PowerShell script to install all required pre-requisites, as shown below:

Install-WindowsFeature Web-Server, Web-Mgmt-Tools, Web-Mgmt-Console, Web-WebServer, Web-Common-Http, Web-Default-Doc, Web-Static-Content, Web-Performance, Web-Stat-Compression, Web-Dyn-Compression, Web-Security, Web-Filtering, Web-Windows-Auth, Web-App-Dev, Web-Net-Ext45, Web-Asp-Net45, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Includes, InkandHandwritingServices

Image
Figure 3: Installing OOS server pre-requisites

After installation of pre-requisites, perform a re-boot.

Next, mount the ISO image downloaded for installing Office Online Server and then start setup. For our installation, we’ll leave all defaults as-is. In the preview you will note that the version of Office Online Server is 2013. This is expected:

Image
Figure 4: Installing Office Online Server.

Configuration of Office Online Server

After installation completes, Office Online Server will not be available for use. To make it available for use with Exchange Server 2016 we must install a new Office Online Farm.

Before we do that, we’ll need to install a valid SSL certificate and configure a DNS name.

The standard naming for Office Online Server is oos.domain.com. We will choose to use oos.stevieg.org for both the internal and external URLs for our simple farm.

We’ll use the Manage Computer Certificates management snap-in to import the SSL certificate and check the certificate Friendly Name. Search in the Windows 2012 R2 Start Menu, then launch the snap-in:

Image
Figure 5: Locating Computer Certificates

You should see Certificate – Local Computer launch. Navigate to Personal and right-click Certificates. Choose All Tasks>Import… and import your certificate.

Image
Figure 6: Importing an existing SSL certificate

In our example we’ve imported an example Wildcard certificate. We’ll navigate to Certificates and record its Friendly Name from the list.

Image
Figure 7: Checking the Friendly Name of the SSL certificate

You’ll note from the command below that we specifically need to enable editing of documents when creating the farm. This is dependent on whether or not you have appropriate Office licensing. We are choosing to enable it in the example below:

New-OfficeWebAppsFarm -InternalURL « https://<OOS FQDN> » -ExternalURL « https://<OOS FQDN> »  » -CertificateName « <Certificate Name> » -EditingEnabled

Image
Figure 8: Creating a new Office Online Server Farm

Configuration of Exchange 2016

To ensure that Exchange Server 2016 can utilize our new Office Online Server farm we must configure the discovery endpoint using PowerShell. This can be configured at the Mailbox server level, or the organization level. It is useful to configure at the mailbox level if you need to maintain co-existence with Exchange 2013.

As we are upgrading from Exchange 2010, we can simply configure the endpoint at the organizational level with the Set-OrganizationConfig cmdlet and then restart the OWA app pool on our single server, as shown below:

Set-OrganizationConfig -WacDiscoveryEndpoint https://<OOS FQDN>/hosting/discoveryRestart-WebAppPool MsExchangeOwaAppPool

Image
Figure 9: Configuring Exchange 2016 to use the Office Online Server

Testing Office Online Server with Exchange 2016

Finally, we’ll need to make sure that document viewing and editing works as expected. If all is configured correctly, then viewing an email with an attachment should present the View option against an attachment:

Image
Figure 10: Checking integration of OOS

If you don’t see the option it may simply be that after making the Organization configuration change, Active Directory had not replicated before re-starting the OWA app pool and attempting access.

When you see the view option, simply select it to switch to view mode. If you’ve also enabled Editing in the Office Online Farm, you’ll see the Edit and reply option as well.

Image
Figure 11: Viewing attachments using OOS

By selecting Edit and reply, you will be able to compose a reply and edit the document before sending. If the configuration is correct then you should see the full Office Online in editing mode displayed:

Image
Figure 12: Editing attachments using OOS

Summary

In this penultimate part in the series we’ve migrated mail routing across from Exchange 2010 to Exchange 2016, and we’ve installed Office Online Server (if required) to allow viewing and editing of attachments in Outlook Web App. In the final part of this series we will migrate mailboxes, then decommission Exchange Server 2010.

Migrating the Pilot Group

Before migrating mailboxes en-mass to Exchange 2016, it’s important to validate that you’ve had an opportunity to identify any issues that using and moving test mailboxes didn’t expose.

First we will select a pilot group of users to migrate to Exchange Server 2016. They should provide feedback on any issues they encounter, and will represent a cross-section of end-users; for example users that are heavy mobile users, those that are primarily external users and those that regularly use features like shared calendars and delegation.

Many smaller organizations will find most pilot candidates within the IT department, but if you have users who are keen to be early adopters outside of IT, then you’ll get a better representation of real issues.

Migrating Mailboxes

When migrating mailboxes from Exchange 2010 to Exchange 2016, we’ve got a number of methods that can be used to migrate mailboxes in large numbers.

The first method applies if you have created equivalent databases to match your source Exchange 2010 environment. For each database, you can queue up mailboxes to be moved using the following command:

Get-Mailbox -Database <Database> | New-MoveRequest -TargetDatabase<Database_E2016> -BatchName <Database>

Image

Figure 1: Creating new move requests

If you are using traditional backups on your Exchange 2016 server then take into account the impact of log file usage when determining the batch sizes.

When a mailbox is moved, log files consuming the same amount of space as the mailbox itself are generated. This means that you can only move as many mailboxes as log space allows in between regular backup jobs.

You can mitigate against this by either performing additional incremental backups during mailbox migrations; or temporarily turning on circular logging.

We can keep track of the migrations using the Exchange Management Shell by calling the Get-MoveRequest cmdlet, again specifying the BatchName; then piping the output to Get-MoveRequestStatistics to gain a detailed insight into our current batch of migrations:

Get-MoveRequest -BatchName "<Database>" | Get-MoveRequestStatistics

Image

Figure 2: Monitoring move requests from PowerShell

If you’d prefer to use the Exchange Admin Center rather than PowerShell to co-ordinate the migration, then consider using the migration batches, as shown during our test mailbox moves.

Figure 3: Using the EAC interface to the New Migration Batch cmdlets

Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:

Image

Figure 4: Adding mailboxes to the new migration batch

After creating and starting a migration batch via the Exchange Admin Center, we can examine the progress of those moves by selecting the migration batch from the list, and then choosing View Details:

Image

Figure 5: Viewing the list of Migration Batches

We’ll then be presented with a list of all mailboxes within the batch, each of which can be selected and the full status available for detailed examination:

Image

Figure 6: Monitoring progress of a Migration Batch

Either of these two methods is equally effective, and whichever you use is down to which ever method makes most sense within your organization.

After performing migrations of end users you can verify that no additional mailboxes remain on Exchange 2010, using the following command at the Exchange 2016 Management Shell:

Get-Mailbox -Server <Server>

If any mailboxes do remain, then pipe the results of the command to the New-MoveRequest cmdlet as a new migration batch, for example:

Get-Mailbox -Server <Server> | New-MoveRequest -BatchName "Remaining Mailboxes"

We’ll also need to move the system mailboxes from Exchange 2010. We’ll find these by using the Get-Mailbox cmdlet with the –Arbitration parameter:

Get-Mailbox -Server <Server> -Arbitration

You’ll expect to see a couple. Move them to Exchange 2016 using the New-MoveRequest cmdlet again:

Get-Mailbox -Server <Server> -Arbitration | New-MoveRequest

After all mailbox moves from the Exchange 2010 server are complete, remove the mailbox move requests from Exchange 2016.

To remove successfully completed move requests, use the Remove-MoveRequest cmdlet in combination with the output of Get-MoveRequest:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Image

Figure 7: Removing completed move requests

If you opted to use the Migration Batch method then you can remove it via the Exchange Admin Center by viewing the batch, and then if it is complete, hitting the Delete button:

Image

Figure 8: Removing a completed batch

Decommissioning Exchange 2010

Getting ready to decommission Exchange 2010

By this point, we should be safe to remove Exchange 2010 from the environment. Earlier in the series we moved inbound and outbound mail flow to Exchange 2016, moved client access across; and we have just completed migrating all Mailboxes over to Exchange 2016.

Before removing the staging server, it’s important to verify that these servers are definitely no longer used. For example, if you have devices that use the Exchange 2010 server for SMTP relay, double check that all these devices have been updated to use the Exchange 2016 server.

Also double check you’ve implemented and migrated mail flow. We’ll need to verify that both Inbound and Outbound mail (via Receive and Send Connectors respectively) is configured to flow via Exchange 2016 only.

After checking that mail flow should no longer be configured to flow through the Exchange 2010 infrastructure, we should be ready to remove Exchange 2010 completely. To ensure that this is definitely the case, shut down the Exchange 2010 server and leave switched off for a reasonable period of time (for example, a week) to ensure that should anything have been missed the Exchange 2010 server can be started up and anything that wasn’t originally identified migrated.

Removing unused Offline Address Books

We’ll start off with a relatively simple task, removing the old default Offline Address Book.

As part of the installation of Exchange 2016, a new Offline Address Book was created and set as the default. This will have the suffix (Ex2013) signifying it is created by Exchange 2013 or above.

We’ll remove the old Exchange 2010 one by opening the Exchange Management Console and navigating to Organization Configuration>Mailbox and then within the Offline Address Book tab selecting the original address book, with the Generation Server specified as the old Exchange 2010 server. Simply choose Remove:

Image

Figure 9: Removing obsolete Offline Address Books

Removing Databases

In our example organization we do not use Public Folders, therefore we only have one type of Database we need to remove from our Exchange 2010 – Mailbox Databases.

Before we press ahead and remove the databases, we’ll need to double check that all mailboxes have been moved to Exchange 2016.

To verify all mailboxes have been removed from our Exchange 2010 server, we’ll use the following commands:

Get-Mailbox -Server <ServerName>
Get-Mailbox -Server <ServerName> -Arbitration
Get-Mailbox -Server <ServerName> -Archive

After verifying that no mailboxes exist on the server, we’re ready to remove the databases. As part of this process Exchange 2010 will double check that no mailboxes exist. It will not allow the removal of databases that contain mailboxes.

We’ll use the following PowerShell command from our Exchange 2010 server to first get a list of the databases:

Get-MailboxDatabase –Server <ServerName>

After confirming that the command is showing the correct databases, remove the Mailbox Databases using the following command;

Get-MailboxDatabase –Server <ServerName> | Remove-MailboxDatabase

Uninstalling Exchange 2010

With Mailbox Database configuration removed we can now uninstall Exchange Server 2010.

To do this, navigate to Programs and Features, within the Control Panel and choose Uninstall after selecting Microsoft Exchange Server 2010 from the list of installed applications:

Image

Figure 10: Uninstalling Exchange 2010

The Exchange Setup application is used for the uninstallation process, much like it was used for the original installation. When prompted, we’ll therefore unselect each Exchange Role installed, for example Client Access, Hub Transport and Mailbox.

Additionally, we’ll choose to uninstall the Management Tools – which includes the Exchange Management Console and Exchange Management Shell:

Image

Figure 11: Uninstalling all components of Exchange 2010

After choosing Next, Exchange Server Setup will perform checks to ensure that we’re actually ready to uninstall. After moving Send Connectors earlier in this series and performing the tasks in this article, we’ll expect each readiness test to complete successfully, allowing us to choose Uninstall:

Image

Figure 12: Verification of successful uninstallation

After choosing Uninstall we’ll expect the setup program to continue with removal of Exchange 2010. After it completes successfully the server can be decommissioned, and the server removed from the domain.

Summary

In this six-part series we’ve walked through a straightforward migration to Exchange 2016 from Exchange 2010. If you had experienced migrations between previous versions you will have seen that in comparison, the Exchange 2016 migration process is relatively straightforward.

Notes:
– I am not the author of this article, but i found it to be very nice.
– I have taken the liberty to copy it from its source website.
– I provide here the links to the originals and who was its author.
Source Articles:


Orignal Author:

Steve Goodman

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.