Share via

PSS MSI RFC Triage for Thursday October 27th, 2005

  • Article

Context:

Second installment of general notes from the PSS MSI RFC Triage weekly conference call. For further context, see the first installment.

Question 1

I’ve got a question in regards to ProductValidateFlags and patching in MSI 3.0. To frame the question, here’s a sample scenario:

Let’s say I have a product and patch set RTM, QFE1, QFE2, SP1, where all upgrades target RTM. 0x922 was used as my ProductValidateFlags setting when generating the patches. If I install SP1 directly on RTM to bring my Installed version to 1.1.0.0 and then install QFE1 or QFE2, patch sequencing allows me to do this successfully.

I am assuming that it is the patch sequencer that first orders the patches logically and then makes the product version relationship comparison (Installed vs. Base) against a “virtual” Installed version (in this case RTM’s version).

Is this correct? The reason I ask is that even though MSITRANSFORM_VALIDATE_NEWEQUALBASEVERSION is set, this scenario behaves like MSITRANSFORM_VALIDATE_NEWGREATEREQUALBASEVERSION.

Answer 1

QFE1 and QFE2 are applicable to RTM, and they will be applied because SP1 does not supersede them.

For more details, refer to Windows Installer 3.0 Patch Sequencing Whitepaper Section named The Sequencing Process (page 15):

The Sequencing Process

The actions MSI takes when sequencing patches can be broken down into a few core steps.

  1. Create a framework of ProductVersion values.
    As described earlier, minor update patches (which change the ProductVersion) create the framework for sequencing patches. The ProductVersion value that is created by each patch indicates the logical ordering of the patch relative to other minor update patches, so the first step in sequencing a set of patches is to examine these patches and sort them based on the ProductVersion value that each creates.
  2. Group patches by ProductVersion.
    All remaining unsorted patches do not change the ProductVersion value, and are thus small-update (QFE) patches. Each QFE indicates in its targeting data the ProductVersion values that would allow the patch to apply. This targeting data provides the next level of sequencing for the patches. The QFEs are examined and grouped by their target ProductVersion. QFEs that apply to more than one ProductVersion value are assigned to the highest possible ProductVersion value targeted by the patch. Patches which apply to no ProductVersion values are discarded as inapplicable.
  3. Group by Family within each ProductVersion.
    Once the patches have been grouped together by ProductVersion target, the MsiPatchSequence table is examined and patches are divided again into smaller groups by membership in each PatchFamily. In contrast to the grouping by ProductVersion, a patch may belong to multiple families and thus may be placed in several family groups.
  4. Sort each Family group.
    Members of each family group are then sorted by their sequence value. Patches which belong to multiple families are sorted independently in each family.
  5. Combine Families in each ProductVersion.
    The sorted families within a ProductVersion are then combined to generate a single ordered list for the ProductVersion value. Patches which belong to multiple families are cross-referenced to ensure that the final ordered list includes the sorting results from all families.
  6. Combine ProductVersion groups.
    Next, the sorted groups for each ProductVersion value are combined with the minor update patches to create a single list of ordered patches which apply to the product.
  7. Eliminate superseded patches.
    Finally, the relationships between patches are evaluated to determine whether one or more patches are no longer required. Patches which are no longer needed are marked as “superseded” and will no longer apply to the product, although they remain applied to the product in case they are needed in the future.

Question 2

I Noticed in a log file a line beginning with MSI (a), I know MSI (c) is Client and MSI (s) is Server but what is MSI (a)?

Answer 2

The (a) is for CustomAction Server.

Question 3

My customer is running a CustomAction in the InstallUISequence that uses MsiInstallProduct to launch another MSI package, is this a Nested Installation?

Answer 3

No. By definition, it is not a nested installation. It is not a nested installation because it's not a nested custom action and additionally it does not end up having a parent/child relationship after installation. Among the other issues your customer will face include:

  • They will not be able to install silently as the UI Sequence does not run and therefore his 2nd MSI would not run.
  • They will not able to install using Group Policy and the SMS may not work in all scenarios

Question 4

Is there something akin to MSI 3.0's patch supersedence in MSI 2.0? We've got a requirement to operate on MSI 2.0.

Answer 4

No, not directly. The closest in MSI 2.0 is obsoleting patches set via the Revision Number summary information stream property. You can do this in the PCP file by using the ListOfPatchGUIDsToReplace property in the PatchWiz.dll Properties table.

Obsolescence Across Upgrade Types:

Question 5

There was this great thread asking for an Orientation to Patching software under UAP/LUA.

Answer 5

Dig into https://forums.microsoft.com/msdn/ShowPost.aspx?PostID=111453 to get some great context on Patching software under UAP/LUA.

Content credit also belongs to

  • Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
  • Hem, MSI Team Dev. You can get other Hem insights about developing for Windows Installer from the Windows Installer Chat Archives
  • Nitin, Phil, Alden, and Erik, Microsoft Support Team
  • Heath, Microsoft Dev. You can get other Heath insights about developing for Windows Installer from Heath's blog

[Author: Robert Flaming]

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