#mailbox migration

New Post has been published on http://o365info.com/migrating-exchange-on-premises-mailboxes-separately-exchange-hybrid-based-environment-what-are-the-migrated-permissions-part-5-of-5/

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

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 actually 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.

Article series Table of content | Click to expend

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

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

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

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

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

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 formal 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, because, 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 be migrated 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:

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.

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.

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

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

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

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

3.  Amanda configured as a delegate of Henry.

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 only part of the Exchange on-Premises mailboxes that had “Exchange permission’s relationship” to the cloud (Exchange Online).

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:

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.

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. In addition, 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.

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.

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

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:

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.

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.

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

The recipient (Jackson in our scenario) sees the E-mail as if it was 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.

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.

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 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.

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

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

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

Summary and recap

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

Just a quick reminder, the scenario that we have reviewed in the current article was 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 migration that was not supposed to be migrated to the cloud, was migrated!

To what “row” should you reference

In case that your question is – should I relate to the formal 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 be migrated.

In case that our experience problem in which a specific Exchange permission that was supposed to be migrated 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 formal 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

New Post has been published on http://o365info.com/migrated-permissions-of-migrated-mailboxes-in-exchange-hybrid-based-environment-introduction-part-3-of-5/

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 main question that we need to answer is – what will happen to the existing permissions?

Article series Table of content | Click to expend

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

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

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

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

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

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. This is a term that I use for describing Exchange mailbox that has a specific 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 major 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 are 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 granted 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 be 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 specific 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 are 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 be 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 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:

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 versus 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 specific “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 specific 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 specific 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”

Additional reading

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 1)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 2)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 3)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 4)

Advanced sharing scenarios with Exchange Hybrid deployments

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

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

New Post has been published on http://o365info.com/migrated-permissions-of-migrated-mailboxes-in-exchange-hybrid-based-environment-introduction-part-3-of-5/

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 main question that we need to answer is – what will happen to the existing permissions?

Article series Table of content | Click to expend

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

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

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

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

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

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. This is a term that I use for describing Exchange mailbox that has a specific 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 major 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 are 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 granted 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 be 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 specific 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 are 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 be 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 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:

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 versus 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 specific “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 specific 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 specific 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”

Additional reading

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 1)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 2)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 3)

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 4)

Advanced sharing scenarios with Exchange Hybrid deployments

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

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

New Post has been published on http://o365info.com/testing-cross-site-permissions-exchange-hybrid-based-environment-part-2-of-5/

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

As mentioned in the former article, the subject of Exchange permissions relationship in Exchange Hybrid environment can be realized in two major scenarios:Scenario 1 – Cross site permission

Scenario 1 – Cross site permission The Exchange permissions that Exchange on-Premises mailbox can have on cloud mailbox and vice versa.

Scenario 2 – Mailbox migration A scenario in which we migrate Exchange on-Premises mailbox to the cloud and vice versa.

The current article is dedicated to the scenario 1, we will review and verify the specific Exchange permissions that considered as “cross site permissions.”

Article series Table of content | Click to expend

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

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

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

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

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

The formal information about “cross site permissions” in the Exchange Hybrid environment

In the following quotation, we can see the information about the “cross site permissions” in Exchange Hybrid that is published by Microsoft:

Support for cross-premises 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 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.

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]

The information in the article tells us that:

1.  We can define the Full access permission between mailboxes that located on Exchange on-Premises environment and Exchange Online environment.

2.  Cross site permissions in Exchange Hybrid environment don’t support Send As and Send on behalf Exchange permissions.

The information in the article doesn’t relate to the following scenarios:

1.  Cross site permissions and calendar sharing

There is no clear statement regarding the subject of – “cross site permissions” and calendar sharing (calendar sharing is implemented by using Exchange Folder permission).

2.  Assigning permissions to a security group

There is no clear statement regarding the subject on – the ability to assign permission such as Full Access permission to a security group.

3.  Delegated permissions

