Migrated permissions of migrated mailboxes in Exchange Hybrid based environment – Introduction | Part 3#5

The subject of the Exchange permission’s relationship between migrated mailboxes in the Exchange Hybrid environment could be quite confusing.
The term “Exchange permission’s relationship,” try to describe two (or more) mailboxes that have existing permission’s structure between them.
When we migrate these mailboxes from their “native environment” to the “other environment” the central question that we need to answer is – what will happen to the existing permissions?

Will this Exchange permission be migrated along with the mailbox to the other environment?
What happened in a scenario in which we “break” existing Exchange permission’s relationship by migrating only one partner to the other Exchange environment?

The current article we will review in high level the different type of “mailbox migration” scenario in the Exchange Hybrid environment.

The next article, is dedicated to the scenario in which we migrate mailboxes as a group from existing Exchange environment to the “other Exchange environment”

The article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5, is dedicated to the scenario in which we migrate mailboxes, but at this time, we break the existing Exchange permission’s relationship by migrating only part of the mailboxes to the “other environment.”

The special character of Exchange Hybrid environment and the subject of migrated mailboxes

The Exchange Hybrid is composed of the on-Premises environment (On-Premise Active Directory and Exchange on-Premises) and the “cloud” environment (Windows Azure Active Directory and Exchange Online).

One of the most prominent features of Exchange Hybrid is the “transparency” of the physical location of the Exchange mailboxes. The Exchange administrator can decide to keep existing mailbox on the Exchange on-Premises infrastructure or, migrates the mailbox to the “cloud” and vice versa.

The challenge that stands before us is that in reality, the infrastructure of “Exchange permissions” between two different Exchange environments is not so “transparent.”

To be able to simplify the subject of Exchange permissions, I use a term “Exchange permission’s relationship.”

The term – “Exchange permission’s relationship” is not a technical term. I use this term for describing Exchange mailbox that has an explicit permission on other Exchange mailboxes.

Given that two Exchange mailboxes have “permissions relationship” for example – mailbox A have a specific permission on mailbox B, the question is what will happen to these permissions in the following scenarios:

• Case 1 – a scenario in which we migrate mailbox B to the cloud and mailbox A “stay behind” on the Exchange on-Premises infrastructure.
• Case 2 – a scenario in which we migrate booth of the mailboxes (mailbox A + mailbox B) to the cloud.

In this scenario our questions are-

What will happen to the “Exchange permission’s relationship” that existed between the two mailboxes?

Will the “permissions relationship” will stay the same or the “permissions relationship” will be “disconnected”?

The two primary scenarios that relate to mailbox migration in Exchange Hybrid environment.

In the Exchange Hybrid environment, we can define two major “mailbox migration” scenarios, when relating to the subject of the “migrated Exchange permissions.”

Scenario 1 – migrate mailboxes that have “permissions relationship” as a group.

In this scenario, the Exchange on-Premises mailboxes that have the “permission relationship” between them, are migrated together to the cloud (Exchange Online).

For example:

• Mailbox A and mailbox B are hosted on Exchange on-Premises server.
• Mailbox A has a specific permission on mailbox B.
• Exchange administrator migrates booth of the mailboxes to the cloud.

Scenario 2 – migrate a specific mailbox that has “permissions relationship” with another mailbox.

In this scenario, only one mailbox is migrated to the cloud. For example, mailbox A that has permission on mailbox B stay at Exchange on-Premises, and mailbox B is migrated to the cloud.

For example:

• Mailbox A and mailbox B are hosted on Exchange on-Premises server.
• Mailbox A has a specific permission on mailbox B.
• Exchange administrator migrates mailbox B to the cloud, and mailbox A continue to be hosted by the Exchange on-Premise server.

When implementing this scenario in which we “break” existing Exchange permission’s relationship that exists between mailboxes, we are creating the scenario which describes as – “cross site permissions”.

In this case, the permission’s infrastructure is implemented between a mailbox that hosted on Exchange on-Premises server and other mailboxes that hosted in the cloud (Exchange Online).

The formal information about the Exchange permission that migrated to the cloud

To be able to get some answer regarding our questions about mailbox migration and the migrated permissions in Exchange Hybrid environment, let’s start with a quotation from Microsoft’s articles that relate to this subject:

