How to: Express Migration to Office 365 Exchange OnlineAlex Fields
For a long time, I have been advocating for hybrid style migrations from Exchange On-premises to Exchange Online with Office 365, regardless of whether you are a small, medium or larger-sized enterprise. The reason being, it is a much better end user experience, and does not require manual reconfiguration of Outlook clients.
A seamless switch-over experience can also be achieved with third party tools, but if you are coming from On-premises versions of Exchange 2010 or Small Business Server 2011, for example, there is no reason not to take advantage of hybrid, saving money for other projects and initiatives. Even with Exchange 2007, it would be possible to install a 2013 server to act as a temporary hybrid “bridge” so to speak–and I do this all time.
New Express Migration method for Small Businesses
For small businesses, the argument/complaint I always hear is that setting up a hybrid relationship with Exchange Online is “too complex,” and thus we have many people opting for more manual methods such as PST export/import or cut-over. Those are okay migration paths, but I personally think that it is more work in most cases than just setting up the hybrid scenario.
It seems that Microsoft now agrees with me–hybrid is going to be an easier path for most small businesses with the addition of “Express migration” to the list of options. So, the argument that “hybrid is hard” will no longer be valid.
Here is a link to the blog post from Microsoft announcing and describing this new option.
However, I find it is a bit lacking in some of the detail required for both preparation and execution/finalization of the mailbox moves. So, to rectify, here are some “cliff notes” to help you:
Step 1: Prepare for the migration
If you haven’t already, go ahead and sign up for an Office 365 subscription online and verify your domain.
Next, ensure that your external domain name is added as an Alternative UPN suffix in AD Domains & Trusts. Right-click Active Directory Domains and Trusts, and select Properties. Enter your email domain name and click Add. Click OK.
The reason you do this is so that you can be sure that your on-premises users have their UPN suffix set to match the email domain name (e.g. company.com instead of company.local). In Active Directory Users & Computers, check the Properties / Account tab on your users:
Note: For best results, the naming convention of the user accounts should also match the Email addresses (e.g. [email protected] vs. domain\MJohnson). If this type of change is required in your environment, it may affect how users log on to Windows in the existing domain.
Last, as always, make sure you are up-to-date with the latest service pack & update rollups for Exchange (SP3 at the time of this writing, for Exchange 2010).
Step 2: Begin migration steps from the Office 365 portal
Navigate to Users > Data migration and choose Exchange. This requires that you already have SBS 2011*, Exchange 2010, Exchange 2013 or Exchange 2016. You will be prompted to download and run the Hybrid Configuration Wizard. This must be run from inside the on-premises network where the Exchange server lives, on a domain-joined Windows computer or member server.
*For SBS, you must still install a hybrid 2013 or 2016 server between SBS and the 365 cloud to act a bridge–as previously described on my blog.
Step 3: Hybrid Configuration Wizard & Azure AD Connect Setup
This process is pretty well covered by Microsoft, and I don’t need to repeat it here. Basically you can select the defaults in most cases, selecting Minimal Hybrid Configuration, and the option to Synchronize users & passwords one time. Just be sure to run this against a member server, not on the domain controller (it is not supported to run the Azure AD Connect tool on SBS anyway–so be sure it is a 2012 R2 or 2016 member server).
When you select Minimal, you are enabling the “Express” migration features, but you won’t have super rich co-existence like you get with a full-on hybrid. If you have a small number of mailboxes (like 50 or less), and plan to move all users very quickly, then this is perfect.
I also like the option to synchronize users & passwords one time, which will basically install Azure AD Connect for the purposes of migration, running just one sync (instead of having the sync be perpetual–which is what happens if you choose to set it up on your own).
The one-time option is ideal, because it leaves an open choice for you to pick how you want to manage identity & passwords after the migration is over–you will not be locked into a hybrid environment. Some small organization admins would rather not keep a hybrid Exchange server around forever–and that’s okay with this option, because you will be able to remove your legacy Exchange server completely, if you so choose, without replacing it. If you do decide to keep Azure AD Connect installed separately and syncing, you will also need to have an Exchange server for management purposes.
Note: You can choose one of three methods to manage users when you are done with this migration:
- Cloud-only: Just remove your Exchange server after the migration is over. You can then manage new users, passwords, etc. in the cloud through the Office 365 portal (no more connection with on-premises accounts)
- Microsoft Essentials Dashboard Integration: Enable this integration to synchronize passwords and have on-premises tools for administering users & mailboxes, without an Exchange Server.
- Azure AD Connect: This tool can be installed and activated again if you so choose, which also requires a long-term on-premises Hybrid Exchange server to remain in place. This will synchronize passwords or allow you to choose other options such as Single Sign-On.
Step 4: Add licenses to the users in the cloud
Here is one place Microsoft’s article misses a little bit, I think. They do mention that you need to license your users before migration, but that is not laid out very explicitly. After you finish setting up the Hybrid Configuration Wizard & Azure AD Connect, but before you kick off any migrations–that is the proper time to license users.
From the Office 365 Portal, go to Users. Select an active user, and choose Edit next to Product licenses.
Note: If you licensed users prior to running the HCW & AAD Connect, you will have issues with migration, because mailbox objects will already exist in the cloud, however you are only allowed to have one mailbox per user at a time between on-premises and Exchange Online in a hybrid scenario. Therefore, do not license users until the synchronization is completed, because Exchange Online will be aware of the on-premises mailbox by then (but not before), so a cloud mailbox will not be created.
Step 5: Begin migrations
This is the “exciting part”–you can return to the Users > Data migration screen, select the users you would like to migrate (they recommend starting with just a couple to validate the process), and click Start Migration.
When migration is completed, users will be prompted to close and re-open Outlook, at which point they will be reconnected to their cloud mailboxes, and prompted to authenticate using their email address and password.
Hint: if you experience continuous password prompts in Outlook after migration is completed, close Outlook. Go to Control Panel, open the Credential Manager and clear out any entries for Outlook/Office products. Open Outlook again and you should be prompted. Ensure you are using the full email address (same as would be used to sign into OWA for Office 365) and the correct password. Tick the box to “Remember password.”
For public folder data (if it exists) I usually recommend exporting this to PST from an Outlook client, and re-importing it to the cloud in the form of a public folder database, or into a simpler shared mailbox. This works 98% of the time for most small businesses, but it is not always possible. Advanced public folder migration scenarios are not covered here.
Step 6: What to do after data migration is completed
Unfortunately, that’s not the end of the story, even though the article by Microsoft makes it appear that way. There are a few things you’ll want to do in order to finalize the migration and prepare for the removal of Exchange from your environment.
A. Update DNS Records
As soon as you’ve finalized the migration, you are ready to complete the Office 365 setup process you started earlier by verifying your domain. Return to the Office 365 Admin center > Settings > Domains to complete your set up. You will be required to enter additional DNS records with your domain registrar / service provider.
Once you have added the records, mail will no longer be delivered to your on-premises Exchange server–it should go straight to Exchange Online.
On-premises, open the DNS management console on your Active Directory server. If you have existing (A) records for autodiscover, remove them first. Expand the DNS zone for your (external) email domain name, and edit or add the CNAME record for autodiscover, and make it point to: autodiscover.outlook.com
You can verify it is working by clearing the DNS cache on the server and then pinging autodiscover.yourdomain.com. It should return a value for one of the Microsoft datacenters, such as nameast, namwest, namnorth, etc.
You can add the other DNS records if you choose to use Skype for Business, Intune, etc., but these records alone would be sufficient for the purposes of email migration to Office 365.
B. Changes to Exchange Server
If you plan to retire Exchange on-premises, you will have a couple small adjustments to make to ensure that clients no longer attempt to connect to the local Exchange server, before removing it (I usually wait at least a week or so post-migration before removing Exchange completely–just in case you’re missing some data on the cloud side of things).
SBS 2008/2011 or Exchange 2007/2010
Open the Exchange Management Shell and type the following:
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.outlook.com
And press Enter.
Next, to disable Outlook Anywhere, simply type the following into your Exchange Management Shell:
Disable-OutlookAnywhere –Server <ServerName>
And press Enter. You’re done.
C. Replace SMTP relay function
You might also want to add an SMTP relay connector to Office 365, if you were previously using your Exchange server to relay mail from on-premises LOB apps, or from scan-to-email devices, etc. Office 365 can provide a relay connector to replace this functionality.
1. From the Exchange Online admin portal, go to Exchange Admin Center > Mail flow > Connectors. Use the “plus” symbol to add a new connector, choose From: Your organization’s email server and To: Office 365. Step through the wizard, specifying the external IP address(es) of your organization under By verifying that the IP address… and clicking the “plus” symbol. You can leave default values in the rest of the wizard.
2. Ensure that your spf record in DNS includes spf.protection.outlook.com as well as ip4:<YourExternalIp>:
v=spf1 ip4:[ExternalIPAddress] include:spf.protection.outlook.com -all
3. Check that your firewall allows SMTP (25) outbound from the device(s) that require access to the connector.
4. On the device itself, you will need to change the SMTP or smarthost address from the internal Exchange server’s IP to the host of your MX record (e.g. companyinc-com.mail.protection.outlook.com). You can ping this address to obtain an IP if the device only accepts inputs of IP rather than hostnames.
D. Remove Exchange Server
You can now follow uninstall procedures for Exchange. These instructions are valid for any Exchange 2007 or 2010 install.
Remember, this new “Express” method takes some of the legwork out of a traditional hybrid migration, making it an easy choice for small businesses. Also, you will have a choice to make in the end, about how you want to manage user accounts & passwords.
If you choose to add back Azure AD Connect, then you will also need to keep a hybrid Exchange Server around for management purposes. Otherwise, you can remove Exchange completely as described here, and enable password sync with Windows Server Essentials integration, as an alternative that does not require Exchange Server. Or, you can just leave everything as-is, and manage users & passwords in the cloud, separately from your on-premises environment.