Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5  5/5 (2) 10 min read

In the current article, we will review the mail migration scenario in which we “break” existing Exchange permission’s relationship. I use the term “break” because, in this scenario, we are migrating only one partner from the existing “couple” to the cloud.

When we migrate Exchange on-Premises mailboxes in the cloud not as a “group” we are creating a “cross site permissions” scenario in which the object from Exchange on-Premises environment needs to have permissions on “cloud mailboxes” and vice versa.

Generally speaking, this scenario is not recommended by Microsoft.
The thing is that, in reality, this type of scenario is implemented because many reasons such as specific limitations or, a lack of knowledge about the preferred scenario (migrating Exchange on-Premises mailboxes as a group).

For this reason, it’s important that we will know what are the Disadvantages of the mail migration method, meaning – what are the mailbox migration that will not be migrated to the cloud when we “break” existing Exchange permission’s relationship that exists between Exchange on-Premises mailboxes.

The formal Microsoft information about such type of scenario.

The interesting thing that in the current time, there is no precise information published by Microsoft about such type of scenario.

The only option that we have is to try to draw conclusions from the existing information about the projected results.

The general idea is that in case that the Exchange on-Premises mailboxes have a “permissions relationship”, the recommendation is to migrate this mailbox together as a group, and avoid from “breaking” the permission’s relationship. In this case, some of the permissions will not be migrated.

For example, the article says that in an Exchange Hybrid environment only Full Access permission can be assigned to Exchange on-Premises mailbox in cloud mailbox and other permissions such as Send As permission are not supported.

The conclusion is that if we implemented mailbox migration scenario that “break” the permission’s relationship between two Exchange on-Premises mailboxes that have Send As permission, these permissions will not function anymore.

For example, an Office 365 mailbox can be granted the Full Access permission to an on-premises shared mailbox.

We don’t, however, support the use of the Send-As, Receive-As, or Send on behalf of mailbox permissions in hybrid deployments between on-premises Exchange and Office 365 organizations.

[Source of information – Exchange Server Hybrid Deployments]

If a mailbox receives permissions from multiple mailboxes, that mailbox, and all of the mailboxes granting permissions to it, need to be moved at the same time.

[Source of information – Exchange Server Hybrid Deployments]

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.

[Source of information – Exchange Server Hybrid Deployments]

Scenario 2 – migrate only part of the Exchange on-Premises mailboxes to the cloud

In this scenario, we would like to verify, what are the Exchange permissions that will migrate to the cloud, along with the migrated mailbox given that we “break” existing permission’s relationship that exists between Exchange on-Premises mailboxes.

Description of the different scenario that we are going to check

In the following table, we can see the list of the different Exchange permission’s scenario that we are going to test:

Scenario 2 – migrate only part of the Exchange on-Premises mailboxes to the cloud

The expected results are as follows:

  • Full Access permission are going to be migrated to the cloud.
  • Send AS permission are not going to be migrated to the cloud.
  • Folder permission (calendar sharing) – there is no formal information regarding the expected results.
  • Delegated permission – there is no formal information regarding the expected results.

Phase 1#2 – preparing the Exchange on-Premises infrastructure for the test scenario

In the following scenario, we will deliberately “break” the permission relationships that existed between Exchange on-Premises mailboxes, by migrating only a specific Exchange on-Premises mailboxes to the cloud.

In our scenario, a recipient named Amanda, have permissions on a couple of Exchange on-Premises mailboxes.

Amanda mailbox will stay on the Exchange on-Premises server and all the recipient mailboxes that Amana has permissions to will be migrated to the cloud.

scnario 2 - Mailbox migration separation Exchange Hybrid

Step 1 – define the Exchange permission’s relationship between the Exchange on-Premises mailboxes.

The structure of the Exchange permission’s relationship that exists between the Exchange on-Premises mailboxes are as follows:

1. Emma has Full Access permission + Send As permission on Anthony Mailbox.

Exchange on-Premises Permissions matrix - Full Access permission and Send as Permission -A-01

In the following screenshot, we can see that Amanda has Full Access permission on Robert’s mailbox.

Exchange on-Premises Permissions matrix - Full Access permission and Send as Permission -A-02

In the following screenshot, we can see that Amanda has Send As permission on Robert’s mailbox.

Exchange on-Premises Permissions matrix - Full Access permission and Send as Permission -A-03

