Configuring Exchange Online Service Principal permissions correctly is one of those things that looks straightforward until something breaks in production. Connecting an application to Exchange Online is not the same as connecting a user. The objects involved are different, and the mistakes people make are different too. This post walks through the full picture from app registration to a locked-down Role Group, so your automation has exactly what it needs and nothing else.

Every time I see an automation project that touches Exchange Online, the same shortcut appears: grant the service account Organization Management, run the tests, and move on. It works. It also means that a single leaked certificate or a single runaway script has full Exchange admin rights across the entire tenant. Also, think of your AI agent taking actions. You don’t want a single hallucination to ruin the entire organization’s mail system

What Are We Doing

This is an interactive post, so make sure to follow the steps and leave a comment if something is not clear. By the end of this post, we will have a Service Principal that connects to Exchange Online and can only update the Dynamic Distribution Group that has a name starts with “Auto-” and preview it. But won’t be able to access any other resources, such as users’ mailboxes.

This guide applies to any automation workload for managing Exchange Online resources: provisioning groups, managing mailboxes, setting configurations, running reports. The pattern is identical regardless of what the application needs to do. Only the role entries and scope filter change.

How Service Principal Auth Works in Exchange Online

Before touching RBAC, it helps to understand what actually happens when an application connects to Exchange Online. There are two moving parts: Entra ID and Exchange Online itself, and they handle different halves of the problem.

Entra ID handles authentication. Your app registers there, gets a client ID, and authenticates using either a certificate (recommended) or a client secret. The Exchange.ManageAsApp application permission tells Entra ID that this app is allowed to connect to Exchange as itself rather than as a delegated user.

Exchange Online handles authorization. Once the app authenticates, Exchange Online checks its own RBAC engine to decide what the app is actually allowed to do. The Entra ID permission just gets the app through the door. The Role Group and Scope decide what it can touch once inside.

This separation is important. Granting Exchange.ManageAsApp alone does not give the SP any Exchange permissions. Without a Role Group assignment, the SP connects successfully and can do nothing.

App-only vs delegated Application permissions (Exchange.ManageAsApp) run as the application identity with no user context. Delegated permissions run as a specific user. For automation and backend processes, always use application permissions. Delegated permissions require an interactive user login, which is not suitable for unattended workloads.
BTW: the Exchange.ManageAsApp is optional for management operation.

The RBAC Building Blocks

Exchange Online RBAC is built from four objects. Understanding what each one does before writing any PowerShell saves a lot of confusion later. Starting from the smallest piece in the RBAC

Management Role Entry

A Management Role Entry is the atomic unit of permission in Exchange Online RBAC. Each entry maps to a single cmdlet and optionally, to specific parameters within that cmdlet that a principal is permitted to execute. For example, a single Role Entry might permit New-DynamicDistributionGroup but restrict it to only the -Name and -RecipientFilter parameters, blocking everything else. Consider the Management Role Entry is a single page of the RBAC book

Management Role

A Management Role is a collection of cmdlets (Management Role Entries). Exchange Online ships with over 80 built-in roles covering everything from mailbox management to transport rules. For automation, you never assign a built-in role directly to a Service Principal. You create a child role derived from the most appropriate built-in parent, then strip it down to only what the application actually calls. This prevents privilege creep the moment the parent role gets updated or expanded by Microsoft.

Management Scope

A Management Scope defines which objects the role applies to. It answers the question “which recipients can this principal write to?” Without a scope, a role assignment applies organization-wide. In Exchange Online (cloud-only tenants), scopes are defined using OPATH recipient filter expressions.

Role Group

A Role Group is the object that ties a Management Role and a Management Scope together and holds members. Members of the Role Group inherit the combined permission: they can run the cmdlets defined in the Management Role, but only against objects that match the Management Scope filter. Service Principals are added to Role Groups as members, the same way user accounts are. You can see the Role Group using the web interface by clicking on Roles –> Admin Roles

