If you would like to read the other parts in this article series please go to:
- Exchange 2010 Role Based Access Control (Part 1)
- Exchange 2010 Role Based Access Control (Part 2)
- Exchange 2010 Role Based Access Control (Part 4)
Introduction
So far in parts one and two of this article series we have seen the links between management role groups, management roles and management role assignments. There is also another piece of the puzzle to look at, namely management role entries, which we will be doing here in part three. Once we understand what management role entries are, we shall then see what membership of the Discovery Management role group means for a user that needs to perform a mailbox search.
Management Role Entries
To recap, we have seen so far that a user can be added to a management role group which is linked via management role assignments to one or more management roles. The management roles contain one or more management role entries which are essentially cmdlets that the user will be able to run. Whilst it is possible to use the Get-ManagementRole cmdlet to view the management role entries, this isn’t necessarily the best method as I shall explain later in this article. For now, running the Get-ManagementRole cmdlet will enable you to understand the link between the management roles and the management role entries. For example, to look at the properties of the Mailbox Search management role a suitable cmdlet would be:
Get-ManagementRole ‘Mailbox Search’ | fl
Like many of the other example cmdlets within this article series, you can again see that we are piping the results of the Get-ManagementRole cmdlet into the format-list cmdlet so that we can obtain detailed results. In fact, there are quite a few parameters returned when using this approach and the main parameter that we are interested in at this time is the RoleEntries parameter. Therefore to filter the output to view only this parameter the following cmdlet can be used:
Get-ManagementRole ‘Mailbox Search’ | fl RoleEntries
You can see the results of running this cmdlet in Figure 7.
Figure 7: The Properties of the Mailbox Search Management Role
If you look carefully at the output contained in the RoleEntries parameter listing, you can see that the Mailbox Search management role contains the Stop-MailboxSearch, Start-MailboxSearch, Set-MailboxSearch, Search-Mailbox, Remove-MailboxSearch, New-MailboxSearch, Get-Recipient, Get-MailboxSearch, Get-Mailbox, Get-DomainController and Get-ADServerSettings cmdlets along with the associated parameters that the assigned user will be able to run.
However, I am sure you will agree that looking at cmdlet output similar to that shown in Figure 7 is not easy on the eye. Fortunately, the Get-ManagementRoleEntry cmdlet can be used to retrieve the management role entries in a much clearer and more meaningful manner. To retrieve all the management role entries for the Mailbox Search management role the cmdlet to use is:
Get-ManagementRoleEntry ‘Mailbox Search\*’
Obviously the management role name is enclosed in quotes because it contains a space character. However, you will also notice the \* characters at the end of the management role name which are used to retrieve all management role entries since the * character is used as a wildcard character. You can see the results of running this cmdlet in Figure 8, where it is clear to see the names of the 11 cmdlets, the management role entries, that are included in this management role.
Figure 8: The Management Role Entries for the Mailbox Search Management Role
However, what is not so clear from Figure 8 is the list of parameters associated with each cmdlet that belongs to the Mailbox Search management role. To overcome this, you can pipe the results of the cmdlet into the format-table cmdlet (abbreviated to ‘ft’ in the example below) and also include the –AutoSize and –Wrap parameters. The result is a cmdlet that looks like this:
Get-ManagementRoleEntry ‘Mailbox Search\*’ | ft –AutoSize -Wrap
The result of running this improved cmdlet can be seen in Figure 9 where the management role entry parameters are now clearly displayed.
Figure 9: Detailed Management Role Entries
The fact that the general wildcard character of * has been used means that the results of the Get-ManagementRoleEntry cmdlet can be refined. For example, you can see from Figure 9 that 7 out of the 11 management role entries contain the string ‘search’ in their names. Therefore, if you need to refine the output of the Get-ManagementRoleEntry cmdlet to only show management role entries that have the string ‘search’ in their names you could use a cmdlet similar to the following:
Get-ManagementRoleEntry ‘Mailbox Search\*search’ | ft –AutoSize -Wrap
You can see the results of running this cmdlet in Figure 10.
Figure 10: Filtered List of Management Role Entries
Combined Result
Putting this all together, we have seen that adding a user to the Discovery Management role group gives that user the Mailbox Search management role which itself contains 11 management role entries that effectively allow for the running of the 11 Exchange Management Shell cmdlets that were detailed earlier in this article. The management role is linked to the management role group via the Mailbox Search-Discovery Management role assignment which allows recipient object permissions at the organization level. Of course, adding a user to the Discovery Management role group also gives that user the Legal Hold management role which has its own associated Exchange Management Shell cmdlets. Although we have not covered that role in this article series, the concepts we’ve used to uncover the cmdlets available to the Mailbox Search management role are the same. Note that when multiple management roles are given to a user, the user receives the permissions to run all cmdlets associated with all assigned management roles.
Performing a Mailbox Search
Now that we have looked at the Discovery Management role group, its associated Mailbox Search management role and 11 management role entries, what does this mean for a user that is added to the Discovery Management role group?
Let us consider the case of a user who needs to perform mailbox searches across all mailboxes in the organization. Figure 11 shows the Exchange Control Panel within Outlook Web App for this user before any additional permissions have been assigned. In other words, this user is the same as any normal user regarding Exchange permissions; the user has rights to their own mailbox but has no other specific Exchange permissions granted. The rights to the user’s own mailbox are controlled via a default role assignment policy as we shall see later in this article series.
Figure 11: Exchange Control Panel – Default Permissions
Now let’s see what happens if this user is added to the Discovery Management role group and then logs back into Outlook Web App. You can see from Figure 12 that a new drop-down selection box appears in the top-left corner of the screen; this has been highlighted. This drop-down list allows the user to administer their own mailbox as before via the Myself option, but at the same time it also allows them to administer organization-wide settings depending on the permissions that have been assigned to them. Administration of organization-wide settings is controlled via the My Organization option.
Figure 12: Exchange Control Panel – Added Permissions
If the user selects the My Organization option they will be taken to a subsequent screen that allows them to manage elements of the organization depending on assigned permissions. As you can see from Figure 13, the Reporting tab is available when the user has been added to the Discovery Management role group; this allows the user to perform mailbox searches across the organization from within the Exchange Control Panel.
Figure 13: Exchange Control Panel – Mailbox Search
Summary
That concludes part three of this article series on Role Based Access Control in Exchange 2010. So far we have seen how adding a user to the Discovery Management role group ultimately gives that user the ability to perform mailbox searches. In part four, we will start looking at the other method of assigning permissions via RBAC, namely management role assignment policies.
If you would like to read the other parts in this article series please go to:
