Azure Automation
An Azure service that is used to automate, configure, and install updates across hybrid environments.
Azure Automation script assistance as the script works on the local but fails when we execute it on the automation account Azure
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 18%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDZ%3C/text%3E%3C/svg%3E)
Daulat Zhi Imran Khan
21
Reputation points
Azure Automation script assistance as the script works on the local but fails when we execute it on the automation account Azure
Azure Automation
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-16T13:15:33.3733333+00:00 Here is my query,
I have a PowerShell script that I want to automate using an Azure Runbook.
The Objective is: The Script needs to run and download the Externalemailsent and send an email to all the required members daily.
We have tried even with Azure funtions but still fails
- I have created an App registration to connect via Tenant ID and Client ID
- I have uploaded the script to the Runbook, but even after all the required permissions, the process does not complete
- I have been working with our team for the past 3+ hrs and everything else failed for us
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-16T13:38:39.5866667+00:00 We are facing an authorization issue while running Exchange Online PowerShell message trace cmdlets from Azure Automation using certificate-based app-only authentication.
Scenario details:
- Execution environment: Azure Automation (PowerShell 5.1 runbook)
Module: ExchangeOnlineManagement (stable version)
Authentication method: App-only (Client ID + certificate)
Cmdlets used:
Connect-ExchangeOnline -AppId <ClientId> -CertificateThumbprint <Thumbprint> -Organization <tenant>.onmicrosoft.com`Get-MessageTrace` / `Get-MessageTraceV2` App Registration configuration: Office 365 Exchange Online → Application permission: `Exchange.ManageAsApp` Admin consent granted Certificate correctly uploaded and matching thumbprintObserved behavior:
Connect-ExchangeOnlinesucceedsAny attempt to run message trace cmdlets results in:
UnAuthorized (UnAuthorized)No permission-specific or RBAC-specific error is returned
Troubleshooting already performed:
Verified
Exchange.ManageAsApppermission and admin consentVerified certificate and tenant values
Verified module compatibility and runbook type (PowerShell, not PowerShell 7)
Attempted Exchange RBAC assignments and role configurations (no supported path found for app-only identities)
Behavior is consistent across multiple attempts
Question for support: Is certificate-based app-only authentication for Exchange Online PowerShell message trace cmdlets supported when executed from Azure Automation? If not, is the
UnAuthorized (UnAuthorized)response the expected behavior for this scenario?We would appreciate confirmation of the supported authentication model for running Exchange Online message trace operations from Azure Automation.We are facing an authorization issue while running Exchange Online PowerShell message trace cmdlets from Azure Automation using certificate-based app-only authentication.
Scenario details:
Execution environment: Azure Automation (PowerShell 5.1 runbook)
Module: ExchangeOnlineManagement (stable version)
Authentication method: App-only (Client ID + certificate)
Cmdlets used:
Connect-ExchangeOnline -AppId <ClientId> -CertificateThumbprint <Thumbprint> -Organization <tenant>.onmicrosoft.com`Get-MessageTrace` / `Get-MessageTraceV2` App Registration configuration: Office 365 Exchange Online → Application permission: `Exchange.ManageAsApp` Admin consent granted Certificate correctly uploaded and matching thumbprintObserved behavior:
Connect-ExchangeOnlinesucceedsAny attempt to run message trace cmdlets results in:
UnAuthorized (UnAuthorized)No permission-specific or RBAC-specific error is returned
Troubleshooting already performed:
Verified
Exchange.ManageAsApppermission and admin consentVerified certificate and tenant values
Verified module compatibility and runbook type (PowerShell, not PowerShell 7)
Attempted Exchange RBAC assignments and role configurations (no supported path found for app-only identities)
Behavior is consistent across multiple attempts
Question for support:
Is certificate-based app-only authentication for Exchange Online PowerShell message trace cmdlets supported when executed from Azure Automation?
If not, is theUnAuthorized (UnAuthorized)response the expected behavior for this scenario?We would appreciate confirmation of the supported authentication model for running Exchange Online message trace operations from Azure Automation.
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(236.8, 68%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBY%3C/text%3E%3C/svg%3E)
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator2026-01-16T15:16:31.74+00:00 Hello Daulat Zhi Imran Khan, we understand that you are trying to run Exchange Online message trace cmdlets (
Get-MessageTrace / Get-MessageTraceV2) from Azure Automation PowerShell 5.1 runbook using certificate-based app-only authentication.Connect-ExchangeOnlinesucceeds, but the message trace cmdlets fail with:UnAuthorized (UnAuthorized)App registration has
Exchange.ManageAsApppermission with admin consent. Standard troubleshooting (certificate, tenant, RBAC, module versions) has already been performed.and want to know if app-only authentication is supported for message trace cmdlets and whether the UnAuthorized response is expected.
- Exchange.ManageAsApp supports many administrative operations via app-only authentication.
- Message trace cmdlets require a user context for auditing and compliance.
- App-only authentication is not supported for Get-MessageTrace or Get-MessageTraceV2.
- The UnAuthorized (UnAuthorized) response is expected behavior, not a misconfiguration.
As per the Microsoft documentation: Cmdlets that access mailbox audit logs or message traces require delegated permissions and cannot run with app-only authentication.
To answer your questions:
- Its Not supported, The Exchange Online PowerShell cmdlets Get-MessageTrace and Get-MessageTraceV2 require a delegated user context. Even if your app has Exchange.ManageAsApp permission with admin consent, message trace operations cannot run using app-only authentication. App-only authentication in Exchange Online PowerShell You can refer the below document that message trace via app-only requires delegated or interactive context, not pure app-only in PowerShell. Message trace with app-based auth
- This is expected behavior, not a misconfiguration. App-only cannot execute message trace cmdlets.
Connect-ExchangeOnline -AppId … -CertificateThumbprintwill succeeds butGet-MessageTrace / Get-MessageTraceV2fails withUnAuthorized (UnAuthorized)
To resolve the you can try the below workaround:
- Create a dedicated service account in Azure AD.
- Assign Exchange Administrator or Compliance Search role (sufficient for message trace).
- Ensure the account has MFA disabled or use a service account that can be securely stored.
- Store credentials securely in Azure Automation:
- Create a Credential Asset in your Automation account.
- Example name: EXO-ServiceAccount.
- Connect from the runbook using the credential:
$cred = Get-AutomationPSCredential -Name "EXO-ServiceAccount" Connect-ExchangeOnline -Credential $cred -Organization <tenant>.onmicrosoft.com- Run Message Trace Cmdlets: Use standard cmdlets after connecting:
Example: retrieve message trace for the last day Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date)- Automate & Schedule
- Schedule the runbook in Azure Automation to run periodically.
- Optionally export results to Log Analytics, storage account, or email for reporting.
Hope this helps, If you need any assistance or encounter any issues, please od let us know, thanks.
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-19T03:49:18.1766667+00:00 Thanks for the this soltution, We are working on this we also wanted to know on how to automate the email process once the process is completed
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-19T04:10:29.9+00:00 Hi Bharath,
After creating a service account with Exchange admin access and creating a new runbook, we tried executing the steps provided, but it thorwed the different error states.
Can you pls help me by getting into a call and look into this
Failed AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '00000002-0000-0ff1-ce00-000000000000'. Trace ID: bddf42aa-5061-4610-a983-d8c286c5b000 Correlation ID: 5cbcd7d9-2896-4f92-85f4-c4b87471cab0 Timestamp: 2026-01-19 04:08:09Z (AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '00000002-0000-0ff1-ce00-000000000000'. Trace ID: bddf42aa-5061-4610-a983-d8c286c5b000 Correlation ID: 5cbcd7d9-2896-4f92-85f4-c4b87471cab0 Timestamp: 2026-01-19 04:08:09Z) -
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator
2026-01-19T17:18:08.77+00:00 Hello Daulat Zhi Imran Khan, The above error you are getting because of Your organization has enabled or enforced MFA for accessing Exchange Admin Center (EAC), or Conditional Access policy is triggering MFA because:
- You’re signing in from a new location, device, or network, or
- Admin portals (like Exchange Admin) now require MFA by policy
Exchange Admin Center is considered a high‑privilege portal, and Microsoft increasingly enforces MFA for admin access.
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-20T03:46:03.95+00:00 Hi Bharath,
Thanks for the information, but what is the solution for the problem?
I did dig deep into this and identified that we need to disable security deafults which is triggering this MFA.
But as per the compliance requirements for SOC and others this is not a best praticice.
Can you Pls let me know what are the others ways to automate it,
-
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator
2026-01-20T11:40:33.37+00:00 Hello Daulat Zhi Imran Khan, MFA is being triggered for your automation account, blocking certificate-based app-only authentication.
Security defaults or Conditional Access policies apply MFA to service principals or fallback to user authentication.
Do not disable security defaults globally (non-compliant). Instead, use Managed Identity or properly scoped Conditional Access exclusions for service principals.
Solution Paths:
- Managed Identity for Azure Automation.
- App-only authentication with correct permissions and Conditional Access exclusions.
To Use Managed Identity
- Enable System-assigned Managed Identity on your Automation Account.
- Grant the identity the Exchange.ManageAsApp role in Exchange Online.
Connect-ExchangeOnline -ManagedIdentity- Run your runbook > no MFA required, fully compliant.
Use Azure managed identities to connect to Exchange Online PowerShell | Microsoft Learn
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-20T11:51:23.1433333+00:00 Thanks Bharath, but a conditional access policy cannot be created until the Security defults has been turned off. This is the first message that shows when we are configuring the policy.
I am requesting a call, Pls tell me how this can be a achieved
-
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator
2026-01-20T17:48:08.7533333+00:00 Hello Daulat Zhi Imran Khan, You are right! Conditional Access cannot be created until turning off Security Defaults, but we do not comply with SOC criteria if Security Defaults are disabled globally.
Hence, App-only authentication is not supported by message trace cmdlets; MFA blocks service accounts; and using Conditional Access requires deactivating Security Defaults.
The only remaining completely compliant and supported automation option is Azure Automation with Managed Identity.
-
Daulat Zhi Imran Khan 21 Reputation points
2026-01-21T07:40:51.2333333+00:00 Hi Bharath,
We tried the Managed Identify but most the scripts/ are depcarted by microsft and does not support,
Here is the summary what I have tried to do
Issue Summary
We are attempting to automate Exchange Online message trace reporting using Azure Automation while keeping Security Defaults enabled.
All documented and forum-recommended approaches (certificate-based app auth, Exchange RBAC, Managed Identity) have been tested and consistently fail due to platform limitations, not misconfiguration.
We need Microsoft confirmation and guidance.
Environment
Azure Automation Account (Cloud runbook)
System-assigned Managed Identity enabled
Security Defaults enabled
ExchangeOnlineManagement module (v3.9.x)
Tenant: Exchange Online (cloud-only)
Authentication goal: Non-interactive / MFA-free automation
What We Tried (and Outcomes)
1. App-only authentication (certificate-based)
Connect-ExchangeOnline -AppId -CertificateThumbprintResult: ❌ Blocked by Security Defaults → MFA enforced (AADSTS50079)
This is expected behavior.
2. Conditional Access exclusions
Result: ❌ Not possible while Security Defaults are enabled Azure Portal explicitly requires disabling Security Defaults to use CA policies.
3. Managed Identity with Exchange Online PowerShell
Connect-ExchangeOnline -ManagedIdentity -Organization <tenant>Observed behavior:
Managed Identity token acquisition works inside Azure Automation
ExchangeOnlineManagement module requires
-OrganizationAuthentication succeeds up to token issuance
Authorization fails due to missing permissions
4. Exchange RBAC role assignment attempts
Tried assigning permissions via Exchange Online PowerShell:
Exchange.ManageAsApp→ Not a valid Exchange RBAC roleApplicationImpersonation→ Deprecated; new assignments blockedNew-ServicePrincipal→ Ambiguous / not applicable to Managed IdentityConclusion: Exchange RBAC is no longer a viable mechanism for granting app or MI access.
5. Entra ID / Enterprise Applications permissions
Exchange.ManageAsAppcan be granted to App RegistrationsManaged Identity Enterprise Applications have read-only permissions UI
No supported way to assign Exchange application permissions to a Managed Identity
Core Technical Problem (Root Cause)
Exchange Online PowerShell requires application-level authorization, but there is currently no supported permission path to grant those permissions to a Managed Identity.
Specifically:
Exchange RBAC for apps is deprecated
ApplicationImpersonation is blocked
Application permissions (
Exchange.ManageAsApp) exist only in Entra IDManaged Identity Enterprise Apps cannot be granted these permissions
Security Defaults block all user/app interactive auth
This creates a dead-end where:
App-only auth is blocked by MFA
Managed Identity auth cannot be authorized
No supported override exists
Why This Appears Confusing Publicly
Connect-ExchangeOnline -ManagedIdentityexistsDocs reference Managed Identity for EXO
Forum replies suggest Managed Identity works
But no end-to-end permission model exists
This leads customers to attempt unsupported combinations repeatedly.
Subject
Azure Automation + Managed Identity + Exchange Online PowerShell not supported (Permission model gap)
Issue Summary
We are attempting to automate Exchange Online message trace reporting using Azure Automation while keeping Security Defaults enabled.
All documented and forum-recommended approaches (certificate-based app auth, Exchange RBAC, Managed Identity) have been tested and consistently fail due to platform limitations, not misconfiguration.
We need Microsoft confirmation and guidance.
Environment
Azure Automation Account (Cloud runbook)
System-assigned Managed Identity enabled
Security Defaults enabled
ExchangeOnlineManagement module (v3.9.x)
Tenant: Exchange Online (cloud-only)
Authentication goal: Non-interactive / MFA-free automation
What We Tried (and Outcomes)
1. App-only authentication (certificate-based)
Connect-ExchangeOnlineResult:
❌ Blocked by Security Defaults → MFA enforced (AADSTS50079)This is expected behavior.
2. Conditional Access exclusions
Result:
❌ Not possible while Security Defaults are enabled
Azure Portal explicitly requires disabling Security Defaults to use CA policies.
3. Managed Identity with Exchange Online PowerShell
Connect-ExchangeOnlineObserved behavior:
Managed Identity token acquisition works inside Azure Automation
ExchangeOnlineManagement module requires
-OrganizationAuthentication succeeds up to token issuance
Authorization fails due to missing permissions
4. Exchange RBAC role assignment attempts
Tried assigning permissions via Exchange Online PowerShell:
Exchange.ManageAsApp→ Not a valid Exchange RBAC roleApplicationImpersonation→ Deprecated; new assignments blockedNew-ServicePrincipal→ Ambiguous / not applicable to Managed IdentityConclusion:
Exchange RBAC is no longer a viable mechanism for granting app or MI access.
5. Entra ID / Enterprise Applications permissions
Exchange.ManageAsAppcan be granted to App RegistrationsManaged Identity Enterprise Applications have read-only permissions UI
No supported way to assign Exchange application permissions to a Managed Identity
Core Technical Problem (Root Cause)
Exchange Online PowerShell requires application-level authorization, but there is currently no supported permission path to grant those permissions to a Managed Identity.
Specifically:
Exchange RBAC for apps is deprecated
ApplicationImpersonation is blocked
Application permissions (
Exchange.ManageAsApp) exist only in Entra IDManaged Identity Enterprise Apps cannot be granted these permissions
Security Defaults block all user/app interactive auth
This creates a dead-end where:
App-only auth is blocked by MFA
Managed Identity auth cannot be authorized
No supported override exists
Why This Appears Confusing Publicly
Connect-ExchangeOnline -ManagedIdentityexistsDocs reference Managed Identity for EXO
Forum replies suggest Managed Identity works
But no end-to-end permission model exists
This leads customers to attempt unsupported combinations repeatedly.
-
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator
2026-01-21T08:34:36.9666667+00:00 Hello Daulat Zhi Imran Khan, We have reached out to you in Private messages for additional details, could you please look into it and share us the details?
Thanks
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Anonymous2026-01-29T14:08:00.7766667+00:00 Hello Daulat Zhi Imran Khan,
Please follow these documents and let us know the results
1)https://learn.microsoft.com/en-us/powershell/exchange/connect-exo-powershell-managed-identity?view=exchange-ps#create-and-configure-a-system-assigned-managed-identity
2)https://learn.microsoft.com/en-us/powershell/exchange/connect-exo-powershell-managed-identity?view=exchange-ps#connect-to-exchange-online-powershell-using-system-assigned-managed-identity
Sign in to comment
Sign in to answer