Windows Installer Team Blog

Developing for Windows 7

Windows Installer Team — Fri, 11 Sep 2009 21:52:00 GMT

I recently came across several resources that are available from Microsoft to help developers get their applications ready and shining on Windows 7! Since these resources are scattered in several places, I thought it would be beneficial to have a post with a compilation of these. So here you go…

1. Training Kit for Developers (Windows 7 RTM version)

This kit includes presentations, hands-on labs, and demos designed to help you learn how to build applications that are compatible with and shine on Windows 7 by utilizing key Windows 7 features. You can find topics such as: Taskbar, Sensor and Location, Libraries and Shell, DirectX, Multi-touch, Ribbon, etc. The kit is built for both native Win32 C++ developers and .NET developers. The kit also includes Application Compatibility labs for: Version Checking, Data Redirection, UIPI, Installer Detection, Session 0 Isolation, and High DPI, to help you get over the most common application compatibility issues.

Available for download on Microsoft download center.

2. Application Quality Cookbook

This Cookbook provides you with the means to become familiar with how to verify the compatibility of your applications with the new operating system and provides an overview of the few known application incompatibility issues in Windows 7 and Windows Server 2008 R2. But more than that, it also points out differences in performance, reliability, and usability, and provides links to detailed white papers and other developer guidance.

You can download the complete version (available in .docx and .xps formats) of the Application Quality Cookbook from its location on Code Gallery.

3. Developer Guide

The Windows 7 platform makes it easy for developers to create engaging, user-friendly applications by providing familiar tools and rich development features that allow them to take advantage of the latest PC capabilities. This guide summarizes the key developer advances in each of the following three areas:

· Solid Foundation

· Richer Application Experiences

· The Best of Windows and the Web

You can download the Windows 7 version of the Developer Guide (available in .docx and .xps formats) from its location on Code Gallery.

4. Application Compatibility

If you are facing Compatibility problems with your applications on Windows 7, here are some excellent application compatibility resources to get you started!

· Application Compatibility Factory (ACF) Program – Helps customers identify and resolve potential compatibility issues they may face when migrating desktops and applications to Windows 7.

· Windows XP to Windows 7 Migration – Tools and resources available from Microsoft to help you each step along the way when migrating from a Windows XP environment to Windows 7.

· Microsoft Application Compatibility Toolkit 5.5 – contains the necessary tools and documentation to evaluate and mitigate application compatibility issues before deploying Windows 7.

· Win7 App Compat FAQ for developers

· MSDN forum Application Compatibility for Windows Development

5. The Windows 7 Blog for Developers

A blog focusing mainly on the developer aspects of 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.

Windows 7 Taskbar support with the MsiShortcutProperty table

Windows Installer Team — Thu, 03 Sep 2009 04:53:00 GMT

Starting with Windows 7, Windows Installer enables native support for setting properties on shortcuts created during installation or re-installation. The MsiShortcutProperty table can be used to set any property defined by the IPropertyStore interface.

In order to use the new table, you need to specify the PropertyKey and PropVariantValue for the shortcut you want to set the properties on (you can set multiple properties on a shortcut). The properties allowed are the ones registered in the current property schema. The system-supplied properties are defined in propkey.h: many of them are new in Windows 7. Properties supplied by 3^rd parties are also supported, as long as they have been registered with the schema subsystem (for eg. via PSRegisterPropertySchema).

You can use string representations for both – e.g. System.AppUserModel.ID for the PropertyKey PKEY_AppUserModel_ID, and a corresponding string representation for the PropVariantValue. Windows will automatically coerce the value to the correct type.

MsiShortcutProperty	Shortcut_	PropertyKey	PropVariantValue
AppIDProperty	OrcaNT.406D93CE_00E9_11D2_AD47_00A0C9AF11A6	System.AppUserModel.ID	Microsoft.WindowsInstallerTools.Orca
PreventPinningProperty	OrcaNT.406D93CE_00E9_11D2_AD47_00A0C9AF11A6	System.AppUserModel.PreventPinning	0

These properties are consumed by shell, not windows installer.

Examples:

1. Allow an app to glom onto its shortcut on the taskbar

