Systems Management Question

K1000 7.0 agents not completing inventory

12/14/2016 6185 views
I have a large number of machines that have the agent installed, but will not check in.
I'm running the new 7.0.121306 server and the 7.0 agent. 
These are all machines that were installed and working fine with the previous server and agent combo.

I have uninstalled and reinstalled the agent through provisioning and through manual installs with the same result.
The files are on the machines and I can run the inventory manually, but it never actually updates or shows a check in on the server.

I can see the Konea process is running, but not sure what else to look for there.

Any ideas?
12 Comments   [ + ] Show comments


  • Can you check the KAgent.log file for any errors on the machine where agent is not checking in?
  • I did a search for the word error in the log and nothing turned up. Good idea though.
  • Have you tried stopping and starting konea? We've been having a similar (same?) issue where everything is installed, can manually run a check-in (runkbot 4 0), and the service is running, but it won't inventory on its own until the service manually restarted.
    • The service or the process? Or will the process die and come back when the service is restarted?
      • The service. "sc stop konea" >> "sc start konea"

        From some quick testing It looks like the process stops and starts with the service.
  • I just ran kinventory and inventory and then restarted the service but still no connection to the server.
  • check the logs under:
    The K1000 7.0 always connects to port 443 (the linked error message should be seen in the logs) instead of 443 or 80.
    So if you blocked this port no agent can connect.
    If you have trouble analyzing the logs contact support or copy the nessesary logs here.
    • Good theory, but it's not all machines. It's hit or miss at all of our branches. Thanks again.
  • So I put in a ticket with Dell > quest's support team. They said they are aware of the situation and they plan on having it fixed in the next release. Until then it's advised to remove the the Agent and use a GPO to install an old version. Here's the link to the old agent;


    EDIT:: So i realize that the link provided is the kbin file. This file needs to be uploaded and applied to the k1 in order to get the 6.4 msi. To do this go to the k1 > settings > provisioning > update agents > manually upload agent bundle. Before doing this i recomend saving the 7.0 agent from \\k1000\client\agent_provisioning\windows_platform\ampagent*.msi just in case. I wish i had done this prior to downgrading to Agent 6.4. You can try provisioning an uninstall as an MI and use a GPO to deploy the 6.4 agent.

    I'm still in the process of this downgrade so this is all the advice I can offer right now. If anyone went through this same issue and fixed it, please share your process.
    • Much appreciated Sir.
    • Thanks for the details. Sounds like need to wait for next release before it's ready
  • Sound pretty typical for DELL or whoever they are now. So many issues with this system!
  • can you use the 6.4 agent with the 7.0 kace version? let's say i upgrade to 7.0 but not the agent.
    • Yes you can and that is exactly what I've done.
  • Can you tell us the exact version number of the agent that has this problem? Version 7.0.763 is available now but I don't know if it has the bug you described, or if it's the "next version" where it's fixed.
    • That's the version but it seems like it's only on a specific model of computer that we have. The rest of our fleet eventually came through.
      Our majority of machines are Dell's but we have one branch that is Lenovo's. The Lenovo's are the ones that are only communicating with the older client.
  • I just tried the method of downgrading a few to see before deploying to my whole fleet, and it's still not checking in with 6.4.522 agent... I'm at a loss..
  • UPDATE: Contacted Quest and have applied a hotfix to the Kace server to address this. Waiting to see. Will follow up once I see results... (older) -We are seeing the same. Clients, both 6.4 and 7.0 are not connecting at all. Have tried starting and stopping service and uninstalling and reverting back to 6.4 on a test batch with no results.
    • We are having the same issue. I opened a ticket with Quest several weeks ago but we were not offered a hotfix. Can you provide any details on the hotfix?
      • Called Quest last week and received a patch called kbox_patch_K1-19139-v2.0. This has helped with the check-in rate, now we are having issues with a good number of clients not completing inventory. They are having me run the following from the Kace working directory:
        kinventory.exe autorepair (run this 3 times)
        AMPTools.exe retrust
        AMPTools.exe restart
        Runkbot 4 0
  • I am experiencing the same issue. Most of the clients will check in, but the inventory process (if it works) takes a ridiculous amount of time. I do have a couple of clients that will not check in period. I called Quest will little help. They are researching. We are on server 7.1.149 and running agent 7.1.62.
    • Hi tgrinnell,

      I have the same issue as yours.

      We upgraded server to 7.1.149 a week ago and only about 10% of agents upgraded to 7.1.149.

      Inventory is intermittent.

      Did Support find an answer ?

      Thank you.
      • Hi there. No, support was not able to resolve the issue. They stated it was most likely our virus scan (SOPHOS). However, that does not make sense. We've used SOPHOS every since we've had the K1000. Eventually, inventories started working again, but I'm not sure what caused it. Keep me posted on your situation. Good luck!

Be the first to answer this question

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