Blog

MSI Installation

No Comments
MSI Installation

Command Line Options

Option Parameters Meaning
/I Package|ProductCode Installs or configures a product.
/f [p|o|e|d|c|a|u|m|s|v] Package|ProductCode Repairs a product. This option ignores any property values entered on the command line. The default argument list for this option is ‘omus.’ This option shares the same argument list as the REINSTALLMODE property. p – Reinstalls only if file is missing. o – Reinstalls if file is missing or 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. Only repairs files that have msidbFileAttributesChecksum in the Attributes column of the File table. a – Forces all files to be reinstalled. u – Rewrites 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. Do not use the ‘v’ reinstall option for the first installation of an application or feature.
/a Package Administrative installation option. Installs a product on the network.
/x Package|ProductCode Uninstalls a product.
/j [u|m]Package or [u|m]Package/tTransform List or [u|m]Package/gLanguageID 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 machine. g – Language identifier. t – Applies transform to advertised package.
/L [i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] Logfile Writes logging information into a logfile at the specified existing path. The path to the logfile location must already exist. The installer does not create the directory structure for the logfile. Flags indicate which information to log. If no flags are specified, the default is ‘iwearmo.’ i – Status messages. w – Nonfatal warnings. e – All error messages. a – Start up of actions. r – Action-specific records. u – User requests. c – Initial UI parameters. m – Out-of-memory or fatal exit information. o – Out-of-disk-space messages. p – Terminal properties. v – Verbose output. x – Extra debugging information. Only available on Windows Server 2003. + – Append to existing file. ! – Flush each line to the log. “*” – Wildcard, log all information except for the v and x options. To include the v and x options, specify “/l*vx”.  
/m filename Generates an SMS status .mif file. Must be used with either the install (-i), remove (-x), administrative installation (-a), or reinstall (-f) options. The ISMIF32.DLL is installed as part of SMS and must be on the path. The fields of the status mif file are filled with the following information: Manufacturer – Author Product – Revision Number Version – Subject Locale – Template Serial Number – not set Installation – set by ISMIF32.DLL to “DateTime” InstallStatus – “Success” or “Failed” Description – Error messages in the following order: 1) Error messages generated by installer. 2) Resource from Msi.dll if installation could not commence or user exit. 3) System error message file. 4) Formatted message: “Installer error %i”, where %i is error returned from Msi.dll.
/p PatchPackage[;patchPackage2…] Applies a patch. To apply a patch to an installed administrative image one must combine the following options: /p <PatchPackage>[;patchPackage2…] /a <Package>
/q n|b|r|f Sets user interface level. q , qn – No UI qb – Basic UI. Use qb! to hide the Cancel button. qr – Reduced UI with no modal dialog box displayed at the end of the installation. qf – Full UI and any authored FatalError, UserExit, or Exit modal dialog boxes at the end. qn+ – No UI except for a modal dialog box displayed at the end. qb+ – Basic UI with a modal dialog box displayed at the end. The modal box is not displayed if the user cancels the installation. Use qb+! or qb!+ to hide the Cancel button. qb- – Basic UI with no modal dialog boxes. Please note that /qb+- is not a supported UI level. Use qb-! Or qb! – To hide the Cancel button. Note that the! Option is available with Windows Installer 2.0 and works only with basic UI. It is not valid with full UI.
/? or /h   Displays copyright information for Windows Installer.
/y module Calls the system function DllRegisterServer to self-register modules passed in on the command line. Specify the full path to the DLL. For example, for MY_FILE.DLL in the current folder one can use: msiexec /y .\MY_FILE.DLL This option is only used for registry information that cannot be added using the registry tables of the .msi file.
/z module Calls the system function DllUnRegisterServer to unregister modules passed in on the command line. Specify the full path to the DLL. For example, for MY_FILE.DLL in the current folder one can use: msiexec /z .\MY_FILE.DLL This option is only used for registry information that cannot be removed using the registry tables of the .msi file.
/c   Advertises a new instance of the product. Must be used in conjunction with /t. Available starting with the Windows Installer version that is shipped with Windows Server 2003 and Windows XP SP1.
/n ProductCode Specifies a particular instance of the product. Used to identify an instance installed using the multiple instance support through a product code changing transforms. Available starting with the Windows Installer version shipped with Windows Server 2003 and Windows XP SP1.

Types of Command Line Options

