Deploy Installers

The Gateway platform supports deploying and running installers on Remote Integrators. This is primarily used for deploying new versions of the Remote Integrator components (Remote Agent, UpdaterA, and UpdaterB), but it can also be leveraged for other installers.

Installers must be explicitly allowed by Conevity before they can be deployed via the Gateway platform. Please get in touch if you’re interested in this functionality.

Installers are deployed via the Bulk Deploy Installer dialog. This dialog lists all installer packages in the left pane, and all Remote Integrators in the right pane. There are additional columns displaying the current version of each component, the host operating system and .NET version, as well as whether there is a pending reboot (which may cause installers to fail). The S.A. column indicates if a user has manually changed the service account hosting the UpdaterA/B processes (which we do not recommend).

You can add and remove installers using the buttons at the top of the Installer Packages pane. Note that deployed installers must be headless (ie - they cannot require a user to interact with a UI) and are typically MSI files (but can also be EXE).

Filters

There are many reasons why an installer may fail to install (after deployment) as there are an infinite number of host system configurations in the wild. The Filters feature is designed to identify these scenarios and alert the user. The user can then skip deployment to these Remote Integrators, if desired.

Click the Edit link to open the Filters dialog. Click the Add Filter button at the top, and look through each tab.

You can give your filter a name, description, and choose to exclude any remote agents which have pending reboots or are running under non-standard service accounts (both common reasons for an install to fail).

The Remote Agents tab lets you specify one or more Remote Agents to explicitly exclude. For example, if you know that certain host software always blocks installers (Carbon Black, for example), you could include all hosts running this software.

You can also exclude Remote Agents based on OS Version and .NET Version, on the next two tabs. The Incompatible Upgrades tab lets you define known incompatible upgrades - for example, if you cannot upgrade version 1.0 to 3.0 directly.

Once you save your Filter(s) and close the dialog, you can choose which filters to apply to the deployment tree by checking each Filter. If a Remote Agent matches a filter, it is greyed out and marked as excluded. You can optionally re-include it in the deployment by clicking the Remote Agent checkbox.

Simple Deployment

To deploy a single installer, select the installer from the left pane. Then select the Remote Agents to deploy to in the right pane. You can use the All hyperlink and selection icons to bulk select.

Clicking the Deploy button will initiate the transfer and installation of the installer.

Note that errors will be displayed in the Status column (if there are any).

Advanced Deploy

When deploying a new version of the Remote Integrator, you can use the Advanced Deploy option. This option deploys multiple installers as well as performing some common maintenance items. Once you’ve selected the Remote Integrators to be deployed, click the Advanced Deploy button.

There is a lot of functionality built into this dialog.

Operation:

Deploy & Install: Installers will be deployed (copied) and executed.
Deploy Binaries Only: Installers will be deployed (copied) only. If you wish to reduce the upgrade time window, you can use this option to deploy all the installers ahead of time. Once all the installers are copied, you can re-run the Advanced Deploy and choose the Deploy & Install option. If the installer file already exists on the Remote Integrator, the deployment step is skipped.

Packages:

Choose which packages to deploy. Typically you will deploy new versions of the Remote Agent and UpdaterA, and deploy a known-good version of the UpdaterB package. You can optionally choose to deploy the latest version of UpdaterB. Database packages (Mongo) can also be deployed at this time.

The reason behind having two Updater processes is to provide redundancy in the case that a newly deployed version doesn’t function as expected. As long as one Updater process is connected and available, the RI can be upgraded/downgraded and managed. For this reason, we recommend you update only one Updater at a time. Perform the Updater upgrade, wait until operations under the newly deployed versions are verified, and then update the other Updater. Typically, you can leave UpdaterB one version behind the Remote Agent and UpdaterA versions.

Additional:

Flush Plugins: Flush all cached plugins after install. Plugins will be re-downloaded as required.
Cleanup Package Folder: Flush all cached packages after install (reclaim space).
Save Post-Upgrade Report: Create an excel report summarizing the bulk deployment.

In the Summary section, you can view a description of what operations the Advanced Deploy dialog will perform.

You can also use the Pre-Upgrade Report link to save the state prior to deployment.

Click the Continue button to start the deployment.