Feature Matrix

This appendix is a single-page index of what NetLock RMM does. It groups every feature into Console, server, and agent areas, records platform support where it varies, and links to the chapter that documents the feature in full. Use it to answer "does the product do X, and where do I read about it?" — not as a configuration reference. For mechanics, follow the cross-links.

Three conventions apply throughout:

• Yes / No in a platform column means the feature is or is not available on that operating system.
• A dash (—) means the feature does not apply to that platform.
• Where a column names a tool or shell instead of Yes (for example PowerShell), that is the platform-specific implementation.

Note: This matrix summarises shipped behaviour. When a feature area carries deployment-specific or licensing-specific limits, the linked chapter is authoritative.

X.7.1 Console features

The web Console is the single operator surface. The features below are available regardless of agent platform; they are properties of the Console itself.

Optional module: The Ticket System applies only when it is enabled in Settings → Ticket System. See Chapter 10.

The AI features are optional. They run either on the managed NetLock AI reached through the Members Portal, or on an OpenAI-compatible provider the deployment configures and hosts itself — the choice is made under Settings → AI / LLM (see A.11.2). Two kinds exist: the general-purpose AI Chat page, and targeted per-feature assistants. The targeted integrations are the AI Assistant in the Scripts editor (which writes directly into a script), the AI Assistant on the Automations dialogs, the AI SQL Assistant in the Widget Editor, and the Analyze with AI action on event and audit details (which opens AI Chat with the entry pre-filled). See Chapter 13.

A separate, optional Customer AI feature extends AI to end users: when enabled in the tray-icon policy, staff open an AI chat directly from the agent's tray icon. Conversations are end-to-end encrypted on the device — the server stores only ciphertext and operators never see message content. Accounts self-register and are activated by an operator (or auto-activated per tenant), and usage is bounded by per-user and per-tenant monthly token limits. Operators manage these accounts from the Customer AI dialog on the Tenants pages, gated by the enduser_ai_accounts permission. See Chapter 13.6.

Whitelabeling options

Whitelabeling is broad enough to list separately. Each option below is configured under Settings → Whitelabeling and documented in A.6.

X.7.2 Server features

The server is the central service the Console reads from and agents report to. Self-hosted operators run it themselves; cloud operators do not.

Self-hosted only: Server architecture and role splitting apply to self-hosted deployments. Cloud deployments delegate server operation to the hosted operations team.

X.7.3 Device management and remote access

These features act on managed devices through the agent. Platform columns record where each is available.

Remote Screen Control streams the device's screen as JPEG frames from the agent through the NetLock server to the viewer — the web Console or the Relay App. The picture is tuned per session with a stream mode: Quality (4:4:4 colour, native resolution, up to 20 fps), Balanced (the default, up to 30 fps), Performance (up to 60 fps), Auto (adapts to the connection) and Custom; a statistics overlay shows frame rate, bandwidth, latency and the capture method in use. The product does not use VNC or RDP. Full detail, including session switching, recording, and unattended access, is in Chapter 3 and A.7; the modes are described in A.7.5. On Linux a mode sets the frame-rate cap and the resolution ceiling only. Linux support is experimental and runs on the device's Wayland session; its prerequisites, the desktop support matrix, and how unattended access works on Wayland are covered in X.8.5.

The Relay Server provides end-to-end-encrypted TCP tunnels and jump-host access for network devices without an agent. See Chapter 9.

X.7.4 Security and control

Antivirus management covers Microsoft Defender only; third-party antivirus products are not managed. Application Control and Device Control are library features under Collections — see Chapter 8.6 and Chapter 8.7. A ruleset or whitelist reaches devices only through a policy; see Chapter 6.

X.7.5 Software and patching

The App Hub is a catalogue you pick from; installation runs through Software Deployment. See Chapter 8.5 and Chapter 8.8.

Patch Management is split across two surfaces. The /patch-management page is a global approval queue with a vulnerability view and SLA tracking; per-policy rollout rules — schedule, deployment rings, reboot, retry, notifications — live inside the policy editor. See Chapter 7 for the page and Chapter 6 for per-policy rollout.

X.7.6 Automation and monitoring

An automation is a conditions → policy and/or items rule, not a workflow engine: there are no event triggers, no schedules, and no actions other than assigning one policy and adding sensors and jobs from the library. Every rule has a priority; among the rules whose conditions all hold for a device, the one with the lowest number that assigns a policy decides the policy, and the sensors and jobs of every matching rule are added on top. Automations cannot run scripts themselves or send notifications. See Chapter 5 for the resolution model and Chapter 6 for what a policy contains.

Note: A device is assigned at most one policy at a time. Policies do not attach to tenants, locations, groups, or devices directly — attachment is routed exclusively through Automations.

Sensors not only alert but can run an action script on a threshold breach. Sensor and Job mechanics live in Chapter 8.2 and Chapter 8.3. Website uptime monitoring and the Port Scanner are documented in Chapter 9.

Tray icon

The agent exposes an optional tray application to end users on all three platforms. Its branding, button set, App Hub window labels, and AI Chat are configured per policy.

The tray AI Chat is optional and end-to-end encrypted: conversations are encrypted on the device and the server stores only ciphertext. It is enabled and fully labelled per policy and managed from the Console's Customer AI dialog; see Chapter 13.6.

See Chapter 6 for tray-icon policy settings.

X.7.7 Platform support

The supported operating systems and architectures — together with additional community-confirmed platforms and the Linux prerequisites for Remote Screen Control on Wayland — are documented on their own page: Platform Support.

Related chapters

• Chapter 3 — Devices — device inventory and remote access.
• Chapter 5 — Automations — policy routing.
• Chapter 6 — Policies — what a policy configures.
• Chapter 7 — Patch Management — the approval queue.
• Chapter 8 — Collections — the reusable libraries.
• Chapter 9 — File Server & Monitoring — relay, uptime, port scanning.
• X.5 — Integration endpoints — external systems the product talks to.
• X.8 — Platform Support — supported operating systems and Linux Remote Screen Control prerequisites.