Can you imagine deploying 60-70 new computers per day for multiple customers with just 1 or two techs?
The RMM Suite and your RMM platform make this "childs play"!
The RMM Suite provides an Onboard Automation tool that can fully automate the ongoing deployment of endpoint software and configuration tasks. It's a powerful tool that takes just a few minutes of planning and setup to effectively leverage. Follow along as we walk through a typical setup scenario.
The Onboard Automation (OBA) tool runs when an agent first checks into the RMM platform. If an alarm is configured (recommended), then this happens within 2-3 minutes of the agent first being installed and checking in. Without the alarm, it can take up to 24-hours for the RMM to schedule the daily automation tasks, so using the alarm is essential if you are going to deploy many new systems from your tech bench.
The OBA tool consults a configuration file for a list of RMM scripts to run. It uses the APIs to run these scripts based on an agent's classification within several task categories. This initial run usually executes many scripts to deploy software and configure the endpoint, first for MSP tasks and then for customer-specific tasks. This provides a high degree of flexibility in a highly automated process.
Once the initial execution runs, the OBA tool continues to run each day, comparing the current task list with what has already been completed. If a new task is found, it is run and the process logged. This allows a "Standard Configuration" to be defined by the MSP for internal and client-specific settings that is maintained automatically.
There are several categories of tasks that the OBA tool uses to decide what it should do. There are three "general" categories that allow the MSP to perform their tasks, called "All Agents", "All Servers", and "All Workstations". Scripts defined in these categories run on all endpoints unless specifically excluded for a particular customer. This allows, for example, to deploy a configuration script to every workstation, but exclude a specific customer that needs an alternate setting. The concept allows tailoring an otherwise broadly deployed process.
Additional categories are next tied to specific customers, allowing execution of scripts to all agents, just servers, just workstations, or even workstations in a specific site location.
The OBA configuration file simply defines each of the task categories, then lists the names of the scripts that should be executed. Each script has a control parameter associated with it - Yes | No | All - that controls how it will be run. "No" allows the script to remain in the config file but it is disabled and will be ignored. "Yes" will cause the script to be executed if the agent belongs to a "managed" group. This will skip any agent that is considered "unmanaged" (break/fix or not yet managed/onboarding stage). The "All" option allows the script to execute on all endpoints regardless of the managed/unmanaged status. This is especially useful for scripts that configure the endpoint or the RMM agent itself.
Preparation And Planning
Preparation mainly consists of creating the RMM scripts needed to perform the application installation and endpoint configuration processes. These should be created and tested before defining them in the OBA config file. Testing can be completed simply by manually executing the script from the RMM platform.
Planning requires an understanding of what processes should be performed globally, which customers should be excluded from global tasks, and then selecting the customer-specific tasks. Something to consider here - the RMM Suite app installers are often generic and employ a Cloud Script Variable to assign a license key or similar configuration setting. Customers that don't have a key will abort that script without a "failure", allowing this script to potentially be applied globally, yet executed only where a CSV value has been defined.
This is the easy part! Depending on your RMM, you may need to enable the "New Agent" alarm to allow the onboarding process to run immediately after the first check in. Everything from that point onward is automated. Simply maintain the OBA config file to add scripts as the standard configuration changes, knowing that these will run automatically the next time the Daily Tasks are run.
Note that you can define scripts that install, remove, or update endpoint components, but once a specific script has run successfully, it will NOT be run again. Updates can be deployed by including some specific text in the name such as "Update XXX to V3.45" or "uninstall XXX V3.0". The RMM Suite maintains this tracking in the "init" sub-key of our registry path, so an alternative would be to clear or remove the key if you need to run a task again.