Permissions Information for Cmdlet Help and Procedural Topics
Applies to: Exchange Server 2010 Beta Topic Last Modified: 2008-12-04
The permissions model in Microsoft Exchange Server 2010 utilizes management roles to grant permissions to perform tasks and access information to administrators and users on all Exchange 2010 server roles excluding the Edge Transport server role. Management roles accomplish this by controlling the cmdlets, parameters and user interface (UI) elements that are available to you. This means that a user who is assigned the Organization Management role will be able to access cmdlets, parameters and fields in the console and the web interface that a user who is assigned the Recipient Management role can't.
Exchange 2010 provides several built-in management roles to that will suit the needs of many organizations. However some organizations may need to create new custom roles to better match your needs. These custom roles, when assigned to users, may change the cmdlets, parameters and fields that are available to the user performing a procedure. For more information about built-in roles, see Built-in Management Roles.
Because of the vast number of customized roles, the procedures and cmdlet help that's published with Exchange 2010 makes the assumption that the user reading the content is assigned one of the built-in management roles. The roles that are required to perform a procedure or to run a cmdlet are indicated in each topic.
Permissions on Edge Transport servers aren't controlled by management roles. Users who are members of the local Administrators group on the Edge Transport server can perform procedures on that server. This is why the permissions in some procedures and cmdlets will include management roles and Edge Transport specific information.
The sections below discuss in more detail how procedures and cmdlet help are documented and how you can determine whether a role you are assigned allows you to perform a procedure or run a cmdlet.
For more information on management roles and the permissions model used in Exchange 2010, see Overview of Permissions.
Procedural topics step you through the process of performing a task. These procedures can be anything from creating a new mailbox to configuring a dial plan on a unified messaging (UM) server. Because the procedures that are provided step you through specific scenarios that require specific cmdlets, parameters and UI fields to be available, we indicate which built-in roles are required to perform the procedure. These roles provide access to everything that you need to successfully complete the procedure.
When you read a procedural topic, you may see that more than one role is listed. This means that any of the listed roles can perform the procedure. For example, if both the Organization Management role and the Recipient Management role are listed, either role can perform the procedure. It doesn't mean that you need to have both roles. Some procedures may include Edge Transport server permissions in place of or in addition to management roles, which indicates they can be performed on Edge Transport servers.
While the topics indicate which built-in roles are required to perform the procedure, users who are assigned custom roles can also perform the procedure. The custom role must include all of the cmdlets and parameters, as defined by management role entries, which are used by the procedure.
To see which management role entries are associated with each built-in management role, see Management Role Cmdlet and Parameter Map.
To see what management role entries are associated with custom roles you've created, View Management Role Entries.
Cmdlet help topics display all of the parameters that are part of each cmdlet and also provide examples for how the cmdlet can be run. Every parameter that's part of the cmdlet is listed, regardless of the roles that are assigned to you. The examples that are provided for each cmdlet assume that you are assigned a role that has access to all of the parameters that are used.
As with procedural topics, cmdlet help topics list the roles that are needed to run a cmdlet. You only need to be assigned one of the roles in order to run a cmdlet. However, the parameters that you have access to on a cmdlet may differ depending on the roles assigned to you. If you're assigned more than one of the required roles, the combination of all the roles applies. This means that if RoleA provides access to Parameter1 and Parameter2, and RoleB provides access to Parameter3, you will have access to all three parameters.
|Many cmdlets have additional roles appended with the text - Tenant. Tenant roles apply to users who use Exchange services offered online by Microsoft. Roles without -Tenant text apply to users who have deployed Exchange 2010 in their on premises organization. Tenant and on premises roles can vary because of differences in configuration that is available to the user. Be sure that the roles required to run a cmdlet apply to your organization, either Tenant or on premises.|
Some cmdlets may include Edge Transport server permissions in place of or in addition to management roles, which indicates they can be run on Edge Transport servers.
While cmdlet help topics indicate which built-in roles are required to run a cmdlet, users who are assigned custom roles can also run the cmdlet. The custom role must include the cmdlet as a management role entry, and the management role entry must specify at least one parameter.
You can't determine the parameters on a cmdlet you have access to by viewing the cmdlet help. To see which parameters are available for the roles that are assigned to you, see Management Role Cmdlet and Parameter Map.
To see what management role entries are associated with custom roles you've created, see View Management Role Entries.