Earlier this month, I published some notes (“Office 365 – Have You Evaluated These Exchange Online Features?“) on features within Exchange Online that deserve a bit of scrutiny.
One of these features is the “Default Role Assignment Policy” which, by its name, is assigned by default to every mailbox.
What does this policy contain?
Are there any permissions that may not align with your organization’s policies?
Below is a deeper look at this policy and some settings you might want to dig into.
What Is It?
The “Default Role Assignment Policy” is assigned to every mailbox and “grants end users the permission to set their options in Outlook on the web and perform other self-administration tasks“. You’ll find the policy in the Exchange Admin Center under “Permissions” and “User Roles”.
What Does It Allow?
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
The policy contains 13 roles for “commonly used permissions” as defined by Microsoft, all of which are enabled out of the box.
These roles are:
MyProfileInformation: This role enables individual users to modify their name.
MyDistributionGroups: This role enables individual users to create, modify and view distribution groups and modify, view, remove, and add members to distribution groups they own.
MyDistributionGroupMembership: This role enables individual users to view and modify their membership in distribution groups in an organization, provided that those distribution groups allow manipulation of group membership.
My Marketplace Apps: This role will allow users to view and modify their marketplace apps.
MyRetentionPolicies: This role enables individual users to view their retention tags and view and modify their retention tag settings and defaults.
MyTextMessaging: This role enables individual users to create, view, and modify their text messaging settings.
MyBaseOptions: This role enables individual users to view and modify the basic configuration of their own mailbox and associated settings.
My ReadWriteMailbox Apps: This role will allow users to install apps with ReadWriteMailbox permissions.
My Custom Apps: This role will allow users to view and modify their custom apps.
MyVoiceMail: This role enables individual users to view and modify their voice mail settings.
MyMailSubscriptions: This role enables individual users to view and modify their e-mail subscription settings such as message format and protocol defaults.
MyTeamMailboxes: This role enables individual users to create site mailboxes and connect them to SharePoint sites.
Evaluating the Roles
Requirements will vary by organization and some may not even be relevant in your environment.
For the “MyContactInformation” and “MyProfileInformation” roles, they will not work if you are using Directory Synchronization as any changes need to be made in the on-premises Active Directory. So it might be worthwhile to disable it just to avoid any confusion. If you’re not using Directory Synchronization, do you want users to be able to change their own name in the directory? It’s not a common operation that I see delegated out to users and is likely to cause more issues than it solves. Consider disabling these. The one exception is that “MyPersonalInformation” under “MyContactInformation” is what allows you to change your pictures via OWA. Leave that role enabled if you want to allow users to update their pictures; if you don’t, you’ll need to modify the “OwaMailboxPolicy-Default” as well and set “SetPhotoEnabled” to “$False”.
The “MyDistributionGroups” role is the one I most often recommend disabling. Do you want your users to be able to create their own distribution groups in the directory? Generally not. If you don’t disable this one, at least consider creating a “Distribution Group Naming Policy“.
“MyDistributionGroupMembership” is another role that if you’re using Directory Synchronization, it may not apply to you. Unless you’ve migrated your distribution groups to the cloud, they would need to be modified in the on-premises Active Directory. If you want to actually use this feature, you need to dig really deep into OWA. Go to “Settings” | “Mail” | “Other” and then click the link to “Go to an earlier version” and then you’ll finally be presented with the “Groups” button. Completely intuitive! Hopefully this is eventually pulled a little higher into the options menu.
The “MyRetentionPolicies” is a little confusing in that is allows users to add “Personal Tags” that are not part of their assigned Retention Policy. Not sure I understand the use case for this and would generally recommend that you disable it.
I believe that “MyMailSubscriptions” role is part of the “Connected Accounts” feature in OWA but there is very little documentation on it. The cmdlets that it includes (“New-SyncRequest” along with Get- Set- and Resume-) aren’t even documented on TechNet. This one can likely can be disabled.
The “My Marketplace Apps”, “My ReadWriteMailbox Apps” and “My Custom Apps” roles pertain to the Office Apps. I find a number of these helpful but some organizations want to restrict their users from using them.
The rest of the roles are pretty innocuous. The “MyTextMessaging” role is pretty legacy where you could setup the ability to receive a text message when you had a meeting or received an email. Limited to certain locations and providers, it’s basically pre-smartphone era and can be disabled.
Still want to know more about the roles and what specific cmdlets/parameters they allow?
You can see the cmdlets behind each role by running the following in PowerShell:
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.