As far as I know, 7-zip is the only open source competitor to WinZip. It uses its own self-extracting installation scheme.

For unattended operation, run it with switches -y /q /r:n. Yes, that is "dash-y slash-q slash-r-colon-n", as described here and here.

This is a simple PFTW installer.

First, download the full installer package from Adobe. Run:

    AcroReader51_ENU_full.exe /a /r /f1c:\acrobat.iss

Complete the installation manually. When you are finished, the installer will write the c:\acrobat.iss answer file. Copy this file and the package itself to Z:\packages.

Then, to perform unattended installations, run:

    AcroReader51_ENU_full.exe /a /s /sms /f1Z:\packages\acrobat.iss

Just download the MSI file, which you already know how to handle.

Most of the available properties are documented, except for PERL_EXT, which tells the installer to make ActivePerl the default handler for .pl files.

Unlike Acrobat Reader, this new release does not use InstallShield's PackageForTheWeb. Instead, it uses something called the "Netopsystems FEAD optimizer", whose command-line switches are documented nowhere.

However, Adobe provides silent installation instructions in their knowledgebase articles 53446 and 53495. Viewing these requires registering for an account with the "Adobe Solutions Network"; how annoying. Briefly, the magic invocation is:

    AdbeRdr60_enu_full.exe -p"-s /v\"/qn\""

Alternatively, you can get hold of the MSI file with a quick hack. If you start the installer and wait for it to finish extracting files, you will find it creates a folder named %SystemRoot%\cache\Adobe Reader 6.0\ENUBIG. (SystemRoot is normally C:\WINNT or C:\WINDOWS.)

This folder contains the complete uncompressed tree, including an MSI file named Adobe Reader 6.0.msi. So just copy the ENUBIG folder to, say, Z:\packages\AdobeReader60, and you can perform unattended installations like any other MSI package:

    msiexec /qb /i "z:\packages\AdobeReader60\Adobe Reader 6.0.msi"

The downloaded installer is named ncsetup.exe; you probably want to rename it to att-5.0.8.2.exe or somesuch. Running "strings" on the executable reveals that it was created by Wise Installmaster, so the /s flag will do the trick.

Cygwin has its own installer (setup.exe) with no unattended mode. In fact, the package selection portion cannot be performed with the keyboard; only with the mouse.

However, Cygwin's setup.exe does allow you to download everything during one run and install it during another. So to automate the installation of a subset of packages, you simply

1. Run the installer once by hand to download just the packages you want.
2. Write an AutoIt script to run the installer in "install from local package directory" mode, clicking in the right spot to select "All Packages".

