Creating RBAC Role To Delegate Contact Management

Update 21-11-2013: If you want the additional contact fields to be edited then please review this post

I had an interesting question the other week about solving a business challenge a customer had with regards to delegating the creation of contact objects in Active Directory.  In their previous messaging system users were managing their own external distribution groups, adding and removing external people, and they wanted to do the same in Exchange 2010.

A default Exchange 2010 installation does not grant these capabilities by default, so we have to do a little configuration.  Role Based Access Control (RBAC) was introduced by Microsoft in Exchange 2010 and is used to control access to the messaging environment.

I thought that this would be worth sharing so that the solution is published and the logic of creating the custom RBAC role is discussed.


Building Blocks

We will need to permit:

  • Management of Distribution Groups in Active Directory
  • Creation and management of Mail Enabled Contacts in Active Directory
  • Management toolset to manage the above

Management of Distribution Groups

Exchange 2010 does not allow a user to manage groups that they own by default.  All of the necessary plumbing is present, you just have to enable the feature.  This is explained in detail here.  Couple of things to note:

  • Groups cannot manage groups in Exchange 2010, this feature has returned in Exchange 2013 CU1. There is a workaround for Exchange 2010
  • Make sure the mailboxes and the DGs are in the same GAL

As noted above to manage groups that they own, assign MyDistributionGroups to the appropriate Role Assignment Policy.  In the below example the Default Role Assignment Policy was changed to enable this.  Note that this will allow users to also create new Distribution Groups, so I’ll cover that in a separate blog.  Also you may not want to change the Default Role Assignment Policy in your environment.  You can have multiple Role Assignment Policies and different groups of mailboxes can have a Role Assignment Policy that maps to their business needs.

Exchange 2010 Default Role Assignment Policy Edited To Enable MyDistributionGroups

Well that’s the easy part done !

So let’s create a RBAC Role, and for the purposes of this test do a direct role assignment to one user account, though this can easily be a group and would be the recommended methodology.

Creation & Management of Mail Enabled Contacts in Active Directory

End users cannot create contacts in AD by default, but we can change the default RBAC to allow this.  The trick is to assign just the minimum permissions possible.  RBAC is aware of the permissions that have been assigned to a person, and will change the display to reflect the assigned permissions.  If you do not have access to do something, then you will not see that option.

Where to start?  We need to know which role contains the cmdlet that we want to leverage.  In this case we want the New-MailContact cmdlet, and to see in which roles it is present we can use Get-ManagementRole and the –Cmdlet parameter

Get-ManagementRole -Cmdlet New-MailContact

Exchange 2010 RBAC - Checking Which Role(s) Contain Necessary cmdlet

We can see that the Mail Recipient Creation contains the cmdlet that we need.  It also contains a bunch of other cmdlets that would grant too many capabilities.  A full listing is shown below for reference.

Get-ManagementRoleEntry –Identity “Mail Recipient Creation\*”

Exchange 2010 RBAC - Management Role Entries Contained in Mail Recipient Creation Management Role

The built-in roles are read only and cannot be changed, so we cannot remove any cmdlets from them.  What we can, and will do, is to create a writable copy and make the necessary changes to our copied Management Role. 


To create a new role called AD-Contact-Editors based off the built-in “Mail Recipient Creation”

New-ManagementRole –Name AD-Contact-Editors –Parent “Mail Recipient Creation”

Exchange 2010 RBAC -  Creating New Management Role

Right now, our newly created AD-Contact-Editors role is a mirror copy of the original parent role.  Thus it has all the cmdlets and parameters the parent has.  Now we need to strip all of the unwanted cmdlets from our new role. Ultimately we want to leave in the bare minimum.  

You could strip each cmdlet out one at a time.  For this exercise it will be easier to remove all but one and then add a couple back in.  We cannot remove all of the role entries, which is why we leave one behind.  Let’s leave just Get-MailContact in the role.  To remove the role entries, we shall pass the unwanted cmdlets through to Remove-ManagementRoleEntry.  So all cmdlets that are not Get-MailContact will be removed.

