This document is part of Unattended, a Windows
deployment system.
The goal of this document is to collect instructions for performing unattended/silent installations of many popular Windows applications. Such instructions are useful for automating these installations.
A quick word on terminology: Strictly speaking, an unattended installation is one which does not require user interaction, and a silent (or quiet) installation is one which does not display any indication of its progress. However, most people use these terms interchangeably.
Here, we are interested not only in performing unattended installations, but also in waiting for those installations to finish and suppressing any reboot they might want to perform. This is necessary for reliably installing multiple applications.
There are several systems which vendors use to create installers for their applications. To make an educated guess about how to run an installer unattended, you need to know which system was used to create it. Sometimes this will be obvious from the installer's splash screen; sometimes you can figure it out by running strings; and sometimes you will have to guess.
Of course, you can try running the installer with the /? switch to find out which other switches it supports. But if you really expect this to work, then you have not been using Windows for very long. In my experience, the odds are about 1 in 4 that /? will tell you anything at all, even when there is something to tell.
Microsoft's own Windows Installer Service is the nominal standard, and if everybody used it, there would be no need for this document. Unfortunately, Microsoft invented it too late.
The package files have a .msi extension, and you manipulate them using the msiexec utility.
For installation, use the /i and /qb switches. Use the /l* switch to produce a log file. You can provide named options (or "properties") at the end of the command line; which properties are supported depends on the package. For example, this command:
msiexec /qb /l* perl-log.txt /i ActivePerl.msi PERL_PATH=Yes PERL_EXT=Yes
...is how you install ActiveState Perl, instructing the MSI package to
add Perl.exe to your PATH
and to associate
.pl
files with it. (See below
for more on Perl.)
Perhaps the most important common property is the REBOOT property, which you can use to suppress any automatic reboot the MSI package might try to perform. So in general, you want to provide the /i, /qb, and REBOOT=ReallySuppress parameters to msiexec.
msiexec can do many other things, like uninstall software or apply patches. Neat, huh? Too bad nobody uses it.
InstallShield is one of the oldest and most widely used application packaging systems.
Installers created by InstallShield recognize the /r,
/s, /sms, /f1, and /f2
switches. The installer itself is invariably named
setup.exe
.
To perform a silent installation, you need an InstallShield "answer
file", customarily named setup.iss
. Some applications
ship with such a file, but if yours does not, you can use the
graphical installer itself to create one.
Here is how it works. Run the installer with the /r
("record") switch. Proceed through the dialogs and complete the
installation. This will create a setup.iss
file and
place it in the C:\WINDOWS
directory (yes, really). This
file will include all of your responses to the InstallShield dialogs,
allowing you to perform unattended installations as if you were giving
the same answers again. Simply copy setup.iss
to the
same directory as the installer executable.
Once you have a setup.iss
file, run the installer with
the /s ("silent") option. This will perform an unattended
installation.
Unfortunately, the installer will fork a separate process and exit, meaning it will return immediately even if you run it under start /wait. This makes it useless for scripting purposes. Luckily, there is another switch, /sms, which will cause the installer to pause until the installation completes.
Hence, for an InstallShield application, you want to provide both the /s and the /sms switches.
The /f1filename switch allows you to specify
a fully-qualified alternate name for the setup.iss
file.
Note that there must be no space between the /f1
switch and the file name. This switch works both with /r
to create the file and with /s to read it.
The /f2filename switch specifies a log file. Once again, there must be no space between the switch and the file name.
WARNING: Be careful what characters you use in these file names, because InstallShield silently strips certain non-alphanumerics (like hyphens).
Oh, one more thing. The /r and /s switches
only work if the release engineer is competent. Many packages have
"custom dialogs" which are not supported by setup.iss
,
which means the dialogs will always appear no matter what you do. For
such packages, I suggest asking the vendor to fix their installer. If
that does not work, I suggest doing what you can to deprive them of
business.
InstallShield has a relatively new add-on product called PackagefortheWeb, or PFTW for short. This is basically an InstallShield tree bundled up as a single-file executable.
When you run this executable, it extracts a bunch of files to a
temporary directory and launches the setup.exe
within.
The PFTW package recognizes the /s and
/a ... switches. The /s switch instructs
the PFTW package to run silently, although this does not necessarily
mean that the underlying setup.exe
will run silently.
The /a ... ("add") switch allows you to add
switches to the command line of the underlying setup.exe
process. You may provide any of the normal InstallShield switches
here, including /r, /s, and /sms.
Thus, to automate the installation of a PFTW package named
foo.exe
, you would first perform one installation by hand
to create the answer file:
foo.exe /a /r /f1c:\temp\foo.iss
Then, to install the package completely silently, you would run:
start /wait foo.exe /s /a /s /sms /f1c:\temp\foo.iss
The first /s is only needed for a completely silent installation. If you leave it off, the PFTW package will show you a status bar as it extracts the InstallShield tree to the temporary directory.
Recent versions (7 and above) of InstallShield's tools are able to produce MSI files. Read InstallShield's documentation for full details.
These MSI files may be shipped alone or with a
setup.exe
installer. These installers in turn come in
two flavors, called "InstallScript MSI" and "Basic MSI".
InstallScript MSI uses the traditional
InstallShield switches. Basic MSI is another story.
To perform an unattended installation using a Basic MSI installer,
you provide the /s /v"..." switches, where
... represents any additional switches you want to pass
down to msiexec
. These should include the /qb
(or /qn) switch to make the installation non-interactive,
so a minimal invocation would be:
setup.exe /s /v"/qb"
Just to make things interesting, any of these mechanisms might be combined with PFTW. For example, I eventually figured out that the IBM Update Connector requires these flags for unattended installation:
updcon532.exe /s /a /s /v"/qb"
The first /s tells the PFTW installer to extract
silently. The /a tells it to provide the remaining
switches to the underlying setup.exe
. The second
/s tells setup.exe
to run silently, while the
/v"/qb" tells it to pass /qb to
msiexec
, which causes msiexec
to run
non-interactively but display a basic interface.
Finally, InstallShield has a KnowledgeBase article which is less helpful than you might expect. Are we having fun yet?
InstallMaster from Wise Solutions is a competitor to InstallShield. You can usually identify the installers it produces by running "strings" on the executable and grepping for "Wise".
InstallMaster installers are supposed to recognize the /s switch to perform a silent installation. And in my experience, they generally do. But there is no way to set options, and the exit status is meaningless.
NOTE: This product has been rebranded the "Wise Installation System". Don't let them confuse you.
Inno Setup is an open source competitor in this space. You can usually identify the installers it creates by running "strings" on the executable and grepping for "Inno".
The switches for Inno Setup are fully documented in the
ISetup.hlp
file in the Inno distribution. The GnuWin32
project has put a copy on the Web.
In my experience, the /silent switch is usually sufficient for a basic unattended installation. But to be completely sure, I recommend /sp- /silent /norestart.
Note that the /verysilent switch may reboot the machine without prompting, which is pretty much the worst of all possible worlds. So if you use /verysilent, be sure to use /norestart as well.
The Nullsoft Scriptable Install System (NSIS) is another open source installation system. It was created by the WinAmp authors to distribute that application, but it is now a general-purpose system which anyone might use.
When an NSIS installer runs, it creates a little window which says
verifying installer: N%
, where N
counts from 0 to 100. So you can recognize these installers by this
behavior. (Actually the verification procedure is optional, but most
installers have it enabled. As an alternative, you can run "strings"
and grep for "NSIS"...)
NSIS installers recognize /S for silent installation, /NCRC to suppress the CRC (verification) step, and /D=dir to specify the "output directory", which is where the program will be installed. These options are case-sensitive, so be sure to type them in upper case.
Incidentally, all /S does is change the installer script's SilentInstall attribute from "normal" to "silent". What effect this has, exactly, depends on the person who wrote the script. If /S does not perform a silent install, consider submitting a bug report to the installer's creator.
Most Microsoft hotfixes respond to the /? switch, but they do not always tell you everything.
According to KB article 816915 and KB article 824687, Microsoft is moving towards standardized packaging and naming for hotfixes. But they are not done yet.
Modern hotfixes support /passive (formerly /u) for unattended installation, /norestart (formerly /z) to suppress the automatic reboot, and /n to skip backing up files needed for uninstalling the hotfix.
Some hotfixes use an old Microsoft packaging technology called "IExpress", whose switches are more-or-less documented in KB article 197147 and an old USENET post. These installers first extract some stuff to a temporary folder and then run a command from inside that folder. They support the /t:path switch to specify the temporary folder name and the /c:command switch to specify the command to run. Specifying just /c suppresses running the command at all, so you can use /c /t:path to extract the hotfix just to look at it.
These packages support the /q switch for quiet operation, except sometimes you have to use /q:a instead. They also support the /r:n switch to suppress the reboot. Sometimes these do not work and you have to fiddle with the /c:command switch; see the second "NOTE" in KB article 317244 for an example.
Leave it to Microsoft to make systems administration an experimental science.
If the application simply has no unattended installation procedure, you can create your own. I prefer to avoid these approaches if at all possible, since they are relatively unreliable and difficult to maintain.
There are several tools around which can take a snapshot of a machine's state before and after a manual installation, compute the differences between the states, and bundle them up as an "installer". The Wise product line provides good support for this, and Microsoft's free tool (recently updated) provides bad support for it.
The problem with this approach is that it fundamentally cannot work reliably. An installer's behavior may depend on the exact initial state of the machine, such as the OS version or the presence/absence of other installed software. So the repackaged installer will almost never do exactly the same thing that a fresh installation would, unless the target machine is completely identical to the original machine.
In addition, for every new release of an application, you will need to repackage it again. And there are other disadvantages which even Microsoft recognizes.
For these reasons, I think repackaging is a very bad idea and I advise against it.
AutoIt is a free
tool which can simulate key presses and mouse clicks, following a
script customarily named with a .aut
extension. Most
installers have a sufficiently simple and consistent interface that a
very short AutoIt script suffices to automate their installation.
The AutoIt distribution includes very good documentation. You can
copy the AutoIt.exe
program wherever you like (say,
Z:\bin
) and invoke it standalone.
AutoIt scripts do have drawbacks.
First, you must be careful when upgrading to new releases of an application, since the installer's UI may have changed.
More worryingly, AutoIt scripts are theoretically unreliable because they do not let you determine when a sub-process has exited. You can tell when AutoIt itself exits, but that is not the same thing at all. For example, an installer's last window might disappear while the installer was still working. Your master script, waiting only for the AutoIt executable, would then proceed, starting another installation or rebooting the machine.
AutoIt provides Run
and RunWait
primitives, but it does not provide a way to
wait for the termination of an application which was invoked by
Run
. If it did, this race condition could be avoided.
In practice, it does not matter much, because most installers do
finish their work before destroying their last window. Just make sure
your .aut
script uses WinWaitClose
to wait for that last window to
vanish.
Availability | Open Source |
Details |
As far as I know, For unattended operation, run it with switches
|
Example | 7-zip.bat |
Availability | Free Download |
Details | 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 Then, to perform unattended installations, run: AcroReader51_ENU_full.exe /a /s /sms /f1Z:\packages\acrobat.iss |
Example | acrobat-reader.bat |
Availability | Open Source |
Details | 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. |
Example | perl.bat |
Availability | Free Download |
Details |
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
This folder contains the complete uncompressed tree, including an
MSI file named
msiexec /qb /i "z:\packages\AdobeReader60\Adobe Reader 6.0.msi" |
Example | adobe-reader.bat |
Thanks to | Nils Østbjerg |
Availability | Free Download (direct link to FTP site), but requires the service. |
Details | 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. |
Example | att.bat |
Availability | Open Source |
Details | Cygwin has its own installer ( However, Cygwin's
(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.) |
Example | cygwin.aut, cygwin.bat, sshd.bat |
Availability | Open Source |
Details | Binary distributions of Emacs for Windows are distributed as
Using 7-zip, extraction takes two steps: One
to extract the |
Example | emacs.bat |
Availability | Free |
Details | 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 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. |
Example | (copy folder to
|
Availability | The software is a commercial product; the incremental update installers are available for download. |
Details | The master The incremental installers, on the other hand, respond to
|
Example | notes.bat |
Availability | Free Download |
Details | Typical random Microsoft package. For
unattended install, run with
|
Availability | Free Download |
Details | After downloading IE6setup.exe issue the following command to download necessary files for installing.
IE6setup.exe /c:"ie6wzd.exe /d /s:""#E" To perform an unattended installation, run
|
Example | ie6.bat |
Availability | Free Download |
Details | Click the "IT Pros" link on the .NET Framework Redistributable page to download
dotnetfx.exe .
Run |
Availability | Commercial |
Details | 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
The Office installer has many public properties. They are
documented in KB
article 270920, although a better description can be found in the
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 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. |
Example | office2k.bat, officexp.bat |
Availability | Commercial |
Details | This is another fun one. You might try following the directions in KB article
195828. If you do, you will be disappointed, because
Luckily, by running "strings" on 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 But oh, if only it were that simple. If you are installing on
Windows 2000, you will find that the So, the full unattended procedure for installing Visual C++ 6.0 is:
|
Example | vs6.bat |
Availability | Subscription based, although you can browse it online. |
Details | NOTE: The following applies to the April 2002 and October 2002 editions of the MSDN Library. I make no promises about other editions, although I would be happy to hear about your experiences with them. 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 Naturally, this But we do not give up so easily. If you run In other words, all you have to do is run
You may be wondering: If setting one useless property is all
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 |
Example | msdn.bat |
Availability | Open Source |
Details | For unattended install, run with I am not sure what Many thanks to Marcus Greil for pointing out the available options. |
Example | mozilla.bat |
Availability | Commercial |
Details | 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. |
Availability | Open Source |
Details | (NOTE: This is not pretty. There is a project at http://installation.openoffice.org/ which is supposed to improve matters.) 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
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
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. |
Example | officeop.bat, openoffice.txt |
Availability | Free Download |
Details | Uses Wise Installmaster, so responds to the
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... |
Example | php.bat |
Availability | Commercial Product |
Details | Not free and version 4.0 has recently come out (2002-Nov-7), but a very good terminal program. Actually requires no "official" installation to work normally. Just copy the correct contents into a directory and create a shortcut for it. The first time it is run it asks for a location to store profile data; just accept the default. |
Example |
|
Availability | Commercial Product, but not for long |
Details | (Note: Shiva was bought by Intel a few years ago. Intel rebranded the product line "Intel Netstructure", decided to terminate it, and then sold it to some other company who has renamed themselves "Shiva Corporation". We still use the ancient version where I work...) 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. |
Example | shiva.bat, shiva.aut |
Availability | Free Download (Click on the J2SE version you want, then select the JRE download) |
Details | This is an Installshield with MSI installer. Sun displays pleasant originality by providing instructions for silent installation. I like to use: [jre].exe /s /v"/qb IEXPLORER=1 MOZILLA=1 NETSCAPE6=1 REBOOT=ReallySuppress JAVAUPDATE=0" As far as I can tell, it does no harm to request support for all of the browsers even if some of the browsers are not installed. Sun also provides intranet deployment instructions using an MSI file which you can obtain in a somewhat convoluted way. |
Example | sun-jre.bat |
Thanks to | Bret Tragni |
Availability | Open Source |
Details | This is an Inno installer, so just use the
|
Example | tightvnc.bat |
Availability | Commercial |
Details | 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
|
Example |
msiexec /i "Z:\packages\TimbuktuPro_5.1(900)\TimbuktuPro.msi"
/qn |
Availability | Free Download |
Details | Run the installer with the |
Example | support-tools.bat |