(UPDATE 1: Seth de l'Isle found a way to install Cygwin without using AutoIt. He sent these observations and his complete instructions to the mailing list.)

(UPDATE 2: There is some evidence that Cygwin eventually will have command-line switches to permit unattended installation.)

The downloaded installer is named DX81NTeng.exe. Run DX81NTeng.exe /c /t:path to extract the tree to path. From that tree, run dxsetup /silent /install.

Development on LeechFTP ceased a while ago, but many people still like it for its size, speed, simplicity, and robustness. The only problem is that the automatic "checking for software update" feature will always fail because the update server is gone. Users can disable this feature in the "options" menu; it only checks once a week, and it does not hurt anything anyway.

Leech can also just be installed on a test machine and the contents of the Program Files\LeechFTP directory moved from system to system. It creates registry entries for each user that runs it, but the defaults are very sensible.

The only trick is to make sure that all users can write to "LeechFTP\default.lfq" (default queue file). This file gets clobbered and recreated by each user. The simplest approach is probably to use a cacls line to give "users" the ability to "change" the entire directory.

(copy folder to C:\Program Files\LeechFTP)

cacls "C:\Program Files\LeechFTP" /t /e /g users:c

The master setup.exe is just an InstallShield executable. Use the /s /sms (and perhaps the /f1) switches.

The incremental installers, on the other hand, respond to /?. For unattended installation, provide the /nouser switch. Note that each incremental installer only works for the immediately preceeding version of Notes, so you must apply each of them in order.

Typical random Microsoft package. For unattended install, run with /q /c:"setup /qn1".

     IE6setup.exe /c:"ie6wzd.exe /d /s:""#E"

To perform an unattended installation, run IE6setup.exe from the \ie6sp1 directory with the /q and /r:n options.

Run dotnetfx.exe /q /c:"install /q" to perform a silent installation.

This is a fun one.

To perform unattended installations of Office, you need to create what Microsoft calls an "Administrative Installation Point". This is basically a copy of the CD-ROM, modified to incorporate your license key and organization name. From the top-level of the first Office CD-ROM, run:

    setup.exe /a data1.msi

Just answer all the questions about license keys and such, and the installer will create your Administrative Installation Point. The data1.msi file within will work like any other MSI package.

The Office installer has many public properties. They are documented in KB article 270920, although a better description can be found in the setupref.xls spreadsheet in the Office Information download from the Office Resource Kit toolbox. I happen to like the settings ADDLOCAL=ALL, REBOOT=ReallySuppress, NOUSERNAME=TRUE, ALLUSERS=1, and DISABLEADVTSHORTCUTS=1. Your mileage may vary.

Note: To create an Administrative Installation Point, you must have the Retail or Enterprise edition of Office 2000, not the OEM edition. And for Office XP, only the Enterprise edition will do. If you try to use the OEM edition, the setup.exe /a process will appear to work, but it will actually just scribble uselessly over the root directory of the current drive. (Hint: You can correct this behavior by using the Office Resource Kit to create a transform file which changes the OEMRelease property from 1 to 0. But you did not hear this from me.)

Of course, you will want to apply all of Microsoft's updates, because Office is riddled with security holes. There are two ways to do this.

One is to follow Microsoft's Administrative Updates Journal. Here you will find "administrative" versions of the updates which you may apply directly to your Administrative Installation Point, so that all installations performed from that point will have the updates incorporated already. Be aware that some updates (e.g., the View Control Security Update) have no administrative version; such updates must be applied on each client.

If you have applied any administrative updates to your installation point, your users will not be able to use the Product Updates section of Microsoft's web site to install updates themselves. Microsoft figures that if you apply any updates administratively, you want to apply all updates administratively. If your users (like mine) prefer to administer their own systems, they may find this annoying.

The other way to update Office is to apply the normal version of each update on each client. The only hard part here is figuring out how to install them in unattended mode, because each update is a little different. The example script below should provide a decent starting point, and might even be current.

This is another fun one.

You might try following the directions in KB article 195828. If you do, you will be disappointed, because smsinst.exe forks and exits immediately, rendering it useless for scripting. The KB article's instructions for using the acost.exe tool to configure which components to install is still accurate, however.

Luckily, by running "strings" on smsinst.exe, we can learn that all it does is run regedit /s key.dat and then fire up acmboot.exe. The key.dat file is just a simple registry patch to trick acmboot.exe into thinking that the GUI portion of Setup has already run. You must provide the /k switch to acmboot.exe to specify your license key (sans hyphens).

Having installed Visual Studio, you probably want to install the latest service pack (SP5 as of this writing). To perform an unattended installation of SP5, run setupsp5.exe /qn1. You may also provide the /g switch to specify a log file.

But oh, if only it were that simple. If you are installing on Windows 2000, you will find that the /qn1 switch does not actually work, because the installer insists on popping up a useless warning that your version of MDAC is out-of-date. The solution to this? Update MDAC to the latest version before trying to install the service pack.

So, the full unattended procedure for installing Visual C++ 6.0 is:

1. Run regedit /s key.dat
2. Run start /wait acmsetup.exe /k license-key
3. Reboot
4. Update MDAC to the latest version
5. Run start /wait setupsp5.exe /qn1

The good news is that the MSDN Library comes with an MSI package. The bad news is that when you try to install it with msiexec, a little dialog box appears telling you to run the provided setup.exe instead.

Naturally, this setup.exe responds to /? with "Incorrect command line parameters", so you have to guess what it wants. It turns out that it will take any arguments you give and pass them on to msiexec. So we can just run setup.exe /qb and be done with it, right? Wrong. Before running msiexec, setup.exe forks itself into the background, so start /wait returns immediately instead of waiting.

But we do not give up so easily.

If you run setup.exe with the /l*v logfile option, you can learn quite a bit about what it is doing. In particular, you can discover that setup.exe simply passes a SETUP_EXE=yes property to the underlying msiexec process.

In other words, all you have to do is run msiexec /qb /i msdn.msi SETUP_EXE=yes, and the installation proceeds without a hitch.

You may be wondering: If setting one useless property is all setup.exe does, why does Microsoft want you to use it? The answer is that the MSDN Library requires IE6, and setup.exe will install it for you if necessary. So, you should make sure you have IE6 installed before you attempt this procedure, because I have no idea what will happen otherwise.

Incidentally, this will perform a "Default" installation of MSDN Library, which means that most of the files will not be installed locally but rather loaded from the source directory as required. So choose the path to that msdn.msi package carefully, because that is the path MSDN will search whenever it needs something. (Hint: If you would rather perform a "Full" installation so that all files are copied to the local machine, add INSTALLATION_TYPE=Full to the command line.)

For unattended install, run with -ma and -ira options. This is not exactly well-documented; this old USENET post is all I can find.

I am not sure what -ira does, exactly, but without it the Mozilla installer fires up Mozilla just before exiting. This is annoying because the windows Mozilla creates can interfere with other things, like AutoIt scripts. With -ira, this does not happen, and I have noticed no bad side-effects, so there we are. (If anybody has definitive information here, I would love to hear it.)

Many thanks to Marcus Greil for pointing out the available options.

This product ships with an ordinary MSI package which can be installed in the usual way, but to preconfigure when/what/how to scan you have to do some more work. You need to download the "Installation Designer" to do this.

After installing the "Installation Designer", run it and give it the original .msi file to customize. The easiest approach is to install the VirusScan software on that very computer and configure it to your liking. When you get about halfway through the "Installation Designer", it will give you the option to export the settings from the local computer.

The original installer is a .msi file plus several other files and directories. When you finish creating your "custom" installer it will be a "self contained" .msi file that has no external dependencies.

OpenOffice.org uses a custom installer which it inherited from StarOffice. The installation can be automated using a "response file", which is more-or-less documented in the StarOffice 5.2 Administration Guide and the StarOffice 6.0 Administration Guide from Sun.

A minimal response file appears to consist of an [Environment] section with settings for InstallationMode and DestinationPath. I have no idea why the destination path is needed; you would think it would have some kind of default.

Unfortunately, this only does a proper installation for the current user, not for all users. The closest thing I have found is to manually create a shortcut on the "All Users" Desktop and in the Start Menu; this is what the example script does.

By default, OpenOffice installs a "QuickStarter" which runs every time you log in; it has a little icon which shows up in the system tray. I hate things like that, so the example openoffice.txt file shows you how to turn it off.

For a more complete discussion of these issues, see this thread on the OpenOffice.org forum. Note that OpenOffice 1.1 has some improvements over 1.0, so read the discussion to the end.

Uses Wise Installmaster, so responds to the /s switch. Unfortunately, the PHP folks seem to have done something wrong, because the installer still pops up a dialog box for the "IIS Scriptmap Node Selection". I have reported this as a bug and hope to see them fix it someday.

Meanwhile, an AutoIt script seems the best approach.

NEWS FLASH: I am now unable to reproduce this problem under Windows XP. Or maybe it has something to do with the IIS version. Either way, I need to investigate further. So many broken installers, so little time...

xcopy /i /c /e /y /h "Z:\packages\SecCRT" "C:\Program Files\SecureCRT 3.4.1"

copy "C:\Program Files\SecureCRT 3.4.1\SCRT.lnk" "C:\Documents and Settings\All Users\Start Menu\Programs\SecureCRT.lnk"

This is an InstallShield installer, but it has custom dialogs so the /s switch does not work. An AutoIt script is the only way to go.

  [jre].exe /s /v"/qb IEXPLORER=1 MOZILLA=1 NETSCAPE6=1 REBOOT=ReallySuppress"

Netopia provides an MSI package. Use it with standard arguments to perform a silent install.

It is possible to set which accounts can log in, passwords, security settings (everything in the "Setup" menu) ahead of time so you do not have to configure them manually for each install. Timbuktu uses a file named tb2.plu in the application directory to record all the settings from the "Setup" menu. So, to create an installer with your custom settings:

• Install Timbuktu on a machine.
• Manually change all the settings to your liking.
• "Exit and Shutdown Timbuktu Pro" so it will save the current configuration.
• Copy the file tb2.plu from the application directory (typically C:\Program Files\Timbuktu Pro) into the install directory structure you obtained from Netopia. There is a subfolder called Program Files\Timbuktu Pro; overwrite the version of tb2.plu which is there.

Run the installer with the /X switch (figured out by running "strings"). The installer will prompt for a directory to which it will extract the tree. Inside the tree will be an MSI file named 2000rkst.msi.