System.AppUserModel.ID property in Windows 7 defines an AppUserModelID. Applications can use this property to group its windows together with the shortcut on the Windows taskbar. This means that if the application sets an AppUserModelID in its process, and same AppUserModelID in the shortcut, then when the shortcut is pinned to the taskbar and the application is launched from it, the application icon will group together with the shortcut. This property is particularly useful for applications that wish to override the taskbar’s default grouping and unification – apps running under a host process, or an app that owns several different processes. PropertyKey, PropVariantValue that you would author in the MsiShortcutProperty table of your package would be “System.AppUserModel.ID” and “CompanyName.ProductName.SubProduct”, respectively.

2. Prevent pinning of shortcuts

Setting “System.AppUserModel.PreventPinning” property to “1” prevents a shortcut from being pinned to the taskbar.

FAQs

Q: Is there a new standard action that I need to schedule?

A: No, setting of shortcut properties will be a part of the CreateShortcuts standard action.

Q: Can I set properties on shortcuts that are not a part of my installation?

A: No, you can only set properties on shortcuts created by your installation.

Q: What happens if the setting of a property fails?

A: If Windows Installer fails to set a shortcut property, it will return a warning and the installation will continue.

Q: What happens on downlevel platforms?

A: This functionality is only available on Windows Installer 5.0 and above. The MsiShortcutProperty table – if present – is ignored on Windows Installer 4.5 and below.

[Author: Ashish Awasthi]
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.

Authoring a single package for Per-User or Per-Machine Installation context in Windows 7

Windows Installer Team — Thu, 03 Sep 2009 04:49:00 GMT

Prior to the introduction of UAC in Windows Vista, setup authors were able to create a single package that could install for the current user (“Just for me”) or for all users on the computer (“Everyone”). With the introduction of UAC, setup authors were no longer able to create a single package that could install in both modes. This feature provides the functionality to aid the development of a dual-purpose package for installation on Windows 7.

Historical Perspective:

With the introduction of UAC in Vista, setting ALLUSERS=2 no longer provided the conditional logic to set the installation context based on user’s privileges. As a workaround, Windows Installer provided a way to declare a package is UAC compliant – setting bit 3 of the Word Count Summary property. If this bit is set, no elevation prompt is thrown – and the package is installed per-user. It is the responsibility of package author to ensure that there are no writes to per-machine locations and that elevated privileges are not required for installation; otherwise the installation would fail due to a lack of privileges.

This meant that the setup authors typically had to create two packages for Windows Vista – one with the UAC compliant bit set for per-user installation; and other without this bit, for per-machine installation. Also, setup authors had to ensure – in a per-user installation – that the common locations like ProgramFilesFolder were not used, because there were no per-user equivalents for them in Windows Vista.

Introducing dual-Mode Package:

With Windows Installer 5.0 on Windows 7 and higher, you can author a dual mode package that can be installed per user or per machine. Setup authors can set the MSIINSTALLPERUSER property to 1 and ALLUSERS to 2 to identify the package as a dual-purpose package. Note that MSIINSTALLPERUSER is only evaluated when ALLUSERS=2. These properties can be specified in the package, passed through the command line, modified by a transform, or – more commonly – selected through a user interface dialog.

Adhere to these Development guidelines for dual-mode packages to ensure your package can be installed in either the per-user or per-machine context. Windows 7 SDK includes a sample package PUASample1.msi to serve as an example of how to author a dual mode package.

Per-user capable known folders and registrations of the Windows Shell:

Prior to Windows 7, an app installed in the per-user context, only had its entry-points like shortcuts, installed per-user – the app binaries and registrations were (unless specified as per-user) written in per-machine locations like “Program Files” and HKLM, since there were no per-user equivalents for some of these locations. Windows 7 includes support for a per user equivalent version of FOLDERID_ProgramFiles and FOLDERID_ProgramFilesCommon as well known folders. These folders will be automatically created by Windows Installer if they do not exist.

FOLDERID_UserProgramFiles: “%LocalAppData%\Programs”.

FOLDERID_UserProgramFilesCommon: “%LocalAppData%\Programs\Common”.

