If you would like to read the other parts in this article series please go to:
Our goal for this article is to delegate contact administration to any given user. The only thing that the delegated user should have access to using Exchange Admin Center is related to Contact management.
Preparing the environment…
Let’s create an Organizational Unit on the root of the domain and name it Contacts. Then, we need to create a test user to validate our delegation process. So let’s create a regular user called User6 and we can validate that the user is just a regular user based on its Active Directory groups (Figure 01).
Important:
In order to manage Exchange Server 2013, and in this case the contacts, we do not need a mailbox user, just a regular user will do the trick. Of course, since we are not creating a mailbox for him, there is no way for him to access https://exchangeURL/owa which means that the user must use https://ExchangeURL/ECP which is the Exchange Admin Center.
Figure 01
Our goal is to allow the management of just Contacts objects, and the first step is to find out which Management Roles use the cmdlets that we are looking for. We can run the main cmdlets to see if they are all on the same Management Role, as shown in Figure 02.
Figure 02
Based on our previous research, the Mail Recipient Creation will provide us the ability to create and remove however, the set and disable verbs are provided by Mail Recipients Management Role.
There is another way to research in a broader way, using wildcard, as shown in Figure 03.
Figure 03
Based on our research we will need two Management Roles to have all cmdlets required to support the Contact management in our organization. We will start by showing some troubleshooting steps and we can use the same steps for any future delegation using RBAC.
Creating the Management Role
The first step is the creation of a Management Role based on the existent Mail Recipient Creation management role.
The naming convention is key especially when planning several levels of customization while the wildcard is key to find the information. Remember that a Management Role will restrict the cmdlets that can be used and they will be part of an Admin Role Group later on. Therefore, the naming convention of the new Management Role should be more towards the function/scope of the Management Role than who will use it.
There is no right or wrong, we can always name the Management Role with a brand new name to reflect our needs. An example for this first one could be: AP_Contact_Creation and in order to find out the parent, afterwards we will need to use Get-ManagementRole AP_Contact_Creation | Select Name,RoleType.
The second option which is my favourite (I am not saying that is practical but just personal preference) is to keep the original name and add a prefix that helps me identify the reason of the Management Role afterwards. An example could be _AP_Contact_Mail_Recipient_Creation name. The reason for the _AP prefix is to identify that it was created manually and those two letters represent my organization (Anderson Patricio); the second piece of information is the main objective of the Management Role that is _Contact_ and the final information is the original name of the Management Role.
To wrap it up you may have noticed that we are using _ instead of spaces and that is to avoid playing with special characters when using Exchange Management Shell.
For this article series, we are going to use Andy’s favorite naming convention and the entire process can be seen in Figure 04.
Figure 04
As you may have noticed we decided to use the second option, and see how easy it is to find the information by typing in Get-ManamentRole _AP*, and if we keep the same standard for all other management roles the administration will be a piece of cake (Figure 05).
Figure 05
In order to validate what we have in our new Management Role, we can type in Get-ManagementRoleEntry _AP*\* at this point we know that we have just one Management Role. In the future, we may want to be more restrictive so we can take advantage of the second field of our naming convention by typing in Get-ManagementRoleEntry _AP_Contact_*\* where, only a list of the cmdlets related to Contact delegation will be listed (Figure 06).
Figure 06
Now that we have a management role, a user to test, and an Organizational Unit ready for testing we can go ahead and create a new Admin Role Group using either Exchange Admin Center or Exchange Management Console.
We are going to use Exchange Admin Center, and these are the steps required to create the new Admin Role Group:
- Logged on Exchange Admin Center
- Click Permissions
- Click Add
- On the new page define a name for the new Admin Role Group (Contact Administration in our Article), then restrict the write scope to only the Contact OU using the format apatricio.local/Contacts. Finally, click Add in roles and add the Management Role that we have just created. The result should be similar to Figure 07.
Figure 07
- Add a member to this new Admin Role Group, so let’s add our User6
- Click Save
Initial test…
Logged on to https://Exchange2013URL/ecpas user6, our initial page should be similar to the one shown in Figure 08. Well, the results are not even close of what we have planned and that is okay. That is because we have just copied one default Management Role and now we need to customize according to our requirements.
Figure 08
We are going to focus first on our requirements and test. When we have everything set, then we cleanup the Management Roles and remove any unnecessary options. Using the current scenario (a single Management Role associated to the Admin Role Group) we should be just fine creating and removing contacts from the Contacts OU, however we won’t be able to Edit it because it is not available at this time (Figure 09).
Figure 09
This is due to the fact that we do not have the Set-MailContact available on the Managament Role that we created. We can double check that by searching which roles have that cmdlet using Get-ManagementRole –Cmdlet Set-MailContact and we can see that the Management Role that we created before is not there (Figure 10).
Figure 10
We need to create a new Management Role based on the Mail Recipients, and this cmdlet can be used New-ManagementRole _AP_Contact_Mail_Recipients –Parent “Mail Recipients” as shown in Figure 11.
Figure 11
Now, the next step is to add this new Management Role to the existent Contact Administration Admin Role Group.
Figure 12
Second Test and cleanup process…
If you are still logged as user6, make sure to logoff first and then log back on to get the new permissions and by this time the user will be able to edit a contact, as shown in Figure 13.
Figure 13
Okay, we seem to have completed our requirements to manage contacts, however we still have tons of stuff on the Exchange Admin Center (Figure 14). These are the main items listed on the left side and their respective tabs when they are selected:
- Recipients: Mailboxes, resources, contacts and shared
- Permissions: Outlook Web App Policies
- Organization: sharing
- Mail flow: accepted domains
- Mobile: mobile device mailbox policies
- Hybrid: Setup
Figure 14
In order to cleanup first we need to understand what we have available in our two Management Roles that are being associated to the Admin Role Group and which we are testing. We can use Get-ManagementRoleEntry _AP_Contact*\* | Select Name,Role
Figure 15
In theory, we need only the ones related to MailContact, and the following cmdlet will give us all cmdlets and where they are located (Figure 16).
Figure 16
We can use the same cmdlet above but with –notlike, and will have all entries that are not related to MailContact. In order to double check we can run the following cmdlets to compare the number of entries (first all entries that do not have Mail Contact and in the second we check all of them).
Note:
Yes for your answer, Measure-Object is also fine to check those numbers out.
$v1 = Get-ManagementRoleEntry _ap_contact*\* | Where-Object { $_.Name –notlike ‘*MailContact’}
$v2 = Get-ManagementRoleEntry _ap_contact*\*
Write-Host $v1.count
Write-Host $v2.count
Figure 17
Time to delete all the ones that we don’t need, and we can run the following cmdlet Get-ManagementRoleEntry _ap_contact*\* | Where-Object { $_.Name –notlike ‘*MailContact’} | Remove-ManagementRoleEntry . Then type A to delete all entries in a single shot (Figure 18).
Figure 18
If you list all the cmdlets for our two Management Roles the result will be the same as shown in Figure 19.
Figure 19
Before testing, we need to add an entry for the Get-Recipient cmdlet, as follows:
Add-ManagementRoleEntry _AP_Contact_Mail_Recipients\Get-Recipient
Now, user6 can log off any existent session and log back on, and the result will be much better than that of our previous attempt (Figure 20).
Figure 20
The next step is to test all functionalities to make sure that everything is working as expected. Here are a couple of issues that you may encounter with the solutions to rectify each.
Issue #01: Creating a new contact does not allow you to search the Organization Unit (Figure 21)
Figure 21
We are missing the cmdlet to search organization units and here is the solution.
Add-ManagementRoleEntry _AP_Contact_Mail_Recipient_Creation\Get-OrganizationalUnit
Issue #02: The Edit is not showing up (Figure 22)
Figure 22
The solution is to add the Get-Contact cmdlet using the following cmdlet:
Add-ManagementRoleEntry _AP_Contact_Mail_Recipients\Get-Contact
Issue #03: Some attributes of the Contact are not available for editing (Figure 23)
Figure 23
The solution is to add the Set-Contact cmdlet using the following cmdlet.
Add-ManagementRoleEntry _AP_Contact_Mail_Recipients\Set-Contact
To finish up this article series we can look once more at all cmdlets that are being used after fixing all the issues as shown in Figure 24.
Figure 24
If there is any missing component you can use what we have done so far to add the missing cmdlet or even remove entries if you want to be more secure.
Conclusion
In this second article of our series, we covered the steps required to delegate only contact administration to specific users using RBAC.
If you would like to read the other parts in this article series please go to:
