Understanding Management Role Scopes

Article
06/29/2011

Applies to: Exchange Server 2010

Management role scopes enable you to define the specific scope of impact or influence of a management role when a management role assignment is created. When you apply a scope, the role assignee assigned to the role can only modify the objects contained within that scope. A role assignee can be a management role group, management role, management role assignment policy, user, or universal security group (USG). For more information about management roles, see Understanding Role Based Access Control.

Every management role, whether it's a built-in role or a custom role, has management scopes. Management scopes can be either of the following:

Regular A regular scope isn't exclusive. It determines where, in Active Directory, objects can be viewed or modified by users assigned the management role. In general, a management role indicates what you can create or modify, and a management role scope indicates where you can create or modify. Regular scopes can be either implicit or explicit scopes, both of which are discussed later in this topic.
Exclusive An exclusive scope behaves almost the same as a regular scope. The key difference is that it enables you to deny users access to objects contained within the exclusive scope if those users aren't assigned a role associated with the exclusive scope. All exclusive scopes are explicit scopes, which are discussed later in this topic.
For more information about exclusive scopes, see Understanding Exclusive Scopes.

Scopes can be inherited from the management role, specified as a predefined relative scope on a management role assignment, or created using custom filters and added to a management role assignment. Scopes inherited from management roles are called implicit scopes while predefined and custom scopes are called explicit scopes. The following sections describe each type of scope:

Implicit Scopes
Explicit Scopes
- Predefined Relative Scopes
- Custom Scopes

Each role can have the following types of scopes:

Recipient read scope The implicit recipient read scope determines what recipient objects the user assigned the management role is allowed to read from Active Directory.
Recipient write scope The implicit recipient write scope determines what recipient objects the user assigned the management role is allowed to modify in Active Directory.
Configuration read scope The implicit configuration read scope determines what configuration objects the user assigned the management role is allowed to read from Active Directory.
Configuration write scope The configuration write scope determines what organizational and server objects the user assigned the management role is allowed to modify in Active Directory.

Recipient objects include mailboxes, distribution groups, mail enabled users, and other objects. Configuration objects include servers running Microsoft Exchange Server 2010. Each type of scope can be either an implicit scope or explicit scope.

Implicit Scopes

Implicit scopes are the default scopes that apply to a management role type. Because implicit scopes are associated with a management role type, all of the parent and child management roles with the same role type also have the same implicit scopes. Implicit scopes apply to both built-in management roles and also to custom management roles. For more information about management roles and management role types, see Understanding Management Roles.

The following tables list all of the implicit scopes that can be defined on management roles.

Implicit scopes defined on management roles

Implicit scopes	Description
`Organization`	If `Organization` is present in the role's recipient write scope, the role can create or modify recipient objects across the Exchange organization. If `Organization` is present in the role's recipient read scope, roles can view any recipient object across the Exchange organization. This scope is used only with recipient read and write scopes.
`MyGAL`	If `MyGAL` is present in the role's recipient write scope, the role can view the properties of any recipient within the current user's global address list (GAL). If `MyGAL` is present in the role's recipient read scope, the role can view the properties of any recipient within the current GAL. This scope is used only with recipient read scopes.
`Self`	If `Self` is present in the role's recipient write scope, the role can modify only the properties of the current user's mailbox. If `Self` is present in the role's recipient read scope, the role can view only the properties of the current user's mailbox. This scope is used only with recipient read and write scopes.
`MyDistributionGroups`	If `MyDistributionGroups` is present in the role's recipient write scope, the role can create or modify distribution list objects owned by the current user. If `MyDistributionGroups` is present in the role's recipient read scope, the role can view distribution list objects owned by the current user. This scope is used only with recipient read and write scopes.
`OrganizationConfig`	If `OrganizationConfig` is present in the role's configuration write scope, the role can create or modify any server configuration object across the Exchange organization. If `OrganizationConfig` is present in the role's configuration read scope, the role can view any server configuration object across the Exchange organization. This scope is used only with configuration read and write scopes.
`None`	If `None` is in a scope, that scope isn't available to the role. For example, a role that has `None` in the recipient write scope can't modify recipient objects in the Exchange organization.