As the author of a Windows Installer package, you simply continue to use the existing Windows Installer properties ProgramFilesFolder and CommonFilesFolder. At install time, Windows Installer will redirect to the per-machine version (i.e. the version that is globally available to all users) or the per user version that is available for the current user for whom the application is being installed. Note that the ProgramFilesFolder and ProgramFiles64Folder have the same per-user equivalent on a 64-bit system; similarly for CommonFilesFolder and CommonFiles64Folder. The MSDN article on Installation Context describes automatic redirection of various properties, registry keys, and shortcuts based on the context in which a package is installed.

Developing for multiple Windows platforms:

Dual mode packages are only recognized on Windows 7 and above. The MSIINSTALLPERUSER property will be ignored on down-level systems. ICE 105 is provided to help you verify that your package can truly be installed in either mode. It basically verifies that your package is not writing to any machine-wide locations. The table below explains the behavior of different kinds of installations on various platforms:

Type of MSI package	Windows 7	Vista	Platforms prior to Vista
Windows 7 Dual-mode app: Offers choice to install per user or per machine.	User has the choice to install per user or per machine.	Installs per machine and UAC credentials are required. Developers must condition the UI such that the “Install Only for Me/For Everyone” dialog would not be presented.	Installation context depends on ALLUSERS property
	If installed per user then all writes are isolated to that user’s profile and no UAC prompt.	Will not install per user.	Will install per-user depending on ALLUSERS property.
	If installed per machine there is a UAC prompt, and application will be available for all users.	MSI will always install per machine, there is a UAC prompt, and application will be available for all users.	Typically for per user installs, entry short cuts created per user and files installed globally.
UAC Compliant app: Offers choice to install per user.	Installs only per user (all writes isolated to users profile, no UAC prompt)	Installs only per user, (isolated to users profile, no UAC prompt)	Installation context depends on ALLUSERS property
Legacy app: Offers choice to install per user or per machine.	App will always install per machine (regardless of what user chooses) and UAC credentials are required.	App will always install per machine (regardless of what user chooses) and UAC credentials are required.	Installation context depends on ALLUSERS property. Typically for per user installs short cuts created per user and files installed globally.

Some things to consider…

The target customers for dual mode packages are LOB ISVs who author lightweight applications that don’t need administrative privileges and don’t need to write to machine-wide locations during installation. So, there are cases where a per-user or dual mode package would not serve the purpose:

· If there are any machine-wide prerequisites, you will have to install them separately.

· Per-user apps are not supported by some OS Registration points, you cannot install services or drivers or global assemblies, etc.

· Apps that are meant for all users – like firewall or anti-virus cannot be installed per-user.

· A per-user package will only be serviced when the user who installed it, is logged on to the machine.

· Also, “Set Program Access and Defaults (SPAD)” cannot be set for apps installed as per-user installation context.

FAQ’s

Q: If the MSIINSTALLPERUSER and ALLUSERS properties can be specified in the package, through the command line, or via the UI, what takes precedence?

A: Precedence of properties in decreasing order of priority

1. What is specified via UI

2. What is specified in command line

3. What is set in package

Note that the both MSIINSTALLPERUSER and ALLUSERS properties should be set at the same time. For example, you should not set ALLUSERS property via command-line and MSIINSTALLPERUSER property via UI.

Q: What about servicing for a per-user installed app?

A: Once a dual mode application is installed per-user, it can be serviced (patched/repaired/uninstalled) by a standard user, with no UAC prompt or elevation needed assuming the user is logged on.

Q: Can per-user and per-machine installations of the same app co-exist on the same machine?

A: It depends. If the app is first installed per-machinethe app will already be visible to all users and cannot be installed per-user. However, if a standard user Jane installs an app per-user, another user Abby can install the same app per-machine, assuming she has admin credentials. Jane will continue to see and use her version of the application on shortcuts, start menu, etc. If Jane removes her version of the application from “Uninstall or Change Program” wizard, she will then see the per-machine version of the application.

In the “Uninstall or Change Program” wizard, Jane would be able to see both the per-user and per-machine versions of the app, but she would not be able to uninstall the per-machine version without providing administrator credentials. She would, however, be able to uninstall (or repair) her per-user version of the app without seeing a UAC prompt. Abby will only see the per-machine version that she installed and made visible to all users on the system.

Q: Okay, if per-user and per-machine versions of an app can co-exist, which version gets updated when a patch is ready to be installed?

