Filtering patches with REST API

How to put filtering inside the fixlet

Can you provide examples of what you mean by this?

Can you provide the text for any relevance you are using?

Links to similar posts or examples on BigFix.Me or elsewhere that you are referencing?

Can you provide screenshots of what you are trying?

You haven’t given enough detail to provide an answer. Provide as much detail as you possibly can, the more the better.

I have basically included this relevance tag inside my xml to filter those patches which have windows as in the name and exclude other patches such as office sql and others.

<Relevance>names of relevant fixlets whose (
   name of site of it = "Enterprise Security" and
   source severity of it = "Critical" and
   (current date - source release date of it) < 30*days
   and name of it as lowercase contain "Windows")</Relevance>

But unable to retain the patches inside the baseline.

The XML of what? Where? Can you provide a screenshot? Can you provide the full XML? (redacting servers, IPs, operator names, or other info)

So you are trying to filter a set of patches in order to build a baseline?

Bigfix version 9.5.13. I have a list of Microsoft Security Updates from Web Reports that I want to add to a baseline, but it is very tedious going one-by-one to add about 40 fixlets. These patches are just for Windows 10. If I could extract a list of patches from the console that are just for Windows, add to baseline I am not finding a way to filter by name which has windows

Thank you for the clarification. Can you provide more info about the Web Report that you are using to get the list? Is it a custom web report you have created, and if so, provide the HTML/XML/SessionRelevance of the report?

There are many different ways to go about filtering, selecting, and adding patches to a baseline, with varying degrees of flexibility and ease of use. I’ll list them in order I’d recommend considering them:

  1. Patch Domain Console Filters
  2. WebUI Patch Policies (automated options for patching without building baselines)
  3. Custom Console Filters
  4. Existing Console Dashboards ( I am not very familiar with these options )
  5. Custom Console Domain (Session Relevance)
  6. Custom BigFix REST API (Session Relevance)
  7. Custom Console Dashboard (Session Relevance)

Baseline baseline baseline

So you are using the REST API to do this? How are you doing it? can you provide more details?

Are you trying to add components to the baseline using the REST API?

Do you already know how to build baselines and add components through the console?

Yes i have used REST API

please answer all of my questions more completely.

https://bigfix.me/relevance/details/3019839
I am exactly trying to do this my conditions are bit different

I still am not clear what “this” is. You haven’t provided much context or examples or screenshots.

The example on BigFix.Me you linked to is client relevance, not session relevance, so it is not the “right” thing for automating this through the REST API, but it is possible to write equivalent session relevance and there should be some on BigFix.Me somewhere.

What are your conditions?

this answers a different question than the one I asked:

I could go into details of many different possible answers, but I am not even sure which one is what you are asking at this point. Just guessing, but I think this is closest to what you are looking for, but it is outdated and would need updates to work, plus isn’t ideal even if it worked as is: https://bigfix.me/fixlet/details/6132

I’m happy to go into much more detail on this, or any other possible solution, but I really need to know more to know what to go into detail about.

I’ll add that I would not recommend automating something with the REST API unless you have done it manually through the console a few times so that you have a target to hit with the automation, including being able to export the XML of an existing baseline that you can use as a guide or template with the REST API.

On top of that, you might not need to do any of this at all if WebUI Patch Policies fit your needs, which I would strongly recommend testing.

To do this, you need to build a session relevance query that returns the list of patches that you are looking for.

The best way to test and write session relevance is using the BigFix Console Presentation Debugger. Once you have the session relevance working, you can then use that session relevance with the REST API to do what you need.

Please go through this mini tutorial on using the Presentation Debugger: jgstew.github.io/_posts/2018-10-29-Open-BigFix-Console-Presentation-Debugger.md at master · jgstew/jgstew.github.io · GitHub

This session relevance will give you ALL applicable windows patches, which isn’t what you want, but it is the base starting point which you need to refine and filter down from: https://bigfix.me/relevance/details/2999178

Here is the same kind of session relevance, but showing how to filter it down based upon OS of the computers (might not be the most efficient method): https://bigfix.me/relevance/details/2999180

Also, the process you are trying to follow is a bit more specific in terms of filtering down the list of patches, but it is exactly the process done here, which while being a BigFix task that runs on a client, is actually REST API automation: https://bigfix.me/fixlet/details/6132

You have to download the file from BigFix.Me to actually get the contents of it, they don’t show up on the site completely.

After discussion in a private message, what you are looking for is exactly what this does: https://bigfix.me/fixlet/details/6132


you have to start small and work you way up to the result you want. You have to test as you go, getting more and more specific. You should also use number of to test.

Does this session relevance work?

number of elements of member sets of bes computer groups whose (name of it as lowercase contains "win")

One problem with your current method is that this is going to be wrong:

number of relevant fixlets of elements of member sets of bes computer groups

This is going to be slow, and return the set of relevant fixlets TIMES the number of computers, which is going to be huge.

This will make the set of relevant fixlets returned unique by collapsing them into a set, then expanding them back out, so this is one option:

number of elements of sets of relevant fixlets of elements of member sets of bes computer groups

Still slow, but at least you have it reduced a ton.

Even so, I think it is going to end up being MUCH faster to start with filtering down the fixlet set, THEN see if the computers in the computer group of interest are applicable:

number of fixlets whose( applicable computer count of it > 0 AND Category of it as lowercase contains "security" AND Source Severity of it as lowercase contains "critical" AND name of it as lowercase does not contain "superseded" AND name of it as lowercase does not contain "corrupt patch" AND name of it as lowercase does not contain "sql" AND name of it as lowercase does not contain "office" AND name of it as lowercase does not contain "sharepoint") of bes sites whose(name of it = "Enterprise Security")

This seems like 100x faster to get the potential set of fixlets to test against the computer group.

