Core Concepts

NetLock RMM is easier to learn if you read the vocabulary first. The product uses a small number of terms very consistently, and almost every chapter in Part II assumes you already understand the ones introduced here. Read this chapter end-to-end before jumping into feature documentation.

The agent, the server, and the Console

Three components form the system:

• The agent is a small piece of software installed on every device you want to manage. It reports status, runs jobs you schedule, enforces policies, and provides the endpoint for remote shells and file transfers. Once installed it talks to the server on a regular schedule.
• The server is the central component. It holds configuration, receives data from agents, runs the web Console, and mediates remote-access sessions. In cloud deployments the vendor runs it; in self-hosted deployments you run it.
• The Console is the browser-based user interface you spend your day in. It reads and writes configuration to the server; it does not talk to agents directly.

Every feature in this manual ultimately reduces to "the Console tells the server what should happen, and the agent makes it so".

Tenant, location, group

NetLock RMM organises managed devices into a three-level hierarchy. Every device belongs to exactly one group, which belongs to exactly one location, which belongs to exactly one tenant.

• A tenant is the top-level container. For an in-house IT team this usually maps to "the company". For an MSP it maps to one customer organisation.
• A location is a subdivision of a tenant, usually a physical site or office. A small tenant might have one location; a multi-site customer will have several.
• A group is a subdivision of a location. Groups typically reflect how devices should be configured rather than where they physically are — for example Servers, Workstations, Kiosks.

The hierarchy is primarily an organisational structure for devices and for scoping what users can see. Unlike some RMMs, you do not attach policies directly to a tenant, location, or group. Instead, policies are routed to devices by Automations, which match devices by attributes such as their tenant, location, or group name.

See Chapter 4 for the full reference on managing this hierarchy.

Tip: Group devices by how they should be configured, not just where they live. "Every laptop, regardless of site" is a better group than "every device in the Berlin office" if your policies differ primarily by device type.

Agents and devices

A device is a managed computer — a workstation, laptop, or server. When you install the agent on a new device, it contacts the server and registers itself as an unauthorized device: present on the network, but not yet accepted into a tenant. An administrator reviews unauthorized devices in Devices → Unauthorized, chooses the tenant, location, and group to assign them to, and approves them. From that moment the device is an authorized device and appears in the main device list.

Note: Agents that have never been approved are the most common source of "missing device" support tickets. The First-Run Walkthrough covers the approval flow in detail.

Devices also carry a label (a free-form human-readable name), custom fields defined at the Collections level, and any number of per-device settings. Chapter 3 is the canonical reference for everything device-related.

Policies

A policy is a named bundle of desired configuration for a device. Examples: "managed laptops — strict", "kiosk devices", "server baseline". A single policy can configure:

• General agent behaviour (sync interval, auto-update).
• Tray Icon branding and visibility.
• Windows Defender Antivirus — exclusions, scan jobs, notifications.
• Windows Application Control and USB Device Control rulesets.
• Linux UFW firewall.
• SNMP sensors to collect on devices.
• Scheduled Jobs to run on devices.
• Patch Management rollout rules, per platform (Windows, Linux, macOS, Docker).
• Which App Hub apps are exposed in the Tray Icon.

Policies are edited in the Policy Settings page and stored in the server database. The agent picks up changes on its next sync (5-1440 min, configurable per policy).

Important: NetLock RMM does not keep a policy version history and does not support rolling back to a previous policy state. Edits apply in place. If you need a safety net, clone a policy before making a risky change.

A device is assigned at most one policy at a time. Policies are not layered or merged.

Automations

An automation in NetLock RMM is narrower than the word implies in other products. It is a rule that decides which policy gets assigned to which device, based on a simple condition:

IF a device's <attribute> matches <expected value>  THEN  assign policy <name>

<attribute> is one of: Device Name, Tenant, Location, Group, Internal IP-Address, External IP-Address, Domain.

There are no event triggers, no schedule triggers, no manual triggers, and no actions other than assigning a policy. Automations do not run scripts, send notifications, create tickets, or chain steps. Their only job is to route policies to devices.

When a device syncs, the server evaluates all automations in priority order. The first rule whose condition matches the device determines the device's policy. If no rule matches, the device has no policy. Adding, editing, or deleting an automation forces every connected device to re-evaluate immediately.

The practical consequence: to give devices a policy, you need both a Policy and at least one Automation whose condition matches those devices. A policy on its own is inert.

For event-driven work — "run a script when a disk fills up", "open a ticket when a sensor breaches a threshold" — NetLock RMM uses Sensors (with action scripts) and Jobs (scheduled scripts), not Automations. See Chapter 8 — Collections.

Collections

Collections is the umbrella term for reusable building blocks you create once and reference from many places. Eight kinds of Collection item exist:

Collections items are cross-referenced: an automation may invoke a script, a policy may include an Application Control ruleset, a software deployment may use App Hub entries. Chapter 8 documents each in detail.

Permissions

NetLock RMM uses a role-based permissions model. Each user holds a set of permission flags that gate access to Console features. Flags come in three shapes:

• *_enabled — whether the user sees the feature at all (for example collections_enabled).
• *_add — whether the user can create new items in the feature.
• *_manage — whether the user can edit or delete existing items.

Permission flags control which items appear in the navigation menu on the left, which buttons are visible on a page. A user without dashboard_enabled will not see the Dashboard menu item; a user with collections_application_control_enabled but without collections_application_control_manage will see the Application Control page read-only.

Permission names appear throughout this manual in backticks, for example collections_application_control_manage. See Users & Roles for how to assemble permissions into roles, and the Permission reference appendix for a full list.

Real-time updates

Several parts of the Console update in real time using a persistent connection to the server. Device status, script and job execution results, and policy deployment notifications all flow in without a page refresh.

What to read next

• First-Run Walkthrough — apply these concepts to a fresh deployment.
• Navigating the Console — where each concept lives in the UI.
• Glossary — one-line definitions for quick lookup.