Role Based Access Control, the new permissions management model in Exchange Server 2010, is managed using the Exchange...
Management Shell. The concept of RBAC is simple in theory; the permissions are based on PowerShell. However, moving from the built-in settings that role groups and roles provide to a more granular method involves more than what’s possible through the Exchange Management Shell (EMS).
RBAC contains nine built-in role groups, including the Discovery Management role group. If you want to give a user permission to perform discovery searches and place another user’s mailbox on legal hold for example, you would add that user to the Discovery Management role group.
Each role group contains several roles, and there are 65 different roles in all. For instance, the Discovery Management role group has two roles assigned to it: the Mailbox Search role and the Legal Hold role. Entries in those roles are based on PowerShell.
Certain cmdlets and parameters that assigned to each role give a user with role permissions the ability to use EMS, the Exchange Management Console or the Exchange Control Panel. This allows the user to perform PowerShell tasks behind the scenes via cmdlets and parameters.
Although it’s easy to find the nine role groups and definitions for each group, and even easier to locate the 65 roles and their definitions, it can be tricky to locate entries that go with those roles.
Being able to locate the roles and role groups is important because default role groups and roles are more extensive than legacy Exchange permission options. You can create customized roles and role groups by using an existing role as your parent and stripping out the permissions you need to change using a child role. The caveat is that a child role cannot have more permissions than its parent.
This creates problems when you don’t know what permissions you’re starting with -- namely the cmdlets and parameters themselves -- and you don’t understand the role or what it does. In this case, you’ll have difficulty creating new roles. Unfortunately, the primary way to obtain this information is to use various PowerShell commands to locate the management role entries of each role.
The tools you'll need to work with RBAC
When searching for a tool to work with RBAC, I found an Excel spreadsheet that maps out role groups, roles and role entries for Exchange Server 2010 RTM and Exchange 2010 SP1 (Figure 1). The spreadsheet uses a sort and filter structure that makes it easy to find what you are looking for.
The spreadsheet helped somewhat, but I wanted information that was drilled down to the parameter level. You might be asking, “If you know the the cmdlets, can’t you search for their parameters?” The answer, unfortunately, is no because roles aren’t configured down to that level.
When Microsoft designed RBAC and its entries; they didn’t only include a bunch of cmdlets. They thought about the role’s purpose and what users would need to do with that cmdlet. That’s why they only released certain parameters.
I approached the Exchange team with my problem and they gave me a CodePlex link containing the RBAC Manager tool (Figure 2).
Once I installed the RBAC manager, I was able to view all role groups, management roles, role assignments and role entries as well as cmdlets and parameters. Upon further inspection, I realized this tool went even one step further.
The tool let me configure RBAC through a GUI, as opposed to the EMS. In my opinion, this is a homerun for any admin who has attempted command-line RBAC in Exchange Server 2010.
For a video review of these tools, check out the free video I created as part of an Exchange 2010 Design and Deployment Training course.
J. Peter Bruzzese (Triple-MCSE, MCT, MCITP: Messaging) is a Microsoft MVP, the Enterprise Windows columnist for InfoWorld and the Exchange 2010 instructor for Train Signal. He is the mind behind ExclusivelyExchange.com. You can reach him at email@example.com.