Windows Installer Team Blog : Design Pointers

Integration Hurdles for EXE Custom Actions

Windows Installer Team — Sat, 20 Oct 2007 17:35:00 GMT

A while back, two sets of engineers were arguing whether simply calling an EXE custom action would be good enough for Windows Installer based package. The first team with the EXE didn't want to do the work to move to Windows Installer but they really wanted the second team to take a dependency. The team based on Windows Installer said the integration problems with calling an EXE was so great they would not integrate without a Windows Installer package.

As an attempt at arbitrating the disagreement, it was requested the Window Installer team provide an analysis. A quick paper was written to capture the analysis. This paper has since been shared in other similar circumstances.

In a recent instance, Microsoft blogger Aaron Stebner suggested this quick paper would make a good blog. Here it is. Hope it's useful ;^)

Integration Hurdles for EXE Custom Actions

Overview and Scope

Windows Installer (MSI) architecture was designed to work best when all the installation behaviors are native to the Windows Installer. When the native behavior (called Standard Actions) are insufficient, there is a way to provide extend behavior (called Custom Actions). Custom Actions come in various base types that are differentiated on the way the Windows Installer service instantiates the custom action in the appropriate sandbox. Among the types of custom actions are executable files and dynamic link libraries.

Bare custom actions are risky to the integrity of a Windows Installer base install and this document will consider the risks.

This document will not dive deep into the architecture or the possibilities to improve the custom action architecture in the future.

Integration Hurdles

The installation integrity risk running EXE custom actions come in a number of varieties

Problem	Description	Mitigation (by consumer of EXE)
Crash	Bad EXEs can bring down the custom action sandbox	None
Binary Dependency	Bad EXEs can require technologies that are not in the system at the time of the install. Specific instance: MSXML custom actions required MFC 7 but it didn't exist on machines.	None
Load	Bad EXEs can expect to load DLLs from the path but the path could be customized by the user on the machine.	None
Rights	Bad EXEs can require more rights (e.g. admin) than the package thus breaking scenarios (per-user)	None
Logging	EXEs do not have access to the Windows Installer Log so there is no integrated troubleshooting.	None (best effort, build DLL that provides log path to EXE and puts the log next to or into the Windows Installer log)
UI	EXE do not have access to the UILevel so they do not know whether it's OK to display UI.	None (best effort, build DLL that reads UILevel and alters command line)
Progress	EXEs do not have access to the widows installer progress bar.	None (best effort, add entries to the ReserveCost table)
Hangs	EXE may hang and neither the Windows Installer nor the user has no way of knowing whether the install is hung or just taking a long time.	None (best effort, build DLL that calls CreateProcess and WaitForMultipleObjects)
Costing	EXE do not have any way of being integrated into the Windows Installer costing	None (best effort, build DLL that add ticks to the progress bar)
Rollback - rollback behavior - decision when to execute rollback (did failure occur in the FWD case thus calling the Backward case is extraneous?)	Bad EXE do not support rollback.	None (best effort, build DLL that calls EXE uninstall if exists)
Transparency and Predictability	EXEs are not data driven from the contents of the MSI thus are not transparent to users, especially admins.	None
Uninstall	Bad EXEs do not support uninstall	None (best effort, build DLL that calls EXE uninstall if exists)
Uninstall Rollback	Bad EXEs do not support uninstall rollback	None (best effort, build DLL that calls EXE install)
Repair/Resiliency	Bad EXEs do not support repair	None (best effort, build DLL that calls EXE install again)
First Run	Bad EXEs mix per machine installation with per-user installation that should be invoked at first run	None
Error Codes	Bad EXEs do not provide return codes or have return codes that do not match the custom action return code expectations.	None (best effort, best effort, build DLL that interprets errors returned from the EXE and returns the appropriate value)
Watson	EXE failures are difficult to map to Watson buckets (for teams that have implemented Setup Watson)	None (best effort, build DLL that initializes Setup Watson with the needed context to differentiate EXE error)
PSS Costs	When an EXE fails, the supports costs are absorbed by the enclosing product	None (best effort, build DLL that records needed context to differentiate EXE error)
Localization	Does installation or manipulation by the EXE cause strings to be written to the system? If yes, how are the strings differentiated?	None
Selection	Some EXEs have different levels that can be installed (Minimum, Full).	None (best effort, build DLL that maps UI or feature selection to different levels in EXE)
Terminal Server and SMS	Bad EXEs do not run correctly on Terminal Server where there is no user logged in and will not have a user hive	None
Group Policy (Publishing, assignment)	<missing this context>	None
Debugging	There is no way to debug custom actions in EXE from MSI.	None (best effort, build DLL that uses dll debugging then alter EXE call from inside DLL)
Access to Database	EXEs are unable to access the database	None (best effort, build DLL that uses dll method to access the database)
Run From Source or Cache	EXEs are unable to be configured to run from source	None
Servicing	EXEs are more difficult to confirm they contain the right security fixes when servicing	None
Help	EXEs that contain 2.0 User Education integration may not have MSI's namespace parents configured at the time they are called	None (best effort, move the EXE to a different location in the sequence after the html help custom actions)
Events	EXEs that produce events during install will appear outside the MSI context	None
Customization	Numerous third party tools exist to customize an install to the needs of a particular specialized user (usually LORGs)	None
File In Use	There is no way for a custom action to inform the user that files they want to manipulate are in use	None
Pending File Renames, File in Use, and Rollback	If a EXE custom action replaces files that are held in use and a MoveFileEx causes those files to end up in Pending File Renames, then the install rolls back it's possible that the files will still be changed on the next boot.	None
Detection of When to Install (Resiliency v Rollback)	A rollback during repair or reinstall could cause premature removal of a EXE install that existed on the machine before MSI was installed. If one implements rollback, one has to implement foolproof detection for existing installs of the component and not run the EXE package if the same version of EXE is already on the machine. Otherwise, a cancel or failure in the MSI could cause a preexisting installation of the EXE component to be removed.	None
Reboot	If the EXE requires a reboot, there is no way to communicate the need for the REBOOT to the MSI	None
Cancel	As EXEs can not call MsiProcessMessage, they are unable to respond to the cancel button.	None (best effort, build DLL that calls MsiProcessMessage)
Watson	EXEs that crash may cause a Watson dialog during the install	None

