I am trying to find a straight answer as too why when reviewing patches that come in with multiple "product" versions, some may be listed as Approved (Default Override) *System* or Denied (Default Override) *System* before I have even had a chance to review. I have attached a screenshot of a particular patch that was waiting for me to review the other day, (ignore the age of the patch as we are in the middle of a manual migration).
This is not the first time I have seen a version of a patch approved or denied like this, but it is troubling when I only have 1 to approve and do not realize that there may be more out there with an approval or denial already applied. I currently have "Override Default Approval Status with Denied for superseded updates in this policy" checked off and "Set New Patch Product Default Approval Status in this policy" to Pending Approval across the board. I have included a screenshot of this as well.
Any insight would be great.
Thank you,Joseph Figaniak
Default approval status applies only at the time the patch is FIRST discovered. Patches are discovered during patch scans against managed machines. Let's say you have a default approval status set to Approved. Any patches discovered with that classification/product would be automatically approved within that policy. You then change the classification default to Pending Approval. Any patches already known to the system will remain approved. Any new patches will marked as Pending Approval. Any patches already known to the system that are approved will remain marked as approved until you select the patches and change the status.
Taking this a step further, the default approval status applies at the time of discovery. Admins can change the approval status of an individual patch to approved or denied. That patch will then fall 'outside' of the default approval status because an admin has manually changed, or overridden, the default status.
Since the "approver" is *System*, the patch is set to the status it has now based on the configuration of the default approval status at the time the patch was first discovered. If an admin had changed the status from the default, the admin's login name would be listed in the Admin column.
Based on the screenshots you've provided, and making some assumptions based on additional configuration, here's my theory in what was likely to have occurred:
Regarding the first patch in your screenshot:
Changes to policy default approval status is logged in the System log. You can review these under System > System Log. Use the Description column to filter to the name of the policy to keep from having to scroll through all the logs. You should find entries stating, "The default approval status was changed to...." which will include details of the policy name, what the status was changed to (but not what it had been before), and associated to the login name of the admin who made the change.
The second screenshot includes a couple of options at the bottom which you've highlighted. The first, override default approval status with denied for superseded, would not apply to any of the patches in your screenshot since they don't appear to be superseded (check the patch detail by clicking the hyperlinked KB to be sure, but generally superseded patches are highlighted in yellow). The second option applies only to the PRODUCT of the patch. Periodically, MS releases new products for patches (like when they released Bing or when they acquired Skype and began patching those through Windows Update). Before the "new product" option was available in the VSA, all new products would default to Approved. After customer feedback, this option was added so you can define the default status when MS releases a new product group. This option would not apply to the patches in your screenshot since the products for these patches have been around for quite some time.
There's one final thing to note: When a patch is no longer reported for any machine in your environment, Kaseya will hide that patch. For example, you remove all Win2K machines from your environment and no machines report several Win2K patches. Those patches will become hidden, but will not be deleted from the database. If you then introduce a machine that has a need for one of those hidden patches, the patch will become visible again within your VSA. The patch will have the same status when it 'reappears' as when it was hidden. The default approval status will not be applied IF the patch was already known to the system and became hidden. If the patch was approved, then goes hidden, the approval status is changed to denied, if/when the patch reappears, it will be Approved since that was the status of the patch at the time it was hidden.
If you have any additional questions, feel free to post here. If you need help looking into your production system and/or can't align what I've described here to what you're seeing in your environment, please open a ticket with support at helpdesk.kaseya.com so they can assist with investigation.
It's a design limitation in Kaseya. Read this thread: community.kaseya.com/.../19214.aspx
In reality, the patching system really hasn't been worked in a development sense since the Windows XP era. It is quirky and hard to use, and some of the choices made at the design level are now imposing serious limitations given that OS's and the MS patch system has evolved massively in the last 10+ years.
At Connect, it was announced that the whole patch system (and the KSDU module) is about to be ripped out and replaced with a new "universal" patching product called lumension.
So don't expect any development work on addressing the flaws in the existing patch system.....we just need to work with it for the next couple of releases, then it's history. hopefully with lumension being a massive improvement!
I'll have to respectfully disagree that this is a design limitation. From the information provided by the OP, this is almost certainly due to changes in the default approval status for either the Classification or Product over time, and the function of the Default Approval Status is very deliberate based on a long history of customer feedback for this module. The presence of multiple patches with the same KB number (even sharing a product and classification) is based on the way Microsoft releases their patches and Kaseya's standard of not presuming duplicates when there is any discrepancy in the five-part key (four-part update ID + language). If any one of these components differ as reported by MS, the patch is considered unique. The addition of Lanuguage as part of the unique identifier was in direct response to customer concerns of missing patches when MS changed the way they identified unique records about three years ago (prior to which patches did not release with "duplicate" udpate IDs).
With the exception of Win10, Microsoft's patching processes (specifically the WUA service, agent, and client) have changed very little since it was introduced in Win2KSP4. There have been updates to the agent itself and the aforementioned 'duplication' of update IDs, but the functionality, the .api availability, etc., effectively remain the same.
With that said, the current Patch module is admittedly one of the older modules and has an older look and feel. HEAT, our new partner for the patch and update module, was announced at Connect and is planned for integration into the product in 2016. In the interim, however, the Patch module should meet most business needs (again, with the exception of the Windows10 issues, which do have internal engineering focus). While there are some areas for improvement, most failures of patch installations are due to environmental issues and can be resolved to allow successful installations, and it is possible to configure patch to be fairly hands-off from an ongoing module-maintenance perspective. It can be setup in ways that really optimize automation of patch approvals and installs.
Are there specific things you're finding are imposing serious limitations and/or make it hard to use? There may be alternate approaches to minimize those difficulties.