Custom PowerShell/exe Sensor not Turning Red

Hello Wolfgang,

Thank you for your message.

Regarding what you would like to achieve, I recommend to use limits or a lookup file to define the sensor status based on the value returned instead of using the exit code.

Here is a modified version of your code which returns 0 and 1 based on the result of the command Test-Path:

try {
    $testpath = (Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')

    if ($testpath -eq $True){
        Write-OutPut "1:There is a Reboot Pending"
        Exit 0
    } else {
        Write-Output "0:Life is Good!  No Reboot Pending"
        Exit 0
    }
} catch{
    Write-Output "-1:$($_.exception.message) At line : $($_.InvocationInfo.ScriptLineNumber)"
    Exit 1
}

Then, in PRTG you need to configure the Upper Error Limit of the channel to 0 or a custom lookup. That way, PRTG will automatically trigger the Down state of the sensor.

If you have questions, do not hesitate.

Regard.

Thank you for the script idea. I have been working with it on and off all day and for some reason, I can't get it to run. The sensor shows "response not well-formed," the script and an error code PE132.

I found this KB: https://kb.paessler.com/en/topic/60719-error-code-pe132-script-powershell which I had read yesterday and changed the Write-Host line to "Write-Host "1:Reboot Pending" and still get the same message.

For any number of reasons, some of my servers don't reboot automatically after installing Patches, so I am checking the Windows Update Registry key to see if a reboot is pending.

Hello,

Thank you for your feedback.

Can you please replace Write-Host with Write-Output and then check if the same issue occurs after the next scanning interval or a manual scan.

Which sensor do you use in PRTG exactly ? Is it the EXE/Script sensor ? EXE/Script Advanced ? You can find the sensor type in its Overview tab on the right.

I am using the EXE/Script Sensor with PRTG version 21.4.73.1656

I replaced Write-Host with Write-output and that still gives the "response not-well-formed" message.

I realize that this code is not elegant, however, it helped me determine that PRTG is processing the entire script and then sending whatever the LAST write-output statement is in the script and ignoring the Conditional test.

$condition = $true
$result = 5

$testpath = (Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')

if ($testpath -eq $condition)
{ 
$result = 0

    Write-Output "0:A Reboot is required. With Exit Statement"
    Write-Output "50:Value from Reboot"
#    Exit 0
}


if ($testpath -ne $condition)
{
$result = 1

    Write-Output "1:A Reboot is NOT required. With Exit Statement"
    Write-Output "100:Value from No Reboot"

#    Exit 1
}

# Write-Output "$result:Variable"

Write-Output "1:Just a Test"

Also if I use the Write-Output "$result:Variable" line in the code, it gives me the same "Response not well-formed" message in the sensor output.

Hello Wolfgang,

Can you please let me know if that the separation "-------" in the response you provided belong to your code or if it is only for formatting purpose (for your response). This should be outside of the script.

Regarding the code, you are using Write-Output twice for each statement and therefore the response sent to the probe is not correct. You can only return one value/message with the EXE/Script sensor.

Note that the conditional statement can't be avoided by PRTG, however it could be possible that the probe encounters an error while checking the path (no access rights for example). I recommend to execute the code within a Try Catch statement to capture the exception and return it to PRTG.

$condition = $true
$result = 5

try {
$testpath = (Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')

if ($testpath -eq $condition){ 
    Write-Output "0:A Reboot is required."
    Exit 0
} elseif ($testpath -ne $condition) 
{
    Write-Output "1:A Reboot is NOT required."
    Exit 0
}
} catch{
    Write-Output "-1:$($_.exception.message) At line : $($_.InvocationInfo.ScriptLineNumber)"
    Exit 1
}

To get further information regarding the issue, I invite you to enable the sensor debug logs by using the option Store result under the sensor Settings tab. Then, execute a manual scan and check the log files generated under "DataPath\logs\sensors" where DataPath is the path displayed in PRTG Administration Tool on the probe server.

Hi Florian,

The "-----" was just for formatting and clarity in my reply. It is not part of the code.

My script has 5 Write-Output's to illustrate the problem.

For example, if I remove outputs 2-5, PRTG will report message 1. If I add output 2, then message 1 is ignored and message 3 is reported. In the case of my conditional, if I comment out "1:just a test", PRTG reports the "100:Value" message.

Regardless of my code, the Catch statement code you are providing reports that the response is not well formed.

I'm a bit short on time this morning and out of the office for most of the day, but will try the debug option and post the results this evening or over the weekend.

Thanks, Wolfgang

I ran a quick test and made a very small modification to your code. Adding my modification, clears the "response not well-formed" Message in PRTG and displays the word "test."

try {
    $testpath = (Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')

    if ($testpath -eq $True){
        Write-Output "1:There is a Reboot Pending"
        Exit 0
    } else {
        Write-Output "0:Life is Good!  No Reboot Pending"
        Exit 0
    }
} catch{
    Write-Output "-1:$($_.exception.message) At line : $($_.InvocationInfo.ScriptLineNumber)"
    Exit 1
}

Write-Output "2:Test"

This is quite interesting as the logic of the code should not lead to the error message "response not well-formed" (could not reproduce the issue on our side).

The sensor debug logs should bring more information regarding the issue. Waiting for your feedback.

I am trying to send you a screen snip. I went to the log directory and checked, there are no sensor logs. Still getting the same errors.

Update: As of Saturday, January 15, after a lot of testing and troubleshooting, I have found a way to make this fail outside of PRTG. I'll update this thread with a status as soon as I find what is making things fail.

Hi Wolfgang,

Glad to hear that you could reproduce the issue.

Regarding the sensor debug files, you should be able to find them in the logs\sensors folder. Therefore, I invite you to execute a manual scan to force their creation and double check the path in PRTG Administration Tool. In case, the sensor is located on a remote probe, I invite you to have a look on that server on which they will be created.

Florian,

I was able to fix the issue outside of PRTG, however I can still reproduce the issue in PRTG. I have concluded that PRTG is not transferring the script (your version above, or mine) to the remote system and running it.

I created this script and have it as a Sensor on the local PRTG Server. That server runs only PRTG and no other applications:

$RegPathRebootPending = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

$RebootPending = (Test-Path $RegPathRebootPending)

If ($RebootPending) { 
    # $true
    Write-Host "2:There is a reboot Pending"
    Exit 2
}
Else {
    Write-Host "0:Life is good! No Reboots are Pending"
    Exit 0
}
}

The script always reports that the status is "good" regardless of the Registry key being present or not.

If I add "Write-Host "3:Hello World!", then PRTG reports "Hello World."

I have about 100 servers and this solution is very painful, but it works. write the script as such:

$RemoteComputerName = "RDPServer-00"

Invoke-Command -computername $RemoteComputerName -ScriptBlock {$RegPathRebootPending = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

$RebootPending = (Test-Path $RegPathRebootPending)

If ($RebootPending) { 
    # $true
    Write-Host "2:There is a reboot Pending"
    Exit 2
}
Else {
    Write-Host "0:Life is good! No Reboots are Pending"
    Exit 0
}
}

Then save it to a ps1 file. In this case, the script name is RDPServer-00. Add a custom exe sensor that points to that PS1 file under RDPServer-00 and set it to "use windows credentials of parent device" and it will run as expected and report accurately.

Some things that don't work:

1. Regardless of the Result Handling setting, Log files do not generate.
2. Moving "-computername localhost" or in this case "-computername RDPServer-00" to the Parameters in PRTG does not work. I tested it with " marks and ' marks.
3. Using localhost as the -computername parameter in the script does not work.
4. The CheckRegistry script from the PRTG website does not work.

A theory:

After running and working with all of the Demo Scripts provided by PRTG with the installation and then running every PowerShell script that I could find on the PRTG website, I believe there are 2 problems in PRTG.

1. The script is not actually being transferred to the server where the Sensor is configured. Therefore it is returning whatever it has in Memory as the result.
2. The Test-Path command returns only True or False. PRTG doesn't know how to handle the result and it simply ignores the conditional logic in the script.

Wolfgang

Hi Wolfgang,

Thank you for your feedback.

Regarding the execution of the script, it is indeed necessary to develop it to execute the command on the target devices otherwise it will be executed for the probe server on which it is located.

Note that the probe uses PowerShell directly to execute the script therefore it can't be at the origin of the issue with the conditional not taken into account. The latter simply returns the data it gets from PowerShell. As illustrated above, the script works as expected on our side. ("Write-Host "3:Hello World!" ignored as expected when adding it)

For the parameters, I invite you to use "IP/DNS" (with quotes and without the parameter name) directly in the Parameters field of the sensor and then get the value in the script as follow:

param(
[string] $RemoteComputerName= ""
)

You should then be able to pass the device address to the script from PRTG. You can also use the placeholder %host which will automatically get the device IP address.

Regarding the sensor log files, I invite you to make sure that the option Store result (not Store result in case of error) is selected in the sensor Settings tab and double check the path of the data folder visible in PRTG Administration Tool (> PRTG Core server for the local probe). After a scanning interval, you should get the sensor log files:

If that's not the case, I invite you to restart the local probe when possible (in PRTG Administration Tool > Service Start/Stop) to make sure that the logging system works properly.