Cross-forest permissions have long been one of the more difficult aspects of an Exchange Hybrid migration. Ensuring mailbox permissions are preserved can be a major undertaking.
Exchange Hybrid migrations did not support any sort of cross-forest mailbox permissions at first. After a couple of years Microsoft made it possible for full access permissions to work cross-premises.
Recently Microsoft has improved the cross-forest permissions story for Exchange Hybrid migrations. In this blog post, I’ll give you the information you need to set the different permissions in your Exchange Hybrid deployment.
Full access permissions and automapping
When Full access permissions are assigned before the move, everything continues to work. But, configuring full access permissions after a mailbox has already been migrated will not configure automapping.
The problem here is not with the permissions. The permissions are there, and they work. The problem is the automapping attributes. Two Active Directory attributes need to be updated for automapping to work. Those attributes are:
- The mailbox that is permissioned: msExchDelegateListLink
- The user who is being granted permissions: msExchDelegateListBL
In the example below, I’ll use my account (nathan@mcsmlab.com) and a generic account (sales@mcsmlab.com). Nathan is in the cloud and Sales is an on-premises mailbox.
First, I need to add permissions for Nathan to access the sales mailbox on-premises. That is done with the standard Add-MailboxPermission cmdlet in Exchange.
PS C:\>Add-MailboxPermission -Identity sales@mcsmlab.com -User nathan@mcsmlab.com -AccessRights FullAccess -InheritanceType All
I will then need to run Set-ADUser on-premises.
PS C:\>Set-ADUser -Identity nathan@mcsmlab.com -Add @{msExchDelegateListLink/BL=sales@mcsmlab.com}
Once that is done, AAD Connect will sync all the proper attributes into Azure AD and auto-mapping will work as expected.
A more technical explanation of the workaround for auto-mapping full access permissions can be found here.
Send-As permissions
Send-as permissions allows one user to send messages from another user’s primary email address.
If the Send-as permissions are setup before any accounts are migrated, then they will work. The problem again is that adding Send-as permissions after one of the mailboxes is migrated into Office 365 does not work.
The problem with Send-As permissions not working is that the actual Active Directory permissions are not synced. The work around to get Send-as permissions going is to manually add the permissions on both the cloud object and on-premises object. Using those same two accounts (Nathan and Sales) the command that need to be run in Exchange Online PowerShell is:
PS C:\>Add-RecipientPermission sales@mcsmlab.com -AccessRights SendAd -Trustee nathan@mcsmlab.com
The command to run in the Exchange Management Shell on-premises is:
PS C:\>Add-MailboxPermission -Identity sales@mcsmlab.com -User nathan@mcsmlab.com -AccessRights SendAs
This work-around is not supported by Microsoft at all at this point. They are working on a more manageable solution, but there is no ETA for that right now.
Send-on-Behalf-of permissions
Send-on-behalf is like Send-as, except the recipient sees that the message was sent by another person.
If setup before the accounts migrate, the permissions are preserved. Send-on-behalf cannot be setup across organizations though.
The problem here is that the PublicDelegates AD attribute has not been synced by Azure AD Connect. Microsoft has resolved this problem with a new version of Azure AD Connect, which is expected to be rolled out by the end of April 2018. Once your Azure AD Connect server is updated, Send-on-behalf permissions will work.
Delegate Access
Delegate access refers to a combination of rights granted by one user to another. Delegate Access is granted from within Outlook.
Configuring delegate access in hybrid Exchange deployments depends on the version of Exchange you have on-premises. This TechNet article details the configuration needed for each version of Exchange.
Wrap up
We’re still a long way from seamless cross forest mailbox permissions working in Exchange Hybrid deployments. As you can see, it can take considerable effort to set these permissions. depending on the permissions and situation in which you want to install them.
It is important to note that Microsoft still does not support modifying Exchange attributes via any tools other than the Exchange Admin Center or Exchange Management Shell. This means that several of the fixes I wrote about above are “unsupported.” I spoke with the Exchange team about this, and there is no clear answer as to which of these fixes is fully “supported” or not. Even the solutions I have listed above with links to TechNet articles may not fully count as “supported” if they require modifying Exchange attributes with tools other than Exchange.
I’d recommend you keep the cross-forest permissions to a small number of mailboxes if at all possible.
Photo by Denys Nevozhai on Unsplash
[adrotate banner=”50″]
Anyone get the following error?
Set-ADUser : The attribute cannot be modified because it is owned by the system
???
See the comments above about using “msExchDelegateListLink” not “msExchDelegateListLink/BL”.
it works but only if you put it in the correct distinguishedName format.
Set-ADUser –Identity SM-InventoryControl -add @{“msExchDelegateListLink”=”CN=name,OU=xxxxx,OU=xxxx,OU=xxxxx,DC=xxxx,DC=com”}
woops please edit out the ad user with your own, obviously.
Real talk, did you ever test this stuff before you wrote it?
I don’t believe you did
Set-ADUser -Identity nathan@mcsmlab.com -Add @{msExchDelegateListLink/BL=sales@mcsmlab.com}
Doesn’t work for me either i have tried it without the / with no success, please advise?
Thanks
Hi Nathan,
I also got error from running the following commands:
Set-ADUser -Identity nathan@mcsmlab.com -Add @{msExchDelegateListLink/BL=sales@mcsmlab.com}
is that have to run
Set-ADUser -Identity nathan@mcsmlab.com -Add @{msExchDelegateListLink=sales@mcsmlab.com}
or
Set-ADUser -Identity nathan@mcsmlab.com -Add @{msExchDelegateListBL=sales@mcsmlab.com}
Looking forward to hearing from you.
Many thanks.
Hi Nathan,
I have followed the steps in the article, and the shared mailbox in local exchange shows up in Outlook client. However, when I try to open the shared mailbox, it give the error “cannot expend the folder. The set of folders accnot be opened. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance. ”
Have you ever encountered the same issue?
Nathan,
This article is nice. The query which I have you might find it off topic but is related to the permission in Hybrid Environment.
If I have users A,C,D in exchange Online . There is a shared Mailbox B in our on-premises.
Now, User A want to give “Publishing Editor” permission(Calendar permission) to user C on mailbox B. Is it possible in Hybrid Environment. Is it supported by Microsoft Environment ?
Did you tested the same in your environment. If you can share you reply on this , It would be much appreciated?
We have forest A (domain: Lab A.com) and forest B (Domain: LabB.com), forest A has a trust relationship with forest B. Forest A users are currently using an Instance of Exchange 2013.
Users in the newly created Forest B (LabB.com) are currently access existing mail services via the trust relationship.
Now, we are considering the implementation of Azure (ADFS & AAD) & office365, with the identity of User@LabB.com, with the possibility of single signon.
Considering that users in Forest B (LabB.com) are still using their mail resources via a trust relationship with LabB.com as a secondary smtp address, what issues can you see arising with the Azure & office365 implementation.
Its interesting that you say MS do not support the SendAs permission workaround as at one of their own Ignite conferences, they suggest this as a workaround. They also do say that they are going to work on this for future. Not sure when this is likely to be but I expect that if this workaround is used then it will be important to ensure the on-premise environment is kept up to date to ensure if sync does happen no previously applied permissions are lost
Nathan, Thank you very much for this nice article!
I have found the solution (at least a workaround) that I was experienced with the *%^”!* “Send As” permission applied to On-Prem shared mailboxes once the user mailbox is migrated to O365. It worked perfectly.
Do you know if this AD atrribute replication is in the roadmap of the O365 guys?
Thanks again!
Thanks – for the article! Something interesting we’ve noticed in hybrid – user mailboxes are cloud, shared on premise. We are also moving our on prem from 2010 to 2016. In 2010 EMC, we can pick cloud mailboxes for forwarding through the picker. If I go out to 2016 EAC, the same operation can’t be completed (doesn’t see the cloud mailboxes). However, the underlying powershell cmdlets will work on 2016…normal?
I’m not completely sure I understand the question, but in general you HAVE to manage Exchange objects with the correct version of Exchange. If the object you are managing is a 2010 mailbox, you have to manage it with Exchange 2010 tools. If you try to manage a 2016 mailbox with 2010 tools, bad things happen.
PowerShell tends to be more forgiving than the GUI, but the same rule applies.
Sorry for being confusing. If the on premise mailbox is homed on a 2010 server, and I use 2010 tools (EMC), I can set forwarding to a Cloud mailbox. If I move that same on premise mailbox to a 2016 server, the picker in the 2016 EAC doesn’t seem to see the same cloud based mailboxes to select from for forwarding.
Thanks for the article. Need your help on this.
I get the same error while running the command.
Set-ADUser -Identity migrated@cloud.com -Add @{msExchDelegateListLink/BL=onpremise@cloud.com}, however getting an Error :
Missing ‘=’ operator key in hash interval.
The hash interval is incomplete.
I don’t immediately see an issue with your command. I would suspect you have a copy/paste problem.
Try pasting the command into notepad, then into PowerShell.
Attribute should be msExchDelegateListlink and not msExchDelegateListLink/BL I think.
I have same error as Tony Murray
This didnt work forme for some reason
Add-MailboxPermission -Identity sales@mcsmlab.com -User nathan@mcsmlab.com -AccessRights SendAs
Another approach is for adding permission wich worked for me is the following:
Get-mailbox “Sales_ii” | Add-ADPermission -User “JaneM” -ExtendedRights “Send As”
You are right, on-premises you can’t set Send-As permissions with the Add-MailboxPermission cmdlet.
Add-ADPermission -Identity “Mailbox” -User GrantedUser -AccessRights ExtendedRight -ExtendedRights “Send As”
I also had issues with msExchDelegateListLink/BL (Exchange 2013 CU20 Schema). I had the best results using msExchDelegateListLink with the Username in Distinguished Name format, for example @{msExchDelegateListLink=’CN=Jess Henry,OU=Group,OU=Users,OU=Group,DC=jfrmilner,DC=local’}
As I’ll most likely need this again I’ve saved a full example to my github
https://github.com/jfrmilner/PowerShell-Office365/blob/master/Scripts/Migration-HybridAutoMappingMailboxPems.ps1 (hope it helps someone)
This one worked for me
Set-ADUser -Identity sales -Add @{msExchDelegateListLink=”CN=nathan,OU=contoso,DC=@mcsmlab,DC=com”}
Very nicely explained. I had a similar encounter with one of our customers where almost half of the mailboxes had delegate permissions and the delegated user’s mailbox had permissions to other users and so on. It was very difficult for us to migrate all these mailboxes and we did not want any service interruptions.