Strange Error in Fixlet Debugger while using "Query Channel using QnA"

This does not appear to happen on every instance of the Fixlet Debugger I try, but it happens often enough where I need to figure out if this is a bug or just me not understanding how Query Channel works from the Fixlet Debugger:

When using the Fixlet Debugger (9.5.13.130) and trying to query a remote BES Client (Also version 9.5.2.130) I get an error as I enter the computer name of the remote system I’m trying to query in the Fixlet Debugger:

In the box labeled “Enter a valid computer name or a valid computer ID to query” I type the computer name (the hostname essentially) as defined and seen in the BigFix Console.

When I do this on the Fixlet Debugger on a particular machine it behaves normally. It looks up the computer ID from my connection to the Root Server and at the bottom right of the Debugger I get “Computer ID : nnnnn” and “Query Channel using QnA”…no problem everything works

When I try the same process from a different Fixlet debugger installed on a different system (same OS [win2k16 - 1607]) I get the following error:

“Target Computer does not exist or you do not have administrative permissions on the target Computer: COMPUTERNAME”

Where “COMPUTERNAME” is the actual hostname of the computer I’m trying to query. (screenshot attached)

qnachannelperms

  • Verified the bes client versions and platform versions were the same (9.5.13.130).
  • Verified that the REST API credentials were configured
  • Verified that the Fixlet Debugger versions were the same (9.5.13.130)
  • Verified that the user with which I am logging on to the Fixlet Debugger QnA channel has rights to the computer object in the console.

Now, all this being said…if instead of the computer name (hostname) I enter the actual Computer ID of the remote computer I want to query, everything is fine. It accepts my entry and I can remote query the system with no issues.

Any ideas?

I don’t have insight into the code, so take this with “a grain of salt”, but I think I saw something similar when my connection from the fixlet debugger to the server timed out. I had to close and restart the debugger, otherwise it would not re-authenticate.

I suspect it is failing to reauthenticate when it runs the session relevance to map the target computername to a computer id, but is reauthenticating for the post to the clientquery resource. At least that’s one scenario I can understand for failing to send a query by client name but succeeding by client ID.

Thanks for the reply Jason. That makes sense in a way, though I’d like to figure out why it consistently succeeds on some computers and consistently fails on others…It seems to be random as to the computer on which it fails or succeeds, but it’s consistent in that if it fails on that system…it fails all the time.

Mike

Oh perhaps I misunderstood.

If an endpoint is consistently failing, it may not be receiving UDP messages from its relay. Could be a NAT or firewall issue.

No, that’s not it, but maybe it’s me that’s not explaining correctly:

I have several servers that all have the BigFix Console and the Fixlet Debugger installed. From some of these servers I can enter the computer name in the Fixlet Debugger ‘Evaluate Using QnA’ function and it works. The computer id is listed at the bottom right of the Fixlet Debugger and it evaluates remotely on them.

On some other (random from what I can tell) servers, this functionality comes back with the error in my OP above. What I meant by ‘consistently fails’ was that on the computer where this works…it ALWAYS works…and on the ones where it fails…it ALWAYS fails…there are no blips where it fails once in between other successful attempts…and there are none where it works once in between other failed attempts.

The reason I say it’s not UDP is because the computers can receive other messages from the server (i.e. ForceRefresh, they see actions initiated right away and they can still be queried using the QnA tool…you just have to plug in the computer id into the Fixlet Debugger).

Hope that clears things up.

I frequently get the same error when using a computer name, but if I then use the computer id of the same client all is well.

It is only a mild annoyance, mostly because I can remember the names of my test targets but my mental name to id lookup table does not live in long-term memory.

I’m guessing this probably isn’t the cause of the problem in the OP, but one thing that tripped me up the first couple times I used this was that the computer name is case sensitive and has to match exactly the name reported in BigFix.

2 Likes

I think you are right - a quick test using the correct case worked and deliberately using incorrect case produced the error.

Thanks.

1 Like

Can confirm from an experience this morning - it is case-sensitive.

Yes, I noticed the case sensitivity while troubleshooting, but in my case I was entering the correct case so that is not the source of my specific problem.

Hello, can you confirm those versions please. As I thought the Remote Query option was not available until v9.5.11. Did you mean Fixlet Debugger 9.5.13.130?

I have seen it not work with the COMPUTERNAME and I have had to use the COMPUTER ID.
Try this and let us know.

Yes, my goof. I meant to say 9.5.13.130. Fixing it on original post as well.

Yes, ‘computer id’ works fine, but it’s on random computers…sometimes COMPUTERNAME works and sometimes it doesn’t…As I mentioned before: What I have seen is that it’s consistent once it either works or doesn’t. But I can’t tell on what computer it’s going to work and on which one it’s not.