I would love to have a column added to the Fixlets and Tasks listing that showed which Baseline the fixlet or task was included in. With this simple change we could sort on that column and instantly get a list of all fixlets and tasks NOT in a baseline, and add them to new or existing baselines as needed!
This functionality would drastically simplify the patch process and would save BigFix admins a lot of time and effort spent auditing every baseline to see if we left any fixlets out!
One way I have tried to get around this is with Custom Filters, where I put the word Baseline into the comment field for any fixlet that is in a baseline, but the Custom Filter Properties for âCommentâ only allow âContainsâ or "Equalsâ, not the negatives, so I canât use that either. If I could put âDoes not containâ that would work. But that is not an option for some reason.
I would love some sort of feature like this, as well. I keep going back through old fixlets and finding that I somehow missed something that was released by Microsoft, like, 3 years ago, somehow. Or, at least, I think I did. Then I gotta dig through all my baselines looking to see if it was in one of them already or not.
The backwards method I am using now is adding a comment âBaselineâ to every fixlet that I add to a baseline.
I can run a report listing all fixlets that donât have this comment, but itâs difficult to use as a report, as you cannot just click the items and do anything with them.
So I use the All Patch Management/Fixlets and Tasks menu item to list all fixlets that are relevant, then go down them one at a time and click in the lower panel, then hit END to go to the bottom, if I see the comment, I know itâs in a baseline.
Slow, inefficient, and infuriating if you donât click in the lower panel before hitting end, because that takes you to the last fixlet.
From comments on this and other BigFix forum sites it would seem that this feature has been requested for 5 or more years, and yet still there is no way to easily tell if a fixlet is in a baseline or not.
Good idea !!! and if weâre going to do something involving baselines, having the baselines a little smarter would be great too. I mean, the baseline knowing when a fixlet is included twice (right now it does not, and if you build a baseline based on applicable fixlets of old PCs, you have to go sort it out), reordering fixlets inside of it in a faster easier way (chronologically, by release date, etc)⌠baselines are surprisingly backwards in that regardâŚ
If youâre in to building your own dashboards, the following session relevance will generate XML that can be imported as a Baseline, containing the fixlets from âPatches for Windowsâ and âUpdates for Windows Applicationsâ, that have at least one relevant computer and are not already contained by an existing baseline. Youâll need to tweak it to use your custom site name when checking existing baselines (I used âCM_Windowsâ), and you may also want to change the filters (I retrieve fixlets with default actions only). I also filter to only fixlets that are relevant for a computer that has reported within the last 60 days.
I use this in a custom Dashboard that takes the results, and uses âImportXMLToSite()â to give me a one-click baseline builder. You can test this in the Presentation Debugger, HTML mode, copy/paste the results to a file and then import it with the console (during Import, youâll need to âSynch all componentsâ.
("<BES xmlns:xsi=%22http://www.w3.org/2001/XMLSchema-instance%22 xsi:noNamespaceSchemaLocation=%22BES.xsd%22> <Baseline> <Title>req - Patch Windows Baseline 2017-XX</Title> <Description><![CDATA[<P>req - Patch Windows Baseline 2017-XX ]]></Description> <Relevance>windows of operating system</Relevance> <!-- May include additional Relevance stanzas --> <Relevance>if exists property %22in proxy agent context%22 then not in proxy agent context else true</Relevance> <!-- Update Category as needed --> <Category>Patch Win_All</Category> <Source></Source> <SourceID> </SourceID> <SourceSeverity> </SourceSeverity> <CVENames> </CVENames> <SANSID> </SANSID> <Domain>PTCH</Domain> <BaselineComponentCollection> <BaselineComponentGroup>" & concatenation of ( (it as html) of ("<BaselineComponent Name=%22" as html) & (name of it as html) as string & "%22 IncludeInRelevance=%22true%22 SourceSiteURL=%22" &
url of site of it as string & "%22 SourceID=%22" & id of it as string & "%22 " & (if exists default action of it then " ActionName=%22" & content id of default action of it as string & "%22 " else "")& ">%0d%0a<ActionScript MIMEType=%22application/x-Fixlet-Windows-Shell%22><![CDATA[//add actionscript here" & "]]" as html as string & "></ActionScript>%0d%0a<SuccessCriteria Option=%22OriginalRelevance%22></SuccessCriteria>%0d%0a<Relevance><![CDATA[true" & "]]" as html as string & "></Relevance>%0d%0a</BaselineComponent>"
) of elements of set of items 0 of
(item 0 of item 0 of it, name of item 0 of items 0 of it, item 1 of item 0 of it)
whose (true) of
((it, unique values of preceding texts of firsts " " of operating systems of applicable computers of it as lowercase) of
(fixlets of bes sites whose (name of it is contained by "Enterprise Security|Updates for Windows Applications")) whose
(fixlet flag of it AND applicable computer count of it > 0 AND (exists (applicable computers of it) whose (now - last report time of it < (60 * day)))AND (if not exists display category of it then true else display category of it is not contained by set of ("Audit"; "Bug Fix"; "Configuration"; "Definition Update"; "Hotfix"; "Microsoft Unsupported"; "Registry Setting"; "Setting"; "Uninstall"; "Update"; "Updates"; "updates")) AND name of it as lowercase does not contain "superseded" and exists default action of it),
set of (it) of (fixlets whose ((category of it contains "Patch") and baseline flag of it) of
(bes custom sites whose (name of it = "CM_Windows")))) whose
(not exists (it, elements of item 1 of it) whose
(item 0 of item 0 of item 0 of it is contained by set of source fixlets of components of component groups of item 1 of it and
(category of item 1 of it as lowercase contains "win_all" or category of item 1 of it as lowercase contains item 1 of item 0 of item 0 of it as lowercase))) )& " </BaselineComponentGroup></BaselineComponentCollection></Baseline></BES>" as html
Thanks! This is so far above my head I really donât even know where to put this or how to use it. Ditto for dashboards - I see that there are some (not particularly useful ones) already made, but I have no idea where to edit them or make new ones.
Someone above mentioned Session Relevance - again, it will be quite some time before I know BigFix well enough to dabble with such things - We just started using it in May. Iâm having a hard enough time figuring out the simple stuff that I had thought would have been built into any patching system. I mean, WSUS tells you right up front which ones are needed and just applies them. No need to add them to a baseline first. I like the flexibility of baselines, but they have not been wisely implemented.
No way to tell if a fixlet is in a baseline?
No way to sort a baseline? Manual clicking to move items up or down ONE space?
No easy way to move fixlets between baselines?
I have used WSUS and KACE, and both are worlds better than BigFix when it comes to the basic items like the above usability features.
BigFix is far more powerful, but less usable unless you have a LOT of behind-the-scenes knowledge. Iâll get there, but itâs going to be painful getting basic functionality until then.
There are so many different ways to create baselines, that a âbest practice for patch managementâ video might make a good addition (if thereâs not one already).
Most of the guidance I see revolves around âtake this monthâs patches and create a baseline from them. You can use the Patch Management Dashboard to grab the patches released by dateâ. I donât like that very much, because it can be difficult to catch when a new system is added to the deployment, but is missing an old patch.
It can be helpful to use the âComputer Groupâ view, which will show you the Fixlets that applicable to any members of the group, to build patch baselines. This is what I used before I wrote a dashboard to autogenerate my baselines. There are going to be a number of fixlets that you donât want to deploy (for instance, there are âapply workaroundâ and âundo workaroundâ fixlets for a lot of the security items where you make config changes instead of installing patches, and theyâd conflict with each other), so youâd want to âhideâ those Fixlets to stop them from appearing in the list.
Again, this has the limitation that you canât tell which of those patches are already in your baselines, but it doesnât really hurt anything to have a patch in multiple baselines. What does impact you is having very large baselines, and this is a common problem especially when building baselines to catch-up old machines.
I was trying to minimize the number of baselines, as if we ever want to automate patching with policies, we will need three policies per baseline.
one for test systems, auto-reboot in 3 minutes
one for live users, requests a reboot in 15 min, stays on top afterwards until rebooted
one for servers, requests a reboot in 24 hrs, stays on top afterwards until rebooted
I may end up combining the latter two - compromising on 30 min or something. The main issue is people hate to have their systems rebooted and servers really shouldnât be rebooted automatically.
Thereâs always the chance that I go rogue and put the normal desktop users and test systems into an auto-boot in 15 min policy. Iâll just lock my door and hope they donât have a crowbar.
Currently the base1 (initial) baseline is 220 items, the base2 is 83 and when it gets to 200 Iâll start a base3. Might take a while since as things get superseded I remove them from the baselines. And having to stop and re-issue policy actions after any edit to a baseline - well, thatâs job security!
Kudos to you all for coming up with these great ideas and suggestions for improvement. I too have struggled to find a way to efficiently find what baseline a fixlet is included in. I too have run into problems with duplicate fixlets in a baseline. If these simple improvements could be implemented it would be greatly appreciated.