Add or Remove Programs / Registry
The list of applications that you see in "Add or Remove Programs" (ARP) is defined in the Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, and for 64-bit clients it also spills over into HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. Scan through all the entries, named and GUID labels as well. Those that have a "DisplayName" value, are what you should see in the ARP list. When you find the products you're looking to remove, note the "UninstallString" value and move on to the next one. For "msiexec.exe" values, be sure to replace "/I" with "/X" (or lower case "/x", it doesn't really matter).
Sometimes you'll find references to .EXE files, as well as those which perform bootstrap setups and uninstalls (Autodesk 2009 and later products are well known for this). In other words, you'll find the product listed multiple times. Once with the product name, and another (or several) with a corresponding GUID. Many vendors, Autodesk included, provide documented guidelines for automating removal of their products, which can be very useful.
Other places to look are HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE\SOFTWARE\Classes (aliased) and HKEY_USERS\.DEFAULT.
Files and Folders
The nature of most modern installer utilities is that they will only uninstall what they originally installed. Basically, the uninstall routine reads a manifest of what was installed, checks to see if it is the identical object, and then removes it. If the object (file, folder) is new, or has been modified since the installation was completed, it will typically leave it behind. That means that the folder in which the file resides cannot be removed either. This is why you often need to do a little extra work to automate a truly "clean" uninstall package. There are many ways to do this, but one of the most effective ways is to use a script wrapper.
It is important that you always use the vendor-provided uninstall mechanism first, and then follow behind with any required clean-up tasks. NEVER, I repeat NEVER just delete files and folders without running the appropriate uninstall mechanism first. Otherwise you may end up with a lot more junk strewn about the computer than you realize.
Hooks and Handles
One of the most common reasons that files and folders cannot be deleted during an uninstall operation is that which I described above. But the other common reason is that a service or process has one of the files opened "in use" at the time of the uninstall. If the vendor uninstall mechanism doesn't properly stop related services or terminate related processes, the files will be blocked from deletion. If you can diagnose relevant services and processes, you can incorporate the appropriate termination commands to allow for a clean uninstall. The most common commands for this are SC.exe and TASKKILL.exe, but you can also use Sysinternals' "PSSERVICE.exe" and "PSKILL.exe".
Sloppy Work
Many small-time development shops either cannot afford to implement proper packaging tools and processes, or simply don't care. It's just a fact of life and economics.
Many will build their own ad hoc installer utilities, or give you a .ZIP file to extract and do your own heavy-lifting (moving files, registering DLL and OCX components, adding registry keys, running scripts, making shortcuts), which sucks ass, but again: they can't (or won't) do it for you. Sad that it's 2012 and this is still not uncommon.
Many will give you an installation package, but the uninstall aspects were forgotten or released untested. This too can make it a suck-ass experience to mop up behind.
If a vendor hands you a soggy bag of crappy software, you still have an option: Repackage it. If you have InstallShield or AdminStudio, you can repackage their crap into a shiny new installer package. In most cases, you can make an .MSI but if there are prerequisite/redistributable dependencies you might prefer a bundled "SETUP.exe" package. Either way, you get a cleaner installation package with a reliable ARP interface and the ability to do a clean uninstall as well. In fact, if you spend a little time with uninstall testing you can incorporate some "Custom Action" tasks into the package to do your own cleanup work without the need for scripting.
Per-User
While most things are fine with "per machine" installation and removal, there are times when you need to seek out items under each user context and delete them. Files, folders, and Registry keys are most common. There are several ways to hit this...
- Build a package to delete items on a per-user context and deploy to each user using a per-user advertisement.
- Use a login script
- Use Group Policy Preferences
- Use ActiveSetup packages
Each of these is a world unto its own, so I won't dive into them here, but there's plenty you can find via a Google search that should help point you in the right direction.
Summary
While many products are well packaged for enterprise deployments, many more are not. This is why so many IT professionals spend so much time shoe-horning applications for mass deployment and mass removal. The more work you put in "up front" the less you will have to put in later.
No comments:
Post a Comment