Team:
I have an issue where I am trying to build a report of Windows devices that have deviated from what their correct build numbers should be. A correct build number is what Microsoft deems a build number should be should an endpoint be patch compliant.
I created global properties that track the latest 4 editions of build numbers for Server 2016, 19, 22 and 25. I am trying to build an analysis that will determine if a server is compliant based on it’s build number, or, if that server’s build number is something less than what Microsoft suggests the build number to be.
I am trying to build a relevance statement that compares an endpoint’s OS build number with that of the global property that I created, but I’m getting an error:
if (name of operating system contains “Win2019” and version of operating system = value of property “Microsoft Windows Server 2019 Build Number (-0)”) then “Compliant” else “Non Compliant”
The error I get is…
"type error; the property ‘value of ’ is not defined
What am I doing wrong here?
Any help here would be greatly appreciated!
Thank you!
Tony
That looks like client relevance, so I’m guessing that you’re trying to define an analysis property?
Client relevance doesn’t have access to property results, so analysis properties can’t really reference each other. If you want to include the value of one property in another property, and that’s the only place the value can be found, then you’ve basically got to replicate the first property’s relevance within the second property. So try replacing value of property "Microsoft Windows Server 2019 Build Number (-0)" with the relevance of the property Microsoft Windows Server 2019 Build Number (-0) and your relevance should work.
Thank you hp3! You’re correct; I’m trying to build a property within an analysis. The property will be called “Patch Compliance State,” and will be built on two things. First, it will retrieve the current “version of operating system” of the client. Secondly, the property should then read the current value of a property called, " Microsoft Windows Server 2019 Build Number (-0)" which will be updated monthly to reflect the latest OS build number that Microsoft publishes. I wanted to use the global property (which is nothing more than a hardcoded value for the OS build number), rather than embed the actual hardcoded value to avoid having to update this analysis every month. I’d rather do quick update of the values of the global property.
Correct, that approach isn’t going to work because no client has access to query the BigFix server/database to retrieve the values that any other computer reported for their property. Anything like that could open some security considerations, like a local computer admin exploiting their client to retrieve data from your deployment.
What you could do, instead of updating an Analysis with acceptable build numbers, is update a text file and attach it to a custom site as a Site File with the “send to clients” option.
Then in the client relevance, you’d compare your build number to the site file (which will be distributed to the client)
I can’t help wondering if an approach I’ve used to capture missing updates could be of use here. A property can inspect fixlet headers so possible if you look for relevant fixlets for MSYY-MMM that are not superseded and contains “Cumulative Update”, it would allow 1 property to be self maintains as new content become available and you don’t need to maintain something for each version of Windows Server. A “True” result would indicate the system is compliant as there are no relevant fixlets for the underlying OS
Q: not exists relevant fixlets whose ((it starts with "ms" AND it does not contain "(superseded)" AND it contains "cumulative update") of (value of header "Subject" of it as string as lowercase)) of sites "bessecurity"
A: True
T: 0.030 ms
This is an approach I’ve used to cover multiple OS (Windows as well as various Linux distros) and parsing the KBs/ patch IDs for patches that are older than is permitted as a grace period and all by a single property that updates as an when new content becomes available.
An example from a lab server of mine missing the March 2025 CU but should also work on any other Windows Sever build (or workstation builds)
Q: operating system
A: Win2022 10.0.20348.3091 (21H2)
T: 0.014 ms
Q: not exists relevant fixlets whose ((it starts with "ms" AND it does not contain "(superseded)" AND it contains "cumulative update") of (value of header "Subject" of it as string as lowercase)) of sites "bessecurity"
A: False
T: 0.037 ms
Q: values of (headers whose (name of it starts with "X-Fixlet-Source-ID" ) of relevant fixlets whose ((it starts with "ms" AND it does not contain "(superseded)" AND it contains "cumulative update") of (value of header "Subject" of it as string as lowercase)) of sites "bessecurity")
A: KB5053603
T: 0.049 ms
Q: values of headers "Subject" of relevant fixlets whose ((it starts with "ms" AND it does not contain "(superseded)" AND it contains "cumulative update") of (value of header "Subject" of it as string as lowercase)) of sites "bessecurity"
A: MS25-MAR: Cumulative Update for Microsoft server operating system version 21H2 - Windows Server 2022 - KB5053603 (x64)
T: 0.036 ms
Jason, thank you, I appreciate your help! I think what I’d prefer is to keep this encapsulated in an analysis. If a property from an analysis can retrieve the version of operating system of a client, I think I’ll have to hard code the current “acceptable” Microsoft values into the relevance statement.
The file idea is a great idea, assuming the endpoints can talk to their relays. Many of the devices I’m targeting actually have a variety of issues, such as non-reporting agents, bad relays, corrupt OS, etc. For this reason, sending a file to them wouldn’t necessarily work. I’d have to rely on a simple report that compares the last known build number of an endpoint to the latest build number by Microsoft and flag deviations that way.
In theory, I could also just report on the last report date, but that too won’t always work, as we have some systems that have been repeatedly patched but, behind the scenes, the endpoints are rolling the patch back. In one case, it’s been doing this for over 12 months. Hence again, I’d have rely on the build number to tell me about this deviation, as well.
Any other ideas you may have, please keep them coming! I really appreciate the help!