A: This depends on the context that the app was originally deployed and the context that the patch is being applied. For instance, let’s imagine that standard users Jane and Toby have both installed an app per-user, before the administrator Abby decided to install it for all the users on the machine. If Jane is logged on when the patch is to be applied, then her version of the app will be updated, and she will not be presented with a UAC prompt. Same holds for Toby. When Abby is logged on, the per-machine version of the app will be updated.

Q: I manage an enterprise environment where I would like to block users from installing applications per-user. What can I do?

A: Setting the policy DisableMSI to 1 will block the per-user install operations of dual mode packages. Setting it to 1 will also block all the uninstall/patching/upgrade of the packages that were previously installed with MSIINSTALLPERUSER=1. Setting the DisableMSI to 2 will block windows installer from doing any operations on the machine. Setting the DisableUserInstalls policy to 1 disables install/uninstall/upgrade/patching of per-user applications.

[Authored by Ashish Awasthi & edited by 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.

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.

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

Windows 7 released to manufacturing

Windows Installer Team — Sat, 01 Aug 2009 03:08:00 GMT

As some of you may have already heard, Windows 7 has now been released to manufacturing! Read the latest blog post on the Engineering Windows 7 blog. This also means that now you have all the more reason to try the new functionality in Windows Installer 5.0 that is included in Windows 7. Windows Installer provides some key improvements and enables new experiences for application setup developers, ISVs and IT Administrators. Also all features provided with the MSI 4.5 redistributable release are rolled into Windows 7.

You can download the recorded presentation [video1, video2, video3] & the power point slide deck to learn more about these Windows Installer features.

Improvements over Windows Vista:

Standard actions support for enhanced permissions setting, service configuration and most common UI oriented tasks, eliminating the need for writing custom actions
Performance related improvements give you the ability to speed up installation of large packages & patches, and better integration with UAC help provide a good overall end user experience
Patching improvements made to support highest version of shared component, and support custom action during patch uninstall

New experiences in Windows 7:

Support for installing multiple packages using transaction processing
Support to embed a custom UI handler within MSI package, making custom UI easier to integrate
Support to create & deploy a single dual mode MSI package capable of being installed both in per-user as well as per-machine context

Please note that the MSDN documentation section "What's new in Windows Installer 5.0" has been updated accordingly and is available for online viewing. Feel free to post your comments/questions to this blog post.

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

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.

Enhanced Permissions Setting with Windows Installer 5.0

Windows Installer Team — Thu, 05 Mar 2009 11:08:00 GMT

Setting appropriate permissions for an object is one of the core operations in creating an application installer. One of the most frequent pieces of feedback has been to provide enhanced capabilities around securing resources installed on the system. MsiLockPermissionsEx Table in Windows 7 enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer.

· Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o Ability to apply Deny ACLs to objects

o Indicate inheritance properties for permissions

o Expand the set of well-known SIDs

o Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

· Security settings can be applied to services as well in addition to Files, Folders, Registry keys

· Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation

FormattedSDDLText is a new column data type used by the SDDLText field of the MsiLockPermissionsEx Table to secure a selected object.

Q: How does new MsiLockPermissionsEx table change the semantics or behavior of the older LockPermissions table?

A: Packages using the older LockPermissions table will continue to work as expected. However, we encourage you to author your packages targeted for Windows 7 and above to use the new MsiLockPermissionsEx table to take advantage of the power and flexibility provided by SDDL while customizing security settings for your resources.

Q: Can I author both LockPermissions and MsiLockPermissionsEx tables in my package?

A: No, in the interest of simplifying authoring and avoiding collisions, it is not allowed to have both LockPermissions and MsiLockPermissionsEx tables in the same package. If both tables are present, the installation will fail. ICE 104 verifies that only one of the two tables: MsiLockPermissionsEx or LockPermissions is present in the package.

Q: What happens if two conditions in different rows evaluate to true for the same LockObject/Table pair in MsiLockPermissionsEx table? Which SDDLText will be applied?

A: If a LockObject/Table pair has multiple conditional expressions that evaluate to true, the installation will fail. So, be careful while authoring your conditions: if you have more than one security setting in your package for an object – make sure the corresponding conditions are mutually exclusive.

Q: What happens if the SDDL specified in MsiLockPermissionsEx is incorrect, or if the user does not have permissions to apply the security settings described by the SDDL?

A: The installation fails if Windows Installer is unable to resolve the SDDL specified in the MsiLockPermissionsEx table into a valid security descriptor, or if the user doesn’t have the permissions to apply those settings, unless the package is blessed by an administrator.

Q: When is the resolution of SDDLText into the binary security descriptor done?

A: Unlike the older LockPermissions table, the resolution of permissions into the binary security descriptor for MsiLockPermissionsEx is done during the execution phase, at the time when an object is actually being installed. This is important because it means you can even set security settings referencing a new user account that is being created as part of the installation as long as the account creation is scheduled before the object is installed.

Q: Now that I can set security attributes on a service installed by a package via the MsiLockPermissionsEx table, can I do so with the LockPermissions table as well?

A: No, if you wish to set security attributes on a service, you will have to use the MsiLockPermissionsEx table. The behavior and semantics of the LockPermissions table will not change.

Q: My product has already been released. Can I use MsiLockPermissionsEx table to secure objects that are already installed? Can I use this feature to secure objects via a patch?

A: Similar to the LockPermissions table, you can use a patch to secure objects that are being installed on the machine with MsiLockPermissionsEx table, including objects that replace existing ones on the machine as part of the installation. If an object is not installed as part of the current installation, security settings specified in MsiLockPermissionsEx will not be applied to it. It should be kept in mind that a patch that includes either of these two tables – MsiLockPermissionsEx or LockPermissions – will be marked as not uninstallable.

Q: Will there be an ICE validation test to help me author the new table?

A: Yes, ICE 104 is being introduced to help validate the MsiLockPermissionsEx table.

Q: Will this feature be available on down-level platforms?

A: No, as of now, this feature is being introduced only in Windows 7. Down-level platforms will ignore MsiLockPermissionsEx table, if present. See the table below for behavior on various platforms:

	Only LockPermissions	Only MsiLockPermissionsEx	Both tables	Neither
Windows 7 and above	Security settings from LockPermissions table are applied	Security settings from MsiLockPermissionsEx table are applied	The installation fails if both tables are present.	*Default security settings are applied.
Down-level platforms	Security settings from LockPermissions table are applied	*Default security settings are applied.	Security settings from LockPermissions table are applied	*Default security settings are applied.

*“Default security settings” mean that if an object does not replace an existing object, it receives no explicit security descriptor: the access to the new object is based on the attributes of its parent or container object. If an object replaces an existing object on the system, the replacement gets the security settings of the object it replaces. If the replaced object had no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.

Enhanced Service Configuration with Windows Installer 5.0

Windows Installer Team — Thu, 05 Mar 2009 09:34:00 GMT

In Windows 7, Windows Installer provides enhanced native support for setup authors to configure services as part of an application install.

Starting with Windows Vista, Windows provides a powerful set of configuration options to configure services. These enhancements result in better security, performance and reliability for services. For example, the least privilege and resource isolation principles for services address security related issues by minimizing the vulnerabilities in a system. At the same time, delayed auto-start helps system startup performance by speeding up system boot time. Similarly, preshutdown notification for a service and improved failure detection and recovery options increase system reliability and a better end user experience.

MsiServiceConfig table provides options for configuring a service that is being installed or one that already exists on the machine by specifying the type of configuration as well as the parameters needed for that configuration. MsiServiceConfigFailureActions table is used to document failure actions that need to be invoked in the event of a service failure. This change takes effect the next time the system is started. Both these tables will be processed during the MsiConfigureServices action. The MsiConfigureServices standard action should be scheduled in the following order:

1. StopServices – From ServiceControl table

2. DeleteServices – From ServiceControl table

3. InstallServices – From ServiceInstall table

4. MsiConfigureServices – From MsiServiceConfig and MsiServiceConfigFailureActions tables

5. StartServices – From ServiceControl table

Q: Can I configure a service already installed on the system with this table?

A: Yes, as long as the corresponding component is being acted upon (installed/uninstalled/re-installed), you can configure an existing service. This is similar to stopping an already existing service via the StopServices standard action. Make sure the user has the privilege to configure services.

Q: When will the changed configuration take effect?

A: Generally the configuration options take effect when the service is restarted. An option like delayed auto-start will be manifested when the system restarts.

Q: Will this change the behavior of packages not using the new tables or the new standard action?

A: No, all existing tables and standard actions retain their current semantics. Packages not using the new standard action or the new tables will continue to work as earlier.

Q: My product has already been released. Can I use this feature to configure my services via a patch?

A: Yes, service configuration can be done via a patch. However, a patch that includes either of these two tables will be marked as not uninstallable.

Q: What happens if MsiConfigureServices action encounters an error?

A: The installation fails if MsiConfigureServices standard action fails. So, be extra careful while authoring these tables and ensure that the user has privileges to configure services if the package is not blessed by an administrator.

Q: Will this standard action work on down-level platforms?

A: No, as of now, the standard action MsiConfigureServices is introduced only in Windows 7.

Q: Will there be an ICE validation test to help me author these new tables?

A: Yes, ICE 102 is introduced to validate the two new tables.

MSI 5.0 in Windows 7 Beta

Windows Installer Team — Tue, 10 Feb 2009 09:27:00 GMT

Windows Installer version 5.0 is included in Windows 7 Beta. The MSDN documentation section "What's new in Windows Installer 5.0" has been updated accordingly and available for online viewing. In addition, all functionality provided with the MSI 4.5 redistributable release is included on Windows 7. Over the next few days, we will do a series of deep dive posts on some of the newly added feature areas. So please use the comments to let us know your thoughts and questions.

I also encourage you to take a look at the scenarios published at http://input.microsoft.com and provide your feedback. The Application Setup related scenarios are under Setup and Deployment section.

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

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

Take the Windows Application Platform Team survey

Windows Installer Team — Thu, 20 Nov 2008 23:00:00 GMT

Hey all,

The Windows engineering teams are putting together plans for how application installation and servicing will work in future versions of the operating system. We would like to take this opportunity to hear from you to better understand your current pain points and needs going forward.

We have put together a survey to collect your valuable feedback. We hope you will take this opportunity to tell Microsoft what you feel are the needs and priorities to take into consideration to improve the overall application setup & deployment experience.

Sincerely,

Windows Application Platform team

Did you miss PDC 2008?

Windows Installer Team — Wed, 05 Nov 2008 23:11:00 GMT

Hey everyone --

In case you missed my presentation at PDC 2008 in Los Angeles last weekend, the streaming version is now available online! This talk covers recent changes in Windows Installer and ClickOnce, plus information about upcoming changes in Windows 7.

http://channel9.msdn.com/pdc2008/PC42/

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

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.

Introduction for Zainab Hakim - An update

Windows Installer Team — Fri, 06 Jun 2008 21:44:00 GMT

Hi all,

It was recently pointed out to me that I had not yet updated my introduction post. So I wanted to take a moment to let you all know of a change in my job description and role. Since October 2008, I have been the Program Manager (commonly known as PM at Microsoft) for Windows Installer. I’m excited about my new role and its been a great journey so far. Thank you for your continued interest in the Windows Installer and I look forward to your comments and feedback as always.

Hi, I'm Zainab (pronounced Zay'nab) ~~and I am the test engineer for the Windows Installer (MSI) team.~~ I have been a part of the MSI team for just a little under 3 years now. I love coming in every day to my job and working on the technology that significantly affects a variety of customers worldwide and enables them to provide a great installation and configuration experience of their applications.

