Can a Chained install run in repair mode

[Tim_Mayert]

Basically what I want to know is if there is a setting that needs to be set so that if you run a Chained Parent install package in repair mode that it would actually trigger the re-install/repair of all the children chained packages that were originally installed?

I know if I uninstall one of the children of a chained package that the repair of the parent will trigger the install of that now uninstall package, but if I do not uninstall any of the children packages then they are NOT triggered to be run again for repair. Here is what that section of the log states:

InstallShield 14:07:05: Skipping chained package Pkg61 installation because it is already installed
InstallShield 14:07:05: Skipping chained package Pkg58 installation because it is already installed
InstallShield 14:07:05: Skipping chained package Pkg57 installation because it is already installed

So if there is a setting to allow for this could someone let me know?

Thanks,

[ganesh2you]

Hi ,

I am not aware is there s any setting for that, But that is possible with script file modification, are u using MSI install shield script file ?

[Tim_Mayert]

We are only using Basic MSI projects as we have more demand for admin .msi pushes for our software and therefore can not go with an InstallScript MSI project type.

So if there is no way to trigger a repair mode of the individual install packages then does that also mean that we would not be able to attempt a minor upgrade when we go to the next version of the software, where some will be full major upgrades and others may only be minor upgrades :confused:

[MichaelU]

There is a "hidden" option to enable this scenario (search for ecoReinstallInstalled), but getting the command lines correct to support both install and repair or minor upgrade is not a trivial matter. I should probably clarify that due to the complexity it's not a scenario I would say we support - just that the raw capabilities are in there.

[Tim_Mayert]

Thanks MichaelU,

Adding that entry worked, and the Chained parent will re-trigger the chained installed project to be re-ran and therefore run in repair mode

But now have 2 questions:
1: As long as the correct properties are passed to the chained products this can then be used to run the install as repair or in Minor Upgrade mode correct?

2: I did notice one other thing while testing repair mode. If I try to perform a repair of any of the chained products I will get the search dialog box that is prompting for the chained product's .msi file. So does the main parent chained package NOT cache the chained product's .msi file? I would like to be able to run a repair from the parent chain as well as the chained products, but it does not allow for that. Is there some other setting that needs to be applied to cache the individual products msi or is this just how chains work, just does not seem correct....

[MichaelU]

I believe 1 should be as flexible as you need, assuming you can make the parameters it passes similarly flexible. For 2, do you specify a folder (such as something under [LocalAppDataFolder]), and choose not to delete the files? The chaining support can work with either, but if it deletes the files it would result in the uncached style behavior you see on repair.

[Tim_Mayert]

Thanks MichaelU,

I had *.* for the Streamed Files: - Run-time path and I have the "Detete streamed files after installation" check box unchecked.

So after reading a bit more it seems that this will cache the projects .msi files, but they would be in the temp folder and therefore they were being removed at the end of the install

So I set the Run-time path to a folder like the example, but now the install fails because it can not find the product .msi files????

So why does it fail to extract the files to the path indicated under the Run-time path if I supply a folder there? Does the Installation (run-time path) and the Streamed files: - Run-time path need to be the same?

Or is it because I am using {path}\*.*?

[Tim_Mayert]

Okay I sort of got this going. I had to use the following in both the Installation (run-time path) and the Streamed files:Run-time path:
[LocalAppDataFolder]Downloaded Installations\{Upgrade Code}\{Product .msi file}.msi

Then the product installs correctly cached and remained on the system to run repair mode.

BUT now have an issue with this. On a GPO push, pushing to machines that do not use users logged in this fails really bad....

In the lot it states that it extracts all .mst/msi files without errors:
InstallShield 13:53:14: Extracting file 'C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{6B46BC5D-B942-43B3-9EB1-7EAE65C7536A}\Product msi file.msi' for chained package Pkg1

but when it gets to the section where it is going to trigger that install product it complains that it can not find it:
MSI (s) (F4:78) [13:55:15:894]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{6B46BC5D-B942-43B3-9EB1-7EAE65C7536A}\Product msi file.msi 3: -2147287037

There is no other indication in the log that there was any failures in extracting the files or having the folder removed.

So can any one explain this to me or let me know if there is a better way or location where the chained product .msi/.mst files can be extracted so that they work correctly on all systems and under GPO?

Oh and just to let you know I did try [CommonAppDataFolder], but when you try to perform a repair on the parent chain, from Add/Remove, it would fail to extract the files because the folder is locked. This is because the initial install created that folder as elevated admin and therefore running from the Add/Remove does not elevate high enough to re-write to that folder and therefore it fails....

Chaining is starting to become very complicated and hard to work with......

[Tim_Mayert]

Okay getting a little farther on this, but now I want to cache the chained .msi projects under the [CommonAppDataFolder]Downloaded Installations\{prodkey}. So I set this and it all works, but then if you hit repair on main install it will produce a fatal error.

Checking the log it shows that it can not re-extract the files to the cache locations. So now there are a couple things I can try:
1. Create a custom action dll that will delete the folders before the repair tries to extract them again. I tested by deleting the folders and it seemed to work. But this custom action dll would have to be triggered in Immediate sequence and currently does not seem to work...

2. Have the install create those cached folders and set the permissions for everyone to have read/write access. I have tried this but it does not seem to set the permissions correctly or at all.... Be nice to get this working so if anyone know why permissions are not set on a subfolder of [CommonAppDataFolder]... could you let me know???

3. Detect if a Repair is being ran directly from the ARP control panel then simply condition the ISChainPackagePrepare to not be triggered. This will prevent the files from being extracted and therefore avoid the extraction error, but I need to know what is the best method to detect if you are running repair from the ARP and not from the command line. I have tested the command line and if you supply the repair mode properties on the command line it will correctly re-extract the .msi files and run the install repairs. So it is only if Repair is triggered from the ARP that it will fail. So if anyone know of a good method that detects if the install is ran from the ARP then could you let me know??

Thanks,