3 Replies Latest reply on Sep 30, 2009 9:24 AM by Jared Barneck

    Monitoring distributed Software

    Rookie

      Hello,

       

      is it possible to "monitor" the deployed software? Is there a service that tells me when a software that was deployed as a landesk package is uninstalled/changed/whatever? This means in some cases that a update package that I want to deploy doesn't install proper. Or an uninstallation of an older package before a new one.

       

      What I need is something like the "Detection Page" (in the "Distribution Package") where I can say: "Package, when you recognize a File/Registry Key/Whatever (e.g. the program executable) don't start yourself" and then in the "Shedulded Tasks" The Package can run hourly or weekly. Currently the packages install themself over their existing installation, thats user-annoying and sometimes settings-resetting ^^. But because of the Detection Page does something different (that I don't realy understand by now) this is only what I want to have. Is there a feature like that?

       

      Best,

      Norman from ableton

        • 1. Re: Monitoring distributed Software
          Jared Barneck SupportEmployee

          This use case doesn't make sense to me.  That doesn't mean it is invalid, it just means I don't understand it.

           

          You want to have software install on machines and the task to constantly run but track who has it installed and who doesnt...Why does a Policy delivery method not work for you?  That is exactly what it is and does.

          • 2. Re: Monitoring distributed Software
            Rookie

            Hey,

             

            ok, I see what you mean. So let me specify what I mean.

            The feature that I want is a function which takes care about the packages I've distributed. For example I want to deploy the version 9.1.2 of Acrobat Reader and don't want to let the user to update to 9.1.3. When this happens "LANDesk" (I think the Agent) should start the package that installs again the 9.1.2 version.

            You say that the feature that I want is within the policy delivery method. Do you mean the settings "Type and frequency of policy" so that an above described error can be correced each day/week/month? Is this the policy? And what is checked so the agent can be sure that there was an "unauthorized" update?

            If so why can you also set this in shedulded tasks (Repeat every: hour/day/week/month)? Isn't this redundancy? Or does this "repeating" do something different?

             

            Best,

            Norman

             

            ps: I know that an update for a software shouldn't be possible for the users, but some have admin rights here, so I have to think about this problem.

             

            Thanks in advance

            • 3. Re: Monitoring distributed Software
              Jared Barneck SupportEmployee

              I see your use case now.

               

              You want users to remain at Adobe 9.1.2 and if they install 9.1.3, you want to uninstall 9.1.3 and reinstall 9.1.2.

               

              So if you use a Policy and set it to required once, then when you first install 9.1.2, it is going to mark you as having installed it once and probably won't reinstall it.

               

              If you do a push, then we will reinstall Adobe 9.1.2 on every device in the task becuase the primary package is Adobe.

               

              So detection is the key, however, the problem is that Detection only works for a dependent package, not a primary package.

               

              So do this (It is called the blank batch file trick (I sent this out as a "Tip and Trick" way back when 8.5 first came out)

               

              1. Create a blank batch file.

              2. Create a Package to push the blank batch file.

              3. Make your Adobe 9.1.2 package public.

              4. COnfigure the blank batch file to depend on Adobe 9.1.2.

              5. Configure detection on the Adobe 9.1.2 package so that it fails detection if Adobe is either not there or if it is a newer version.

              6. Create a Push task to push the blank batch file.

              7. Have the task repeat.

               

              Now, everyone will still run the task daily, but those who are at Adobe 9.1.2 will only rerun a blank batch file, which takes almost no resources and always succeeds because a blank batch file can't really fail to run. Because the blank batch file is the primary package and Adobe 9.1.2 is the dependent, dependent packages only run if they are not detected.  It is KEY that you make it NOT detect if they have a newer version.

               

              I hope that works for you.