One dashboard that watches your server CPU, memory, internet bandwidth and firewall - and calls you before users start calling you. This is the complete PRTG setup, in the right order.
Most offices learn about a problem when a user shouts about it. A full CPU, a choked internet line or a dead firewall is visible hours before it becomes a complaint - if something is watching. PRTG Network Monitor by Paessler is that watcher: you install it on one Windows machine, it discovers your network, and it keeps testing CPU, RAM, bandwidth and device health every minute. This guide builds the setup in the same order as the video: install, discover, add the four monitoring pillars, then set alerts that mean something.
PRTG's core server runs on Windows - a spare PC or a small VM is fine for a small office. Download the installer from Paessler, run it, and PRTG installs its core server plus a local probe on the same machine. The probe is the worker that actually sends the tests; the core is the brain and the web dashboard.
PRTG's auto discovery scans an IP range and creates devices with starter sensors - ping, and whatever SNMP or WMI answers with. Run it on your office subnet, then clean up: discovery is generous, not wise. Delete sensors you will never read, rename devices to names humans use, and group them - Servers, Network, Printers - before you add anything else. A tidy device tree is the difference between a dashboard and a junk drawer.
For a Windows server, add the WMI CPU Load and WMI Memory sensors. WMI reads the machine's own performance counters, so the numbers match Task Manager. Two honest warnings from real life. First, WMI needs credentials with local admin rights on the target, entered once in the device settings - wrong credentials are the number one reason these sensors show errors. Second, WMI is heavy: Paessler's own guidance is to keep WMI sensors per probe modest (around 120 at a 60-second interval), because every WMI query costs the probe real work. For one server, CPU plus memory is just two sensors - no problem at all.
Bandwidth answers the question every office asks: who is eating the internet? The simple first step is an SNMP Traffic sensor on your router or switch uplink port - it graphs total traffic in and out, cheaply and reliably. That tells you when the line is full. It cannot tell you who filled it. For names and applications you need flow data (NetFlow, sFlow, IPFIX) or the Packet Sniffer sensor, which break traffic into top talkers and protocols - a separate guide in this series compares the three honestly. Start with SNMP totals; add flow only when the "who" question keeps coming back.
Add your firewall as a device. A Ping sensor proves it is alive; an SNMP Traffic sensor on its WAN and LAN ports proves traffic is actually flowing; a Port sensor on your VPN or mail port proves the service outsiders need is really listening. That trio - alive, flowing, serving - is honest firewall status. A ping alone is not: a firewall can answer ping while its VPN service is dead. After any firewall reboot, watch all three return to green before you call it healthy.
Monitoring without alerts is just graph collecting. Set notifications on the few sensors that mean work stops: server down, firewall down, disk nearly full, WAN saturated for a long stretch. Then respect the budget: one sensor is one measured value - CPU is one, RAM is one, each disk is one, each switch port is one. Paessler's own average is 5 to 10 sensors per device. A server with CPU, RAM, two disks and ping is about 5 sensors, so the free 100 go further than people fear - as long as you spend them on values you will act on, not on every port of a 48-port switch.
Every sensor in this guide is created live in the video - installation, discovery, CPU and RAM, bandwidth and firewall status.
Watch Full VideoYes. Paessler's freeware edition gives 100 sensors free for life, with the same alerting, reporting and mapping features as the paid editions. The first 30 days after install are an unlimited trial; when it ends you choose your best 100 sensors and continue free.
One sensor monitors one measured value - the CPU load of a server, the traffic of one switch port, the free space on one disk. A typical device needs about 5 to 10 sensors, so 100 sensors cover a small office if you choose them with discipline.
Not for a small network. PRTG runs comfortably on a modest always-on Windows PC or VM for a few hundred sensors. Very heavy methods - many WMI sensors at short intervals, or packet sniffing on a busy link - are what push hardware, not normal office monitoring.