Agentless discovery is fast, powerful, and requires no footprint on the devices it finds. For servers, network devices, switches, printers, and anything else that lives permanently on the network, it’s the right tool. Scan a range, authenticate with credentials, pull in-depth data. Done. But there’s a category of devices agentless scanning simply cannot reach: the endpoint that isn’t on the network when the scan runs. The sales rep’s laptop, powered off at home. The remote developer’s workstation, connected to a coffee shop Wi-Fi. The contractor device that connects to VPN twice a week. The executive’s machine that’s always “somewhere” but rarely on the corporate network at 6:00 AM, when the scan trigger fires.
These are the devices that tend to run the most sensitive data, accumulate the longest patch backlogs, and surface in breach reports. And network scanners miss them almost by definition – if the device isn’t on the network at scan time, there’s nothing to find.
That’s what the Lansweeper IT Agent solves. In Part 4 of the MSP Masterclass series, Thomas Van Havere walks through three ways to deploy it – from a direct click-through wizard install, to a PowerShell deployment script built for automation – and then shows how to manage agents at scale through groups and custom actions. This post breaks down every step.
Agent vs. Agentless: The Right Tool for the Right Device
Before getting into deployment, it’s worth being clear about what the Lansweeper IT Agent is and isn’t.
The agent is a lightweight software component that sits on an endpoint and reports asset data back to the Lansweeper platform on a configurable schedule – without depending on the device being reachable from the network at any particular moment. When the device comes online, the agent syncs. Whether that’s on-site, on VPN, or on a hotel Wi-Fi, the data flows.
This makes agents the right choice for:
- Remote and hybrid workers whose devices are rarely on the corporate network during scan windows,
- Laptops and portable endpoints that move between locations and networks,
- Devices that need frequent, high-fidelity data – software inventory, patch status, configuration details – without waiting for the next network scan cycle,
- Environments where WMI or SNMP authentication is difficult to maintain centrally.
Agentless scanning, by contrast, remains the right approach for infrastructure that’s permanently on the network: servers, network devices, virtual machines, printers, IoT, OT. No agent needed on a switch.
In a well-configured MSP environment, both run in parallel. Agentless covers the infrastructure. Agents cover the endpoints. Together they close the visibility gap.
Start Here
New to the series?
Start with Part 1 to understand the MSP architecture and multi-site management model before diving into installation.
Three Ways to Deploy the Lansweeper IT Agent
Thomas covers three deployment methods in the video, ranging from a manual click-through install to a fully automated scripted deployment. Most MSPs will use a combination depending on the client environment and their own tooling.
All three start in the same place: Discovery → Systems → Download and Install Packages → IT Agent Discovery.
Method 1: Direct Wizard Installation
The simplest path. Download the EXE, double-click it, and follow the prompts. This is the right approach for one-off installs, lab testing, and any situation where you’re standing in front of – or remoted into – a single device.
The one thing you need before you run the installer: a linking code.
The linking code is how the installed agent authenticates back to your specific Lansweeper site. Without it, the agent has nowhere to register. Generate it before starting the install so it’s ready to paste when the installer asks.
To generate the code: in your Lansweeper Discovery site, go to Systems → Link Discovery System → Create New Linking Code. Set an expiration date that covers your deployment duration – Thomas recommends at least a year for most deployments. Copy the code immediately and store it somewhere secure.
Critical detail: Lansweeper only supports one active linking code per site at a time. Generating a new code invalidates the old one. If you have agents already deployed using an existing code, generate a new code carefully and update deployments before the old code expires – not after.
With the code in hand, run the installer: accept the EULA, choose your installation directory (default is fine unless your client has specific drive policies), paste the linking code when prompted, and finish. The installer completes in under a minute and immediately opens the Lansweeper site to confirm the agent is registered.
Back in Discovery → Systems, refresh the page and the newly installed agent appears in the list – named after the device hostname. You’ll also see it flagged in the Reconciliation tab whenever that device appears in inventory, clearly identified as discovered by an agent.
Method 2: Silent Installation (MSI/Configuration File /Parameters)
For environments where you need to push the agent without user interaction – via Group Policy, SCCM, Intune, or any other software deployment tool – Lansweeper supports several silent install options:
- MSI installer – standard Windows installer format, works with any deployment tool that handles MSI packages
- Configuration file – pre-define the linking code and install parameters in a config file; the installer reads it and runs silently
- Command-line parameters – pass the linking code and configuration directly as install arguments
The Lansweeper documentation (accessible from the IT Agent download page via View How-Tos) covers the exact syntax for each approach. For MSPs with an RMM or MDM already in the stack, silent deployment parameters are typically the fastest integration path – the agent becomes another package in your existing deployment pipeline.
Method 3: PowerShell Deployment Script
This is the method Thomas demonstrates in detail in the video, and for good reason – it’s the most flexible for MSP use.
The script is available directly from the Lansweeper download page: copy it with one click, paste it into a .ps1 file, and there’s exactly one change to make: replace the placeholder with your linking code (the same code you generated for the wizard install).
What the script does, step by step:
- Downloads the latest Lansweeper agent installer directly from Lansweeper’s servers – meaning it always gets the current version, no stale packages to manage
- Creates a temporary working directory
- Runs the installer silently in the background using the linking code you provided
- Cleans up after itself – deletes the temporary files and downloaded installer once installation is complete
Run it in an elevated PowerShell prompt (right-click → Run as Administrator, or execute via your RMM with admin context). The output log in the terminal confirms each step as it completes. The final line – “IT Agent Discovery installation successfully completed” – is your confirmation. Refresh the Lansweeper Systems page and the new agent registers within seconds.
Why this matters for MSPs at scale: The script approach is RMM-native. Paste it into your remote monitoring and management tool as a script job, populate the linking code variable, and you can push the Lansweeper agent to every Windows device in a client environment without touching a single machine manually. Combined with a platform-specific version for Linux and macOS (both supported, with the same wizard and script options documented in the how-tos), you can cover an entire mixed-OS client environment from a single deployment workflow.
Configuring Agent Behaviour: Actions and Groups
Deploying the agent gets it onto devices. Actions and groups control what it does once it’s there – specifically, how often it scans and how you organise agents across large client environments.
Default Agent Action
Every Lansweeper agent, once deployed, automatically registers under the Default Agent Actions group. This is your baseline – agents run on the default scan schedule until you configure something more specific. You can find this under the Actions section, where you can modify the trigger (scan frequency), rename the action, or reassign agents to different groups.
Creating Custom Agent Actions
For client environments with different endpoint types, security zones, or reporting requirements, custom agent actions let you apply different scan schedules to different device populations.
To create one: Actions → Create Action → Agent-Based. Give it a name (Thomas uses “Windows Agents” in the video), define a trigger (recurring every four hours, daily, or whatever cadence matches the client’s data freshness requirements), and assign the groups whose agents should run on this schedule.
This is particularly useful when you have:
- High-priority endpoints (executive devices, finance workstations) that need more frequent scanning
- Remote workers whose devices should be scanned whenever they connect, rather than on a fixed schedule
- Compliance-driven clients that need to demonstrate frequent asset data updates as part of their audit posture
Creating Agent Groups
Groups are how you organise agents within a client site. Lansweeper provides a default agent group out of the box, but you can create custom groups – for example, a “Windows Agents” group that contains all Windows endpoints, separate from macOS or Linux devices – and configure update schedules per group.
To create a group: navigate to the Groups section, select IT Agent Group as the type, name it, set an update schedule (Thomas sets Monday weekly in the demo), and assign the agents that belong to it. That group can then be targeted by custom actions, giving you precise control over which devices get scanned, how often, and when.
The practical value for MSPs: Groups map naturally to client reporting structures and service tiers. A client paying for enhanced endpoint monitoring gets a group scanned every four hours. A client on a standard tier gets daily scans. The configuration is per-site, per-group, and fully adjustable – no changes needed at the platform level.
What Shows Up After Deployment
Once agents are deployed and running, the data they collect appears in the same inventory and dashboard views as agentless-discovered assets – the source (agent vs. network scan) is flagged in the Reconciliation tab for each asset, but the data itself flows into a unified view.
This means your client’s dashboards reflect the complete picture: infrastructure discovered agentlessly, endpoints discovered by an agent, cloud assets discovered through cloud connectors. Different discovery methods. One authoritative inventory. No separate portals or data reconciliation to manage.
The Scale Argument for MSPs
The reason Thomas spends time on the PowerShell script and group configuration – rather than just showing the click-through wizard and moving on – is that manual installs don’t scale. If you’re managing 20 client environments, each with hundreds of endpoints, clicking through an installer on every device is not a service model. It’s a full-time job.
The deployment patterns covered in this video are designed for a different operating model:
- Script once, deploy via RMM everywhere. The PowerShell script is parameterized. Change the linking code, run it across your RMM’s device list, and every endpoint in a client environment gets the agent in a single job.
- Groups and actions give you per-client customization without per-device management. Configure once at the group level; every agent in the group inherits the behaviour.
- Agents self-report. Once installed, you don’t need to initiate scans manually. The agent runs on schedule, syncs when online, and updates the inventory automatically.
That’s the operational model that makes agent-based discovery viable as a managed service component at scale – not as a one-time onboarding task, but as a continuous, low-maintenance source of endpoint intelligence across your entire client base.
What Comes Next
With both agentless and agent-based discovery configured, a client environment’s asset data is now flowing in from multiple sources – network scans, Active Directory, and direct agent reporting from endpoints. In the next Masterclass episode, Thomas will show what that fully populated environment looks like: the dashboard, asset views, and how to start deriving actionable intelligence from the data you’ve been collecting.
Get in Touch
Book a call with the Lansweeper MSP team
No generic demo. A real conversation about your business with people who understand what you’re building and want to help you grow it.
