How to properly offboard mailboxes from Office 365 back on premise in mixed environment

This post is to archive all my issues I have found so far during this project.

First impression is that there is a lack of information regrading offboarding Office 365 mailboxes back on prem and if there is any, it doesn’t contain much details or proper explanation. At this point I will try to explain all my findings in details and as much simple as I can.

If you will have any questions just ask in comments and I will try to answer as fast as I can.

This is my scenario of offboarding Office 365 mailboxes back on premise.

My environment contains:

  1. Two datacenters – one in EU – Europe – and one in NA – USA
  2. Office 365 tenant with ~880 mailboxes – ~8TB of data – EU based tenant.
  3. On premise mixed Exchange environment – 2010, 2013 – ~1600 mailboxes
  4. Datacenter Site A – All servers are Exchange 2010 RU7 on Windows 2008 R2
    1. Two EDGE servers load balanced – W2008R2
    2. Two CAS/HUB servers – CAS Array – load balanced – W2008R2
    3. Two MBX servers in DAG – W2008R2 – ~800 mailboxes
  5. Datacenter Site B – mixed Exchange 2010 and 2013, seven Exchange 2010 RU7 on Windows 2008R2 and one Exchange 2013 CU10 on Windows 2012R2
    1. Two EDGE servers load balanced – W2008R2
    2. Two CAS/HUB servers – CAS Array – load balanced – W2008R2
    3. Two MBX servers in DAG – W2008R2 – ~800 mailboxes
    4. One CAS/MBX server with one database – Public Folder database – W2008R2
    5. One CAS/MBX server with one database – Hybrid server – W2012R2

My first migration strategy – !!! WRONG WAY – DIDN’T WORK !!! – O365 -> specific 2010database

All Office 365 mailboxes must go to particular site depends on user location – EU and APAC users to EU datacenter, NA and SA users to NA datacenter.

My first strategy was to migrate all Office 365 mailboxes back on premise to particular site depends on users location.  Based on what I have found and read at the time on the internet I have created new migration end point using my mailbox which was seating on Exchange 2013 database. When I was creating new migration end point I was using Office 365 Exchange Admin Center portal and I was following the wizard using my personal mailbox which  automatically used Autodiscover settings and resolved MRSProxy URL to my Exchange 2013 server – mail2013.mydomain.com and I used my Domain/Exchange admin account. After my new migration end point was created I have started creating migration batches using this endpoint and I have pointed the batch to one of my Exchange 2010 databases. When I have started my migration batch I have immediately received an error saying something like that “your target database is not compatible and your mailbox cannot be migrated”.

My second migration strategy – !!! WRONG / LONGER WAY !!! – O365 -> Exchange2013 database -> specific Exchange2010 database

On the next step I have created new migration batch using my new migration end point and this time I have pointed my migration batch to my Exchange 2013 database. This time when I started my migration batch I have had no errors at all.

After 6 weeks of migrating mailboxes from Office 365 back on premise I have realised that my migration project is running very slow (1.5 TB in 6 weeks) and it is very complicated as it involves me to create another few steps – I had to create migration batches from Exchange 2013 database to particular Exchange 2010 database each time my O365->2013 batch was finished.

Can you feel the mess I was dealing with for last 6 weeks;) ???

Step 1 – migrate 10 mailboxes from Office 365 to on premise Exchange 2013 database.

Step 2 – migrate mailboxes from on premise Exchange 2013 to specific Exchange 2010 database.

Believe me, Nightmare !!!

Additional to this my environment contains LYNC 2013. Another NIGHTMARE !!! Imagine this, I have moved mailbox form Office 365 back to on premise Exchange 2013 database. When I tried to move this mailbox to specific Exchange 2010 database as a step 2, I have received warning saying “If you will migrate this mailbox to Exchange 2010 you will lose Unified Contacts” what the what ??? I started digging and reading about this error and found the solution but as I couldn’t make any changes to my Lync environment – it is managed by different team – I had to add additional step to my project. Every time my Office 365 mailbox was moved to Exchange 2013 database I had to send this information to my Lync team and ask them to run Invoke-csucsRollback -Identity emailaddres@mydomain.com cmdlet and wait when it’s done. Once it was done I could restart my migration batch and mailbox start moving from Exchange 2013 database to specific Exchange 2010 database with no warnings or errors.

Below generic idea presented in graphic

My third migration strategy – !!! PROPER WAY !!! – O365 -> specific 2010database

After a while I have started thinking and reading more about offboarding form Office 365 and I have finally found the proper solution. The whole idea is  to create proper migration end point which will be pointing to the right MRSProxy URL on Exchange 2010 CAS server instead of Exchange 2013 server.

I have created new migration end point using my temporary mailbox which is seating on Exchange 2010 database in site A and I have created new migration batch which is pointing straight to my Exchange 2010 database in site A. When I started my migration batch, it started straight away and no errors at all !!! No additional steps involved, no mess, no LYNC team involved anymore and it is faster than O365->2013->SiteA2010 or SiteB2010.

Migration plan – current – proper:

  1. Create new temporary mailbox on each site: tempmbxNA@mydomain.com in NA DAG and tempmbxEU@mydomain.com in EU DAG
  2. Logon to your Office 365 tenant portal
  3. Create new migration end point using tempmbxNA mailbox
  4. Create new migration end point using tempmbxEU mailbox
  5. Create new migration batches for users based in NA and SA using NA migration end point
  6. Create new migration batches for users based in EU and APAC using EU migration end point

 

 

In my next post I will explain all catches I have found while renewing SSL certificates in my whole Exchange environment – it was fun as well !!!

Published by

Tomasz Chlebek

IT Architect with over 20 years experience.