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

By /

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

Introduction

Moving email services to Office 365 has become mainstream, with many organizations either moving email to the cloud or looking for ways that it might benefit them to do so. However it’s always good to have a back-out strategy and there are scenarios where you might need to move mailboxes from Exchange Online to an on premise Exchange organization, such as:

  • A change in IT strategy
  • A start-up outgrowing Office 365
  • New compliance requirements
  • Acquisitions and mergers
  • Company splits or department outsourcing

And of course many more. In this multi-part article series, we’re going to look at how to move mailboxes from Office 365 to Exchange 2010. You’ll notice we’ve not said “move back” as we’ll be assuming that either on-premises Exchange was decommissioned after a migration or the mailboxes never existed there in the first place.

The two main scenarios we’ll be looking at cover both the simplest way of moving mailboxes between organizations and what we need to do to safely implement a Hybrid Exchange organization against an existing Office 365 tenant.

In the first two articles, we’ll start with how to simply move mailboxes from Office 365 to Exchange 2010 on-premises. The type of scenarios this will be appropriate for include moving a smaller organization, or where you need to just move a few mailboxes and the Office 365 tenant will be left as-in.

Our Example Scenario

In our simple scenario, we’ve been tasked with moving two mailboxes from Office 365 to on-premise Exchange 2010. The company that requires this move has independently operating business units with their own IT staff. One business unit uses Office 365 with no on-premises IT equipment, and another business unit runs a small Active Directory and Exchange 2010 implementation.

Image
Figure 1: Our two simple standalone Office 365 and Exchange organizations

As a first step to consolidate functions, two Research and Development staff are being moved between business units, and require their mailboxes to be moved as-is from the Office 365 tenant to the on-premises Exchange 2010 organization. As this is politically sensitive, we must not make any unnecessary changes to the Office 365 tenant or Exchange 2010 organization and other integration options like Hybrid Configuration or organization relationships that are still under review.

We’ll simply move the two mailboxes from Office 365 to Exchange 2010, leaving Mail Users in their place:

Image
Figure 2: Example of mailbox moves

If you’re not sure what the difference between a mailbox and a mail user is, we’ll take a quick moment to explain. A mail user is effectively a mail enabled user account with a forwarding email address instead of a mailbox. Incoming email to their Office 365 email address will still reach the users, but will be forwarded to their on-premises email address on Exchange 2010.

Getting Started

Before we start moving mailboxes across, we need to make sure some pre-requisites are in place. It goes without saying that we’ll need a working Exchange 2010 deployment to move mailboxes to, and we won’t cover how to set a basic Exchange server up within this article.

Our second pre-requisite is external access to Exchange 2010 from the internet – from Microsoft’s Office 365 datacentres in particular. Internet access is required to the Exchange Web Services (EWS) virtual directory as the mechanism that will be used for Mailbox Migration is the MRS Proxy, or to give it it’s full name, the Mailbox Replication Service Proxy. The MRS Proxy web components live within the Exchange Web Services virtual directory.

To verify connectivity from the outside world a good first step is to work through the tasks in the article Using the Hybrid Configuration Wizard in Exchange 2010 Service Pack 2 – Part One (Planning) which will verify the minimum requirements for a Hybrid Configuration but will also ensure that EWS will be accessible.

For the remainder of part one and part two of this series, we’ll need:

  • The Exchange Management Console (EMC)
  • The Exchange Management Shell (EMS)
  • A PowerShell session open to Exchange Online, which we’ll call the Exchange Online PowerShell session.

Start both the EMC and EMS, and then open a new PowerShell session and connect to Exchange Online using the following cmdlets:

$ExchangeOnlineCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection:$true -Credential $ExchangeOnlineCredential

Import-PSSession $Session

Image
Figure 3: Starting an Exchange Online PowerShell Session

We’ll leave that session open in the background for later use, and move back to the Exchange Management Shell where we’ll perform some configuration on Exchange 2010.

If it’s not already enabled, we’ll need to enable the MRS Proxy component. First, we’ll retrieve a list of EWS virtual directories:

Get-WebServicesVirtualDirectory

Next, using the output from the above cmdlet we’ll construct the relevant cmdlet to enable the MRS Proxy on each internet-facing EWS virtual directory:

Set-WebServicesVirtualDirectory -Identity “ServerName\EWS (Default Web Site)” -MRSProxyEnabled:$True

In practice this should be fairly straightforward, as shown below:

Image
Figure 4: Enabling the MRS Proxy component

Finally, we’ll run iisreset /noforce against each server we’ve performed the above change on, typically at a time suitable to risk a small interruption in service.

Preparing Mailboxes for Moves

Now that we’ve enabled Exchange to allow remote mailbox moves via the MRS Proxy component, we’re almost ready – we now just need to get a couple of local mail-enabled users on-premise to serve as the target accounts to migrate mailbox from Office 365 to.

We’ll need to perform a few steps to do this:

  • Create local mail users
  • Retrieve each Office 365 user’s Mailbox GUID value
  • Apply the Mailbox GUID value to the corresponding local mail user.

First, let’s create our two corresponding mail users for our two users to migrate. Each user’s Office 365 and Exchange 2010 email address details are shown below:

User

Office 365 Email Address

Exchange 2010 UPN and Email Address

Marty Mcfly

[email protected]

[email protected]

Doc Brown

[email protected]

[email protected]

Table 1

We can perform this using the Exchange Management Console, or using the Exchange Management Shell, using a cmdlet similar to that shown below for each user:

New-MailUser -Name “Marty Mcfly” -SamAccountName marty.mcfly -UserPrincipalName [email protected] -Password (Get-Credential).Password -ExternalEmailAddress [email protected]

Image
Figure 5: Creating to new mail-enabled users

After successfully creating each Mail User, we should be able to email each of these on-premises addresses, and email should successfully be received by the users at Office 365.

Whilst worth testing, succes is not essential and simply serves to demonstrate that these on-premises mail-enabled users act as “pointers” to the real mailboxes in Office 365.

Our next step to get us ready to move the mailboxes is to assign the Mailbox GUIDs from Office 365 to each on-premises mail user. We’ll do this by opening our Exchange Online PowerShell session that we started in the previous section, then for each Mailbox we want to move executing the following cmdlet:

Get-Mailbox [email protected] | Select Name,ExchangeGUID

Image
Figure 6: Retreiving Mailbox GUID information from Office 365

We’ll record the Mailbox GUID, listed as ExchangeGUID and then apply it to each corresponding mail user using the Exchange Management Shell against our on-premises Exchange 2010 environment:

Set-MailUser marty.mcfly -ExchangeGuid 9d3c4ac7-b41e-4ba4-91b2-bc7ecaa3b4d2

Image
Figure 7: Applying Mailbox GUID information to on-premises Exchange 2010

With the Mailbox GUID set, we’ve now got the key attribute configured within Exchange that will allow Office 365 to “reach in” and locate the correct mail user to use as a target when moving the Mailbox.

Summary

In the first article, we’ve examined a scenario where we are tasked with moving a number of mailboxes quickly and efficiently from Office 365 to Exchange 2010. We’ve looked at the pre-requisites that must be in place before attempting a mailbox move and prepared local Mail Users ready for mailbox moves.

The next part of this series will cover moving the mailboxes themselves, and also look at the client experience during the move and what caveats exist with this type of move.

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