Role Group vs direct assignment You can also use New-ManagementRoleAssignment to assign a role directly to a Service Principal without a Role Group. It works, but Role Groups are easier to audit, easier to manage when rotating SPs, and the Role-plus-Scope binding lives in one place rather than being repeated per principal.

How the Objects Connect

The diagram below shows the permission chain. Each layer adds a constraint until only the precise required permission remains at the bottom.

Register the App in Entra ID

Related Post – Connect to Office 365 Using Graph API and PowerShell

Go to Entra ID to register your application or use an existing one. Navigate to API Permissions and add the Exchange.ManageAsApp API permissions as below. Let’s assume that you named the Entra ID Application as Exchange_AutomationV1

Once the permissions are added and granted, click on Enterprise App and search for the application just created, in this example, it’s Exchange_AutomationV1

Copy the following values

• Application ID
• Object ID

Now start PowerShell 7 and connect to Exchange Online using your admin account. Start by creating the Service Principal in Exchange Online. The Service Principal is a representation of the Entra ID Application in Entra ID. It’s like mapping the Entra ID Application to a local Exchange Online service account.

To create a Service Principal in Exchange, follow these commands, but make sure to use your Application ID and Object ID copied from the previous steps

The AppID and ObjectID are the Enterprise App Application ID and Object ID, but the DisplayName is just a friendly name for you to identify this service principal

#Creating Service Principal
PS7 > New-ServicePrincipal -AppId de547fed-eb23-469e-8316-63ee8ebff20d -ObjectId 42431529-7384-48d1-85c0-d71efa79b3f3 -DisplayName Exchange_AutomationV1

DisplayName                              ObjectId                                                                            AppId
-----------                              --------                                                                            -----
Exchange_AutomationV1                    42431529-7384-48d1-85c0-d71efa79b3f3                                                de547fed-eb23-469e-8316-63ee8ebff20d

PS7> Get-ServicePrincipal -Identity "Exchange_AutomationV1"

DisplayName                              ObjectId                                                                            AppId
-----------                              --------                                                                            -----
Exchange_AutomationV1                    42431529-7384-48d1-85c0-d71efa79b3f3                                                de547fed-eb23-469e-8316-63ee8ebff20d

Choose the Right Built-in Parent Role

Before creating anything, identify which built-in Exchange role most closely covers what your application needs to do. Your custom child role will inherit from this parent, and you will then remove the entries you do not need. Picking the closest parent means less stripping work and reduces the risk of accidentally inheriting something dangerous.

The most commonly used parent roles for automation workloads are:

• Distribution Groups: Managing distribution groups and dynamic distribution lists
• Mail Recipients: Mailbox, contact, and mail user management
• Mail Recipient Creation: Creating mailboxes and mail users
• Recipient Policies: Email address policies and address lists
• Transport Rules: Mail flow rules management
• View-Only Recipients: Read-only recipient lookups
• View-Only Configuration: Read-only org configuration
• Audit Logs: Unified audit log access

To see all available built-in roles and what cmdlets they contain:

# List all built-in roles
PS7> Get-ManagementRole | Where-Object {$_.IsRootRole} | Select-Object Name | Sort-Object Name

# See what cmdlets a specific role contains
PS7> Get-ManagementRoleEntry "Distribution Groups\*" | Select-Object Name | Sort-Object Name

Create a Custom Child Role

Never assign a built-in role directly to your Exchange Online Service Principal (SP). Built-in roles are broad by design, and Microsoft can add cmdlets to them. Create a child role, strip it down to only what the application calls, and you control exactly what the SP can do, regardless of future changes to the parent.

# Create a child role from your chosen parent
PS7> New-ManagementRole `
    -Name "Automation-CustomRole" `
    -Parent "Distribution Groups"  # replace with your chosen parent

Name                  RoleType
----                  --------
Automation-CustomRole DistributionGroups

