Running a network monitoring server on Windows

Install guides from the mid-2000s built monitoring servers on Windows XP by hand: Apache, PHP, MySQL, a Windows build of the SNMP tools, and a scheduled task standing in for cron. There are better routes now, and the right one depends on why Windows is involved: the only spare machine runs Windows 11, policy says every server runs Windows Server, or you need to watch Windows hosts. Sizing and the first hour after install are the same on any platform; the chapter on setting up a monitoring server covers them.

Pick a shape before you pick a tool

Most open-source monitoring servers are written for Linux first. The Zabbix server, for example, is not supported on Windows at all; its Windows support is the agent. So the real question is how to give a Linux monitoring stack a home, or whether a smaller native tool is enough.

For a monitor that will run for years, a Hyper-V virtual machine is the least surprising choice. With an external virtual switch it gets its own LAN address, receives traps and syslog like any Linux server, and starts with the host:

New-VMSwitch -Name "LAN" -NetAdapterName "Ethernet" -AllowManagementOS $true
Set-VM -Name "nms01" -AutomaticStartAction Start -AutomaticStartDelay 60

WSL 2: a real Linux kernel, with caveats

WSL 2 runs a genuine Linux kernel in a lightweight utility VM, so after wsl --install -d Ubuntu the usual packages for net-snmp, rsyslog and most monitoring tools install normally. Three behaviors matter.

Networking first. By default WSL 2 sits behind NAT with a private address. LAN devices cannot reach it, and the usual workaround, netsh interface portproxy, forwards TCP only, so traps on UDP 162 and syslog on UDP 514 never arrive. On Windows 11 22H2 and later, mirrored mode gives Linux the host's own interfaces. Set it in %UserProfile%\.wslconfig:

[wsl2]
networkingMode=mirrored
memory=6GB

[general]
instanceIdleTimeout=-1

Mirrored traffic also passes the Hyper-V firewall. In a PowerShell window run as administrator:

$wsl = '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'   # WSL's documented VMCreatorId
New-NetFirewallHyperVRule -DisplayName "WSL SNMP traps" -Direction Inbound -VMCreatorId $wsl -Protocol UDP -LocalPorts 162 -RemoteAddresses 10.20.0.0/16
New-NetFirewallHyperVRule -DisplayName "WSL syslog" -Direction Inbound -VMCreatorId $wsl -Protocol UDP -LocalPorts 514 -RemoteAddresses 10.20.0.0/16

Lifetime second. WSL starts when someone runs it and shuts an idle distribution down after a short timeout, and turning on systemd in /etc/wsl.conf does not keep it alive by itself. The instanceIdleTimeout=-1 line disables that shutdown at the time of writing, but these settings have changed between WSL versions. To start the distribution with nobody signed in, add a Task Scheduler job with an "At startup" trigger, set to run whether the user is logged on or not, whose action keeps one process attached:

wsl.exe -d Ubuntu --exec sleep infinity

Reboot and confirm that the pollers run before anyone logs in.

Memory third. The WSL 2 VM may use up to half the host's RAM by default; the memory= line caps it.

Containers on a Windows host

Docker Desktop runs Linux containers on a WSL 2 back end. Two catches matter. It is a desktop application that starts when a user signs in, not a service that starts at boot. And published ports pass through its own networking layer, so at the time of writing a container generally sees that layer's address as the source rather than the device that sent the trap. Most monitors identify senders by source address, so every trap appears to come from one host. Docker's licence terms also require a paid subscription for commercial use in larger organizations.

Containers suit tools that only poll outward: an uptime checker, an exporter, a dashboard. Run trap and syslog receivers in a Hyper-V VM instead.

Tools that run natively

• Agents. Zabbix agent 2 ships as an MSI for Windows 10 and Windows Server 2016 or later (at the time of writing) and listens on TCP 10050. The Prometheus community's windows_exporter runs as a service on TCP 9182. Checkmk, Icinga and Nagios-style tools have Windows agents too.
• Uptime checks. Uptime Kuma runs on Windows with Node.js and covers HTTP, TCP, ping and DNS checks.
• SNMP command-line tools. The Windows installers in the net-snmp project's own download area date from around 2011; newer builds come from third parties or from compiling the source. Inside WSL, sudo apt install snmp gives you a maintained snmpget, snmpwalk and snmptrap.
• Packet capture. Wireshark runs natively and proves that a trap reached the network card.

Windows' own SNMP service

Windows still offers an SNMP agent as an optional feature (a Feature on Demand since Windows 10 version 1809). Microsoft deprecated it starting with Windows Server 2012 and points to CIM over WS-Management (WinRM) instead. It speaks SNMPv1 and v2c only, so the community string crosses the network in clear text. Use it only for a legacy tool that can do nothing else, with a read-only community that is not public, accepting packets only from your poller.

