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.
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.
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.
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.