Custom Actions

Custom Action Wizard:

Additional Options:

Setting

Description

Return Processing

Specify how the custom action thread should be processed. Valid options for the Return Processing list are: • Asynchronous (No wait for completion) • Asynchronous (Wait for exit code) • Synchronous (Check exit code) • Synchronous (Ignores exit code) These flags are used to specify that the main and custom action threads run synchronously (the installer waits for the custom action thread to complete before resuming the main installation thread) or asynchronously (the installer runs the custom action simultaneously as the main installation continues).

            Respond Options Panel

The Respond Options panel lets you specify how your custom action will respond to the rest of the installation.

Option

Description

In-Script Execution

Specify when you would like your action to execute. • Immediate execution— Select this option to have the action execute when it is encountered in the sequence. Which means, it can run any time during the installation. • Immediate execution (Terminal Server Aware)— Same like the Immediate Execution, except the custom action impersonates the user during per-machine installations on terminal server machines. • Deferred execution— Select this option to have your action wait until the script begins to run. This means, it will run only between Install Initialize and Install Finalize. • Rollback execution—Select this option to set your action to execute only during rollback. If you changed something to the system during the execute sequence using a custom action, you need to undo that change with a rollback custom action. Rollback execution (Terminal Server Aware)— Same like the Rollback Execution, except the custom action impersonates the user during per-machine installations on terminal server machines. • Commit execution—Select this option to have your action delayed until the installation has successfully completed the installation script. • Commit execution (Terminal Server Aware)—Same like the Commit Execution, except the custom action impersonates the user during per-machine installations on terminal server machines. • Deferred execution in system context—Select this option if your action needs elevated system privileges for performing tasks such as editing the registry. The action is deferred until the script begins to run. When the action does run, it runs with elevated system privileges. This action is meant for system level changes, hence elevates itself to admin status.

Deferred Execution:

The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed.

The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script.


1. Should be placed between install initialize and install finalize.
2. Does not have access to MSIDATABASE in deferred execution.

Custom Action Conditions:

INSTALLED                          during repair or install on top of install

NOT INSTALLED                                during first time installation

REMOVE=ALL                    during uninstallation

NOT REMOVE                    during first install and repair

Condition for Action to run only during Upgrade

Condition: NOT UPGRADINGPRODUCTCODE

●     Return codes from custom actions are insufficient to record the success or failure of a custom action, so the outcome of custom actions must be recorded in the log using “MsiProcessMessage”.

●     Custom actions that change system state must be written as a deferred and rollback custom action pair.

●     Custom actions that change system state during installation must remove or restore the system state during uninstallation. In addition, custom actions that change system state must be written as a deferred and rollback custom action pair.

Like any custom actions, changes to client firewall settings must support silent install and full rollback.

During installation, the Execute sequence runs in two stages, immediate mode and deferred mode. Immediate mode walks through the actions in the Execute sequence, generating an internal, hidden installation script; this script contains, for example, instructions for what files, registry data, shortcuts, and so forth, to install. Immediate mode does not touch the target system. Note that the User Interface sequence runs only in immediate mode.

The second stage of the Execute sequence, deferred mode, carries out the system changes described by this internal installation script. (Strictly speaking, deferred mode is performed only for actions between the built-in actions InstallInitialize and InstallFinalize.) During deferred execution, MSI property values are fixed and cannot be changed. Moreover, the values of only a handful of MSI properties can explicitly be read during deferred execution.