How is it possible to add a user to Distribution List via Add-DistributionGroupMember from an Azure Automation Account?

Question

How is it possible to add a user to Distribution List via Add-DistributionGroupMember from an Azure Automation Account?

Tyler Wakefield 30

I have a PowerShell script that works both from PowerShell ISE (PS version 5.1.26100.8655) and VS Code (PS version 7.6.2) and successfully adds the designated user to a distribution list. I am now trying to get this script to run from an Automation Account so that I can invoke it from a Power Automate workflow later. However, I have been unable to get the script to run either in a PowerShell 5.1 or 7.2 runtime environment in my Azure subscription.

The Exchange Online Management module refuses to load in the 7.2 environment. I've tried manually packaging version 3.5.0 as suggested by many posts but every time I get an error that the specified module cannot be located even when the module list for the environment shows it is loaded and in an "Available" state. I have also tried downloading the file from the PS gallery and loading that but the same issue occurs.

I can get the module to load normally in the 5.1 runtime environment but every time I run the script it returns an error "Maximum retry count reached." I have confirmed that the application running the script has

Exchange.ManageAsApp permissions and is assigned as an Exchange Administrator. It seems like this should be a relatively straightforward task to automate but I cannot figure out how to get this script to execute properly.

Import-module MSAL.PS 
Import-module Microsoft.Graph.Authentication
Import-module Microsoft.Graph.Users
Import-module ExchangeOnlineManagement 

$applicationID = Get-AutomationVariable -Name "ApplicationID"
$applicationSecret = Get-AutomationVariable -Name "ApplicationSecret" | ConvertTo-SecureString -AsPlainText -Force
$tenantId = Get-AutomationVariable -Name "TenantID"

$ClientSecretCredential = New-Object -TypeName System.Management.Automation.PSCredential `
    -ArgumentList $applicationID, $applicationSecret

Try {
    
    Connect-MgGraph -tenant $tenantId -ClientSecretCredential $ClientSecretCredential
    
    #Get the User ID (using User Principal Name)
    $User = Get-MgUser -UserId $username
    $UserId = $User.Id


    #Generate token to connect to Exchange
    $details = @{
    'TenantId'     = $tenantId # Directory (tenant) ID
    'ClientId'     = $applicationID # Application (client) ID
    'ClientSecret' = $applicationSecret 
    'Scope'        = "https://outlook.office365.com/.default"
    }

    $token = Get-MsalToken @details

    Connect-ExchangeOnline -AccessToken $token.AccessToken -Organization "pereviewsoftware.com"

    #Add the user to the group
    Add-DistributionGroupMember -Identity $groupName -Member $UserId -ErrorAction Stop

    $result = @{
        Status = "Success"
        Message = "$username has been added to $groupName"
    }
}
Catch {
        $result = @{
        Status = "Error"
        ErrorMessage = $_.Exception.Message
        StackTrace = $_.ScriptStackTrace
        }
} Finally {
    Write-output ($result | ConvertTo-Json -Depth 10)
}

Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-06-25T18:45:51.0166667+00:00
Hello Tyler Wakefield

Thank you for posting your query on Microsoft Q&A platform.

In Azure Automation, the recommended approach is to use the ExchangeOnlineManagement module and connect to Exchange Online using either managed identity or certificate-based app-only authentication. The Connect-ExchangeOnline cmdlet officially supports parameters such as -ManagedIdentity, -ManagedIdentityAccountId, -Organization, -AppId, and certificate-based authentication parameters.

See the official cmdlet reference here: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/connect-exchangeonline?view=exchange-ps

A simplified managed identity example would be:

Import-Module ExchangeOnlineManagement Connect-ExchangeOnline ` -ManagedIdentity ` -Organization "<tenant>.onmicrosoft.com" ` -ShowBanner:$false Add-DistributionGroupMember ` -Identity $groupName ` -Member $username ` -BypassSecurityGroupManagerCheck ` -ErrorAction Stop Disconnect-ExchangeOnline -Confirm:$false

Please replace <tenant>.onmicrosoft.com with the tenant’s actual .onmicrosoft.com domain.

A few important points to validate:

Make sure the ExchangeOnlineManagement module is available in the same Azure Automation runtime environment where the runbook is running. Azure Automation uses runtime environments/modules to load PowerShell packages during job execution. References: Manage modules in Azure Automation and https://learn.microsoft.com/en-us/azure/automation/runtime-environment-overview

If you use app-only/certificate-based authentication instead of managed identity, the app must be configured for unattended Exchange Online PowerShell access. Microsoft documents this under app-only authentication for Exchange Online PowerShell. Reference: https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps

For the Add-DistributionGroupMember operation, permission is still controlled by Exchange Online RBAC. The cmdlet documentation states that permissions are required before running the cmdlet. It also documents the -BypassSecurityGroupManagerCheck switch. If the caller is not listed in the group’s ManagedBy property, this switch may be required, for distribution groups or mail-enabled security groups, the caller must be in the Organization Management role group or have the Security Group Creation and Membership role assigned. Reference: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/add-distributiongroupmember?view=exchange-ps

