Lansweeper IP Scanner: Setup, Configuration
You notice the inventory problem when an audit asks for a reliable device count, a merger introduces unfamiliar subnets, or a switch report shows equipment your asset database doesn't contain. The Lansweeper IP Scanner can help, but only if you treat it as a repeatable, history-aware inventory workflow. Ping reachability creates breadth, while credentials and protocols create depth. Reliable results require both to be measured separately.
Why IT Teams Reach for an IP Scanner in the First Place
An IP scanner becomes necessary when your existing inventory answers “what should exist?” but not “what is responding right now?” Reorganizations, acquisitions, audits, and unmanaged devices all expose the same weakness. Agent-based discovery can provide rich endpoint detail, but agents aren't always installed on printers, cameras, switches, Linux hosts, appliances, or newly connected equipment.
Lansweeper's IP scanning workflow is agentless and can identify systems across defined network targets. The practical distinction from a quick ping sweep is that Lansweeper can retain scan metadata, compare attempts with successful sightings, and use supported protocols to collect deeper asset information. Its broader asset-discovery context is described on the Lansweeper product page.
The configuration decision has two dimensions:
Breadth of discovery: How many responding IP addresses become asset records?
Depth of attribution: How much device, operating system, configuration, software, or network information can be retrieved?
Enabling ping-based asset creation favors breadth. Mapping WMI, SNMP, SSH, or other protocol credentials favors depth. Neither choice is universally correct. A security team may want a broad liveness inventory, while infrastructure operations may need authenticated details for remediation and lifecycle planning.
Practical rule: Don't judge scan quality by the number of assets created. Judge it by whether each asset has the level of attribution your operating process requires.
That trade-off affects licensing, database hygiene, network load, and reporting effort. A successful deployment starts by deciding whether each target is intended for discovery, inventory, compliance evidence, or ongoing operational monitoring.
Prerequisites Before You Configure Anything
Before creating a target, verify three layers. Most failed deployments aren't caused by the scan screen itself. They fail because the scan server can't reach the subnet, the firewall blocks management traffic, or the credentials lack the permissions required to return useful data.
Server readiness
Use a Lansweeper installation or scan server positioned where it can reach the required network segments. Reserve adequate disk capacity for scan logs and database growth, and schedule discovery during windows that won't compete with sensitive production traffic. In environments with multiple locations, place scan execution where routing and firewall policy are predictable rather than assuming one central server can see everything.
Network reachability
Test from the scan server, not from an administrator's workstation. For Windows discovery, Lansweeper documents inbound TCP 135, TCP 445, and dynamic DCOM ports in the 49152-65535 range as required unless your organization has restricted the dynamic range through policy. SNMP discovery requires UDP 161, and the device must respond correctly to the requested query. The Windows scanning requirements provide the access conditions to validate before testing credentials.
Credential coverage
A Windows scanning account needs membership in Distributed COM Users and Performance Monitor Users, WMI read access to , and DCOM launch and activation permissions. Network devices need appropriate SNMP community strings or SNMPv3 credentials, while Unix-like systems typically require SSH access.
Missing permissions can look like a dead device. Missing routing can look like invalid credentials. Check the inexpensive causes first, and record each test so another engineer can reproduce the result. Teams comparing adjacent monitoring and service-management options can also review RDS and SysAid considerations while defining the wider operating model.
Defining IP Range Scanning Targets That Stay Repeatable
A target should describe a stable operational boundary, not a temporary troubleshooting guess. The IP Scanner accepts single IPs, IP ranges, CIDR blocks, localhost, and semicolon-separated combinations, which makes it flexible enough for site blocks and mixed network segments.
Use a naming convention that exposes ownership and location immediately. A target named for a site and subnet is easier to schedule, troubleshoot, and report on than one named after the engineer who created it. Standard definitions also let you rerun the same scope and compare outcomes without wondering whether the range changed.
A useful target record includes:
Location: Site, region, or data-center label.
Network purpose: User access, server, voice, wireless, or facilities.
Range definition: The exact single address, range, CIDR block, or semicolon-separated set.
Credential scope: The credentials expected to work there.
Owner: The team responsible for routing, ACLs, and device access.
The critical setting is Save Pinged IP. When enabled, Lansweeper creates an asset page for every IP that responds to ping, even if no data is retrieved through DNS, FTP, HTTP/HTTPS, SNMP, SSH, Telnet, WMI, or other supported protocols. The IP Range scanning target documentation describes this behavior directly.
That makes the option valuable for liveness checks, but it can also create records for ephemeral hosts, unmanaged devices, or addresses that reveal little beyond reachability. If your asset database is intended to support ownership, patching, warranty, or configuration workflows, separate ping-only discovery from credentialed inventory in your reporting.
Teams responsible for address management should also compare the scan scope with ManageEngine DDI Central, because IP discovery and address-management processes answer related but different questions.
Mapping the Protocols That Control Scan Depth
A ping response proves that an address answered a reachability test. It doesn't prove that Lansweeper can identify the operating system, retrieve configuration, or associate the device with an owner. Scan depth depends on the services exposed by the target and the credentials mapped to those services.
Lansweeper documents support for a broad protocol set, including SNMPv1, SNMPv2, SNMPv3, SSH, HTTP, HTTPS, FTP, SMTP, Telnet, JetDirect, SSDP, UPnP, mDNS, DNS-SD, Bonjour, SIP, and WMI through its network-device scanning requirements.
Match protocol to device class
Windows systems depend primarily on WMI and DCOM access. Linux, Unix, and many appliances generally need SSH credentials. Switches, routers, printers, UPS devices, and other network equipment often expose SNMP, while discovery services such as mDNS, Bonjour, SSDP, or UPnP may provide useful identification for specialized devices.
Don't map every credential globally without considering scope. A credential that works in one region may fail in another because of local ACLs, device templates, or security policy. Assign credentials to the smallest practical target group, then report failures by that group.
SNMPv3 deserves a specific validation step. Lansweeper notes that SNMPv3 scanning can fail when FIPS compliance is enabled on the Lansweeper server. That failure can resemble an incorrect credential, so check server policy before rotating valid device credentials.
The operational conclusion is straightforward. Ping is a breadth signal. Protocol authentication is a depth signal. Treating them as the same measure is how teams end up with a large asset count and weak inventory evidence. For related device-discovery strategy, review the Device42 topic collection without assuming that another platform's discovery model maps directly to Lansweeper's.
Scheduling Scans and Reading the Result History
Scheduling is only useful when you connect it to result interpretation. Run stable targets during sensible maintenance windows, then inspect whether the scan produced successful sightings rather than assuming that a completed job produced complete inventory.
Use separate schedules for different network characteristics. A quiet server segment can be scanned independently from a busy user or voice segment. In larger environments, stagger execution across scan servers so several sites don't create avoidable bursts at the same time.
Lansweeper's stored metadata makes the difference between an attempt and a successful result visible:
: The last scan attempt made through the IP Address Range Scanning method.
: The last successful scan of an asset.
: The table where scan history is written for reporting and audit purposes.
Scan logging can be retained for up to 60 days, as documented in Lansweeper's scan-logging troubleshooting guidance. That retention period is useful for investigating recent changes, but it shouldn't replace a durable reporting process when audit evidence must be retained longer.
Measure by location
Lansweeper's reporting model distinguishes total assets, assets scanned successfully, and assets scanned unsuccessfully. Success is defined by the last successful scan time equaling the last tried scan time. Calculate that outcome by IP location or subnet, not only as a global figure.
A global result can hide a regional ACL problem, an expired credential, or a routing break. A site-level view tells you where the workflow is failing and which team needs to act. For monitoring-oriented workflows, the SysAid monitoring discussion offers useful adjacent context, but the scan-history fields remain the evidence for Lansweeper discovery.
Troubleshooting When Discovery Is Quieter Than Expected
A quiet result doesn't mean the network is empty. It usually means the validation path stopped too early. Start with the scan server and move outward, testing one dependency at a time.
Use the cheapest checks first
Test from the scan server: Confirm that the server can reach a known target in the affected range. A successful test from another administrative workstation doesn't prove that the Lansweeper server follows the same route.
Verify required ports: Check the firewall path for the protocol you expect to use. Windows, SNMP, and SSH failures have different network requirements, so don't test only ping.
Run the built-in device tester: Use the tester from the scan server itself before mapping credentials into the production scan configuration. This isolates credential and protocol behavior from scheduling and target-definition problems.
For SNMP, follow Lansweeper's SNMP troubleshooting procedure. Confirm that port 161 isn't blocked, that the device responds to OID 1.3.6.1.2.1.1.2.0, and that the response comes from the same IP address queried. If the response comes from a different address, Lansweeper ignores the data.
One counterintuitive edge case affects device classification. When TCP 135 is open, a device can be treated as a Windows system rather than an SNMP-managed device. If the target is network equipment and the scan behaves unexpectedly, check whether that port is causing the wrong discovery path to win.
Troubleshooting habit: Record the subnet, scan server, protocol, credential scope, and tester result for every failure. “It doesn't scan” isn't enough information to fix the next occurrence.
Make the workflow sustainable
Successful enterprise discovery depends on operating discipline as much as initial configuration. Keep target names tied to site and subnet, rotate service credentials through a controlled process, and preserve a report that separates ping-only assets from credentialed assets. Review success per location so local routing, ACL, and credential failures don't disappear inside a global average.
Documentation can also be confusing during product transition. Lansweeper distinguishes the Classic or Legacy UI from the newer Platform, and hybrid environments may require searching both documentation collections. Don't assume an older community instruction describes the current default behavior.
Recent documentation says newer releases default to saving pinged IPs, which can increase the number of asset records created from responsive addresses. For globally distributed teams, that may improve breadth while increasing cleanup work and making asset counts less representative of managed inventory. Buyers should decide whether they need broad liveness visibility, deep attribution, or separate datasets for each.
Lansweeper's history as a Belgian network discovery and hardware inventory product dates to 2004, followed by the 2020 acquisition of Fing and a €130 million Insight Partners investment in June 2021, according to this Lansweeper history summary. Those milestones help explain why IP discovery now sits inside a broader enterprise asset-management conversation, but they don't remove the need to validate your own network conditions.
For procurement teams, compare licensing and operating requirements alongside adjacent IT operations tools rather than buying a scanner in isolation. Stackingo can be included as a multi-vendor marketplace option for comparing Lansweeper entitlements with related platforms. The next step for an IT leader is to pilot one representative subnet, define the required depth of attribution, measure success by location, and use those results to set the enterprise rollout standard.
Frequently Asked Questions About Lansweeper IP Scanning
Does Lansweeper require an agent for IP scanning?
No. IP Range scanning is designed for agentless discovery, but deeper inventory still requires the target to expose a supported protocol and provide usable credentials. Ping-only asset creation can identify a responsive address without producing the configuration detail you need.
What's the difference between a pinged-only asset and a credentialed asset?
A pinged-only asset shows that an IP responded to a reachability check. A credentialed asset can provide richer information through WMI, SNMP, SSH, or another supported protocol, making it more useful for ownership, configuration, and lifecycle reporting.
How do Classic and Platform scanning configurations differ?
Lansweeper now documents Classic or Legacy UI and Platform environments separately. In a hybrid deployment, search both documentation sets and confirm the instructions against the interface and release you operate.
What should enterprises plan for when scaling across sites?
Plan for segmented targets, scan-server placement, credential scope, firewall validation, and reporting by location. Licensing value depends on whether the resulting records support the operational use case, not on how many IP addresses respond.
Stackingo lets IT leaders compare Lansweeper licensing with other enterprise IT operations tools through one structured procurement workflow.
Stackingo offers multi-vendor access to enterprise software licensing, including Lansweeper, with requirements and scenarios organized for comparable quotes. Visit Stackingo to evaluate Lansweeper alongside adjacent IT operations tools before standardizing your multi-site discovery program.
