Cannot get custom EXE/Script PowerShell to work, PE132

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

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

Dear blazedanblazin,

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

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!

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.

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.

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?

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?

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.

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.

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.