Users, contacts, and security groups are represented in Active Directory as objects. These objects have many attributes that determine how they are used. The most important attributes are the permissions assigned to the objects. Permissions grant or deny access to objects and resources. For example, you can grant a user the right to create public folders but deny that same user the right to create mail-enabled contacts.

Permissions assigned to an object can be applied directly to the object, or they can be inherited from another object. Generally, objects inherit permissions from parent objects. A parent object is an object that is above another object in the object hierarchy. However, you can override inheritance. One way to do this is to assign permissions directly to an object. Another way is to specify that an object shouldn’t inherit permissions.

In Exchange Server 2013, permissions are inherited through the organizational hierarchy. The root of the hierarchy is the domain. All other containers in the tree inherit the permissions of the domain container. Sometimes, however, you want to create structures that represent parts of the organization or you want to limit administrative access for part of the organization. To do this, you use organizational units. Organizational units (OUs) are containers for objects that you not only want to group together but that you also want to manage together.

For the management of Exchange information and servers, Exchange Server 2013 uses several predefined groups. These predefined security groups have permissions to manage the Exchange organization, Exchange servers, and Exchange recipient data in Active Directory. In Active Directory Users And Computers, you can view and work with the Exchange-related groups using the Microsoft Exchange Security Groups organizational unit (see Figure 9-1).

Figure 9-1. Using Active Directory Users And Computers to work with Exchange management groups.

Table 9-1 lists predefined groups created in Active Directory for Exchange Server 2013. As the table shows, each group has a slightly different usage and purpose. Several of the groups are used by Exchange servers. These groups are Exchange Servers, Exchange Trusted Subsystem, Exchange Windows Permissions, and ExchangeLegacyInterop. As indicated in the table, you use the other groups for role-based access control and assigning management permissions. Role groups marked with an asterisk (*) are also available with Exchange Online.

Table 9-2 lists predefined groups and administrative roles used with Exchange Online and Office 365. These groups and roles are used for role-based access controls and assigning management permissions. However, HelpDeskAdmins and TenantAdmins aren’t managed in Exchange Online. Instead, you add users to the related Office 365 role to get the desired permissions.

When working with Exchange-related groups, keep in mind that Organization Management grants the widest set of Exchange management permissions possible. Members of this group can perform any Exchange management task, including organization, server, and recipient management. Members of the Recipient Management group, on the other hand, can manage only recipient information, and Public Folder Management can manage only public folder information. View-Only Organization Management can view Exchange organization, server, and recipient information, but this group cannot manage any aspects of Exchange.

Table 9-3 provides an overview of the default group membership for the Exchange groups in an on-premises organization. Membership in a particular group grants the member the permissions of the group. Exchange groups that aren’t listed don’t have any default members or membership.

With Exchange Online, the TenantAdmins group is a member of the Organization Management role group and inherits its permissions from this role group. Rather than add members directly to TenantAdmins, you add members to this role by granting the Global Administrator role to users in Office 365 Admin Center.

Similarly, the HelpDeskAdmins group is a member of the View-Only Organization Management role group and inherits its permissions from this role group. Rather than add members directly to HelpDeskAdmins, you add members to this role by granting the Global Administrator role to users in Office 365 Admin Center.

To grant Exchange management permissions to a user or group of users, all you need to do is make the user or group a member of the appropriate Exchange management group. For on-premises Exchange, one of the tools you can use to manage users and groups is Active Directory Users And Computers. You can make users, contacts, computers, or other group members part of an Exchange management group by completing the following steps:

You can remove a user, contact, computer, service account, or other group from an Exchange management group by completing the following steps:

For both on-premises Exchange and Exchange Online, you use Exchange Admin Center to manage membership in Exchange role groups. When you are managing the organization, select Permissions in the Feature pane and then select Admin Roles to work with Exchange role groups. When you select a role, the right-most pane provides a description of the role, lists the assigned roles, and also shows the current members (see Figure 9-4). While working with this view, you can double-tap or double-click a group entry to view and manage its membership.

Figure 9-4. Using Exchange Admin Center to work with Exchange role groups.

