Most IT teams can name the laptops they handed out and the servers they racked. The gap shows up everywhere else: the switch someone added to a branch office, the printer that arrived with a department, the test machine that was never decommissioned. Network discovery is how that gap gets closed, by scanning the network on a schedule and reporting what answered.
Windows ships a setting with the same name, and that one controls whether a computer shows up to others on a local network. This article covers the IT Asset Management (ITAM) practice: how a scan finds devices, what it can and cannot tell you about them, how agent based and agentless methods divide the work, and how to run a scan and turn the results into inventory.
What is network discovery
Network discovery is the automated process of finding devices that are reachable on a network and collecting whatever they will report about themselves. A tool contacts every Internet Protocol (IP) address in a defined range, identifies which ones are active, and records what each one returned.
The scan reaches anything that holds an address and answers, and its particular value is covering the hardware no software agent will ever run on. It is one input into a broader asset discovery strategy, and a single pass over a corporate network typically returns:
- Computers and workstations.
- Servers, both physical and virtual.
- Network devices, including switches, routers, firewalls and wireless access points.
- Printers and multifunction devices.
- IP phones, cameras, storage appliances and other connected hardware.
- Software applications running on the devices it reaches.
A quick clarification before going further: everything in this article refers to scanning a network to build an asset inventory. The identically named Windows option is a separate, per machine setting that controls whether a single computer is visible to others on a local network.
What a scan returns
A finished scan hands back a table of devices and the attributes each one exposed over the network. How much arrives depends on which protocols are enabled and whether read credentials are configured, so the same device can come back rich or thin. The fields collected are:
- Device name and device type.
- IP address.
- Media Access Control (MAC) address.
- Manufacturer, model and serial number.
- Network interfaces.
- Uptime.
- Contact and location, where the device has been configured to report them.
- Supply levels, on printers.
That is enough to know what is on the network, and an Asset Management Database (AMDB) asks for a little more. The fundamentals it rests on are the ones a scan has no way to read: who owns the device, where exactly it sits, what it cost and how it was acquired, its warranty, its lifecycle stage, and which other elements it depends on. Those get filled in when a discovered device is converted into an asset, which is where the rest of this article goes.
How network discovery works
The mechanics are consistent across tools. A scanner reaches a range of addresses, speaks a handful of standard protocols to whatever answers, and writes the results somewhere they can be reconciled against records that already exist.
The protocols that find devices
No single protocol sees the whole network, so discovery runs several at once and combines what each returns. Which protocols are enabled decides how much detail comes back, and a device that looks thin in the results is often a device whose protocol was never switched on.
Each protocol contributes something different:
- Simple Network Management Protocol (SNMP) is the workhorse. It returns the device name, manufacturer, model, device type, MAC address, serial number, interfaces, uptime, contact, location, and printer supply levels.
- Address Resolution Protocol (ARP) returns the MAC address of the device.
- Internet Control Message Protocol (ICMP) establishes whether an address belongs to a live device, and reports open ports.
- Network Basic Input/Output System (NetBIOS) returns the hostname, usually from Windows workstations and printers.
- Domain Name System (DNS) and Multicast DNS (mDNS) both return the device name.
- Universal Plug and Play (UPnP) returns manufacturer information, mostly from printers.
- Transmission Control Protocol (TCP) can be enabled alongside the others, and like every protocol here its port is configurable when the default does not apply.
The scan sequence
Most tools follow the same five steps, and the quality of the result depends almost entirely on how carefully the first one is done. A range that skips a subnet produces a clean report with a hole in it, and nothing later in the sequence flags the omission.
The sequence runs as follows:
- Define the range, protocols and schedule. Specify which address ranges to scan, enable the protocols to use, supply read credentials such as an SNMP community string, and set how often the scan repeats.
- Contact every address. The scanner works through the range and identifies which addresses are active.
- Collect attributes. For each device that answered, the tool gathers what the enabled protocols return, going deeper where credentials allow it.
- Identify and classify. Responses are correlated to decide what each device is, and to give it an identifier stable enough to recognize on the next pass.
- Reconcile and store. Results are matched against existing records so known devices are updated instead of duplicated, and genuinely new ones are flagged for review.
Where discovery data lands
Discovery output only becomes useful once it meets the records a team already keeps. Reconciliation is the step that matches a rediscovered device to its existing entry, updates what changed, and separates the genuinely new from the merely rescanned.
From there the data feeds two places. The asset inventory gains the hardware facts it needs for lifecycle and audit work, and the Configuration Management Database (CMDB) gains the devices and relationships that Change Management depends on when someone needs to know what a planned change will touch.
Agent based and agentless discovery
Network discovery is an agentless method, which means it collects what it can from outside the device with nothing installed on it. An agent takes the opposite approach: a small program runs on the endpoint and reports from the inside, which is how detailed software inventory and usage data get collected at all.
The two cover different ground, and most teams run both, often managed from the same place. For desktops and laptops an agent is the better instrument because it returns more than a scan can, and our breakdown of agent based and agentless approaches goes further into the trade offs.
Why scans miss devices
A scan that completes without errors can still return less than what is on the network. The causes split into two groups, and the first produces results that look like a product fault rather than a configuration problem.
When the MAC address cannot be read
Discovery identifies devices by their MAC address, which makes every failure to read one a device that never reaches the results table. A device sitting in a different subnet than the scanning proxy is the common case, because its MAC cannot be resolved across the boundary.
The other case is Proxy ARP. When a switch, router or access point answers on behalf of certain addresses, every device behind it reports that same MAC, and devices that cannot be told apart are left out rather than added as duplicates. Results carry annotations that name both situations directly, so a device marked "MAC address not found" or "Multiple occurrences for the same MAC" is telling you which of the two you are looking at.
Configuration and timing
The remaining causes are easier to spot and easier to fix. Recurring scans absorb most of them, because a device missed in one pass tends to appear in the next, and that same rhythm is how unauthorized devices surface once the baseline is stable.
Look for these first:
- Protocols left disabled. A device shows up with an address and little else when the protocol that carries its detail was never enabled on the scan.
- Credentials that do not match. An SNMP profile configured for one version returns almost nothing from a device expecting another, without failing loudly.
- Ranges that miss a subnet. Branch offices, guest networks and virtual local area networks added after the scan was configured stay invisible until someone adds them.
- Host firewalls. A workstation set to drop unsolicited traffic will not answer, even while it is switched on and in use.
- Timing. Devices powered off during the scan window never appear, which quietly undercounts laptops when scans run overnight.
How to run network discovery with InvGate Asset Management
Unify Your IT Asset Inventory in 24 hours! Leverage Automated Discovery
InvGate Asset Management gives IT teams one interface for hardware, software and cloud assets, covering the full lifecycle from the moment a device is found to the moment it is retired. It combines network scanning, agent based collection and integrations with the platforms that already hold parts of the estate.
Network scanning runs through Discovery Sources, the mechanism the platform uses to bring devices in without anyone touching them. InvGate Discovery is the source that scans your network directly, and it runs through a lightweight proxy installed inside the network so nothing needs to be exposed externally. The InvGate Asset Management's Agent is a second Discovery type, deployed from the same section, and its job is filling in depth on the computers where it runs rather than finding new hardware.
The capabilities that matter most for network discovery work are these:
- Agentless network scanning. Reaches printers, switches, appliances and anything else that answers, with no software installed on the device.
- Selectable protocols and ports. Enable only the protocols you need per source, and change the port each one uses where defaults do not apply.
- Scheduled recurring scans. Set the frequency once so the inventory keeps pace with a network that changes weekly.
- Review before adoption. Detected devices sit in their own view until someone decides which belong in the inventory.
- Connected device mapping. Reads switch interfaces over SNMP to show which devices sit behind which port, building relationships instead of a flat list.
Step by step: running a network scan
Four steps take you from nothing installed to devices in the inventory. The first two are one time setup per network segment, and the last two are the cycle you repeat.
1. Install the discovery proxy
The proxy is the component that performs the scan from inside your network and reports results back. Go to Settings > Discovery > Proxies, create a new proxy, download the installer for the operating system it will run on, and execute it on the chosen machine.
Most organizations run one proxy per network, location or segment. That placement matters more than it looks, because a device in a different subnet than the proxy will not have its MAC address read and will not reach the results table.
2. Configure the proxy
A configuration window opens after installation and asks for your InvGate Asset Management URL, the proxy security token and a name for the proxy. All three values are available during the process.
Once they are entered, the connection between the proxy and the platform is established and the proxy is ready to run scans. Nothing else needs to be installed on the machines being scanned.
3. Create the discovery source
Go to Settings > Discovery > Discovery sources, click Add, and choose InvGate Discovery. Here you pick the proxy that will run the scan, the address ranges to cover, the protocols to use, and the schedule, including start date, time and frequency.
Protocol selection is the setting worth revisiting later. Each execution writes a log with the number of devices found and updated, and a downloadable file listing which addresses responded and what was detected for each, which is the fastest way to see whether a protocol is worth enabling.
4. Review and convert the results
Detected devices appear under Assets > Discovery, each carrying its status, source, conflicts against existing assets, and annotations explaining anything unusual. From here you can convert devices into assets, use Select similar assets to group everything of the same kind and source, or Set as ignored to keep hardware you do not track out of the list without deleting it.
Selecting a single device and clicking Convert to asset opens a form with values suggested from what discovery collected. Selecting several and clicking Convert item(s) opens an editable table instead, which is considerably faster for a first inventory.
Mapping which devices sit behind which port
A scan that reaches switches over SNMP can do more than list them. It reads each interface and reports what is connected to it, which turns a flat list of addresses into a picture of how the network is actually wired.
The mapping reads Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP) and the switch's own MAC address tables, in that order of precedence, then matches what it collects against everything the platform already knows. A few conditions are worth knowing before relying on it:
- It needs an InvGate Discovery source with SNMP enabled, and it covers the network devices that source reached over SNMP.
- An interface can show assets already in the inventory and devices discovered but not yet converted, side by side, so the picture does not wait for conversion to be useful.
- When more than four devices report on a single interface, that interface is classified as an Uplink, because there is no way to tell which of them is directly connected.
- An entry reading "Device not found" means the MAC address on that interface matches nothing in the instance, which usually points at a device outside the scanned range.
Other discovery sources
Although it's not a dedicated network discovery tool, InvGate Asset Management's network scanning covers what is reachable on the wire, and a good deal of the estate lives in systems that already track it. Discovery Sources also pull from those platforms directly, covering Active Directory, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, Microsoft Hyper-V, VMware, Kubernetes, Microsoft Intune, JAMF and SOTI MobiControl. Cloud instances in particular belong to their own integration rather than to a network scan.
Running several sources against one inventory is what closes the remaining gaps, since a device invisible to one source is usually well documented by another. To see how this works on your own network, start a 30-day free trial of InvGate Asset Management, or talk to Sales about scanning a larger or segmented environment.
InvGate's Integrations database
Connect our solutions with the apps you use every day.
Explore InvGate's integrations
Conclusion
Network discovery answers one question well: what is connected to this network right now. It answers it without touching a single device, which is why it reaches the printers, switches and appliances that no agent will ever run on.
Turning those answers into an inventory takes the step most guides skip. A scan produces addresses and attributes, and reconciliation, ownership and lifecycle data turn them into records a team can manage, audit and plan against.
Frequently Asked Questions
Is this the same as the network discovery setting in Windows?
No. The Windows setting controls whether one computer is visible to others on a local network, and it is configured per machine. The practice described here scans a network from a central tool to build an inventory of everything connected to it.
Does network discovery require an agent?
No. Network discovery is agentless by definition and collects what devices expose over the network. Agents are a separate method that adds depth on computers, particularly installed software and usage data.
What information does a network scan collect?
The device name and type, IP address, MAC address, manufacturer, model, serial number, interfaces, uptime, contact and location, plus supply levels on printers. How much of that arrives depends on which protocols are enabled and whether read credentials are configured.
Why do some devices never appear in the results?
Discovery identifies devices by MAC address. A device in a different subnet than the scanning proxy will not have its MAC read, and devices behind a Proxy ARP configuration all report the same MAC, so neither group can be added to the results.
How often should network discovery run?
Often enough to keep pace with how fast the network changes, which for most organizations means weekly or daily. A single scan is accurate on the day it runs and degrades from there as devices are added, moved and retired.
