Exchange Server uses a permissions model called Role Based Access Control (RBAC) to manage the delegation of permissions for Exchange administrative tasks. RBAC was first introduced in Exchange 2010 and continues to be used in Exchange Server and Exchange Online today. It’s important to understand how RBAC works because it is the mechanism that you use to apply a least-privilege approach to Exchange administrative permissions. RBAC is also how end users are granted permissions to perform tasks such as managing their own distribution groups.

In this tutorial we’ll look at:

  • How RBAC works by examining the pre-defined RBAC management roles
  • How to configure custom management roles

The Basics of Role Based Access Control

Whether you understand the inner workings of RBAC or not, you’re still making use of it every day when you perform Exchange administrative tasks. That’s because RBAC has a series of pre-defined management role groups, management roles, and management role assignments for a variety of common administrative scenarios.

Management role groups are the security groups in Active Directory. You can see the management role groups that Exchange creates during setup in the Microsoft Exchange Security Groups OU in Active Directory.


Some of those groups should already look familiar to you, such as Organization Management and Recipient Management. Some of the groups in that OU are for other purposes, such as the Exchange Trusted Subsystem group which contains computer accounts for Exchange servers. So if you want to see just the role groups, you can switch to the Exchange Management Shell instead and run the Get-RoleGroup cmdlet.

[PS] C:\>Get-RoleGroup

