/build/static/layout/Breadcrumb_cap_w.png
07/25/2018 482 views
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

Comments

  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.


Community Chosen Answer

3
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.
Answered 07/25/2018 by: ondrar
Second Degree Brown Belt

All Answers

2
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.
Answered 08/01/2018 by: DaveMT
Fourth Degree Black Belt