What is Deferred Execution Custom Action and Why is it Used ?
Created: 04 Nov 2008 | Updated: 04 Nov 2008 | 3 comments
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.
- Should be placed between install initialize and install finalize.
- Does not have access to MSIDATABASE in deferred execution.
Blog Entry Filed Under:
About Endpoint Management Community Blog
The Endpoint Management Community Blog is the perfect place to share short, timely insights including product tips, news and other information relevant to the Endpoint Management community. Any authenticated Connect member can contribute to this blog. Filter by:
Blog Tags
Altiris Client Management Suite Configuring Altiris Deployment Solution Symantec Management Platform (Notification Server) Wise Packaging Basics Altiris Server Management Suite Best Practice Compatibility Altiris IT Asset Management Tip/How to Helpdesk Solution Workflow Solution 7.x Installing Ghost Solution Suite Reporting Windows Performance ServiceDesk IT Management Suite Upgrade Mobile Management 7.x SMP 7.x
Comments 3 Comments • Jump to latest comment
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
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:
Give them all the same conditions as each other
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
Would you like to reply?
Login or Register to post your comment.