Odd Issue with PowerShell SAM Monitor on one Node

I worked with the System Engineering team to try and figure out the issue and it looks like the issue is something with Solarwinds trying to run the PS script. This issue cropped up roughly 2 days after updating to 2023.3 last month.

We have a MPE and APE

Tested Monitor through Edit Template in SAM.  This failed about 90% of the time with unknown status in the test.  We were monitoring what was going on with the node we were testing against and Orion was able to connect to the node and launch the PS monitor but it left the wsmprovhost.exe open. If I leave the monitor running out of Orion it will continue to open wsmprovhost.exe until resources are exhausted on the node.

Next we removed Solarwinds from the test completely. On the MPE and the APE we ran the script the script from PowerShell and the script worked fine.  There were no time outs and the results came through right away. 

From what we can tell when we use Solarwinds to run the PS Script via a SAM monitor it times out 90% of the time and some times it actually connects.

If we remove Solarwinds from the equation and run from PowerShell on each of the polling engines it works. 

Maybe there is a bug in 2023.3 that was missed?

I worked with the System Engineering team to try and figure out the issue and it looks like the issue is something with Solarwinds trying to run the PS script. This issue cropped up roughly 2 days after updating to 2023.3 last month.

We have a MPE and APE

Tested Monitor through Edit Template in SAM.  This failed about 90% of the time with unknown status in the test.  We were monitoring what was going on with the node we were testing against and Orion was able to connect to the node and launch the PS monitor but it left the wsmprovhost.exe open. If I leave the monitor running out of Orion it will continue to open wsmprovhost.exe until resources are exhausted on the node.

Next we removed Solarwinds from the test completely. On the MPE and the APE we ran the script the script from PowerShell and the script worked fine.  There were no time outs and the results came through right away. 

From what we can tell when we use Solarwinds to run the PS Script via a SAM monitor it times out 90% of the time and some times it actually connects.

If we remove Solarwinds from the equation and run from PowerShell on each of the polling engines it works. 

Maybe there is a bug in 2023.3 that was missed?

If it's set to remote host and you're testing it locally on the polling engines that test doesnt sound right. the equivalent would be invoking psremoting on the remote server from the solarwinds server in a script block, if so you probably also want to pass in creds and potentially change the variable output around a bit

That is what we are doing.  Setup the script to run via PowerShell from both Polling engines and it worked.  Tried to run the same script with the same account in Solarwinds and it times out.  WMI is connecting just fine the issue is something with Solarwinds and the PowerShell monitor.

We have the same thing happening in our environment. Fortunately this is a server deployed just for running monitoring scripts so I gave up on troubleshooting and instead I'm restarting it everyday. But similar to your case we are running several PowerShell monitor components on it, and it spawns dozens of processes which in the end consume all CPU resources and crash the server and those components times out randomly. 

Odd fun thing.  Everything is working fine this morning.  BUT I just discovered it looks like my MPE was updated to 2023.3 correctly when I ran the update on 9/12.  I checked the APE and it looks like the update never made it that far it is still on 2023.2. 

Looks like I may have found a bug in 2023.3.  I updated my APE to 2023.3 and the PowerShell monitors are dead again.  I really miss 2020.2.6.

You need to run this again after each update:

Find the line:  <add key="UseLegacyPowerShellImpersonation" value="false" 

Change the line to:  <add key="UseLegacyPowerShellImpersonation" value="true" />

Those settings are getting reverted to "false" after each update.

This also fixes odd issues with AppInsights for IIS.  I will be adding this to my Solarwinds Orion update process. 

This worked for me, thanks!

I ended up openning a support case on the issue as well.  We noticed that the setting change reverts back after SW updates.  I was informed that 2024.1, the setting reverting should no longer happen.

I still have the case open though, as I am trying to get a better understanding so we do not have to enable legacy authentication for powershell script.