The following prerequisites must be in place to carry out a staged migration.
- A directory sync server must be configured to synchronise on-premises users to Office 365. See here for instructions.
- Your Office 365 tenant organisation must have the domain of your on-premises organisation as an accepted domain i.e add the domain to Office 365 within the portal.
- Confirm Outlook anywhere is working on your on-premises Exchange deployment
- In my scenario I was migrating from Exchange 2003 and Outlook Anywhere was not configured. I used the guide here. The only comments I would make are the
- registry entry HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\RPC\RPCPROXY requires the NetBIOS name, internal FQDN and external FQDN (if they’re different) and NTLM authentication is required on the RPC virtual directory and within Outlooks proxy settings; these seems to be true when using Outlook 2010, I haven’t tested other clients.
- To confirm Outlook anywhere is working use the Microsoft Remote Connectivity analyser: https://testconnectivity.microsoft.com/
- Create an on-premisesuser who will be the migration administrator; this user can be either a domain admin or assign the user full access to the mailboxes and modify the writeProperty permission on the TargetAddress. The TargetAddress security can be modified using ADSIedit.
- Lower the TTL of the MX record for the domain you’re migrating.
- Tell the users that their mailbox is being migrated. Depending on your user base Outlook Web App may be suffice if not an autodiscover record should be created but could cause issues.
- Export the user account email addresses from Active Directory using csvde e.g. csvde -f c:\output.csv -r “(&(objectCategory=person)(objectClass=user)(mail=*email.domain.name))” -l “mail”. The default header is mail but for the migration it must be emailAddress.
Create a migration end point
Login to the Exchange Administration Center and select recipients, then migration, then the plus sign and migration to Exchange On-line.
Select staged migration.
Enter the credentials of the on-premises account which has access to all mailboxes being migrated; this is either the domain admin or the user created in prerequisite step no. 4.
Specify the internal FQDN of the Exchange server and RPC proxy i.e. the public FQDN used when connecting via Outlook Anywhere.
Name the migration e.g. maybe you’re migrating users with surnames A-G then maybe Exchange2003MailboxesAtoG.
The status of the migration can be viewed from within the Exchange Admin Center.
At this point the TargetAddress attribute of the users you’re migrating is modified to email@example.com.
Depending on the size and number of items it may be best to plan migrations over a weekend or may be an evening would suffice e.g. in my experience a 3.8GB mailbox took around 3 hours over a 5Mb connection.
If your user would like to be able view new incoming emails straight away then point them to Outlook Web App, configure their mobile device to use Exchange On-line or configure a new Outlook profile to utilise the Exchange On-line. If you opt for a new Outlook profile a few points to remember:
- Outlook 2010 or 2007 client needs to be at least SP1 and SP3 respectively
- Outlook 2010 and earlier client require the desktop setup to be run; pretty sure this installation requires a reboot too.
- An autodiscover record should exist too; existing users should not see any problems unless you have to reconfigure their Outlook profile.
Once the migration is complete you’ll receive an email like the one below.
The migrated users’ on-premises mailbox-enabled accounts should be configured as mail-enabled accounts; Microsoft have a number of scripts to streamline this process which can be found here.
The script: ExportO365UserInfo.ps1 requires PowerShell to be installed, the synopsis of the script is as follows:
- Create and connect to a remote session of Exchange On-line
- Import the migrated users
- Using the migrated users email address get the Exchange Distinguished name, cloud email address and on-premises email address
- export the above to a csv.
The script: Exchange2003MBtoMEU.vbs requires the output of the PowerShell script above, Microsoft Exchange management tools and a FQDN of a domain controller. The synopsis of the script is as follows:
- Import information from csv file created by the script above
- Collect information from Active Directory
- Adds x.500 addresses and distinguished names to a proxy list
- Deletes the users mailbox
- Mail enables user using information collected earlier
Once your batch is complete, delete it from the migration section of the Exchange Admin Center.
Switch MX to Exchange On-line; this can be viewed within the Office 365 portal. Login go to domains, select the domain, then select view DNS settings, then select View DNS records.
Upgrade to Exchange 2010 and then remove the Exchange 2003 installation. Guides on Microsoft TechNet:
Understanding upgrade from 2003 to 2010:
Removing Exchange 2003: