Understanding Management Role Scopes

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:

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

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.