Windows Installer Team Blog : MSI4.5

Latest SDK for Windows Installer 5.0

Windows Installer Team — Thu, 13 Aug 2009 04:43:00 GMT

The RTM release of the Windows SDK for Windows 7 and .NET Framework 3.5 SP1 is now available for customers to install from the download center in both ISO and Web Setup format. See the SDK announcement on the Windows SDK blog.

Please note that the stand-alone version of the Windows Installer 4.5 SDK is now no longer available for download from the Microsoft download center. Windows Installer SDK has traditionally always been included with the Windows SDK, but during the timeframe for the release of MSI 4.5 redistributable there was no other Windows or Windows update release for simultaneously shipping the SDK.

We encourage you to download and use the latest version of the Windows Installer SDK tools (Windows Installer 5.0) included with the RTM release of Windows SDK for Windows 7.

[Author: Zainab Hakim]
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.

MSI 4.5 natively included with SP2 for Windows Vista & Server 2008

Windows Installer Team — Thu, 13 Aug 2009 03:44:00 GMT

As you may already know that Service Pack 2 for Windows Server 2008 and Windows Vista (SP2) is available for download from Microsoft download center [link]. MSI version 4.5 is natively included as part of SP2. The version of Windows Installer is 4.5.6002.18005 across all architectures and platforms.

If you have already installed the MSI 4.5 redistributable on your Vista or Server 2008 SP1 machine, you can upgrade to SP2 over the MSI 4.5 redistributable. After installation of SP2, the Windows Installer version on your machine will be 4.5.6002.18005. The upgrade would have no effect on the functionality provided by Windows Installer 4.5.

Other notable hotfixes for Windows Installer 4.5 also included in SP2 are;

· KB 958655 – Error message when you use Windows Installer (MSI) 4.5 to install multiple MSI packages in Windows Server 2008, Windows Vista, Windows Server 2003 or Windows XP: "API call rejected - No actions in Context".

· KB 967756 – After you uninstall some software updates in Windows Vista or in Windows Server 2008, some assembly files may still reflect the updated version instead of the original version of the files

· KB 958756 – The customized properties for an .msi package installation are reset to their default values after you install Windows Installer 4.5

Adopting Windows Installer 4.5

Windows Installer Team — Fri, 06 Mar 2009 00:25:00 GMT

It's been a few months now since the Windows Installer 4.5 redistributable was released [link]. Over the past couple months I have received several questions (quite often similar in nature) that warrants this blog post <grin>. In this post, I will attempt to answer some of the most frequently asked questions with regards to adoption & deployment of MSI 4.5.

1. I’m considering taking a dependency on MSI 4.5 for my next release. I would like to know how prevalent MSI 4.5 might be in our target environments. Do you have any data on this?

We are pleased to hear that you are considering taking advantage of the new feature set and functionality provided in MSI 4.5. We have some data that may help you understand the current penetration of MSI 4.5 in the ecosystem.

a. Statistics from the Microsoft download center:

As of March 2009, there have been over 5.6 million downloads of MSI 4.5 (combined across all supported platforms & OSes).

b. Other ways in which MSI 4.5 is being deployed to users machines:

Yes, besides the fact that users are downloading MSI 4.5 from Microsoft download center, there are also other mechanisms via which MSI 4.5 is being deployed to users machines. For example;

- SQL Server 2008 (both full server as well as express version) requires MSI 4.5 as a pre-requisite.

- This dependency in turn has a cascading effect on other products that are already dependent on SQL Server 2008 or will be in the future.

c. Future Windows service packs:

MSI 4.5 will be natively included in all future service packs of Windows. It is already included in Windows Vista and Server 2008 SP2. Release candidate for this service pack is presently available from the Microsoft download center.

2. When will MSI 4.5 be deployed via Windows Update?