Exchange 2010 RBAC -  Removing Unwanted Management Role Entries

Top Tip:

Always check the objects that are returned prior to piping to the remove cmdlet.

So in this case we would run

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

Only when we are happy with what is returned should we run:

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

If we check to see what’s now in the AD-Contact-Editors Management Role, it only contains the Get-MailContact cmdlet.

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

Exchange 2010 RBAC -  Checking Current Management Role Entries

Let’s add back New-MailContact using New-ManagementRoleEntry

Add-ManagementRoleEntry –Identity “AD-Contact-Editors\New-MailContact”

Exchange 2010 RBAC -  Adding Required Management Role Entries Back In

If we try and test this in ECP, we only have the capabilities to manage ourselves at this point so we need to add a couple more cmdlets back in.  We need to add

  • Remove-MailContact
  • Get-Recipient
  • Set-Recipient

Add-ManagementRoleEntry –Identity “AD-Contact-Editors\Remove-MailContact”

Add-ManagementRoleEntry –Identity “AD-Contact-Editors\Get-Recipient”


This should give you a management role that looks like this:

Get-ManagementRoleEntry “AD-Contact-Editors”

Exchange 2010 RBAC -  Checking Required Management Role Entries

In case you are wondering why we have not added Set-MailContact to our custom role, there is a very good reason.  Custom Management Roles can only contain cmdlets and parameters that exist in their parent role.  If you check out the original contents of the custom role there is no Set-MailContact cmdlet in it, thus we can never add it to this role.  

Assign the new role to a user.  User-10 will our fluffy and cute guinea pig.

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

Exchange 2010 RBAC -  Assigning Custom Management Role Directly To Mailbox

To check that the Management Role was correctly assigned, we could run:

Get-ManagementRoleAssignment -Role AD-Contact-Editors

Time to test!

Testing & Validation

Probably the most important portion is testing and validation, and is often overlooked.

Test, test and test like you mean it Smile

You can allow your end users to use PowerShell to manage create and edit the contacts, though I suspect the admin assistant that wants to use PowerShell will be few and far between….

Chances are they will like the nice graphical ECP interface, so let’s focus on that.


Bellow is what our test user (user-10) sees in ECP.  Note this is the manage my org view.  All they can see is the External Contacts tab.

Exchange 2010 ECP Showing User Editing Contacts

In their Groups ECP view they see:

Exchange 2010 ECP Showing User Editing Groups

And they can add the contacts to the DG

Exchange 2010 ECP User Editing Editing Distribution Group

Outlook also will show the correct directory information.  This is how Outlook 2010 sees the DG:

Outlook 2010 Showing Same Directory Information


RBAC in Exchange 2010 allows for a lot of great customisation to the default built-in roles.  For many customers the default roles will work fine, and if not they can be easily customised.

For the users that you grant these permissions they will be able to manage/edit/delete all the contacts in the organisation.


This blog shows the basic framework for editing and customising RBAC.  By following the same process of identifying the role you need to work with, copying it and then customising the copied role you can provide a tailored solution to meet your organisation’s needs.

This will allow for the a basic mail enabled contact to be created.  If you want the additional contact fields to be edited then please see this post.




