Automating install of several applications

Question

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:

1. Install several applications that may use different installers.

2. 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)

3. 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.

4. 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:

1. 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)

2. Unattended/silent install assuming each installer supports it via an answer file or flags passed to the installer.

3. 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.

Answer 1

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.

Answer 2

When you're dealing with software for which you don't have the code for the setup, there really isn't a "right answer".

You may have license agreement considerations if you're doing this with third-party software. Server Fault isn't an attorney, but if this is for something that you're going to be distributing outside your organization I'd have it checked out by your counsel.

"Repackaging" means different things to different people. To my mind, it means building a new setup program for somebody else's application. Typically these are MSI packages, but it could just as easily be some other setup system. This can be done with automated tools, "by hand", or with some combination of those strategies.

Repackaging by using automated tools can create installs that work flawlessly, or that are hopelessly damaged. Using a repackaging tool blindly, without carefully examining the package that it creates can lead to a huge mess. Some tools (Wininstall LE, I'm looking at you) create really, really ugly MSI files by default (one file per component, everything a keypath).

Repackaging "by hand" via reverse-engineering the "intentions" of the original setup program's author can make for cleaner repackaged installs, but you have to really dig in and figure out if the original setup program has behavior that you're not seeing on your test machine. This ends up being an exercise in reverse engineering (and, possibly, frustration).

If you can get by w/ running unattended setups for the necessary applications I think you'll get the cleanest configuration. If you're worried about the Add/Remove Programs (ARP) list then I suppose you could have your installer "shell" modify the ARP registry entries after each 3rd party setup completes to remove its entries. (Personally, I'd leave the ARP entries alone...)

I'd be extra-careful, if this product is meant for COTS use, that you detect existing installations of the 3rd party programs you're installing and deal with it appropriately. I'm remembering cruddy old educational software I used to deal with that would blindly trash whatever version of QuickTime was installed and replace it with some ugly Win16 version, whether I liked it or not. Ugh...

If you're distributing this outside your organiation and other sysadmins (like, say, me) have the potential to need to deal with this thing please take our interests into consideration. We'd like to be able to silently install your product, and we'd like to be able to maintain the 3rd-party components that you install.

Answer 3

The only really viable option to accomplish all your goals is option #3.

The primary reason repackaging is typically unreliable is that when the apps are originally installed, they're all installed onto the same system, without uninstalling the other apps first. That means you end up with a sequence dependency to make sure you have all the right shared libraries installed.

If app A installed myLib.dll version 1.0.0.1, and app B uses the same version, the change detection system won't recognize that app B requires myLib.dll at all, unless it keeps a copy in the program folder. This is especially problematic for apps that use redistributable libraries from Microsoft, that may or may not be on the target machine to start with. Most apps that use custom libraries tend to keep them in the program folder.

To get option #3 to work even remotely reliably, here is what I would do:

1. Create a virtual machine to install the various apps on. Most VM software I'm familiar with will let you set up your virtual drives in such a way that you can decided whether or not to commit changes to the virtual drive image. After you have it up and running, turn on said feature.

2. Start the change detection software.

3. Install ONE application/update/whatever, making sure you install it to Program Files\BundledAppsWhatever

4. Remove the registry entry that would place said app in the add/remove control panel

5. Finalize the change detection process.

6. Move the repackaged app to your physical machine.

7. Reset the VM undo disk, so you have a clean system.

8. Repeat steps 2-7 as necessary.

Now, with all that said, I am not on top of current offerings for repackaging solutions, so I'm not aware of any that will give you the flexibility you want for adding and removing programs the way you described.

Answer 4

If your company is big enough (ie, their IT budget is "huge"), there are several products that work along these lines.

If you're looking for something for small-medium environments, you're going to be looking at finding the installation flags, and then scripting the push somehow.

Answer 5

maybe you should try Npackd (http://code.google.com/p/windows-package-manager/)