Remote Monitoring

Click the Monitoring tab within the console sidebar > Monitors > Choose the existing template of checks and actions from the list 

Next you will be moved into the Evaluation workflow canvas.

This canvas is familiar to Automated Workflows drag-and-drop canvas. The set of actions on the right sidebar is the same as for Security Posture workflows.

Detection: Initial step in a chain. The primary function of this step is to assess if a specific check or action is necessary based on predetermined requirements.

Example :

Determine if the device is Windows Server. RMM system will proceed with executing or scheduling further checks only for non-server devices.

Subsequent Checks: Once a detection confirms the compliance with predefined parameters, the system initiates further checks.

Example 1:

Use CPU Usage Action to monitor the CPU Usage of a system and generate alerts based on the detected severity levels.

Use the action's properties to set the severity levels (Low, Medium, High, Critical), e.g.:

• Low: CPU usage is between 0% to 20%.
• Medium: CPU usage is between 21% to 50%.
• High: CPU usage is between 51% to 90%.
• Critical: CPU usage is above 90%.

Based on the set severity in the action properties, the system will determine the threshold for each alert level.

Example 2:

Use Event Viewer Action to review recorded events associated to applications on your system. The default Application log examines records in the Windows Event Viewer.  Use the actions's properties to set the conditions, e.g.: if it identifies at least 10 events within the last 24 hours at a critical or error level, an alert will be triggered.

Scheduling the check

Each check is executed based on its triggering settings, which can be accessed and modified under the 'Settings' gear icon on the right.

Recurrence

• Interval: Set the time gap between consecutive checks. For example, if a check is set to recur every 24 hours, the system will perform that check once every day.
• Maintenance Window: Set a specific timeframe during which checks are allowed to occur without causing interruptions or conflicts with other system activities.
• Network Change: Set a check to be triggered when a change in the network is detected, such as a device connecting or disconnecting.
• Once: Set a check to be executed only a single time.
• User Logon: Set a check to be performed when a user logs into a system.
• Daily: Set a check to be executed daily at specified time

Schedule Settings

• Ignore Blackout Hours: Blackout hours refer to periods during which checks are not permitted due to predefined reasons (e.g., system maintenance). By choosing to ignore them, checks will proceed even during these restricted hours.
• Allow Later Start: This setting permits the check or action to start at a time later than initially scheduled, giving flexibility to the system administrator or user.

Please be aware of an existing limitation for the Detection - it is temporarily not configured for scheduling. Currently, it is designed to operate just once and does not support recurring activations.

RMM Settings

Go to Settings on the upper toolbar for more configurations:

• Description (optional, displayed in the overview)
• Icon (optional, displayed in the overview)
• Alert ID (a unique identifier of alert result recorded to the device inventory)

To create a customized monitoring check click '+Create' on the upper toolbar of Monitoring, set the Name (obligatory step) and Description (optional)

You will be moved to the same workflow canvas where you can configure your own set of checks and detection criteria. Drag and drop the necessary actions to the canvas.

Each action can be configured according to specific requirements via Properties, e.g. while checking Disk space health the severity of each level can be set.

If necessary, more actions can be added to the workflow, e.g. 'Send Email' action to notify user about open alert.

Check to trigger Alert

If required, add an On Open Alert or On Close Alert action to your workflow.

These actions allow you to trigger alerts when a specific condition is met or resolved.  Click on the selected action and define the condition that should trigger the alert.

Example

Monitoring a Windows Service (e.g., DCOM Server Process Launcher)

Add a Service Status action to monitor the status of a Windows service and define the conditions as follows:

• If the service status is Running, Start Pending, or Continue Pending, → Connect these to the On Close Alert action. This means the alert will be closed when the service is healthy or starting normally.
• If the service status is Stopped, Paused, Missing, or Stop Pending, → Connect these to the On Open Alert action. This means the alert will be opened when the service is in a problematic or non-operational state.

To achieve the Restart Service if stopped functionality, add a Start Service action to the Open Alert workflow:

• Click On Open Alert tab
• Enable Advanced Action by clicking on Setting gar on the upper right corner.
• Drag the Start Service action into the canvas.
• Click 'Save'

Such action is useful to ensure essential services are always running.

 Windows systems are underpinned by Windows Services - these services provide crucial functions to users, machines and applications network-wide. The Windows Services Check monitors the selected Windows Services and fails where a service is in the stopped state. During the installation process the Agent queries the device for any Windows Services that are set to start automatically, it then compares any discovered services with the services.ini file and where a match is found a Check is automatically added for the service(s). Additional Windows Service Checks can be added manually either in the Agent (during and post-installation) as well as from the Dashboard (post-installation).

Select default or created RMM package from the list and click 'Publish Policy'

From the settings pop-up window, choose the desired target device.

Options include targeting Sites, Queries, Device Groups, Active Directories or individual devices.

After publishing a policy, it becomes accessible for review.

Within the Policies overview section, users can observe all targeted devices alongside the status of each conducted check.

• If a check results in an alert, this will be marked in a color depending on alert severity.
• By hovering over the respective icon, the name of the check becomes visible.
• By clicking on an alert icon, the detailed information on all opened alerts for this device will be listed below, under Checks tab.
• More information tab allows you to overview details of each check (e.g. Free Disk Space - detailed information on free and used space on the disk, Application log - list of logged events, etc.)
• Date/Time - shows the last check date and time.

 The 'Refresh' button on the top toolbar updates the chart with the latest results. 

 The last check time and data within the Policy are refreshed only in case of change in the Alert status—specifically, when an alert is opened or closed.

Example: If you check CPU Usage and it reaches 90%, an Alert is triggered. This information is recorded in the Policy, along with the time it occurred. These data points will not be updated until CPU Usage falls below 90%, and the alert is closed. During this entire time, the device may have CPU Usage fluctuating between 90% and 99%, but the Policy will continue to show 90%.

The Outage tab provides the history of alerts on the device: their status, date and reason.

The same information is also displayed on a dashboard in the Overview.

Open Alerts are also available for review under Device inventory (View Inventory-Health-Alerting)