I opened a ticket on this, but I'm curious if others have experienced this...I had a customer complain that if he runs Windows Update manually, there are updates available despite Kaseya (and me!) saying that his machine is completely up to date. So I did a few spot checks and noticed this all over the place. Here's one example:
KB2487367 Security update for .NET 4, released 8/9/2011
It is APPROVED for the patch policy
The computer is definitely in the patch policy and no other
The patch isn't denied in ANY policy
If you look at Patch Status, I see Installed Patches: 131, Missing Approved: 1 (MSRT for January), Missing Denied: 18. KB2487367 is not in any of these groups.
I'd like to have this (and all patches I approve for that matter) actually applied to my endpoints. And I'd also like to see Windows Update report that a computer is up to date so that customers who spot check me don't think I'm providing lousy service.
What could I possibly be doing wrong here?
Given what you've provided above, it's possible that the scan is failing to complete successfully. When Kaseya runs patch scan, we invoke the Windows Update Agent (WUA.api). WUA determines the patches that are missing from and applicable to the endpoint and writes those results to a log. Kaseya gathers that information, uploads it to the KServer, and parses the data. The result is the list of patches within your VSA. The patch policy will determine whether the patch is approved or denied for the endpoint, and anything Missing Approved is installed during the next Automatic Update cycle. If the scan isn't completing properly, then results of the Kaseya v. Windows Update scan will be incongruous.
If the patch is approved and Windows Update is reporting the patch as Missing from the endpoint, the logs available will be able to shed light on what's going on. If possible, please take a screenshot of Windows Update showing the patch as missing and upload that screenshot, c:\windows\windowsupdate.log, and ptchscn2.xml from the working directory of the endpoint to your ticket. If you want to shoot me the ticket number, I'll take a look and get you some specific detail regarding this issue.
While it's not applicable to this specific patch, it is worth noting that Kaseya doesn't support device drivers, MS Forefront, or MS Defender patches, so those would not show within Kaseya and would not be installed via a Kaseya-called update process - and they won't appear within your VSA.
I am having this exact same problem across all of my servers.
40+ patches that are approved via patch policy (and are denied in none) are infact showing as 'missing denied' under the patch status.
Did you find a solution?
OK found the cause.
It turns out that if a machine is a member of more than one patch group then the following logic applies:
Group 1 Patch = Approved
Group 2 Patch = Pending
Result = DENIED
I cant see how this is right?
Surely 'Pending Approval' should be neutral in the patch logic?
If you have not approved a patch, why should it be released to your machines?
With your setup, you either need to approve it in both policies or give it a single patch policy.
But I have approved the Patch...in patch Group 1
Why should a 'Pending Approval' status in patch Group 2 trump the Approved status in patch Group 1 ?
They may be named differently....but 'Pending Approval' is identical to 'Denied'...and therefore serves no purpose.
Its a fail safe when more than one policy is applied. In this case it fails to inaction (less change to the agent machine), which is theoretically safer than failing to push changes to a destination agent.
I would concur with @Dantheman - you need to approve in both policies or revise the policy assignments.
I appreciate the fail safe.....and think it makes perfect sense to be cautious and deny unless approve.
Its my fault....I need to re-read the kaseya Patch manual and get my policies right.
My point however really heads towards feedback/feature request.
Pending Approval is redundant. It is identical to Denied and therefore only adds confusion.
Having a Pending Approval that remains neutral does in fact serve a purpose.
Joshua - Pending approval is a bucket into which newly released patches will fall (when the Default Approval is set to do so). If those patches were to fall directly into Approved or Denied (with no other alternative), it would be exceptionally difficult to find the newly released patches each release date to process those. You'd have to dig through the thousands of patches to find the 10 or 200 new patches each month so you could approve/deny them.
A patch is only approved when it is explicitly approved. There has been a fair amount of discussion regarding this on the forums. One chain of posts is here: http://community.kaseya.com/xsp/f/30/p/11731/57972.aspx
If Pending Approval became neutral, you could very well end up deploying a patch that you don't want to deploy. For example, you set the Classification "Service Pack" to Pending Approval because you want to be able to identify newly released service packs, but don't want to just push them out to users immediately - you also might not want to immediately deny them just to later have to dig through hundreds or thousands of already-denied service packs. If Pending Approval allowed that patch to install (as a "neutral" category), then you'd be pushing out Service Packs (in this example) to end users when you might not be ready to do so. If you just denied them based on a default approval level, you might never realize they were released. This leads to a lot of gray area that, in patching, can quickly become dangerous. Rather than muddy the waters by inadvertently allowing a patch to install that hasn't been explicitly approved, the process requires that you actively choose to approve each patch (either individually or based on the default approval level). The 'danger' of deploying based on a neutral setting is pretty high. IE is another example - Microsoft doesn't group IE into its own product category. Rather, it's included under the product category to which that particular version of the IE patch applies (you'll find it under the XP, Win7, Win2003, etc. product categories). A lot of people have delayed or avoided deployment of IE9 because of compatibility issues, particularly when it was first released. If "Pending" allowed this to install...that would be very painful for a lot of people. You could just Deny all patches by the OS product category, but then how would you determine which ones are newer that you need to process (in this case, approve)? There isn't a 'safe' way to allow Pending to be neutral. Rather, we take the cautious road and only allow patches to deploy (via Automatic Update) that have been explicitly approved.
pending approval = not approved = do not want yet
if patches with pending approval went out without getting approved, why even have an approval process?
if you want the patch then approve the patch in both policies or take away the policy that restricts it.
My original problem wound up being the fact that an application had been installed just after the most recent patch scan. The app utilized .NET 4 and installed that automatically. At that point Kaseya showed that some .NET patches didn't apply, but a Windows Update scan showed that they did. That led to more checks which revealed the same thing. Sorry for the confusion, but that was basically my fault for not putting all of the pieces together.
As for the other comments on this thread, they remind me of when I tried to create a "Test Workstations Policy". I wanted to apply that and the normal policy to a few sample workstations in the offices. I would approve questionable patches only on the Test Workstation Policy, wait to see what happens, then approve on the others. The problem with it was that the patch wouldn't apply until it was approved in both policies...same deal as what you all are talking about.
I suppose the only way to do a Test Policy is to keep it in sync with the normal poliicy, but my hope was to create a Test Policy with ONLY the test patches approved in it and allow that to overlap the normal policy. How does everyone else handle testing?
Just my 2c on this;
The Pending Approval feature is actually very useful and I would not want it removed.
If you don't want to use the Pending Approval functionality simply turn it off. To turn the Pending State off, navigate to the "Patch Management > Patch Policy > Approval by Policy", Select your Policy from the drop down menu and change the "Default Approval Status" for both the Classification and Product policy views to either "Approved" or "Denied". Note that you would need to revisit the policy's "Default Approval Status" once a month or so to deal with new Classifications and Products (i.e. Windows 8).
As a general rule of thumb you will almost never (in M$ world that is) be able to fully patch all of your managed systems all of the time.
If it is an SLA requirement then you would need to put somebody on to patch management as a full time job as you will always find patches that can't be installed by either WSUS or Kaseya's Patch Management. These patches would need to be deployed either manually or via a scripted install that can deal with the reasons why it can't be deployed via the automated systems.
I have a pilot group and a production group. We apply one or the other to machines, never both.
I approve the patches in the pilot group and 3 weeks later I copy the pilot group to production...
that way I have some machines with the new patches and others with the formerly approved patches
I also do not want pending approval removed....because when a new patch is picked up as needed on a machine I don't want to have to revisit all my denied again to find it..nor do I want it auto approved.