So I'm trying to check on a couple of new patches I approved by policy. Scheduled an automatic update and it looks like some patches were installed. I go to Patch Status and start a Test there to make sure everything is working. Here's where it goes pear shaped, it's been stuck on "Pending" for close to 24 hours now. This is on a 2008R2 server but I'm also seeing the same type of issue with a Win7 desktop. I ran an Initial Update on the desktop to test something and while the Initial Update says it's complete pending some updates that have to manually installed for some reason. The updates that it shows as Pending Patches are all normal KB that are not tagged as Manual Install on Internet Only in Kaseya.
Is anyone experiencing this? Trying to figure out if this is a degradation in Kaseya or a ticket worthy issue.
trevor.okazaki - I had a look at our windows 2008R2 machines with patching and there's no immediate trend suggesting there's an issue. I do see some problem machines we need to look at, but nothing stands out.
Beyond rebooting as a general cure and checking if the Windows Update is up-to-date and it works as expected locally I've no wisdom to share...
Trevor- We battled with this issue for quiet some time, opened a support ticket and provided some log files and did not receive an answer that resolved the issue.
At first we verified that there were no other pending actions that may be stuck processing which could cause a delay in the deployment. Next, we browse under Cancel Updates and selected Terminate to stop the pending patches. Reboot the device and allowed another patch cycle to start. This proved to be a small success with 1-2 machines but not all that had the ongoing problem.
In our case we identified that some Windows Updates were being triggered from Microsoft directly and getting "stuck" and the machine would not continue with any patching activity. These updates would fail causing the machine to continually request an update from the end users via the MS prompts and would attempt, fail and schedule for a later time. We made some changes to our policy to allow these updates to apply separately from our kaseya patching and we have not seen the issue reoccur.
Feedback from support indicated that they were aware of this issue and that they were not able to manage this aggressive update push from Microsoft.
Just to be clear, in our case it was Windows 10 devices that it was happening to. Just wanted to share our experience in case there was any connection.
That's what has me baffled. The desktop is a Win7 machine that I went through the first step in troubleshooting, reboot, thinking "ah it's probably stuck on a reboot prompt." I'm going to look at mikey090tx's suggestion of looking into cancelling some of the stuck updates. There's 4 that shouldn't apply to the desktop in question regarding Office 2016 (still on 2010 on that machine) to see if it canceling those will force it to move on to the next group of updates that are pending.
Looked into the Procedure Logs and found this gem "Patch scan check failed using primary data source with result 0x8024002e; Attempting patch scan using alternate data source" My Primary data source is online and enforced by Policy. Now to figure out why it's failing to verify the patch list from the online source.
Good news and bad news. The good news is I've figured out this isn't isolated to Win7, I ran a Patch Scan on my own Win10 machine and it's also getting the scan failure. The bad news is I don't know why. Two different firewalls (testing a new one), not on a VPN and strangest of all the 2008R2 server doesn't have the scan check failure.
Common between both the Win and 2008R2 is an error when running the Patch Status test "FAILED in processing THEN step 1, Write File, with error File or Directory Not Found, Source = D:\Kaseya\WebPages\ManagedFiles\..\install\curl.exe, Destination = D:\kworking\system\curl.exe"
Win7 has a D:\ but no Kaseya folder, 2008R2 doesn't have a D:\.
More fun to decipher!
There's a whole lot of information on this error code having to do with Windows Updates. I don't think it's related to Kaseya, at least that's unlikely. Kaseya fires commands at Windows Updates and something is blocking access for the machine(s).
It could be something to do with a malware attack that limits access, but I certainly hope not. A second option I found, had some info on the June 2019 updates breaking Windows Update. And any use of Antivirus / Antimalware could cause Windows Update to break as well.
It's getting more and more complicated to keep track and Microsoft is a big part of the problem. I also noticed seemingly unrelated patches being applied to machines that don't have a product installed the patch is supposed to patch. That also happens if you run Windows Update on the machine. So, enjoy the puzzle...
I'm also looking at this to either be a Microsoft related issue or a network one. Cylance wasn't listed as one of the AVs that were affected by the patch but it's not impossible that the patch did break it.
OudjesEric figured it out. It's a Microsoft problem and it's a pain in the rear to fix. I went through Microsoft's Fix Windows Update Errors and the solution involved renaming the SoftwareDistribution folder and catroot2 folder (more likely the catroot2 folder). Unfortunately to do the rename it had to be in Safe Mode. It would appear that the folders get recreated at some point during the process and it resolves the issue.
Telltale sign of the issue is looking at the Scan Machine section and each machine that I was testing on has an alert for Online as the source.
Now to figure out how to work this into a Kaseya procedure so I can deploy it across all the machines showing the error.
You shouldn't need to boot into safe mode to rename that folder, but you do need to stop the services which use them.
This would prob do it:
net stop wuauserv
net stop cryptsvc
net stop bits
Rename the folders, then start the services back up.
Trevor- I believe that this was already done, I don't recall if I got this from the automation exchange or other community resource.
executeshellcommand net stop wuauserv
executeshellcommand c:\windows\SoftwareDistribution SoftwareDistribution.old
executeshellcommand net start wuauserv
--- redeploy updates...
or execute procedure to do this if one was configured..
did not have this detailed but may add these?
executeshellcommand net stop bits
executeshellcommand net stop cryptsvc
mikey090tx I actually wrote my procedure that way and it's a bit more than that. Just having Windows rebuild that catroot2 folder doesn't fix the issue. I ran the Windows Update Repair Tool which unfortunately doesn't adequately list the exact changes that it's making. The tool does say at one point that it's checking the registry so I ran a registry compare and there are 637 entries changed so that's a ton of info to to through.
Hi Trevor, I also experienced a patch problem with failed patches on some machines. Getting the same error "FAILED in processing THEN step 1, Write File, with error File or Directory Not Found, Source = D:\Kaseya\WebPages\ManagedFiles\..\install\curl.exe, Destination = D:\kworking\system\curl.exe" "
Did some reseach and send a ticket too support.
I explained support there was something wrong here and it applied only to machine with more then one drive.
(As you notice it looks for curl.exe on drive D:)
Support come up with al kinda suggestions but I figure it out myself that when u use de Patch Mangement - file source with "To working directory on drive with most free space" it looks at curl.exe other then the drive where it suppose to be and then u get an error. Probely this is also related to why some machines not doing well on patching through Patch Management.
So i changed it to "To working drive/directory" and it seems to be working fine now (still testing).
Please let me know if you also see this issue and work around.
DataCees I came to the same conclusion you did with the setting "To working directory on drive with most free space" I also changed my policy to the drive Kaseya is installed on. In a quick test it did not change anything but it could be that I was testing prior to the policy reaching the computer I was testing on. Like you I'm testing and waiting to see the results on that particular error.