Option Parameters Meaning
/help   Help and quick reference option. Displays the correct usage of the setup command including a list of all switches and behavior. The description of usage can be displayed in the user interface. Incorrect use of any option invokes this help option. Example: msiexec /help Note: The equivalent Windows Installer Command-Line Option is /?.
/quiet   Quiet display option. The installer runs an installation without displaying a user interface. No prompts, messages, or dialog boxes are displayed to the user. The user cannot cancel the installation. Use the /norestart or /forcerestart standard command-line options to control reboots. If no reboot options are specified, the installer restarts the computer whenever necessary without displaying any prompt or warning to the user. Examples: msiexec /package Application.msi /quiet Msiexec /uninstall Application.msi /quiet Msiexec /update msipatch.msp /quiet Msiexec /uninstall msipatch.msp /package Application.msi / quiet Note: The equivalent Windows Installer Command-Line Option is /qn.
/passive   Passive display option. The installer displays a progress bar to the user that indicates that an installation is in progress but no prompts or error messages are displayed to the user. The user cannot cancel the installation. Use the /norestart, /forcerestart, or /promptrestart standard command-line options to control reboots. If no reboot option is specified, the installer restarts the computer whenever necessary without displaying any prompt or warning to the user. Example: msiexec /package Application.msi /passive Note: The equivalent Windows Installer Command-Line Option is /qb! with REBOOTPROMPT=S set on the command line.
/norestart   Never restart option. The installer never restarts the computer after the installation. Example: msiexec /package Application.msi /norestart Note: The equivalent Windows Installer command line has REBOOT=ReallySuppress set on the command line.
/forcerestart   Always restart option. The installer always restarts the computer after every installation. Example: msiexec /package Application.msi /forcerestart Note: The equivalent Windows Installer command line has REBOOT=Force set on the command line.
/promptrestart   Prompt before restarting option. Displays a message that a restart is required to complete the installation and asks the user whether to restart the system now. This option cannot be used together with the /quiet option. Note: The equivalent Windows Installer command line has REBOOTPROMPT = “” set on the command line.
/uninstall <Package.msi|ProductCode> Uninstall product option. Uninstalls a product. Note: The equivalent Windows Installer Command-Line Option is /x.
/uninstall /package <Package.msi | ProductCode> /uninstall <Update1.msp | PatchGUID1>[;Update2.msp | PatchGUID2] Uninstall update option. Uninstalls an update patch. Note: The equivalent Windows Installer Command-Line Option is /I with MSIPATCHREMOVE=Update1.msp | PatchGUID1[;Update2.msp | PatchGUID2] set on the command line.
/log <logfile> Log option. Writes logging information into a log file at the specified existing path. The path to the log file location must already exist. The installer does not create the directory structure for the logfile. The following information is entered into the log: Status messages Nonfatal warnings All error messages Start up of actions Action-specific records User requests Initial UI parameters Out-of-memory or fatal exit information Out-of-disk-space messages Terminal properties Note: The equivalent Windows Installer Command-Line Option is /L*.  
/package <Package.msi|ProductCode> Install product option. Installs or configures a product. Note: The equivalent Windows Installer Command-Line Option is /I.
/update <Update1.msp>[;Update2.msp] Install patches option. Installs one or multiple patches. Note: The equivalent Windows Installer command line has PATCH = [msipatch.msp] <;PatchGuid2> set on the command line.

Types of msi installation

The types of MSI installation are dependent upon the Property:

Property Value Description (Type of Installation)
ALLUSERS 0 Per User
ALLUSERS 1 Per Machine
ALLUSERS 2 Determined by User Access

Per-machine Installations

The per-machine installation of an application means that the application is available for all users of a computer. It also means that:

  • Shortcuts are installed to the All Users profile.
  • COM registration is always written to HKLM\Software\Classes.
  • On Windows 2000 and Windows NT, at elevated privileges.
  • Icons and transforms are stored in %WINDOWS%\Installer\{ProductCode}.

Beginning with Windows Vista, applications should use the SHGetFolderPathEx function and the Knownfolder_ID to determine the full path to the special folders. The names of the Windows Installer System Folder Properties remain unchanged. The extended functions of the Knownfolder API subsume all the functionality of the original versions. Existing applications that use the SHGetFolderPath function and the CSIDL will continue to work.

Per-user Installations

The per-user installation of an application means that the application is available only for a particular user. It also means that:

  • Shortcuts are installed only to that users’ profile.
  • Applications appear only under Add/Remove Programs on Control Panel for users that have installed the applications.
  • On Windows 2000, COM registration is written to HKCU\Software\Classes.
  • Applications may or may not run at elevated privileges.
  • Icons and transforms are stored in %USERPROFILE%\Application Data\Microsoft\Installer\{ProductCode GUID}

