Good day folks, in Patches for Windows (English) site | Fixlets and Tasks | there are a number of categories “By Source Severity, By Source Release Date, By Site, By Cateogry and By Source”. Is there an easy way to create a new category to sort by Operating System? So that this “By Operating System” view will give additional options to sort by different types of Windows (such as Windows XP, Windows 2003, etc…)?
Currently, all the patches for different Windows operating systems are listed in the same category. It is not user friendly.
If I click on By Source Severity | Critical | it shows my all the Windows patches for all kinds of Windows operating systems. It will be nice to break it down by operating system type.
I am having an exact same problem, Ours is a company which takes care of patching the servers for our customers, Contractually we are only supposed to patch only operating system related patches, we have got more than 300 servers to patch on a per month basis, now since the BIG FIX console is not at all user friendly in this regard as the sub categories like : operating systems -> win 2003, win 2008, win 7 etc etc, and sub categories like microsoft applications like sharepoint, office 2003, office 2007 is missing under the patches for windows site, we are finding a real hard time identifying application and operating system patches, I urge IBM’s Tivoli Developers to add these sub categories to the console for the sake of user friendlyness of the product
Creating filters as said by YORK is not a convincing option for me.
You’re right this is something that should just be in the domain spec and make it easy for users to see on the domain bar what patches are where.
The plan is to eventually add metadata to all of our fixlets in Enterprise Security about what OS and apps they apply on so you guys can do something like "names of bes fixlets whose (mime field “x-Fixlet-Category” contains “Windows XP”) or something and it will come up with a list of all of the XP fixlets. We’d have the same idea for any Windows OS or application patch.
I think I figured out a way to do this. Create a separate custom site for each OS in your environment. When you setup the Custom Site I recommend selecting Patch Management as the domain. Go to the Computer Subscriptions tab and click the “Computers with match the criteria below” dialog button. From the drop down boxes select OS, contains, and then type in Win7 or Win8 or Win2003, etc. for whatever OS you are wanting to filter by (Hint: Go to Computers, By Retrieved Properties, By OS to see how BigFix names the first part of the OS and use the same). Once this is done and you Save Changes, go to Custom Sites and select the Custom Site you just created. You should start seeing computers added to Subscribed Computers category under your custom site. The problem here is that you are still only able to see the patches a single computer needs one computer at a time. To overcome this you will need to create a new automatic computer group. In my environment I named the new automatic computer group the exact same thing as my Custom Site which was just the name of the Operating System the group was setup for. To do this go to Tools and click Create New Automatic Computer Group. For the Create in site drop down box select the name of the custom site you created, for create in domain you can select whatever you want but I would recommend Patch Management. For the filter duplicate the exact same settings as you used to setup the custom site. Once you save this you can click on Computer Groups in your Custom Site, click on the group name in the upper window, and filter according to whatever makes you happy in the window below. From here you can create you baselines or whatever you usually do. I recommend selecting the Custom Site you created for the create in site drop down list and then selecting Patch Management for the Create in domain drop down box.
Why isn’t the use of Custom Sites better explained anywhere?
This idea doesn’t work well if you also need to filter out fixlets by other criteria in a custom filter. For example not showing superseded corrupt install fixlets, or other fixlets you don’t want to have to manually select “around” as to not deploy them. This problem is seriously hindering our ability to avoid large baselines.
Another option would be to “Globally Hide” the Superseded/Corrupt content you don’t want to see it on a regular basis, then Automatic groups should be able to resolve the issue for you.
Of course, the Superseded content has a “False” relevance clause added (at least for Windows systems), and should never show as relevant on an Active system. I think IBM does this to leave the content in the system for audit purposes. Hiding it “Globally” (may require a Master Operator to do) won’t hurt anything.
As for Corrupt content, I hold that it should be deployed to endpoints just like any other patch Fixlet content!
Microsoft clearly documents which DLL, etc versions are included in each patch. While MS has gotten better about their patches not “breaking” other patches, it’s still possible to install a package or other program that will “back-level” a DLL or other component. If this happens, and the DLL is now not at the correct revision level for the patch, is the system really patched? I argue NO, it’s NOT. There was very likely code in the DLL that was modified for the patch (hence the new version of the DLL) and the patch should be re-deployed to correctly patch the system.
Of course, if you don’t want to see them, you can always HIDE or GLOBALLY HIDE them as well.
Except we can’t globally hide updates because there are some cases where we still want to apply them manually. Also, I’ve read on these forums and guidance by IBM, you don’t want to add the corrupt patch updates to your monthly baseline actions. It’s not just corrupt and superseded, but other criteria as well, like does not contain “exchange”.
We want to use Custom Filters as our list of fixlets to select from for monthly updates because it allows us to define specific fixlet types that are always approved for distribution, and it allows us to select the entire list in one go. Having to manually select relevant fixlets using the CTRL key amongst a mix of relevant fixlets we want and may not want, for a group of 300 servers, is very tedious and prone to human error.
Something else IBM could add is the ability to add more than one filter type on a custom filter. For example, fixlet name contains AND filtered by group. Currently you are forced to choose only one type to filter by (e.g. fixlet, action, group, analysis, etc.)