Discover printers and ports using WMI and basic SNMP

In any minimally serious network, Discover open printers, servers, and ports It's not an "extra," it's essential if you want peace of mind. Between security policies, audits, and users printing on anything with toner, you need to know what's on your printer, where it is, and how it's performing.

The good news is that you don't have to reinvent the wheel: WMI in Windows environments and SNMP on virtually any network device They give you everything you need if you know how to use them. The trick is understanding what each technology offers, which ports are involved, how it all fits with firewalls, and what the implications are for performance and security.

Overview: Agents, WMI, SNMP, and other ways to monitor

When we talk about monitoring equipment and printersActually, we're talking about choosing the “channel” through which the monitoring tool will extract the information of the device. Broadly speaking, these options coexist in corporate networks:

1. Agent installed on the device
Many monitoring platforms include their own agent for Windows, Linux or even specific applications. It is installed on each computer, and the agent collects metrics (CPU, RAM, disks, services, etc.) and sends them to the monitoring server.

• Advantage: very granular access to system data, even beyond what WMI or SNMP offer.
• InconvenienteIt needs to be deployed, maintained, updated, and checked to ensure it doesn't become a performance or security problem.

2. WMI (Windows Management Instrumentation)
In the Windows world, WMI is the standard. It allows you to obtain very detailed information about hardwaresoftware, processes, services, performance and even configure certain aspects of the system. All of this is done through remotely accessible WMI classes.

• Use by default RPC over TCP, with port 135/TCP as the assigner and then high dynamic ports (49152-65535) if not restricted.
• In many scenarios it is also used on WinRM (HTTP 5985 / HTTPS 5986) to avoid dealing with open RPC port ranges.

3. SNMP (Simple Network Management Protocol)
SNMP is a standard application layer protocol, defined in several RFCs (1157, 1901-1908, 3411-3418, among others), and is part of the TCP/IP stack. It is the common language for routers, switches, firewalls, printers, NAS, UPS, security appliances and also for many servers.

• Read/write queries and operations typically use UDP 161.
• Asynchronous notifications (traps and informs) travel via UDP 162.
• Its power lies in the combination of SNMP + MIB + OID agents.

4. SSH
In type systems UNIX (Linux, BSD, etc.), many tools choose to connect via SSH (TCP 22) to execute commands and parse the output. This is an alternative when SNMP is unavailable or when finer control is desired without installing additional agents.

5. APIs and web services
More and more manufacturers are exposing their metrics through REST APIs, SOAP or web servicesIt is the usual way to monitor modern applications, cloud solutions, or very specific appliances where SNMP/WMI does not fit well or has fallen short.

Quick recommendation: what to use for each type of equipment

An guide The one that works on most corporate networks is the following:

• Windows computers: prioritize WMI (or WMI via WinRM) versus your own agents, unless you need very advanced monitoring of applications that only expose data through that agent.
• Linux/UNIX Servers and Workstations: uses SSH or a lightweight agent. SNMP is also possible, but it often falls short in providing system details.
• Network electronics (switches, routers, AP, firewalls): SNMP It's the natural choice. Often there isn't even another standard method.
• Printers and “edge” devices (NAS, UPS, specific hardware): almost always SNMP.
• Modern applications and services: if the manufacturer offers API Officer, use it first.

Los property agents Leave them as a backup plan, for when you don't have WMI, SSH, SNMP, or APIs that cover your needs. They often complicate deployments, maintenance, and security hardening.

How SNMP works internally: managers, agents, MIBs, and OIDs

To discover printers and ports using SNMP, you first need to understand how the information is organized. SNMP is based on three pillars: SNMP manager, managed devices (agents) and MIB/OID.

SNMP Manager (NMS)
It is the central piece: the console or server that runs the Network Management SystemIt is the one that sends requests (GET, GETNEXT, GETBULK, SET) to the agents and receives responses, traps and informs.

• Periodically interview agents to gather metrics.
• It processes values, applies thresholds, generates alerts and graphs.
• You can write to certain OIDs (SETs) if security allows it, although in practice it is recommended to almost always work in write mode. read-only (RO).

Managed devices and SNMP agents
Each routerThe switch, printer, or server you want to monitor runs a SNMP agentThis agent:

• It locally collects statistics on hardware, network, print queues, temperature, etc.
• It presents this information according to the definitions contained in its MIBs.
• It can generate traps towards the NMS when something happens (e.g., paper jam, interface drop, overtemperature).
• It can even act as proxy for devices that do not have native SNMP.

MIB (Management Information Base)
The MIB is, to put it simply, the “dictionary” that defines which variables can be queried and in what formatIt is a text file (usually in ASN.1 notation) that describes:

• Symbolic name of the object.
• Data type (INTEGER, OCTET STRING, COUNTER, Gauge, TimeTicks...).
• Access (read-only, read-write).
• Functional description.
• Hierarchical relationship with other objects.

There are standard MIBs (for example) IF-MIB, IP-MIB, SNMPv2-MIB) and manufacturer-specific MIBs (Cisco, HP, Xerox, Synology, etc.). These private MIBs are what allow you to go beyond the generic, for example, View the toner level or printed pages of a specific model printer.

OID (Object Identifier)
Each object defined in a MIB is identified with a OID, a numerical sequence separated by periods, for example:

• 1.3.6.1.2.1.1.3.0 -> sysUpTime.
• 1.3.6.1.2.1.1.5.0 -> sysName (device name).
• 1.3.6.1.2.1.1.4.0 -> sysContact.

The OIDs are organized into a tree structure, where:

• 1.3.6.1.2.1 corresponds to the standard MIB (mib-2).
• 1.3.6.1.4.1 is the branch of companiesThat is, manufacturers' MIBs.

A typical example of a proprietary OID for a Synology NAS would be something like this: 1.3.6.1.4.1.6574.5related to disk SMART information, while a Cisco OID could hang from 1.3.6.1.4.1.9.

SNMP ports, basic operations, and protocol versions

For SNMP monitoring to work, you need to be very clear about the ports involved and the communication modelOtherwise, the firewall becomes your worst enemy.

Standard SNMP ports

• UDP 161Normal queries and operations (GET, GETNEXT, GETBULK, SET). The NMS sends requests to the agent on that port.
• UDP 162: traps and informs. In this case the agent initiates communication to the monitoring server.

Although TCP can be used with SNMP in some cases, The classic and most widespread implementation is UDPThis has implications: there's less overhead, but there's also no guarantee of delivery. That's why monitoring systems often repeat queries if they don't receive a response.

Most important SNMP operations

• GETThe NMS requests the value of one or more specific OIDs.
• GETNEXT: similar to GET, but requests the next OID in the hierarchy, very useful for iterating through tables.
• GETBULK: introduced in SNMPv2, designed to efficiently download large blocks of data (entire tables).
• SETThe manager writes a value to the agent. It's powerful but dangerous, which is why almost all serious networks avoid exposing SET or restrict it as much as possible.
• trap: asynchronous message that the agent sends to the NMS when an event occurs (e.g., printer out of paper, link down).
• INFORMATION: similar to a trap, but with confirmation of receipt by the NMS.

SNMP versions and security
Historically, SNMP has gone through several versions, with changes mainly in the area of ​​security:

• SNMPv1 (RFC1155, 1156, 1157). Very simple model, security based on “community string”, without encryption.
• SNMPv2cRevised version with performance improvements (GETBULK, new types, etc.), but maintaining the same community-based security scheme. It is the most used in practice.
• SNMPv3. Enter authentication and encryptionwith user-based security (USM) and more robust access models. It is much more secure, but also more complex to configure and may introduce some extra overhead.

For convenience, many networks still use SNMPv2c in read-only (RO) mode with complex communities and access control lists on devices. If you need to comply with strict security policies, it's advisable to plan a phased migration to v3.

WMI in Depth: Ports, RPC, and WinRM

In Windows environments, WMI is the go-to tool for extracting system information without installing additional agents. But at the network level, WMI depends on RPC And that has consequences for the firewall.

Ports involved in classic WMI

• TCP 135: port of RPC Endpoint MapperIt is the initial entry point; through it the client negotiates which dynamic port the subsequent call will use.
• High TCP dynamic ports: typically 49152-65535 In modern systems, the actual WMI/DCOM session is established there.

If you're heavily segmenting the network and filtering ports, this implies a problemOpening a full range 49152-65535 between segments is generally not acceptable from a security standpoint.

Alternative: WMI via WinRM
To avoid this flood of dynamic ports, Microsoft offers the possibility of exposing WMI over WS-Management via WinRM:

• HTTP in the port 5985 / TCP.
• HTTPS in the port 5986 / TCP.

In this way, you can limit WMI communication to well-defined ports and easier to control in the firewall, in addition to adding encryption when using HTTPS. It's the preferred method for modern Windows monitoring and remote management tools.

WMI + Active Directory and other services
It should not be forgotten that many remote administration operations related to WMI, PowerShell Remoting or the promotion of domain controllers themselves also make use of:

• LDAP (389/TCP and UDP), LDAPS (636/TCP).
• SMB (445/TCP) for named conduits.
• High ephemeral RPC ports for different dependent services (DFS, file replication, Netlogon, etc.).

If you are thoroughly shutting down a Windows network, it is essential to review the extensive table of system service ports Microsoft's policy is to avoid cutting off critical components (Kerberos, DNS, Windows schedule, AD replication, etc.).

Discovering printers and ports with SNMP: a practical approach

