2 Replies Latest reply on Feb 7, 2013 10:27 PM by Catalysttgj

    Redeploying a software distribution on reimaged machine with same name

    jabramson Apprentice

      An interesting situation is occurring and I am trying to figure out if there is a better way to handel this.

       

      1) Currently using 9 SP3

      2) PCs are queried from AD to put in the policy to distribute a software package via mandatory policy. This is done because the only way to determine which PCs should get it is by an OU where user names are added for people who need the application installed.

      3) Using a prerequisite check to make sure the PC doesn't already have the software installed.

      4) Manage Duplicate Devices checked for "Both device names and MAC addresses match" and Restore old Device IDs.

      5) Current delivery method of the scheduled task is Policy-Supported Push.

       

      So the PC is reimaged with the same name. The scheduled task shows that the PC result is "The action completed successfully" in the Result tab. So the PC isn't getting the software redistributed to it even though it was reimaged.

       

      Now I would think since the newly re-imaged device doesn't have the application listed as installed on the local db that it would indicate to the core that it doesn't have it and needs it, but it retains the status in the scheduled task as indicated.

       

      So for the software distribution gurus, is there a better way of handling this? Some thought would be to remove the "Restore old device IDs" but that would mean lots of duplicates in the DB. At the same time I don't want to lose history of the record. I have read and reread this Doc but the answer given doesn't seem to make sense since it doesn't work this way with the environment I have setup. http://community.landesk.com/support/message/79302#79302

       

      Now on another thread it talks about this being the situation if the delivery method is a P-SP versus a policy. This task is setup as P-SP. So is that the issue? http://community.landesk.com/support/message/57910#57910
      I assume I can change the delivery method now and it won't reinstall on any devices that were already successful. But will it then start running in the future on re-imaged PCs? Also, isn't the downside of using a Policy is no multicast option?

       

       

      Thanks,

       

      -Jonathan

        • 1. Re: Redeploying a software distribution on reimaged machine with same name
          Frank Wils ITSMMVPGroup

          Yes, the PSP is the issue. For this purposevit's better to assume it works as a push. 1 time only. A pure Policy will always sync. Matchng the local DB with the tasks on the server. Changing your delivery method will definately work for you. Create the task, add a policy delivery method, add your ldap targets and start. Set and forget :)

           

          Frank

          • 2. Re: Redeploying a software distribution on reimaged machine with same name
            Catalysttgj Expert

            Required policy. That translates to what Frank was pointing out. Your policy needs to periodically run again. You can create a delivery method for this. We set up our required policies to run once a day, but you have to make sure that the detection is working properly in a package, otherwise you could end up with the package trying to reinstall over and over again. We didn't like the outcome of two packages where one is a dependent of the other. Setting up detection in one of the packages, which then if detected causes the installation of the dependent package. This model is weird and ackward, and its prone to failure (unless LANDesk has fixed all of this.) In the past you could get false positives on the detection because it utilizes vulscan to perform the detection logic, but if vulscan was already running, for instance performing a security scan at the time, it would cause an error code return of the additional copy of vulscan being called by software distribution, which would produce a false positive. This would then trigger the dependent package to be installed even if it really wasn't needed. Because of this issue we chose a different path. We build custom definitions to install software. This way vulscan itself handles all the logic of detection and installation. Then we create packages that simple call vulscan with the /repair switch and the name of the custom definition. When these packages are scheduled, we set them up for daily frequency, and this way when a policy sync occurs it will kick vulscan and attempt to repair the patch. If the patch is not detected, nothing happens. The return code to the task will be no patches found basically. This is a BIG change though, so I wouldn't expect that you'd jump right at this. Can take a major rethink of how things are done. There are obviously limits. Hope simething here is somewhat useful to ya.