This is the second in a series of posts. You can find links to the other parts of the series here:
In Part One I gave an overview of the different scenarios in which cross-premises permissions are affected in a Hybrid scenario between Office 365 and Exchange On-Premises. In this part I will start testing and demonstrating the behaviour of the various permissions, starting with Full Access permissions, the simplest of all the permissions in this scenario, but still with considerations to bear in mind. At this point I should clarify that the following information is based on an Exchange Hybrid Lab with Exchange 2016, but the experience is expected to be the same in any supported Hybrid deployment.
So, the Full Access permissions look as follows:
So, for the purposes of these tests I will be working with two mailboxes, Delegate Mailbox1 and Delegate Mailbox2 (inventive, I know!). To test full access permissions, I have set both user accounts up with Full Access to the other mailbox in Exchange On-Premises as per the screenshots below, I then migrated Delegate Mailbox2 to Exchange Online:
Migrated User Accessing On-Premises Mailbox
The user’s migration experience was exactly as expected, and then after the migration, I re-opened Outlook, went to expand the folders, et voilà! Full Access works perfectly!
On-Premises User Accessing Migrated User
With my on-premises user the experience was very similar. I received a prompt to restart Outlook, and then the folders were there without any problems! Nice and simple! In both cases, as the accounts had been auto-mapped before the migration, the accounts showed up without any intervention.
Adding new permissions cross-premises
Adding new permissions cross-premises saw some interesting behaviour. I was only able to add Full Access permissions to on-premises mailboxes via PowerShell as the O365 mailboxes were not visible in the picker via EAC. From Exchange Online, I was able to add via EAC in the GUI. As expected, both sides required adding the mailboxes manually from Account Settings within Outlook, but after letting the changes propagate, worked perfectly!
In summary, as expected this all worked – it should do now that it is fully supported by Microsoft! But definitely worth noting the few “gotchas” around where you can add the permissions and the auto-mapping behaviours for existing and new permissions.
In the next part, I will be running through the experience with Send As/Send on Behalf permissions, so subscribe to make sure you don’t miss it!