Systems Management Question

Patching issues after upgrading to 8.0

01/23/2018 2980 views
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. 
Answer Summary:
7 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.
  • I am having something like this on some of the PCs I have, I can't say 100% sure this start after the version 8 upgrade on the server and the agent, but I think it has.

    For me the kpatch.exe gets hung in the task manager for detect and deploy. so I have to do a end task on kpatch.exe, then it takes off and the kpatch.exe will come and go in the task list and finish the tasks. But when I do a detect or a deploy again I have to repeat this process.

    I have tried to uninstall and delete the quest folders under program files x86 and programdata, am I missing something.
    • I'm experiencing the exact same thing. The kpatch.exe process seems to hang, and killing the process seem to push it along. After terminating the process, the kpatch.exe process immediately starts back up, and you can watch the files chug along in the Quest\KACE\Patches folder. Definitely started after upgrading to version 8, and it's not all systems. I've tried uninstalling/reinstalling the agent, and deleting the computer in the KACE console, and still having the issue. Hope they can figure this one out soon.
      • Try setting the process timeout to 2 hours. That's what resolved the issue for us.
  • Having this exact same issue after running an inline upgrade to windows 10 1709 and 1803 (same issue with both versions). I run a detect/deploy job which left on its own will hang on a detect until the process times out. If I manually terminate kpatch.exe the job will start detecting everything like its supposed to and deploy/reboot only to get hung up on the first detect of the next cycle. If I kill kpatch.exe after every reboot I can actually get it to return a success. Interested to see if anyone found other solutions to this problem other than what has already been posted. Nothing seems to be working for me.
  • Just updated to 8.1, glad i'm not the only one. It takes 45min to detect ONE patch.

Answer Chosen by the Author

After weeks of troubleshooting, we pinpointed the issue to LM.Detection.exe taking longer in 8.0 than previous versions. Quest support recommended we up the process timeout to 2 hours in settings > provisioning > communication settings. Quest support team is still looking into why LM.Detection is taking longer, but for now, all of our patching jobs are succeeding. 
Answered 03/12/2018 by: anonymous_142269
White Belt

All Answers

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

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