K1000: How to best track inventory/assets when a hard drive is moved from one machine to another?
Example: You have laptop with a broken screen and move the hard drive to a replacement computer.
We have this situation come up often enough and I assume others do as well so thought perhaps someone could offer some advice. It seems as though if you are not careful, you can end up with duplicate Inventory and/or Asset items in KACE...and not keeping up with it can create quite a mess.
We use an asset tag for our systems as part of the hostname so in the above scenario, you have possible asset/inventory items for the following:
1) Computer A with broken screen: Hostname= Comp1
2) Computer B with original hard drive: Hostname= Comp2
<drive moved from Computer A to B>
3) Computer B with hard drive from computer A: Hostname= Comp1
<rename computer B to match Asset tag>
4) Computer B with correcte hostname: Hostname= Comp2
<Comuter A gets repaired, HD from computer B installed>
5) Computer A with corrected hostname: Hostname= Comp1
Granted, unless KACE does inventory after each change you don't end up with 5 separate inventory items but it still gets messy.
Answers (4)
Starting from the very beginning:
AMP Connection logic:
0. Agent creates a new KUID in the install process.
1.Agent makes an AMP connection, presenting a KUID, machine name, bios serial number, and some other information. If AMP dedupe is on, it checks to see if the same KUID is already connected from a different mac address. If it is, the server tells the agent to go away and create a new KUID and amp goes back to step one.
2.The server checks for a machine in inventory with the same KUID. If it exists, the last connected is updated, and the IP address is set to the current amp connection. It will get an inventory command if it is over due on the task queue, otherwise, it will stay connected and get the inventory message at its scheduled time.
3.If no machine in inventory matching the KUID, amp gets a message to do inventory, the agent boot straps kbots if needed, and will post inventory back to the server.
When inventory is received by apache:
1.Checks to see if there is an inventory record in the MACHINE table for that KUID. If yes, it updates inventory.
2.If no match on KUID, it checks for a match on Machine Name and BIOS Serial number. If there is a match, it updates inventory, and sets the inventory KUID to the KUID that the agent presented. REMEMBER that KUID is guaranteed to be unique, but it is not guaranteed to be perpetual. It is not the unique ID used in the inventory, the unique ID is MACHINE.ID.
3.If no match on Name and Serial No, a new machine record is created (you will see this in the server log).
**** NOTE that duplicates show up here if the machine name has changed. If the machine is not named the same, you must make sure to apply the original KUID in order to avoid creating a duplicate MACHINE record in inventory.
When inventoryTHEN Computer Asset Mapping logic comes in.
1.Once a machine inventory is processed, the server looks to see if there is an existing MAPPED Computer Asset. MAPPED means that there is a Computer Asset with the MACHINE_ID in its MAPPED_ID field. If there is an existing mapped asset, it adds all of the deltas in inventory to asset history for that Computer Asset.
2.If there is no existing Computer Asset with a MAPPED_ID field that matches MACHINE.ID, then it searches for an UNMAPPED Computer Asset (meaning a Computer Asset that has 0 in its MAPPED_ID field) that has a matching value in the mapped field set in Computer Asset Type detail screen. By default this is by Name. MAPPING LOGIC IS NEVER RE_EVALUATED once the asset is mapped by MACHINE.ID to a MACHINE record in inventory. The upside to this is that if the mapped field value changes (say new computer name) it will remain mapped to the right asset with all of its history. The downside is that the value of the mapped field is not updated, so the Asset will continue to have the old machine name, even if the inventory is presenting a new machine name. For this reason, best practice is to change this mapping logic to BIOS Serial No before you start populating inventory. ****** This is where duplicate assets show up. If we have a duplicate computer created by logic above, the new duplicate computer will not match to its asset because the asset is still mapped to the original inventory, so a duplicate computer asset will be created. There is no easy way to clean this up and retain asset history. One thing you can do, If you delete the MACHINE record, the MAPPED_ID field will be reset to 0 rendering the Computer Asset unmapped again, so next inventory, it will get remapped based on logic in mapping fields.
After digesting the excellent response from hmoore, I am going to experiment with setting Disable Duplicate Machine Detection to CHECKED. Also, I think I will change *when* I am installing the KACE agent to prevent new inventory items from being created. I already have a script that checks for a hostname that matches our naming convention before installing the AV client so will probably add it to that. Or I may experiment with creating a separate Scripted Install for systems that are being re-deployed. Finally, I wish had read the following:
" For this reason, best practice is to change this mapping logic to BIOS Serial No before you start populating inventory. "
......when we were first deploying KACE. Good advice indeed, IMHO.
I try to sysprep when at all possible before moving hard drives from machine to machine. If you can't do it before-hand you could always do it afterwards. It's just a nice way to remove all the unique fingerprints of the old system from the OS install. You'll get a new Kace record and can manually delete the old.