Review everything that was inherited

# Review everything that was inherited
PS7> Get-ManagementRoleEntry "Automation-CustomRole\*" | Select-Object Name | Sort-Object Name

Name
----
Add-DistributionGroupMember
Get-AcceptedDomain
Get-BookingMailbox
Get-CrawlState
Get-DistributionGroup
Get-DistributionGroupMember
Get-DynamicDistributionGroup
Get-DynamicDistributionGroupMember
Get-EligibleDistributionGroupForMigration
.....

The Get-ManagementRoleEntry cmdlet retrieves the Role-Based Access Control (RBAC) role entries configured on management roles within Exchange and Exchange Online. It is primarily used to identify which cmdlets and parameters specific administrators or role groups have permission to execute.

Now, remove every entry your application does not explicitly call. Be precise here. Go through your script or application code and list every Exchange cmdlet it actually invokes. Anything not on that list gets removed.

Define exactly what your application needs – replace with your actual list

PS7> $keep = @(
    'New-DynamicDistributionGroup',   # example - replace with your cmdlets used
    'Get-DynamicDistributionGroup',
    'Set-DynamicDistributionGroup',
    'Get-DynamicDistributionGroupMember',
    'Get-OrganizationalUnit',         # EXO internal dependency
    'Get-Recipient'                    # EXO internal dependency
)

# Remove everything not in the keep list
PS7> Get-ManagementRoleEntry "Automation-CustomRole\*" |
    Where-Object { $_.Name -notin $keep } |
    ForEach-Object {
        Remove-ManagementRoleEntry `
            -Identity "Automation-CustomRole\$($_.Name)" `
            -Confirm:$false
    }

# Confirm the final list
PS7> Get-ManagementRoleEntry "Automation-CustomRole\*" | Select-Object Name
Name
----
Get-DynamicDistributionGroupMember
Get-OrganizationalUnit
Set-DynamicDistributionGroup
Get-DynamicDistributionGroup
Get-Recipient
New-DynamicDistributionGroup

Watch for internal EXO dependencies Some cmdlets require other cmdlets to be present on the role even if your application never calls them directly. Exchange Online calls them internally during execution. If you strip them and a cmdlet fails with a resolution or access error, that is usually why. Add them back one at a time until the cmdlet works.

Here is a comparison before and after. As you can see, the permissions are trimmed down to only 6 cmdlets.

Before Stripping The Permission

After Stripping The Permissions

Add-DistributionGroupMember Get-AcceptedDomain Get-BookingMailbox Get-CrawlState Get-DistributionGroup Get-DistributionGroupMember Get-DynamicDistributionGroup Get-DynamicDistributionGroupMember Get-EligibleDistributionGroupForMigration Get-ExoJob Get-Group Get-Mailbox Get-MailUser Get-OrganizationalUnit Get-Recipient Get-ScopeAdmins Get-ScopeEntities Get-UnifiedAuditSetting Get-User Invoke-ChangeMeetingOrganizer New-DistributionGroup New-DynamicDistributionGroup Receive-ExoJob Remove-DistributionGroup Remove-DistributionGroupMember Remove-DynamicDistributionGroup Remove-ExoJob Set-DistributionGroup Set-DynamicDistributionGroup Set-Group Set-OrganizationConfig Set-UnifiedAuditSetting Start-AuditAssistant Stop-ExoJob Test-DatabaseEvent Test-MailboxAssistant Update-DistributionGroupMember Validate-CrawlFilter Write-AdminAuditLog

Get-DynamicDistributionGroupMember Get-OrganizationalUnit Set-DynamicDistributionGroup Get-DynamicDistributionGroup Get-Recipient New-DynamicDistributionGroup

Create the Management Scope

The scope is what stops the SP from being able to write to every recipient in the tenant. Without a scope, the role applies organisation-wide. With a scope, the SP can only operate on objects that match the filter you define.