MSI 4.5 will be on Windows Update as part of future service packs to Windows (see #1, part c). It will not be available independently as a required mandatory update like Windows Installer 3.1 v2.

3. Is it true that there is a forced reboot required on Windows Vista and Windows Server 2008 with MSI 4.5? Unlike Windows XP and Windows 2003, this reboot can't be deferred?

Yes, it is true that servicing Windows Installer always requires a reboot on Vista and above. The new changes made to the Windows Vista servicing stack in combination with the change made by Windows Update to always have the Windows Installer loaded, causes the update to be “pended” until a subsequent reboot thus generating the mandatory reboot requirement when servicing the Windows Installer. We understand that a reboot can be difficult to absorb for applications taking a dependency on MSI 4.5. Unfortunately, none of the solutions that could be pursued were low cost and low risk enough to be acceptable at that point in the Windows Vista SP1 and Windows Server 2008 ship cycle. However, the growing prevalence of MSI 4.5 (details provided in #1), is mitigating the reboot issue to some extent.

4. We are considering the possibility of bootstrapping Windows Installer 4.5 with our product’s setup. Is there a single 4.5 redistributable that can cover multiple OS versions and CPU architecture that is of a smaller size?

No, there is no single redistributable package to install MSI 4.5. There exist different installation technologies to install a Windows component like Windows Installer on Vista and above OSes versus down-level OSes (Windows XP and Server 2003). Additionally, the binaries itself are different based on OS version and platform architecture.

Update to MSI 4.5 (KB958655)

Windows Installer Team — Sat, 06 Dec 2008 02:59:00 GMT

Hello everyone,

We wanted to let you know that a non-security QFE was released recently for MSI 4.5 redistributable, available via Microsoft download center (Search for KB958655). The KB article contains information on the symptoms and cause of the issue. The intent of this post is to clarify some concerns/questions you may have that are necessarily not addressed via the KB article. Additionally, we will monitor this post, so feel free to post comments.

Also as noted in the KB article, you are most likely to be affected by this issue during installation of SQL Server 2008 or during upgrade from SQL Server 2005 to SQL Server 2008.

Some FAQs:

1. I already have MSI 4.5 on my machine. Do I need to install this update?

It’s optional. As mentioned above, this issue is hit only in rare cases, so it’s not absolutely critical for you to install this update.

2. Is this update applicable to all OSes and architecture types?

Yes, this update is applicable to all supported OSes and architecture types as the original MSI 4.5 redistributable. Vista RTM/SP1, Windows Server 2008, Windows XP SP2/SP3, and Windows Server 2003 SP1/SP2.

3. Is it true that on Vista & above platforms, I can install this update even if MSI 4.5 redist is NOT present on my machine?

Yes. The QFE packages for Vista & above platforms are just like a refresh to the original MSI 4.5 redist. It targets both MSI versions 4.0 and 4.5. If MSI version on the machine is 4.0, the QFE installs just like the original redist package, while if MSI version is already 4.5 then only the affected binaries are updated. So if you have not already installed 4.5, you can choose to do so by installing this QFE package directly.

4. I have removed the MSI 4.5 redistributable from my Vista machine, but why is the MSI version on my machine still 4.5?

If MSI 4.5 redist is uninstalled, the Windows Installer version on the machine will still remain 4.5 as long as this QFE is present. If MSI 4.5 redist is uninstalled followed by removal of the QFE, only then the Windows Installer version on your machine will go back to 4.0.

5. Are these changes (specifically #3 and #4 above) also applicable to Windows XP and Windows Server 2003?

No. For these Operating systems, the QFE package will only be applicable if you have already installed MSI 4.5 redist on your machine. Also if you later try to uninstall MSI 4.5, you will be warned about dependent QFEs still existing and be asked to remove these manually.

6. What is the expected version of Windows Installer after I install this QFE?

Target Operating System	Updated Windows Installer 4.5 version
Windows Vista RTM	4.5.6000.20951
Windows Vista SP1, Windows Server 2008	4.5.6001.22303
Windows XP SP2, Windows XP SP3, Windows Server 2003 SP1, Windows Server 2003 SP2	4.5.6001.22299

Windows Installer 4.5 versions

Windows Installer Team — Fri, 06 Jun 2008 22:52:00 GMT

As you all may already know the final release of the Windows Installer 4.5 Redistributable and SDK are now available.

The current version of Windows Installer is in the form; major.minor.build.update. We have received a few questions regarding the differences in the "build" and "update" fields of the version of Windows Installer 4.5 installed across different supported Windows Operating Systems . I will try to explain what these differences are and why they are expected.

The Windows Installer 4.5 redistributable can install on the following Windows Operating Systems:

Target Operating System	Windows Installer 4.5 version
Windows Vista RTM	4.5.6000.20817
Windows Vista SP1, Windows Server 2008	4.5.6001.22162
Windows XP SP2, Windows XP SP3, Windows Server 2003 SP1, Windows Server 2003 SP2	4.5.6001.22159

Windows Vista RTM build number is 6000, while Windows Vista SP1 and Windows Server 2008 RTM are build number 6001. Hence, to comply with the different OS build numbers and applicability logic on Vista RTM and Vista SP1/Server 2008 operating systems, the Windows Installer binaries are built from the Vista RTM and Vista SP1 servicing branches respectively.

The "update" field is based on the OS revision number. Since the redistributable packages to install Window Installer 4.5 on the different target operating systems are built from different Windows servicing branches, the revision number is different for each.

However, the different versions have no effect on the functionality provided by Windows Installer 4.5.

Windows Installer 4.5 is now available!

Windows Installer Team — Tue, 03 Jun 2008 19:58:00 GMT

I am pleased to announce that the final release of the Windows Installer 4.5 Redistributable and SDK are now available. There is also a KB Article published about the release.

New and improved features in Windows Installer 4.5

The following new and improved features have been implemented in Windows Installer 4.5.

Multiple package transaction

In a multiple package transaction, you can create a single transaction from multiple packages. In a multiple package transaction, a chainer is used to dynamically include packages in the transaction. If one or more of the packages do not install as expected, you can roll back the installation.

Embedded UI handler

You can embed a custom user interface (UI) handler in the Windows Installer package. This makes a custom UI easier to integrate. You can also invoke an embedded UI handler from the Add or Remove Programs item in Control Panel. Or, you can invoke an embedded UI handler during a Windows Installer repair process.

Embedded chainer

You can use the embedded chainer to add packages to a multiple package transaction. You can use an embedded chainer to enable installation events across multiple packages. For example, you can enable install-on-demand events, repair events, and uninstall events across multiple packages.

Update supersedence resiliency

This feature lets you correct for changes in the FeatureComponent table during supersedence.

Shared component patching resiliency during uninstall

This feature makes sure that the most recent version of a component is available to all products.

Custom action execution on update uninstall

This feature lets an update add or change a custom action so that the custom action is called when an update is uninstalled.

If you have any questions about the 4.5 release, please see our MSDN Documentation or other topics posted on this blog about 4.5. Additionally, we will be monitoring and responding to the comments on this post.

Thanks to everyone who helped us throughout the beta program of this release!

[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.

What changed in Windows Installer 4.5?

Windows Installer Team — Fri, 02 May 2008 00:10:00 GMT

Apart from the feature work that we did in Windows Installer 4.5, we made a few changes to Windows Installer to address some user feedback or pain points. Here's some of the important issues that were addressed:

Added SeBackupPrivilige back to the Windows Installer service. This sould help any custom actions that needed this privilige like the ones that were reported on the Vista Compatability Team blog.
Some case sensitive service name comparisions in InstallValidate used to result in an unnecessary files-in-use message on Vista. This is now fixed in Windows Installer 4.5.
When a patch added new content in the form of a new component and that patch was being uninstalled, we used to remove that content, even if that content is shared by other products. This is now fixed in Windows Installer 4.5.

In addition to this, since Windows Installer 4.5 is the latest release of Windows Installer, it will have all the fixes and feature work that we did till Vista SP1.

[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.

Join us at TechEd 2008!

Windows Installer Team — Fri, 25 Apr 2008 20:55:00 GMT

Hello Everyone --

The schedules for Microsoft TechEd 2008 in sunny Orlando, Florida have recently been posted and I am pleased to announce that we will have FOUR Windows Installer-related sessions: two during the Developers Conference June 3-6 and two during the IT Professionals Conference June 10-13.

IT Professionals Conference Sessions:

Session Title

Track

Level

Type

Speaker

Software Packaging and Deployment with Windows Installer (MSI) 4.x

Join Windows Installer Lead Program Manager Tyler Robinson, as he discusses the latest release of Windows Installer: version 4.5. In this session, the servicing and packaging agility improvements in Windows Installer 4.5 are discussed, along with their impact on common corporate deployment scenarios. Additionally, tips and tricks for deploying all types of Windows Installer (MSI) packages are discussed, with plenty of time for Q & A at the end.

Windows Client

200

BRK

Tyler Robinson

Advanced Software Distribution Tricks with Windows Installer (MSI) 4.x

Windows Installer Test Engineer Ken Wong and Lead Program Manager Tyler Robinson discuss the tools that Windows Installer 4.x adds to a system administrator’s arsenal for distributing software inside their corporation. This deep dive compliment to the “Software Packaging and Deployment with Windows Installer (MSI) 4.5” session is designed to be interactive, so please come ready with questions to be answered during the session.

Windows Client

300

TLC

Ken Wong

Developers Conference Sessions:

Session Title

Track

Level

Type

Speaker

Demystifying Installation Requirements of the Certified for Windows Logo

With the Windows Vista and Windows Server 2008 "Certified for Windows" logo program, Windows is now requiring either ClickOnce or Windows Installer as the application packaging technology. While application installation is among the top application compatibility issues for users moving to the latest Windows platform, users see fewer issues when developers have packaged their applications with an application packaging technology native to the platform. In consultation with both application installation users and subject matter experts, the Certified for Windows logo has added the most requested items to the installation requirements and test cases. In this session, former Windows Application Deployment Team (home of Windows Installer and ClickOnce) program manager Robert Flaming discusses the justification for some of the "Certified for Windows" requirements and walks through some common issues that users have had to tackle as they prepare to get their "Certified for Windows" logo.

Windows and Frameworks

300

TLC

Robert Flaming

Designing within Windows Installer (MSI) Architecture: Embracing User Account Control, Multi-Package Transaction, and Other Windows Advances via Windows Installer

User Account Control has created new challenges for ISVs creating packages for Windows. Windows Installer 4.0 and 4.5 has extended its architecture to account for the new User Account Control experiences for the most seamless integration on Windows Vista (and above). This session discusses the Windows Installer architecture and how ISVs can build packages that appropriately take advantage the architecture. This session is designed to be interactive, so please come ready with questions to be answered.

Windows and Frameworks

300

TLC

Hemchander Sannidhanam

If you plan to attend TechEd, please attend our sessions and say HI to myself, Ken, Hem and Robert!

Issues with Patchwiz.dll v4.0

Windows Installer Team — Mon, 21 Apr 2008 21:28:00 GMT

Issue Description

Performing any of the following operations using patchwiz.dll v4.0 could result in data loss in the root directory:

1. UiCreatePatchPackage is called with the hwndStatus parameter set to NULL OR

2. UiCreatePatchPackageEx is called with the hwndStatus parameter set to NULL and dwFlags set to 0x8000 OR

3. Using msimsp.exe v3.0 to create Windows Installer patches while using patchwiz.dll v4.0.

Cause

When invalid parameters are supplied to UiCreatePatchPackageEx API, it bails out with an error code. However, while returning, the API erroneously uses partially initialized data to clean up the temporary directory. This partially initialized data results in deleting the writeable data in the root drive.

Resolutions

There are four resolutions for this issue currently:

1. Do not use patchwiz.dll v4.0 to call UiCreatePatchPackage and UiCreatePatchPackageEx with these parameters.

2. Get the latest patchwiz.dll v4.5 from the Windows Installer 4.5 Beta program. The latest version of patchwiz.dll there fixes the data loss issue mentioned in this blog. However, the call to UiCreatePatchPackage with hwndStatus parameter set to NULL will fail to create a patch. We understand that this is a regression. It will be fixed in Windows Installer 4.5 RTM.

3. Use patchwiz.dll v3.1.

4. Use msimsp.exe v4.0 to create Windows Installer patches while using patchwiz.dll v4.0 or higher.

Windows Installer 4.5 Multi Package Transaction and UAC

Windows Installer Team — Fri, 04 Apr 2008 04:49:00 GMT

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:

Column	Type	Key	Nullable
PackageCertificate	Identifier	Y	N
DigitalCertificate_	Identifier		N

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 is the reason why during uninstall, credential prompt is displayed for all the packages that carried embedded CABs. We do understand this limitation.

Windows Installer 4.5 Transaction Enhancements: Multi Package Transaction

Windows Installer Team — Fri, 04 Apr 2008 02:59:00 GMT

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.

Windows Installer (MSI) 4.5 Technical Chat

Windows Installer Team — Tue, 01 Apr 2008 20:50:00 GMT

Windows Installer 4.5 chat is due in another two days. The MSDN Technical Chat is scheduled on April 3, 2008 at 10:00 AM (Pacific). Click here to add the chat to your calendar so you don't miss it!

Windows Installer 4.5 UI Enhancements: Embedded UI

Windows Installer Team — Tue, 01 Apr 2008 20:13:00 GMT

Why Embedded UI?

Windows Installer’s existing internal UI does not provide the flexibility necessary for unique setups or complex scenarios. Setup authors, who want a UI experience that Windows Installer’s internal UI doesn’t support, use MsiSetExternalUI/MsiSetExternalUIRecord to initialize and use their custom UI.

However, the custom UI can only be used from an external process that initializes the external UI before the install begins. Because of this requirement, the OS natively has an extremely limited set of scenarios in which external UI can be used. Repairs from ARP, admin installs, installations via shortcut activation never use external UI. For many teams wanting to use external UI, the bootstrapper requirement, is an onerous requirement itself. Use of the bootstrapper can also break some deployment scenarios, as software distribution has much richer support for native deployment of MSI files than for bootstrapper executables.

Windows Installer 4.5 provides support for embedded UI. This provides the package author enhanced control of the Windows Installer user interface through custom code which is bundled with the MSI file itself and without requiring complex and bug-prone workarounds to handle the various activation paths which can trigger an install. Regardless of the activation method of the installer operation, MSI will use the custom embedded UI provided within the package.

The PPT slide deck attached to this blog provides an overview of the workings of Windows Installer’s internal, external and embedded UI.

How to use it?

A setup author who wishes to use embedded UI provides a DLL that exports the InitializeEmbeddedUI, EmbeddedUIHandler, and ShutdownEmbeddedUI functions. The setup author should then include MsiEmbeddedUI table containing information about the custom DLL that handles the Windows Installer messages.

An Example

In this section we will walk through the steps involved in creating a package that uses embedded UI.

Create a Embedded UI DLL

Similar to external UI, a setup UI developer should provide an embedded UI handler. Such an embedded UI handler should export InitializeEmbeddedUI, EmbeddedUIHandler, and ShutdownEmbeddedUI functions. A template implementation of each of these functions is provided below:

int __stdcall InitializeEmbeddedUI(MSIHANDLE hInstall, LPCWSTR szResourcePath, LPDWORD pdwInternalUILevel)

{

// Use hInstall to query the install type. Ex: Is it product/patch install/uninstall?

// Use the resource patch provided in the parameter szResourcePath to read any UI resources

// Use the pdwInternalUILevel to read/write the internal UI level

if(MsiGetMode(hInstall, MSIRUNMODE_MAINTENANCE))

{

// Put up maintenance UI

}

if(ERROR_SUCCESS == MsiGetProperty(hInstall, TEXT("PATCH"), rgchValueBuf, &dwValueBuf))

{

if(dwValueBuf > 0)

// Put up patching UI

}

// Embedded UI handler will handle all the Windows Installer messages and I do not

// want to display Windows Installer’s internal UI

*pdwInternalUILevel = INSTALLUILEVEL_NONE;

return ERROR_SUCCESS;

}

// EmbeddedUIHandler is very similar to the callback provided to MsiSetExternalUIRecord

int __stdcall EmbeddedUIHandler(UINT iMessageType, MSIHANDLE hRecord)

{

INSTALLMESSAGE mt;

UINT uiFlags;

mt = (INSTALLMESSAGE)(0xFF000000&(UINT)iMessageType);

uiFlags = 0x00FFFFFF&iMessageType;

switch (mt)

{

case INSTALLMESSAGE_ERROR:

{

…

}

case INSTALLMESSAGE_WARNING:

{

…

}

case INSTALLMESSAGE_FILESINUSE:

{

…

}

return 0;

}

int __stdcall ShutdownEmbeddedUI()

{

// Let me shutdown the UI and exit gracefully.

}

Populate the MsiEmbeddedUI table

MsiEmbeddedUI	FileName	Attributes	MessageFilter	Data
UIDLL	UIDLL.dll	3	38	[Binary Data]
ResDLL1	ResDLL1.dll	0		[Binary Data]
ICO	my.ico	0		[Binary Data]

Notice that the table in the above example says that the UIDLL handles UI messages INSTALLLOGMODE_ERROR | INSTALLLOGMODE_WARNING | INSTALLLOGMODE_FILESINUSE (i.e., 2 + 4 + 32 = 38). In a way, the MessageFilter column of MsiEmbeddedUI table is similar to the dwMessageFilter parameter of the MsiSetExternalUIRecord API; in that both define the messages for which their callbacks expect to be called. The Data column corresponding to the row where `MsiEmbeddedUI`.`MsiEmbeddedUI` == UIDLL contains the embedded UI DLL.

MsiEmbeddedUI table also lists the resource DLL and the icon file used by the UI DLL. When InitializeEmbeddedUI callback gets called, the szResourcePath parameter for that function points to the directory that has all the resource binaries extracted from this table.

FAQ

Q: What if I do not want my embedded UI to handle certain Windows Installer message?
A: Include only the messages that your implementation of EmbeddedUIHandler can handle in the MSIEmbeddedUI.MessageFilter column. That will ensure that the EmbeddedUIHandler callback gets just the messages that it can handle.

Q: What will happen if InitializeEmbeddedUI fails to return any of the documented return values or just crashes?
A: That will cause the install to fail with ERROR_INSTALL_FAILURE.

Q: Where is my embedded UI DLL hosted?
A: The embedded UI DLL will be hosted in its own sandboxed impersonated custom action server.

Q: What happens after ShutdownEmbeddedUI call is returned?
A: The embedded UI DLL will be unloaded and the custom action server hosting the embedded UI DLL will be shutdown.

Q: Can my embedded UI DLL run during silent installs?
A: No.

Q: Will embedded UI get any messages if I am already using external UI using MsiSetExternalUI or MsiSetExternalUIRecord?
A: If you are using external UI, then embedded UI within the package will not be used. Similarly, if embedded UI is already being used, calls to set the external UI will fail.

Q: What happens to the messages that embedded UI does not handle?
A: Depending on the internal UI level, the messages will be sent to the internal UI handler.

Windows Installer 4.5 Servicing Enhancements: Shared Components and Patch Uninstall

Windows Installer Team — Sat, 29 Mar 2008 17:40:00 GMT

Why do I care about shared component patch uninstalls?

There has been an ask from Windows Installer customers to improve the servicing story surrounding shared components. We could summarize the asks into following points:

I want Windows Installer to keep the highest version of the file across products when an update to a shared component is uninstalled.
I do not want to get any source resolution dialogs while installing or uninstalling updates to a shared component.

Look at the PPT attached with this blog post to get an overview of the scenario. If you think you might ever get into a scenario described in the PPT, then you should read on.

How does Windows Installer 4.5 address this?

This section providers an overivew of how Windows Installer 4.5 addresses this

1. Components that need the robustness that this feature provides should be marked appropriately.

2. When installing an RTM version of that component, or when a patch carries an update to the component, we store info on the highest version of the component due to this product, irrespective of whether the component is actually updated on disk.

3. When the file on disk is to be updated, enumerate all the product clients for the component being updated.

a. If the cache baseline opcode is being generated for the product currently being installed Then

i. The RTM version of the component is looked up and that becomes the source of the cache operation.

Else

i. Verify that the component at the target location is the RTM version for this product.

ii. Cache the component from the target location into all the component’s clients’ empty RTM caches

b. This behavior will ensure that any patches to any of the products that carried the component will not result in any source resolution dialogs. This copy-on-write behavior also provides the optimal disk usage.

4. When a patch is being uninstalled, we do the following:

a. Update the registration created due to this patch in step 2

b. If the component affected by this patch uninstall has opted for the shared component robustness functionality

Then

i. If file version on disk > file version referenced in transform of the patch being uninstalled then,

a. Do not down-rev the component.

ii. If file version on disk <= file version referenced in transform of the patch being uninstalled then,

a. Enumerate the registration created in step 2 to determine the highest versioned component and the corresponding product/patches

b. If the component version calculated in the previous step is the same as the version of the component on disk then, we have nothing else to do.

c. Use the the component cache created in step 3 along with the patch that can take this component to the highest version to create and copy the resultant version of the component.

c. Else behave like Windows Installer 3.1.

How do I turn it on?

If any product marks its shared component with msidbComponentAttributesShared attribute, then this component gets this behavior irrespective of whether other products have marked it that way or not. Here’s the definition of this attribute:

//msidefs.h

enum msidbComponentAttributes

{

...

#if (_WIN32_MSI >= 450)

msidbComponentAttributesShared = 0x00000800;

#endif // (_WIN32_MSI >= 450)

};

The DisableSharedComponent machine policy will let administrators turn off the opt-in behavior of msidbComponentAttributes. The following table lists possible configurations:

DisableSharedComponent	Description
0	This is the default value. When this value is set, packages can opt-in to use the Windows Installer’s shared component functionality by setting their component’s attribute to msidbComponentAttributes.
1	This value will not let any package on the machine get the shared component functionality as desired by setting the msidbComponentAttributes component attribute.

Caveats

Targeting Limitation

It needs to be called out that the assumption that this feature makes is that every patch targets the RTM version of its product. This ensures that the binary delta contains the delta for the RTM product. This can be done by building a patch to shared components such that:

1. The patch targets RTM, by listing the RTM version of the product in the TargetImages table of the PCP.

2. If targeting RTM image is not an option, patch authors could also use ExternalFiles table of the PCP to provide the RTM version of the file. This will ensure that the delta inserted into the patch will be able to update the RTM version of the file.

New functionality is bound to Windows Installer 3.0 Baseline Caching

It needs to be noted that this feature is available only when caching is not disabled. Also, for this feature to kick in there should be at least one MSI 3.0 minor update patch or all MSI 3.0 patches (as is the requirement for baseline caching to kick in).

Component State is Agnostic to Non-File Resources

Note that this feature doesn’t restore the registry keys while it restores the right version of a file. This assumes that the registry keys are compatible across different versions of the component.

Shared Components and Languages

Two files with the same version but for different languages are regarded as same.

A Patch That Opts-in

A patch can add the msidbComponentAttributesShared attribute and start getting the benefits of this new feature. However, when the last patch that opted in for this functionality is being uninstalled, then that transaction doesn’t get this functionality because the in-memory view of the database doesn’t contain this patch and we will behave the way when dealing with any other attribute that was patched.

Sharing across contexts

When managed (i.e., MSIINSTALLCONTEXT_USERMANAGED or MSIINSTALLCONTEXT_MACHINE) and unmanaged products (i.e., MSIINSTALLCONTEXT_USERUNMANAGED) share a component by marking it with the msidbComponentAttributesShared attribute, then while looking for other products that have a better version of the component, Windows Installer does not look across the managed/unmanaged boundaries. Same thing applies to unmanaged products installed for two different users.

Windows Installer 4.5 Servicing Enhancements: Patch Uninstall Custom Actions

Windows Installer Team — Tue, 25 Mar 2008 22:50:00 GMT

In this blog post, I will provide an overview on what you can do with the new patch uninstall custom actions and how they work. The hope is that by understanding how patch uninstall custom actions work you will be able to put this new custom action type to use easily.

Why Patch Uninstall Custom Actions?

If a patch carries a custom action or carries any updates to a custom action then, that updated custom action is not run when uninstalling the patch. Also, a custom action does not get the information associated with the patch that is being uninstalled. You can look at the attached PPT to get a high level overview of the problem and the way Windows Installer has addressed it in Windows Installer 4.5

How to use this new custom action type?

A custom action that wants to run during patch uninstall will mark itself with a new msidbCustomActionTypePatchUninstall attribute. This attribute can be specified in the ExtendedType column of the CustomAction table. This new column is of type DoubleInteger and can be added when releasing a patch. A custom action marked with this attribute will run only when a patch is being uninstalled.

a. This attribute can be part of the original MSI. But, this attribute should not be dropped or added by a patch to an existing custom action. Altering this attribute in a patch on an existing custom action will cause patch uninstall to fail.

b. A new custom action with this attribute can be added by a patch.

c. When running a patch uninstall custom action, Windows Installer will use the custom action provided in the patch being uninstalled.

d. Windows Installer will make the updates within the patch being uninstalled available to the patch uninstall custom action.

Walkthroughs

Walkthroughs in this section are aimed at understanding several key scenarios associated with this feature. Each walkthrough will discuss what occurs when certain events are triggered. They however, do not discuss the “how”. Walkthroughs try to provide a reason on why certain behavior is appropriate and why certain tradeoffs were made.

In Stream RTM Patch Uninstall Custom Action

Install Product A:

RTM version of the product A carries a patch uninstall custom action PatchUninstallCA1.
This custom action is provided in a Binary Table in the form of RTMCA1.exe.
Upon this install, the custom action is not run.

Apply Patch Q1:

Patch Q1 updates the custom action PatchUninstallCA1:

i. It has a patch sequence (as authored in the MsiPatchSequence table) number of 1.0.2.0.

ii. It replaces RTMCA1.exe in the binary table with Q1CA1.exe.

Upon this patch application neither custom action is run.

Apply Patch Q2:

Patch Q2 updates the custom action PatchUninstallCA1:

i. It has a patch sequence number (as authored in the MsiPatchSequence table) of 1.0.1.0.

ii. It replaces RTMCA1.exe in the binary table with Q2CA1.exe.

Upon this patch application neither custom action is run.

Uninstall Patches Q1 and Q2:

Patches Q1 and Q2 are uninstalled by setting MSIPATCHREMOVE=<Patch GUID of Q2><Patch GUID of Q1>
When both the patches: Q1 and Q2 are uninstalled at the same time, custom action PatchUninstallCA1 ends up running Q1CA1.exe.

This walkthrough summarizes three behaviors:

A custom action marked by the msidbCustomActionTypePatchUninstall attribute will be run only during a patch uninstall.
When two patches that modify a custom action are uninstalled in a single transaction, the patch that has the highest patch sequence number wins. Note that the reason for respecting patch sequence numbers during patch uninstall is to have the ability to resolve ties in situations where a patch might become inapplicable implicitly.

While the above walkthrough takes an EXE custom action as an example, the behavior applies to even DLL and script custom actions.

On Disk Patch-Added Patch Uninstall Custom Action

Install Product A:

RTM version of the product does not have any custom actions. It installs file FTK.exe whose file table key is FTK. Version of FTK.exe is 1.0.
The product is installed without running any custom actions.
Sequence numbers of some important actions:

Action	Sequence Number
InstallFiles	900
PatchFiles	1050

Apply Patch Q1:

Patch Q1 adds a new patch uninstall custom action Q1CA and another new deferred patch uninstall custom action Q1CADeferred. When run, this custom action executes FTK.exe.
Q1 carries FTK.exe 1.1.
Action sequence numbers:

Action	Sequence Number
Q1CA	1000
Q1CADeferred	1005

Upon patch install, FTK.exe will be updated to 1.1 and neither of the patch uninstall custom actions will be run.

Apply Patch Q2:

Patch Q2 adds another new patch uninstall custom action Q2CA. When run, this custom action executes FTK.exe.
Q2 carries FTK.exe 1.2.

Action	Sequence Number
Q2CA	850

Upon patch install, FTK.exe will be updated to 1.2 and Q2CA will not be run.

Uninstall Patches Q1 and Q2:

During patch uninstall the custom actions marked to run only during patch uninstall are run. The sequence in which they are run is:

i. Q2CA. This runs FTK.exe 1.2 because the files have not been updated by the patch uninstall operation yet.

ii. InstallFiles

iii. PatchFiles

iv. Q1CA. This also runs FTK.exe 1.2 because the files have not been updated by the patch uninstall operation yet.

v. Q1CADeferred. This will queue the custom action to run during script execution.

vi. During script execution, FTK.exe 1.0 will be run because the files have been updated by now.

This walkthrough summarizes the behavior that sequence numbers are important for patch uninstall custom actions that rely on non-“Binary Table” resources. Just like any standard custom action, based on when they are executed, they get different versions of the custom action.

Note that this behavior is applicable to DLL and script custom actions as well.

Patch Uninstall Custom Actions’ Ability to Access Install State

Install Product A:

RTM version of the product carries a patch uninstall custom action RTMCA. RTMCA is a patch uninstall DLL custom action.
Upon install of this product RTMCA is not run.
Action sequence numbers:

Action	Sequence Number
RTMCA	1000

Apply Patch Q:

Patch Q carries two patch uninstall custom action DeferredQCA and RollbackQCA.

i. DeferredQCA is a patch uninstall deferred DLL custom action and

ii. RollbackQCA is a patch uninstall rollback DLL custom action.

Patch Q updates the RTM version of product A in the following way:

i. Adds a new component C. This results in the following changes:

· A new component added to the Component table.

· A new component-feature mapping in the FeatureComponents table.

· A new registry key associated with the component results in a new entry in the Registry table.

ii. Changes an existing file. This results in:

· A change in file version of an existing file in the File table.

Action sequence numbers

Action	Sequence Number
DeferredQCA	1010
RollbackQCA	1011

Upon patch install none of the patch uninstall custom actions is run.

Uninstall Patch Q:

Upon uninstall of patch Q, RTMCA will be run first amongst all patch uninstall custom actions. This custom action would like to know info that is being altered due to this patch uninstall. It therefore queries MsiTransformView<Patch GUID> table (for example, MsiTransformView{EA2EEDE8-94F8-4013-A370-36435C4B1259}) to get that info. For this walkthrough, this table will have the following contents (Several entries not included for the sake of clarity):

Table	Column	Row	Data	Current
File	Version	BlueFile	1.2.0.0	1.0.0.0
Component	Condition	C_PS_QFE2	NULL	NULL
Component	Attributes	C_PS_QFE2	2	NULL
Component	ComponentId	C_PS_QFE2	{88838DDB-DA25-4C4A-B221-E2BAC0305975}	NULL
Component	Directory_	C_PS_QFE2	PATCHSEQFOLDER	NULL
Component	KeyPath	C_PS_QFE2	QFE2	NULL
Component	INSERT	C_PS_QFE2	NULL	NULL
FeatureComponents	INSERT	F_PS_StdColor,C_PS_QFE2	NULL	NULL
Registry	Name	QFE2	QFE2	NULL
Registry	Value	QFE2	QFE2-Simple1	NULL
Registry	Component_	QFE2	C_PS_QFE2	NULL
Registry	Key	QFE2	SOFTWARE\Microsoft\MsiTest\PatchSequencing	NULL
Registry	Root	QFE2	-1	NULL
Registry	INSERT	QFE2	NULL	NULL

RTMCA would query this table to identify the component that was originally added by this patch will be dropped due to this patch uninstall. Based on this information, it can make any decisions that it has to. It needs to be noted that any modifications made to this table will be ignored and not used by Windows Installer in any way. The purpose of this table is for a patch uninstall custom action to make its decisions off of the patch being uninstalled and the state of the machine.

DeferredQCA will be run in script and therefore will not be able to access the MsiTransformView<Patch GUID> table.

Implicit Patch Uninstalls

Install Product A:

RTM version of the product does not have any custom actions.

Apply Patch SP1:

Patch SP1 adds a new binary patch uninstall custom action UninstallCA.

Apply Patch Q1:

Q1 targets SP1 and carries an update to UninstallCA.

Apply Patch Q2:

Q2 targets SP1 and carries an update to UninstallCA.

Apply Patch Q3:

Q3 targets SP1 and carries an update to UninstallCA.

Notes:

The patch sequence numbers for the above three patches are:

Patch	Patch Family	Sequence Number
SP1	Fam1	1.1.0.0
SP1	Fam2	1.1.0.0
Q1	Fam1	1.1.1.0
Q2	Fam1	1.1.2.0
Q2	Fam2	1.1.1.0

Uninstall SP1:

MSIPATCHREMOVE property will be set to SP1 only. However, Q1, Q2 and Q3 will all be uninstalled because they transition from applicable to inapplicable. All patches that go out of view in this manner, get the opportunity to run their patch uninstall custom actions.
However, since all of them update the same custom action, the question is whose custom action will be run. The answer is: the patch whose sequence number is the highest will be used. However, when there are two patches with different patch families then the choice will be non-deterministic.