How windows installer engine installs the installation package?

http://blogs.technet.com/b/alexshev/archive/2008/02/21/how-windows-installer-engine-installs-the-installation-package.aspx

 

Introduction

This is a very high-level introduction on what is going on when we initiate an installation.

Client and Server processes

The main components of Windows Installer engine are msiexec.exe and msi.dll located in the %SystemRoot%\System32 folder.  If you want to know the version of MSI installed on your machine, check the version number of either of those two files.

On Windows 9x Windows Installer Engine is implemented as client process, whereas on Windows NT 4.0 and up it has two parts - client process and Windows service.  Because Windows 9x are old systems and barely in use anymore, I will focus on the server implementation of Windows Installer Engine.

Remember:  On Windows 9x operating systems there is no server process.  The whole installation is done in the client process.

Remember:  When we launch Windows Installer engine (by running msiexec.exe) we are launching the client process.  Client process will launch the Windows service process.

Client process is running under credentials of the user who started up the installation process.  Server process is running under the LocalSystem account which is generally a lot more powerful than user's account.

Three types of installation

Windows Installer engine supports three types of installation:

• Normal installation (/i switch)
• Administrative installation (/a switch)
• Advertisement (/j switch)

Advertisement switch (/j) stands for just-in-time and has two optional modifiers.  You can use either one of them:

• m - advertising to all users of the machine
• u - advertising to the current user only.

Depending on the passed switch, Windows Installer engine will start executing INSTALL, ADMIN, or ADVERTISE top-level standard action.

User interface levels

Windows Installer supports four user interface levels:

• Full (/qf): All authored modal and modeless and built-in modal error message dialogs are displayed.  This is the default user interface level.
• Reduced (/qr): All authored modeless and built-in modal error message dialogs are displayed.
• Basic (/qb): Only built-in modal error message dialogs are displayed.
• None (/qn): Completely silent installation.

Sequence tables

There are two types of sequence tables which contain the list of actions Windows Installer runs during installation:

• UI sequence table:  Run by the client process.  Presents the user interface to the user.
• Execute sequence table:   Run by the server process.  Performs actual installation.

Each type of installation has its own pair of sequence tables:

• Normal installation:
• InstallUISequence
• InstallExecuteSequence
• Administrative installation:
• AdminUISequence
• AdminExecuteSequence
• Advertisement:
• AdvtUISequence 
• AdvtExecuteSequence

When user interface level is Full or Reduced, Windows Installer engine will start with processing actions from the UI sequence table and continue with Execute sequence table's actions.

When user interface level is Basic or None, UI sequence table will be skipped and installation will be started with executing actions from the Execute sequence table.

Two phases of installation

There are two phases during installation:

• Acquisition:   All actions from the UI sequence table and all actions from the beginning to the InstallFinalize action in the Execute sequence table are running during acquisition phase.  No changes to the system are done at this phase.  Main tasks for acquisition phase are:
• Checking prerequisites (optional):
• Installation is started up on the correct version of operating system, platform, etc (Launch Conditions).
• Competitive upgrade is being installed on the system with competing product installed (Application Search).
• License for licensed product is valid (Product Validation)
• Selecting features to install (either through user interface or properties in the command line).
• File Costing - making sure that target system has enough of available hard disk space to install the product.
• Generating the installation script for the next phase.
• Execution:  This phase is performed by InstallFinalize action in the Execute sequence table.  During this phase an installation script, generated during acquisition phase, is passed to process which runs with elevated privileges.  This process executes all actions from the script.  All changes to the system are done at this phase.  Depending on success or failure of the running installation script, the Execution phase will be completed by:
• Rollback installation:  If installation is unsuccessful, the installer restores the original state of the system.
• Commit phase:  If installation is successful, installer will run all Commit custom actions.

Remember:   Acquisition phase is also known as Immediate phase when it comes to custom actions.  All Immediate custom actions are running in the context of the user performing the installation.  Immediate custom actions must not change the system.  Execution phase is also known as Deferred phase when it comes to custom actions.  Deferred custom actions usually run with elevated privileges unless they are not impersonated.  Impersonated deferred custom actions are running in the context of the user performing the installation.

 

Installation workflow

