Chained MSI not being executed during maintenance

[ACordner]

I have setup a BasicMSI project to chain the installation of 4 separate MSIs that comprise a complete application. Each chained MSI's installation is controlled by the user selecting features to be installed, and the Install Condition property for each chained MSI is set to install if not already installed and the feature name is found in either ADDLOCAL or REINSTALL:

Install Condition:
Not Installed AND (ADDLOCAL><"AssociatedFeature" OR REINSTALL><"AssociatedFeature")

This process is working great during initial installation - all selected features are installed and unselected features are not installed.

However, if I run setup again so that it enters maintenance mode, I select the Modify option and choose to install the features that were omitted from the initial install, the newly selected features are not getting installed! I have verified that the ADDLOCAL property contains "AssociatedFeature" and the Installed property of that feature is "Absent" and is being requested to be installed locally in the log file:

:
MSI (s) (20:24) [08:28:54:646]: PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'AssociatedFeature'.
:
MSI (s) (20:24) [08:28:55:005]: Feature: AssociatedFeature; Installed: Absent; Request: Local; Action: Local
:
InstallShield 8:28:55: Skipping chained package Pkg4 because install and remove conditions are false
:

Based on the value of the ADDLOCAL property and the Install Conditions I have setup, I cannot understand why the chained MSI is not getting launched.

[MichaelU]

Note that the conditions are evaluated by the parent MSI, so the clause "Not Installed AND (...)" prevents the condition from ever evaluating to true during a maintenance scenario. You may instead want to just tie this to a feature action state, something like &AssociatedFeature > 2 for install, and &AssociatedFeature < 3 for uninstall.

[ACordner]

OK, Thanks! That reminder helps a lot and makes sense. I think I have the conditions working fine now, but I have encountered another issue. The selected features correctly trigger the installation of the associated chained MSIs during initial installation, but again when doing a maintenance mode Modify to add another feature, MSI is attempting to launch the chained MSI but it appears it is failing to locate the file. The chained MSIs are NOT streamed because they would end up making the setup.exe > 700MB, which is undesirable.

Log file from initial setup:
MSI (c) (8C:88) [14:02:07:130]: Original package ==> Z:\MySetup\Chained MSI Install.msi
MSI (c) (8C:88) [14:02:07:130]: Package we're running from ==> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1e8a5.msi
:
MSI (c) (48:B0) [14:02:38:849]: ******* RunEngine:
******* Product: Z:\MySetup\MyFirstChainedMsi.msi
******* Action:
******* CommandLine: **********
MSI (c) (48:B0) [14:02:38:865]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (c) (48:B0) [14:02:38:865]: Machine policy value 'DisableUserInstalls' is 0
etc.


Log file from maintenance setup:
MSI (c) (CC:84) [15:54:00:448]: Original package ==> Z:\MySetup\Chained MSI Install.msi
MSI (c) (CC:84) [15:54:00:448]: Package we're running from ==> C:\WINDOWS\Installer\230ec.msi
:
MSI (c) (B8:CC) [15:54:11:731]: ******* RunEngine:
******* Product: MySecondChainedMsi.msi
******* Action:
******* CommandLine: **********
MSI (c) (B8:CC) [15:54:11:762]: Note: 1: 2203 2: MySecondChainedMsi.msi 3: -2147287038
MSI (c) (B8:CC) [15:54:11:762]: MainEngineThread is returning 2

In what folder is MSI expecting to find MySecondChainedMsi.msi during a maintenance mode install? I have tried manually copying the file to C:\Windows\Installer and various other places so MSI would find it, to no avail.

In the Chained MSI Packages settings, the Installation (run-time path) setting is set to:
[SourceDir]MySecondChainedMsi.msi

While this seems to be fine for the initial install, maintenance mode does not recognize it.

[ACordner]

After some research, it appears I have the chained MSIs working in maintenance mode as long as I run setup.exe from the source media! I had to change the Installation (run-time path) setting for each chained MSI to use [SETUPEXEDIR] instead of [SourceDir].

However, if I attempt to launch the setup using the Control Panel's Add/Remove Programs it still fails. I added "/l*v " to the registry's ModifyPath entry so that it would generate a log file and this is what I am getting:

MSI (c) (50:F8) [17:12:33:580]: ******* RunEngine:
******* Product: MySecondChainedMSI.msi
******* Action:
******* CommandLine: **********
MSI (c) (50:F8) [17:12:33:580]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (50:F8) [17:12:36:580]: Failed to grab execution mutex. System error 258.
:
MSI (s) (2C:98) [17:12:36:580]: ******* RunEngine:
******* Product: C:\MySecondChainedMSI.msi
******* Action:
******* CommandLine: **********
MSI (s) (2C:98) [17:12:36:580]: Note: 1: 2203 2: C:\MySecondChainedMSI.msi 3: -2147287037
MSI (s) (2C:98) [17:12:36:580]: MainEngineThread is returning 3
etc.

So, it appears [SETUPEXEDIR] does not resolve to a useable folder when using Add/Remove Programs.

[MichaelU]

I'm not quite sure the best approach for this scenario. SETUPEXEDIR is only set when launching from setup.exe, and SourceDir is a bit sticky. Namely if you try to resolve it during uninstall or patches, things can be messy. Yet for the scenario you want to support, you'd need to re-resolve it.

You may want to schedule a ResolveSource action which will set the SourceDir property, or check out its conditions. In particular, you may want to make sure it's run if any features are being installed (perhaps condition on ADDLOCAL being non-empty, perhaps use an OR'd list of your features gated by action state).