Blog Post

Exchange Team Blog
3 MIN READ

Converting mailboxes already migrated to Exchange Online to Shared mailboxes

The_Exchange_Team's avatar
Aug 29, 2022

Let’s say that your organization is in Exchange hybrid setup and you already migrated some mailboxes to Exchange Online. Now you need to convert some of those migrated user mailboxes to shared mailboxes. How do you do this? This is a question that we get from our customers a lot.

The tricky part here arises because the mailboxes have already been migrated to Exchange Online. This means you can’t simply use Set-RemoteMailbox -Type Shared as per the documentation. Moreover, because they’re objects that are synced from Active Directory (AD) just modifying them from the Exchange admin center in the cloud won’t work because the object is mastered on-premises. Finally, you might have used Set-RemoteMailbox -Type Shared from on-premises without errors/warnings, but the change doesn’t replicate to Exchange Online even after forced syncs.

How to check if the mailbox was already migrated?

From PowerShell connected to Exchange Online, you can check the RemoteRecipientType value using Get-Mailbox:

If the mailbox you want to convert has a type of ProvisionMailbox, you can use the Exchange Management Shell to run Set-RemoteMailbox -Type Shared. That cmdlet has been available since Exchange 2013 CU21/Exchange 2016 CU10.

My mailbox says ‘Migrated’, so what’s the next step to convert it?

If the environment permits it, you can offboard, convert while on-premises, and then migrate back to Exchange Online. This will ensure the right values on mailbox attributes and the recipient type details will be respected by both directories.

If you’ve already used Set-RemoteMailbox -Type Shared on-premises, you’ll notice that you don’t get an error/warning even if the mailbox is Migrated and that, when looking at the object on-premises, the remote mailbox is a Shared mailbox, while the cloud considers it a UserMailbox (in next screenshots, I used red for highlighting the UserMailbox values and green for SharedMailbox):

Exchange Management Shell on-premises shows the following:

While Exchange Online shows:

To get things “in sync” you have to do the conversion again cloud-side, either from the Exchange admin center or Exchange Online PowerShell by running Set-Mailbox -Type Shared for the mailbox:

Since the values coming from on-premises through AAD Connect are correct, there is no risk of it overwriting unwanted values during the next sync.

If you already converted to SharedMailbox in the cloud and this value is getting overwritten with UserMailbox because you don’t have the appropriate values on-premises, you’ll need to also do the necessary changes from on-premises as per this guidance. That will ensure that the wanted values are in place to match the action you wanted after the next sync.

If you are trying to convert to a Shared mailbox, removing the license should be done after seeing it the mailbox marked as Shared in Exchange Online. Similarly, if the goal is to convert the mailbox to Regular, the license should be assigned prior to conversion so that the mailbox always has the proper license in place (and to avoid any accidental mailbox data deletions). While shared mailboxes generally do not require a license, there are scenarios when they do (see this).

Thank you for your help and review on this to Mukesh Kumar and Nino Bilic.

Corina Ionescu

Published Aug 29, 2022
Version 1.0
  • hatsikidee's avatar
    hatsikidee
    Brass Contributor

    Thanks for this article. I already figured out that you need to set the type on the mailbox twice. Glad to see that it's the correct way to do it 🙂

     

    Just out of curiosity... it looks like the on-prem change is replicated to AAD with AAD connect, shown in your examples. Why then doesn't Exchange Online modify the type on the mailbox automatically? I would say that if the RemoteRecipientType is modified, EXO is aware of the change and would modify the setting on the mailbox as well. So why is this not done?

     

    Thanks.

  • sjhudson's avatar
    sjhudson
    Brass Contributor

    Thanks Corina, this helped a lot.

    Creating, migrating, and converting Shared and Regular mailboxes in an Exchange Hybrid environment can be a minefield!

    It would be nice to see an article based on the opposite procedure…

    Converting Shared mailboxes already migrated to Exchange Online to Regular (User) mailboxes

    Thanks again Stephen

  • SaschaSeipp's avatar
    SaschaSeipp
    Brass Contributor

    The_Exchange_Team : So what I take from that is this:

    • If the cloud mailbox has the status of Shared mailbox and OnPrem Exchange still "thinks" it is a user mailbox, then via AADC, the cloud is able to convert it (back) to a user mailbox. If that functionality is in there, then why not provide the correct way for the intended changes?! (Probably kind of the same question as hatsikidee posted before).
    • Those Shared mailboxes directly created via New-/Enable-RemoteMailbox -Shared should have the RemoteRecipientType "ProvisionMailbox" and hence don't have the problem from Ex2016 CU10 on, right?
    • If the currently more or less Microsoft supported way to fix this problem is to directly fiddle with AD properties, wouldn't it be easier to change all the mailboxes with RemoteRecipientType "Migrated" to "ProvisionMailbox" and be done with the problem once and for all (at least for those customers that don't need to migrate OnPrem mailboxes any more)? Obviously this would need to be made possible in Exchange Online, which I suppose it is not right now.
  • hatsikidee , thanks for checking this!

    One of the reasons for further checking and writing this blog was precisely the same curiosity you had, more specifically that it allows you to run the cmdlet in Exchange Management Shell and we do see Azure AD recognizing the change from on premises, while Exchange Online is not getting the memo to actually do the change 🙂

     

    What we found during that investigation was that the design limitation is with the cmdlet itself, since Set-RemoteMailbox -Type Shared doesn't trigger for Migrated mailboxes as it does for Provisioned ones. That isn't something that we could modify the behavior for at this time, so the documentation for the cmdlet was modified to include this bit "A migrated shared mailbox cannot be converted to a regular mailbox and a migrated regular mailbox cannot be converted to a shared mailbox." to raise awareness.

  • sjhudson , Happy to hear that you found this useful!

    What I have mentioned in this blog applies for the reverse scenario as well, just that it's more common to want to convert to Shared so I focused on that.

  • SaschaSeipp , thanks for the comment! I'll answer in line :

    • If the cloud mailbox has the status of Shared mailbox and OnPrem Exchange still "thinks" it is a user mailbox, then via AADC, the cloud is able to convert it (back) to a user mailbox. If that functionality is in there, then why not provide the correct way for the intended changes?! (Probably kind of the same question as @hatsikidee posted before).  -->For this specific scenario, it's a limitation from the cmdlet Set-RemoteMailbox -Type when it comes to Migrated mailboxes. It wasn't designed to handle Migrated ones this way, so it has this behavior that looks unexpected since you see the info correctly in the source of authority from OnPrem, but cloud doesn't update accordingly. This is not something that can be modified at this time.
    • Those Shared mailboxes directly created via New-/Enable-RemoteMailbox -Shared should have the RemoteRecipientType "ProvisionMailbox" and hence don't have the problem from Ex2016 CU10 on, right? --> Correct. The parameter was introduced with that version going forward and was catered for ProvisionMailbox .
    • If the currently more or less Microsoft supported way to fix this problem is to directly fiddle with AD properties, wouldn't it be easier to change all the mailboxes with RemoteRecipientType "Migrated" to "ProvisionMailbox" and be done with the problem once and for all (at least for those customers that don't need to migrate OnPrem mailboxes any more)? Obviously this would need to be made possible in Exchange Online, which I suppose it is not right now.  --> The preferred and classic workaround would be to offboard - modify while on premises - onboard again, but we're aware that this is not something that is always possible (especially for customers that started in Exchange hybrid, migrated everything to cloud and only kept an Exchange server for management purposes). Manually fiddling with AD properties in general is something we usually don't want unless there's a KB mentioning it as a workaround (if in a KB, it means it got tested specifically for that scenario and there shouldn't be any surprises).