Managing folder-level permissions for Office 365 Groups

In a recent article, we discussed some recent improvements for managing Office 365 Groups mailboxes via PowerShell. Now, we will focus specifically on the management of folder-level permissions, but first, some history.

Back when Office 365 Group first launched, the corresponding group mailbox was exposed to most of the mailbox-related PowerShell cmdlets and we were able to perform actions such as delegating permissions, changing attributes or even use the Search-Mailbox cmdlet. Later on, Microsoft removed this functionality and introduced the *-UnifiedGroup cmdlets, which covered only a limited subset of the available operations. Some cmdlets were then updated to support a –GroupMailbox switch, making them usable against Groups, most notably the Get-MailboxFolderPermission cmdlet. It took Microsoft several more years before actions other than viewing folder-level permissions become supported for Groups, and now we finally have them working, as detailed in the above article.

So how do we go about managing folder-level permissions for Groups then? As already mentioned, we have been able to report on the permissions for a while now, thanks to the Get-MailboxFolderPermission cmdlet. To represent the permissions given to owners and members respectively, two new principals were introduced, owner@local and member@local respectively:

Get-MailboxFolderPermission GroupName -GroupMailbox

FolderName           User                 AccessRights                                                                   SharingPermissionFlags
----------           ----                 ------------                                                                   ----------------------
Top of Informatio... Default              {None}
Top of Informatio... Anonymous            {None}
Top of Informatio... Member@local         {Author}
Top of Informatio... Owner@local          {ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, DeleteAllItems, …

Well, technically those are not actual security principals but are being recognized as the External type:

 (Get-MailboxFolderPermission default -GroupMailbox -User "member@local").User

UserType ADRecipient DisplayName
-------- ----------- -----------
External             Member@local

Regardless of the type, the corresponding entries represent the list of owners or members of the Office 365 Group respectively, and are in fact utilized to grant them permissions. In the example above, you can see the default set of permissions for every folder in the Group mailbox sans the Calendar one. Namely, all members get Author permissions, meaning they can create new items, but can only edit and delete items they’ve created. Owners get a broader set of permissions, which includes: ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, DeleteAllItems, FolderVisible. Interestingly enough, they don’t have the EditAllItems permission, and also lack the CreateSubfolders one. This makes sense, as clients do not expose folders of the Group mailbox other than the Inbox, and also never show any subfolders. And it also explains why they aren’t given Owner permissions.

The Calendar folder gets its own set of permissions, governed by the value of the CalendarMemberReadOnly parameter. In the default configuration, CalendarMemberReadOnly is set to $false, even though the cmdlet output doesn’t show the value. This in turn means that Members get the exact same access to the Calendar folder as Owners, in other words everyone has Editor permissions. Toggling the value of CalendarMemberReadOnly to $true reconfigures the permissions so that Members now only get Reviewer access, in other words they can no longer create or edit meetings. This is all illustrated on the screenshot below:

Another way to change the permissions is now supported, via the corresponding *-MailboxFolderPermission PowerShell cmdlets. For example, if you want to grant permissions to specific folder, you can use:

Add-MailboxFolderPermission default -User vasil -AccessRights Owner -GroupMailbox

FolderName           User                 AccessRights
----------           ----                 ------------
Top of Informatio... Vasil Michev         {Owner}

To remove any permission entry, use Remove-MailboxFolderPermission cmdlet. Interestingly, the Set-MailboxFolderPermission does not support the –GroupMailbox switch, meaning we cannot directly edit permissions. We can however remove them, then add the new entry. This includes the member/owner permissions as well, as illustrated in the next example:

An unfortunate side effect of this limitation of the Set-MailboxFolderPermission cmdlet is the fact that we cannot change the “Default” or “Anonymous” permission levels, as those cannot be removed via the Remove-MailboxFolderPermission cmdlet.

It is important to understand that not all clients might work with custom permissions, as they simply might lack the necessary code to handle them. In my test, OWA correctly recognized the fact that a member of the group was now given Editor permissions to the Inbox folder, and allowed them to remove any item found there. The same behavior was observed in the Outlook app on Android. However, there were some reports over at the MTC that the iOS Outlook app didn’t respect the permissions, which I wasn’t able to confirm as an Android user.

Another important remark is that even though you can set permissions on any folder or subfolder, clients will still not show them unless you use some workaround akin to the “open Group as shared mailbox in OWA” one. So in most situations the information presented above is of purely academic value 🙂