I currently have an issue with my notification script, when the sensor message has a single quote in it.
I'm running a PowerShell script to automatically create a ticket. The parameters for running the script: '%sensor' '%sensorid' '%status' '%message' '%device' '%since' '%lastup' '' '' '' '%prio'
All goes well, as long as the sensor message doesn't contain a quote. However, as soon as it contains a quote like "Error by lookup value 'Critical (2)' in channel 'Drum Unit' (Ready)" (a channel of the default SNMP printer settings sensor in PRTG), it breaks my script. The parameters following the '%message' parameter all get jumbled up.
It considers the single quote as a parameter. So: %message becomes "Error by lookup value" %device becomes "Critical" %since becomes "2" %lastup becomes "in channel" %prio becomes NULL (because of the 3 empty inputs, due to the structure of the PowerShell script)
I know I can kinda work around this by putting the '%message' parameter as last parameter, but that means I won't get the entire message in my ticket. So, no proper solution. This has either has to be a change in PRTG (not insert single quote in the sensor message), or a change in the way I pass the parameters to the script (but I have no idea how)...
Article Comments
Hi Stephan,
I tested with the double single quotes around %message , but with the single double quotes the script doesn't do anything at all anymore.
I kinda worked around the problem by setting the %message parameter as the last parameter (and changed the PowerShell script accordingly). At least it's creating tickets, but it only has part of the sensor message in the ticket.
So, it's a workaround, not a solution.
Any other tips to fix this problem?
Jul, 2017 - Permalink
Tested it already with double quotes around all parameters (replaced all single quotes in parameters field with double quotes). The result was the same as with double single quotes: the script didn't do anything at all anymore.
So unfortunately double quotes didn't help either...
Jul, 2017 - Permalink
A new (similar) issue arose:
When you have a sensor with a \ in the name, and you pass the name on to the PowerShell notification script (using the '%sensor' parameter), it's treating the \ as escape character (normal PowerShell behaviour).
Not sure how I can mitigate this issue, since I don't think using for example -replace ([RegEx]::Escape(%sensor)), "%sensorname" as parameter, or for example -replace (%sensor -replace '
','
'), %sensorname, will work.
Double quotes won't help either, as (once again) a \ is a valid PowerShell escape character.
Of course there's the work-around of going through all the sensors and replace the backslashes in the sensor names with forward slashes. But it's a work-around, not a solution...
Anyone have any ideas?
Jul, 2017 - Permalink
It's a backslash, not a forward slash. ;-)
I have quite a few sensors checking Scheduled Tasks, using the ScheduledTask2XML.exe (prtgtoolsfamily).
The sensor names include the group names the sensors are created in
(Scheduled Task: \<group_name>\<sensor_name>
Just did some more testing (manual input): PowerShell is able to handle a single backslash. It goes wrong when it uses the value to do an API call to our ticket system. A double backslash...
\\<group_name>\\<sensor_name>
can be handled by the ticket system.
I managed to solve this particular message by adding one line in the PowerShell:
$sensor = $sensor -replace "\\", "\\\\"
So, disregard the issue with backslash; that's solved in Powershell.
The issue with the single still remains! I can't fix that in PowerShell, since it's already breaking at calling PowerShell with parameters...
Jul, 2017 - Permalink
Let's see what the developer says about it ... I'll forward him the link to this thread, maybe he
has an idea of how to implement this properly. May take a while, depends on his workload.
Jul, 2017 - Permalink
Just to keep you in the loop, the developer is currently on vacation and had no time to take a look at it. This will probably take about 3-4 weeks until he responds. Sorry that this takes so long, he was on sick leave right before the vacation started - not much room for bug checking :(
Aug, 2017 - Permalink
Got word from development, we're not going to implement it (or change anything about it), since we can potentially break what users have currently configured. Maybe this is helpful, it will make PowerShell based notifications rather tedious to set up from what I can tell:
[StackoverFlow]Command Line escaping single quote for PowerShell
Sorry to be the bearer of bad news here :/
Kind regards,
Stephan Linke, Tech Support Team
Aug, 2017 - Permalink
Hi Stephan,
It's okay. I'll just keep the message parameter as last parameter. That way, if it does contain a single quote, the only effect would be that only part of the message will be in my ticket (but at least it won't break the 'create ticket' script).
I'll try to comprehend what they're doing on the webpage you gave me (StackoverFlow), but I'd need a quiet period to focus on that. And with the current workload that's going to be a bit harder said than done ;-)
As for the 'we can potentially break what users have currently configured' part: Just change the message of the sensors so they don't include singe quotes anymore. That shouldn't break anything, I'd say...?
Aug, 2017 - Permalink
Hi Corné,
Hehe, alright then. I guess the "removing single quotes" part is easier said than done as well since the way we're executing PowerShell code is already slightly convoluted, to put it charitably.
Testing this is a really tedious process as well and nobody wants to open pandora's box here :)
Kind regards,
Stephan Linke, Tech Support Team
Aug, 2017 - Permalink
"It's too hard" seems an unfortunate state of affairs with this.
My suggestion: create a new placeholder, say %escaped_message that provides a properly escaped powershell compatible message parameter.
I also have this problem. Many of the messages produced by PRTG now include single quotes, so single quoting the %message placeholder goes wrong in my notification and ticket scripts.
Jul, 2019 - Permalink
We're currently evaluating the switch to PowerShell Core (instead of using the PowerShell 5.1 that comes with Windows), which will hopefully alleviate the issues we're having with passing parameters, etc. :) This may take a while, though :)
Jul, 2019 - Permalink
Hi Corné,
Did you already try the following:
'%sensor' '%sensorid' '%status' ''%message'' '%device' '%since' '%lastup' '' '' '' '%prio
Note the double single quotes around the %message placeholder. Does that work?Kind regards,
Stephan Linke, Tech Support Team
Jul, 2017 - Permalink