Although solutions exist to migrate mailbox permissions, we have to decide what permissions should move rather than just moving them over. In this post, I will cover the common considerations when deciding what mailbox permissions to migrate in MAD projects.
First, let’s review the three kinds of Exchange Mailbox Permissions:
- Full Mailbox Permissions
- Assigned by an administrator
- Most common for shared mailboxes
- Delegate Permissions
- Assigned by a user or an administrator
- Most common for Administrative Staff to manage calendars and other items
- Folder Level Permissions / Calendar Permissions
- Assigned by a user normally
- Most common for people to share calendars with other colleagues, but several other nasty business processes exist! (see below)
All three of these scenarios have specific use cases. However, one common theme exists across them all: Often they are added and never reviewed.
Some organizations have developed annual access reviews to combat this issue, but others do not. Commonly when one company buys another, they are purchasing a smaller company that likely has looser security policies. When planning the migration, and understanding the considerations for Mailbox Permissions, you have to balance function, security, and help desk volumes.
When users log into the new system, if they can’t manage someone’s calendar like they used to, that likely will generate an urgent help desk call. The same can be said for every scenario above. Although few will notice when they still have access to somewhere they do not need, this process can uncover compliance issues. One issue that can make this concern even more apparent is AutoMap.
AutoMap
Years ago, users had to go through several annoying clicks to add a shared mailbox to their Outlook profile. Help Desks always had to deal with this issue and users always got annoyed. Microsoft introduced a feature called “AutoMap” where the shared mailboxes you have access to are added to your profile. This is great. However, if your source environment has this off, and the target has it on, and you migrate permissions, users can see all the mailboxes they had access to but didn’t use. This too will cause help desk calls, but as indicated above, can help uncover compliance issues
Note on Folder Level Permissions
Beyond calendar permissions, some people have complex folder structures with unique folder level permissions. This can be as simple as someone sharing out a folder of their mailbox to one person, or several folders and levels with unique permissions. Most would argue this isn’t a great idea, but you will find this business process. If you do not move folder level permissions, this can be quite impactful for the select few that have spent a lot of time doing this level of granular access.
What is the right option?
You need to understand what users are doing and what has been done in the past. It may be time for a “clean slate” approach and provide users with instruction on how to add delegates and permissions back post migration. More commonly in projects, I find the right mix is adding full mailbox permissions for shared mailboxes and delegate permissions only for user mailboxes. However, your project may have different requirements and you may choose one option for a subset of users.
The right option will also depend on how the target controls these permissions. If rules are strict, then it may be best to have users re-apply permissions and cover this in communications.
If you want to learn more, check out my webinar on this topic over at Quadrotech on June 16th at 4PM BST. If it is after June 16th, you can register to view the recording. Register here: https://resources.quadrotech-it.com/webinar/office-365-tenant-migration-how-to-migrate-exchange-mailbox-permissions
