Performing a Staged Exchange Migration to Office 365 (Exchange Online) 

Introduction

It’s a fact that more and more organizations are making, or at least are considering making, the move from an on-premise messaging environment to Exchange Online (part of Office 365) in the foreseeable future. The migration path from an on-premise messaging environment to Exchange Online will differ based on things such as size of the on-premise environment, number of users, the messaging environment an organization is migrating from as well as the expectations revolving around coexistence.

So if we leave third party migration solutions out of the picture, we really have four different migration approaches at our disposal:

• Exchange Cutover migrations
• Staged Exchange migrations
• Hybrid Exchange Deployment-based migrations
• IMAP-based e-mail migrations

In this particular multi-part article series, I’ll go through the steps necessary to perform a staged Exchange migration to Office 365 (Exchange Online). The other migration approaches will be covered in another set of articles here on MSExchange.org.

Ok so the primary targets for a staged Exchange migration are medium organizations that wish to move mailboxes to Exchange Online over a period of time. With this migration approach, you configure simple coexistence (mail flow between Exchange on-prem and Exchange online as well as a shared global address list (GAL)). It’s worth noting that this migration model only supports Exchange 2003 and Exchange 2007 as source environments not Exchange 2010. In addition, it’s worth noting the staged Exchange migration approach isn’t supported with Office 365 professional and small business plans.

To share the GAL in a staged Exchange migration scenario, you set up directory synchronization (DirSync) and if single sign-on (SSO) is required, you deploy Active directory Federation Services (ADFS) to achieve this. So unlike when using the Exchange Cutover migration approach, you set up ADFS and DirSync prior to performing the actual migration.

Note:
If you require rich coexistence (free/busy & calendar sharing), MailTips integration (between Exchange Online & Exchange on-premise), Exchange Online-based online archiving support, mailbox offboarding functionality (move mailbox back to Exchange on-prem) as well as the option to manage Exchange Online users using the on-prem Exchange Management Console, you must use the hybrid Exchange deployment-based approach. With this approach you deploy one or more Exchange 2010 servers in your Exchange 2003 or Exchange 2007 on-premise environment and then configure coexistence using the Hybrid Configuration Wizard (HCW) that was introduced with Exchange 2010 Service Pack 2. I’ll cover this migration approach in another multi-part article series here on MSExchange.org in a not so distant future.

When performing a staged Exchange migration, the e-mail data is migrated to Exchange Online using the e-mail migration tool that lives inside the Exchange Online version of the Exchange Control Panel (ECP). This tool is based on the Outlook Anywhere (RPC over HTTPS) protocol so prior to beginning the migration, it’s vital that both autodiscover and Outlook Anywhere work properly in your Exchange on-prem environment.

Lastly, as most of you know, Office 365 not only consists of Exchange Online but also Lync Online and SharePoint Online. However in this article series we only focus on the Exchange side of things. Said in another way, the steps required to set up and “migrate” Lync Online and SharePoint Online are outside the scope of this article series.

Overview of the Lab Environment

The lab environment used as the basis of this article series consists of the following servers:

• 1 x Windows Server 2008 R2 Domain Controller (AD Forest name: onpremise.dk)
• 1 x Exchange Server 2007 Service Pack 3 multi-role (CAS/HUB/MBX) server
• 1 x Windows Server 2008 R2 domain member server (for DirSync purposes)

Note:
In this specific lab environment, we will NOT deploy ADFS in order to achieve single sign-on, but instead rely on the the Microsoft Online Services Sign-In Assistant (MOS SIA), which provides an end user with sign-in capabilities to Office 365.

Creating an Office 365 Tenant

Okay so the very first thing we want to do is to create the Office 365 tenant. You can create a trial athttp://www.office365.com. After having filled out the form and chosen an Office 365 tenant name, you receive an email containing the Office 365 portal link and other information such as tenant name, service plan and expiration date (Figure 1).

Figure 1: Office 365 Welcome Email

When you log on to the Office 365 portal, you are presented with the screen shown in Figure 2. Much like the Exchange Management Console (EMC), the Office 365 portal is split into four work centers (left pane): Setup, Management,Subscriptions and Support. You also see three or four links in the top of the page depending on whether you have been assigned an administrative role or not. Normal end users have the Home, Outlook and Team Site links while an administrator also has the Admin link.

Figure 2: Office 365 Portal

Adding a New Domain to O365

The very first thing we want to do in order to prepare for a migration of mailboxes to Exchange Online is to add our on-premise domain name (in this case “onpremise.dk”) to the Office 365 tenant. To add a domain to an Office 365 tenant, click “Domains” under the Management work center. On the “Domains” page, you see the default “domain.onmicrosoft.com” domain listed.

Figure 3: Domains section in Office 365 portal

Click “Add a domain” and then specify the domain you wish to add as shown in Figure 4 then click “Next”.

Figure 4: Specifying the domain you wish to add

Office 365 now needs to verify that you actually are the owner of this domain. This can be done using two methods. One is to add a TXT record to the public DNS server hosting your domain (recommended approach) and the other is to add an invalid MX record. In this article, we use the TXT record-based approach.

Figure 5: Instructions for verifying the added domain

To add a TXT record, logon to the DNS control panel at your DNS hosting provider then click ”Add TXT record” or whatever it’s called in the web UI you’re using. The steps differ a bit from provider to provider, but basically, you need to add a host name and the ”Destination” for that host name as shown in Figure 6.

Figure 6: TXT record added in the DNS Control Panel at public DNS provider

After having added the TXT record go back to the Office 365 portal and click the ”Verify” button. Since it can take up to 72 hours for the TXT record to propagate throughout the DNS systems, you will most likely receive the error message shown in Figure 7. So now is a good time to have a break and do something else.

Figure 7: DNS verification for domain failed

When Office 365 can verify the domain successfully, you are taken to the page shown in Figure 8. Here you can specify which services you wish to use with the domain. Make sure you at least select ”Exchange Online” and then click ”Next”.

Figure 8: Specifying the services for which the domain is to be used

The domain has now been added to the Office 365 tenant and at this stage you can either select to ”Configure DNS settings” or click ”Close”. Since we do not want to direct SMTP traffic directly to Exchange Online or change the autodiscover DNS record yet, click ”Close”.

Figure 9: The domain has now been added to the Office 365 tenant

We’re taken back to the domain list, and here we can see the status for the domain has changed to ”Verified”.

Figure 10: Domain has been verified successfully.