The remote monitoring and management (RMM) process is slightly confusing because it takes the established term "monitoring" out of its usual context and uses it in a different way. Most administrators likely think instinctively of tools that monitor servers in the data center (e.g., Nagios or Prometheus). However, that's not what RMM is about; instead, it focuses on an organization's clients, monitoring them remotely with various metrics so that, if something goes wrong with a computer, the alarm bells sound for the admin in charge. Monitoring and, in particular, managing mobile clients require different tools and processes from monitoring static servers in a data center.

In this scenario RMM providers enter the play: RMM is basically remote monitoring by an agent component with the option of remotely initiating immediate actions on the client and, where needed, being able to help resolve a problem by sharing the desktop. It is a kind of TeamViewer on steroids, if you like, with a monitoring function as the icing on the cake.

Corporate client fleets are increasingly becoming heterogeneous and mobile, so RMM tools have often become a central element of system administration. Products are available from both the open source and commercial realms. The open source candidate is Tactical RMM [1]. The program promises high performance, low maintenance overhead, and a comprehensive feature set. It comes with agents for Windows, macOS, and Linux, covering practically all the popular common operating systems used in day-to-day business.

Paired with MeshCentral

Tactical RMM integrates seamlessly with MeshCentral [2], a web interface that supports extensive use of the tool's feature set. However, some administrators would rightly argue that a state-of-the-art RMM tool must enable web-based administration and that Tactical RMM would be pretty useless without MeshCentral. At the end of the day, most admins are likely to use both tools together in their everyday work.

The separation between Tactical RMM and MeshCentral has practical implications for those who want to install and use the product, because you have to install and configure both Tactical RMM and MeshCentral to enjoy the full Tactical RMM experience. I look at how this partnership works, discover what you need to watch out for, and point out the stumbling blocks on the way.

Implementation as a Virtual Instance

The authors of Tactical RMM offer comprehensive documentation for their tool, illustrating several routes to a successful install. The classic approach is still that of installing on a virtual instance with a shell script downloaded from the web. This process is remarkable, because the more typical way is to deploy any required services as Docker containers. Tactical RMM also supports Docker containers but states that the legacy approach with scripting and a VM is the only officially supported route.

To get started, you first need a virtual instance with as much disk space as possible, at least four CPU cores, and no less than 4GB of RAM. If your setup is not too large, you should be able to back up the environment's new data and the metrics data history for around a year on 500GB. Debian GNU/Linux 12 is strongly recommended as the technical underpinnings. If you prefer to work with Ubuntu, you can go for Ubuntu 22.04.

SSL and DNS Required

Before the installation can start, you have to meet a few requirements that mainly relate to the infrastructure Tactical RMM needs to work correctly. SSL, for example, is key during the setup process. The agents that run on the clients and need to talk to the mothership require encryption because they will be sending sensitive and often personal data subject to mandatory special protection as defined by the General Data Protection Regulation (GDPR) of the European Union. Transmitting this data across the network without encryption is unthinkable, which makes SSL more or less mandatory. This operation can only work if the server has a valid SSL certificate that the client can validate when the connection is established.

You have some very clear-cut homework. Tactical RMM cannot simply switch to a "real" certificate later if you specify the use of a self-signed certificate during installation. A valid SSL certificate for Tactical RMM must be in place from the outset of the setup process. Alternatively, Tactical RMM offers the option of automatically supplying valid certificates by Let's Encrypt, which is undoubtedly the cheapest option. For it to work, though, you need to prepare the domain in which Tactical RMM will be accessible.

More specifically, you need to make sure at least the api, mesh, and rmm host entries work for the respective domain. For example, assuming example.net is the domain name, api.example.net , mesh.example.net , and rmm.example.net need to point to the IP address on which Tactical RMM will be accessible. Incidentally, installing Tactical RMM on a virtual instance in a smaller office environment, which will typically reside behind a network address translation (NAT) router, is fine, but you do need to make sure you have a dynamic DNS (DDNS) entry with a sub-hosts option in place that points to the respective setup and has at least the three DNS entries referred to above. In this kind a setup, you also need to ensure that you pass HTTPS port 443 on the router to the local IP address on which Tactical RMM is running.