This goes more to general “how to debug relevance”.
Start by putting it in the Fixlet Debugger. When I do that, the last closing parenthesis is highlighted in red - indicating a parenthesis imbalance. This particular query is Session Relevance, so it can not evaluate in the Fixlet Debugger, but at least you can get the syntax errors worked out.
So first fix the imbalance. It’s likely that you need an additional open parenthesis right after the last “bes actions whose (”
Next, try to break down the query into its simplest form. Before you try to retrieve all of the properties of the bes action results, be sure you are actually getting a set of bes action results. Just retrieve their count. Breaking up your two different result sets, I’d start with the following queries and make sure they get some results:
q: number of results of bes actions whose ((start date of it >=("3 feb 2017") as date) and (end date of it <=("1 dec 2016") as date))
q: number of elements of (set of targeted computers of it - set of computers of results of it) of bes actions whose (start date of it >=("3 feb 2017") as date) and (end date of it <=("1 dec 2016") as date)
Once these two queries are returning the counts that you want, you can start retrieving the properties.
You might also be able to collapse the two queries into one using the result <( bes computer, bes fixlet )>
inspector listed at https://support.bigfix.com/inspectors/Session%20Objects_Any.html, combined with the pipe operator “|” to handle error conditions where the computer has not reported a result. Only try this once you are getting results for the action query. I don’t have access to a console to check this right now, but it might look something like this -
q: (IDs of item 1 of it, names of issuers of item 1 of it, names of item 1 of it, states of item 1 of it, time issued of item 1 of it, name of item 0 of it, operating systems of items 0 of it, ip addresses of items 0 of it, last report times of items 0 of it, (detailed status of result (item 0 of it, item 1 of it) | "Not Reported"), (status of result (item 0 of it, item 1 of it) | "Not Reported"), names of member actions of item 1 of it) of (targeted computers of it, it) of bes actions whose (start date of it >=("3 feb 2017") as date) and (end date of it <=("1 dec 2016") as date)
I suspect this may break where you don’t have a ‘targeted computers of bes action’, for instance where you’ve targetted by a dynamic property. If that gives a problem, you might further try
q: (IDs of item 1 of it, names of issuers of item 1 of it, names of item 1 of it, states of item 1 of it, time issued of item 1 of it, name of item 0 of it, operating systems of items 0 of it, ip addresses of items 0 of it, last report times of items 0 of it, (detailed status of result (item 0 of it, item 1 of it) | "Not Reported"), (status of result (item 0 of it, item 1 of it) | "Not Reported"), names of member actions of item 1 of it) of ((if (exists targeted computers of it) then (targeted computers of it) else (reported computers of it)), it) of bes actions whose (start date of it >=("3 feb 2017") as date) and (end date of it <=("1 dec 2016") as date)
This one uses “targeted computers of it” if this property exists, otherwise it switches to “reported computers of it”. You won’t know about dynamically-targetted computers that haven’t reported yet, but for manually-targetted computers you should either get results or a “not reported” entry.