how do i get the besclient version from this relevance. This “(version it) of client of it” seems doesn’t work.
<?xml version="1.0" encoding="UTF-8"?>
<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BESAPI.xsd">
<Query Resource="((names of it,operating system of it,(version it) of operating system of it,(version it) of client of it) of members of bes computer groups whose ( name of it = "TC - MQFT Servers"))">
<Result></Result>
<Error>The operator "client" is not defined.</Error>
</Query>
</BESAPI>
I’m afraid you’re trying to mix Session Relevance with Client Relevance, a common source of confusion. Because API queries use Session Relevance (querying the server database), you cannot directly retrieve things from the Client - you have to check the ‘property results’ that the client has previously reported.
To test Session Relevance queries, I like to use the hidden “QNA” page of Web Reports. It behaves similar to the Fixlet Debugger, but runs in Session Relevance context.
Connect to your Web Reports server, and change the end of the URL to /webreports?page=QNA
From there you can use the Introspectors, running a query like properties of type "bes computer"
to see what’s available.
In Session Relevance, there are a number of built-in properties of a ‘bes computer’; for other things like the Operating System version, the ‘bes computer’ does not provide that directly, you’d have to retrieve that from a BES Property Result.
You can filter the results to find, while you can’t communicate with the ‘client’, you can retrieve the ‘agent version of bes computer’ to get the BigFix client version.
Q: properties whose (it as string contains "version") of type "bes computer"
A: agent version of <bes computer>: string
For the Operating System version, you’d have to find (or create) a Property for that. You can search your list of BES Properties like the following. I use this template often, and if there is a BES Property that is ‘reserved’ then I prefer to use it, as it’s guaranteed to exist in every BigFix deployment:
q: (names of it, reserved flag of it, name of source analysis of it | "Global", name of site of source analysis of it | "Global") of bes properties whose (name of it as lowercase contains "version" and name of it as lowercase contains "os")
A: Sophos Anti-Virus Version, False, Sophos Anti-Virus / Endpoint Security Client Information - 9.x/10.x, Client Manager for Anti-Virus
A: Sophos Anti-Virus Version, False, Sophos Anti-Virus Client Information - 7.x/8.x for Mac, Client Manager for Anti-Virus
A: OS Version Number - Windows, False, Operating System Information (Windows), BES Inventory and License
A: Adobe Photoshop Version, False, ( (Deprecated) Adobe Product Detection (Windows) ), BES Inventory and License
A: Adobe Photoshop Elements Version, False, ( (Deprecated) Adobe Product Detection (Windows) ), BES Inventory and License
A: Kernel version / OS Release - Unix, False, Operating System Information (UNIX), BES Inventory and License
A: Installed Applications - Versions - Mac OS X, False, Application Information (Mac OS X), BES Inventory and License
A: CentOS Download Plug-in Version, False, Download Plug-in Versions, Patching Support
A: CentOS R2 Download Plug-in Version, False, Download Plug-in Versions, Patching Support
A: Release Version - Microsoft Windows Malicious Software Removal Tool, False, Windows Security: Microsoft Windows Malicious Software Removal Tool - Configuration Information, Patching Support
A: OSD Version, False, Bundle Creator Machine Information, OS Deployment and Bare Metal Imaging
A: OS Version, False, Bundle Creator Machine Information, OS Deployment and Bare Metal Imaging
A: OS Version, False, Hardware Attributes, BigFix ServiceNow Data Flow
I did not find a built-in OS Version property. I did find versions that are specific to Windows or to Linux or to other operating systems, which come from separate Analyses; it would be inconvenient to try to query the multiple properties, so I’d recommend creating a new Custom Property in your deployment to retrieve the OS version, and use that to retrieve results.
While we’re on the topic, how you structure the relevance query will have a huge impact on its performance. If it’s crafted in a way where very computer triggers a new BES Property lookup, that can be a huge performance hit, so I’ll refer here to the authority on efficiently retrieving BES Computer Property Results:
With that, we could try a query such as the following (you’ll still need to do the XML encoding on it)
(
name of item 0 of it|"missing Name"
, operating system of item 0 of it | "missing OS"
, (if (size of item 1 of it = 1) then ((if it = "" then "OS Version: No values" else it) of concatenation ";" of values of results (item 0 of it, elements of item 1 of it)) else (if (size of item 1 of it > 1) then (("OS Version duplicates: " & concatenation "|" of ((name of it) & "=" & (id of it as string)) of elements of item 1 of it) as string) else ("OS Version Property does not exist")))
, agent version of item 0 of it
) of (
elements of item 0 of it /*expand the computer set - gets you one line per computer*/
,item 1 of it
) of (
member set of bes computer group whose (name of it = "TC - MQFT Servers")
, set of bes properties whose (name of it as lowercase = ("OS Version") as lowercase) /*you need to create the custom "OS Version" property*/
)
Edit: fixed the query for ‘operating system of item 0 of it’
I have tried this “values of results of bes property “BES Client Version””. it worked but it doesn’t narrow the list of server to mentioned group. it dumps whole lot of servers.
“TC - MQFT Servers” has 600 server.
You’d have to post your version of the query for me to tell you why…if you query in the form above, the results should be limited to the computer group; because we aren’t just pulling ‘results of property’ (which would include all computers), in this form we pull ‘values of results (item 0 of it, elements of item 1 of it)’ – where item 0 is one specific computer, and item 1 is the set of (exactly one) BES Property from which to pull the result.
This form is more complex, sure, but it is efficient, and handles error-trapping for missing or unreported results, as well as duplicated property names.
relevance=’((names of it,operating system of it,(version it) of operating system of it,values of results (it, bes property “BES Client Version”)) of members of bes computer groups whose ( name of it = “’+MFT_GRP+’”))’
Nice find!
What’s happening there is that ‘operating system of it’ returns a string. When given a string, the version <string> inspector is really aggressive about trying to find something in that string that looks like a version. So although ‘version of operating system of bes computer’ does not exist as a property, casting the operating system to a string works…usually.
I did have problems in my environment where some operating system strings could not be cast to a version, but so far I’ve only found that to be the case for my Proxy Agents - OS Deployment or VMWare extensions.
q: version "Win10 10.0.18362.778 (1903)"
A: 10.0.18362.778
q: version "abcdefghijk10.5lmnop"
A: 10.5
q: (name of it, agent type of it, operating system of it) of bes computers whose ( not exists ((versions it) of operating systems of it ))
A: BES-Root, Proxy - ESXi CLI APIs, Microsoft Windows Server 2016 or later (64-bit)
A: Insights, Proxy - ESXi CLI APIs, Microsoft Windows Server 2012 (64-bit)
A: 192.168.1.44, Proxy - Bare Metal Extender,
A: rhel-bfi, Proxy - ESXi CLI APIs, Red Hat Enterprise Linux 8 (64-bit)
A: RHEL-Root, Proxy - ESXi CLI APIs, Red Hat Enterprise Linux 8 (64-bit)
that group is mix of wintel/unix. And some of aix hosts are old AIX5.3, besclient it has is older version which doesnt support running the query.
In my work flow I dump the list of server from that group to verify the target server is present in that group or not. But there are still old hog are hanging in our infrastructure, getting the besclient version is other way i can filter out that host which i dont’ have to target for API action.
