2. Creating roles for specific tasks
It is entirely possible that your deployment might require a
new role to perform very specific tasks. A new role is better than
attempting to modify one of the built-in roles included in Exchange
because you can never be sure that a change made to one of these roles
might not affect or break functionality in some way or create
difficulties during a future software upgrade. In addition, by creating
a new role, you isolate your changes in one place and therefore make it
easier to understand and to debug any problems that might occur.
You can create a new role for this purpose by using the following rules:
Custom roles have to be created using one of the built-in roles as a parent; they cannot be created from another custom role.
A child role cannot hold more rights than its parent.
It
is usually better to start with a limited set of cmdlets and gradually
add cmdlets until the set necessary to perform the desired tasks is
determined rather than attempting to slim down a large set of cmdlets.
The
set of cmdlets that is included in a role must include a Get cmdlet to
match every Set or Remove cmdlet. For example, if you look at the
MyProfileInformation role that allows users to update their own
personal contact data through the Options section of Outlook Web App,
you’ll see that it includes entries for the Get-Mailbox cmdlet to
retrieve the current personal data and for the Set-Mailbox and Set-User
cmdlets to allow the user to update the data. Look at the details of
the individual role entries for Set-Mailbox and Set-User; you will see
that the parameters are restricted to a limited set including the
display name, first name, initials, and so on.
As
an example, assume that you want your help desk staff to be able to
update the personal information for recipients because you don’t want
users doing this through Outlook Web App. The first step is to discover
which built-in role to use as the parent. You could choose
MyProfileInformation or Mail Recipients because both roles allow access
to user properties. In this case, base your custom role on Mail
Recipients.
New-ManagementRole –Name 'Help Desk User Updates' –Parent 'Mail Recipients'
The
built-in Mail Recipients role includes a very large number of cmdlets
that you don’t want to make available to the role holders, so you
remove everything except the Get-Mailbox cmdlet because it’s easier to
put back the few cmdlets you need than to edit them in place.
Get-ManagementRoleEntry –Identity 'Help Desk User Updates\*' | Where {$_.Name –ne 'Get-Mailbox'} |
Remove-ManagementRoleEntry –Confirm:$FalseYou
can now add the cmdlets to your role and specify the parameters that
you’ll allow with each cmdlet. You want to allow the help desk team to
update a number of user settings, so you need to permit access to six
cmdlets in all (five in addition to the one left after you remove the
set inherited from the parent role). Some trial and error by testing
whether you can perform the desired task through EAC and EMS might be
necessary before you determine the exact cmdlet set you require:
Add-ManagementRoleEntry 'Help Desk User Updates\Set-Mailbox' –Parameters Identity, DisplayName, SimpleDisplayName
Add-ManagementRoleEntry 'Help Desk User Updates\Get-User'
Add-ManagementRoleEntry 'Help Desk User Updates\Set-User'
–Parameters Identity, FirstName, LastName, Initials, Office, Phone, MobilePhone, Department, Manager
Add-ManagementRoleEntry 'Help Desk User Updates\Get-CASMailbox'
Add-ManagementRoleEntry 'Help Desk User Updates\Set-CASMailbox'
–Parameters Identity, IMAPEnabled, OWAEnabled, OWAMailboxPolicy
You can now check that the custom Help Desk User Updates role includes the correct cmdlets and parameters with:
Get-ManagementRoleEntry 'Help Desk User Updates\*' | Format-Table
Assuming
everything looks good, you are now ready to assign the new role to
users or to security groups. Exchange already adds the Help Desk
security group to Active Directory to use with its Help Desk management
role. You can add your new management role to this role group as
follows:
New-ManagementRoleAssignment –Role "Help Desk User Updates" –SecurityGroup "Help Desk"
The next time a member of the Help Desk security group logs on, he will pick up the new role assignment.
3. Specific scopes for role groups
As discussed earlier, Exchange supports the concept of scoping
for a role group. When you set a scope for a role group, members of the
role group can manage only the objects covered by the defined scope.
The most common scope is set by an OU in Active Directory, meaning that
a role assignment made with this scope can process any object in the
OU. You can create the scope in three ways:
RecipientOrganizationalUnitScope parameter. Specify an explicit OU in Active Directory.
CustomRecipientWriteScope parameter. Create
a management scope with the New-ManagementScope cmdlet that points to
an OU in Active Directory. This approach is preferable if you will
reuse the scope several times. It also enables you to give the scope a
human-friendly name that might be more recognizable than the name of
the OU.
Database name. Exchange enables you to create scopes based on database names.
For
example, a large organization might have a distributed help desk with
different teams located in regions around the world to support local
user communities. You might not want the American help desk to be able
to manage European users and vice versa. In this case, you could create
two role groups for the American and European help desks and set the
appropriate scope so that both role groups have access only to the
users they support. This approach depends on a certain organization of
user accounts within Active Directory because you cannot apply a scope
to a notional set of users. A clear division such as an organizational
unit must exist to support a scope.
Troubleshooting You can’t add a scope to an existing role group by using Set-RoleGroup
The
Set-RoleGroup cmdlet doesn’t allow a scope to be retrospectively added
to a role group. If you need to set a scope on a role group after it is
created, use the Get-ManagementRoleAssignment cmdlet to fetch details
of all the role assignments for the role group and then pipe this
information to the Set-ManagementRoleAssignment cmdlet to set the new
scope for each role assignment. For example:
Get-ManagementRoleAssignment –RoleAssignee 'Help Desk Level 2' | Set-ManagementRoleAssignment
–RecipientOrganizationalUnitScope 'contoso.com/Exchange Users'
In
this example, you create a new role group with a scope set to allow the
members of the role group to manage European mailboxes.
New-RoleGroup 'European Help Desk' –Roles 'Message Tracking', 'Mail Recipients', 'Move Mailboxes'
–Members '[email protected]', '[email protected]'
–ManagedBy '[email protected]', '[email protected]'
–Description 'This group is used to manage European mailboxes'
–RecipientOrganizationalUnitScope 'contoso.com/EMEA Mailboxes'
As
an alternative, you could create the management scope beforehand to
point to the name of the OU and then use it with the New-RoleGroup
cmdlet.
New-ManagementScope –Name 'European Mailboxes' –RecipientRoot 'contoso.com/Exchange Mailboxes/EMEA'
–RecipientRestrictionFilter {RecipientType –eq "UserMailbox}
New-RoleGroup 'European Help Desk' –Roles 'Message Tracking', 'Mail Recipients', 'Move Mailboxes'
–Members '[email protected]', '[email protected]'
–ManagedBy '[email protected]', '[email protected]'
–Description 'This group is used to manage European mailboxes'
–CustomRecipientWriteScope 'European Mailboxes'
