Just want to give you all a heads up on this problem. You will not know until you check the c:\windows\windowsupdate.log so check your logs.
The big question here is: Why is there no proper workaround from Kaseya, like the one used for WSUS/SCCM? The fix from Microsoft could be more than one month away!
Translation for workaround 'Use "user settings" to patch the system...' appears to be patch using Windows Update.
This is not the first time we have had issues like this the "Windows Update Agent" update also had no official fix from Kaseya.
Reading the technet article it appears that only Windows 32bit clients with a large amount of outstanding patches has this particular issue.
What is interesting is that step 2 "Decline any unnecessary updates on the WSUS server.", what if we created a new deny patch policy in Kaseya, denied any new patches released this year (just before when this issue was first noticed) and all superseded patches with this policy and applied it to the agents that have this issue the patch scan might actually finish without an error.
Once you have fully updated the endpoints with this patch policy, unassign this patch policy from the endpoints to approve the 2015 patches and run another scan and update.
Not sure if it will work but it might be worth a try.
I assume it does affect alla clients as it needs to scan for all patches even though they have been applied already. How would it know before scanning if the patch is needed ? :)
It does actually affect 64-bit also sometimes. If you have fragmented memory or low memory (like 2-4GB RAM) you could still see this issue. You are also affected by the problem this also cause: performance issues when scanning for patches.
I have tried everything possible. The only thing that might work is to use offline scanning and hopefully you get most of the missing patches. Windows Update is not an option for us as we want to block certain patches that currently cause issues with a few applications we use.
Denying a patch does not change the fact that the patch is scanned for. It will as you know still show up in the "Denied" list.
What we need is a fix from Kaseya that REMOVE superseeded patches so that it will not be scanned for. This is what work as a workaround for WSUS/SCCM.
Thanks for the info on the patch list, I can see why the patch policy idea won't work.
Regarding 64bit Windows Machines with this issue;
Not sure who would be crazy enough to run a production 64bit Windows machine on less the 4GB of RAM. If the computer has 4GB of RAM, a simple reboot should sort out most low or fragmented memory issues, unless the computer is running to many things on startup then clearing up any unnecessary startup applications and/or upgrading the RAM would be an easy fix.
So that is why I said its really only 32bit Windows machines that would run into this issue as the OS can't address much more then 3.5GB of it (3.7GB if you tweaked it).
svchost.exe who run Windows Update Agent is by default only allowed to use 2GB RAM (on 32-bit only? Don't know). But I agree that this is normally only 32-bit OS who would be affected by this issue. Just wanted to make clear that you should check all Windows 7 computers as it would explain many issues with scanning like no result and also performance issues.
There is a patch out now from Microsoft for low-memory machines failing patch scans. You'll need to manually install KB3050265 on affected machines.
Note this is a Windows bug, not a shortcoming of Kaseya.
Thanks for sharing this with the community. I'll pass along to Support so they can address any outstanding tickets and update any necessary documentation.
Thanks for the update! :) When testing the update (worked fine) I noticed that we even had computers affected (no patches needed or missing patches) that did not even had the error 8007000E in the log. So I guess the patch also fix other issues as well...
Understand that this is a Windows bug but Kaseya could add support for removing patches from scan just like you can in WSUS/SCCM. This should make the scan process a bit quicker.