We have recently upgraded our K1000 and agents to 8.0. Since then, we are getting errors during our patch jobs. It occurs on both detect and deploys jobs (they run separate). Seems like what is happening is the detect job times out, even though we have it set for time out of 5 hours, and then the kpatch.exe process stays running afterwards. The next job, the machine will report either a log upload fail or handshake error. I can kill the kpatch.exe process and the job will then run again, but sometimes it goes into the loop again with errors, sometimes it succeeds. We did not have this issue with version 7. Nothing has changed in our environment, and no other process are running with the K1000 during patch jobs. I have a 3 week old ticket with support, but they do not seem to know what is going on either. Just wanted to know if anyone has seen similar occurrence or have insight. 
4 Comments   [ + ] Show Comments


  • We experienced issues after upgrading to KACE 8.0 as well. One big thing we had to do was get an updated License from Quest and that resolved most of our issues.
    We did see timeout issues as well when the agents would report back Error in the failed status. Turns out they were completing even though they reported Error, they just failed to report back during the timeframe is why the Error occurred. Increasing our time to 5 hours did correct most of those. The systems we got errors with Handshake Failed or Log upload failed I was able to resolve by setting a script to stop the ampagent, purge the Patches folder under ProgramData\Quest\Kace and then restart the ampagent. This forced the agent to reobtain all patching files. A refresh of the patching essentially. Another thing to watch for is to ensure when it upgraded the client again to 8.0, that is did in fact purge the old Dell folders (C:\ProgramData\Dell\KCE & C:\Program Files (x86)\Dell\KACE) from the system as well.

    Here is the batch commands I setup in a script to purge the Patching files from the local PC:

    net stop ampagent
    rd C:\ProgramData\Quest\KACE\Patches /s /q
    net start ampagent

    After the script run, do a detect on that PC and it'll take a while, but should repull down the needed files.
  • I'm experiencing a similar problem. The past two nights, I've run detect & deploy jobs on 90 and 60 servers, respectively. Both nights saw massive numbers of "error (log upload failed)" failures reported. In most cases, the systems had been patched successfully, but they failed to report back to Kace properly.

    II've got a support ticket open, but the first suggestion of verifying that antivirus and monitoring software is excluding the Kace paths hasn't helped. We're already doing that, and these patch jobs are the same jobs we've had for years. This is just the first month of server patching since upgrading to version 8.
  • I think I've found the cause of the problems at my site, but we still don't have an ideal solution for it. Long story short - our agents are reinstalling themselves every time group policy refreshes.

    We have a GPO created with the GPO provisioning tool, and everything is configured as expected. It worked fine in the 6.x and 7.x days, but it's broken under 8.0 for us. Brand new GPO, current version of the tool, no other GPOs that install the agent, nothing on the server that would provision or update the agent.

    As soon as I run gpupdate, the agent reinstalls. If I disable the GPO, the problem goes away.
  • Seems like the issue for us is LM.Detection process getting hung up. I've noticed on my machines that have log upload fails, I see LM.Detection stays on for hours. If I go in and end LM.Detection process, patch detection them resumes as normal. Not sure what can cause LM.Detection to get hung up. We have whitelisted KACE directories in AV and firewall as suggested by support, but we are still having machines fail.
Please log in to comment


Not sure if this is the answer, but are your agents/devices able to resolve the FQDN of your KACE SMA in your DNS? As that may cause communication issues a bit like this. Also with the switch to the KONEA agent the agent changed communication to port 443 only regardless of if you has SSL set on your SMA or not, so making sure ports are open as well may also help.
Answered 01/24/2018 by: Hobbsy
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity
Nine Simple (but Critical) Tips for Effective Patch Management
This paper reviews nine simple tips that can make patch management simpler, more effective and less expensive.