Mailbox permissions migration On-premises mailbox permissions such as Send As, Receive As, and Full Access that are explicitly applied on the mailbox are migrating to Exchange Online.
Inherited (non-explicit) mailbox permissions and any permissions on non-mailbox objects—such as distribution lists or a mail-enabled user—are not migrated.
Therefore, you have to plan for configuring these permissions in Office 365 if applicable to your organization. For example, you can use the Add-RecipientPermission and Add-MailboxPermission Windows PowerShell cmdlets to set the permissions in Office 365.
Support for cross-premises mailbox permissions Exchange hybrid deployments supports 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 granted the Full Access permission to an Office 365 mailbox, and vice versa. For example, an Office 365 mailbox can be given the Full Access permission to an on-premises shared mailbox.

[Source of information – Exchange Server Hybrid Deployments]

On-premises mailbox permissions such as Send As, Receive As, and Full Access that are explicitly applied on the mailbox are migrated to Exchange Online if the tenant in Exchange Online has been fully synchronized using Dirsync or AAD Sync.
Inherited (non-explicit) mailbox permissions such as permissions applied to the mailbox database and any permissions on non-mailbox objects (such as distribution lists or a mail-enabled user) are not migrated. Therefore, you should recreate these permissions in Exchange Online using the Add-MailboxPermission or Add-RecipientPermission cmdlets.

[Source of information – Exchange Hybrid Deployment with Office 365 – Part I]

Scenario 1 – Migrating Exchange on-Premises mailboxes as a “group.”

Given the two (or more) Exchange on-Premises mailboxes have “permission relationships,” and the Exchange administrator migrates these mailboxes as a group (together), all the existing permissions migrate to the cloud, besides non-explicit (Inherited) permissions.

In the following table, we can see the summary of the Exchange permission that will migrated to the cloud.

In case that we migrate Exchange on-Premises mailboxes that had “permission relationships,” the following permissions should be migrated:

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

The following permissions\options will not be migrated:

• Non-Explicit (Inherited) permissions will not be migrated.
• In a scenario of Full Access permission, the Automap feature will not have migrated.

Notice that the article doesn’t relate to the subject of – Delegated permission and Folder permission (calendar sharing).
We will test this Exchange permissions in the following articles – Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5

Scenario 2 – Migrating a particular Exchange on-Premises mailboxes to the cloud

The information in the Microsoft article does not relate directly to this type of scenario, in which only part of the Exchange on-Premises mailboxes migrated to the cloud.

Generally speaking, the article doesn’t recommend implementing a migration process which will “break” existing Exchange permission’s relationship (the recommendation is to migrate mailboxes as a group).

The only “hint” that exists in the article, relates to the supported cross site permission –
the Full Access permission.

If we use “negation method,” the logical conclusion that in case that we “separate” to Exchange on-Premises mailboxes that had “permission relationships,” the only permissions that will do to function (that will be migrated) is the Full Access permission.

The article doesn’t relate to Send As permission and for this reason, we can assume that
the Send As permission will not continue to function.

In other words, in case the Exchange on-Premises recipient had Send As permission on the mailbox that was migrated to the cloud, the Send As permission are supposed to be removed because, in an Exchange Hybrid environment, the cross site permissions don’t support Send As permission.

In the following table, we can see the summary of the Exchange permission that will migrated to the cloud.

At the current time, we cannot know for certain if the Send As permission
or Send on Behalf permission will be removed.

In case that we migrate Exchange on-Premises mailboxes that had “permission relationships,” the following permissions should be migrated:

• Full Access permission

The following permissions\options will not be migrated:

• Send As permission.
• Send on behalf permission.
• Non-Explicit (Inherited) permissions will not be migrated.
• In a scenario of Full Access permission, the Automap feature will not have migrated.

Notice that the article doesn’t relate to the subject of – Delegated permission and Folder permission (calendar sharing).
We will test this Exchange permissions in the following article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5

Folder permission and calendar sharing

As mentioned, the Microsoft article doesn’t relate to the subject of Folder permission that is used in a scenario of calendar sharing, etc.

For example, what will happen in the following scenarios?:

