Understanding Management Role Groups
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2010-12-16
A management role group is a universal security group (USG) used in the Role Based Access Control (RBAC) permissions model in Microsoft Exchange Server 2010. A management role group simplifies the assignment of management roles to a group of users. All members of a role group are assigned the same set of roles. Role groups are assigned administrator and specialist roles that define major administrative tasks in Exchange 2010 such as organization management, recipient management, and other tasks. Role groups enable you to more easily assign a broader set of permissions to a group of administrators or specialist users.
|This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2010 permissions, such as using the Exchange Control Panel (ECP) to add and remove members to and from role groups, create and modify role groups, or create and modify role assignment policies, see Understanding Permissions.|
|If you want to assign permissions to users to manage their own mailbox or distribution groups, see Understanding Management Role Assignment Policies.|
The following are the layers that make up the role group model:
- Role holder A role holder is a mailbox that can be added as a member of a role group. When a mailbox is added as a member of a role group, the assignments that have been made between management roles and a role group are applied to the mailbox. This grants the mailbox all of the permissions provided by the management roles.
- Management role group The management role group is a special USG that contains mailboxes that are members of the role group. This is where you add and remove members, and it's also what management roles are assigned to. The combination of all the roles on a role group defines everything that users added to a role group can manage in the Exchange organization.
- Management role assignment A management role assignment links a management role and a role group. Assigning a management role to a role group grants members of the role group the ability to use the cmdlets and parameters defined in the management role. Role assignments can use management scopes to control where the assignment can be used. For more information, see Understanding Management Role Assignments.
- Management role scope A management role scope is the scope of influence or impact on a role assignment. When a role is assigned with a scope to a role group, the management scope targets specifically what objects that assignment is allowed to manage. The assignment, and its scope, are then given to the members of the role group, which restricts what those members can manage. A scope can be made up of lists of servers or databases, organizational units, or filters on server, database or recipient objects. For more information, see Understanding Management Role Scopes.
- Management role A management role is a container for a grouping of management role entries. Roles are used to define the specific tasks that can be performed by the members of a role group assigned the role. For more information, see Understanding Management Roles.
- Management role entries Management role entries are the individual entries on a management role that provide access to cmdlets, scripts, and other special permissions that enable access to perform a specific task. Most often, role entries consist of a single cmdlet and the parameters that can be accessed by the management role, and therefore the role group to which the role is assigned.
The following figure shows each of the role group layers in the preceding list and how each of the layers relates to the other.
For more information about RBAC, see Understanding Role Based Access Control.
When you create a role group, you create the USG that holds the members of the role group, and you create the assignments between the role group and the management roles you specify. Optionally, you can also specify a management scope to apply to the role assignments, and you can add any mailboxes that you want to be members of the new role group.
After you create a role group, each layer becomes an independent object. The role group continues to be the central point at which all of the layers are joined together, however, each layer is managed individually. For example, to modify the management scope that you applied to the role group when it was created, you need to change the scope on each individual role assignment after the role group is created. The management of the role group model is performed using the cmdlets that manage the individual layers of the role group model.
The following table lists the role group layer and the procedural topics that you can use to manage each layer.
Role group management topics
|Role group model layer||Management topic|
Management roles and assignments
Management role entries
Built-in roles groups are roles shipped with Exchange 2010. They provide you with a set of role groups that you can use to provide varying levels of administrative permissions to groups of users. You can add or remove users to or from any built-in role group. You can also add or remove role assignments to or from most role groups. The only exceptions are the following:
You can't remove any delegating role assignments from the Organization Management role group.
You can't remove the Role Management role from the Organization Management role group.
The following table lists all of the built-in role groups included with Exchange 2010. For more information about built-in role groups, see Built-in Role Groups.
Built-in role groups
Administrators who are members of the Organization Management role group have administrative access to the entire Exchange 2010 organization and can perform almost any task against any Exchange 2010 object.
Administrators who are members of the View Only Organization Management role group can view the properties of any object in the Exchange organization.
Administrators who are members of the Recipient Management role group have administrative access to create or modify Exchange 2010 recipients within the Exchange 2010 organization.
Administrators who are members of the UM Management role group can manage the Unified Messaging (UM) features in the Exchange organization such as Unified Messaging server configuration, UM properties on mailboxes, UM prompts, and UM auto attendant configuration.
Administrators or users who are members of the Discovery Management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria.
Users who are members of the Records Management role group can configure compliance features, such as retention policy tags, message classifications, transport rules, and more.
Administrators who are members of the Server Management role group have administrative access to Exchange 2010 server configuration. They don't have access to administer Exchange 2010 recipient configuration.
Users who are members of the Help Desk role group can perform limited recipient management of Exchange 2010 recipients.
Administrators who are members of the Hygiene Management role group can configure the antivirus and anti-spam features of Exchange 2010. Third-party programs that integrate with Exchange 2010 can add service accounts to this role group to grant those programs access to the cmdlets required to retrieve and configure the Exchange configuration.
Administrators who are members of the Public Folder Management role group can manage public folders and databases on Exchange 2010 servers.
Administrators who are members of the Delegated Setup role group can deploy previously provisioned Exchange 2010 servers.
Linked role groups are used in organizations that install Exchange 2010 in a dedicated resource forest and place users in other, trusted foreign forests. Linked role groups, as the name implies, create a link between a role group in the Exchange forest and a USG in a foreign forest. This is useful when the Active Directory Domain Services (AD DS) user accounts of the administrators you want to administer Exchange don't reside in the same resource forest as Exchange. Linked role groups can only be associated with one foreign USG. Additionally, you don't need to create a two-way trust between the Exchange forest and the foreign forest. The Exchange forest needs to trust the foreign forest but the foreign forest doesn't need to trust the Exchange forest.
For more information about permissions in multiple-forest topologies, see Understanding Multiple-Forest Permissions.
A linked role group consists of two parts:
- Linked role group The linked role group is a container object that associates the foreign USG with the management role assignments assigned to the role group.
- Foreign USG The foreign USG contains the members that should be granted the permissions provided by the linked role group.
When you create a linked role group, you provide a domain controller in the foreign forest that contains the users you want to manage the Exchange forest and the USG that contains those users as members, the foreign USG name, and the credentials required to access the foreign forest. Exchange adds the security identifier (SID) of the foreign USG to the linked role group. Because the USG SID is the only identification of the foreign USG, we strongly recommend that you specify the foreign forest in the name of the role group if you have multiple foreign forests.
A linked role group doesn't contain any members. All of the members of that role group are managed using the foreign USG. This means you can't use the Update-RoleGroupMember, Add-RoleGroupMember, or Remove-RoleGroupMember cmdlets to add or remove role group members. When you add members to the foreign USG, they are given the permissions provided by the linked role group.
You can't change a standard role group, which contains its own members, to a linked role group and vice versa. If you want to change a role group from a standard role group to a linked role group, you must create a new linked role group and replicate the management role assignments that are present on the standard role group on the linked role group. This is also the case for built-in role groups because they're standard role groups. If you want to perform all of the management of your Exchange forest from a foreign forest, you need to create new linked role groups and add the management roles that exist on the built-in role groups to the new linked role groups. For more information about how to accomplish this, see Create Linked Role Groups that Mirror Built-in Role Groups.
For more information about deploying Exchange in a resource forest, see Deploy Exchange 2010 in an Exchange Resource Forest Topology.
By default, members of the Organization Management role group can add and remove members to and from role groups. However, you might want to enable users who aren't members of the Organization Management role group to add and remove role group members. If so, you can use role group delegation.
Role group delegation is controlled by the ManagedBy property on each role group. The ManagedBy property contains a list of users who can add and remove members to and from that role group or change the configuration of a role group. The users aren't assigned any permissions given by the role group unless they're also members of the role group.
If the ManagedBy property is set on a role group, only those users who are listed as role group managers on that property can modify a role group or the membership of a role group by default. However, an optional parameter on cmdlets that modify role groups or role group membership can override that restriction. The BypassSecurityGroupManagerCheck switch can be used by users who are members of the Organization Management role or are assigned, either directly or indirectly, the Role Management management role. When this switch is used, the ManagedBy property is ignored and the user can modify the role group or role group membership.
If the ManagedBy property isn't set on a role group, only users who are members of the Organization Management role or are assigned, either directly or indirectly, the Role Management management role can modify a role group or role group membership.
|Roles assigned to a role group may be assigned using delegating role assignments. With delegating role assignments, members of a role group that's assigned a delegated role can assign that role to another role group, assignment policy, user, or USG. Members of the role group can assign only that role and can't delegate the role group, unless they're also added to the ManagedBy property. For more information about delegated role assignments, see Understanding Management Role Assignments.|
For more information about how to manage role group delegation, see Add or Remove a Role Group Delegate.
When a user is made a member of a role group, the management roles assigned to the role group are assigned to the user. If a user is a member of multiple role groups, the management roles from each role group are aggregated and assigned to the user. Users, USGs, and other role groups can be members of role groups.
Only users who are members of the Organization Management or Role Management role groups and users who have been delegated the ability to add and remove users to or from role groups can manage role group membership.
For more information about how to manage role group membership, see the following topics:
As mentioned previously, a role group is made up of several layers. To help you understand what happens when a role group is created, consider the following example, which creates a new role group.
New-RoleGroup -Name "Seattle Recipient Management" -Roles "Mail Recipients", "Distribution Groups", "Move Mailboxes", "UM Mailboxes" -CustomRecipientWriteScope "Seattle Users", -ManagedBy "Brian", "David", "Katie" -Members "Ray", "Jens", "Maria", "Chris", "Maira", "Carter", "Jesse", "Lukas", "Isabel", "Rick", "Katie"
When the preceding command is run, the following happens:
A new role group object, which is a special USG, called Seattle Recipient Management is created.
The mailboxes for Ray, Jens, Maria, Chris, Maira, Carter, Jesse, Lukas, Isabel, Rick, and Katie are added as members of the role group. These users receive the permissions provided by this role group.
The users Brian and David are added to the ManagedBy property of the role group. These users can add and remove members to and from the role group but won't be given any permissions provided by the role group because they're not members. Katie is also added to the ManagedBy property of the role group. Because she's added to the ManagedBy property, and she's a member of the role group, she can add or remove members to and from the role group, and she also receives the permissions provided by the role group.
The following management role assignments are created. The role assignments assign each management role specified in the command to the role group. The management scope Seattle Users is added to each role assignment. The name of each role assignment is a combination of the management role being assigned and the role group name.
Mail Recipients_Seattle Recipient Management
Distribution Groups_Seattle Recipient Management
Move Mailboxes_Seattle Recipient Management
UM Mailboxes_Seattle Recipient Management
If you compare the results of this command to the Management role group layers figure earlier in this topic, you can see where each step correlates to the role group layers. You can then refer to the Management role group management topics shown in "Role Group Management" earlier in this topic to manage each role group layer.