Nothing but excellent news in the hybrid Exchange realm these days! Microsoft recently updated the support statement for cross-premises permissions in a hybrid deployment. As of now, Full Access delegate permissions are supported cross-premises. I know many customers will be delighted to hear this as this has been a big ask for quite some time now.
It’s important to understand that the support only applies to Full Access permissions, as stated here. Other permissions like Send-As, Receive-As or Send-on-Behalf are still not supported. Note that Microsoft is in the process of updating its documentation; you should see a more consistent message across TechNet over the next few days!
Although full access permissions have been reported to work intermittently, no cross-premises permissions were supported previously. As such, you could not rely on them working either. From what I understand, the plumbing was already in place for a while but the intermittent results were partially due to the Outlook client not honoring them quite as one would expect. Provided you have the November 2015 update to Outlook 2013, you should no longer run into any problems.
As you move mailboxes to Office 365, permissions are migrated along. If you already had permissions assigned before the move, there is nothing you need to do. Although the permissions were also migrated previously, you had to move connected mailboxes at the same time so they would be hosted in the same organization in order for them to work. Not too long ago, I was talking to a customer who started out with a handful of mailboxes to move to Office 365 but ended up with a huge migration batch because of the interweaved permissions… As of now, this is no longer needed, making planning for migration batches a lot easier!
You should now also be able to add the Full Access permissions after mailboxes have been moved. This means you can give an on-premises mailbox access to a mailbox in Office 365 and the other way around without having to set the permissions prior to moving the target mailbox to Office 365.
In order to explain things more clearly, I have put together a Q&A. I hope this helps!
Until later,
Michael
What cross-premises permissions are supported in a hybrid deployment today?
Full Access only. Other delegate permissions like Send-As, Receive-As or Send-on-Behalf are not. There are no changes to cross-premises calendar delegation either. That continues to work the same way it did before.
Will the permissions work both ways?
Yes. On-premises mailboxes can access Office 365 mailboxes and vice versa.
What do I need to do to make this work?
Nothing, really. Just make sure you are using an up-to-date Outlook client. For Outlook 2013, this means you need at least the November 2015 Cumulative Updates. Needless to say, the more up-to-date you are, the better!
In order to add permissions for a recipient in the other organization, you can either use PowerShell or the Exchange Admin Center. Unlike the EAC in Office 365, you cannot use the on-premises EAC to grant an Office 365 mailbox access to an on-premises mailbox. For that you must revert to using PowerShell.
How do I add permissions to an Office 365 mailbox for an on-premises recipient?
Follow these steps to add Full Access permissions to an Office 365 mailbox for an on-premises recipient:
- Login to the EAC in Office 365 (Exchange Online)
- Navigate to recipients > mailboxes and then select properties of the mailbox you want to add Full Access permissions for.
- In the properties window, navigate to mailbox delegation
- Scroll down to you get to the Full Access From there, use the recipient picker (plus-sign) to add the on-premises mailbox you wish to grant permissions to:
- Click save.
How do I add permissions to an on-premises mailbox for an Office 365 recipient?
As mentioned earlier, you cannot use the EAC to add permissions for an Office 365 recipient. Instead, you must use the on-premises Exchange Management Shell. Don’t worry it’s quite simple!
| Add-MailboxPermission –Identity <On-Prem_mailbox_to_give_permissions_for> -User <O365_mailbox_to_give_permissions_to> -AccessRights FullAccess –AutoMapping $false |
For example:
| Add-MailboxPermission –Identity onpremmbx@domain.com –User clouduser@domain.com –AccessRights FullAccess –AutoMapping $false |
Unlike for permissions in the same environment, the AutoMapping feature is not supported. Hence why I specified the –AutoMapping $false parameter. I suspect the permissions to work without adding the parameter too!
What will my users see?
There is no difference in how Outlook displays an Office 365 mailbox over an on-premises mailbox you have access to. However, an on-premises user might get prompted for credentials when trying to access a mailbox in Office 365. This is because, in the back, the Outlook client must establish a connection with the Office 365 service first.
How that looks, depends on a number of things like the version of the Outlook client, whether you use Modern Authentication and whether or not they already have another Office 365 mailboxes in their Outlook profile.
Hi Michael
I’m and avid follower of your work and really want to pick your brain on a single point. I’m currently deploying dual hybrids for 2 London councils. In your TechEd 2014 session which I attended in Barcelona. Which in the recorded version at https://channel9.msdn.com/Events/TechEd/Europe/2014/OFC-B317 at 38.30 into the video you speak about AADSync being the glue between multi forest environments and when a user is on boarded AADSync will update attributes for both environments. Is this assuming GalSync is in place and there is a User in one forest and a contact in another? Therefore if we are matching in AADSync cross forest against the “mail” attribute and the User/Contact are “joined” in the metaverse. AADSync will update the targetaddress of the contact in ForestB to point to 365 if the corresponding user in ForestA is onboarded?
Many thanks, I know you are busy. Apologies if there is a better place to ask a question like this.
Hi Graham,
sorry for the belated reply; sometimes it’s easier to email/tweet me…
It is true that the attribute flow is the most important part of a multi-forest setup.
When doing such a deployment with AAD Sync, you have multiple options. Which ones to choose depend on your current setup.
You’ll notice that when adding multiple directories in AADC, you will have the option to choose how objects are matched and whether or not objects are represented more than once throughout the various forests.
In your case, I assume the latter would be true. What AADC then will do is join the objects together in the metaverse and export it to AAD. What it will not do, is modify the on-prem objects like e.g. changing the addresses on those objects. The modification of the targetAddress is something that happens as part of the onboarding process and is being taken care of by the MRS. As such, the mailbox is converted to a MEU and the targetAddress is updated. The latter is not one of the (hybrid) write-back attributes, hence why AADC doesn’t take care of it.
Hope this helps!
That’s great, thanks Michael. This is what I was expecting.
Always good to hear back from you and I will remember to use one of your preferred mediums to message you in future.
All the best
When an on-premise mailbox tries to access (Full access) a mailbox that is Office 365 and is prompted for credentials what credentials should be entered?
The user accessing the Office 365 mailbox should enter his “Office 365” credentials. If he does not have any, he won’t be able to access the mailbox in EXO. What those credentials look like will depend on how you have setup authentication (ADFS, SSO, PTA, PHS, ….)