(imported topic written by akummer)
Hi,
you sent out the information that fixlets have been changed.
Could you please explain why and what?
Best regards
Andreas
(imported comment written by ErinC91)
It does appear that every single component of every baseline we have requires re-sycn’d
(imported comment written by emock91)
We had to re-create all our Baselines, same problem … what changed ??
Eric
(imported comment written by BenKus)
Hey guys,
Sorry about the lack of detail in the announcement.
Here is some more detail and background info:
Just a few years back, we only had a dozen or so supported platforms and a handful of Fixlet sites. In the last few years, we have been developing many new Fixlets sites (i.e., Asset Discovery, Power Management, Security Configuration Management, License and Inventory, new patching for 3rd party applications/non-english systems/Unix and Linux systems, etc.) Also, we have greatly expanded our support for platforms that has included all sorts of Unix/Linux/Mac platforms and mobile platforms are not far away.
This proliferation of new features was great for the customers, but we needed to update some of the core architecture to make sure that we don’t drown ourselves in our own expansion of features/products for our customers. We have been making small optimizations/changes in every version of BigFix, but one particularly useful change was that we have added the concept of “site relevance” to our agent and Fixlet sites.
Site Relevance – Background:
In old versions of BigFix, all agents got all Fixlets and it was up to the agent to decide whether or not to report the Fixlets relevant (even if the the Fixlets were geared for a different OS). As we released more sites/platforms, it started to become more common to see that agents were downloading Fixlet content that seemed like a waste. For instance, AIX computers would download Fixlets for French Patches for Windows, Windows NT computers would download thousands of Fixlets for RedHat, and so on. This normally was a fine and efficient system because the Fixlets are small and the agent had many optimizations to quickly ignore Fixlets that don’t apply… But as the number of sites grew, it became more important to avoid using unnecessary disk space, network traffic, CPU cycles, etc. In particular mobile computers have much more limited resources and we didn’t want to burden the mobile agents with data they didn’t need.
Site Relevance – Solution:
To solve this issue for all platforms, we introduced “site relevance” agent enhancements into BigFix 7.1. We have recently added site relevance to our Fixlet sites so that customers with 7.1 can take advantage of the site relevance benefits. The way this works is that each site will have relevance that tells the agent whether or not the agent should even care about the site. For instance, for the Patches for Windows sites, the site relevance is:
if( name of operating system starts with “Win” ) then platform id of operating system != 3 else false
which means that the agent should not download the site unless it was a Windows computer that was not a mobile platform. If a Unix/Linux/Mac/Windows mobile BigFix agent 7.1 and above sees this relevance, it will not even bother to download the Fixlet site. The relevance is also applied as “parent relevance” to each Fixlet digest, which means that you will see it if you look in the console at the Fixlet details.
This solution is an efficiency that was somewhat overdue and I think this is a good change that will benefit many people (if not now, then hopefully in the future).
Unfortunately in the short term, it means your baselines will have a warning that the underlying Fixlets have changed (note that the change does not really affect the Fixlets/actions for your existing Windows systems and so there should not be in difference on which computers are applicable for the Fixlet).
And I will go ahead and anticipate more requests for the feature of a “Synchronize All Baselines” button and file the request.
Hopefully that (rather long) explanation was helpful… any questions?
Ben
(imported comment written by akummer)
Hi Ben,
thanks for the explanation!
Does this also has an effect on the recommended amount or fixlets in a baseline?
We have been adviced not to use more than 50 fixlets per baseline (better less).
We use 7.1 with “usePre70ClientCompatibleMIME” set to false.
Thanks
Andreas
(imported comment written by ErinC91)
Thanks for the explanation Ben
(imported comment written by BenKus)
Hi Andreas,
If you are using efficient mime (usePre70ClientCompatibleMIME set to “false”), you can make much bigger baselines. There isn’t an upper limit in any case, but I think that baselines of 150+ shouldn’t impact agent performance much.
Ben
(imported comment written by SystemAdmin)
Yes, thank you, this is a much welcome addition. We use all the patch languages so our systems were processing a dozen unnecessary sites before 7.0 and we could target subscriptions by OS language. It’s nice to have the relevance built into the sites now instead of having to manually configure it.
(imported comment written by manjukris91)
Hi. Once a fixlet is created, will there be changes to it? For example, adding more actions, modifying fixlet size etc?
This question may not be relevant to this discussion. But, can you please let me know about this?
(imported comment written by BenKus)
Hi manjukris,
BigFix will change the Fixlets if there is any good reason to change them, including: if the source changes (such as if Microsoft updates a patch or bulletin), if we make a mistake and need to fix it, if we find new information (such as if we hear there is an issue with a patch or configuration change).
BigFix announces changes on the BigFix Administration mailing list.
Ben