Skip to content

Cross site permission and migrated permissions in Exchange Hybrid based environment | Part 1#5

The current article series dedicated to the subject of – the available Exchange permissions in Exchange Hybrid environment. The term “Exchange permissions” is realized in two major scenarios:

  • Scenario 1 – Cross site permissions
    • The term “cross site permissions”, define the available Exchange permissions, that we can assign to Exchange on-Premises mailbox on a cloud mailbox and vice versa.
  • Scenario 2 – Migrated “Exchange permissions”
    • The other scenario in which we relate to “Exchange permissions” in Exchange Hybrid environment is the Exchange permissions that will migrate along with the mailbox in case that we migrate Exchange on-Premises mailbox to the cloud and vice versa.

The information published by Microsoft about Cross site permission and migrated permissions in Exchange Hybrid based environment

The information published on the subject of Exchange permissions by Microsoft is quite minimal. Although the information relates to specific Exchange permissions that are available in each of the scenarios above, there is a lot of “missing parts”.
The meaning is that the published infrastructure doesn’t relate to all of the Exchange permissions matrices and also, the information doesn’t relate to all of the common scenarios.

To make the issue more complicated, in reality, there is variance between what is “declared” in the formal article vs. what is happening in fact.

In my opinion, the variance from the formally published information is caused by the Inability to catch up with the rapid pace of changes made in the Office 365 dynamic environment.

My purpose in the current article series is, to remove as much as possible the ambiguity around the subject of Exchange permissions in Exchange Hybrid environment.

What is so special in the Exchange Hybrid based environment?

In Office 365, the Exchange Hybrid infrastructure combines the Exchange on-Premise environment and the Office 365 environment into a single logical entity.

If we want to be more technical, Exchange Hybrid environment combines the on-Premises environment that includes – On-Premise Active Directory and Exchange on-Premises organization with the Office 365 environment, that include Windows Azure Active Directory and Exchange Online.

The striking feature of the Exchange Hybrid environment is, the “resource sharing” between the two distinct Exchange forests that includes almost all the Exchange different services.

For example, Exchange Hybrid environment includes a shared GAL (Global Address List), shared domain namespace; sharing of different Exchange web-based services such as – Out Of Office, Free\Busy time (availability services), mail tips and much more.

In Exchange Hybrid environment, the Exchange mailboxes are scattered between the Exchange on-Premises infrastructure and the cloud infrastructure (Exchange Online).

In Exchange Hybrid environment mailboxes are scattered between on-Premises and the cloud

Exchange recipient doesn’t know if his mailbox is located at the Exchange on-Premises infrastructure or, at the Exchange Online infrastructure.

Exchange on-Premises mailbox and Exchange Online mailbox – permission relationship

The only exception to this “harmony” is – the subject of Exchange permission between the two different Exchange forests.

Vs. subject, such as mail flow and Exchange web services that operate in a transparent manner in the two distinct environments (Exchange on-Premises vs. Office 365 environments), the subject of – “cross site permissions” in the Exchange Hybrid environment, is a little more complicated.

The important thing that we should be aware is that in the current time, some of the “Exchange permissions” will not work between the two different Exchange forests, and some Exchange permission will work.

What is the meaning of the term “cross site permission” in Exchange based environment?

The term “cross site permission,” was created for describing the Exchange permission module that exists between two distinct Exchange organizations.

The term relates to a scenario in which two distinct Exchange organizations (Exchange forests) need to share resources.

For example, a scenario in which recipient from Exchange organization A, can have a specific Exchange permission such as Full Access, on the mailbox of a recipient from Exchange forest B, and vice versa.

The meaning of the term - cross site permission in Exchange base environment -01

The term “cross site permission” is a little confusing because two reasons:

1. The use of the term “site”

Because we use the word “site,” it looks like we talk about one Exchange organization with multiple sites and the permissions that can be implemented between Exchange recipients from different sites.

In Exchange based environment, the term – “cross site permission” – describe an infrastructure that includes two different Active Directory forest, and not one Exchange a single forest with multiple sites.

The term “cross site permission” describes the possible permissions that can be used between the recipients who hosted on the two separated environments.

2. The term “permission.”

The term “permission” is vague and doesn’t explain what type of permissions can be implemented between two different Exchange organizations.

The main purpose of the current article series is – to explore the available Exchange permissions that we can use in the Exchange on-Premises environment and the cloud environment.

The two main scenarios in which Exchange permissions in Exchange Hybrid environment are realized.

