A powerful email and collaboration platform developed by Microsoft, designed to support enterprise-level communication and productivity. Miscellaneous topics that do not fit into specific categories.
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)
-
ExchangeOnlineManagement3.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.