First-Run Walkthrough

This chapter takes you from your first login all the way to a managed device that is online, labelled, and has a policy applied. It assumes the server is already running (whether cloud or self-hosted).

Before you start, read Core Concepts if you have not already. Every step below uses terms introduced there.

Step 1 — Sign in

Open the Console in your browser. The login screen accepts either an username or email address and password, or a configured single-sign-on provider if your organisation has enabled SSO.

1. Enter your email in the Email field.
2. Enter your password in the Password field and sign in.
3. If your account has two-factor authentication enabled, enter the current code from your authenticator app on the next screen.
4. If your organisation uses SSO, click the SSO button on the login page instead and complete the provider's flow.

You land on /account/home, a small personal dashboard showing your profile information, navigation order menu and email signature configuration for the ticketing system.

Note: If you are the very first user on a self-hosted deployment, the initial administrator credentials were set during server installation. Default username is: "admin" and default password is "admin".

Step 2 — Complete the Setup Wizard

The first time an administrator visits the Dashboard page, the Setup Wizard opens automatically. It walks you through the minimum configuration needed to get the product useful:

1. Create a tenant (if none exists yet).
2. Create a location under that tenant.
3. Create a group under that location.
4. Optionally generate an agent installer for one of your supported platforms.

If you dismiss the wizard, the same steps are available manually from the Tenants menu and the Agent Download dialog. The wizard is simply a faster path.

Tip: Name your first tenant deliberately. It is common to use the company or customer name. You can rename it later, but external integrations (for example reports emailed to stakeholders) use the name you set here.

Step 3 — Create a tenant, location, and group

If you skipped the wizard, do this manually:

1. In the left-hand navigation, open Tenants.
2. On the Manage Tenants page, click the add button and fill in the tenant name and basic details. Save.
3. Select the new tenant in the list to enter its detail view. The Console stores the selection so subsequent screens act on this tenant.
4. Open Location Settings and add a location — typically a physical site ("Berlin HQ", "Remote Workers").
5. Inside the location, add one or more groups. Groups should reflect how devices will be configured; a good starter set is Workstations, Laptops, and Servers.

See Chapter 4 for the full reference on the tenant page and its dialogs.

Step 4 — Generate an agent installer

With a target group in place, you can generate an installer that pre-configures the agent to register into that specific tenant, location, and group. NetLock RMM ships the agent as a single self-contained executable per platform and architecture, with the server configuration embedded at build time.

1. Open the Agent Download dialog from the Setup Wizard or from the Devices page.
2. The dialog runs as a five-step wizard. Step through:
   1. Configuration name — a label for this installer build.
   2. Deployment method — select the target tenant, location, and group.
   3. Target server — select the communication, remote, update, trust, file, and relay servers this agent will talk to.
   4. Authorization — choose whether the agent is pre-authorized or registers as unauthorized pending admin approval.
   5. Platform and architecture — choose one of win-x64, win-arm64, linux-x64, linux-arm64, osx-x64, osx-arm64. Also choose Standard Installer (console, silent-capable) or GUI Installer (graphical, with customisable window title, welcome message, and button labels).
3. Click the build action. The Console packages a binary with the embedded config into a .zip and returns a download link.
4. Optionally download an accompanying install script — Install-NetLockAgent.ps1 for Windows, Install-NetLockAgent.sh for Linux or macOS — that automates the download, extract, and run steps.

Warning: Treat agent installers like secrets. The server configuration is embedded inside the binary, so anyone with the installer can register a new device into the configured group, depending on your configuration settings. You can also set a installer to auto authorize until a certain date and all installations originating from the specific installer will first land under unauthorized devices.

Step 5 — Install the agent on a device

On the target device, copy the .zip, extract it, and run the binary with administrator or root privileges.

Windows (PowerShell, elevated):

Expand-Archive .\NetLockAgent.zip -DestinationPath .\NetLockAgent
.\NetLockAgent\NetLock_RMM_Agent_Installer.exe

