This was one in a series of articles written for Flexera on 2004 entitled, The Many Possible Results of Deploying a Bad Package.

Because it is old and the company has changed hands and names a couple of times times, this is no longer officially available but like many of my old articles that are otherwise lost, I’ve reposed them here in case anyone finds them useful.

The Many Possible Results of Deploying a Bad Package

Not using the right tools and not taking the time to quality check your work are probably the two biggest reasons for package deployment failures. If you are like most people, you may have attacked a few easy packages when you first started repackaging software and built some confidence in your skills. From there, most of us have a story of being slapped back to reality when a package got deployed that should never have been! Here we will cover some common problems associated with the deployment of a bad package.

Failed Installations

Luckily, with a failed installation, Windows Installer will roll back and not leave target systems in an unknown state. Interactively, an error may just present a warning dialog and allow installation to continue. However, an installation executing silently (via Group Policy for example) will record an error in the application event log and roll back if any errors are encountered. Of course, if you do not identify and correct the problem, this installation attempt may retry indefinitely.

Application Errors

A bad package usually means a bad application. Naturally, this means that users cannot perform their work and help desk calls increase. Packages that do not utilize techniques that ensure a complete package will be prone to such errors. Features like AdminStudio’s SmartScan, InstallMonitor, and Setup Intent help to ensure an application has all the components it needs to operate properly. 

Repetitive Self-Healing Attempts

Among the most annoying problems for a user is to wait while Windows Installer attempts to repair itself each time an application is launched. By including files in your package that do not belong, such as temporary files and files that may belong to another user profile, Windows Installer will fail to repair itself and try again at every launch. Exclusion lists (and to an even greater extent the PackageCleaner utility) help to ensure these mistakes do not make it into your packages.

Executing One Application Triggers Self-Healing of Another

If you fail to ensure your packages do not interfere with each other, this rather confusing situation can be common. By not making use of conflict analysis and resolution features like AdminStudio’s ConflictSolver it is almost impossible to verify compatibility between packages. 

Failed Updates

Windows Installer patches and updates provided by vendors must be applied to the original vendor MSI packages provided. If you intentionally or accidentally repackaged an MSI, or made changes to it directly, patches and updates may fail. This is one primary reason why MSI packages must not be repackaged; doing so changes the component structure and GUIDs which break any provided patches or updates. When it is necessary to make any changes to a vendor-provided MSI package, a transform (MST) should always be used to do so.

Failed Uninstalls

Uninstalling applications can break other applications if proper conflict resolution techniques were not applied. Reference counts maintained by Windows Installer for each file are based on component GUIDs that must be consistent across packages in order to function properly. These reference counts determine if a file is removed during the uninstall process – if the package believes it is the only one using a file, it is removed. Tools like AdminStudio’s ConflictSolver identify and correct such inconsistencies automatically. 

Damaged Reputations

Causing users to lose time, or even their work, due to what can be blamed on a bad package may cause irreparable damage to the reputation of your package and deployment team. When users have bad experiences with your team and lose confidence in the process, you may quickly become the target of blame for any unexplained problem that should arise. If you do your work right, users may not even be aware of your work, but if there is a mistake involved, the spotlight shines bright on those responsible.

Take the Time and Money to Do It Right

Getting the right tools and taking the time to use them can save you a great deal of time and money down the road. AdminStudio and PackageCleaner make up an excellent set of tools to avoid all of these repackaging pitfalls, but it is important to establish a consistent process that makes use of them. There will always be the possibility that mistakes can get through your process, but you can drastically reduce the likelihood by having the best set of tools for the job.

For more on AdminStudio, visit: http://www.installshield.com/products/adminstudio

For more on PackageCleaner, visit: http://www.packagecleaner.com