COM Advertising with Self-Heal (SH) and Install-on-Demand (IOD)
Unwanted IOD activity can cause support calls and/or trouble when locked down end users, who generally don't trigger self healing, start seeing confusing Windows Installer dialogs. The dialogs can reference a totally different software application and potentially ask for installation media for that product.
If the IOD cannot proceed, many users think the application cannot be accessed. The application can generally be accessed by hitting 'cancel' repeatedly.
This problem is made worse when software is deployed with default feature lists and the Windows installer package has been set up 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 Wise tools rarely create advertised features.
Vendor supplied software that you receive as a packager may have advertised features. Reviewing every software package for advertised features and using a response transform to turn them on or off can be tedious.
A possible solution involves the MSIEXEC command line, so if you are using group policy to deploy, you will still need to look at using alternate methods.
When you execute an MSIEXEC command line that does not specify a feature list, any features set to default to advertising will be advertised. By using the ADDDEFAULT=ALL property / value any features that are set to be installed, but default to advertise will now be fully installed and NOT advertised. So this command line would fix the problem:
MSIEXEC /i package.msi ADDDEFAULT=ALL /qn
Reading the SDK does not necessarily steer one to thinking the ADDDEFAULT property should change the install behavior. However, it would seem that all the properties that take a list of Feature Identifiers implicitly do a FULL install of the feature and override the behavior of doing an advertised installation.