For silent, unattended deployment via GPO, Intune, or Ansible, add flags:

.\NetLock_RMM_Agent_Installer.exe --hidden --no-log

• --hidden / -h — hide the console window (Windows only).
• --no-log / --nolog — delete installer logs after completion.
• --temp <path> / -t <path> — use a custom temporary directory.

Linux / macOS (Bash, with sudo):

unzip NetLockAgent.zip -d NetLockAgent
chmod +x NetLockAgent/NetLock_RMM_Agent_Installer
sudo ./NetLockAgent/NetLock_RMM_Agent_Installer

With no arguments the installer uses its embedded config. For manual re-configuration or repair, the installer also accepts positional modes: clean "<path-to-server_config.json>" for a fresh install with an external config, fix "<path>" to repair while preserving the existing server config, and uninstall to remove the agent.

The installer registers the agent as a background service (Windows service, systemd on Linux, LaunchDaemon on macOS) and starts it. Within a minute or two the agent contacts the server.

Note: NetLock RMM does not ship native .msi, .deb, .rpm, or .pkg packages; a single binary is used across all distributions.

Back in the Console, the device does not appear in Devices yet — it appears in Unauthorized Devices instead, unless you chose pre-authorization in step 4's wizard. This is by design: an administrator must explicitly approve any agent that claims membership in a tenant, to prevent rogue or misconfigured agents from polluting your inventory.

Step 6 — Approve the unauthorized device

1. In the navigation, open Devices → Unauthorized Devices.
2. Locate the new entry. It shows the device's hostname, operating system, and the tenant / location / group the agent was configured for.
3. Select the entry and approve it. Optionally adjust the target group before approval if the agent was configured against the wrong one.
4. Give the new device a human-readable label using the Edit Label dialog — for example MARKETING-LAPTOP-01 becomes Anna's laptop.

The device now appears in the main Devices list and reports status in real time. See Chapter 3 for the full Devices reference.

Step 7 — Create a policy and route it with an automation

With the device authorised, give it a policy. This takes two pieces in NetLock RMM: the policy itself (what should be enforced), and an automation rule that routes the policy to the right devices.

7a — Create the policy

1. Open Policies from the navigation.
2. On Manage Policies, click Add. Enter a name and description — for example Starter Workstations. Save.
3. Click Manage on the new row to open Policy Settings.
4. The default settings enforce the agent configuration but do not yet configure Antivirus, Application Control, Patch Management, or any other opt-in feature. Feel free to set your first settings. On a later stage you can edit the policy again to activate specific sensors or jobs.
5. Save.

7b — Route the policy with an automation

1. Open Automations from the navigation.
2. Click Add. Fill in:
   • Name and Description.
   • Condition — choose Group.
   • Expected result — enter the exact name of the group you created in step 3, for example Workstations.
   • Trigger (policy) — select Starter Workstations.
3. Save.

The server immediately re-evaluates every connected device against the new automation and pushes the matching policy. Within the agent's next poll interval the policy lands on the device.

Note: NetLock RMM evaluates automations in priority order and picks the first match. If you create multiple automations that could all match a device, order matters.

See Chapter 6 for the full Policies reference, Chapter 5 for the Automations reference, and Guide H.4 for a step-by-step walk-through.

Step 8 — Verify the policy arrived

Finally, confirm the pipeline worked:

1. Open Devices -> Authorized from the navigation.
2. The column called Policy indicates what policy is currently assigned to the device.

If the expected policy is not displayed there, check your automations order.

Or see Troubleshooting for deeper diagnostics.

What you have now

At the end of this walkthrough you have:

• A tenant with one location and at least one group.
• One managed device, labelled and approved.
• A policy attached to the group.

That is the smallest meaningful deployment of NetLock RMM. Everything else — automations, patch management, scripts, reporting — layers on top of this foundation. The next chapter, Navigating the Console, describes the UI you will spend the rest of your time in.