Office 365 Remote Move “Completed with Warning” – Part 1

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

I’ve seen a number of different O365 forum entries on this issue, but I wanted to pull together some thoughts on what I’ve done to resolve these errors for my customers.
Normally, a mailbox remote move operation performs a copy of the on-premise mailbox content to the Office 365 mailbox. However, If the mailbox has a condition that falls outside of “acceptable Office 365 content”, such as corrupted items, large items (>25 MB), or a mailbox is too big (>25 GB) then the remote move will inevitably go to a failed state. The on-premises mailbox continues to work, Office 365 users continue to send to the on-premises mailbox, and no one is really worse for the experience – well, if you ignore the time the mailbox was unavailable to the migrating user (assuming not Exchange 2010). Really, the loser in that scenario is the administrator who will have to address the failure conditions and then attempt another move.

However, “completed with warning” is a different animal and it will put end users at risk. In this case, the Office 365 mailbox is fully populated and available for Office 365 users to communicate with other Office 365 users. The last step in the remote move process is to clean up the Active Directory references to the on-premises Exchange mailbox. The user object changes from mailbox-enabled to mail-enabled, which shows up as a Remote User in the Exchange Management Console.

When this cleanup process fails, you are left with a mailbox-enabled user within the on-premises Exchange environment, so you essentially have two instances of the mailbox. This gets very confusing very quickly; the short version of the “warnings” fallout is listed below.
– Mail from external senders result in NDR messages; unable to find on-prem mailbox.
– Users with on-premises mailboxes will see an entry in the GAL for the migrated user, but that entry does not point to the Office 365 mailbox. Exchange 2003 mailboxes will not receive NDRs indicating that mail delivery failed.
– Users with Office 365 mailboxes will see the migrated mailbox in the GAL and will be able to successfully route mail to the migrated O365 mailbox.
– The migrated user’s Outlook profile will prompt for AD credentials, as if it was going to open the O365 mailbox but it will fail. However, if the user does attempt to log in via OWA they can access the O365 mailbox. Which is something, but ultimately not all that useful when mail isn’t arriving from 2003 users or external users …
So this is clearly not a good spot for the migrating user. Ideally, this is something that can be addressed quickly in order to minimize any potential mail routing confusion.
At this point, there are two important considerations:
1. Why did this happen, and how do I prevent this from happening to another mailbox at a later date?
2. How do I manually complete the clean-up process that was supposed to happen at the end of the remote move?
I’ll detail the 2nd question regarding how to address this situation in my next blog. For this blog, I’ll deal with the first question regarding why this happened and what you can do to prevent it from happening again. To begin, you should go to the cloud organization “Move Requests” and double-click on the impacted mailbox. The “Details” tab should provide the “why” information. In the screenshot listed below, it looks like a permissions error.
“Insufficient access rights to perform the operation. Active directory response: 00002098″

This is a pretty common reason for a remote move to fail, so I’ll map out the steps to resolve it. Obviously, the steps to correct the identified error may differ on a case-by-case basis. Assuming the vast majority of mailboxes succeed and only a small percentage fail, then the administrator has most likely properly configured permissions for their on-premises and O365 accounts. But the user object failing during the remote most likely does not have the “inherit permissions” checkbox clicked on the “Advanced Options” under the “Security” tab.

Doing this cleanup won’t help you address the failed move, but it is important to understand why it failed so you can ensure other mailboxes in the environment do not suffer the same fate when they migrate. In the case of “include inheritable permissions” you can automate this process by leveraging the script included in this blog – http://exchadtech.blogspot.com/2010/09/script-to-check-inheritable-permission.html. Normal guidance applies: please test any changes in your environment before pushing out a change globally.
In the next article, I’ll cover the steps to complete the Active Directory clean up in order to restore mail flow operations for the troubled mailbox.