This Table illustrates the Properties which are set by the Windows Installer depending upon the type of Installation:

Property Ref known folder id (Per-Machine) CSIDL (Per-Machine) Ref known folder id (Per-User) CSIDL (Per-User)
Desktopfolder The full path of the Desktop folder for All Users. Publicdesktop Introduced in Windows Vista. CSIDL_COMMON_DESKTOPDIRECTORY Existed on Windows 2000 and Windows NT. Desktop CSIDL_DESKTOPDIRECTORY
Programmenufolder The full path of the Program Menu folder for All Users. Commonprograms Introduced in Windows Vista. CSIDL_COMMON_PROGRAMS Existed on Windows 2000 and Windows NT. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Startmenufolder The full path of the Start Menu folder for All Users. Commonstartmenu Introduced in Windows Vista. CSIDL_COMMON_STARTMENU Existed on Windows 2000 and Windows NT. Programs CSIDL_PROGRAMS
Startupfolder The full path of the Start Up folder for All Users. Commonstartup Introduced in Windows Vista. CSIDL_COMMON_STARTUP Existed on Windows 2000 and Windows NT. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Templatefolder The full path of the Templates folder for All Users. Commontemplates Introduced in Windows Vista. CSIDL_COMMON_TEMPLATES Existed on Windows 2000. Startmenu CSIDL_STARTMENU
Admintoolsfolder The full path of the Administrative Tools folder for All Users. Commonadmintools Introduced in Windows Vista. CSIDL_COMMON_ADMINTOOLS Existed on Windows 2000. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Appdatafolder Starting in Windows Vista, the full path of the Roaming folder for the current user; otherwise, the full path to the Application Data folder for the current user. Roamingappdata Introduced in Windows Vista. CSIDL_APPDATA Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Startup CSIDL_STARTUP
Commonappdatafolder The full path of the folder that contains the application data for All Users. Programdata Introduced in Windows Vista. CSIDL_COMMON_APPDATA Existed on Windows 2000. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Favoritesfolder The full path of the Favorites folder for the current user. Favorites Introduced in Windows Vista. CSIDL_FAVORITES Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Templates CSIDL_TEMPLATES
Personalfolder Starting in Windows Vista, the full path of the Documents folder for the current user; otherwise, the full path of the My Documents folder or Personal folder for the current user. Documents Introduced in Windows Vista. CSIDL_PERSONAL Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Sendtofolder The full path of the sendto folder for the current user. Sendto Introduced in Windows Vista. CSIDL_SENDTO Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Admintools CSIDL_ADMINTOOLS
Fontsfolder The full path of the System Fonts folder. Fonts Introduced in Windows Vista. CSIDL_FONTS Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Introduced in Windows Vista. Existed on Windows 2000.
Programfilesfolder The full path of the Program Files folder for the current user. Programfiles Introduced in Windows Vista. CSIDL_PROGRAM_FILES Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Roamingappdata CSIDL_APPDATA
Programfilesfolder The full path of the Program Files folder for the current user. Programfilesx86 Full path to the xxx folder for All Users. Introduced in Windows Vista. CSIDL_PROGRAM_FILESX86 Existed on Windows NT and Windows 2000. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Commonfilesfolder The full path of the Common Files folder for the current user. Programfilescommon Introduced in Windows Vista. CSIDL_PROGRAM_FILES_COMMON Existed on Windows 2000 and Windows NT. Programdata CSIDL_COMMON_APPDATA
Commonfilesfolder The full path of the Common Files folder for the current user. Programfilescommonx86 Introduced in Windows Vista. CSIDL_PROGRAM_FILES_COMMONX86 Existed on Windows NT and Windows 2000. Introduced in Windows Vista. Existed on Windows 2000.
Windowsfolder The full path of the Windows folder for the current user. Windows Introduced in Windows Vista. CSIDL_WINDOWS Existed on Windows 2000, Windows NT, Windows 98, andwindows 95. Favorites CSIDL_FAVORITES
Systemfolder The full path of the System folder for the current user. Systemx86 Introduced in Windows Vista. CSIDL_SYSTEMX86 Existed on Windows NT and Windows 2000. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.
Localappdatafolder The full path of the folder that contains local (nonroaming) applications. Localappdata Introduced in Windows Vista. CSIDL_LOCAL_APPDATA Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Documents CSIDL_PERSONAL
Mypicturesfolder Starting in Windows Vista, the full path of the Pictures folder for the current user; otherwise, the full path of the My Pictures folder for the current user. Pictures Introduced in Windows Vista. CSIDL_MYPICTURES Existed on Windows 2000, Windows NT, Windows 98, and Windows 95. Introduced in Windows Vista. Existed on Windows 2000, Windows NT, Windows 98, and Windows 95.

