Kaseya Community

Approval by Policy bug? Denied patches appearing in pending patches to approve?

This question is not answered

Hello, all. I am having an inconvenience with Patch Management>Patch Policy>Approval by Policy.  Every week or two, when I get around to approving or denying patches that aren't automatically set to Approved, I find that there are listings which are supposed to be set to Denied, but they still show up in the pending list of patches to approve.

For example, I have a Patch Policy called Servers-Approved. In that policy, I have set all Windows 2000, XP, Vista and 7 submissions to DENIED. Yet when I look at the list of patches waiting for my permission, there are some that sneak through. Today in my Servers-Approved I had 2 Windows 7 patches listed, and even though they are also on the list of Windows 7 patches, which are denied, they still show up. They still show up even though 200 pixels on the screen to the right in the main policy listings it says DENIED.

I've already updated all of my policies or I would have posted a screenshot or two to illustrate. Has anyone else had this problem? Have I been as clear as mud?  :)

Thanks.

All Replies
  • This has also happened to me, I've noticed it happening for the last couple of weeks.

  • I guess the problem goes the other way as well. I have a few update product groups set to automatic Approved, like Silverlight. To me, that means that they should never appear in the Pending Approval column/screen - they should automatically be added to the Approved column. But today, I have 2 Silverlight updates that are waiting for me to approve them for some reason...?

  • Every patch has two categorizations:  Classification and Product.  A patch needs to be approved both by classification and by product (the Default Approval Status must be "Approved" for both of these) for the patch to be automatically approved.  If the patch has a classification that is set to auto-approve but a product set to Deny or Pending Approval, the patch will follow the more restrictive setting.  Using Topher's example, a Silverlight patch has a Product of Silverlight but a Classification of Update Rollup.  Another Silverlight patch has a product of Silverlight but a classification of Feature Pack.  If the Product Silverlight has a default approval setting of Approved, Update Rollup has a default of Approved, and Feature Pack has a default of Denied (or Pending), any patch that is Silverlight + Update Rollup would be automatically approved.  The patch that is Silverlight + Feature Pack would be Denied (or Pending Approval) because the more restrictive setting would apply.  

    You can toggle between the Classification and Product on the Approval by Policy page using the Group By/View drop down menu to the right of the screen (above the patch list matrix).

    I've never seen an instance where a patch does not follow the programming properly, with regard to Default Approval status.  The above will apply to all patches that are NEWLY discovered by a VSA.  If a patch was previously known to the VSA, was no longer needed by any endpoint in the environment, it then becomes hidden.  If a machine comes along and needs that same version of the now-hidden patch, the patch will unhide and will have the same approval level as it did at the time the patch went hidden.

    Patches already known to the VSA will follow the default approval status that was in place at the time of discovery of that patch.  If you change the default approval status, those patches already known to the VSA will remain with their existing approval status.  New patches will follow the new approval level.

    If you're seeing behavior other than what is described above, please feel free to open a ticket with support.  We can help you to identify why a particular patch didn't follow the approval level you expected.

  • Thanks, Brande. No need for a support ticket yet -- I will verify your points above and get back to you. In the past, I have/had only approved patches via Policy, not by Patch, so I will look into that, based on your recommendations. Thank you very much for your advice.

  • Topher,

    To clarify, everything I outlined above refers to the Approval by Policy function, not the Approval by Patch function.  Within Approval by Policy, a patch that is newly discovered will become approved only if the defined Category and Classification for that patch are set to Approved. I did a TechJam on Patch Management a last month, and both the recording and the slide deck are available for download/review.  The policy approval information specific to what we're discussing here begins at the 33 minute mark of the recorded presentation (Patch Policy info begins a couple of minutes before that, but the information specific to default approval status starts at 33:00, so you can jump right to that mark, if you'd like).

  • Patch Managment issues.docx

    I see this post is over a Month old but I just came across it and I am having a similar issue.  Check out the attached Word document which describes my issue to include screenshots.  Basicaly I have both product and classification approved but patches are being denied or put in pending approval.  For instance I have Windows 7 patches approved and Common Windows Components approved yet those patches are either denied or pending approval.  Thanks.

  • ggordon,

    It is most likely that the patches that are pending/denied that you expect to be approved are individual patches that were _already_ known to the VSA at the time the default approval status was changed for the classification/product.  As described on 6/4 in the thread above, the patches will follow the approval status at the time they are first discovered.  If you change the default approval status after a patch is discovered by the VSA, the approval level will NOT change for that patch.  The new approval status will apply to all NEW patches that are discovered by the VSA from that point forward.  Any that are already in the pending or denied bucket will not change to approved.

    The exception (which is not really an exception) is that patches that are no longer needed by your VSA become hidden.  If a machine is introduced to your environment that needs that patch that has been hidden, the patch unhides and will have the SAME approval level as it had at the time the patch was hidden.  This is most often seen with deployments where the environment has managed  to upgrade old machines/software and eliminate the legacy software from the environment (old versions of Windows, Office, IE, etc.).  All patches that are not applicable to any machine in the environment will hide.  A new client/department comes on board that is using outdated software.  Those patches that were once hidden will unhide.  The approval would NOT follow the default approval status because the patch is NOT new to the VSA.  It is restored to view using the approval level it had when it was hidden.  

    I encourage you to open a ticket on this if you would like further investigation. If your log retention contains enough historical data to still capture the point in time the default approval status was changed, we can offer further details on timeline.  If the log retention does not go back far enough, then we may not be able to provide a definitive answer.  However, it's almost certainly the case that the patches currently in the Pending/Denied state that list "default override" were already know to the VSA at the time the override was changed to a different status.

  • Thanks, that makes total sense.  I will just have to go through and manually approve the old patches.  Thanks.

  • Well, now that the past month has settled down, I wanted to update Brande and everyone else that my problem is gone!  Sure, I may have cheated it - we migrated to a new KServer box and rebuilt all agent installations from scratch. The issues I was having do not occur any longer and so far Patch Management Approval by Policy is working as intended.