Reference: Setup.exe commands

Setup.exe Command Line Parameters

Special Installation Modes
* /a : Administrative installation
* /j : Advertise mode
* /x : Uninstall mode
* /uninst : Uninstall product (InstallScript MSI projects only)

Silent Installations
* /p : Specify password
* /r : Record mode (InstallScript MSI projects only)
* /s : Silent mode
* /f1 : Specify alternative response file name (InstallScript MSI projects only)
* /f2 : Specify alternative log file name (InstallScript MSI projects only)

SMS Data
* /m : Generate MIF file (InstallScript MSI projects only)
* /m1 : Specify serial number in MIF file (InstallScript MSI projects only)
* /m2 : Specify locale string in MIF file (InstallScript MSI projects only)

Download and Cache Locations
* /ua : Specify URL for InstMsiA.exe
* /uw : Specify URL for InstMsiW.exe
* /us : Specify URL to ISScript.msi
* /um : Specify URL to .msi package
* /b : Cache installation locally

Passing Data to the Installation
* /v : Pass arguments to Msiexec
* /z : Pass arguments to CMDLINE variable

Debugging
* /d : Debug InstallScript (InstallScript MSI projects only)
* /verbose : Generate verbose InstallScript engine log file (InstallScript MSI projects only)

Miscellaneous
* /f : Specify alternative compiled script (InstallScript MSI projects only)
* /h : Clone release to a temporary location and run from that location
* /L : Setup language
* /w : Wait
* /SMS : Wait (InstallScript MSI projects only)

Special Installation Modes
*/a : Administrative installation
*/j : Advertise mode
*/x : Uninstall mode
*/uninst : Uninstall product (InstallScript MSI projects only)

Silent Installations
*/p : Specify password
*/r : Record mode (InstallScript MSI projects only)

In order to run an InstallScript MSI project installation program in silent mode, one must first run Setup.exe with the /r switch to generate a response file, which stores information about the data entered and options selected by the user at run time. Running an InstallScript MSI installation program with the command Setup.exe /r displays all the run-time dialog boxes, and stores the data in a file called Setup.iss, created inside the system's Windows folder. To specify an alternative response file name and location, use the /f1 argument, described below. Basic MSI projects do not create or use a response file for silent installations.

*/s : Silent mode - For an InstallScript MSI project, the command Setup.exe /s runs the installation in silent mode, by default based on the responses contained in a response file called Setup.iss in the same directory (response files are created by running Setup.exe with the /r option). To specify an alternative file name or location of the response file, use the /f1 option, described below.

The command Setup.exe /s also suppresses the Setup.exe initialization window for a Basic MSI installation program, but does not read a response file. To run a Basic MSI product silently, run the command line Setup.exe /s /v/qn. (To specify the values of public properties for a silent Basic MSI installation, you can use a command such as Setup.exe /s /v"/qn INSTALLDIR=D:\Destination".)

*/f1 : Specify alternative response file name (InstallScript MSI projects only) - Using the /f1 argument allows one to specify where the response file is (or where it should be created) and what its name is, as in Setup.exe /s /f1"C:\Temp\Setup.iss". The /f1 switch is available both when creating a response file (with the /r option) and when using a response file (with the /s option).

*/f2 : Specify alternative log file name (InstallScript MSI projects only) - When running an InstallScript MSI project installation program in silent mode (using the /s argument), the log file Setup.log is by default created in the same directory as the response file. The /f2 argument allows one to specify an alternative log file location and file name, as in Setup.exe /s /f2"C:\Setup.log".

SMS Data
*/m : Generate MIF file (InstallScript MSI projects only) - The /m switch causes Setup.exe to generate an SMS Management Information Format (MIF) file. A typical command is Setup.exe */m"SampleApp". (Including the “.mif” file extension is not necessary.)
/m1 : Specify serial number in MIF file (InstallScript MSI projects only) - Using the /m1 parameter (along with /m) enables you to specify a serial number to be written to the MIF file. A typical command is Setup.exe /m"SampleApp" /m1"1234-5678".
*/m2 : Specify locale string in MIF file (InstallScript MSI projects only) - Using the /m2 parameter (along with /m) enables you to specify a locale string to be written to the MIF file. A typical command is Setup.exe /m"SampleApp" /m2"ENU".
*/b : Cache installation locally - In the Release Wizard, for a Downloader build, you can specify whether to cache the contents of a compressed package on the local system. With the /b argument, the user can specify the directory in which to cache the installation files, as in Setup.exe /b"C:\CacheDirectory".