In this script block, we are creating a new management scope that targets all the Dynamic Distribution Groups with the name attribute start with “Auto-”

# Create a recipient-based scope
PS7> New-ManagementScope `
    -Name "Automation-Scope" `
    -RecipientRestrictionFilter {
        RecipientType -eq 'DynamicDistributionGroup' -and
        Name -like 'AUTO-*'}

Name             ScopeRestrictionType Exclusive RecipientRoot RecipientFilter                                                             ServerFilter
----             -------------------- --------- ------------- ---------------                                                             ------------
Automation-Scope RecipientScope       False                   ((RecipientType -eq 'DynamicDistributionGroup') -and (Name -like 'AUTO-*'))

Cloud-only vs hybrid In a hybrid environment you can also use -RecipientRoot to target a specific Active Directory OU. In Exchange Online (cloud-only), there is no meaningful OU hierarchy to reference, so the recipient filter expression is your only containment boundary at the RBAC layer.

Deep Dive: RecipientRestrictionFilter

This parameter deserves more attention than most guides give it. It is evaluated server-side by Exchange Online every time the SP attempts a write. The SP does not receive an error explaining that the scope blocked it — it just gets access denied. If you get the filter wrong, operations fail silently and the logs give you nothing useful.

A few things that are different from regular PowerShell that catch people out:

• The syntax is OPATH, not standard PowerShell. Operators look similar but behave differently in places.
• The filter is evaluated at the Exchange service layer. You cannot bypass it by manipulating the local session.
• The entire expression goes inside curly braces { } or a quoted string.
• Property names are unquoted. String values use single quotes.
• Boolean values are $true and $false, not the string true.
• Wildcards (* and ?) only work with -like and -notlike.
• Compound expressions use -and, -or, and -not. Not && or ||.
• Parentheses work for grouping and precedence control.

Supported Operators

Operator	Meaning	Works With	Example
-eq	Exact match	String, Enum, Boolean, SmtpAddress	RecipientType -eq 'DynamicDistributionGroup'
-ne	Not equal	String, Enum, Boolean	Department -ne 'IT'
-like	Wildcard match	String, SmtpAddress	Name -like 'AUTO-*'
-notlike	Wildcard non-match	String	Name -notlike 'LEGACY-*'
-gt	Greater than	DateTime, Integer	WhenCreated -gt '2024-01-01'
-lt	Less than	DateTime, Integer	WhenCreated -lt '2020-01-01'
-ge	Greater than or equal	DateTime, Integer	WhenChanged -ge '2023-06-01'
-le	Less than or equal	DateTime, Integer	WhenChanged -le '2024-12-31'
-and	Both must be true	Compound	RecipientType -eq '...' -and Name -like 'AUTO-*'
-or	Either must be true	Compound	Name -like 'AUTO-*' -or Name -like 'BOT-*'
-not	Negates the condition	Any	-not (Name -like 'LEGACY-*')

Filterable Properties Reference

These are the recipient properties you can reference inside a RecipientRestrictionFilter expression

Identity and Type

Property	Type	Example	Notes
RecipientType	Enum	RecipientType -eq 'DynamicDistributionGroup'	Always use as a type guard
RecipientTypeDetails	Enum	RecipientTypeDetails -eq 'UserMailbox'	More granular than RecipientType
ObjectCategory	String	ObjectCategory -like '*group*'	Low-level; prefer RecipientType

Naming and Address

Property	Type	Example	Notes
Name	String	Name -like 'AUTO-*'	Display name. Primary naming boundary
DisplayName	String	DisplayName -like 'AUTO-*'	Usually same as Name; can diverge after rename
Alias	String	Alias -like 'auto_*'	Mail alias, left of @
PrimarySmtpAddress	SmtpAddress	PrimarySmtpAddress -like '*@lists.contoso.com'	Target a specific accepted domain
EmailAddresses	MultiValue	EmailAddresses -eq 'smtp:dl@contoso.com'	Matches any proxy address in the collection

