Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Powershell scripts need to use .NetFramework 3.5 or better

I have a script which uses Posh-SSH GitHub - darkoperator/Posh-SSH: PowerShell Module for automating tasks on remote systems using SSH but it needs .Net Framework 3.5 and we need to be able to use the syntax of Powershell 5 too, otherwise we're constrained by the limitations of Powershell v2.

Has anyone found a way to force/allow/cajole PowerShell scripts in SAM to run using Powershell 5, not the default v2. I've Googled at length before posting here to ask the experts.

We don't even have Powershell v2 installed on some servers, it's ancient.

If this case I need to run this script only on one server, not have compatibility across the environment. It logs in to an HPE MSA and issues commands to get the pool info (show pools), then the output which comes back (which is XML) is walked through to find the available space on the storage pools. With thin-provisioned LUNs we need to keep an eye on available raw storage.

I was getting 'Not defined' in the output. I tested by just adding two lines for a fake Message and Statistic, and that was then ok. What is happening is that it cannot connect via SSH to the MSA, therefore the output, which is generated in a loop, never happens because the connection fails and no output is received. All works on the exact same machine, where I developed it, when I run it in VScode. I made sure to include import-module for Posh-SSH, and I polite in putting an exit(0) at the end.

I can create an SQL database and tables, put the data in there, then display it in Solarwinds using Custom Object - but what's the point - we miss out on perfstack and all the other benefits this product is supposed to provide. I don't want to go back to writing dozens of scripts which email me with the data. There is an API method on the HPE MSA, but I don't want to re-engineer. Besides I have other ideas for using Posh-SSH in other places in Solarwinds.

Solarwinds should have an option to select the default Powershell version to use, either 2 or 5. It doesn't seem like this would be a lot of work.

In the meanwhile, has anybody got any clever tricks to get the job done? Get the script to launch powershell 5, then return the results to this script. Is that feasible?

We're going to keep running in to these limitations and they cause problems - it's nearly 2020, we should have an option to use Powershell 5 in the scripts. Or maybe it obvious and I'm just missing something.

Find more posts tagged with

Accepted answers

jonathanswift

That was embarrassing. I've got it all working now, pulling Pool availability info from HPE MSAs. When I was developing it, at some point I put the san variable name as $sans (because the script originally did multiple SANs), then changed it to $SAN in one place, but it still worked because the variable $SANs was still set. There were a few other niggles around my -join statements, and [floats] not converted to strings.

But in investigating this I think I can be sure now that the Powershell scripting engine is using 5.1 where available - I didn't have Powershell 2.0 even installed, nor .Net Framework 3.5, so it appears that even if the original SAM only supported Powershell 2.0, this is no longer true. Also, the idea of invoking commands remotely has given me extra ideas for new functionality in our setup.

All comments

jonathanswift

I can see that you can call another script using Invoke-Command, and that can pass back information - in this case I just want the XML output passed back.

I don't know if the Powershell script which is invoked is running as v5 (using .Net Framework 3.5 or better) yet, but the below is a prototype for testing;

script1.ps1

$SAN = "MYSAN01"

$Username = "Fred"

$Password = "Bl0ggs"

$results2 = Invoke-Command -ComputerName . -FilePath "<my personal path>\script2.ps1" -ArgumentList "-server $SAN", "-username $Username", "-password $Password"

$results2 | select-object processname,id | ft -AutoSize

calls script2.ps1

param (

[Parameter(Mandatory=$true)][string]$server = "",

[Parameter(Mandatory=$true)][string]$username = "",

[Parameter(Mandatory=$true)][string]$password = "" )

$result = Invoke-Command -ScriptBlock {(Get-process | Select processname,Id)}

return( $result )

This does return that process info;

ProcessName	Id
-----------	--
ApplicationFrameHost	10076
AppVShNotify	13356
AppVShNotify	14132

swpyatt

Create a Powershell monitor with the code and test it;

$a = $psversiontable.psversion

Write-Host "Statistic: 100"

Write-Host "Message: " $a

Output Result: Message.Statistic:5.1.14393.3053

Statistic.Statistic:100

Of course that is the version on the server running the monitor. You have to upgrade to the latest version.

jonathanswift

Good idea, so I added that to the first and second script, and ran it on the main poller (Windows 2019, test set up) and got;

Message.FirstScript:5.1.17763.771

Statistic.FirstScript:NaN

Message.SecondScript:5.1.17763.771

Statistic.SecondScript:NaN

Which suggests the script is running using PowerShell 5.1. Despite the component saying it requires PowerShell 2.0, that server doesn't have PowerShell 2.0 installed, nor .Net Framework 3.5 (only 4.7). Maybe the production machine has 2.0 and it's defaulting to that. I'll try it there. Thanks for the idea, that was a good way to check.

jonathanswift