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

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

• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 1)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 3)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 4)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 5)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)

Introduction

Part one of this series looked at reasons why you might want to move mailboxes, either some or all, back from Office 365. Just to recap, these might include company mergers and acquisitions, a change in IT strategy, new requirements or changes to organizational structure.

In our first article we’ve began to look at the first of two scenarios that we’ll walk through the migration process for; moving a number of mailboxes from a standalone Office 365 tenant to on-premises Exchange 2010 with the minimal number of changes required to allow this to take place.

For our example scenario, two independently operating business units have a number of staff moving from one unit to another, and require the associated mailboxes for those users to be moved from Office 365 to on-premises Exchange 2010. The first part of this series covered the basic pre-requisites that need to be in place before mailbox moves can be considered, and also covered the preparation required against those mailboxes to allow moves to take place.

This part of the series wraps up the simple move scenario by examining how to actually move our prepared mailboxes from Office 365 to on-premises Exchange 2010 and also covers what to expect from a client perspective.

Choosing Mailboxes Databases and On-Premise Credentials

Before we can press ahead and move our two mailboxes from Office 365, we’ll need to obtain a little bit more information about our on-premises Exchange organization.

The first is to choose a Mailbox Database for each mailbox we want to move. Quite feasibly this can be the same database for both mailboxes – but the main point of note is the auto-selection of mailbox databases you’ll usually be able to take advantage of with local move requests doesn’t apply to remote moves.

You’ll find the list of Mailbox Databases within the Exchange Management Console (EMC) under Organization Configuration>Mailbox, listed on the Database Management tab. Alternatively, open up the Exchange Management Shell (EMS) and use Get-MailboxDatabase to list Exchange 2010 databases:

Figure 1: Selecting an on-premises Mailbox Database to migrate Office 365 mailboxes to

We’ll only need the name of the database, as shown highlighted above; we don’t need any other details such as prefixing the server name. For our moves, we’ll use DB01.

The second set of information we’ll need is suitable credentials to provide to Office 365 to move the mailbox. These credentials are for on-premises Exchange 2010, and the key point of note is that you’ll be entering what may be administrative credentials for your on-premises Exchange organization into Office 365 for it to use when logging into your Exchange organization remotely over the internet. Therefore you should choose the credentials you use wisely.

Suitable accounts to use for mailbox moves include:

• An account that possesses, as a minimum, the Migration role.
• An account that has been assigned to the built-in Recipient Management role group, which includes the Migration role.
• An administrator account that is part of the Organization Management role group, which although has the necessary rights is typically a bad choice to use when providing rights to an external service.

Adding an account to the Recipient Management group is typically the simplest compromise and can be accomplished quickly and easily by adding a user account to the aforementioned group within Active Directory, as shown below:

Figure 2: The Recipient Management role group within Active Directory

Moving Mailboxes

With our two accounts set up with local Mail Users and respective Mailbox GUIDs copied from Office 365 along with a Mailbox Database and suitable credentials ready, all that is left now is to actually move the mailboxes themselves.

All mailbox migrations to and from Office 365 using Remote Moves are initiated from Office 365. After initiating a move, Office 365 connects to the on-premises Exchange 2010 organization using the credentials we provide and handle the hard work of shifting the data. Therefore, to initiate the move, we’ll re-open the Exchange Online PowerShell session uses earlier.

The cmdlet used should be familiar – New-MoveRequest. The slight difference compared to local moves or moving mailboxes to the cloud is that we’ll use the -Outbound parameter to signify that Office 365 should be pushing a mailbox out from the cloud to an on-premises Exchange org.

We’ll first use the Get-Credential cmdlet to supply the on-premises Exchange admin credentials, then we’ll issue our custom New-MoveRequest cmdlet, as shown below:

$Credential=Get-Credential

New-MoveRequest [email protected] -Outbound -RemoteHostName mail.exchangelabs.co.uk -RemoteTargetDatabase DB01 -RemoteCredential $Credential -TargetDeliveryDomain exchangelabs.co.uk

Figure 3: Initiating Mailbox Moves from Office 365

After successfully creating the two new move requests we can use the standard Get-MoveRequest and Get-MoveRequestStatistics cmdlets to monitor progress, again using Exchange Online PowerShell:

Figure 4: Monitoring Mailbox Move progress

If we switch over the Exchange Management Console and navigate to Recipient Configuration>Mailboxes we’ll also see our two on-premises mail users have been converted to Mailboxes, and have icons signifying they are moving:

