When most MSPs inherit a client environment it is not a clean slate. You get a spreadsheet maybe, a Visio diagram from three years ago, and a promise that “yes, we know what’s on the network.” Then you start scanning and find the printer running on an unpatched firmware that hasn’t been touched since 2019, the rogue switch someone plugged in during a renovation, and four servers that IT forgot to decommission.
That’s not a client’s problem. That’s an asset visibility problem. And it happens because the tools most organizations rely on only show you what they already know about.
Agentless discovery is how you close that gap. In Part 3 of the Lansweeper MSP Masterclass, Thomas Van Havere walks through exactly how to configure it from setting up credentials, to creating scan actions, to pulling in Active Directory in a separate, cleanly scheduled scan. This post breaks down every step, flags the decisions that matter, and explains the thinking behind each one.
Before touching the configuration, it’s worth understanding what’s actually happening under the hood. Lansweeper’s agentless discovery works through the sensor. It is the on-premise component that reaches out to devices and collects information.
That sensor can discover assets in two modes:
1. Credential-Free Device Recognition (CDR)
This is pure passive-to-active discovery with no authentication required. You point Lansweeper at an IP range, and it scans every address in that range for publicly available information (i.e. open ports, broadcast data, whatever the device exposes without credentials). CDR surfaces the shape of the network: what’s there, where it is, what type of device it appears to be. It won’t give you software inventory or configuration depth, but it gives you coverage, and coverage is the foundation upon what everything else is built.
2. Credential-Based Scanning
This is where discovery goes deep. Using the same IP range targets, Lansweeper authenticates against devices (Windows via WMI, network devices via SNMP, VMware via vCenter or ESXi API) and pulls in-depth asset data: installed software, patch levels, hardware specs, configuration details, user assignments. This is the data that makes patching, compliance, and incident response actually work.
Thomas makes this call-out explicitly in the video, and it’s the right order of operations: configure credentials before creating actions. Actions reference credentials. If you build the scan before the credential exists, you’ll have to go back anyway.
To create a credential, navigate to your client’s Lansweeper site and find the credentials section. Click Create Credential in the top right corner.
What to fill in:
On credential security: Credentials entered in Lansweeper are never stored in the Lansweeper cloud. They stay on the hub: the on-premise component installed at the client site. The cloud platform orchestrates the scan, and the credentials never leave the customer’s infrastructure.
For MSPs managing multiple clients, this matters both technically and commercially. You’re not centralizing client credentials in a third-party cloud. Each client’s credentials stay within their own environment.
With credentials in place, the next step is creating actions: the scan definitions that tell Lansweeper what to scan, when to scan it, which sensor to use, and which credentials to try.
Navigate to Discovery → Actions and click Create Action.
You’ll see options for agentless, agent-based, and cloud actions. For this video’s focus, on-premise network discovery, select Agentless. Agent-based and cloud discovery are covered in separate Masterclass episodes.
Give the action a name that reflects its scope. In the video, Thomas uses “Contoso” for an IP range action. In practice, naming by network segment or function (“Contoso – Server VLAN”, “Contoso – Endpoint Range”) makes your action list readable as the client environment grows.
There’s also an option to enable AI usage tracking. Currently in beta, it will be worth turning on when it’s generally available. It will add a layer of software intelligence to your discovery data.
This is where you tell Lansweeper which IP addresses to scan. Lansweeper accepts multiple notation formats:
You can mix formats within a single action and add multiple ranges. The practical advice from the video: don’t put your entire environment into one action. Create separate actions for different network segments. It keeps scheduling cleaner, makes troubleshooting faster, and means you can adjust scan frequency per segment independently.
Exclusions: You can exclude specific IPs or ranges from any action: devices you don’t have authorization to scan, infrastructure in a shared tenancy, or systems that should be handled separately. You can add exclusions during setup or come back and edit them later.
Triggers determine when scans run. The right trigger depends on what you’re scanning:
Thomas sets a daily trigger at 6:00 am for the lab environment. For client environments, match the trigger cadence to the client’s SLA for asset data freshness.
Select the sensor that will execute this scan. In small client environments, there’s typically one sensor. In larger, distributed environments, you’ll select the sensor closest (network-wise) to the target range. Scanning across WAN links adds latency and can trigger security alerts on some networks.
This is where the credential work from Step 1 pays off. You’ll see all the credentials you’ve created and can select which ones apply to this action’s target range.
In the video, Thomas assigns four credentials to a mixed environment: SNMP v3, vCenter, Windows domain, and ESXi. Lansweeper will try each applicable credential against each device it finds.
Credential prioritization: You can reorder credentials to control which Lansweeper tries first. Once it finds a working credential for a specific device, it remembers and uses that credential directly for subsequent scans without trying the others. This makes scans progressively faster and more efficient as Lansweeper learns the environment.
A practical note for MSPs: You don’t need a credential for every device in the range. CDR will still identify devices that don’t match any credential; they’ll just have less depth. You get complete coverage; credential-matched devices get full data. If full coverage is required, check the credentials and add additional ones to get the in-depth information of the assets.
Thomas makes a strong recommendation in the video: create a dedicated action for Active Directory scanning, separate from your IP range actions.
The reason is operational. AD scanning has a different cadence from IP scanning, different credentials, and different data output – user objects, computer objects, group memberships, and organizational units. Keeping it in its own action means you can schedule it independently, troubleshoot in isolation if something breaks, and read your action list without having to decode what’s in scope for each entry.
Creating an AD action follows the same flow as an IP action, with one difference in the target definition step: instead of IP ranges, you select Active Directory as the target type and fill in your domain details (the AD server IP and the domain name).
Select both Computers and Users if you want the full picture. Assign the domain scanning credential (a read-only domain account is sufficient – Lansweeper doesn’t need write access). Set a trigger and save.
One extra option on the review screen: a checkbox to scan immediately rather than waiting for the first scheduled trigger. In the video, Thomas checks this and the scan starts the moment the action is saved.
Start Here
Start with Part 1 to understand the MSP architecture and multi-site management model before diving into installation.
Once actions are running, Lansweeper goes to work. CDR identifies everything visible on the network. Credential scans go deeper on authenticated devices. AD scanning pulls computer and user objects. The data starts populating. In the next Masterclass episode, Thomas will show what that populated environment actually looks like: the dashboard, the asset views, and what you can do with the data once it’s there.
The configuration covered in this video is essentially a repeatable template. Once you’ve done it once, the flow is the same for every new client:
The variations are in the specifics – credential types, IP ranges, trigger schedules – not the structure. That repeatability is what makes Lansweeper viable as a managed service foundation at scale.
Agents have a place. But deploying and maintaining agents across every client’s environment at scale multiplies your operational burden (rollouts, updates, compatibility issues, removal when clients churn). For MSPs, this type of overhead compounds.
Agentless discovery inverts the model. The scan infrastructure is centralized: one sensor per client site, managed through one multi-site portal, with no endpoint agent to maintain. No client-side software to update. And because Lansweeper’s CDR technology doesn’t require credentials to identify devices, you get baseline visibility on day one – before you’ve negotiated credential access, before IT has formally handed over domain accounts, before any of the usual MSP onboarding friction has been resolved.
That’s not a nice-to-have. For MSPs, that’s the difference between starting an engagement knowing what you’re dealing with and spending the first three weeks trying to figure out what’s actually in the environment.
Coverage first. Depth follows. That’s the model.
Follow along with Thomas as he walks through every step live: MSP Masterclass Part 3 – Agentless Discovery →
Missed the earlier episodes?
Coming up next: Part 4 will show what a fully populated discovery environment looks like and how to start using the asset data that’s now flowing in.
Get in Touch
No generic demo. A real conversation about your business with people who understand what you’re building and want to help you grow it.
Blog
Explore the full platform, free for 14 days.
No credit card required.