Its companion, the SNMP Trap service, matters even if you never use the agent: when running, it holds UDP 162 and stops snmptrapd or any other receiver on the same machine from binding the port.

Get-WindowsCapability -Online -Name "SNMP*"
Get-NetUDPEndpoint -LocalPort 162 | Select-Object LocalAddress, OwningProcess
Stop-Service SNMPTRAP; Set-Service SNMPTRAP -StartupType Disabled

Quick checks from PowerShell

Test-Connection 10.20.4.11 -Count 4            # ICMP echo
Test-NetConnection 10.20.4.11 -Port 443        # TCP connect
Test-NetConnection 10.20.4.11 -TraceRoute      # the path, hop by hop

Test-NetConnection tests TCP only, so it cannot tell you whether UDP 161 or 162 gets through. For SNMP, send a real query with snmpget and, if it times out, capture on both ends to see which side drops it.

Watching Windows hosts themselves

Windows servers on your network need watching too, and SNMP is the weakest way to do it.

For agentless polling, turn on WinRM with Enable-PSRemoting and give the monitor a dedicated account with only the rights it needs (Remote Management Users plus WMI namespace permissions), never a domain admin.

Windows does not send syslog by itself. Windows Event Forwarding is built in: hosts push selected events over WinRM to a Windows Event Collector. Otherwise, put a small shipper on each host, such as NXLog Community Edition or Fluent Bit with its winevtlog input, and forward to your syslog collector over UDP 514, or TCP where losing lines matters. Start with a short list:

Getting those lines into the monitor is covered in the chapter on feeding your monitor from outside programs.

Keeping it up: sleep, updates and boot

The most common failure of a monitor on Windows is not software. The machine went to sleep.

powercfg /change standby-timeout-ac 0
powercfg /change hibernate-timeout-ac 0

Also clear "Allow the computer to turn off this device to save power" for the network adapter in Device Manager, and set the firmware to power on after a power cut.

Windows restarts itself to finish updates. On Windows 11, set active hours and, on Pro and higher, use Group Policy to control automatic restarts. On Windows Server, set updates to download only or manual and install them in a window you choose. Windows 10 reached end of support on October 14, 2025, so a monitor still on it gets no security fixes unless it is covered by Extended Security Updates. Add an outside heartbeat so that the monitor going quiet is itself noticed, as the chapter on running a monitoring server describes.

Anything native should run as a service that starts automatically and restarts on failure:

Set-Service -Name MyAgent -StartupType Automatic
sc.exe failure MyAgent reset= 86400 actions= restart/60000/restart/60000/restart/60000

Type sc.exe in full: in Windows PowerShell, plain sc is an alias for Set-Content. For clocks, check the Windows Time service with w32tm /query /status, and inside WSL or a VM run timedatectl after any host sleep.

Windows Defender Firewall rules

Windows Defender Firewall allows outbound traffic by default and tracks the replies, so SNMP polls out on UDP 161 normally need no rule. Inbound traffic does. Scope rules to the management network and the Domain and Private profiles, and check with Get-NetConnectionProfile that the network is not classed as Public.

$mgmt = '10.20.0.0/16'
New-NetFirewallRule -DisplayName "SNMP traps in" -Direction Inbound -Protocol UDP -LocalPort 162 -RemoteAddress $mgmt -Profile Domain,Private -Action Allow
New-NetFirewallRule -DisplayName "Syslog in" -Direction Inbound -Protocol UDP -LocalPort 514 -RemoteAddress $mgmt -Profile Domain,Private -Action Allow

If the machine is itself polled over SNMP, allow UDP 161 inbound from the poller's address only. For WSL in mirrored mode, add the Hyper-V rules shown earlier as well. Then send a test trap from another machine and watch it arrive; the chapter on SNMP traps covers the receiver.

Checklist

• Shape chosen: a Hyper-V VM for always-on, WSL 2 or containers for trials, native tools for small jobs.
• A supported Windows release, with updates and restarts scheduled.
• Sleep and hibernation off, adapter power saving off, power-on after an outage set in firmware.
• The monitor starts with nobody signed in, proven by a real reboot.
• Under WSL: mirrored networking, idle shutdown disabled, a memory cap, Hyper-V rules for UDP 162 and 514.
• The Windows SNMP Trap service disabled wherever another receiver needs UDP 162.
• Defender Firewall open for UDP 162 and 514 from the management network only.
• Windows hosts watched by an agent or WinRM, with key event IDs forwarded.
• An outside heartbeat that notices when the Windows machine itself goes quiet.

Once the monitor runs, the rest of the field manual applies as written.