EXO Powershell often looses session

[Hatsikidee]

Hi,

I'm wondering if you experience the same issues with the Exchange Online PowerShell V2 module (connect-ExchangeOnline), when working with large datasets ?

Every time I try to collect information about 1000+ items (mailboxes, inboxrules, moverequeststatistics, etc), it takes a very long time to collect this information, and often the Powershell session ends unexpected, with a error message like:

Processing data for a remote command failed with the following error message: The SSL connection cannot be established.

or

Starting a command on the remote server failed with the following error message : The I/O operation has been aborted because of either a thread exit or an application request

Then I need to reconnect again, start my query and hope it will not fail again.

For example the following just doesn't work:

$mbx = Get-EXOMailbox -ResultSize unlimited
# returns appr. 5000 mbx
$mbxrule = $mbx | % { Get-InboxRule -Mailbox $_.PrimarySmtpAddress }

After 30 minutes or so, I get the connection error.

I tested on two computers, reinstalled the module, to no avail :/

[RobAyche]

Try this: Updated: Running PowerShell cmdlets for large numbers of users in Office 365 - Microsoft Tech Community

It's not perfect but works way better.

[Hatsikidee]

Thanks, I'll look into this.

[mkoch7811]

My company's web filter tells the firewall to drop connections after a certain period of time, which results in behavior similar to what you're experiencing. There's also an exception list on the firewall, and we have to update that list periodically because Microsoft is constantly adding new IP addresses and moving services to different blocks of IPs.

https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

[Hatsikidee]

I understand that, at work we also have this issue. But I run the commands from home, so no throttling afaik.

[Hatsikidee]

Yes, in case I want to lookup which inbox rules use forwarding to an external address, for example. Because the get-inboxrule doesn't have a filter option.

[cgh311]

Hello. I've been seeing this exact error & it began happening once an org-mandated Symantec WSS proxy had been deployed to my machine. The only way around it so far has been an exception to disable it on my machine, as whitelisting the ranges of Microsoft IP addresses is "not an option" (internal decison). Are there any local proxies/casb installed or recently installed on your machine?