Posted on 01-07-2014 12:47 PM
We previously used FileWave, which what the computer was removed from the group, the application was also removed. We've now got most our install policies setup, but since Casper doesn't auto-uninstall an app when a computer or user is removed from a group, what is the best method or industry standard among users for processing uninstalls?
Solved! Go to Solution.
Posted on 01-07-2014 01:05 PM
Uninstalls have never been a strong suit of the product, but you could make use of Casper Suite's uninstall function by indexing all your packages in Casper Admin, then enabling each for uninstall by enabling the checkbox called "Allow this package to be uninstalled by Casper or a Policy" (<--wording is from Casper Suite 8.x, not sure how its worded in version 9)
Now, this won't auto uninstall anything, but will allow you to create policies to use the same package for uninstalling the software as well as installing it.
A caveat: this function of Casper Suite is a bit hit or miss. I've seen cases where junk gets left behind or the uninstall doesn't actually work. If your installations are fairly simple packages or DMGs, they should generally work to uninstall this way. If they are complex, i.e, use pre/post-install scripts or are vendor supplied metapackages, etc, there are no guarantees of how well this will work. I strongly encourage you to test each one out thoroughly before letting them loose on your Macs. A smaller caveat, but worth mentioning is that indexing all your install packages increases the size of your database a little. Not usually a big deal, but just something to keep in mind.
The tricky part is going to be determining when to do the uninstall. You would probably need to use Smart Groups for Macs that have Application Title A present, but are not in a specific group, whatever that may be in your environment. Once the software is uninstalled, the Mac should fall out of that group. Not sure how feasible any of the above is for you since it will depend on your setup.
Posted on 01-07-2014 01:34 PM
I am a strong proponent of creating custom uninstall scripts/packages for each piece of software you distribute. I am yet to see a single package that I want to just blindly remove every file listed in the BoM on the receipt.
As for the automation... you could script a daemon that would check the date modified on a file that your regular JSS policies touch. If the date modified is too far out of line, the user gets some kind of pop up or warning. If it passes some other milestone, you can execute the uninstall script. This feels heavy handed to me, but is the only way I can think of to automate this level of enforcement.q
Posted on 01-07-2014 01:05 PM
Uninstalls have never been a strong suit of the product, but you could make use of Casper Suite's uninstall function by indexing all your packages in Casper Admin, then enabling each for uninstall by enabling the checkbox called "Allow this package to be uninstalled by Casper or a Policy" (<--wording is from Casper Suite 8.x, not sure how its worded in version 9)
Now, this won't auto uninstall anything, but will allow you to create policies to use the same package for uninstalling the software as well as installing it.
A caveat: this function of Casper Suite is a bit hit or miss. I've seen cases where junk gets left behind or the uninstall doesn't actually work. If your installations are fairly simple packages or DMGs, they should generally work to uninstall this way. If they are complex, i.e, use pre/post-install scripts or are vendor supplied metapackages, etc, there are no guarantees of how well this will work. I strongly encourage you to test each one out thoroughly before letting them loose on your Macs. A smaller caveat, but worth mentioning is that indexing all your install packages increases the size of your database a little. Not usually a big deal, but just something to keep in mind.
The tricky part is going to be determining when to do the uninstall. You would probably need to use Smart Groups for Macs that have Application Title A present, but are not in a specific group, whatever that may be in your environment. Once the software is uninstalled, the Mac should fall out of that group. Not sure how feasible any of the above is for you since it will depend on your setup.
Posted on 01-07-2014 01:34 PM
I am a strong proponent of creating custom uninstall scripts/packages for each piece of software you distribute. I am yet to see a single package that I want to just blindly remove every file listed in the BoM on the receipt.
As for the automation... you could script a daemon that would check the date modified on a file that your regular JSS policies touch. If the date modified is too far out of line, the user gets some kind of pop up or warning. If it passes some other milestone, you can execute the uninstall script. This feels heavy handed to me, but is the only way I can think of to automate this level of enforcement.q
Posted on 01-08-2014 06:46 AM
@mm2270 wrote:
Uninstalls have never been a strong suit of the product, but you could make use of Casper Suite's uninstall function by indexing all your packages in Casper Admin, then enabling each for uninstall by enabling the checkbox called "Allow this package to be uninstalled by Casper or a Policy" (<--wording is from Casper Suite 8.x, not sure how its worded in version 9) Now, this won't auto uninstall anything, but will allow you to create policies to use the same package for uninstalling the software as well as installing it.
Note that this feature isn't going to work for PKG installers that have built in logic, since BOM will only list files that were layed down on the Mac, and will remove them.
Bill Maher understands how undoing something isn't always easy...
https://twitter.com/billmaher/status/258750733728505857
Posted on 01-09-2014 07:03 AM
Thanks for the answers...we were hoping it would be easier, but looks like we'll be using a combination of all the methods described. I like the idea of smart groups that trigger the uninstall, but I wish Casper really had a better solution, but oh well. We'll probably just target those apps that have tight license constraints first and go from there.
Thanks!