If you would like to read the other parts in this article series please go to:
Introduction
In part 1 of this article series, we took a walk down memory lane, when it came to Exchange Online migration options back when Exchange Online was Exchange 2007 based and part of the BPOS suite.
In this part 2, we will continue where we left off in part 1. More specifically, we will look closer at the migration options that were available with the next version of Exchange Online, which was included with the rebranded offering that going forward was and still is known as Office 365.
Let’s get going…
The First Office 365 Wave Announced…
The BPOS suite was far from a perfect cloud offering. The primary reason being that the Software as a Service (SaaS) products that was included was developed with on-premises scenarios in mind. For instance, Exchange 2007 was never planned as a cloud Exchange service shared by thousands of customers. Although it was among the first Microsoft products to be based on PowerShell, this version did not support remote PowerShell. Also, scalability and sizing wise, this version was never optimized for cloud service purposes.
With the next version (vNext) of Exchange, the product group knew that they needed to build it for on-premises as well as cloud purposes.
Back in November 2009, Microsoft released Exchange Server 2010 RTM to its on-premises customers. In October 2010 a private beta program was established for select enterprise customers so they could test the next version of BPOS which in April 2011 reached general availability and rebranded as Office 365.
Figure 1: The first version of the Office 365 Admin Portal
Since Office 365 was basically a complete new infrastructure existing BPOS customers has a year to plan the migration from BPOS to Office 365. This of course included migrating from the 2007 version of Exchange Online to the new Exchange 2010 based Exchange Online service. Since there were no direct migration tools that could migrate mailboxes from the old Exchange Online version to the new, Microsoft was involved in this migration and was very busy assisting and fixing reported issues for the customers that had been given one year to migrate to Office 365.
Migration Options to the Exchange 2010 based Exchange Online Service
With the Exchange 2010 version of Exchange Online, the following migration methods was available with the use of native tools included with Exchange 2010.
Staged Exchange Migrations
The primary target for a staged Exchange migration was medium organizations that wanted to move mailboxes to Exchange Online over a period of time. With this migration approach, you configured simple coexistence (mail flow between Exchange on-premises and Exchange online. In addition, you had two identical global address list (GAL) one on-premises and one in Exchange Online, so that end users could look up their migrated colleagues and vice versa.
To provide end users with a unified GAL in a staged Exchange migration scenario, you set up directory synchronization (DirSync) and if single sign-on (SSO) was required, you deployed Active Directory Federation Services (AD FS) 2.0 farm and federated the respective domains. So an Exchange Cutover migration approach (next one listed), you would need to deploy and configure AD FS servers and a Directory Synchronization server prior to performing the actual migration. The on-premises mailbox users would need to exist as mail enabled users in Exchange Online just like is the case nowadays.
It’s worth noting that this migration model only supported Exchange 2003 and Exchange 2007 as source environments and not Exchange 2010. The reason for this was because of NSPI specific code changes made in Exchange Online resulting in not being able to use the Outlook Anywhere protocol with Exchange 2010 servers on-premises. In addition, the staged Exchange migration approach wasn’t supported with Office 365 Professional and Small Business plans only Enterprise plans.
In order to create migration batches, you exported on-premises users to a CSV file and uploaded to the tenant using the “E-Mail Migration” tool in the Exchange online Portal.
Figure 4: Exporting mailbox users from Active Directory to a CSV file
Figure 2: E-Mail Migration tool in the Exchange Control Panel (ECP)
Figure 3: Migration Batch in the E-Mail Migration tool in ECP
A major disadvantage of the staged Exchange migration approach is you had to convert the on-premises mailbox user to a mail enabled user using a PowerShell script since the E-Mail migration tool wasn’t capable of performing this write to the Active Directory via the Outlook Anywhere protocol.
In order to do this, you had to first run a script against Exchange Online, which would dump the users and respective attribute data to a CSV file.
Figure 4: Script connects to Exchange Online for the respective Office 365 tenant and collects required information
Based on the CSV file, you would then need to convert the on-premises mailbox users to mail enabled users using another script.
Figure 5: Converting mailbox user objects to mail user objects using the Exchange2007MBtoMEU.ps1 script
The Outlook clients would now get a “The Microsoft Exchange administrator has made a change that requires you to quit and restart Outlook”, which is fine in itself. Unfortunately, though, there were also a major disadvantage of the stage Exchange migration approach seen from the end user perspective. Because the mailbox GUID is not preserved for the mailbox in Exchange Online, after Outlook had been restarted the user would get the dialog box shown in Figure 6. In order to fix this annoying behavior, the Outlook profile would need to be repaired.
Figure 6: Dialog box when you do not create a new Outlook profile
As you can see the staged Exchange migration provided many great things, but it also had and still have some severe admin as well as end user annoyances.
Back in 2012, I did an extensive write-up on the staged Exchange migration steps, which you can find here, if you want to get extra nostalgic.
This concludes part 2 of this multi-part article series.
