Inconsistent results from API call

1

Every week at the same time, we run an API call to get the serial number for every macOS device in our environment. The call is run under a local console operator account with permissions to see all devices in our environment (however, it is not a Master Operator).

We have a Windows/macOS analysis (30-day period) that runs to gather the serial number:

if mac of operating system and exists property "iokit registry" then (string "IOPlatformSerialNumber" of dictionary of service plane of iokit registry) else if exists property "hardware" then (if exists hardware then (serial of hardware|"N/A") else "N/A") else if exists property "smbios" then (if exists smbios then (values "serial_number" of structures "system_information" of smbios as string|"N/A") else "N/A") else "N/A"

Our API call filters this analysis by operating system:

(values of results (bes properties whose (id of it = (2299734257,566369,1)),bes computers whose (operating system of it as lowercase contains "mac")))

However, we are finding that some devices will appear one week, disappear the next, and then appear again.

These devices:

  1. Have a First Report Time of at least 6+ months
  2. Have a longstanding value returned by our analysis
  3. Have our local console operator listed in the device’s User Management Rights tab

Over four weeks, we have device that go FFTF, TTFT, FTFF, FTFT, TFTF, where F means it didn’t show up in the export, and T means it did.

So far, it doesn’t just appear to be the same devices. It could be any device that just doesn’t show up one week, and then appears again fine. Devices are in different sites, have different CPUs, etc. — I haven’t been able to find a common denominator.

Running the API call manually, there doesn’t appear to be any inconsistencies between calls run minutes apart.

Is there anything I can do to make these results more reliable? I will be submitting this as a support ticket as well.

2

That’s a bit difficult to speculate, without getting actual results and seeing where the computers might be dropping. Hopefully Support can help in this area.

I would suggest that the session relevance query you’re using can be made much more efficiently. Right now as a cross-product of a property and the plural ‘bes computers’, the property must be looked-up for each computer. That may not be a big deal, especially if you have a small number of Mac computers to begin with, but at least it’s something we can check also.

Referring to Efficient Session Relevance Query for Computer Properties which is pretty much the authority on how to most efficiently retrieve BES Computer Property results, I’d suggest we could refactor your query, as well as showing whether your computer disappears entirely, or whether your computer appears to have not reported the analysis results.

Now, the query you’re showing here only reports the property result values - it does not report which computer reported each result. We may need to see your actual query to debug it.

I’d start by trying out this query, which changes a couple of things -

  1. It’s a more efficient lookup of the property
  2. The values of results are concatenated - so, one row per computer, and, crucially, if a computer has not reported a value the computer remains in the results, just with an empty string for the result value
  3. The computer ID reporting the value remains in the query result

(concatenation ";" of values of results (item 0 of it, item 1 of it), id of item 1 of it) of (item 0 of it, elements of item 1 of it) of (bes properties whose (id of it = (2299734257,566369,1)), set of bes computers whose (operating system of it as lowercase contains "mac"))

3

Thanks @JasonWalker . Should the new query be more efficient than the one I posted earlier, even with including the computer ID? Over 10 runs for each, the original query had an average of 196ms, while the new query had an average for 349ms. We have about ~6k macOS devices, and ~12.5k Windows devices.

I will start running the new query alongside our old one to compare for differences — thank you for the troubleshooting headstart.

4

Ah, ok. I’d say that “along a large enough scale” I’d expect my form of the query to be a bit more efficient, but I don’t think those device counts are large enough to make much of a difference.

In any case, it may not be necessary to keep the computer ID in your final query, but here for troubleshooting it’s worth noting whether the machine has disappeared / is not managed by your API account (in which case the computer will have no row in the results), or whether the computer is still visible but not reporting a result for your analysis property (in which case it should appear in the results as a computer ID with no serial number).

5

This past weekend, the new query ran alongside my original one. There were four responses that came back with a computer ID, and no serial. However, these four computers have not checked in for a long time, and have no response for “Serial” in our analysis — I would not have expected them to be included.

There are still other devices that our API account should be able to see, but are not being returned by either query (the device shows the API account in “User Management Rights”, there is a value in our “Serial” analysis, and the device is online/checking in for months). And the odd part is that they were visible to the API account in previous weeks, on and off.

6

If it’s handful of computers, one thought is on occasion I have had to reset the BigFix client as the computer was not fully checking in. Typically I catch this when seeing a computer is not in a Group (typically a newer group) but it isn’t.

Stop besclient, delete besdata folder, restart client.

We’ve also just resorted to using Master Operator accounts a lot even when I would highly prefer to use read only or lower privileges’. Catching and solving all the inconsistent results and devices that are offline a lot (or other) just leads to bad reports and frustrated management. Granted some of that is also due to my work priorities, as I know I could solve it, but priorities are placed elsewhere.