EXE Script sensor returns 0 in PRTG (but returns value in PowerShell)

Import-Module UpdateServices
$WSUSServer = Get-WsusServer -Name SERVERNAME.DOMAIN -PortNumber XXXX
$LastReportTime = Get-WsusComputer -UpdateServer $WSUSServer -ComputerTargetGroups "Server" -IncludeSubgroups | Sort-Object -Property LastReportedStatusTime | Where-Object {$_.LastReportedStatusTime -lt (Get-Date).adddays(-14)} | select fulldomainname, LastReportedStatusTime
$OverdueComputers = $LastReportTime.FullDomainname | Where-Object {$_.LastReportedStatusTime -lt (Get-Date).adddays(-14)}
$OverdueComputersCount = $OverdueComputers.Count

#Write result output
Write-Host "<prtg>"
Write-Host "<result>" 
"<channel>Overdue Servers</channel>"
"<value>"+ $OverdueComputersCount +"</value>" 
"</result>"
"<text>" + "" + $OverdueComputersCount + " servers are overdue to report in WSUS: " + $OverdueComputers + "</text>"
Write-Host "</prtg>"

Hello Martin,

Thank you for your message.

In the latest versions of PRTG, we have released new PowerShell security features which could affect the PowerShell script. To check if it's the case, I invite you to proceed with the steps below:

• Replace Write-Host with Write-Output

Import-Module UpdateServices
$WSUSServer = Get-WsusServer -Name SERVERNAME.DOMAIN -PortNumber XXXX
$LastReportTime = Get-WsusComputer -UpdateServer $WSUSServer -ComputerTargetGroups "Server" -IncludeSubgroups | Sort-Object -Property LastReportedStatusTime | Where-Object {$_.LastReportedStatusTime -lt (Get-Date).adddays(-14)} | select fulldomainname, LastReportedStatusTime
$OverdueComputers = $LastReportTime.FullDomainname | Where-Object {$_.LastReportedStatusTime -lt (Get-Date).adddays(-14)}
$OverdueComputersCount = $OverdueComputers.Count

#Write result output
Write-Output @"
<prtg>
<result>
<channel>Overdue Servers</channel>
<value>$($OverdueComputersCount)</value> 
</result>
<text>$($OverdueComputersCount) servers are overdue to report in WSUS: $($OverdueComputers)</text>
</prtg>
"@

• Disable new PowerShell security feature In case the first option didn't work, you can try to disable the feature under Setup > System Administration > Monitoring (/systemsetup.htm?tabid=2) > Experimental Features | PowerShell Security Enhancement.

Then, execute new scan of the existing sensor and/or create a new sensor with the corresponding script.

• Return execution error in sensor message If an error occurs during the execution of the script (not visible on the web interface), adding a Try catch could help to return it in the sensor message and check where it could come from. Here is a piece of code you can use for that:

try {
# your code
} catch {
    write-output @"
{
"prtg": {
	"error": 1,
	"text": "$($_.exception.message) At line : $($_.InvocationInfo.ScriptLineNumber)"
}
"@
}

If you have questions, let me know.

Regards.

Aug, 2021 - Permalink

Hi Florian,

Thanks for your reply on this issue.

Regarding your solution proposals:

- Modifying the script as suggested with "Write-Output" did not change anything, script still works when executed in ISE, but returns 0 when executed in PRTG.

- PowerShell Security Enhancement is already disabled in our configuration.

As for the "try/catch", I can't get this to work, by replacing the "# your code" bit with my code, but I'm properly doing it wrong. When I try this it returns with "Missing closing '}' in statement block or type definition"

Any addition troubleshooting advise I can try would be much apriciated.

Aug, 2021 - Permalink

Hi Martin,

Thank you for your feedback.

Missing braces

I indeed noticed the missing curly bracket "}" and added it in the previous post (missing at the end of the code). Please, add it and check if there is any error message displayed (in the sensor message field) when executing a manual scan.

Sensor debug logs

I also invite you to enable the sensor log files by selecting the option Store result in the Settings tab. For the next scans, PRTG will generate the debug files in the Logs\sensors folder (located by default under "C:\ProgramData\Paessler\PRTG Network Monitor\Logs\sensors"). Note that the path of the data folder can be different and therefore I invite you to open PRTG Administration Tool on the corresponding server to check if it's the case.

Then, open the log file (ending with .txt only) which has the ID of the sensor. Which data do you get there ?

Regards.

Sep, 2021 - Permalink

Hi again Florian,

Thanks for the updated script, the "try/catch" script now works, and returns this:

Response not well-formed: "({ "prtg": { "error": 1 "text": "Access to the path 'Update Services' is denied. At line : 3" } )" (code: PE132)

This indicates access denied to some path, which is likely the "C:\Program Files\Update Services" folder on the WSUS server, however if access right privileges on this is the cause, why does the script return valid values when executed from a non-administrative Powershell instance from the PRTG server?, it is only from within PRTG this seems to fail and return 0 values.

So while I can't rule out any corrupt folder/file access privileges on the WSUS server, I doubt this is the root cause, as the user PRTG is set to use actually has administrative access to the server.

Sep, 2021 - Permalink

Hi Martin,

I apologize for the delay.

Can you please share the script without confidential information to have a look at it. Do you execute a command remotely by using Invoke-Command by any chance ? If that's the case, can you check if providing the credentials explicitly works, by following the steps below:

• Pass the credentials of the device to the script by adding the following in the Parameters field of the sensor Settings tab:

"%windowsuser" "%windowspassword"

• Get the credentials in the script by adding params there

param(
    [string] $windowsuser,
    [string] $windowspassword
)

• Create PS credential object with the username and password (https://adamtheautomator.com/powershell-get-credential/)
• Pass the credential object to Invoke-Command (or other cmdlet executing remote commands)

The script should then use the credentials defined in the parent device settings and should not encounter issue if the account has administrator rights.

Sep, 2021 - Permalink