For various reasons, there are times when an administrator does not want a part of the ECP to be accessible by some users and they desire a features' tab or entry point to not be visible at all. The web.config file for the Exchange Control Panel (ECP) contains the requirements a logged in user must meet before the feature tab or configuration item may be displayed in the UI.
Here we will step through an example of how to go through the process of determining what you must do to accomplish this task.
IMPORTANT: Exchange Control Panel files are not modified to accomplish this — the process only involves changing the user's RBAC Role assignment.
SUPPORT NOTE: Modifying the Exchange Control Panel files to remove parts of the UI is not supported. Serious problems may occur if you modify web.config files. The only supported way of removing a feature from the ECP is by modifying the effective rights a user has using RBAC, as documented in this post.
In Exchange 2010, Role Based Access Control (RBAC) is the new permissions model that allows you to assign granular permissions based on management roles. To learn more about RBAC, see Understanding Role Based Access Control in Exchange 2010 documentation, and the previous post RBAC and the Triangle of Power.
Remove the Delivery Reports tab for a user
In Exchange 2010, the Delivery Reports tab in ECP allows users to retrieve delivery reports for messages sent to or received by them. In this example, the goal is to not display the Delivery Reports tab in ECP so it's not accessible by a user.
Figure 1: The Delivery Reports tab in ECP
- To remove the Delivery Reports tab from ECP for a user, we need to determine what's needed for the tab to show. To get this information, we need to check the Web.Config file located in ECP's folder at "
:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Reporting". ECP uses the authorization section of the Web.Config file to evaluate if the tab should be displayed. If the user is not allowed to run the cmdlet shown, the tab is not displayed. Let's view the Authorization section of the Deliveryreports.slab location path:
<location path="DeliveryReports.slab">
<system.web>
<authorization>
<allow roles="Search-MessageTrackingReport@R:Organization" />
<!-Deny everyone else ->
<deny users="*" />
</authorization>As shown in the above figure, access to the Search-MessageTrackingReport cmdlet is required to display the Delivery Reports tab. To disable the Delivery Reports tab, we need to determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, so we can remove the permission for the user to run it. This ensures the tab will not be displayed to that user.
To determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, we use the Get-ManagementRole cmdlet:
Get-ManagementRole -cmdlet Search-MessageTrackingReport
The result:
Name RoleType
------- --------------
Message Tracking MessageTracking
View-OnlyConfiguration ViewOnlyConfiguration
MyBaseOptions MyBaseOptionsNext we must determine which of the above roles the user is a member of and where it would make sense to remove the Search-MessageTrackingReport cmdlet from. For example, we wouldn't want to remove the cmdlet from the ViewOnly Configuration because that is an administrative role. The user is not an administrator, and therefore it's not likely that he/she has been assigned the MessageTracking role. This means that we will have to check to see what roles/assignments the user is a member of:
Get-RoleGroup | where {$_.Members -like "*Display UserName*"} | fl name
The command doesn't return any results because the user is not a member of any administrator type role. Next, we will check the management role assignments for this user:Get-ManagementRoleAssignment -RoleAssignee UserName
Among other items you see the list of roles (note these are user/self configuration roles):
Name Role
-------- ---------
MyBaseOptions-Default Role Assignment Policy MyBaseOptions
MyContactInformation-Default Role Assignment Policy MyContactInformation
MyVoiceMail-Default Role Assignment Policy MyVoiceMail
MyDistributionGroupMembership-Default Role Assignment Policy MyDistributionGroupMembership
Custom Default Policy MyDiagnosticsIt looks like the only one we are interested in here is the "MyBaseOptions" because we already know that the cmdlet we want to block is only available in that role that the user has anything to do with. The user is not an administrator so the other roles are not interesting to us for this scenario.
To make sure the user is assigned to the role assignment policy we can verify:
Get-Mailbox UserName | fl roleassignmentpolicy
RoleAssignmentPolicy: Default Role Assignment Policy
Tip: If you want to combine some of the above steps into one line to find out which role contains that cmdlet we are interested in (Search-MessageTrackingReport), you can use the following set of cmdlets:
Get-ManagementRole -Cmdlet Search-MessageTrackingReport | Get-ManagementRoleAssignment -RoleAssignee UserName -Delegating $False | FT Role, RoleAssigneeName
The result:
Role RoleAssigneeName
---- ----------------
MyBaseOptions Default Role Assignment Policy -
Now, we know that we need to create a new Role Assignment Policy for the user and associate it with a new (customized) MyBaseOptions role. We will make a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it.
First, we will create a new (end user) Role Assignment Policy called Alternate Assignment Policy, and leave the original policy unchanged (for other users who should still have access to the Delivery Reports tab).:
New-RoleAssignmentPolicy "Alternate Assignment Policy"
For this new policy, we need to turn on a few of the default options that the Default Policy had. For example, to add the ability for the user to edit their own contact information we add the MyContactInformation role to the policy:
New-ManagementRoleAssignment -Name "MyContactInformation-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyContactInformation
To add the ability for the user to manage their own distribution group membership, we add the MyDistributionGroupMembership role to the policy:
New-ManagementRoleAssignment -Name "MyDistributionGroupMembership-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyDistributionGroupMembership
-
Now we need to create a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it and then assign it to the new Role Assignment Policy. We can give it any name, preferably something with a good description.:
New-ManagementRole "MyBaseOptionsWithoutMessageTracking" -Parent MyBaseOptions
- We remove the Search-Message
TrackingReport cmdlet from the "MyBaseOptionsWithoutMessageTracking" role:
Remove-ManagementRoleEntry "MyBaseOptionsWithoutMessageTracking\Search-MessageTrackingReport"
- Next, we assign the newly created MyBaseOptionsWithoutMessageTracking role to the Role Assignment Policy:
New-ManagementRoleAssignment -Name "MyBaseOptionsWithoutMessageTracking-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyBaseOptionsWithoutMessageTracking
- Then, we assign the Role Assignment Policy to the user:
Set-mailbox mod1user1 -RoleAssignmentPolicy "Alternate Assignment Policy"
This can also be performed in the ECP, as shown in figure 2.
Figure 2: Assigning the Role Assignment Policy to the user in ECP
Done! Now we can test the user experience. As shown in figure 3, when UserName logs on, the Delivery Reports tab isn't visible.
Figure 3: The Delivery Reports tab is removed for the user
After the Delivery Reports tab is removed, if your user tries to track a message from within Outlook Web App or Outlook, he/she will receive the following error:
Figure 4: Error when user tries to track a message