Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

After Update to PRTG Version 21.2.67.1562 (Stable) get-probe does not give anything back #215

Closed
carsten0407 opened this issue Apr 27, 2021 · 28 comments
Closed

After Update to PRTG Version 21.2.67.1562 (Stable) get-probe does not give anything back #215

carsten0407 opened this issue Apr 27, 2021 · 28 comments
Labels
bug Issues that have been confirmed to be bugs in PrtgAPI and will be fixed in a future version

Comments

@carsten0407
Copy link

What's going on?

Hi Lord,

after we Update to PRTG Version 21.2.67.1562 (Stable)
the command --> get-probe does not give anything back

get-probe -name "NAME" ist functionally

Do you know anythibg about that?

Thanks

Carsten
@carsten0407 carsten0407 added the question Questions raised by people who don't know how to program or read the wiki :P label Apr 27, 2021
@lordmilko
Copy link
Owner

Hi @carsten0407,

When I run Get-Probe against PRTG 21.2.67.1562 I get an error; this appears to be caused by the new "PRTG Core Server" autonomous device object. This object is a device, however because it is under the root node PRTG is erroneously returning it from API requests for probes as well. I will open a case regarding this with Paessler support.

@lordmilko lordmilko added bug Issues that have been confirmed to be bugs in PrtgAPI and will be fixed in a future version and removed question Questions raised by people who don't know how to program or read the wiki :P labels May 2, 2021
@AlphaJosh
Copy link

Workaround:

$a = New-SearchFilter ProbeStatus NotEquals "" -Illegal
Get-Probe -Verbose -Filter $a

@lordmilko
Copy link
Owner

Hi @AlphaJosh,

I've been looking into this and have found that the true workaround that is required is to have a permanent filter on probes for Type equals Probe; in the meantime users can implement this manually by doing flt type eq probenode|get-probe or really any other filter which causes only Probe objects to be returned and not AutonomousDevice objects (as you have done)

As this has the potential to affect a large number of users I am currently working to release PrtgAPI 0.9.15 ASAP which will include a proper fix for this issue. I hope to release this within the next week or so

Regards,
lordmilko

@lordmilko
Copy link
Owner

Hi @carsten0407 / @AlphaJosh ,

Please be advised PrtgAPI 0.9.15 has now been released which includes a fix for this issue

To update PrtgAPI, please run Update-Module PrtgAPI and reopen PowerShell

Regards,
lordmilko

@carsten0407
Copy link
Author

Hi Lordmilko,

it works again, but I didn't expect anything else

Good work,

thanx ;-)

@carsten0407
Copy link
Author

carsten0407 commented May 10, 2021 via email

@lordmilko
Copy link
Owner

Hi @carsten0407,

Can youu please do

Set-PrtgClient -LogLevel All

Get-Probe <probeName> -Verbose

where <probeName> is your probe name

and post the output? (please remove any sensitive details like your PRTG URL, username and passhash from the output)

@carsten0407
Copy link
Author

carsten0407 commented May 11, 2021 via email •
edited by lordmilko
Loading

@lordmilko
Copy link
Owner

lordmilko commented May 11, 2021 •
edited
Loading

Hi @carsten0407,

I don't understand your response.

First you said

First one not functionally, installed after the PRTG-Update

But then you said

Second one is OK , installed before the PRTG-Update

However both of these XML responses show the same PRTG version: 21.2.67.1562

When you say "PRTG-Update" do you actually mean PrtgAPI Update? i.e. is the top one the response given by PrtgAPI 0.9.15 while the bottom one is the response given by PrtgAPI 0.9.14? In the first response I can see you are searching for "ProbeName1" but in the second response it is "ProbeName2". I'm not sure if this is just because you modified the output to hide some sensitive info, however if these API requests are for different probes it is impossible to compare these properly.

Also, please be careful when responding to GitHub issues - not only did you leak the URL of your PRTG web server, you also appear to have leaked the username and passhash that you use for your API requests, in addition to all of the information contained in your mail signature when you responded to the email. I have modified your response above to remove the sensitive info about your PRTG server

@carsten0407
Copy link
Author

carsten0407 commented May 11, 2021 via email •
edited by lordmilko
Loading

@lordmilko
Copy link
Owner

lordmilko commented May 11, 2021 •
edited
Loading

Hi @carsten0407,

I see what you're saying; I tried adding a new probe to my test server, and sure enough when I do Get-Probe - even without any additional arguments - the new probe server does not show up.

If I do Get-Object -Id <idOfTheNewProbe> it does show up, but if I then do Get-Object -Id <idOfTheNewProbe> -Type probenode the object isn't returned at all, despite the fact you can clearly see in the XML response the type is probenode

