Real Men Don't Click

Unattended Pre-configured Software Setup


There's anumber of ways to perform an unattended setup with a pre-defined configuration (dutch version here). We will walk trhough a number of typical ones.

Microsoft's Semi-Imposed Standard : MSI's or Windows Installer Packages

Microsoft promotes "Windows Installer" as the one true way to install software on a Windows system, so it goes without saying that this is often the easiest way to go about it.

Silent Install

msi packages are executed by msiexec.exe and can be installed hands-free with msiexec switches, eg. /QB. There'se a number of levels as to how much interaction and feedback the user will get.

	
	C:\msiexec	

		msiexec /Option  [Optional Parameter]

		Install Options
			</package | /i> <Product.msi>	Installs or configures a product
			/a <Product.msi>				Administrative install - Installs a product on the network
			
			/j<u|m> <Product.msi> [/t <Transform List>] [/g <Language ID>]
								Advertises a product - m to all users, u to current user

			</uninstall | /x> <Product.msi | ProductCode>	Uninstalls the product

		Display Options
			/quiet			Quiet mode, no user interaction
			/passive		Unattended mode - progress bar only
			/q[n|b|r|f]
					Sets user interface level
						n - No UI
						b - Basic UI
						r - Reduced UI
						f - Full UI (default)
	
			/help			Help information

		Restart Options
			/norestart		Do not restart after the installation is complete
			/promptrestart		Prompts the user for restart if necessary
			/forcerestart		Always restart the computer after installation

	

Therefore, one could start a handsfree installation of msOffice with something like :

		msiexec -i "D:\data1.msi" /qb /norestart
	

Customization with Public Properties

When specifying a silent install, the setup will be executed with the defaults set by the developer. Sometimes we will want to change those, eg. to specify a destination other than "C:\Program Files\ ... ". MSI packages can have 'Public Properties' whose value can be changed by specifying a new value on the command line :


	msiexec -i "D:\data1.msi" /qb /norestart INSTALLDIR=F:\msOffice ALLUSERS=2

	

This will install - without any user intervention - to the given location, but only if the designer of the msi package has made INSTALLDIR public. He may have choosen not to, or he may have used an other name for the property, such as TARGETDIR. You'll have to read the documentation, or resort to some trial and error.

Customization with TRANSFORMS

Another way to modify Windows Installer Packages is by creating TRANSFORM packages (mst). To do this, you will need an msi editor. Some software vendors supply a product-specific msi editing tool with their software (for Microsoft Office : there's usually something in the Office Resource Kit Tools). Otherwise, try to find a generic msi-editor (use Google).

With an msi editor, you create an mst file by going through a fake setup (the tool will collect all your choices and preferences and write them to the mst), or by editing the mst directly, or a combination of those. Some also have the option to compare a system before installation to a system after installation, and collect all the changes, including files created, registry settings changed, etc. This is called 'repackaging'.

Anyway, after you got an mst file, you refer to it in combination with the original msi, and the setup will replicate all your preferences:


	msiexec -i "D:\data1.msi" /qb /norestart TRANSFORMS="F:\customsetup\myCustomizedOfficeSetup.mst"

	

Note that some 'setup.exe' are in fact msi installers, and the options and switches discussed here can be applied to them, eg. D:\setup /qb /norestart TRANSFORMS="F:\customsetup\myCustomizedOfficeSetup.mst" .

'Legacy' Installers with command line options

Before Microsoft started promoting msi as 'the' installer tool, software developers provided a setup routine with their programs. Of course, there was no standard as to what these installers (referred to as 'Legacy Installers' by microsoft) would or wouldn't accept as arguments. However, quite a lot have a switch for 'silent install' (often /Q, /quiet, /S, /silent, ...) and some accept other parameters to customize the setup before running it silently. In that case, they often use 'answer files' : text files that contain the answers to all the questions the setup program would ask during an interactive installation. In some cases (eg Lotus Notes), it is possible to 'record' a setup while it's being executed (for real - so do a model installation on a clean machine) - which results in an answer file that can be used to exactly duplicate the setup. This method is also supported by InstallShield (further).

"Repackaging", i.e. creating an msi or mst by comparing a system before installation to a system after installation, is also often used to be able to recreate a customized setup for this kind of application.

InstallShield and Wise

InstallShield and Wise are the 2 main companies that specialize in producing tools to create installer programs or setup routines, and often the (so-called legacy) installers created with these products also support arguments that can be helpful to create a cusyomized unattended setup.

Wise installers usually understand the /S swith for silent. InstallShield usually supports /r, /s, /sms, /f1, and /f2. /r will create a text file (%windir%\setup.iss) that you can add to your setup files. Unattended instals are then done by providing the /sms AND /s switch : /s for Silent, /sms to make a script wait for the installer to end before going to the next statement. (/f1 and /f2 can be used to refer to answer files on other locations than the setup folder, but these are hard to handle. See SourceForge : Unattended).

In other cases, Wise or InstallShield are just msi packages, or setup progams that support ( anumber of) msiexec arguments. Again, read the documentation and experiment.

Copy configuration files

A lot of applications still keep their configuration in one or more text files. If you've managed to do a (default) unattended setup, you can often just coppy the config files from a (model) installation in to the appropriate directories to set up the application. Of course, you will add the copy or xcopy commands to a setup script :-)

Import registry settings

Likewise, it is possible to import registry setttings to customize an application, e.g. to get rid of post-installation tasks such as accepting the EULA, entering licensing keys (if they could not be included in an MST, a network distyribution point or an msi Piblic Property, etc. This is also a great trick to set ODBC configuration after you've installed a database client or an odbc driver.

Simply export the desired registry keys to a text file (with extension .reg). You can add multiple keys together in 1 file. Silently merge them into the registry of the target computer with REGEDIT /S my_Oracle_ODBC.reg


Sample scripts for unattended installation with pre-defined customization

Here are some real life examples of unattended installation scripts. Often, they rely on files to be present at a given location, so a fullblown unattended deployement mechanism will require some planning re. the paths to and names of the files in question (network shares, mapped drive letters, server names, drive letters of removable media, and so on). A lot of that is discussed in the Automatic Software Deployment page.

Acrobat Reader 7.0
The installer, as downloaded from Adobe website, contains an .msi package that need to be unpacked.. This too can be scripted :-). On the other hand, the executable itself allows for (certain) switches to be passed through to the embedded msiexec routine. So there's more than 1 way to do this ...

There's a lot more of this kind of stuff at

Koen Noens
June 7th, 2005
Alle rechten voorbehouden