2. Emma has Publishing author permission to Jackson’s calendar.

Exchange on-Premises Permissions matrix - Calendar sharing permission -A-01

In the following screenshot, we can see that Jackson, share his calendar with Amanda by giving her Publishing author permission.

Exchange on-Premises Permissions matrix - Calendar sharing permission -A-02

3. Amanda configured as a delegate of Henry.

Exchange on-Premises Permissions matrix - Delegate permission -A-03

In the following screenshot, we can see Oliver’s mailbox. Oliver defines Emma as his delegate.

Exchange on-Premises Permissions matrix - Delegate permission -A-04

Phase 2#2 – Verifying the Exchange permissions that were migrated to the cloud

Migrating the Exchange on-Premises mailboxes to the cloud

In the following screenshot, we can see that the Exchange administrator, migrated only part of the Exchange on-Premises mailboxes that had “Exchange permission’s relationship” to the cloud (Exchange Online).

Scenario 2 – migrate only part of the Exchange on-Premises mailboxes to the cloud -01

1. Verifying the migrated explicit Full Access permissions

In the Exchange on-Premises environment, Amanda had Full Access permission on Robert’s mailbox.

The expected results are:

  1. Amanda explicit Full Access permission on Anthony’s mailbox will be migrated to the cloud.

The actual results are:

When we look at the mailbox delegation information on Robert’s mailbox, we can see that Emma has Full Access permission on Robert’s mailbox.

Verifying the Exchange Full Access permissions that where migrated to Exchange Online -A-01

In the next step, we will try to check if Amanda that had Full Access permission on Robert’s mailbox, can successfully access Robert’s mailbox.
Also, we would like to check if the Auto Mapping feature is still “working.”
The expected result is that the Auto Mapping feature will not be migrated to the cloud.

Verifying Amanda’s ability to access Robert’s mailbox

In the following screenshot, we can see the Amanda Outlook profile doesn’t include Robert’s mailbox.

Verifying the Exchange Full Access permissions that where migrated to Exchange Online -A-02

The expected result is that Amanda will “keep” her Full Access permission, but the AutoMap option was not supposed to be kept after the migration.

In other words, the expected scenario is that Amanda will need to add Robert’s mailbox to her Outlook mail profile manually.

In the following screenshot, we can see how to add Robert’s mailbox manually to Amanda Outlook mail profile.

Verifying the Exchange Full Access permissions that where migrated to Exchange Online -A-03

Robert’s mailbox successfully added to Amanda Outlook mail profile.

Verifying the Exchange Full Access permissions that where migrated to Exchange Online -A-04

2. Verifying explicit Send As permissions

In the Exchange on-Premises environment, Amanda had Send As permission on Robert’s mailbox.

The expected results are:

  1. Amanda explicit Send As permission on Anthony’s mailbox will not be migrated to the cloud.

The actual results are:

When we look at the mailbox delegation information on Robert’s mailbox, we can see that Amanda has Send As permission on Robert’s mailbox.

Verifying the Exchange Send As permissions that were migrated to Exchange Online -A-01

In the next step, we will try to check if Amanda that has Send As permission on Robert’s mailbox, can successfully send an E-mail message using the identity of Robert (using Robert E-mail address).
Verifying Amanda ability to send E-mail using Robert’s identity

To verify if Amanda Send As permission is functional, we will try to send E-mail from Amanda mailbox.

In the following screenshot, we can see that Amanda uses Robert’s identity, by providing Robert
E-mail address in the From field.

Verifying the Exchange Send As permissions that were migrated to Exchange Online -A-02

In the following screenshot, we can see that the E-mail successfully sent to the destination recipient.

The recipient (Jackson in our scenario) sees the E-mail as if it sent by Robert.

The conclusion is that the Send As permission was successfully migrated, and can be used by the recipient (Amanda) that has these permissions.

Verifying the Exchange Send As permissions that were migrated to Exchange Online -A-03


3. Verifying Folder permissions (calendar sharing)

In this section, we would like to check what happened the Folder permission that Amanda had on Jackson’s calendar (In the Exchange on-Premises environment; Amanda had Publishing author permission on Jackson’s calendar).

In the scenario of Folder permission (calendar sharing), we don’t have a “specific expected results” because the Microsoft articles, doesn’t include a direct reference to the Folder permission in a mailbox’s migration scenario.

