SNMP Monitoring for Windows Server: OIDs & Limits

By the SNMP Monitoring team · Reviewed July 2026

Windows Server speaks SNMP, and for a mixed fleet that's genuinely useful — a Windows box can appear in the same dashboards as your Linux servers and network gear. But go in with clear expectations. The built-in SNMP Service is legacy: v1/v2c only, cleartext, deprecated in newer releases, and shallower than Windows' own management interfaces. The cross-platform HOST-RESOURCES OIDs work fine for CPU, memory, disk, and processes; the deep Windows internals do not. This guide covers what SNMP sees on Windows, its limits, and when to reach for WMI or a third-party v3 agent instead.

Parent: devices. Related: Windows SNMP setup, SNMP vs WMI.

Enabling SNMP on Windows

SNMP is an optional Windows feature, off by default. You add the SNMP Service feature (via Server Manager or Install-WindowsFeature SNMP-Service), then configure a read-only community and an accepted-hosts list in the service's properties, and open UDP 161 to your manager. The full step-by-step — including the Security and Agent tabs — is on the Windows SNMP setup page, so this guide won't repeat it. In outline the enabling sequence is:

Add the SNMP Service feature (Server Manager or Install-WindowsFeature SNMP-Service).
Set a read-only community in the service's Security tab — never public.
Restrict accepted hosts to your manager's IP(s).
Open UDP 161 in Windows Firewall, scoped to the manager.

The key point for monitoring is that once it's running, a Windows host answers the standard MIBs like any other device, which is what lets it join your existing SNMP monitoring.

The v1/v2c limitation

Before you rely on it, understand the constraint that shapes everything: the built-in Windows SNMP Service supports only SNMPv1 and v2c. There is no native v3, so the community string travels in cleartext, and Microsoft has deprecated the feature in newer Windows releases. That means Windows SNMP is safe only on a trusted management network, hardened with a random community and a tight accepted-hosts list — never exposed, and never assumed to be encrypted. If you need authenticated, encrypted monitoring on Windows, the built-in agent can't provide it; you'd use a third-party v3-capable agent or WMI. The risks of cleartext v2c are detailed on SNMPv1/v2c risks.

Key Windows OIDs

The good news: the cross-platform HOST-RESOURCES-MIB works on Windows, so the core server metrics read the same as on Linux:

Metric	OID
CPU (per processor)	1.3.6.1.2.1.25.3.3.1.2
Storage (drives, incl. C:)	1.3.6.1.2.1.25.2.3.1.{3,5,6}
Running processes	1.3.6.1.2.1.25.4.2.1
Uptime	1.3.6.1.2.1.25.1.1.0

The storage table lists each drive — C:, D:, and so on — alongside physical and virtual memory, with size and used in allocation units, exactly as on any HOST-RESOURCES device. CPU is per-processor load, and the process table enumerates what's running. For a Windows box in a mixed fleet, these cover the essential health metrics.

What SNMP misses on Windows

Here's where the legacy agent shows its limits. SNMP gives you the generic server picture, but Windows holds far more about itself than the standard MIBs expose:

Service states — whether a specific Windows service is running or stopped.
Event log conditions — errors and warnings in the Windows event logs.
Per-application counters — the detailed performance counters Windows tracks.
Deep OS internals — much of what Get-CimInstance surfaces natively.

None of that comes through the built-in SNMP agent. For that depth you use WMI/CIM, Windows' native management interface, which is richer but Windows-only. The trade-off between the two is laid out on SNMP vs WMI.

Reading metrics with snmpwalk

Confirm SNMP works and read the storage table — the most useful Windows walk:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 hrStorageDescr

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical Memory
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: C:\ Label:  Serial Number ...
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: D:\

Those index numbers map each drive and memory area, so you then read hrStorageSize and hrStorageUsed at the same index to compute free space on C:. A quick sysDescr walk confirms it's Windows:

snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 sysDescr.0

SNMPv2-MIB::sysDescr.0 = STRING: Hardware: Intel64 - Software: Windows Version 10.0 (Build 20348)

When to use WMI or a third-party v3 agent

SNMP isn't always the right Windows tool. Choose based on need:

Uniform health across a mixed fleet? → built-in SNMP, on a trusted network.
Deep Windows internals (services, event logs)? → WMI/CIM.
Encrypted, authenticated monitoring? → a third-party SNMPv3 agent, or WMI.
Sensitive data or an untrusted path? → not the legacy SNMP Service.

The built-in agent earns its place for cross-fleet uniformity; for anything requiring depth or security, WMI or a v3-capable agent is the better call. Windows-specific monitoring options are compared on SNMP vs WMI.

Frequently asked questions

How do I monitor Windows Server with SNMP?

Install the SNMP Service feature, configure a read-only community and accepted-hosts list, and open UDP 161 to your manager (see Windows setup). Then poll the cross-platform HOST-RESOURCES OIDs — CPU (…25.3.3.1.2), storage (…25.2.3.1), processes (…25.4.2.1), uptime (…25.1.1.0). Keep it on a trusted network, since the built-in agent is cleartext v1/v2c.

Does Windows SNMP support v3?

No. The built-in Windows SNMP Service supports only SNMPv1 and v2c — there is no native v3 — and Microsoft has deprecated the feature in newer releases. The community string is sent in cleartext, so use it only on a trusted management network. For encrypted, authenticated monitoring, use a third-party v3-capable agent or monitor over WMI instead.

What SNMP OIDs work on Windows?

The cross-platform HOST-RESOURCES-MIB OIDs work: CPU per processor (1.3.6.1.2.1.25.3.3.1.2), the storage table for drives including C: (1.3.6.1.2.1.25.2.3.1), the running-process table (1.3.6.1.2.1.25.4.2.1), and uptime (1.3.6.1.2.1.25.1.1.0). These cover CPU, memory, disk, processes, and uptime — the generic server health picture — the same way they do on Linux.

Should I use SNMP or WMI on Windows?

Use SNMP when you want one protocol across a mixed fleet and need uniform health metrics — CPU, disk, memory, uptime. Use WMI when you need deep Windows-specific data like service states, event-log conditions, or detailed performance counters that SNMP's standard MIBs don't expose. Many environments use both: SNMP for consistency, WMI for Windows depth. See SNMP vs WMI.

Key takeaways

Windows SNMP is legacy: v1/v2c only, cleartext, deprecated — trusted networks only.
The cross-platform HOST-RESOURCES OIDs work: CPU, storage (drives), processes, uptime.
Key OIDs: CPU …25.3.3.1.2, storage …25.2.3.1.{3,5,6}, processes …25.4.2.1, uptime …25.1.1.0.
SNMP misses service states, event logs, and per-app counters — that's WMI territory.
For encryption or Windows depth, use WMI or a third-party v3 agent, not the built-in service.
For independent off-box checks, see external monitoring with ostr.io.

Monitor it from outside the network