4 Replies Latest reply on Oct 19, 2009 7:01 AM by craigSx2

    Applications uninstall when LDAP location is lost

    Rookie

      Hi All,

       

      We have an interesting issue here. All our applications deployment tasks are linked to LDAP queries. This works well for deployments but we have found that when the computer is taken off the network, the LDAP location is lost and LANDesk performs the uninstall task associated to the install package. This has been escalated to LANDesk via our support company and has been labelled as a product enhancement.

       

      Has anyone seen this issue before?

       

      We are using LD8.8 SP3.

       

      Thanks

      Craig

        • 1. Re: Applications uninstall when LDAP location is lost
          Tom Farrugia SupportEmployee

          In order for this to happen, you must have uninstall packages associated with the packages you targeted in the original LDAP policy.  The presence of the uninstall package associated to the package is what dicatates this behavior.  If you need it on some tasks, and don't want it on others, clone the package and offer one with the uninstall option and the other without.

          • 2. Re: Applications uninstall when LDAP location is lost
            Rookie

            Hi Craig,

             

            We have exactly this problem using LDAP linkage on our application deployments (policy based).  I guess you're also finding that when the clients reinstate their LDAP connectivity that the applications are redeployed again?

             

            I was about to submit a support call along the same lines, as this is starting to cause quite a few headaches for us (we have over 800 published application policies and a lot of laptop users) - did you ever get any more information back on your case as to possible cause/fixes?

             

            Also on LD88 SP3.

             

            Lionel, on this thread -> http://community.landesk.com/support/message/31303#31303 suggested that the issues stem from DNS resolution, which could be feasible in our environment as well, as I have yet to see this occur on a desktop machine, but it may be that we simply haven't had this reported back yet.

             

            Any ideas welcome!

             

            Cheers

             

            Craig

            • 3. Re: Applications uninstall when LDAP location is lost
              Rookie

              Hi Craig,

               

              We have logged this through our LANDesk partner and they have confirmed that it is an issue in LANDesk. The problem stems from the client loosing the LDAP Location value (as would be expected with a remote machine) which fools the LANDesk to perform the uninstall. We have had a enhancement request put into LANDesk to address this.

               

              The options going forward is

              1. control the uninstall from a batch file (ie ping a server name and if successful, perform the uninstall. If unsuccessful, it is assumed that the client is off the network and to exit without uninstalling)
              2. Unassociate the install and uninstall packages and create seperate uninstall tasks. Manually drop the machine in to perform the uninstall).

               

              We have opted for option 2 as we were operating in this mode in version 8.7.

               

              If you can raise this with LANDesk as well, then it would add weight to the product enhancement request.

               

              Also, if there are any LANDesk people looking at this thread, could you comment?

               

              Thanks
              Craig

              • 4. Re: Applications uninstall when LDAP location is lost
                Rookie

                Thanks Craig, that's really useful information.  I will get the case logged with LANDesk and see where that goes....interesting use of the term "product enhancement" there!

                 

                I think we'll also fall back to dropping the uninstallation association from the packages until this is sorted....we do have the option of not using LDAP based memberships I suppose but this is going to create a vast amount of rework so will hold off going down this route if there's a chance this will be resolved.