Why does Web Jetadmin say 'Device Not Found' even though I can ping the printer?

This is a strong signal pointing toward an SNMP community name mismatch — the printer is reachable on the network, but Jetadmin's SNMP credential doesn't match what the printer is configured to accept.

What is an SNMP community name and why does it need to match?

It functions like a shared password between Web Jetadmin and the printer for SNMP communication. If they don't match exactly, discovery attempts will be rejected.

Could a firewall really be the cause if my local firewall is already disabled?

Yes — check firewalls anywhere along the network path between the Jetadmin server and the printer, not just on the server itself.

HP Web Jetadmin Not Discovering Printers? [Fixed]

Quick-Fix Summary

Confirm basic network reachability to the printer's IP address.
Check for firewalls between the Jetadmin server and the printer, not just on the server itself.
Verify the SNMP community name matches exactly — my uncommon tip, and the most common specific cause.
Check whether WS-Discovery is disabled on the printer.
Confirm SNMP is enabled on the printer at all.

Fix 1: Confirm Basic Network Reachability

From the Web Jetadmin server itself, try pinging the printer's IP address, or use a basic network tool to confirm a connection can be established at all before troubleshooting anything Jetadmin-specific.

Why this works: this rules out the most fundamental possible cause first — if the server genuinely can't reach the printer's IP address at any level, no Jetadmin-specific configuration will matter until that's resolved.

Fix 2: Check for Firewalls Between the Server and Printer

Check not just the local firewall on the Jetadmin server itself, but any firewalls sitting between the server and the printer, particularly if they're on different subnets with network infrastructure in between. Confirm the specific ports Web Jetadmin relies on for discovery (commonly including SNMP on port 161) are open along the entire path.

Why this works: this is a genuinely common real-world cause. A firewall anywhere along a multi-hop network path can silently block exactly the traffic Jetadmin needs.

Fix 3: Verify the SNMP Community Name Matches Exactly (My Uncommon Tip)

Here's the specific mismatch that explains a large share of "Device Not Found" results when the network path itself is actually fine, and it's genuinely easy to overlook because it lives in two separate places that need to agree with each other.

Web Jetadmin discovers and communicates with printers largely through SNMP (Simple Network Management Protocol), and SNMP uses a community name — essentially a shared password — that must match exactly between what's configured on the printer itself and what Web Jetadmin is using when it attempts to discover that device. If your printer has a custom SNMP community name set, and Web Jetadmin is still configured with the default, discovery will fail cleanly and consistently.

To check and fix this: on the printer's own Embedded Web Server, look under network or SNMP settings for the currently configured SNMP community name. In Web Jetadmin, check your discovery settings or device credentials for the community name it's using to attempt discovery, and confirm it matches the printer's setting exactly, case-sensitive and character-for-character.

Fix 4: Check Whether WS-Discovery Is Disabled on the Printer

On certain HP printer families — DesignJet, LaserJet Pro, OfficeJet Pro, and PageWide XL models specifically — check whether WS-Discovery is enabled in the printer's own network settings.

Fix 5: Confirm SNMP Is Enabled on the Printer at All

Through the printer's EWS, verify that SNMP itself hasn't been disabled entirely as part of a broader network security hardening configuration.

Why this works: some organizations disable SNMP fleet-wide as a security measure, and if this has happened to your printer specifically, no amount of correcting community names or checking firewalls will help, since the protocol Web Jetadmin depends on for discovery isn't running on the device at all.

When to Call a Professional

If you've confirmed basic network reachability, checked every firewall along the path, verified the SNMP community name matches exactly on both sides, checked WS-Discovery status for the relevant printer families, and confirmed SNMP is genuinely enabled — and discovery still fails, this points toward something worth deeper investigation with whoever manages your broader network infrastructure.