Many admins I talk to want to use the Exchange 2010 RBAC permission model to delegate some administrative tasks to their admins, but they also tell me it’s quite complicated to understand. Sure, it can be very complicated but for most “smaller” implementations (less than 20 admins?), it’s quite easy to understand. Hopefully this article will clear things up…

RBAC, Role-based access control simply allows you to delegate object creation and modification. Important to understand is that you no longer need the ACL permissions in AD and it doesn’t matter what AD permissions you need. Everything is authorized through the RBAC and they apply to all Exchange management tools (EMC, EMS, ECP).

There are 11 built-in management role groups available in your root domain’s OU Microsoft Exchange Security Groups. If they are good enough – use them. Otherwise, you will need to create a custom role group. There are many different ways you might want to delegate and I suggest you don’t over-complicate things. I tend to stay with KISS – “Keep it simple stupid”…

Nothing gives you a better understanding than an example… This example shows how to delegate so that an admin has full rights to the objects in the OU they manage, a quite common example.

First, if you start EMC/EMS without any roles assigned you will get an error: Processing data from remote server failed with the following error message: The user isn’t assigned to any management roles. Then we’re all good to start.

Step 1. Decide what roles are required by the admin.

You can either use one or more of the default built-in management roles, there are 70 of them and you list them with:

Get-ManagementRole

You might want to know which entries a specific role contains? Example

Get-ManagementRole “User Options” | fl RoleEntries

Hey, not very pretty. Another, maybe better way, would be to get the entries this way instead:

Get-ManagementRoleEntry “User Options\*” | ft –AutoSize -Wrap

Still, a lot of information. Maybe you want to know what the admin can do when it comes to ActiveSync and just filter that out?

Get-ManagementRoleEntry “User Options\*ActiveSync*” | ft –AutoSize -Wrap

By now you probably have identified a built-in role that you can use. In my case, I decided to use roles “Mail Recipients”, “Mail Recipient Creation” and “Distribution Groups” instead of creating custom ones.

Step 2. Decide the management scope

You can define a scope based on a serverlist, by domain, by database. What you decide is up to your environment. I decided to base it on OU.

New-ManagementScope -Name “CUST-Scope” -RecipientRestrictionFilter { RecipientType -like “*” } -RecipientRoot “domain.local/Infrastructure/Users”

You could change the following parameter if you only want them to be able to manage mailboxes:

-RecipientRestrictionFilter { RecipientType -eq “UserMailbox” }

Examples and documentation.

Step 3. Create the new management role group

This will actually create a Universal Group in the root domain’s OU Microsoft Exchange Security Groups. Sure, you could specify -SecurityGroup parameter to create it somewhere else.:

New-RoleGroup -Name “CUST-ROLE-Admins” -Roles “Mail Recipients”,”Mail Recipient Creation”,“Distribution Groups” -CustomRecipientWriteScope “CUST-Scope”

Examples and documentation.

Step 4. Add members to the group

Do it manually via ADUC or use PowerShell:

Add-RoleGroupMember “CUST-ROLE-Admins” -Member <user>

Examples and documentation.

Done! Now the user should be able to start EMC/EMS without errormessage and perform the tasks you assigned to the user.

Tip: I tend to name all custom settings with a prefix, such as CUST-. In this way, I know what I’ve created and what is default and also makes it easier when listing since I can choose to show only the items starting with CUST-*. Examples:

Get-ManagementScope | Where {$_.Name -like “CUST-*”}

 

Troubleshooting

Error when creating a new user with a mailbox: The term ‘New-Mailbox’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Solution: The role(s) you have assigned to the admin doesn’t have the permission to run New-Mailbox. Maybe you have just assigned role “Mail Recipients” and not “Mail Recipient Creation”?

Error when enabling a mailbox for an existing user: <user> isn’t within you current write scope. Can’t perform save operation.

Solution: Changed { RecipientType -eq “UserMailbox” } to { RecipientType -like “*” }