Connect-exchangeonline in azure shell not possible anymore

Hello Michelangelo Bottura

Thank you for reaching out to Microsoft Q&A regarding the "UnAuthorized" error you're encountering when using the Connect-ExchangeOnline. It looks like you're running into a compatibility issue with the Web Account Manager (WAM) authentication feature introduced in recent ExchangeOnlineManagement module updates. This change can interfere with Cloud Shell's authentication flow, leading to failures during token handling or post-authentication steps, such as fetching the banner content. To resolve this, you can try the following workarounds:

1. Disable WAM Authentication (Recommended for Latest Module):
   • Load the module: Import-Module -Name ExchangeOnlineManagement -MinimumVersion 3.8.0
   • Connect with WAM disabled: Connect-ExchangeOnline -DisableWAM -Verbose
   • This reverts to the previous authentication behavior without downgrading.
2. Use Device Code Authentication:
   • Load the module: Import-Module -Name ExchangeOnlineManagement -MinimumVersion 3.8.0
   • Connect using device code: Connect-ExchangeOnline -Device -Verbose
   • Follow the on-screen instructions: Visit the provided URL in a browser, enter the code, and sign in. This method is suitable for environments like Cloud Shell without direct browser integration.
3. Downgrade to a Pre-WAM Module Version (Temporary Fix):
   • Remove the loaded module: Remove-Module -Name ExchangeOnlineManagement
   • Uninstall newer versions: Uninstall-Module -Name ExchangeOnlineManagement -AllVersions -Force
   • Install version 3.5.0: Install-Module -Name ExchangeOnlineManagement -RequiredVersion 3.5.0 -Scope CurrentUser -Force
   • Import and connect: Import-Module -Name ExchangeOnlineManagement -MinimumVersion 3.5.0; Connect-ExchangeOnline -Verbose
   • Note: This version may lack some newer features, so consider it a short-term solution.

If these steps don't resolve the issue, please verify your account's Remote PowerShell access by running Get-User -Identity yourUPN | Select RemotePowerShellEnabled (once connected) to ensure it's enabled. Additionally, confirm you have the appropriate Exchange admin roles assigned.

Hope this helps.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Two days later, the issue disappeared.
Steps to debug after first noticing the error:

• determine the current exchangeonlinemanagement module baked in in the cloud shell: 3.8.0
• test "connect-exchangeonline" error (module 3.8.0)
• install a previous version (3.7.0)in the home folder, which overrides the default one
• restart cloud shell
• test "connect-exchangeonline" error (a different one, module 3.7.0)

Now:

• test "connect-exchangeonline" (module 3.7.0): OK
• unistall 3.7.0 module
• restart cloud shell
• test "connect-exchangeonline" (module 3.8.0): OK

To sum up: no corrective actions were possible to resolve the issue. However, it disappeared on its own after two days.
Output below:

