Filtering by -Id doesn't work anymore with PRTG Version 20.1.57.1745

[HanseGarant]

Describe the bug Clearly and concisely describe what you were trying to do, what happened and what you were expecting to happen

Hi!

Since the last Update of PRTG to Version 20.1.57.1745, we could not perform any actions with PrtgAPI anymore. We can connect to the server, but can't receive any sensor information. Additionaly we can't set any tags to the sensors.

Steps to reproduce Put the relevant code from your application that caused the issue to happen in the code block below

With Get-Sensor we get only empty response.

# Code goes here!
Get-Sensor -Id xxxx

What is the output of Get-PrtgClient -Diagnostic?

# Output goes here!
blank!

Additional context Anything else I should know to help solve the issue?

We already updated the Powershell PrtgAPI to the latest Version 0.9.12

[lordmilko]

Hi @HanseGarant,

PrtgAPI still works with 20.1.57.1745 on my system. It definitely doesn't make sense that Get-PrtgClient -Diagnostic would return nothing

Are you able to advise what the output of the following is? (note that the first two of these commands will show your server/username and passhash, which you should remove when posting your response)

Get-PrtgClient

As well as

Set-PrtgClient -LogLevel All
Get-Device -Verbose

and how about

Get-Process

In the first command, if you've connected to a server with Connect-PrtgServer it should return the PrtgClient object of your session

In the second command, it should show the full API request that was executed as well as the XML response that was returned

Finally, does this only affect PrtgAPI on one system or multiple? And approximately what version were you running prior to 20.1.57.1745?

[HanseGarant]

Hi @lordmilko ,

you're right, I made a mistake with the command. Here is the response.

PS C:\Users\administrator.KJ-DOM> get-prtgclient -Diagnostic

PSVersion      : 5.1.14409.1005
PSEdition      : Desktop
OS             : Microsoft Windows Server 2012 R2 Standard
PrtgAPIVersion : 0.9.12
Culture        : de-DE
CLRVersion     : .NET Framework 4.8 (528049)
PrtgVersion    : 20.1.57.1745
PrtgLanguage   : german.lng

PS C:\Users\administrator.KJ-DOM> Get-PrtgClient

Server     : HG-COM.k-j.grp
UserName   : prtgadmin
PassHash   : *********
Version    : 20.1.57.1745
RetryCount : 1
RetryDelay : 3
LogLevel   : All

Get-Device -Verbose is working. I'm getting many devices from our PRTG-Server.

PS C:\Users\administrator.KJ-DOM> Get-Process

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
  14126     205   228356     195080   1.817,94   1392   0 AtlasService
    111      10     2560       5592       0,02   4604   0 CNTAoSMgr
     49       5      664       2952       0,00   2680   0 conhost
     49       5      652       2936       0,02   4624   0 conhost
     49       5      644       2932       0,00   4684   0 conhost
     62       7     1924       8064       4,58   5620   2 conhost
     50       5      780       3220       0,03   9684   0 conhost
     49       5      760       3260       0,00  10588   0 conhost
    625      18     2120       4420      70,97    528   0 csrss
     94       8     1180       3548       0,00    592   1 csrss
    217      13     1804      26252       1,59   2252   2 csrss
    117       8     3024       5728       0,02   9284   0 cygrunsrv
    184      14    15044      25548       0,05    912   1 dwm
    202      23    25296      67788       4,33   7404   2 dwm
   1670     102    62668     134068      64,33   8020   2 explorer
    268      20    19012      17508       0,13   9816   0 FritzOnlineMeterXML
      0       0        0          4                 0   0 Idle
    160      15    10780      18036       0,14   1480   0 inetinfo
    386      33    18068      25556       0,36   5232   0 IVFax2Mail
    336      28    14568      20864       0,16   5164   0 IVFax2Print
    405      34    20328      25868       0,31   5712   0 IVFaxOnDemand
    392      34    19204      25856       0,36   5348   0 IVMail2Fax
  11914      32    18968      25948      27,59   2896   0 IVMail2Sms
    484      40    31972      36416       1,41   5436   0 IVPhoneAccess
    346      29    14784      21192       0,16    436   0 IVSmtpReceiver
    349      28    15728      21184       0,17   2016   0 IVSmtpSender
    400      34    19304      25512       0,34   4772   0 IVVoiceMailPlayer
    336      23    12896      25632       0,19    896   1 LogonUI
    239      13     9136       8356     879,58   2672   0 LogServer
   2498      30    16300      24996     589,73    700   0 lsass
    390      36    50876      34784      94,72   4628   0 lsMailServer
    303      33     5232      10036       0,06   1512   0 mqsvc
    164      12     2236       6964       0,03   2932   0 msdtc
    101       9     1512      12520       0,41  10484   2 notepad
    863      60    76672       9328   1.940,70   1916   0 NTRTScan
    385      26    10884       4868      62,81   8560   2 PccNTMon
    754      43   128040     141820       4,67   7396   2 powershell
   1319      99   102036     116060  30.033,52   1892   0 PRTG Probe
   1527     171   873072     909744  13.740,47   2912   0 PRTG Server
    238      12     2120       8340       0,66   4248   2 rdpclip
    116       9     3492       5112       0,00  11044   0 rsync
    248      12    10476       3644       2,36   1084   0 rundll32
    389      12     6532      10836     113,02    692   0 services
     55       3      288       1064       0,13    416   0 smss
    166      14     2788       7420      36,02   2384   0 snmp
    540      25     7312      15568       3,05   1276   0 spoolsv
     93      10     1304       4280       0,00   2428   0 sqlbrowser
    405      46    63412      19172   7.158,05   1708   0 sqlservr
    469      50   257984     201396      82,69   1776   0 sqlservr
    104       9     1444       6180       0,02   2500   0 sqlwriter
    546      29     6596      13132      93,16    288   0 svchost
    725      39    23248      34712      85,92    588   0 svchost
    427      14     4308      11016       6,38    768   0 svchost
    489      25     8132      12036     189,52    800   0 svchost
    513      19    16480      19712     891,11    956   0 svchost
   1656      52    50924      68040   1.930,92    992   0 svchost
    427      34    12124      16000       8,02   1100   0 svchost
    116      11     3348       8040       0,06   1304   0 svchost
    206      13     3352      10400       0,08   1460   0 svchost
    489      29    11164      16940      17,59   1896   0 svchost
    158      14     4592       8984       0,08   2780   0 svchost
    827      32    72916      82604      17,38   3864   0 svchost
    272      18     3052       9028       9,16   3920   0 svchost
    107       8     1452       4756       0,05   3976   0 svchost
     87       6      904       4084       0,02   8264   0 svchost
   2908       0      116       1092   4.253,75      4   0 System
    211      17     3380       9492       0,20   6588   2 taskhostex
    785      62    32696      10924     188,59   2540   0 TmListen
    239      12     7388      12400       0,17   4672   0 tmssclient
    124       9     1460       6296       0,00   3344   0 VSSVC
     84       8      840       4024       0,06    600   0 wininit
    121       7     1400       5568       0,13    628   1 winlogon
    145       7     1236       5400       0,22   8000   2 winlogon
    129      14     2596       6160       0,14   2824   0 xcapisvc
    338      23     7324      21032       3,09   8008   2 xdiag