You use Office Admin Center to manage membership in Office 365 role groups. When you are managing the Office 365 service, select Users And Groups in the Feature pane and then select Active Users to view a list of all active users in the organization. When you select a user, the properties page for the user is displayed. Next, select Settings in the Feature pane, as shown in Figure 9-5. If you want the user to have administrator privileges, complete the following steps:

Figure 9-5. Using Office 365 Admin Center to work with Office 365 roles.

Active Directory objects are assigned a set of permissions. These permissions are standard Microsoft Windows permissions, object-specific permissions, and extended permissions.

Table 9-4 summarizes the most common object permissions. Keep in mind that some permissions are generalized. For example, with Read Value(s) and Write Value(s), Value(s) is a placeholder for the actual type of value or values.

Table 9-5 summarizes Exchange-specific permissions for objects. If you want to learn more about other types of permissions, I recommend that you read Windows Server 2012 Pocket Consultant (Microsoft Press, 2012).

Although you can use standard Windows permissions, object-specific permissions, and extended permissions to control Exchange management and use, Microsoft recommends that you use the new role-based access controls instead. My recommendation is to use the role-based access controls whenever possible in place of specific permissions. However, you might want to duplicate the old style permissions during your transition from Exchange 2007 to Exchange 2013. This can simplify the transition by allowing you to configure new Exchange groups, such as Organization Management or Recipient Management, exactly as they are configured in the Exchange 2007 organization. In this case, after you’ve ensured permissions are configured as required for proper operations and support of any applications that work with Exchange data, you can start implementing a role-based model for your organization.

In Active Directory, different types of objects can have different sets of permissions. Different objects can also have general permissions that are specific to the container in which they’re defined. For troubleshooting or fine-tuning your environment, you might occasionally need to modify advanced permissions. You can set advanced permissions for Active Directory objects by following these steps:

Role-based access control is a permissions model that uses role assignment to define the management tasks a user or group of users can perform in the Exchange organization. Exchange defines many built-in management roles that you can use to manage your Exchange organization. Each built-in role acts as a logical grouping of permissions that specify the management actions that those assigned the role can perform. You also can create custom roles.

You can assign roles to role groups or directly to users. You also can assign roles through role policies that are then applied to role groups, users, or both. By assigning roles, you grant permission to perform management tasks.

At the top of the permissions model is the role group, which is a special type of security group that has been assigned one or more roles. Keep the following in mind when working with role-based permissions:

As Table 9-1 showed previously, Exchange 2013 and Exchange Online include a number of predefined role groups. These role groups are assigned fixed management roles by default. As a result, you do not need to explicitly add roles to these groups to enable management, nor can you add or remove roles associated with the built-in groups. You can, however, manage the members of the predefined role groups using the procedures discussed previously. You can also create your own role groups and manage the membership of those groups.

When you assign a role to a group, the management scope determines where in the Active Directory hierarchy that objects can be managed by users assigned a management role. The scope is either implicitly or explicitly assigned. Implicit scopes are the default scopes that apply based on a particular type of management role.

Table 9-6 lists key management roles with an organization scope. A role with an organization scope applies across the whole Exchange organization. Table 9-7 lists key management roles with an organization scope that apply to individual servers. Table 9-8 lists key management roles with a user scope. A role with a user scope applies to an individual user. When you create a role group, you also can set an explicit scope, such as for objects in the Customer Service organizational unit or objects in the Technology organizational unit.

Role assignment policies grant users permissions to configure their Outlook Web App options and perform limited management tasks. When you install Exchange 2013, the setup process creates the Default Role Assignment Policy and sets this as the default for all new mailboxes. This policy grants users the MyBaseOptions, MyContactInformation, MyDistributionGroupMembership, and MyVoiceMail roles, but it does not grant users the MyDistributionGroups and MyProfileInformation roles.

Exchange Online has a Default Role Assignment policy as well. This default policy, assigned to all Exchange Online users, grants all of the management roles. As discussed later in this chapter, you can create other role assignment policies as well.

By default, members of the Organization Management group can manage any role group in the Exchange organization. Anyone designated as a manager of a role group can manage the role group. You assign a user as a manager of a role group using the -ManagedBy parameter, which can be set when you create or modify a role group.