PS /home/myself> connect-exchangeOnline -Verbose                                                                                                        VERBOSE: Computed version info: 3.7.0          
VERBOSE: ModuleVersion: 3.7.0
VERBOSE: [ThreadID: #] Trying to get a new token from AAD for cloudshell login
VERBOSE: [ThreadID: #] Uri string for cloudshell login http://localhost:50342/oauth2/token?resource=https%3A%2F%2Foutlook.office365.com%2F&api-version=2018-02-01.
VERBOSE: [ThreadID: #] Successfully got a token from AAD
----------------------------------------------------------------------------------------
This V3 EXO PowerShell module contains new REST API backed Exchange Online cmdlets which doesn't require WinRM for Client-Server communication. You can now run these cmdlets after turning off WinRM Basic Auth in your client machine thus making it more secure.

Unlike the EXO* prefixed cmdlets, the cmdlets in this module support full functional parity with the RPS (V1) cmdlets.

V3 cmdlets in the downloaded module are resilient to transient failures, handling retries and throttling errors inherently.

REST backed EOP and SCC cmdlets are also available in the V3 module. Similar to EXO, the cmdlets can be run without WinRM basic auth enabled.

For more information check https://aka.ms/exov3-module

Starting with EXO V3.7, use the LoadCmdletHelp parameter alongside Connect-ExchangeOnline to access the Get-Help cmdlet, as it will not loaded by default.
----------------------------------------------------------------------------------------
VERBOSE: AutoGen EXOModule created at  /tmp/tmpEXO_ffgmmmwi.30x
VERBOSE: Running Configure-AppSettings
VERBOSE: Setting PrintWarningsReceivedFromServer to False
VERBOSE: Logs location is reset to /tmp/EXOCmdletTelemetry
VERBOSE: Max directory size reset to 2000000000
VERBOSE: Max log size reset to 100000000
VERBOSE: Log level reset to Default
VERBOSE: Logger reset to null.

PS /home/myself> get-module -listAvailable | ? {$_.name -match "exch" }                 
    Directory: /home/myself/.local/share/powershell/Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     3.7.0                 ExchangeOnlineManagement            Desk      {Add-VivaModuleFeaturePolicy, Get-ConnectionInformation, Get-DefaultTenantBr…
    Directory: /usr/local/share/powershell/Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     3.8.0                 ExchangeOnlineManagement            Desk      {Add-VivaModuleFeaturePolicy, Add-VivaOrgInsightsDelegatedRole, Get-Connecti…
PS /home/myself> Uninstall-Module -name exchangeonlinemanagement -MaximumVersion 3.7.0
PS /home/myself> get-module -listAvailable | ? {$_.name -match "exch" }               
    Directory: /usr/local/share/powershell/Modules
ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     3.8.0                 ExchangeOnlineManagement            Desk      {Add-VivaModuleFeaturePolicy, Add-VivaOrgInsightsDelegatedRole, Get-Connecti…

# CLOUD SHELL RESTART

PS /home/myself> Connect-ExchangeOnline -verbose                       
VERBOSE: Computed version info: 3.8.0
VERBOSE: ModuleVersion: 3.8.0
VERBOSE: [ThreadID: #] Trying to get a new token from AAD for cloudshell login
VERBOSE: [ThreadID: #] Uri string for cloudshell login http://localhost:50342/oauth2/token?resource=https%3A%2F%2Foutlook.office365.com%2F&api-version=2018-02-01.
VERBOSE: [ThreadID: #] Successfully got a token from AAD
----------------------------------------------------------------------------------------
This V3 EXO PowerShell module contains new REST API backed Exchange Online cmdlets which doesn't require WinRM for Client-Server communication. You can now run these cmdlets after turning off WinRM Basic Auth in your client machine thus making it more secure. 
Unlike the EXO* prefixed cmdlets, the cmdlets in this module support full functional parity with the RPS (V1) cmdlets.
V3 cmdlets in the downloaded module are resilient to transient failures, handling retries and throttling errors inherently. 
REST backed EOP and SCC cmdlets are also available in the V3 module. Similar to EXO, the cmdlets can be run without WinRM basic auth enabled. 
For more information check https://aka.ms/exov3-module
Starting with EXO V3.7, use the LoadCmdletHelp parameter alongside Connect-ExchangeOnline to access the Get-Help cmdlet, as it will not be loaded by default
----------------------------------------------------------------------------------------
VERBOSE: AutoGen EXOModule created at  /tmp/tmpEXO_ual3f402.itr
VERBOSE: Running Configure-AppSettings
VERBOSE: Setting PrintWarningsReceivedFromServer to False
VERBOSE: Logs location is reset to /tmp/EXOCmdletTelemetry
VERBOSE: Max directory size reset to 2000000000
VERBOSE: Max log size reset to 100000000
VERBOSE: Log level reset to Default
VERBOSE: Logger reset to null.

Additional data point: -DisableWAM does not fix it, but -Device and -ShowBanner:$false do (module 3.10.0)

Summary: Same OperationStopped: UnAuthorized error as reported above, in Azure Cloud Shell (PowerShell), on ExchangeOnlineManagement 3.10.0. No issues at all through June and into the beginning of July — this started partway through July with no changes on my side (module version, account, roles, and Azure subscription/tenant context were all unchanged). Adding this because I was able to narrow down which fixes actually work, which doesn't fully match the WAM explanation given earlier in this thread.

Environment

• Azure Cloud Shell (PowerShell)
• ExchangeOnlineManagement 3.10.0
• Single Azure AD directory/tenant (ruled out any tenant/subscription mismatch as a cause)

Connect-ExchangeOnline -Verbose output

Connect-ExchangeOnline -Verbose
VERBOSE: Returning precomputed version info: 3.10.0
VERBOSE: ModuleVersion: 3.10.0
VERBOSE: [ThreadID: #] Trying to get a new token from AAD for cloudshell login
VERBOSE: [ThreadID: #] Uri string for cloudshell login http://localhost:50342/oauth2/token?resource=https%3A%2F%2Foutlook.office365.com%2F&api-version=2018-02-01.
VERBOSE: [ThreadID: #] Successfully got a token from AAD
VERBOSE: Failed to fetch banner content from server. Reason: Object reference not set to an instance of an object.
VERBOSE: ConnectionContext Removed
OperationStopped: UnAuthorized

Token acquisition succeeds cleanly — it fails specifically on the banner-content fetch that runs right after.

What didn't fix it

• Connect-ExchangeOnline -DisableWAM -Verbose → same error, same point of failure.

What fixed it

• Connect-ExchangeOnline -Device → works (bypasses the silent Cloud Shell login broker entirely, uses interactive device-code sign-in instead).
• Connect-ExchangeOnline -ShowBanner:$false → works (skips the banner fetch that's throwing the null reference).

Conclusion: Since -DisableWAM has no effect, WAM itself doesn't appear to be the actual cause in this case, despite being the general recommendation for this error string. The failure looks localized to the banner-content fetch that runs after the silent cloudshell login token exchange succeeds — -Device avoids it by skipping that login path altogether, and -ShowBanner:$false avoids it by skipping the banner fetch specifically. For anyone hitting this on 3.10.0 in Cloud Shell, -ShowBanner:$false is the simplest non-interactive workaround.

I have the same issue, and a Microsoft "support technician" pointed me to this thread. Was there ever a concrete resolution of this?