That is my example, what we're using and what doesn't work anymore:

PS C:\Users\administrator.KJ-DOM> Get-Sensor -Id 4347
PS C:\Users\administrator.KJ-DOM>

As you can see, the response is blank. Attached you can find a screenshot of this sensor.

[lordmilko]

You're right! Filtering by -Id isn't working. I tried executing some manual calls against filter_objid or filter_id which didn't work. Furthermore, on the API test page on /api.htm?tabid=3 filtering by ID doesn't work there either. This seems like a bug in PRTG; I will file a report with Paessler

[lordmilko]

Hi @HanseGarant,

PRTG confirmed this is a bug. No ETA on when it will be resolved. Potentially could be worth downgrading to the previously installed version ("C:\Program Files (x86)\PRTG Network Monitor\PRTG Installer Archive\PRTG Installer (Previously Installed Version).exe") until a patch is released, although I see that 20.1.57 fixes some sort of security issue

[HanseGarant]

hi @lordmilko,

thanks for your fast support. Hoppefully they will fix it soon. Are you closing this thread or do you reply if it is fixed?

[lordmilko]

Right now its undetermined whether this will require a change to PrtgAPI or not, so I will leave this issue open for now

[lordmilko]

Hi @HanseGarant,

Paessler just provided a workaround for now. The issue is that PRTG now requires the object ID to be formatted as a 10 digit number (with leading zeroes). To force PrtgAPI to do this, instead of typing

get-sensor -id 1001

type

flt id eq "0000001001"|get-sensor

Note however that this behavior is not backwards compatible; as such, when they restore the old behavior your scripts will break again

[mhengl]

Hi @HanseGarant, @lordmilko, we'll provide a hotfix version as soon as possible. We're very sorry for the problems caused by this breaking change, it was an unintended side-effect.

[lordmilko]

Hi @mhengl,

I think it's worth noting that when it comes to the filter_ API, different properties have different formatting rules. There are a number of properties that PrtgAPI executes a ZeroPaddingConverter on when formatting the request. PrtgAPI understands these rules which are backwards compatible with a large range of PRTG versions. If you attempt to filter by a 10 digit object ID in prior versions of PRTG, it does not work. The implication of this is that if the fix for the Id property is to eliminate the rules regarding leading zeros all together, all of these other properties would break.

From my perspective, this doesn't really make sense. I would expect PRTG should simply convert whatever the specified value was to an integer (or maybe a long), wherein all leading zeroes would simply be ignored. This would protect against this sort of issue happening again, as well as ensure backwards compatibility with the formatting that is required by prior PRTG versions.

Regards, lordmilko

[Z3nto]

Hi @all, I got an answer for that from Paessler. They are trying to release a patch by the end of the week. Regards, Z3nto

[mhengl]

@lordmilko @HanseGarant Release is available. https://www.paessler.com/prtg/history/stable#20.1.57.1786

I've added you recommendations to the the discussion points for the new API version. Thanks for the Input and sorry again for the problems caused.

[lordmilko]

Thanks @mhengl,

I have confirmed that the filter_objid API call is working again now and that no other properties have been broken in this update

Thanks for your timely response!

Regards, lordmilko