Windows Installer Sequencing

April 9, 2008

Ok well this is probably one of the harder topics to try and explain on paper. Its considerably easier to do with a whiteboard and a room full of people. But I will have a shot at it no doubt Kim (AngelD) will assist with any problem areas. Throughout this document try to keep this diagram in your head.

So in order to understand windows installer you really need to get your head around the installation sequences sooner rather than later. I often hear people throwing around the terms of Immediate and Deferred custom actions and completely misunderstanding the context of what this really means. So here I will try to explain how and why this is so important.

Windows Installer has 6 tables which control the order and flow of when and where all other tables are read (as above). Of these 6 installation sequence tables only 2 of them are executed during a typical execution. Tables are to be executed are determined by the installation command line. The tables and their respective command lines are :

Command Line Exec Table Name UI Table Name Top Level Action
msiexec.exe /i InstallExecuteSequence InstallUISequence INSTALL
msiexec.exe /a AdminExecuteSequence AdminUISequence ADMIN
msiexec.exe /j AdvtExecuteSequence AdvtUISequence(usually hidden) ADVERTISE

What this means is that when you run msiexec.exe /i <Path to msi> which is a typical installation command line you will be executing the two tables of InstallExecuteSequence and InstallUISequence.

Additional to each pair of tables a User Interface Level (UILEVEL) is thrown into the mix by additional switches to the previous command line.

Windows Installer supports four user interface levels:

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

By utilising these extra command line switches items within the UI Tables as shown in the table above are conditionally loaded.

For example:

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.

Note: Actions can be in both tables and may or may not be executed in both of the respective tables. When custom actions are involved this can be toggled by custom action attributes (as specified from the type column of the custom action table)

Installation Phases

Each installation is broken down into a series of phases those phases each have different attributes and more importantly occur at staged times throughout the installation. The first of the phases is the Acquisition phase.

Acquisition Phase (Immediate)

The acquisition phase consists of all actions from the appropriate UI Sequence table (as controlled from the selected command line options) and all actions from the Install Sequence table (as controlled from the selected command line options). Generally during the acquisition phase items should not be installed to the target platform it should be used purely as a data gathering phase. The data gathered is then used to conditionally control the actions which happen in the later phases.

During this phase some of the main items performed 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.

To gain some real appreciation of what is happening during this phase and in particular from when the action InstallInitialize is reached. The InstallInitialize action is important as this action signifies that start of the Installation script generation. As I have tried to depict with the main diagram at the top of this page the first parse of the actions between InstallInitialize and InstallFinalize are parsed and their conditions are evaluated, where a condition is met the action is written into the Installation script. (Note: this script does not exist prior to installation). This process is repeated until the InstallFinalize action is reached.

Now to throw a little confusion into the mix where an action is a custom action the custom actions type is evaluated and if the custom action has an Immediate attribute and the condition is evaluated as true then that custom action is executed Immediately hence the name. Where a custom action has an attribute of Deferred and the condition is evaluated as true that custom action is written into the installation script.

Note: 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

The execution phase is split into two separate phases known as Deferred and Commit/Rollback.

 

Deferred Phase

This phase is performed by InstallFinalize action in the Execute sequence table.  During this phase the installation script, generated during acquisition phase, is passed to a process which runs with elevated privileges.  This process executes all actions from the script.  This is where the actual installation takes place, files are copied registry is written and the application is installed. When an action is a custom action the custom actions attributes are evaluated and if it is deemed to be a Deferred – Commit that action is moved across into the 2nd installation script. Where a custom action is a standard deferred custom action is it simply executed at that point.

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.

Some important items to note here are as we switch from the immediate phase into a generated installation script, it is at this point that we lose contact with the Windows Installer Session which in turn means that we lose access to a number of properties that were available during the immediate phase.

Note: 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.

 

Commit Phase

Once the Deferred phase reaches the InstallFinalize action and all actions are successfully run the Commit phase runs. During this phase only Deferred custom actions with a Commit / Rollback attribute will be present in the 2nd installation script. As such this is where Deferred Commit / Rollback actions are run. Actions in this phase a custom actions which deploy a item which needs an opposing uninstall action to perform removal. (a poor example as I can’t think of one quickly is if you installed a service using a custom action call as opposed to the service tables)

Once the commit phase reaches InstallFinalize it hands back to the immediate phase which is generally where typical cleanup of application installation data will occur. Note at this point you again have access to all the session which means properties are again accessible.

Ok so that wraps up the Beginners guide to Installation sequences from here I will move onto an Advanced guide which will target all of the MSI Function calls and actual attributes etc. (Might need your help here AngelD)

6 Responses to “Windows Installer Sequencing”

  1. Chris Says:

    Just a few comments on commit CA\’s.   It should be noted that commit CA\’s are really intended to clean up rollback information not to actually make configuration changes.   After all, rollback can be disabled by policy and if it is, your commit CA\’s won\’t fire.
     
    Unfortunatly there is another problem…. some platform api\’s don\’t lend themselve very well to transactional installation.  One example would be GAC assemblies and another is some WiX CA\’s ( I believe Adding Users ) where Rob has stated that the work is done in the commit phase because the underlying API doesn\’t have a pretty way of undoing certain changes.     When I asked him how this would behave with rollback disabled he had to admit it wouldn\’t work.
     
     

  2. Unknown Says:

    I am having a hard time reading this Diagram.  Does anyone have a cleaner copy of this?

  3. Craig Says:

    Thanks for all these posts John, yes they are very useful when WI explanatory info is so scarce on the web (notwithstanding AppDeploy, Installsite, etc),Could you clarify something re Immediate CA\’s: Is it ok to change something on the system via an Immed. CA as long as its sequenced after InstallFinalize? It won\’t run on the normal phases between InstallInit -> InstallFinalize (the possible dangerous bit), and if you are using a Deployment tool like SMS the install will be running with elevated privileges so permissions shouldn\’t be an issue? Or have I misunderstood this still??I thought that once you\’d gotten past Commit then passed back to Immediate phase then the app is installed and the danger of running a CA before something you require isnt laid down is no longer a problem?

  4. John Says:

    Hi Griff,
     
    You should avoid changing the system using immediate CA\’s. When you get up to using Vista and UAC it is not supported. Better to get into the habit now to avoid the new learning curve under UAC related MSI\’s.
     
    Although it is technically possible you should avoid it where you can. If you need access to properties etc use the CustomActionData property to make a deferred CA more useful.
     

  5. John Says:

    Hi Chris,
     
    I will endeavour to clean this up a little better, I did attempt to cover this but wording it is quite difficult. At present I am moving house with no internet access which is painful so it may be a week or two before I can get it sorted.
     
    Regards,
     
    John

  6. jheerq Says:

    Well done. My organization is floored with the quality of the details supplied. I expect that you continue with the great job succesfully done.
    Palo Alto locksmith


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.