Concurrent Installations

What is Concurrent Installation?

Concurrent Installations, also called Nested Installations, is a deprecated feature of the Windows Installer. It is typically used to install some pre-requisite component(s) for the main application.

How concurrent installation works?

A concurrent installation action installs another Windows Installer package during a currently running installation. A concurrent installation is added to a package by authoring a concurrent installation action into the CustomAction table and scheduling this custom action into the sequence tables. The Target field of the CustomAction table contains a string of public property settings used by the concurrent installation. The Source field of the CustomAction table identifies the concurrent package. A concurrent installation action can only reinstall or remove an application that has been installed by the current application’s installation package.

Why not to use concurrent installation?

Nested installs are deprecated and highly discouraged. Below are some of the limitations and problems associated with nested installs:

  • Concurrent installations cannot share components.
  • An administrative installation cannot also contain a concurrent installation.
  • Patching and upgrading may not work with concurrent installations. The installer may not properly cost a concurrent installation.
  • Integrated ProgressBars cannot be used with concurrent installations.
  • Resources that are to be advertised cannot be installed by the concurrent installation.
  • Nested installations live under the context of the parent product and do not appear in the Add or Remove Programs Control Panel applet. Therefore uninstall of the parent product is the only way to uninstall a nested install.
  • A package that performs a concurrent installation of an application should also uninstall the concurrent application when the parent product is uninstalled.

The recommendation would be to use the bootstrap executable wrapper to install the MSI packages one after another. Each individual MSI would therefore be serviceable and can be treated independently.

Types of Custom Actions supporting Concurrent Installation

The type of concurrent installation action is specified in the Type field of the CustomAction table. Depending upon the custom action type, the package for the concurrent application can reside in sub storage of the main package, as a file at a location specified by a property, or as an advertised application on the user’s machine. The following types of custom actions perform a concurrent installation.

Custom action type Description
Custom Action Type 7 Concurrent installation of a product residing in the installation package.
Custom Action Type 23 Concurrent installation of an installer package within the current source tree.
Custom Action Type 39 Concurrent installation of an advertised installer package.

Where to place a Concurrent Installation

A concurrent installation shares the same user interface and logging settings as the main installation. Concurrent installation actions should be placed between the InstallInitialize action and InstallFinalize action of the main installation’s action sequence. Upon rollback of the main installation, the installer would then rollback the concurrent installation as well. The use of deferred execution with concurrent installation actions is unnecessary because the installer combines rollback information from the concurrent and main installations. All changes are reversed upon a rollback installation. The return values for concurrent installation actions are the same as for other custom actions. Standard or custom actions that specify an automatic restart of the system, or request the user to restart, can also perform restart or request from within a concurrent installation.

Specifying the type of installation at command line

To specify the type of installation, pass either the ADDLOCAL, ADDSOURCE, REINSTALL, or REMOVE property to the concurrent installation action. Concurrent installation actions can be authored in pairs, one action used for installing and the other action used for removing the concurrent installation. A Custom Action Type 7 or Custom Action Type 23 is typically used to install. A Custom Action Type 39 is typically used to remove the concurrent installation when the parent product is uninstalled. The record for the removal custom action in the CustomAction table can have the product code GUID in the Source field and “REMOVE=ALL” in the Target field. The two custom actions need to be authored in the action sequence table with mutually exclusive conditions. For example, the custom action that installs the product can have “NOT Installed” in its Condition field and the custom action removes the concurrent installation can have REMOVE=”ALL” in its Condition field.

Note: A parent installation cannot call its own package as a concurrent installation action. Also if a per-machine installation attempts to run a per-user concurrent installation, the installer registers the parent installation as per-user by default. This can cause the installer to incorrectly remove the application because the installer attempts to uninstall the application per-machine when it is actually registered as per-user. To force the state of a concurrent installation to track the state of its parent installation, enter ALLUSERS=”[ALLUSERS]” in the Target column of the CustomAction table. In this case, the concurrent installation is per-machine if the parent is per-machine, and the concurrent installation is per-user if the parent is per-user.