Delegated permissions can be considered as a combination of Folder permission and Send on behalf permission. The article says that Send on behalf permission is not supported, but it is not clear if there is an option to use delegation between Exchange on-Premises mailbox and cloud mailbox (and vice versa).

Our scenario description

To be able to get clearer answers for the “missing parts” of information regarding the supported cross site permitting, we will use the following scenario:

An organization named o365info.com that uses Exchange Hybrid based environment.

Alice is the personal assistant of Bob.

Bob’s mailbox is located in the cloud (Exchange Online) and Alice’s mailbox is hosted by the Exchange on-Premises server.

We would like to assign Alice various types of Exchange permissions, so she will be able to access Bob’s mailbox.

In the following section, we will test a different type of possible Exchange permissions in which Bob will “allow” Alice to have a specific permission to his mailbox.

Trying to assign delegation permissions in Exchange Hybrid environment

In the next section, we will try to check if the cross site permissions in Exchange Hybrid environment support Delegation permissions.

Bob tries to define Alice as his delegate.

The delegation is implemented by using the File menu ==> Account Settings… ==> Delegate Access ==> Add…

In the following screenshot, we can see the list of the Exchange recipients.

Technically speaking, when we use the GAL (recipient list) when we send new mail, the recipient list doesn’t enable us to differentiate between Exchange on-Premises recipient and “cloud recipients.” In other words, Bob doesn’t know if Alice’s mailbox is located at the Exchange on-Premises server or Exchange Online.

In the current scenario, Bob uses the recipient list for locating and selecting an Alice’s name.

Notice an interesting thing, when we look over the recipient list, we can see that on the left side of some of the recipient’s name, there is a red circle icon.

The meaning of this icon is, that we cannot assign the required permissions to the recipient who have this red circle icon.

In case that Bob tries to add Alice’s name as a delegate, the following error appears:

The user Alice Caamano cannot be added. Non-local users cannot be given rights on this server

The conclusion

Cloud recipient cannot define Exchange on-Premises recipient as his delegate.

Trying to share calendar (Folder permissions) in the Exchange Hybrid environment

In the following section, we will try to check if we can assign Folder permission in Exchange Hybrid environment.

In our scenario, Bob tries to share his calendar (Folder permission) with Alice.

To share the calendar, we will choose the calendar permissions icon and click on the Add… button.

Very similar to the former scenario, we can that on the left side of some of the recipient’s name, there is a red circle icon.

In case that Bob tries to add Alice’s name as a delegate, the following error appears:

“The user Alice Caamano cannot be added. Non-local users cannot be given rights on this server”

The conclusion

Cloud recipient cannot share his calendar with Exchange on-Premises recipient.

Trying to assign Send As permissions in Exchange Hybrid environment

In the following section, we will try to check if we can assign Send As permission in Exchange Hybrid environment.

In our scenario, we will assign to Alice (Exchange on-Premises recipient) the Send As permission on Bob’s mailbox that is hosted at Exchange Online.

In an Exchange environment, the recipient cannot assign the Send As permission by himself. The Send As permission can be assigned by an Exchange administrator. We will log into the Exchange Online management and assign the Send As permission.

In the following screenshot, we can see that we assign the Send As permission to Alice on Bob’s mailbox.

In the next phase, Alice will try to send E-mail using Bob E-mail address. We can see the Alice has added the “From” option to the E-mail message, and she uses Bob E-mail address.

When Alice tries to send the E-mail message, the following error message appears: “You do not have the permissions to send the message on behalf of the specific user”

The conclusion

Exchange on-Premises recipient cannot have Send As permission on a cloud mailbox.

Trying to assign Full access permissions in Exchange Hybrid environment

In the following section, we will try to check if we can assign Full Access permission in Exchange Hybrid environment.

In our scenario, we will assign to Alice (Exchange on-Premises recipient) the Full Access permission on Bob’s mailbox that is hosted at Exchange Online.

In the following screenshot, we can see that we assign the Full Access permission to Alice on Bob’s mailbox.

By default, when we assign Full Access permission, the option of Auto Mapping is activated automatically.