I served as the test lead for Windows Installer 4.5 out-of-band release, which is the latest release of Windows Installer. This article describes all the new and improved features of 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!

Join us at TechEd 2008! (part 2)

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

Members of the Windows Installer team will be at both the TechEd Developers (June 3-6) and TechEd IT Professionals (June 10-13) conferences in sunny Orlando, Florida. For information about our Breakout and Interactive Theatre Sessions, please see my previous post. In addition to the scheduled sessions, we will be staffing the Technical Learning Center (TLC) for both conferences. Information on the TLC area for the Developers conference is available here and information on the TLC area for the IT Professionals conference is available here.

Robert Flaming and Hemchander Sannidhanam will be manning the TLC area at the Developers conference. You will be able to find them at the Microsoft Product Demo Station area during the following times:

· Robert Flaming – Windows Presentation Foundation

o June 03 8:30 AM - 12:00 PM

o June 03 11:45 AM - 2:45 PM

o June 03 2:30 PM - 6:00 PM

o June 04 8:15 AM - 11:45 AM

o June 04 11:30 AM - 2:45 PM

o June 04 2:30 PM - 6:00 PM

o June 05 8:15 AM - 11:45 AM

· Hemchander Sannidhanam - .NET Framework

o June 03 8:30 AM - 12:00 PM

