cannot connect to exchange online via powershell

Hi Folks,

while I'd love to offer new information on this, I have little substantial to share compared to previous week.

We have spent a lot of hours, headaches and meetings on this. While we do make progress, it is slow and tedious, as transient issues like this tend to be (and our systems being seriously hardened even against casual internal access does not accelerate things, though security requires it).

So, no new insights to share, no ETA, but I wanted to reconfirm that we are still on the chase and fully aware that this issue is still there :)

Recapping a few things:

The recommended workaround for this problem is to connect like this:

Connect-ExchangeOnline -ConnectionUri "https://outlook.office365.com/powershell-liveid?SerializationLevel=Full"

This should work reliably - if it doesn't, we need to know! - and has the least impact.

It will keep working after we fix the problem and the only penalty is a very slight performance impact. I strongly advice against using techniques that redirect the server connected to instead (such as specifying a delegate organization):

• Your target endpoint is picked for optimal performance, redirecting is likely to cost more than increasing serialization level
• By interfering with our endpoint selection, you likely prevent us from optimizing loads as dynamically as otherwise possible. Potentially affecting not only yourself but also other users.

Individually, using this as a single person wouldn't matter much and you won't possibly see anybody's service denied through that, but you might negatively impact your org's Exchange Online PowerShell performance experience, if you do this across the board, especially if you forget to undo things as soon as things work again.

Also, this form remains a valuable feedback tool for our engineers working on this (myself included). As this issue is transient, maintaining a fresh state of affected users helps us. It also ensures we can see the spread (if any).

Thank you everybody for your patience and apologies for the inconvenience to all affected.

Will update as soon as I have anything new to share.

Cheers,

Friedrich

I am having the same issues as most of you guys when my import process broke on Sunday night...

I have found a workaround but I don't think it's a full fix...I have added the "-CommonName *" and I was able to import all the modules.  keep in mind the execution of commands like "get-mailbox UserName" will return more information than previous so Microsoft will have to acknowledge the changes and make corrections.

$TenantCredentials = new-object -typename System.Management.Automation.PSCredential -argumentlist $TenantUserName, $TenantPassword

$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $Tenantcredentials -Authentication "Basic" -AllowRedirection

Import-PSSession $exchangeSession -Prefix O365 -AllowClobber -Verbose -CommandName *

Try this, it seems to work for me...without this "-DelegatedOrganization" switch, I cannot import the session as you are currently experiencing.

Connect-ExchangeOnline -UserPrincipalName _______@______.___ -DelegatedOrganization TENANT.onmicrosoft.com

good luck

Hi folks,

a quick update from engineering:

This is a known issue with only some of the service endpoints, which is why some of you are affected, some not, and why it can go away after some time.

Engineering is working on a fix for this and will patch this as soon as possible (Since we are still narrowing it down, I can't give you a solid ETA yet, sorry), at which point everything should be back to normal. Once the problem has been resolved, I will most definitely post an update here.

In the meantime, there is a workaround to get you unblocked:

You can update the connection Uri to explicitly include the "SerializationLevel=Full" parameter.

For example:

Connect-ExchangeOnline

would become:

Connect-ExchangeOnline -ConnectionUri "https://outlook.office365.com/powershell-liveid?SerializationLevel=Full"

While this will keep working indefinitely, it increases the bandwidth use, potentially slowing execution at scale. I would recommend to not use this as a permanent update to your code and undo it once the issue has been resolved.

Note: We have received reports of this workaround not working for everybody and were able to reproduce the issue.

If the workaround above fails to work for you, there is another workaround option that will fully redirect you to another server:

Connect-ExchangeOnline -DelegatedOrganization TENANT.onmicrosoft.com

This is a less ideal solution, as it affects the target server selection, preventing our session performance optimization to fully apply, so only use this if option one fails you.

I'll try to keep you updated on this once I have any news on the issue :)

If you are affected by this and want to help us troubleshoot this, please fill out this quick survey. It helps us with developing a pattern and tracking down affected sessions.

Update: Fixed error in workaround

I was having the same issue. But using Connect-EXOPSSession -UserPrincipalName ******@contoso.com -DelegatedOrganization contoso.onmicrosoft.com worked fine..

This "Connect-EXOPSSession -UserPrincipalName ******@contoso.com" was enough previously but  -DelegatedOrganization with same tenant name works.