I have been daily patching a bunch of machines and I've discovered a nuisance that apparently halts patching. Is there some patch that we need to approve or is there possibly a script that we could run? I'm pretty sure this is the culprit for keeping my fully patched numbers lower than they should be. Just wondering!
and every machine that wasn't fully patched (that I was able to jump on) has the same message. I've had these machines patching daily for weeks, and quite a bit of them are apparently getting stuck at this, therefore they are not patching.
Microsoft is slowly rolling out an update to the Windows Update Agent, similar to a controlled release. Kaseya hasn't yet received this update, and we've been watching for it to be released in the wild so we can attempt to get it out to all customers as soon as possible. If you can open a ticket and send me the ticket number, I'll touch base with you regarding this - we can review the data that's being returned by a few of your endpoints based on the patch scan to determine whether Kaseya can proactively make this patch available before MS full release. That isn't to say that the update from Microsoft isn't "fully baked" - it is. Rather, MS is just trying to prevent all systems from updating at the same time. But if we can get sufficient data from the scan results of endpoints that are already reporting the need for this patch, we may be able to 'bump' Kaseya users to the front of the line to get this update.
CS111890
Let me know what else you'd like me to retrieve and I will do it!
I'm surprised no one else has joined this thread. I guess you haven't realized you are affected yet! We are still in the process of finding a workaround to keep patches flowing to endpoints.
I am trying to do a manual update with this script; still in testing mode; anyone tried this yet ?
Kind regards,
Sloeber70
iVITa Admin at eurosys.be
we typically patch twice a month...once for pilot and then once in third week of month...so I expect to be screwed soon...
We've had the same issue last month. I was the unfortunate person to install the updates for our customers and installed this update manually no the required servers(yes, it was a very long working sunday, and we didn't have to install it on all servers).
@SLoeber70: I'll try to use your script tomorrow and let you know about the results. We still have some servers waiting for this WUA update.....
Walter - Who is general failure and why is he reading my harddisk?
Just a note on this Update WUA script;
It is downloading a file from the Kserver that was uploaded to a custom path by the author of this Agent Procedure and therefor will be of no use to you unless you find the same Windows Update Agent files and upload them to your Kserver.
There is no standalone installer of the latest version of the Windows Update Agent (7.6.7600.256).
Source: support.microsoft.com/.../946928
I'm logging a ticket with Kaseya now hopefully we can get them to give us a solution very soon for this as this is a pretty big deal and could cause us to lose customers.
Great so I get the same message from the support team that Brande gave you guys 12days ago. In the meantime I have machines that are not going to get patched.
its been a sandcastle lately. i hope things get better soon. a lot of the core features are losing their sparkle.
Maybe they are gearing up for a new Kaseya module to deal with Patch Management :D
Only $0.99 extra a month per agent :P
I've been looking into this a bit this week and have found one machine that has installed the latest Windows Update Agent automatically, and that's one of the servers we use as a source for other systems. There were 3 event19 messages, all stating something similar to "Installation Successful: Windows successfully installed the following update: Windows Update ActiveX", with the last word being different between the messages. After it installs the update it reboots, then continues with downloading updates.
Other systems are then able to pull those updates and install them, but they do not get the Windows Update Agent updated.
Still doing some testing, but thought i'd share my experience.
I, too, am finding that on a number of machines with Kaseya patch failures, they are in the "need to update Windows Update" state. I haven't tried just updating Widnows Update, then leaving Kaseya to do the rest though--by the time I'm in Windows Update, I might as well just click Install.
All,
Kaseya continues to actively work to find a solution to the requirement for the Windows Update SelfUpdate. While we are still hindered because Microsoft has yet to release the appropriate utilities to allow third parties to trigger the SelfUpdate, we have identified some potential options that may lead to a successful SelfUpdate and/or allow patches to install that are failing specifically due to the requirement of the SelfUpdate.
KKB000904 has been posted to outline the issue, provide potential options for addressing this, and communicate our plans for additional solutions.
Thank you,
Brande
Hi,
Some machines displayed a popup when patching, is this related to the WUA Update ? Is Kaseya distributing the update when a patch schedule is triggered.
Dis anyone see this too ? See attached screenshot.
Hans
K Support: What is the quickest way to determine if patch failures are caused by this issue?
Thanks.
Connect to any machine that is not fully patched and trying running the updates manually. If it prompts you to update Windows Update before showing you any patches, then it was being blocked.
Thanks, Dan.
For clarification, if a machine is affected by this problem, are the patches reported as failed or simply missing and they don't attempt to install?
I've created the script as explained in this post, and it is working fine, option 1, but you have to reboot the system, if not, the agent popup appears.
see attached xml's. It checks first if the update is already done by checking WindowsUpdate.log for the current version; if not OK, it runs the update, and individul logs are created in the agentworkingdir; all agents also log their status on the patch location, delimited file, you can import this in excel.
Feel free to use.
Sloeber70,
Very nice script - thanks for uploading it!
I'm trying to import it at the moment, but there's another script referenced in step 2 with the ID: 1631542570
Could you please let me know what this other script is so that I can link it correctly? I'm assuming that it may be a reboot script, but want to make sure I'm not missing anything.
Thanks again,
Simon
@Simon,
You need to point to the second script, which is also included in the zip.
There is a reboot in the first script, but it is disabled, if you want a reboot scheduled in 2 minutes after the self update, with warning msg to the logged on user, then you need to enable this.
Thanks @Sloeber70
In the first script, I’ve already pointed it to the second script.
In the second script, there are two references to a third script – this is the one that I can’t find…
Sorry, did not see that.... I am launching there an immediate patchscan. System script : 269
eperson, they don't fail. They continue to show as missing, unexplained. You will see in the logs that the patch process is working, but the patches just don't get installed.
@Sloeber70 - good idea! Now, I know how to find out what the system scripts are doing, but how do I schedule one in another script?
this is the procedure you can use - just point to this one
System scripts : you have to make those in XML first, and then just import them.
Regards,
I've found a source that has created unofficial versions of the standalone installer for Windows Update Agent (7.6.7600.256) and have successfully rolled this out with some Kaseya procedures.
This took considerable effort to test to my satisfaction and I found that on Windows XP and 2003, code-signing requirements caused issues when running the unsigned installation package as 'system', so I developed a workaround for this using a signed version of the update package when no user is logged on for XP or 2003. If your XP users are not administrators, you may want to modify the procedure slightly to always roll out the signed update package for XP / 2003. The code-signing requirement doesn't seem to be a problem in Vista / 7 / 2008.
I have attached a zip containing the procedures and a note about the extra files you will need to run them.
Let me know if you need further explanation, and I hope this helps - there is no way I'm going to log onto thousands of endpoints to fix Microsoft's shortcomings! :)
Combo
We're starting to be affected by this issue, and getting concerned that theres no regular update from Kaseya. As such I will assume the worst and not expect it to be resolved for a while. As such, I need a way to identify the machines that are requesting the Windows Update agent to be updated to 7.6.7600.256 and if required update them manually. I cant have machines not being patched - period.
Does anyone know of a reliable way to identify PCs waiting for WUA to be updated?
Thanks in advance
David
Kaseya Certified Administrator
I looked into how you can detect if the if the WUA needs to be updated, I found that the current WUA version can easily be detected by checking the version of the "%WINDIR%\System32\wuauclt.exe" file. During my investigation I found that the machines with this update issue already had the updated version of the wuauclt.exe file.
So if you find that the %WINDIR%\System32\wuauclt.exe version is 7.6.7600.256 and the target machine has not patched in in the last 1 week to 2 months then its a good possibility that the machine's WUA needs to be "fixed".
Hi KardKnox
I checked on one of our machines thats got the issue but its wuaclt.exe file is version is 7.5.7601.17514.
I also found one that was on version 7.4.7600.226 reporting WUA update required, very confusing :(
From the KB and this forum post I am guessing we are still waiting for a final resolution to this?
I've resorted to manually updating agents....the scripts posted above are just too complex and awkward, and then the 'third party' installers referenced don't work anyhow.
Theres all sorts of hassles with Windows Update at the moment. WSUS needs a patch to support Windows 8 clients and the latest WUAU client code, for example: blogs.technet.com/.../wsus-support-tip-warning-skipping-scan-self-update-check-returned-0x800b0001-in-windowsupdate-log.aspx .. except that the patch completely breaks WSUS most of the time! fixes for broken WSUS here: blogs.technet.com/.../wsus-kb272011-common-issues-encountered-and-how-to-fix-them.aspx
Microsoft have had to overhaul the patch update process to make it more secure, since the flame malware exploits it. blogs.technet.com/.../further-hardening-of-wsus-now-available.aspx
The ramifications for Kaseya are great. My guess is that MS is forcing clients to get the version .256 WUAU updates from them direclty, to ensure that clients receive valid, genuine certs & code, and not more flame-infested malware....this is also why they haven't released the WUAU code as a standalone hotfix - if they release a stand-alone, it gives hackers everything they need to fabricate a new generation .256 version bogus update engine, and the same problem simply repeats itself.
The .256 patch itself is a mess. I've had most of the XP boxes I manage get stuck in a 'checking for updates' infinate loop when visiting microsoft update website affer applying .256. Its horrible. The fix for me so far, is to browse to http://www.update.microsoft.com from the client, and get at least as far as the "express" / "costom" check ofr update screen. If you can get this far, you sould have a working .256 engine, and all is well.
NB: If the XP client doesn't have WAUA version .256 installed, patch KB2656370 won't install.