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, and which sensors and jobs a device gets on top of that policy, based on a list of conditions:

IF all of these conditions hold for a device  THEN  assign policy <name>  and/or  add sensors and jobs

A condition compares one fact of the device: the device itself, its tenant, location or group, its internal IP address or domain, its platform, a device attribute such as the device name, the operating system or the label compared with an operator (equals, contains, starts with, wildcard pattern, regular expression), a service or an installed application of its inventory, or a custom field value. A rule has at least one condition, all of them have to hold, and any of them can be negated. Every rule has a priority number and an enabled switch.

There are no event triggers, no schedule triggers, no manual triggers, and no actions other than assigning a policy and adding sensors and jobs (see Chapter 5.6). Automations do not run scripts themselves, send notifications, create tickets, or chain steps. Their job is to route policies, sensors and jobs to devices.

When a device syncs, the server takes the enabled rules whose conditions all hold for the device, orders them by priority (the lower number wins), then by the number of conditions (more first), then by age (older first), and assigns the policy of the first one. If no rule matches, the device receives the default policy when one is marked on the Policies page; otherwise it has no policy. The dialog proposes a priority from the rule's most specific organisation condition (device 100, internal IP 200, domain 300, group 400, location 500, tenant 600, otherwise 700), so a rule for one device beats a rule for its group, which beats a rule for its tenant, unless you choose otherwise. Adding, editing, enabling, disabling, or deleting an automation forces the affected devices 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. The default policy is the one shortcut: marked on the Policies page, it covers every device that no automation reaches.

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.