Standardizing the Patch Experience

Article
06/29/2009

Introduction

Managing patches is an issue of critical importance to system administrators and IT managers. To simplify the task of keeping systems fully patched, product groups across Microsoft are working to standardize the operation of our patches. This article discusses the improvements Microsoft is making as part of this standardization effort. It is intended to serve as a roadmap that will help customers plan for and take advantage of the patch management improvements as we implement them.

The specific changes are discussed in detail in the following sections. They fall into three broad categories:

Changes designed to clarify the documentation that accompanies patches through the use of standard terms and document formats.
Changes designed to reduce the management burden associated with patches, through the adoption of uniform technologies and engineering practices.
Changes designed to improve manageability by standardizing patches' behavior on the user's system.

For context, it's worth noting that these standardization efforts are only part of a much broader set of initiatives designed to improve patch management across the board. We've confined the scope of this paper to improvements that result from standardization related to existing technologies and services. However, additional projects are also underway to develop entirely new technologies and services. Many of these are described in white papers and other material on TechNet, and we'll provide additional information as these projects progress. For additional patch management information please visit https://www.microsoft.com/technet/itsolutions/cits/mo/default.mspx

Standardized Documentation

Several changes are associated with improving the clarity of the documentation that accompanies our patches. In general, the goal of these changes is to talk with customers in a consistent, well-understood way, in order to provide the most complete and useful information we can.

Terminology

Issue: Over the years, a number of redundant terms associated with Microsoft software updates have come into use. For instance, the terms patch, hotfix, and QFE are largely synonymous, all referring to a software change whose scope is limited to a small number of changes. Other terms have distinct meanings, such as service pack and service release, but the differences between them aren't well understood. Developing and using consistent terminology will allow our documentation to be more clear and useful to customers.

Standard: This standard will establish a single set of patch-related terms, and mandate their use in all documentation related to patches.

Status: The standard has been completed and adopted companywide. All current and future documentation will use the standard terminology. Although we don't plan to revise previously published documentation, we do regularly remove outdated and expired content, which will have the effect of eventually bringing all documentation into compliance with the standard.

More information: The standard taxonomy is described in Microsoft Knowledge Base article 824684

Knowledge Base Article Format

Issue: Every Microsoft security patch is accompanied by two documents: a security bulletin and a Knowledge Base article. Security bulletins have long had a standardized format, but Knowledge Base articles have been relatively free-form. Developing a detailed, standard format for Knowledge Base articles will enable us to minimize the overlap between the two documents, and ensure that customers can easily find the information they need to manage patches.

Standard: This standard will establish the role, format and content of Knowledge Base articles published in conjunction with patches. In brief, Knowledge Base articles will focus primarily on the patch – how to install it, verify its successful installation, troubleshoot problems, and so forth – while security bulletins focus primarily on the security vulnerability that necessitated the patch.

Status: The standard has been completed and adopted companywide.

More Information: A description of the new format is discussed in Microsoft Knowledge Base article 824689.

Patch Naming

Issue: Patches are distributed in the form of files called packages. Historically, each product team has set its own standards regarding how it names the package. Adopting a common patch naming standard that conveys basic information about the patch will make it easier for customers to confirm that they have the right one.

Standard: The standard will establish a common naming convention for all patch packages, providing information such as the product the patch applies to, the language the patch was developed for, and a reference to the Knowledge Base article that describes how to use it.

Status: The standard has been completed and adopted companywide.

More information: The standardized naming convention is described in Microsoft Knowledge Base article 824685.

Property Page Use

Issue: Windows supports the use of "property pages" associated with files. The property page, which can be viewed by right-clicking on the file and selecting "properties", provides the creator of the file with a location in which to record brief information for users. Until now, most patches have not included information in their property pages, and even in cases where they have, the content has been left to the discretion of the team that created it. Populating the property pages consistently with meaningful information will improve customers' ability to confirm that they have the latest version of the patch and are installing it on the right platform.

Standard: The standard will require that all patches use the properties page, and populate it with a standard set of information including the version number, creation date, and the product (and service pack) on which it can be installed.

Status: The standard has been completed, and product teams are changing their engineering processes to comply with it.

More information: The use of the properties page is discussed in Microsoft Knowledge Base article 824686.

Add/Remove Programs Use

Issue: Many products' patches, as part of their installation process, create an entry in the Add/Remove Programs list (which can be accessed via the Control Panel). However, this is not universally done, and even when done, it's not always done in a uniform way. Standardizing the use of the Add/Remove Programs list will make it easier for customers to confirm which patches they have installed, as well as making it easier for customers to uninstall them if needed.

Standard: This standard will mandate a single, consistent way of recording a patch in the Add/Remove Programs list. As a longer-term effort, we are also examining whether it may be appropriate to develop a repository of information that would be dedicated solely to patches.

Status: The standard is currently under development.

Technology and Engineering Practices

