RMM Suite Technical Capabilities

The RMM Suite consists of these key VSA Platform Enhancements:

Agent Procedures

A diverse set of shared procedures that automate many common tasks. While easily customized, most can be utilized immediately to deploy and update applications, perform agent on and off-boarding tasks, deploy daily maintenance, and perform custom auditing. When integrated with Kaseya Service Desk, a full suite of auto-remediation procedures can be used to eliminate manual remediation of alerts. The included procedures are field proven and eliminate hundreds of hours of development time.


Both KAV and KAM components are supported with standards-based methods and components to insure reliable deployment and operation. Alerts are machine parseable for automatic remediation of common issues. A suite of Procedures/Scripts automatically remediate common issues, while a collection of external tools verify operation and currency of definitions, with automatic updating when outdated definitions are found. These tools support multiple AV platforms in addition to KAV.


An extensive collection of monitors utilizing machine-parseable headers check events, services, performance, and other alerts. A structured format for all monitors allows direct and consistent identification of type, source, priority, and automated handling methods. The monitors are focused on what can be remediated, eliminating “noise” and “nuisance” alerts.

Disk Capacity alerts are monitored through custom-built applications, eliminating the “one size fits all” monitoring method, resulting in fewer false alerts. Our intelligent disk capacity monitoring automatically adjust the thresholds based on disk capacity while capacity trend monitoring provides predictive alerts based on increasing utilization.

A layered auto-remediation method is used for many issues (restart service, then invoke service management script to start and monitor the service for continued operation, for example). Nearly all monitors employ a “three strike” tracking to further reduce false alerts from transient issues.

Patch Management

Patch Management is implemented with a full set of patch policies. These provide a starting point for effective patch management. Patching is managed by patch policies, controlling deployment of specific classes of updates. System Policies are used to consistently configure patch settings and schedule updates and system restarts. For workstation patches, users are reminded the day before to not shut down, then nagged regularly to reboot if necessary. Server patching is tightly controlled – specific day/time, perform a reboot, then apply updates and reboot. Server schedules are easily sequenced to honor server interdependencies, and are managed by pre-defined system policies.

Policy Management

System Policies allow an MSP to apply monitors, schedule tasks, and remediate common conditions with minimal manual effort. A broad set of pre-defined System Policies provide consistent and effective management of complex configurations.

System Policies are used to control every aspect of monitoring, patching, maintenance, Audit, AV/AM, and general configuration. Policies are applied globally for common configuration and directly for host-specific settings for maximum control. Remediation policies detect when a compliance deviation exists and invoke procedures to remediate the configuration without manual intervention;

Network Monitor

Network Monitor is used for out-of-band monitoring of critical services as well as system performance. A suite of templates with multiple performance threshold tiers allows monitoring with minimal effort and an extremely low level of false alerts that often occur when using default monitors. The supplied templates and Service Desk procedures support the following monitors:

Monitors Site Connectivity:

  • Confirms that site communication has failed before alerting

Monitors Operational Availability:

  • Server is up and able to communicate with external hosts;
  • Service is operational (DNS, HTTP, DHCP, SMTP and similar services); This is a test to communicate with the target service and not simply determine if the service/daemon is “running” on the system ;

Monitors Server Performance:

  • Templates with multiple “tiers” to define thresholds based on the capability of the environment;
  • Templates for common platforms (domain controller, SQL server, Exchange server, etc.) allow monitors to be rapidly deployed with minimal customization;
  • Monitors only what can be adjusted or tuned to reduce noise and false alerts;
  • Performance alerts can be globally restricted to Never create a ticket – track performance only; Only create a ticket weekdays between specific hours; Only create a ticket between specific hours on any day; or Unrestricted (optionally, by client) always creates a ticket;

Service Desk

Our Service Desk (SD) implementation provides a high degree of automation, from validating alerts and checking for repeating events to automatically remediating alerts and performing voice alerting of critical events.

SD handles all incoming events by alert and email, identifying events that can be auto-remediated and invoking the remediation procedure. It also identifies events that can be cancelled (universally or by time restriction) to reduce nuisance tickets. The alert source, type, priority and handling info are extracted from alert summary data for optimized processing and direction to a ticketing system.

Specific alert classes are identified and routed to the appropriate process handler. This initiates and tracks remediation events, identifying successful remediation. Multiple patch failures are summarized into a single ticket per agent, eliminating hundreds of duplicate tickets.

The completion process communicates with any ticketing system via email using a standardized header for direct and consistent parsing for further ticket routing and classification. Successfully remediated tickets can be forwarded with “Closed” status or simply dropped. Tickets with failed remediation or those that had no defined remediation process are forwarded in “New” status for manual follow-up. Tickets that do not require a ticket are not forwarded; these include certain auto-response (AV definition update) and request (user requests maintenance to run now) events.

Open tickets that are at priority 1 or 2 can invoke BINS (Baroan Incident Notification System) as well as send an immediate email to the on-call team.

Incident Notification System

An application that provides after-hours voice notification for just pennies per call (requires a subscription to a third-party Internet voice-call service). All open P1/P2 events will immediately send a notification email to the on-call team. The customer service type is then evaluated against coverage hours. If the alert occurred within coverage time, a call will be made. Alerts that occur outside of coverage hours will be deferred to the morning, and all deferred events will be summarized with a single call. Calls are not made while the help desk is in operation.

