PowerShell/PowerCLI Monitor Problem

Hello,

Are you running your PowerShell script in "Local Host" or "Remote Host" mode? When you run PowerShell script in "Local Host" execution mode in APM, the user is NT AUTHORITY\SYSTEM (and maybe this user can't add snap-in correctly).

Please try to switch to "Remote Host" and assign the administrator credential to the monitor.

Kind Regards,

Lukas Belza (SolarWinds development)

It's an ESX server, there are no remote credentials to run the script.

The script needs to be run locally.  I'll have a dig around and see if there are permission issues.

Hello,

In APM we can use another approach to run PowerShell script - using Windows VBscript monitor and running the local script. That should solve your issue. Please create the application with "Windows Script Monitor" and place following script:

fileName = "C:\PowerShellScript.ps1"
Set objShell = CreateObject("Wscript.Shell")
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    + "{impersonationLevel=impersonate,authenticationLevel=Pkt}!\\" _
    + strComputer + "\root\cimv2")
Set colSettings = objWMIService.ExecQuery _
    ("SELECT Architecture FROM Win32_Processor")
For Each objProcessor In colSettings
    If objProcessor.Architecture = 9 Then
                      powerpath = "%windir%\sysnative"
                        Exit For
    ElseIf objProcessor.Architecture = 0 Then
                      powerpath = "c:\windows\system32"
                        Exit For
    End If
Next
Set vPSscrIpt = objShell.Exec(powerpath + "\windowspowershell\v1.0\powershell.exe " + fileName)
vPSscrIpt.StdIn.Close()
Do While vPSscrIpt.Status = 0
    WScript.Sleep 100
Loop
WScript.Echo(vPSscrIpt.StdOut.ReadAll)
WScript.Quit vPSscrIpt.ExitCode

It's an ESX server, there are no remote credentials to run the script. The script needs to be run locally.  I'll have a dig around and see if there are permission issues.

I believe what lukas is saying is that under local user mode the script executes under the local "system" account. In remote mode the script uses the account specified under the credentials section of that component monitor. It may be that the "system" account doesn't have adequate permissions to properly execute but the local or domain user account you use to log into the machine does.

Hello,

Using "Remote Mode" I was able to run the script containing "Add-PSSnapin -Name VMware.VimAutomation.Core" command without any error (I had to set some WinRM settings to be able to executes the remote scripts in PowerShell).

But when I tried to run some real script to get some information from VMware ESX server, I got "Exception of type 'System.OutOfMemoryException' was thrown." error when Connect-VIServer command is executed.

When I execute the script in PowerShell console I see that memory consumption of poweshell.exe process grows up to 450-500 MB (see screenshot). For that reason we probably aren't able to run this script in our SAM PowerShell monitor (that is executed in JobEngineWorker.exe process together with another polling jobs).

The using of VB script as wrapper is good workaround - the VB script solves the issue with importing VMware snapin and also executes the script in separate powershell.exe process.

Kind Regards,

Lukas Belza (SolarWinds development)

Hey all, I have been trying to get the VB wrapper script working with SAM and can't for the life of me get the returned value back to the SAM Windows Script Monitor.  I confirmed that the powershell script works on the local server, I confirmed that the VB wrapper that calls the powershell script works locally on the server as well.  The WScript Echo does return the "Statistic: #" value that I'm looking for.  However, when running this in SAM and testing with the get output I get an error that the predefined columns are not present...essentially meaning that the Statistic: # is not being received properly by the script to the monitor.

Any ideas?

Could you post the script here, as well as the resulting output of the script? It may be something simple, such as your exit codes not being correct, or that your statistic/message values are improperly formatted.