What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Cannot get custom EXE/Script PowerShell to work, PE132

Votes:

0

I'm having issues running a custom EXE/Script sensor. It's a simple PowerShell script that's tested to return string output in the form of value:message.

Status summary of the sensor:

Response not wellformed: "(File C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\test.ps1 ca nnot be loaded because the execution of scripts is disabled on this system. Ple ase see "get-help about_signing" for more details. At line:1 char:157 + if ($PSVersionTable.PSVersion -ge (new-object 'Version' 5,0)) { Import-Module Microsoft.PowerShell.Management; Import-Module Microsoft.PowerShell.Utility};& <<<< 'C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\test.ps1' ; exit $LASTEXITCODE + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException )" (code: PE132)

I also read somewhere that PRTG uses PowerShell 32bit when executing scripts so I've also verified profiles on both PowerShell and PowerShell (x86) on the target server are set to Unrestricted.

Also tried creating the custom sensor on another server that I've confirmed PowerShell execution policies on (unrestricted) and neither mine nor the demo scripts run (same error).

My PowerShell profile does not appear to be corrupt as I can remotely invoke powershell commands to my target server from other servers on the network and even from the PRTG server itself.

The Windows account being used is a domain admin.

I get the same exact issue/error when I setup a test sensor using the "Demo Powershell Script - Returns a fixed integer value.ps1".

exe-script-sensor pe132 powershell prtg

Created on Mar 24, 2016 9:33:27 PM

Last change on Mar 25, 2016 7:46:06 AM by  Felix Saure [Paessler Support]



11 Replies

Votes:

0

Dear blazedanblazin,

to run Powershell scripts, you need to allow it first by changing the execution policy. This can be done only when you start a Powershell console as administrator. To allow all scripts to run, use

Set-ExecutionPolicy Unrestricted

Created on Mar 25, 2016 9:44:59 AM by  Arne Seifert [Paessler Support]



Votes:

0

Guess I wasn't clear enough, but execution policy settings were already verified and set to Unrestricted.

Created on Mar 25, 2016 11:53:26 AM



Votes:

0

Dear blazedanblazin,

what happens when you run the same script from the console instead via the PRTG Exe/Script sensor?

Created on Mar 25, 2016 2:09:16 PM by  Arne Seifert [Paessler Support]



Votes:

0

The script runs just fine on the target server and when executed/invoked remotely on the PRTG server to the target server.

Ran locally on target server (mtladmin): PS C:\> powershell -file "
jaxwebmon\c$\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\test.ps1" 0:OK - Backups for configs exist!

Ran from PRTG server, remotely executed on target server (mtladmin): PS C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE> Invoke-Command -ComputerName mtladmin -file "
jaxwebmon\c$\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\test.ps1" 0:OK - Backups for configs exist!

Created on Mar 25, 2016 6:10:44 PM



Votes:

0

Dear blazedanblazin

In this case, please check the sensor's security context (via its settings tab.) If it is set to use the probe's security context, please change it to use the Windows credentials of the parent device. Please check the Windows credentials in the according device.

Created on Mar 28, 2016 11:28:12 AM by  Arne Seifert [Paessler Support]



Votes:

0

Changed the security context of the sensor to Use Windows credentials of parent device, un-paused the sensor, check now and still the same error.

Also verified the chain of Windows credential inheritance all the way back to the root and confirmed it should be using our AD service account which is a domain admin.

We do have another device that we use a custom sensor for NetworkFileCount.exe and it's security context is set to Use security context of probe service. We cloned that sensor over and of course tweaked some parameters to test it on our target device (mtladmin) and it works so I'm not sure if credentials are the issue in this case.

Created on Mar 28, 2016 12:15:44 PM



Votes:

1

Dear blazedanblazin

Even tough it might does not help, please enter the Windows credentials into the settings tab of the parent device of this sensor.

If you are 100% sure to have set the 32-bit powershell to Set-ExecutionPolicy Unrestricted (please doublecheck regardless), could it be that any group policy interferes?

Can you run bat files and/or exe files, meaning only ps1 files are blocked?

Created on Mar 28, 2016 2:06:52 PM by  Arne Seifert [Paessler Support]



Votes:

1

Just guessing..

What is your probe service running as? It should be Local system, I have seen that cause odd issues, and PRTG handles its own authentication.

Try running cmd as local system (psexec -i -s cmd.exe) then running the powershell script?

As Arne suggested, does running bat files have any issues. Is it as simple as file permissions to the folder?

Created on Mar 29, 2016 1:53:15 AM



Votes:

0

Found the issue, looks like you have to check both x64 and x32 bit powershell execution policies on BOTH servers, PRTG and the target system.

I confirmed my target server had both powershells set to unrestricted, BUT my PRTG server's x32bit powershell wasn't.

In my defense though I thought PRTG was remotely executing all sensors in some other consistent way, but I guess not. This now sounds like each sensor is executed remotely on target machines based on the type of sensor and what it's doing. That part doesn't appear to be clarified in the documentation I'd read through.

Thanks for all the assistance though.

Created on Mar 31, 2016 2:59:12 PM



Votes:

0

Another thing to watch for and little unrelated to the original issue, is after moving past the execution issues and giving my script some more verbose messages to return, I found that PRTG seems to have a character limits on messages before it deems them to be Not Wellformed and in turn doesn't relay values to Channels and always cause a Down state.

Took me a while, but after some hair pulling I found the number of characters in my returned message to be the issue. Once found I didn't feel like finding the exact count as I'd wasted enough time already.

Being new to PRTG also has it's challenges with Channels too, let me tell ya. Had an interesting time wrapping my head around them and how I could use the default Channels (which you can't get rid of) to throw my sensor into a Down state based on returned values.

Created on Mar 31, 2016 9:19:22 PM



Votes:

1

Ahhh..I get it, after re-reading some of your first comments "Ran from PRTG server, remotely executed on target server", it is clear that you are getting to the PRTG server, then remoting (via powershell) to the target server.

For Custom EXE script sensors, %100 of scripts are run on the PRTG server. The script may of course invoke a script on another server.

I have a brief page on the Custom EXE Sensor here https://thedomainiown.wordpress.com/prtg-related/general-custom-exe-script/ and a lot of examples that use it.

PRTG will chuck errors if your output has more that one ":" in it, eg "256:OK - Files in C:\Temp". Also PRTG does not log the status messages, only the status codes, but they can be useful for when it goes to an error state.

It took me a long time to figure this stuff out too. Now I understand it better than I understand my wife.

Created on Apr 2, 2016 10:07:43 AM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.