Overview

Network Discovery inventories the machines on a gateway's LAN and shows which of them are not yet running the ET Ducky agent. It runs inside the same OOB gateway used for hardware management — a dedicated device, or a regular agent with the OOB gateway role enabled — and reports what it finds to Systems → Network Discovery in the dashboard.

Scanning is opt-in and admin-triggered. Nothing is scanned automatically. A scan happens only when an organization administrator clicks Scan network. This is Phase 1: inventory only. Remote agent deployment to unmanaged machines is a separate, later capability.

What a scan does

When you click Scan network, the dashboard asks your gateway to sweep its local subnets. For each live host the gateway:

• detects liveness via ICMP ping and the local ARP / neighbor table;
• probes a small set of management ports to fingerprint the OS family — 445/5985/5986/3389/135 suggest Windows, 22 suggests Linux;
• records IP, MAC (when the host is on the gateway's own network segment), and a reverse-DNS hostname where available.

Signal	Detected by	Classified as
Answers ICMP ping, or has a recent ARP / neighbor entry	Ping + local ARP table	A live host (added to the inventory)
TCP 445, 5985, 5986, 3389, or 135 open	Short TCP connect probe	OS → Windows
TCP 22 open	Short TCP connect probe	OS → Linux
Live, but none of the above ports answered	—	OS → Unknown

Agent-compatible means the OS fingerprinted as Windows or Linux. A host that answered ping/ARP but exposed none of the probe ports stays Unknown and is not counted agent-compatible — see the caveat under Reading the results.

The gateway reports the endpoints to the cloud, which marks each Managed or Unmanaged by matching it against your enrolled agents (by MAC, then hostname).

Reading the results

Column	Meaning
Hostname / IP / MAC	Identity of the discovered host. MAC is only visible for hosts on the gateway's own network segment.
OS	Coarse guess from open ports (Windows / Linux / Other / Unknown). A hint, not authoritative.
Open ports	Management ports that answered during the sweep.
Status	Managed correlates to an enrolled agent (shown with its agent id). Unmanaged means no matching agent — a candidate for agent deployment.

Use the filter to show Unmanaged only for a quick coverage-gap view.

Views

Network Discovery lives under Systems → Network Discovery and is organized into sub-tabs. Switch views from the sub-tab bar at the top; the organization dropdown (top-right) scopes results to a single client.

• Devices — the flat inventory, filterable by managed/unmanaged, OS family, subnet, and agent-compatible.
• Topology — an interactive map of the organization: the cloud, each VLAN's OOB gateway, and the devices behind it.
• Coverage — how many agent-compatible hosts run the agent, and the deploy-target gap per subnet.
• Changes — hosts first seen recently, and hosts that have gone quiet.
• Segments — a per-VLAN rollup that flags segments with no on-segment OOB gateway.
• OOB candidates — managed hosts whose hardware is vPro/AMT-capable but not yet provisioned (no scan required). Provision them in one click — see Enabling dormant AMT.
• Attack surface — which services (SMB, RDP, SSH, WinRM, …) are listening across the fleet, with risky exposures flagged.
• Non-computers — printers, switches, phones, cameras and IoT, grouped by MAC vendor.

Workflow: find agent coverage gaps

1. Open Systems → Network Discovery and pick the client in the organization dropdown.
2. On the Devices view, set the filter to Unmanaged only (optionally narrow by subnet or agent-compatible).
3. Each unmanaged, agent-compatible host is a deploy target. Switch to Coverage to see the gap per subnet at a glance.

Workflow: find out-of-band blind spots

1. Open the Segments view. Any segment flagged no on-segment OOB gateway is a blind spot — devices there cannot be reached out-of-band.
2. Stand up a gateway on that segment (a dedicated Pi, or an agent-hosted gateway running on the segment). See Out-of-Band Management.
3. Check OOB candidates for vPro machines you can switch on with one-click provisioning, and Attack surface for risky exposed services to remediate.

Driving full agent coverage

Discovery tells you what's on the network; getting to full coverage is a short, repeatable loop. At scale the key move is to deploy by directory, not by discovery — the machines discovery can't fingerprint are exactly the ones a directory-based push still reaches.

1. Place a gateway on every managed VLAN. Discovery only sees segments with an on-segment gateway; check Segments for blind spots first.
2. Scan, then classify — including Unknowns. Managed hosts are done; unmanaged agent-compatible hosts are your visible deploy targets. For Unknown hosts, remove genuine non-computers with the Non-computers view (grouped by MAC vendor), then reconcile the rest against Active Directory / Entra, DHCP leases, or DNS. Anything that resolves to a Windows or Linux endpoint is a firewalled deploy target discovery can't fingerprint.
3. Deploy by directory. Push the agent to a machine group via GPO, Intune / Endpoint Manager, or your RMM (Linux: config management or the install script). Membership — not an open port — drives the install, so firewalled endpoints are covered too. Use an organization install token for edge or unmanaged machines.
4. Verify against your real device count. Re-scan; newly enrolled hosts flip to Managed. Confirm coverage against your authoritative inventory (AD / asset list), not just the dashboard's agent-compatible number, and use Attack surface to prioritize any still-unmanaged host exposing RDP / SMB / SSH.
5. Re-scan on a cadence. Scanning is on-demand, so re-scan after each onboarding wave and periodically; the Changes view surfaces new and newly-quiet hosts to feed back into the loop.

Workgroup / non-domain networks: with no directory to deploy from, lean on discovery plus manual reconciliation — scripted install with a per-host install token, and optionally a temporary firewall allowance for the probe ports from the gateway IP so more hosts fingerprint correctly.

Requirements & access

• An OOB gateway on the target LAN — a dedicated device, or an agent with the OOB gateway role enabled (Agent properties → “OOB gateway for this network”).
• Starting a scan requires an organization administrator and a paid subscription; viewing results requires an organization administrator.
• The gateway must be online (connected to the cloud) when you start a scan.

Privacy & network considerations

A network sweep sends ICMP and a handful of TCP connection attempts to hosts on your own subnets. This is lightweight, but any active scan can be noticed by intrusion-detection systems. Because scans are opt-in and admin-triggered, ET Ducky never probes your network without an explicit action, and discovery is scoped to the gateway's own local subnets.

Accuracy notes

• MAC matching is most accurate on the gateway's local subnet. Hosts reached across a router are correlated by hostname/IP only.
• OS fingerprinting is a heuristic from open ports; treat it as a hint.
• Endpoints not seen on later scans are kept in the list (with an older “last seen”) rather than removed, so coverage history is preserved.

Related

• Out-of-Band Management — the gateway this feature runs inside, plus firmware-level power/console for AMT/DASH/IPMI hardware and how to enable an agent-hosted gateway instead of a dedicated device.
• Agent Management — deploying and managing the ET Ducky agent on the machines discovery flags as unmanaged.