As mentioned, in Exchange Hybrid environment the term Exchange permissions relate to two main scenarios

  • Scenario A – Cross site permissions
  • Scenario B – Migrated “Exchange permissions”
The two main scenarios in which Exchange permissions in Exchange Hybrid environment are realized.-02

Scenario A – Cross site permissions

A scenario in which Exchange on-Premises recipient need to have Exchange permissions on a cloud mailbox and vice versa.

For example, a scenario which has the following characters:

  • Alice’s mailbox is hosted on Exchange on-Premises.
  • Bob’s mailbox is hosted in the cloud (Exchange Online).
  • Alice needs to have a specific permission on Bob’s mailbox.

In this scenario our question is

Q1: Can we assign any Exchange permissions to Exchange on-Premises recipient on a cloud mailbox and vice versa?

Q2: In case that there is a limitation for the Exchange permissions that we can use in a cross site permissions scenario, what are the optional Exchange permissions that we can assign to Exchange on-Premises recipient on a cloud mailbox and vice versa?

Exchange on-Premises recipient needs to have Exchange permissions on a cloud mailbox -01

Scenario B – Migrated “Exchange permissions”

In this time, we are relating to the available Exchange permissions that we can use, in case that we are migrating Exchange on-Premises mailboxes to the cloud and vice versa.

This “mailbox migration scenario” in Exchange Hybrid environment, is a little bit more complicated because there is two type of posable “mailbox migrations” scenarios.

B.1 – Exchange on-Premises mailboxes that migrated “together” to the cloud.

A scenario in which we are migrating Exchange on-Premises mailboxes to the cloud.

The specific characters of this scenario are that the Exchange on-Premises mailboxes have an existing permissions relationship, and we are migrating this mailbox together as a group to the cloud.

For example, a scenario which has the following characters:

  • Bob’s mailbox and Alice mailbox are Exchange on-Premises mailboxes.
  • Alice has permission to Bob’s mailbox.
  • Bob’s mailbox and Alice mailbox, was migrated to the cloud (Exchange Online).

In this scenario, our questions are:

Q1: In case that we migrate a “group” of Exchange on-Premises mailboxes to the cloud, that had “Exchange permissions relationship”, does all of the existing permissions are “copied” to the cloud along with the mailbox data?

Q2: In case that only some of the Exchange permissions are “copied” to the cloud along with the mailbox data, what are this Exchange permissions?

Migrating Exchange on-Premises mailboxes to the cloud as a Group -02

B.2 – Exchange on-Premises mailboxes that migrated “separately” to the cloud.

A scenario in which we are migrating Exchange on-Premises mailboxes to the cloud.

The specific characters of this scenario are, that the Exchange on-Premises mailboxes have an existing permissions relationship but, the mailbox migration process is “breaking” this relationship because we are migrating only a specific “partner” to the cloud.

For example, a scenario which has the following characters:

  • Bob’s mailbox and Alice mailbox are Exchange on-Premises mailboxes.
  • Alice has permission to Bob’s mailbox.
  • Only Bob’s mailbox was migrated to the cloud (Exchange Online).

In this scenario, our questions are:

Q1: In case that we “break “the existing relationship by migrating only specific Exchange on-Premises mailbox to the cloud, does all of the existing permissions are “copied” to the cloud along with the mailbox data?

In other words, will the permissions that the Exchange on-Premises recipient had will continue to function on the cloud mailbox?

Q2: In case that only some of the Exchange permissions are “copied” to the cloud along with the mailbox data, what are this Exchange permissions?

The separation scenario – the partner mailbox was migrated to the cloud -03

The difference between the cross site permissions scenario and a mailbox migration scenario that break existing permissions relationships.

Q1: What is the main difference between scenario A and scenario B.2?

A1: Theoretically, the outcome of the two scenarios should have been identical from the perspective of the available Exchange permissions.

When we “break” existing permissions relationship by migrating an Exchange on-Premises mailbox to the cloud, the new setup is identical to a “standard cross site permissions” scenario.

In other words, theoretically, the available Exchange permissions that we can assign to Exchange on-Premises mailbox on a cloud mailbox should be affected by the fact that the Exchange on-Premises mailbox had a previous permissions relationship with the mailbox that was migrated to the cloud.

The reality is different because, the cross site permissions that we can use between two mailboxes (Exchange on-Premises mailbox and cloud mailbox) that didn’t have a previous permissions relationship is different from the cross site permissions that are available for use in case that the two mailboxes had a previous history of Exchange permissions and at a later stage, one of the “partner” was migrated to the cloud.

For example, the permissions that described as calendar sharing (Folder permission) behave differently in each of the different scenarios.

