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.
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.
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.
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
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.