It seems everyone today is looking to migrate most workloads to Office 365, or at least migrate part of their on-premise workload to Office 365. One of the most popular items we see customers migrate first is the Exchange workload…and why not? Exchange on-premise can easily be one of the bigger “resource hogs” in the environment and it requires routine planning and maintenance to keep it running at a supported Microsoft best-practice level.

That is why so many of our customers choose to migrate to Exchange Online as their first big push into Office 365. Some of the common questions customers tend to ask about is cross-premise functions in an Exchange Hybrid deployment. Specifically, delegate mailbox permissions like Full Access, Send on Behalf, Send As and folder permissions. Since this can be a bit difficult to find clear answers on what specifically works and is supported.

In this post we will review what Microsoft fully supports, what they do not support, and what does work…if you have all of the right components in place.

First things first

Before deploying your Hybrid Exchange coexistence with Exchange Online (OFFICE 365), it is recommended to get your existing on-premise Exchange servers up to the latest SP/RU or CU. This will help ensure that everything works as expected as some older versions of Exchange 2010/2013 do not have the required or are not supported at all.

  • Exchange 2016 – No additional configuration is required.
  • Exchange 2013 – A supported Exchange 2013 cumulative update (CU) and additional configuration are required.
  • Exchange 2010 – A supported Exchange 2010 update roll (RU) and additional configuration are required.

We will dive a bit further into the specific requirements for cross-premise delegate permissions in the next sections, but just know that getting Exchange patched to the latest versions should always be a pre-requisite before deploying Exchange Hybrid with Office 365.

To find the latest release for your Exchange environment, see the following TN article.

Note: You should also be running the latest version of Azure Active Directory Connect (AD Connect). At a minimum you must be running version 1.1.553.0 and make sure that you have selected ‘Exchange Hybrid Deployment’ during the configuration of AD Connect. Also, as a Microsoft best practice, at least one Hybrid Exchange Server should always be deployed when you are using AD Connect and Exchange Online (more on that in a blog post to come…)

Click here to download the latest version of AD Connect.

Delegate Permissions

There are several types of delegate permission that can be configured in an Exchange environment. These permissions and features are Full Access, Send on Behalf, Send As, Private items, and Folder permissions, Auto-mapping.

As of February 2018 the feature to support Full Access, Send on Behalf and folder rights cross forest is being rolled out and expected to be complete by April 2018.

Supported Permissions

Full Access

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. Users need to open the mailbox using the Outlook desktop client; cross-premises mailbox permissions aren’t supported in Outlook on the web.

Send on Behalf of

A mailbox on an on-premises Exchange server can be granted the Send on Behalf of permission to an Office 365 mailbox, and vice versa. For example, an Office 365 mailbox can be granted the Send on Behalf of permission to an on-premises shared mailbox. Users need to open the mailbox using the Outlook desktop client; cross-premises mailbox permissions aren’t supported in Outlook on the web.

Private items

When adding a delegate the option can be configured to allow a user with folder permissions to see private calendar items.

Unsupported Permissions and features

  • Send-As lets a user send mail as though it appears to be coming from another user’s mailbox.
  • Auto-mapping enables Outlook, when it starts, to automatically open any mailboxes that a user has been granted Full Access
  • Folder permissions grants access to the contents of a particular folder.

Note: While these permissions are currently labeled as “Unsupported”, they can work if you have all of the pre-requisites in place. Namely the latest version of Exchange on-premise installed as detailed in the previous section.

Configure Exchange On-Premise to Support Hybrid Delegate Permissions

As stated above, the officially supported features at the time of writing this blog post are Full Access, Send on Behalf and folder permissions, keeping in mind that Send As permissions can also work cross premise. Regardless, there may be some additional changes you need to make to your on-premise environment to support ANY of these features, depending on your current version of Exchange.

Use this table as a guide to determine if your environment meets the prerequisites to support cross-premise delegate permissions.

Exchange version Prerequisites
Exchange 2016 No additional configuration required.
Exchange 2013 Exchange 2013 servers need the following:

  • The latest cumulative update (CU), or the immediately previous CU, installed. Exchange 2013 servers running older CUs aren’t supported and may not work with delegated mailbox permissions in a hybrid deployment.
  • The Exchange organization is configured to allow access control lists (ACLs) to be stamped on mail objects and synchronized with Office 365.
  • On-premises remote mailboxes associated with mailboxes moved to Office 365 prior to Exchange 2013 CU10 need to be manually configured to support ACLs. Remote mailboxes, created on servers running Exchange 2013 CU10 or later, and after the Exchange organization is set to allow ACLs, are configured automatically.
