Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)

By /

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

Introduction

The previous parts of this series have all been about the setup – getting the “reverse Hybrid” implementation in place to facilitate the off-boarding of mailboxes cleanly and smoothly to an on-premises Exchange organization. In the penultimate part of the series, we’ll configure mail routing, and move mailboxes to on-premise before the final part of the series where we will deal with removing the Hybrid configuration leaving us a clean Office 365 tenant and Exchange environment.

Mail Routing

At present, we’d expect Office 365 tenant receives 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.

Image
Figure 1: Example of mail routing to on-premises Exchange via Office 365

We will have to make one change though, to enable Office 365 to forward mail for our domain. We’ll perform this change using Exchange Online PowerShell. Using a PowerShell 2.0 prompt, we’ll connect to the service:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection:$true -Credential $cred
Import-PSSession $session

Next, we’ll change our accepted domains within Office 365 to be both Internal Relay domains and set the OutboundOnly parameter to False. First after connecting, we’ll use Get-AcceptedDomain to check the status of our accepted domains:

Image
Figure 2: Examining Office 365 accepted domains

The domain name we’ll want to change is the exchangelabs.co.uk domain in this example – the tenant domains ending in onmicrosoft.com will stay untouched. We’ll use the following syntax for the Set-AcceptedDomain cmdlet to change the domain settings:

Set-AcceptedDomain -Identity exchangelabs.co.uk -DomainType InternalRelay -OutboundOnly:$False

Image
Figure 3: Updating our shared domain to allow routing to on-premise Exchange

After making the change, we’ve 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:

v=spf1 include:spf.protection.outlook.com -all

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

v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 -all

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 that 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 your test on-premise mailbox, and vice versa
  • Between Office 365 mailboxes within your tenant and on-premise, and vice versa

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

To select our first mailbox, we’ll use the Exchange Management Console to navigate to our Office 365 tenant, choosing Recipient Configuration and then Mailbox:

Image
Figure 4: Selecting the first Office 365 mailbox to move to on-premises Exchange

After choosing an appropriate Mailbox, we’ll right-click on the Mailbox and choose New Remote Move Request. Ensure you’ve selected the right mailbox, then choose Next:

Image
Figure 5: Examining the first page of the remote move request

Now, on the Connection Configurations we’ll enter some important details. We’ll need to specify a Target Forest, which will be our Microsoft Exchange On-Premise organization.

Under the FQDN of the Mailbox Replication Service proxy server, we’ll enter one of the servers we chose as a Hybrid Client Access Server.

Finally on this page of the Wizard, we’ll enter suitable credentials of an on-premises user that can perform the move. An example of a user with appropriate rights is a member of the Organization Management security group, or for a user with less privileges, a user that is a member of Recipient Management:

Image
Figure 6: Specifying the connection configuration information for the remote move request

On the Move Settings tab, we’ll now specify both the on-premises domain, which will be the shared domain – in our case exchangelabs.co.uk and a target Mailbox Database to move the mailbox onto:

Image
Figure 7: Specifying our shared domain for delivery to on-premises, and the target database to move the mailbox to

After the wizard begins, you can monitor the process of the move by navigating to Recipient Configuration>Move Request. You’ll need to refresh this page manually to see moves complete, and can see individual mailbox move progress either by selecting the Properties for each use or customizing the columns shown in the main view:

Image
Figure 8: Examining the mailbox move in progress

After the move request completes, it’s worth ensuring that 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 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 group 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 configured the mail routing for the tenant to allow mail to flow via Office 365 to on-premises Exchange, then moved mailboxes from Office 365 to our Exchange environment. In the final part of this series, we’ll finish up by removing the Hybrid configuration that joins our on-premise environment to the cloud, and remove configuration from Office 365 so it’s safe to decommission.

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

About The Author

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.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top