Patch Packages
A Windows Installer patch (.msp file) is a file used to deliver updates to Windows Installer applications. The patch is a self-contained package that contains all the information required to update the application. A patch package (.msp file) can be much smaller than the Windows Installer package (.msi file) for the entire updated application. For more information about delivering smaller updates to applications, see Reducing Patch Size.
A patch package contains the actual updates to the application and describes which versions of the application can receive the patch. Patches contain at minimum two database transforms. One transform updates the information in the installation database of the application. The other transform adds information that the installer uses for patching files. The installer uses the information provided by the transforms to apply patch files that are stored in the cabinet file stream of the patch package. A patch package does not have a database like an installation package (.msi file.)
Beginning with Windows Installer version 3.0, patch packages can contain information that describe the patching sequence for the patch relative to other updates in the MsiPatchSequence table and additional descriptive information in the MsiPatchMetadata table.
Users can install applications and updates from a network administrative image. Although patch packages can be applied to administrative installations, the recommended method to deliver updates is to have users install the original application and then apply the patches to the local instance of the application on to their computer. This keeps users in synchronization with the administrative image. If a patch is applied to the administrative installation, all clients of that administrative installation must recache and reinstall the application to receive the update. Until a user recaches and reinstalls, the user is unable to install-on-demand and repair installations from the patched administrative installation.
Beginning with Windows Installer 3.0, non-administrators can apply patches to per-user-managed applications after the patch has been approved as trusted by an administrator. For more information on how to do this, see Patching Per-User Managed Applications. Another method is to use least privileged user account patching.
If the AllowLockdownPatch policy has been set, non-administrator users can apply a patch to an existing application while running an installation at elevated privileges. This method is not recommended because it enables untrusted patches to be applied to an application that can run with elevated privileges.
Patch packages are comprised of the following parts. For more information about the construction of patch packages, see Creating a Patch Package.
Summary Information Stream
The summary information stream of the patch package provides information about the identity and purpose of the patch.
The summary information stream holds a minimum of the following:
- A GUID that uniquely identifies the patch. The GUID for this patch is appended with a list of GUIDs for earlier patches that are replaced by this patch.
- A semicolon-delimited list of product codes for valid targets for this patch.
- A semicolon-delimited list of transform substorage names in the order they are to be processed.
- A semicolon-delimited list of sources for this patch.
Transform Substorage
A patch package contains transforms that can add or remove files, registry entries, user interfaces, and customizations. Transforms are included as substorages in the package. A patch package contains two transforms for each target database. One transform is the actual updates to the installation database and is generated from the differences between the original and updated images of the installation package. The other transform adds entries to the Patch, PatchPackage, Media, InstallExecuteSequence, and AdminExecuteSequence tables. Information in the substorage ties it to a specific UpgradeCode, ProductCode, ProductVersion, and ProductLanguage. A patch package that can be applied to multiple targets contains more than one pair of these transforms.
Cabinet File Stream
The cabinet file stream included in a patch can contain these types of files:
- Patch files containing the information required to change the old version of the file into the new version. A single patch file can be used to update one or more old versions of a file.
- Additional files being added to the application that are not present in the old version.
- An entire replacement file. In the rare case where the new version of a file is smaller than the patch required to update the old version of that file, the new file can be included in its entirety. These are new files that are installed over their old versions.
Uninstallable Patches
Whether a patch can be uninstalled depends upon how the patch was authored, the version of Windows Installer used to install the patch, and the changes made by the patch to the application. If a patch is not uninstallable, then the only way to remove the patch is to uninstall the entire application and reinstall without applying the patch being removed.
You can call for the uninstallation of patches applied with Windows Installer version 3.0 by using Command Line Options, the MsiRemovePatches function, or the RemovePatches method as described in the Uninstalling Patches section. The Windows Installer verifies that each of the patches listed for removal in the MSIPATCHREMOVE property is uninstallable. If the user does not have privileges to remove the patch, the patch is unknown for the product, patch policy prevents removal, or the patch was marked as not uninstallable, the installer returns an error indicating a failed installation transaction.
Windows Installer 2.0: Not supported. Patches applied using a version of Windows Installer that is earlier than Windows Installer 3.0 are not uninstallable.
Patches that are Not Uninstallable
A patch (.msp file) applied to an installed application is not uninstallable in the following cases. The only method to remove a patch that is not uninstallable is to uninstall the patched application and then reinstall the application without reapplying the patch. In this case, you must reapply any patches that you do not wish to be removed from the application.
Patches applied using a version of Windows Installer that is less than Windows Installer 3.0 are not uninstallable.
Patches applied to applications installed on a computer that has had the DisablePatchUninstall policy set by an administrator are not uninstallable. When this machine policyhas been set, no patches on the computer can be uninstalled, even by an administrator.
Patches that do not have a MsiPatchMetadata table in their database are not uninstallable.
Patches that do not include the following row in their MsiPatchMetadata table are not uninstallable. The patch is not uninstallable for other values of Company, Property, and Value.
| Company | Property | Value |
|---|---|---|
| AllowRemoval | 1 |
The patch has been applied to an application installed in a context for which the user has insufficient privileges to uninstall patches. The words «Not Allowed» in the following table indicate that an administrator or non-administrator user cannot uninstall patches from patched applications installed in this context. The word «Allowed» in this table means that privileges do not prevent an administrator or non-administrator user from uninstalling patches, however for any of the other reasons discussed in this section, it still might not be possible to uninstall the patch.
| application Installation Context | Administrator Uninstall of Patch | Non-Administrator Uninstall of Patch |
|---|---|---|
| Per-Machine | Allowed | Generally Not Allowed The only exception is if the patch was applied using (LUA) patching. A patch marked as a LUA patch is uninstallable by either administrators or non-administrators. LUA patching is only available for packages installed per-machine from media and require special authoring. |
| Per-User Non-Managed for Current User | Allowed | Allowed |
| Per-User Non-Managed for Different User | Not Allowed | Not Allowed |
| Per-User Managed for Current User | Allowed | Not Allowed |
| Per-User Managed for Different User | Not Allowed | Not Allowed |
A major upgrade applied by a patch is not uninstallable. Major Upgrades of an application should be performed by installing the upgraded application (.msi file) rather than a patch.
Patches applied to an administrative installation are not uninstallable. Patching administrative installations is not recommended. The current set of patches should be applied on the user’s computer after the user installs the application from the administrative image. This can prevent the package code cached on the user’s computer from becoming different than the package code on the administrative installation. If the package code cached on the user’s computer becomes different from that on the administrative installation, reinstall the application from the administrative installation and then patch the client computer.
When a patch adds new content to any of the tables in the following list, Windows Installer marks the patch as being not uninstallable. An uninstallable patch can add new files, assemblies, registry entries, components, or features to an installation by adding new rows to database tables that are not included in this list.
Resources
Installing Updates in Windows
There are two ways to install Microsoft supplied critical updates under Windows, manually, via Windows Update, or automatically, via .
To manually check for and install updates to Windows XP, log on to an administrative account on your machine. Go to start > All Programs > Windows Update .
Internet Explorer will start and go to Microsoft’s Windows Update web site. The site will first check for updates to the Windows Update program.
If this site has never been visited from your computer, it will probably want to install an update to the Windows Update program.
Click Yes to accept the update.
Following the update, or if no update is found, the following screen will appear.
Click Scan for updates . The machine will be scanned, and if there are updates available that have not been installed, a screen like the following will appear.
Click Review and install updates . This review will include all the updates classified by Microsoft as Critical Updates and Security Patches . The following screen will appear.
Review the list of updates, and if there is a valid reason not to install one, click the Remove button for that update. Click the Install Now button. A license agreement will pop up.
Click the Accept button. While the update downloads and installs, you will see a window similar to the following.
If you are prompted to reboot the computer when the installation is complete, click OK .
The process of manually checking for and installing critical updates should be done on a frequent, regular basis.
Automatic Updates
To set up Automatic Updates so that updates will be automatically downloaded and installed on your machine, log on to an administrative account on the machine. Go to start > Control Panel and double click System . Click on the Automatic Updates tab.
Make sure the box is checked in front of: Keep my computer up to date. If this and the rest of the options are set but grayed out, the policy has been implemented at the domain level. You cannot override a domain policy, but you can still manually install updates.
You have three choices. They are fairly self-explanatory. If you choose one of the first two choices, a bubble will pop up in the lower right corner of your screen when updates are available to download/install. Clicking on the bubble will start the process of downloading/installing the update. However, you must be logged on to an administrative account in order to for the bubble to appear.
The third option is what is recommended — Automatically download the updates, and install them on the schedule that I specify . Once this has been set from an administrative account, updates will be downloaded and installed without even logging on, as long as the computer is turned on and booted into Windows at the scheduled time.
See Automatic Security Patches for Linux for a copy of the script and a description of the process for installing patches under Linux.
Last updated January 7, 2008, by John Luiten
Send questions about this page to
Patching
An application that has been installed using the Microsoft Windows Installer can be upgraded by reinstalling an updated installation package (.msi file), or by applying a Windows Installer patch (an .msp file) to the application.
A Windows Installer patch (.msp file) is a self-contained package that contains the updates to the application and describes which versions of the application can receive the patch. Patches contain at a minimum, two database transforms and can contain patch files that are stored in the cabinet file stream of the patch package. For more information about the parts of a Windows Installer patch package, see Patch Packages.
Servicing applications by delivering a Windows Installer patch, rather than a complete installation package for the updated product can have advantages. A patch can contain an entire file or only the file bits necessary to update part of the file. This can enable the user to download an upgrade patch that is much smaller than the installation package for the entire product. An update using a patch can preserve a user customization of the application through the upgrade.
**Windows Installer 4.5 and later:В В **
Beginning with Windows Installer 4.5, developers can mark components in a patch with the msidbComponentAttributesUninstallOnSupersedence value in the Component table. If a subsequent patch is installed, marked with the msidbPatchSequenceSupersedeEarlier value in its MsiPatchSequence table to supersede the first patch, Windows Installer 4.5 and later can unregister and uninstall components marked msidbComponentAttributesUninstallOnSupersedence to prevent leaving behind unused components on the computer. If the component is not marked with with this bit, installation of the superseding patch can leave an unused component on the computer. Setting the MSIUNINSTALLSUPERSEDEDCOMPONENTS property has the same effect as setting this bit for all components.
**Windows Installer 3.0 and later:В В **
Developers who use Windows Installer 3.0, and author patch packages that have the MsiPatchSequence table can create patch packages that do the following:
- Use the product baseline cached by the installer to more easily service applications with smaller delta patches. For more information about using the product baseline, see Reducing Patch Size.
- Skip actions associated with specific tables that are unmodified by the patch. This can significantly reduce the time required to install the patch. For more information about which tables can be skipped, see Patch Optimization.
- Create and install patches that can be uninstalled singly, and in any order, without having to uninstall and reinstall the entire application and other patches. For more information about uninstalling patches, see Removing Patches.
- Apply patches in a constant order regardless of the order that the patches are provided to the system. For more information about how the Windows Installer determines the sequence used to apply patches, see Sequencing Patches.
- Apply patches to an application that has been installed in a per-user-managed context. For more information, see Patching Per-User Managed Applications.
**Windows Installer 2.0:В В **
The MsiPatchSequence table is not supported. Beginning with Windows Installer 3.0, patch packages can contain information that describes the patching sequence for the patch relative to other updates and additional descriptive information.
The recommended method for creating a patch package is to use patch creation tools such as Msimsp.exe and Patchwiz.dll. Developers can generate a patch creation file as described in the section: Creating a Patch Package. The creation of a small update patch is described in the section: A Small Update Patching Example.
Microsoft Windows Installer accepts a Uniform Resource Locator (URL) as a valid source for a patch. For more information about how to install a patch located on a Web server, see Downloading and Installing a Patch From the Internet.
A single Windows Installer patch (.msp file) can be applied to the installation package when installing an application for the first time. For more information, see Patching Initial Installations.
It is not possible to eliminate all circumstances when the application of a patch may require access to the original installation source. However, to minimize the possibility that your patch will require access to the original source, adhere to the points listed in the following section: Preventing a Patch from Requiring Access to the Original Installation Source.
To minimize the possibility that your patch is not broken by a subsequent customization transform, typically the patch is installed first, followed by the customization. Installing customization transforms first, and then the patch, may break the customization. For more information about patching customized applications, see Patching Customized Applications.
