Enable SNMP on Windows Server
Setting up SNMP on Windows Server follows the same logic as on Linux, but the mechanics are different. There's no package to apt install and no snmpd.conf to edit — instead, SNMP ships as an optional Windows feature you turn on, and you configure its community strings and permitted hosts through the service's own properties. Once it's running, a Windows box answers the exact same standard OIDs a Linux host does, so any Net-SNMP client can query it and any external monitor can watch it. This guide covers how to enable SNMP on Windows Server, set a read-only community, lock it down, and confirm it responds.
Prerequisites
To enable SNMP on Windows, line up the following first:
- A supported Windows Server edition where the SNMP Service optional feature is still available (it has been deprecated in favor of newer tooling on recent releases, but remains installable as a feature).
- Administrator rights — installing a feature and editing a system service both require them.
- A decision on your read-only community string (a long random value) and the OIDs you plan to expose — sketch that with the OID allowlist concepts.
- A Net-SNMP client on another machine —
snmpget,snmpwalk— to test from off-box. See the Net-SNMP toolkit. - Access to the Windows Firewall so you can permit the SNMP UDP port inbound.
The building blocks map cleanly onto the Linux setup — a service, a community, an allowlist of hosts, a firewall rule — even though the buttons and files are Windows-specific.
Step-by-step
The shape of the job is: add the feature, set the community and hosts, allow the firewall, restart, test. Because the precise UI wording shifts between Windows Server versions, treat the clicks below as the pattern rather than a pixel-perfect script.
- Add the SNMP Service feature. Through Server Manager, use Add Roles and Features and select SNMP Service under Features. (Administrators comfortable with PowerShell can install the same feature from an elevated prompt; the feature name may vary by release, so confirm it on your version rather than assuming.)
- Open the service properties. In the Services console (
services.msc), find SNMP Service, right-click, and choose Properties. This is where Windows keeps what Linux would put insnmpd.conf. - Set the read-only community. On the Security tab, add your community string with READ ONLY rights. Never leave a default like
publicin place. - Restrict who can query. Still on the Security tab, choose Accept SNMP packets from these hosts and list the monitoring source's address — not any host. That's your host allowlist.
- Allow the port through Windows Firewall. Permit inbound UDP 161 (or your chosen custom port) from the monitoring source only.
- Restart the SNMP Service so the settings take effect, and set its startup type to Automatic so it survives a reboot.
That's the whole enable-SNMP-Windows path. A few things are worth calling out because they differ from Linux. First, community and host rules live in the service's Security tab, not a text file — the underlying settings are stored by the service rather than in an editable .conf. Second, Windows exposes the same standard MIBs: the Host Resources MIB (RFC 2790) still serves host uptime at 1.3.6.1.2.1.25.1.1.0, CPU load at 1.3.6.1.2.1.25.3.3.1.2, and storage usage at 1.3.6.1.2.1.25.2.3.1.6, while the IF-MIB (RFC 2863) serves interface counters. So although the setup is Windows-flavored, the data is portable — the sensor catalog applies unchanged. Because exact command syntax and feature names drift across Server releases, verify each on your specific version instead of copy-pasting blindly.
Configuration example
Windows doesn't have a snmpd.conf, so the "configuration" is the set of values you enter in the SNMP Service Security tab. Here's the effective read-only setup as a table:
| Setting | Where | Value |
|---|---|---|
| Community string | Security tab → Accepted community names | <long-random-string>, rights = READ ONLY |
| Accepted hosts | Security tab → Accept packets from these hosts | Monitoring source IP only |
| Send authentication trap | General/Traps tab | Off unless you collect traps |
| Firewall rule | Windows Firewall (inbound) | Allow UDP 161 (or custom port) from the monitoring source |
| Startup type | Services console → SNMP Service | Automatic |
Read that top to bottom and it mirrors a hardened Linux agent: a read-only community, a tight host allowlist, no traps you don't use, and a scoped firewall rule. The standard MIBs it will then serve are the same ones every SNMP agent publishes, so a Net-SNMP client sees a Windows host and a Linux host the same way. The conceptual counterpart on Linux — communities, views, and access rules in a config file — is covered in the snmpd.conf reference.
Verify it works
Test from a second machine, since that's the path a real monitor takes. From any Net-SNMP client, query host uptime on your Windows box:
snmpget -v2c -c <community> <windows-ip> 1.3.6.1.2.1.25.1.1.0
A returned TimeTicks value confirms the service is running, the community matches, and the firewall is letting SNMP through. Walk the processor table to see per-CPU load:
snmpwalk -v2c -c <community> <windows-ip> 1.3.6.1.2.1.25.3.3.1.2
If the query times out, work through it in order: is the SNMP Service actually started, is the community exact, is the querying host in the accepted hosts list, and is UDP 161 open inbound? Any one of those blocks a response. A timeout that survives all four points to a network path or firewall further upstream — the troubleshooting guide has the full sequence.
Security note
SNMP on Windows Server carries the same risks as anywhere, plus the reminder that v2c is not encrypted:
- Never keep a default community. Use a long, random read-only string; treat it as a password. See secure the community string.
- Lock the accepted-hosts list to your monitoring source rather than any host.
- Scope the firewall rule to that same source and nothing wider.
- Move off UDP 161 to a random port where practical to reduce scanner noise — see custom port.
- Remember the wire is clear text under v1/v2c (RFC 1157 / RFC 1901); keep SNMP on a trusted segment or use encryption at the network layer.
The broader threat model lives in the security section.
Next: connect external monitoring
A Windows Server watching itself has the familiar problem — a crash, a blue screen, a hung service, and the local watcher goes down with the box it was supposed to report on. Monitoring from outside sidesteps that. An independent checker on another network keeps polling the agent and turns a silent, dead server into an alert. That's double durability: a second, independent source that catches what the host itself can no longer tell you.
ostr.io Monitoring is agentless from the monitoring side — it polls the standard OIDs your Windows agent already exposes, from outside your network, and fires real-time email and SMS alerts on downtime, slow responses, and resource spikes. With the service verified, add an SNMP endpoint in ostr.io.
