Bob wrote the guest view article for the initial print release of the SD Times, published April 15, 2008. Entitled, Why is Software Installation Still Such a Mess? The article discusses some problems with Windows software installation with some suggestion on how it could be improved.
April 15, 2008
The creation of a setup routine is far too often an afterthought given little attention by software vendors: A setup that just installs the software and “gets the job done” is not enough.
There are a growing number of organizations trying to manage software configurations through the use of automated software installations. Among other things, this helps ensure that software is installed the same way on all systems, which can reduce support costs. For these organizations, the automated deployment of software is the only authorized means of software delivery. As a result, the task of installing software may be far more challenging than answering “next, next, next” in an installation wizard.
A setup can be written to perform any number of changes that may or may not be known to us—changes that may well be undesirable in a managed environment. It seemed like Windows Installer (MSI setup) was going to solve this problem to a large degree. Microsoft introduced Windows Installer with the release of Office 2000 several years ago as a well-structured standard to be leveraged by all.
In fact, Microsoft went so far as to make its use a requirement for Windows logo certification. It is powerful, well documented and includes many features important to administrators including logging, rollback, repair, validation and command line control. But naturally with all these great features comes complexity, both in the management of Windows Installer to avoid unwanted repairs and prompts for missing network source files, as well as in the authoring of such setups.
When a setup is to simply install some files, registry entries and a shortcut, things tend to go pretty well. Add elements like hardware drivers, services, updates, and permission changes, and watch the level of complexity soar. There are plenty of helpful tools out there to author such setups, but they can still be a challenge to the uninitiated and none of these tools generate a perfect package.
So how do we define a perfect package? Microsoft included a validation feature through which a set of rules may be checked to identify several potential issues. These rules call out warnings and errors and ideally give you some confidence that the MSI setup you have before you is well written. The universally accepted set of validation rules is the Full MSI Validation Suite (darice.cub) and Windows 2000 Logo Program Suite (logo.cub). Unfortunately, no authoring tool generates a setup that does not have at least a handful of complaints from these rules. Many of the warnings and informational messages presented may be harmless, but interpreting what the problem is, and if or how it should be corrected, requires expertise. Frustratingly, Microsoft itself releases setups riddled with such warnings. If validation were a more helpful feature, it would be the goal of vendors and in-house developers to produce a setup that satisfies the rules. Some diligent administrators may attack these problems and produce a perfect package, but it is often disregarded as a lot of noise not worth pursuing.
Due to the complexities inherent to Windows Installer, many vendors have simply decided to stick with their legacy setup.exe process. This may or may not provide a silent means of installation. However, even when legacy setups do provide a means of automated installation, just how to leverage this ability can vary significantly between applications and even between versions of the same application.
Some legacy setups simply cannot be automated. In these cases, administrators are often left to repackage the setup. Repackaging is the process of identifying the changes made by a vendor setup to generate a new customized deployment package. Even when some vendors provide a means of silent installation, there are many who repackage them anyway to realize the benefits of Windows Installer across all their applications. This is another specialty that can take years to master. Not knowing the intentions of the author can result in problems with repackaging because the process strips a setup of its logic. This can particularly cause problems in cases where conditions are checked to determine what actions are to be taken by the setup (such as in the identification of external dependencies).
If everyone moved to Windows Installer managed setups, it would at least eliminate the need (or desire) for repackaging. But a lack of expertise in how to create a proper Windows Installer setup can result in one that meets the format requirement but does not follow the rules that allow it to be fully beneficial. When trying to replicate the behavior of a legacy setup in a Windows Installer setup, authors who do not realize the native capabilities that Windows Installer’s standard actions provide can quickly turn to writing their own custom actions. Custom actions essentially allow authors to run scripts, commands, call DLLs and even execute embedded executables to accomplish their goals. The complication comes in when a rollback, uninstall, upgrade or repair takes place—for these scenarios custom actions are not taken into consideration, so what they should do in these scenarios must be addressed as well. For example, if a file were installed using its file table (a standard approach), Windows Installer would handle its removal or reinstallation automatically. If a custom action that runs a script to install the file is used, removing or rolling back the setup will leave the file behind unless another custom action is explicitly written to handle it.
The other problem with custom actions is that what they are doing may be hidden from administrators. In a controlled environment with a tight configuration management process, deploying an application without paying attention to its actions could mean changing local security or updating undesired files or registry items on target systems.
Finally, you may wonder why Microsoft does not provide everything as an MSI setup. For the most part they do, but there is an inherent limitation of Windows Installer in that it cannot update files protected by Windows File Protection (WFP). The files that make up the Windows installation are protected from deletion and replacement by WFP. They may only be deleted, updated or replaced by hotfixes, service packs and Windows upgrades offered by Microsoft. Microsoft keeps this capability to itself and therefore out of the Windows Installer.
That is also why applications closely coupled with the operating system are also not available as MSI setups (like Internet Explorer and Windows Media Player). However, it is possible to wrap these installations into a Windows Installer setup as a custom action. In fact, Microsoft has provided major updates like service packs with a “Windows Installer Wrapper” for those who desired them. And while a wrapper like this is not a true Windows Installer setup with all of its benefits, it is as close as those striving for a catalog of nothing by Windows Installer setups is going to get.
Some may disagree, but I think that starting over with a new format would be too drastic a step. I think that the current offering is very powerful and extensible and should be able to support demand. Further, there are too many people, companies and products invested in the technology to start over or implement drastic change. However, there are definitely a few things that can be done to help make Windows Installer more accepted and friendlier. Just some of what I see as big steps toward fixing the software installation mess:
• We need a helpful set of validation rules so it can serve its purpose effectively.
• Vendors need to clearly communicate configuration or security changes that may be made by a setup routine.
• Administrators must communicate problems and concerns encountered with vendor setups to the vendors directly. Only by hearing from its customers can a company effectively prioritize giving attention to their installation capabilities.
• Microsoft should deliver all setups as Windows Installer Setups, even if they need to wrap the core functionality in a custom action. Properly written, the custom action could pass those relevant parameters to the legacy setup (such as to run silently or control reboots). Microsoft should set the example and follow its own guidance and resolve their validation errors.
Vendors need to think beyond end user, interactive setups. Do software vendors need to hire the right people (or train the right people) to deliver the setup customers need? Why are some people still hesitant to move to Windows Installer? If it is just the learning curve, I’d say people need to get with the times! Finally, supportability is a big issue for Microsoft, and Windows Installer is a key aspect of this. It seems clear to me that Microsoft must take a leadership role by providing MSI setups of its own and cleaning up the validation errors present in the ones it currently ships.
Bob Kelly is the founder of AppDeploy.com, a resource for systems administrators.
The article is no longer online, but can be found in this archive.