Off-boarding email from Office 365 to Exchange 2013 (Part 5)

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

• Off-boarding email from Office 365 to Exchange 2013 (Part 1)
• Off-boarding email from Office 365 to Exchange 2013 (Part 2)
• Off-boarding email from Office 365 to Exchange 2013 (Part 3)
• Off-boarding email from Office 365 to Exchange 2013 (Part 4)
• Off-boarding email from Office 365 to Exchange 2013 (Part 6)

Mail Routing

At present, we’d expect Office 365 tenant to receive mail directly – i.e. the DNS Mail Exchanger (MX) records that let other SMTP servers know where to deliver mail point to Office 365.

While we move mailboxes to on-premises Exchange, we can leave this configuration in place. Outbound mail from Exchange won’t be routed to the internet via Office 365, but inbound mail for on-premises recipients can route via Office 365 and then onward to our on-premises Exchange via the Receive connector configuration the Hybrid Configuration Wizard implements.

If you have examined the configuration in Office 365 and on-premises then you may have noticed that both environments have the domains configured by default as Authoritative domain types.

Because we have configured on-premises equivalents to each mailbox we have a complete Global Address List (GAL) on both sides, with appropriate routing addresses from on-premises to the cloud. This means that Office 365 knows which mailboxes will be on-premises, and will use the outbound connector configured by the Hybrid Configuration wizard to route appropriate email to on-premises.

After moving a mailbox to on-premises you may route mail directly to recipients from the Exchange 2013 servers, by-passing Office 365. If you plan to do this, then there is another area worth looking at.

You maybe remember in the previous part of this article, we touched upon the SPF record for Office 365. If this is in place, and left untouched, then we will experience issues sending mail to some recipients. This is because the SPF record for Office 365 doesn’t include the outbound external IP address for our on-premises Exchange Server.

You can change this by editing your existing SPF record to include the external IP address that your Exchange server sends as; for example if your current SPF record is as follows:

We will then want to use the ip4: syntax to add the external IP address to the SPF record, along with the other records:

After editing the SPF record, you can check it is in place correctly using Microsoft’s Sender ID Framework SPF Record Wizard.

With these changes in place, it is time to test mail routing works correctly – you can do this by creating a test on-premises mailbox, and after DirSync has taken place ensuring mail flows between the following locations:

• Between internet users and a test on-premises Exchange 2013 mailbox, and vice versa
• Between Office 365 mailboxes within your tenant and on-premises, and vice versa

After you are confident mail flow is functioning correctly after making the changes, we are now ready to move mailboxes from the cloud to on-premises.

Moving Mailboxes

We’re finally at that point where we can begin moving mailboxes from Office 365.

Like moving to Office 365, most of the work is in getting the right foundations in place to make the actual move seamless and relatively transparent. You’ll find the moving of mailboxes fairly straightforward though and if you’ve experienced moving mailboxes within Exchange Server or to Office 365 before it will be a familiar process.

To begin our moves, we’ll first start with a single mailbox so we can once again verify functionality – this could be a test mailbox or one of the team working on the project.

Before we begin moving mailboxes, we’ll need to create a Migration Endpoint. This is used to define in Office 365 the on-premises URL that will be used to connect to the Mailbox Replication Service (MRS) Proxy.

To create this, navigate to the Office 365 Exchange Admin Center and choose Recipients, then choose Migration. From the toolbar, choose More Options (. . .) and from the drop-down menu, select Migration Endpoints:

Figure 1: Migration Endpoints in the Exchange Admin Center

The Migration Endpoints pop-up browser window should display. Choose the Add (+) button to create a migration endpoint to represent our on-premises Exchange 2013 server:

Figure 2: List of existing Migration Endpoints

We’ll now see the New Migration Endpoint Wizard. This will allow us to define several types of Migration Endpoints. Choose Exchange Remote, which is used for MRS-Proxy based migrations:

Figure 3: Starting the New Migration Endpoint wizard

We’ll then be afforded the opportunity to first auto-populate the details via Autodiscover, by entering an email address of an on-premises mailbox alongside the administrator credentials used to perform the migration. If there isn’t a suitable on-premises mailbox (yet) then the MRS Proxy Server can be manually specified, as shown below. This will typically be the FQDN used for your external Exchange Web Services URL:

Figure 4: Defining an MRS proxy endpoint manually

After completing the configuration, a migration endpoint should be listed. We’ll use this in the next step when creating a batch of mailboxes to off-board back to on-premises Exchange Server 2013.

Figure 5: Viewing the new Migration Endpoint

With a migration endpoint successfully defined in Office 365 we can create our first migration batch. A migration batch contains the list of mailboxes we want to migrate, and allows us to organize each group of mailboxes as a single entity.

To create a migration batch, within the Migration tab of the Exchange Admin Center, select Add (+) from the toolbar and then from the drop-down menu, choose Migrate from Exchange Online:

Figure 6: Starting an migration to Exchange on-premises

The New Migration Batch wizard will open, pre-configured for off-boarding mailboxes.

First we will select the mailboxes to migrate to on-premises Exchange. We’ve got to options for migration; first we can select mailboxes using the recipient picker, by choosing the Select the users that you want to move option, then choose the Add (+) button.

If you have pre-defined a list of those you wish to move you can use a CSV file as input. This simply needs the EmailAddress column header with a list of those mailbox email addresses listed.

Bear in mind when importing a long list of mailboxes that we can only select a single database to migrate to later in the wizard.

