In the current article, we will review the mail migration scenario in which we “break”…
Migrating Exchange on-Premises mailboxes as a group | Exchange Hybrid based environment | What are the migrated permissions? | Part 4#5
In the current article, we will review the scenario in which we migrate Exchange on-Premises mailboxes that have an “existing permission’s relationship” to the cloud as a group.
Our purpose is to check what are the Exchange permissions, which will migrate to the cloud, along with the mailbox data.
In the next article, we will review a slightly different scenario in which we verify what are the Exchange migrated permissions in case that we “break” the relationship between Exchange on-Premises mailboxes that have an “Exchange permission’s relationship.”
Table of contents
Scenario 1 – migrate Exchange on-Premises mailboxes as a “group” to Exchange Online
Let’s start with the formal information about migrated permissions as it appears in Microsoft’s article:
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.
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. In addition to these permissions, the Auto Mapping feature is also unsupported when used between mailboxes in the on-premises Exchange and Office 365 organizations.
[Source of information – Exchange Server Hybrid Deployments]The information in the Microsoft article relates to the following parts:
The migrated permissions
The Microsoft article explains that, as long as we migrate from Exchange on-Premises mailboxes as a “group,” the following explicit permission’s Full Access permission and Send As permission, should be migrated.
Non-migrated Exchange permissions
- Inherited (non-explicit) mailbox permissions will not be migrated.
Note – if you are not familiar with the concept of Inherited (non-explicit) mailbox permissions, read the article section –Migrated permissions of migrated mailboxes in Exchange Hybrid based environment – Introduction | Part 3#5 - The Auto Mapping feature is unsupported when we migrate mailboxes that had Full Access permissions from on-premises to Exchange Online.
The article doesn’t relate to the following Exchange permissions:
- Folder permissions such as calendar sharing
- Delegated permissions
Description of the scenario that we are going to check
In the following table, we can see the list of the different Exchange permission’s scenarios, that we are going to test:
The expected results are as follows:
- Full Access permissions are going to be migrated to the cloud.
- Send As permissions are not going to be migrated to the cloud.
- Non-explicit permissions are not going to be migrated to the cloud.
- AutoMap feature is not going to be available.
- Folder permissions (calendar sharing) – there is no formal information regarding the expected results.
- Delegated permissions – 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 migrate a group of Exchange on-Premises mailboxes, that have an “Exchange permission’s relationship” between them.
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’s mailbox.
2. A security group named – Helpdesk, have Full Access permission + Send As permission on Anthony’s mailbox.
In the following screenshot, we can see that Alice is a member of the Helpdesk security group. Later, after we migrate the Exchange on-Premises mailboxes to the cloud, we will check if the permissions that assigned to the security group was also migrated. We will verify if Alice can continue to have Full Access permission to Anthony’s mailbox.
In the following screenshot, we can see that Emma and the Helpdesk group
have Full Access permission on Antony’s mailbox.
In the following screenshot, we can see that Emma and the Helpdesk group
had Send As permission on Antony’s mailbox.
3. Emma has Publishing author permission to William’s calendar.
In the following screenshot, we can see that William, share his calendar with Emma by giving her Publishing author permission.
4. Emma configured as a delegate of Oliver.
In the following screenshot, we can see Oliver’s mailbox. Oliver defines Emma as his delegate.
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 the group of the Exchange on-Premises mailboxes, which had “Exchange permission’s relationship” to the cloud (Exchange Online).
1. Verifying the migrated explicit and non-explicit Full Access permissions
In the Exchange on-Premises environment, Emma and a security group named Helpdesk
had Full Access permission on Anthony’s mailbox.
The expected results are:
- Emma explicit Full Access permission on Anthony’s mailbox will be migrated to the cloud.
- Helpdesk security group non-explicit Full Access permission on Anthony’s mailbox, will not be migrated to the cloud because the Microsoft article says that – “Inherited (non-explicit) mailbox permissions are not migrated”.
The actual results are:
When we look at the mailbox delegation information on Anthony’s mailbox,
we can see that Emma + a security group named Helpdesk have Full Access permission on Anthony’s mailbox.
In the next step, we will try to check if the recipients (Emma + a security group named Helpdesk) that have Full Access permission on Antony’s mailbox, can successfully access Antony’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 Emma ability to access Anthony’s mailbox
In the following screenshot, we can see the Emma Outlook profile after the migration to Exchange Online. We see that Emma Outlook profile includes Anthony’s mailbox.
This is partially expected result because, the expected result was, that Emma should keep
her Full Access permission to Anthony’s mailbox, but the AutoMap option was not supposed to be kept after the migration.
In other words, the expected scenario is that Emma will need to add Anthony’s mailbox to her Outlook mail profile manually.
Verifying Alice (a member of a security group) ability to access Anthony’s mailbox
In Exchange on-Premises environment, Alice is a member of the security group named – Helpdesk and the Helpdesk group had a Full Access permission to Anthony’s mailbox.
The expected result is that Alice will not be able to view Anthony’s mailbox in her Outlook mail profile. The Microsoft articles say 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.”
In the following screenshot, we can see Alice Exchange on-Premises Outlook profile.
We can see that Alice Outlook profile includes Anthony’s mailbox.
This is not expected result because the expected result was that Inherited (non-explicit) mailbox permissions should not migrated.
2. Verifying explicit Send As permissions
In the Exchange on-Premises environment, Emma and a security group named Helpdesk
had Send As permission on Anthony’s mailbox.
The expected results are:
- Emma explicit Send As permission on Anthony’s mailbox will be migrated to the cloud.
- Helpdesk security group non-explicit Send As permission on Anthony’s mailbox, will not be migrated to the cloud because the Microsoft article says that – “Inherited (non-explicit) mailbox permissions are not migrated”.
The actual results are:
When we look at the mailbox delegation information on Anthony’s mailbox, we can see that Emma + a security group named Helpdesk have Send As permission on Anthony’s mailbox.
In the next step, we will try to check if the recipients (Emma + a security group named Helpdesk) that have Send As permission on Antony’s mailbox, can successfully send an E-mail message using the identity of Antony (using Antony E-mail address).
Verifying Emma ability to send E-mail using Anthony’s identity
To verify if Emma Send As permission is functional, we will try to send E-mail from Emma’s mailbox.
In the following screenshot, we can see that Emma uses Anthony’s identity, by writing down Anthony’s E-mail address in the From field.
In the following screenshot, we can see that the E-mail successfully sent to the destination recipient.
The recipient (William in our scenario) sees the E-mail as if it sent by Anthony.
The conclusion is that the Send As permission was successfully migrated, and can be used by the recipient (Emma) that has these permissions.
3. Verifying Delegate permissions
In this section, we would like to check what happened the Delegate permission that Amanda had on Oliver’s mailbox.
In the Exchange on-Premises environment, Emma had Delegate permission on Oliver’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 Anthony’s mailbox, Emma appears as delegated.
The meaning is that the Delegate permission was successfully migrated from the Exchange on-Premises environment to the cloud.
Verifying Emma ability to send E-mail on behalf Anthony
The Delegation permission should enable Emma to send E-mail on behalf of Oliver.
To verify if Emma Send on behalf permission is functional, we will try to send E-mail from Emma’s mailbox.
In the following screenshot, we can see that Emma uses Oliver’s identity, by providing Oliver’s
E-mail address in the From field.
In the following screenshot, we can see that the E-mail successfully sent to the destination recipient.
The recipient (William in our scenario), sees the E-mail sent by Emma on behalf of Oliver.
The conclusion is that the Send on behalf permission was successfully migrated.
4. Verifying Folder permissions (calendar sharing)
In this section, we would like to check what happened the Folder permission that Emma had on William’s calendar (In the Exchange on-Premises environment; Emma had Publishing author permissions on Oliver’s calendar).
In the scenario of Folder permission (calendar sharing), we don’t have an “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 Emma’s mailbox, and check if she can access William’s calendar.
In the following screenshot, we can see that Emma manages to display William’s calendar.
The meaning is, that the Folder permission was successfully migrated from the Exchange on-Premises environment to the cloud.
Summary and recap
In the following table, we can a “matrix” of Exchange permissions in a scenario of migrated mailboxes in the Exchange Hybrid environment.
It’s important that we notice the difference between the “expected results” as they appear in the Microsoft formal articles vs. the “actual results” that we get when performing the mail migration.
In case that your question is – should I relate to the precise information that appears in the Microsoft article or should I relate to the results that I experience when I migrate mailboxes to the cloud?
My answer is that it’s important that we know “what to expect” by being familiar with the “formal information” that published in the Microsoft articles.
Regarding the migrated permission’s results that are different from the formal information, there is no guarantee that you will get the same results in your environment.
Also, in case that you will need to contact Microsoft support regarding issues with “migrated permissions,” and the information doesn’t appear in the formal article, there is high chance that you will not be able to get the required 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 formal information or, to the actual results that you get by testing the different mail migration scenarios.
This Post Has 0 Comments