Kace Patching Handshake Errors
We have been having problems getting Kace to patch our endpoints for quite some time now. Support hasn't been able to come up with a solution, and we are getting concerned about security since so many computers have missed months worth of updates. One of the main issues we see is consistent "Handshake Failed" errors. We have used the logs to narrow this down and determined that it is because Kace is unable to unzip the "thirdpartypatchfiles80_x64.zip" file:
[2018-07-25.07:35:27][KPlugins(9684):KWeb::DownloadUsi] DownloadFile: Downloaded C:\Program Files (x86)\Quest\KACE\thirdpartypatchfiles80_x64.zip from [servername]/patches/windows/thirdpartypatchfiles80_x64.zip Download speed: 10601344.000000 bytes/second
[2018-07-25.07:35:27][KPlugins(9684):ParsePatchFile::U] pluginPatching: UnzipToDir 'C:\Program Files (x86)\Quest\KACE\thirdpartypatchfiles80_x64.zip' 'C:\Program Files (x86)\Quest\KACE\' failed
[2018-07-25.07:35:27][KPlugins(9684):ParsePatchFile::D] pluginPatching: DownloadPatchEssentials: failed to unzip 'C:\Program Files (x86)\Quest\KACE\thirdpartypatchfiles80_x64.zip'
When we look in this directory, the .zip is indeed there, but it is actually listed as thirdpartypatchfiles80_x64.zip.checksum (possibly the .checksum at the end causes Kace to think the filepath is incorrect?) From what I understand, Kace uses the SYSTEM user for this process. SYSTEM has full control over the KACE folder and the patch file itself, so it doesn't seem to be a permissions issue. Does anybody have experience with this happening? Any suggestions for fixing it?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
ondrar
5 years ago
For what it's worth, when I have any patching errors, including handshake failed, I have the entire contents of the computer's C:\ProgramData\Quest\KACE\patches folder deleted, so that next time a patching job runs, that computer gets a fresh copy of everything.
Maybe it's a bit heavy-handed, and maybe it can be done more eloquently, but I have success with it.
I say "for what it's worth" because I haven't checked out the logs to see what the exact errors are, so it may not work in your case, but it might, too.
Posted by:
DaveMT
5 years ago
We do the same thing ondrar mentioned (Even have a script written to clean out systems that are giving failures).
One thing we have also learned with patching is the need for restricting the time frame for patching. Our "Monthly" will only detect and deploy patches for the past 3 months (2 month overlap each month), and we have a separate patch schedule to full scan and patch systems imaged less than 24 hours. Having systems detect and deploy patches for over a year (in our case, we did all patches needed) each month, we found that patching took sometimes over a day to complete and we got a lot of errors including "handshake error(s)'. Changing the schedule up made a world of difference in our patching success.
Comments:
-
If i may slightly necro here...
You simply added a variable to the patch smart labels that the patch should only be 3 months old? In theory, would not having the variable "Missing is yes" do what you need, since if patching is working all the needed ones are applied and thus are not missing?
(I am getting this error, and my patching has labels based on OS and further by bit factor, so I should not be getting, say, a Win7 x64 that is "missing" a Win7 x86 patch. I don't know if adding the Age variable is going to be worth my effort if the Missing is yes will do what I need.) - Theswerd 5 years ago
