The Confusing Case of Cross-Forest Delegation
If you've even participated in an Exchange Online migration at almost any level, it's likely you've run into the issue of cross-forest delegation. You know that Exchange allows you to delegate rights from one mailbox to another, allowing users to access other mailboxes. When you do an Exchange hybrid migration, there are some special considerations you have to take to keep these delegated rights working. Depending on who you ask, you'll get all kinds of different answers about what works when. In this blog post I will explain the confusing case of cross-forest delegation, and what you can expect to work or not work.
There is no cross-forest delegation
Much of the success of Office 365 is built on the Exchange hybrid migration. Since the initial release of Office 365 it has been possible to connect your on-premises Exchange organization to Exchange Online and have the two organization work almost like a single Exchange deployment. In the early days getting hybrid to work was a long and complicated process, but it was possible. The introduction of the hybrid configuration wizard has made the process of configuring hybrid Exchange much better.
One of the major features that has consistently been missing from Exchange hybrid deployments is cross-forest delegation. The support statement from Microsoft since the beginning of time has been "cross-forest delegation does not work". You can preserve existing delegated rights if all mailboxes in the delegation relationship are migrated in the same migration batch.
Except that is not true
As it turns out, cross-forest delegation does work. In fact, it has at least sort of worked for quite a while.
First we have Free/Busy federation. Free/Busy federation is the ability to see another user’s availability from their calendar. While this is not the same thing as delegation, most users think of it as a form of delegation. When one person wants to see another person’s calendar, they don’t really care if they are seeing that calendar via Free/Busy federation or delegation of the calendar folder.
In addition to the Free/Busy confusion, we can add the fact that cross-forest delegation does actually work sometimes. User1 can have existing delegated rights to User2’s mailbox and actually sometimes have those permissions work after User2’s mailbox is migrated to Exchange Online with User1 remaining on-premises. Sometimes is of course the important word in that last sentence. I don’t think anyone really knows why or when those delegated permissions are preserved after a mailbox migration.
But now, some cross-forest delegation is supported
As Office 365 is an ever evolving service, Microsoft has recently updated this TechNet article to reflect that cross-forest delegation can work in limited circumstances.
Delegated mailbox permissions Exchange hybrid deployments support the use of the Full Access mailbox permission between mailboxes located in an on-premises Exchange organization and mailboxes located in Office 365. 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.
…but wait, there’s more
The astute among my readers will have already clicked that link, and read the quoted section themselves. They may have even read a paragraph a little down that page that says exactly the opposite thing.
Cross-premises permissions We don't support cross-premises permission scenarios. Permissions are only migrated and functional when implementing an Exchange hybrid deployment if there are corresponding directory objects in Office 365. Additionally, all objects with special permissions such as Send As, Receive As and Full Access must be migrated at the same time. This also means that to migrate these permissions, you must make sure directory synchronization has completed before you start moving mailboxes. For more information, see Permissions in Exchange hybrid deployments.
I’m not pointing this out to say that Microsoft is dumb or evil. We all know that documenting software is hard, and documenting software that changes as fast as Office 365 does is almost impossible. I’ve made Microsoft aware of this conflict, and they’ll likely have it fixed before you read this blog post.
I’m pointing this out to illustrate the larger point that TechNet is not the all-knowing repository of everything that it used to be. With the pace of change in Office 365, TechNet will end up being self-contradictory or even flat out wrong fairly often.
I wish there was an easy answer for how to get the most up to date and accurate information about how Office 365 works, but there isn’t. The only option I know of is to do what I do, spend a bunch of time researching stuff and the apologize when you’re wrong.
Hopefully blog posts like this will help keep you current. Check back soon, and we’ll surely have more knowledge-y goodness for you.