Managing Devices

The Devices section is where most day-to-day RMM work happens. It covers the inventory of managed devices, the queue of agents waiting to be approved, device detail views with status and events, bulk operations such as reboot or shell commands, remote desktop sessions, and a world map showing where your devices are located geographically.

The section is exposed as a top-level menu group with three sub-pages:

All three pages respect the currently selected tenant, location, and group context from the header selector. See Navigating the Console for how the context works.

3.1 Device inventory, filters, and labels

The Devices page lists every authorized device for the selected tenant / location / group. Each row shows status, identifying information, and quick-action affordances.

Status indicators

Each device reports status in real time:

• Online — the agent is currently connected to the server.
• Online + Remote connected (pulsing) — the agent is currently connected to the server and has a remote connection established
• Offline — the agent has not checked in within the expected interval.

Status changes appear without a page refresh (the page uses the Console's real-time update channel). If status updates stop arriving, a page reload re-establishes the connection.

Filtering and searching

The Devices list offers two filter controls: a free-text search box and an online-only toggle.

The search box performs a case-insensitive contains match across 13 fields at once — enter any substring and rows where any of the following fields contains it remain visible:

• device name and label
• tenant, location, and group name
• agent version and last-access timestamp
• IP address, operating system, and domain
• antivirus solution and firewall status
• last active user

The online-only toggle, when enabled, restricts the list to devices whose status is currently Online + Remote connected. Combined with a search term, it narrows the list to online devices matching the search text.

Labels

Every device can carry a human-readable label. Rename it to something meaningful (Anna's laptop, Warehouse POS 3) using the Edit_Label dialog.

1. Select the device in the list.
2. Right click the label and open Edit_Label.
3. Enter the new label and save.

Tenant / location / group assignment

Every device belongs to exactly one group, in exactly one location, in exactly one tenant. To move a device between groups, use the group assignment affordance on the device. Moving a device may change which policy it receives, because policy assignment is driven by Automations that match on device attributes such as group name. Expect policy changes to land within the device's sync interval.

3.2 Unauthorized devices and the approval flow

An agent that successfully contacts the server but has not yet been approved appears in Unauthorized Devices, not in the main Devices list. This intermediate state prevents rogue or misconfigured agents from silently polluting your inventory.

The approval flow is:

1. The agent is installed on a device with configuration that targets a specific tenant / location / group.
2. The agent contacts the server and registers as unauthorized.
3. An administrator reviews the entry in /unauthorized_devices — confirm the hostname, operating system, and the target tenant / location / group are correct.
4. Adjust the target group if needed.
5. Approve the entry. The device is created in the authorized inventory and begins receiving policies and automations.
6. Optionally set a label immediately after approval using the Edit_Label dialog.

Rejecting an unauthorized device removes it from the queue; the agent will re-register on its next poll and reappear unless you block it at the network or agent level.

See the First-Run Walkthrough for a full end-to-end example, and Guide H.2 for a task-focused recipe.

3.3 Device detail view

Selecting a device in the list opens its detail view. The detail view pulls everything the Console knows about the device into one place:

• Identifying information — hostname, label, tenant / location / group assignment, operating system, last-seen timestamp, IP addresses reported by the agent.
• Status — current online / offline / error state, and the agent version.
• Custom fields — values for every custom field defined in Collections, editable per device.
• Events — recent operational events scoped to this device; a link into the full Events page is available.
• Policy — the single policy currently assigned to the device (or no_assigned_policy_found if no automation matched). See Chapter 5 — Automations for how assignment works.
• Actions — per-device operations: remote control, remote shell, file browser, registry editor, event log viewer, service manager, wake-on-LAN, uninstall application, SNMP tools, and the bulk affordances covered in 3.4 and 3.5.

The per-device actions are implemented as the dialog set below. Each dialog targets the currently selected device (or the set selected for bulk actions):

The exact availability of some dialogs depends on the device's operating system — for example the Registry Editor is Windows-only, and the Linux / macOS Service Editor applies only to Linux and macOS devices.

Editing custom fields on a device

1. Open the device detail view.
2. Scroll to the custom fields area.
3. Edit the value inline, or open the custom-field editor for richer types (for example a date picker).
4. Save. The new value is recorded and visible in reports and panels that reference the field.

Defining which custom fields exist happens at the Collections level; see Chapter 8 — Custom Fields.

Viewing per-device events

The detail view shows a tailored slice of the Events feed: only events concerning this device. This is usually where you go first to diagnose why an action did not land — a policy deployment that silently failed, a script that did not run, a sensor that went silent.

For the full events reference, see Chapter 12.

3.4 Bulk actions

Rather than operating on devices one at a time, the Devices page supports selecting many devices and issuing a single operation against all of them. Common bulk actions include:

• Bulk remote shell — execute a command on every selected device and collect the results.

The bulk remote shell flow uses two dialogs:

• Bulk Remote Shell — pick the command to run, confirm the target set, and launch.
• Bulk Remote Shell Results — display per-device results as they arrive, including stdout, stderr, and exit status.

Warning: Bulk actions run on every selected device without further per-device confirmation. Double-check the selection before you launch a bulk reboot on a production fleet.

Tip: For repeatable work, save the command as a script in Collections and invoke the script rather than typing the command every time.

3.5 Remote control and remote shell

Individual devices support remote access via the Console:

• Remote shell — an fire and forget shell session on the device (PowerShell on Windows, Bash or the default shell on Linux and macOS), opened from the Remote Shell dialog. Command history for the device is available from the Shell History dialog.
• Real-Time Remote shell — an interactive shell session on the device (PowerShell on Windows, Bash or the default shell on Linux and macOS), opened from the Remote Shell dialog. Command history for the device is available from the Shell History dialog.
• Remote control — a graphical remote-control session to the device's desktop, opened from the Remote Control window.

How remote control works

NetLock RMM does not use VNC or RDP for remote control. Instead it streams the device's screen over its own protocol using one of two video encodings:

• H.264 — hardware-accelerated on the device's GPU when available, with a CPU software encoder as fallback. H.264 is the default when the agent and relay can negotiate it.
• JPEG polling — used when H.264 is not available (for example when the H.264 slot on the relay is already in use), and also the mode used by the legacy transport.

The Remote Control window exposes a connection-mode dropdown with two options:

• Relay (Recommended - faster) — the session is routed through a dedicated Relay Endpoint that sits between the Console and the agent. This is the fast, modern path and is always preferred when the relay is configured.
• SignalR (Legacy - fallback) — the session is routed through the Console's own SignalR hub on the main server. This path is slower and always uses JPEG polling.

Selection is explicit: you pick the mode before starting the session. The Relay path auto-falls-back to JPEG if the relay's single H.264 slot is already occupied, and to SignalR + JPEG if the relay cannot be reached at all.

See Chapter 9 — Relay Server for how to deploy and manage the Relay App, and A.7 Remote screen control for authentication and default-settings reference.

3.6 The Device World Map

The Device_World_Map page at /device-world-map visualises your fleet geographically. Each device is plotted on a world map based on IP-geolocation data captured when it reports to the server.

Use cases include:

• Confirming a device claims to be where you expect it to be (an unexpected pin in another country is a useful signal).
• Assessing the impact of a regional issue — for example, how many devices are on a specific coast during a power event.
• Communicating fleet spread to non-technical stakeholders in a single screenshot.

The map respects your tenant / location / group context: selecting a tenant in the header narrows the map to that tenant's devices only.

Note: Map accuracy depends entirely on the quality of IP geolocation for the device's external IP. Devices behind a VPN will appear at the VPN exit rather than the physical device location. The IP lookup happens locally on your NetLock RMM server. IP lookups are never communicated to the outside world.

Permissions

Device-related permissions follow the standard pattern:

• A top-level permission enables the Devices section.
• Per-action permissions gate bulk actions, remote shell, remote desktop, approvals, and label editing.
• Tenant-scoped users only see devices in tenants they have access to.

See the Permission reference for the full list.

Related chapters

• Chapter 4 — Tenants, Locations & Groups — the hierarchy devices live in.
• Chapter 6 — Policies — how policies flow to devices.
• Chapter 8 — Collections — scripts, sensors, and custom fields that extend what a device exposes.
• Chapter 9 — File Server & Monitoring — relay-mediated remote access.
• Chapter 12 — Events & Audit — per-device event and audit records.