I recently received a request for specific users to be able to modify users and contact information for the HR department.

I immediately thought of Exchange Role Based Access Control. Personally, I think this is one of the best features of Microsoft Exchange 2010, but that’s another story.

In short, RBAC ensures that end-users only have the minimum permission required to perform a task. With RBAC, I could create a custom Role, Role assignment,Role group and edit Role entries that’ll enable end-users carry out only specific tasks. I like to see the idea of Roles in Exchange 2010 RBAC as a set of tasks that can be carried out with one or more Role entries(Cmdlets). The Roles(Task-set) are assigned or mapped to a Role Group(Exchange-specific security group) to enable the group members(users) perform those tasks. Let’s dive in.

I did a little research and determined that the default ‘Recipient Management’ security group had all the necessary permissions to perform the delegated tasks. But the Roles assigned to this group have way too much permission for the intended objective. I needed to limit the end-user tasks to just changing and updating Users/Contact information.

I started by creating a new Role Group:

1) New-RoleGroup -Name “Address Book Management” -Description “Custom Role Group for Address Book Management Users” -Members JaneDoe, JohnDoe

After determining the relevant parent role, the following cmdlet enabled me create a new custom role:

2) New-ManagementRole -Name “Address Book Management” -Description “Custom Role of Parent Type Mail Recipients for Address Book Management Tasks” -Parent “Mail Recipients” -Verbose

The next command let me assign the new custom role to the newly created role group:

3) New-ManagementRoleAssignment -Name “Address Book Management-Address Book Management” -SecurityGroup “Address Book Management” -Role
“Address Book Management” -Verbose (I like to use the verbose parameter to follow the command execution process)

Since the new role is a child of the parent Mail Recipient role, it should have all the RoleManagementEntries (cmdlets) that enable the role group members perform the Mail Recipient role tasks. The following command gave me a list of all cmdlets available to the “Address Book Management Role”:

4) Get-ManagementRoleEntry -Identity “Address Book Management\*” | more ( The ‘more’ command simply allows me to page through the long list of cmdlets returned).

Going through the list, I find that there are a number of disable-, enable-, remove- cmdlets, that I would prefer the delegated end-users not have access to. I’ll remove the entries(cmdlets) with the following commands:

5) Get-ManagementRoleEntry -Identity “Address Book Management\*” | ?{$_.Name -like “*enable-*”} | Remove-ManagementRoleEntry ( These cmdlets return a filtered list of cmdlets with the enable- verb and pipes them to the Remove-ManagementRoleEntry cmdlet for removal).

I’ll run the same commands for the disable- and remove- verbs:

6) Get-ManagementRoleEntry -Identity “Address Book Management\*” | ?{$_.Name -like “*disable-*”} | remove-managementroleentry

7) C:\>Get-ManagementRoleEntry -Identity “Address Book Management\*” | ?{$_.Name -like “*remove-*”} | Remove-ManagementRoleEntry

I could also combine all three filters into one line of code and pipe the result to the Remove-ManagementRoleEntry cmdlet as such:

8) C:\>Get-ManagementRoleEntry -Identity “Address Book Management\*” | ?{($_.Name -like ‘*remove-*’) -or ($_.Name -like ‘*disable-*’) -or ($_.Name -like ‘*enable-*’)} | Remove-ManagementRoleEntry

At this point, I pretty much have all the cmdlets needed for the Users Support staff to safely perform address book modification tasks without deleting or disabling any users or contacts.

To test the new role group and role permissions, I asked the support staff to open a web browser, login to their outlook webmail and navigate to the top right corner for the Options button:See All Options: Manage My Organization. They are presented with a listing of Organization users and contacts and could select and make intended changes as needed.

I find that the support staff members of the new role group, can edit contact details without disabling or removing any users.