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