This seems like a bug in PRTG; I will speak with Paessler

@carsten0407
Copy link
Author

carsten0407 commented May 12, 2021 via email

@carsten0407
Copy link
Author

carsten0407 commented May 12, 2021 via email

@lordmilko
Copy link
Owner

Hi @carsten0407,

Possibly a slightly earlier PRTG update caused this behavior, however I have reached out to Paessler and they have confirmed they can reproduce this behavior as well; as such at this time this is a bug in PRTG so we will need to wait to hear back from Paessler

@carsten0407
Copy link
Author

carsten0407 commented May 12, 2021 via email

@lordmilko lordmilko mentioned this issue May 12, 2021
Closed
lordmilko added a commit that referenced this issue May 18, 2021
@lordmilko
Revert "Fix GetProbe not working in PRTG 21.2.67 (Fix #215)"
3fd83cb 
This reverts commit 2b50641.
lordmilko added a commit that referenced this issue May 18, 2021
@lordmilko
Fix new GetProbe behavior for resolving #215 failing to retrieve all …
7022aa1 
…probes in some circumstances due to PRTG failing to return all probes when filtering for objects of type "probenode" (Fix #219)
@lordmilko
Copy link
Owner

Hi @carsten0407,

I have pushed a new pre-release version of PrtgAPI 0.9.16 which includes a new fix for the original issue that doesn't also have side effects due to other bugs in PRTG.

Are you able to download the latest build via the manual installation instructions and advise whether you can now retrieve all probes properly?

Regards,
lordmilko

@lordmilko
Copy link
Owner

Hi @carsten0407,

Are you able to advise whether the new build resolves your issue? I would like to release PrtgAPI 0.9.16 including this fix however would like to confirm the fix does indeed work properly first

Regards,
lordmilko

@carsten0407
Copy link
Author

carsten0407 commented May 26, 2021 via email

@carsten0407
Copy link
Author

carsten0407 commented May 31, 2021 via email

@carsten0407
Copy link
Author

carsten0407 commented Jun 1, 2021 via email

@lordmilko
Copy link
Owner

PrtgAPI 0.9.16 is currently in pre-release

Please see the manual installation instructions for details on how to download and run it

@carsten0407
Copy link
Author

carsten0407 commented Jun 1, 2021 via email

@lordmilko
Copy link
Owner

Hi @carsten0407,

The version number is the same (since it isn't the proper 0.9.16 yet).

Are you able to provide the output of the following

Set-PrtgClient -LogLevel All

Get-Object -Type probenode

Get-Probe -Verbose

Get-Probe <probeName> -Verbose

Where is the name of the probe that isn't being returned

Please obscure any sensitive details such as your server name, username and passhash in the result

@carsten0407
Copy link
Author

carsten0407 commented Jun 1, 2021 via email •
edited by lordmilko
Loading

@lordmilko
Copy link
Owner

lordmilko commented Jun 1, 2021 •
edited
Loading

Hi @carsten0407,

It doesn't appear that you are using the new pre-release version of PrtgAPI

Get-Probe -name test –Verbose

VERBOSE: Get-Probe: Synchronously executing request https://??????????????????/api/table.xml?content=probenode&columns=objid,name,condition,fold,groupnum,devicenum,upsens,downsens,downacksens,partialdownsens,warnsens,pausedsens,unusualsens,undefinedsens,totalsens,schedule,basetype,baselink,notifiesx,intervalx,access,dependency,position,status,comments,priority,message,parentid,tags,type,active&count=*&filter_name=test&filter_type=probenode&username=???????PowershellUser&passhash=????????????

In this API request, you can see that it executes filter_type=probenode - however this is the old PrtgAPI 0.9.15 behavior. If you are using the PrtgAPI 0.9.16 pre-release this should say filter_parentid=0

To make sure you are using the new version of PrtgAPI, can you

  1. Download the latest build
  2. Right click the downloaded PrtgAPI.zip file and go to Properties
  3. On the General tab, under Security select Unblock
  4. Unzip the file to C:\temp\PrtgAPI
  5. Open a new PowerShell and type ipmo C:\temp\PrtgAPI
  6. Provide the output of
Get-Probe -name test –Verbose
(gmo prtgapi).path

@carsten0407
Copy link
Author

carsten0407 commented Jun 1, 2021 via email

@lordmilko
Copy link
Owner

Hi @carsten0407,

Sorry, I accidentally @'d @AlphaJosh instead of you. Are you please follow the instructions above?

@carsten0407
Copy link
Author

carsten0407 commented Jun 1, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Issues that have been confirmed to be bugs in PrtgAPI and will be fixed in a future version
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lordmilko @AlphaJosh @carsten0407