I'm trying to discover a reliable way of bundling several applications that may use different installer software (InstallShield, MS installer Service, Wise, etc) and automating installation of them all in some fashion. I haven't seen any product out there that reliably does this. Here's what I would like it to do:
-
Install several applications that may use different installers.
-
Install applciations without requiring manual interaction for each app. I'd prefer an option in the main installer to have a custom option where you can select the apps you want and just click "Install" and have it install those applications (but without popping up the install for those apps)
-
Have the main installer only show up in the Add/Remove programs menu within Windows, so that when that one application is removed, all applications that were installed are also removed.
-
Control install parameters for each bundled application so that they can be installed in a logical related directory structure. For example, installing all the apps in a Program Files\Bundled App Set folder.
From what I've researched, there's really only a few ways to do this:
-
External install, which would simply launch the installer for each application and require manual interaction for each installer (but that breaks almost all goals above, but would at least install all apps chosen after interaction)
-
Unattended/silent install assuming each installer supports it via an answer file or flags passed to the installer.
-
Repackaging installs using software that can track changes to a system during an install and record those changes which are then repackaged into a new installer. I've read this isn't very reliable and tends to break often. It can have problem detecting things like services added to Windows.
There's also a 4th option using merge modules, but that would only work if every application uses the same MS installer service. I didn't list it because of that.
This is really a question for opinions on the best way to go about this. Some software I have access to and can repackage, and other software I do not. I would prefer to not go with a hybrid system, like using #1 and #2, but if I have to, I have to.
I would imagine there's some way of doing this right, and I'm open to any opinions or suggestions to get something like this working–and hopefully not be incredibly fragile in the end. Maybe it isn't possible? Any help is appreciated. Thanks.
Best Answer
I have used a technique along the lines of pjhayward's solution for years. Our company uses hundreds of different programs, some from large commercial providers and others from one-person side businesses. The technical proficiencies of these vendors are all over the map, particularly when it comes to designing installers.
I consider vendor-delivered MSIs the gold standard (though there is still plenty of variation in the package designs). Using Microsoft's free Orca tool (embedded in one or more of their platform SDKs, I believe), it's fairly easy to create Transform files to coerce these packages into our typical layout. We customize the Start Menu to group programs by functional category, we change the install directory to group applications by vendor inside the Program Files folder, and we banish desktop shortcuts altogether. Serial numbers and license server addresses are applied, if appropriate, perhaps an automatic update service is disabled, etc.
The biggest benefit of using MSIs is that Microsoft's Group Policy (which works through Active Directory and is included in all Windows Server licenses) can deploy these packages, with their Transforms, to designated groups of machines automatically or by user request. We use the automatic method, assigning general-purpose apps to all machines, CAD apps to those who might use them, Adobe apps to specific machines (stupid per-seat licensing), etc. Details of doing this effectively would be a separate SF question, if it's not already asked and answered.
For the many, many installers that aren't in MSI format, we go through a repackaging process similar to pjhayward's. The most significant drawback to doing this is that the repackaged installation loses any intelligence built in to the original installer. Sensitivity to platform differences (say 32- or 64-bit systems) will be clobbered, possibly requiring additional repackagings to cover each platform. Decisions about installing and/or updating third-party components will be made based on the sample machine, regardless of different initial states of the target machines. Etc.
Speaking of third-party components: We make every effort to install each component through a separate package, regardless of the vendors' frequent desires to bundle everything together. Their strategy makes sense for a single person installing a handful of software products manually on his/her own machine, but breaks down in the case of many-node, many-product automated installations. No matter how many vendors rely on MSXML 6 or some obscure license management tool, we install each of them once, typically before installing the products they were distributed with. This also helps us minimize inadvertent version downgrades, since we can easily tell if the bundled version is older or newer than the one we're already deploying.
We use Attachmate's WINinstall, which was distributed in a lite form with the Windows Server 2003 CDs. We have a license of the full product, but the LE version, in combination with Orca and the occasional embedded vbscript supplement, has been sufficient for my needs. Evan Anderson's comments about WINinstall are valid, but we've been able to live with its warts.
pjhayward's list (currently) glosses over a critical step: Cleaning up the captured installation package before using it to perform installations elsewhere. Undesirable files and registry entries are often picked up as part of the capture process, and it's important to identify and remove them before they do damage on subsequent installs. Look for things like sequential state registry keys that might be completely wrong for a machine that's been running for a while, and Indexing Service or Windows Update cache files that are created mid-capture.
Please note that licensing is outside the scope of my answer, but is quite relevant to this type of scenario. Bulk distribution techniques have to be balanced with awareness of actual usage rights granted by each product's license agreements.
I hope this helps. It's perhaps more than you're asking, and it's not a perfect match to the deployment approach your question describes, but it's a solution we've found workable for many years now.