I've created an PowerShell script running a program and examining its output. When the scipt is run by PRTG as sensor, the sensor fails and the log says that the given path could not be found as a executable program, script, etc. However, if I run the script with as the same user also running the PRTG Core Service, in the same way PRTG does, the script executes sucessfully. The path of the program inside the script is given in absolute form. I re-checked it by copying the path from the error message in the log to PowerShell, causing the program to run.
Custom Sensor: Program not executable by script
Votes:
0
12 Replies
Votes:
3
Hi,
The PRTG probe that executes the script, by default runs on the local system account.
As long as the path of the program inside your script points to the local machine, this should not be a problem. If it is a network share, the local system account will not be able to access this share!
Votes:
0
The program to be executed resides on the local machine, no network share involved. The program in question is PortQry.exe from Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=17148).
Votes:
0
What command line parameters are you using with PortQry.exe in your script?
Votes:
0
-n, -e and -p (we need PortQry.exe to do UDP scans)
Votes:
0
With the -n parameter, the name of the (remote) computer is parsed. There might still be an issue here with the local system account not being allowed to run the port scan.
You can try to modify your script to write the output to a text file and next run it from PRTG. The output might differ from what you expect it to be.
Votes:
0
The command doesn't even reach the point where to parse the remote computer name. I tried dumping the command before actually executing it, which gave me just the command I expected. Still, the error message (of the CommandNotFoundException) tells me that the path "C:\Windows\System32\PortQry.exe" could not be found as a program, Cmdlet, etc. When copying this path to PowerShell, the command runs fine. Now I'm kinda running out of ideas of how to debug this.
Votes:
0
Could the PortState sensor from http://prtgtoolsfamily.com/?page=downloads_sensors be of any use?
Votes:
0
While the question remains why the original sensor refused to run from PRTG, the PortState sensor is indeed helpful as it covers just our need! Thanks for the hint!
Votes:
0
Using the PortState sensor, I'm running into some trouble interpreting the returned results. PRTGToolFamily, could you help me understand what the values returned by the sensor mean? The descriptions on the website says "number of seconds a TCP or UDP port is not responding", however, I'm receiving values ranging from 1 to 1.130.536, which raises some doubt about the correctness of the description.
Votes:
0
When using multiple instances of the PortState sensor, it is important to supply the sensors object id (-id= parameter).
When this parameter is omitted, results are mixed up and strange readings will appear.
Votes:
0
I've created multiple PortState sensors on the same host, however, they are all configured with -id=%sensorid
Votes:
1
Please open a support ticket by sending an email to [email protected], refering to this KB article.
Please also include some screenshots from your sensor settings and their return values.
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.
Add comment