Jaa

Tao of the Windows Installer, Part 4

  • Artikkeli

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.

Series links:

Patching 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. In addition, from a system administrators point of view, one key improvement is the ability to remove patches. Prior to Installer v3.0 patches could not be uninstalled without removing the parent application. This is no longer the case. Note that you should update the Installer before you deploy any applications or patches, as upgrading afterwards does not make already installed patches uninstallable. If this is not possible, then still author patches for MSI3.0. While they won’t be able to take advantage of the new features, they are fully backward compatible and won’t need changed once you do upgrade.
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:

  • Use binary delta patching. You can patch efficiently by just targeting baselines (RTM, SP1, SP2, etc.).
  • Ensure that none of your custom actions access the original source location.
  • Ensure that the ResolveSource action is conditionalized so that it only runs when needed, or alternatively is not present at all.
  • Populate the MsiFileHash Table for all unversioned files. Msifiler.exe can easily do this for you.
  • Ensure that all files have the correct version and language information. Msifiler.exe can easily do this for you.
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:

  • Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive
  • Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup

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:

  • Deployment latency. Once the admin image is updated a reinstall command must be invoked on all clients. Before this occurs clients remain in the infamous client/server out of sync state where they can not utilize the admin image.
  • Lack of Inventory. Applying a patch to an admin image does not stamp the image with information about the patch. It simply updates the files and MSI. Thus clients have no way to determine and report on which updates they’ve consumed from admin images.
  • No Undo Support. Reverting an admin patch from the admin image is not supported by Windows Installer.
  • Patch Mixing Issues. Since there is a lack of information on what patches were applied on the admin image, sequencing patches applied on the admin image and those applied on the client side is impossible. Also, the availability of a previous version file is required for binary difference patches to work. But, when a client is synced up to an image that has been admin patched, most binary patch applications fail since, most binary patches target the RTM image.
  • Performance. The admin patching model suffers from higher bandwidth usage and lack of change delta information. Bandwidth is increased because an entire new MSI package must be downloaded as well as individual source files, increasing both overall download size and latency as compared to a client patch. Precise change delta information is missing because the admin image is modified in place, forcing clients to perform brute force reinstalls to ensure they are brought up to date.
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:

  • The application was installed on Windows XP using Windows Installer 3.0 or later
  • The application was originally installed per-machine
  • The application is installed from removable media, such a CD-ROM or DVD disk. This requirement has been removed in Windows Vista.
  • The MsiPatchCertificate table is present and populated in the original package
  • Patches are digitally signed by a certificate listed in the MsiPatchCertificate table
  • Patches can be validated against the digital signature
  • LUA patching has not been disabled by setting the MSIDISABLELUAPATCHING property or the DisableLUAPatching policy

The limitation that the original source location must be removable media limits the usefulness of this in a corporate environment and it is really aimed at home users who are patching software they installed from a retail CD. However, if this applies to you, then using this method gives you more flexibility in your patching.

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:

  • Small Update. These change one or more application files that are too minor to warrant changing the product code. A small update is also commonly referred to as a hotfix.
  • Minor Upgrade. These make changes to many resources. A minor upgrade can be used to add new features and components but cannot reorganize the feature-component tree. Minor upgrades provide product differentiation without actually defining a different product. A typical minor upgrade includes all fixes in previous small updates combined into a patch. A minor upgrade is also commonly referred to as a service pack (SP) update.
  • Major Upgrade. These are comprehensive updates of a product that needs a change of the ProductCode Property. A typical major upgrade removes a previous version of an application and installs a new version.

There are different limitations and requirements for each patch type. Refer to the SDK for details.

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 1.2.3.100 and patch B is sequenced with 1.2.3.200, a future patch could, if required, be sequenced as 1.2.3.150. 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 https://www.microsoft.com/info/cpyright.htm.

Comments

  • Anonymous
    June 27, 2006
    The comment has been removed

  • Anonymous
    July 03, 2006
    An off topic question I wanted to ask long ago, but missed the spot to do it...

    What in the world is Windows Installer doing when it says preparing to install?  Is it getting psyched up?  I have a 1.3GB single file .msi that takes over 5 minutes preparing to install...seems a bit excessive.

  • Anonymous
    July 08, 2006
    I recently noticed a series of in-depth articles that have been posted on the Windows Installer team...

  • Anonymous
    July 12, 2006
    I ihing your msi file (1,3 GB) ist too large. You schould make many small (100 mb) cabs file.

  • Anonymous
    July 19, 2006
    As an off topic suggestion, I think Windows Installer Team can now publish a book for Windows Installer Technology. This will help many enthusaists Developers and Deployers understand the process from someone who designed and developed the tool. Best would be "Understanding & Working with Windows Installer 4.0 and popular OS Platforms".

  • Anonymous
    July 20, 2006
    Generally, the larger your MSI file the longer it will take to initialize the engine. The best suggestion to reduce initialization time is to reduce the size of your MSI package.

    --------

    Unfortunately, there aren't any plans for the Windows Installer Team to write a book. However, there are many books already available on the Windows Installer. I highly suggest taking a look at the book list at www.installsite.org.

  • Anonymous
    September 18, 2006
    Well, here we are with the last part in this series, where we'll be looking at security in relation to...

  • Anonymous
    September 18, 2006
    Well, here we are with the last part in this series, where we'll be looking at security in relation to...

  • Anonymous
    October 04, 2006
    PingBack from http://929.hu/blog/?p=113

  • Anonymous
    October 16, 2006
    Windows Installeriga on küllaltki keerukas algajal otsi lahti teha. Mul endalgi on üks installer käsil ja tänu keerukamale funktsionaalsusele, mida see peab pakkuma, tuli ka rohkem süveneda Windows Installeri hingeellu. Leidsin internetis ringi tu...

  • Anonymous
    October 30, 2007
    Today, Macrovision Corp. notified customers of FLEXnet Connect® (formerly called InstallShield Update

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/2822463-windows-installer-3-x-patching