---
type: Article
title: "Enable SNMP on Windows Server"
description: "SNMP ships as an optional Windows feature, not a package. Turn it on, set a read-only community and permitted hosts, and answer the same OIDs Linux does."
resource: "https://snmp-monitoring.com/setup/windows-server/"
tags: [setup, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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](/setup/oid-allowlist.md) concepts.
- A **Net-SNMP client** on another machine — `snmpget`, `snmpwalk` — to test from off-box. See the [Net-SNMP toolkit](/tools/net-snmp.md).
- 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.

1. **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.)
2. **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 in `snmpd.conf`.
3. **Set the read-only community.** On the **Security** tab, add your community string with **READ ONLY** rights. Never leave a default like `public` in place.
4. **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.
5. **Allow the port through Windows Firewall.** Permit inbound **UDP 161** (or your chosen custom port) from the monitoring source only.
6. **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](/sensors/index.md) 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](/setup/snmpd-conf.md).

![Windows Server SNMP Service properties open on the Security tab to enable SNMP on Windows with a read-only community](https://snmp-monitoring.com/img/setup/snmp-windows-server-security-tab.webp)

## 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:

```bash
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:

```bash
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](/setup/troubleshooting.md) 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](/setup/secure-community-string.md).
- **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](/setup/custom-port.md).
- **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](/security/index.md).

## 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](/monitoring/double-durability.md): a second, independent source that catches what the host itself can no longer tell you.

[ostr.io Monitoring](https://ostr.io/service/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](/setup/add-endpoint-ostrio.md).

![Diagram of an external monitor polling a Windows Server SNMP agent over UDP and sending email and SMS alerts](https://snmp-monitoring.com/img/setup/windows-external-snmp.webp)

## FAQ

**Does Windows Server include SNMP, or do I install it?**
It's an optional feature, not on by default. You add the SNMP Service through Add Roles and Features (or the equivalent feature-install command for your release), then configure it in the Services console. Note that Microsoft has deprecated the SNMP Service on newer Server versions, though it usually remains installable as a feature.

**Where do I set the community string on Windows — there's no snmpd.conf?**
Correct, there's no config file to edit. Community strings and the accepted-hosts allowlist live on the **Security** tab of the SNMP Service's properties in the Services console. That tab is the Windows equivalent of the community, view, and access lines you'd write in `snmpd.conf` on Linux.

**Can Linux tools query a Windows SNMP agent?**
Yes. Windows serves the same standard MIBs — Host Resources MIB, IF-MIB — so any Net-SNMP client (`snmpget`, `snmpwalk`) queries it exactly as it would a Linux host. The OIDs are identical; only the setup differs.

**Why does my Windows SNMP query time out?**
Check four things in order: the SNMP Service is started, the community string matches exactly, the querying host is in the *accept packets from these hosts* list, and UDP 161 (or your custom port) is open inbound in Windows Firewall. Missing any one produces a timeout.

## Conclusion

Enabling SNMP on Windows Server comes down to four moves: add the SNMP Service feature, set a read-only community and a tight accepted-hosts list on the Security tab, open the SNMP UDP port to your monitoring source, and restart the service. There's no `snmpd.conf` — Windows keeps those settings in the service properties — but the standard OIDs it serves are identical to Linux, so any Net-SNMP client can read it. Verify from a second machine, keep the community and host list locked down, then let an external monitor watch the box so a crash still reaches you.