To view the currently available role groups and the roles they’ve been assigned, select Permissions in the feature pane and then select Admin Roles. As shown in Figure 9-7, when you select a role group, the details pane lists the assigned roles and members.

Figure 9-7. Viewing the role groups and the assigned roles and members of a selected group.

To create a role group, complete the following steps:

In the shell, commands you use to work with role groups include the following:

You use New-RoleGroup to create role groups. When you create a role group, you must specify the group name and the roles assigned to the group. You should also specify the managers and members of the group. The managers and members can be individual users or groups identified by their display name, alias, or distinguished name. If you want to specify more than one manager or member, separate each entry with a comma. The following example creates the Special Recipient Management role group to allow members of the group to manage (but not create) recipients:

New-RoleGroup -Name "Special Recipient Management"
-Roles "mail recipients", "recipient policies"
-ManagedBy "juliec", "tylerk", "ulij"
-Member "mikeg", "lylep", "rubyc", "yus"

By default, the scope of the role group is the organization. You can also set a specific scope for an organizational unit. The following example creates a role group named LA Recipient Management and sets the scope to the LA Office organizational unit to allow members of the group to manage recipients in the LA Office organizational unit:

New-RoleGroup -Name "LA Recipient Management"
-Roles "mail recipient creation", "mail recipients", "recipient policies"
-ManagedBy "LA Managers" -Member "LA Help Desk"
-RecipientOrganizationalUnitScope "LA Office"

A linked role group links the role group to a universal security group in another forest. Creating a linked role group is useful if your Exchange servers reside in a resource forest and your users and managers reside in a separate user forest. If you create a linked role group, you can’t add members directly to it. You must add the members to the universal security group in the foreign forest.

When you create linked role groups, you use the -LinkedDomainController parameter to specify the fully qualified domain name or IP address of a domain controller in the foreign forest. This domain controller is used to get security information for the foreign universal security group, which is specified by the -LinkedForeignGroup parameter. If you use the -LinkedDomainController parameter, you must specify a foreign universal security group with the -LinkedForeignGroup parameter, and you can’t use the -Members parameter. Optionally, use the -LinkedCredential parameter to specify credentials to use to access the foreign forest. To pass in the credentials, use a Credential object.

The following example creates a linked role group that enables the members of the Chicago Managers universal security group to manage recipients located in the Chicago office:

$cred = Get-Credentials
New-RoleGroup -Name "Chicago Recipient Managers"
-LinkedDomainController corpserver26.cpusers.cpandl.com
-LinkedCredential $cred -LinkedForeignGroup "Chicago Managers"
-CustomRecipientWriteScope "Chicago Recipients" -Roles "mail recipients"

In this example, Chicago Managers is a group created in the user forest and the administrator is logged on to the resource forest. When PowerShell reads the Get-Credentials command, a prompt for the user name and password for the user forest appears.

Role groups are created as universal security groups in the Active Directory database. In Active Directory Users And Computers, you’ll find role groups in the Microsoft Exchange Security Groups container. After you create a role group, you can manage it using Active Directory Users And Computers or Exchange Management Shell. The management tasks you can perform depend on which tool you are using. In Active Directory Users And Computers, you can manage group membership, rename the group, or delete the group. Additional tasks you can perform when you use Exchange Management Shell include setting managers and modifying role assignments.

If you type Get-RoleGroup at the Exchange Management Shell prompt, you see a list of all role groups defined in the Exchange organization to which you are connected. You can filter the output in a variety of ways using standard PowerShell filtering techniques. Get-RoleGroup also has a -Filter parameter that you can use to filter the output according to specific criteria you set. The following example looks for a role group named CS Recipient Management and lists all its properties:

Get-RoleGroup -filter {Name -eq "CS Recipient Management"} |
format-list

You can use Set-RoleGroup to change the name of a role group or to define a new list of managers. To delete a role group, use Remove-RoleGroup.

By default, members of the Organization Management group can manage the membership of any role group in the Exchange organization. Anyone designated as a manager of a role group can manage the membership of that role group as well.

In the shell, commands you use to configure role group membership include the following:

