Home

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.

Ben Winzenz

9 Comments
Regular Visitor

We see this scenario far more often than we would like due to issues with a third party identity management solution that is executing built in functions that utilizes enable-mailbox.  The bigger question is why doesn't enable-mailbox check to see if there is already Exchange properties on an AD object?  It can be difficult to have an identity management solution check to see if the account is already in the cloud. 

Contributor

We force this condition in our environment due to the fact that we are not allowed to have a migration endpoint. In order to get the on-premises mailbox and the cloud mailbox to connect and have our AAD Connect sync properly, we make sure to copy the Exchange Online GUID of the mailbox and add it to the proper AD property. We then force the mailbox into a remote mailbox.

 

<Connect to O365>

$oEmailGuid = Get-Mailbox -Identity $UPN | Select-Object ExchangeGUID

 

<Connect to on-premises AD>

Set-ADUser $SamAcct -Replace @{msExchRecipientDisplayType = "-2147483642" } -Credential $cred
Set-ADUser $SamAcct -Replace @{msExchRecipientTypeDetails = “2147483648” } -Credential $cred
Set-ADUser $SamAcct -Replace @{msExchRemoteRecipientType = “4” } -Credential $cred
Set-ADUser $SamAcct -Replace @{targetAddress = $TAddress } -Credential $cred

 

<Connect to on-premises Exchange>

Set-RemoteMailbox $UPN -ExchangeGuid $oEmailGuid.ExchangeGuid

 

 

Microsoft

@Kyle Berwaldt this will largely depend on how the Identity management system is mailbox-enabling these accounts and may also depend on the Exchange version.

If I try and mailbox-enable a user whose mailbox was migrated to Exchange Online from my Exchange 2016 server using PowerShell, I get the following error:

Enable-Mailbox on this mail user is disallowed because the mailbox has been migrated.

 

Exchange 2010 allowed me to mailbox-enable the same user with no error.

Regular Visitor

@bwinzenz , Thank you!  Thats great to hear that the issue has been resolved in 2016.

 

The identity management solution is running the cmdlet enable-mailbox.  We are still on Exchange 2013 CU21 where the cmdlet will still successfully run :(.

Senior Member

@Kyle Berwaldt I don't think the EXO mail attribute writes back, but even if it did you'd still have the gap in the initial replication. We use dynamic 365 licensing policies based on AD properties, along with enable-remotemailbox. This has prevented the issue from happening anymore and creates the object directly in EXO.

Contributor

Interested in seeing the 'recomended' process, having executed the other method a few times.

Visitor

In the linked article, step 7. Could you go in to more detail about this command, the one to restore the Exchange on-prem disconnected mailbox to Exchange Online?

 

 

New-MailboxRestoreRequest -RemoteHostName mail.contoso.com -RemoteCredential $cred -SourceStoreMailbox “exchange guid of disconnected mailbox” -TargetMailbox “exchange guid of cloud mailbox” -RemoteDatabaseGuid “guid of on-premises database” -RemoteRestoreType DisconnectedMailbox

 

I guess I run this in an Exchange Online Powershell, and it will pull in content over the Hybrid connection?

 

Microsoft

@Jeff Arndt correct you run it from Exchange Online PowerShell. Similar to how Hybrid mailbox moves to Exchange Online utilize remote credentials, this allows you to copy the content from the on-premises disconnected mailbox into the cloud mailbox. It does require that you have MRS Proxy enabled on your EWS virtual directories (enabled by default on Exchange 2013 and newer), and that you allow external access to /ews/mrsproxy.svc even if it is just from Office 365 IP's.

Occasional Visitor

Hello,

 

does this recovery method also work with Exchange 2010?

 

I've just tried to create such "New-MailboxRestoreRequest" in our O365 tenant and got an error:

 

Remote server '<server name>' version (14.3.399.0 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:05FFFF) isn't supported. Missing API: 'TenantHint'.

    + CategoryInfo          : NotSpecified: (:) [New-MailboxRestoreRequest], MRSRemotePermanentException

    + FullyQualifiedErrorId : [Server=VI1PR02MB4031,RequestId=dccb4fca-f7d6-4b4c-a929-d15aac70bbbe,TimeStamp=9/30/2019 1:14:08 PM] [FailureCategory=Cmdlet-MRSRemotePermanentException] 7B1FD142,Microsoft.Exchange.Management.Migration.MailboxReplication.MailboxRestoreRequest.NewMailboxRestoreRequest

    + PSComputerName        : outlook.office365.com

 

Normal mailbox moves from on-prem -> O365 work OK

 

Thanks in advance for your feedback.

Lukas