Developers should note the following warnings when authoring concurrent installations. Concurrent installations cannot share components. An administrative installation cannot also contain a concurrent installation. Patching and upgrading may not work with concurrent installations. The installer may not properly cost a concurrent installation. Integrated Progress Bars cannot be used with concurrent installations. Resources that are to be advertised cannot be installed by the concurrent installation. A package that performs a concurrent installation of an application should also uninstall the concurrent application when the parent product is uninstalled.

Preventing a Package from Concurrent Installation

To prevent a package from ever being installed as a concurrent installation, add either of the following conditional statements to the LaunchCondition table. This prevents the package from ever being installed by a concurrent installation action run by another installation. This does not prevent the package from being removed by the RemoveExistingProducts action. See also the ParentOriginalDatabase property and ParentProductCode property.

When to use concurrent installation?

Applications installed with concurrent installations can eventually fail because they are difficult for customers to service correctly. Do not use concurrent installations to install products that are intended to be released to the public. Concurrent installations can have limited applicability in controlled corporate environments when used to install applications that are not intended for public release. The concurrent installations documentation is provided for package authors that wish to use concurrent installations with applications that are not for public distribution. Concurrent installations are not available with Windows Installer version 1.0.

Modes of Installation

The Windows Installer Service is designed to supply all of the installation needs of the applications that use it. This includes four distinct modes of installation:

  1. Regular installation
  2. Administrative installation
  3. Rollback installation
  4. Maintenance installation

In this section, these four different modes are briefly described

Regular Installation

What is a Regular Installation?

Performing a regular installation is the most common use of the Windows Installer. This is an installation that takes information and files from the source media and transfers them to the user’s computer to produce a working copy of the software.

How does a Regular Installation happen?

The Installer processes a regular installation (and other installations) in two phases:

1. During the acquisition phase, the Installer reads from the Installer package, and interacts with                the user, to determine what actions need to be carried out. These actions are written to an Installer script.

2. During the execution phase, the part of the Installer with elevated privileges executes the script that was created during the acquisition phase.

Installer packages contain a database that tells the Installer exactly what to do. The sequence of events in a regular installation is controlled by entries in the InstallUISequence and InstallExecuteSequence tables. That might include displaying a dialog or copying selected files to the user’s hard drive. The actions contained in these two tables can be native Installer actions or custom actions. Custom actions can be supplied by creating a DLL with a specific entry point. This allows you to extend the Installer to perform any action you can conceive of, not just those that were allowed for by the team that designed the Installer.

Administrative Installation

What is an Administrative Installation?

An administrative installation does not install an executable application on a user’s hard drive. Rather, it installs the entire Installer package and all other files from the original source media to a network drive. It installs a source image of the application onto the network that is similar to a source image on a CD-ROM. Users in a work group who have access to this administrative image can install the product from this source. The location that the administrative install transfers files to is known as an installation point. Later, users can run the setup program from the installation point to actually install the application to their own hard drive.

Why is an Administrative Installation required?

The following is a list of the main uses for an administrative installation.

  • Pre-setting properties with the AdminProperties property—with normal installations, double-clicking an MSI file results in the full installation interface and no special command-line properties are applied. This can result in leaving out the TRANSFORMS property, which might cause important customizations to be omitted. Administrative installations allow the administrator to specify a list of properties (not MSIEXEC switches) to be used when the MSI is double-clicked. This is useful if you have distribution scenarios in which users are either directed to run MSIs from the network or they can easily find them on the network.
  • Served applications—Windows Installer natively supports running applications executables from a server rather than from the local hard drive. This is known as Run from source in Windows Installer. To do this, an administrative installation must be created. A unique aspect about Windows Installer served applications is that they can be fault tolerant. If multiple administrative installations are made available and specified as sources for the applications files, Windows Installer will check the list of sources until it finds one that is available.
  • Pre-activation of Microsoft products—Microsoft Products that require activation can only be pre-activated if they are setup as an administrative install. There are other ways to ensure that activation does not require user intervention.
  • Reduce back-end replication—in large networks, the amount of data passed over the network to distribution servers can cause network load problems. Because administrative installs can be patched, using administrative installs can reduce back-end (server to server) replication. Patches have the potential to dramatically reduce the amount of data transfer required because they only contain binary deltas of files that change between two versions of a package. The benefits of reduced bandwidth for maintenance must be balanced with the uncompressed format of administrative installs—which use up to twice as much disk space as an MSI that has the application files compressed within internal or external CAB files.
  • Extract only needed files from a software CD-ROM—many software vendors send out a single, large CD-ROM that has all or most of their software packages—especially if their software is under site or blanket licenses. Some CD-ROMs may contain files required to deploy applications in multiple spoken languages. Such a CD-ROM might contain more than 400MB when all that is needed is a 10MB application. Performing an administrative installation with the desired MSI file will extract only the needed files to the network. This approach only works if the individual applications on the CD-ROM have their own MSI files rather than one large MSI file.