Exchange 2010 Exchange 2010 SP3 servers need the following:

  • The latest update rollup (RU), or the immediately previous RU, installed. Exchange 2010 SP3 servers running older RU aren’t supported and may not work with delegated mailbox permissions in a hybrid deployment.
  • On-premises remote mailboxes associated with Office 365 mailboxes need to be configured to support ACLs. This needs to be done for each on-premises remote mailbox that’s associate with an Office 365 mailbox.
Exchange 2007 or earlier Not supported.

 

Use the Inscape platform to for FREE to get 360-degree insight and control over Office 365 licensing, permissions, security risks, and threats. Get Started

Enable ACLable objects

If your Exchange On-Premise organization is already running the latest CU of Exchange 2013, and the ACLable object sync is enabled in your environment, then you are good to go. If not there are a few additional steps that you will need to do to enable the cross-premise delegate permissions.

This table breaks down what steps you will need to take based on the level and configuration of Exchange 2013 on-premise when you migrate or migrated users to OFFICE 365 and at that time:

Installed version ACLable object synchronization Then you need to…
Exchange 2013 CU9 or earlier This feature isn’t available in Exchange 2013 CU9 and earlier. Manually configure each mailbox to support ACLs.
Exchange 2013 CU10 or later Disabled.
  1. Enable ACLable object synchronization at the organization level
  2. Manually enable ACLs on each mailbox moved to Office 365 before ACLable object synchronization was enabled at the organization level.

No additional configuration is needed for mailboxes moved to Office 365 after ACLable object synchronization is enabled at the organization level.
Exchange 2013 CU10 or later Enabled. No additional configuration is needed.

Enable ACLable object sync (Exchange 2013 CU10 and up)

To enable ACLable object synchronization at the organization level, do the following:

  1. Install the latest version of Azure Active Directory Connect (AAD Connect) on all of your AAD Connect servers. This is needed to allow AAD Connect to synchronize the attributes needed to support hybrid permissions. You can download AAD Connect from Microsoft Azure Active Directory Connect.
  2. Open the Exchange Management Shell on a server running the latest available Exchange 2013 CU, or the immediately previous CU.
  3. Run the following command: Set-OrganizationConfig -ACLableSyncedObjectEnabled $True

After you do this, any mailboxes that you move to Office 365 will be properly configured to support delegated mailbox permissions.

Enable ACLs on remote mailboxes

If mailboxes were moved to Office 365 prior to you completing the steps above, you’ll need to manually enable ACLs on those mailboxes. If you are still running Exchange 2010 SP3, you will need to do this for all mailboxes migrated unless you upgrade to Exchange 2013 CU10 or higher.

To enable ACLs on mailboxes moved to Office 365 before ACLable object synchronization was enabled at the organization level, do the following.

  1. Open the Exchange Management Shell on a server running the latest available Exchange 2013 CU, or the immediately previous CU.
  2. To enable ACLs on a single mailbox, run the following command: Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}
  3. To enable ACLs on all mailboxes moved to Office 365, run the following command: Get-RemoteMailbox | ForEach { Get-AdUser -Identity $_.Guid | Set-ADObject -Replace @{msExchRecipientDisplayType=-1073741818}}
  4. To verify that the mailboxes have been successfully updated, run the following command: Get-RemoteMailbox | ForEach { Get-AdUser -Identity $_.Guid -Properties msExchRecipientDisplayType | Format-Table -AutoSize DistinguishedName, msExchRecipientDisplayType}

Send As – does it work?

The short answer is YES, the Send-As permission will work cross premise. Although it is NOT SUPPORTED officially by Microsoft. So if you follow all the instructions and you cannot get Send-As to work properly, the only option is to move the shared mailbox to Office 365 at the same time as the user mailbox.

That said, there are a few gotchas we have seen in production Hybrid environments with the Send-As permission. Specifically, when it comes to assignment of the Send-As permission by group. If you have assigned the Send-As permission to user(s) via an on-premise security group, you will need to assign the Send-As permission to the individual user’s from Exchange Online PowerShell after the migration.

Example of re-assigning SendAs after migration

[email protected] has migrated to Office 365 and previously was assigned the SendAs permission to [email protected] which is still on-premise in Exchange 2010/2013/2016. The permission was assigned via a security group that User1 is a member of in AD. Even though the security group is synced to Azure AD via AD Connect, the Send As permission does not work.

To fix this we connect to Exchange Online via PowerShell and run the following command:

Add-RecipientPermission <identity> -AccessRights SendAs -Trustee <user>

User1 (in Office 365) should now be able to send mail as [email protected] (in Exchange on-prem). The command would need to be re-ran for any other Office 365 user who needs SendAs permissions to [email protected]

Note: If all of these instructions are followed and the user still cannot SendAs, then the only Microsoft Supported option will be to migrate the shared mailbox to Exchange Online as this feature is not officially supported to work at this time.

References

Was this article helpful?
YesNo