Whilst policy based software installation with automatic uninstall looks very cool - it is just this sort of concern that prevents a some customers from making use of it - the danger of a mass uninstall starting itself unintentionally. Test well!
Thx for your help, but it's not really the answer that I would like to have ;-)
I have done more investigation and the results are: Logging with a user but in offline mode (cache credential), everything works fine, because policy.sync cannot contact the LANDesk server and nothing happens, and again login with a local account, automatically all software are uninstall...
It will be great if the uninstall association do the same but based on the AD. If the AD can be contacted, get the group list and validate the policy, but if the AD cannot be contacted, please DO NOT ASSUME that you should uninstall. But wait until you can contact the AD again and compare with the previous group list before starting the uninstall. This will resolve the problem when logging with a Local account.
This features is really great! Basically put a computer in a AD group = Install renmove for that group = uninstall. Any IT will love this feature! But test and test it again, using more granular and professional method to be sure that this feature works and can be used. Because for the moment, you can not use it, and it's a shame...
1 of 1 people found this helpful
You are right .. its a great feature but it should be tested well. Note that when you add a AD Group to a SWD task you get three options: Machine, User and Group. If you use machine or User then a query runs from the schedular service on the core server to evaluate the group membership. The Core server contacts the AD in this case. If however, you select Group then the policy is based on what the client sends back with inventory - i.e. it is based on its actual AD group membership. In this case, if the client can not contact AD - then it will not change its group membership and possibly trigger an unintended deinstallation. Im not sure which option you are currently selecting, but I would usually go with the Group option - since it places less load on both AD and the schedular service on the core.
That's really a helpfull answer... I'm using Computer. And really, I never understand why there is also the Group option, when you create the query.
I will do some test based on the inventory information, looks more efficient... I will force some inventory, event connected with a local account, to see if in the inventory you will lost the group memebership information... I'm curious...
See you at the next episode
Looks cool, but it's the same issue... When you run the inventory logged with an AD account, the Computer group membership is OK. Running the inventory with the local Admin acount, the computer group membership is empty, and the inventory also --> means initiated the uninstall...
I'm thinking that LANDesk do not have the right to get the AD information, when logging with a local account, and this is the reason of the computer group empty. There is no reason to say, if you logged with another account, the computer group membership change...
BTW, the command line Microsoft tool, GPResult, give you the list of group membership, and even logged with a local account, you have the group memberhsip of the computer correct...
Perhaps you should look at creating an uninstallation task using group membership. Installation gets handled by one task and uninstall by another. Not quite as nice as an automatic uninstallation if someone gets removed from a group but it would only remove if that machine was in the removal group.
Unless there is a design change in the product this might be the only other way to go.
The One-Stop Shop for LANDesk Enhancements