The problem:
Sometimes, when creating a bundle, installing a product will kick off an executable, for example setup.exe. After a few seconds, setup.exe will kick off sub-installers which do the actual install. The setup.exe then terminates after a few seconds, having done its work, while the actual install has not been finished yet (since the subinstaller is still busy).
In the bundle, the Wait for action to finish will then goto the next step (because setup.exe has terminated). The following steps might however depend on a completed install. Subsequent steps in the install then will fail. Also, if the setup.exe is the LAST step, then LAUNCH actions will trigger, since it 'thinks' it's done all the installation steps, resulting usually in a 'file not found' error while trying to launch the software. This is logical, since the setup hasnt copied the executable yet.
The Solution:
It would be great if you could add subinstallers to a step. For instance, say setup.exe is the launcher for domything.exe and then dosomemorethings.msi, subsections could be added to the install step to wait for certain processes to finish (subinstallers are also processes). Another way of looking at it would be to add a NEW step after the setup.exe, where you could at least add a step like wait for service or process to start (already in ZCM), and call it: wait for service or process to terminate. Of course, in both situations, a solution must be found to prevent those steps thinking the subinstallers have fuinished because they havent even started yet. This could be fixed by adding checkboxes which could have a name like: wait for process to start before waiting to terminate.
Benefit:
A LOT of hassle can be prevented by making this solution. More and more, program setups use a launcher which self-terminates prematurely.
by: René L. | over a year ago | Application Mgmt
Comments
You might easily work around the issue by creating a run script action which would be waiting for the sub-installer to terminate successfully - either by monitoring the event log, the process list, an installation log file or checking for the presence of an "installation_finished.txt", depending on what your sub-installers are doing.
Installers are written by too many clueless people to be able to cater for all of them in a GUI, so you as a deployment admin are left with the task of finding a custom solution for each broken installer.