An empty discovery result is never one problem — it is one of six, and guessing wastes hours. This is the technician’s split-test order that isolates which one you have.
You ran the IP range scan, waited, and OpManager reported nothing — or it found devices that sit in the inventory as grey “unknown” boxes with no data. Resist the urge to reinstall or to widen the range and hope. Discovery is a chain: the scan must reach the device, the device must answer, the credential must match, the protocol port must be open, and the result must be approved into the inventory. A break at any link looks identical from the console — an empty list. The checks below follow the chain in order; each one takes under two minutes and each either fixes the problem or eliminates a suspect permanently.
Example readings. Where your device stops in this chain is exactly where the fault lives.
The most embarrassing cause is also the most common: discovery worked, and the devices are sitting in the Discovered Devices list waiting for a human. Nothing enters the monitored inventory until you click Approve; Ignore removes a device and blocks it from being re-added by future scans. Before any technical troubleshooting, open that list. If your switches are there, your “discovery problem” was a queue, not a fault.
From the OpManager server itself — not from your laptop — ping one missing device. OpManager discovers with ICMP/Nmap-style probes, so if the server cannot ping the target, discovery cannot see it either. A failed ping points at routing, a VLAN boundary, or the device’s own firewall dropping ICMP. A successful ping with an empty discovery result moves you down the chain: the device is reachable but not answering the questions discovery asks.
A switch or server with SNMP disabled is invisible to classification: it may appear as an unknown ping-only node or not at all. On the device, confirm the SNMP agent/service is running and that it accepts queries from the OpManager server’s IP — many devices silently drop SNMP from unlisted sources. On the OpManager side, the device snapshot page tells the truth: a populated sysDescr means SNMP answered. Also check the device icon — OpManager marks SNMP-responding devices, and their absence from a whole subnet usually means SNMP was never enabled on that fleet.
SNMP v1/v2 lives or dies on the community string: one wrong character and every query times out. Re-type it rather than trusting what is saved. For SNMPv3, verify the username, authentication and privacy settings match the device exactly, and remember the engine ID must be unique per device. Then confirm the credential is actually associated with the device or selected in the discovery profile — a credential that exists in the list but is attached to nothing monitors nothing. WMI has its own trap: the target must have the WMI and RPC services running, and the credential needs the form DOMAIN\username.
Firewalls between the OpManager server and a subnet — or host firewalls on the devices — drop monitoring traffic silently. SNMP polls travel on UDP port 161 from the server to the device; if a firewall rule or ACL blocks it, credentials and SNMP settings can both be perfect and discovery still finds air. Windows targets add WMI’s dependency on RPC (TCP 135 plus dynamic ports), which is why WMI monitoring across a strict firewall is painful by design — SNMP is usually the calmer protocol across network boundaries. Fix the rule to allow the OpManager server’s address specifically, then rediscover one device as proof before rescanning the range.
Watch how discovery, credentials and the approval step fit together in the full OpManager setup video — the order in the video is the order that works.
▶️ Watch Full VideoUsually the range was wrong (a typo in start/end IP), the scan was pointed at a subnet the server cannot route to, or a discovery filter excluded everything. Recheck the range and filters first, then walk the split-test on this page from ping upward.
OpManager could reach them but could not classify them, which almost always means SNMP did not answer with a matching credential. Fix the community string or SNMPv3 settings, associate the credential, and rediscover the device.
WMI needs more than a password: the WMI and RPC services must be running on the target and the firewall must allow RPC traffic. Across subnets with strict firewalls, SNMP is usually the practical choice; WMI shines inside a Windows domain on the same network.