Test Scenarios

When testing the MSI that contains this EXE, one needs to test the following

Deployment technologies

Group Policy Software Distribution

Publishing
Assignment

SMS deployment
Install from network share/media
Install from local cache
Hard drive imaging

Customer segments

Retail install
OEM pre-install
Enterprise deployment

User types

No user (install during winlogon, install by SMS agent) - these will not have a user hive
Lockdown user
Regular user
LUA without registry virtualization
Admin user

[Author: Robert Flaming]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

A starting point for Windows Installer 4.5 embedded UI?

Windows Installer Team — Sat, 08 Sep 2007 07:48:00 GMT

A few questions have come in asking for a starting point for building a Windows Installer 4.5 Embedded UI.

Feature Design

As we put together the ideas behind the Embedded UI features, we aspired to provide a simple extension off the preexisting features in the Windows Installer platform.

Simple Starting Idea

When we started designing this feature, our target scenario went something like this:

An ISV has spent a lot of time building a really cool external UI for their Windows Installer based experience users have a habit of trying to invoke the .MSI file directly rather than the setup.exe bootstrapper file. Generally this ISV puts up an plain dialog "Please invoke [ProductName] from the setup.exe file next to this file.". It wastes the users time and hurts the package's customer satisfaction.
Over time, we added nuances to this feature but our base assumption was that the ISV was the type of ISV that was ready to invest into an external UI.
Guiding Principle: what would an external UI do?

With the simple idea that a package author just wanted to put their custom UI inside the package, most of the complexity we referenced back to our guiding principle: what would an external UI do? We even considered a "zero cost migration from external UI" requirement but it didn't fit scenarios or the ISV persona who was already prepared to build custom code to get their custom UI experience. A little more code was acceptable as long as reuse was in reach.

Friends and Foundations

One of the other early tests we had for ourselves was whether we thought the friends of Windows Installer could use this feature with the foundations already in place. Some of our bigger ISV and Tools Vendor friends already had custom external UI handlers so we wanted the cost for them to be low to build from their foundation. For smaller or newer ISV or Tools Vendors, we scouted our documentation and samples for a viable starting point for their foundation.

A Starting Point

For an ISV without a preexisting starting point, here's what we thought you'd use to build start from.

First think of DLL custom action

When custom actions are needed, DLL custom actions are the way to do. They provide the capacity for the maximum integration with our architecture, including message passing for UI and logging, ability to read the database in the session, and the ability to request being executed NoImpersonated. Further most of the tools provide some starting framework to get an ISV off the ground with a DLL custom action. For us, considering the Embedded UI handler as a specialized version of a DLL custom action allowed us to reuse our custom action sandbox as the embedded UI sandbox.

Second think of external UI message processing

Once the Embedded UI DLL has been booted, it needs to do it's work. The next thing a UI handler will need is to process messages. Although we do not currently have a external UI sample in the Windows Installer portion of the Platform SDK, we do have some code samples in the MSDN documentation. Of these, there is sample code for MsiSetExternalUI and MsiSetExternalUIRecord. Of the messages, progress is the one that will occur most frequently so we have a sample for that. Once the progress sample is in place, the work remaining is to expand the number of case statements handled to match the list of message types from INSTALLUI_HANDLER_RECORD. These case statements will each need to decide whether further parsing is required and we've documented that too at Parsing Windows Installer Messages. Sometimes the message parsing is going to require communicating a message back to the Windows Installer which you can learn to do with Returning Values from an External UI Interface Handler.

Third switch to your favorite User Interface design environment

The Windows Installer UI tables are from the Wizard 97 era of UI guidelines. User Interface design has some a long way in the 10 years since and the Windows Installer UI tables have not tried to keep up all that much. The Windows Installer team has advised ISVs seriously consider building their own favorite UI when they reach the limits of the Windows Installer.

How about a sample?

Sorry, we don't have one yet but we do have it in the list of feedback that we plan to work on after we finish the engine work itself.

Arbitrary labels used as Primary keys must not be changed between versions

Windows Installer Team — Wed, 07 Mar 2007 21:17:00 GMT

Summary

Msi Editing tools that write auto generated references inside installer tables may cause unnecessary content to be included inside a patch. ‘Patching’ components with unchanged content may cause them to be uninstalled when the patch is removed thereby breaking the original application.

Scenario

“I create a small patch for my product. When I selectively uninstall the patch my original product is broken. The trouble is I’m using Msi 3.x and this isn’t supposed to happen. Doesn’t Msi 3.x ‘cache’ whatever I patch so I can just roll it back when I uninstall? I have followed all the rules to the letter but can’t see where things are going wrong?”

This Is How I Can Reproduce This Behaviour

I create an installation msi for my simple single file application msiExplorer.exe. There is nothing untoward about this installation. The file goes in Program Files\msiExplorer and puts a shortcut on the desktop. The installation also creates a single registry key HKLM\Software\msiExplorer with value Text set to “A”. It installs. It works. Here’s the registry table:

Next, I create a new ‘upgraded’ version of this product. The only thing I change is the label in the registry column of the registry table. (Why would I want to do that!? – well just bear with me and I’ll explain below). I change the label to “RegKey2”.

Now I go through the patch creation process by duly creating a PCP file. In the PCP I specify the old ‘RTM’ msi and the new ‘updated’ msi – the usual routine. When I execute MsiMsp.exe it works. No errors reported. I can even load the original RTM msi database into Orca and overlay it with my new msp. It confirms that the registry table has been modified and shows me what is now included in the patch.

Notice how the actual Registry key, value and data are the same. Only the Registry column has changed.

Ok, I install RTM. It runs without problem; the registry key is duly created. I apply the patch (msiexec /p msiExplorer.msp). It installs, it runs. The Registry key looks the same – well it would wouldn’t it? At this stage it’s difficult to tell who was responsible for writing that registry value – the RTM install or the subsequent patch.

However I know the patch has been successfully applied because when I look in Add\Remove programs, there is my app and the patch correctly listed.

So everything looks good. Unfortunately the trouble starts when I decide to selectively remove MsiExplorer_Patch1 (msiexec /i msiExplorer.msi MSIPATCHREMOVE=msiexplorer.msp). The patch uninstall executes successfully, Add\Remove programs shows it has been removed and I think I’m ok.

