Cross-premises Full access permissions are now supported

Some of you might have already heard the news – Full access permissions are now officially supported between on-prem and Exchange Online mailboxes. I was waiting for the likes of Mr. Van Hybrid to post a detailed article, so I can just point to it, however they seem to be busy with other stuff, so here’s my humble attempt 🙂

First of all, we’re not talking about migrating or preserving permissions during mailbox moves, that’s different. We’re talking about real cross-premises scenarios – mailbox A located on-prem is accessing data from mailbox B located in Exchange Online. Or vice versa. Such cross-premises permissions have “worked” for a while now. To resolve some issues around this scenario however, changes were needed on both server and client side and thus the supportability statement from Microsoft up until now was “not supported”. Well, it seems that Microsoft is now finally confident enough that those issues are solved, thus the corresponding TechNet article has been updated to reflect the updated statement for support for cross-premises mailbox permissions. Here are the relevant bits from the article:

Support for cross-premises mailbox permissions 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. For example, an Office 365 mailbox can be granted the Full Access permission to an on-premises shared mailbox.

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

We don’t, however, support the use of the Send-As, Receive-As, or Send on behalf of mailbox permissions in hybrid deployments between on-premises Exchange and Office 365 organizations. These permissions are only available when both the mailbox granting the permissions, and the mailbox receiving the permissions, are in the same organization. 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. In addition to these permissions, the Auto Mapping feature is also unsupported when used between mailboxes in the on-premises Exchange and Office 365 organizations.

Yes, there are several caveats, and some of those are important ones. Only Full Access permissions are supported, nothing else. No permissions on the folder level! No Send As, Receive As, Send on behalf of. No support for automapping (which means no support for accessing Archive mailbox for the mailbox in the other organization)! You need to have Outlook with the November 2015 updates or later, and even with those you might still receive additional credential prompts.

The quote from the article above is a bit unclear on one point, but Microsoft’s Tim Heeney has clarified this for us – Full access permissions will work before and after a move. The other unclear part is how you actually grant permissions. When adding delegates to an EO mailbox, you can do this either via the EAC or via PowerShell. For an on-prem mailbox however, PowerShell is your only choice, as cloud objects will not be visible in the mailbox picker under the on-prem EAC (the picker in EO will show both mail-enabled users and mailboxes on the other hand).

Another point that probably needs clarifying is the information provided in this TechNet article. The article discusses the details around cross-premises delegation for *dedicated* Office 365 tenants. While the articles mentions that all types of cross-premises delegation are supported (including folder level permissions, Send As and Send on behalf of), the method used for this is quite different. It makes use of a new type of recipient, ACLableSyncedObject, with the corresponding msExchRecipientDisplayType value of “-1073741818”. This in turn requires changes in the forest schema. It will also require proper support on AADConnect level, etc. The important part is – this method is not yet supported for Office 365 multitenant customers, period.

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *