How to Restore from a Soft Deleted Mailbox in Office 365 Exchange Online Using New-MailboxRestoreRequest

A scenario came up with a customer recently where their mailbox was migrated to Exchange Online, but not before discovering something wasn't right with their account in the on-premises Active Directory. The on-prem account was filtered out from AADConnect, and the synced account removed from Azure AD with Remove-MSOLUser -RemoveFromRecycleBin. With the on-prem account fixed (for whatever it was, not important here) the customer's admin let it pass the AADConnect filter so it could sync back to Office 365. A consequence of that is a new mailbox provisioned, and the original one with the user's data disconnected, in a soft deleted state.
 
The chosen solution to get the data out of the soft deleted mailbox and into the newly provisioned one was New-MailboxRestoreRequest. However, setting up that kind of request can be tricky for the uninitiated in Exchange Online. Here's why and what to do about it.
 
Suppose we have a very similar scenario, where user Tim's mailbox was just migrated to the cloud. There's about 51MB in it, and 392 items.
 

 

 
Then the user account sync is broken, the MSOLUser account removed, the account sync restored, and a new MSOLUser account created. This gives us two mailboxes, one brand new and available for Tim, the other the original soft deleted one with his old items we want to get back:
 

 
The new mailbox is virtually empty, only 4MB now:
 

 

 
No problem, right? Just run New-MailboxRestoreRequest and tell it where the source soft-deleted mailbox is, and then the new target mailbox. We set variable objects for both mailboxes:
  

$src = get-mailbox tfrankinsaw -SoftDeletedMailbox

$tar = get-mailbox tfrankinsaw

We then echo the $src and $tar variables to be sure they're right. Same name, two different databases. So far so good.
 

 

 
We also take a look at the ExchangeGuid attribute values for each mailbox, which provides a unique identifier for any mailbox in an organization, regardless of whether it's connected, soft deleted, disabled, or whatever.

 
So we can use $tar.ExchangeGuid and $src.ExchangeGuid to show these unique identifiers for each mailbox.
 

 
We run into a problem, though, running New-MailboxRestoreRequest with the ExchangeGuid values to tell Exchange Online which mailboxes are the source and target. Each attempt to do this results in the same sort of error:




Cannot process argument transformation on parameter 'TargetMailbox'. Cannot convert the "7645f038-2d1f-4d32-82b4-e95f6f
27e6bd" value of type "System.Guid" to type "Microsoft.Exchange.Configuration.Tasks.MailboxLocationIdParameter".    + CategoryInfo          : InvalidData: (:) [New-MailboxRestoreRequest], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,New-MailboxRestoreRequest

If we try to run it using just -SourceMailbox, to see if the problem is just with -TargetMailbox in the above example, we get the same error:

 

 

Cannot process argument transformation on parameter 'SourceMailbox'. Cannot convert the "587c8e4c-78ef-4087-b24f-e20ade
46289c" value of type "System.Guid" to type "Microsoft.Exchange.Configuration.Tasks.MailboxLocationIdParameter".
    + CategoryInfo          : InvalidData: (:) [New-MailboxRestoreRequest], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,New-MailboxRestoreRequest
 

Fortunately there's another attribute that can sometimes be used to uniquely locate a mailbox, and in this scenario it will work. It's the LegacyExchangeDN attribute, and it too can be used to identify mailboxes to a certain degree. It's not a hard rule by any stretch, not like with ExchangeGuid attribute values (for example, in the case of primary and archive mailboxes the LegacyExchangeDN attributes are the same). But in this particular scenario we can differentiate between the soft deleted mailbox and the new clean target one with their respective LegacyExchangeDN values. Since we can't use ExchangeGuid for New-MailboxRestoreRequest we can retry using LegacyExchangeDN. We need the -AllowLegacyExchangeDNMismatch switch, because New-MailboxRestoreRequest was designed for use with recovery databases where the LegacyExchangeDN matches. Just an interesting tidbit there. Let's also give a name for the request and off it goes:

New-MailboxRestoreRequest -Name "Happy Restore Job" -TargetMailbox $tar.LegacyExchangeDN -SourceMailbox $src.LegacyExchangeDN -AllowLegacyDNMismatch