2 Replies Latest reply on Apr 19, 2016 9:49 AM by kbrooks

    Duplicate Devices useless

    kbrooks Apprentice

      Does anyone have a good solution to have LANDESK automatically clean up duplicate devices? Using device names and MAC addresses does not work, as the device names can change if a system is rebuilt and using a different name (x86 vs x64 for example). The MAC address is also pretty useless as sometimes AnyConnect will take over and report a virtual MAC as the primary binding and so it will detect separate systems as duplicates. What would REALLY make sense if they gave you the option to check for matching serial numbers. You know, something unique to a system that won't change if it gets renamed, or connects through WiFi instead of a wired connection....

       

      Currently I have to export all devices to a spreadsheet, highlight duplicate devices, then go through one by one and remove the old device names. Of course, that means the audit history doesn't get merged into the new one.... I'll be honest, the company is becoming quickly dis-enchanted with LANDESK, and issues like these are just another straw on the camel's back....

        • 1. Re: Duplicate Devices useless
          MarXtar ITSMMVPGroup

          Hi, I can understand your frustration but the methods provided do their best with what is available.

           

          However, even using your serial number suggestion you would encounter issues if you ever had systems that didn't have a serial number (they would all be classed as duplicates) or had 'To be filled by OEM' as some third party devices have, or even when an engineer replaces a motherboard and forgets to transfer over the serial number info (as used to happen a lot with Dell in the past). LANDESK has a mechanism that many other products lack and tries to use an unusual condition (Name AND MAC address changing at the same time) as a trigger to detect a duplicate. These two values MUST exist on a device and NORMALLY would not change simultaneously. Serial number doesn't have to exist and therefore is even less trustworthy. Sure, LANDESK 'could' improve the functionality a bit further and please add ideas into the enhancement request section, but it can help to recognise that this is in part a condition created by your own processes and other vendor solutions (sharing MAC addresses or a different build process) but that your expectation is that LANDESK must be able to handle it alone.

           

          To summarise, the current mechanisms allow duplicate detection due to Device Name change, OR MAC address change OR Both changing simultaneously. In many environment one of these combinations would work. Your environment has the unfortunate situation where two things are combining to make this less than ideal; you can change a machine name AND you have a solution that means we can't trust the MAC address.These are external factors so far that are outside of the products control BUT.......

           

          OS Provisioning provided by LANDESK has a method of keeping the Unique Device ID even after rebuild whether or not the device has been renamed. Is an external rebuild process being used? If so, then that is also contributing to the creation of duplicates when the LANDESK method should create a duplicate at all. Duplicate Device detection aims to help clear up after an external mechanism has created the issue.

           

          Probably not what you want to hear, but I would suggest you consider adjusting your internal processes when related to the renaming of a machine during your build process. 'Someone' is deciding a machine must be rebuilt AND renamed, so at that point that someone could also look at cleaning up the duplicate (or requesting it to happen). You are correct that it doesn't merge the audit trail but that is the point where the process breaks down. Consider what is preventing the use of the LANDESK method that would keep the identify of the device throughout the process and merge this audit history? Also perhaps consider if it makes sense to keep using bit-levels in the computer name.

           

          Sometimes just because we've always done it that way doesn't mean we should continue. Of course there may be a vital business reason why you must do that (such as another product that relies on it) but reconsider if it makes sense.

           

          This doesn't magically solve your issue but hopefully it identifies issues that are outside of LANDESK's control. Perhaps your frustration with the product will be lessened as you see that it isn't entirely LANDESK's fault and that there isn't a 100% perfect mop up method. Hopefully it helps to identify the potential root causes that could lead you to resolving one of the potential root causes.

           

          Perhaps someone else has put together a more configurable and automated routine that you can use, but within the confines of the standard LANDESK technology there are mechanisms/process changes that could achieve your goal.

           

          Mark McGinn

          MarXtar Ltd/MarXtar Corporation

          http://landeskone.marxtar.co.uk

          LANDESK One Development Partner

           

          Try MarXtar State Management for LANDESK to Better Understand and Manage your Assets

          • 2. Re: Duplicate Devices useless
            kbrooks Apprentice

            Thank you for your well-written and in-depth response. I will admit, I was a little frustrated, as I had higher-ups (VPs) questioning why we were seeing duplicates, why our inventory was off, and why we were still having these issues after having LANDESK and other vendors out several times to resolve them. I will put together some ideas and add them to the feature request forum. I think one of the ways to handle the blanks and the 'To.Be.Filled.By.OEM' is maybe to be able to have the option to include exclusions. (that made sense in my head).

             

            I agree that changing the process would be the best solution, however the process is being dictated by Information Security, and that trumps everything else (don't get me started on UAC). Our number one headache is working around required company policies and (mostly) security tools. I'm also battling LDAV right now as well, but that is a whole other discussion. Once again, I appreciate your response and explanation for why it is set up like it is.

             

            Regards,

             

            ~Kevin Brooks