You add members to a role group using Add-RoleGroupMember. When you add a member to a role group, the member is given the effective permissions provided by the management roles assigned to the role group. If the role group has designated managers, you must use the -BypassSecurityGroupManagerCheck parameter or be a role group manager to override the security group management check. The following example adds a user to the LA Recipient Management role group:

Add-RoleGroupMember -Identity "LA Recipient Management"
-Member "joym"

Whether you are working with Exchange Online or on-premises Exchange at the shell prompt, don’t forget that all the features of PowerShell are at your disposal. The following example lists all users with mailboxes in the Technology department and adds them to the Technology Management role group:

Get-User -Filter { Department -Eq "Technology" -And -RecipientType
-Eq "UserMailbox" } | Get-Mailbox | Add-RoleGroupMember
"Technology Management"

You can list members of a particular role group using Get-RoleGroupMember. Members are listed by name and recipient type as shown in the following example and sample output:

Get-RoleGroupMember -Identity "CS Recipient Management"

Name                           RecipientType
----                           -------------
Riis Anders                        UserMailbox
Darren Waite                       UserMailbox

You can delete role group members using Remove-RoleGroupMember. When you remove a member from a role group, the user or group of users can no longer perform the management tasks made available by that role group. However, keep in mind that the user or group of users might be a member of another role group that grants management permissions. If so, the user or group of users will still be able to perform management tasks.

You can assign built-in or custom roles to users, role groups, and universal security groups in one of two ways:

Directly assigning roles is accomplished using role assignment commands. By adding, removing, or modifying role assignments, you can control the management tasks that users can perform. Although you can assign roles directly to users or universal security groups, this approach increases the complexity of the permissions model in your Exchange organization. A more flexible solution is to assign roles via assignment policy. Assigning roles via assignment policy requires you to do the following:

Management roles define the specific tasks that can be performed by the members of a role group assigned the role. A role assignment links a management role and a role group. Assigning a management role to a role group grants members of the role group the ability to perform the management tasks defined in the management role. Role assignments can use management scopes to control where the assignment can be used.

In the shell, commands you use to work with role assignment include the following:

You can list role assignments using Get-ManagementRoleAssignment. You use New-ManagementRoleAssignment to assign roles. The following example assigns the Retention Management role to the Central Help Desk group:

New-ManagementRoleAssignment -Name "Central Help Desk_Retention"
-Role "Retention Management" -SecurityGroup "Central Help Desk"

The following example assigns the Mail Recipients role to members of the Marketing Help Desk group and restricts the write scope to the Marketing organizational unit:

New-ManagementRoleAssignment -Name "Marketing_Options"
-Role "Mail Recipients" -SecurityGroup "Marketing Help Desk"
-RecipientOrganizationalUnitScope "cpandl.com/Marketing"

This allows users who are members of the Marketing Help Desk group to manage existing mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups in the Marketing organizational unit. This does not enable these users to create recipients in this organizational unit. To create recipients, the users need to be assigned the Mail Recipient Creation role.

You can modify role assignment using Set-ManagementRoleAssignment. The following example disables the Central Help Desk_Retention role assignment:

Set-ManagementRoleAssignment -Identity "Central Help Desk_Retention"
-Enabled $False

When you disable a role assignment, the users assigned the role can no longer perform the management tasks granted by the role. However, keep in mind that a user might have been granted the permission in another way. By disabling a role assignment rather than removing it, you can easily enable the role assignment again as shown in the following example:

Set-ManagementRoleAssignment -Identity "Central Help Desk_Retention"
-Enabled $True

However, if you are sure you no longer want to use a particular role assignment, you can remove it using Remove-ManagementRoleAssignment as shown in the following example:

Remove-ManagementRoleAssignment -Identity "Central Help Desk_Retention"

When you create a new assignment policy, you can assign it to users using the New-Mailbox, Set-Mailbox, or Enable-Mailbox cmdlet. If you make the new assignment policy the default assignment policy, it’s assigned to all new mailboxes that don’t have an explicitly designated assignment policy. After you create an assignment policy, you must assign it at least one management role for permissions to apply to a mailbox. Without any roles assigned to it, users assigned the policy won’t be able to manage any of their mailbox configurations. To assign a management role, use New-ManagementRoleAssignment.