Passing Data to the Installation
*/v : pass arguments to Msiexec - The /v argument is used to pass command line switches and values of public properties through to Msiexec.exe.
*/z : Pass arguments to CMDLINE variable - The /z argument is used to pass data to the InstallScript system variable CMDLINE, as in Setup.exe /z"My Custom Data", after which the variable CMDLINE would contain the string "My Custom Data".
*/verbose : Generate verbose InstallScript engine log file (InstallScript MSI projects only)
For an InstallScript MSI project installation program, you can create a verbose InstallScript-engine-installation log file using the /verbose argument followed by the path to the log file you want to create. A typical command is Setup.exe /verbose"C:\IS.log". The log file generated can help you troubleshoot errors in installing the InstallScript engine on a target system. The /verbose option requires a full path to the log file, and not a relative path.

Reference: Windows Installer command line

The following is a list of the command lines that can be used with an .msi installation per Microsoft

Msiexec - Provides the means to install, modify, and perform operations on Windows Installer from the command line.

To install or configure a product
Syntax
msiexec /i {package|ProductCode}
Parameters
/i : Installs or configures a product.
Examples
To install a product from A:\Example.msi, type:
msiexec /i A:\Example.msi

To use the administrative installation option
Syntax
msiexec /a package
Parameters
/a : Applies the administrative installation option.

To repair a product
Syntax
msiexec /f [p][o][e][d][c][a][u][m][s][v]{package|ProductCode}
Parameters
/f : Enables one or more of the command-line options listed in the following table.

p Reinstalls only if file is missing.
o Reinstalls if file is missing or if an older version is installed.
e Reinstalls if file is missing or an equal or older version is installed.
d Reinstalls if file is missing or a different version is installed.
c Reinstalls if file is missing or the stored checksum does not match the calculated value.
a Forces all files to be reinstalled.
u Rewrite all required user-specific registry entries.
m Rewrites all required computer-specific registry entries.
s Overwrites all existing shortcuts.
v Runs from source and re-caches the local package.

Examples
To repair the installation package, type:
msiexec /fpecms Example.msi

To uninstall a product
Syntax
msiexec /x {package|ProductCode}
Parameters
/x : uninstalls a product.
Examples
To remove or uninstall a package, type:
msiexec /x Example.msi

To advertise a product
Syntax
msiexec /j [{u|m}] package
msiexec {u|m} package /t TransformList
msiexec {u|m} package /g LanguageID
Parameters
/j : Advertises a product.
u : Advertises to the current user.
m : Advertises to all users of the computer.
/g LanguageID : Identifies the language.
/t TransformList : Applies transform to advertised package.
Examples
To advertise a package to all users of this computer, type:
msiexec /jm Example.msi
To advertise a package to all users of this computer, type:
msiexec /jm Example.msi

To set logging level
Syntax
msiexec /L [i][w][e][a][r][u][c][m][p][v][+][!]LogFile.txt
Parameters
/L : Specifies the path to the log file.

i : Logs status messages.
w : Logs nonfatal warnings.
e : Logs all error messages.
a : Logs startup of actions.
r : Logs action-specific records.
u : Logs user requests.
c : Logs initial user interface Parameters.
m : Logs out-of-memory.
p : Logs terminal properties.
v : Logs verbose output. To use v, specify /L*v.
+ : Appends to existing file.
! : Flushes each line to the log.
* : Logs all information except for the v option. This is a wildcard.
LogFile.txt : Name and path of the text log file.
• To include the v option in a log file using the wildcard flag, type /L*v at the command prompt.
• The Windows Installer log file options can also be used with the uninstall and repair processes.

Examples
To install a package and create a log file that contains the information related to the status, out-of-memory, and error messages, type:
msiexec /i Example.msi /Lime logfile.txt

To apply a patch
Syntax
msiexec /p PatchPackage
Parameters
/p : Applies a patch.
PatchPackage : Specific patch.
• To apply a patch to an administrative installation package, use the following Syntax:
msiexec /p PatchPackage /a Example.msi

To install a transform using the command line
Syntax
msiexec /i packageTRANSFORMS=TransformList
Parameters
/i : Installs or configures a product.
package : Specifies the Windows Installer package file.
TRANSFORMS= : Property that is used to specify what transform (.mst) files should be applied to the package.
TransformList : List of paths separated by semicolons.

To advertise a product using a transform with the command line
Syntax
msiexec /j[u][m] package /t TransformList
Parameters
/j : Advertises a product. This option ignores any property values entered on the command line.
u : Advertises to the current user.
m : Advertises to all users of this computer.
/t : Applies transform to advertised package.
TransformList : List of paths separated by semicolons.

To set the user interface level
Syntax
msiexec /q{n|b|r|f|n+|b+|b-}
Parameters
/qn : Displays no user interface.
/qb : Displays a basic user interface.
/qr : Displays a reduced user interface with a modal dialog box displayed at the end of the installation.
/qf : Displays the full user interface with a modal dialog box displayed at the end.
/qn+ : Displays no user interface, except for a modal dialog box displayed at the end.
/qb+ : Displays a basic user interface with a modal dialog box displayed at the end.
/qb- : Displays a basic user interface with no modal dialog boxes.
• /qb+- is not a supported user interface level. The modal box is not displayed if the user cancels the installation.

