SOLVED

Error when connecting to Exchange online vis PowerShell

MVP

Trying to connect to various Exchange Online tenants using the new PowerShell V2 modules and receive this error on some:

 

Import-PSSession : Data returned by the remote Get-FormatData command is not in the expected format

 

have tried both v2 module and older modules and get same result. Doesn't happen on all tenants, just a few. isn't anything to do with workstation or process as all that is run is:

 

connect-exchangeonline

 

It certainly seems to be a tenant specific issue. The standard MS support is not being helpful and just closes the ticket without providing any real solutions.

 

Did see that this seems to be an issue for some about 7 days ago but this continues to persists and results is unable to connect to Exchange Online via PowerShell to run any scripts.

 

Can someone assist??

13 Replies

@Robert Crane Hey, you should report it https://docs.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2?view=exchange-ps#...

 

But I have also followed this thread, maybe this works for you as well?

 

"UPDATE - Added "-delegatedorganization xxx.onmicrosoft.com"   and now it connects to V2"

 

https://answers.microsoft.com/en-us/msoffice/forum/all/cannot-connect-to-exchange-online-via-powersh...


@ChristianBergstrom wrote:

@Robert Crane Hey, you should report it https://docs.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2?view=exchange-ps#...

 

But I have also followed this thread, maybe this works for you as well?

 

"UPDATE - Added "-delegatedorganization xxx.onmicrosoft.com"   and now it connects to V2"

 

https://answers.microsoft.com/en-us/msoffice/forum/all/cannot-connect-to-exchange-online-via-powersh...


Thanks, but it doesn't tell you where to send those logs unfortunately!

@Robert Crane At the bottom on the same page, it will take you here 

https://github.com/MicrosoftDocs/office-docs-powershell/issues

 

Or just attach the logs in a ticket to the MS support.

@ChristianBergstrom Ah yes, good old GitHub. Thanks.

 

MS Support via the standard logging a ticket process has proved remarkable unhelpful in all respects unfortunately. We are well beyond going back there due to lack of inaction.

@Robert Crane I'm afraid I know exactly what you mean. Anyway, hope it gets sorted!

@ChristianBergstrom Appreciate the assist. I'll report back if there is progress. Seems that:

Connect-ExchangeOnline -DelegatedOrganization '<tenant>.onmicrosoft.com'

 

will also work BUT that's a pain if you have a script that runs across many tenants, every day! Some of which need this and others that don't!

@ChristianBergstrom Neither command worked so still an issue. 

 

Where to from here?

best response confirmed by Robert Crane (MVP)
Solution

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. We are investigating this, whether it is the same problem or an entirely new one.

 

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 typo in workaround

@Fred_Weinmann Thank you very much for entering this conversation! @Robert Crane there you go ;)

@ChristianBergstrom actually, I really need to thank Robert and the MVP network here :)

I got roped into this because Robert asked an MVP friend for ideas who happened to know me.

 

Thus connected, we were able to narrow this down a lot due to the call Robert had with me, allowing me to hands on troubleshoot this together with him. Before that, the temporary nature of things was a real issue, making it difficult to track, when you can't reproduce an error.

@Fred_Weinmann Thanks for the info anyway. I am not experiencing the issue with V2, I was just trying to help Robert out.

@ChristianBergstrom and much appreciated that, truly :)

The community lives by the people that are part of it trying to help each other. Just wanted to make sure Roberts active and helpful interaction was also out there and not just something that silently happened in the background. Wouldn't have felt comfortable to "take all the glory" myself here (for values of glory in a tech disruption, anyway ^^).

@Fred_Weinmann We're also seeing this for one user in our tenant, but not another user, if that help or confuses things.  

1 best response

Accepted Solutions
best response confirmed by Robert Crane (MVP)
Solution

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. We are investigating this, whether it is the same problem or an entirely new one.

 

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 typo in workaround

View solution in original post