Custom Attributes

Property	Type	Example	Notes
CustomAttribute1 to 15	String	CustomAttribute1 -eq 'AutomationManaged'	Best option for cloud-only tenants. Stamp at creation time.
ExtensionCustomAttribute1 to 5	MultiValue	ExtensionCustomAttribute1 -eq 'ManagedByBot'	Multi-value variant for multiple tags per object

Organizational

Property	Example	Use Case
Department	Department -eq 'Engineering'	Restrict SP to a single business unit
Company	Company -eq 'Contoso Ltd'	Multi-company tenant separation
City	City -eq 'Riyadh'	Geo-based scoping
CountryOrRegion	CountryOrRegion -eq 'SA'	Country-level boundary
ManagedBy	ManagedBy -eq 'CN=Admin,...'	Objects owned by a specific person
OrganizationalUnit	OrganizationalUnit -eq 'contoso.com/Groups'	Hybrid environments with OU structure

Lifecycle and State

Property	Example	Use Case
HiddenFromAddressListsEnabled	HiddenFromAddressListsEnabled -eq $false	Exclude hidden/decommissioned objects
WhenCreated	WhenCreated -gt '2024-01-01'	Restrict to recently created objects
WhenChanged	WhenChanged -lt '2025-01-01'	Inactivity detection or cleanup scopes

Common Mistakes

What You Tried	Why It Fails
Name -match 'AUTO-.*'	Regex is not supported in OPATH. Use -like 'AUTO-*'.
Name -contains 'AUTO'	-contains is for array membership. Use -like '*AUTO*' for substring.
RecipientType -in ('DDG','MailUser')	-in is not supported. Chain -eq with -or instead.
WhenCreated -eq 'today'	Relative date keywords are not supported. Use a literal date string.
$_.Name -like 'AUTO-*'	Pipeline variable $_ is not valid in OPATH. Reference properties directly.

To update a scope after it has been created, changes take effect immediately, no reconnection required:

PS7> Set-ManagementScope `
    -Identity "Automation-Scope" `
    -RecipientRestrictionFilter { CustomAttribute1 -eq 'AutomationManaged'}

Create the Role Group

Create a dedicated Role Group that combines your custom management role and management scope. Give it a name that makes the purpose obvious, you will thank yourself six months later when reviewing the environment.

PS7> New-RoleGroup `
    -Name "Automation-RoleGroup" `
    -Description "SP access for <your workload> - least privilege" `
    -Roles "Automation-CustomRole" `
    -CustomRecipientWriteScope "Automation-Scope"

Name                 AssignedRoles           RoleAssignments                                                     ManagedBy
----                 -------------           ---------------                                                     ---------
Automation-RoleGroup {Automation-CustomRole} {2pmwc4.onmicrosoft.com\Automation-CustomRole-Automation-RoleGroup} {Organization Management, 2f66ccde-f8b3-4c6c-8a29-29a38f568e0b}

Add the Service Principal

Now we need to add the Entra ID Service Principal to the role group as a member

# Get the EXO SP object
$sp = Get-ServicePrincipal -Identity "<AppDisplayName_or_AppId>"

# Add to the Role Group using the internal Identity GUID, not the display name
Add-RoleGroupMember `
    -Identity "Automation-RoleGroup" `
    -Member $sp.Identity

Always use $sp.Identity (the internal EXO GUID) rather than the display name string. If the SP display name contains spaces or special characters, passing it as a string to Add-RoleGroupMember can fail silently or resolve to the wrong object

Verify the Full Permission Chain

Do not skip this. Run all four checks before handing the SP credentials to your application.

# 1. Confirm the role assignment and scope are correctly linked
PS7> Get-ManagementRoleAssignment -RoleAssignee "Automation-RoleGroup" |
    Format-List RoleAssigneeName, Role,
                CustomRecipientWriteScope,
                RoleAssignmentDelegationType