Historically, Microsoft product teams have been free to develop their own technologies and engineering processes, as a means of enabling them to explore better solutions to the technical challenges they face. However, in some cases, clearly superior technologies and processes have emerged, and the time is right to standardize on them.

Installer Convergence

Issue: Architectural differences among Microsoft products can, in some cases, necessitate differences in the way patches must be installed. A number of different technologies have been developed for installing patches, each associated with one or more products. However, each has unique characteristics that an administrator may need to be aware of in order to use it effectively. Reducing the number of installers, and converging on a minimum set, offers the prospect of dramatically reducing the burden of patch management.

Standard: This standard will mandate that all Microsoft patches use either of two installer technologies:

The Windows Installer (also known as MSI), which will be used by patches for most applications.
Update.exe, which will be used by patches for Windows operating system components and a small number of applications.

Status: This standard has been completed, and is being adopted. Most applications will migrate to the Windows Installer shortly after MSI 3.0 is released (expected in the second quarter of 2004). Most operating system components already use Update.exe. Full convergence of all products onto these two installer technologies is expected no later than end of 2004. Long-term, a future version of Windows will introduce an installer technology that all patches, for all products, will eventually use.

More information: Information on the Windows installer is available at https://msdn2.microsoft.com/en-us/library/Aa372866.aspx

Patch Size Reduction

Issue: The size of a patch can significantly affect its uptake, especially in cases where users have limited bandwidth or they're charged according to the amount of data they download. One factor that determines the size of a patch is whether debug symbols are included in it. These symbols are important to the engineering and quality control process, but are not needed to install and use the patch. Removing them will allow faster patch downloads, and should encourage patch uptake.

Standard: This standard will mandate that all debugging symbols be removed from patches before they are released. Customers who need debugging symbols can obtain them from Microsoft Product Support Services, as discussed in Knowledge Base article 311503.

Status: The standard has been completed, and has been adopted companywide. In addition, new technologies are being developed that will further reduce patch size, in some cases dramatically. As these technologies approach maturity, we'll provide additional information on them.

Behavior Changes

As discussed above, Microsoft has a major effort underway to reduce the number of installer technologies we use. Doing so will, by itself, help to standardize the patching experience. However, while this migration is happening, several other initiatives are in progress to minimize the differences in the way our current set of installers operate, and provide a more consistent user experience.

Installer Options and Flags

Issue: Each installer technology supports a unique set of run-time options, selected via "flags" that are included in the command line. For instance, one installer might provide an option that allows the user to suppress dialog messages during installation, and it might be invoked via the "/q" (for "quiet") flag; another installer might also provide an option to suppress dialog messages, but it might be invoked via the "/s" (for "silent") flag and operate slightly differently. Providing a common set of options that all installers support, invoked via a standard set of flags, will significantly reduce the management burden faced by systems administrators who use scripts to deploy patches en masse.

Standard: This standard will establish a uniform set of run-time options that all installer technologies will support, and specify the flags associated with each. To avoid disruption to customers whose existing scripts use the current run-time options, the installers will continue to support the current options and flags in addition to implementing the new ones.

Status: The standard has been completed, and is being adopted.

More information: The set of standard options and flags is discussed in Microsoft Knowledge Base article 824687.

Installer Return Codes and Log Entries

Issue: The situation regarding installer return codes and log entries parallels that of installer options. Each installer technology has a unique set of numeric codes that it uses to indicate whether the installation completed successfully. Likewise, they vary in their use of log files that provide more verbose diagnostic information. Establishing a uniform set of return codes, and a consistent pattern of usage for log files, will simplify the job of deploying and troubleshooting patches.

Standard: This standard will establish a uniform set of return codes and log entries that all patch installers will use.

Status: This standard is under development.

Uninstall Support

Issue: Among the most frequent feedback from system administrators is that patches be uninstallable – that is, it should be possible for the administrator to remove the patch if needed, and restore the system to its pre-patch state. Many product patches are already uninstallable (Windows is the best example), but this is not the case for every product. Providing an across-the-board ability to uninstall security patches should improve the speed with which system administrators can deploy them. This capability would allow administrators to deploy the patches after less lengthy pre-deployment testing in the knowledge that the patch can be easily removed if a side effect is discovered later.

Standard: This standard will require all patches to be uninstallable.

Status: This standard has been completed, and is being adopted.

Patch Registration

Issue: Microsoft (and many third party vendors as well) offers security management tools to help administrators ensure that their systems are fully patched. In general, these tools operate by examining the system for tell-tale signs left by each patch as it was installed. Examples of the types of data commonly used to identify the patches on a system include entries in the system registry, date/time information on patch files, and the names of the files themselves. Consolidating the operation of patch installers to record consistent types of information in well-defined places will let security management tools operate more effectively.

Standard: This standard will establish a place where patches register their presence on the system, and will define the registration data that patches will record there.