• Step 1:  User launches the installation by starting up the msiexec.exe.  Windows Installer copies the MSI file into Temp folder and gives the unique name to the copy.
• Step 2:  If user interface level is Basic or None go to Step 10.
• Step 3:  Start processing actions from UI sequence table in the client process.
• Step 4:  Checking Launch Conditions.  Windows Installer engine runs the LaunchConditions action which queries the LaunchCondition table for conditions that need to be checked.  If any of the conditions fails (evaluates to FALSE), Windows Installer engine displays the message box with the error message and then terminates the installation.
• Step 5:  Application Search.  Windows Installer engine runs the AppSearch action.  This action relies on information in AppSearch, Signature, CompLocator, RegLocator, IniLocator, and DrLocator tables to search for required/competing applications on the target system.  A successful search sets the value of user defined property which can be used in conditions for other actions.  This property is not set if the search fails (meaning - it is either undefined or keeps the old value).
• Step 6:  File costing.  Windows Installer runs CostInitialize, FileCost, CostFinalize, and InstallValidate actions in order to check if target system has enough hard disk space for a default set of features to be installed.  File costing is a very complex process which takes into account the size of all files to be copied to the target system, additional space required by registry, new initialization files to be created and their size after adding required entries into the initialization files, new shortcuts being added to the system, etc.  Windows Installer performs three major operations during file costing:
• Evaluate Feature conditions:  The Feature table has a Level column.  The value in this column determines if the feature will be installed or not.  This value can be modified at install time depending on the result of evaluation of condition in the Condition table.  If the condition in the Condition table evaluates to TRUE, Level column in the Feature table will be set to the value of Level column in the Condition table.
• Evaluate Component conditions:  Component table has a Condition column.  If the condition is NULL or evaluates to TRUE, component is enabled and will be installed.  The size of the component will be evaluated and included in the total size of installation.
• Resolve Directory table:  The Directory table specifies the directory layout for the product.  Each record indicates both source and target directories.  When entries in the Directory table are resolved during file costing, every row becomes a property in the Property table.
• Step 7:  Windows Installer is running required user interface.  The type of the user interface depends on what type of installation is performed (fresh, maintenance, patch, or resumed install):
• Fresh install:  User interface provides a number of wizard dialogs through which the installing user can set installation options, such as installation directory, set of installed features, per-user or per-machine installation, and so on.
• Maintenance install:  User can remove or repair the product, or change the set of features installed on the target system.
• Patch and resumed install:  The user interface just notifies the user of the type of installation being performed.
• Step 8:  Windows Installer shows the modeless progress dialog.  Client process launches the server process as a result of executing the ExecuteAction standard action.  This action initiates the processing of Execute sequence table (InstallExecuteSequence or AdminExecuteSequence) in the server process.  All public properties that have been defined in the client process are passed to the service process.
• Step 9:  Server process loads the MSI file into memory and starts processing actions from the Execute sequence table.
• Step 10:  Checking Launch Conditions.  This is the same check as in the Step 4.  The reason this check is repeated is because the user interface level can be set to None or Basic, in which case Step 4 would be skipped.
• Step 11:  Application Search.  Same as Step 4 and is repeated for the same reason as Step 10.
• Step 12:  File costing.  File costing is performed in the server process based on whether there have been any changes in the default set of features.
• Step 13:  Windows Installer is calling InstallInitialize action which starts the process of creating an installation script.  All actions from the Execute sequence table up to InstallFinalize action that are going to make changes to the system are written to the installation script.
• Step 14:  The InstallFinalize action marks the end of the installation script creation process.  Windows Installer starts executing the installation script with elevated privileges.  User has a choice to mark custom actions as impersonated, in which case they will run under installing user's credentials.  Each executed action is written to the rollback script.  If the end user cancels the installation or installation fails, Windows Installer would use the rollback script to undo all changes to the system.  If all actions from the installation script complete successfully, Windows Installer runs all commit custom actions authored in the Execute sequence table.
• Step 15:  Windows Installer runs all actions sequenced after the InstallFinalize action.  Those actions should not make any changes to the system because those changes cannot be rolled back in case of failure.
• Step 16:  Server process is passing control back to the client process.  Windows Installer runs all actions sequenced after the ExecuteAction action.  After all actions are executed, if any, the Windows Installer shows a final dialog with the status of installation (success, canceled by the user, or failed).