/build/static/layout/Breadcrumb_cap_w.png

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.

 

 


0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
Posted by: hmoore 11 years ago
Second Degree Blue Belt
7

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.

The Focus above is “Disable Duplicate Machine Detection” ( DDMD )is unchecked (default).   
 
However, the superior method, for 99/100 customers, IMO, is to treat the KUID as an authoritative, global unique identifier and set the DDMD to checked.
 
Then you get the following benefits:
•all the highlighted below is true
•duplicates are impossible on existing KUIDs in inventory.  Saving customers whose machines connect/ disconnect quickly (ie laptops switching from wired to wireless).  KUIDs will update the inventory record with this KUID connected or not.  A simple alert can notify customer’s if more than one machines are erroneously sharing a KUID. 
•Customers must not re-use KUIDs for this to work. If they are they have a broken imaging process that should be fixed anyway. For existing problems just deploy the “ reset KUID script”
 
Why is DDMD=checked not the default?  Well it was the only method until AMP came along, but when AMP came along we decided to try to save customer’s from themselves but we didn’t anticipate the quick-switching above.    
 
After a questions from last week about this I’ve decided that DDMD=checked should be the default because it’s easy to cleanup any issues with the reset KUID script.
 
With DDMD=unchecked you can easily run into duplicates and recovering from duplicates is a PAIN IN THE ASS because the asset record you want is never tied to the inventory record that is now valid. 
 

Comments:
  • Wow! Very helpful. I haven't digested it all but pretty sure that's what I need to make a plan going forward. Thanks much! - etipton 11 years ago
  • How do you set up the amp dedupe option? I must be blind that I can't find it.

    thanks! - sharonk 11 years ago
Posted by: etipton 11 years ago
Second Degree Green Belt
1

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.

Posted by: etipton 11 years ago
Second Degree Green Belt
0

<deleted>

Posted by: jegolf 11 years ago
Red Belt
0

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.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
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