|
| 1 | +--- |
| 2 | +title: Resolve Issues in Exchange Online PowerShell Module after WAM Integration |
| 3 | +description: Resolves compatibility issues when using Exchange Online PowerShell after Web Account Manager integration. |
| 4 | +author: cloud-writer |
| 5 | +ms.author: meerak |
| 6 | +audience: ITPro |
| 7 | +ms.topic: troubleshooting |
| 8 | +ms.custom: |
| 9 | + - sap:Administrative Tasks |
| 10 | + - Exchange Online |
| 11 | + - CSSTroubleshoot |
| 12 | +manager: dcscontentpm |
| 13 | +search.appverid: |
| 14 | + - MET150 |
| 15 | +appliesto: |
| 16 | + - Exchange Online |
| 17 | +ms.date: 08/21/2025 |
| 18 | +ms.reviewer: vivepai, ninob |
| 19 | +--- |
| 20 | +# Resolve issues in Exchange Online PowerShell module after WAM integration |
| 21 | + |
| 22 | +Beginning in Exchange Online PowerShell module version 3.7.0, Microsoft is implementing Web Account Manager (WAM) as the default authentication broker for user authentication. Although WAM offers improved security and a streamlined user experience, it might cause compatibility challenges in some situations. This article discusses these situations and provides workarounds for them. |
| 23 | + |
| 24 | +> [!NOTE] |
| 25 | +> Although you can use the **DisableWAM** switch together with the [Connect-ExchangeOnline](/powershell/module/exchangepowershell/connect-exchangeonline) command to disable WAM when you connect to Exchange Online PowerShell, you should use this option only as a temporary method. If you require assistance to resolve issues without having to disable WAM, contact Microsoft Support at [[email protected]](mailto:[email protected]). |
| 26 | +
|
| 27 | +## Scenario: Using the RunAs option |
| 28 | + |
| 29 | +### Symptoms |
| 30 | + |
| 31 | +When you run the `Connect-ExchangeOnline` PowerShell command under a different user context than the credentials that were used to sign in to Windows, WAM-based authentication fails. |
| 32 | + |
| 33 | +In this scenario, you receive the following error message: |
| 34 | + |
| 35 | +> One or more errors occurred. (Unknown Status: Unexpected Error: 0xffffffff80070520 Context: A specified logon session does not exist. It may already have been terminated. Tag: 0x21420087 (error code -2147023584) (internal error code 557973639))- at Microsoft.Exchange.Management.ExoPowershellSnapin.GetConnectionContext.ProcessRecord() at System.Management.Automation.CommandProcessor.ProcessRecord();InnerException : Unknown Status: Unexpected Error: 0xffffffff80070520 Context: A specified logon session does not exist. It may already have been terminated. Tag: 0x21420087 (error code -2147023584) (internal error code 557973639)…; |
| 36 | +
|
| 37 | +### Cause |
| 38 | + |
| 39 | +WAM relies on the active user session to load its plugins and to access cryptographic keys and certificates that are associated with a user profile. If you run PowerShell under a different context, this action isolates the session and prevents WAM from functioning correctly. |
| 40 | + |
| 41 | +### Workaround |
| 42 | + |
| 43 | +For security, you shouldn't use the `RunAs` option to run PowerShell commands. This method bypasses key protections and introduces risks that are associated with impersonation and session isolation. |
| 44 | + |
| 45 | +Run PowerShell only in the same context as that of the signed-in Windows user to ensure compatibility with WAM. You can disable WAM temporarily by using the DisableWAM parameter together with the `Connect-ExchangeOnline` PowerShell command to connect to Exchange Online and then re-enable WAM. |
| 46 | + |
| 47 | +## Scenario: Running GDAP flows |
| 48 | + |
| 49 | +### Symptoms |
| 50 | + |
| 51 | +In certain Granular Delegated Admin Privileges (GDAP) flows, WAM-based authentication causes tokens to miss required WIDS claims. |
| 52 | + |
| 53 | +In this scenario, you receive the following error message: |
| 54 | + |
| 55 | +> The role assigned to user '[email protected]' isn't supported in this scenario. |
| 56 | +
|
| 57 | +### Cause |
| 58 | + |
| 59 | +WAM might not correctly populate all the required claims in GDAP flows, especially if you use the `-DelegatedOrganization` parameter. |
| 60 | + |
| 61 | +### Workaround |
| 62 | + |
| 63 | +Disable WAM temporarily to connect to Exchange Online PowerShell in GDAP flows. |
| 64 | + |
| 65 | +Collect diagnostic logs by using the -EnableErrorReporting parameter together with the `Connect-ExchangeOnline` PowerShell command, and send the logs to [[email protected]](mailto:[email protected]). |
| 66 | + |
| 67 | +## Scenario: Using Windows Task Scheduler |
| 68 | + |
| 69 | +### Symptoms |
| 70 | + |
| 71 | +Scripts that use WAM-based authentication fail when they're run in the Windows Task Scheduler by having the **Run whether user is logged on or not** security option enabled. |
| 72 | + |
| 73 | +In this scenario, you receive the following error message: |
| 74 | + |
| 75 | +> One or more errors occurred. (Unknown Status: Unexpected Error: 0xffffffff80070520 Context: A specified logon session does not exist. It may already have been terminated. Tag: 0x21420087 (error code -2147023584) (internal error code 557973639))- at Microsoft.Exchange.Management.ExoPowershellSnapin.GetConnectionContext.ProcessRecord() at System.Management.Automation.CommandProcessor.ProcessRecord();InnerException : Unknown Status: Unexpected Error: 0xffffffff80070520 Context: A specified logon session does not exist. It may already have been terminated. Tag: 0x21420087 (error code -2147023584) (internal error code 557973639)…; |
| 76 | +
|
| 77 | +### Cause |
| 78 | + |
| 79 | +WAM requires an active user session in order to function. In inactive sessions, critical components such as **%LOCALAPPDATA%**, cryptographic keys, and certificates are inaccessible. |
| 80 | + |
| 81 | +When the script execution starts, it has to sign in to Exchange Online. However, if the user doesn't sign in to the system, the script sign-in fails because WAM doesn't have the required user information to facilitate the script's sign-in attempt. |
| 82 | + |
| 83 | +### Workaround |
| 84 | + |
| 85 | +To run automated scripts, use certificate-based authentication. This method is secure and recommended. Alternatively, you can run scripts by using scheduling methods that preserve the user session context. |
0 commit comments