4 Replies Latest reply on May 27, 2009 3:56 PM by irishmn76

    LD 8.8 SP2A LDAP-Based Uninstall Association Problem

    Rookie

      Guys

       

      I'm currently migrating a LANDesk 8.1 infrastructure to 8.8 SP2A, and one of the key features I'm looking to take advantage of is Uninstall Association for our software deployment.

       

      I've come across a problem whereby if I use LDAP-based object (groups) targets for deployment, my policies will install the software fine when machines are added to the LDAP groups, but fail to remove it again once the machines are removed from the groups.  I've tested the same tasks/packages using standard devices, and this way the software installs and uninstalls successfully.

       

      Looking at the policy.sync.log and client databases its almost as if the client is totally oblivious to the fact the computer has been removed from the group, even after reboots, inventory scans and restarts of the policy.

       

      Has anyone seen this issue, or have any pointers as to how I could troubleshoot further?

       

      Thanks in advance,

       

      Craig

        • 1. Re: LD 8.8 SP2A LDAP-Based Uninstall Association Problem
          Rookie

          Looking at doing this as well

           

          Our company also wants to target all TASKS using LDAP machine groups.  We want to be able to remove the machine from the ldap group and have landesk automatically perform a deinstall.  We have not implemented yet but are very interested in this thread.

          • 2. Re: LD 8.8 SP2A LDAP-Based Uninstall Association Problem
            zman Master

            Simply removing an object from a LDAP target will not automatically uninstall the application. You must create a uninstall distribution package and target it to the object.

            • 3. Re: LD 8.8 SP2A LDAP-Based Uninstall Association Problem
              Rookie

              Thanks for the belated activity on the thread folks!  I have now resolved the problem, which seems to be related to client database corruption on some of our test machines - renstallation of the client allowed packages to install and uninstall correctly.  As Zman says you do need to create the uninstallation packages and associate these with the installation packages, once this is done then the scheduled tasks do their jobs fairly well (uninstallation will only work if you setup the tasks as Policies, not PSPs).  It's a shame only Main pacakges are supported by policy tasks, as we would ideally have liked to use multiple packages within single distribution tasks - maybe something for version 9!

               

              This sort of leads to another query about the performance of the policies:

               

              We amend our client configuration so that LDAP group memberships are enumerated at the client, but I have seen some quite extensive lag between assigning/unassigning the machines from LDAP groups before the policy.sync takes effect - even when running manually.  As the policies are targeted to LDAP group objects, their membership effectively doesn't change so my assumption here is that I don't have a requirement to constantly re-run the policy tasks?

               

              Would be interested to hear anyone elses experience of this type of setup, and any best practices in terms of the frequency of running policy.sync via the local scheduler.

               

              Thanks,

               

              Craig

              • 4. Re: LD 8.8 SP2A LDAP-Based Uninstall Association Problem
                irishmn76 SupportEmployee

                The problem you're seeing is because there are two different types of AD resolution in the LANDesk product, core server and client.  The core server uses schedqry.exe to resolve all AD policies by default every hour.  The client side is the ldapwhoami.exe that runs everytime policy.sync.exe runs.  My guess in what you're seeing is that while the client is up to date on when it's been added or removed from the group the core has not been.  The only way to correct that is shorten the time the core goes to query AD.  The caution on that is if it's too short the core could get very busy just quering AD all the time.  To set that time out go on the core and click configure -> Services.  The scheduler tab has the setting for how often the core resolves all LDMS and AD queries.