Chained MSI packages have been possible for a several years now ever since Windows Installer 4.5. Starting with InstallShield 2009 packagers have the option to create chained MSI packages but after researching them myself recently I have noticed there is not much to go on other than Flexera’s white paper. So here is my take…
As a packager, application management admin, or “jack of all trades” (as is usually the case in the application management world), chained MSI packages offer an elegant solution to a messy problem. While working with vender media the source that is usually provided to you from the publisher wraps the installation up nicely through an InstallShield executable exe file. This is great for a single user to manually install. But what do you do when you want to jump to that new operating system, or new deployment infrastructure? Well that’s when you begin to unravel the mysteries of how your source media was setup by your vendor so you can make an easy to use, standardized installation that you can deploy to all your users itching to get back to work. As you are discovering the pieces of the puzzle that the application manufacturer as created you discover that it contains not one…not two…but multiple MSI files. If you follow packaging best practices you know better than to create a nested MSI or capture. There are merge modules that you can sometimes use to combine your dependency applications to reduce the number of MSI packages you have to deal with. However as explained in the Flexera white paper these options have limitations. The major limitation being the ability to perform long-term maintenance on the individual products contained in the MSI packages after they are installed on the target system. This is where chained MSI packages become the perfect solution. With a chained MSI package you can have all your pieces of your pie together in one pie pan and yet still have access to each piece of pie individually as well. And that’s really the best way to think of how it works. The pie pan being the chained MSI itself and the pieces of pie being the individual MSI packages that came originally with from the application vendor, or custom MSI packages created to work alongside them.
Also in the white paper by Flexera is an attempt to explain the options you can choose while creating your chained MSI package. The white paper’s recommended option is to “stream” your individual MSI files into the chained MSI. Now understandably this is the cleanest and most compact solution when creating your chained MSI, however, it’s also the most limited. Even the white paper itself explains the limitations of creating a streamed chained MSI packaged. Just to name the most important limitations: package size limit is 2GB; streamed media is placed in temporary storage during install and removed by default after installation is complete. For me the last one is most important. By not having the source media available on the local system after install repairs or individual packages would have to be pointed to a location where the original source files can be found. So that is why this post is about Non-Streamed Chained MSI packages. By not streaming the files directly into the chained MSI you allow for much more flexibility and easier long-term maintenance of the application after local installation.
First make sure you have discovered all the files you plan to include in your chained MSI package. For this example I have renamed some MSI files generically so that it would serve the purpose of this instruction better.
Open InstallSheild and click on create new project.
Choose Basic MSI Project
Fill in the Project Name field with whatever you want to call your chained MSI
Choose what project save location and folder settings you wish, then click OK
Navigate to the Installation Designer tab
Choose Setup Design from under the Organization section
Create a single feature, and as many components as you have separate MSI files that you are going to chain together. If you wish to add additional files outside of the MSI installations you plan on chaining together that is ok too. Just remember that whatever you put in your setup design installs first before the MSI files you are chaining together installs. At this time you can also add the files to each component that you are plan on including.
Navigate to Files and Folders under the Application Data section.
Here is where you are going to plan out where to copy your source files to the local system before the MSI packages are installed. My personal preference is to either put them in a sub folder under the vendor of the main application you are installing or under a designated folder on the system where source files for all your applications will live. Make sure that all the source media files you plan to execute during the chained MSI process are located in the INSTALLDIR folder location of your package. Using the INSTALLDIR location is not necessary(other folder locations can be used), but it makes your work later much easier.
Now that our files are in place we can make the magic happen.
Navigate to Releases under the Media section
Right click on the folder that says Chained .msi Packages and click on New Chained Package(or you can just left click on the Chained .msi Pacakges and press Insert to create a new chained package as well.)
I like to rename each chained MSI package to match the name of the MSI I will be associating it with, but whatever naming you choose will be fine. Just remember that the order you place your MSI packages on this list will be the order in which they are installed.
At this step it is a good idea to have the information about your MSI ready. This information definitely should include the MSI name, product code and any public properties you want to set or names of transforms you want to use with your individual MSIs in the chain. You can also choose the MSI UI level at time of install here.
Notice that in the Installation (run-time path) field it says”[INSTALLDIR]PreReq1.msi” you WILL want to type NOT browse to this location into the text box. Since this location does not exist yet on the physical machine you will not be able to browse to it.
Once you have filled out the information for the chained MSIs then go ahead and build your release. (If there any other settings you would like to change before creating your final MSI release, please make them before this point. This could include the ARPSYSTEMCOMPONENT=1 in the property table to make sure that only the ARP entries for the individual MSI packages will be seen and not an extra entry for the chained MSI itself.)
(To clean up your install files even more you can change the setting in your release to not include a setup.exe launcher. Since this is the sort of thing that we are trying to avoid using, and using one with a chained MSI is not reliable anyway this is an easy way to cut unwanted files.)
Well now you know…one way at least, to create a chained MSI. Thanks for stopping by, and if you have any comments or suggestions please make sure to leave them here on the post or email them to us. Happy packaging!
6 thoughts on “Non-Streamed Chained MSI packages with InstallSheild”
Thank you so much for that very detailed article!
Working as a s/w packager I am definitely going to use this method when working with the multiple msi’s.
I have one question for you please: is it possible to apply the mst’s for each msi’s? If yes, would you please describe how it can be done?
Thank you very much,
It is possible to use MSTs with a chained MSI. Just include the MST with the MSI files when adding them to the chained MSI. On the chained MSI window under the releases section there is a dialog box entitled Install Properties. You can use this box to enter any MSI install command such as you would at a command line. Here just use the normal TRANSFROMS=%YourMSTName.mst% command line.
Hope that helps!
How about repairing the chained msi’s when the parent is repaired?
The chained MSI’s product codes are linked to the parent. If a repair is initiated on the parent then it will attempt to repair all the MSIs contained in it. Alternatively, the product codes of the chained MSIs are also registered with the system they are installed on. So repairs can be initiated on the individual MSIs as well.
>>The chained MSI’s product codes are linked to the parent. If a repair is initiated on the parent >>then it will attempt to repair all the MSIs contained in it.
In normal circumstances the chained MSI will not repair when the parent is being repaired by default. To get this behaviour to work you will need to set the ecoReinstallInstalled flag in the ISChainPackage table and once you have done this you will need to pass REINSTALL=ALL to the chained MSI if the chained MSI has already been installed, or else the repair will fail.
I have not tried repairing with your method does it work successfully? Ig so I suppose the disadvantage is that you could be repairing a chain that was not installed?