Allow Users To Manage Distribution Groups Without Creating New Ones–Exchange 2013 Redux

In a previous Exchange 2010 post we discussed a scenario where users were delegated the capability to create Mail Enabled Contacts in Active Directory using a custom Role Based Access Control (RBAC) role.  As part of the solution, we enabled the MyDistributionGroups Role.  While this may meet the needs of most organisations, it does introduce one issue where users who are assigned such a  Role Assignment Policy can edit Distribution Groups they own but also create new ones.

How can we solve the challenge of allowing users to managed Distribution Groups that they own, but also prevent them from removing them or adding new ones?  Well, it’s a similar story to the previous blog – we will create a custom RBAC Role!  This was covered in a previous post for Exchange 2010, and this blog entry will focus upon Exchange 2013.  The process is the same, screenshots have been updated to reflect Exchange 2013.

Exchange admins are generally familiar with RBAC that relates to their administrative activities.  This is managed via Management Roles.  One thing that is a little different is that the RBAC configuration for items related to users managing their own mailbox is stored within a Role Assignment Policy.  The same terminology applies, but we need to be clear that end-user RBAC is contained within a Role Assignment Policy and administrator RBAC lives in Management Roles.  Multiple Role Assignment Policies may be present within an Exchange organisation.  A mailbox can only have a single Role Assignment Policy assigned at any given time.  You may want to have multiple Role Assignment Policies to address business requirements.  If not explicitly called out, then mailboxes will pick up the default Role Assignment Policy when created or moved from Exchange 2007 to Exchange 2010/2013.

The scenario for this post is that we want to have three levels of delegated end-user management for distribution groups.  This is typical within larger businesses.  There will be users who will edit absolutely no distribution groups.  A separate collection of users can edit the distribution groups that they own, and finally a smaller group of users who are able to edit/create/remove owned distribution groups.  If the vase majority of users fall into the first category and can edit zero distribution groups, then we can simply use the default Role Assignment Policy for that purpose.  Then as noted here, we will need to create a Role Assignment Policy to allow creation/removal of owner distribution groups.  We also need to created a third Role Assignment Policy, and that is the purpose of this post.

This scenario calls for having multiple Role Assignment Polices as each will have a different configuration.  For example you may envision the following:

  1. Default Role Assignment Policy – can edit zero Distribution Groups

  2. DG-Management Role Assignment Policy – can edit Distribution Groups owned by user, cannot create new ones.

  3. DG-Full-Management Role Assignment Policy – can edit Distribution groups owned by user, and can create new ones.

We will create the Role Assignment Policy which allows editing existing distribution groups.

This is a simple test lab with one DC, one Exchange 2013 CAS server and one Exchange 2013 mailbox server.  Just to prove that this has been working out of the gate, the lab was provisioned with Exchange 2013 RTM.  After testing completed it was upgraded to Exchange 2013 CU8 to validate behaviour.  Note that at this time Exchange 2013 RTM/CU1/CU2/CU3 are not supported, and you must be on a recent update.

Create New Role Assignment Policy

Let’s create a new Role Assignment Policy called DG-Management.  We want to mirror the existing Default Role Assignment Policy, as a mailbox can only be assigned a single Role Assignment policy and we need to ensure that the user can perform all required activities on their mailbox.  This can be customised to suit your requirements, in this example we will copy from the Default Role Assignment Policy, but this is not required.

We can write down the roles assigned to the Default Role Assignment Policy and manually add them, or alternatively we can save the Default Role Assignment Policy's roles to a PowerShell variable.  We then provide this variable as the list of roles when the new Role Assignment Policy is created.  Let’s save the Roles assigned to the variable $Roles.


$Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles


$Roles | Select Name

Saving Default Role Assignment Policy Roles To A Variable

The $Roles variable now contains the following Roles:

My Marketplace Apps

When creating the new Role Assignment Policy called DG-Management, we provide the $Roles variable which contains the saved roles.


New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles


Checking Existing Role Assignment Policy - Then Creating A New One

Create Custom Management Role

All the Management Roles that can be assigned to a Role Assignment Policy  are typically prefixed with “My” to indicate that they are for end-user RBAC.  To achieve our desired results, we need to work with the Management Role called MyDistributionGroups.

In order to stop users with this Management Role creating and deleting Distribution Groups, we need to remove the “New-DistributionGroup” and “Remove-DistributionGroup” cmdlets.  As discussed in the RBAC Primer article, the built-in RBAC roles are read only so we need to make a writable copy.  This is what we are doing with the New-ManagementRole cmdlet, note that we specify the parent role so it knows what it is copying, and this is remembered.

New-ManagementRole -Name "Edit-Existing-DG-Only"  -Parent MyDistributionGroups -Description "Can edit existing Distribution Groups only"

Update 9-11-2016  Added the -Description parameter based on comment feedback.  Upto you if you want to use it or note.

Once we have our writeable Management Role Edit-Existing-DG-Only, we can edit it to remove the New-Distributiongroup and Remove-DistributionGroup cmdlets.  The removal is done using the Remove-ManagementRoleEntry cmdlet.


Remove-ManagementRoleEntry Edit-Existing-DG-OnlyNew-Distributiongroup -Confirm:$False



Remove-ManagementRoleEntry Edit-Existing-DG-OnlyRemove-Distributiongroup -Confirm:$False


Creating Custom Management Role And Removing ManagementRoleEntries

If we now check to see what cmdlets are contained in the Edit-Existing-DG-Only Management Role, the ones we removed are no longer present.


Get-ManagementRoleEntry "Edit-Existing-DG-Only*"


Checking Management Role Contentst - Role Entries Were Successfully Removed

Note there is no New-DistributionGroup cmdlet listed.

If we compare this to the original read only Management Role, MyDistributiongroups, we can see that the New-DistributionGroup and Remove-DistributionGroup cmdlets remain there as we are unable to remove them.  That is why we made a new Management Role, so we could edit it.

Get-ManagementRoleEntry "MyDistributionGroups*"


Contents Of The Default Management Role - MyDistributionGroups

Now that we are happy with the contents on the new Management Role, lets assign it to our new Role Assignment Policy.

Assigning New Management Role To Role Assignment Policy

To  assign this custom Management Role to our new Role Assignment Policy we can use either PowerShell or Exchange Admin Center.



New-ManagementRoleAssignment -Policy "DG-Management" -Role Edit-Existing-DG-Only


Exchange Admin Center

In EAC, navigate to the Permissions, then User Roles section.  Edit the new Role Assignment Policy called DG-Management.  Initially it should look like the below image (assuming that you did not already use PowerShell to assign the Management Role.

Assigning Management Role To Role Assignment Policy Using EAC

Select only the Edit-Existing-DG-Only Management Role.  This is the one highlighted in the image below.

Note That Only The Custom Management Role Was Selected - Edit-Existing-DG-Only

Hit save to commit the change.

Now that we have created a new Role Assignment Policy, Created a custom Management Role and assigned the custom management role it is time to test it out.

We will assign the new Role Assignment Policy to a test mailbox.

Assigning Custom Role Assignment Policy To Test Mailbox

In order to test the work we have done, the Role Assignment Policy must be assigned to a mailbox.  As mentioned above a mailbox can only have a singe Role Assignment Policy at any given time.  You can have multiple Role Assignment Policies, and assign one to a given mailbox.  You do not have to explicitly assign a Role Assignment Policy, and this is the default behaviour for a mailbox.

We can assign the Role Assignment Policy via PowerShell or Exchange Admin Center.



Set-Mailbox user-1@tailspintpys.com –RoleAssignmentPolicy DG-Management


Assigning Role Assignment Policy To Mailbox Using Set-Mailbox

Exchange Admin Center

Open up the properties of the test mailbox, and go to the Mailbox Features section.  In the Role Assignment Policy dropdown, select the DG-Management policy.

Testing & Validation

Now that user-1 has been explicitly assigned the Role Assignment Policy DG-Management, we can open up the EAC as that user and review the options presented to user-1.

When user-1 opens up the EAC, they have the below capabilities.  Note that there is no New or Delete button under “Public Groups That I Own”.  This is the red highlight box.

Testing The New Role Assignment Policy - Note There Are No Add Or Remove Buttons

Thus, they are not able to create or delete distribution groups.  The above screenshot was from the RTM build of Exchange 2013.  After upgrading the CAS and Mailbox servers in this lab to CU8 the behaviour is the same.

Upgraded to CU8 Still No Add Or Remove Buttons

When the above screenshots were taken, user-1 was not the manager of any distribution groups so the groups that I own pane was empty.  After creating a new distribution group called DG-1, and assigning user-1 as the owner, this group then appears in the groups that I own pane.  This is indicated with the red arrow below:

Created New Distribution Group - User-1 Added As Owner

Reference – Default Role Assignment Policy With MyDistributionGroups Enabled

Just as a reference to compare the screens above, let’s remind ourselves what simply adding the MyDistributionGroups Management Role to the default Role Assignment Policy looks like.  First we switch the user back to the default Role Assignment Policy, and then add


New-ManagementRoleAssignment –Policy “Default Role Assignment Policy" –Role “MyDistributionGroups”

Adding MyDistributionGroups To Default Role Assignment Policy

Logging back on to EAC, note that there is now a plus and delete icon. This is displayed as the New-Distributiongroup and Remove-DistributionGroup cmdlets are present in the MyDistributionGroups Management Role.

Note That Buttons To Add And Remove Groups Are Visible

Command Reference

All the commands used to create the DG-Management Role Assignment Policy are listed here for simplicity.  The Role Assignment Policy is called DG-Management and the custom management role is called Edit-Existing-DG-Only

$Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles

New-ManagementRole -Name "Edit-Existing-DG-Only" -Parent MyDistributionGroups

Remove-ManagementRoleEntry Edit-Existing-DG-OnlyNew-Distributiongroup
Remove-ManagementRoleEntry Edit-Existing-DG-OnlyRemove-Distributiongroup

New-ManagementRoleAssignment -Policy "DG-Management" -Role Edit-Existing-DG-Only

Set-Mailbox user-1@tailspintoys.com  -RoleAssignmentPolicy DG-Management
Get-ManagementRoleEntry Edit-Existing-DG-Only\*

Note On Assigning Role Assignment Policies

If you do not explicitly state which Role Assignment Policy should be used when creating  or moving a mailbox to Exchange 2010/2013 from Exchange 2007, Exchange will use the one marked as default.  Note it is not necessarily the one called “Default Role Assignment Policy”.  That is created by default, is the only one by default and is initially marked as default.  This can be changed to suit your needs.  Let’s say you create a custom Role Assignment Policy that you want 95% of the users to have since it’s your base standard, then you can mark the custom one as the default.  The one called default is no longer the default.  That’s all a bit zen, no?

For example:



Set-RoleAssignmentPolicy -Identity "Contoso Standard" -IsDefault:$true




Rhoderick Milne [MSFT]


  1. Rhoderick,
    I came across this very need to allow group owners to modify their groups, while not being able to create new groups or remove current groups. I have followed your example, and may I say it worked like a charm. The caveat to this is I was hoping to tighten the permissions even more. I am hoping to restrict all distribution group management to strictly membership control. Meaning allow owners to add/remove users to the group, but nothing else. No changing of the alias, displayname, delivery options, etc. In my new role "Restricted-DG-Management" in which I copied the items from the MyDistributionGroups to get the full list of Management Role Entries. I then did the following very meticulously:
    Removed... New-DistributionGroup Entry (Removed the "+" icon from OWA)
    Removed... Remove-DistributionGroup Entry (Removed the "Trash" icon from OWA)
    Removed... Set-Group Entry (Greyed some fields - but that is it, but not all)
    Removed... Set-DynamicDistributionGroup Entry (did nothing, but none of my dynamic groups will have owners so I'm removing it anyway)
    Removed... Set-DistributionGroup Entry. This is where it all went down hill. I no longer had ANY visibility of the "Groups I Own" at all within OWA so that I could edit them. I now only have the "Distribution Groups I Belong To" section. I can easily back out of this by removing the new role and what not, but that isn't my "concern".

    For each management role entry I removed, I noted the cmdlet parameters that was associated.

    As it stands, not being able to modify membership via OWA but strictly through Outlook isn't the "worst" solution, but I was just wondering if what I am trying to achieve is even possible.

    Can we use RBAC to restrict group management to just group membership? I do NOT want users to be able to change email addresses, names, alias or anything other than who is in the group.

    Using Exchange 2016. I appreciate your time.

    • But this is totally possible, guys!
      Just remove the specific Parameters from the specific ManagementRoleEntry, eg.:

      Set-ManagementRoleEntry MyDistributionGroupsEditMembersOnly\Set-DistributionGroup -Parameters "Alias" -RemoveParameter

      ...will remove the availability of "Alias" parameter and in most cases will gray out the related edit field in GUI (DisplayName being so far the only one not being grayed out; still throws an error when you click "Save").

  2. I've run into the same issue...currently have an open ticket with Microsoft about it but I'm not optimistic about a solution!

    • Yea I am not optimistic either. It seems a very particular/specific set of permissions that I could see as a very real request, but maybe not one so largely practiced that MS has invested any time into it. I would love to hear how it goes for you.

      For reference, these are the permissions that remain on my new custom management role, unfortunately it seems like the permissions can't be accessed/utilized in OWA because the Set-DistributionGroup entry was removed.


      • As predicted Microsoft's answer was "It's behaving as designed." So for some reason they think it's reasonable that an owner should also be able to edit all the properties of a DG as well as the membership!

        I've been spending some time trying to find a third party application that provides a friendly web interface to do this while limiting the permissions of the owner. Unfortunately the only one I've found designed specifically for this is being sold by a company that isn't responding to my requests for a demo. All others are part of a larger identity management solution as a value add.

        • Thanks for the update Jay. It is quite frustrating, but as you said, it is a predicted response. 🙁 I also have done some research on how this could be doable, and also found it to be bundled in ID management products - more unfortunate news as we won't be going that route. Thanks again!

  3. I’ve been spending some time trying to find a third party application that provides a friendly web interface to do this while limiting the permissions of the owner.

Leave a Reply

Your email address will not be published. Required fields are marked *