But when I look in the registry.......

.........my registry key has gone. So now you can imagine when I run my app – if it depended on this key – it’s going to fail.

Why does that happen?

The key aspect of the scenario is that the registry key with a new label ‘looks’ like a new registry resource added by the patch. When a patch is removed, the new product is restored to its view minus the patch. Additionally, the Installer processes the patch being removed for any resources that it added. It then schedules removal for those resources. Therefore, while the key with label RegKey1 became active (the verbose log file shows it being written).........

........... it was later deleted per label RegKey2 as part of the added resource cleanup (the last portion of the verbose log file before the end opcode).

So How Could You Unknowingly Get Into This Situation?

I’m using an ‘industrial strength household name Msi Editing tool’ (ISHNMET). It’s a very good product. It has a nice feature which will read a COM Server file and automatically extract the COM registration information and populate the tables. One of these tables is the registry table. It therefore populates the registry column with arbitrary labels Registry1, Registry2...etc. Here’s a mock up of how it might look:

I have to rebuild my msi package every day and have automated the process. The developers submit their updated files and the tables are built by script. When the msi is built by the ISHNMET it does its trick of automatically extracting the COM information. If the developer has built some extra COM functionality into a dll the entries are inserted mid table bumping all the lower rows down. The naming algorithm just re-labels all the rows. In this example Registry4 gets bumped down a row and re-labelled as Registry5

Now when we go through our patch creation process we correctly pick up that MsiExplorer.exe component has changed but inadvertently include component ‘SomeComponent’ because the label changed! Now we are going to deliver a patch which includes the problem discussed above.

To be fair the very latest versions of ISHNMET try to minimise this scenario. However you might for example delete a registry entry and then change your mind, re-create it using the GUI and have it reappear in the registry table with a brand new label. So it probably pays to be aware of the dangers of arbitrary labels.

Does this happen anywhere else?

Exactly the same issue applies to the file table. If the ISHNMET uses arbitrary labels for the files it is adding to the file table then they are subject to the same vulnerability. Where the label in the file table is used as the keypath in the component, it is automatically changed at both reference points when re-labelling occurs. From the ISHNMET point of view this keeps the referential integrity between Component and File nice and tidy. From our point of view though, this will be picked up by MsiMsp.exe. You could finish up attempting to patch a file with an identical copy. Here is what this looks like with my simple example:

Modify the File column of the file table (Was msiExplorer.exe, now msiExplorer1.exe)

... and modify the keypath reference in the component table....

Create the patch and just to confirm it, overlay the RTM msi with the msp.

Install RTM. Install the patch. Use Add\Remove programs to confirm the patch is registered

You might even inspect the patch cache and notice that no copy of msiExplorer.exe has been saved.

Now selectively uninstall the patch and the original msiExplorer.exe (The one in Program Files\msiExplorer) has disappeared. Try to run the shortcut and if you’re lucky the executable will be restored via install-on-demand resilience or in my case, just to prove the point, I hid the source msi so that I could see the install-on-demand dialog.

The app is broken.

This same explanation above works for the File as well – and it should be noted that you’d need to maintain the same filekey for binary delta patching to work (just look at the Patch table and you’ll know why by reviewing the primary key columns for that table)

Here’s the Message

The Installer’s format is a relational database. Identity is expressed by the primary key – which is why it is so crucial. An item is found in the database by searching for its primary key. That’s how transforms can know which data to modify (efficiently) and how Patchwiz can determine what has changed. It’s imperative that the primary keys are not changed between versions of the package.

[Author: Robin Drake]

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 and Restart Manager: MSI Files-In-Use V2

Windows Installer Team — Tue, 12 Dec 2006 00:33:00 GMT

Introduction

Files-In-Use functionality is among the countless services that Windows Installer exposes for setup authors to leverage for their application install/maintenance. This functionality lets setup authors display the processes that hold on to files that would be updated by this install. The user would want to shut those processes before continuing with the install to ensure that the install wouldn’t require a reboot. The current Files-In-Use mechanism involves enumerating the HKEY_PERFORMANCE_DATA key using registry API for information on processes and the PE images that they have held in-use. This works well in scenarios where the process holding the file in use has a visible window that the user can shut down.

Usage of the new Restart Manager API’s will allow Windows Installer to display processes such as: system services, tray applications or applications that have no visible window that require shutting down to avoid a reboot. Additionally, Restart Manager provides additional functionality above-and-beyond enhanced files in use detection, including:

· Shutting down of all or selected processes.

· Automatic restart of processes that were shutdown to install the in-use files.

· Ability to join a currently running Restart Manager session to consolidate shutdown/reboot across multiple installations.

· Appilications that had been shut down, have the opportunity to be restarted to a state that they were before being shut down.

Terminology

Sessions. Sessions in this blog refer to Terminal Service sessions. On Vista services run in session 0, while users log in to different non-zero sessions.

Client. Client in this blog refers to the invoker of the install. Remember that while an install could be invoked by a call to MsiInstallProduct, MsiApplyMultiplePatches, etc., the install (updating the system) is actually performed by the Windows Installer service. This is a different process running in session 0 (on Vista).

Comparison of Pre-Vista Files-In-Use Vs Vista Files-In-Use

Basic UI

A new dialog resource is added to Windows Installer on Vista that is displayed when running in basic UI mode. This dialog, unlike its legacy counterpart displays the processes that are holding onto files-in-use. Additionally, this dialog will also provide users with the option to shutdown/restart these processes to avoid the reboot. The figure below compares the basic UI files-in-use dialog boxes on Pre-Vista and Vista. Note how due to the better detection mechanism of restart manager, we are able to display a service that needs to be stopped for this install to actually avoid a reboot.

Full UI

When run in full UI, to leverage the restart manager’s abilities completely, the package author could provide a new MsiRMFilesInUse dialog box. See the image below for a comparison of how the old files-in-use dialog looks on XPSP2 and how the new RM files-in-use dialog on Vista looks like.

External UI

