Allow Users To Manage Distribution Groups Without Creating New Ones

In a previous post we discussed a scenario where users were delegated the capability to create Mail Enabled Contacts in Active Directory using a custom 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.

This post is based on Exchange 2010.  If you would prefer an Exchange 2013 specific post, please view this entry

Update 20-1-2014: Corrected PowerShell code to add a missing bracket in $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

Update 1-6-2015: Link to an Exchange 2013 specific version of this post was added. 

How can we solve the challenge of allowing users to managed Distribution Groups that they own, but also prevent them from removing or adding new ones?  Well, it’s a similar story to the previous blog – we will create a custom RBAC Role!

One thing that is a little different is that the RBAC configuration for the items related to configuring your 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.


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 option #2 in this blog.  Option1 is the initial setup with the Default Role Assignment Policy, and Option3 can be done by following the steps in the previous blog to simply enable the MyDistributionGroups Role in the relevant Role Assignment Policy.

Let’s get jiggy with it, and create a new Role Assignment Policy!  **


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  roles to a variable.  We can 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 will then contain the following Roles:



Save RBAC Roles To Variable

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


Creating New Role Assignment Policy - Roles Are Provided In Variable $Roles


Create Custom Management Role

All the Management Roles that can be assigned to a Role Assignment Policy  are prefixed with “My” to indicate that they are for user RBAC.  This is a list of the Exchange 2010 roles starting with the prefix “My”:

Exchange 2010 End User RBAC Roles

The Management Role Entries for MyDistributionGroups is shown below along with showing that this is a built-in role and is intended for end user purposes.

MyDistributionGroups Role Contents And Properties

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 before, the built-in RBAC roles are read only so we need to make a writable copy.

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


Create New Management Role Based From MyDistributionGroups

Then removing the new and remove distribution group cmdlets:

Remove-ManagementRoleEntry Edit-Existing-DG-Only\New-Distributiongroup

Remove-ManagementRoleEntry Edit-Existing-DG-Only\Remove-Distributiongroup


Checking to see the current Management Role Entries, note the New and Remove cmdlets are gone:

Contents Of Custom Management Role - With No Remove & New Distribution Group Cmdlets

Once happy, will assign this custom Role to our new Role Assignment Policy.

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

New Management Role Assignment To Assign Custom Role

Note that we can do most RBAC work in ECP after Exchange 2010 SP1, though I still prefer PowerShell as that was what I had to learn initially.  Old dog, new tricks etc…..


Custom RBAC Role Visible in Exchange Control Panel


Testing & Validation

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.  If you do not explicitly state which one should be used when creating  or moving a mailbox to Exchange 2010, Exchange will use the one marked as default.  Note it is not necessarily the one called “Default Role Assignment Policy”;  that one 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 Role Assignment Policy that you want 95% of the users to have as it’s your base standard then you can mark it as the default.


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

Marking Role Assignment Policy As Default

Viewing all of the Role Assignment Policies shows Contoso Standard is the default.  Mailboxes created will now leverage the Contoso Standard Role Assignment Policy unless explicitly stated otherwise.  Mailboxes created prior to this point will continue to use their existing Role Assignment Policy and will not automagically change to this new default policy.

Showing Which Role Assignment Policy Is Default

Let’s set our test mailbox (user-20) to explicitly use the DG-Management Role Assignment Policy


Set-Mailbox -Identity user-20 -RoleAssignmentPolicy DG-Management

When user-20 then opens up ECP, they have the following capabilities, note that there is no New or Delete button under “Public Groups That I Own”.


Exchange 2010 ECP With Restricted Group Management Capabilities

For a Distribution Group to show up, it must have the ManagedBy attribute set.  In this test org there are several DGs, but only the ones that user-20 has ManagedBy appear.

Listing Of Distribution Groups Showing ManagedBy Attribute



We can see that the basic steps to tune and customise RBAC are very similar to the previous blog on delegating Mail Enabled Contact creation.  There are some differences as we are creating a custom Management Role to be used as part of a Role Assignment Policy though all the concepts still apply.




