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

The $Roles variable now contains the following Roles:

MyTeamMailboxes
MyDistributionGroupMembership
My Marketplace Apps
MyBaseOptions
MyContactInformation
MyTextMessaging
MyVoiceMail

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

 

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

 

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*"

 

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*"

 

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.

PowerShell

 

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.

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

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.

PowerShell

 

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

 

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.

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.

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:

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”

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.

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

 

Cheers,

Rhoderick