Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2012-11-05

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 built-in or custom, has management scopes. Management scopes can be either of the following:

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:

Each role can have the following types of scopes:

Recipient objects include mailboxes, distribution groups, mail enabled users, and other objects. Configuration objects include servers running Microsoft Exchange Server 2010, and databases located on servers running Exchange. 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 or database configuration object across the Exchange organization.

If OrganizationConfig is present in the role's configuration read scope, the role can view any server or database 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 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 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, see Predefined Relative Scopes and Custom Scopes.

Expand the following table to see a list of all the built-in management roles and their implicit scopes. For more information about each built-in role, see Built-in Management Roles.

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

ApplicationImpersonation

Organization

Organization

None

None

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

None

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 Import Export

Organization

Organization

OrganizationConfig

OrganizationConfig

Mailbox Search

Organization

Organization

None

None

Message Tracking

Organization

Organization

OrganizationConfig

OrganizationConfig

Migration

Organization

Organization

OrganizationConfig

OrganizationConfig

Monitoring

Organization

Organization

OrganizationConfig

OrganizationConfig

Move Mailboxes

Organization

Organization

OrganizationConfig

OrganizationConfig

MyAddressInformation

Self

Self

OrganizationConfig

OrganizationConfig

MyBaseOptions

Self

Self

OrganizationConfig

OrganizationConfig

MyContactInformation

Self

Self

OrganizationConfig

OrganizationConfig

MyDiagnostics

Self

Self

OrganizationConfig

OrganizationConfig

MyDisplayName

Self

Self

OrganizationConfig

OrganizationConfig

MyDistributionGroupMembership

MyGAL

MyGAL

None

None

MyDistributionGroups

MyGAL

MyDistributionGroups

OrganizationConfig

None

MyMobileInformation

Self

Self

OrganizationConfig

OrganizationConfig

MyName

Self

Self

OrganizationConfig

OrganizationConfig

MyPersonalInformation

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

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 Audit Logs

Organization

None

OrganizationConfig

None

View-Only Configuration

Organization

None

OrganizationConfig

None

View-Only Recipients

Organization

None

OrganizationConfig

None

Explicit Scopes

Explicit scopes are scopes that you set yourself to control which objects a management role can modify. Although 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.

For more information, see the following sections:

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. You can't specify a custom recipient scope when you create a role assignment with a predefined relative scope. You can, however, specify a custom configuration scope if needed.

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. Or, you might only want to allow a group of administrators to be able to manage a specific set of mailbox databases.

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. You can create the following three types of custom scopes:

  • OU scope   An OU scope, which is the simplest custom scope, is created using the RecipientOrganizationalUnitScope parameter on the New-ManagementRoleAssignment cmdlet. By specifying an OU scope when a role is assigned, the role assignee 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.

  • Recipient filter scope   Recipient filter scopes use filters to target specific recipients based on recipient type or other recipient properties such as department, manager, location, and more. For more information, see the Recipient Filter Scopes section.

  • Configuration scope   Configuration scopes use filters or lists to target specific servers based on server lists or filterable properties that can be defined on servers, such as an Active Directory site or a server role. In Exchange 2010 Service Pack 1 (SP1), configuration scopes can also use database scopes to target specific databases based on database lists or filterable database properties. For more information, see the Configuration Scopes section.

Simple and broad or complex and granular recipient and configuration custom scopes can be created by using the New-ManagementScope cmdlet. When you create either a recipient or configuration scope, only the recipient, server, or database objects that match their respective 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 scopes 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 scopes 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 lists or 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 or lists 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.

Recipient Filter Scopes

Recipient filter scopes enable you to control which recipient objects role assignees can manage by evaluating one or more properties on a recipient object against a value that you specify in a filter statement. Recipients included in recipient scopes are mailboxes, mail-enabled users, distribution groups and mail contacts. Only the recipients that match the filter you specify can be managed by the role assignees assigned that role assignment. An example of a filter statement is { Name -Eq "David" } where Name is the property on the recipient object that's being evaluated and David is the value you want to evaluate against the property. The -Eq comparison operator indicates that the value stored in the property must be equal to the value that was specified for the filter to be true. If the filter is true, that recipient is included in scope.

Recipient filter scopes are created by specifying the recipient filter to use with the RecipientRestrictionFilter parameter on the New-ManagementScope cmdlet. By default, the New-ManagementScope cmdlet creates regular scopes. If you want to create an exclusive scope, include the Exclusive switch along with the RecipientRestrictionFilter parameter.

