Issue with Inconsistent Results from Client Query

We are currently executing a script on target endpoints that generates logs. To capture this data, we use the Client Query feature. However, we’ve noticed that the results are inconsistent—sometimes we receive the expected data, while other times the response comes back blank. Is this expected behavior, or could there be an issue with the Client Query process?

What is the relevance that you are using? Given your description, is it the case that the data is inconsistent for the same file for the same device? Is the file being written to while the Client queries the data?

In my experience, every time I am getting unexpected results, I look into logs and differences between a device and gives expected results and another that doesn’t.

Every single time it has been my fault and I need to improve my code. A few examples off the top of my head:
The full path may exist or may not exist, giving different results.
I need to escape a character.
x32 vs x64 inconsistencies
etc

i am using the below query

<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BESAPI.xsd">
    <ClientQuery>
        <ApplicabilityRelevance>true</ApplicabilityRelevance>
        <QueryText> if exists file ("C:\temp\serverlogfile.txt") then lines of file "C:\temp\serverlogfile.txt" else "The target file doesnot exists on the server"</QueryText>
        <Target>
            <ComputerName>serverName</ComputerName>
        </Target>
    </ClientQuery>
</BESAPI>

If the target file is not there atleast i should be getting “The target file doesnot exists on the server”. But sometimes the file is captured or sometimes not. This behaviour happens on servers randomly and is not happening with a particular servers.

Are you getting no response to the query, or are you getting a response from the computer that is an empty value? Just want to be clear as those are different cases.

No response from the query… Also if the response from the query is null, we are trying three times before we release our workflow.

Random question but is UDP working on all of the target endpoints?

1 Like

Not really random… :slight_smile:

2 Likes

i have seen this behaviour on the same endpoint couple of times where sometime the data is queried on the system and sometime it doesnot. This rules out the possibility of the UDP issue.

Can you talk us through the infra setup?

Are there Relays in the middle? Proxy servers? Firewalls?

It sounds like it might be a case for a support ticket where a wireshark trace can be captured though.

One point to note though, and you probably already know this so please forgive my “beginners guide to” style but by it’s design, UDP doesn’t always work. It can be hit or miss because of the way it sends packets and doesn’t actually wait for a response so it may even be as simple as the packets not hitting the endpoint periodically.

Yes, there are relays, and one part of the infrastructure is behind a firewall.

If the client query is using UDP, there’s always a chance it could miss due to the nature of how UDP transmits packets without waiting for a response. Is there an alternative method to capture the file other than using the archive?

That’s true to some extent, but in this case, it seems like the issue might be related to UDP blocking rather than packet loss or Clients are either behind proxy or firewall.

You might consider enabling persistent connections.