爱华网Introduction
The goal of this document is to collect instructions forperforming unattended / silent installations of many popularapplication installers. Such instructions are useful for automatingthese installations.
A quick word on terminology: Strictly speaking, anunattended installation is one which does notrequire user interaction, and a silent (orquiet) installation is one which does not displayany indication of its progress. However, most people use theseterms interchangeably.
Here, we are interested not only in performing unattendedinstallations, but also in waiting for those installations tofinish and suppressing any reboot they might want to perform. Thisis necessary for reliably installing multiple applications.
General information
There are several systems which vendors use to create installersfor their applications. To make an educated guess about how to runan installer unattended, you need to know which system was used tocreate it. Sometimes this will be obvious from the installer'ssplash screen; sometimes you can figure it out by running strings; and sometimes you will haveto guess.
Of course, you can try running the installer with the/? switch to find out which other switches itsupports. But if you really expect this to work, then you have notbeen using Windows for very long. In my experience, the odds areabout 1 in 4 that /? will tell you anything at all,even when there is something to tell.
MSI packages
Microsoft's own Windows Installer Service is thenominal standard, and if everybody used it, there would be no needfor this document. Unfortunately, Microsoft invented it toolate.
The package files have a .msi extension, and youmanipulate them using the msiexecutility.
For installation, use the /i and /qbswitches. Use the /l* switch to produce a log file.You can provide named options (or "properties") at the end of thecommand line; which properties are supported depends on thepackage. 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 MSIpackage to add Perl.exe to your PATH and to associate.pl files with it.
Perhaps the most important common property is the REBOOT property, which you canuse to suppress any automatic reboot the MSI package might try toperform. So in general, you want to provide the /i,/qb, and REBOOT=ReallySuppress parametersto msiexec.
msiexec can do many other things, like uninstallsoftware or apply patches. Neat, huh? Too bad nobody uses it.
InstallShield
InstallShield is one of the oldest and most widelyused application packaging systems.
Installers created by InstallShield recognize the/r, /s, /sms,/f1, and /f2 switches. The installeritself is invariably named setup.exe.
To perform a silent installation, you need an InstallShield"answer file", customarily named setup.iss. Someapplications ship with such a file, but if yours does not, you canuse 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 theinstallation. This will create a setup.iss file andplace it in the C:WINDOWS directory (yes, really).This file will include all of your responses to the InstallShielddialogs, allowing you to perform unattended installations as if youwere giving the same answers again. Simply copysetup.iss to the same directory as the installerexecutable.
Once you have a setup.iss file, run the installerwith the /s ("silent") option. This will perform anunattended installation.
Unfortunately, the installer will fork a separate process andexit, meaning it will return immediately even if you run it understart /wait. This makes it useless for scriptingpurposes. Luckily, there is another switch, /sms,which will cause the installer to pause until the installationcompletes.
Hence, for an InstallShield application, you want to provideboth the /s and the /sms switches.
The /f1filename switch allows you tospecify a fully-qualified alternate name for thesetup.iss file. Note that there must beno space between the /f1 switch andthe file name. This switch works both with /r tocreate the file and with /s to read it.
The /f2filename switch specifies a logfile. Once again, there must be no space betweenthe switch and the file name.
WARNING: Be careful what characters you use inthese file names, because InstallShield silently strips certainnon-alphanumerics (like hyphens).
Oh, one more thing. The /r and /sswitches only work if the release engineer is competent. Manypackages have "custom dialogs" which are not supported bysetup.iss, which means the dialogs will always appearno matter what you do. For such packages, I suggest asking thevendor to fix their installer. If that does not work, I suggestdoing what you can to deprive them of business.
PackagefortheWeb
InstallShieldhas a relatively new add-on product called PackagefortheWeb, or PFTW for short. This is basicallyan InstallShield tree bundled up as a single-file executable.
When you run this executable, it extracts a bunch of files to atemporary directory and launches the setup.exewithin.
The PFTW package recognizes the /s and /a... switches. The /s switch instructs the PFTWpackage to run silently, although this does not necessarily meanthat the underlying setup.exewill run silently.
The /a ... ("add") switch allows you to addswitches to the command line of the underlyingsetup.exe process. You may provide any of the normalInstallShield switches here, including /r,/s, and /sms.
Thus, to automate the installation of a PFTW package namedfoo.exe, you would first perform one installation byhand to create the answer file:
foo.exe /a /r /f1c:tempfoo.iss
Then, to install the package completely silently, you wouldrun:
start /wait foo.exe /s /a /s /sms /f1c:tempfoo.iss
The first /s is only needed for a completely silentinstallation. If you leave it off, the PFTW package will show you astatus bar as it extracts the InstallShield tree to the temporarydirectory.
InstallShield with MSI
Recent versions (7 and above) of InstallShield's tools are ableto produce MSIfiles. Read InstallShield's documentationfor full details.
These MSI files may be shipped alone or with asetup.exe installer. These installers in turn come intwo flavors, called "InstallScript MSI" and "Basic MSI".InstallScript MSI uses the traditionalInstallShield switches. Basic MSI is another story.
To perform an unattended installation using a Basic MSIinstaller, you provide the /s /v"..." switches, where... represents any additional switches you want topass down to msiexec. These should include the/qb (or /qn) switch to make theinstallation non-interactive, so a minimal invocation would be:
setup.exe /s /v"/qb"
Just to make things interesting, any of these mechanisms mightbe combined with PFTW.For example, we eventually figured out that the IBM Update Connector requires theseflags for unattended installation:
updcon532.exe /s /a /s /v"/qb"
The first /s tells the PFTW installer to extractsilently. The /a tells it to provide the remainingswitches to the underlying setup.exe. The second/s tells setup.exe to run silently, whilethe /v"/qb" tells it to pass /qb tomsiexec, which causes msiexec to runnon-interactively but display a basic interface.
Finally, InstallShield has a KnowledgeBase article which isless helpful than you might expect. Are we having fun yet?
Wise InstallMaster
InstallMaster from Wise Solutions is a competitor toInstallShield. You can usually identify the installers it producesby 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 ourexperience, they generally do. But there is no way to set options,and the exit status is meaningless.
Note: This product has been rebranded the "WiseInstallation System". Don't let them confuse you.
Inno Setup
Inno Setup is an open source competitor in thisspace. You can usually identify the installers it creates byrunning "strings" on the executable and grepping for "Inno".
The switches for Inno Setup are fully documented in theISetup.hlp file in the Inno distribution. Here, is an html version. Thanks to Lawrence Mayer forit.
In our experience, the /silent switch is usuallysufficient for a basic unattended installation. But to becompletely sure, we recommend /sp- /silent/norestart.
Note that the /verysilent switch may reboot themachine without prompting, which is pretty much the worst of allpossible worlds. So if you use /verysilent, be sure touse /norestart as well.
Nullsoft Scriptable Install System
The Nullsoft Scriptable Install System (NSIS) isanother open source installation system. It was created by theWinAmp authors to distribute that application, but itis now a general-purpose system which anyone might use.
When an NSIS installer runs, it creates a little window whichsays verifying installer: N%, where Ncounts from 0 to 100. So you can recognize these installers by thisbehavior. (Actually the verification procedure is optional, butmost installers have it enabled. As an alternative, you can run"strings" and grep for "NSIS").
NSIS installers recognize /S for silentinstallation, /NCRC to suppress the CRC (verification)step, and /D=dir to specify the "outputdirectory", which is where the program will be installed. Theseoptions are case-sensitive, so be sure to typethem in upper case.
Incidentally, all /S does is change the installerscript's SilentInstall attribute from"normal" to "silent". What effect this has, exactly, depends on theperson who wrote the script. If /S does not perform asilent install, consider submitting a bug report to the installer'screator.
Ghost installer
Ethalone's Ghost installer is just another commercialproduct, available in free and commercial editions. The freeedition is nothing but the compiler, which takes XML files; thecommercial edition is the compiler plus a graphical editor andwizard to create these XML files.
When a Ghost installer runs, it creates a little graphicalwindow which says "Ghost installer wizard. Setup is preparing theGhost Installer wizard..." together with a progress bar.
Ghost installers recognize -s (case-sensitive) forsilent installation, but that works only if the person who createdthe installer defined a standard installation type (if there aremore than one).
If you have trouble to get it silent you might try to guessinternal variables and pass new values at the command line using-var:MyVar=value. Unfortunately, using"strings" will not help you guessing. See here.
Other command line parametersare -r (repair), -c (add/remove), and-u (uninstall).
Microsoft hotfixes and older packages
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 towardsstandardized packaging and naming for hotfixes. But they are notdone yet.
Modern hotfixes support /passive (formerly/u) for unattended installation,/norestart (formerly /z) to suppress theautomatic reboot, and /n to skip backing up filesneeded 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. Theseinstallers first extract some stuff to a temporary folder and thenrun a command from inside that folder. They support the/t:path switch to specify the temporaryfolder name and the /c:command switch tospecify the command to run. Specifying just /csuppresses running the command at all, so you can use /c/t:path to extract the hotfix just to look atit.
These packages support the /q switch for quietoperation, except sometimes you have to use /q:ainstead. They also support the /r:n switch to suppressthe reboot. Sometimes these do not work and you have to fiddle withthe /c:command switch; see the second"NOTE" in KB article 317244 for anexample.
Leave it to Microsoft to make systems administration an experimental science.
If all else fails...
If the application simply has no unattended installationprocedure, you can create your own. I prefer to avoid theseapproaches if at all possible, since they are relatively unreliableand difficult to maintain.
Repackaging
There are several tools around which can take a snapshot of amachine's state before and after a manual installation, compute thedifferences between the states, and bundle them up as an"installer". The Wiseproduct line provides good support for this, and Microsoft's free tool provides bad support forit.
The problem with this approach is that it fundamentally cannotwork reliably. An installer's behavior may depend on the exactinitial state of the machine, such as the OS version or thepresence/absence of other installed software. So the repackagedinstaller will almost never do exactly the same thing that a freshinstallation would, unless the target machine is completelyidentical to the original machine.
In addition, for every new release of an application, you willneed to repackage it again. And there are other disadvantages which even Microsoft recognizes.
For these reasons, we think repackaging is a very bad idea andwe strongly advise against it.
AutoIt
AutoIt is a free tool which can simulate keypresses and mouse clicks, following a script customarily named witha .aut or a .au3 extension. Mostinstallers have a sufficiently simple and consistent interface thata very short AutoIt script suffices to automate theirinstallation.
The AutoIt distribution includes very good documentation. The Unattended distribution includesboth versions 2 (AutoIt.exe) and 3 (AutoIt3.exe). These versionsdiffer in their script formats. Currently, all scripts that areshipped with Unattended are written for version 2, but we plan to switch to version 3 inthe future and advise to create new scripts only in version 3.
AutoIt scripts do have drawbacks.
First, you must be careful when upgrading to new releases of anapplication, since the installer's UI may have changed.
More worryingly, AutoIt scripts are theoretically unreliablebecause they do not let you determine when a sub-process hasexited. You can tell when AutoIt itself exits, but that is not thesame thing at all. For example, an installer's last window mightdisappear while the installer was still working. Your masterscript, 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 anapplication which was invoked by Run. If it did, thisrace condition could be avoided.
In practice, it does not matter much, because most installers dofinish their work before destroying their last window. Just makesure your .aut script uses WinWaitClose towait for that last window to vanish.
You should make sure that your script contains a [ADLIB] sectionto catch surprising reboot requests.
http://unattended.sourceforge.net/installers.php