o June 03 11:45 AM - 2:45 PM

o June 04 8:15 AM - 11:45 AM

o June 04 2:30 PM - 6:00 PM

o June 06 11:30 AM - 2:45 PM

o June 06 2:30 PM - 6:00 PM

Tyler Robinson and Ken Wong will be manning the TLC area at the IT Professionals conference. You will be able to find them at the Microsoft Product Demo Station area during the following times:

· Tyler Robinson – Vista Application Compatibility and Deployment

o June 10 11:45 AM – 2:45 PM

o June 11 11:45 AM – 2:45 PM

· Ken Wong – Vista Application Compatibility and Deployment

o June 10 11:45 AM - 2:45 PM

o June 11 8:15 AM - 11:45 AM

o June 11 2:30 PM - 6:00 PM

o June 12 8:15 AM - 11:45 AM

o June 12 11:30 AM - 2:45 PM

See you there!

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.

What changed in Windows Installer (MSI) in Windows Vista Service Pack 1?

Windows Installer Team — Wed, 30 Apr 2008 01:53:00 GMT

Stefan Krueger met with us a few weeks ago for the Microsoft MVP Global Summit. Among the many topics we discussed was a suggestion from Stefan that we use the team’s blog to communicate relevant bug fixes that we make in our releases. This posting is the result of that suggestion. (Thanks, Stefan!)

