How to recover when a mailbox exists in both Exchange Online and on-premises
Article
Applies to:
Exchange Online, Exchange Server 2019, Exchange Server 2016, Exchange Server 2013
Description
In a Microsoft Exchange Server hybrid deployment, a user may have a mailbox in both Exchange Online and an Exchange on-premises organization. This isn't a desired state for a hybrid organization because it will create mail flow issues. In this case, messages will be delivered to the mailbox that corresponds to the location of the sender. If the sender is located in your on-premises organization, messages will be delivered to the on-premises mailbox. If the sender is located in your Exchange Online tenant, messages will be delivered to the Exchange Online mailbox.
How to improve the situation
To correct this mail flow issue, we recommend that you refer to the methods that are provided in this article. Other possible options use recovery methods that are not guaranteed to work. As Microsoft 365 continues to evolve and new features are added, additional options may be possible. This article will be updated to reflect additional corrective methods as they become available.
Scenario 1: Keep Exchange Online mailbox
This scenario would be most applicable if the user mailbox was previously migrated to Exchange Online, and somehow the old mailbox was reconnected or a new mailbox was provisioned on-premises. Another possible scenario is when an Exchange Online license is assigned prematurely, and a new cloud-only mailbox is created while the user already has an existing mailbox in Exchange on-premises. Be sure to read the important note at the end of step 8.
To use this method, follow these steps:
Open the Exchange Management Shell, save the on-premises mailbox information to a file, such as "SMTP addresses", "Legacy Exchange DN", "Exchange attributes", and so on.
Set the PowerShell Format enumeration limit to "unlimited" to make sure that no attribute values are truncated. For example:
Restore any custom proxy addresses and any other Exchange Server attributes that were stripped when the mailbox was disabled (compare to the Get-Mailbox cmdlet from step 2).
Add the LegacyExchangeDN value of the previous on-premises mailbox to the proxy address of the new remote mailbox as an x500 address. To do this, run the following cmdlet:
Note
The value of the LegacyExchangeDN parameter can be found in the file that's saved in step 2.
To get the GUID of the disconnected mailbox, use the value of the ExchangeGUID parameter from the file that's saved in step 2.
To get the GUID of the on-premises database, use the value of the Database parameter from the file that's saved in step 2, then run the following cmdlet:
To get the GUID of the cloud mailbox, run the following cmdlet by using Exchange Online PowerShell:
Get-Mailbox "user identity" | fl *ExchangeGUID*
(Optional) Stamp the Exchange Online GUID on the remote mailbox using Exchange Management Shell (required if you ever want to off board the mailbox back to on-premises).
Set-RemoteMailbox "user identity" -ExchangeGuid "Exchange guid value of Exchange Online mailbox"
Restore the contents of the disconnected mailbox to Exchange Online by using Exchange Online PowerShell. For the Credentials, you must specify an on-premises Exchange admin account. To perform a remote restore, the administrator must have one of the following conditions:
A member of the Domain Admins group in Active Directory Domain Services (AD DS) in the on-premises organization.
A member of the Exchange Recipients Administrators group in Active Directory in the on-premises organization.
A member of the Organization Management or Recipient Management group in Exchange Server 2013 or above.
$cred = Get-Credential
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
Note
The remote restore isn't supported for Exchange Server 2010. The minimum supported version is Exchange Server 2013.
Important
Because New-MailboxRestoreRequest was designed to work in a single Exchange Server organization, the cross-premises restore jobs will fail due to an unavoidable mismatch between the source and target mailbox ExchangeGuid's. The mailbox restore request will end in status "FailedOther", and the report (from Get-MailboxRestoreRequestStatistics -IncludeReport) will show the following error message in the final report Entry:
This failure can be disregarded and the job instead treated as a success, as long as the second to last entry in the report shows the correct number of items having been copied (e.g. Copy Progress: 5000/5000 messages, 2.34 GB/2.34 GB). For example:
Any items reported in the BadItemsEncountered, LargeItemsEncountered, or MissingItemsEncountered properties (from Get-MailboxRestoreRequestStatistics) should be treated normally, as these would have been encountered regardless of whether the mailbox was migrated via migration batch / move request, or via New-MailboxRestoreRequest.
Scenario 2: Remove Exchange Online mailbox data
The mailbox information in Microsoft 365 may no longer be needed. In this case, see this Exchange Team Blog article for more information about how to remove the Exchange Online mailbox information completely.
This module examines how Microsoft 365 supports data governance by enabling organizations to archive content by using archive mailboxes and restore deleted data in Exchange Online and SharePoint Online.
As a Windows Server hybrid administrator, you integrate Windows Server environments with Azure services and manage Windows Server in on-premises networks.