So, in this case, please verify both parts:

The Automation Account identity/app can connect to Exchange Online PowerShell.

The same identity/app has the required Exchange RBAC permissions to update distribution group membership.

Also, I would suggest testing the connection first with a simple read-only command before running the add-member operation, for example:

Connect-ExchangeOnline -ManagedIdentity -Organization "<tenant>.onmicrosoft.com" -ShowBanner:$false Get-AcceptedDomain

If this succeeds, then test:

Get-DistributionGroup -Identity $groupName

After that, run Add-DistributionGroupMember.

Kindly let us know if the solution provided worked for you.

If you need any further assistance, please feel free to reach out.

If you found the comment helpful, please consider clicking "Upvote it".

Thanks,

Suchitra.
Tyler Wakefield 30 Reputation points

2026-06-25T19:25:15.1533333+00:00
Hi @Suchitra Suregaunkar ,

As I specified in my original post, when I run the script from the PowerShell 5.1 runtime environment I am able to successfully connect to Exchange Online and the identity has the required API permissions and RBAC role. However, every command I've attempted to run from Exchange Online returns this error:

CheckRetryAndHandleWaitTime : Maximum retry count reached. At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_crkl0nwe.ylr\tmpEXO_crkl0nwe.ylr.psm1:1565 char:36
Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-06-25T19:57:10.4333333+00:00

Thanks for sharing the details. We will check this and keep you posted updates.
Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-06-26T00:12:03.27+00:00
Hello Tyler Wakefield Could you please clarify a few details:

Exchange Cmdlets Scope: Have you tried running a simple read-only Exchange cmdlet (e.g. Get-DistributionGroup, Get-Recipient, or Get-AcceptedDomain) in the runbook after connecting? Does every Exchange cmdlet (even queries) result in the "Maximum retry count reached" error, or is it specifically write operations (like adding group members) that fail?

Bypass Group Manager Check: When attempting to add the user to the distribution list, did you include the -BypassSecurityGroupManagerCheck switch on the Add-DistributionGroupMember cmdlet? If not, please try adding that parameter and let us know if it changes the outcome. (This helps determine if the failure is due to Exchange’s “group manager only” restriction on distribution group updates.)

Connection Method in Automation: Are you able (or willing) to test an alternative connection method in your Automation runbook, such as using a Managed Identity or certificate-based authentication, instead of passing a manual MSAL token via -AccessToken? For example, if your Automation account has a system-assigned managed identity with the appropriate roles, try:
Connect-ExchangeOnline -ManagedIdentity -Organization "<tenant>.onmicrosoft.com" -ShowBanner:$false
If you’ve attempted a managed identity or certificate approach already, please let us know the results.

ExchangeOnlineManagement Module Version: Which version of the ExchangeOnlineManagement module is imported in your Automation Account? If it’s an older version, consider updating to the latest (v3.6.x as of now) and re-testing. Also, confirm that PowerShellGet and PackageManagement modules are present, as they’re required for the EXO V3 module. Error Details / Logging: Could you try running the failing cmdlet outside of the try/catch block or with -Verbose logging enabled to capture more detail? If possible, inspect the full error or any inner exception beyond the “Maximum retry count reached” message. For instance, does the error contain a more specific cause (like “insufficient permissions” or “operation requires group manager”) in the extended output or job logs? Any extra details would help confirm whether this is a permission issue being masked by the retry logic.

Thanks,

Suchitra.

Tyler Wakefield 30

@Suchitra Suregaunkar I did some more testing this morning and I can confirm that I get the maximum retries error message on all the Get commands you listed. I have provided a more verbose error below.
The BypassSecurityGroupManagerCheck had not effect.

I have not yet tried the managed identity authentication because I couldn't find a direct way to assign the API permissions to the managed identity. I believe I may have found a workaround for that issue so I will give that a try later today to see if that makes any difference.

I did not have the PowerShellGet or PackageMangement modules installed previously but they are now and don't seem to do anything. The latest version of ExchangeOnlineMangement available from the Gallery is 3.10.0 but as previously stated I've tried manually loading the older version 3.5.0 without success.

CheckRetryAndHandleWaitTime : Maximum retry count reached.
At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_ulu41mv0.1wk\tmpEXO_ulu41mv0.1wk.psm1:1565 char:36
+ ... Retryable = CheckRetryAndHandleWaitTime -retryCount $retryCount -Erro ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,CheckRetryAndHandleWaitTime
 

Write-ErrorMessage : 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.
At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_ulu41mv0.1wk\tmpEXO_ulu41mv0.1wk.psm1:1194 char:13
+             Write-ErrorMessage $ErrorObject
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Write-ErrorMessage

Answer accepted by question author

0 additional answers

Your answer

Tyler Wakefield 30 Reputation points

2026-06-25T19:25:15.1533333+00:00

Hi @Suchitra Suregaunkar ,

As I specified in my original post, when I run the script from the PowerShell 5.1 runtime environment I am able to successfully connect to Exchange Online and the identity has the required API permissions and RBAC role. However, every command I've attempted to run from Exchange Online returns this error:

