Doctor Deploys Blog

What does this blog cover?

With Windows Installer 4.5 support for multi package transaction, the Windows Installer transaction boundary can span more than a single package. Additionally, UAC credential prompts are tied to a package trust boundary. This means, there can be more than one UAC credential prompt per transaction. If you want to use multi-package transactions and don’t want more than one credential prompt, then this blog is for you.

How do I author my packages to not get more than one UAC credential prompt per transaction?

Here’s what you got to do:

1.       Author MsiPackageCertificate table into the package that will be installed first in your multi-package transaction.

2.       Sign all the subsequent packages with one of the certificates listed in the MsiPackageCertificate table.

How does the MsiPackageCertificate table look like?

The MsiPackageCertificate table identifies the possible signer certificates used to digitally sign packages that are part of this product install and do not need separate UAC credential prompt to acquire admin approval. Using this table, setup authors can list the digital certificates that the packages that constitute this product will be signed with.

The table definition is listed below:

Columns

PackageCertificate
The unique identifier for this row in the MsiPackageCertificate Table.

DigitalCertificate_
An external key into the first column of the MsiDigitalCertificate Table. The row indicated in the MsiDigitalCertificate Table contains the binary representation of the signer certificate.

Could you please walk me through on how all of this fits together?

1.       User clicks on a setup.exe.

2.       Setup.exe calls MsiBeginTransaction.

3.       Setup.exe calls MsiInstallProduct to install First.msi that carries an MsiPackageCertificate table that lists the certificates that this package trusts.

4.       Windows Installer puts up a credential prompt for administrator’s consent to install First.msi.

5.       Upon admin consent, Windows Installer goes about installing the product.

6.       Setup.exe calls MsiInstallProduct to install second.msi that is signed by a certificate listed in First.msi package’s MsiPackageCertificate table. Since:

a.       Administrator trusted First.msi and

b.      Second.msi is signed by a certificate trusted by First.msi,

Windows Installer doesn’t put up any credential prompt for second.msi.

7.       Setup.exe finally calls MsiEndTransaction and commits the transaction.

FAQ

Q: Can a package that is not the first one to be installed as part of the transaction, add more trusted digital certificates for this transaction?

A: Yes. As long as the package was consented explicitly (via UAC prompt) or implicitly (trusted because it is signed by one of the trusted certificates)

Q: What will be the content of the Consent UI? Will it display the package information of the transaction information?

A: It will display just the package information. This is analogous to our behavior vis-à-vis MsiPatchCertificate table.

Q: What happens if a certificate listed in the MsiPackageCertificate table is revoked or expired?

A: Packages signed with revoked certificates will result in separate UAC prompts and cached credentials will not be used for those package installs. This is analogous to our behavior vis-à-vis MsiPatchCertificate table.

Q: Does the same behavior exist during uninstalls and re-cache reinstalls?

A: Yes. If a package carrying MsiPackageCertificate table is accepted as trusted by a UAC credential prompt then any subsequent packages (launched by embedded chainer or otherwise) signed by one of those certificates will also be considered as trusted.

Q: Can a patch add/delete certificates listed in the MsiPackageCertificate table?

A: Yes.

Q: Can a UAC compliant package add certificates?

A: No. UAC compliant packages are considered to be per-user packages; hence do not require admin credentials. So, they do not have the ability to add certificates.

Q: Can you uninstall multiple packages in a transaction with just one UAC prompt?

A: Yes. If you use the new MsiPackageCertificate table to chain trust across packages. However, there is a caveat to that. If the package has an embedded CAB then that will be stripped when it is cached on to the user’s machine. As a result, the certificate that was used to sign that package is no more valid. So, the certificates from MsiPackageCertificate table are not valid anymore and the chain of trust is broken. This causes us to put up credential prompt for all the packages that carried embedded CABs. We do understand this limitation.

[Author: Hemchander  Sannidhanam]
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.

Original post by Windows Installer Team

Why Multi Package Transaction?

Application vendors who compose their applications from multiple MSI packages should find this blog interesting. Currently Windows Installer does not provide a mechanism for installing multiple packages in a single transaction. This blog will talk about how Windows Installer has exposed the ability for multiple packages and patches to be part of a single transaction. Please go through the attached slide deck to get a high level overview of what problem space this new functionality addresses.

Overview of Windows Installer Transaction Terminology

Acquisition Phase

During this phase, Windows Installer analyzes the MSI package and the machine state and composes the list of operations that need to be performed to the system to install the package. Costing is an example of an activity that is run during this phase.

Execution Phase

During this phase, Windows Installer uses the list of operations created in the acquisition phase to change the system. As it is making those changes, it also creates a list of undo operations that it can use if the install fails. Copying the files, updating the registry keys and such are the activities performed in execution phase.

Commit Phase

This is the time when the transaction is committed to the system. For example, committing the assemblies to the GAC, or running the commit custom actions constitute this phase. Note that this is a point of no return. Any failures here are not guaranteed to be undone.

Rollback

Windows Installer supports transactional installs because it can rollback a transaction upon failure. That’s primarily because, it stores off undo operations for any changes that it makes to the system.

