Run uninstall policy on indexed DMG package but doesn't remove all the files, how to remove the remaining files/folders?

[#1]

I have created several packages with Composer and they install fine but
uninstalling seems to be an issue at times.

For example, I created a package for Filemaker 11.0.4. Had both the main
installer and updater on the desktop of the composer computer. Ran composer
snapshot (new and modified files). Installed Filemaker. Installed the
update to 11.0.4. Ran Filemaker several times. Created our companies
favorites for the Filemaker server. Once done, packaged the package up as a
DMG package. Indexed the package in Casper Admin.

I then created a policy that installed the package. That installed fine.
Created another uninstaller policy. Uninstalled everything except for the
filemaker folder in Applications and a file in there for tutorial..

In a nutshell, how do I alter the package so that it will completely remove
the application folder instead of leaving bits of it behind. Also is it
possible to customize the uninstall process so that it will forcably remove
all the files/folders that I choose?

I have a couple of other packages that exhibit similar behaviors. The
majority of the app is gone except for one little bit or some text file that
lives inside the app folder in the Applications folder.

Thank you for your help.
Brenton Snyder

[dderusha]

We Have experienced the same and normally test a removal and write a clean up script to pick up the leftovers

Dan De Rusha

[golbiga]

If it's just one or two files/folders you can just do a run command in the advanced tab of a policy to remove the files. I do this w/ EndNote because it exhibits the same behavior as FileMaker Pro (misses one stupid txt file)

Allen

[david_yenzer]

golbiga/Allen - Thanks for reminding me of this functionality. We created our base image and found out after the fact that we had left an excess folder on the image that we wanted to remove. After some looking around and many failed attempts using Composer to remove a specific folder, we simply created a Policy and typed in the folder path to delete it. Simple. That tool will be very useful moving forward.

I also wonder if we could institute a similar policy that would delete a "Mountain Lion" instance, since we don't want our users to install that on our hardware. We have a policy for "restricted hardware" to kill a process, but a Policy that deletes a specific location might be good insurance. I wonder if when they download it from the app store the file goes to a specific location (ie, Downloads folder?). Will do some testing.

[mm2270]

If Mountain Lion is anything like the way Lion worked, when it downloads, it gets downloaded to /Applications, and then launches the actual installer afterwards.

I would simply set up a Restricted Software setting that not only kills the Mountain Lion install process, but also deletes it. Its just a checkbox in the Restricted Software setting. Your users may be pissed that their 4+ GB download vanished, but too bad I say, if you plan on blocking that.

As for the original question as to why some items get left behind during an uninstall, that has happened to me in the past, and I suspected its related to an application that has had updates installed after the original package was installed. In other words, if you build a Microsoft Office installer and push that out, then individual updates to Office are deployed later, if you run the uninstall process from the first full package, it may leave some items behind because some of the components in the Office folder are either entirely new (not in the original pkg) or have been modified, As a result, the uninstall process may not see them as valid items to be uninstalled. Remember, its using an Index of the package, and I think that index includes file sizes and perhaps modification dates.
This is all theory, as I've never taken the time to test that out, but that's been my thinking whenever I've seen it happen.