3 Replies Latest reply on Nov 13, 2009 4:36 AM by phoffmann

    Software Deployment & automatic healing



      Alright, I have read most of the bkm on the subject for software deployments and have not come across this yet.  Hopefully someone here knows if this can be done automatically or whatever.



      After I deploy a package.  In this example I want it to be a msi policy-push.  Assuming all the installs work just fine, but a week later something removes a file needed for that software.  Is there anyway for LDMS to automatically recognize this faulty install, then reinstall the package or fix the package?



      Same questions for batch file...



      Thanks in advance...









        • 1. Re: Software Deployment & automatic healing
          phoffmann SupportEmployee

          LANDesk doesn't re-invent wheels when it's not necessary :).


          MSI already has self-healing properties - we leave that alone. Batch-files are single-files and are either present or not.


          The only app-"healing" of a sort that LANDesk itself has is related to ESWD packages (we came up with this before MSI came out) - so if you've got something simple like a batch file or whatnot that needs to have this property, then the ESWD package builder may be a way to go. For MSI's - you may as well use MSI's healing abilities.


          No need in making life more complicated than necessary :).


          Paul Hoffmann

          LANDesk EMEA Technical Lead.

          • 2. Re: Software Deployment & automatic healing

            Thanks Paul,

            That made sense...


            I now have a follow up question to that...


            I would like to Assign departmental software to a group (departmentalized group), query or static group either way.  Let the install occur at that time, and leave it active, so that if a week or month goes by and I add a machine to that group or have to reimage one of the machines in that group all the departmental software gets reinstalled automatically.  Possible?


            I understand I can create the queries and assign policy based deployments, but my understanding is that once I drop that query into the scheduled task, the machines that the query found are the only ones that will attempt the install.  Nothing down the road will attempt to install unless I redrop the query into the scheduled task.


            Does LDMS have this or is there even a third part app that can do it?




            • 3. Re: Software Deployment & automatic healing
              phoffmann SupportEmployee

              So - first of all, what version of LANDesk do you use - policies change DRAMATICALLY between 8.7 and 8.8


              Furthermore - queries do get re-evaluated in regular intervals (i.e. - 1 hour by default). So in short, "yeah", we can do this, just that the details normally differ based on what you have/are using.


              The trick - when re-imaging clients - is to make sure that they get the right (which is to say - their old) Device ID's. If that doesn't happen, it's treated as a "separate device" and may simply not be targed by your queries.




              Here's something I responded to someone using 8.7 who reported a similar problem, which was caused by the very thing I described (i.e. their devices received new device ID's, thus were never part of the policies they were supposed to get).


              I've done some digging into this, and I think that your problem is that you don't get the correct device ID's. What I mean by that is that during your re-imaging, you don't re-use existing LANDesk device ID's (which is how we identify a device in the database uniquely) but instead end up with duplicates.

              This is pretty easy to prove.

              Do the following.

              1 - Create a policy and target it to a test-client.

              NOTE - this should be a simple package - such as a BATCH-file which launches NOTEPAD.EXE or something rudimentary like that, so that it's nice and small.

              2 - Start the policy
              3 - Let the policy apply - in our case, wait for the NOTEPAD window to come up and close it.

              4 - Policy successfully installed - so far so good.

              Now - on to "deleting" the clients' awareness of the policy...

              5 - Launch REGEDIT on the client and go here:

              You'll see registry directories here of the variety:
              - {Package-2}
              - {Package-365}

              Each is a Package ID - so you need to find your Notepad package (the NAME string will help you here).

              6 - Now - delete whole {Package-xxx} directory for your notepad package. This essentially "duplicates" the behaviour as if the machine were re-imaged (but in this case retains the same LANDesk device ID).

              7 - now run "AMCLIENT /APM" again (to check for policies).

              Your client will re-execute (and download of course, if necessary) the NOTEPAD-batch file.


              So what I think your problem is that you've not enabled the re-use of existing DeviceID's in LANDesk for when you re-image a device.

              You do it in the following way:

              A - Launch the 32-bit Console on the Core (must be the Core).
              B - Go to CONFIGURE -> SERVICES.
              C - Click on the "INVENTORY"-tab.
              D - Click on "DEVICES".

              E - Choose a setting to remove duplicates.

              NORMALLY this should be "Both device names and MAC addresses match". If you are likely to replace NIC's and/or device names, you can choose
              Device Names match
              MAC addresses match

              If you use the two "stand-alone" option, an "OR" logic is applied. To use an AND logic for the two to apply, you muse use the "Both..."-option.

              F - Now that you've chosen an option to delete old duplicates, note that the option "RESTORE OLD DEVICE IDs" has ungrey'ed itself.

              G - Tick the box to "RESTORE OLD DEVICE ID's".

              What this does - essentially - is to tell the Inventory service to (simplified) behave in the following way:

              G.1 - On an incoming inventory scan, note down the Name and/or MAC-address (as configured in your options above).
              G.2 - Check whether these already exist in the database.

              IF THEY EXIST ...
              ... and the incoming scan reports a different device ID, reject that scan. Inform the device to re-set it's device ID to what is in the database.

              In other words, if a device is re-formatted, and comes in with a different device ID, the Inventory service will tell it (over a few conversations - usually 3) regenerate/re-use its old device-ID, thus preventing duplicate entries in the database.

              This will also then allow your policies to properly pull, as the old DeviceID's are going to be used, the old policies will target the correct device.

              Thus, if you had "one" of those six instances of "BOBSPC" in a policy, we'd be checking for the DEVICEID (ultimately) associated with that entry, and NOT (!) the DEVICENAME.

              It's very important to understand that a device's name doesn't mean much to LANDesk - it's pretty much all going through DeviceID's.

              I hope that this explains what you're seeing, and I hope that my analysis of what's happening on your side is correct. I've given you simple steps above to verify this and hopefully set you on the right track.



              Paul Hoffmann

              LANDesk EMEA Technical Lead


              Message was edited for better readability by: Paul Hoffmann