The importance of –2147481594 in Exchange Hybrid with Office 365
You have setup a hybrid between on-premises Microsoft Exchange and Office 365 (Exchange Online), but when you try and move a mailbox from on-premises to Office 365 it tells you that the mailbox already exists. What it is telling you is that the user has a mailbox on-premises and one in Office 365 (Exchange Online). Gulp!
There are two scenarios where I have seen this happen
Most commonly, when a mailbox has been created for a user in Exchange Online before Directory Synchronization between on-premises AD and Office 365 has been setup. You then add Directory Synchronization (DirSync) and it links up (joins) an AD account from on-premises AD with an Office 365 account. You now have a situation where the AD account has a mailbox on-premises and in Exchange Online. Even if you attempt to delete the mailbox in Exchange Online (by removing the Exchange Online licenses from the user), as soon as you assign the license back to the user, the mailbox is re-created, so you still cannot move the mailbox from on-premises to Exchange Online.
The second scenario is, you have deployed DirSync and it is working “well”. Subsequently you have created a user in AD with a local mailbox and then synced the user account across into Office 365. You very soon after sync (example; under 1 minute), you assign the synced user in Office 365 an Exchange Online Plan license, which in turn creates a mailbox for the user in Exchange Online.
Yes, this shouldn't happen, in theory, if a user has a mailbox on-premises, and you sync the account into Office 365, when you assign a license it shouldn't create a mailbox, it should know that the user has a mailbox on-premises. If you assign the license through the Office 365 Admin Portal, it should give you a dialog box saying that a mailbox wont be created for the user as the mailbox exists on-premises.
Why does this happen, and how to prevent this?
What you want, is for Dirsync to set a flag on the user object in Office 365, to indicate that the object has a mailbox on-premises, and therefore not to create one when you assign an Exchange Online license. Specially, the attribute in question is called msExchangeReceipientType, and you want it in the cases described above for the value to be “–2147481594” before assigning an Exchange Online license. If you have DirSync in place, and the user does have a mailbox on-premises it will be this, except in the 2 scenarios described above. Sometimes, you are just so quick, that the msExchangeReceipientType hasn't been set correctly for the user object, and you assign the license, or when you don't have AD sync, then it obviously wont be that value.
What you could do to prevent the behavior seen in the scenarios above, is check the value before assigning a license e.g., if you assigning licenses to users on mass via PowerShell, check this value before assigning the license if it is not “-2147481594” don't assign the license.
To view the value of msExchangeReceipientType, use the Azure AD Module for PowerShell and connect into your tenant. Then run “Get-MSOLUser -UserPrincipalName ‘upnofuser’ | fl” to list all properties for the user object.
What happens if I have a user where the issue has already occurred, and now they have a mailbox in Office 365 and on-premises.
The problem is you cannot easily change the msExchangeReceipientType value manually e.g. via PowerShell. You need to get DirSync to set the value. So if you have an account where this is an issue, the best thing is to remove the account from being synchronized, remove the account from Office 365, and then re-sync the account.
Here are the steps in more detail:
- Move the AD account into an OU which is not being synchronized with Office 365 (Azure AD).
- Force a DirSync. This should force a deletion of the account in Office 365 (Azure AD)
- Check that the account has been deleted from Azure AD, if it hasn’t, force DirSync again. Do this until AD account is removed from Azure AD
- Use Azure AD remote PowerShell to remove the account from the user recycle bin. i.e. Remove-MsolUser -UserPrincipalName ‘upn’ -RemoveFromRecycleBin –force
- Check through the O365 admin UI portal, that the account has gone from the recycle bin
- Move the AD account back into an OU which is being synchronized with Office 365 (Azure AD)
- Force DirSync. This will re-provision the account into Office 365 (Azure AD)
- Check that msExchRecipientDisplayType is now what it should be e.g. “-2147481594”.
- Try move mailbox again
Note: by removing the account in Office 365 (Azure AD), you will be deleting content associated to this account too e.g. mailbox and OneDrive for Business, so if you need data, make sure you backup before doing this.
On a similar note. I have seen a situation where an organization wants to move resource mailboxes from Exchange on-premises to Exchange Online, but when they attempt the move request they get an error saying they need to assign a license first. As you know you don't need to licenses resource mailboxes in Exchange Online, if they are created as a resource mailbox i.e. not a user mailbox behaving like a resource mailbox. What has often happened in this case, is that their on-premises resource mailboxes were actually created as user mailboxes and therefore need a license assigned. How does Exchange Online know this, because of the value of msExchangeReceipientType. In this case it is probably set to “-2147481594”, which denotes that it is a user mailbox. What you need to do, is check this value for your synced accounts to ensure that this is not what is set on resources like rooms etc.
As a reference to what the values of msExchangeReceipientType mean and for example should be for a resource mailbox, check out this blog post.
Hope this helps,
Michael