Kaseya Community

deny a patch that was already approved

This question has suggested answer(s)

we had SQL SP4 accidentally get approved. luckily (i think) it tried to install twice but failed. now that its failed, i want to revoke or deny this patch so it doesnt try to install it again next week. is there a way to do this in the GUI? i can't seem to find anything.

All Replies
  • So, even though theInfo Centre report showed the Citrix patch as Denied, if I deloy all patches, the Citrix update was installed. Why?? What is the point of a system that cannot reliably deny a patch?

    Yes, I can make sure that if I manually deploy I omit the Citrix updates but what about the scheduled deployment? What if I or a colleague accidently includes them?

    This failure makes Third Party patching - something for which Kaseya charges extra - pretty much unusable, which therefore puts us in a very difficult position with our customers.

  • So, after three and a half weeks, the ticket that I raised (complaining that rejected patches were being installed) has been "answered":


    "If a scheduled deployment is run via a Deployment Profile assigned to the machine, then the Citrix patches do not get installed as the Override Profile assigned to the machine is respected.

    When you manually deploy the Citrix patches via the Vulnerabilities > Deploy Patches function then the patches will get installed as this ignores the Override Profile. Therefore it is important to not select any patch with a Status of Vulnerable when manually deploying patches."


    My reply, as you can imagine, was that this was unacceptable.

    How can Kaseya expect staff in an MSP to memorise those patches that have been denied for individual customers – or, indeed, even specific machines in various customers? It makes running ad-hoc patch runs (such as where the are many machines with failed patches or where the scheduled run had to be skipped) as you’d have to check every single machine for denied patches.

    It seems blindingly obvious that if a patch is denied then it should be denied, full stop – no matter how the deployment is scheduled. To allow the patch you should have to reverse the denial, as was always the case with Patch Management. At the very least, the denial should be visible under the Vulnerabilities tab, which it isn’t.

    This issue leaves us in a very difficult situation: we have been moving our customers from Patch Management to Software Management because the former cannot reliably patch Windows 10 or Server 2016 and with the aim of being able to offer third-party application patching. Now, not only does it look as if the third party patching is unusable, there is also the issue that Microsoft patches denied to specific servers (e.g. due to compatibility issues) might be  inadvertently deployed.