Durable Function errors with MI on Set-Mailbox

Question

Durable Function errors with MI on Set-Mailbox

Kirt Sawaya 0 Microsoft Employee

I’m seeing an issue running Exchange Online Set- cmdlets* (e.g., Set-Mailbox) from an Azure Durable Function.

Environment

Plan: Flex Consumption
OS: Linux
PowerShell Durable Functions with ExternalDurablePowerShellSDK = True
Auth: Managed Identity (Connect-ExchangeOnline -ManagedIdentity)

Behavior

Managed Identity permissions are correctly configured
Same identity works on an Azure VM without issue
In the Durable Function (Activity function):
- Get-Mailbox → works
  - Set-Mailbox → fails

Example:

PowerShell

Connect-ExchangeOnline -ManagedIdentity

Get-Mailbox -Identity [EMAIL REDACTED] # Works

Set-Mailbox -Identity [EMAIL REDACTED] -LitigationHoldEnabled $true # Fails

Error

EXCEPTION: A server side error has occurred because of which the operation could not be completed. Please try again after some time. If the problem still persists, please reach out to MS support.

Key Observation

If I execute Set-Mailbox inside a script block using a different Managed Identity context, the command succeeds—even within the same function.

Expected Behavior

Set-Mailbox should succeed in the Durable Function, consistent with behavior on an Azure VM using the same identity.

Questions

Is this a known limitation with Set- cmdlets* in Durable Functions (Linux / Flex Consumption / External SDK)?
Could this be related to how the PowerShell worker or Exchange Online session is handled in this environment?
Are there recommended configurations or workarounds for running EXO write operations here?

Rakesh Mishra 9,340 Reputation points Microsoft External Staff Moderator

2026-05-22T23:21:37.7666667+00:00
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.

2 answers

Your answer

Answer 1

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:

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
Verify that exact identity has Exchange.ManageAsApp. - https://learn.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?view=exchange-ps
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
Validate mailbox Litigation Hold licensing. - https://learn.microsoft.com/en-us/microsoft-365/admin/misc/create-litigation-hold-mac?view=o365-worldwide
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.

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Share via

Durable Function errors with MI on Set-Mailbox

2 answers

Your answer