/
Installer Package Push Updates / Advanced Deployment

Installer Package Push Updates / Advanced Deployment

Version 16 introduces new push-update features:

  • UI updates to show more remote agent information

  • Filtering of remote agents (exclude from deployment)

  • Not updating the service account

  • Advanced deployment options

    • Chain multiple installers

    • Pre-push msi payloads without install

    • Pre and post deployment reports

UI Updates

The deploy installer package dialog now includes the following filterable columns:

  • Current RA, UA, and UB version

  • Operating system version

  • .NET version

  • Pending Reboot State (if the target machine has a pending reboot from another install/update)

  • Non-standard service account (the remote agent service is not running under the default account)

Filtering

Deployment filtering is a new feature which lets you exclude remote agents from deployments based on certain criteria. Currently supported filters are:

  • Pending Reboot

  • Non-standard service account

  • Direct exclusion (remote agent was explicitly excluded)

  • OS Version

  • .NET Version

  • Incompatible Upgrades (Where version A cannot be upgraded to version C, it must be upgraded to version B first).

The filter bar is displayed when a remote agent or updater package is selected from the packages pane. To add/edit/remove filters, click the edit link within the filter bar:

The Deployment Filters dialog lets you create and edit filters:

You can choose to create multiple filters, each with a single filter type (one filter for unsupported OS versions, one filter form unsupported .NET versions, etc.), or, you can combine multiple filtering criteria into a single filter.

Each filter that you create is displayed within the deploy installer dialog and can be enabled/disabled by selecting the associated checkbox.

Remote agents which are excluded by a filter are greyed out. An exclamation icon as well as the reason for exclusion are displayed. You can hover over the exclusion icon to see a detailed reason for exclusion:

If you wish to override the exclusion and include the remote agent in the deployment, you can click on the exclusion warning icon. This will ignore the filter and include the remote agent in the deployment. Click again to re-exclude.

Advanced Deployment

An additional button has been added to the Deploy Installer dialog: ‘Advanced Deploy’. This button is enabled when either a remote agent or updater package is selected. The advanced deployment dialog adds the following functionality:

Operation:

  • Deploy & Install: The default operation which transfers the msi package(s) and installs them.

  • Deploy Binaries Only: Copy the binaries to the remote server, but do not install them. When doing a large deployment, a large percentage of the overall time is often spent waiting for the binary payloads to transfer to the remote server. This option lets you pre-deploy the binaries (a week ahead of a planned upgrade, for example) and therefore reduce the overall time when performing the upgrade.

If the target package already exists on the remote server, the file is not re-transferred.

Packages

Upgrades typically involve deploying new versions of all three remote integrator components: Remote Agent and Updater A and B. In previous versions, each of these packages was deployed as a single bulk operation (bulk upgrade Updater A, then bulk upgrade Updater B etc.). It is now possible to ‘chain’ packages together and have each component deploy in one operation.

For example, you may choose to deploy a new version of Updater A and Remote Agent in a single operation. In this case, the Updater A package will be deployed and installed, and if successful, the remote agent package will be deployed and installed.

Typically, we recommend that you use the following pattern for upgrades:

  1. Leave Updater B on a known-good version. This is your lifeline in case of defects in newer Updater A and/or Remote Agent versions.

  2. Upgrade Updater A.

  3. Upgrade Remote Agent.

On your next upgrade cycle, upgrade Updater B to the current version of Updater A prior to pushing out new versions of Updater A and Remote Agent.

Using this pattern will leave Updater B one version behind Updater A and Remote Agent. Optionally, you can bulk upgrade Updater B to the latest version once the new Updater A has been field-tested.

Package deployments occur in the following sequence:

Updater B (if selected) is pushed and installed. If install succeeds and Updater B successfully connects to the gateway, the Updater A (if selected) is pushed and installed. If install succeeds and Updater A successfully connects to the gateway, the remote agent package is pushed and installed.

Additional Operations

Flush Plugins: If deploying a remote agent package, you can optionally flush the plugin directory.

Save Post-Upgrade Report: A CSV file will be created (on the desktop) containing the deployment parameters and results of the bulk deployment. Deployment results are always logged in the event log in a tab-delimited format which can by copy/pasted into Excel.

Related content

Remote Agent Database De-coupling
Remote Agent Database De-coupling
More like this
Remote Agent Decommissioning
Remote Agent Decommissioning
More like this
Advanced Plugin Versioning
Advanced Plugin Versioning
More like this
Local UI Evaluation Releases
Local UI Evaluation Releases
More like this
Remote Agent Overview
Remote Agent Overview
More like this
RA UI Administration
RA UI Administration
More like this