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?
@AlanM Seems like for this particular case it works in Fixlet debugger with Local Client Evaluator only. So it fails in the Action debugger, which doesn’t have a Local Client Evaluator.
Just wanted to follow up for anyone who is looking to have a “patch catch-up” site. This does work. You just have to run it in the console on a client to test it. (as others have noted) Just thought it would be helpful to sum it up.
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")}
regset "[HKEY_LOCAL_MACHINE\SOFTWARE\key]" "test"="1"
else
regset "[HKEY_LOCAL_MACHINE\SOFTWARE\key]" "test"="2"
endif
There is some additional code to do a date diff you should also add. You would need to add it in when you run your key to put it in patch remediation. So when you do your check:
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")}
if {now - (value "patchDate" of keys "HKEY_LOCAL_MACHINE\SOFTWARE\key" of (registry;x64 registry) as time) > 15*minute}
regset "[HKEY_LOCAL_MACHINE\SOFTWARE\key]" "patch"="1"
regset "[HKEY_LOCAL_MACHINE\SOFTWARE\key]" "patchDateDone"="{now}"
endif
endif
For me, the “patch=1” pulls it out of the remediation site. There is another fixlet that lowers the CPU and sets patch to 0. that puts it in our patch current site.
I know our Sales Engineer is working on a papers on how to fully accomplish this as a process, but it’s not complete.
I found a small “gotcha” in this and perhaps someone can help me with this because I’m hoping to use this same concept for a site-to-site movement for post imaging software deployment. This:
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")
Looks for RELEVANT fixlets, period. Not just relevant fixlets that have actions associated to you (the machine). So there may be a baseline that has not been made active yet, or we may even only want to target to a specific group and not others (but would still be relevant if you assigned an action). This needs an additional “… and whose fixlets are assigned to me” sort of thing.
Just checking that this is the case when evaluated by the client. And thinking out loud here … maybe factor in the report (the result of an evaluation by the client) and look for the one from the machine in question.