How can I use it?

In this section I will use several walkthroughs to bring forth how the new MsiBeginTransaction and MsiEndTransaction API work.

A simple walkthrough

1.       A setup author who wants to install multiple MSI packages as part of installing a single logical product, would request the Windows Installer service to start a transaction by calling the new MsiBeginTransaction API. By calling this API, the setup author requests Windows Installer to install subsequent packages as part of the transaction that was started by the call to MsiBeginTransaction.

2.       The setup.exe that started the transaction now calls MsiInstallProduct.

3.       Windows Installer runs the acquisition and execution phases to the MSI package that was requested to be installed. The net effect of this is:

a.       Costing actions like CostInitialize, FileCost, CostFinalize, InstallValidate are run on a per-package basis.

b.      When script execution actions like InstallExecute, InstallExecuteAgain, or InstallFinalize are run, the machine state is altered, files are copied/patched/upgraded, registry keys installed/modified and the product is published.

4.       Windows Installer defers the commit phase for the package until a later point of time. What this means is that if there are any assemblies or commit custom actions in this package, they will not be run now.

5.       The setup.exe can queue up more packages/patches to this transaction by calling API like MsiInstallProduct, MsiApplyMultiplePatches, etc.

6.       If the setup.exe is done with installing the product, it then calls MsiEndTransaction to commit and complete the transaction. At this point the commit phases of each of the packages is run in the order in which their install requests were made in steps 2 and 5 above.

This walkthrough summarizes the following aspects a multi-package transaction:

1.       Acquisition and execution phases are run on a per-package basis.

2.       Acquisition and execution happens right away. I.e., when a call to MsiInstallProduct returns successfully while running a multi-package transaction, you know that acquisition and execution phases were complete for that package.

3.       Commit level dependencies cannot exist between packages that are part of a multi-package transaction.

4.       Commit phases of all the packages that are part of a transaction are run in FIFO order. i.e., commit phase of the first package on which MsiInstallProduct was called will be run first before moving onto the commit phase of the second package.

A rollback walkthrough

1.       A setup.exe calls MsiBeginTransaction API.

2.       The setup.exe that started the transaction now calls MsiInstallProduct to install Required.msi. Let us assume this call succeeded.

3.       Setup.exe now calls MsiInstallProduct to install AnotherRequired.msi. Let us assume this call also succeeds.

4.       Now while doing some other work on its own, let us assume that the setup.exe determines that it should rollback the transaction. At this point, Setup.exe calls MsiEndTransaction to rollback and end the transaction.

5.       At this point, Windows Installer will run the rollback operations of both AnotherRequired.msi and Required.msi in that order.

This walkthrough summarizes that:

1.       Rollback can be deferred.

2.       Rollback operations are executed in LIFO order.

 Optional Package Failures

1.       A setup.exe calls MsiBeginTransaction API.

2.       The setup.exe that started the transaction now calls MsiInstallProduct to install Required.msi. Let us assume this call succeeded.

3.       The same setup.exe now calls MsiInstallProduct to install optional.msi.

4.       While installing optional.msi, let us assume Windows Installer encounters an error. This error could be either because, user canceled the install or because of some other reason altogether. In any case, Windows Installer rolls back the install of optional.msi.

5.       Based on the return code from MsiInstallProduct, Setup.exe learns that there was a failure while installing optional.msi. However, it chooses to continue the product install and disregard the failure due to the optional package.

6.       Setup.exe now calls MsiInstallProduct to install AnotherRequired.msi. Let us assume this call succeeds.

7.       When Setup.exe is done with installing the product, it calls MsiEndTransaction to commit the transaction. At this point, Windows Installer will run the commit phases of both Required.msi and AnotherRequired.msi.

This walkthrough summarizes that every package/patch install run during a multi-package transaction is optional. Failures in those API will not rollback the entire transaction.

Subsequent blogs will attempt to capture other areas of the multi-package transaction.

[Author: Hemchander  Sannidhanam]
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.

Original post by Windows Installer Team

Hello everyone –

I am pleased to announce that Windows Installer 4.5 Beta 2 is now available from the Microsoft Connect site. If you have not signed up for the beta yet, please do - we are listed as “Windows Installer 4.5″ under the “Available Connections” section of the site. If you have already joined the beta, please head back to the Connect site and download the updated bits, tools and documentation.

This is our last planned beta release before we ship, so your feedback at this stage is especially important!

Thanks.

 - Tyler

PS: Due to some unfortunate timing, the Microsoft Connect team will be rolling out a new version of the Connect site on Saturday, March 22nd and the site will not be available from 10:00 AM and 2:00 PM (PDT). If you have issues accessing the beta program afterward, please leave a comment on this thread so we can follow-up on any issues.  

[Author: Tyler Robinson]
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.

Original post by Windows Installer Team

Hello everyone! First off, I wanted to let you know that I have re-joined the Windows Installer (MSI) team as a Lead PM, so you all will be hearing a lot more from me in the future <grin>

I have a few exciting announcements to make today:

