How to restore an inactive mailbox for a federated user in an Exchange Hybrid deployment
This article describes the basic steps that any Exchange Administrator can take to recover an inactive mailbox of a federated user in Exchange Online that’s having also Litigation Hold enabled.
Let’s assume that we are in Exchange Hybrid deployment with Office 365 and the user’s objects are created within a federated domain and synced from local Active Directory and mailboxes provisioned in Exchange Online.
Scenario: One user left the company and his mailbox was existing in Exchange Online with Litigation Hold enabled. The user was removed from the synchronization in local AD ( or Deleted from AD) –> automatically the MsolUser (the cloud object of that user) goes in Deleted Users –> the mailbox goes in Soft Deleted (or Inactive status ) and –> after 30 days the MsolUser will be purged and the mailbox will become inactive.
Issue: After more than 30 days the user come back and he’s requesting the content of his old mailbox, or another employee takes on the job responsibilities of the departed employee, or if another user needs access to the contents of the inactive mailbox, you have to restore (or merge) the contents of the inactive mailbox to an existing mailbox
Essentially, the first step that an Admin will take will be to run in Exchange Online PowerShell:
New-Mailbox -InactiveMailbox as per https://technet.microsoft.com/en-us/library/dn894100(v=exchg.150).aspx but that’s failing with error:
“The parameters passed to the cmdlet represent a managed account, which doesn’t match the namespace state, which is federated.”
The problem is that we actually can’t use New-Mailbox -InactiveMailbox to restore a mailbox for a federated user (federated domain) with Litigation Hold enabled the behavior and the error that occurred being expected in this particular scenario.
What to do?
I’ll share with you below, two solutions for this behavior:
- Restore to a non-federated domain and perform a hard match.
Well the first best practice and Microsoft recommendation will be to restore the user in a non-federated domain (such as the onmicrosoft.com one) and after that performing a hard match between the mailbox and the re-created/resynced user from local AD.
Note: In my test scdtech.co is an accepted federated domain in O365 - tenant scdltd.onmicrosoft.com .
The user UPN alex.ciobanu@scdtech.co was deleted from local AD and his cloud mailbox became an Inactive mailbox.
Checking in EXO PowerShell we can see that very easily:
Get-Mailbox "Alex Ciobanu" -InactiveMailboxonly
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Alex Ciobanu alex.ciobanu am5pr0601mb2658 49.5 GB (53,150,220,288 bytes)
Get-Mailbox "Alex Ciobanu" -SoftDeletedMailbox
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Alex Ciobanu alex.ciobanu am5pr0601mb2658 49.5 GB (53,150,220,288 bytes)
Get-Mailbox "Alex Ciobanu" -SoftDeletedMailbox | fl *email*
IsInactiveMailbox : True
EmailAddresses : {SMTP:alex.ciobanu@scdtech.co, smtp:alex.ciobanu@scdltd.mail.onmicrosoft.com, smtp:alex.ciobanu@scdltd.onmicrosoft.com, X500:/o=Scdtech/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=24a4e28bdaa04d529c788d64c195b80d-Alex Ciobanu}
EmailAddressPolicyEnabled : False
WindowsEmailAddress : alex.ciobanu@scdtech.co
Now, the next step that I want to take is to restore the mailbox to a NON-federated domain ( for example scdltd.onmicrosoft.com ) in order to avoid the error described at the beginning of the article. In order to do that you need firstly to:
--> find out the GUID of the SoftDeleted mailbox:
Get-Mailbox "Alex Ciobanu" -SoftDeletedMailbox | fl *exch*
ExchangeGuid : 95988a05-adb9-4709-bca4-88feb2a58993
ExchangeSecurityDescriptor : System.Security.AccessControl.RawSecurityDescriptor
ExchangeUserAccountControl : None
LastExchangeChangedTime :
LegacyExchangeDN : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=2e30112ed2614386892e46ba366e485b-Alex Cioban
ExchangeVersion : 0.20 (15.0.0.0)
--> perform the restore itself to the scdltd.onmicrosoft.com domain (non-federated).
New-Mailbox -InactiveMailbox 95988a05-adb9-4709-bca4-88feb2a58993 -Alias alex.ciobanu -MicrosoftOnlineServicesID alex.ciobanu@scdltd.onmicrosoft.com
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign the mailbox a license, or it will be disabled after the grace period.
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Alex alex.ciobanu am5pr0601mb2658 49.5 GB (53,150,220,288 bytes)
WARNING: The inactive mailbox has been recovered. To preserve data until you obtain a valid license, we have enabled Single Item Recovery for 30 days. Additionally, we have also enabled Retention Hold for 30 days. Once a valid license has been assigned for this mailbox, you can choose to disable these settings and use Litigation or In-Place Hold instead to preserve data.
Now we have the old inactive mailbox restored in a new mailbox in cloud on the onmicrosoft.com domain and a fresh cloud user: alex.ciobanu@scdltd.onmicrosoft.com that’s owning the mailbox. We can check that in EXO PS again just to be sure:
Get-msoluser -UserPrincipalName alex.ciobanu@scdltd.onmicrosoft.com
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
alex.ciobanu@scdltd.onmicrosoft.com Alex False
Get-Mailbox alex.ciobanu
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Alex alex.ciobanu am5pr0601mb2658 49.5 GB (53,150,220,288 bytes)
After re-creating the user in local AD and assigning a license for the new created user in cloud ( alex.ciobanu@scdltd.onmicrosoft.com ), all that we need do is to match the AD user with the cloud mailbox and to enable the remote mailbox in Exchange onPremise environment.
In order to perform the above please be sure that :
- the new created user in the local AD is synced to Azure AD trough your synchronization tool and you assigned a license on the cloud user.
- You copy the ObjectGuid from local AD so that we can convert it into the ImmutableID that we will need for the cloud user.
We can convert the ObjectGuid of the AD user to ImmutableID by running the below script ( can be run in any PowerShell console )
[System.Convert]::ToBase64String((new-Object system.Guid("cac296d4-cc1a-4dc7-93dc-4234813f5799")).ToByteArray())1JbCyhrMx02T3EI0gT9XmQ==
Once we have the above done, we can set the ImmutableID on the cloud created user:
Set-MsolUser -UserPrincipalName alex.ciobanu@scdltd.onmicrosoft.com -ImmutableId 1JbCyhrMx02T3EI0gT9XmQ==
Now, we are having only one fully synced user from local AD that’s owning the new cloud mailbox ( the old inactive one ) and the user alex.ciobanu@scdltd.onmicrosoft.com should not exist anymore because of the match. Instead we need to have the local AD user alex.ciobanu@scdtech.co synced and available in Azure AD. We can check that very easily in EXO PS:
Get-msoluser -UserPrincipalName alex.ciobanu@scdltd.onmicrosoft.com | fl *imm*
ImmutableId : 1JbCyhrMx02T3EI0gT9XmQ==
Get-msoluser -UserPrincipalName alex.ciobanu@scdltd.onmicrosoft.com | fl *imm*
Get-msoluser : User Not Found. User: alex.ciobanu@scdltd.onmicrosoft.com.
At line:1 char:1
+ get-msoluser -UserPrincipalName alex.ciobanu@scdltd.onmicrosoft.com | ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser
Get-msoluser -UserPrincipalName alex.ciobanu@scdtech.co | fl *imm*
ImmutableId : 1JbCyhrMx02T3EI0gT9XmQ==
Get-Mailbox alex.ciobanu@scdtech.co
Name Alias ServerName ProhibitSendQuota
---- ----- ---------- -----------------
Alex Ciobanu alex.ciobanu am5pr0601mb2658 49.5 GB (53,150,220,288 bytes)
Get-msoluser -UserPrincipalName alex.ciobanu@scdtech.co | fl *proxy*
ProxyAddresses : {SMTP:alex.ciobanu@scdltd.onmicrosoft.com}
All that we need to do is to enable also the remote mailbox recipient type in Exchange On Premise environment to be sure that:
- the mail flow will work for this mailbox in case if my MX records are pointing to my On_Premise environment,
- all other msExchange attributed from AD (such as targetAddress and msExchRecipientType and msExchRecipientDisplayType) will be correctly stamped indicating the fact that I have a synced user with a cloud mailbox.
So, in Exchange Manangement Shell we just run:
Enable-OnPremRemoteMailbox alex.ciobanu -RemoteRoutingAddress alex.ciobanu@scdltd.mail.onmicrosoft.com
Name RecipientTypeDetails RemoteRecipientType
---- -------------------- -------------------
Alex Ciobanu RemoteUserMailbox ProvisionMailbox
And if I go back in EXO PS, I can see that I have a synced user in AzureAD, having a fresh mailbox (containing the content of the inactive one)
get-msoluser -UserPrincipalName alex.ciobanu@scdtech.co | fl *proxy*
ProxyAddresses : {smtp:alex.ciobanu@scdltd.onmicrosoft.com, smtp:alex.ciobanu@scdltd.mail.onmicrosoft.com, SMTP:alex.ciobanu@scdtech.co}
Get-Mailbox alex.ciobanu@scdtech.co | fl *email*
IsInactiveMailbox : False
EmailAddresses : {smtp:alex.ciobanu@scdtech.co, SMTP:alex.ciobanu@scdltd.onmicrosoft.com}
EmailAddressPolicyEnabled : False
WindowsEmailAddress : alex.ciobanu@scdltd.onmicrosoft.com
Now the user can access his new mailbox and he will retrieve also the content of his old mailbox and of course he will receive all the new emails and will have the same experience as the other users.
For the administrators this process might looks complex (since is involving actions on AD, Sync, Exchange OnPremise and EXO) but this is the best way to recover an inactive mailbox without having orphaned objects remaining in cloud.
This method converts the inactive mailbox to a new mailbox that contains the contents of the inactive mailbox. After it's recovered, the inactive mailbox no longer exists.
- Restore to a new created mailbox in cloud and perform a mailbox merge
You may try to restore the inactive mailbox to a new created mailbox (which will become the target mailbox) and use the MailboxRestore Request command as described below.
NOTE: Please note that this process can be done safely and more easily than the first solution but, as an Admin you’ll assume the fact that the object of mailbox that you restored will remain orphaned in cloud, because you will restore only the content.
If we want to resync the user from local AD (the same initial object containing the same SMTP address), and provide access to the old inactive mailbox, then we suggest to create a new mailbox in cloud (by assigning a EXO license) and restore the old inactive mailbox to the new one by following:
- Go to local AD and clear msExchMailboxGuid and msExchRemoteRecipientType should have the value 1
- Sync the user back from local AD to O365 ( you can do that via normal Delta-Sync after adding that object under the synced OU in AD )
- Assign a license to the user User@contoso.com
- Wait for the new mailbox to be provisioned: User@contoso.com (the provisioning should take around 10 – 20 minutes max).
- You have to retrieve the ExchGuid for the both mailboxes ( the inactive one and the new created one)in order to be able to run the Restore request
Get-Mailbox User@contoso.com| fl *exchangeguid*
ExchangeGuid : 94e7f4fc-2ee6-4c6a-ac7e-25091aa542f9
Get-Mailbox User@contoso.com -SoftDeletedMailbox | fl *exchangeguid* OR
Get-Mailbox User@contoso.com -InactiveMailbox | fl *exchangeguid*
The output should be something like:
ExchangeGuid: a30dd57f-8f3a-4a06-a1cc-481742c8fc23
- Now we need just to copy the old mailbox content from the inactive mailbox to the active newly created mailbox by running:New-MailboxRestoreRequest -SourceMailboxa30dd57f-8f3a-4a06-a1cc-481742c8fc23-TargetMailbox94e7f4fc-2ee6-4c6a-ac7e-25091aa542f9-AllowLegacyDNMismatch
- The only thing that remain now is to monitor the progress of the above command by running from time time:
Get-MailboxRestoreRequest | select targetmailbox,requestguid OR,
Get-MailboxRestoreRequestStatistics -Identity <MailboxRestoreRequestIdParameter>
Once any of the above solutions will be completed, you’ll have the old content from the inactive mailbox restored in the new created one and a very happy user.
Comments
- Anonymous
October 18, 2017
Very helpful - Thanks - Anonymous
December 26, 2017
The comment has been removed - Anonymous
December 30, 2017
Thanks a lot!