Missing Recipient Creation Permissions in ECP and Shell

Customer running Exchange 2016 RTM was unable to create Mail Contacts in the Exchange Control Panel (ECP) or Exchange Management Shell (EMS). When opening EMS, the New-MailContact cmdlet was not visible, which was an indicator that there was a Role-Based Access Control (RBAC) permissions issue. Within ECP, the Plus symbol was not visible.



Troubleshooting steps taken
Customer was using the Administrator account that was a member of the “Organization Management” RBAC default role group. We also tested with a new account that was also added to the “Organization Management” group and the issue persisted. We also experimented with adding the test account to all default RBAC role groups and the issue still persisted. We also had the customer update to Cumulative Update 6 and the issue still persisted.

At this point, I wanted to verify the cmdlets were still present and available on the system (trying to rule out an odd corruption issue) so I opened PowerShell and manually loaded the Exchange module (bypassing RBAC) by running the following command:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

The New-MailContact cmdlet was available and working. Therefore, I knew it was an issue with RBAC via Remote PowerShell (as locally loading the Exchange modules bypasses RBAC).

I ran the below command (Get-ManagementRoleEntry) to view which management roles were associated with the New-MailContact cmdlet:

Get-ManagementRoleEntry *\New-MailContact | Format-List

From the output I could see that the “Mail Recipient Creation” role contains this cmdlet (Management Role Entry is synonymous with cmdlet within the RBAC framework). I then ran Get-ManagementRoleAssignment cmdlet to  view all of the default assignments. I compared these to my lab environment and they all appeared correct. Therefore, I decided to test a manual assignment of the “Mail Recipient Creation” role to my test account by running the below command (New-ManagementRoleAssignment):

New-ManagementRoleAssignment –Name TestFix –Role “Mail Recipient Creation” –User TestUser

After logging into ECP with the TestUser account, I could now create mail contacts. After opening EMS with TestUser I could now view New-MailContact as an available cmdlet:



This told me that somewhere in the RBAC framework, the Mail Recipient Creation role was missing as an assigned role for the default role groups.

I was unfortunately unable to find the root cause and due to time constraints we chose to implement a workaround by manually adding the Mail Recipient Creation role to the Organization Management and Recipient Management role groups by running the below commands:

New-ManagementRoleAssignment –Name OrgMgmtFix –Role “Mail Recipient Creation” –SecurityGroup “Organization Management”

New-ManagementRoleAssignment –Name RcptMgmtFix–Role “Mail Recipient Creation” –SecurityGroup “Recipient Management”

After running these commands and logging into ECP again with the Administrator account, we were then able to create Mail Contacts.


Getting Lync PowerShell to use RBAC

You may find that some things will work in the Lync GUI that will not work in PowerShell (Access Denied), the reason for this is that RBAC only applies to remote PowerShell and local PowerShell uses the AD permissions and not RBAC.

To resolve this you can login to PowerShell using the following script: (Copy the contents to a file and name it Connect-Lync.ps1)

$usercredential = get-credential
$pso = new-pssessionoption -skipcacheck -SkipCNCheck -SkipRevocationCheck
$session= New-PSSession -ConnectionUri https://localhost/ocspowershell -credential $usercredential -sessionoption $pso
import-pssession $session

Note: 1. This script ignores the certificate (so it will work if your using a self signed cert)
          2. You may need to modify the execution policy to run this unsigned script in PowerShell “set-executionpolicy remote”


that RBAC applies only to remote management. If you are logged on to a computer running Lync Server 2010 and you open Lync Server Management Shell, RBAC roles will not be enforced. Instead, security is enforced primarily through the security groups RTCUniversalServerAdmins; RTCUniversalUserAdmins; and RTCUniversalReadOnlyAdmins.”

Troubleshooting RBAC

(or determining RBAC Permissions)

  • Get-ManagementScope – displays defined scopes, or details of a individual scope.
  • Get-ManagementRole
    • GetChildren – enumerate roles of immediate children
    • Recurse – enumerate roles of children and the children of those roles
    • Cmdlet – enumerate roles include this specific cmdlet
    • CmdletParameters – enumerate roles include this specific parameter
    • RoleType
  • Get-ManagementRoleEntry – shows all the role entries in a Management role (Ex: Get-ManagementRoleentry “Recipient Policies\*”)
  • Get-RoleGroup – shows all the groups or if you specify one with –ID will give you details on that group
  • Get-RoleGroupMember – shows all the group’s members (ex: Get-RoleGroupMember “Organization Management”)
  • Get-RoleAssignmentPolicy – Shows the role assignment policies
  • Get-ManagementRoleAssignment
    • http://technet.microsoft.com/en-us/library/dd351024.aspx
    • Examples: 
      • Get-ManagementRoleAssignment –Role “Organization Configuration” –GetEffectiveUser –Delegating $False | FL Name, RoleAssigneeName, EffectiveUserName, AssignmentChain (shows the users and groups that have Org Config RBAC permissions)
      • Get-ManagementRoleAssignment -WritableRecipient administrator –GetEffectiveUsers (shows the users that can make changes to administrator)

Note: As with all powershell commands you can use help cmdlet –examples to get more info (ex: help Get-ManagementRoleAssignment –Examples)



OK not yay ….. its all good until you have to go outside of the built in groups 😉
In case you don’t know “Role Based Access Control” is the new permission model for exchange 2010, it allows you to be granular and specific in your delegation of permissions, which is a great thing but takes a good deal of forethought to get properly configured.  image
Not for the feint of heart, in fact wouldn’t recommend it unless you have a REAL need it. For most people the defaults(listed on the right) are good enough

The good news is once you do you can simply put your admins into the applicable groups.

So as I’m trying to figure this out here is what I came up with for syntax to give “Site 1 Mail Admins” management permission for users in OU “Site 1”

New-RoleGroup -name “OKC MAIL ADMINS” -Members “Site1 MAIL ADMINS” -Roles “Mail Recipients”, “User options”, “Mail Recipient Creation”, “Mail Enabled Public Folders”, “Distribution Groups”,” –RecipientOrganizationalUnitScope “ex2010/Lab Users/Site 1”

here is the break down

So now I can add my admins to that group and they can Manage users and distro groups in that OU.
I do want to point out this is specific to exchange and is not the same as AD permissions.