** – Forget the music and stuff Will Smith, where is Independence Day 2 anyway ?!?!?

Comments (30)
  1. Hi. Thanks for a good explanation on what, how and why.

    Its almost the same as this blog from 2009, which I have used a lot.…/3408844.aspx



  2. Hi Steen,

    You're correct that it is similar, but I wanted to take the concepts and expand some aspects.  The other reason that I have this here is when I teach Exchange workshops to Microsoft Premier customers, I can point them to a single place and I have the links to hand 🙂  



  3. anonymouscommenter says:

    hi thanks for the article.

    I have a question. I want to delegate to poeople Group ownership, but I dont want they can adding vip person to this groups. How can I provide adding someone to an Distribution Group even by Group Manager

  4. UTG – I don't think that you will be able to block this unless you use a different product like FIM (though that needs to get validated) as Exchange RBAC does not restrict the recipient read scope.  

    Even if you place an Exclusive scope around the VIP OU, I doubt that it will prevent other DG managers from adding VIP users to their groups.



  5. anonymouscommenter says:


    according to your blogpost I've managed to accomplish this behaviour, but I ran into issue with editing groups. If I try to edit group that is hidden from GAL, OWA shows error "The operation couldn't be performed because object 'be94dda3-7bb3-4a28-9fbe-ef6e6f503d76' couldn't be found on 'dc1.test.local'." If I unhide that group, managing starts working. May I ask you for any advice how to manage even hidden groups this way?



  6. Hi Vladimir,

    Back after Christmas holidays!

    Is this still something you are interested in working on? I can’t honestly remember if I ever tried to do this with a hidden group (probably not though).


  7. anonymouscommenter says:

    When I run the command New-RoleAssignmentPolicy -Name DG-Management -Roles $Roles, I get this error: The “MyDistributionGroupMembership-Default Role Assignment Policy” management role can’t be found.

    Any thoughts?

    Thanks for the article.

  8. Hi Guy,

    If you run $Roles what is returned at that point please? Do you get a listing of Roles?


  9. anonymouscommenter says:

    Hi Rhoderick, Yes, I get the listing of roles.

  10. Hi Guy, I went back to my lab on this. That code above is not right.

    If you run
    Get-RoleAssignmentPolicy (“Default Role Assignment Policy”).RoleAssignments | Select identity

    That returns the RoleAssignemntPolicies – not the individual roles — which is what we want.

    I’ll go back to my other machine later and see what I was playing at!

    In the meantime try this please.

    $managementRole = Get-RoleAssignmentPolicy (“Default Role Assignment Policy”)

    $Roles = $managementRole.AssignedRoles

    if you then echo out $Roles, you should see this:


    Then you should be able to use $Roles as the -Roles parameter in the New-RoleAssignment command.


  11. And I see formatting is now lost 🙁 let me retry that….

  12. Bah – not working with IE11, IE10 or Firefox. I’ll file this as an issue on the internal blog support site then…..

  13. Went back a looked at this – there is a missing bracket in the original command, and that is messing it up – sorry!

    Compare this

    $Roles = (Get-RoleAssignmentPolicy “Default Role Assignment Policy”).AssignedRoles


    $Roles = Get-RoleAssignmentPolicy “Default Role Assignment Policy”).RoleAssignments

    Let’s see if this posts properly and preserves formatting…..


  14. anonymouscommenter says:

    After publishing some recent articles on RBAC, there was some feedback that a primer on RBAC would also

  15. anonymouscommenter says:

    Hi, when I enter New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles, I’ve got the respponse: “New-RoleAssignmentPolicy : A parameter cannot be found that matches parameter name ‘Roles’.” I need to allow some users to manage a membership for two or three groups. thanks for your answer.

  16. anonymouscommenter says:

    P.S. – I tried it after entering $Roles = (Get-RoleAssignmentPolicy -Identity “Default Role Assignment Policy”).AssignedRoles, but $Roles is empty

  17. anonymouscommenter says:

    It looks as “Default Role Assignment Policy” has no AssignedRoles

  18. I’m onsite with customers right now, but will try and repro this in a vanilla lab later this week.


  19. anonymouscommenter says:

    I believe that this applies to E2013 too.
    Looking at the default roles, the "MyDistributionGroupMembership" role already exists by default, which allows addingremoving members, so why is it necessary to create a Sub Role of "MyDistributionGroups" called "Edit DG" or in other examples "MyDistributionGroupsManagement"
    and then edit the role entries for create and remove groups themselves.
    Shouldn’t the "MyDistributionGroupMembership" role apply and be sufficient as it is selected by default.
    All rather confusing.

  20. Hi Rob, thanks for the nudge on Twitter. I sometimes miss or don’t get the updates for comments.

    It’s late here, but let me take a stab at answering.

    Take a peek at

    Get-ManagementRole mydistributiongroupmembership | FL Name, Description, *SCOPE*

    Note that the recipient write scope is: ImplicitRecipientWriteScope : MyGAL

    and in the description"

    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.

    I added the ** highlighting. Yes — this allows a user to manage what they are a member of, though the scenario above is where a person is adding and removing others from the particular DG. Not just themselves.

    Does that match what you see when testing?


  21. anonymouscommenter says:

    You are the best – this is exactly what I was looking for and it worked great!

  22. Groovy! Glad that worked out 🙂


  23. anonymouscommenter says:

    A quick note: as shown this gives list owners rights to rename groups and change their email aliases. You can remove these specific rights like this:

    Set-ManagementRoleEntry "Edit-Existing-DG-OnlySet-Group" -Parameters DisplayName, Name, WindowsEmailAddress -RemoveParameter
    Set-ManagementRoleEntry "Edit-Existing-DG-OnlySet-DistributionGroup" -Parameters Alias, DisplayName, EmailAddresses, Name, SamAccountName, SimpleDisplayName, WindowsEmailAddress –RemoveParameter

  24. anonymouscommenter says:

    Thank you! Used this in Exchange Online.

  25. anonymouscommenter says:

    I’ve tried this a few times, and am unable to get it to work in on-premises 2013. I copied and pasted every command, and verified every one, but when the user logs in, the "distribution groups I own" list is empty. I confirmed that at least one group has
    my test user listed in the "ManagedBy" attribute too. It only works if I add the user to either an admin role with the "Distribution Groups" role, but I don’t want the user to be able to add new groups.

  26. anonymouscommenter says:

    This is what I did and I still do not have the ability to manage the DL. I confirmed that my account is an admin of a DL named ‘careers’ but I do not see any option to edit the membership in OWA when i search for groups.

    #This script will enable the ability for any user who is an owner of a DL to edit the memebership.
    $Roles = (Get-RoleAssignmentPolicy -Identity "Default Role Assignment Policy").AssignedRoles

    #This creates a new policy named DG_Management
    New-RoleAssignmentPolicy –Name DG-Management –Roles $Roles

    #This creates a management role which will only allow the user to edit an existing and remocves the ability to create new or delete
    New-ManagementRole -Name "Edit-Existing-DG-Only" -Parent MyDistributionGroups
    Remove-ManagementRoleEntry Edit-Existing-DG-OnlyNew-Distributiongroup
    Remove-ManagementRoleEntry Edit-Existing-DG-OnlyRemove-Distributiongroup

    #Run this command to check your work
    #Get-ManagementRoleEntry Edit-Existing-DG-Only*

    #This creates a new policy named "DG Management" and assigns the Edit permission that you created above
    New-ManagementRoleAssignment -Policy "DG-Management" -Role Edit-Existing-DG-Only

    #This assigns a user to the new policy
    Set-Mailbox -Identity -RoleAssignmentPolicy DG-Management

  27. anonymouscommenter says:

    In a previous Exchange 2010 post we discussed a scenario where users were delegated the capability to

  28. Very good post!!! Very usefull now a days!!

Comments are closed.

Skip to main content