MSP Builder Multi-Tool

The RMM Suite includes the MSP Builder Multi-Tool, which allows an MSP to develop additional Service Desk procedures using more than 60 advanced functions, including:

  • Thirteen advanced math functions – the basic 4 functions plus increment/decrement, rounding, hex/dec conversion, and small-value random number generator (0-99);
  • Six comparisons that operate with double-precision numeric values, yet automatically switch to string-based comparisons when a non-numeric value is detected;
  • Fifteen string manipulation functions that return positional substrings, substring replacement, substring detection, delimited string field manipulation, ASCII code manipulation, case conversion, and version string comparisons;
  • Nineteen date and time functions, from simple lookups of current date, time, weekday (name or number), Julian day, and date-part to complex time calculations that return elapsed time or tell if a specific (or current) time is within a specific date/time range;
  • Four Logic functions that provide And, OR, and Not logic plus a function that evaluates specific numeric and text strings into True/False values. Additional “true” values can be user defined;
  • Two network functions that provide the ability to determine if an IP address is within a specific subnet and perform NSLookup commands to convert name to IP and vice-versa. The latter only works for public names as it runs from the Kaseya server;
  • Extensive logging is available - Log everything; Log only errors and LOG function messages;

Log messages can be prefixed with an identity to aid in development and procedure troubleshooting. Built-in functions are provided for log management to rename logs by day (7 logs), date (unlimited logging), or “current/prior” (2 logs).


A full suite of standalone maintenance tools that perform common, regularly scheduled maintenance tasks, including disk cleanup, capacity checks, disk reliability and SMART tests, AV and AM checks, and much more. The maintenance tasks can easily be extended to perform any custom tasks that an MSP wishes to implement or a customer requires.

Maintenance is initiated by Kaseya, but run autonomously on the agent system without further assistance from Kaseya. Maintenance will even run as scheduled if the computer is not connected to the Internet. The procedures are distributed from Kaseya throughout the day – servers early am, workstations 10am-4pm, to spread the workload. The individual maintenance tasks can be configured to run daily, weekly by specific or random day, or monthly.

There are two daily cycles in the maintenance process. The Day cycle performs data collection and non-invasive checks that usually completes within 60 seconds, such as collecting system information and updating custom fields, verify that the system AV is installed, running, and has current definitions, remind user of upcoming events, such as patching and planned reboots, and initiates hourly disk capacity checks and updates the daily trend log. It also schedules the “night” maintenance cycle.

The Night cycle performs more aggressive tasks that might affect system performance. If a user is logged on when maintenance starts, they will be notified and have the opportunity to defer the maintenance. The night cycle include tasks such as temp file cleanup, disk quality – CHKDSK and SMART tests, Defrag, and a weekly reboot.

Maintenance tasks can be deployed globally, by client, by site, or to a specific computer. MSP engineers can create & deploy custom maintenance packages that schedule when Night maintenance runs, define “working hours” to prevent Night tasks from running during specific times, and configure which tasks run, in which sequence, and on what schedule.

Alerts are generated when specific conditions are met, such as a maintenance task failed, AV security is missing, disabled, or outdated, or disk capacity below a calculated “smart threshold” or trending suggests high utilization will soon exhaust capacity.

Smart Monitoring

Smart Monitoring replaces many basic Kaseya alerts to reduce tickets that would usually result from transient conditions. These Smart Monitors include AV checks for real-time and accurate verification of operation. These alond have reduced Kaseya-based alerts by over 70% (specifically, AV not running or definitions outdated.) Disk capacity checks are based on 12 distinct disk sizes, with auto-adjusting free-bytes and free-percent thresholds. Larger drives have lower thresholds as this represents more space, eliminating the “one size fits all” method of free space monitoring based on a single percentage or value. It also eliminates the need to create and configure many monitors with unique threshold values.

All threshold type alerts utilize “3-strike” logic to prevent alerting unless the issue persists, eliminating alerts from transient issues.

User Interface

A User Interface allows interaction between the user, maintenance tasks, and the Kaseya VSA. It can be fully customized to identify the MSP with logo and links to MSP web and portal sites. The user interface displays for 15 seconds after a user logs on, then minimizes to system tray. The UI keeps the user informed about tasks that are often done behind the scenes, which reinforces the value that the MSP provides.

Key information displayed by the User Interface includes:

  • When the last ran and next maintenance is scheduled
  • Identifies next scheduled reboot time
  • Lists a summary of the last 50 maintenance events
  • Displays status of maintenance – current or 2/4 days overdue
  • User can defer current day’s maintenance in advance
  • User can defer maintenance when it starts for 30 minutes, up to 12 times before maintenance will start. If a maintenance initiated reboot is needed, the user can defer it for 30 minutes up to 4 times before the reboot is performed.
  • Provides access to all maintenance detailed logging from the past 7 days
  • Enables user to request all maintenance tasks to be “run now” when maintenance is overdue
  • Provides links to MSP web site, portal, and ticket request pages