4 Replies Latest reply on Nov 22, 2011 8:59 PM by Catalysttgj

    Detection Logic with .MSI in LANDesk


      I am currently using provisioning to build new machines and eventually to re-build existing machines. A major advantage of using provisioning is the ability to make use of hardware independent imaging which in turns reduces the number of images that need to be maintained. We have a requirement that dictates that all laptop/netbook/notebooks automatically have an item of software installed on them as part of the provisioning process. In keeping with the benefits of provisioning, I do not want to have a template for laptops and a template for desktops. Instead I was hoping to distinguish between a laptop and a desktop and then carry out the necessary action based on the device type.


      Initially I planned to do this as a pre-requisite query which would return only laptops so that the software could not be deployed to a desktop. However it appears that pre-requisite queries are evaluated when the template is loaded and at this point only a miniscan would have been sent to the inventory.


      My idea was to make use of a few scripts. I wrote an AutoIT script to query WMI to ascertain the device type. If the device type was a desktop a .txt file was written to the root of C. The aim was to then use that file as detection logic for the software package. The SWD package was made up of the following:


      Main package: DeleteFile.exe


      The DeleteFile.exe would simply delete the ldDetection.txt file once the software has been successfully installed.


      Dependent Package 1: WMIQuery.exe


      This.exe would run a WMI query to ascertain the device type. If the device was a desktop ldDetection.txt file is written to the root of C. If the device is a laptop the program exits without doing anything.


      Dependent Package 2: setup.exe


      This .exe would be the software setup files. Detection logic is configured within the package so that the software will not run if ldDetection.txt at C:\

      This method worked, but following testing I was ready to implement my work around only the issue arose when I discovered the setup file comes as an .MSI and of course with an .MSI SWD there is no opportunity to enter detection logic.


      Has anyone found a work around to such a scenario? Should the detection logic be inside the .MSI? I was hoping to keep all logic external from the .MSI.

      Any ideas would be greatly appreciated.

        • 1. Re: Detection Logic with .MSI in LANDesk
          zman Master

          I have not tried this but, maybe use custom vulnerabilities for the installs. Create a custom vulnerability and use query filter under detection rules for laptops/desktops.

          1 of 1 people found this helpful
          • 2. Re: Detection Logic with .MSI in LANDesk

            Thanks for your quick response Zman. 


            I have also considered this so I will give it a go. I wonder if the filter is evaluated upon task execution as opposed to template execution.

            • 3. Re: Detection Logic with .MSI in LANDesk
              zman Master

              I'm assuming since it is a part of detection rules it will run with vulscan.

              • 4. Re: Detection Logic with .MSI in LANDesk
                Catalysttgj Expert

                My opinion on this is to use a custom registry value that you poke in the "model" information that you can pull from your WMI query. That way, you have even more granularity. You could do the laptop/desktop deal by evaluating the chassis type and plugging that in to a custom registry location as well. The benefit of a custom registry value over writing to a file will be very obvious. Its easy to create your own "Product definition" including the custom registry value as whatever you want it to be for each Product def that you come up with. This is how we currently do it for our environment. We have models defined, and you can create compound definitions this way too. We have LD9 + model, or LD87 + model as just a couple of examples. We also use custom registry values for customer specific programs (programs as in business units not software), so we can target not only specific mobile models but specific mobiles that are assigned to specific programs. It works great. We've been doing it this way for years. Wouldn't do it any other way now.


                Hope thats a useful tidbit.



                and Happy Happy!