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.
Recommended
Office 365 shared mailbox: When, how, and why to use it
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.
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:
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:
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:
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:
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:
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:
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:
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.
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:
Figure 4: Checking the first disk number to use for Exchange data
Format the disk using the PowerShell function we’ve created above:
Figure 5: Formatting an Exchange data disk using ReFS
After formatting all disks, they should show with correct corresponding labels:
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:
Figure 7: Accessing system settings
The system information window should open within the control panel. Choose Advanced system settings, as shown below:
Figure 8: Navigating to Advanced system settings
Next, the System Properties window will appear with the Advanced tab selected. Within Performance, choose Settings:
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:
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.
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:
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:
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 |
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 |
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 |
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 |
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:
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:
Figure 2: First login to the EAC
You should see the Exchange Admin Center login form. Login using an organization admin credentials:
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.
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:
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 |
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.
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:
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:
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:
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:
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:
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):
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
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
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
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 »
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:
Figure 11: Creating a test mailbox
There is no prescriptive name for a basic test account, so enter suitable unique and identifiable details:
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.
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
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:
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:
Figure 1: Locating the primary Send Connector for outbound email
Open the properties for the Send Connector used for outbound mail flow.
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>
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
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:
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:
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:
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
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:
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:
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:
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:
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:
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.
