Removing a Feature From The Exchange Control Panel
Published Mar 04 2010 02:00 PM 19.6K Views

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
  1. 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          MyBaseOptions

    Next 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                                        MyDiagnostics

    It 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

  2. 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

  3. 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

  4. We remove the Search-Message TrackingReport cmdlet from the "MyBaseOptionsWithoutMessageTracking" role:

    Remove-ManagementRoleEntry "MyBaseOptionsWithoutMessageTracking\Search-MessageTrackingReport"

  5. 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

  6. 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
 

    -Perry Newman

    17 Comments
    Not applicable
    Thanks Perry,

    By default regular users only seem to be able to edit very basic contact information (phone etc) within the ECP.  We want to allow regular users to edit their Title, Office, and maybe a few other fields, the way administrators can.  How do we go about this?

    Thanks!
    Wes
    Not applicable
    Get-Mailbox typo of Get-ManagementRoleAssignment?
    Not applicable
    RBAC takes a little bit of time to wrap your brain around but it does offer a good bit of flexibility. I would like to see a GUI to manage this and make it a little more understandable.

    Also, there doesn't seem to be a way to have custom config scopes or custom read scopes.

    See the issue I am running into here:
    http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/286d13fe-2a4a-4cc3-b386-6cbd445...
    Not applicable
    Hi Pesos,

    To be able to edit more than the basic contact information, you would have to modify the whole form and add controls. Right now there is not a way to add those controls unfortunately.

    hHanks!
    Not applicable
    Hi Dloder,

    I don't think it's a typo although there might be a few ways to accomplish some of the same steps. If it's the step we are talking about is this one:

    Get-Mailbox UserName | fl roleassignmentpolicy

    then we should be good. We are just using it to find out with policy is assigned to the user.

    Thanks!
    Not applicable
    Hi Tim,

    Yeah, RBAC is a challenge. There is a lot to it. I am also still learning.

    Thanks for the feedback on the GUI about some of the limitations. I will pass it along. Some things can be still only done using the shell. I know we are working on making things better in the GUI though.

    Thanks!
    Not applicable
    Thanks Perry, is this type of addition planned for the future?  Or would this be a total customization we would have to do, that I imagine would get overwritten with each update, similar to OWA customizations?

    thanks!
    Wes
    Not applicable
    Hi Wes,

    It would be manual customization and you would risk overwriting the customization as you state.

    I can certainly pass along the suggestion of giving administrators the ability to give users the option to edit more information such as office and title etc.

    Thanks,
    Perry
    Not applicable
    Hello, I want to help me, I need to change the permissions of the role myprofileinfo, leaving only the displayname modifiable
    Not applicable
    Great post Perry !

    Anyway we could alter the Default assigment policy ? insted of creating a new one and applying it to users?

    what about a single parameter within an RBAC entry ?

    Thanks again,
    Ilantz
    Not applicable
    [PS] C:Windowssystem32>New-ManagementRoleAssignment -Name "xxxxxxx" -Role "xxxxxx" -RecipientRelativeWriteScope Self


    How can I assign all users to this role, or define it with securitygroup user?

    I nedd complete this command, thanks..
    Not applicable
    Hi Ilantz,

    You can alter the Default policy but it is a good idea to keep that one intact in case you have to go back to it quickly if something goes wrong in your configuring of it and need time to figure it out.

    Thanks,
    Perry
    Not applicable
    Hi Perry,  i try to modify but i can't, how i can do it
    Not applicable
    Hi Eduardo,

    I may be misunderstanding your question but you can add an assignment to the default policy in the same manner as this blog is doing that to the Alternate Policy but change the "-policy" parameter to the correct name:

    New-ManagementRoleAssignment -Name "MyBaseOptionsWithoutMessageTracking-Alternate Assignment Policy" -policy "Default Role Assignment Policy" -role MyBaseOptionsWithoutMessageTracking

    Again, I don't recommend doing that but it can be done.
    Not applicable
    Thanks Perry !

    if we assign the new role to the default policy, i must remove the original assignment ? i ended up creating a new policy as you recommended, but it looks like an additional overhead to change the policy for each new user...

    i was also asked to remove some of the set-mailboxregionalconfiguration parameters , so i ended up with a new policy..

    are there more RBAC practical tips around the corner ?
    Not applicable
    Someone out there needs to write a book with lots of these types of examples in it. I think it would sell a ton of copies, because this is such a complicated issue for us to wrap our minds around.

    That said, I'd like to ask the MSExchangeTeam to PLEASE write more detailed blog posts about RBAC.
    Not applicable
    Hi Ilantz,

    You should be able to assign multiple times. However, I still think a new policy is the best so you keep the original intact.

    Ilantz and Paul, I am sure more tips on this topic will come along. We'll do our best.

    Thanks!
    Perry
    Version history
    Last update:
    ‎Mar 04 2010 02:00 PM
    Updated by: