Redoing inefficient patch labels and patch schedules
We've been using our SMA for several years now, mainly for endpoint inventory and Microsoft patching. Years ago, we were a pure Windows 7 shop but we're now a mixture of 7/10 (300 and 300, so about a 50% split). More and more, we've just been seeing tons of handshake failures and slow patching overall and I'm pretty sure a lot of the labels/schedules we've been using probably aren't following best practices anymore and may actually be doing more harm than good. We do employ replication shares so we don't have all our sites bombarding the SMA directly, but I'd like to create some new patch labels/schedules and I'd love to get some feedback on what works for people. As an example, one of the original admins who brought KACE into the environment had a single patching label for Windows patches. This patch label by itself has almost 1600 patches in it using the criteria below:
Type - is not - Software Installer
Impact - is - Critical
Publisher - contains - Microsoft
Superseded - is - No
While that may have been fine back in the beginning, it's probably detrimental to have our endpoints evaluate that many patch signatures during detection phases. It seems to me that incorporating some additional criteria such as OS (now that we're using both 7/10) and maybe including some date restrictions (such as limiting my patch label to only include patches released within the last 60 days) might better improve this process.
Additionally, our patch schedules target endpoints by Site (IP ranges), but that's it. Schedules can have 100+ devices in them which may also be causing us issues. I'm wondering if creating more patch schedules but defining more specific elements such as not only Site, but also chassis type + operating system, would give me smaller more efficient groups.
I'd love to just get some feedback from others to see how patch-related labels and schedules are being constructed in your environments and how it works for you and your users.
Thank you!
Answers (4)
At first I would suggest to go to 10.0 and then redo all of your labels.
With 10.0 a new patching mechanism was introduced which means it makes sense to start new with the knowledge you have now you can create more efficient labels and schedules.
Comments:
-
Thanks, Nico. I think that makes the most sense as what to do next - dtobias_keenan 5 years ago
We're a new KACE customer still in the implementation phase, and one of the big things our engineer has mentioned is to add a filter for Status=Active to basically all patching filters. Otherwise, the appliance could be trying to search through all 10,200 (in our environment) active and inactive patches vs. just the ~2100 active patches.
I imagine that breaking down your patches/schedules by date or OS like you mentioned would further help, but I think active vs. inactive may give you the most immediate boost, and it's easy to implement.
All that said, we're not on 10.0 yet, so following Nico's advice first would probably be wise.
Comments:
-
Thanks, Jacob. The active/inactive is a good idea and on one of my test labels, it dropped the count from 1600 to 1400 patches after stripping them out. As Hobbsy mentioned below, finding a sweet spot for limiting by back release date may also help. Most of our systems are pretty current on patches so having a back date of 45-60 days may make sense in keeping those labels light as well and then figuring out a different patch process for newly imaged systems where they may need to backfill the patches from over a longer release date. - dtobias_keenan 5 years ago
One thing also to be aware is that now Quest is "testing" all released patches, rather than Lumension, some of the data labels that you would have built your patch labels on has changed. Which means that for customers that have been using KACE for years, all of your patch labels are best rebuilt, as they may not work...........Nice one Quest ;o)
With regards to ongoing patching, we always recommend limiting the patches by a reasonable back release date, that stops your ongoing labels filling up and getting too large, but be aware you may need to just then do a "Patch All" on new build machines to override those settings
Comments:
-
I wonder if it's possible to do this during the imaging process through the SDA. All new systems going forward are Windows 10 and the use of cumulative updates does limit (at least in quantity), the number of updates we have to apply. We try our best to update our images at least twice per year but we're a small IT group for a decently sized shop with lots of other responsibilities so it doesn't always happen unfortunately. - dtobias_keenan 5 years ago
Nico and Jacobtauer both have given you things to do. V10 patching works much better then before and why search for any patches that are not active, they will not apply.
Also if your RSA's are workstations and not servers that can lead to problems with connection limits, you want to use Server OS for your RSA's. If your RSA's are robust enough you can patch everything at once and the RSA's will limit the load per distribution point. We use 4 labels Critical MS patches, Non-critical MS Patches, Critical Non-MS patches, Non-critical Non-MS Patches.
Comments:
-
Yup, we do employ RSA's at each site for local patching versus having them come back to the SMA directly (no failover enabled). They are Server 2008 R2 hosts so we do need to upgrade them in the future to avoid the January 2020 EOL date. We'll start with the 10.0 upgrade after this month's patch window closes then proceed with the breakdown of the labels/schedules into something smaller and more efficient. - dtobias_keenan 5 years ago
-
Steve,
I really like your comment here and was wondering if you could post a screenshot or primer as to what your 4 patching labels look like. I am rebuilding my pre-10 labels from scratch and having a good effective idea of yours would be great.
Much appreciated,
Mark - markh4799 5 years ago
