3 Replies Latest reply on Dec 13, 2018 7:01 AM by phoffmann

    Delete Duplicates - How to Merge Records

    ASelby Rookie

      Currently running Ivanti Management Console

      LANDesk Software

      Data Analytics 10.3.1554


      We recently found that our Scheduled Task for Deleting Duplicates was not running properly, so we recreated and tested.  Now previously stored data saved in the Stub record (Created when device is first scanned upon Receipt) is not merged into the final record after Provisioning.

      The data was retained previously.  What are we missing?


      In the Delete Duplicates Script in Database Doctor, the attribute to determine uniqueness is Computer.System.Serial Number

      Most recent date is set to Computer.Record Creation Date


      Any thoughts?


        • 1. Re: Delete Duplicates - How to Merge Records
          phoffmann SupportEmployee

          We don't "merge" device records.


          We use THIS process here -- About: "Devices" and "Duplicate ID's" option for Inventory, and how they work  ... at a guess, you / someone changed something in the config?

          • 2. Re: Delete Duplicates - How to Merge Records
            ASelby Rookie

            Thanks for the link.  I checked through all of that, and all appears to be correct.  But if records are not merged, how does information from the stub record get included in retained record, as it has for the past several years?

            • 3. Re: Delete Duplicates - How to Merge Records
              phoffmann SupportEmployee

              So the way it works is essentially like this for the provisioning-scans.


              • Those device entries do not tend to have a DEVICEID (a SID-like "unique identifier") value.
              • Instead they have a MAC-address and/or a Serial Number to go on.
              • When we get a "full" inventory scan, we try to check the database to ensure "Hey, do I know of this MAC-address / Serial Number already" (through those "stub records" as you call them) ... and if we find a match, then we update that records with the "full" inventory scan data (so now it has a device ID and such).

              • By the same token, a "stub" inventory record only contains a MAC-address, so it's based on THAT that the Core tries to marry it up to an existing device by trawling through all known MAC-addresses.
              • You can turn on this option -- How to enable the Inventory option Store Scans on the Core Management Console -- to easily store any incoming inventory scan "stub" or "full" or otherwise), and look inside them (and - crucially - EDIT them if you want/need).
              • Now, there's a possibility that due to changes (in either hardware or our stuff or whatnot), something is causing the matching logic to not work / have a proper "hit" on marrying up the reccords for some reason ... and having files that you only need to copy / paste into the LDSCAN folder for re-processing can help you understand what is / isn't going on.
              • If need be, you can open up a case with support (and they can have a look at things with you) to try & help you along.

              ... does that help / make sense with how things should work?