# 2. Confirm only the expected cmdlets remain on the role
PS7> Get-ManagementRoleEntry "Automation-CustomRole\*" | Select-Object Name | Sort-Object Name

# 3. Confirm the scope filter is correct
PS7> Get-ManagementScope -Identity "Automation-Scope" |
    Format-List RecipientFilter, RecipientRoot, ScopeType

# 4. Confirm the SP is a member of the Role Group
PS7> Get-RoleGroupMember -Identity "Automation-RoleGroup"

Check	Expected
Role on the Role Group	Automation-CustomRole
Scope on the Role Group	Automation-Scope
RoleAssignmentDelegationType	Regular (not Delegating)
RecipientRoot on the scope	Empty for cloud-only tenants is expected
SP visible in Role Group Members	Yes

Connecting from Your Application And Testing The Results

Certificate-based app-only auth is the right choice for any unattended workload. Certificates are harder to exfiltrate and easier to rotate with zero downtime.

Make sure that the certificate private key is stored in the Local Computer certificate store, and the public certificate is uploaded to the Entra ID application

# App-only connection using certificate thumbprint
Connect-ExchangeOnline `
    -AppId                  "<ApplicationId>" `
    -CertificateThumbprint  "<Thumbprint>" `
    -Organization           "<TenantDomain>.onmicrosoft.com" `
    -ShowBanner:$false

Run Get-ConnectionInformation to confirm that you successfully connected as the managed identity

PS7> Get-ConnectionInformation


State                           : Connected
Id                              : 1
Name                            : ExchangeOnline_1
UserPrincipalName               : OAuthUser@Thepowershellcenter.onmicrosoft.com
ConnectionUri                   : https://outlook.office365.com
AzureAdAuthorizationEndpointUri : https://login.microsoftonline.com/Thepowershellcenter.onmicrosoft.com
TokenExpiryTimeUTC              : 25-May-26 12:05:03 AM +00:00
CertificateAuthentication       : True
ModuleName                      : C:\Temp\tmpEXO_cmbxbn33.5jh
ModulePrefix                    : 
Organization                    : Thepowershellcenter.onmicrosoft.com
DelegatedOrganization           : 
AppId                           : de547fed-eb23-469e-8316-63ee8ebff20d
PageSize                        : 1000
TenantID                        : 979feaee-b9cb-4b5d-b3c3-5a11ee95b809
TokenStatus                     : Active
ConnectionUsedForInbuiltCmdlets : True
IsEopSession                    : False

Try to run Get-Mailbox, you will see that the operation will fail as the Get-Mailbox was not part of the Management Role Entry, so the entire cmdlet is not exposed in the session.

