Recently I ran into an issue with shared mailboxes in Exchange Online. In the Office 365 Admin portal I created a custom view in the Active users section to track issues with our licensing process:
Some users were displayed here which where moved from on-premises as regular mailboxes and then converted to shared with the button in EAC. Which is odd because a license isn’t required for a shared mailbox.
At a first glance everything seemed okay, the mailbox moved to the Shared view in EAC. The only thing off was the fact that LicenseReconciliationNeeded was set to True for this user which is why it showed up as mailbox without a license in the portal.
Next I compared the mailbox properties as well as the on-premises AD attributes with another shared mailbox, that happened to be shared before it was moved to Exchange Online.
So for the shared mailbox that was converted before the move msExchRemoteRecipientType was set to 100 (Shared mailbox in Exchange Online) while the other still displayed a value of 4 (Migrated mailbox).
Next step was to involve Microsoft Premium Support. Their first recommendation was to change the value from 4 to 100 in the on-premises AD and have it synced back to Azure AD. This didn’t make sense to me and by that time I already discovered that I could easily reproduce the issue in the test environment by converting a moved mailbox with the button in EAC so it was not caused by an issue in our on-premises AD.
Next the engineer provided the following KB article and explained that the behavior I’m seeing is ‘by design’: Shared mailboxes are unexpectedly converted to user mailboxes after directory synchronization runs in an Exchange hybrid deployment.
The article describes a scenario where a mailbox has been moved to Exchange Online, is converted to Shared and with the next directory sync is converted back to regular. Interestingly that last part is not happening in our environments and I was not able to reproduce the described behavior, not with a highly customized FIM nor with a default AAD Connect sync engine.
Anyway, accoring to the article it is not supported to convert a regular mailbox for a synced user to the shared mailbox type. The technical explanation is that directory synchronization currently doesn’t support the syncing back of all attributes that change during the conversion.
Microsoft recommends to move the mailbox to on-premises, convert it to shared and then move it back to Exchange Online. For some customers this may present an acceptable work-around, for others it is cumbersome and requires additional planning and communication to end-users.
And the real question of course is why Microsoft allows their customers to convert a synced mailbox to shared when the underlying technical issue can result in the mailbox being deleted after the grace period ends. I left feedback through the support channel and on the Office 365 Uservoice site. Please vote here if you agree this should change: Support conversion to shared mailbox for synced users
Some users were displayed here which where moved from on-premises as regular mailboxes and then converted to shared with the button in EAC. Which is odd because a license isn’t required for a shared mailbox.
At a first glance everything seemed okay, the mailbox moved to the Shared view in EAC. The only thing off was the fact that LicenseReconciliationNeeded was set to True for this user which is why it showed up as mailbox without a license in the portal.
Next I compared the mailbox properties as well as the on-premises AD attributes with another shared mailbox, that happened to be shared before it was moved to Exchange Online.
So for the shared mailbox that was converted before the move msExchRemoteRecipientType was set to 100 (Shared mailbox in Exchange Online) while the other still displayed a value of 4 (Migrated mailbox).
Next step was to involve Microsoft Premium Support. Their first recommendation was to change the value from 4 to 100 in the on-premises AD and have it synced back to Azure AD. This didn’t make sense to me and by that time I already discovered that I could easily reproduce the issue in the test environment by converting a moved mailbox with the button in EAC so it was not caused by an issue in our on-premises AD.
Next the engineer provided the following KB article and explained that the behavior I’m seeing is ‘by design’: Shared mailboxes are unexpectedly converted to user mailboxes after directory synchronization runs in an Exchange hybrid deployment.
The article describes a scenario where a mailbox has been moved to Exchange Online, is converted to Shared and with the next directory sync is converted back to regular. Interestingly that last part is not happening in our environments and I was not able to reproduce the described behavior, not with a highly customized FIM nor with a default AAD Connect sync engine.
Anyway, accoring to the article it is not supported to convert a regular mailbox for a synced user to the shared mailbox type. The technical explanation is that directory synchronization currently doesn’t support the syncing back of all attributes that change during the conversion.
Microsoft recommends to move the mailbox to on-premises, convert it to shared and then move it back to Exchange Online. For some customers this may present an acceptable work-around, for others it is cumbersome and requires additional planning and communication to end-users.
And the real question of course is why Microsoft allows their customers to convert a synced mailbox to shared when the underlying technical issue can result in the mailbox being deleted after the grace period ends. I left feedback through the support channel and on the Office 365 Uservoice site. Please vote here if you agree this should change: Support conversion to shared mailbox for synced users
1 comment:
There is a simple fix for this: Assign a license to the user with shared mailbox, that shows up as LicenseReconciliationNeeded. Then remove the license and check the LicenseReconciliationNeeded again. Or assign a license, convert to shared and remove the license. Still this seems to be a bug and should be fixed.
Post a Comment