Patch Data Overview

All patch data in any Kaseya installation comes directly from the patch scan results for all managed machines. There is no “master” Kaseya patch database maintained by Kaseya. When patch scan results are processed, all patch data obtained from the Windows Update Agent (WUA) API is added to or updated in the Kaseya database. Please refer to the “Patch Scan Overview” thread in the Patch Management forum for details.

The patch data obtained from the patch scan results is stored in the Kaseya database and gets mapped to each machine that has reported it in its patch scan. It also gets mapped to each Patch Approval Policy that exists at the time the patch scan results are processed. All Patch Approval Policies contain exactly the same patches. As long as there is at least 1 machine reporting a specific patch, that patch will always be visible in ALL Patch Approval Policies. When a patch is no longer reported by ANY machine, NONE of the Patch Approval Policies will display the patch. In version 5.x, the patch policy mapping record for that patch gets deleted. This results in having to re-approve the patch when it is re-added to all policies whenever another machine subsequently reports this patch. In K2, this has been changed to only hide the patch policy mapping record for that patch, so when it is re-added to all policies after another machine subsequently reports this patch, the previous approval is restored.

Among the patch data obtained from the WUA API during a patch scan is the KB article number, MS security bulletin ID (if a security patch), title, description, patch classification, product family, patch download link (if available), and other data visible in the Patch Details page (click on any KB article link on any patch page). In order to uniquely identify the patch, we use identifying data provided by the WUA API from the Microsoft Update Catalog. This identifying data provides the unique key within all Kaseya installations. Unfortunately, Microsoft is not consistent when it comes to the updating of this identifying data when changes are made to the data in the Microsoft Update Catalog. The identifying data will get changed whenever the actual patch files are revised (this is a good thing!). But Microsoft will also sometimes change the identifying data when only the data in the Microsoft Update Catalog is modified. What this means is that we end up with multiple patch data records for what is essentially the same patch. This happens because machine “A” gets patch scanned on Monday and reports patch “X” is missing with ID = X1, and then Microsoft updates the Microsoft Update Catalog on Wednesday, and then machine “B” gets patch scanned on Friday and reports patch “X” is missing with ID = X2. Because of the identifying data, we have to treat each patch as a different patch because there is no other patch data that can be used to reliably indicate they are for the same patch.

Customers have suggested using the KB article number for identifying patches. Unfortunately, the KB article number cannot be used to identify a specific patch. In many cases, it identifies a series of patches for the same issue where different patches are created for different operating systems. Sometimes, the same KB article number is used for a series of patches that get updated every month (e.g., the monthly update to the Malicious Software Removal Tool). Sometimes a KB article number is associated with a specific security bulletin, but the actual patch downloads have different KB article numbers depending on the operating system. And sometimes, multiple KB numbers are used for the same update (e.g., IE7, IE8, etc.) So, in reality, the KB article number is only a reference to Microsoft documentation related to a patch or an issue to which a set of patches are associated.

The discussion on identifying patches is background as to why there appears to be “duplicate” patch data records in Patch Approval Policies. We have chosen to identify unique patch data records based on the Microsoft identifying data. Sometimes, this results in multiple records requiring approval for logically the same patch. This provides the most granularity for approving specific patches. While this is too much granularity for some customers, doing something else would provide too little granularity for other customers. We do understand the pain point here for some of our customers, so we will look to providing several options for approving patches in a future release.