Doctor Deploys Blog

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.

Original post by Windows Installer Team

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 could build your foundation 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.

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

Original post by Windows Installer Team