Creating RBAC Role To Delegate Editing Contacts

Previously we discussed how to customise Exchange 2010 RBAC to delegate creating mail enabled contacts.  The intent of that original post was to allow for the for creation of simple mail enabled contacts that would facilitate sharing the SMTP address of a person outside the Exchange organisation.

Marc commented on that post as the provided solution did not fit his requirements which were different.  There was no intent to go and modify the details of the contact objects in the original post.  Phone number, office and location amongst others were not required.  Marc on the other hand does want these fields to be edited.  So what to do?  Time for some more RBAC fun!!!

Reviewing Initial State

Let’s assume that we are at the end state of the previous blog, all those steps were followed and the custom RBAC role of “AD-Contact-Editors” exists as documented in that post.  This would involve running the following PowerShell commands:


New-ManagementRole -Name AD-Contact-Editors -Parent "Mail Recipient Creation"

Get-ManagementRoleEntry -Identity AD-Contact-Editors\* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

Add-ManagementRoleEntry -Identity "AD-Contact-Editors\New-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors\Remove-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors\Get-Recipient"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors\Set-Recipient"

New-ManagementRoleAssignment -Role AD-Contact-Editors -User User-1

They should all be on a single line, but may wrap.

Note that the Management Role has been assigned to an individual account – please see the note below on assigning to a group for production usage. 


The AD-Contact-Editors custom management role should contain the following cmdlets:

Exchange 2010 RBAC - Management Role Entries In Custom Role AD-Contact-Editors

Opening up ECP shows that User-1, who is assigned this custom RBAC role, can Create and Delete contacts.  Note that there is no details button, thus a contact cannot be edited once created, and additionally the capability to edit other properties of the contact are not exposed.

Exchange 2010 RBAC - ECP View Of Custom Role AD-Contact-Editors

As mentioned in the other post, AD-Contact-Editors is a copy from the built in “Mail Recipient Creation” role since that was the only role which has the New-MailContact cmdlet.  However, it does not contain the Set-MailContact cmdlet, and since the cmdlet does not exist in the parent role it can never be added to the child role.  So if we want to provide the capability to run Set-MailContact then we will need to do some more delegation work in RBAC!


Set-MailContact, Where Art Thee?

As before, lets see where the Set-MailContact cmdlet lives:

Get-ManagementRole –Cmdlet Set-MailContact


Exchange 2010 RBAC - Checking To See Where Cmdlet Exists

We can see that Set-MailContact lives in three places.  In this case we want to leverage the Mail Recipients built in role, so we shall make a copy of that to work with!   For lack of imagination, this new custom role will be called:    AD-Contact-Editors-Recipients. 


Creating Custom Management Role

Lets create the role, by copying the parent role:

New-ManagementRole -Name AD-Contact-Editors-Recipients -Parent "Mail Recipients"

Exchange RBAC - Creating Custom Management Role


The Mail Recipients role contains a lot of unwanted cmdlets for this task, and since AD-Contact-Editors-Recipients is a direct copy then it too will contain the same unwanted cmdlets.  Lets flush out all cmdlets apart from Get-MailContact.

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients\* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

The above should be on one line, but may wrap.

Exchange RBAC - Removing Unnecessary Cmdlets From Custom Management Role


After pressing “A” to accept that all the cmdlets will be removed, lets check the current contents of our custom AD-Contact-Editors-Recipients role:

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients\*

Exchange RBAC - Checking Cmdlets Present In Custom Management Role

That looks good!  It only contains the Get-MailContact cmdlet – all the others were removed.  Now we can add back in the couple of cmdlets that we need by running all of these commands:

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Set-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Enable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Disable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Set-Contact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Get-Contact"

I won’t screenshot you to death, so here is just one image showing the above being added back in:

Exchange RBAC - Adding Back Reqired Cmdlets

Again, lets check to see the cmdlets contained within the Role:

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients\*

Exchange RBAC - Checking Cmdlets Present In Custom Role

Looking good!

Update 1-6-2014:  The focus of the post was on the above items, since creating the custom RBAC role is the hardest part of the process.  Initially this role was directly assigned to an end user called “User-1”, but have also added the steps so that the role assignment has also been done to a Role Group as well.  Thanks for the feedback folks!  For testing purposes individual assignment is fine, though in production usage groups will be used.  Just the same as for NTFS permission assignment….

If you want  to assign directly to an individual account, then execute the:

New-ManagementRoleAssignment -Role AD-Contact-Editors-Recipients -User User-1

Exchange RBAC - Assigning Custom Role Directly To End User


