Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 4)

by [Published on 1 March 2016 / Last Updated on 1 March 2016]

In the previous article in this series, we began the post installation configuration of Exchange 2016 and made changes to client access. In this part of the series we will configure transport and mailbox databases, then begin preparing for the migration from Exchange 2010.

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

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, 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

Prohibit Send Limit

Prohibit Send/Receive Limit

Keep Deleted Items for (days)

Keep Deleted Mailboxes for (days)






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.


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.

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

See Also

The Author — Steve Goodman

Steve Goodman avatar

Steve Goodman is an Exchange MVP and works as a Technical Architect for one of the UK's leading Microsoft Gold partners.


Featured Links