When you create a recipient restriction filter, Exchange evaluates the filter you provided against every recipient object in the organization by default. If you want to limit which recipients the scope evaluates, you can use the RecipientRoot parameter along with the RecipientRestrictionFilter parameter. The RecipientRoot parameter accepts an OU. When you use the RecipientRoot parameter, Exchange evaluates only the recipients included in the specified OU against the filter you provided.

When you add a recipient filter scope to a role assignment, specify the name of the recipient scope in the CustomRecipientWriteScope parameter on the New-ManagementRoleAssignment if you're creating a new role assignment, or the Set-ManagementRoleAssignment cmdlet if you're updating an existing role assignment. Each role assignment can have one recipient scope, including predefined relative scopes. You can add one configuration scope to the same role assignment you added a recipient scope to.

For more information about filter syntax and for a full list of filterable recipient properties on recipients, see Understanding Management Role Scope Filters.

Configuration Scopes

The following are the two types of configuration scopes offered in Exchange 2010:

  • Server scopes   There are two types of server scopes, server filter scopes and server list scopes. Server configuration that can be managed if a server object is included in a server scope include Receive connectors, transport queues, server certificates, virtual directories, and so on.

    • Server filter scopes   Server filter scopes enable you to control which server objects role assignees can manage by evaluating one or more properties on a server object against a value that you specify in a filter statement. To create a server filter scope, use the ServerRestrictionFilter parameter on the New-ManagementScope cmdlet.

    • Server list scopes   Server list scopes enable you to control which server objects role assignees can manage by defining a list of servers that a role assignee can access. To create a server list scope, use the ServerList parameter on the New-ManagementScope cmdlet.

  • Database scopes   There are two types of database scopes, database filter scopes and database list scopes. Database configuration that can be managed if a database object is included in a database scope include database quota limits, database maintenance, public folder replication, whether a database is mounted, and so on. In addition to database configuration, database scopes can also be used to control which databases recipients can be created in. Database scopes are available only in Exchange 2010 SP1.

    • Database filter scopes   Database filter scopes enable you to control which database objects role assignees can manage by evaluating one or more properties on a database object against a value that you specify in a filter statement. To create a database filter scope, use the DatabaseRestrictionFilter parameter on the New-ManagementScope cmdlet.

    • Database list scopes   Database list scopes enable you to control which database objects role assignees can manage by defining a list of databases that a role assignee can access. To create a database list scope, use the DatabaseList parameter on the New-ManagementScope cmdlet.

For more information about filter syntax and for a full list of filterable server and database properties, see Understanding Management Role Scope Filters.

Server and database lists can be defined by specifying each server and database you want to include in their respective scopes. Multiple servers or databases can be specified in their respective scopes by separating the server and database names with commas.

When you add a server or database configuration scope to a role assignment, specify the name of the server or database configuration scope in the CustomConfigWriteScope parameter on the New-ManagementRoleAssignment cmdlet if you're creating a new role assignment, or the Set-ManagementRoleAssignment cmdlet if you're updating an existing role assignment. Each role assignment can only have one configuration scope.

In addition to controlling which databases role assignees can manage, database scopes also enable you to control which databases role assignees can create mailboxes on. This is separate from controlling which recipients a role assignee can manage. If a role assignee has permissions to create a new mailbox, mail-enable an existing user, or move mailboxes, you can further refine their permissions by using database scopes to control the database on which the mailbox is created, or which database a mailbox is moved to. Controlling which recipients a role assignee can manage is done using a recipient scope specified in the CustomRecipientWriteScope parameter on the New-ManagementRoleAssignment or Set-ManagementRoleAssignment cmdlet. Controlling which databases a mailbox can be created on or moved to is controlled using a database scope specified in the CustomConfigurationWriteScope parameter on the same cmdlets.

Note:
Automatic mailbox distribution can be controlled using database scopes. For more information, see Understanding Automatic Mailbox Distribution.

Exchange 2010 SP1 features may require either server scopes, database scopes, or both, to be managed. If a feature requires both server and database scopes to be managed, two role assignments must be created and assigned to the role assignee that should have access to manage the feature. One role assignment should be associated with the server scope, and one role assignment should be associated with the database scope.

