Blog

The latest from our experts.

Migrating Mailboxes to Office 365

Things to watch out for when migrating mailboxes from on premises Exchange to Office 365

When moving mailboxes from on premises Exchange to Office 365 using a Remote move scenario and a Hybrid server, the process is fairly simple and very user friendly.

Similar functionality is included in staged and cutover scenarios but there are some things you can only do with a Hybrid server on premises. Here is the article that explains all the limitations of the different methods.

3 things that a Remote move scenario allows are:

1. Automatic Outlook redirection and configuration after the mailbox moves.

As long as Auto Discover is setup properly, Outlook clients will experience very little disruption after the mailbox finishes moving to Office 365. Usually, it is a pop up window that says, “Your Exchange Administrator has made a change that requires you to restart Outlook.”

The user then closes Outlook and re-opens Outlook. After a minute, they may see another pop up with the same message. After closing Outlook and re-opening one more time, they should be configured properly and connected to Office 365. What is happening on the backend is fairly straight forward. The mailbox move process flags the mailbox and changes it to a Remote Mailbox with a remote routing address of domain@domain.mail.onmicrosoft.com (depending on the version of Exchange on the Hybrid server the remote mailbox may be labeled differently). Outlook sees this change and attempts to Auto Discover the new configuration information. When the remote routing address is found, it attempts another Auto Discover with that address and resolves the needed configuration information from Office 365.

Some phones will also use Auto Discover to resolve the needed settings after the mailbox moves.

2. Remote move is almost identical to a mailbox move on premises.

It will move all contacts, tasks, journals, calendar entries, etc. It will also strip any corrupt items (depending on the corrupt item limit set for the move). Other methods such as an IMAP migration will only sync email and all other items in the mailbox will need to be imported another way.

3. Using a remote move scenario with a Hybrid server allows for mailboxes to be migrated back on premises if necessary.

The ability to test mailbox moves and move them back on premises if an undesired result happens, is a nice feature. In situations where a mailbox was moved to Office 365 and an on premises application used it for something, you can simply move the mailbox back on premises and then make any needed changes and test, before migrating it back to Office 365.

What Doesn’t Migrate Properly

Here is a brief list of things that DO NOT migrate with the mailbox properly to Office 365. While this list is in no way exhaustive, and Office 365 is changing all the time, I think it is helpful to know these ahead of time.

1. In Policy Booking settings.

In Policy booking settings will not exist after a resource mailbox with these settings configured is migrated to Office 365. It is important to export all of these settings before any resource mailboxes are moved. Here is a command I use to grab this information.

get-mailbox -ResultSize unlimited | ?{$_.recipienttypedetails -eq “RoomMailbox”} | get-calendarprocessing | select identity, bookinpolicy | export-csv roompolicies.csv –notype

2. SMTP Forwarding settings.

SMTP forward settings will not be migrated when a mailbox is moved to Office 365. You should run a command to export all of these settings and re-apply them after the mailbox is moved. Here is a command I use to grab this information.

Get-Mailbox -resultsize unlimited | Where {$_.ForwardingAddress -ne $null} | Select Name, PrimarySMTPAddress, ForwardingAddress, DeliverToMailboxAndForward | Export-Csv c:\export\ForwardingInfo.csv –NoTypeInformation

3. Nested Security groups.

Nested security groups may cause problems for users that are migrated to Office 365 and access on premises mailboxes. While the user can add the mailbox and access it normally after migrating, they may have issues modifying categories on meetings or sending as or on behalf of a user. I have found that assigning the user explicit Full Control rights will correct this behavior for most scenarios except Send As. Officially, Microsoft does not support Send As with an on premises mailbox and an Office 365 user as described here.

Cross-premises Permissions
We do not support cross-premises permission scenarios. Permissions are only migrated and functional when implementing an Exchange hybrid deployment if there are corresponding directory objects in Exchange Online.

Additionally, all objects with special permissions such as Send As, Receive As and Full Access must be migrated at the same time. This also means that to migrate these permissions, you must make sure directory synchronization has completed before you start moving mailboxes.

Unofficially, I have seen it work properly when this command is used to configure Send As rights on the on premises mailbox.

Add-RecipientPermission UserA@domain.com -AccessRights SendAs -Trustee UserB@domain.com

Either way, it is recommended you group users together so shared mailboxes or resource mailboxes are moved when the users that need access to them are moved.

Hopefully, this will help you have the smoothest migration process and user experience as possible while migrating to Office 365.

By | 2017-05-07T07:26:54+00:00 September 11th, 2014|Cloud Architecture|5 Comments

5 Comments

  1. Naveen Singh February 1, 2016 at 12:32 pm

    Very Very Good..!!
    Excellent Article..!!

  2. Najeeb February 19, 2016 at 7:21 am

    does this still apply?

    • Kiara Rodemaker February 19, 2016 at 9:40 am

      Yes, it does!

  3. Tuh August 11, 2016 at 3:13 am

    Thank you for the command to set the send-as rights, it helped me alot today 🙂

  4. Arjen Robben September 28, 2016 at 9:45 am

    Appreciate it for sharing your awesome web page

Comments are closed.