How Windows Installer Engine installs the installation package?
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:
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:
Sequence tables
There are two types of sequence tables which contain the list of actions Windows Installer runs during installation:
Each type of installation has its own pair of sequence tables:
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:
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).
