PowerShell Remote session getting disconnected with below error in every 150sec to 180 sec.

Copper Contributor

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. For
more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OperationStopped: (outlook.office365.com:String) [], PSRemotin
gTransportException
+ FullyQualifiedErrorId : JobFailure
+ PSComputerName : outlook.office365.com
Creating a new Remote PowerShell session using Modern Authentication for implicit remoting of "Get-DistributionGroup" command ...

Same script are using by other of my team member are working fine for them

8 Replies
MMM, If its working fine with other, I suspect it might be the Antivirus or firewall forcing the connection to close.
Also you can enable PowerShell logging for more insight
https://adamtheautomator.com/powershell-logging-2/
One of the things I might consider is using Wireshark to see more details about how to connection is ended and whats the details.

@sumabisw 

 

Since we have zero idea what you're doing, it might also pay to check the limits applied to different subscriptions while simultaneously verifying the licences you have had assigned to your are the same (where applicable) as those assigned to your colleagues.

 

 

It sounds like you're running into some kind of deliberate throttling.

 

 

Edited to include the following information

Based on the following thread (at the bottom):

 

 

Then if this relates to the Exchange Online PowerShell module (I'm going to refer to the V2 module), you might want to use the -PSSessionOption in the call Connect-ExchangeOnline .

 

 

Note

The OperationTimeout does not dictate for how long your command may execute. It dictates how long your local client waits for any kind of a response.

 

So, if you're running an inefficient query that causes the Exchange Online services to take Donkey's ages to run, then it's possible your client will hit the 180 second default operation wait limit, and having received nothing back from Exchange, will proceed to terminate the operation. This might (again, I'm making a lot of assumptions here) be the issue you're facing.

 

How to check your current operation timeout limit

 

Get-PSSession -Name "ExchangeOnlineInternalSession_*" | ForEach-Object { [PSCustomObject]@{ Id = $_.Id; Name = $_.Name; State = $_.State; OperationTimeout = $_.Runspace.ConnectionInfo.OperationTimeout;  } }

 

 

How to specify a different operation timeout during the connection

A value of 0 means there is no timeout limit. This should cause the client to wait indefinitely (doesn't stop the service from cancelling the operation, but that's outside your control and may relate to the per subscription limits linked in the initial part of my post.) 

 

Connect-ExchangeOnline -Organization robertsonpayne.onmicrosoft.com -ShowBanner:$false -PSSessionOption (New-PSSessionOption -OperationTimeout 0);

 

If you re-run the checking process, you should find you get output like this:

LainRobertson_0-1661339917434.png

 

 

Cheers,

Lain

@LainRobertson 

 

Hi Robertson.

 

I run your command and found the below details :

sumabisw_0-1661341658563.png

I am not sure but look like this time need to update as unlimited , Please suggest..

@sumabisw 

 

No, that shows a value of 180,000, which is 180,000 milliseconds, 180 seconds, or, in other words, three minutes.

 

Since three minutes is the default setting, this makes sense.

 

You might want to try the command I listed earlier to set the OperationTimeout to a value of 0, as 0 allows your client to wait indefinitely.

 

Cheers,

Lain

@LainRobertson

Nope that also did not worked. Same error , even set the value 0

Thanks..

@sumabisw 

 

Fair enough.

 

Assuming this is indeed in relation to the Exchange Online V2 module then that's all I could think of.

 

Cheers,

Lain

@sumabisw 

 

Yep, that's definitely the correct module which means I'm out of ideas.

 

The error still makes it sound like a client-side issue causing the client to stop waiting, I'm just not sure what the root cause may be if it's not the OperationTimeout interval.

 

Cheers,

Lain