Configure Exchange Hybrid mailbox permissions during migration to Exchange Online

Exchange logo

This is a simplified guide with everything that you need to do in order to get hybrid permissions working when migrating to Exchange Online.

In order to configure your Exchange organisation to support these permissions, you need to follow the steps which are outlined here: The first thing you need to do is update to the latest CU, whichever version of Exchange on-premises you are running.


The remaining steps required can then be summarised as follows:

Exchange version
Mailbox Configuration
Install the latest CU
Set ACLableSyncedObjectEnabled
Set msExchRecipientDisplayType for any mailboxes migrated before ACLableSyncedObjectEnabled was set.
2010Install the latest CUSet msExchRecipientDisplayType for every mailbox before and after migration


1. Update your on-premises Exchange servers to the latest CU (2010/2013/2016).

This is a requirement for Exchange hybrid anyway, and will make the next steps easier.

2. Enable object synchronization at organization level (Exchange 2013/2016 only)

Unless you are on Exchange 2010, run the following using Exchange PowerShell on-premises:

get-OrganizationConfig | Select-Object ACLableSyncedObjectEnabled

If this is not set to true, enable it:

Set-OrganizationConfig -ACLableSyncedObjectEnabled $True

3. Enable ACLs on remote mailboxes.

Make sure you have enabled ACLable object synchronization at the organization level as above.

Enabling ACLs will depend on which version of Exchange you are running. If you are running the latest CU of 2013 or 2016, you just need to do this once for any mailboxes moved before you enabled ACLableSyncedObjectEnabled in your Organization.

If you are running Exchange 2010, you will need to do this every time you migrate a mailbox to Exchange Online, so incorporate this into your migration scripts.

So, run this to get any mailboxes already moved:
Get-RemoteMailbox | ForEach {Get-AdUser -Identity $_.Guid | Set-ADObject -Replace @{msExchRecipientDisplayType=-1073741818}}
Or for individual mailboxes as they move (make sure they have been migrated):
Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

Note: There are 2 possible values listed to make a mailbox ACLable:
ACLableSyncedMailboxUser: -1073741818
ACLableSyncedRemoteMailUser: -1073740282

I suspect that -1073740282 will also work but have not tested this. -1073741818 is the value that is set automatically once you have enabled ACLableSyncedObjectEnabled for the organization, therefore this is the one you should use.

Note that you can check the setting for all migrated mailboxes like this:

$arrUser = @()
$arrUser += Get-RemoteMailbox | ForEach { Get-AdUser -Identity $_.Guid -Properties msExchRecipientDisplayType }
$arrUser | Format-Table -AutoSize Name,msExchRecipientDisplayType #All users
$arrUser | where-object {$_.msExchRecipientDisplayType -ne “-1073741818”} | Format-Table -AutoSize Name,msExchRecipientDisplayType #Just the users with the wrong value


This should work between migrated and non-migrated users, as long as the autodiscover record points to the on-premises hybrid URL. It is configured during hybrid setup.

Configure permissions

Permissions can be configured for all scenarios, and will work in both directions.

There are however some limitations:

  • 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. Automapping does not work.
  • 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 (note from Exchange Online to on-premises requires Exchange attributes written back).
  • Send-As: Not supported, but if you add the send-as permission manually in both environments, Send-As will work in most of the scenarios.
  • Individual folder permissions are not supported.

For migration purposes, the only permission that is not carried through migration is when a migrated user has SendAs rights on an on-premises mailbox. This can actually be set before either mailbox is even migrated since it is an AD permission, so this can be done before users are migrated. See line four in the spreadsheet, this can be set in Exchange Online using e.g. Add-RecipientPermission -Identity “O365 Onprem-23” -Trustee cloud-23 -AccessRights SendAs.

All other permissions e.g. Delegate, Full Access, Send On Behalf of, will work without any further configuration.

Specific examples and commands required

The following table shows how to set permissions if required. Almost all permissions are carried across during migration, so these are mostly only required if new permissions are required during migration.

I recommend performing these tests yourself using completely separate accounts for each test, in order to avoid confusion over which permissions are required. Use the following spreadsheet as a guide.