Some cmdlets may use configuration scopes that aren't immediately obvious. The following table includes a list of cmdlets and the configuration scopes that you can use to control their usage. For cmdlets included in the recipients feature area, configuration scopes enable you to control on which databases recipients can be created. They don't control which recipients can be managed. The Required scopes column can contain the following:

  • Database   To run the cmdlet, the role assignee must be assigned a role assignment with a database scope that includes the database to be managed or the role's implicit configuration write scope must include the database to be managed.

  • Server   To run the cmdlet, the role assignee must be assigned a role assignment with a server scope that includes the server to be managed or the role's implicit configuration write scope must include the server to be managed.

  • Server or database   To run the cmdlet, the role assignee must be assigned a role assignment where either a database scope includes the database being managed, or where a server scope includes the server where the database is located. Or, the role's implicit configuration write scope must contain the database to be managed, or contain the server where the database is located, and the role assignment can't have a custom write scope.

  • Server and database   To run this cmdlet, the role assignee must be assigned two role assignments. The first role assignment must include a database scope that includes the database to be managed. The second role assignment must include a server scope that includes the server where the database is located. The role assignments can have custom configuration scopes defined, or the role assignments can inherit the implicit configuration write scope from the role. To inherit the implicit write scope from the role, the role assignment can't have a custom write scope.

Feature areas and applicable database and server scopes

Feature area Cmdlet Required scopes

Databases

Clean-MailboxDatabase

Database

Databases

Dismount-Database

Database

Databases

Mount-Database

Database

Databases

Move-DatabasePath

Server and database

Databases

Remove-MailboxDatabase

Server or database

Databases

Remove-PublicFolderDatabase

Server or database

Databases

Set-MailboxDatabase

Database

Databases

Set-PublicFolderDatabase

Database

High availability

Add-DatabaseAvailabilityGroupServer

Server

High availability

Add-MailboxDatabaseCopy

Server

High availability

Move-ActiveMailboxDatabase

Server

High availability

New-DatabaseAvailabilityGroup

Server

High availability

Remove-DatabaseAvailabilityGroup

Server

High availability

Remove-DatabaseAvailabilityGroupServer

Server

High availability

Remove-MailboxDatabaseCopy

Server or database

High availability

Resume-MailboxDatabaseCopy

Server or database

High availability

Set-DatabaseAvailabilityGroup

Server

High availability

Set-MailboxDatabaseCopy

Server or database

High availability

Start-DatabaseAvailabilityGroup

Server

High availability

Stop-DatabaseAvailabilityGroup

Server

High availability

Suspend-MailboxDatabaseCopy

Server or database

High availability

Update-MailboxDatabaseCopy

Server or database

Recipients

Connect-Mailbox

Database

Recipients

Enable-Mailbox

Database

Recipients

New-Mailbox

Database

Recipients

New-MoveRequest

Database

Troubleshooting

Test-MapiConnectivity

Database

Database scopes and pre-Exchange 2010 SP1 installations

Database scopes are new in Exchange 2010 SP1. The release to manufacturing (RTM) version of Exchange 2010 supports only recipient scopes and server configuration scopes. When you create a new database scope on an Exchange 2010 SP1 server, you'll receive the following warning:

Copy Code
WARNING: Database management scopes will only apply when connected to a server running Exchange 2010 SP1 or greater.
Exchange 2010 RTM servers will not apply any roles from a role assignment linked to a database scope. Database
management scopes will also not be visible to reporting cmdlets (Get-ManagementScope) when executed from an Exchange
2010 RTM server.

When you create a database scope, it's only applied to users who connect to servers running Exchange 2010 SP1. Users who connect to servers running Exchange 2010 RTM won't have any role assignments associated with database scopes applied to them. This means that any permissions provided by these role assignments won't be granted to users when they connect to Exchange 2010 RTM servers. Database scopes can't be created, removed, modified, or viewed from Exchange 2010 RTM servers.

A database scope can include any database in your Exchange organization. This includes Exchange Server 2007 and Exchange 2010 RTM. This enables you to control which databases, regardless of Exchange version, that users can manage. As with other database scopes, role assignments associated with database scopes that contain Exchange 2007 and Exchange 2010 RTM databases are only applied to users when they connect to an Exchange 2010 SP1 server.

Users who connect to an Exchange 2010 RTM server can view and modify role assignments associated with database scopes. This includes changing the configuration scope on an existing role assignment to a server scope if it's currently associated with a database scope. However, if the configuration scope on a role assignment is changed to a server scope and a user later wants to change it back to a database scope, or if the user wants to change the configuration scope to another database scope, the user must make the change while connected to an Exchange 2010 SP1 server. Users can only specify server scopes when they change the configuration scope on a role assignment if they're connected to an Exchange 2010 RTM server.