Windows Vista Service Pack 1 was recently released and you may have noticed that the version of MSI on the system has incremented to 4.0.6001.18000. Below you will find a list of the most important issues that we addressed in Service Pack 1 and the SDK.

Updates that can be found in Windows Vista Service Pack 1:

· User Shortcuts in Redirected Start Menu Do Not Get Removed On App Uninstall

If you attempt to uninstall an application that was installed for a roaming user, you may receive error 1910 and the shortcuts from the start menu will not get removed.

· Win32_product does not work on vista when more than one per-user application is installed

Queries to the Win32_Product WMI class will fail if the machine has at least 2 per-user applications installed with a generic failure error.

Updates that can be found in the Windows SDK for Windows Server 2008:

· PatchWiz 4.0 ignores the IgnoreMissingSrcFile property

This property in the TargetImages Table is often used to reduce the time necessary to generate a patch, but the property was ignored in patchwiz 4.0 that was included in the Windows Vista SDK.

· Patchwiz 4.0 does not recreate the Patch table if dropped

Previous versions of patchwiz would automatically recreate critical tables (eg: Patch, PatchPackage) if they were dropped in the patch. Patchwiz 4.0 did not include this behavior, which caused failures in some cases.

· PatchWiz 4.0 does not support authoring of OptimizeCA MsiPatchMetadata property

The OptimizeCA property can be included in the MsiPatchMetadata of a MSP to restrict custom action usage and improve performance during patch application. Using this property with patchwiz 4.0 caused a build failure.

· PatchWiz 4.0 is unable to build patch for products with large number of files (>32767)

Previous versions of patchwiz supported building patches with a large number of files, but patchwiz 4.0 did not.

· Orca crashes when a transform is generated and a row is deleted from the current table

Orca crashes if the user attempts to generate a new transform and deletes a row from an existing table. (Using Orca, select New Transform, then delete a row from a table).

· ICE30 does not display all ICE errors

ICE30 only detects a subset of the total number of SFN/LFN collisions for components that contain files.

We're Hiring!

Windows Installer Team — Sun, 27 Apr 2008 00:05:00 GMT

The Windows Installer (MSI) team is part of the rapidly-growing Windows Application Platform (WAP) team here at Microsoft. We currently have several openings for talented Program Managers with real-world knowledge of the Application Deployment, Platform and/or related Tools space.

The positions we have open are job codes 225586, 225368, 228382, 223260, and 226806. (Please go to the Microsoft Career web site and log in before clicking on these links.) If you think you might be a good fit for any of these positions, please apply through Microsoft’s Career web site.

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!