The Register's latest look at Raspberry Pi Desktop lands on a conclusion every IT team quietly knows: old PCs aren't past it. The Debian 13-based refresh runs comfortably on veteran ThinkPads, and — crucially — installs without turning the process into a hobby project. With a turnkey Linux distro and a free afternoon, a 2014 laptop becomes the reception signage box, the warehouse label server, or the spare bench machine.
Great news for hardware budgets. Quietly terrible news for your network map.
Because every repurposed ThinkPad, every resurrected desktop, every old laptop pressed back into service is a device that just fell out of every system meant to track it. The Windows RMM agent was wiped during the re-image — or the box now runs Debian, so your agent was never going to cover it anyway. The CMDB still says "decommissioned, 2021." The Visio diagram predates the whole project. But the machine is alive: on your VLAN, holding a DHCP lease, serving users — and completely invisible to your monitoring stack until reception submits a ticket that says "the screen is blank" and nobody can even find the hardware.
Whether you run internal IT or a NOC for twelve client sites, you already live this. Here's why your network inventory is quietly lying to you — and how to fix it this week.
The Problem: Your Network Is Full of Devices Nobody Owns Anymore
RMM tools only see what has an agent
NinjaOne, ConnectWise RMM, Datto — every major RMM platform is agent-based, and most lead with Windows and macOS. That's by design: agents are how you patch, script, and remote in. It also means the platform is structurally blind to:
- Managed switches, firewalls, and access points
- Printers, IP cameras, NAS boxes, UPS network cards
- Linux hosts — including that ThinkPad now running Debian 13
- Anything whose agent was removed during a repurpose or re-image
Turnkey Linux on old hardware makes this worse, not better. Repurposing is exactly the moment a device exits your RMM and enters the shadow realm of "pings, but nobody knows what it is."
Discovery tools scan on schedules, not continuously
Plenty of shops bolt on a separate discovery product — Lansweeper, Spiceworks, Netdisco — running nightly or weekly. Between scans, the network moves on. A device plugged into the conference room switch on Monday afternoon doesn't exist in the inventory until Sunday's scan. In an environment with hundreds of endpoints and constant churn, that's a rolling week of unknowns, plus the assumption that last Tuesday's scan results still describe today's reality. They don't.
Topology documentation is a snapshot of the past
The classic stack: RMM for endpoints, a standalone NMS polling switch health, a Visio diagram from 2019 for topology, and an IPAM spreadsheet in SharePoint updated "recently-ish." Four tools, four data models, zero integration. So when a segment goes flat, the tech opens the ticket queue, opens a terminal, and starts archaeology: show ip arp, show mac address-table, a MAC vendor lookup, a traceroute, and eventually a walk to the IDF to read port labels. Forty-five minutes, minimum, to answer "what is this device and where is it plugged in."
What this actually costs
Real scenarios you'll recognize:
- DHCP scope exhaustion from ghost leases. The guest Wi-Fi scope fills. Users can't connect, ticket volume spikes, and the fix requires knowing which leases are stale — but inventory says those laptops were recycled in 2019, so nobody trusts the data enough to act.
- The unknown IP that pings. Security hands you a report: 192.168.10.87 is responding, no hostname, no agent, no CMDB entry. Identifying it burns an afternoon of ARP lookups and port hunts — a question a live map answers in seconds.
- Ghost outages on "decommissioned" hardware. The repurposed desktop running reception signage dies Saturday night. Nothing was watching it, because your inventory says it doesn't exist. Users report it Monday. Paper MTTR: the entire weekend.
The compounding costs: 30–60 minutes of forensic work per unknown device, alerts missed on unmanaged-but-critical gear, a CMDB nobody trusts, and technicians burning out on repeat archaeology instead of actual fixes.
The root cause isn't laziness — it's architecture. Discovery, monitoring, alerting, helpdesk, and remote action live in five disconnected products, so answering one simple question requires five logins and a good memory.
How AlertMonitor Turns Discovery Into a Live Map, Not a Quarterly Spreadsheet
AlertMonitor approaches this from the opposite direction: the network tells you what it looks like, continuously.
Continuous, agentless discovery. AlertMonitor discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP table analysis, and active scanning. Not a weekly job: continuous. The Debianized ThinkPad, the forgotten LaserJet, the camera someone installed on a Friday — they appear on the map as they appear on the network.
A topology map that's always current. The live topology map reflects the real network state right now — switches, links, VLANs, and what's plugged into what. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full network context: MAC address, vendor OUI, IP, switch, port, VLAN. Your team stops relying on stale Visio diagrams and quarterly scans.
Context replaces archaeology. Old workflow: ticket → SSH to the core → ARP → MAC table → port hunt → walk to the IDF. AlertMonitor workflow: click the device on the live map → see which switch, which port, which VLAN, and what kind of hardware it looks like → take action. A 45-minute hunt becomes a sub-minute lookup.
One system, end to end. Because discovery, monitoring, alerting, helpdesk, and remote actions live in the same product, a new-device alert becomes a ticket with one click, the ticket carries the device's full network context, and the topology answer is never more than a click away. No five-tab forensics, no helpdesk and NMS disagreeing about what reality is.
The practical impact: unknown-device identification drops from 30–60 minutes to under two, ghost outages become instant alerts instead of Monday surprises, and your inventory earns back trust — because it isn't an inventory. It's a live map.
Practical Steps: Hunt Your Ghost Devices Today
Before any tooling change, quantify your unknowns with what's already on your bench.
1. Compare live ARP entries against your known inventory. Run this from any Windows host that sees the subnet. Whatever it flags is either a policy exception or a ghost:
# Find ARP entries not present in your known-device inventory
$known = Import-Csv "C:\Inventory\known-devices.csv"
$knownMacs = $known.MAC.ToLower() | Sort-Object -Unique
$arpOutput = arp -a | Select-String "192\.168\.10\."
foreach ($line in $arpOutput) {
$parts = ($line.ToString() -split '\s+') | Where-Object { $_ }
$ip = $parts[1]
$mac = $parts[2].ToLower()
if ($knownMacs -notcontains $mac) {
# macvendors.com free tier is ~1 req/sec — add a delay for big ranges
$vendor = Invoke-RestMethod "https://api.macvendors.com/$mac" -ErrorAction SilentlyContinue
Write-Output "UNKNOWN: $ip MAC: $mac Vendor: $vendor"
}
}
2. Audit DHCP for leases no one can explain. Stale, anonymous leases are where repurposed-and-forgotten machines hide:
# Export every active DHCP lease across all scopes on a Windows DHCP server
$leases = Get-DhcpServerv4Scope | ForEach-Object {
Get-DhcpServerv4Lease -ScopeId $_.ScopeId
} | Where-Object { $_.AddressState -eq 'Active' }
$leases | Select-Object ScopeId, IPAddress, HostName, ClientId, LeaseExpiryTime |
Export-Csv "C:\Reports\active-leases.csv" -NoTypeInformation
# Leases with a blank hostname are your prime suspects
$leases | Where-Object { -not $_.HostName } |
Format-Table ScopeId, IPAddress, ClientId
3. Sweep the subnet and see what answers without a name. From any Linux box or WSL session:
# Ping sweep + reverse DNS across a /24 — "no PTR record" means an unknown device
for i in $(seq 1 254); do
ip="192.168.10.$i"
if ping -c1 -W1 "$ip" &>/dev/null; then
ptr=$(dig +short -x "$ip" 2>/dev/null)
echo "$ip -> ${ptr:-no PTR record}"
fi
done
4. Verify what's really plugged into each switch port. ARP tells you an IP exists; the switch tells you where it lives:
# Pull interface descriptions and link status from a switch via SNMP
snmpwalk -v2c -c YourCommunityString 192.168.10.2 IF-MIB::ifDescr
snmpwalk -v2c -c YourCommunityString 192.168.10.2 IF-MIB::ifOperStatus
5. Then make the manual sweep unnecessary. This is where those scripts stop being a monthly chore:
- Point AlertMonitor's discovery (SNMP + ARP + active scanning) at every VLAN — including guest and IoT segments, where repurposed hardware loves to hide.
- Create a New Device Detected alert policy routed to the helpdesk queue, with the device's switch, port, and vendor attached automatically.
- Review the live topology map weekly for links and devices that shouldn't be there — the map updates itself; your only job is to look.
- Close every monitoring gap: each device on the map should have an agent, an SNMP profile, or a documented reason it doesn't.
The Hardware Will Keep Outliving Your Inventory
The Register's conclusion stands: veteran ThinkPads aren't past it, and with Debian 13 under the hood they'll run for years. Your network will keep filling up with hardware that outlived its inventory entry — repurposed, re-imaged, redeployed. The only question is whether your visibility keeps up, or whether the next "blank screen in reception" ticket starts another 45-minute hunt.
Stop managing ghosts. Point AlertMonitor at your network and let the live map do the remembering.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.