Examples
To display the basic user interface options during the package installation of Example.msi, type:
msiexec /qb Example.msi

To call the system API DllRegisterServer to self-register modules passed on the command line
Syntax
msiexec /y module
Parameters
/y : Calls the system API DllRegisterServer to self-register modules passed on the command line.
module : Specifies the file name of module.
• This option is used only for registry information that cannot be added using the registry tables of the .msi file.
Examples
The following example shows how you can use the msiexec /y command:
msiexec /y my_file.dll

To call the system API DllUnRegisterServer to unregister modules passed on the command line
Syntax
msiexec /z module
Parameters
/z : Calls the system API DllUnRegisterServer to unregister modules passed on the command line.
module : File name of module.
• This option is used only for registry information that cannot be added using the registry tables of the .msi file.
Examples
The following example shows how you can use the msiexec /z command:
msiexec /z my_file.dll

Useful Query - All machines that do NOT have specific file

Handy query that will show all machines that are missing a certain .exe file. Replace 'file.exe' with the filename of your choice:

select 
    SMS_R_System.NetbiosName,
    SMS_G_System_SoftwareFile.FileName
from
    SMS_R_System
inner join SMS_G_System_SoftwareFile
on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_SoftwareFile.FileName = "file.exe"

MSI package deployment overview: How-To and How-Not-To

Windows Installer. A prime example of a great idea that, when properly implemented makes life much easier. Yet more often than not this great idea is implemented in a less than perfect manner, and rage mixed with sorrow follow shortly thereafter.

I frequently get questions on how to deploy MSI-based applications into production, as well as how to patch those apps that are already deployed. Microsoft created an very nice vehicle to address this question that drives like this:

How it should work:

Theoretically when an application comes in an MSI, deployment to the masses would happen as follows:
1. Create an administrative install with the 'msiexec /a package.msi' command
2. Use a packaging tool to create a transform to tailor the install to your specific needs
3. Deploy it to the world using the 'msiexec /i package.msi transforms=transform.mst' along with the silent install command of your choice.

In the event that a patch is released, it will come in an .msp package. To patch your environment, you'd proceed like this:
1. Patch your administrative install with the 'msiexec /p patch.msp /a admininstallpackage.msi'
2. Reinstall your client installations by send the the 'msiexec /vasu' command to them (can use other parameters, 'v' is key however.)

Down the road at some point you'll likely need to either upgrade or remove that package, which is accomplished as such:
1. Add the GUID of of the currently deployed package to the upgrade field of your new package.
2. Deploy the new package and it will detect and remove the old
-or-
1. Send the 'msiexec /x' command with the silent flag of your choice to machines that have the package installed

So essentially you're performing all client installs from the same point, so in the event that a patch is released, you simply update that point and recache the install on your clients.

Easy, right? Ideally yes, but read on as I burst your happy little windows installer bubble, and laugh manically as the shrapnel from the balloon snaps you in the eye.

How it actually works in most cases:

Ask anyone that packages applications regularly and they'll usually give you mixed reviews of MSI packages. When properly created they are easy to deploy, easy to maintain, and easy to remove. However the reality is that software vendors other than Microsoft themselves rarely create MSI's properly, and it ends up being more of a headache than a help.

As with so many things today the need to 'make it simple' has generated some tools to aid software vendors in the task of getting their software into installable packages for their customers. The tools themselves, such as InstallShield and Wise are actually quite good, but they do unfortunately make it easy to create a semi-functional windows installer package.

So what does this mean exactly?



*Insert dramatic pause*




It means that very few vendor-provided MSI's work the way that MSI's should. *Insert collective sigh from the audience followed by confused mumblings* It means that very few MSI's were actually meant to be translated into an administrative install point, and it means that very few software companies that ship their product in a MSI installation ever send out updates in MSP format.

What do I do with those MSI's that do not function properly?

The right way to handle these varies. If you have a strong Windows Installer background you could attempt to fix their MSI so that it acts as an MSI should. Alternatively, you could just thoroughly test their install and work within their specification to deploy it. This is the most common solution. Those installs generally work, just be prepared to test thoroughly in your environement.

As a last resort you could utilize a tool such as Wise or InstallShield to recapture the application. I'll go into these tools and this method in great detail later, but as an overview the software essentially watches and records the installation, and uses that information to create it's own new install. There are some deffinate risks involved in this, as I will outline later, and generally this is an if-all-else-fails tactic. Choose wisely.


And there you have it, deploying windows installer applications and patches in a nutshell. One of the (perhaps masochistic) draws for me to application packaging is that there is a lot of real world problem solving here. Take the bull by the horns, test it, analyze it, and figure out which route you should take.