PS7> Get-Mailbox
get-mailbox : The term 'get-mailbox' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, 
verify that the path is correct and try again.
At line:1 char:1
+ get-mailbox
+ ~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (get-mailbox:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Let’s try to remove a DDL and as you see it also wont work for the same reason above

PS7> Remove-DynamicDistributionGroup

remove-DynamicDistributionGroup : The term 'remove-DynamicDistributionGroup' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling 
of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ remove-DynamicDistributionGroup
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (remove-DynamicDistributionGroup:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 

The Set-DynamicDistributionGroup is part of the Management Scope Entry, so let’s give it a try and modify a DDL named as “Auto-test Group“. The update will succeed as the group in the management scope level, which was a Dynamic Distribution Group and the name starts with Auto-

PS7> Set-DynamicDistributionGroup "Auto-test Group" -Alias TestNow2

Name     ManagedBy                           
----     ---------                           
Test Now 6211bdac-0357-487d-9eea-9d53868a1308

Let’s try to modify a DDL that does not start with Auto-

The operation failed with a clear message. even though the Set-DynamicDistributionGroup is allowed in the session, the target DDL is outside the management scope, so the operation failed.

PS7> Set-DynamicDistributionGroup "Test_CustomAttr15_DDG" -Alias TestNow222
Write-ErrorMessage : ||The operation on Identity "Test_CustomAttr15_DDG" failed because it's out of the current user's write scope. 'Test_CustomAttr15_DDG' isn't within your current 
write scopes. Can't perform save operation.

Troubleshooting

Issue	Likely Cause	Fix
Get-ServicePrincipal returns nothing	EXO SP not yet provisioned after consent	Wait 10-15 minutes after granting admin consent
SP connects but gets access denied on all cmdlets	Not a member of any Role Group	Run Add-RoleGroupMember using $sp.Identity
Cmdlet runs but silently does nothing	Object does not match the scope filter	Check the RecipientRestrictionFilter matches your target objects
RecipientRoot blank on scope	Expected for cloud-only tenants	No action needed
Cmdlet fails with resolution error	EXO internal dependency stripped from role	Add Get-Recipient and Get-OrganizationalUnit back to the role
Add-RoleGroupMember fails or resolves wrong object	Display name used instead of Identity GUID	Use $sp.Identity not the display name string
SP has more access than expected	Built-in role assigned directly instead of a child role	Create a child role and strip it down, then reassign

FAQ

Why does Get-ServicePrincipal return nothing after granting admin consent?

Exchange Online provisions the Service Principal object asynchronously after Entra ID admin consent is granted. It does not appear instantly. Wait 10 to 15 minutes after consent and then retry Get-ServicePrincipal -Identity "<AppId>". If it still does not appear after 20 minutes, go to Entra ID under Enterprise Applications, find your app, and confirm that admin consent is showing as granted on the permissions tab.

The SP connects successfully but gets access denied on every cmdlet. Why?

A successful connection only means Entra ID authentication worked. Exchange Online RBAC is a completely separate layer. If the SP is not a member of a Role Group, it has no Exchange permissions at all regardless of what is configured in Entra ID. Run Get-RoleGroupMember -Identity "YourRoleGroup" and confirm the SP appears. If it does not, run Add-RoleGroupMember using $sp.Identity, never the display name string.

A cmdlet runs without errors, but nothing actually happens. Whats going on?

This is almost always the Management Scope blocking the operation silently. When the target object does not match the RecipientRestrictionFilter, Exchange Online denies the write without surfacing an explanatory error to the caller. Check your scope filter with Get-ManagementScope -Identity "YourScope" | Format-List RecipientFilter and verify it actually matches the object you are targeting. Test the filter independently using Get-Recipient -Filter { your filter } before attaching it to the scope.

A cmdlet fails with a resolution error or “couldn’t be resolved” message. What is missing?

Exchange Online calls certain cmdlets internally during the execution of others, even if your application never calls them directly. The most common internal dependencies are Get-Recipient and Get-OrganizationalUnit. If either was stripped from the role during lockdown, cmdlets like New-DynamicDistributionGroup will fail with a resolution error at runtime even though they are present on the role. Add the missing dependency back with Add-ManagementRoleEntry and retest.

Why does Add-RoleGroupMember fail or add the wrong object

This happens when you pass the SP display name as a string to the -Member parameter. Display names containing spaces, special characters, or that are not unique can resolve incorrectly or fail without a clear error. Always retrieve the SP first with $sp = Get-ServicePrincipal -Identity "<AppId>" and then pass $sp.Identity, which is the internal EXO GUID. That value is always unique and unambiguous.

Should I use Exchange.ManageAsApp or Graph mail permission for Exchange Automation?

Always use Exchange.ManageAsApp. Graph mail permissions such as Mail.ReadWrite and MailboxSettings.ReadWrite are designed for reading and sending mail, not for managing Exchange objects via PowerShell. Exchange.ManageAsApp is the dedicated permission for app-only Exchange management and is the only one you need for any RBAC-controlled automation workload. Granting Graph mail permissions on top of this broadens the attack surface without adding any capability.