1 2 Previous Next 18 Replies Latest reply on Jul 14, 2008 10:35 PM by puercomal

    Device Disappears from Database After Manual Scan



      I thought perhaps i was mistaken when this happened last week, but today i have manually scanned a PC using the LD Console right click menu, and once that was complete the PC disappeared, this has happened a few times recently.  I am an admin user so i have the All Machines scope, we are using 8.7 SP4 with the mini-rollup.



      Any ideas what might be causing this and how to fix it?



        • 1. Re: Device Disappears from Database After Manual Scan
          phoffmann SupportEmployee

          First thing to check would be whether the device is actually still IN the Database.


          You do this best by querying the COMPUTER-table. Something like (if the device is called "MyDevice"


          select * from dbo.COMPUTER where DEVICENAME='MYDEVICE'



          More advanced method would be to check versus the UniqueID string "DeviceID" in the COMPUTER table.


          If it's not there anymore, you likely have a case of multiple computers using one DeviceID, and thus over-writing each other.


          Paul Hoffmann

          LANDesk EMEA Technical Lead.

          • 2. Re: Device Disappears from Database After Manual Scan


            Thanks Paul, I'm one

            step ahead of you!



            I already had the

            appropriate columns showing, so on a hunch I checked in the event log on the

            core (as I have enabled event logging for devices that change their Device




            In the event log I saw

            the device I was looking for which had changed its device/display name, and the Device ID was there also.  When I

            searched using the Device ID in the console, of course, I found a device with a different

            display name to the one I was looking for in the above post.  So I then

            checked the Inventory History for this device, exported results to Excel,

            deleted irrelevant data and I have found that 25 PCs all have the same Device




            I have checked this

            thread as well (http://community.landesk.com/support/thread/1159) which seems

            to be the same thing, but I already have the correct/same settings in Duplicate

            Devices section of Configure Services.



            Duplicate Device IDs

            would indicate to me that one of our PC images has not been 'doctored' before

            installing on PCs, however I have checked with our build engineer and he is adamant

            that this is not the case.  I have also checked and the 'problem' PCs range from

            desktops, to laptops, from Intel to AMD so this CANNOT be an mistake with the

            build as the machines use different builds.  The total number of PC/Laptops using these different builds is in the 100s not 25.



            Since enabling event

            logging on the core of devices changing their Display Name I have noticed that

            there are hundreds of changes every few days, which is quite a concern.


            1. Any ideas what else could be causing
                   the Duplicate ID problem?

            2. Can anyone tell me how the Inventory
                   Scanner creates a Device ID to ensure that it is completely unique?

            3. Is there anyway to recreate the
                   Device ID remotely, other than doing a messy reg edit/Inventory re-Sync?


            • 3. Re: Device Disappears from Database After Manual Scan
              phoffmann SupportEmployee

              Sure thing - good news is none of this is very difficult :).


              1 - How does this usually happen?

              Pretty much the ONLY way to get this to happen is to have the person who's building the corporate OS-image install the LANDesk agent as part of the image...


              ... and forget to delete the UniqueID strings in the registry.


              Result - you have a bunch of imaged machines (where the OS name can be renamed pretty easy) all of which share the same LANDesk Unique ID.


              That's how this problem pretty much ALWAYS happens :).


              2 - How the UniqueID gets created

              We use the same algorithm as Microsoft do in their creation of SID's. So - the odds of creating a duplicate "accidentally" are in the region of 1 : 1 billion, if memory serves.


              3 - How to resolve this

              Two ways to do this mainly


              3.A - The manual route...


              3.A.1 - You go to each affected computer.

              3.A.2 - You delete the following:

              File - Search for "LDISCN.CFG" on C:\ and the agent install'ed directory/subdirectories.

              Registry - HKLM\Software\Intel\LANDesk\Common API\UniqueID

              Registry - HKLM\Software\LANDesk\Common Api\UniqueIDNOTE - some of those may not exist (well - LDISCN.CFG in particular), but I want to make sure we'll not end up with "old" agent stuff creating the same UniqueID (we still check for the existence of those files).


              3.A.3 - Launch an Inventory scan (If no DeviceID is deteced, the Inventory scanner will create a new one).


              3. B - The automatic route...


              3.B.1 - Open the 32-bit Console on the Core.

              3.B.2 - Go to CONFIGURE -> SERVICES...

              3.B.3 - Click on the "Inventory"-tab.

              3.B.4 - Click on the "Device ID"-button.


              3.B.5 - Enable the option "Reject Duplicate Identities".

              3.B.6 - Ensure you have valid attributes to uniquely identify your posts. By default those are:


              Computer.Device Name

              Computer.Network.NIC AddressAnd the "Duplicate Device ID Triggers" is set to "2" in this default scenarion.



              A - Any time a scan comes in, the MAC-address and Device Name are checked.


              B - If only ONE of the attributes is different, the scan is processed (Device could be renamed / have a new NIC).

              C.1 - If TWO (as we configured "2" in the Triggers) attributes are different, ergo Device has a new/different name AND a new/different MAC-address, then the scan is rejected.

              C.2 - Additionally, the DeviceID is marked as a "bad Device ID", and ANY client that comes in with that DeviceID in the future will be told to generate a new one.


              D - Press "OK" to activate the changes and close the "Duplicate Device ID" window.

              E - Press OK to close the "Configure LANDesk Software Services" window (may require a re-start of the Inventory services.


              F - Wait / make a cup of tea/coffee.


              That's pretty much all that there's to it.


              Paul Hoffmann

              LANDesk EMEA Technical Lead

              • 4. Re: Device Disappears from Database After Manual Scan





                I disagree.  The UniqueID may be the result of some algorithm but the number that determines whether a machine is unique or not is a linear number such as 1234.



                It's obvious that each new machine checking in with the core is assigned a linear number by the core... and that's why duplicates really hurt.   For example, if you image 12 machines with UniqueID 1234,  they will continually check in with the core, update inventory and vulnerability information and constantly overwrite record number 1234.  In short, you will se the data from the last station that checks in.   (at least in the default column set)



                If it were up to me, I'd have the core generate a new number for any attempt to overwrite an old (existing) record... database 101, gentlemen.   Or have the UniqueID code detect the changed SID which results from SYSPREP.    Thanks!






                • 5. Re: Device Disappears from Database After Manual Scan

                  We had this issue durring our pilot stage of deployment.


                  It turned out to be how Duplicate devices were handled in our environment AND that we had a VPN client that created a generic MAC address for the virtual NIC for the VPN.



                  So if you are sure your images do not have the device ID in them it could be the "Restore old Device ID's" setting in the inventory section of Configure Services.





                  To Get there: Configure>Services>Incentory and click on the Devices button.





                  This brings up the "Duplicate Devices" window.





                  If you have the "Restore Old Device ID's" box checked AND you have a situation where the VPN MAC address is the same you can then get  two devices with the same Device ID.





                  I hope this helps.

                  • 6. Re: Device Disappears from Database After Manual Scan
                    phoffmann SupportEmployee

                    fribergb - Maybe this is a case of crossed wires here.


                    If you look into the COMPUTER table, you've got the following important bits of data.













                    Now, COMPUTER_IDN's DO go up sequentially, this is correct.

                    DEVICEID / UNIQUEID's - do NOT.


                    COMPUTER_IDN's are used DB-internally to reference a specific client. Rather than referring to "BOB's PC" as "{3D1511EB-7073-EB44-9E4F-4F1D472202E9}" all the time, it saves quite a bit of SQL to simply refer to it as "COMPUTER_IDN=1".


                    Now, a client has NO idea what COMPUTER_IDN it is. It only knows it's own DEVICEID.


                    What happens essentially is this:


                    1 - Computer_A sends a scan in with DeviceID = {3D1511EB-7073-EB44-9E4F-4F1D472202E9}.

                    2 - The Core processes it, and gives it a COMPUTER_IDN of (say) 1234.

                    3 - Computer-B sends in a scan with DeviceID = {3D1511EB-7073-EB44-9E4F-4F1D472202E9}.

                    4 - The Core processes it, and simply overwrites the record of COMPUTER_IDN 1234, because it (mistakenly) believes that the scan came from the same client (when in fact it only came from an imaged client which had the LD agent on it).


                    A client - in ANY communication with the Core will only state "my Device ID is {3D1511EB-7073-EB44-9E4F-4F1D472202E9}" (for example), it will NEVER say "I am COMPUTER_IDN 1234" - the Core simply matches the DeviceID to the respective COMPUTER_IDN.


                    This makes a lot of sense, as computer records can be deleted, re-created and so on - sequences change for a variety of reasons. This is why we do NOT use a device's name or even the COMPUTER_IDN (which the Core would need to pull out of the DB and somehow tell its clients anyway) but the DeviceID as an identifier. If there is no record for a said DeviceID, then it's a NEW device. Otherwise, update the existing records.


                    Sometimes this can be desired behaviour, sometimes it is not - no software can make the call on when this owuld be desired.


                    So I think you got your COMPUTER_IDN's versus DeviceID's mixed up - two rather separate items. One of them is relevant to clients (the DeviceID/UniqueID), the other is only of interest to the Core (since clients are utterly unaware what their COMPUTER_IDN's are).


                    I hope this clarifies things


                    Paul Hoffmann

                    EMEA LANDesk Technical Lead.


                    Message was edited by: phoffmann - fixed typos / added clarification

                    • 7. Re: Device Disappears from Database After Manual Scan


                      Me mixed up?   That's entirely possible.



                      However, my point remains the same... in the database world, developers sometimes chose a key value that doesn't work all the time in the field.   For as many times as this issue pops up, I think it's possible that you might re-think your key value assignment or (at the very least) work on eliminating the problem, rather than discussing why it exists and how we should manually fix it.



                      Bottom line is that we constantly re-image machines and the client is a bulky software download that takes time and bandwidth.   It would save us at least ten minutes per install (or re-image) if you could resolve this issue.



                      Like Jack says in "as good as it gets" - "I'm drowning here and you're describing the water"






                      • 8. Re: Device Disappears from Database After Manual Scan
                        phoffmann SupportEmployee

                        Interesting point.


                        I've been with this issue now (through the various versions of LANDesk) for over 5 years - a better way of solving it has not come up.


                        - We do need SOME unique identifier on the client which is "owned by LANDesk", and not related to OS-name or anything else that's likely to change (even SID's can change - such as through OS redeployments).


                        - Passing a COMPUTER_IDN on to the client and using that as a single, unique identifier would aggravate the problem if nothing else. We'd need to change the existing DB-structure to change the COMPUTER_IDN-column from being a sequentially growing number to just holding a number (which some of the time would need to be generated).


                        Problem is - how do you deal then with computers that are deleted?


                        I've tried to think up alternatives, but each has as many (and often more) drawbacks than the current solution.


                        At present, the solution is primarily one of two:


                        Option 1 - DON'T include the LANDesk agent on the image, rather just include a command-line to install it

                        This is by far the best recommendation, as it automatically means that you can install the "latest version" of the LANDesk agent very easily (whether calling WSCFG32 direct, or running a package based install).


                        For any OS-install method, this would be my recommended way of getting the LANDesk client on. Include it as part of the post-OS script, not part of the image itself.


                        Option 2 - Include the LANDesk agent on the image, but clear out unique identifiers

                        This is an educational issue.


                        If you are working together with one of our partners, they should be able to help you there, otherwise phone up LANDesk support before/while working on the image (I've had customers phone us in and asking for recommendations / points to watch out for when including the agent on a clone-image).


                        That's pretty much it, as I see it.


                        If it's "too late" so to speak, there's nothing we can do other than to try and clean up the pieces in a manner that's hopefully not overly disruptive.


                        If you do have ideas or suggestions on how to improve this, I'm certainly game to listen.


                        The problem I ran into (several times) is that every time I'd thought I'd found a way that was better than the COMPUTER_IDN / DeviceID assignment method, I ran into some other wall that would have caused considerably more problems than it solved. The current solution does work, and the % of customer incidents who have this are very low (particularly since this is usually the sort of thing where the "Make the mistake once, aware of it forever"-rule applies) - whereas the rest of the software's components work very well with this frame of reference.


                        Hope this help, and thanks for the feedback :).


                        Paul Hoffmann

                        LANDesk EMEA Technical Lead.

                        • 9. Re: Device Disappears from Database After Manual Scan


                          Thanks, Paul, I appreciate the time you spent on this issue.



                          I think you are telling me that you've tried and you can't find another identifier that works as well as a number generated at install.   I can think of two or three solutions off the top of my head:



                          1.   A script that re-sets the id for one or more client



                          2.  A script which re-sets the id for ALL clients (wouldn't it be nice, in some situations, to have a clean database generated automatically??)  If you hit the "re-number all button " you would get all machines checking in with all new data and it would be SO EASY to delete the old.



                          -best idea of all-



                          3.  Check SID when you start the client.  If it's changed from the SID that the system had when the UniqueID was gen'd, re-gen....   too easy. 



                          Thanks for listening!









                          • 10. Re: Device Disappears from Database After Manual Scan


                            Add this parameters to your shortcut of the inventory "/F /Sync" within the quotes. I think your inventory isn't in full option, you have in delta mode.






                            • 11. Re: Device Disappears from Database After Manual Scan
                              phoffmann SupportEmployee

                              A few things in response to fribergb-s suggestions.


                              Re: 1. A script that re-sets the id for one or more client

                              => That's pretty easy to do really - all you need to do is delete the UniqueID in the registry locations.


                              Though I don't see the use-case here - if you CAN access a client, it inevitably must be in Inventory already. If you cannot (because you have duplicate Device ID's) then Duplicate Device ID Detection can do this work for you (since it flags "bad" Device ID's and automatically tells ALL clients to generate a new Device ID when they talk to it).


                              Re: 2. A script which re-sets the id for ALL clients

                              => I do not quite see the value here. Re-setting the Device ID on your ENTIRE environment is going to cause you a stupendous amount of duplicate entries in the DB (as is currently) ... and assuming a worst-case scenario where your entire environment IS based off a single-image, again, the existing solution of Duplicate Device ID Detection will quickly mark the common Device ID(-s) as "bad" and the clients will sort themselves out over the coming days.


                              Considering also how rare a problem like this is (and how quickly it's caught), I'd be very hesitant with a "regenerate all client-ID's" button, as this is likely to cause far greater headaches than it'll solve. In particular when we get around to trying to manage 10,000+ nodes (which are complex enough environments at the best of times, usually). The addition of laptops / "road warriors" and so on further complicate / stagger any such effect.



                              3. Check SID when you start the client...

                              => Ah - 'tis the problem.


                              We cannot rely on the OS-SID, since there's the whole thing of OSD'ing a client and then re-using the Device ID (based on MAC-address and inventory record). This would create a plethora of false positives in many environments.


                              That's one of the reasons why I meant that the current solution (having "our own" SID - the DeviceID) is the best solution. It's something that no other influence will change (except for LANDesk). We cannot us OS-info like Device Name / SID or even hardware information (MAC-address / the old Pentium III CPU ID's / etc...) - all these things are prone to change unannounced/uncontrolled (re-imaging of the client / replacement of a defective hardware component, etc...) - and therefore cannot be relied on to be accurate and/or reliable.


                              In closing, the current solution to "a mistake that shouldn't be done" (it's - as I said, primarily an educational matter) is about as good as it gets. We can identify uniquely when a Device ID is being shared (which is configurable), and when a Device ID is detected as such, it will (assuming Duplicate Device ID detection is enabled) will be rejected and clients will regenerate their ID's over time.


                              It's certainly a lot more controlled (and thus safer from "unexpected side effects") than a blanket "regenerate all ID's coming in for a week or two"




                              Paul Hoffmann

                              LANDesk EMEA Technical Lead.

                              • 12. Re: Device Disappears from Database After Manual Scan
                                phoffmann SupportEmployee


                                If you wish to take a more "proactive" approach, you can try to use UDD (Unmanaged Device Discovery) to discover the devices that are "unmanaged" (by way of not being in the DB), and simply schedule the pre-existing "restore client records" script, which will send in a synch scan.


                                This is the only job other than sending out a client-configuration which you can schedule for UDD-devices, and since the clients in question have a LANDesk agent (and are addressed via IP-address), this will accelerate things somewhat (since you kick off the inventory scans yourself).


                                Though I would suggest staggering this in larger environments, so as not to over burden the Inventory Service needlessly.


                                Paul Hoffmann

                                LANDesk EMEA Technical Lead.

                                • 13. Re: Device Disappears from Database After Manual Scan





                                  To answer some of your q's:



                                  1.  What good is changing the UniqueID on a client when the records are overwriting?   Easy... if you have three machines that all overwrite record 1234, you clear the UniqueID once and then you have two machines, once again and you have three machines!   Makes sense?



                                  2.  Wholesale clear would create a ton of duplicates?  Not really.  It would create fresh records with a higher number but only one per machine.  Then you could eliminate the duplicates in one swipe by selecting and deleting all lower-number records.    What use is this?  Well, we had a damaged core and the data and inventories had become unreliable.   We fired up a new core and now have completely clean data - all fresh and new.   Fresh, clean data is nice, but you shouldn't have to create a new core server to get there- if you had a "clear all" function, all new machines, as they check in, would not only have a truly unique ID, they would provide fresh and clean data.  In a production environment- that's GOLD.



                                  3.  I understand that changing out the NIC would give a new MAC and so forth... but what I'm getting at is very simple.  A human can detect when the records are being overwritten because of an imaging error.   Why can't the software?   Here's the deal... if two different machines with different mac's and different users, motherboards, etc. are constantly checking in under the same ID, there is a duplication.   It should be prevented by the database rather than by the astute user.



                                  You suggest that this problem is rare, and perhaps that's true.  But who can really know?   If you have 400 machines on coreX and then you create coreY and suddenly you have 401 machines, you had a duplicate in there ALL ALONG without ever catching it.   My guess would be that this sort of thing happens on a very regular basis- it's just never caught until you install five or six machines with the same UniqueID by mistake.



                                  If you think about it, this insidious problem might NEVER show it's head... you might get a service call on machine X ten minutes after it checks in and you can remote, chat, etc.... then the record gets overwritten with machine Y and you get a service call on machine Y.   You'd NEVER know.



                                  BTW it also means that you guys aren't getting paid for all the licenses in use!



                                  4.  The idea of tying the SID to the UniqueID-generation-process would be easy, foolproof and a slam to write... why not try it?   Then, only when the SID changes would the process require a re-generation.   And an SID should never be re-generated unless the machine has a new image... maybe there are other times when an SID changes but shoot... why not re-generate- it doesn't cost you anything but a duplicate which can easily be discovered and deleted.



                                  5.  I don't understand the Addendum... maybe I'm just tired.  But these clients ARE all in the DB- they just overwrite the same record over and over- they aren't unmanaged.   I've never actually had any luck pushing a client to an unmanaged device...  but i haven't tried it in a while.  Maybe worth a look.



                                  Finally, as to the "education" question, I believe that I'm very educated, thank you very much.     I just wanted to skip the step of installing the client and LDAV on all 100 new computers.   Sigh.   Guess I can't.    Yes, we have it in our logon script, and yes, it's supposed to work.  But I'd rather be sure that all 100 work perfectly before I shoot them out the door.   For today I've solved this by having our workers un-sysprep and then install the client, LDAV and then run an autofix patch.   But now I have another problem... all the new records for these machines are in the database with the wrong computer name!






                                  • 14. Re: Device Disappears from Database After Manual Scan
                                    phoffmann SupportEmployee

                                    fribergb - thanks for taking the time to answer, it's appreciated.


                                    First off, just to clarify, my use of the term "educational matter" was not meant to be a snide comment or anything like that, purely stating that usually when people phone in to support with this issue, we explain to them how this happened, what was "done wrong" (so to speak). There's no "wrong" per se, since nothing was broken, just that inclusion of software (in this case the LANDesk agent) on images doesn't usually cause problems. In the case of the LANDesk agent it does (since we need a genuine, unique identifier). It was purely about this that I was talking about - you very clearly understand the issue at hand :).


                                    Regarding #1 - Well - it's what we do at present with Duplicate Device ID Detection. When we detect a bad device ID (or if you're brave, you can even edit this manually), then any client coming in with that gets told to generate a new ID.


                                    This "must" be reactive, on account of the nature of the beast. Since we only ever will know of a single device which has a Unique ID (namely - whichever client it was that last sent a full scan to the Core, overwriting previous ones), the only way of really doing this is by clients being made aware of the "Aha - you use a bad deviceID - please make a new one".


                                    Since we cannot be proactive on this, we need to be reactive (and have the problem solve itself over time) - as the saying goes, "We don't know what we don't know" :).


                                    Re # 2 - The duplicates I was referring to would be created unless you delete all the clients out of the DB.



                                    "Bobs PC" used to have DeviceID {1234-5678-9101...} and COMPUTER_IDN of 2.

                                    Now - with the "global reset" that you are talking about, we'd have an additional (due to different DeviceID) entry of (for instance):

                                    "Bobs PC" now has a DeviceID of {abcde-f1234-5678...} and a COMPUTER_IDN of 3


                                    The new COMPUTER_IDN would be created (and thus a "duplicate" record), since a new/different deviceID is used.


                                    This is not going to be a problem for devices that share a device ID of course, but it IS a problem for clients which have had a genuinely unique ID. My experience is that usually in these scenarios you have at least a subset of PC's that have not been imaged with the "same ID"-image ... servers for one, certain laptops for another. The larger the environment, usually the more diverse it is.


                                    Sorry, I should have specified what I was talking about with the duplicate entries. I was talking of a scenario where not 100% of clients had the same device ID. Maybe that's a better explanation :).


                                    Re: #3 - The software can, you just need to configure it to do so. Our default configuration (of DeviceName + MAC-address being the two attributes). This is just a recommendation - if you are certain of your unique identifiers you can use anything you want (and any number). It's all configurable :).


                                    The reason why I think the problem is pretty rare (aside from the fact that we don't get that many calls in) is that not that many people use that specific sort of OS-image. In my experience, more people use either minimalised Sysprep'ed images or even unattended install.


                                    I'll add more to this later, need to save this as is as work distracts .

                                    1 2 Previous Next