Comments (43)
  1. says:

    Could add more points on get – windows features

  2. Hi Guowen – was this the blog you intended to comment on?  

    Get-window feature does not "feature" here at all.



  3. anonymouscommenter says:

    Dude your the man!!! This helped me alot

  4. anonymouscommenter says:

    Well after testing that I can only –

    1. I can only create a contact

    2. I cannot add a phone # to it

    3. I cannot go back to edit it

    what other permissions do I need to add to be able to do this, looks like I 'm almost there.

  5. Hi Marc,

    I'll bet that this is due to that Set-MailContact is not within the ManagementRoleEntry

    Add that badboy back in and let us know how you get on please.  That was not what the customer who asked for this originally wanted, but we should be able to accommodate your request too 🙂



  6. anonymouscommenter says:

    I tried to add it back in but I get this error –

    [PS] C:Windowssystem32>Add-ManagementRoleEntry -Identity "AD-Contact-EditorsSet-Recipient"

    The "Set-Recipient" management role entry wasn't found on the "Mail Recipient Creation" management role. Make sure you

    typed it correctly, and try again

       + CategoryInfo          : NotSpecified: (0:Int32) [Add-ManagementRoleEntry], ManagementObjectNotFoundException

       + FullyQualifiedErrorId : 3961CEC7,Microsoft.Exchange.Management.RbacTasks.AddManagementRoleEntry

  7. anonymouscommenter says:

    I tried Set-MailContact it errored out the same way

  8. Hey marc, That would be expected as it is not in the parent role, there should be a note in the above about that.  I thought you had a separate role assignment with that.  

    let me grab the exact syntax for you



  9. Marc – this post will go live tomorrow morning just after 09:00 EST…/creating-rbac-role-to-delegate-editing-contacts.aspx

    Try that out and let me know how you get on please!



  10. Marc – did that work for you?

  11. anonymouscommenter says:

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

  12. anonymouscommenter says:

    Hi, any chance the user can modify the contact? he can add or delete, but not modify.

  13. anonymouscommenter says:

    thanks, it worked

  14. Groovy!

    Do let me know if there are other good RBAC scenarios that you need covered.


  15. anonymouscommenter says:

    Hi Rhoderick,

    Must say nice blog… but I do have a different scenario here. I want to create a RBAC role for a set of users where they should have permissions to run cmdlets but only for specific cmdlets. For example if I say they should be able to run 2-3 specific cmdlets
    through EMS to do the changes. Is there any way to configure RBAC where we can allow specific cmdlets and restrict others. Please suggest.

    Thanks in advance!!!!


  16. Hi Abi,

    That’s pretty much the point of RBAC and how it works. You only see the cmdlets (and the parameters) that you allow to a particular role. If you do not grant other roles (which contain the cmdlets) then they are not visible/usable and are implicitly unavailable.
    There is no need to do an explicit block of them.

    Please look at the tag cloud on the right, and peruse the RBAC tagged posts.


  17. anonymouscommenter says:

    Hi Rhoderick,

    i would like to know the answer for the same query as Abi. Can you please suggest that.
    Thank you

  18. anonymouscommenter says:

    Is there a way where i can specify 3-4 role entries for a newly created role and remove the rest.
    Thanx in advance 🙂

  19. Hi Deep – it may be easier to remove all but one and then add the others back OR you can remove them one at a time. Depending upon the role you are modifying one may be quicker than the other.

    To do this look for the Remove-ManagementRoleEntry items in here

    You can take the cmdlet out totally, or just some parameters in the cmdlet. Its up to you 🙂


  20. anonymouscommenter says:

    Hi Rhoderick,

    Thanks for grate post.
    I have multi OUs and I want to delegate administrator rights to IT users in these OUs ONLY. The problem is when Mail Recipients or Mail Recipient Creation granted to those users, they can see ALL recipients. Is there any way to restrict even viewing for their
    respective OUs?

    Thanks in advance

  21. Hey Gen,

    You cannot restrict the view scope for either configuration or recipient scopes.

    Out of curiosity Is this causing an issue ?


  22. anonymouscommenter says:

    thanks ….

    Top management requirement that each geographically OU has its own administrator, and no administrator can see other OU recipients. Although no one can change anything, but they need it this way


  23. Ah,

    Can I ask why they want this? What is the business driver please?


  24. anonymouscommenter says:

    Hey Rhoderick, after following these instruction I have found that I am currently able to add and remove contacts (only those not hidden) from distribution groups as well as create contacts. However, I cannot create distribution groups and cannot see hidden
    contacts in general. Any suggestions as to what I may have done wrong or why I am unable to do this?

  25. Hi Kat – I do not belive that the ability to manipulate hidden objects is allowed.

    Have seen similar things when end users try to manage groups that were hidden, or were outside of their ABP.

    To enable the creation of distribution groups, did you also follow the steps in that separate blog post please?


  26. anonymouscommenter says:

    Hello, thank you for your very interesting post… I have a problem because I want to allow some users to create Mailbox contacts but only on a specific OU in my Active Directory.
    Do you know how I can do it ? I tried to put the right only on this specific OU to my test user but when he tries to create a new Mailcontact the Mailcontact is created in the default "Users" OU. I did not put any right to this OU to this user… Do you know
    how to change this ? My other problem is that if I cannot do the way I am willing then my users will be able to delete contacts of another departments. (Because the idea it to put every contacts of every department in specific OU…)

    Thank you for your help.


  27. anonymouscommenter says:

    Great job and well written

  28. anonymouscommenter says:

    Your blog post provides exactly the solution I was looking for. Unfortunately when trying this with our office365 account, the Remove-ManagementRoleEntry step throws an error:

    Cannot process argument transformation on parameter ‘Identity’. Cannot convert value "AD-Contact-Editors" to type

    However the get-managementroleentry command works as expected. Have I missed something, being quite new to the field?

    Best Regards

  29. anonymouscommenter says:

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

  30. anonymouscommenter says:

    Hi Roderick,

    Great blog! I was hoping going through this would allow my user to create a new contact, they are able to create an External contact but there’s not option to create just a contact.



  31. Hi Mr/Mrs Zombie!

    Are you looking for them to use New-Contact as opposed to new-MailContact ?


  32. anonymouscommenter says:

    Hi Rhoderick,
    Just wanted to leave a note to say a huge thank you for your blog posts on this . I’d not used Exchange Management Shell for much before but this made it easy to do exactly what I wanted.

  33. anonymouscommenter says:

    Hi, excellent guide.

    I want new contacts to end on a specific OU and not on the default Users folder. How can I accomplish this? I tried to setup a Admin Role through the ECP and assign an specific OU but gives me an error message saying that I can’t write to the Users folder.

  34. Thanks Louise! Great to hear 🙂

  35. Hi Joe,

    I don’t believe that functionality exists for contact placement. We can set a default OU for distribution group creation, but do not believe it applies to contacts.

    You would need to create a scope to the OU where the contacts are to be created, and use that when making the assignment. Users still need to manually choose the correct OU.

    FIM and 3rd party tools may light up more options for you here.


  36. Steve says:

    Exchange 2016
    hello, this worked great thank you!
    I created and Delegated an OU to a user with Full control on Contacts.
    I’d like them to create contacts in that new OU.
    As my test user when I try to create a new contact it just spins and spins in the “select an organizational unit”
    “You don’t have permission to open this page. If you’re a new user or were recently assigned credentials, please wait 15 minutes and try again.”
    I followed your instructions to the letter.
    Note: I can browse the OU containers normally with my other admin accounts.

    1. Hi Steve,

      How was this bit here done please?

      “I created and Delegated an OU to a user with Full control on Contacts.”


  37. Liam Evans says:

    Hello, this post is helpful, however the change has removed all other options from the ECP only the recipients and tools options are available. How do I restore them?

    1. Hi Liam,

      If you followed the post then this creates a new RBAC role specific to this purpose. Yes it has minimal options, so you then need to add back the required roles to gain access to the required cmdlets. That will then light up the relevant area(s) in ECP.


      1. Liam Evans says:

        Thank you for this information, I have tried to run the commands but cannot find one that works. Are you able to give me a sample command? For example, I want to add back the role that enables the user to edit DG groups only (not add new ones).

Comments are closed.

Skip to main content