I’m looking to create a custom-site that we will use as a way to catch up servers and PC on baseline patching to cut down evaluation times of clients. We have some pretty big baselines and I don’t want them evaluated all the time unnecessarily. The problem I’m running into is that computers that don’t need the baseline should not be subscribed to the new site since there is nothing in it relevant to them. I want to open an action that will evaluate the applicability of a computer to a certain baseline and if nothing in the baselines for that site are relevant for that client to un-subscribe from that site by applying a breadcrub client setting of sorts. This is a REALLY rough outline of what the action will do:
if {nothing from "Windows_Patches_2011" of "CATCH-UP_PATCH_SITE" is relevant}
setting "2011"="1" on {now} for client
endif
The site will only subscribe clients that don’t have this breadcrumb or others from other baselines within the site. Any ideas?
Maybe I’m missing something, but it seems you have the cart before the horse.
How you you know if an endpoint is relevant to a component in baseline before you can access the site and evaluate the baseline?
Well I’m just throwing out the idea. The logistics can be worked out as far as site subscription is concerned but my main focus is how I tell the site that if no baselines are relevant, run a task to change a value on and endpoint that will cause it to unsubscribe.
I think I have a solution that would work for you. I ran into the issue myself and setup a site with Baselines that only evaluate every X days. I have the custom site that the baselines reside in, a custom group with relevance that says join if your date/time stamp is older than X days, an action to tag machines that don’t have a scan date and force them in the group (if I evaluate every 5 days i make their date 15 days old), and an action to update their scan date when the Baselines complete so it kicks them out of the automatic group until the next time.
The Baselines themselves have a fixlet at the end that drops a custom setting in the registry to state that that particular Baseline has been ran. All these actions are targeted dynamically at the group so that way the client jumps in the group, subscribes to the site, runs the content, updates it’s scan date, and falls out of the group every X days.
I have taken machines with a CVSS score of 1310 (about 6 month old image) to a score of 19 with no operator intervention required so I can vouch for it working.
There are two inspectors you could use to essentially see if something has completed in the site and make an action that would mark something like you said that could be used in subscription relevance to unsusbscribe:
evaluated of <site>
and
number of relevant fixlets of <site>
So with those you could make sure that the site had been evaluated and that there wasn’t anything relevant. But of course this depends on the content being very static.
Thanks @AlanM and @jjusmc. I am working with both of your suggestions now and they look to be where I want this site to go but I do have another concern. I have 4 baselines in this site that are pretty sizeable and I’m uneasy about leaving the actions open-ended because one baseline alone has over 500 fixlets in it. Obviously if we run other tasks with these being offered it can tend to make a big mess of things as our environment has already experienced.
What would be a good method for having these baseline actions open without potentially impacting future patching cycles?
In regards to my setup, if you set it up where the clients have to subscribe to the site they will only evaluate the content while they are subscribed. This includes the Baseline actions since they are from that site. So the computers jump in the group once every 4 days, evaluate/run the actions, and then unsubscribe once complete and delete that Baseline content. That means that no more evaluation until the next time they subscribe.
Also, in a perfect world, the next evaluation the clients will have already completed the Baselines the first time through, will evaluate the content and come back Not Relevant, apply their tags, and unsubscribe from the site.
Understood however I thought IBM said having a number of open actions greater than 2500 can degrade performance regardless of whether clients are actually evaluating them or not. Evaluation is all done on the client side anyway. My concern is if I leave these baselines open and open more in our regular monthly patching as well as when we retire monthly baselines to this site, what the best practice for this should be.
It should be noted that our platforms teams that handle the building of images don’t have a great process at the moment and it requires a lot of actions to be open just for them.
So I’m trying to create the fixlet to deploy the breadcrumb and, even though the relevance I’m using to evaluate the fixlet is returning True, none of my endpoints or evaluating True when the fixlet is put in the site. Here is the relevance I’m using:
number of values whose (it is "Baseline") of headers whose (name of it is "X-Fixlet-Type") of relevant fixlets of site whose (name of it is "Catch-Up Site") = 0
When I use this in the debugger on a system that it should be applicable to it returns True but when I deploy the fixlet dynamically, no endpoints pick it up.
Is the Fixlet itself showing up as non-relevant (no applicable computers), or do the computers report Not Relevant when you push it as an Action?
I had a similar problem when i was trying to manage a fixlet relevance in this way, based on relevant baselines in a site. I think it has to do with the value of “site” or “action” losing context when the Action becomes active.
I’m doing something similar, but I’m basing the relevance on Pending Actions with a particular Constraint. I constrain my patching actions such that they only execute when a Client Setting “PatchWindowState” is not set to “closed”. I have the Action try three times before giving up, so now it’s no longer Pending. When there are no remaining Pending actions, I change the client’s PatchWindowState to Closed, which also unsubscribes from my catch-up site.
As for the number of open actions … I think that warning there has to do with responsiveness of the Console, which will try to retrieve status on all visible Actions when you open it. In a whitepaper IBM gave me on Patch Catch-Up, one of the recommendations was to use a dedicated Operator account to deploy catch-up patching. The CatchupOperator would have management rights assigned based on a Catch-Up Property on the client. When the client is caught-up, in addition to unsubscribing from the site containing the patch baselines, it would also unsubscribed from the catch-up operator account so it is no longer evaluating the Actions as well.
It’s the fixlet inspector. It can’t be evaluated in the context of a fixlet relevance.
I found this is in the fixlet inspector docs , where it says “these inspectors only work in the context of property evaluation, not fixlet evaluation”
I have found that it does work in an action script. So an approach could use action script which would do something when there’s no more relevant baselines.
// Action script
if {not exists relevant fixlet whose (exists header whose (name of it ="X-Fixlet-Type" and value of it = "Baseline") of it) of site whose (name of it is "Catch-Up Site")
}
// do something
if {not exists relevant fixlet whose (exists header whose (name of it ="X-Fixlet-Type" and value of it = "Baseline") of it) of site whose (name of it is "Catch-Up Site")}
setting "Pre2015Patches"="1" on {now} for client
else
setting "Pre2015Patches"="0" on {now} for client
endif
Just a quick chiming in. we are looking to do the same EXACT thing. Watching this one closely.
Just a note, I’ve been told you will also need to capture the time you put the PC in the catch up site. It will need to make sure it runs for at least 5min. Else it may not see it’s relevant and get spit out too quickly.
STATUS: Running action...
Command failed (Singular expression refers to nonexistent object.) if {not exists relevant fixlet whose (exists header whose (name of it ="X-Fixlet-Type" and value of it = "Baseline") of it) of site whose (name of it is "Patch Remediation")}
Did you run it in the client context? The Fixlet Debugger doesn’t have the site type inspectors so you would need to test this in a client or test the relevance through the client context in the FixletDebugger
OK, so we “have to pass the bill before we can see what’s in it”.
Actually got that to to work. Still working on the concepts of where/when/how things are “relevant”. Is there a better way to “debug” things like this without having to shove it in a console fixlet?
So should that fixlet that does the flip need to exists outside the patch site so it doesn’t mess with the applicable fixlets part of the query? Or can it be a separate fixlet in the remediation site, but outside the baselines and then it would be fine?
