RMM Agent Definition

Put simply, an RMM Agent (RMM stands for "remote monitoring and management") is a software program designed to run on the endpoints of a connected product deployment for the purposes of communication with the cloud-based remote monitoring and management for connected products.

(Remote monitoring and management or RMM is a form of remote device management or RDM.)

RMM Agents can vary widely in their feature sets and deployment models, which we will explore in this article. However, RMM Agents typically share some characteristics:

1. They are designed to run natively on the target Operating System. In traditional RMM solution use cases (i.e., MSPs or IT departments looking to support IT assets like workstation PCs or networking equipment), Windows is the ubiquitous operating system. However, for Connected Product use cases (i.e., Kiosks, POS systems, digital signage, or camera systems), operating systems are very diverse.
   ‍
2. They are designed to be unobtrusive to the overall function of the device. Most RMM agents have a very lightweight “footprint” and are capable of running on very small devices. Often Remote monitoring & management agents run in parallel with the primary business software to reduce impact on device operations.
   ‍
3. They provide two-way messaging capabilities. These two-way messaging capabilities both communicate information from the device and receive information from the cloud (the remote monitoring & management tool).

RMM Agent vs. Library vs. API

One feature of an RMM Agent is that the software is usually designed to run within the confines of an Operating System. Depending on the deployment model of the device, this might be directly within the Operating System of the device as a native program, or in an alternate model such as a docker container or app (Android/iOS). The RMM Agent takes advantage of the native Operating System capabilities for functions it might require, such as a file system, networking, memory management, processing allocation, etc.

This differentiates an RMM Agent from deployment models that involve a library or SDK that is built into (underlays) the business application that runs on a device. A library or SDK is designed to be utilized at the outset of the product development lifecycle so that the primary business application can utilize the functions provided by the library or SDK to facilitate the monitoring and management of the application and device. This approach is advantageous if your connected product is based on a device that lacks a traditional OS (such as SOC devices) or there are other constraints on the ability of an RMM Agent to be able to derive information from the target operating environment (such as limited device resources, or operation within a sandboxed environment as might be typical on iOS devices).

An RMM Agent will typically allow you greater flexibility, agility, and control of your RMM posture if your device will support that deployment model.

Both the RMM Agent and Library approaches do require some form of communication to the cloud-based components of an RMM platform solution. This communication is handled via some form of API. This cloud-side API may offer you a third option for integrating your connected product when neither the RMM Agent or Library approach can fit with your deployment model. If the RMM provider allows for it, you can build the API calls directly from your connected product to the cloud and subscribe to the API to receive information in return. There will typically be accommodations you will need to make in your development lifecycle to include security, provisioning, and API consumption streams that your product development team will have to tackle. This application of development resources can be a large hurdle to overcome, which is why utilizing the RMM Agent approach will provide a faster time-to-market in most circumstances.

RMM Agent Typical Feature Set

RMM Agents can contain a variety of feature sets and capabilities. Some RMM Agents may be custom built for just one job (remote desktop or RDP, for example), while others may provide a large extensible set of functionalities. Described here are typical functions of an RMM agent that you may encounter or desire when trying to find the right RMM platform:

• Messaging: This is a core capability of any RMM Agent – it must be able to provide information reliably and securely from the device on which it runs to the cloud-based components of the RMM platform. Sophisticated RMM Agents will allow you to tune this capability to meet your particular product needs or to reduce security vulnerabilities. Examples might include messaging only within a given business operations time window, combining/buffering messages to account for low bandwidth deployments, or being able to quickly silence messages that are no longer important.
  ‍
• Offline Operation: Having a device lose its connection to the cloud is a frequent occurrence with most connected product deployments. The RMM Agent must be able to gracefully deal with those outages. It must decide what messages should be stored and forwarded for later consumption by the cloud and what messages are fine to be dropped. It must deal with any scheduled tasks that it has been asked to perform during the offline period. It must receive information from the cloud when it returns to an online state in a consistent and predictable fashion. The successful handling of these conditions is often a complication that a good RMM Agent can provide a solution that puts the product management team’s mind at ease when experiencing downtime or when troubleshooting an offline device.
  ‍
• Action Execution: While not all RMM Agents provide for the ability to execute actions on their endpoints, many do. This may take the form of a strict set of predefined actions (e.g. reboot, restart service X, pull log file Y) or the agent may provide a set of predefined actions and then also allow for the user to extend those to their own needs (through the use of scripts, executables, or APIs). The ability to execute actions on a targeted endpoint is a key capability in offering management and recovery abilities within an RMM platform. Often the firing of a remote action can be directly substituted for the need for remoting into a given device, saving large amounts of time and streamlining helpdesk or IT support operations.
  ‍
• Software/Firmware/Configuration Distribution and Application: Another capability that is sometimes, but not always, offered as part of an RMM Agent is the ability to receive and execute updates for the target device. These updates could be for the business software, the firmware, or the configuration on the target device. Also, the ability of the RMM Agent to update itself can be an important consideration when evaluating an RMM platform. Key considerations for software distribution include the ability to schedule the updates, the ability to recover from failed updates, and the ability to operate over low or limited bandwidth for the distribution of such updates. Each of these capabilities are core to common IT management or connected device management workflows, and can significantly improve the capabilities of your RMM tool.  
  ‍
• Remote Screenshare: While an RMM Agent should allow you to remotely manage and recover your endpoints, sometimes there is no substitute for being able to do a remote access session with a device and poke around the device in real-time. Depending on your agent installation or deployment model, this may take the form of a remote desktop session on Windows, a reverse tunnel SSH session to Linux, or a native screen share application within your Android or iOS solution.
  ‍
• Extensible: Some RMM Agents do only what they do out of the box, but if that feature set doesn’t fit your needs, you should look for a platform that offers an extensible agent that you can customize and create specific actions for your connected product. Areas to consider include what options does the RMM Agent allow for deploying and managing extensions that your product team develops, or what local APIs does the RMM Agent have for communication of messages and/or execution of actions?

RMM Agent Operating Parameters

Since RMM Agents are typically deployed as an operating system native executable (i.e. does not require any additional software installations to run like Java, Python, etc.), you will want to make sure that the agent from your chosen platform has support for the OS your custom product is built on.

Ideally, the RMM Agent will support all current operating systems as well as future options that you may wish to pursue as part of your roadmap. For example, your connected product may currently run on a flavor of Microsoft-Windows, but you have plans for future versions of the product to run on Linux, or perhaps you are already running a mix of operating systems across your deployment or even within a single deployed location. It is important that the RMM Agent not only support your chosen operating system, but also maintains full feature and roadmap support for the operating system going forward.

Another key aspect of an RMM Agent is how much resources it utilizes on the endpoint to which it is deployed. An RMM Agent’s requirements for CPU and memory should never interfere with the primary business applications needs, and the agent should be capable of operating in deployments where those resources are scarce. Similarly, an RMM Agents need for bandwidth should be judicious and tunable for the connected products specification.

Finding the RMM Agent (and Platform) That’s Right for You

An RMM platform’s agent is a very important piece of the remote monitoring and management equation. While there may be other methods of gathering, reporting, and receiving information, the RMM Agent is typically the best choice for the job.

The feature set that the RMM Agent offers should cover your current and future needs or provide for simple extensibility to allow for product growth. Finally, the RMM Agent should fit within your operating parameters so that it does not interfere with your connected product’s primary function. It should be a quiet partner on the devices that better facilitates all of your remote monitoring and management needs.

If you’re interested in learning more about Canopy’s RMM agent (called Leaf), you can read more in this post on data collection from the edge or dive into this RMM agent FAQ document.

Finally, if you’re ready to see if our RMM software could be a potential fit for your business, we’d love to help. Let's talk.