Alternatively if you want to assign to a brand new  Role Group called “AD-Contact-Editors-RG” then execute:

New-RoleGroup AD-Contact-Editors-RG -Description "Contact Creators" -Roles "AD-Contact-Editors-Recipients"


Exchange RBAC - Assigning Custom Role To A Role Group

If assigning the management Role to a group, we also need to ensure that the test account is added to the Role Group:

Add-RoleGroupMember -Identity AD-Contact-Editors-RG -Member User-1

Adding Test Account To Role Group

And then we can run Get-RoleGroupMember to verify the membership addition. 

Get-RoleGroupMember -Identity AD-Contact-Editors-RG


Moving on now to the most important part, testing!


Testing & Validation

Logging onto ECP as the test account (User-1), now shows that the details button has been enabled when looking at the contact objects:

Exchange RBAC - Able To Edit Properties Of AD Contacts Via ECP

We can edit the contact, and fill in some meaningless data!

Exchange RBAC - Editing AD Contact Via ECP

Once the changes have been saved,  AD users and computers then displays the updated fields:

Changes Submitted Via ECP Visible In AD       image

Parting Glass

Since our test user now has RBAC Role Assignments to both the AD-Contact-Editors and AD-Contact-Editors-Recipients custom roles, they are now able to create, delete and modify contact objects!  The two RBAC Role Assignments can be seen below:

Exchange Custom RBAC Role Assignments

To summarise the commands used:

New-ManagementRole -Name AD-Contact-Editors-Recipients -Parent "Mail Recipients"

Get-ManagementRoleEntry -Identity AD-Contact-Editors-Recipients\* | Where-Object {$_.Name -ne 'Get-MailContact'} | Remove-ManagementRoleEntry

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Set-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Enable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Disable-MailContact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Set-Contact"

Add-ManagementRoleEntry -Identity "AD-Contact-Editors-Recipients\Get-Contact"

New-ManagementRoleAssignment -Role AD-Contact-Editors-Recipients -User User-1


If needed we could have scoped RBAC down even further and limited the actual contact fields they were allowed to modify.  Maybe that’s a post for another day!



* – The super eagle eyed out there may notice the deliberate image issue above Smile 

Technorati Tags: ,,


Comments (9)
  1. anonymouscommenter says:

    Is there a way to have the new roles show up in ECP so i can assign members to the group or is Powershell the only option??

    BTW: This blog post and the last are great and are working as expected. Thank you for the great walkthrough.

  2. anonymouscommenter says:

    Really, these should be assigned to a Role Group and not to a user. This answers Mike’s question, and makes future administration of this Role very simple. I feel that is a missed step here.

    New-RoleGroup AD-Contact-Editors-Group -Description "Contact Creators" -Roles "AD-Contact-Editors-Recipients","AD-Contact-Editors"

  3. Jay that’s correct – yes they should. I used this role assignment on another one of the RBAC posts, with a caveat there to use a group. The intent here was not to focus on the role assignment bit since that is easier than having to create and manipulate
    custom roles. But, yes I can certainly add that.

    Mike – I didn’t get the comment notification, so sorry for not answering before. There have been some recent bumps with the blogs and that alert went into the cracks.

    I got a notification about Jay’s comment today…..


  4. anonymouscommenter says:

    I tried this and it looks good so far. But I have one problem: if I want to edit an existing address or want to add a secondary address, I receive http-error 403 access denied. The url is: …/ecp/UsersGroups/EditProxyEmailAddress.aspx

    Any idea?

  5. anonymouscommenter says:

    Hi Rhoderick,

    thanks for these Blog Series! Awesome! Works as it should on Ex13.

    However, i have two questions:

    a. can i somehow hide the "tools" Menu in ECP for the Users? I double checked my ManagementRole, and they only have Contact + Recipient CMDlets. I don’t want my users to see that tools tab.

    b. is there a way to restrict creating contacts in a specific OU? We store all contacts in some sub OU like companyou1ou2Contacts not in the Users OU.


  6. anonymouscommenter says:

    I really appreciate the post, but it still wouldn’t allow me to edit the email addresses in ECP (ECP > specific external contact > E-mail Options > missing the "Add", "Edit", and "Remove" buttons).
    I had to add the get-accepteddomain role entry to get it to work.
    thanks, jp.

  7. Steve says:

    This is GREAT thanks.
    How can we target OU’s?

  8. tijs says:

    Can this be updated to reflect Office365 / Exchange 2016?

    1. If I get the time – yes.

      The premise of the post was to illustate how to figure out the steps rather than just provide rote instructions. That should still help out even if some individual lines are updated.


Comments are closed.

Skip to main content