Installing the probe and fixing problems

1. Create the probe in the portal

In Mail Monitor open Probes, give the probe a name (for example “Customer server – head office”) and press “Create and install”. The setup opens with three tabs: Windows, Linux and Docker. Each tab has the install line ready, with the token that links the probe to your account inside it.

The token is shown only at that moment. If you lose it, no problem: from the probe’s card you generate a new token, and the old one stops working immediately.

2. Windows

You need a Windows PC or server that is always on, inside the network to check. Download mmprobe.msi from the setup, open Command Prompt with “Run as administrator”, go to the file’s folder and paste the line. The same line works for deploying it from an RMM.

• The probe installs to C:\Program Files\MailMonitor and becomes the “Mail Monitor Probe” service, which starts on boot.
• Configuration, result queue and log (probe.log) live in C:\ProgramData\MailMonitor.
• To remove it: Settings → Installed apps → “Mail Monitor Probe” → Uninstall.

msiexec /i mmprobe.msi SERVER=https://mailmonitor.instanthelp.it TOKEN=<token>

3. Linux

Any 64-bit machine with systemd will do: Debian, Ubuntu, RHEL, Proxmox, even a Raspberry Pi (arm64). Paste the line in a terminal: it downloads the right probe for the architecture, configures it and starts it as the “mmprobe” service. Run again on an installed probe, it updates it.

• Configuration, queue and log live in /var/lib/mmprobe.
• Service status: systemctl status mmprobe.
• To remove it, the same line with --uninstall instead of server and token.

curl -fsSL https://mailmonitor.instanthelp.it/api/probe/install.sh | sudo sh -s -- --server https://mailmonitor.instanthelp.it --token <token>

4. Docker (NAS and servers)

On a Synology NAS (Container Manager), QNAP (Container Station), Proxmox or a server with Docker. The setup gives you a ready compose file, to paste as a “project” on the NAS. Two things matter:

• The container only sees the folders you mount. Mount them read-only (/volume1/backup:/backup:ro) and use the path inside the container in your checks (/backup/*.tar.gz).
• Keep restart: unless-stopped: the probe updates itself by writing the new version into its volume and restarting.
• Ping needs cap_add: [NET_RAW]. System service checks are not available inside a container.

5. Tell it what to check

When the probe connects, the setup shows it by itself. Create a service run by that probe and add the checks; “Test now” has the probe run them in a few seconds, even before you save.

• File: a path with wildcards (D:\Backup\*.vbk). ERROR if it is missing, older than N hours or smaller than N MB.
• Service: the Windows service name (not the display name) or the systemd unit. ERROR if it is not installed or not running.
• Process: the process name and how many must be running.
• Ping and HTTP/TCP: internal addresses too, which cannot be checked from the cloud.
• Script: your own script with the expected exit code and, if needed, rules on its output. See step 6.

6. Scripts are enabled on the machine only

Scripts start disabled. They can only be enabled on the probe’s machine, never from the portal: whoever has access to the portal cannot run programs on the customer’s computers unless the customer decided so. There are three modes: off, local only (files you put in the probe’s scripts folder) and also from the portal (admins write the script in the portal).

"C:\Program Files\MailMonitor\mmprobe.exe" scripts local      (Windows, administrator prompt)
sudo mmprobe scripts local                                       (Linux)
MMPROBE_SCRIPTS=local                                            (Docker, then recreate the container)

7. If the connection drops

The probe keeps running the checks on the schedule it already has, and keeps the results with the time they were measured. After three minutes without contact Mail Monitor sends you a single “probe offline” alert, not one per check. When it is back the probe delivers everything, the results replace the MISSING entries and you get a summary: the checks ran on time and were only delivered late. If the machine was switched off instead, those times stay MISSING.

8. Common problems

• The probe shows “never connected”: check that the service is running (services.msc on Windows, systemctl status mmprobe on Linux, docker ps on Docker) and that the machine can reach the server over HTTPS on port 443. Errors are in probe.log.
• The antivirus blocks or deletes it: some corporate antivirus products, Kaspersky for example, flag it by behaviour. Add C:\Program Files\MailMonitor\mmprobe.exe to the trusted applications and reinstall.
• A check on a network share (\\nas\backup) says the folder is unreachable: on Windows the probe runs as LocalSystem, which cannot see shares. In services.msc → “Mail Monitor Probe” → Properties → Log On, set an account with read access and restart the service.
• A file check in Docker finds nothing: the folder is not mounted in the container, or the check uses the NAS path instead of the one inside the container.
• A script ends in ERROR with “Script disattivati su questa sonda” (scripts disabled on this probe): the mode on the machine does not allow it. Change it as in step 6.
• A Windows service check says “not installed”: it needs the service name (for example VeeamBackupSvc), not the one shown in the list.
• I lost the token: from the probe’s card generate a new token and reinstall with the new line.

9. Updates

The probe updates itself, without rebooting the machine: automatic updates are on by default and can be turned off from the probe’s card, so you update when you choose. Every version is signed: the probe only installs packages carrying our signature, so not even someone who tampered with the server could make it run anything else.