Obviously, the majority of the RBAC roles in Exchange relate to what administrators can and cannot do. That is the nature of Exchange: to ensure you have professionals handling those responsibilities, not users. However, there are roles in Exchange environments that, while not a hierarchy or a pecking order per se, require different people to have different abilities. That's where the role groups come in.
The 11 groups are actually a combination of roughly 65 roles. These roles are made up of entries -- that is, PowerShell cmdlets and parameters for the built-in management roles as defined by the Exchange development team. This is where we see the exciting piece to this puzzle; since Exchange 2007, Exchange administration has been built on PowerShell, a shift in design that allows you to control a role by manipulating the cmdlets and parameters assigned to that role.
Now, where it really becomes fun -- and, for many, confusing -- is that you can create your own role groups by mixing predefined roles and/or by creating your own roles and defining the entries (cmdlets and parameters) for those roles as you see fit.
The immediate beauty of RBAC as it is implemented in Exchange 2010 is how you can assign broad access and permission settings through the built-in role groups, establish a midlevel of granularity by mixing predefined management roles, or really get into the guts of RBAC by creating your own roles, defining the cmdlets and parameters, scope assignments, and more (to the nth degree) and building exactly what your environment needs.
Microsoft has known the value of RBAC for quite some time. Role-based security (another term used for RBAC) was built into the .Net framework, and Windows Server 2003 has the Authorization Manager snap-in for the MMC Console that uses the same approach; this tool continues to be available in Windows Server 2008.
The RBAC apporach could get even more useful if other development teams at Microsoft pick up on the value of this model. If they redesign their tools with PowerShell control throughout, they could take advantage of the same RBAC model and allow the same choice of broad, midrange, and granular control for each and every enterprise product. Already, Communications Server 2010 has implemented RBAC based on PowerShell cmdlets and parameters. The next version of System Center Configuration Manager (SCCM) is also embracing the concept of RBAC.
This article, "The joys of Microsoft Exchange 2010's RBAC," was originally published at InfoWorld.com. Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com.