Curious how y’all are creating your monthly Windows patch baselines?
Currently we use a manual process to grab all of the patch Tuesday releases “MS-24-FEB” for example, then we add more components if they exist for .NET related stuff. Often times we have to re-order the fixlets/tasks so that the Servicing Stack updates occur first.
Then, we take our prior months baseline, and integrate it to a single baseline congaing all patches for the year, then delete that prior monthly baseline.
This is time consuming… and tedioius.
I am wondering if there isn’t a better way. The end result we desire is
A current month baseline containing all patch Tuesday patches and any new / updated .NET/ASP patches.
An annual baseline containing all of the patches year to date.
I am responsible for patching our Windows servers. We have various automatic groups to group servers together - some based on location, others based on the server’s function. We start our monthly patch cycle the weekend following Patch Tuesday, so usually Thursday morning I’ll run a script that looks at each group to see which patches are relevant. Those that match our criteria (patches from specific sites, have a defined source severity, have a default action, etc.) are added to a baseline that will apply to that group only.
Once the baseline has been built, the script submits an action with the group as the target, the baseline as the source and the schedule based on data from our CMDB.
At the end of the month’s patch cycle I go through and delete the expired patch jobs and the monthly baselines. Then do it all over again the following month.
We have a scripted process that automatically creates and refreshes baselines using for fixlet search criteria that matches our specific deployment requirements, using the REST API. In simple(ish) terms, it will do an API call to pull all the relevant fixlets for a certain search criteria bespoke to our needs, split these into batches for each year of the release date then create/refresh the baselines for the matching year. In the case of a new patch cycle, a baseline of only the newly released patches is refreshed so we can deploy only new patches to a pilot community prior to global deployment of all past and present patches that will only commence after a successful pilot period. The baselines are currently manually deployed to automatic computer groups where we have other processes that integrates to a centralized maintenance window management tool which then control, via the client lock state, when a server or mission critical workstation will process the deployed baselines.
We found that this way the baselines do not grow to too many components (with 100 being the recommended max though prior to MS moving to cumulative, we did have closer to 200 components in 2 or 2 of the baselines) and we are only having to make 1 deployment of each baseline for the entire Windows estate and any system that needs to follow a strict maintenance window, which the Bigfix admins do not control nor have any control over, will only process this when they reach their configured maintenance window. Of course on the down side, the locked client does also mean that by default, any other deployed fixlet other than those in “BES Support” will not be processed until the maintenance window.
You may want to look at whether Patch Policies would meet your needs. You can create different polices then create deployment schedules which may work for you. Any features of Patch Policies that doesn’t meet your need, submitting an Ideas request would help HCL gain visibility of their customer needs which helps drives development on new and existing features.