Operating system applicability on fixlets and relationships to basline

Usage and Config Platform
1

(imported topic written by Metapro91)

I’m having some issues try to generate information for management. Basically they want to know out of all the patches that have been approved for our environment, what percentage are relevant to our system. This would be easy if we were incorporating everything, but they want to split it up by operating system. i.e.,

All relevance patches for workstations / All possible patches for workstations

We already have a property to differentiate between workstations and servers, but the problem lies in how fixlets are generated. There’s no flag or property stating which operating systems could possibly (at any time) have the fixlet applied or relevant to. Going through each fixlet and entering that info based out of the relevance and into the comment field, for example, is to tedious to even think of. Basically the only way to tell if a fixlet is applicable to a group of machines is if it’s currently relevant. This is great if we want to be able to take actions, right now, on what’s relevant, but not good if you’re in a dynamic environment where you need to adhere to set patch standards. Maybe adding something like “Non-Relevant but applicable to OS” would be what I’m thinking.

At the risk of leading to another thread, I think this leads to baselines. As many have previously stated, they want to see a baseline as a collection of “accepted” fixlets to be applied as soon as their relevant. The problem is if they aren’t in the baseline before they become relevant then it won’t get the fixlet. Using Microsoft Security Hotfixes for example clearly shows how large and unwieldy they can become. This is compounded by what I mentioned above: If there was a way to separate fixlets by XP, Win7, Office, .NET etc., then we could greatly reduce the size of these baselines and be confident that we aren’t missing any patches now or in the future. Although the solution for using large baselines has been discussed many times I’ve yet to see a really good solution, so please share any thoughts on systems that work for you.

Hopefully these issues ring true to some of you and others have solutions they can provide. BigFix is an awesome tool, but baselines are an area where I think a lot of advancement could be made.

2

(imported comment written by BenKus)

Well… I know why you want this and we have actually spent a lot of time thinking about this… but the fundamental problem that we have is that there is not exactly an easy concept of “possibly relevant”.

In your example, your management’s request report has assumed that OS is an indicator for “this computer might need this patch”, but there are all sorts of reasons that might not be true including: the patch applies to an application and not to an OS, a patch pre-requisite was never installed (e.g., should an IIS patch be “possibly relevant” on Windows 2003 Server if IIS has never been installed?), the OS never needed the patch because it had a later service pack, etc.

So if we were to implement your scheme of OS-based “possibly relevant” mechanism, we can almost guarantee that people would immediately be mad at us because we have misled them with this info because it was not accurate in all cases. Rather than do that, we stick to the idea of very-well defined “relevant” vs. “not relevant”.

We do have a potential solution to this, which is to create a new “third Fixlet state” with its own custom relevance that would determine if Fixlets might be relevant. And then we would ask Fixlet authors to define this according to the details of the Fixlet (e.g., IIS was installed so you might have needed an IIS patch)… However, this change would increase the amount of work per Fixlet and add a potentially confusing complication to Fixlets…

But… having said all that… we might be able to find a report for you that will meet some of your needs… Can you give me a bit more data on the report that you had in mind and I will see what I can come up with?

Ben