Scripting : Inventory 'Falling off' K1000

Inventory 'Falling off' K1000

Hey Guys,

Has anyone ever come across an issue where computers either fall off Kace (probably after a period of inactivity) or are in Kace but never check in? (Even though the machines are in use and online/Force Inventory doesn't do anything) I have only recently taken over managing the Kace Appliances and am trying to be more vigilant in terms of managing the agent updates when they come out. I don't think the agents were updated often enough in the past.

In most cases we confirm the check-in post image deployment, so somewhere along they line they drop off. In a lot of the cases, the agent is already installed and some cases the agent is up tp date. Has anyone come across this or stumbled upon anything that may cause this to occur? Are there any preventative measures to take to ensure agents

Note, since I've taken over I've been using the K1000 built in script to update the agent and not a manually created one. Mostly Windows 7 machines but are moving to Windows 10 soon and want to proactively prevent this.

Thanks

3 Comments [ + ] Show comments

We have recently come across this issue as well while we were in the process of preparing for the version 8 release of the K1000. The devices aren't being removed from the Inventory but they aren't checking in and the Force Inventory doesn't always work. Our agent versions are ranging from 6.2 through 7.2

We currently have an open ticket with support regarding this issue but what we have been seeing is the Agent Command Queue being flooded with resets. We have been able to clear out the tasks under Agent Command Queue and then we are able to have some devices update to the latest version. However the queue continues to fill up within hours of clearing. The last update from support was having the engineers look into the issue. - RyanPersaud 7 years ago
I have also had this issue a couple of times in recent months. It has been rare....only about 10 machines .....out of 1500 pc's. But still a source of concern. Would like to know the resolution from your ticket with Quest. - akmagnum 7 years ago
- Submitted a ticket with Quest also and they gave a few things to look at, specifically mentioning KUID, similar PC names, etc. The below specifies duplicates, but they mean that more up to date entries fall off because they share unique information with another device:
  
  Quest Update 1:
  Thank you for the information provide, yes this can be see if the system share part of the same information like name, kuid, mac address, etc K1000 will identify one of the two system with the message BAC_MAC_IP and you will see the condition that one system connect and one does not, please let us know if you can identify one of the systems that continuously see it disappears from K1000 in order we can gather a kapture state for review in this case.
  
  How to Use the KACE Kapture State Utility for Windows (Legacy 7.x and older) (116144)
  https://support.quest.com/kace-systems-management-appliance/kb/116144
  
  Thank you,
  
  Quest Update 2:
  Thank you for the update, the below document is for reference for duplicate machines on inventory
  
  Understanding and dealing with Duplicate Machines inventory (125175)
  https://support.quest.com/kace-systems-management-appliance/kb/125175
  
  This document is in the case the K1000 logs shows the message of bad mac ip
  
  BAD_MAC_IP – Provisioned Devices Not Populating Inventory (129683)
  https://support.quest.com/kace-systems-management-appliance/kb/129683
  
  Thank you, - maherfed 7 years ago
  - We had previously been running the report to find duplicates and clearing them from the system if it was correct. They also had us run the Kapture State Utility and upload the logs for them to check. We currently have a tether open to Quest for them to look at the system.
    
    One thing that we have been able to do although it isn't a fix but a temporary workaround. Since we are in the process of segregating our Servers from the rest of our staff/faculty and lab devices into their own organization. We logged into the System side and moved the server devices. The Servers that were showing online but hadn't checked in re-registered and did a check after being moved into the Server Org. This has allowed most of the server devices to show correctly with the exception of about 15 devices that are currently stuck in limbo. - RyanPersaud 7 years ago
Thanks for the update - how do you run this report? I assume this is a preventative measure rather than a remedial seen as the agents can't be reached if not checking in or fell off Kace? For a while before I took over, the agent was no installed as a post task so I think this worsened the issue due to many devices having the same Kace ID. However, we have noticed some new devices not checking in.
I'm going to get a script going that our admin can add to AD to try and force an inventory for some of the machines. - maherfed 7 years ago
- It was based off the report from Quest: https://support.quest.com/kb/125175
  
  You are correct in that it is more preventative but if you look at the section under 'Cause' it lists the method it narrows down by. For us we had very few that had the same KUID. A lot of the devices on our list had the same name which was a result of older devices being replaced by newer models. Under normal circumstances this should have already been purged and would not be an issue. - RyanPersaud 7 years ago