Pre-Vista, external UI handlers could listen to files-in-use messages using the INSTALLLOGMODE_FILESINUSE flag. These setups would then receive a INSTALLMESSAGE_FILESINUSE message with list of processes that need to be shutdown for the install to not require a reboot. These setups will continue to receive these messages even on Vista.

New setups, however, will get chance to leverage the Windows Installer-Restart Manager interaction to shutdown and restart those processes automatically. Such setups could listen to the INSTALLMESSAGE_RMFILESINUSE message after they subscribe to it in their call to MsiSetExternalUI by specifying INSTALLLOGMODE_RMFILESINUSE in the flags to this call. The table below summarizes Windows Installer’s response to various return values from an external UI that handles the INSTALLMESSAGE_RMFILESINUSE message

Return Value	Windows Installer’s action
IDOK	Will request Restart Manager to shut down and restart the applications that hold files in use
IDCANCEL	Will cancel the installation
IDIGNORE	The installation will go on, although a reboot will be required at the end
IDNO	If the package has MsiRMFilesInUse dialog then 1610 Message will be sent. If MsiRMFilesInUse dialog is not present then INSTALLMESSAGE_FILESINUSE message will be sent to the UI handlers.
IDRETRY	Will cause Windows Installer to send the legacy INSTALLMESSAGE_FILESINUSE message to the UI handlers
-1	Will be treated as an error and will end the installation

No UI

When a silent install is performed, Windows Installer will use restart manager to detect the processes that need to be shutdown to mitigate the reboot and will request restart manager to automatically shutdown these processes. Upon completion of the update, Windows Installer will request restart manager to start up the processes.

Controlling Windows Installer’s interaction with Restart Manager

Windows Installer provides the following properties and policy to let setup authors and IT admins fine tune their setup’s behavior:

MSIRESTARTMANAGERCONTROL: This property specifies whether the Windows Installer package uses the Restart Manager or FilesInUse Dialog functionality.

MSIRMSHUTDOWN: This property determines how applications or services that are affected by an update should be shut down while a reboot is being mitigated.

MSIDISABLERMRESTART: This property determines whether applications or services that are affected by an update are restarted when a reboot is being mitigated by Windows Installer's interaction with Restart Manager

DisableAutomaticApplicationShutdown: This policy specifies whether Windows Installer uses the Restart Manager or FilesInUse Dialog functionality.

Custom Actions and Restart Manager

Setup authors could add additional resources that need to be released as part of the setup using the restart manager session handle that Windows Installer provides to them via MsiRestartManagerSessionKey property.

Custom actions can query the value of the MsiRestartManagerSessionKey property and use it in a call to RmJoinSession API. Custom actions that call RmJoinSession API must call RmEndSession API too once they are finished adding resources. Also, custom action should not call the RmShutdownApplications, RmGetAffectedApplications and RmRestartApplications API directly and should just use the restart manager’s resource addition/filtering API.

Since all files-in-use detection and process shutdown would be completed in InstallValidate action, the MsiRestartManangerSessionKey property will be cleared in Windows Installer’s InstallValidate action.

Windows Installer-Restart Manager Interaction in Detail

1. During engine initialization, if Windows Installer’s interaction with RM is not disabled by a property/policy the service starts up an RM session and sets the MsiRestartManangerSessionKey property.

2. During costing, Windows Installer adds file resources that it wants RM to monitor.

3. During InstallValidate, Windows Installer requests RM to find out what all processes need to be shutdown for the install to succeed.

a. If RM detects that the file is held in use by a critical process or the client of this setup or a custom action server or by the Windows Installer service itself then a reboot can not be mitigated. In such a case:

i. For legacy MSI packages it will continue the install.

ii. For new MSI packages with MsiRMFilesInUse dialog it will send out 1610 error message.

b. If the package is authored such that the services detected by RM would be shutdown because of the authoring of the Service* tables then those services will not be displayed in the files-in-use dialogs.

4. It then sends a message to the client requesting it to see if it can shutdown these applications. Upon receiving this message, the client then interacts with RM and compiles a list of processes that it can shutdown. If in this process:

a. RM finds that a process is being run in another user’s session then, it informs the caller that it cannot shut it down.

b. RM finds that the client does not have enough credentials to shutdown the process then, it informs the caller that it cannot shut it down.

5. If the client detects any reboot, it informs the service of this. The service then warns the user that a reboot might be needed (as outlined in 3.a.i and 3.a.ii).

6. If the client does not detect any reboot then the client sends the INSTALLMESSAGE_RMFILESINUSE message to:

a. External UI handlers (if one exists that has specified using the INSTALLLOGMODE_FILESINUSE flag).

b. If External UI handlers do not handle the message, it is forwarded to the internal UI handler.

7. Based on how the UI handlers respond to the INSTALLMESSAGE_RMFILESINUSE message, the service would continue its processing accordingly.

8. If the UI handler requests Windows Installer to shut down the processes:

a. Windows Installer service will request RM to shutdown any services that might have to be shutdown. If there are no services to shutdown then, nothing is done.

b. Windows Installer service then requests the client to shutdown the required processes.

The way RM shuts down these processes can be controlled using the MSIRMSHUTDOWN property.

9. If RM could not shutdown any of the processes, then Windows Installer displays 1611 message if the package has MsiRMFilesInUse dialog. If not, no message is displayed and the install continues (but a reboot might be needed). RM might not shutdown a process, if the process doesn’t respond to WM_ENDSESSION or WM_CLOSE messages or if it is a service, it does not respond to SCM requests.

10. If RM succeeds in shutting down the processes, then the install will not require any reboot.

11. If after Step 7, UI handlers request the service to send the INSTALLMESSAGE_FILESINUSE message, the service responds to the request.

12. Upon completion of the install, Windows Installer Service requests RM to restart all the services that it shutdown, while the client requests RM to restart all the applications that registered using the RegisterApplicationRestart API.

Windows Installer-Restart Manager-UAC

During non-GP (group policy) based first-time installs of non-UAC compliant MSI packages, Windows Installer interacts with UAC to obtain admin credentials before performing an install. Once, those credentials are obtained they are used through out the install.

Shutting down elevated processes

If during this install, any elevated processes are detected in the same session as the Windows Installer service, they will be shutdown by the Windows Installer service using the credentials provided by the user. If however, there was any elevated process running in the user’s session (different from the session that Windows Installer service is running), then the user will not be able to shut down those elevated processes because, the service cannot pass on credentials of the elevated process to an un-trusted client.

