I have a PowerShell script, either from the Knowledge Base, from Support or somewhere from the internet. I'm a bit lost, though. How do I install this and what do I need to do in order to get it to work properly?
This article applies to PRTG Network Monitor 16 or later
Guide For PowerShell Based Custom Sensors
Do not worry, we guide you through the installation of PowerShell scripts to PRTG. Simply follow these steps:
1. Configure the Execution Policy of the PRTG Server
The execution policy configured on a host specifies what scripts can be executed on the Windows host. There are several available settings for that:
|Restricted||No scripts can be executed directly, only within an interactive session.|
|AllSigned||Only scripts from a trusted author can be executed.|
|RemoteSigned||Downloaded scripts have to be signed prior to execution.|
|Unrestricted||No restrictions, all codes will be executed.|
By default, the execution policy is set to Restricted. It will hinder PRTG from executing scripts, therefore we cannot use them.
We need to set it first. Because the scripts are always executed by the PRTG Probe service (the PRTG Probe is a 32 bit application), we need to use the 32 bit PowerShell:
- Open Windows PowerShell (x86), respectively Windows PowerShell (32bit) as Administrator.
- Set the ExecutionPolicy to RemoteSigned with the following command:
- Remember that when the device is located on a remote probe, you need to do the steps on the Remote Probe system, not on the PRTG Core Server system.
That's it actually. Let's proceed to the next step. Note that you need to do this only once.
2. Install the PowerShell Script
Next, we'll have to check the output of the script. We only have two options here:
|One line||EXE/Script||<PRTG Application Directory>\Custom Sensors\EXE\|
|XML||EXE/Script (Advanced)||<PRTG Application Directory>\Custom Sensors\EXEXML\|
If you already know the output type, simply copy the script to the corresponding directory.
Make sure it has .ps1 as extension. However, if it's unsure what kind of script you have, you have two options:
- Open up the script and search for something like Write-Host or Out-Host
- If the output looks like XML, place the script into the EXEXML folder.
Otherwise, place it into the EXE folder.
3. Test the Script
Okay, the script is now installed. But how do we use it correctly? If the script is documented properly (either via PowerShell or text documentation), this should be no problem. You can show the PowerShell help for a script like that:
Get-Help <path-to-the-script> -detailed
It will show you a description of the script and what parameters are supported including their description. If the script lacks documentation entirely, simply open up the script within an editor and search for param. The parameters are listed there. You can then call the script either like this:
-parameter1 <testvalue> -parameter2 <testvalue2>
You can omit the parameters if you enter them in the correct order. If the script works fine, you can proceed with creating the sensor in PRTG.
4. Create the Sensor in PRTG
|EXE/Script||Select the script you have just installed.|
|Parameters||Enter the parameters. Remember that you can use the placeholders here.|
|Security Context||Chose if you want the script to be run using the user account of the probe service or the one configured in the device.|
|Mutex Name||If you have many sensors that run concurrently, you can configure different mutex names, so they don't hinder each other.|
That's it, you're done!
|Problem||Response not well formed: "(File C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\test.ps1 cannot be loaded because the execution of scripts is disabled on this system."|
|Solution1||The execution policy is not configured correctly on the host. Go through Step 1 of this tutorial to resolve this.|
|Solution2||Double check that the downloaded script-file is not "Blocked". Right-click the script file, on the General tab you'll see: "This File came from another computed and might be blocked to help protect this computer." Click "Unblock".|
|Problem||The sensor shows UnauthorizedAccess.|
|Solution||This is probably due to the user account configured in the probe service or device, depending on what you selected as security context. Make sure that the user has all permissions necessary to execute the sensor properly.|
|Problem||The term '<insert-cmdlet-name-here>' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.|
|Solution||This indicates that either a command or function used by the script is not declared properly within the script or that it uses a cmdlet that is not available on the PRTG server. Most likely, the latter one is the case. Please make sure that you're running the latest Windows Management Framework.|
|Problem||The sensor displayed incorrect results (0) or no values after migrating the sensors to a new/different server/windows version. You may also get: XML: Junk after document element </text> -- JSON: The returned JSON does not match the expected structure (Invalid JSON.). (code: PE231) error messages.|
|Solution||Keep in mind that newer operating systems will usually run a newer powershell version, your cmdlets may be missing parameters or your variables may not be correctly called within text ($($var) instead of $var). Run the script from the command-line to confirm that it still works or adjust it if necessary.|
Could you by any chance provide a guide on creating lookup files to turn standard xml output into something PRTG can understand?
You might want to check the REST Custom Sensor, as it allow you to properly evaluate XML/JSON into PRTGesque channels :) Or do you require assistance with that?
Stephan Linke, Tech Support Team
I am getting the "Response not well formed ... cannot be loaded because the execution of scripts is disabled on this system" error even though I have tried setting the execution policy to RemoteSigned, Unrestricted, and Bypass on the system where the sensor is located (the probe system itself). I have also tried using the "-Scope LocalMachine" parameter and using both options for Security Context. I can log into the server and run the script from within a PowerShell process myself with no problems. What am I missing?
I have been down this path and hopefully I am at my end. There is an Advanced HTTP sensor that I am hoping will fit the bill. Stephan's suggestion sounds pefect, until you get under the hood. It is beta, does not support smart URL lookups (sensor only reports locally). The other option is to write a script or EXE which outputs the format you need and the values you need and that could work with a custom sensor. I would love it to take a remote native json or xml output returned as the deity(ies) intended....
If the Rest sensor mentioned was ever updated to support remote URLs as many other similar sensors are... it would be grand...
@TypoProne Thanks for your input. The Sensor is indeed still in beta and likely not make it into a non-beta state, as we're working on a successor that will be easier to handle. But no ETA on that yet :)