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.
Two Ways Lansweeper Discovers Assets and When to Use Each
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.
Step 1: Set Up Your Credentials First
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:
- Name: Make it descriptive and consistent. “Windows Domain Credential – Contoso” beats “Cred 1”. You’ll have multiple credentials per client in a mature deployment, and names are how you’ll tell them apart at 11 pm during an incident.
- Credential type: Lansweeper supports Windows (WMI), SNMP v1/v2/v3, vCenter, ESXi, SSH (for Linux), and more. The recommendation from the video: create one credential type per credential. Mixing types into a single credential is technically possible but creates ambiguity later.
- Login format for Windows: This is the detail that catches people. If you’re using a domain account, format it as domain\username. If it’s a local administrator account, prefix it with .\ – for example, .\localadmin. Lansweeper needs this to authenticate correctly against Windows WMI. Get this wrong and the scan will connect but fail to retrieve data.
- Password: Entered in the next step.
- Hub assignment: When prompted to choose which hub stores this credential, select the appropriate one. If the client has multiple hubs (larger environments with distributed sensors), you can push the credential to all relevant hubs in one step. No need to configure each hub separately.
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.
Step 2: Create Your Scan Actions
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.
Action type: Agentless
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.
Naming and description
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.
Define your targets
This is where you tell Lansweeper which IP addresses to scan. Lansweeper accepts multiple notation formats:
- IP ranges: 10.40.0.0 – 10.40.0.112
- CIDR notation: 10.40.17.0/24
- Individual IPs
- Hostnames
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.
Set a trigger
Triggers determine when scans run. The right trigger depends on what you’re scanning:
- Server ranges: Schedule at night. Servers are always on. Scanning after hours keeps scan traffic off the network during peak usage and doesn’t compete with production workloads.
- Endpoint ranges: Schedule during working hours, morning or afternoon when you know laptops are on and users are active. Scanning at 2:00 am will miss half your endpoints.
- Recurrence options: One-time (instance) or recurring. For recurring scans, set an interval – every 4 hours, daily, weekly – depending on how dynamic the environment is and how current you need the data.
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.
Assign a sensor
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.
Map credentials to the action
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.
Step 3: Active Directory – Keep It Separate
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.
What Comes Next
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:
- Create the site in the multi-site portal
- Install Lansweeper Discovery and link to the site
- Set up credentials
- Create IP range actions (one per network segment)
- Create an Active Directory action
- Let it run
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.
The Bigger Picture: Why Agentless Matters for MSPs
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.
Start Here
New to the series?
Start with Part 1 to understand the MSP architecture and multi-site management model before diving into installation.
Catch Up
Missed the earlier episodes?
Catch up on Part 2 to see how to get Lansweeper Discovery running for a new client in under 10 minutes.
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.
