From time to time, I get asked about the Component Applicability tab in a baseline. There are scenarios where the results are not as clear as they seem. Those scenarios are around content that has been updated, but the baseline has not been synchronized. If you build monthly patch baselines for Microsoft patches, you will run into this as many of the Microsoft patches are cumulative, and are marked as superseded when the next month’s cumulative patches come out. I dug deep on this one as it seemed that I could not trust what BigFix was telling me, and that hurt my brain. Now, I have a much better understanding of that tab, so I thought I would share my findings.
Below is a detailed walkthru of the issue.
Problem:
When source fixlets that are included in a baseline are updated but the baseline has not been synchronized, the Component Applicability tab of the baseline no longer has the ability to definitively display the applicable computer count where the Source Fixlet has changed in relation to the component in the baseline. The below view reflects this scenario for 3 of the components, and it is evident where the Applicable Computer Count reports a certain number of devices as ‘unknown’. In reality, some of the below components can still be applicable, even though this view does not reflect it.
Systems will still evaluate the baseline and it’s components as always, and will still report accurate baseline applicability (Applicable Computers tab). When deployed, baseline applicability will be verified in real time, and each component will then verify applicability and execute if applicable, as baselines have always done.
So, from a deployment perspective, the baseline will execute just like we would expect it to and install all the appropriate content.
The nuanced difference here is how the component applicability tab comes to us within the console. Since Clients don’t report component applicability to the Root Server, but rather baseline applicability, the component applicability tab is built based upon the current applicability of the source fixlets. In the example above, since some of the source Fixlets have been changed (they were marked as superseded), the Console no longer has any context to report Component Applicability in those cases. The baseline view in the Console is a combination of data sets from clients – the evaluation of the baseline, and evaluation of source fixlets. Clients do not report applicability of the components of a baseline directly – that data is gathered from the fixlets themselves and combined with the baseline applicability data to give us the above view. It is important to stress that this is a VIEW created within the console for us to see the correlated data, but, as it reports ‘unknown’ in some cases, it may not reflect the actual applicability of the components whose source fixlets have changed – that is the key.
This is the inherent way that BigFix works, and the way that the baseline view is assembled in the console. That is why when content becomes out of sync, that the data in the component applicability tab no longer accurately reflects applicable system counts. To alter this would fundamentally alter how BigFix reports on baselines and have a direct impact on the amount of data that must be reported, processed, and inserted into the database, along with its size.
So, in my case, I have customers that are wanting to report accurate information for their patching baselines after some of those fixlets have been superseded by standard Microsoft patch content release schedules. Some of my customers also deploy patches 30+ days after release intentionally.
We effectively have 2 options to move forward:
- Enable the client setting to allow superseded content to be evaluated. This is an all or nothing switch. Generally speaking, this will solve the customer’s request, but it will come with an extreme cost – showing a TON more fixlets that are relevant in their environment, increasing the number of fixlets to be evaluated, and skewing all of their general patch data. This is a very high cost, and will continue to cost more as time rolls on and there are more and more superseded fixlets.
- Another option is to create copies of the fixlets and place them in a custom site, and then create the baseline from those copied fixlets. This means that those fixlets will never become out of sync because the copy in the custom site doesn’t get updated when the next patch cycle happens and new data is gathered from the content servers. This obviously requires effort and planning on the customer’s part, and over time, they will have a lot of copied patch fixlets that will need to be cleaned up. This also means that depending on how they are reporting against patch compliance, they may get two different stories. This isn’t a perfect solution, but it solves the original problem (accurate component applicability tab) without the pain of option 1.
I hope you find this useful.