Examples :
Record the UNinstall and run the iss file:
setup.exe /r /f1c:\me\killit.iss
setup.exe /s /f1c:\me\killit.iss /f2c:\me\killit.log
Record the install and run the iss file:
setup.exe /r /f1c:\me\installit.iss
setup.exe /s /f1c:\me\installit.iss /f2c:\me\installit.log
psexec \\xp-test -i 1 %logonserver%\netlogon\me\killit.cmd
http://unattended.sourceforge.net/installers.php
MSI packages
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.
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 tomsiexec.
msiexec can do many other things, like uninstall software or apply patches. Neat, huh? Too bad nobody uses it.
InstallShield
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 copysetup.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 understart /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 nospace 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.