Configuring Pre & Post Actions

Remote Installer allows you to perform custom actions before and/or after install, uninstall or repair processes. Such actions are defined for each deployment package and may affect install, uninstall or repair processes and their output is also added to the detailed log.

You can choose among a wide range of action types to perform, which are the following:

• Import of a Registry File;
• Executable File;
• Script File;
• PowerShell Script;
• Shell Command;
• Message.

You can also define if the action should be executed on Machines running both x86 and x64 platforms or only one specific platform (x86 or x64) for multi-platform deployment packages.

The actions to be performed before and/or after install, uninstall or repair processes are defined during the deployment package configuration procedure on the Pre & Post Actions tab Pic 1. For each operating action, it is possible to choose if the operation should wait for the action to be completed before executing the next one and if the operation should be interrupted if the action has returned an exit code that is interpreted like a failure sign. For each message, you can also define if the deployment operation should wait for the message dialog to be closed.

The actions are grouped in the table by their execution type, which shows if it should run before or after install, uninstall or repair processes and sorted by their execution order. When a multi-platform package is being configured, the table items are also grouped by the target platform.

Toolbar Overview

The options of adding, editing, deleting and moving actions up and down the execution order, as long as the configuration menu, are also available in the pop-up menu of the Pre & Post Actions table.

You can add as many actions as needed to every install, uninstall or repair package. Regardless of how the wait for completion configuration is set, it is guaranteed that all Pre-Install/Uninstall/Repair actions, except notification messages, will be completed before the actual install, uninstall or repair process is executed and that the operation will not be finished until all Post-Install/Uninstall/Repair actions are completed and all messages are displayed.

Adding Pre & Post Actions

To add a new action to the deployment package, you should press the New Action button on the Pre & Post Actions table toolbar or choose the New Action item from the pop-up menu. The New Action wizard will be displayed on the screen.

If a multi-platform package is being configured, the first page of the wizard will offer you to choose the target platform for the action being created.

It is possible to specify if the action should be performed with the x86 and x64 installations or with a particular installation. If the deployment package being configured is a generic one, this step is skipped. Please note that the target platform cannot be changed in future when editing the action. The next step of the New Action wizard is choosing the action type Pic 2.

You can choose among the Import of a Registry File, Executable File, Script File, PowerShell Script, Shell Command and Message action types. The action type is also selected only during the action creation process and cannot be changed in future when editing the action. When the action type is chosen, click Next to start the actual action configuration.

Let us take a closer look at configuring each action type from those available, starting with the import of a registration entries (.reg) file.

Import of Registry File Configuration

While configuring the registration entries (.reg) file import action, you can define the action name, which can be used for easier identification in future, in the Name field, specify if the action should be executed before or after the install, uninstall or repair process by changing the Run On field value, provide the path to the registration entries (.reg) file to import to the Path field, and choose if the operation should wait for the action to complete before executing the next one. If you have chosen that the operation should wait for the action to be completed, it is possible to interrupt the operation if the action returns an exit code that does not belong to the successful ones, thus interpreted as a failure. The success codes should be provided to the Success Codes field as unsigned integers separated by semicolon, e.g. 0; 1; 10.

The configuration principle of the next three action types, namely Executable File, Script File and PowerShell Script, is the same. Using the Executable File action type, you can run executable console applications and batch files before and/or after the install, uninstall or repair process. The Script File type should be used to execute simple console scripts, e.g. those written on Visual Basic. The PowerShell Script type should be used to execute PowerShell scripts. Let us take a closer look at the configuration process using the Executable File action type as an example.

Executable File Configuration

Script File Configuration

PowerShell Script Configuration

When configuring an action, you can enter the action name, which can be used for easier identification in future, in the Name field and specify if the action should be executed before or after the install, uninstall or repair process by changing the Run On field value. The next thing to provide is the path to the executable file to be entered to the Path field. If you are using a local path, the action will be copied to each remote Machine before being executed, and it is possible to copy the entire action directory together with the executable file itself. This approach should be used if the action depends on external files. The required command line arguments to be passed to the executable file should be provided to the Parameters field. Just like for the Import of a Registry File action, you can choose if the operation should wait for the action to be completed before executing the next one. If you have chosen that the operation should wait for the action to be completed, it is possible to interrupt the operation if the action returns an exit code that does not belong to the successful ones, thus interpreted as a failure. The success codes should be provided to the Success Codes field as unsigned integers separated by semicolon, e.g. 0; 1; 10.

The next action type is the Shell Command. This action type allows you to execute any shell command before and/or after the install, uninstall or repair process. Let us take a closer look at the action configuration process.

Shell Command Configuration

When configuring the Shell Command action, you can specify the action name, which can be used for easier identification in future, in the Name field and specify if the action should be executed before or after the install, uninstall and repair process by changing the Run On field value. The actual shell command to execute should be provided to the Command field. As for the other action types, it is possible to choose if the operation should wait for the action to be completed before executing the next one. If you have chosen that the operation should wait for the action to be completed, it is possible to interrupt the operation if the action returns an exit code that does not belong to the successful ones, thus interpreted as a failure. The success codes should be provided to the Success Codes field as unsigned integers separated by semicolon, e.g. 0; 1; 10.

The last one of the available action types is the Message. This action type allows you to display simple notification messages to users currently logged on to remote Machines. Let us take a look at the message configuration process.

Message Configuration

When configuring the Message action, you can specify the action name, which can be used for easier identification in future, in the Name field and specify if the action should be executed before or after the install, uninstall and repair process by changing the Run On field value. The message dialog title is entered into to the Title field, and the actual message to be displayed is typed into the Message field. The Timeout field allows you to define the time interval the message should be displayed for. By default, the deployment operation continues as soon as the message is displayed. If you want it to wait until the message dialog closes, check the Wait until this action is completed before running the next one option.

For the title and message definitions, you can use the following placeholders that will be replaced with actual values before displaying the message box on a remote Machine:

You can preview the dialog to be displayed to a remote user using the Message Dialog Preview link.

After you have configured the action to be added, press Create to proceed. The action you have configured will be added to the Pre & Post Actions table at the end of the execution order. To move it up and down the execution order, use the Move Up and Move Down items on the Pre & Post Actions table toolbar or in the pop-up menu.

Editing the Action

To edit an action, you should select it in the Pre & Post Actions table and choose the Edit Action menu item from the pop-up menu or press the Edit Action button on the toolbar. The Edit Action dialog will appear on the screen.

When editing the actions, it is possible to change the same configuration parameters as during the addition process, with the exception of the action type and the target platform. After you have completed configuring the action, press Apply to apply the changes made.

Deleting Pre & Post Actions

To delete pre and post actions from the deployment package being configured, you should select the unnecessary actions in the Pre & Post Actions table and press the Delete Actions button on the toolbar or choose the Delete Actions item from the pop-up menu. When selecting a multi-platform action, which is added to both x86 and x64 installations, in one of the Target Platform grouping rows, be aware that it will be deleted from both x86 and x64 installations.

Now you are fully introduced to the option of executing any type of actions before and/or after install, uninstall or repair processes and should be able to efficiently use this feature of Remote Installer for complex deployment packages.