Just wanted to run something by everyone and see if more people would agree that this is a viable idea that they’d support… The problem that has existed for a long time has always been reporting of Fixlet compliance in baselines (using session relevance example below) when fixlets are updated. With normal fixlets it’s pretty rare thing because generally the fixlets remain in place but with the *Windows Extended fixlets that are just updated to the new version there is no way around reporting fixlet compliance at that stage:
/* Produces: ComputerName, PatchesEverRequired, PatchesStillRequired | Compliance then calculated by: (PatchesEverRequired - PatchesStillRequired) / PatchesEverRequired * 100% */
(name of computer of it, number of results (computer of it, source fixlets of components of component groups of bes fixlets whose (baseline flag of it and name of it = "Some Baseline") whose (relevant flag of it), number of results (computer of it, source fixlets of components of component groups of bes fixlets whose (baseline flag of it and name of it = "Some Baseline") whose (exists first became relevant of it))) of bes computers
I guess what I would do (and not even sure if it would be possible) but add a secondary session relevance: cached fixlets of components of component groups of bes fixlets whose (baseline flag of it), where it is the temporary entity that represents the cached version within the baseline…
This is a very good point and pain point for reporting off of superseded fixlets that we are still deploying. Our patch cycle goes past patch Tuesday, so it’s a regular issue and we have to look for alternatives to pull the relevant servers for a superseded patch. We’ve done a hodge podge of reports that I have never been happy with in the end. We also have other vulnerability reporting tools in our environment, and since ISO manages those… they become the authority on vulns.
I have thought about copying the fixlets we deploy to a new site, but that has it’s own management overhead as well.
My “best idea” was some sort of “source of truth” of patch information to check for and then have relevance to validate against properties, such as installed patches, values from analyses (version of service, etc), etc. Never got to it.
I do know that v11.0.6 offers several new API endpoints that may help in some cases but we have not yet explored it.
We’re also moving to a 2 week patch cycle in the not to distant future, so that may be the main way we address this gap.
Yea but that puts pressure on the agents? I already have environment with Compliance analysis and a ton of custom ones, so average cycle times are high, starting duplicate fixlets is not really a good solution and will only make things worse..
Boyd, right but the compliance reporting itself uses “relevant flag of it”/”first became relevant of it” and those would not exist against the fixlets in the custom site if machines are not subscribed?
It also creates a “sync” problem - you create the copies but you’d have no idea if 1-2-3 of a bunch of the duplicated patches haven’t actually been updated by HCL after the duplication and you are reporting incorrect compliance…
My thinking is that in a ITSM approach, the custom site is the source of truth for patching, since only authorized patches are copied there via the CM process. The Computers that need patching are also subcsribed only to the custom site(s) where the authorized patches are placed. All of the usual compliance relevance applies. In this approach, the external site is not the source of truth for reporting.
The complication is the ongoing management of the custom site content so everhything is updated when necessary as the publicly available patches on the external sites are updated by HCL. This is not a small commitment.
The benefit is that all patches are under change control, and so each patch wave uses the same content for patching, regardless of the external refresh cycles driven by the publishers or the vendors.
Was wondering if HCL adding the ability to include versioning of fixlets within the platform so there could be a major.minor.revision concept on them, be they managed sites or custom sites be an area that is missing now the platform have developed beyond OS patches.
Anytime an op changes a fixlet they can choose to update its minor version though the revision is automatically incremented for any change (to avoid situations where the fixlet is update but op fails or decides not to update the minor version. This with a new feature added to baselines so the op can chose, per fixlet, whether to check revisioning against the component, this could permit flexibility that those wanting to leverage the baseline applicability as a compliance measurement.
That’s a good shout, maybe… I guess we have to wait a bit and see.
I like that and it kind of goes with what I though. What I was thinking is that as soon as add fixlets to a baselines, they should automatically be created as “temporary fixlets” on db level and from there agents should report their relevancy/first became relevant/last became relevant/etc …just like a standard fixlets. If you think about it, that doesn’t really add anything on client side load-wise because even today the clients still evaluate the relevancy of the fixlets that are in the baselines as were at the time they were added but it just doesn’t record the output as individual fixlet-like but instead as a portion of the overall relevancy of the baseline itself.. Once you have the info of the temporary fixlets in db, on reporting side you can do all sorts of very clever reporting - obviously, for my question you’d just use “cached fixlets of components…” just to get the info for the temporary fixlets but “source fixlets of components..” would still be available, so hypothetically you might want add both to a compliance report and in a way, you’d be visibly seeing “if I run as is this is what it will run but if I run updated version it will happen something else”… And if I convert the terminology of the logic to “versioning” - you’d essentially be seeing which machine needs the current version vs which needs the new and maybe within the take action window you can “overrride” the default “Include fixlet revision checks” pre-saved within the db option, so I can just change the setting for 7-zip because on my machine I’ve only tested the older version and don’t want to take a chance with the new…