#TypeSource (user)Target (mailbox user is accessing)Working?NotesAccountsPowerShellDelay if setting up newTestedWorking after migration?
1Full AccessOn-premCloudYCheck with Get-MailboxPermission -Identity cloud-20Onprem-20 /cloud-20Exchange Online:NoneYYes, but automapping is removed after a few minutes, so mailbox has to be added again via Outlook acccount settings.
Does not automapAdd-MailboxPermission -Identity "cloud-20" -User "onprem-20" -AccessRights FullAccess -InheritanceType All
2Full AccessCloudOn-premYCheck with Get-MailboxPermission -Identity onprem-21Onprem-21/ cloud-21Exchange on-premises:NoneYYes, automapping remains
Does not automapAdd-MailboxPermission -Identity "onprem-21" -User "cloud-21" -AccessRights FullAccess -InheritanceType All
3Send AsOn-premCloudYNot fully supported by MicrosoftOnprem-22 /cloud-22Exchange on-premises:??YYes, because permission still exists on on-prem AD object
Check using:Add-ADPermission -Identity "o365 cloud-22" -User "onprem-22" -AccessRights ExtendedRight -ExtendedRights "Send As"
Get-ADPermission -Identity "cloud-22" | Where-Object { ($_.ExtendedRights -match "Send-As")}Exchange Online:
get-RecipientPermission -Identity cloud-22Add-RecipientPermission -Identity cloud-22 -Trustee onprem-22 -AccessRights SendAs
Remove with remove-recipientpermission
4Send AsCloudOn-premYNot fully supported by MicrosoftOnprem-23/ cloud-23Exchange on-premises: Several hours.YNo, SendAs permission is not migrated, add Exchange Online permission using Add-RecipientPermission.
However this permission can be set before mailbox migration using add-recipientpermission before the mailbox is even migrated.
Had to download the address book.
Check using:Add-ADPermission -Identity "O365 Onprem-23" -User cloud-23 -AccessRights ExtendedRight -ExtendedRights "Send As"
Get-ADPermission -Identity "o365 onprem-23" | Where-Object { ($_.ExtendedRights -match "Send-As")}Exchange Online:
get-RecipientPermission -Identity "O365 Onprem-23"Add-RecipientPermission -Identity "O365 Onprem-23" -Trustee cloud-23 -AccessRights SendAs
Remove with remove-recipientpermission
5Send on behalf ofOn-premCloudYPermissions are set in sending users org.Onprem-24 /cloud-24Exchange Online:Run AD sync or waitYYes
Requires that users have msExchRecipientDisplayType set to 2073741818 on the remote (cloud) mailbox.Set-Mailbox "cloud-24" -GrantSendOnBehalfTo onprem-2430 mins
Set this, and it will be written back Exchange on-premises, you can connect to Exchange Online after AAD sync and check using:
Check on prem after sync:Get-RemoteMailbox "cloud-24" | fl GrantSendOnBehalfTo
Get-RemoteMailbox "cloud-24" | fl GrantSendOnBehalfToIt will not work until written back.
6Send on behalf ofCloudOn-premYCheck:Onprem-25/ cloud-25Exchange on-premises:Several hours.YYes because permission still exists on-premises
Get-Mailbox "onprem-25" | fl GrantSendOnBehalfToSet-Mailbox "onprem-25" -GrantSendOnBehalfTo cloud-25
7Outlook Calendar delegateOn-premCloudYLogon as cloud-26 and make onprem-26 a delegate first.
1. Send a meeting to cloud-26, should be received by delegate
2. Open Inbox
3. Open Calendar
Onprem-26 /cloud-26YYes, all 3 working
8Outlook Calendar delegateCloudOn-premYLogon as onprem-27 and make cloud-27 a delegate first.
1. Send a meeting to onprem-27, should be received by delegate
2. Open Inbox
3. Open Calendar
Onprem-27/ cloud-27YYes, all 3 working

Configure Exchange Hybrid mailbox permissions during migration to Exchange Online – Spreadsheet2

Posted in Exchange Online, Office 365

Related Posts

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: