Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 3)

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

• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 1)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 2)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 4)

Introduction

In this series we rapidly migrate from Exchange 2010 to 2013. In parts one and two we decided on server specifications and then configured the base operating system, installed Exchange 2013 and then began configuration.

Post-Installation Configuration Changes

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

In the example below, we’ve specified both our server name LJD-E1501 and HTTPS name mail.lisajanedesigns.co.uk and then updated each Virtual Directory accordingly:

Figure 1: Updating Internal and External 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 2013, 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 2013 proxies Outlook Anywhere connections to the Exchange 2010 server.

To update these values, navigate to Servers and then choose Edit (Pencil icon) against the Exchange 2013 server:

Figure 2: Editing the server properties

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 3: Updating settings for Outlook Anywhere

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 the obligatory iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2013. Before we do that we will first make some additional configuration changes.

Configuring Receive Connectors

We’ll need to ensure that the same settings are applied to Receive Connectors on Exchange 2013 as per our Exchange 2010 staging server. Default and Client connectors are already created and do not typically need to be altered. The defaults for Exchange Server 2013 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 2013 server from the list, then choose Add (+) to create a new Receive Connector:

Figure 4: Viewing and creating new Receive Connectors

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 5: Creating a new Anonymous Relay connector

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 6: Selecting TCP/IP IP listener and port bindings

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 swing into 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.210-220, we’ll specify that range here:

Figure 7: Specifying a range of IP addresses that will be able to connect to 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 8: Editing properties for the new Receive Connector

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 9: Updating settings to allow relay

Moving Default Mailbox Databases

We will move the initial database created by Exchange Server 2013 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:

Figure 10: Renaming the existing 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:

Figure 11: Moving the existing database

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:

Figure 12: Creating new databases and mounting databases using PowerShell

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:

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:

Figure 13: Using PowerShell to modify all new databases

Preparing for Exchange 2013 Migration

Testing base functionality

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

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

Figure 14: Creating a test mailbox using the Exchange Admin Center

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

Figure 15: Example settings for a new test account

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 2013 test user and existing Exchange 2010 users.

Figure 16: Verifying OWA functionality

Updating Exchange 2010 Virtual Directory URLs

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

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

It is now time to move the autodiscover.lisajanedesigns.co.uk and mail.lisajanedesigns.co.uk names across from Exchange 2010 to Exchange 2013.

This, along with the respective DNS / firewall changes, will result in HTTPS client traffic for Exchange 2010 going via the Exchange 2013 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 2013.

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.

Figure 17: Reconfiguration of Exchange 2010 virtual directories

From a client perspective this should not have any immediate effect. The Exchange 2013 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 2013 server we need to change internal DNS records so that both the Autodiscover name and HTTPS namespace (in our case, mail.lisajanedesigns.co.uk) are configured with the IP address of the new Exchange 2013 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 2013 server:

Figure 18: Updating internal DNS records

Clients will not be immediately redirected to use the Exchange 2013 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 this article we’ve moved from configuring the server to co-existence. In the final part of this series we’ll complete preparation for migration, migrate mailboxes and decommission Exchange Server 2010.

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

• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 1)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 2)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 4)