This article covers a special kind of Role-Based Access Control (RBAC) Management Role, the unscoped top-level...
management role. As the name implies, unscoped management roles are not bound to a scope and apply at the global level.
Unscoped management roles provide restricted access to administrators or user accounts to execute specific scripts or non-Exchange cmdlets from a different PowerShell module (regular PowerShell cmdlets remain available).
To create an Unscoped management role, you need to be a member of the Unscoped Role Management Group. To assign the Administrator to the Unscoped Role Management Group, use:
New-ManagementRoleAssignment –Name 'Unscoped Role Management-Administrators' –User Administrator –Role 'Unscoped Role Management'
If you want to assign this role to a group, use SecurityGroup instead of User parameter and specify the group name.
Restart Exchange Management Shell (EMS) for the new permission to become effective, making the UnScopedTopLevel parameter available. Now, create an unscoped management role by specifying the Unscoped switch when using New-ManagementRole:
New-ManagementRole –Name 'Exchange Maintenance' -UnScopedTopLevel
The scripts you want to associate with an unscoped management role need to reside in the $exinstall\RemoteScripts folder on each relevant Exchange server. By default, this will be the location: C:\Program Files\Microsoft\Exchange Server\v15\RemoteScripts. The format for assigning a script to an Unscoped Management Role is:
Add-ManagementRoleEntry –Identity 'Role Name\Script Filename' [–Parameters <Param1>, <Param2>, ..] –Type Script –UnscopedTopLevel
To assign a non-Exchange cmdlet, replace Script Filename with the name of the cmdlet and set type to Cmdlet. Specify all parameters you want to allow to be used with the script or cmdlet.
Assume you want to assign permissions to run a script HealthCheck.ps1 using a parameter named Notify, use:
Add-ManagementRoleEntry –Identity 'Exchange Maintenance\HealthCheck.ps1' –Parameters 'Notify' –Type Script –UnscopedTopLevel
Create a management role group
In this example, I have created an Unscoped Top Level Management Role named 'Exchange Maintenance', which is allowed to run a script HealthCheck.ps1 and specify a parameter Notify. Now, I can create a role group, assign the Unscoped Management Role to this role group, and add accounts or groups that need to be able to run that script or cmdlet.
Let's assume you have a service account saExchange. Run the following cmdlets to create the Role Group and add this account (specifying BypassSecurityGroupManagerChecks as it is not configured to manage this group through the ManagedBy property):
New-RoleGroup –Name 'Run Exchange Maintenance' –Roles 'Exchange Maintenance'
Add-RoleGroupMember –Identity 'Run Exchange Maintenance' –Member saExchange -BypassSecurityGroupManagerChecks
While saExchange has permission to run this script, it does not necessarily have permissions to run Exchange or other cmdlets. In other words, the account needs to execute every cmdlet used in the script in order to run successfully. Make sure you assign the account a proper role group, or specify individual Management Role Entries.
To be able to run a non-Exchange cmdlet from a specific module, use Add-ManagementRoleEntry. Assume you have the Quest Active Roles snap-in installed on every Exchange server, and allow running a specific cmdlet in your script. To allow saExchange to run Get-QADUser, use:
Add-ManagementRoleEntry –Identity 'Exchange Maintenance\Get-QADUser –PSSnapIn Quest.ActiveRoles.ADManagement –UnscopedTopLevel
If you change your mind, use Remove-ManagementRoleEntry to remove the script or cmdlet:
Remove-ManagementRoleEntry –Identity 'Exchange Maintenance\HealthCheck.ps1'
To remove the Unscoped Top Level Management Role, use:
Remove-ManagementRole –Identity 'Exchange Maintenance' –UnScopedTopLevel
While this may take a while to set up, Unscoped Top-Level Management Roles allow for configuring fine-grained permissions, aimed at specific tasks. Apart from Exchange permissions, you can limit the scope of an account in terms of which scripts or non-Exchange cmdlets it can run, in combination with what parameters. Depending on your requirements, this may be a welcome method to lock down the Exchange environment, limiting chances of mistakes and potential consequences.
RBAC permissions options in Exchange 2013
Define which commands, tasks end users can access
How does RBAC work?
Exchange 2010 role based access control basics
RBAC management in Exchange 2013