To be able to check this scenario, we will login to Amanda’s mailbox, and check if she can access Jackson’s calendar.

In the following screenshot, we can see that Amanda manages to display Jackson’s calendar.

The meaning is, that the Folder permission was successfully migrated from the Exchange on-Premises environment to the cloud.

Verifying the Exchange Calendar Sharing permissions that where migrated to Exchange Online -A-01

4. Verifying Delegate permissions

In this section, we would like to check what happened the Delegate permission that Amanda had on Henry’s mailbox.

In the Exchange on-Premises environment, Amanda had Delegate permission on Henry’s mailbox.

In the scenario of Delegated permission, we don’t have an “expected results” because, the Microsoft articles, doesn’t include a direct reference to the Delegate permission in a mailbox’s migration scenario.

In the following screenshot, we can see that when we look at the delegated list that configured in on Henry’s mailbox, Amanda appears as delegated.

The meaning is that the Delegate permission was successfully migrated from the Exchange on-Premises environment to the cloud.

Verifying the Exchange Delegate permissions that where migrated to Exchange Online -A-01

Verifying Amanda’s ability to send E-mail on behalf Henry

The Delegation permission should enable Amanda to send E-mail on behalf of Henry.

To verify if Amanda Send on behalf permission is functional, we will try to send E-mail from Amanda’s mailbox.

In the following screenshot, we can see that Amanda uses Henry’s identity, by providing Henry E-mail address in the From field.

Verifying the Exchange Delegate permissions that where migrated to Exchange Online -A-02

In the following screenshot, we can see that the E-mail successfully sent to the destination recipient.

The recipient (Robert in our scenario), sees the E-mail sent by Amanda on behalf of Henry.

The conclusion is that the Send on behalf permission was successfully migrated.

Verifying the Exchange Delegate permissions that were migrated to Exchange Online -A-03

Summary and recap

In the following comparison table, we can inform about the expected Exchange permissions that should migrate versus the actual result of the Exchange permissions that migrated.

Partial mail migration, only some of - The migrated Exchange permissions - test result table

Just a quick reminder, the scenario that we have reviewed in the current article based on a concept in which we “separate” between Exchange on-Premises mailboxes that have an Exchange permission’s relationship, and migrate only part of the mailboxes to the cloud.

It’s important that we notice the difference between the “expected results” as they appear in the Microsoft formal articles, versus, the “actual results” that we get when performing the mail migration.

When looking at the “actual results,” we can see that some of the permissions that were not supposed to migrate to the cloud, was migrated!

To what “row” should you reference

In case that your question is – should I relate to the precise information that appears in the Microsoft article (the expected result) or should I relate to the results that I experience when I migrate mailboxes to the cloud?

My answer is:

It’s important that we will be familiar with the “formal information” as it’s published by Microsoft because this information defines what are the exact Exchange permissions that are supposed to migrate.

In case that you experience a problem regarding the Exchange permission that was meant to be migrated and was not migrated, only then we can contact Microsoft’s support.

Bottom line

When you plan your mail migration project in an Exchange Hybrid environment, you will have to decide if you want to relate only to the documented precise information or, to the actual results that you get by testing the different mail migration scenarios.

Cross site permission and migrated permissions – Exchange Hybrid | Article series index

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5
Article Name
Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5
Description
In the current article, we will review the mail migration scenario in which we “break” existing Exchange permission’s relationship.I use the term “break” because in this scenario we are migrating only one partner from the existing “couple” to the cloud.
Author
Publisher Name
o365info.com
Publisher Logo

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

2 Responses to “Migrating Exchange on-Premises Mailboxes Separately | Exchange Hybrid based environment | What are the migrated permissions? | Part 5#5 ”

  1. Not sure what you’re doing differently, but my send-as rights are not working in the cross premises setup where some users are on EXO and some remain on prem. 🙁

  2. Excellent article with great in-depth details.

    However, like Joe, I have received different results than what you have achieved. My summary below
    Summary –
    – Send As does not work cross site
    – Calendar Delegate does not work cross site (via Outlook Delegates)

    I think the main takeaway from all of this is to batch up your moves to business groups to ensure delegates are captured as best as humanly possible. You need a good project manager to get the right information from your end clients to reduce the instances of broken permissions impacting your end clients.

Leave a Reply

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