This blog post was originally posted in Essential’s blog.
There’s two things to bear in mind when it comes to migrating mailbox permissions to Office 365:
Number 1 – You won’t get an ‘easy ride’
The process of switching across permissions as you move to Office 365 is not usually plain-sailing. There are always caveats and exceptions which mean you’re going to have to roll up your sleeves and:
- Do the groundwork to understand what types of permissions you’re migrating, and
- Pre-empt and be prepared to fix up what doesn’t get migrated post-migration.
This is the only way to ensure a smooth user experience and avoid a deluge of calls to your help desk. In brief, the following scenarios apply to the different migration approaches you might take (some exceptions are outlined later in this article):
- If you’re planning a Cut-Over or Staged migration approach, using DirSync or the Azure AD Connect tool to provision mailboxes copies any folder permissions and delegate access permissions that exist on on-premises mailboxes into the cloud. Send As or Full Mailbox Access permissions, however, aren’t replicated. This means you’ll need to re-apply these permissions manually as each group is moved over.
- If you’re running in a Hybrid environment and you’re using MRS to transition mailboxes, this does not (as yet) automatically synchronise Send As permissions. So any usage of this permission must be sussed out in advance and manually re-applied to the relevant mailboxes.
- If instead of using MRS you plan to use a 3rd-party tool to do your mailbox migration, you will need to be prepared to have to manually re-apply all permissions post-migration unless the tool can do it for you.
Number 2 – You’ll need to migrate sharers together
Unless you’re planning to migrate everyone in your organisation to Office 365 over the space of a weekend (e.g. using a Cut-Over migration), you’re always going to have co-existence issues when it comes to permissions working ‘across the divide’. This is because most permissions between individuals and shared mailboxes only work when both the ‘granters’ and the ‘grantees’ (if you will) are in the same ‘place’ – i.e. all on-premises or all in the Cloud. Some permission combination only work one-way – i.e. from on-premises mailboxes accessing a shared mailbox in the cloud, but not the other way around.
If you’re migrating in a Hybrid environment, the good news is that Microsoft now officially supports folk that have been granted Full Mailbox Access to continue ‘business as usual’ regardless of where they are in the migration process. However, given that Send As or Send on Behalf permissions are commonly set up on team mailboxes or between a manager and a personal assistant, this is not in reality going to get you very far. For example, without Send on Behalf being migrated, someone on the help desk may be able to see support emails post-migration, but no longer be able to respond to them if the Help Desk mailbox is still physically on premises.
So, the top tip is to move any ‘sharers’ to Office 365 together, that is, in the same batch.
In order to tackle both of these scenarios you need to be able to assess exactly what permissions are in place.
This is a good blog that explains how to extract the on-premises permissions information you need for review.
The scripts offered in this blog let you extract permissions into a CSV file, which you can then automatically apply to Office 365 using remote PowerShell using scripts.
So what are the exceptions and other things to watch out for?
As we alluded to earlier, there are always exceptions and complications. For example:
- Non Mail-Enabled Objects: Any permissions on non-mailbox objects (such as distribution lists or a public folder) are not migrated automatically. Therefore, you need to be able to identify and recreate these permissions in Office 365 using the Add-MailboxPermission or Add-RecipientPermission cmdlets.
- Distribution Group Permissions: If distribution groups are used to assign permissions, you will need to drill into who is a current member of the group to ensure they are included in the same migration batch. Also you may find you have nested groups, in which case you will need to drill into these also to get the complete picture.
Other best practices:
Keep Users Informed on What Might Happen to Their Permissions as They Migrate – the Auto Mapping feature is unsupported when used between mailboxes in on-premises Exchange and Office 365 organisations. This is the service that ensures the mailboxes, calendars, etc. that users have permissions to are automatically added to their Outlook profile. For this reason you may wish to advise users to create a pre-migration inventory of what they have access to so they can re-subscribe post-migration.
Don’t Cancel Meetings – When deciding which mailboxes to move together, make sure you consider any shared Calendars. On a similar subject, to ensure your room booking processes continue to work seamlessly make sure resource mailboxes have all the correct permissions and In Policy booking settings (e.g. automatically accept a room booking within office hours/weekdays). If you have an individual that is set up as a delegate on a room resource mailbox (for example, with the purpose of approving or turning down booking requests), you will need to make sure you migrate that individual along with the room resource.
Have a Permissions Clear Out – As with moving house, migrations are a great opportunity to take stock of what you no longer need. This applies to getting rid of excess access rights.
You should grant minimal access to as few people as possible to accomplish the task at hand. For example, users might grant delegation rights when simply using sharing folder permissions will suffice. Delegate access rights arguably carry more powers than just the ability to review and manage a co-worker’s mail folder. With delegate access a co-worker can send emails and accept meeting invitations on behalf of an individual. They might also be configured to receive copies of meeting invites.
Also note that the administrator applied ‘Send As’ permission can be problematic from a security auditing perspective as it can be difficult to determine who sent an email in the event of a legal investigation. Was it the manager or one of their PAs?
PS – You might consider it a good idea to turn off the feature in Office 365 that allows users to share their Calendars externally.
Don’t Move Backwards – If you discover you’ve moved a manager into the Cloud and not their assistant, it’s not a good strategy to move the manager’s mailbox back down on-premises. It’s always better move the PA across as soon as possible.
Don’t Take it For Granted Microsoft has Everything Sewn Up – A relatively recent bug in Exchange and Office 365 meant that – thanks to delegated access rights – emails could be accessed via OWA and effectively deleted from a mailbox without trace, even when the mailbox in question was on litigation hold.
This should be fixed at the time of writing, but it highlights the importance of being able to understand what permissions are in place. For example, at the time of the bug being reported a suggested workaround was to disable OWA access for users on In-Place Hold.
Consider Access to Archived items – If you’re migrating archives as part of your migration, ideally you need to ensure that users can still access the archives they could view and search pre-migration, post-migration. This should include items (shortcuts) that were forwarded, for example.
Also typically the archives you move should mirror the batches of mailboxes you move, but if possible, archives can be moved first.
What customers have done in their projects
Keeping track of permissions is clearly a challenging concept and an area that can constantly evolve especially if changes are being made prior to a migration.
In line with the scripts and articles mentioned earlier, a large majority of customers we speak to prefer to proactively manage permissions and ensure there is constant visibility both pre- and post-migration.
To gain this consistent visibility and maintain full control, our customers opt for Mailscape 365 which delivers real time monitoring and intelligent, interactive reports can be scheduled through a web based dashboard to help you work out your array of permissions, including the more tricky delegate permissions before they come back to haunt you. These can be sent as a PDF or CSV which you can use in your scripts.
A few key reports are included below:
- Users Sending As other users
- Users Sending On Behalf of other users
- Users Accessing other Mailboxes
- Mailbox Delegate Permissions (including who has delegate permissions and who their delegates are)
- Mailboxes by OU
- All groups an object belongs to
- The members of all groups an object belongs to
You can also do a cross reference with Office 365 once the users are migrated:
- Office 365 Recipient Permission Report
- Office 365 Send on Behalf permission report
Mailscape also monitors and reports on your on-premises Exchange system and other technologies such as Skype for Business, SharePoint, Active Directory and much more, so if you would like to learn more and take a test-drive or see a demo, get in touch.