Figure 5: Examining on-premises Mail-enabled users converted to Mailboxes

Back in Office 365, we find the opposite occurs after successful migration. Each of the two Mailboxes will now be a simple mail-enabled user; the details of which can be examined with the Get-MailUser cmdlet from our Exchange Online PowerShell session.

We’ll use a cmdlet similar to below to retrieve details about each mail user. We’ll selectively show relevant details, paying special attention to the ExternalEmailAddress attribute as this signifies the on-premises email address mail will now be forwarded to:

Get-MailUser marty | Select Name,PrimarySMTPAddress,ExternalEmailAddress

Figure 6: Examining Office 365 mailboxes converted to mail-enabled users

Within the on-premises Exchange Management Console we can finally examine the Mailboxes we’ve just moved. If we view the properties of each Mailbox, we’ll see on the E-Mail Addresses tab that is part of the Move Request, relevant details such as the original Office 365 email addresses have been retained, along with the LegacyExchangeDN:

Figure 7: Examining migrated mailbox properties

The LegacyExchangeDN, shown as the X500 Address is particularly important as it’s used in places such as Outlook’s nickname cache, and loss of that data can cause end-user issues.

As well as key attributes shown above, other important information is retained after the mailbox migration. Basic information such as the Outlook Web App theme is retained along with information such as Mailbox Rules.

Another great aspect is that mailbox permissions are retained post-move also, so if our two users share mailbox data these permissions do not need to be re-applied. We can check these permissions have been retained by navigating to Recipient Configuration>Mailbox within the EMC. We’ll select a migrated mailbox that had full access permissions granted to another migrated mailbox, then right click and choose Manage Full Access Permission:

Figure 8: Viewing Full Access permissions on a migrated mailbox

Then, we’ll examine the list of permissions applied to the mailbox. As you’ll see the mailbox permissions have been retained after migration:

Figure 9: Confirming Full Access permissions are retained post-migration

It’s little things like this that go a long way to making moves between Office 365 and Exchange 2010 an easier experience for administrators and help ensure that users can continue to work properly after mailbox migrations.

Client Experience

Before mailbox migration it’s safe to assume that for most organizations, clients including Outlook will be connected to Office 365 and users will access mailboxes. For our example scenario, both users are using Outlook 2013 to access their mailbox, and we’ll be able to confirm this is set up correctly by selecting File within Outlook to show the Outlook Web App URL:

Figure 10: Backstage view in Microsoft Office showing the Outlook Web App URL

After a successful mailbox migration, the client experience is similar to traditional mailbox moves as the client will be notified that a change has been made, and Outlook needs to be restarted:

Figure 11: End-user Outlook Prompt

However as this isn’t a Hybrid migration, it’s possible that the underlying AutoDiscover service that assists with reconfiguring the mailbox may not complete successfully. In the first instance, navigating to File>Accounts Settings and then choosing Repair will reconfigure the mailbox correctly:

Figure 12: Attempting to repair an Outlook account

However, especially for non-domain joined clients, this experience may not work correctly. Therefore it’s important to either test this process before attempting with users so you can ascertain whether you’ll need to manually reconfigure Outlook clients after migrating mailboxes.

Other clients, such as ActiveSync, IMAP and POP3 clients will need to be reconfigured manually and to avoid problems, removing and re-adding accounts is recommended.

Finally Outlook Web App users will need to be informed of updated URLs for accessing email. A Hybrid configuration (which we will detail in the subsequent parts of this series) includes Organization Relationships, which have URL references to the opposite Outlook Web App URL, providing users with a new URL post-migration. This kind of simple migration doesn’t include the hybrid setup and therefore Office 365 isn’t aware of where to suggest end users should look for access to OWA.

Summary

In the first two parts of this series we’ve looked at how easy it is to move a small number of mailboxes from Office 365 to Exchange 2010. Even with no Hybrid configuration, Directory Sync or common email domains we can simply create some local users, match some attributes and initiate mailbox moves.

In the next part of this series we’ll begin to look at the more complicated scenario and implement directory synchronization and hybrid components against an existing Office 365 tenant with the aim of moving all mailboxes back, then decommissioning our Office 365 tenant.

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

• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 1)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 3)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 4) 
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 5)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 6)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 7)
• Migrating a standalone Office 365 tenant to Exchange 2010 (Part 8)