9 Replies Latest reply on Jun 14, 2016 6:39 AM by phoffmann

    [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing

    CKuhl Apprentice

      Hello dear Community,

      we have a Problem regarding the Provisioning History.

      I guess the Problem is caused by duplicate entrys, but i am not sure. And if that would be the cause

      i haven´t found a solution to fix the occurrence of duplicates.

      Most Computers in the Device-Database won´t show a OSD Deployment Task in the History

      This behaivior isn´t permanent and sometimes the OSD is listed on a different machine.

      There a machines that have an OSD from the installation but i would guess that that share is fairly low.

      However if i deploy just Software through a Provisioning Task, that one is listed.


      I hope you can give me some advice.


      Best Regards



        • 1. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
          phoffmann SupportEmployee

          So - in short - "yes" odds are that your suspicion is right.


          The Provisioning history / task data is spread out over the following tables:


          • PROV_HISTORY_TASK (this one being the most important one, as it links provisioning tasks to COMPUTER_IDN's / device records directly!)


          ALL of those are ultimately connected through a COMPUTER_IDN to a device (resolve those in the COMPUTER table).


          Now - let's say that "Computer_Idn = 123" runs the OS provisioning task you care about. And (for whatever reasons) when you install the LANDesk agent, that device then gets a new device ID & as such, will get a new entry - say "Computer_Idn = 234" ... the new entry (234) will have none of the provisioning history associated that you're expecting.


          That said ... HAVE you enabled the restoration of device ID's based on MAC and/or Device Name? See the article I've written here -- About: "Devices" and "Duplicate ID's" option for Inventory, and how they work -- that explains how the feature works & how to use it.


          You're interested in the "Duplicate Devices" section primarily (chapter II) along with the option to restore device ID's (that essentially will ensure that devices maintain their existing records).



          The "easy" way to tell if my suspicions are correct are in monitoring the COMPUTER table and monitoring the COMPUTER_IDN entries/values for a device that you control / provision ... that would explain the logical reason behind what you're seeing.


          That can be fixed - but first of all - let's make sure that my suspicion is correct .

          • 2. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
            CKuhl Apprentice

            Hello phoffmann,


            thank your for your answer. Maybe I should explain how the pc´s are being installed.

            The Inv. is configured to clean up Devices by Mac AND Name and restore the old ID.

            1. A Task and a Computer is being created with the LANDesk WebAPI on the LDMS. Also a Task for that device is being created.

            2. A Setup.exe of Win7 is being run in the WinPE + CTOS

            3. A Provisioning Agent is being installed.

            4. On finish the final Agent is being installed.


            I have looked in to the LDMS Database. After the Prov. Agent there are two entry's in the Database.

            The Task is associated with the ID 2963 which is the Device created through the API.

            Then there is another Device with the ID 2962 which is the one created by the Prov. Client.


            So after the LANDesk Inventory cleanup is being run, only the device with the ID 2962 will exits and the History will be lost.

            The interesting thing is, that the device created by the API does not have a Device-ID.

            This example device should be installed for the first time. I will start another install today.


            Best Regards and Thanks in Advance



            • 3. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
              phoffmann SupportEmployee

              Interesting. Some of what you describes sounds a bit odd / doesn't make sense (based on how the process is supposed to work).


              Based on your screenshot, you have a "full" inventory scan as COMPUTER_IDN 2962 - yet you have a "miniscan" (without device ID) as COMPUTER_IDN 2693.


              Now - the reason why I'm scratching my head (and you may fill in a few blanks here) is this.


              If a device boots into Provisioning (or otherwise sends a miniscule scan of "I just have my MAC address to identify myself) we check the database for records of this. The ONLY way that the same device would have a new record added, is if this MAC address wouldn't be possible to be matched up (i.e. - doesn't exist in the DB).


              In reverse situations, if the only record for a device that exists is such a miniscule "UNASSIGNED" device ID (and only a MAC address exists) situation, then we'll update the existing record & marry them up based on the MAC address as well.


              Are you deploying to different hardware & "just" re-using the hostname here? I can't think of another scenario where we'd have (what looks like) a regular inventory scan record followed by what amounts to a mini-scan record. The only way I can figure for that to happen is via a MAC-address mismatch ...?

              • 4. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                CKuhl Apprentice

                We are reinstalling with an existing Device and installing new devices. The case is showed you was a new device. It seems that this issue only occurs if you are installing new devices.

                Ok now I understand how the duplicate is being created. The LANDesk creates the first entry in the database for that mac-adress when you use the PXE boot. After that the pc is created with the LANDesk API and on that ID the task is running. Is there a method to deactivate that LANDesk automatically adds unknown devices that are in the PXE or networkboot? I am sorry but I couldn't  find anything on the internet about that topic.


                Best Regards



                • 5. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                  phoffmann SupportEmployee

                  Aha - so you're doing a hardware replacement/upgrade!


                  So the answer is "not as such" - we *need* to have a device in inventory so that we can schedule things against it.


                  However, if you're migrating hardware, you may want to make use of the Device Mapping feature (introduced in LD 2016) - which is intended to deal with situations such as this (i.e. - a hardware up-lift). So that already includes device name re-use & automatic profile association.


                  Check this link on how to get access to the Interchange session materials -- Access Interchange 2016 recorded sessionsAccess Interchange 2016 recorded sessions -- and one that mentions it specifically is the "single image provisioning" one for instance.

                  • 6. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                    CKuhl Apprentice

                    Sorry but that is not necessarily the case. We are Re-Installing with the same hardware-configuration or installing as complete new devices with the same hardware config. The only difference is if the device was installed with LANDesk before. Usually we don´t replace or upgrade hardware. The device IS in the Inventory via with Web-API. So I nor need or want the auto discover. I am sorry if this is confusing. But we are creating an inventory entry similar to the bare metal devices through the web api provided by landesk.( Just as an example..  How to invoke a LANDesk MBSDK method using a HTTP POST). This method is works. However because of that we have two inventory objects.

                    So the easiest thing to do, would be just to disable the auto-discover...

                    • 7. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                      phoffmann SupportEmployee

                      If you have a device in inventory already, you don't need to create a bare metal entry.


                      The ONLY reason for a bare metal entry is so that we have a record of a device's MAC-address on record. We already have that for existing devices - you just use the normal / regular inventory record. So what's creating the duplicates is "you" - by creating the bare metal entry.


                      The PXE-time mini-scan is going to update an existing entry (so regular inventory records are quite fine).


                      As an aside, if you're using the MBSDK, check out - Getting Started with the MBSDK (Example Scripts Included) -- as well.


                      So if you have an existing device, just use the "add device to task" function, rather than creating a bare metal record which is going to have duplicate records now for a MAC address.


                      You have a process problem, not a technical defect .

                      • 8. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                        CKuhl Apprentice

                        Yes I came to the same conclusion, that I am the one create the duplicate. If I understand you correctly, I can´t disable the miniscan. Ok that means that I have to find a solution via the programming site of things.

                        At first I was´t aware that *we* made the mistake by creating the device regardless of it being already in landesk. If I would have known from the start, I guess I just would have asked if it would be possible to disable that feature. So we took the long way.


                        Thank you for your time and the assistance.


                        Best Regards



                        • 9. Re: [OSD History] [MS 9.6 SP2+] Entrys of OSD are missing
                          phoffmann SupportEmployee

                          You are correct - the PXE miniscan can't be disabled. We need to (somehow) know the IP address that a device has been given ... so the miniscan does just that. "Here's my MAC - here's my IP - now you can send me work to do" .


                          Glad we've figured that one out. A simple logic problem is easily remedied in the end .


                          Happy to help .