The purpose of the Auto Mapping feature is, to add the mailbox which the recipient has Full Access permission on, to his Outlook mail profile automatically.

When using the has Full Access permission in a scenario of cross site permissions the option of Auto Mapping is not available.

In other words, the user will need to add the mailbox which he has Full Access permission on, to his Outlook mail profile manually.

Attached a Quotation from Microsoft article-

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]

In the following screenshot, we can see that Alice will need to add Bob’s mailbox manually to her Outlook mail profile.

A credential’s windows appear; Alice will need to provide her credentials.

In our specific scenario, Alice provides her On-Premise Active Directory credentials.

Note – in a “standard Full Access permission’s scenario” the recipient who has the Full Access permission, doesn’t have to provide his credentials. The need of providing credential is implemented only in a cross site permissions scenario.

In the following screenshot, we can see that Bob’s mailbox appears in Alice Outlook profile.

The conclusion

Exchange on-Premises recipient can have Full Access permission on a cloud mailbox.

Trying to assign Full access permissions to a security group in an Exchange Hybrid environment

In the following section, we will try to check if we can assign Full Access permission in Exchange Hybrid environment to a security group. If we want to be more accurate to a mail-enabled a security group.

The security group will include Exchange on-Premises recipients.

The purpose is – to verify if we can use the option of – Inherited (non-explicit) mailbox permissions. The meaning is, assign permissions to a group instead to a specific recipient and verify if the Exchange on-Premises recipient that includes in this group can use the permissions that they “inherit” from the security group.

To be able to check this scenario, we will make the following preparations:

We will create an On-Premise Active Directory mail-enabled security group named – On-Prem security.

We will add Exchange on-Premises recipient (Alice) as a member of this group

We will assign the On-Prem security Full Access permission to Exchange Online mailbox (Anthony)

We will check if the Exchange on-Premises recipient (Alice) can add the Exchange Online mailbox to her Outlook mail profile.

Step 1 – we use Exchange on-Premises management for creating a mail-enabled security group

Step 2 – we add Alice (Exchange on-Premises recipient) to the mail-enabled security group as a member.

Step 3 – we use the Exchange Online management interface for assigning the mail-enabled security group (On-Prem security) Full Access permission to Anthony’s mailbox.

Step 4 – we manually try to add “Anthony mailbox” to Alice Outlook mail profile. As mentioned, in Exchange Hybrid environment the Exchange feature AutoMap is not supported and for this reason, we will need to manually add the mailbox.

In the following screenshot, we can see that the mailbox was successfully added to the Alice Outlook mail profile.

The conclusion

We can assign Full Access permission to the mail-enabled security group that includes Exchange on-Premises recipient on a cloud mailbox.

Recap and conclusion

In the following table, we can see the summary of the results of the tests that was implemented.

We can see that Full Access permission is supported and operate properly when we assign the permissions to a specific recipient or to the mail-enabled security group.

As It was written in the article, Send As permission and Send on behalf permission are not supported as part of the cross site permissions.

The additional parts that were not mentioned in the formal Microsoft articles are

Delegated permission – this type of permission is not supported as part of the cross site permissions.

Folder permission (calendar sharing) – this permission is not supported as part of the cross site permissions.

Additional reading

Hybrid Headaches – The Confusing Case of Cross-Forest

Exchange Hybrid Deployments and cross-premises Full Access permissions | Michael ‘Van Hybrid’ / Van Horenbeeck

EX2013 CU5/CU6 Hybrid and WSSecurity federation issues

Hybrid: Unable to Share Full Details and Limited Details Calendar from Outlook | MSExchangeGuru.com

ARCHIVED] [SOLVED]After Migration, unable to share calendar in Hybrid Mode | Email and calendar | Microsoft Office 365 Community

Calendar Federation with an Exchange Hybrid | Microsoft MVP Award Program Blog

The next article in the current article series

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

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

How to Move Mailbox from Exchange Server 2010 SP3 to Exchange Server 2013 CU1

In this blog we would be exploring on how to start with the first step towards planning for…