One of the attractive features of Windows Installer si the ability to patch existing product installations with updates. The concept is simply that an upgrade or patch will often only alter a few registry keys or files within an earlier installation. With only a subset of files or registry entries being altered, it should be possible to just roll out the changes to an existing installation to achieve the same thing as rolling out a brand new version of the file.
When creating a patch, rules must be followed to ensure that changes will be applied to a target workstation correctly.
- Do not move Features
- Do not change Component Codes
- Do not change the key path for Components
- Adhere to the rules surrounding ProductCode, Version and PackageCode
To be able to patch existing installations of a product, we must have a functioning upgrade for an MSI (as discussed in the previous section)
Creating Patch Packages (MSP)
Patch packages are not for the faint hearted and a working knowledge of Windows Installer is required. The files needed for making a patch package can be found in the Windows Installer SDK.
A Patch package contains:
- Two Transforms. One Transform will be applied to a target installation, the second to a target installer (such as an administrative install point).
- New files that are to be added to an existing installation
- Files that replace existing files on an older installation
The template (within the SDK) for creating a Patch package is called Template.PCP and is editable with Orca. An example (Example.pcp) is also included within the SDK.
Patch Creation package (PCP)
Must contain the tables listed below:
Properties Table
ImageFamilies Table
UpgradedImages Table
TargetImages Table
The following database tables are optional:
UpgradedFiles_OptionalData Table
FamilyFileRanges Table
TargetFiles_OptionalData Table
ExternalFiles Table
UpgradedFilesToIgnore Table
… more to come on these workings in the future.
Problems with using Patches
Patches are a great idea for commercial software vendors. They provide a method for customers to easily correct identified bugs or small changes within applications.
Utilising or creating patches within a corporate environment is a lot more difficult and adds a large degree of complexity to Application Management.
As patches alter the file table, any production machine that misses the application of required patch will result with an application that cannot be patched. Each application must have patches applies sequentially. In an Administrative restore point is patched, unlatched clients that point to the pre-existing directory location for healing will now be unable to use the altered Source for that function.
Patches are designed to increment the version of an in-place application. Most corporate environments will endeavour to utilise naming formats that reflect the version of the application installed. Changing the version number of these applications causes a massive increase of complexity in managing the Application environment.
There can be situations where the patching feature may be of great value but most organisations will discover that trying to patch existing installations of applications is too prone to mistake and destruction of standardisation within the Application Environment. When application updates are released, a new package with a new name that represents the incremented version of the application should be released and older versions of the application should be uninstalled and replaced.
Applying vendor supplied patches (MSP’s)
Patches (MSP’s) were designed to be applied to either Administrative install points or directly onto machines installed with earlier versions of the application. To update an existing installation of an application, utilise the syntax:
Msiexec /u Patchname.msp
Applying a patch to an administrative install point is achieved with the syntax:
Msiexec /a “Location of Administrative MSI” /p Patchname.msp
The theory for using Administrative installs is a good theory that now has problems due to Microsoft’s technical direction. New versions of Microsoft products will create their own local cache of files for application repair (Office applications being the best example). This local cache is really important for stability of remote users. This local cache will not be created if an Administrative install has been used.
- Log in to post comments