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.