CheckRetryAndHandleWaitTime : Maximum retry count reached. At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_crkl0nwe.ylr\tmpEXO_crkl0nwe.ylr.psm1:1565 char:36
Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-06-25T19:57:10.4333333+00:00

Thanks for sharing the details. We will check this and keep you posted updates.
Tyler Wakefield 30 Reputation points

2026-06-26T13:22:38.41+00:00

@Suchitra Suregaunkar I did some more testing this morning and I can confirm that I get the maximum retries error message on all the Get commands you listed. I have provided a more verbose error below.
The BypassSecurityGroupManagerCheck had not effect.

I have not yet tried the managed identity authentication because I couldn't find a direct way to assign the API permissions to the managed identity. I believe I may have found a workaround for that issue so I will give that a try later today to see if that makes any difference.

I did not have the PowerShellGet or PackageMangement modules installed previously but they are now and don't seem to do anything. The latest version of ExchangeOnlineMangement available from the Gallery is 3.10.0 but as previously stated I've tried manually loading the older version 3.5.0 without success.

CheckRetryAndHandleWaitTime : Maximum retry count reached. At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_ulu41mv0.1wk\tmpEXO_ulu41mv0.1wk.psm1:1565 char:36 + ... Retryable = CheckRetryAndHandleWaitTime -retryCount $retryCount -Erro ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,CheckRetryAndHandleWaitTime Write-ErrorMessage : 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. At C:\Users\ContainerAdministrator\AppData\Local\Temp\tmpEXO_ulu41mv0.1wk\tmpEXO_ulu41mv0.1wk.psm1:1194 char:13 + Write-ErrorMessage $ErrorObject + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Write-ErrorMessage

Answer 1

hi Tyler Wakefield & thx for sharing urs issue here at Q&A portal,

For this job, I’d avoid the ExchangeOnlineManagement module in Azure Automation if possible.

Add-DistributionGroupMember is an Exchange cmdlet, so it depends on Exchange Online PowerShell session behavior. Azure Automation + EXO module version/runtime combos can be painful, esp PS 7.2. The Maximum retry count reached error usually means the EXO REST/remote session connection is failing/retrying, not that the group add itself is wrong.

Since u already have app-only auth, the cleaner route is Microsoft Graph if the target is a Microsoft 365 group. But if it’s a classic Exchange distribution list, Graph won’t fully replace Add-DistributionGroupMember. That’s the annoying split.

For classic DLs, use Exchange Online PowerShell app-only auth with certificate auth instead of client secret/access token. That’s the more supported automation pattern

Connect-ExchangeOnline `

-AppId $applicationID `

-CertificateThumbprint $certThumbprint `

-Organization 'pereviewsoftware.com'

Add-DistributionGroupMember -Identity $groupName -Member $username

A couple things I’d change in ur script

Use $username or user UPN for -Member, not the Graph object id. Exchange cmdlets usually resolve mail-enabled identity better by SMTP/UPN.

Don’t mix MSAL token + Connect-ExchangeOnline -AccessToken unless u really have to. In Automation, cert-based Connect-ExchangeOnline is less cursed.

For PS 7.2 in Azure Automation, make sure the EXO module version is supported in that runtime and imported into the Runtime environment, not just the Automation Account legacy modules area. Module UI saying Available doesn’t always mean that runtime can load it. Cute, right.

If this must be triggered from Power Automate, Power Automate > webhook > Azure Automation runbook is fine. Just keep the runbook auth as EXO app-only certificate auth. That should be way more stable than trying to hand-roll tokens for Exchange.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Tyler Wakefield 30 Reputation points

2026-06-26T15:16:44.4233333+00:00

Hi @Alex Burlachenko

Thank you for your response. I'm attempting to switch to certificate authentication following https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#set-up-app-only-authentication but even that seems to want to fight me. I created the self-signed cert per the instructions and uploaded it both to my App Registration and my Automation Account but running the connection command like this

Connect-ExchangeOnline -CertificateThumbPrint "REDACTED THUMBPRINT" -AppID "REDACTED APPLICATION ID" -Organization "<my tenant name>.onmicrosoft.com"

just throws an error about being unable to decode PII for some reason then displays the cert thumbprint and subject.

Failed IDX12729: Unable to decode the header '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]' as Base64Url encoded string. (IDX12729: Unable to decode the header '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]' as Base64Url encoded string. (Method not found: 'Void System.Text.Json.Utf8JsonReader..ctor(System.ReadOnlySpan`1<Byte>, System.Text.Json.JsonReaderOptions)'.))
Tyler Wakefield 30 Reputation points

2026-06-26T18:30:43.47+00:00

@Alex Burlachenko

I'm not sure what the underlying issue was at this point but I ended up throwing out everything that I had done previously and started from scratch with a new App Registration, a new 7.2 runtime environment, and a new version of the script trimmed down to the bare minimum functionality. After doing all of that and manually loading version 3.5.0 of the Exchange Online module I was able to successfully add my test user to the group.

I suspect it was likely a problem with having conflicting modules loaded since I ran into similar problems even after switching out the tokens for the certificate authentication but in either case it appears to be working now.