If a role is assigned to a role assignee and no predefined or custom scopes are specified, the implicit scopes defined on the role are used to control the recipient or organization objects the user can view or modify.

The following table lists all of the built-in management roles and their implicit scopes.

Built-in management role implicit scopes

Management role	Recipient read scope	Recipient write scope	Configuration read scope	Configuration write scope
`Active Directory Permissions`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Address Lists`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Audit Logs`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Cmdlet Extension Agents`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Database Availability Groups`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Database Copies`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Databases`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Disaster Recovery`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Distribution Groups`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Edge Subscriptions`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`E-Mail Address Policies`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Exchange Connectors`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Exchange Server Certificates`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Exchange Servers`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Exchange Virtual Directories`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Federated Sharing`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Information Rights Management`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Journaling`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Legal Hold`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Mail Enabled Public Folders`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Mail Recipient Creation`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Mail Recipients`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Mail Tips`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Mailbox Search`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Message Tracking`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Migration`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Monitoring`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Move Mailboxes`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`MyBaseOptions`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyContactInformation`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyDistributionGroupMembership`	`MyGAL`	`MyGAL`	`None`	`None`
`MyDistributionGroups`	`MyGAL`	`MyDistributionGroups`	`OrganizationConfig`	`None`
`MyMailSubscriptions`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyProfileInformation`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyRetentionPolicies`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyTextMessaging`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`MyVoiceMail`	`Self`	`Self`	`OrganizationConfig`	`OrganizationConfig`
`Organization Client Access`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Organization Configuration`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Organization Transport Settings`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`POP3 And IMAP4 Protocols`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Public Folder Replication`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Public Folders`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Receive Connectors`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Recipient Policies`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Remote and Accepted Domains`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Reset Password`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Retention Management`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Role Management`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Security Group Creation and Membership`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Send Connectors`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Support Diagnostics`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Transport Agents`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Transport Hygiene`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Transport Queues`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Transport Rules`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`UM Mailboxes`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`UM Prompts`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`Unified Messaging`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`UnScoped Role Management`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`User Options`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`View-Only Configuration`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`
`View-Only Recipients`	`Organization`	`Organization`	`OrganizationConfig`	`OrganizationConfig`

The implicit write scope of a role is always equal to, or less than, the implicit read scope. This means that a role can never modify objects that can't be seen by the scope.

You can't change the implicit scopes defined on management roles. You can, however, override the implicit write scope and configuration scope on a management role. When a predefined relative scope or custom scope is used on a role assignment, the implicit write scope or configuration scope of the role is overridden, and the new scope takes precedence. The implicit read scope of a role can't be overridden and always applies. For more information about predefined or custom explicit scopes, see the related sections later in this topic.

Explicit Scopes

Explicit scopes are scopes that you set yourself to control which objects a management role can modify. While implicit scopes are defined on a management role, explicit scopes are defined on a management role assignment. This enables the implicit scopes to be applied consistently across all management roles unless you choose to use an overriding explicit scope. For more information about management role assignments, see Understanding Management Role Assignments.

Explicit scopes override the implicit write and configuration scopes of a management role. They don't override the implicit read scope of a management role. The implicit read scope continues to define what objects the management role can read.

Explicit scopes are useful when the implicit write scope of a management role doesn't meet the needs of your business. You can add an explicit scope to include nearly anything you want as long as the new scope doesn't exceed the bounds of the implicit read scope. The cmdlets that are part of a management role must be able to read information about the objects or containers that contain objects for the cmdlets to create or modify objects. For example, if the implicit read scope on a management role is set to Self, you can't add an explicit write scope of Organization because the explicit write scope exceeds the bounds of the implicit read scope.

The following sections describe predefined relative scopes and custom scopes.

Predefined Relative Scopes

Exchange 2010 provides several predefined relative write scopes that you can use to modify scope of a management role. Predefined relative scopes provide an easy way for you to more closely match the needs of your business without having to create custom scopes manually. They're called relative scopes because they're relative to the role assignee to which the associated role assignment is assigned. For example, the Self predefined relative scope restricts that write scope to the current user only. The MyDistributionGroups predefined relative scope restricts the write scope to the distribution group the current user owns only. Predefined relative scopes can only be used to scope recipient objects. Predefined relative scopes can't be used to scope configuration objects. The following table lists the predefined relative scopes that you can use.

Predefined relative scopes

Implicit scopes Description

Organization

If Organization is present in the role's recipient write scope, the role can create or modify recipient objects across the Exchange organization.

If Organization is present in the role's recipient read scope, roles can view any recipient object across the Exchange organization.

This scope is used only with recipient read and write scopes.

Self

If Self is present in the role's recipient write scope, the role can modify only the properties of the current user's mailbox.

If Self is present in the role's recipient read scope, the role can view only the properties of the current user's mailbox.

This scope is used only with recipient read and write scopes.

MyDistributionGroups

If MyDistributionGroups is present in the role's recipient write scope, the role can create or modify distribution list objects owned by the current user.

If MyDistributionGroups is present in the role's recipient read scope, the role can view distribution list objects owned by the current user.

This scope is used only with recipient read and write scopes.

Predefined relative scopes are applied when you create a new management role assignment. During the creation of the role assignment, using the New-ManagementRoleAssignment cmdlet, you can specify a predefined relative scope using the RecipientRelativeWriteScope parameter. When the new role assignment is created, the new predefined role overrides the implicit write scope of the management role.

For more information about how to add a management role assignment with a predefined relative scope, see Add a Role to a User or USG.

Custom Scopes

Custom scopes are needed when neither the implicit write scope nor the predefined relative scopes meets the needs of your business. Custom scopes enable you to define at a granular level, the scope to which your management role will be applied. For example, you might want to target a specific organizational unit (OU), a specific type of recipient, or both.

As with predefined relative scopes, custom scopes override the implicit write and organization configuration scopes defined on management roles. The implicit read scope on management roles continue to apply and the resulting custom scope must not exceed the boundaries of the implicit read scope.

The simplest custom scope is an OU scope created using the RecipientOrganizationalUnitScope parameter on the New-ManagementRoleAssignment cmdlet. By specifying an OU scope when a role is assigned, the user assigned the role can modify only recipient objects within that OU.

For more information about how to add a management role assignment with an OU scope, see Add a Role to a User or USG.

More complex and granular custom scopes can be created by using the New-ManagementScope cmdlet. With the New-ManagementScope cmdlet, you can create recipient and configuration filtered scopes. Recipient filtered scopes use filters to target specific recipients based on recipient type or other recipient properties such as department, manager, location, and more. Configuration filtered scopes use filters to target specific servers based on filterable properties that can be defined on servers, such as an Active Directory site or a server role.

When you create either a recipient or configuration filtered scope, only the recipient or server objects that match their respective filtered scopes are returned. When these scopes are applied to a role assignment using the New-ManagementRoleAssignment or Set-ManagementRoleAssignment cmdlets, only the objects that match the filters can be modified by the role assignees who are assigned the role. After a custom scope has been created, you can't change the scope type. A recipient scope is always a recipient scope and a configuration scope is always a configuration scope.

By default, a custom scope enables a role assignee to access a set of objects that match the filters you define. However, they don't actively exclude access to other role assignees who aren't also assigned the same or equivalent scope. Any custom scope can access the same objects if the filters on those scopes match the same objects. There might be objects where this behavior isn't wanted, such as in the case of important personnel, such as executives. For these objects, you can define exclusive scopes. Exclusive scopes use filters in the same way as regular scopes but unlike regular scopes, deny access to objects included in the scope to anyone who isn't part of the same or equivalent exclusive scope. For more information about exclusive scopes, see Understanding Exclusive Scopes.