Let's focus all of this on the case that interests us most: Locate printers on the network and understand which ports are active using SNMP.

1. Activate and configure SNMP on the printers
On most moderately modern printers, SNMP is enabled by default or is activated from the device's web interface:

• Defines a SNMP reading community (Do not use “public” in serious corporate environments).
• If possible, limits SNMP access to the IP address or subnet of your monitoring server.
• Fill in the fields of sysLocation y sysContact so that I can organize them later (office, room, floor, support email, etc.).

2. Check from the monitoring server using snmpwalk
On a Linux host or similar with Net-SNMP tools installed, you can use:

snmpwalk -v2c -c YOUR_COMMUNITY 192.168.xx

If the configuration is correct, you will see a parade long list of OIDs and values: system name, location, number of interfaces, network statistics, page counters, toner levels (if provided by the manufacturer in their private MIBs), etc.

To test only a specific OID (for example, sysName):

snmpwalk -v2c -c YOUR_COMMUNITY 192.168.xx SNMPv2-MIB::sysName.0

3. Identify "garbage" SNMP ports and traffic
A very typical case in networks with a history is finding a Windows print server that keeps trying to communicate via SNMP with printers that no longer exist or have changed subnets.

• Printer TCP/IP ports in Windows can have SNMP enabled by default.
• If that server tries to make SNMP queries to old IPs every few seconds, you'll see lots of blocked packages on your firewall (for example, a FortiGate), all directed to UDP 161 addresses that no longer belong to the network.

The solution is as simple as this: Disable SNMP on those print ports or clean up unused ports. Before deleting anything, it's advisable to verify that there are truly no associated jobs and that the corresponding printer is no longer part of the infrastructure.

4. Use of manufacturer's MIB for advanced data
If you want to go beyond "it's on or off" and to actually monitor the status of the printers (queues, jams, toner, paper trays), you will have to:

• Download the Manufacturer-specific MIBs (Xerox, HP, Canon, etc.), often available on their support portal.
• Upload them to your SNMP tool or MIB browser.
• Locate the OIDs related to each metric (e.g., number of printed pages, consumable lifespan, error codes).

With that you will be able to build graphs and alerts that alert users when a printer runs out of paper, when the toner is at 5%, or when a counter spikes abnormally, preventing surprises for users.

SNMP, security, and good configuration practices

SNMP is incredibly powerful, but if left unchecked it becomes a strainerSome key points to avoid shooting yourself in the foot:

• Always use personalized communitiesnever “public”/“private”.
• Restrict access to Specific IPs or subnets using ACLs on routers, switches or on the SNMP daemon itself (Linux, Windows, ESXi, etc.).
• Whenever possible, stay in read mode (RO)Avoid SET in production except in very controlled cases.
• If your environment requires it, consider using SNMPv3 with authentication and encryption, at least for critical equipment.
• Documenta What MIB and OID? You use them and what they mean, so that other admins can maintain them.

In Windows Server, remember that the SNMP service:

• It is not installed by default; the feature must be added (via GUI, PowerShell or optional capabilities).
• It is mainly configured from the tabs Security y Agent of the service: accepted communities, hosts from which packages are allowed, contact, location, and monitored services.

In Linux, the key file is usually /etc/snmp/snmpd.confwhere you can define views, communities, and listening directions, for example allowing only one defined community and restricting the view to .1 (the entire tree) or specific subsets.

Coordinating WMI, SNMP, and firewalls in segmented networks

In companies with multiple VLANs, DMZs, and highly filtered zones, the challenge is not just monitoring, but actually monitoring. without opening half the universe of portsThis is where WMI, SNMP, and firewall rules need to be properly combined.

Some principles that work well:

• To Internal Windows: enables WinRM (5985/5986) and limits classic WMI by RPC only to highly controlled segments.
• To network equipment and printers: only opens UDP 161/162 to and from the IPs of your monitoring servers.
• Centralize monitoring in a few well protected NMS instead of having multiple scattered query sources.
• Check the table of Windows Server service ports to ensure that AD, DNS, Kerberos, DFS, Netlogon, etc. can still communicate with each other after any hardening.

If you already have a firewall logging denied traffic, it's a good idea. analyze the logs Looking for blocked SNMP patterns (or WMI via RPC) that correspond to misconfigured devices, missing printers, or servers that still believe there are outdated subnets. Cleaning this up reduces background noise and saves you from unnecessary rules.

In the end, combine well WMI on Windows and SNMP for everything elseWith a clear port and community policy, it gives you a highly detailed view of printers, servers, switches, and applications, without having to clutter the network with heavyweight agents or leave the firewall wide open. It's the most sensible way to keep track of who prints, from where, and through which ports, without going crazy every time an audit comes around or you need to review the infrastructure's security.