So, we’ve covered the basics of the Installer, created a package and deployed it. So far, so good, but what happens if the application needs updated? Well, here are some things to think about with regard to patching. Enjoy.
Rule 40: Use Installer Version 3.0 or Later
One of the main objectives of MSI3.0 was to improve application servicing. There are many new features such as sequencing and obsolescence that greatly aid in patching installed applications.
Rule 41: Design and Test Your Servicing Strategy Before You Ship the Initial Product
You must know in advance how you’ll be updating your product, and once it’s shipped it’s too late to change its design. So build and install your product, then create an update (a minor update, a major upgrade, whatever you’ll be using) and make sure that it works.
Rule 42: Author Packages to Avoid Source Requirements During Patching
One major problem with patching previously was that the original source files were required to install the patch. With MSI3.0 this requirement was reduced, but not eliminated. You can help yourself by authoring your packages and patches from the start in a way that reduces dependence on the source files. Here are some tips on doing this:
Rule 43: Think carefully about Merge Module Patching
Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. Since the setup author who owns the MSI doesn’t own the merge module, they have no way to deliver fixes to issues that are found in the merge module, unless the merge module owner makes them available. On the other hand, the owner of the merge module has no way of delivering the fixes directly to the clients who installed the MSI built after consuming his/her merge module. The bottom-line of the story here is:
Rule 44: Avoid Patching Aministrative Installs
Administrators are strongly advised to keep administrative install points as pristine images. Here are a summary of problems you can encounter if you decide to use administrative patching:
Rule 45: Use Least Privileged User Account (LUA) Patching if Possible
LUA patching enables you to identify digitally-signed patches that can be applied in the future by non-administrator users, provided the following conditions are met:
Rule 46: Use the Correct Type of Patch for the Job
The Windows Installer supports a number of classes of patch, each suited for a different task. Use the appropriate one for a given situation. The types are:
Rule 47: Let the patch authoring environment handle sequencing if possible
In most cases, patches for a product fall in a single patch family, and the sequence values in that patch family increase over time. This design idiom is so common that most authoring environments that support patch sequencing automatically create sequencing metadata that fits this design.
Rule 48: Use a single PatchFamily per product unless specific requirements exist for more than one family
For most products, a single patch family provides enough flexibility to sequence patches. When multiple patch families are used, the complexity of authoring increases. If the additional functionality provided by multiple patch families is not required, you can avoid the unnecessary authoring work.
Rule 49: Follow the guidelines for patch families whenever possible
The guidelines for defining patch families are designed to reduce the complexity of patch authoring and patch management. Following the patch guidelines results in fewer authoring errors and simpler sequencing behavior.
Rule 50: Use meaningful names for patch families
Because patch family names have no meaning except as unique identifiers, use a meaningful name that indicates something about the servicing model (whether it is the target product identity, the updated functionality, the company name, or something meaningful to the patch author.)
Rule 51: Always skip numbers in the fourth field
By skipping numbers in the fourth field between consecutive patches, future patches can be sequenced between existing patches. If patch A is 188.8.131.52 and patch B is sequenced with 184.108.40.206, a future patch could, if required, be sequenced as 220.127.116.11. Using fewer than four fields in the sequence number also ensures that space exists between two consecutive patches.
Rule 52: Do not try to extract data from a patch sequence number
Although sequence numbers may be based on other data about the patch or target product, the algorithm used to generate the sequence number varies from authoring environment to authoring environment. In other cases, the algorithm may be ignored completely to achieve the desired sequencing behavior. Attempting to extract data from a sequence number may result in invalid data.
[Author: Richard Macdonald]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.