For the initial batch, ensure you migrate a test mailbox. When you have selected the mailboxes to migrate, choose Next:

Figure 7: Creating a new Migration Batch and specifying users

On the second page of the wizard the migration endpoint will be shown. This should match the on-premises Exchange organization as defined in the previous step, but you might need to select it from a list if you have multiple migration endpoints defined. Confirm it is correct, then choose Next:

Figure 8: Selecting the correct Migration Endpoint

On the penultimate page of the wizard we need to configure settings for the mailboxes once they land on Exchange 2013.

We’ll first give the batch an appropriate, unique, name, and select a target delivery domain. The target delivery domain will be an on-premises domain – usually the primary domain used by the organization- to use for mail routing to on-premises.

If mailboxes have archives, then if we are off-boarding then it is likely we will also move the mailbox archive back to on-premises. If you are leaving it, then you can choose to move the primary mailbox only, without moving archive mailbox. This will mean that the user will still maintain a connection to Office 365 when accessing older email.

Under the Target database and Target archive database options, enter the name of an appropriate mailbox database on Exchange 2013 to migrate to. There is no mailbox database picker, so you must manually enter a database name. This can either be the name of the database or the database GUID.

Finally, select an appropriate bad item limit (for messages that are corrupt and cannot be moved) and a large item limit (where messages are larger than the transport limits on Exchange 2013). The default transport settings for Exchange 2013 set the size at 10MB, whereas Office 365 has customizable limits defaulting at 25MB, so unless you want to skip large items moving back to on-premises here you might want to consider increasing the transport limits on-premises.

When you are happy with the options selected, choose Next:

Figure 9: Selecting options for the on-premises destination

On the final page of the new migration batch wizard we must select three final options. First, we must select a recipient to email a migration report to. You can use the Browse option to use the recipient picker to select an email address. As a handy tip you can also manually enter an SMTP address in the recipient picker if you want to send a notification to an email address outside the Office 365 tenant.

Our second option allows us to configure when to begin the Migration Batch. We can select to manually start the batch – a good option if you plan on creating all your batches up front and then starting them as required.

Our final option allows us to decide when to complete the migration batch. This option is crucial, as it allows us to pre-sync mailboxes before performing the switch. It is key to a co-ordinated migration. For a few test users or a few users who need to go over as quickly as possible, you can choose to automatically complete the migration batch, which will switch each mailbox over as soon as it is synced. For larger batches, manually complete the batch allows us to pre-sync the mailbox and then switch the entire batch in one go.

Figure 10: Selecting options for starting and completing the migration batch

After choosing New, the migration batch will be created and show in the list of migration batches in the migration tab of the Exchange Admin Center. You will see an overview of each batch, with the option to View details on the right hand panel. This will provide detailed information about the status of each batch and individual mailbox:

Figure 11: Viewing an in-progress migration batch

After a test migration batch completes, it’s worth ensuring for the first user everything works as expected; so initially, login to on-premises Outlook Web App and ensure you can send and receive mail between internal and external recipients correctly.

Next, ensure the rich client side process works correctly too. As mentioned earlier in the series, our scenario also involves moving users onto a newly implemented Active Directory domain therefore the standard procedures for joining the PC to the domain and migrating/creating a new profile apply, but we will expect to reset the password for the user on the on-premises Active Directory so it’s known by the user, and reconfigure the following:

• Outlook desktop client – which if the profile remains the same will be able to use AutoDiscover to login to the on-premises Exchange environment and retrieve settings.
• Non-PC clients, such as Mac Outlook 2011, Entourage 2008 Web Services Edition or Mac Mail.
• Mobile Devices such as iOS, Android and Windows Phone which even if the password remains the same will not automatically discover the on-premises Exchange Server.

For a large project, after this stage we’d look to plan for a pre-pilot group of users – such as testing and IT users, then pilot users within the larger organization to prove the process outside in the wild. However, in this series we’re only focusing on the technical aspects rather than the wider project itself.

Therefore, to migrate batches of remaining users we’ll first decide a couple of criteria; first the number of users we have physical resources to reconfigure once they are migrated. That might be how many IT support staff we have available for the task, or if we’ve configured PCs to use the Active Directory beforehand the type of self-help resources available and ability for helpdesk staff to deal with minor questions and issues.

We’ll also need to examine which groups of users will align to on-premises databases, based on the sizing for the Exchange environment, along with the rate we’ll actually be able to migrate mailboxes. For a small project with fast reliable Internet access you are likely to find you’ll be able to migrate mailboxes without issue, but for larger organizations you will need to use results from testing and pilot groups to determine the rate your organization is able to off-board mailboxes from the cloud, and tune On-Premises Exchange effectively.

The key parameter for each batch however is the mailbox database – each multiple-selection of mailboxes you make via the GUI can only have a single Mailbox Database chosen.

Summary

In this part of the series we’ve successfully migrated mailboxes to our on-premises Exchange 2013 environment. In the final part of this series we’ll walk through your options for decommissioning your Office 365 or Exchange Online environment.

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

• Off-boarding email from Office 365 to Exchange 2013 (Part 1)
• Off-boarding email from Office 365 to Exchange 2013 (Part 2)
• Off-boarding email from Office 365 to Exchange 2013 (Part 3)
• Off-boarding email from Office 365 to Exchange 2013 (Part 4)
• Off-boarding email from Office 365 to Exchange 2013 (Part 6)