Office 365 Offboarding: Reverse Hybrid Migration to Exchange 2016 On-premises

Why would anyone want to off-board mailboxes from Office 365 to Exchange On-premises? Isn’t that a bit like moving backwards? Well, I tend to think so, yes–at least in the SMB.  But what happens when a mid or larger-sized enterprise organization eats a smaller-sized business through acquisition?

In this scenario, it is not uncommon for IT at the “adoptive parent” organization to be running their own flavor of Exchange on-premises already–such as Exchange 2013 or Exchange 2016.  If so, Microsoft has a great migration path available to bring the acquired/adopted Office 365 mailboxes back down to this environment.

Yes, you could just do a PST export/import and cut-over DNS records the sloppy way–and that might be just fine, particularly if the number of users is very low.  But there is a better way allowing administrators to take a more careful, staged approach.

If you are familiar with the “hybrid” or “remote move” migration for on-boarding mailboxes, you will be glad to hear that the same is possible in reverse–you can also offboard using the same technique!  Here are my notes from having done one myself recently.

Step 1: Prepare the environment

A. Add the Exchange Online IP’s to the exceptions list in your parent organization’s firewall, explicitly allowing traffic from these IP’s on port 25 inbound to the local Exchange server.

B. Add the external IP address(es) of the parent organization to the SPF record on the child organization’s domain. E.g.:

v=spf1 ip4:xx.xx.xx.xx include:spf.protection.outlook.com -all

C. In the parent organization’s Active Directory Domains & Trusts console, add the alternative UPN suffix for the child org’s domain name.

D. Add a new remote domain name to Exchange on-premises in the parent organization, which will eventually be used by the hybrid connection. E.g. TenantName.mail.onmicrosoft.com:

New-RemoteDomain -Name “Hybrid Domain – TenantName.mail.onmicrosoft.com” -DomainName “TenantName.mail.onmicrosoft.com”

Set-RemoteDomain -TargetDeliveryDomain:$true -Identity “Hybrid Domain – TenantName.mail.onmicrosoft.com”

E. You will also need to ensure that your on-premises Exchange server has the child organization’s domain added to the accepted domains list.  EAC > mail flow > accepted domains. This will temporarily interrupt mail flow between the on-premises parent organization and the Office 365 tenant / child organization.

Step 2: Export & Import users, contacts and distribution groups

If you want to see a really cool set of scripts that will allow you to export and then import the accounts from Office 365 into the local Active Directory, see this series of articles from Exchange MVP Steve Goodman.

If you choose to manually create your users, etc. in advance in the on-premises directory, I recommend doing so in a separate OU (it will be necessary to select this OU when syncing with Azure AD Connect later on). Some key pieces of information here:

• No on-premises mailboxes should exist for the users that will be migrated from Office 365–create the AD accounts only at first
• Be sure that the on-premises UPN for usernames matches precisely the logon name that is used in Office 365
• It is further recommended to match:
  • Email address,
  • Display Name and
  • proxyAddresses (multi-valued attribute)–you will want to capture all aliases in advance–including any SIP and legacy X500 style addresses before syncing
• The “targetAddress” attribute for these accounts should be set to the following address: [email protected]
• You will need to create Exchange objects to be associated with these accounts as well, but they will not be local mailboxes, they will be “Remote” mailboxes using the “New-RemoteMailbox” cmdlet.
• Finally, you also will need to find the ExchangeGUID property by connecting to Exchange Online via PowerShell and running the command
  Get-Mailbox [email protected] | fl ExchangeGUID
  You will then need to set the ExchangeGUID attribute on the on-premises account. See here for more details on this process.

Again, because of the complexity/tediousness of doing this all manually, I would highly recommend the resource I mentioned above. I personally used the scripts provided by Steve Goodman, and the process went very smoothly–we only had a handful of corrections to proxyAddresses (such as missing X500 entries).  It is very important that you have matching information precisely input to the local Active Directory before proceeding to Step 3, since activating Directory Sync will overwrite whatever information is attached to those accounts in the cloud, with whatever you have coming from the on-premises AD.

By the way, if you choose to activate password sync, then this also implies that Office 365 passwords will be overwritten as well, to match whatever you have set for the users on-premises. Be sure to communicate this impact to them in advance of the change, but know that enabling password sync is also optional here.

Step 3: Activate Directory Synchronization

At this point, you are ready to install and Activate Azure AD Connect.

But wait, Alex–what if my parent organization is already using Azure AD Connect to synchronize their directory with another Azure AD tenant?!

No problem.  All you have to do is install the tool on a different server (not the same location as the existing installation).  Then, configure it to sync with the child organization’s tenant, and select the option to only sync objects from the OU containing the appropriately pre-staged items.  Ensure also that the new OU is not included in the scope of objects being synced in the parent org’s existing tenancy.

Step 4: Run the Hybrid Wizard and re-establish mail flow

Now you can download the Hybrid Configuration Wizard and run it. This will establish a relationship between the on-premises Exchange server and the Exchange Online instance.  Connectors will be created that will help pass mail from/to Exchange online.

You may also need to edit the accepted domain that was added earlier and change it from “Authoritative” to “Internal Relay.”  This means that if the server does not yet own or is not aware of a mailbox, it will pass messages along to Office 365. Also, if you had verified other domains in the child organization’s tenant (such as the parent organization’s main email domain), then the same will need to be done in Exchange Online. Navigate in the portal to accepted domains, and edit the domain type from Authoritative to Internal Relay for domains with mailboxes that exist on-premises.

Test mail flow in both directions.

Step 5: Migrate mailboxes

It is possible to do this step either before or after changing DNS records to point on-premises (although flipping this in advance is recommended). In Exchange Online from the EAC, you can find recipients > migration. Select the ellipses and add a Migration endpoint. You need to define the fqdn of the on-premises (parent org) server.  After the endpoint is defined, you can start migrating mailboxes by choosing the “plus” (+) symbol, Migrate from Exchange Online. You will select the mailboxes you intend to migrate, and specify a target database (you should get the database name from the server with Get-MailboxDatabase). Fill out a few other options and you’re all set–migration batches should start moving.

Conclusion

This is a fairly straightforward process that allows administrators to provide a decently smooth transition from Office 365 back to an on-premises instance of Exchange Server 2013 or 2016.  Keep in mind that until you flip autodiscover, MX records, etc. over to the on-premises server, you may need to manually configure profiles in Outlook and on mobile devices (to use the on-premises server). Otherwise, you can treat it much like a cut-over with a small enough group of users, and do this all at once with DNS records and all, allowing the users then to simply remove and re-add their accounts on their mobile devices, and let autodiscover take care of the rest, for example.

I did not go super heavy on detail here–my goal was simply to show in broad strokes what is required to do this end-to-end. More experienced readers will have no trouble following this outline and completing a migration, but I really do recommend the series by Steve Goodman which I linked above–it has much more granular step-by-step detail and some excellent scripts to go with it.