Every change you make in the Exchange admin center or the Exchange Management Shell passes through Role Based Access Control (RBAC) first. When RBAC says no, the error rarely mentions RBAC: a cmdlet "doesn't exist", a parameter "can't be found", or the shell won't even connect. In this post I'll explain the building blocks, show how to see what an admin really has, grant least privilege with scopes, and match each common access-denied message to its cause.
Errors this guide fixes
[FailureCategory=AuthZ-CmdletAccessDeniedException] The user "<user>" isn't assigned to any management roles.Exchange Management ShellEvent ID 258 (MSExchange RBAC)Application logThe term 'New-MailboxExportRequest' is not recognized as the name of a cmdlet, function, script file, or operable program.Exchange Management ShellA parameter cannot be found that matches parameter nameExchange Management ShellInsufficient access rights to perform the operation.Exchange Management Shell / EAC
How it works#
- Management role: a set of role entries, each one a cmdlet plus the parameters it may use. Mail Recipients, for example, covers managing existing mailboxes, contacts and groups.
- Role group: a universal security group in the Microsoft Exchange Security Groups OU. Members get every role assigned to the group. Built-in groups include Organization Management, Recipient Management, Server Management, Help Desk, Discovery Management and View-Only Organization Management.
- Role assignment: the link between a role and a role group (or, as an advanced option, a user), optionally restricted by a scope.
- Scope: which objects the assignment may change. You can restrict it to an OU, a recipient filter or specific servers and databases, and mark a scope as exclusive.
RBAC asks two questions: may this user run this cmdlet with these parameters, and is the target object inside their write scope? If both answers are yes, Exchange performs the change as the Exchange Trusted Subsystem, not as the admin. That's why Exchange admins don't need AD rights on users, but Exchange itself does.
Step-by-step#
1. See what someone actually has#
Reading RBAC assignments needs permissions of its own; members of Organization Management have them:
Get-ManagementRoleAssignment -RoleAssignee jdoe -Delegating $false |
Format-Table Role, RoleAssigneeName, RecipientWriteScope, CustomRecipientWriteScope -AutoSize
Get-RoleGroupMember "Organization Management"A user's results include roles received through role groups, so this is the quickest way to answer "why can't Jane do this?".
2. Find the role that contains a cmdlet or parameter#
Get-ManagementRole -Cmdlet New-MailboxExportRequest
Get-ManagementRole -Cmdlet Set-Mailbox -CmdletParameters ProhibitSendQuota
# Who effectively holds a role, expanded through group membership
Get-ManagementRoleAssignment -Role "Mailbox Import Export" -GetEffectiveUsers -Delegating $false3. Grant through a role group#
Microsoft recommends role groups over direct assignments to users, and so do I: they're visible, auditable and easy to empty. For example, the Mailbox Import Export role isn't assigned to any role group by default, not even Organization Management, so PST exports need it granted explicitly:
New-RoleGroup -Name "Mailbox Export Operators" -Roles "Mailbox Import Export" -Members jdoeRBAC is evaluated when a session starts. The user must open a new Exchange Management Shell, and sign out and back in for the EAC, before the new cmdlets appear. Allow time for AD replication too.
4. Limit the reach with a scope#
New-ManagementScope -Name "Finance users" -RecipientRestrictionFilter "Department -eq 'Finance'"
New-RoleGroup -Name "Finance Help Desk" -Roles "Mail Recipients" `
-CustomRecipientWriteScope "Finance users" -Members helpdesk-finMembers can now change Finance recipients only. Mail Recipients modifies existing recipients; creating mailboxes needs Mail Recipient Creation. To fence off VIP mailboxes even from Organization Management, create the scope with -Exclusive: only assignments that use that exclusive scope can then change those mailboxes, so plan who gets one before you create it.
Common "access denied" messages and their causes#
| What you see | Cause | Fix |
|---|---|---|
The shell won't connect: [FailureCategory=AuthZ-CmdletAccessDeniedException] The user "<user>" isn't assigned to any management roles. Admins also report Event ID 258 (MSExchange RBAC) in the Application log at the same time | The account holds no role assignments at all | Add it to a role group, then sign out and in |
The term 'New-MailboxExportRequest' is not recognized as the name of a cmdlet, function, script file, or operable program. | RBAC only loads cmdlets your roles allow | Assign the role that contains it (step 2), open a new session |
A parameter cannot be found that matches parameter name 'ProhibitSendQuota'. | Your role has the cmdlet but not that parameter | Get-ManagementRole -CmdletParameters shows which role has it |
| The command fails on some users but works on others, saying the object is outside your write scope or can't be found | A custom or exclusive scope | Check CustomRecipientWriteScope on your assignments and any exclusive scopes |
| The EAC shows only your own mailbox options, or whole sections are missing | No admin roles, or only narrow ones | Check assignments as in step 1 |
Insufficient access rights to perform the operation. | An Active Directory permission problem, not RBAC: often inheritance disabled on the object (protected admin accounts), or AD split permissions | See the notes below |
Insufficient access rights: check AD, not RBAC#
Because the work runs as Exchange Trusted Subsystem, AD must still let Exchange write to the object. Exchange relies on the permissions that objects inherit from the domain, and Active Directory's AdminSDHolder protection disables inheritance on members of protected groups such as Domain Admins. If a change fails only on admin accounts, that's the likely reason. It's also behind many ActiveSync failures: see ActiveSync devices not syncing. Never fix it by editing the Exchange Trusted Subsystem group or its ACL entries; Microsoft warns that can do irreparable damage.
Split permissions in brief#
- RBAC split permissions: assign the Mail Recipient Creation and Security Group Creation and Membership roles to a role group of AD administrators, and remove them from Exchange admins' groups. Exchange admins then lose cmdlets such as
New-Mailbox,New-MailUser,New-MailContact,New-RemoteMailboxand theirRemove-counterparts; members of the AD administrators' role group keep them. - Active Directory split permissions: enabled by running
Setup.exe /PrepareAD /ActiveDirectorySplitPermissions:trueplus the licence switch (in a multi-domain forest, also prepare the other domains), then restarting the Exchange servers. No Exchange user, service or server can create security principals any more. AD admins create accounts with AD tools, and Exchange admins mail-enable them, for example withEnable-Mailbox.
Verify#
Get-ManagementRoleAssignment -RoleAssigneeshows the expected role with the expected scope.- In a new session as the delegated admin,
Get-Command New-MailboxExportRequestreturns the cmdlet, a change to an in-scope user succeeds and one to an out-of-scope user fails. Get-ManagementRoleAssignment -WritableRecipient ceo@contoso.com -GetEffectiveUserslists who can actually change a sensitive mailbox. Good looks like a short list you recognise.
Tips and gotchas#
- Keep at least two named accounts in Organization Management so one mistake can't lock everyone out.
- Use View-Only Organization Management for auditors and junior staff who only need to look.
- Review RBAC changes with
Search-AdminAuditLog -Cmdlets Add-RoleGroupMember, New-ManagementRoleAssignment. - Exchange Online has its own, separate RBAC. A role group on-premises grants nothing in the cloud, and vice versa.