1. I know you all have been wondering what has been up with Windows Installer 4.5, and I am pleased to announce that we plan to release Beta 2 within the next few weeks. If you would like to access the beta program, please read Robert’s prior posting on this topic. There will be an announcement posted to the blog when the Beta 2 is available. Your feedback on beta 2 is welcomed and also critical in this stage of our release, as this is our last scheduled beta before we RTM.


2. We have also scheduled an MSDN Technical Chat on Windows Installer 4.5 on April 3, 2008 at 10:00 AM (Pacific). If you have not participated in these chats before, they are a great forum for you to interact directly with members of the team! Click here to add the chat to your calendar so you don’t miss it!

Please stay tuned to the blog for more exciting announcements coming soon …

[Author: Tyler Robinson]
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.

Original post by Windows Installer Team

Back on September 1st, I answered the question When will Windows Installer 4.5 be RTM-ed? with Q1 of 2008.  Turns out that date was too optimistic.  Q2 of 2008 now looks more realistic but, given the first optimistic mistake and in an abundance of caution to avoid compounding the first mistake, let’s call just it Q2-ish. 

For those of you wondering what happened, we’ve had a number of unexpected setbacks that required we either 1) cut features 2) reduce quality efforts, or 3) take more time.  Taking more time is the best option available.  We had believed until just recently that we could make the date but our best intentions did not hold up.

For those of you that also ship software for a living, the story of this slip may be familiar.  Our chief mistakes were inadequately allocating time for a) unfilled positions, b) responding to user and partner feedback, and c) crossteam dependency execution.  Through the cycle we saw these in small increments but it wasn’t until the entry point for our Q1 glide path was missed that we realized the small increments were compounding.

As of the end of November, we’re hard at working down our backlog of knowns.  My reluctance to “set” a new date is because I’m not sure we’ve accounted for enough of the unknowns.  ‘Once bitten, twice shy’ as the old saying goes. ;^) 

We’ll have another project status update before the end of Q1 2008. 

Original post by Windows Installer Team

A question been raised in a couple of contexts is the protocol for shipping a beta on beta software.

Question
What is the protocol for shipping beta software that depends on Windows Installer 4.5 beta?

Answer

We encourage producing a beta software that integrates the features of Windows Installer 4.5 beta.  There is no license that allows redistributing the Windows Installer 4.5 beta.  This does lead to the challenge of how to release a coupled beta.

During the Windows Installer 4.5 Beta period, the most resilient design is to enable the features for Windows Installer 4.5 on a “lights up” basis.  This means that when Windows Installer 4.5 is present on the machine, the software include the new enhancements and when it is not, there is a fallback path that works on the shipped versions of the Windows Installer.  This is a bit more work but customers report they benefit from this flexibility.

For our mutual customers that want to try both your beta software and the Windows Installer 4.5 beta together, we ask that you point your customers to our beta site on http://connect.microsoft.com.  While we recognize is a bit of an additional hassle, we’ve found that beta customers are more resilient than most to the hassles of a beta.  Further, this enables problems found in the Windows Installer 4.5 beta to be directly reported and reported and tracked through the http://connect.microsoft.com tools.

Some have noted a practice in other parts of Microsoft called a “go live” license.  The terms of a “go live” license are such that they do not Windows Installer 4.5 beta case.  The coupled beta approach with “lights up” functionality and a redirect to the Windows Installer 4.5 beta site on http://connect.microsoft.com is the preferred solution.

[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 http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Our friends with WiX (principally blogger Rob Mensching) had some questions about the schema changes.  One of those questions was:

Question:
Will there be an updated ICE and _Validation table that supports the schema changes?

Context:

Windows Installer 4.5 supports adding a new bits

• 
  
  CustomAction table, Type column, msidbCustomActionTypePatchUninstall bit


• 
  
  Component table, Attribute column,msidbComponentAttributesUninstallOnSupersedence and msidbComponentAttributesShared bits  

Which breaks ICE 45 and is out of range of the existing 4.0 _Validation table.

Answer:

Yes, we do have updates to our SDK Tools before we call development complete.  We have planned for this work to happen after the engine changes are complete.  Our habit is to make sure the engine changes are complete before we shift to SDK tools.

[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 http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Our friends with WiX (principally bloggers Rob Mensching and Heath Stewart) had some questions about the schema changes.  One of those questions was:

Question:
Did you really mean to build a patching feature that we can’t patch to because of a schema change?

Context:

Windows Installer 4.5 supports adding a custom action that will run during patch uninstall.  For beta, this was accomplished by adding a new bit msidbCustomActionTypePatchUninstall to the CustomAction table.  Given the value of the bit msidbCustomActionTypePatchUninstall is 0×8000, it means the schema for the Type column of the CustomAction table changes from i2 (the integer column data type) to i4 (the double integer column data type)

Answer:

Thanks for bringing this to our attention.  No, this was not our intent.  As I recall, the change from an attribute bit in the i2 range to the upper half of the i4 range was a side effect from a bug fix.

Thanks for the suggestions to have a separate table or an separate “Ex” column in the same table.  These are both quality ideas for enabling supporting patching in this patching feature. 

Development is considering this feedback and is formulating their solution.

[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 http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team