Durable Function errors with MI on Set-Mailbox

The previously accepted answer was deleted, but after additional testing I found that invoking isolated PowerShell sessions through Script Blocks was the only consistently working solution for Set-Mailbox operations when using Managed Identity inside Azure Durable Functions.

In my testing:

• Authentication with the Managed Identity succeeded.
• Read-only Exchange Online cmdlets worked normally inside the Durable Function context.
• Set-Mailbox and other write operations intermittently failed or behaved inconsistently when executed directly within the Durable Function runspace/orchestration context.

The working workaround was to invoke the Exchange Online commands inside a separate PowerShell session using Script Blocks, which isolated the execution context from the Durable Function runtime. Once isolated, Set-Mailbox operations completed successfully with the same Managed Identity and RBAC permissions.

Based on the behavior observed, this appears related to how Durable Functions manage PowerShell runspaces/session state rather than an RBAC or Exchange permission issue.

Hello Kirt Sawaya ,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having Durable Function errors with MI on Set-Mailbox.

The issue is not proven to be a Durable Functions write-cmdlet limitation.

With the scenario and strongest evidence you provided that Set-Mailbox succeeds inside the same Function when executed under another Managed Identity context.

Therefore, the direct fix is:

1. Explicitly specify the intended user-assigned Managed Identity with -ManagedIdentityAccountId. - https://learn.microsoft.com/en-us/powershell/exchange/connect-exo-powershell-managed-identity?view=exchange-ps
2. Verify that exact identity has Exchange.ManageAsApp. - https://learn.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?view=exchange-ps
3. Verify that exact identity has Exchange RBAC rights for Set-Mailbox -LitigationHoldEnabled. - https://learn.microsoft.com/en-us/powershell/exchange/find-exchange-cmdlet-permissions?view=exchange-ps
4. Validate mailbox Litigation Hold licensing. - https://learn.microsoft.com/en-us/microsoft-365/admin/misc/create-litigation-hold-mac?view=o365-worldwide
5. Run connect/execute/disconnect inside the Durable activity function, not as a shared/stale session. - https://learn.microsoft.com/en-us/azure/durable-task/common/durable-task-code-constraints?tabs=csharp&pivots=durable-functions

If the issue still reproduces after those checks, then collect the failing activity invocation ID, Exchange request/correlation information, module version, Managed Identity object ID/client ID, and exact UTC timestamp, and open a Microsoft support case as a potential Exchange Online service-side failure. But based on the evidence, the root cause to eliminate is wrong or underprivileged Managed Identity being used by the Function, not Durable Functions itself. - https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/get-managementroleassignment?view=exchange-ps

Use the associated links for more reading and detail steps.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hello Kirt,

This behavior where Get-Mailbox succeeds but Set-Mailbox fails with a generic server-side error—strongly suggests a session state or token context issue within the PowerShell worker rather than a pure permissions problem, especially given that the exact same identity works seamlessly on an Azure VM.

In a Flex Consumption plan running Linux and the External PowerShell SDK, the out-of-process worker handles runspaces differently. Your key observation that a different Managed Identity context succeeds is a major clue: forcing a completely new authentication context establishes a clean session, successfully bypassing whatever stale or restricted token state is causing the failure in the primary runspace.

Here are the primary areas to investigate to resolve this:

1. Runspace and Session State Isolation:

The ExchangeOnlineManagement V3 module relies heavily on REST APIs and maintains session context. In Durable Functions, workers can reuse runspaces for Activity functions. If the session isn't explicitly closed, the token context for write operations might become invalid or clash with the external SDK's state management over time.

• Recommendation: Ensure you are explicitly clearing the connection at the very end of your Activity function using Disconnect-ExchangeOnline -Confirm:$false. This forces the session state to clear before the runspace is reused by the worker.

2. Verify Identity-Based Storage Connections:

Durable Functions rely heavily on Azure Storage for managing execution state and orchestrations. When running in Flex Consumption, verify that your underlying function app storage connections are functioning optimally, as token retrieval delays at the host level can occasionally bubble up into activity execution timeouts or generic errors. Ensure your app settings use the required and valid identity parameters, specifically checking that AzureWebJobsStorage__accountName is configured properly for your storage connection. You can reference the official documentation here: Azure Functions identity-based connections

3. Module Version Compatibility:

The PowerShell worker on Linux Flex Consumption environments can be highly sensitive to specific module versions when dealing with headless, non-interactive REST API calls to Exchange Online.

To help narrow this down further and attempt a reproduction, I have a couple of follow-up questions:

• What exact version of the ExchangeOnlineManagement module is defined in your requirements.psd1?
• Are you establishing the Connect-ExchangeOnline connection locally inside the specific Activity function, or is it being handled at a broader scope?

Please let me know these details and your findings in Private messages.

Note: This response is drafted with the help of AI systems.