For my test system, I’ll get an example set of computers this way, which collapses an arbitrary number of computer groups into a unique set of computers:

number of elements of sets of members of bes computer groups whose(name of it as lowercase contains "win")

Then finally, putting it all together:

number of it whose( disjunction of relevants (it, elements of sets of members of bes computer groups whose(name of it as lowercase contains "win") ) ) of fixlets whose( applicable computer count of it > 0 AND Category of it as lowercase contains "security" AND Source Severity of it as lowercase contains "critical" AND name of it as lowercase does not contain "superseded" AND name of it as lowercase does not contain "corrupt patch" AND name of it as lowercase does not contain "sql" AND name of it as lowercase does not contain "office" AND name of it as lowercase does not contain "sharepoint") of bes sites whose(name of it = "Enterprise Security")

This is the set of fixlets that are relevant on at least 1 computer within the group membership defined by bes computer groups whose(name of it as lowercase contains "win")

Once that is working, then you can use session relevance to get the IDs and Names of the relevant fixlets/tasks:

(ids of it, names of it) of it whose( disjunction of relevants (it, elements of sets of members of bes computer groups whose(name of it as lowercase contains "win") ) ) of fixlets whose( applicable computer count of it > 0 AND Category of it as lowercase contains "security" AND Source Severity of it as lowercase contains "critical" AND name of it as lowercase does not contain "superseded" AND name of it as lowercase does not contain "corrupt patch" AND name of it as lowercase does not contain "sql" AND name of it as lowercase does not contain "office" AND name of it as lowercase does not contain "sharepoint") of bes sites whose(name of it = "Enterprise Security")

References:

1 Like

Hey. Thanks the query is working fine. Can you please tell how should i include this inside the <\RELEVANCE> as its not giving the output when i am using this query inside this tag.

please provide the XML of the BES file or the XML you are passing to the API, as well as what API endpoint you are using, etc…

you didn’t provide enough information to answer your question or debug the problem.

$xmlBody = @"

<?xml version="1.0" encoding="UTF-8"?>

<BES xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BES.xsd">

   <Baseline>

       <Title>$BaselineName</Title>

       <Description />

       <Relevance>

 (ids of it, names of it) of it whose( disjunction of relevants (it, elements of sets of members of bes computer groups whose(name of it as lowercase contains "win") ) ) of fixlets whose( applicable computer count of it > 0 AND Category of it as lowercase contains "security" AND Source Severity of it as lowercase contains "critical" AND name of it as lowercase does not contain "superseded" AND name of it as lowercase does not contain "corrupt patch" AND name of it as lowercase does not contain "sql" AND name of it as lowercase does not contain "office" AND name of it as lowercase does not contain "sharepoint") of bes sites whose(name of it = "Enterprise Security")
       
</Relevance>

       <SourceSeverity>critical</SourceSeverity>

       <SourceID> 12</SourceID>

       <BaselineComponentCollection>

          <BaselineComponentGroup>

             <BaselineComponent IncludeInRelevance="true" SourceSiteURL="http://server:52311/bin/bfgather.exe/CustomSite_sitename" SourceID="12" />

               </BaselineComponentGroup>

       </BaselineComponentCollection>

   </Baseline>

</BES>

"@

Start by exporting a simple baseline of one or two components. Read the XML so you have some idea of what you are trying to produce.

I think you are trying too hard to out it all together at once. That’s not good for learning the process.

You are mixing session relevance and client relevance. What you need to post in the XML needs to be client relevance, since it will be evaluated at the clients. You use the session relevance to determine which components to put in to the baseline. What you post in the Baseline XML should not contain any reference to ‘bes fixlets’, ‘bes sites’, or ‘bes anything else’.

When running your API query, start by retrieving one single fixlet. Get its ‘url of source site’, ‘id’, ‘relevance’, and ‘script of default Action’ of it. You’ll need those to create your baseline XML to post back.

1 Like

As @JasonWalker said, this is not where this Session Relevance goes, this is for client relevance. You have to use a different API endpoint to get Session Relevance results, and it has nothing to do with baselines, but if you use this particular session relevance, then it will return which fixlets you should put in the baseline. Once you have the result of which fixlets to put in the baseline, THEN you can build the baseline with those fixlets. That said, it might be easier to start with building a baseline with just 2 hard coded fixlets just to learn how to do that part, THEN worry about which components you actually want in the baseline after you figure out how to properly make a baseline with the REST API.

You really need to break this down into the smallest possible steps. Figure out how to get Session Relevance results with the REST API. Figure out how to create an example fixlet / task (that doesn’t actually have actionscript that would make changes) with the REST API. Figure out how to use SourcedFixletAction to take action on it and target endpoints using ComputerNames or ComputerIDs. Figure out how to create simple baseline, figure out how to use SourcedFixletAction to create an action from that baseline. Then figure out how to make the baseline with the components from the Session Relevance result. Then use SourcedFixletAction with that resulting baseline to create an action.

Also, the part that really saves you the most time is generating the baseline automatically with the right components. Once you do that, you can just create the action and target it by hand in the console. You can figure out how to automate that last part later on, but getting the baseline built is by far the biggest time saver.

Also, you should probably be comfortable with most of these steps by hand in the console first, because that can give you something to build towards. You can often export things created in the console, then use that as a template with the REST API to recreate the same. First recreate it exactly with the REST API, then use it as a template to create something slightly different with the REST API, and so on.

There are many examples of ways to use the BigFix REST API on the forums and elsewhere. It really seems like you need to play around with them and understand them better in general. It does seem like there could be some better minimal examples on the BigFix GitHub REST API Examples Repo. Something to work on adding to in the future.

Related:

I found my post that explains the original solution to automatic baseline creation: Automatic Baseline Creation and eventually AutoPatching