Name                          AssignedRoles                 RoleAssignments
----                          -------------                 ---------------
Organization Management       {MyDiagnostics, MyContactI... {MyDiagnostics-Organizatio...
Public Folder Management      {Public Folders, Mail Enab... {Public Folders-Public Fol...
Recipient Management          {Move Mailboxes, Message T... {Move Mailboxes-Recipient ...
View-Only Organization Man... {View-Only Configuration, ... {View-Only Configuration-V...
UM Management                 {UM Prompts, Unified Messa... {UM Prompts-UM Management,...
Help Desk                     {User Options, View-Only R... {User Options-Help Desk, V...
Records Management            {Transport Rules, Audit Lo... {Transport Rules-Records M...
Discovery Management          {Mailbox Search, Legal Hold}  {Mailbox Search-Discovery ...
Server Management             {Monitoring, Exchange Serv... {Monitoring-Server Managem...
Delegated Setup               {View-Only Configuration}     {View-Only Configuration-D...
Hygiene Management            {ApplicationImpersonation,... {ApplicationImpersonation-...
Compliance Management         {Data Loss Prevention}        {Data Loss Prevention-Comp...

Notice how each role group has one or more assigned roles, which refer to management roles. An example of a management role is Mail Recipients.

[PS] C:\>Get-ManagementRole "Mail Recipients"

Name                                                        RoleType
----                                                        --------
Mail Recipients                                             MailRecipients

Management roles are collections of management role entries. Management role entries are specific tasks that can be performed by users who are assigned with that particular role. Continuing with the example of the Mail Recipients role, the management role entries can be summarized by looking at the description of the management role.

[PS] C:\>Get-ManagementRole "Mail Recipients" | fl Description

This role enables administrators to manage existing mailboxes, mail users, and mail contacts in an
organization. This role can't create these recipients. Use MailRecipientCreation roles to create them.
This role type doesn't enable you to  manage mail-enabled public folders or distribution groups. Use the
MailEnabledPublicFolders and DistributionGroup roles to manage these objects.
If your organization has a split permissions model where recipient creation and management are performed
by different groups, assign the MailRecipientCreation roles to the group that performs recipient
creation and the MailRecipients roles to the group that performs recipient management.

So the Mail Recipients role contains a whole bunch of role entries to make that possible. Role entries have a naming convention of “RoleEntry”, so all of the role entries for the Mail Recipients role will be named “Mail RecipientsEntry”. This means that you can see the list of role entries for the Mail Recipients role by running the following command:

[PS] C:\>Get-ManagementRoleEntry "Mail Recipients*" | Select Name

On my system there’s 125 role entries for the Mail Recipients role, so I won’t list them all here. But they basically include all the cmdlets you’d need for that purpose, such as Get-Mailbox, Set-Mailbox, and Enable-Mailbox (for mail-enabling an existing user). However, it is a separate management role called “Mail Recipient Creation” that has the role entries that permit creating entirely new recipients, such as New-Mailbox, New-MailUser, and New-MailContact.

Both the Mail Recipients and Mail Recipient Creation roles, along with others, are assigned to the role group named Recipient Management. You can see the role assignments for the Recipient Management role group by running the Get-RoleGroup cmdlet.

[PS] C:\>Get-RoleGroup "Recipient Management" | Select -ExpandProperty Roles | Select Name

Move Mailboxes
Message Tracking
Mail Recipient Creation
Mail Recipients
Mail Enabled Public Folders
Recipient Policies
Distribution Groups
Team Mailboxes

The Recipient Management role group is one of the Active Directory security groups that exists in the Microsoft Exchange Security Groups OU. Therefore, if you add a user account to the Recipient Management group, they are granted the ability to perform those administration tasks such as managing mail recipients, distribution groups, and performing message tracking. When that user opens the Exchange Management Shell, only the cmdlets that are included in the role entries for the management roles assigned to the role groups they are a member of will be available. For example, a Recipient Management role group member won’t have access to the New-AcceptedDomain or Set-AcceptedDomain cmdlets, but they do have access to the Get-AcceptedDomain cmdlet.

When the user logs into the Exchange Admin Center, they will also see only the sections that they have access to through their role group membership. For example in the screenshot below, the web browser on the left shows the sections visible to a Recipient Management role group member, and the browser on the right shows the sections visible to an Organization Management role group member.


Some of the differences are obvious, for example the Recipient Management role group member can’t see the compliance management section of the Exchange Admin Center. Others are not so obvious at first. Both users can see the mail flow section where things like Accepted Domains are managed. The Recipient Management role group holder can still see that section, because they need to be able to “see” the list of accepted domains in the organization when assigning SMTP addresses to recipients. But they can’t edit any of the accepted domains, nor can they add new ones.

As the final piece of the RBAC picture, there’s also the concept of management role scope. The management roles (such as Mail Recipients) assigned to the pre-canned role groups (such as Recipient Management) have a scope of “Organization”, which effectively means they apply to the entire organization. Management roles can be scoped to more specific area, such as to a single organizational unit in Active Directory.

So to summarize what’s been covered so far, RBAC is made up of:

  • Management role entries, which are specific tasks that a user can perform, such as running the Set-Mailbox cmdlet.
  • Management roles, which are collections of role entries, such as the Mail Recipients role.
  • Management role scope, which defines where in the organization a management role is applicable to, such as the entire organization, a specific server, or a specific organizational unit.
  • Management role assignments, which link management roles to role groups.
  • Management role groups, which are security groups that users can be added to as members to grant them the permissions to perform administrative tasks.

Once you are comfortable with those basics, you can start looking at creating custom roles.

Creating a Custom RBAC Role

Let’s say that you have a user in the organization who is responsible for managing mail contacts. To provide them with the permissions to perform that task, without any additional effort on your part, you would need to add them to the Recipient Management role group. However, that role group permits them to do much more than just manage the mail contacts they are responsible for, so it doesn’t align with the least privilege approach to security.

The more sensible approach is to create a custom RBAC role and assign it to that user, or to a role group that the user can be made a member of.

The easiest way to create a custom role is by using the Exchange Admin Center. In the permissions section under admin roles, click the icon to create a new role group.


Give the role group a meaningful name, and set the organizational unit that you want to limit the role group to.


Next, click the icon to add a role. In scanning through the list of existing roles (remember, these are collections of role entries), there doesn’t appear to be one already created for managing mail contacts. So a custom role (or two) with the role entries for managing contacts needs to be created. Creating custom roles is easiest when you create the custom role based on an existing role, and then customize it for your needs. In this case, Mail Recipients and Mail Recipient Creation are the two roles to base the new custom roles on.

[PS] C:\>New-ManagementRole -Parent "Mail Recipients" -Name "Custom Role - Mail Contacts"

Name                                                        RoleType
----                                                        --------
Custom Role - Mail Contacts                                 MailRecipients

[PS] C:\>New-ManagementRole -Parent "Mail Recipient Creation" -Name "Custom Role - Mail Contacts Creation"

Name                                                        RoleType
----                                                        --------
Custom Role - Mail Contacts Creation                        MailRecipientCreation

The next step is to remove the unwanted role entries from each of the custom roles, so that they’re only left with the capability to manage mail contacts.

[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts\*" | Where {$_.Name -notlike "*MailContact"} | Remove-ManagementRoleEntry

[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts Creation\*" | Where {$_.Name -notlike "*MailContact"} | Remove-ManagementRoleEntry

So now we’re left with two custom roles called “Custom Role – Mail Contacts” and “Custom Role – Mail Contacts Creation”, each containing only the role entries required for managing contacts.

[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts\*"

Name                           Role                      Parameters
----                           ----                      ----------
Disable-MailContact            Custom Role - Mail Con... {Confirm, Debug, DomainController, ErrorAction, ErrorVariab...
Enable-MailContact             Custom Role - Mail Con... {Alias, Confirm, Debug, DisplayName, DomainController, Erro...
Get-MailContact                Custom Role - Mail Con... {Anr, Credential, Debug, DomainController, ErrorAction, Err...
Set-MailContact                Custom Role - Mail Con... {AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers, A...

[PS] C:\>Get-ManagementRoleEntry "Custom Role - Mail Contacts Creation\*"

Name                           Role                      Parameters
----                           ----                      ----------
Get-MailContact                Custom Role - Mail Con... {Anr, Credential, Debug, DomainController, ErrorAction, Err...
New-MailContact                Custom Role - Mail Con... {Alias, ArbitrationMailbox, Confirm, Debug, DisplayName, Do...
Remove-MailContact             Custom Role - Mail Con... {Confirm, Debug, DomainController, ErrorAction, ErrorVariab...
With a slightly different approach you could also create one single custom role containing all of the role entries you need, instead of two custom roles. But this approach of creating custom roles based of existing roles is a nice, easy way to do the task.

Back to the Exchange Admin Center, the two custom roles are now visible in the picker to add to the new role group we’re creating. Add the two custom roles, and also add the View-Only Recipients role.


Finally, add the users who will be performing the administrative tasks to the role group as members, and save the new role group.


When the members of the new “Mail Contact Managers” role group log in to the Exchange Admin Center, they’ll be able to see the recipients in the organization (just as they can see them in the global address list via Outlook), and in the Contacts area will be able to create new Mail Contacts. If the role group member shown above tries to create a contact in an OU other than the one their role has been scoped to, they’ll receive an error.


But if they choose the correct OU when creating the contact, they’ll be successful. The same OU restrictions also apply to modifying or deleting contacts.


In this tutorial I’ve demonstrated how to use pre-defined management roles in Exchange Server to assign RBAC permissions for administrative tasks. I’ve also demonstrated how to create custom roles and role groups to assign limited permissions to users for specific tasks.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for


  1. Bill

    Is an Exchange mailbox required on a domain account to add it to the Organization Management Role ? We are using Exchange 2016

    It seems I can add domain user accounts and universal security groups to a role. But I’m wondering if there are any limitations in any of the permissions when there is no mailbox assigned to the account?


    1. Andy

      Yor admin account will need a mailbox to sign in to the ECP console on Exchange 2016.

      You do not need to use the mailbox for mail . You can set the mailbox to reject all mail under: Mailbox features – Message Delivery Restrictions.

  2. Matt Montgomery

    I am trying to create exactly this same thing in Office 365 Exchange and run into an issue with running the second removal command. One user posted the same issue but never got a response.

    When running

    Get-ManagementRoleEntry “Custom Role – Mail Contacts Creation\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

    We get

    Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “Custom Role – Mail Contacts
    Creation” to type “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you
    specified in the Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value,
    and then try again.
    Parameter name: identity”
    + CategoryInfo : InvalidData: (Custom Role – Mail Contacts Creation:PSObject) [Remove-ManagementRoleEntry
    ], ParameterBindin…mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry
    + PSComputerName :

    For some reason when running

    Get-ManagementRoleEntry “Custom Role – Mail Contacts\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

    It works fine but only leaves 2 cmdlets in there instead of the 4 you are showing. I basically need working script that enables a user to add and remove mail contacts in the ECP, that’s it.

  3. John Treanor

    Excellent article and thank you for posting this. I’m having trouble with the following:
    Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | Remove-ManagementRoleEntry

    The error I get multiple times is:
    Cannot process argument transformation on parameter ‘Identity’. Cannot convert value “CustomBNSKMailContacts” to type
    “Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter”. Error: “The format of the value you specified in the
    Microsoft.Exchange.Configuration.Tasks.RoleEntryIdParameter parameter isn’t valid. Check the value, and then try again.
    Parameter name: identity”
    + CategoryInfo : InvalidData: (CustomBNSKMailContacts:PSObject) [Remove-ManagementRoleEntry], ParameterBi
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-ManagementRoleEntry
    + PSComputerName :

    Any ideas?
    Thanks in advance –

    1. CJ

      I know I’m a year late, but just in case anyone else comes across this same problem.

      The syntax for that command needs to look like the below (using your example):

      Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($\$($”}

      Not sure if this was an error in the article or an Exchange vs EOL thing, or just something Microsoft have changed since, but hey.

      1. ST

        Slight error in your script. Missing an *.

        Get-ManagementRoleEntry “CustomBNSKMailContacts\*” | Where {$_.Name -notlike “*MailContact”} | %{Remove-ManagementRoleEntry -Identity “$($\$($”}

  4. Mixa

    thx for your post !

  5. Nikolay Nikolov

    Hi Paul, I am a great fan of your articles – you save my a.. many times :). I try to find something, hope can help me with this.
    I need to understand what rights or group in RBAC – Exchange 2010 – give rights to user to change user account photo. Thumbnail photo I think is name of attribute.

  6. Kent Persson

    Is I can see it, it’s possible to possible to limit 2: nd level support to only create/change users is specific OU, is it also possible to limit them to a specified DB? – we have all our users in site-specific databases.

  7. Kostie Muirhead

    Did this, and works great for write scopes, but why on god’s green earth can’t I seem to find a way to limit read scopes?

  8. Kundan Gupta Gupta

    Does view only permission group members actually need a account with license on office 365 ?

  9. Andy Dring

    Thanks Paul,

    Very helpful article.

    One question – is it possible to create a custom group from blank and only add the permissions you require, or is modification by removal from an existing group the only way?



  10. BC

    Is there any role only can change user mailbox quota?

  11. Dan Wheeler

    Great writeup,

    I’m looking to delegate ONLY certain functions to a specific group at my organization; We want them to be able to modify quotas, mailbox delegates, and e-mail addresses, but you don’t appear to be able to do that without a high level of control (or at least it doesn’t appear in the limited ECP).

    Is there a way to give the same “view” as full admins for mailbox objects only?

    1. Avatar photo
      Paul Cunningham

      I don’t understand your question. RBAC lets you control granular admin access all the way down to specific cmdlets and parameters of cmdlets. You can create custom roles to allow as much or as little admin access as necessary.

  12. mushfiqul

    Dear Paul Cunningham,
    There are three OU into exchange 2016. When I user of any OU login in CEP, he can see all recipients of all OU but I want that “A user will only see his own OU recipients login exchange 2016 ecp” is it possible ?

  13. osman

    Hi paul,

    i want to remove “wipe mobile device” permission from role
    My test role doesn’t contains clear-mobiledevice command but i can choose this option.
    Which role entry related with wipe mobile device?


    1. osman

      My test role entries:


  14. konkretor

    Hi Paul,

    i have a little bit extra for you excellent blog post. Thank you so much.
    Why this? When you use the role View-Only Recipients, you see to much of ecp functions from exchange. We reduce the view to the most necessary.

    New-ManagementRole -Parent “View-Only Recipients” -Name “Custom Role – View-Only Recipients”

    Get-ManagementRoleEntry “Custom Role – View-Only Recipients\*” | Where {$_.Name -notlike “*MailContact”} | Remove-ManagementRoleEntry

    I have not found a option to add more than one role to the custom view

    Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-OrganizationalUnit”
    Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Recipient”
    Add-ManagementRoleEntry “Custom Role – View-Only Recipients\Get-Contact”

    Now you have only 4 roles


    that is all!


    1. Michael

      Can you help with my above problem running Exchange 2016? I am unable to set the Write Scope to a specific OU. Please see above comments from me.

      1. Michael

        Problem was sorted out by upgrading from CU7 to CU8

  15. Michael

    Not working in Exchange 2016. Getting error when applying the role group to the Contacts OU as write scrope:

    “Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

    Can you help?

      1. Michael

        I am doing from the ECP. According to your guide, I set the Write Scope to a specific OU where we have got the contacts, and then the ECP throws above error.

        The corresponding command would be something like:

        New-RoleGroup -Name “Mail Contacts Manager” -RecipientOrganizationalUnitScope Contacts -Roles “Custom – Mail Contacts”, “Custom – Mail Contacts Creation” -Members contactadmin

          1. Michael

            Yes. Using the Full path in ECP, it sees the OU, otherwise it would say it does not exist.

          2. Avatar photo
            Paul Cunningham

            Ok. I haven’t seen the issue. Maybe there’s an ambiguous OU name causing problems or something like that. Perhaps running the command in the shell will work better.

    1. Jeff Arndt

      I know it has been a while, but I just came across this same error:

      “Object class organizationalUnit is not recognized as a valid object class for E-mail recipient objects.”

      What I had to do was create it with the Write Scope set to Default, save it, then I could come back and change the write scope to an Organizational Unit.

      Hope this helps someone in the future.

      1. Bob Foglia

        Thank you. This worked for me.

      2. Tim Hubbard

        Perfect! Worked for me too

      3. Caleb

        Awesome! Worked for me.

    2. Affan Javid

      From ECP Create the Role with Default Scope. After it is created in 2nd Step Add the required OU. Worked for me .

  16. ketil

    Hey Poul, wonderfull article and really nicely written.

    I have tried deploying this setup in our test/QA enviroments but i run into a error when the user needs to select the ou upon contact creation. I looks to me like there is some role/permission needed, if a user should be granted access to navigate the AD (so they can select the right ou which they are allowed to write to)

    When the user tries to browse the AD, they are informed that they do not have permission to browse the ad, and the progress circle just keeps spinning.

    Have you seen this problem before?

Leave a Reply