Scenario 1 – migrate mailboxes that have “permissions relationship” as a group

In this scenario, the Exchange on-Premises mailboxes that have the “permission relationship” between them, migrated together to the cloud (Exchange Online).

For example:

• Recipient B shares his calendar with recipient A; booth of the recipients is hosted on Exchange on-Premise server.
• Exchange administrator migrates booth of the mailboxes to the cloud.

Q1: Does the Folder permission will be migrated to the cloud? In other words, does recipient A will still be able to access the calendar of recipient B?

A1: There is no formal reference to this type of permissions in the Microsoft articles. From the test that I have performed, the Folder permission will successfully be migrated to the cloud.
You can view the test result 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 – migrate a particular mailbox that has “permissions relationship” with another mailbox.

In this scenario, only one mailbox is migrated to the cloud. For example, mailbox A that has permission on mailbox B stay at Exchange on-Premises, and mailbox B is migrated to the cloud.

For example:

• Recipient B shares his calendar with recipient A; booth of the recipients is hosted on Exchange on-Premises server.
• Exchange administrator migrates mailbox B to the cloud, and mailbox A continues to be hosted by the Exchange on-Premise server.

Q2: Does the Folder permission will be migrated to the cloud? In other words, does recipient A will still be able to access the calendar of recipient B?

A1: There is no formal reference to this type of permissions in the Microsoft articles.

Technically, Folder permission should not be migrated to the cloud because the Exchange Hybrid cross site permissions are not supposed to support Folder permission.

From the test that I have performed, the Folder permission will successfully be migrated to the cloud.
You can view the test result in the article – Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5

The term Explicit vs. Non-Explicit (Inherited) permissions

The Microsoft article says that-

Inherited (non-explicit) mailbox permissions and any permissions on non-mailbox objects—such as distribution lists or a mail-enabled user—are not migrated.

Q1: What is the meaning of “non-explicit permission” (Inherited) mailbox permissions?

A1: To understand better the term “non-explicit (Inherited) permissions, let’s begin with the definition of “explicit permission.”

Explicit permission

The term “explicit permission,” define a scenario in which we assign Exchange permission to a particular “recipient object” on another “recipient object.”

For example – we assign Alice the Full Access permission on Bob’s mailbox.

Non-explicit permission

The term – “non-explicit permission” (Inherited) in an Exchange environment, describe a method, in which we assign the permission in a “non-directed way.”
In this case, we have more than two “elements” that are involved.

For example, we assign Exchange permission to element A on Element B, but element A is a “container object” such as a group that contains other elements such as an element C.

For example-

• We assign a security group named Helpdesk, the Full Access permission on Bob’s mailbox.
• Alice is a member of this Helpdesk security group.

Because Alice is a member of the security group, and because the security group has
the Full Access permission on Bob’s mailbox, the outcome is that Alice
has Full Access permission on Bob’s mailbox.

In this case, we can say that Alice Inherited her permissions from the security group.
Another way to say the same thing is that Alice has non-explicit permissions on Bob’s mailbox.

Option 2 – Assign permission to a recipient on Exchange database.

An additional type of “non-explicit permission” (Inherited) in an Exchange environment, can be realized in case that we assign Exchange permissions to a particular recipient on an Exchange server database that host Exchange recipient mailboxes.

For example, a scenario in which we assign the Full Access permission to a user named Alice and Exchange on-Premises database.

The particular Exchange on-Premises database hosts the mailboxes of the following recipients: Bob, Robert, and Emma.

The outcome is that Alice will have Full Access permission on Bob, Robert and Emma’s mailboxes.

In other words, Alice doesn’t have an explicit permission for each of the mailboxes, but instead, have permissions on the database that hosts these mailboxes.

In case that we add additional mailboxes to the Exchange database, Alice will automatically
have Full Access permission on the “new mailboxes.”

Bottom line

In the Exchange Hybrid environment, in case that we have a scenario in which we assign “non-explicit permission” (Inherited) on a specific mailbox, and we migrate this mailbox to the cloud; the permissions are not supposed to be migrated along with the mailbox.

Lateר, we will demonstrate such a scenario in the article – Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5 ,and see that the result is a little but different from the “formal expected result”

The next article in the current article series

Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5