Best Practices for Windows Installer MSI Custom Actions

The Windows Installer has many built-in actions for the installation of applications. However, when a packager of an installation package finds it necessary to write a custom action. There are some best practices which have to be followed for optimal execution.

  • Custom actions that use sensitive information should not write this information into the log.
  • Custom Actions must not attempt to set a System Restore entry point from within a custom action.
  • Return error messages from custom actions and write them to the log to facilitate troubleshooting custom actions.
  • Do not change the system state from an immediate custom action. Custom actions that change the system directly or call another system service must be deferred to the time when the installation script is executed.
  • Every deferred execution custom action that changes the system state must be preceded by a rollback custom action to undo the system state change on an installation rollback.
  • Custom actions that perform complex installation operations should be an executable file or dynamic-link library. Limit the use of custom actions based on scripts to simple installation operations.
  • Make the details of what your custom action does to the system easily discoverable to administrators. Put the details of registry entries and files used by your custom action into a custom table and have the custom action read from this table.
  • A custom actions should not display a dialog box. Custom actions requiring a user interface can use the MSIPocessMessage function instead
  • Custom actions must not use any of the MSI functions like,
    MSIVerifyLog etc…
  • If the installation must be capable of running on a Terminal Server, test that all your custom actions are capable of running on a Terminal Server.
  • To have a custom action run when a particular patch is uninstalled the custom action must either be present in the original application or be in a patch for the product that is always applied.
  • Custom actions should not use the UI level as a condition for sending error messages to the installer because this can interfere with logging and external messages.
  • Use conditional statements to ensure that your package correctly runs custom actions, does not run custom actions, or runs alternate custom action when the package is uninstalled.
  • Test that the package works as expected when uninstalling custom actions.
    If the installation must be capable of being run by users that do not have administrator privileges, test to ensure that all the custom actions can be run with non-administrator privileges.
  • Custom actions require elevated privileges to modify parts of the system that are not user specific. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges. Any custom actions the require elevated privileges must include the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options in the custom action type.


Leave a comment

Your email address will not be published.