In support, we hear from people in this “duplicate mailbox” situation relatively often. When this happens, our customers ask us for the best way to recover. In my experience, there are typically two main scenarios under which accounts can get into this situation.
Duplicate (new) mailbox in Exchange Online
An Exchange Online license was applied to the user before the Exchange GUID got synchronized from on-premises Active Directory. For synchronized accounts, having the Exchange GUID synchronized from on-premises is used to tell Exchange Online that the mailbox hasn’t been migrated yet, and is what allows customers to pre-license accounts prior to migration.
Pre-licensing is recommended for many reasons. For example, if the user is licensed, we bypass the validation that all email addresses must match an accepted domain. Another example where pre-licensing accounts is helpful is so that the mailbox doesn’t get disconnected immediately post-migration due to not having a license. This is especially important if “partial” licenses are used (i.e. apply the license for Azure AD, SharePoint Online, but not for Exchange Online). The bottom line is – if the Exchange GUID hasn’t been synchronized when the Exchange Online license is applied, Exchange Online has no way of knowing that there is an on-premises mailbox, so it dutifully provisions a brand new (empty one) for the user.
Duplicate (new) mailbox on-premises
Assume that a mailbox was migrated to Exchange Online, and then the on-premises account was mailbox-enabled again. In most cases, this ends up happening due to utilizing an Identity management tool of some sort (even if it is a PowerShell script!) which decides that users should be mailbox-enabled when they really shouldn’t be. Here, you end up with the opposite end result: a migrated mailbox is in Exchange Online, and a brand new (empty) mailbox is created on-premises.
I’m already in this state; now what?
No matter how you get into this situation, the recommended recovery process will be the same. You can find that recently documented process here:
How to recover when a mailbox exists in both Exchange Online and on-premises
In this blog post, we did want to acknowledge that we know there might be other ways to recover from this scenario. We spent quite a bit of time discussing how to best approach this and document a process that repeatedly gives you the best chance of success with no data loss. For example, one of the more common methods in the past was to disconnect the Exchange Online mailbox by removing the license, migrate the on-premises mailbox, then perform a restore (New-MailboxRestoreRequest) of the previous Exchange Online mailbox into the newly migrated mailbox. The main reason that we do not suggest this as a recovery method is that recovery from Exchange Online disconnected mailboxes cannot always be guaranteed (there can be factors like passing of time etc. which can make the process not be successful). If 99% of the time, it will work flawlessly, but that 1% of the time it doesn’t work, we do not suggest it because you might lose data as a result.
Note that If there are changes in functionality that allow us to document additional recovery methods, we will make sure to update the documentation with those additional methods.
We’d love your feedback on if the documented process works for you and what your thoughts are.