In the shell, commands you use to work with role assignment policy include the following:

You can list role assignment policies using Get-RoleAssignmentPolicy. Rather than view all available assignment policies, you can easily filter the output to look for default assignment policies. Here is an example:

Get-RoleAssignmentPolicy | Where { $_.IsDefault -eq $True }

You use New-RoleAssignmentPolicy to create role assignment policies. The following example creates the Standard User Policy and assigns it as the default:

New-RoleAssignmentPolicy -Name "Standard User Policy"

When you create a new assignment policy, you can assign it to users using New-Mailbox, Set-Mailbox, or Enable-Mailbox as shown in the following example:

Set-Mailbox -Identity "tommyj" -RoleAssignmentPolicy "Standard User
Policy"

If you make the new assignment policy the default assignment policy, it’s assigned to all new mailboxes that don’t have an explicitly designated assignment policy. You can specify that a policy is the default when you create it using -IsDefault. To designate a policy as the default use Set-RoleAssignmentPolicy as shown in this example:

Set-RoleAssignmentPolicy -Identity "Standard User Policy" -IsDefault

After you create an assignment policy, you must assign at least one management role to it for it to apply permissions to a mailbox. Without any roles assigned to it, users assigned the policy won’t be able to manage any of their mailbox configuration. To assign a management role, use New-ManagementRoleAssignment.

You can remove policies using Remove-RoleAssignmentPolicy. The assignment policy you want to remove can’t be assigned to any mailboxes or management roles. Also, if you want to remove the default assignment policy, it must be the last assignment policy. Because of this, you need to use Set-Mailbox to change the assignment policy for any mailbox that’s assigned the assignment policy before you can remove it. If the assignment policy is the default assignment policy, select a new default assignment policy using Set-RoleAssignmentPolicy before you remove the old default policy. You don’t need to do this if you’re removing the last assignment policy. Additionally, keep in mind that you can use Remove-ManagementRoleAssignment to remove any management role assignments assigned to a policy.

With this in mind, the following series of examples show how you can modify and remove assignment policy. The first example removes the assignment policy called “Standard User Policy” by finding all of the mailboxes assigned the policy and then assigning a different policy:

Get-Mailbox | Where {$_.RoleAssignmentPolicy -Eq "Standard User Policy"}
 | Set-Mailbox -RoleAssignmentPolicy "New User Policy"

Next, you can remove all the role assignments assigned to an assignment policy:

Get-ManagementRoleAssignment -RoleAssignee "Standard User Policy" |
Remove-ManagementRoleAssignment

Afterward, you can remove the assignment policy by entering the following:

Remove-RoleAssignmentPolicy "Standard User Policy"

Exchange 2013 and Exchange Online user roles control the settings that users can configure on their own mailboxes and on distribution groups they own. These settings determine whether users can:

The Exchange organization has a default role assignment policy that grants users permission to configure all user-manageable settings. You can create one or more additional role assignment policies and assign them to users at any time using Exchange Admin Center.

To view the currently available policies, select Permissions in the feature pane and then select User Roles as shown in Figure 9-9. To create a policy, tap or click New. In the Role Assignment Policy dialog box, type a descriptive name for the policy, such as All Standard Users. To grant a role to users, select the related check box. To not grant a role to users, clear the related check box.

Figure 9-9. Configuring user roles to manage permissions.

Finally, tap or click Save to create the policy and update the organization settings. It may take several minutes to update the organization settings. If an error occurs, try to create the policy again before you begin any troubleshooting. Sometimes, a complex process won’t be completed fully the first time and retrying will resolve the problem.

To assign a policy to a user, follow these steps:

The built-in roles were listed previously in Table 9-6 Table 9-7 Table 9-8. The built-in roles are fixed, and you cannot create role entries to define additional management tasks for built-in roles. You can, however, create your own custom roles based on built-in roles and then extend the custom roles as necessary to meet the needs of your organization. In this way, custom management roles allow you to do things you can’t do with the built-in roles.

Commands you use to create custom roles and to view any existing roles include the following:

To view management roles, you use Get-ManagementRole. Entering Get-ManagementRole by itself without parameters lists all the roles in your organization. Additional options include using:

The following example lists all the roles associated with the Mail Recipient Creation role:

Get-ManagementRole "Mail Recipient Creation" -Recurse

You can create your own custom roles using New-ManagementRole. New roles can either be empty top-level roles or based on an existing parent role. For example, the following command creates an empty role:

New-ManagementRole -Name "Change Management"
-UnscopedTopLevel

In the following example, a new role is created based on the Organization Client Access role:

New-ManagementRole -Name "Organization Client Access View-Only"
-Parent "Organization Client Access"

After you create a role based on another role, you might need to remove role entries that are not required. For example, the following command ensures the Organization Client Access View-Only role grants view-only permission for Client Access information by removing any entries for commands that don’t begin with Get:

Get-ManagementRoleEntry "Organization Client Access View-Only*" |
Where { $_.Name -NotLike "Get*" } | Remove-ManagementRoleEntry

To remove a custom role, you use Remove-ManagementRole. You can remove a role by name as shown in the following example:

Remove-ManagementRole "Organization Client Access View-Only"

Using the -Recurse parameter, you can remove all child roles of a role. Using the -UnscopedTopLevel parameter, you can remove an unscoped top-level role. You also can use Get-ManagementRole to obtain a list of roles to remove as shown in this example:

Get-ManagementRole *MyTestRole* | Remove-ManagementRole

Every management role has a management scope that determines where in Active Directory objects can be viewed or modified by users assigned the management role. Management scopes can be defined as either regular or exclusive. Regular scopes can be either implicitly or explicitly created. They are simply the standard type of scope, and they define the set of recipients that can be managed. Exclusive scopes, on the other hand, must always be explicitly created, and they allow 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.

Scopes can be:

Scopes inherited from management roles are called implicit scopes, while predefined and custom scopes are called explicit scopes. Implicit scopes include:

Commands you use to work with scopes include the following:

You use Get-ManagementScope to retrieve a list of existing management scopes. If you want to list only exclusive scopes, use the -Exclusive parameter. If you want to list only management scopes that aren’t associated with role assignments, use the -Orphan parameter, as shown here:

Get-ManagementScope -Orphan

You can create custom management scopes using New-ManagementScope. After you create a regular or exclusive scope, you need to associate the scope with a management role assignment. One way to do this is to use New-ManagementRoleAssignment.

You define scopes using recipient restriction filters, explicit server lists, or server restriction filters. For example, the following command creates the Sales Team scope that applies only to mailboxes located in the Sales organizational unit:

New-ManagementScope -Name "Sales Team Scope" -RecipientRoot
"cpandl.com/Sales" -RecipientRestrictionFilter {RecipientType -eq
"UserMailbox"}

The following example creates a scope that applies only to MailServer14 and MailServer18:

New-ManagementScope -Name "Main Server Scope" -ServerList
"MailServer14", "MailServer18"

The following example creates a scope that applies only to servers in the Active Directory site called Seattle-First-Site:

New-ManagementScope -Name "Seattle Site Scope" -ServerRestrictionFilter
{ServerSite -eq "Seattle-First-Site"}

Exclusive scopes work a bit differently. When an exclusive scope is created, all users are immediately blocked from modifying the recipients that match the exclusive scope until the scope is associated with a management role assignment. If other role assignments are associated with other exclusive scopes that match the same recipients, those assignments can still modify the recipients. For example, the following command creates a Protected Managers exclusive scope for users that contain the string “Manager” in their job titles:

New-ManagementScope -Name "Protected Managers"
-RecipientRestrictionFilter { Title -Like "*Manager*" } -Exclusive

After creating an exclusive scope, you then need to associate it with a management role assignment that assigns the appropriate management roles to the appropriate role group or groups. In the following example, members of the Level 5 Administrators security group are granted permission to work with Protected Manager mailboxes:

New-ManagementRoleAssignment -Name "Level 5 Administrators_Mail
Recipients" -SecurityGroup "Level 5 Administrators" -Role "Mail
Recipients" -CustomRecipientWriteScope "Protected Managers"

You use Set-ManagementScope to modify the settings of a management scope. If you change a scope that has been associated with management role assignments, the updated scope applies to all of the associated role assignments. To remove a management scope, you can use Remove-ManagementScope. However, you can’t remove a management scope if it’s associated with a role assignment.

