Understanding management role scopes

Applies to: Exchange Server 2013

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.

Note

This topic focuses on advanced RBAC functionality. If you want to manage basic Exchange 2013 permissions, such as using the Exchange admin center (EAC) to add and remove members to and from role groups, create and modify role groups, or create and modify role assignment policies, see Permissions.

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
    • Recipient Filter Scopes
    • Configuration 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 implicit configuration write scope determines what organizational, database, 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 2013, 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
ArchiveApplication Organization Organization OrganizationConfig OrganizationConfig
Audit Logs Organization Organization OrganizationConfig OrganizationConfig
Cmdlet Extension Agents Organization Organization OrganizationConfig OrganizationConfig
Data Loss Prevention 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
LegalHoldApplication 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 Import Export Organization Organization OrganizationConfig OrganizationConfig
Mailbox Search Organization Organization None None
MailboxSearchApplication 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
OfficeExtensionApplication Self Self OrganizationConfig OrganizationConfig
My Custom Apps Self Self OrganizationConfig OrganizationConfig
My Marketplace Apps Self Self 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
MyTeamMailboxes Organization Organization 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 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
TeamMailboxLifecycleApplication Self Self 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
UserApplication 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
WorkloadManagement Organization Organization OrganizationConfig OrganizationConfig

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

  • Custom Scopes

Predefined relative scopes

Exchange 2013 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 meet 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. 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 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 2013:

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

    • 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. If you have pre-Exchange 2010 SP1 servers in your organization, see the Database scopes and previous versions of Exchange section later in this topic.

    • 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.

Exchange 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 Dismount-Database Database
Databases Mount-Database Database
Databases Move-DatabasePath Server and database
Databases Remove-MailboxDatabase Server or database
Databases Set-MailboxDatabase Database
High availability Add-DatabaseAvailabilityGroupServer Server
High availability Add-MailboxDatabaseCopy Server
High availability Move-ActiveMailboxDatabase Server
High availability Remove-DatabaseAvailabilityGroupServer Server
High availability Remove-MailboxDatabaseCopy Server or database
High availability Resume-MailboxDatabaseCopy Server or database
High availability Set-MailboxDatabaseCopy Server or database
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 previous versions of Exchange

Database scopes were first introduced in Microsoft Exchange 2010 Service Pack 1 (SP1) and continue to be supported in Exchange 2013. Versions of Exchange prior to Exchange 2010 SP1 support only recipient scopes and server configuration scopes. When you create a new database scope on an Exchange 2010 SP1 or later server, you'll receive the following warning:

WARNING: Database management scopes will only be applied when a user connects to a server running Exchange 2010 SP1 or later. Servers running a version of Exchange prior to Exchange 2010 SP1 won't apply any roles from a role assignment linked to a database scope. Database management scopes also won't be visible to the Get-ManagementScope cmdlet when it's run from a pre-Exchange 2010 SP1 server.

When you create a database scope, it's only applied to users who connect to servers running Exchange 2010 SP1 or later. Users who connect to pre-Exchange 2010 SP1 servers 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 pre-Exchange 2010 SP1 servers. Database scopes can't be created, removed, modified, or viewed from pre-Exchange 2010 SP1 servers.

A database scope can include any database in your Exchange organization. This includes Exchange Server 2007, Exchange 2010, and Exchange 2013 servers. 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 databases are only applied to users when they connect to an Exchange 2010 SP1 or later server.

Users who connect to a pre-Exchange 2010 SP1 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 or later server. Users can only specify server scopes when they change the configuration scope on a role assignment if they're connected to a pre-Exchange 2010 SP1 server.