Don't your users hate it when they start a software application that then triggers a request for the installation media of a totally unrelated application?  How about some relief ...

Rob Mensching, the creator of WIX, has an excellent blog entry of 3/12/07 on this that describes the core issues - the link to his post is below.

I have also posted a comment on Rob's blog entry that there are basically two scenarios where this problem manifests itself:

1) Self-healing
2) Install-On-Demand

Of the two, Install-On-Demand presents the most challenging situation because it can happen when you have locked down end users who generally don't trigger self healing.  Additionally, Install-On-Demand is the most confusing of the two for end users because the Windows Installer dialogs that are displayed reference a totally different software application and potentially ask for installation media for this product.  If the install on demand cannot proceed, many users thing the application cannot be accessed.  The software application generally can be accessed by hitting "cancel" on all the displayed Windows Installer dialogs - but who wants to train their corporate end users to get into that habbit?

This problem is made worse when software is deployed with default feature lists and the windows installer package has been setup to cause some features to be set to be advertised on a generic install.  The best practice to minimize this would be to completely avoid advertised features when deploying.  For repackaged software this is not a problem as the feature structure created by repackaging tools rarely create advertised features.  Commerical software that you receive as a Windows Installer package may have advertised features in order to reduce the total amount of software that must be installed.  However, reviewing every software package for advertised features and using a response transform to turn them on or off can be tedious.

This made me wonder if a generic solution could be devised via a custom action or even better via the command line.  After kicking around the command line a bit - I *think* the following will work - although I've done limited testing, so please test on your own.

This solution involves the MSIEXEC command line, so if you are using group policy to deploy, you will still need to look at using response transforms.

When you execute an MSIEXEC command line that does not specify a feature list, any features set to default to advertising will be advertised.  Here is a command line that would cause this behavior if the package has advertised features:

MSIEXEC /i abc.msi /qn

By adding the "ADDDEFAULT=ALL" property any features that are set to be installed, but default to advertise will now be fully installed.  So this command line would fix the problem:

MSIEXEC /i abc.msi ADDDEFAULT=ALL /qn

At first glance it seems like ADDDEFAULT shouldn't change the install behavior, however, it would seem that all the properties that take a list of Feature Identifiers implicitly mean do a FULL install of the feature and override the behavior of doing an "advertised install" (yes I know it's confusing to say advertised install).

Updating command lines is generally much less work than updating packages - so I hope this can help a little with your cross-product install-on-demand problems.

As I mentioned I have done limited testing on XP SP2 (MSI 3.1), if your testing yields other results, please email me at Darwin@DesktopEngineer.com.

Rob Mensching's Post

Topic: Engineers Toolbox, Application Management, Windows Installer