Role entries determine the management actions that members of a role group can perform. You create a role entry by specifying the permitted management command and any permitted command parameters.

Assigning a management role to a role group is essentially similar to creating the related role entries that allow a user or group to perform related management tasks. Another way to grant permission to perform a management action is to create a management role entry and add it to a management role. However, keep in mind that you can’t add role entries to built-in roles.

Commands you use to work with role entries include:

Every management role must have at least one management role entry. A role entry consists of a single cmdlet and its parameters, a script, or a special permission that you want to make available. If a cmdlet or script doesn’t appear as an entry on a management role, that cmdlet or script isn’t accessible via that role. Similarly, if a parameter isn’t specified in a role entry, the parameter on that cmdlet or script isn’t accessible via that role.

The way you create and work with role entries depends on whether they are based on the built-in roles or unscoped roles. Roles based on built-in roles can contain only role entries that are Exchange cmdlets. To use custom scripts or non-Exchange cmdlets, you need to add them as unscoped role entries to an unscoped top-level role.

You can’t add management role entries to child roles if the entries don’t appear in parent roles. For example, if the parent role doesn’t have an entry for New-Mailbox, the child role can’t be assigned that cmdlet. Additionally, if Set-Mailbox is on the parent role but the -Database parameter has been removed from the entry, the -Database parameter on the Set-Mailbox cmdlet can’t be added to the entry on the child role. With this in mind, you need to carefully choose the parent role to copy when you want to create a new customized role.

Role entry names are a combination of the management role that they’re associated with and the name of the cmdlet or script that you want to make available. The role name and the cmdlet or script are separated by a backslash character (). For example, the role entry name for the New-Mailbox cmdlet on the Mail Recipient Creation role is Mail Recipient CreationNew-Mailbox.

You can use the wildcard character (*) in the role entry name to return all of the role entries that match the input you provide. The wildcard character can be used with role names as well as with cmdlet or script names. For example, you can use ** to return a list of all role entries for all roles, *New-Mailbox to return a list of all role entries that contain the New-Mailbox cmdlet, or Mail Recipient Creation* to return a list of all role entries on the Mail Recipient Creation role.

When you create a role entry, you need to specify all of the parameters that can be used. Exchange will try to verify the parameters that you provide when you add the role entry. Only the parameters that you include are available to the users assigned to the role. You need to update role entries manually if parameters available for cmdlets or scripts change.

To avoid errors, keep the following in mind:

You use Get-ManagementRoleEntry to list role entries that have been configured on roles. For example, the following command lists all the role entries that exist on the Mail Recipient Creation role:

Get-ManagementRoleEntry "Mail Recipient Creation*"

You also can list all the role entries that contain a particular command, as shown here:

Get-ManagementRoleEntry *Get-Recipient

You can list role entries that match specific criteria such as role name or cmdlet name. Using Add-ManagementRoleEntry, you can specify role entries to add to a role. You specify the role entry to add using the -Identity parameter and the basic syntax for the identity as RoleNameCmdletName. Role entries are either based on a parent role entry or are unscoped (the default), specified using the -ParentRoleEntry or -UnScopedTopLevel parameter, respectively. The -Role parameter specifies the role to which the new role entry is added.

For example, the following command adds a role entry for Get-Mailbox to the LA Recipient Managers role:

Add-ManagementRoleEntry -Identity "LA Recipient ManagersGet-Mailbox"

This entry assigns permission for the Get-Mailbox cmdlet to members of the LA Recipient Managers role. You can specify the exact parameters that are permitted as shown in the following example:

Add-ManagementRoleEntry -Identity "LA Recipient ManagersGet-Mailbox"
-Parameters Archive, Identity, Filter, OrganizationalUnit, SortBy

You can also assign permission for multiple commands. Consider the following example:

Get-ManagementRoleEntry "Mail RecipientsGet-Mailbox*" |
Add-ManagementRoleEntry -Role "Central Help Desk"