So, in a nutshell Windows Installer cannot mitigate reboots caused by elevated processes. However, this is possible if RM lets its callers shutdown processes across sessions. This is a work in progress that would hopefully be addressed post-Vista.

Shutting down services while applying a digitally signed patch

Windows Installer will not prompt users for elevated credentials when a patch is digitally signed and its signature recognized by the original MSI in its Digital* tables. In this case, Windows Installer service does not have the elevated admin credentials to stop services that are not part of the MSI package. So, it will not be able to shutdown those services. If however, the package is authored correctly then the services that the MSI cares about will be stopped before the files carried by it are updated, thereby mitigating the reboot.

How does my application restart in its old state after the update?

When Windows Installer requests restart manager to shutdown applications, restart manager sends out WM_QUERYENDSESSION, WM_ENDSESSION, WM_CLOSE respectively to GUI applications. When these applications receive these messages, they have the opportunity to save any user data and/or application state information to exit gracefully. This ability for applications to save their state is informally termed as freeze-dry. Applications that register with restart manager using the RegisterApplicationRestart API would be restarted when Windows Installer is done with the install and requests RM to restart all the applications that were shutdown and were registered with it. When these applications are restarted it would appear to the user that they were revived from their frozen state; hence the name: freeze-dry. Read the Guidelines for Applications and Services section on MSDN to learn more on how to support this cool new feature in your applications.

