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.
Best Answer
You can "preseed" answers so that debconf sees you've answered the question already, and doesn't bother asking it again.
You need some tools from the
debconf-utilspackage:Install your program and manually answer the questions once. Then, you can ask debconf what it stored in its database:
That information can be input into
debconf-set-selections(either by piping, or reading from a file).Warner's answer is more cross-platform (debconf is a Debian-and-derivates only technology), but doesn't always work between versions, if the questions change; or in the case you have some debconf questions that are only asked if you have other packages installed.