Relevance: How to return the number of Non-Relevant Fixlets for a Computer

I’m trying to simplify a report query that is designed to fetch and compare the number of relevant and the number non-relevant fixlets on individual computers. The current query was designed to search every fixlet on every machine, check if the fixlet is relevant or not, and then the totals were summed up for each individual machine in javascript. This query is way too inefficient and is very slow since it’s loading a large number of results.

I want to change this query so that relevance is returning the fixlet counts. I found the relevance for finding the relevant fixlets of a computer on the Session Objects Reference (relevant fixlets of <bes computer>), but I can’t figure out how to directly fetch the number of Non-Relevant Fixlets. Is it possible?

I’ve not really tested this, but I believe you should be able to use the results from <bes fixlet> of <bes computer> inspector with something like the following:

(it, multiplicity of it) of unique values of ((relevant flag of it) of results from (bes fixlets whose (fixlet flag of it)) of bes computers whose (name of it as lowercase = "computer1" as lowercase) as string)

Ideally you would further limit the scope of this by filtering the Fixlets by for instance the sites of interest, or by severity/category, etc…but even then the number of results that have to be processed can be quite high.

Out of curiosity, what is the use case to count the non-relevant Fixlets?

Thanks alot, your advice really helped. Here’s the relevance code that I’ve made with what you’ve told me so far.

It works, but it’s not as efficient as I’d like it to be as it current takes 2 minutes to run across a network of 150 machines.

Could you provide me any tips to make it more efficient?

It’s fetching Computer name, total number of fixlets for the computer that were at any time considered relevant, current number of non-relevant fixlets for the computer, and current number of relevant fixlets for the computer.

(
	names of (item 0 of it), 
	item 1 of it, 
	multiplicity of (item 2 of it), 
	multiplicity of (item 3 of it)
) 
of 
(
	it, 
	number of (results from (bes fixlets) of it) whose (exists first became relevants of it) as string,
	unique values of 
	(
		(
			((relevant flags of it) whose (it = FALSE)) as string
		) 
		of 
		(results from (bes fixlets) of it) whose (exists first became relevants of it)
	),
	unique values of 
	(
		(
			((relevant flags of it) whose (it = TRUE)) as string
		) 
		of 
		(results from (bes fixlets) of it) whose (exists first became relevants of it)
	)
) of bes computers
  • Why do you want this number? Also, defining the scope of this number is rather complicated. Does it include all fixlets that were once relevant, but are no longer relevant? or does it include all fixlets?

  • Should I could all linux patches for windows machines, or vis versa?

  • Do you mean all non-relevant patches?

My windows 10 machine is not relevant to windows 2003 patches, but it never could be, so should those windows 2003 patches be included in the number of non-relevant patches for windows 10?

I would recommend looking at this: https://developer.bigfix.com/relevance/reference/bes-fixlet-result.html#last-became-nonrelevant-of-bes-fixlet-result-time

I think this data might only be available in web reports, but not the console session relevance.

Yes, I’m talking about non-relevant patches. The client wants to be able to see the status of the patch updates to their machines as a percentage.

We have discussed many different ways to try to provide a number like this, but there are many issues. If you include all windows patches in the count, then a completely unpatched machine will probably be like 80% patched because most of the patches will never be relevant on a single machine.

The number will be more sensible if you compare number of relevant patches VS patches that were once relevant but are no longer relevant. That is a more realistic number, but even that has issues… One of which is if if the computer is offline, then it will not report that it is actually relevant to new patches, until it comes online, so it’s number will look better than it actually is, so the “last report time” is a factor in the quality of the number.


I think I would actually recommend a qualitative, but kind of arbitrary number that is 100 minus the total of (the number of relevant critical & relevant important patches & number of days since last report) … so it is a score, not a percentage.

CC: @steve