[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

Restart Manager video available on Channel 9

Windows Installer Team — Mon, 04 Dec 2006 21:30:00 GMT

Hello everyone --

As many of you know, one of the great new features Windows Installer supports on Windows Vista is Restart Manager. I just ran across a video on Channel 9 that provides a lot of good information on how to make your application "Restart Manager Aware." Good viewing if you are planning on supporting Restart Manager in your installer and you want to know what you need to do in your application to make a seamless experience.

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

Check out the UAC video on Channel 9

Windows Installer Team — Fri, 01 Dec 2006 22:14:00 GMT

Channel 9 did an interview with Steve Hiskey and Jon Schwartz on the UAC team. Check out the video here if you want to learn more about UAC.

[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 Troubleshooting Tips from First Week of November

Windows Installer Team — Fri, 11 Nov 2005 18:00:00 GMT

Question 1

What is the correct way to find whether a certain product (msi based setup) is installed on the machine?

Answer 1

Searching for Existing Applications, Files, Registry Entries or .ini File Entries [Windows Installer] lists the built-in detect methods. In this case, the CompLocator Table [Windows Installer] is intended to have the needed functionality.

To find the ComponentId for the CompLocator row,

use Orca to open the MSI of the targeted product
find the key binary dependency in the file table
1. select the file table from the Tables window
2. Choose Edit | Find from the menu
3. In the Find dialog, type in the name of the file that you have a binary dependency on into the Find what edit box then click the Find Next button
4. Continue to hit Find Next on the Find dialog until a row in the file table will be highlighted so click the Cancel button on the Find dialog
copy the Component_ column value from the file table

Select the second column of highlighted row and choose Edit | Copy cell menu item

find the component in the component table

select the component table from the Tables window
Choose Edit | Find from the menu
In the Find dialog, paste the value from step 3 into the Find what edit box then click the Find Next button
Continue to hit Find Next on the Find dialog until a row in the component table will be highlighted so click the Cancel button on the Find dialog

Grab the GUID from the ComponentId

Select the second column of highlighted row and choose Edit | Copy cell menu item

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Windows Installer Troubleshooting Tips From Halloween

Windows Installer Team — Wed, 09 Nov 2005 18:00:00 GMT

Question 1

In my lab automation that silently installs Windows Installer packages. This automation is inconsistently getting Error 1618 from its msiexec calls. Please help unblock this scenario as it's inhibiting our push to ship.

Troubleshooting 1

First, start with the MSDN Library and run a search for "windows installer" 1618. This query (when I click it) turns up Initialization Errors [Windows Installer] as the sixth hit. This page contains

Error code	Value	Error
ERROR_INSTALL_ALREADY_RUNNING	1618	An installation is already in progress

Next, have a look at the machine event log and look for the messages per the MSDN Topic Event Logging

Finally, when one puts this information together, the chances are high that another process, such as SMS or Group Policy, is triggering a silent install of a MSI based product thus the mutex is preventing the simultaneous install of the second product.

Solutions 1

To solve for this scenario, one needs to understand the mechanics of determining if Windows Installer is busy and then one needs to consider the appropriate behavior for their application for the "busy" case.

Generally if Windows Installer is busy , Windows Installer will set the Mutex. For a sample demonstrating the mechanics of checking the mutex, see the Windows Installer Platform SDK bootstrapper code example:

    HANDLE hMutex = 0;
    bool bInstallRunning = false;

    const char *szMutexName = "Global\\_MSISETUP_{2956EBA1-9B5A-4679-8618-357136DA66CA}";
    hMutex = WIN::CreateMutex(NULL /*default security descriptor*/, FALSE, szMutexName);
    if (!hMutex || ERROR_ALREADY_EXISTS == GetLastError())
    {
        bInstallRunning = true;
    }
    else
    {
        bInstallRunning = false;
    }

    // only run one instance at a time
    if (bInstallRunning)
    {
        // silently return - correct return code ?
        uiRet = ERROR_INSTALL_ALREADY_RUNNING;
        goto CleanUp;
    }

    // do work here

CleanUp:
    if(hMutex)
        CloseHandle(hMutex);

For Windows Installer 3.0 or greater, we recommend switching from the mutex to attempting to stop the msi service. If you are unable to stop the service, the service is busy installing another product. In pseudocode, these mechanics would look like

if (MSIServer is not running)
    bInstallRunning = true; // because if the service isn't running there can't be an install running
else  if (MSIServer accepts SERVICE_ACCEPT_STOP)
    bInstallRunning = false; // because if it can stop it can't be installing something
else
    bInstallRunning = false; // because it won't accept the stop, so it's doing an install.

With either of these solutions, a non-privileged context will be unable to detect the state of the engine.

Now that you know the mechanics, you need to consider what to do when the Windows Installer is "busy". There are a number of options and which one you choose depends on your judgment. Some solutions choose surface the fact that the Windows Installer is busy and suggest the user try again later. Other solutions choose to put the "busy" check in a polling loop and attempt an auto recover from the mutex.

Question 2

I have a Windows Installer package that InstallInitialize shows all the features and components are installing Action:Local but after the install the feature is advertised. Can you help explain this? (msi packages and verbose logs sent too)

Answer 2

Generally to find these issues I look at the components with conditions. In this case we have the following Component Table Fragments

Component ComponentId Directory_ Attributes Condition KeyPath

C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650 {3162C002-E983-4C45-BE65-A0EADF35AD49} SDK_DIR.540EA3C0_A5E9_41EA_A585_822C09EA2650 4 IS_ROOT_HEALTH_SERVICE=0 R_Server_ConnectorKeys_For_NonRMS10.540EA3C0_A5E9_41EA_A585_822C09EA2650

C_Core_ConnectorKeys.80B659D9_F758_4E7D_B4FA_E53FC737DCC9 {43DC7EF4-E685-45E1-9B3B-9843A2853E43} CORE_DIR.80B659D9_F758_4E7D_B4FA_E53FC737DCC9 4 USE_SETTINGS_FROM_AD=0 R_Core_Connector01.80B659D9_F758_4E7D_B4FA_E53FC737DCC9

Component	ComponentId	Directory_	Attributes	Condition	KeyPath
C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650	{3162C002-E983-4C45-BE65-A0EADF35AD49}	SDK_DIR.540EA3C0_A5E9_41EA_A585_822C09EA2650	4	IS_ROOT_HEALTH_SERVICE=0	R_Server_ConnectorKeys_For_NonRMS10.540EA3C0_A5E9_41EA_A585_822C09EA2650
C_Core_ConnectorKeys.80B659D9_F758_4E7D_B4FA_E53FC737DCC9	{43DC7EF4-E685-45E1-9B3B-9843A2853E43}	CORE_DIR.80B659D9_F758_4E7D_B4FA_E53FC737DCC9	4	USE_SETTINGS_FROM_AD=0	R_Core_Connector01.80B659D9_F758_4E7D_B4FA_E53FC737DCC9

Cross Referencing the C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650 GUID {3162C002-E983-4C45-BE65-A0EADF35AD49} with the install log and one finds

MSI (s) (44:6C) [14:26:41:656]: Executing op: ComponentUnregister(ComponentId={3162C002-E983-4C45-BE65-A0EADF35AD49},,BinaryType=0,PreviouslyPinned=1)

Now I take the condition and search for it in the log

MSI (s) (44!AC) [14:26:26:828]: PROPERTY CHANGE: Modifying IS_ROOT_HEALTH_SERVICE property. Its current value is '0'. Its new value: '1'.

...

Property(S): IS_ROOT_HEALTH_SERVICE = 1

If it were true that this property was set, it would cause the component to be absent and its absence would cause the feature to appear advertised.

Design Suggestion for Question 2

If the advertised state on the feature is the problem, I suspect what’s called for here is another feature. One could have a child feature that just contains the components that will be toggled and is marked to follow parent. Depending on whether that works for all scenarios, there is also the option to have the new feature sit at the root and then write code to toggle the state of the feature.

Editing credit also belongs to

Phil Wilson, MSI MVP,

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Hem, MSI Team Dev. You can get other Hem insights about developing for Windows Installer from the Windows Installer Chat Archives

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Authoring to Windows Installer 4.0 Features mentioned at PDC 2005

Windows Installer Team — Fri, 04 Nov 2005 08:40:00 GMT

As Tyler recently mentioned, you can find the Professional Developers Conference 2005 session and presentation of the Windows Installer 4.0. Here's a preliminary view of how to author to these features. Note: This documentation is preliminary and is subject to change.

Restart Manager Support

As Tyler presented in the slide titled "Windows Installer 4.0: Fewer Reboots", Restart Manager support in MSI just requires MsiRMFilesInUse be present in the package when installing on Windows Vista. This dialog looks a lot like the FilesInUse dialog with a couple of radio buttons added under the list box to represent the new Restart Manager Option along with the fallback option to the old behavior.

Control Table

Dialog_ Control Type X Y Width Height Attributes Property Text Control_Next Help

MsiRMFilesInUse DlgLine Line 0 234 294 0 1

MsiRMFilesInUse Banner Bitmap 0 0 374 44 1 NewBinary1

MsiRMFilesInUse DlgDesc Text 21 23 292 25 65539 Some files that need to be updated are currently in use.

MsiRMFilesInUse DlgTitle Text 13 6 292 25 65539 {&MSSansBold8}Files in Use

MsiRMFilesInUse DlgText Text 21 49 348 17 3 The following applications are using files that need to be updated by this setup.

MsiRMFilesInUse BannerLine Line 0 44 374 0 1

MsiRMFilesInUse RadioButtonGroup1 RadioButtonGroup 19 187 343 40 16777219 ShutdownOption List

MsiRMFilesInUse List ListBox 21 66 331 118 7 FileInUseProcess OK

MsiRMFilesInUse OK PushButton 228 244 66 17 3 OK Cancel

MsiRMFilesInUse Cancel PushButton 299 244 66 17 3 Cancel RadioButtonGroup1

ControlEvent Table

Dialog_ Control_ Event Argument Condition Ordering

MsiRMFilesInUse OK EndDialog Return 1 1

MsiRMFilesInUse OK RMShutdownAndRestart 0 ShutdownOption="ShutdownOption1" 2

MsiRMFilesInUse Cancel EndDialog Exit 1 1

Dialog Table

Dialog HCentering VCentering Width Height Attributes Title Control_First Control_Default Control_Cancel

MsiRMFilesInUse 50 50 374 266 19 [ProductName] OK OK Cancel

Property Table

Property Value

ShutdownOption ShutdownOption1

RadioButton Table

Property Order Value x Y Width Height Text Help

ShutdownOption 1 1 6 9 331 14 Automatically close all applications and attempt to restart them after setup is complete.

ShutdownOption 2 2 6 21 322 17 Do not close applications. (A reboot will be required.)

Dialog_	Control	Type	X	Y	Width	Height	Attributes	Property	Text	Control_Next
MsiRMFilesInUse	DlgLine	Line	0	234	294	0	1
MsiRMFilesInUse	Banner	Bitmap	0	0	374	44	1		NewBinary1
MsiRMFilesInUse	DlgDesc	Text	21	23	292	25	65539		Some files that need to be updated are currently in use.
MsiRMFilesInUse	DlgTitle	Text	13	6	292	25	65539		{&MSSansBold8}Files in Use
MsiRMFilesInUse	DlgText	Text	21	49	348	17	3		The following applications are using files that need to be updated by this setup.
MsiRMFilesInUse	BannerLine	Line	0	44	374	0	1
MsiRMFilesInUse	RadioButtonGroup1	RadioButtonGroup	19	187	343	40	16777219	ShutdownOption		List
MsiRMFilesInUse	List	ListBox	21	66	331	118	7	FileInUseProcess		OK
MsiRMFilesInUse	OK	PushButton	228	244	66	17	3		OK	Cancel
MsiRMFilesInUse	Cancel	PushButton	299	244	66	17	3		Cancel	RadioButtonGroup1

Dialog_	Control_	Event	Argument	Condition	Ordering
MsiRMFilesInUse	OK	EndDialog	Return	1	1
MsiRMFilesInUse	OK	RMShutdownAndRestart	0	ShutdownOption="ShutdownOption1"	2
MsiRMFilesInUse	Cancel	EndDialog	Exit	1	1

Dialog	HCentering	VCentering	Width	Height	Attributes	Title	Control_First	Control_Default	Control_Cancel
MsiRMFilesInUse	50	50	374	266	19	[ProductName]	OK	OK	Cancel

Property	Value
ShutdownOption	ShutdownOption1

Property	Order	Value	x	Y	Width	Height	Text	Help
ShutdownOption	1	1	6	9	331	14	Automatically close all applications and attempt to restart them after setup is complete.
ShutdownOption	2	2	6	21	322	17	Do not close applications. (A reboot will be required.)

Elevation Privleges Not Required

As Tyler presented in the slide titled "What's new in MSI: UAP Elevation and Installs and Patches", you can set the msidbSumInfoSourceTypeLUAPackage bit in the Summary Information Stream of a MSI and prevent the Windows Installer from invoking the UAP elevation prompt. To do this, one just needs to set the 4th position (0x08) in the Word Count property. You can do this with the Windows Installer SDK tool msiinfo.exe. As an example, here's the command and output before setting the bit



c:\>msiinfo product.msi

ClassId = {000C1084-0000-0000-C000-000000000046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Installation Database
[ 3][/j] Subject = Testing
[ 4][/a] Author = Microsoft Corp.
[ 5][/k] Keywords = Installer,MSI,Database
[ 6][/o] Comments = Contact:  Your local administrator
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033
[ 9][/v] Revision = {62B8B42B-9D2E-49C2-A791-C90F212940B8}
[12][/r] Created = 2005/10/25 23:00:48
[13][/q] LastSaved = 2005/10/25 23:00:48
[14][/g] Pages(MSI Version Used) = 200
[15][/w] Words(MSI Source Type) = 0
<snip>

Then one runs msiinfo with the /W switch to set the Word Count property like so


c:\msiinfo product.msi /W 8

Then rerun the view to confirm the setting took like so



c:\>msiinfo product.msi

ClassId = {000C1084-0000-0000-C000-000000000046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Installation Database
[ 3][/j] Subject = Testing
[ 4][/a] Author = Microsoft Corp.
[ 5][/k] Keywords = Installer,MSI,Database
[ 6][/o] Comments = Contact:  Your local administrator
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033
[ 9][/v] Revision = {62B8B42B-9D2E-49C2-A791-C90F212940B8}
[12][/r] Created = 2005/10/25 23:00:48
[13][/q] LastSaved = 2005/10/25 23:00:48
[14][/g] Pages(MSI Version Used) = 200
[15][/w] Words(MSI Source Type) = 8
<snip>

Windows Vista Multilingual User Interface (MUI) Shortcut Support

As Tyler presented in the slide titled "What's new in MSI: More...", you can now add Windows Vista Multilingual User Interface (MUI) Shortcut support to your MSI. The way you do this is to add for new columns to the Shortcut Table of your MSI. These are rows DisplayResourceDLL, DisplayResourceId, DescriptionResourceDLL, DescriptionResourceId placed as follows:

Column	Type	Key	Nullable
Shortcut	Identifier	Y	N
Directory_	Identifier		N
Name	Filename		N
Component_	Identifier		N
Target	Shortcut		N
Arguments	Formatted		Y
Description	Text		Y
Hotkey	Integer		Y
Icon_	Identifier		Y
IconIndex	Integer		Y
ShowCmd	Integer		Y
WkDir	Identifier		Y
DisplayResourceDLL	Formatted		Y
DisplayResourceId	Integer		Y
DescriptionResourceDLL	Formatted		Y
DescriptionResourceId	Integer		Y

Both the DisplayResourceDLL and DescriptionResourceDLL values represent fully qualified paths to files on disk that the MUI system will load (per the Windows Vista protocol) to get the localized strings. Both the DisplayResourceDId and DescriptionResourceId represent the resource index of the string of interest. This integer is non-negative and will be negated before the call to the Shell API to reguster the MUI shortcuts.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

How do I get the Escape key to work on a Windows Installer dialog?

Windows Installer Team — Mon, 31 Oct 2005 17:00:00 GMT

Question

How do I get the Escape key to work on a Windows Installer dialog?

Answer

Edit the Dialog table, go to the record that contains the dialog and enter your No/Cancel button's key (Name field in Control table) into the Control_Cancel field.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Advertising and ARPSYSTEMCOMPONENT

Windows Installer Team — Thu, 20 Oct 2005 00:30:00 GMT

Scenario

On Windows XP, I am advertising an MSI that has ARPSYSTEMCOMPONENT set to 1 but it appears in ARP anyway. Is this by design? Is there a workaround

Indeed, once I fault in the product, the ARP entry goes away. There’s not much to see in the MSI. Just set the property and run an advertisement. My guess is that the advertise script does not allow for this case, so there is probably no way that I can work around it.

Insight

Your analysis is correct. Advertisement doesn't write to the Uninstall key so the app shows up because of ARP's enumeration through MsiEnumProducts and the fact that there's no uninstall key reference with SystemComponent to ignore that particular product.

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Jeff, Microsoft Dev

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

What are the limits for a large MSI package?

Windows Installer Team — Wed, 19 Oct 2005 19:58:00 GMT

MSI MVP Stefan Krueger posted a excellent response to the question "What are the limits for a large MSI package?" in a FAQ entry at InstallSite.org

Thanks for the hard work Stefan ;^)

Our patches seem to work fine, yet none of the files on the disk are replaced.

Windows Installer Team — Mon, 03 Oct 2005 09:00:00 GMT

Question

I am seeing a very strange issue with patches on msi 2.0, our patches seem to work fine, yet none of the files on the disk are replaced.

I tried regenerating the patches with the 2.0 toolset , but that did not help.

Answer

For MSI20 Patches, you will need to pass property REINSTALL=ALL.

You can omit REINSTALL=ALL with MSI30 and higher as it is smart enough to detect which features has changed.

More sophisticated patching users add a type 51 custom action to set the

REINSTALL property
REINSTALLMODE property
Preselected property (to turn off the selection tree dialog)

before CostInitialize. Each of these was conditioned on the PATCH property. You could just set REINSTALL to ALL, but could cause resolve source issues for files you’re not even patching. These patching users keep track of the features their updating when they generate our patches then set the REINSTALL property to that comma-delimited list. That list is only the features they’re updating so that they don’t have the chance of resolve source issues for unpatched features.

Question

I was wondering if there was any downside to specifying ALL, I assume this will also be the case with 3.0.

Answer

Not really, no.

Question

One final question, is there any problem using the 3.0 toolset to generate 2.0 compatible patches (assuming use any of 3.0 patching features such as patch sequencing)

Answer

Not really, no. Do make sure you set the schema to 200 (MSI 2.0) to support 2.0 patches, though. By default PatchWiz.dll 3.0+ will generate 3.0-style tables at least in the MSP, but the schema for existing tables hasn’t changed to the point of breaking 2.0 tables. Newer PatchWiz.dll to generate 2.0-style patches just fine.

Content credit also belongs to

Ken, MSI Dev In Test, You can get other Ken insights about developing for Windows Installer from the Windows Installer Chat Archives
Heath, DevDiv Dev, You can get other Heath insights about developing for Windows Installer from the Heath Stewart's Blog

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Best Practice Guidelines for Building Quality Installs: Part 1, the Basics

Windows Installer Team — Tue, 27 Sep 2005 07:16:00 GMT

This is the first in a series of Best Practice Guidelines for Building Quality Installs . Let's start with the basics of quality Windows Installer (MSI) package. Prior postings the series: Introduction.

Build Components According to Component Rules

To ensure that the installation or removal of one program does not harm any other programs on the system and that the Windows Installer service correctly removes all resources connected with that program, your application installation package must adhere to the component rules.

All Components have a proper ComponentId GUIDs

Though the Component table’s ComponentId field is a nullable, the consequences for not providing a ComponentId is that the component is not uninstallable or manageable via the Windows Installer APIs.

Testability: scan Component table and for any row, confirm there is a component GUID in the ComponentID column.

All COM Servers must be a KeyPath of a Component

Do not include more than one COM server per component (per Organizing Applications into Components). If a component contains a COM server, this must be the KeyPath for the component.

Testability: scan file table and media for com servers. For any com server found, make sure it’s the KeyPath for a component.

No more than one target of Start menu or Desktop shortcut

Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut (per Organizing Applications into Components).

Testability: scan shortcut and directory tables for Start menu or a Desktop shortcut targets. Make sure no component has more than one Start menu or a Desktop shortcut target.

Pass MSI Validation Testing

Any error from the Internal Consistency Evaluators validation suite must be fixed. Warnings represent design guidance to the package author which should be studied for applicability. If warnings do not apply or will not be fixed, they must be added to the Vendor Questionnaire to inform testing automation and customers.

Customer Impact: Highly desired by corporate customers.

Testability: boot Orca on MSI file , click Tools | Validate, in Validaiton Output dialog uncheck the Show "INFO" Messages click Go, run without errors, document any warnings

Uninstallation

Your application’s package must correctly and fully uninstall the application. A pure MSI package does this automatically. If your package includes custom actions, you may need to proactively ensure that your application properly uninstalls with an uninstall custom action.

Customer Impact: Highly desired by corporate and retail customers.

Testability: snap system before install and after uninstall and any thing remaining on the system should be listed in the vendor questionnaire.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Why can't I patch or uninstall a component without a ComponentId?

Windows Installer Team — Tue, 20 Sep 2005 09:00:00 GMT

Question

Why can't I patch or uninstall a component without a ComponentId?

Answer

Check the Windows Installer documentation on Component Table:


ComponentId
A string GUID unique to this component, version, and language. 
Note that the letters of these GUIDs must be uppercase. Utilities such as GUIDGEN can generate GUIDs containing lowercase letters. The lowercase letters must be changed to uppercase to make these valid component code GUIDs.

If this column is null the installer does not register the component and the component cannot be removed or repaired by the installer. This might be intentionally done if the component is only needed during the installation, such as a custom action that cleans up temporary files or removes an old product. It may also be useful when copying data files to a user's computer that do not need to be registered.

So, I’d say this behavior is documented and is by design.

What’s happening under the hood?

Remember that patching is a form of repair. So, when you have a component which doesn’t have a component ID then that component can not be serviced. The reason for that is when you do not provide a component ID then that component will not be registered. So, when Windows Installer tries to find the state of that component then that component will be unknown to it. Furthermore, the request/action state for that component become no ops (unless you explicitly change the component state via a CA). As a result, the component will not be serviced or its baseline cached.

Even if you use a custom action (CA) to set the component action states to local so that Windows Installer will be forced to service the component, you might end up in scenarios wherein the component might not be serviced per your expectations, because you would have made some false assumptions down the road. Bottom-line is: if you have some valid reason to create a GUID-less component, then use a CA to service/uninstall the component yourself than to trick Windows Installer do the job it isn't designed to do.

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