Video Screencast Help
Endpoint Management Community Blog

What is Deferred Execution Custom Action and Why is it Used ?

Created: 04 Nov 2008 • Updated: 04 Nov 2008 • 3 comments
WiseUser's picture
0 0 Votes
Login to vote

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.

This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction.

A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script.

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.

Comments 3 CommentsJump to latest comment

R-Vijay's picture

For more related reading.. refer this below article to know on "how Custom actions are defined and used?".

http://juice.altiris.com/article/5217/custom-actio...

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

-1
Login to vote
looeee's picture

Nice article. Here's some more info for you.

An immediate custom action's role is to gather data to be used by the deferred actions. They are used for checking for prerequisites, licensing, configuring, etc.

To pass data to a deferred action you make a property with the same name as it. From the deferred action you read the data from the property CustomActionData.

If your deferred execute custom action makes a permanent change to the system then it should also back up the original data. Use a Commit deferred execute custom action to delete the backup (in case of success) and a Rollback deferred execute custom action to restore the backup (in case of some other action failing).
The actions should be sequenced like this:

  • Deferred
  • Rollback
  • Commit
    Give them all the same conditions as each other
  • +1
    Login to vote
    abhi_so's picture

    Hi,

    Can anyone specify where exactly the reference count for the shared dll is mentioned and in what form?

    Also, Can anyone explain the concept of dll hell, isolated comonents and side-by-side sharing of dlls?

    Thanks a lot!

    -Abhishek

    -1
    Login to vote