Granting Mailbox Full Access via Groups and keeping the Automapping feature in Exchange 2010
Since Exchange 2010 Service Pack 1 a new feature was added for Outlook 2007 and 2010 users, namely Automapping. When a mailbox user has Full Access on another mailbox, it will be automatically mapped in Outlook. No need for the user to go trough menus to find the additional mailbox screen. It’s a small addition but I know that users and your service desk will appreciate this.
There is one catch I came across, namely automapping does not work when the Full Access permission is granted via a security group. The mailbox is however accessible, but there is no automatic mapping in Outlook.
That constitutes an issue whenever you have a security model based on handing down permissions only via groups and never directly (or at an absolute minimum). In this case you loose the benefit of Automapping. Also if users are not allowed to change certain settings in Outlook, let’s say account settings, they themselves are not able to correctly add an additional mailbox. In this case automapping would have been an excellent substitute.
For these issues I have constructed scripts that will grant all unique users according to group and all subsequent subgroups membership direct full access permission on a specified mailbox. One of those works with an CSV file and is therefore very well suitable to implement with Scheduled Tasks. Check out Mike Pfeiffer's blog post on that subject.
In one instance I have scheduled the CSV version of my script to run once a day a few hours before office hours, but every environment has it’s own requirements. Note that it can take up to two hours for Exchange to implement the new permissions, because of caching by the Information Store service.
In order to recursively get all users from the group parameter and every group that is member of said group, I’ve used portion of a script made by Steve Goodman’s blog post “How to report which Exchange mailboxes group members have full access to”. I have his permission to use and abuse that function, thanks Steve!
Users which are no longer member of any specified groups (or subgroup) are removed. Actually all users (including groups, with the exception of the group used as parameter) are removed when they are directly granted permissions, meaning that inherited permissions will not be affected. The SELF account will obviously be left alone.
I’ve made them available via SkyDrive, click on the link to save the ps1 files.
*update 20120110* There still was a little reference to a specific environment, that has been removed.
Click to download: Set-MailboxPermissionGroupFA.ps1
Format:
Set-MailboxPermissionGroupFA –Mailbox <mailbox> –Group <group>
This script will grant Full Access to all members and members of subgroups of <group> on mailbox <mailbox>.
It needs two parameters, –mailbox and –group. The Mailbox parameter is the mailbox users will get Full Access permission on. The Group parameter is the group where group members are granted Full Access. This works recursively, meaning that when a group is a member the script will check that group for users etc. etc..
As the main Exchange function is Add-MailboxPermission, the parameter Mailbox should adhere to the same format constraints as the Identity parameter. As for the Group parameter, check the Identity parameter from the Get-Group cmdlet.
And as previously mentioned, this script will remove all directly attributed full access permissions when that user is not a group member (anymore). Inherited permissions and the SELF user are left alone though.
Click to download: Import-MailboxPermissionGroupFA.ps1
Format:
Import-MailboxPermissionGroupFA –ListLocation <location of CSV file>
This script will import a CSV file which contains the names of mailboxes and the groups. An example of the format of the CSV file:
Mailbox,Group
Postmaster,”Postmaster Admins”
Information,Marketing_group
SpamBox,Mailbox_Spambox_FullAccess
The header must contain Mailbox and Group, separated by a comma. Subsequent rows have to contain the name of the mailbox and the associated group. When containing spaces, ‘ or “ are required.
These scripts are free to be used, altered and distributed. I would appreciate an honorable mention and I am off course interested in any improvement made. The recursive group membership helper function was made by Steve Goodman.
Points for improvements:
- Currently all accounts are deleted, even if they are still member of the Full Access group. So a selective deletion would be more elegant (important regarding auditing, the store credential cache etc.).
- A Send on Behalf version, you cannot grant this permission to groups. (Send As permissions already work when permission is granted via groups).
Disclaimer: The information here is provided as is. Use the scripts at your own risk. I have tested and implemented these scripts in production environments, but it is possible that the scripts will not work as described in other environments.