In case that we relate to scenario A when Exchange Online recipient tries to share his calendar with Exchange on-Premises recipient, the sharing will fail!

In other words, the “cross site permissions” doesn’t include calendar sharing. (we will review this scenario in the article – Testing cross site permissions in Exchange Hybrid based environment| Part 2#5 )

In case that Exchange on-Premises recipient (recipient B) share his calendar with other Exchange on-Premises recipient (recipient A) and we migrate recipient B mailbox to the cloud, recipient A will keep the “calendar sharing permissions”.
In other words, the “cross site permissions” include calendar sharing. (we will review this scenario in the article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5 )

I know that at the current time, it sounds a little vague. Be patient, in the next articles, we will provide more meaningful examples.

The term “Exchange permission”

Q1: When we mention the term “Exchange permissions,” what are these “Exchange permissions”?

A1: This is a good question because, there is a lot of confusion regarding this term, and many miss concepts.

Generally speaking, when using the term – “Exchange permissions,” we relate to two major types of permissions: Mailbox permissions and Folder permission.

A. Mailbox permission

The term “Mailbox permission” includes three sets of permissions:

Exchange permissions classification – The Major permissions groups

1. Full access mailbox permission
An Exchange permission, that enables recipient A to get “Full Access” to the mailbox of a recipient B. The Full Access permission as the name implies, relate to all the folders included in the recipient mailbox such as – inbox folder, calendar, people, notes and so on.

2. Send As permission

An Exchange permission, that enables recipient A to send E-mail using the identity of a recipient B. In case that recipient A uses this option, and send E-mail using the identity of recipient B, the destination recipient, such as recipient C, “see” that the E-mail sent by recipient B, and recipient C doesn’t aware of the fact that the E-mail was actually sent by a recipient A.

3. Send on behalf permission

An Exchange permission similar to the Send As permission. The major difference is that when we use the Send on behalf permission; the destination recipient will see that the E-mail was sent from recipient A on behalf of a recipient B.

Note: From now on, we will not relate to Send As permission and Send on behalf permission Individually because the logic the relate to this permission to the Exchange Hybrid environment is identical.

B. Folder permission

The term “Folder permission” as the name implies, define an Exchange permission that is assigned to a specific folder. The most common use of Folder permission is realized when
using calendar sharing or, contact sharing.

I would like to emphasize a couple of points, regarding that subject of cross site permissions in Exchange Hybrid, and Folder permission:

1. The information that is published in the formal Microsoft articles doesn’t include a specific reference to the subject of Exchange Folder permission.

2. Exchange Hybrid cross site permission doesn’t support calendar sharing

At the current time, there is no option to assign Folder permission to Exchange on-Premises mailbox on a “cloud mailbox” (Exchange Online) and vice versa.

For example, in case the recipient A mailbox is hosted on Exchange on-Premises, and recipient B mailbox is a “cloud mailbox,” recipient B cannot share his calendar with recipient A.

3. The exception for Folder permission and cross site permissions

There is a non-documented exception to this rule. From my experiences, in the particular scenario in which two mailboxes hosted on Exchange on-Premises, and recipient B shares his calendar with recipient A, if the mailbox of recipient B is migrated to the cloud, recipient A can continue to access the calendar of recipient B, despite the formal declaration that calendar sharing is not supported in Exchange Hybrid environment.

Exchange permissions classification -Additional type of permissions

C. Free\Busy permission (availability service).

The “other” type of Exchange permission that I would like to discuss is, the Free\Busy permission, or if we want to use the more formal term – Availability service

The reason that I mention this permission is, because usually, there is a confusion between the Free\Busy permission and calendar sharing (Folder permission).

Many times, when we mention the term – “calendar sharing,” there is no clear distinction between these two different types of Exchange permissions.

Calendar sharing permissions versus ?Free Busy calendar permissions

The purpose of Free\Busy permission is to enable the Exchange recipient to view the availability of another exchange recipient when he invites them to a meeting by using the mailbox calendar.

The Free\Busy permissions describe a set of permissions, which enables the Exchange recipient to “reveal” different level of information about his “availability status”.

The default Free\Busy permission enables recipient B to see if recipient A is “free” or, have a meeting in the particular time.

In case that recipient A is not free (have a particular meeting at the same time) recipient B cannot see the subject or the content of recipient A meeting.

It is important to emphasize that Free\Busy permissions are notFolder permission” or calendar sharing permission.

Calendar sharing describes a different set of permissions, in which recipient A enable to recipient B to manage his calendar (edit existing items, create a new meeting item and so on).

In the Exchange Hybrid environment, the Free\Busy permission is configured automatically between Exchange on-Premises infrastructure and Exchange Online infrastructure.

Exchange Hybrid environment and Availability services -Free - Busy time

D. Delegate permission

An addition type of Exchange permissions that I would like to mention is the “Delegate permission.”
Most of the time, the “Delegate permission” is implemented by the Exchange recipient who wants to provide “Delegate permission” to another recipient, by using the Outlook mail client interface.

The term – “Delegate permission,” is a friendly term that describes a complicated set of permissions, that include a combination of Send on behalf permission, Folder permission and other permissions that enable the destination recipient (the delegate) to get the meeting requests that are sent to the “original recipient” which delegate him.

Exchange permissions ?- Delegation – A combination of permissions

Exchange permission infrastructure in Exchange Hybrid environment

In the current section, I would like to review the “formal information” that is published in the Microsoft articles, regarding the subject of cross site permissions, and regarding the migrated permissions in the Exchange Hybrid environment.

It’s important to me to Emphasize two subjects:

1. The scope of information and the level of details

Although the articles provide us a lot of information about the subject of Exchange permissions in Exchange Hybrid environment, there is still “missing parts”. The articles, don’t relate to all the available Exchange permissions, and the articles don’t include a detailed description regarding the scenario of – mailbox migration in which we separate between Exchange on-Premises mailbox and cloud mailbox.

2. The difference between the reality and the information which appears in the article

Regarding the scenario of Exchange permissions and mailbox migration in Exchange Hybrid environment, there is a difference between the actual results (the actual Exchange permissions that migrated) vs. the information that appear in the articles.

The good news is that in reality, there are Exchange permissions that are successfully migrated Although the information in the articles doesn’t say that this permission will be migrated.

In article – Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5 , and article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5 , we will test the permissions that are migrated to the cloud in a scenario of mailbox migration.

To be able to make the information clearer, let’s organize the information using the three primary scenarios that relate to permissions in Exchange Hybrid environment.

The Fog that surrounding the subject of cross site permissions in Exchange Hybrid environment

Scenario 1 – Cross site permissions

The permissions that can assigned to Exchange on-Premises mailbox on a “cloud mailbox” and vice versa.

The information that appears in the articles
?
We can assign Full Access permission to Exchange on-Premises mailbox on cloud mailbox and vice versa.

We cannot assign Send As permission and Send on behalf permission to Exchange on-Premises mailbox on cloud mailbox and vice versa.

The information that doesn’t appear in the articles

1. Folder permissions

The information in the articles doesn’t relate to the subject of Folder permission such as calendar sharing.

We will test the option of – Cross site Permissions and Folder permission in Exchange Hybrid environment, in the following articles – Testing cross site permissions in Exchange Hybrid based environment| Part 2#5

2. Delegated permissions

There is no formal information about the subject of Delegation permission.

To logical conclusion is that Delegation permission is not supported because these permissions combine two different Exchange permissions, that are not supported as cross site permissions –
the Folder permission (calendar sharing) and the Send on behalf permission.

We will test the option of – Cross site Permissions and Delegate permission in Exchange Hybrid environment, in the following articles – Testing cross site permissions in Exchange Hybrid based environment| Part 2#5

01-The permissions that can be assigned to Exchange on-Premises mailbox on a “cloud mailbox” and vice versa

Scenario 2.1 – Mailbox migration | Migrating mailboxes as a group

The information that appears in the articles

In a scenario in which mailbox A have permission on mailbox B, and the booth of the mailboxes migrated to the cloud (Exchange Online), the information in the articles state that the following type of permissions will be migrated:

  • Full Access permission
  • Send As permission
  • Send on behalf permission

The exception to this rule is a scenario in which the permissions that were assigned to mailbox A, considers as Inherited (non-explicit) mailbox permissions.

An additional information in the article relates to the subject of Full Access permission and the feature of Automap.

In case that mailbox A have Full Access permission on mailbox B and we migrate this mailbox “together” to the cloud, mailbox A will still have the Full Access permission on mailbox B but the Automap option will not “activated”. In other words, mailbox B will not appear automatically in the mail profile of recipient A. recipient A will need to manually add mailbox B to his Outlook mail profile.

The information that doesn’t appear in the articles

1. Folder permissions

The information in the articles doesn’t relate to the subject of Folder permission.
We will test this scenario in the article – Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5

2. Delegated permissions

There is no formal information about the subject of Delegation permission.

We will test this scenario in the article – Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5

Scenario 2.1 – Mailbox migration Migrating mailboxes as a group -02

Scenario 2.2 – Mailbox migration | Migrating mailboxes separately

The information that appears in the articles

The characters of this scenario are that in this case we “break” an existing permissions relationship between two Exchange on-Premises mailboxes by migrating only “one partner” to the cloud while the other partner (the recipient that had permissions on the migrated mailbox) stays at the Exchange on-Premises server.

The articles don’t relate directly to this type of scenario and instead include a general recommendation to migrate Exchange on-Premises mailbox as a group and not to “separate” mailboxes that have an existing Exchange permissions relationship.

The logical conclusion is that in such scenario, the only permission that will be migrated to the cloud is – the Full Access permission.

Theoretically, the Send As permission and the Send on behalf permission will not be migrated to the cloud together with the mailbox.

Later in the article – xxx, we will see that in my tests, the permissions that were not supposed to be migrated (Send As permission and the Send on behalf permission) are successfully migrated, and the Exchange on-Premises recipient can still have these permissions on the recipient whom his mailbox was migrated to the cloud.

The information that doesn’t appear in the articles

1. Folder permissions

The information in the articles doesn’t relate to the subject of Folder permission.
We will test this scenario in the article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5

2. Delegated permissions

There is no formal information about the subject of Delegation permission.

We will test this scenario in the article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5

Scenario 2.2 – Mailbox migration - Migrating mailboxes separately -03

The subject of Full access mailbox permission and AutoMapping

The quotes from the Microsoft articles regarding the permissions in Exchange Hybrid environment says that AutoMap option is not supported in Exchange Hybrid environment.

In the next section, I would like to briefly discuss this subject

Addition issue, then we will need to know is, the subject the relate to the Exchange feature named – AutoMapping.

The term “AutoMapping” in an Exchange environment, describe the automatic addition of the mailbox to Outlook mail profile, in a scenario in which recipient has Full access permission on other recipient mailboxes.

For example, in case that we assign Alice Full access permission to Bob’s mailbox when Alice opens her Outlook mail client, Bob’s mailbox will appear automatically as an additional mailbox.

In other words, Alice doesn’t need to manually add Bob Mailbox to her Outlook mail profile.

As mentioned, cross site permission in the Exchange Hybrid environment includes Full access permission, but the option of AutoMapping is not supported.

For example,

  • Alice’s mailbox is hosted on Exchange on-Premise server.
  • Bob’s mailbox is hosted on the Exchange Online server.
  • Alice is the assistant of Bob.
  • Alice needs to have Full Access permission to Bob’s mailbox.

Given that the Exchange on-Premises administrators assign the Full Access permission to Alice (that is hosted at Exchange on-Premises), to be able to view Bob’s mailbox, Alice will need to configure her Outlook mail profile manually, and add Bob’s mailbox to her profile.

Exchange Hybrid -cross site permission- Full Access permissions – additional thing to consider -01

The information variance between the Microsoft article and the actual results

In the next articles in the current article series, we will test each of the different scenarios that were described such as cross site permissions and mailbox migration and the interesting thing is that we will be able to see that some of our test results are different from the information that appears in the Microsoft articles.

The possible answers that can explain this variance could be:

1. Different Exchange on-Premises server vs. and different Outlook mail client

Each of the Different Exchange on-Premises server version such as Exchange 2010, Exchange 2013 and Exchange 2016 include a different architecture and support in features that previous Exchange server didn’t include.

The same logic can be applied to the different Outlook mail client that we use. It’s reasonable to assume that Outlook 2016 will support new and improve authentication mechanism and communication protocols vs. Outlook 2010 version.

2. The dynamic nature of Office 365 environment

Theoretically, the Microsoft articles should include the most updated information regarding each of the Office 365 product and about each character and features. The reality is a little bit more complicated because the dynamic nature of Office 365 environment. the amount of updates, new technologies, and new features is enormous.

It looks to me that it is not possible to keep up, and updated the articles Respectively about each of this changes.

The next article in the current article series

Testing cross site permissions in Exchange Hybrid based environment| Part 2#5

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has One Comment

  1. We’ve been able to successfully get Send As to function cross site (very consistently and for many mailboxes) when the mailbox they need to Send As is on premises and the user attempting to Send As is in Office 365. Connect via Azure AD shell and run “add-recipientpermission $Mailbox -AccessRights SendAs -Trustee $UID”. If someone knows a workaround for the other direction that would be great!

Leave a Reply

Your email address will not be published. Required fields are marked *