Cross-premises permissions in Exchange hybrid: Full Access, Send As and delegates

In a hybrid migration, managers, assistants and shared mailboxes rarely move on the same night, so sooner or later someone in the cloud needs access to a mailbox that's still on-premises, or the other way round. Whether that works depends on the permission: some are supported across premises, one works only if you configure it twice, and some aren't supported at all. In this post I'll set out Microsoft's support position, the preparation that makes it work, and the commands to grant and check each permission.

How it works: what's supported across premises#

When a user opens a mailbox in the other environment, Outlook finds it through Autodiscover and connects to whichever side hosts it. That side checks the permission, so the person being granted access must exist there as an object that can appear in a permission entry: an ACLable object. This is Microsoft's support position in summary:

Outlook's Delegate Access feature is a bundle: folder permissions (typically Editor on the calendar), Send on Behalf and, optionally, private items. The Send on Behalf part works across premises; the folder part isn't supported, so keep a manager and their delegates in the same environment.

Prerequisites: ACLable objects and directory sync#

1. Entra Connect. Version 1.1.553.0 or later (any current build) with the Exchange hybrid deployment optional feature turned on, so the attributes behind Send on Behalf are synchronised. Cloud Sync has its own Exchange hybrid writeback option.
2. Organisation setting. In the Exchange Management Shell, run Set-OrganizationConfig -ACLableSyncedObjectEnabled $true. Mailboxes you move to Exchange Online afterwards are stamped correctly.
3. Mailboxes moved before that. Their remote mailbox objects need the ACLable display type. Find them first, review, then fix (this needs the ActiveDirectory module):
   PowerShell

   $todo = Get-RemoteMailbox -ResultSize Unlimited |
     Where-Object RecipientTypeDetails -eq 'RemoteUserMailbox' |
     ForEach-Object { Get-ADUser $_.SamAccountName -Properties msExchRecipientDisplayType } |
     Where-Object msExchRecipientDisplayType -ne -1073741818
   $todo | Select-Object SamAccountName, msExchRecipientDisplayType
   
   $todo | Set-ADObject -Replace @{msExchRecipientDisplayType = -1073741818}

   That value is for user mailboxes; check Microsoft's article before changing shared or resource mailboxes.
4. New cloud mailboxes. When you create them from on-premises, add the -ACLableSyncedObjectEnabled switch to New-RemoteMailbox or Enable-RemoteMailbox; remote mailboxes created for the cloud aren't ACLable otherwise.

Step-by-step: grant each permission in the right place#

The examples use an on-premises shared mailbox Finance, a cloud shared mailbox sales@contoso.com, a cloud user sara and an on-premises user omar.

Full Access: grant it where the mailbox lives#

# Exchange Management Shell: cloud user gets the on-premises mailbox
Add-MailboxPermission -Identity Finance -User sara@contoso.com -AccessRights FullAccess -InheritanceType All -AutoMapping $false

# Exchange Online PowerShell: on-premises user gets the cloud mailbox
Add-MailboxPermission -Identity sales@contoso.com -User omar@contoso.com -AccessRights FullAccess -InheritanceType All -AutoMapping $false

Users then add the mailbox in Outlook desktop through File › Account Settings › Account Settings › Change › More Settings › Advanced › Add. The first connection may prompt for credentials.

Send on Behalf#

# Exchange Online PowerShell
Set-Mailbox sales@contoso.com -GrantSendOnBehalfTo @{Add="omar@contoso.com"}

For an on-premises mailbox, run the same Set-Mailbox command in the Exchange Management Shell. Directory sync carries the change across.

Send As: grant it on both sides#

Send As is checked where the sender's mailbox lives, against the object that represents the other mailbox there. Microsoft's guidance is to add it in both environments, which also keeps it working after either mailbox moves:

# Exchange Management Shell (sales is a remote mailbox object on-premises)
Add-ADPermission -Identity sales -User omar -AccessRights ExtendedRight -ExtendedRights "Send As"

# Exchange Online PowerShell
Add-RecipientPermission -Identity sales@contoso.com -Trustee omar@contoso.com -AccessRights SendAs -Confirm:$false

Delegates and folder permissions: plan the batches#

Before you build migration batches, list who has explicit calendar access on-premises, and put each mailbox in the same batch as the mailboxes it shares folders with:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  $mbx = $_.PrimarySmtpAddress
  Get-MailboxFolderPermission -Identity "$($mbx):\Calendar" -ErrorAction SilentlyContinue |
    Where-Object { "$($_.User)" -notin 'Default','Anonymous' } |
    Select-Object @{n='Mailbox';e={$mbx}}, User, AccessRights
}

The calendar folder has a localised name in some languages; adjust the path if the command returns nothing. My migration batches guide covers running and completing the moves.

Verify#

# Exchange Online PowerShell
Get-MailboxPermission sales@contoso.com | Where-Object { -not $_.IsInherited } | Format-Table User, AccessRights
Get-RecipientPermission sales@contoso.com -AccessRights SendAs
Get-Mailbox sales@contoso.com | Format-List GrantSendOnBehalfTo

# Exchange Management Shell
Get-MailboxPermission Finance | Where-Object { -not $_.IsInherited } | Format-Table User, AccessRights
Get-ADPermission sales | Where-Object { $_.ExtendedRights -like '*Send-As*' } | Format-Table User, ExtendedRights

Good looks like:

• Each grant appears in the environment that hosts the mailbox, and Send As appears on both sides.
• Sara opens Finance in Outlook desktop and can read and file items.
• A message Omar sends on behalf of Sales shows both names to the recipient; a Send As message shows only Sales.

Tips and gotchas#

• Mailboxes that stop appearing. A mailbox Outlook used to add automatically may not appear once one side has moved, because auto-mapping doesn't work across premises. Add it manually; see shared mailbox automapping.
• Explicit beats inherited. Explicitly granted permissions move with a mailbox when the person who holds them is mail-enabled in Exchange Online; inherited ones don't. Replace inherited access with explicit grants before the move.
• Groups. Exchange Online only accepts mail-enabled security groups for mailbox permissions. For cross-premises access, grant individual users where you can.
• Send As failures. An NDR mentioning SendAsDeniedException usually means the permission is missing on the sender's side. Allow time for replication before retesting.
• Admin roles don't transfer. Exchange RBAC role groups on-premises have no effect in Exchange Online; re-create admin permissions there.

References#

• Permissions in Exchange hybrid deployments (Microsoft Learn)
• Configure Exchange to support delegated mailbox permissions in a hybrid deployment (Microsoft Learn)
• Overview of delegation in a Microsoft 365 hybrid environment (Microsoft Learn)