Shared Mailboxes in Exchange Hybrid now work cross premises


Shared mailboxes within an Exchange/Office 365 hybrid environment are now fully functional using Full Access permissions. This has been a limitation for some customers migrating to Office 365 up until now. With this restriction removed, customers can now fully support a long term migration process or even a permanent hybrid choice for their company.

In on-premises Exchange deployments, users can be granted a variety of permissions to other user’s mailboxes. This is called delegated mailbox permissions and it is useful when someone needs to manage some part of another user’s mailbox; for example, managing an executive's calendar, or if multiple users have access to a shared repository mailbox. Some of these permissions can be used in Exchange hybrid deployments.

Exchange hybrid deployments support the use of the Full Access mailbox permission between mailboxes located in an on-premises Exchange organization and mailboxes located in Office 365. A mailbox on an on-premises Exchange server can be granted the Full Access permission to an Office 365 mailbox, and vice versa.

Note: Users might receive additional credential prompts when they first access a mailbox that is in the other realm and add it to their own Outlook profile.

While Exchange hybrid configurations do support the use of the Send-As, Receive-As, or Send on behalf of mailbox permissions, these permissions are only available when both the mailbox granting the permissions, and the mailbox receiving the permissions, are in the same realm. Any mailboxes that receive these permissions from another mailbox need to be moved at the same time as that mailbox. If a mailbox receives permissions from multiple mailboxes, that mailbox, and all of the mailboxes granting permissions to it, need to be moved at the same time and exist in the same realm of either on premises or Office 365 Exchange organizations. In addition to these permissions, the Auto Mapping feature is unsupported when used between mailboxes in the on-premises Exchange and Office 365 organizations.

Over the last few months of helping customers, I have seen where this shared mailbox access topic has been a limitation. I am happy to be able to post this material and be able to update customers that this issue has a resolution. For further reading, visit the TechNet page for additional knowledge. Thank you.

 

Comments (34)

  1. small note says:

    only when you have 2013/2016 onprem
    (rob works on 2010 also but officially only 2013/2016)

  2. Al Napp says:

    Thanks for that news 🙂

    May I clarify something?

    Only “Send-As”, “Receive-As”, or “Send on behalf of” mailbox permissions don’t work when the relationship is split on prem/cloud and any other permissions (e.g. a shared calendar or inbox subfolder) as well as “Full Access” should work across the divide?

    Is that correct, and if so: is it still the case that this only works if all mailboxes originated on prem and migrated to the cloud?

    Cheers

    Al

    1. Mike_O'Neill says:

      Correct. There are some inconsistencies if you create a cloud mailbox and move it on premises.

  3. Bhavesh says:

    Will Shared mailbox works if…
    1) if client machine has Office365 Pro plus user account is in O365.
    2) Shared mailbox is in Onprem
    3) re-assgined shared mailbox permission for user.

    At this moment im seeing shared mailbox not updating or sometimes even though permissions are re-added it doesnt work.

    1. Mike_O'Neill says:

      It would not depend on the client, but the Exchange back end on premises if it’ll work. 2010 Exchange can be hit or miss, 2013+ should work.

  4. Just to clarify this is regarding the Free Shared mailboxes? not just a licensed user’s mailbox that’s been shared with other users?

    1. Mike_O'Neill says:

      Any sharing across realms. The Exchange PG is continuing to address this issue and work on newer options moving forward.

  5. is there a good article, or what is the proper way to migrate shared mailboxes and calendars to Office 365?

    1. Mike_O'Neill says:

      I always point people to the EXDEPLOY site: https://technet.microsoft.com/en-us/office/dn756393.aspx It has all of the migration options, tons of steps, and is updated often.

  6. Neil Osmond says:

    I have an issue at one of my accounts where we are migrating from an existing Exchange 2010 Org to a new Exchange 2013/O365 Hybrid as the business is splitting from another business. The Shared Mailboxes are remaining on the Exchange 2010 Org during the migration period (using Quest Tools for Mailbox Migration) but we need the users to connect to O365 Mailbox and then also connect back to old Org for Shared Mailbox using Outlook 2016. When we connect the first Shared Mailbox we use the Exchange 2010 AutoDiscover Name and this works ok but if connect further Shared mailboxes the same way … the one that was already connected automatically redirects to the Office 365 copy and then the new shared mailbox connection goes back to the Exchange 2010 legacy Org. so it seems we can only point back one Shared Mailbox … Have you seen this before ?

    1. Mike_O'Neill says:

      Need to ensure Autodiscover is pointing to the 2016 servers. The 2010 servers don’t know of the future, but the 2016 ones know of the past. And yes, all hybrid environments point autodiscover on premises. It’s a quiz question that is some times not fully understood.

  7. Dan Lavely says:

    Cross-premise Calendar management, such as “managing an executive’s calendar,” does NOT work. I just spent two days w/Microsoft support proving that. You can view calendar items in a shared calendar cross-premise, but you cannot “manage,”, i.e., “change or create items on” the shared calendar. These statements are too vague to be of use once you get into the details of trying to make it actually work.

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  8. Filip Herman says:

    It doesn’t apply to Exchange 2010 and lower

    1. Mike_O'Neill says:

      Correct. This is just a reference the MS site stating 2013+ is supported.

  9. Andrii says:

    Hi Mike,

    thank you for the good news! Mike, I have one question, will it work if I just grand “full/send as” permissions to on premise mailbox? or some additional changes should be applied?

    Andrii

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  10. AndySpecial says:

    To clarify the ‘Send As’ permission….it seems from this posting that in order for a user to ‘send as’ for a shared mailbox, both the user and the shared mailbox need to be on-prem OR both moved to O365… is that correct?

    a) shared mailbox exists on-prem
    b) user moved to O365 and Outlook 2016 – granted full control over shared mailbox
    c) user gets error: You do not have permissions to send the message on behalf of the specified user

    So if I move the shared mailbox to O365, that user SHOULD be able to ‘send as’ the shared mailbox ?

    thanks very much

    1. AndySpecial says:

      I have my answer after testing….

      As per the prior post:
      “Send-As”, “Receive-As”, or “Send on behalf of” mailbox permissions don’t work when the relationship is split on prem/cloud.

      Even if one specifies in O365 Active Users – Edit Mailbox permissions – Add the shared mailbox under ‘Send As’ section…the user will receive permission error. (User migrated to O365 and the shared mailbox is still on-prem).

      Thanks everyone for your observations.

    2. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  11. Pete_B says:

    That’s great news! This is the last issue we need resolved before we begin migrating to Exchange online.

    however we cant get this working… When trying to add an Office 365 user to the full access permission on a on-prem 2013 shared mailbox the list of users available to choose from are only on-prem users, all office 365 users are excluded from the list and you cannot manually add a user no on the list. maybe I’ve miss-configured something?
    We are running Exchange 2013 CU 16 on Server 2012 R2. do we need CU 17 for this to work or was this change in exchange online?

    Thanks
    Pete

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  12. Christopher Quinn says:

    Is this still true? We have clients that have recently been migrated from Exchange 2010 on premise to Office 365. The shared mailbox is still on premise, and no changes have been made. Yet they continue to see the mailboxes auto mapped.

    1. Mike_O'Neill says:

      We have seen from the field that some 2010 environments, sharing can work. We have no information on why or what options to configure.

  13. RDeelap says:

    So, are 2010 Hybrids not able to share/view calendars? I’ve allowed as much as I can on both sides and they still cannot view calendars. None of the O365 users can give permissions to their calendar to on prem users. None of the on-prem users can add the O365 calendars.

    1. Mike_O'Neill says:

      Correct, the technet information states only 2013 and 2016 are supported for cross realm sharing of the calendar information.

  14. Kourosh says:

    Hi. Our production exchange servers are 2010. Our hybrid servers are exchange 2016 though.

    IN ORDER TO TAKE CARE OF THIS PROBLEM –> Will it be sufficient if we use exchange 2016 to act as hybrid servers while keeping backend servers at 2010? Will it take care of shared mailboxes access issue mentioned here?

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  15. Jeff B says:

    Can you clarify this point from the technet article.
    “If a mailbox receives permissions from multiple mailboxes, that mailbox, and all of the mailboxes granting permissions to it, need to be moved at the same time.”

    Does this point only apply to permissions other than full access or all permissions? Or is it simply referring to maintaining permissions during the migration of a mailbox as in if both mailboxes aren’t moved simultaneously then permissions between those mailboxes will need to be recreated post migration, or is it saying that any user can only be delegated permissions to one cross premises shared mailbox and vice versa?

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  16. Vinícius Ferrão says:

    This is a bit old… but I can’t add users from O365 to full access on Shared Mailboxes On-Premises. The user simply does not appear on the web interface to do the delegation.

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

  17. Parveen Khanna says:

    May I ask how does Full Access permissions across Exchange Online and Exchange On-premises works ? I am not sure if some attributes is stored in On-premises AD having list of users who have full access to a particular mailbox ( like we have attribute publicDelegate for Send-on-behalf-of permission ).
    Can you clarify under the hood what is making this happen ?
    Thanks

    1. Mike_O'Neill says:

      Watch about 10 minutes of the video starting at 32.10: https://www.youtube.com/watch?v=pN6lsxKRrJQ It shows what is broken, what works, and why each scenario is broken.

Skip to main content