ScheduleReboot and chained packages

[SMadden]

Hello,

Does anyone know how to make chaining work when the parent installer needs a reboot? I haven't found anything for this case.

Here are the details:

I have an IS2010 Basic MSI project that chains another Basic msi package. In 99% of the cases this works fine, but on one dev system the device driver binary that gets installed with the parent MSI is locked and the ScheduleReboot action is triggered. When this happens, the chained install is skipped. No error will be thrown. From the MS documentation I can see that this is expected. But what am I supposed to do in this case? I guess in theory any install could run into a locked file at one stage although usually it doesn't. Doesn't that mean chaining is unusable if you want a bulletproof install?

Hmm, I'm puzzled here. What am I overlooking? Any ideas?

Sandra

[ccRubens]

Hi Sandra,

Did u manage to make a chained msi?, i´m trying to but failed many times, can u tell how u did´t?

Thanks.

[SMadden]

Hi,

what exactly doesn't work? I didnt' have any other problems than the one mentioned in the post when following the instructions given here:

http://helpnet.flexerasoftware.com/Robo/BIN/Robo.dll?tpc=/robo/projects/installshield16helplib/ChainerAdding.htm

My project is a BasicMSI in IS 2010 and only meant for Windows 7.

-Sandra

[SMadden]

just in case anyone is interested. I was able to make the chained package successfully install after the reboot with the help of two custom actions.

1) Immediate Execution set Property CA to save the value of IS_CHAINER_POST_COMMANDLINE

2) Deferred in System Context InstallScript CA that parses the CustomActionData and does the following with the value:

- copy the msi into temp folder
- bring the parameters into the right format for an msiexec call
- create a registry value with the msiexec call under RunOnce to make the install start after the next reboot

both CA's are conditioned so that they only run in when there is a chained package to be installed and a reboot detected.

For now this is not gone through QA yet, it's just in a proof of concept MSI and only ran on Windows 7 32Bit.


OPEN QUESTION
----------------

The one problem I still have with this is, why isn't the MSIEngine or InstallShield itself doing this for me? I can't imagine they just 'forgot' about this case. Is there anything in the system that I screw up when forcing the chained package to install after the reboot? In which scenario could this fail?

Any ideas are appreciated.

Thanks,
Sandra

[MichaelU]

Reading between the lines a little bit, I think the reason Windows Installer disallows this is that transactions do not survive reboots. Since chaining is intended to merge multiple package installations (or uninstallations) into a single transaction (its real name is Multiple Package Transaction), Windows Installer just gives up in this case. There are other possible reasons one can infer—perhaps they didn't get multiple package's post-reboot operations into their test matrix—but it's unclear.

I do think your workaround for this limitation sounds pretty good on the surface, and aside from the separate transactions part, I hope there's no big reason it would fail. It's unclear to me whether it's better to parse the IS_CHAINER_POST_COMMANDLINE property, or to process the ISChainPackage and ISChainPackageData tables yourself, so go with what works.

[dbdemigod]

I have the same issue as SMadden (except on XP - haven't tested other OSs yet), and really appreciate the insight (thanks Sandra!).

In my case, the initial install works correctly, but the major upgrade of the primary product does not update the chained MSIs. I have 2 chained MSIs, and I can see in the log that one chained MSI is skipped because it has not changed from the initial install (this is fine), and the second MSI seems to be queued for install ("Marking chained package DMSetup for installation"), but is not updated to the new version.

I've also observed strange behavior on uninstall - I am prompted to restart (although none of the files installed are in use?!?!), and if I say Yes to restart, the chained MSIs are not removed; if I do NOT accept the restart, the chained MSIs are processed and uninstalled correctly immediately afterwards!

I would love to see exactly how Sandra's CAs are sequenced, coded and conditioned, in hopes that it will work for me too. Any chance Sandra could share these details? Thanks.

- Matt -

[SMadden]

Hi Matt,

Upfront, I had to change the code a bit in the MSI that goes out to customers compared to the proof of concept one that I described in an earlier post. I don't want to go into details here why, I'll just describe what worked.

We needed 4 different custom actions, all scheduled in a row with different In-Script Executions. The first two save the value of IS_CHAINER_POST_COMMANDLINE as CustomActionData for the last 2 CAs. From IS_CHAINER_POST_COMMANDLINE you can find out where the chained packages are temporarily extracted to and how they are called.
The 3rd CA saves a copy of the chained installer in a temp folder because the original will have been cleaned up by the time you need it. It does this by parsing the CustomActionData for the installers name and location, gets the %TEMP% folder location and copies it.
The 4th CA makes sure that the chained package is not already installed on the system (MsiEnumRelatedProducts) and if not, extracts the calling parameters from the CustomActionData and creates a registry value under RunOnce to run the installer incl. parameters after the reboot.

1st and 2nd CA:
- MSI Type 51 (Set a Property)
- In-Script Execution: Immediate
- Scheduled in the Execute Sequence after Schedule Reboot and before InstallFinalize
- Property Name: PrecopyChainedPackages and LaunchChainedPackages
- Property Value: [IS_CHAINER_POST_COMMANDLINE]

3rd CA:
- Name: PrecopyChainedPackages
- MSI Type 68672 (InstallScript code)
- In-Script Execution: Deferred in System Context
- Scheduled in the Execute Sequence after 2nd CA

4th CA:
- Name: LaunchChainedPackages
- MSI Type 69184 (InstallScript code)
- In-Script Execution: Commit in System Context
- Scheduled in the Execute Sequence after 3rd CA

Hope this helps you a little. You might also want to look into processing the ISChainPackage and ISChainPackageData tables like Michael suggested instead of parsing IS_CHAINER_POST_COMMANDLINE. It might be easier, I don't know. I didn't try since I had the parsing stuff working already when he mentioned it.

-Sandra

[dbdemigod]

Hi Sandra,

Thanks so much for taking the time to reply so completely - YOU ROCK!!

- Matt -