Kaseya Community

Kaseya - Superseded patches - policy behavior

  • If a patch is approved in a policy, but then is superseded by a newly released Microsoft patch, which is also approved in the policy, does Kaseya try to install both patches or just the most up to date patch.

  • Kaseya's patch logic is client driven. First, K asks the client to run a 'check for updates' scan and return the results. Kaseya then lists any patches which the client indicates are required AND you have approved through patch policies.

    Therefore the logic about which patches to apply comes from the client (ultimately this is determined by the windows updates logic engine). This means Kaseya doesn't need to know or understand the rules of supercedence and dependency - it simply applies whatever Windows Update determines is required (unless you block it through patch policy).

    In your specific example, in most cases therefore only the latest patch would be applied, unless the previous patch was a dependency.

    A good example is KB890830 - the monthly malicious software removal tool patch. If you scan, say, a brand new widows 7 machine, it will only apply that months MRT patch, not *every month's* MRT patch.

    IMHO: this is one of THE best things about Kaseya patching - it NEVER tries to apply an inappropriate patch. Yes you can block a patch that it thinks it wants (e.g. to prevent an IE version upgrade or a .NET framework build, for example) but you can never force an inappropriate patch on a client. Great design!!

  • I mostly agree with Mr. Hart except that I would much prefer to have the option not to have superceded patches showing on my patch approval policy screen. I cannot think of a time, in all the time I've used Kaseya, when I wanted to waste the time or bandwith applying a superceded patch. And, if it isn't going to apply them, as determined by Windows Update on the client, then why should I have to scroll by them on the patch approval screen?

    Of course, I'd also like to have the ability to sort by column headers on the patch approval screens as well but....

  • zippo, you should use a patch filter to hide superseded patches.

    On the patch approvals by policy details screen, click the filter button and set the superseded option to "not superseded". Done.

  • There is also the check box "Override Default Approval Status with Denied for superseded updates in this policy." at the bottom of the policy definition screen which will set your policy as you desire, automatically,

  • Thanks, Craig. Good suggestions that I had overlooked. Sometimes I can't see either forest or trees...

    I think I prefer the second option. Have you ever applied a superseded patch?

  • Have I ever applied a superseded patch? I have no idea. possibly, but not deliberately.

    In any case, the patch itself & Windows Update contains enough logic to validate the patch is applicable before running. So, even if you forced, say, an XP patch on a 2012 box, it simply wouldn't do anything except exit (possibly with an error code indicating incorrect OS). Same with supersedence; the patches all know how to validate the environment before applying, so the worst thing that will happen is you just waste a little time and bandwidth (and probably an unnecessary reboot).

    So, the system is error-proof from this sort of error thanks to great windows update design....

  • In our Kaseya this option has never worked. I still see superseded patches in the approved lists. I've even opened a support ticket to our kaseya seller but they could not provide any answers why the "Override Default Approval Status with Denied for superseded updates in this policy." is not working as it should.

  • If the "Override Default Approval Status with Denied for superseded..." option is not working properly, please open a ticket.  However, before doing so, let me explain the expected behavior of this option:

    1.  At the time this check box is ticked, all EXISTING patches within this policy that are already marked as "superseded" will be set as Denied.  

    2.  Any patch that is already known to the VSA,  is approved or pending approval, AND becomes superseded at some point will be marked as denied at the point the first machine reports Microsoft has flagged the patch as superseded.  This happens as part of the patch scan/discovery process.

    3.  If at any point an administrator CHANGES the approval status of the patch, that change will override the default "denied".  For example, an admin logs in, sees a superseded patch is denied and changes the status to Approved, the patch will be approved AND remain approved going forward (until it is manually changed by an admin).  The "Override...superseded..." option does NOT forcefully re-change the approval status that an admin sets after the checkbox is enabled.

    If the behavior you are seeing does not align to the above, please open a ticket at helpdesk.kaseya.com.  If there is an issue with this option and there are no tickets to report the issue and allow for investigation, it is unlikely the 'broken' behavior will be addressed.  This isn't because the developers don't want to fix the problem (they do), but often times there is some quirk unique to a specific configuration that may cause issues.  Support and development need to be able to dig into cases where the behavior is broken to identify which scenarios may cause unexpected (or incorrect) behavior.

  • Thanks for the info. We are still using 6.3 but we are going to deploy a whole new Kaseya R7 setup next month and maybe the problem goes away with the latest release. If not I will surely open a ticket :)