---
type: Article
title: "Monitor Windows via SNMP"
description: "Poll a Windows Server for CPU, memory, disk and uptime with the same standard OIDs you use on Linux — how to enable the SNMP service and what to watch."
resource: "https://snmp-monitoring.com/devices/windows/"
tags: [devices, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Monitor Windows via SNMP

Windows doesn't lead with SNMP the way Linux does, but it speaks it perfectly well — and for cross-platform monitoring, that's exactly what you want. SNMP Windows monitoring lets one manager poll a Windows Server and a Linux box and a switch with the same tooling and the same standard OIDs, instead of maintaining a separate WMI stack just for the Windows hosts. The Host Resources MIB works here too, so CPU, memory, disk, and uptime read the same as anywhere else. This guide walks through the Windows SNMP setup, the OIDs worth polling, how SNMP compares with WMI, and why an external checker earns its place.

## SNMP support on Windows

Windows has shipped an SNMP Service for decades. It's not installed by default on modern releases — it lives as an optional feature you add — but once enabled, an agent runs on the host and answers polls just like `snmpd` does on Linux. Note the framing: the agent runs *on* the Windows machine, while your monitoring station stays agentless on its side, simply asking questions over the network.

Version support skews conservative. The built-in Windows SNMP Service centers on SNMPv1 and SNMPv2c with community strings and host-based access control — you list which manager IPs may query and under which community. Because v2c sends that community in clear text, keep Windows SNMP on a trusted management network, not exposed to the open internet. If your environment demands authenticated, encrypted polling, that's a reason to weigh SNMPv3-capable tooling or to tunnel the traffic; the native service's strength is simplicity, not cryptography.

One decision worth making early: SNMP or WMI? Both can read Windows health. WMI is Windows-native and exposes an enormous, deeply Windows-specific object model, but it's chatty, heavier, and doesn't help you at all with your switches and routers. SNMP is lighter, standardized, and uniform across your whole fleet. There's a fuller side-by-side in our [SNMP vs WMI comparison](/comparisons/snmp-vs-wmi.md); for mixed environments, SNMP usually wins on consistency.

![Diagram: an external monitor polling a Windows Server SNMP Service for hrProcessorLoad and hrStorageUsed over UDP 161](https://snmp-monitoring.com/img/devices/windows-snmp-poll.webp)

## What you can monitor on Windows

The good news for anyone doing a Windows SNMP setup: the same standard MIBs you use elsewhere apply. The Host Resources MIB (RFC 2790) is implemented on Windows, so the compute-side OIDs carry straight over.

| Metric | OID | Object / MIB |
|---|---|---|
| CPU load (per core) | `1.3.6.1.2.1.25.3.3.1.2` | `hrProcessorLoad`, Host Resources MIB |
| Storage description | `1.3.6.1.2.1.25.2.3.1.3` | `hrStorageDescr` |
| Storage size | `1.3.6.1.2.1.25.2.3.1.5` | `hrStorageSize` |
| Storage used | `1.3.6.1.2.1.25.2.3.1.6` | `hrStorageUsed` |
| System uptime | `1.3.6.1.2.1.25.1.1.0` | `hrSystemUptime` |
| NIC traffic | `1.3.6.1.2.1.2.2.1` | `ifTable`, IF-MIB (RFC 2863) |
| NIC status | `1.3.6.1.2.1.2.2.1.8` | `ifOperStatus`, IF-MIB |

On Windows, the `hrStorage` table enumerates your logical drives — `C:`, `D:`, and so on — plus physical and virtual memory, so a single walk of `hrStorageDescr` labels everything and the matching `hrStorageSize`/`hrStorageUsed` rows give capacity and consumption. `hrProcessorLoad` returns one row per logical processor, exactly as it does on Linux, so a hyper-threaded box hands back a value per thread. IF-MIB covers every network adapter, physical or virtual.

`hrSystemUptime` (`1.3.6.1.2.1.25.1.1.0`) is worth a special mention on Windows: a value that resets to near zero is the cleanest evidence that the server rebooted, planned or not, which is exactly the kind of event you want an alert on.

Here's the honest boundary. Anything deeply Windows-specific — a particular Performance Counter, an IIS metric, an Active Directory health signal, a per-service state — is **not** in these standard MIBs. Those are vendor-specific territory. Don't chase a made-up OID for them; if you need that depth, consult the device's own MIB or reach for WMI for that slice. For the universal vitals in the table above, standard SNMP is enough, and it keeps Windows in the same dashboard as everything else. Our [sensor & OID catalog](/sensors/index.md) documents each standard reading.

## Enabling SNMP — steps

Turning on the Windows SNMP setup follows a predictable path:

1. **Add the feature:** install the SNMP Service via *Optional Features* (or the server role manager). This installs the agent that will run on the host.
2. **Open the service properties:** in the Services console, find *SNMP Service* and open its properties to reach the SNMP-specific tabs.
3. **Set a community string:** on the *Security* tab, add a community with **READ ONLY** rights. Read-only is all monitoring needs, and it means a leaked string can't change the box.
4. **Restrict the managers:** still on *Security*, list the specific IP addresses of your monitoring hosts that are allowed to query, rather than accepting SNMP packets from any host.
5. **Allow the port:** make sure Windows Firewall permits inbound UDP 161 from those manager IPs.
6. **Verify from the manager:** poll the host and confirm real values return before wiring dashboards.

That last check, from your monitoring station, looks like this:

```bash
snmpwalk -v2c -c public 10.0.0.30 1.3.6.1.2.1.25.2.3.1.3
```

- **Drive labels come back** — the service, community, and firewall all agree.
- **Timeout** — usually the firewall or a manager-IP restriction, not the OID.
- **Empty result** — the community may lack read rights, or the OID isn't in scope.

Keep the community string non-obvious and, ideally, change the default port. Our [setup guides](/setup/index.md) cover hardening in more depth.

## Monitoring it externally

Reading `hrProcessorLoad` on demand tells you the Windows Server is healthy at that instant. It won't tell you the moment it stops being healthy — and a monitoring agent installed on the Windows host can't help you when the host is the thing that failed. If a service hangs, a disk fills, or the box blue-screens, the local watcher goes down with it and the alert never leaves the building.

Polling from outside removes that dependency. That's the [double durability](/monitoring/double-durability.md) principle: an independent checker beyond the local network keeps asking your Windows host for its SNMP metrics, so a crashed or unreachable server still trips an alarm somewhere that can reach you. Because SNMP is pull-based, the external side simply polls on its own cadence — and silence from the host is itself a signal worth paging on. Combine it with your on-site [setup](/setup/index.md) and you've covered both angles.

For a zero-setup version, [ostr.io Monitoring](https://ostr.io/service/monitoring) polls your Windows SNMP endpoint from outside your network and sends real-time email and SMS alerts when a metric goes wrong or the host stops answering — no monitoring-side agent, though the Windows SNMP Service still runs on the host.

![Chart: Windows Server C-drive usage and CPU load over several days with an alert threshold line](https://snmp-monitoring.com/img/devices/windows-disk-cpu-chart.webp)


## FAQ

**Does Windows support SNMP out of the box?**
The SNMP Service ships with Windows but isn't installed by default on modern releases — you add it as an optional feature or server role. Once enabled, an agent runs on the host and answers polls with community-based SNMPv1/v2c and host-based access control.

**SNMP or WMI for monitoring Windows?**
WMI is Windows-native and exposes a deeper, Windows-specific object model but is heavier and Windows-only. SNMP is lighter, standardized, and uniform across your whole mixed fleet. For cross-platform monitoring, SNMP usually wins; see our SNMP vs WMI comparison for the full breakdown.

**Which OIDs work on Windows?**
The Host Resources MIB (RFC 2790) is implemented on Windows, so `hrProcessorLoad` (`1.3.6.1.2.1.25.3.3.1.2`), the `hrStorage` table (`1.3.6.1.2.1.25.2.3.1.3/.5/.6`), and `hrSystemUptime` (`1.3.6.1.2.1.25.1.1.0`) all work, plus IF-MIB for NIC traffic.

**How do I monitor an IIS or Active Directory metric over SNMP?**
Those Windows-specific counters aren't in the standard MIBs, so there's no universal OID for them. Consult the relevant vendor MIB if one exists, or use WMI for that particular metric. Don't rely on an invented OID number.

## Conclusion

SNMP Windows monitoring is mostly about getting the built-in SNMP Service configured — add the feature, set a read-only community, restrict the managers, allow UDP 161 — after which the same standard OIDs you use everywhere else (`hrProcessorLoad`, the `hrStorage` table, `hrSystemUptime`, IF-MIB) put your Windows hosts on the same dashboard as the rest of the fleet. Reserve WMI for the deeply Windows-specific metrics, and let something outside the box poll it too, so a downed server still reaches you. Return to the [devices pillar](/devices/index.md) or [home](/index.md) to monitor the rest.