Here, Get-ManagementRoleEntry is used to retrieve a list of all the role entries for the Mail Recipients role that begin with the string “Get-Mailbox” in the cmdlet name, and then add them to the Central Help Desk role using the Add-ManagementRoleEntry cmdlet. The role entries are added to the child role exactly as they’re configured on the parent role, Mail Recipients.

You use Set-ManagementRoleEntry to change the available parameters on an existing management role entry. With the -AddParameter parameter, the parameters you specify are added to the role entry. With the -RemoveParameter parameter, the parameters you specify are removed from the role entry. Otherwise, only the parameters you specify are included in the role entry. For example, with Get-Mailbox you might want users to be able to specify a server and limit the result set size, and you can do this by adding the -Server and -ResultSize parameters as shown in this example:

Set-ManagementRoleEntry -Identity "LA Recipient ManagersGet-Mailbox"
-AddParameter Server, ResultSize

To remove all parameters, set -Parameters to $Null and don’t use either -AddParameter or -RemoveParameter as shown in this example:

Set-ManagementRoleEntry -Identity "LA Recipient ManagersGet-Mailbox"
-Parameters $Null

You use Remove-ManagementRoleEntry to remove role entries. However, you can’t remove role entries from built-in management roles.

The shared permissions model is the default. With the shared permissions model, management of Exchange and Active Directory are not separated within the Exchange management tools. Administrators can use the Exchange management tools to create security principals in Active Directory. In this model, the Mail Recipient Creation role allows administrators to create security principals, such as Active Directory users, and the Security Group Creation And Membership role allows administrators to create security groups and manage security group membership.

Two Exchange role groups have these roles by default:

If you want other users to be able to create security principals and manage the membership of security groups, you have several choices. You can assign the Mail Recipient Creation role, the Security Group Creation And Membership role, or both roles to other role groups, users, and security groups. You also can make the appropriate users, security groups, or both members of the appropriate role group.

An option for extending the shared permissions model is to grant the Security Group Creation And Membership role to the Recipient Management role group. This approach:

I recommend this configuration only when Exchange administrators need to create security groups as part of their regular routine. With this option, you can continue to grant the Mail Recipient Creation role, the Security Group Creation And Membership role, or both roles to other role groups, users, and security groups as well.

Some organizations require strict management of who can create security principals, and this is where split permissions are useful. With split permissions, you remove the default settings that allow members of Recipient Management and Organization Management to create security principals in Active Directory. Thereafter the process of creating security principals and the process of configuring Exchange attributes for security principals are completely separate. As a result, Active Directory administrators are responsible for creating security principals and Exchange administrators are responsible for configuring the Exchange attributes associated with security principals.

With split permissions, you have two configuration options. You can use:

Each Exchange organization has one and only one permissions model. Your Exchange organization is either configured to use a shared model that allows for RBAC split permissions or it’s configured to use Active Directory split permissions. During installation of Exchange 2013, you can specify whether you want to use Active Directory split permissions. If you select this option, the shared permissions and RBAC split permissions models are not available.

To move between the shared model that allows for RBAC split permissions and the Active Directory split permissions model or vice versa, you must run the following command from the Exchange 2013 installation media:

setup.exe /PrepareAD /ActiveDirectorySplitPermissions: {$true|$false}

where $true sets the organization to use Active Directory split permissions and $false sets the organization to use the shared model that allows for RBAC split permissions. You have to prepare Active Directory in each instance because many changes to groups and group membership will be made in the background. Next, you must either wait for Active Directory to replicate an access token to all servers running Exchange 2010 or Exchange 2013, or you must restart all servers running Exchange 2010 or Exchange 2013. Finally, you must implement your permissions model. A step-by-step procedure with examples follows:

When you use split permissions, only members of the group created in the previous procedure will be able to use the Exchange management tools to:

This means Exchange administrators and others won’t be able to use New-Mailbox, New-MailContact, New-MailUser, New-RemoteMailbox, Remove-Mailbox, Remove-MailContact, Remove-MailUser, or Remove-RemoteMailbox. Additionally, with Active Directory split permissions, only members of the group will be able to create distribution groups and manage their membership. Thus, only members of the group will be able to use Add-DistributionGroupMember, New-DistributionGroup, Remove-DistributionGroup, Remove-DistributionGroupMember, and Update-DistributionGroupMember.