| New Installer Supports Security Push |
| Aug. 30, 2004 |
Windows Installer 3.0 will be the leading edge of Microsoft's most recent push to improve the reliability and security of its products. First released with Windows XP Service Pack 2 (SP2), the updated software installation engine will help simplify the task of keeping software installed with it up-to-date, which is critical to keeping systems working and secured against attack. However, customers will not see benefits from the latest Installer until it is adopted by application developers, including Microsoft, and those developers will have to weigh the Windows Installer against a new "ClickOnce" installation technology currently under development. Windows Installer 3.0 is the latest version of a Windows OS feature for installing, uninstalling, and repairing applications. Application developers use Windows Installer APIs and utilities to create installation packages for their applications. While developers can and do write such packages from scratch, the Windows Installer takes care of many complicated installation tasks and handles many errors that can arise when installing applications on Windows. (See the sidebar "Windows Installer Capabilities".) Note that the Windows Installer does not install Windows itself: the OS has its own installation technologies (also used by some server products), including the WinPE boot environment and a patching utility known only by the filename Update.exe. Security Drives Installer Improvements Version 3.0 of the Windows Installer will play an important supporting role in Microsoft's current push to make it easier to keep Windows systems up-to-date and thus less prone to attack. Over the last three years, a wave of high-profile worms and hacker attacks has exploited bugs in Windows and Windows applications. As a result, IT departments are devoting more effort to patching—the process of updating software that's already been installed on Windows systems—to fix security holes and other bugs. Microsoft hopes to support these efforts by improving its technology for patching and making its applications easier to patch. Improvements Microsoft has promised through 2005 include the following:
Security was the original reason for these improvements, but not the only one. Simplifying patching will particularly lower the cost of maintaining applications for companies with many PCs, which in turn could encourage those companies to invest more in new PC applications—an important incentive, given that Microsoft is the world's largest producer of PC software. Windows Installer 3.0 is an important technology for all of Microsoft's promised patching improvements. It supports removable patches and other reliability improvements and enables application developers to ship smaller patches without compromising reliability. It delivers important support functions for detecting installed applications and patches, and it will provide application installation and detection for Microsoft Update and WUS. Finally, it is slated to become the sole installer for most future Microsoft products other than Windows itself. However, for organizations maintaining Windows software, the new Installer and planned new patching technology are only part of a solution. Organizations will still need good processes to completely inventory installed software (to determine which computers and software must be patched), evaluate new security threats (to decide when and how to patch against the threats), evaluate and test patches (to ensure that a faulty patch or installation process does not damage production systems), and distribute patches to computers efficiently (to ensure they arrive in time to make a difference). The improvements to the Installer will make all of these processes less difficult, but not bulletproof. New Support for Patch Management The most important patching improvement in Windows Installer 3.0 is a new patch installation process that enforces patch order and supports later patch removal. The Installer also has changes that make patching and other installation operations less likely to fail due to lack of a CD-ROM or other installation source for an application. Together, these improvements should make patch installation less error prone and reduce overall downtime due to patching. The improvements are designed to work with an application life cycle similar to that of Microsoft applications. In this life cycle, an application developer periodically releases full application versions (major updates in Windows Installer terms) interspersed with patches. Patches update installed application components, such as files and Windows Registry settings, on target computers. Patches are divided into hotfixes (also called QFEs or small updates), which generally make changes to small numbers of components to fix specific bugs, and service packs (minor updates), which roll up previously released hotfixes with additional changes, and which are intended to establish an updated, mutually compatible set of application components on the target computer. New Patch Process for Sequencing, Removal With Windows Installer 3.0, application developers can define sequences of patches (called "patch families") where installing any set of patches in the family will always put an application on that computer into the same state, regardless of the order in which administrators install the patches. Patches in a family can also be removed individually from a target computer after installation. The key to these capabilities is a new patching process: given a new patch to install, the Installer conceptually reverts the application to a past "baseline" state, such as the most recently installed full version or service pack. It then (conceptually) installs the new patch and any previously installed patches in the sequence specified for the patch family. However, the Installer uses an efficient process for updating application components so that it does not have to actually revert the target computer back to the baseline or uninstall and reinstall existing patches. (See the illustration "Patching with Windows Installer 3.0".) The new patching capability delivers several benefits: Minimizing patch sequencing errors. The Installer will ensure that when multiple patches from a family are applied to a computer, they are always applied in the same order. This avoids errors that can occur today when patches are applied in the wrong order. For example, if Hotfix 1 updates a security setting that is subsequently tightened in Hotfix 2, applying Hotfix 2 followed by Hotfix 1 could loosen the security setting back to the value written by Hotfix 1. With Windows Installer 3.0, the application developer can place Hotfix 1 and Hotfix 2 in a patch family, in that order, to prevent this scenario. This will particularly benefit reliability for applications that get many patches and service packs between full releases. Patch removal. With the new patching process, developers can at last create patches that can be removed properly. In effect, the Installer removes a patch by taking the application back to a baseline state and then reapplying all installed patches except the one removed. As noted, the Installer does not actually uninstall and reinstall the patches, but makes the minimal changes to application components needed to produce the net effect of uninstalling and reinstalling. Patch removal is crucial to administrators, because it enables them to recover from problems that slipped through patch testing. It can also facilitate testing by giving administrators an efficient way to return a test computer to an earlier state (to determine which patch is responsible for an observed problem, for example). Faster patching. Because the latest Installer tries to minimize changes to application components during patching, it can sometimes install patches much faster than previous versions when a patch changes only a few components. Hotfixes in particular will likely apply much more quickly. Faster patching is particularly important on servers and other systems where minimizing any downtime, including planned downtime, is crucial. Reducing Installation Source Demands Windows Installer 3.0 has several new features that reduce the chance that an application will require access to its original CD or other installation source, which in turn can lead the Installer to prompt the user during an operation. Such prompts occur for a variety of reasons. (See the illustration "Dude, Where's My Disk?".) While installation source prompts are annoying for individual users, they become serious problems in organizations that are trying to install software on hundreds or thousands of computers using automated software deployment technologies such as SMS. Two features of the new Installer make installation source access less frequent: Baseline file retention. By default, the Installer automatically retains copies of files for up to two baselines for an application on a target computer; generally, this means that the target computer will have the original files for the application's last full release and for its most recent installed service pack. By retaining these files on the computer, the Installer does not need to go back to an installation source to get them when applying or uninstalling patches. To limit the space required by retained files, the Installer makes copies only when needed; that is, it only saves a copy of a baseline file the first time a patch or other change attempts to alter the file. The Installer also limits the amount of disk space used by retained files to 10% of the volume's space by default. Administrators can alter the space limit or disable baseline file retention completely through Group Policy, if necessary. Installation source list maintenance. Windows Installer 3.0 enables administrators or scripts to change the list of installation sources on a computer for an application. This can help reduce the chance that a reinstall, a patch, or a repair tries to access an installation source that isn't available, resulting in a failure or a prompt to the user. For example, if an organization changes the location of its administrative installation points for an application, an administrator can push out a script to each client that removes the old location from the list of installation sources and adds the new. Companies that issue laptop users a "rescue CD," which contains installation sources for laptop applications, can add the CD to the list of installation sources on each laptop. Solutions for Smaller Patches Together, Windows Installer 3.0's improvements for patching and for reducing access to installation sources could also help shrink the size of the patch packages that Microsoft and other developers deliver to their customers. Patch size is clearly important for the hundreds of millions of home PC users who still access the Internet over dial-up lines. It can also prove important in corporations trying to distribute patches to branch offices over slow leased phone lines, or to isolated kiosks or monitoring stations that periodically "phone home" over slow links. Specifically, Windows Installer 3.0's improvements make it more feasible for application developers to deliver small "differential" patches. Differential patches deliver only the changes to files that they modify, rather than delivering complete changed copies of the files. When a patch updates only a few files at a few locations, a differential patch can be much smaller than a full-file version. Differential patches are supported in earlier versions of the Windows Installer, but this technology has frequently been avoided by application developers because a differential patch can only be applied to computers that have the specific file versions changed by the patch. In the past, this requirement often meant that the Installer had to access an installation source for an application, which in turn led to installation failure or prompts to the user. Windows Installer 3.0, in contrast, can install differential patches more reliably if developers follow certain guidelines. In particular, a differential patch that applies to a baseline version of an application will usually not have to access an installation source because the files required by the patch will have been saved on the target computer. Furthermore, if the patch does have to access an installation source (if, for example, the files it requires were eliminated to save space on the computer), the new features for installation source list maintenance make it more likely that a valid installation source can be found. Detection and Systems Management Support Apart from improved patching, Windows Installer 3.0 delivers some improvements to its APIs and scripting interfaces to support automated tools for software detection and distribution. Particular targets for these features are the free WUS software planned for release in 2005 and a patch management feature pack planned for SMS around the same time. Improvements to support systems management tools include the following: Patch scanning. The Installer API now offers a basic patch scanning capability: it can accept a list of available patches (in the form of an XML file) and determine which of those patches are applicable on a particular computer. This function is currently performed by a variety of scanning utilities from Microsoft, including the Microsoft Baseline Security Analyzer, Systems Management Server, and the Automatic Update client (used by Microsoft's Windows Update software distribution site). Putting basic patch scanning into the Installer itself is a first step toward unifying these tools into a single, consistent inventory scanner for Microsoft products. More flexible security for detection and patching. The Installer API makes several changes to the security privileges required to detect and patch applications that will benefit systems management tools and scripts. For example, tools running with administrative privileges can now detect applications that are only installed for some users; previously, tools that wanted to detect per-user applications had to be logged in as the user, making centralized detection difficult. The new Installer also enables administrators to digitally sign and pre-authorize ("bless") installation packages that require administrative privileges so that they can be installed by less privileged users. Among other things, this will enable a user to patch applications that were installed for him by Group Policy application deployment, an operation that would normally require administrative rights. Uniform command line options. Windows Installer 3.0 supports a new set of command line options that match those of the most recent version of the Windows OS patching utility, Update.exe. The new options don't add any new capabilities to the Windows Installer, but standardizing command line options across the two installation technologies will enable systems management tools (and individual developers) to create installation scripts that work on most Microsoft products. This in turn will make it easier to use installation scripts to automate application and patch installation on large numbers of computers Future Directions Through 2005 Shipping in Windows XP SP2 is the first of several near-term milestones for the Windows Installer. Other milestones include the following: Developer tools. To take advantage of the new Installer patching capabilities, developers need new tools for building patch installation packages. Macrovision InstallShield X and Altiris Wise for Windows Installer have already been updated to support Windows Installer 3.0. Due in Aug. 2004 is a new release of Microsoft's Windows Installer SDK, which includes a redistributable version of the Installer. Redistributing the Installer with applications is currently the only way to get it onto computers running OS versions prior to Windows XP SP2, including Windows 2000, Windows Server 2003, and Windows XP. The SDK also includes a minimal set of package building tools and developer documentation. A later step will be new package authoring tools in Visual Studio 2005, due in mid-2005. However, those tools will remain minimal compared to those of third parties. An open-source project called WiX is developing package authoring tools that might interest companies with complex software build processes. (See the sidebar "WiX Supports Text-Based Installer Development".) Adoption in Microsoft products. As noted above, Microsoft intends to take advantage of Windows Installer 3.0 in its upcoming free software distribution offering, WUS, and in a planned feature pack for SMS 2003. Both products will then rely on the new Installer for patching and software detection. The company also intends to gradually move most of its applications to the Windows Installer, hoping that a more uniform set of application installation tools will simplify systems management. For instance, the company's Common Engineering Criteria for server applications dictates that "2005" versions (e.g., SQL Server 2005) use Windows Installer 3.0 or later. Adoption by other developers. A key unanswered question is when application developers other than Microsoft will adopt Windows Installer 3.0 for patching and inventory. To take advantage of new Windows Installer 3.0 features, developers do not have to update application installation packages already shipped and installed. However, they must create patches that include information required by the new features, such as patch family and sequence information. They must also ensure that Windows Installer 3.0 is installed on their customers' computers, which in many cases means redistributing the Installer with the application. Most likely, adoption will be gradual because of the new Installer's OS requirements. Specifically, this version of the Installer requires Windows 2000 SP3 or later. It does not support Windows NT 4.0 or 9x OSs. That means that developers cannot use Windows Installer 3.0 exclusively until they follow Microsoft's lead and retire support for the older OSs. Beyond 2005: ClickOnce and Longhorn By the time many application developers start to look seriously at Windows Installer 3.0, they will have a new alternative: ClickOnce. Planned for delivery in Visual Studio 2005, the ClickOnce installation technology will support over-the-Web installation of managed applications—applications written in C#, Visual Basic .NET, and other languages that target Microsoft's .NET Framework development platform. The initial version of ClickOnce will be very limited compared to the Windows Installer. For example, it will not be able to install file associations, desktop shortcuts, or software components that are shared among multiple applications. Furthermore, ClickOnce applications require the .NET Framework, which cannot itself be installed by the technology. Nor will ClickOnce provide patching, although it will support an over-the-Web automatic updating mechanism that can install new full versions of applications. As a result, initial users of ClickOnce will likely be Web developers who want to add a managed client component (e.g., a search toolbar or Office plug-in) to an application. However, some limitations of ClickOnce are to be lifted in "Longhorn," the major release of Windows due in 2006. In Longhorn, ClickOnce will install file associations, and the .NET Framework will be preinstalled in the OS. As a result, it will be increasingly feasible for substantial applications to be delivered with ClickOnce. That does not mean the Windows Installer will be redundant in Longhorn. It will still be required to install "unmanaged" applications (applications that don't run under the control of the .NET Framework), and it might still have a lead on ClickOnce in areas such as patching and per-user configuration. In fact, Microsoft is planning a Windows Installer Version 4.0 for Longhorn that will support new features, such as installation of applications to OS images (useful for corporate environments) and a feature that will reduce reboot requirements for patches by enabling applications to "hibernate" temporarily and relinquish their locks on executable files. Nevertheless, the development of ClickOnce could require Microsoft resources that would otherwise be spent improving support for the Windows Installer. In particular, it's unlikely that the company's Developer Division, the brains behind ClickOnce and the .NET Framework, will devote substantial effort to improving developer tools for creating Windows Installer packages, or to supporting new Windows Installer features for managed applications. Long-term, the Windows Installer will likely remain the primary installation technology for unmanaged applications, but the company will strive to make managed applications and ClickOnce the standards for Windows. System Requirements, Availability, and Resources The Windows Installer 3.0 engine is already shipping with Windows XP SP2. It is also supported on Windows 2000 SP3 or later, but application developers will need to redistribute it with their applications to ensure that it is present on systems prior to Windows XP SP2. An update to the Windows Installer SDK with the redistributable engine is expected in Aug. 2004. As noted, Windows Installer 3.0 is not supported on Windows 9x or NT 4.0. Microsoft's security plans and status are outlined in "Microsoft Slowly Delivering on Security Promises" on page 3 of the Sept. 2004 Update. ClickOnce is described in "ClickOnce Aims to Ease Installation" on page 24 of the Apr. 2004 Update. A comprehensive introduction to the Windows Installer (formerly called the Microsoft Installer) appeared in the March 1998 Research Report, "Microsoft's Software Installation Technology, Part 1: Client-Side Installation Service." New software maintenance features in Windows XP Service Pack 2, including Windows Installer 3.0 features, are outlined at www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2maint.mspx. The reasons for installation source prompts and other technical issues are answered in the Windows Installer Frequently Asked Questions list at www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx. The latest Windows Installer SDK download can be found at www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm. Application developer documentation for Windows Installer 3.0 is located at msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp?frame=true. Avanade, a systems integrator focused on the Microsoft platform (and a joint venture of Microsoft and Accenture), offers patch management solutions and security assessments; see www.avanade.com. Macrovision InstallShield X from Macrovision is described at www.installshield.com. Altiris Wise for Windows Installer is outlined at www.wise.com. Useful third-party sites covering software installation include installsite.org, www.desktopengineer.com, and www.appdeploy.com. Windows Installer design rationale and other observations on the technology can be found in Rob Mensching's Weblog at blogs.msdn.com/robmen. The WiX project site is sourceforge.net/projects/wix. |