How does an Administrative Installation happen?

Like a regular installation, an administrative installation is table-driven. However, in this case, the tables containing the installation logic are named AdminUISequence and AdminExecuteSequence. A second set of tables is used because this installation has a completely different appearance from a regular installation. During an administrative installation, the Installer changes certain properties in the database based on information contained in the original database. In this fashion, software installed from an installation point can be made to have different defaults than the same software installed from the original source media. The user can choose to run-from-source when he installs and the installer uses most of the product’s file directly from the network. Administrators can run an administrative installation from the command line by using the /a command line option. The ADMIN action is the top-level action used to initiate an administrative installation. When this action is executed the installer calls the actions in the AdminExecuteSequence and AdminUISequence tables to perform the administrative installation. The AdminProperties property is a semicolon delimited list of properties that are set at the time of an administration installation. The installer uses these properties during a post administration installation of the application from the administrative image. During an administrative installation, the installer creates a source image for all features in the product except those features with 0 in the Level column of the Feature table.

Rollback Installation

What is Rollback Installation?

A rollback installation is triggered by the Windows Installer itself rather than the user. When the Windows Installer processes the installation script for the installation of a product or application, it simultaneously generates a complete log of all actions performed as well as copies of any files that it deletes. This is also referred to as a rollback script. These files are kept in a hidden system directory and are automatically deleted once the installation is successfully completed. If however the installation is unsuccessful, the installer automatically performs uses the log to perform a rollback installation that returns the system to its original state. Automatic rollback of an unsuccessful installation is the default behavior of the installer.

How to disable Rollback during an Installation?

To disable rollback during an installation use one of the following:

  • DISABLEROLLBACK Property
  • PROMPTROLLBACKCOST Property
  • DisableRollback Action

However, setting the DISABLEROLLBACK Property to TRUE is a dangerous practice because it can lead to a partially functioning piece of software being left on a computer if anything goes wrong. Unless you expect an application to be installed with extremely limited extra disk space, you should leave rollback enabled. Whenever rollback is disabled, the installer sets the RollbackDisabled property.

What is a Rollback script?

Windows Installer accomplishes rollback by creating a rollback script. A rollback script is a file that contains a linear sequence of operations to perform, such as file and registry updates, configuration information updates, user interface notifications, and state information for other operations. Each operation recorded in the rollback script is a direct response to an operation in the installation script. Rollback scripts are stored in binary formats. Rollback script files (.RBS and .RBF) are backups of existing files. Files with an .RBS extension are rollback script files, and files with an .RBF file extension are backups of existing files. Both are stored in hidden folders called Config.msi. The Config.msi folders are created when the Msiexec.exe file starts copying from the installation point. The rollback script file (.RBS) is always stored in the Config.msi folder on the disk where the operating system is installed. The .RBF files are stored in the Config.msi folder on the disk where the program that is being backed up currently resides. This is done so that there is no crossing of disks when the program files are being backed up. All rollback files and the Config.msi folders are deleted when the installation completes successfully.

Maintenance Installation

What is a Maintenance Installation?

In addition to regular and administrative installations, the Windows Installer is capable of three distinct modes of software maintenance. First, it’s possible for the user to choose to install additional software features after the software has been installed or to remove features that they no longer need. Second, it’s possible to use the Windows Installer to repair an application that’s experiencing problems. Finally, a user might choose to remove the application entirely from their computer. Generally, you’ll want to make all of these capabilities available from the Add/ Remove Programs applet in the Windows Control Panel. For example, when the user chooses Add/Remove Programs in Microsoft Office 2000, the dialog box in Figure 1 appears. This dialog box allows the user choose which of these maintenance modes to enter.

Figure 1: Choosing a Maintenance Mode

How does a Maintenance Installation happen?

No matter which mode the user chooses, the Installer creates a change script and then uses the elevated privilege portion of the Installer software to execute the change script. Like an installation script, a change script is a list of commands from the Installer to itself, not a file that’s available to users. The Windows Installer actually supports quite a number of options for repairing applications. Transforms that have been applied to an installation must be available during subsequent maintenance installations.

 

Leave a Reply