A cluster page under Windows Monitoring Tools | By Ben Monro
The parent guide covers the landscape of windows monitoring tools at a broad level – tool comparisons, pricing philosophy, the agent vs agentless debate, the general “why your monitoring is probably garbage” conversation. This page exists because Windows servers are a different beast entirely.
A Windows desktop going offline costs one person their afternoon. A Windows server going offline can cost a business its day, its data, its dignity, or all three simultaneously. The roles running on those servers (such as DHCP, DNS, Hyper-V, File Services, IIS, RDS, Print Spooler, Certificate Services) each fail in their own special way. Most of them will fail silently, at 2:00 AM on a Friday before a public holiday, while you’re three beers deep and very much off-call.
This guide goes deeper than the parent page – dedicated to Windows Servers.
The parent guide on windows monitoring tools establishes the fundamentals: what monitoring should do, why PerfMon alone isn’t enough, the agent vs agentless tradeoff, Windows server monitoring takes all of that and applies it to infrastructure that actually matters.
A server running DHCP is handing out IP leases to every device on your network. A server running DNS is handling every name resolution query in your environment. A Hyper-V host is running six to twenty virtual machines that other teams are depending on.
When any of those go wrong, it doesn’t just affect one person – it affects everyone.
Windows server monitoring tools that work at this level need to do more than check CPU and disk. They need to understand roles.
The most dangerous monitoring failure isn’t false positives. It’s silence. Your platform reports green, your server is technically up, and the service it’s running has been misbehaving for six hours because nobody thought to check whether the role was healthy, not just the host.
That’s the gap this guide fills.
Before diving role by role, there’s a baseline that every Windows server should have, regardless of what it does. Think of this as the foundation layer. If you don’t have these covered, the role-specific monitoring you layer on top is built on sand.
OS-level baseline for every Windows Server:
This baseline is what separates windows server monitoring tools that do their job from those that just generate pretty graphs nobody reads.
DHCP is the unsung legend of Windows infrastructure. It works perfectly for years. Everyone forgets it exists. Then one day the scope fills up, or the service crashes, or someone accidentally authorises a rogue DHCP server on the network, and suddenly 300 people can’t connect to anything and they’re all blaming the WiFi.
Scope exhaustion is the most common and most avoidable failure. When a DHCP scope runs out of available addresses, new devices (including returning laptops, phones on the corporate WiFi, and servers rebooting) fail to get an IP.
They either grab an APIPA address (169.254.x.x) or sit there unable to communicate. Users see “no internet connection.” IT sees tickets arriving at a rate that questions their career choices.
The insidious part is that scope exhaustion creeps up on you. It doesn’t go from 50% to 100% overnight. It trends slowly – stale leases not being released, DHCP lease times set too long for dynamic environments, guest networks sharing a scope that’s too small.
⚠️ 3 years ago, I was troubleshooting for hours to identify why a new consultant could not connect to the Global Protect VPN. The contractor scope allowed for 5 users, intermittently the consultants would have issues authentication. Eventually I found that consultants would all connect at the same time and bang – no IP addresses left.
A good windows server monitoring tool watches scope utilisation as a percentage and alerts well before it becomes critical. A threshold at 75% gives you breathing room. At 90%, you’re already in triage mode.
The DHCP Server service crashing is less common but devastating when it happens. Event ID 1014 in the DHCP server logs is your first signal. Event ID 1059 tells you authorisation has failed.
The service can also refuse to start after a Windows Update that changes something it depends on and this is where monitoring the Windows service state (DHCPServer) saves you from finding out through the service desk.
Rogue DHCP servers are a security and operational nightmare. A mis-configured VM someone spun up, a network device with DHCP enabled by default, or even a poorly configured VPN client can start handing out addresses that conflict with your legitimate scope.
Monitor for unexpected DHCP servers on your network and set up alerts for lease conflicts.
The Windows Server DHCP role exposes Performance Counters natively. The ones that matter:
Key DHCP Event IDs to watch:
Monro Cloud Monitoring ships with Windows service state checks out of the box, so the DHCPServer service state is one of the first things in your inbox after installation – no custom template work required. Scope utilisation monitoring can be added via a custom check, which the Zabbix-based platform handles cleanly through WMI queries against the DHCP scope object.
These days outages are caused by anything, but if you speak to an engineer from my dads generation, they will still say things like “It’s always a DNS issue”. I mean they didn’t live in a world of wiping out servers with a fat fingered IaC change, but nevertheless it’s still accurate.
Among all the Windows Server roles, DNS is the one where windows server monitoring tools most commonly have shallow coverage. They confirm the DNS service is running. They ping the port. They declare victory and move on. That’s not DNS monitoring.
That’s like asking your wife if she is ok and when she bites back with “YES I’M FINE” you continue on with life. Blissful ignorance for a few hours maybe but mark my words – pain is on its way.
Service state monitoring is table stakes. The DNS Server service (DNS) stopping is an obvious failure, but it’s the least likely way DNS fails in production. More common: the service is running, but it’s not answering queries correctly.
👴 I’ve been doing this for well over a decade and never once have I seen the DNS service just stop.
Resolution testing is the real check. Your windows server monitoring tool should be performing actual DNS queries against your DNS servers and validating the responses. Not just “did it answer?” but “did it answer correctly?”
A monitoring check that queries your internal DNS server for a known internal hostname (and validates the expected IP in the response) will catch misconfigured zones, stale records, and partial outages that a simple port check misses entirely.
Zone transfer health matters in any multi-DNS-server environment. If your secondary DNS servers stop receiving zone updates from the primary, they’ll serve stale data indefinitely. Clients using those secondaries will get wrong answers.
This can cause authentication failures, app connectivity issues, and a wave of tickets that all look unrelated because “DNS is fine, the service is running.” Monitor zone transfer success through Event ID 6702 (success) and 6705 (failure) in the DNS Server log.
Let’s be honest, how often do you check that the root hint servers are actually replying?
DNS forwarder health: if your DNS servers forward external queries to upstream resolvers (ISP DNS, 8.8.8.8, or a security-aware DNS service), you should be testing external resolution separately from internal. If forwarders fail, internal DNS keeps working but external resolution breaks. Half your environment looks fine. The other half is a mystery.
⚠️ People are often lazy about configuring the forwarders in DNS. They assume that root hints will protect them if the forwarders are down. But if you have learnt anything from this article, that only works if the forwarders actually FAIL.
If iinet.com stops responding reliably, that may not be enough to fail over to root hints.
DNS cache poisoning and response anomalies are a security angle. If a DNS server starts returning unexpected records for queries it should know the authoritative answer to, something has gone wrong – either at the forwarder level, the zone level, or (worse) someone has been creative with your infrastructure.
Event ID 4015 in particular is one that r/sysadmin veterans will recognise with the cold dread of someone who has been paged on a Sunday morning. It fires when the DNS server encounters a critical error with Active Directory-integrated zone data (90% of the organisations I have seen are AD integrated), and it tends to appear alongside domain controller replication issues.
More on AD monitoring is covered in the dedicated AD monitoring tools guide, but the cross-role signal here matters.
File servers are the Windows Server role that everyone uses and nobody thinks about until something goes wrong. At which point they think about it very loudly, usually via a call to the service desk that begins with “all my files are gone.”
Disk space monitoring on file servers is non-negotiable. But monitoring a single threshold (say, 85% full) and calling it done is the lazy version. Real file server monitoring using windows server monitoring tools looks at:
🔔 Monro Cloud Monitoring comes out of the box with pre-built alerts to check for rate of change. If someone dumps 700GB of junk in a share, that may change the disk space from 20% to 60% – No alert. We identify that as an alert so you can address it quickly even though it’s not near full capacity.
The Server service (LanmanServer) is the actual Windows service that handles SMB file sharing. If this service stops (and it can, particularly after patches that touch SMB stack components) file shares become completely inaccessible while the server itself pings fine.
Monitoring the Server service state is one of those checks that looks trivial right up until the moment it saves you.
DFS Namespace and DFS Replication deserve their own monitoring strategy in environments that use Distributed File System. DFS-N (Namespace) handles path resolution — the \domain\share path that clients use. DFS-R handles the actual replication of data between servers. Both can fail independently and in instructive ways:
Monro Cloud Monitoring handles Windows service state checks through pre-configured templates delivered at sign-up, which means the Server, DFSR, and DFS services are covered from the moment the agent is installed.
Scope growth and custom threshold triggers can be configured without needing to understand Zabbix template XML from scratch.
Hyper-V monitoring is a two-layer problem. You have the physical host, and you have the virtual machines running on it. Both can fail and both can degrade each other.
The Hyper-V host exposes a set of Performance Counters that are essential for understanding how the physical machine is supporting its guests. These are separate from the standard Windows OS counters and specific to the hypervisor role:
CPU:
Hyper-V Hypervisor\Total Pages
Hyper-V Hypervisor Logical Processor\% Total Run Time
Hyper-V Hypervisor Virtual Processor\% Guest Run Time
% Hypervisor Run Time
Memory:
Hyper-V Dynamic Memory Balancer\Available Memory
Hyper-V Dynamic Memory VM\Physical Memory
Storage:
Hyper-V Virtual Storage Device\Read Bytes/sec
Write Bytes/sec
Hyper-V Virtual Storage Device\Error Count
Network:
Hyper-V Virtual Network Adapter\Bytes Received/sec
Bytes Sent/sec
Hyper-V Virtual Switch\Dropped Packets Outgoing/sec
Each VM needs to be monitored as a system in its own right. This is where windows server monitoring tools that work at the Hyper-V level need to either reach inside the VM (via agent) or collect from the host on behalf of the VM. Agent-inside-VM is almost always the better approach for depth of data.
A Hyper-V host that looks healthy but is running a VM with a runaway process consuming all available vCPU will cause performance problems for other VMs on the same host. Without per-VM monitoring, you’ll see symptoms everywhere and the cause nowhere.
The Hyper-V role depends on several Windows services that, if stopped, bring the entire virtualisation layer down:
Monitoring these service states is non-negotiable on any Hyper-V host. The vmms service in particular has a history of being impacted by Windows Server cumulative updates.
Internet Information Services (IIS) hosts internal applications, company intranets, web-based management tools, and in some environments, production-facing services.
⚠️ For those who don’t know, IIS turns a server into something that can host a website.
IIS Application Pools are the sandboxed processes that run web applications. They crash. They recycle. They run out of memory. They timeout and when they do, the application they host stops responding – but IIS itself keeps running, the server is still up, and your basic ping check reports everything as fine.
Windows server monitoring tools need to monitor Application Pool state explicitly. Key metrics:
It is recommended to monitor the SSL health of the IIS certs. These can break overnight and in my personal opinion are the cause of a HUGE percentage of modern outages.
Event ID 1000 and 1001 (Application Pool crash and restart) in the Windows Application log, and the IIS-specific logs under Applications and Services\Microsoft\Windows\IIS-Configuration, are the first place to look when applications start throwing errors. A monitoring platform that aggregates these and correlates them with performance data saves hours of log hunting.
Applications and Services\Microsoft\Windows\IIS-Configuration
RDS environments are where sysadmin stress goes to compound. You have session brokers routing users to session hosts. You have licensing servers that the entire environment silently depends on. You have user profiles loading over the network.
RDS Licensing Server is the silent killer. The RDS licensing grace period is 120 days after the Remote Desktop Session Host role is installed. After that, if a valid licensing server isn’t configured and reachable, users get disconnected with an error that looks completely unrelated to licensing.
Monitoring the RDS License Server service state and the Event Log for Event ID 44 (licensing warning) and Event ID 1128 (license server unavailable) is essential.
Session Host performance:
Profile load times – slow RDS login is often a profile problem. Roaming profiles loading from a file share, folder redirection pointing at a saturated server, and Group Policy applying dozens of preferences all contribute to login times that make users actively hostile. Monitoring the UserPV/UserLogon events gives insight into where login time is being spent.
RD Gateway health – if your RDS environment is accessed remotely through an RD Gateway, that gateway’s SSL certificate expiry, service state (TSGateway), and connection broker availability are all single points of failure for remote workers.
Print Spooler is perhaps the single most crash-prone service in the history of Windows Server. It has been crashing since Windows NT 4.0. It is still crashing today. The only thing more inevitable than Print Spooler crashing is someone trying to print something important when it does.
The PrintNightmare vulnerability saga (CVE-2021-1675 and CVE-2021-34527) added another layer to print server monitoring: you now need to care about security configuration, not just service health.
It really is a ghastly service. I still can’t believe there are vendors out there trying to make printing sexy, it’s old, annoying to manage and gives you the fun feeling that you’re shredding oxygen producing trees while you sit in an office surrounded by petrol fumes.
If the world can go from office jobs to working from home in a single week – your company can live without paper. But enough of my printing rants.
The Spooler service (Spooler) – service state monitoring is the minimum. When Spooler crashes, all printing stops immediately across every printer managed by that server. Event ID 7031 in the System log signals an unexpected service termination. Event ID 7034 signals it was terminated unexpectedly for the second (or more) time and Windows has given up trying to restart it.
Print job queue depth – a growing print queue that isn’t shrinking is a stuck job situation. The old dude who tried to use his own paper to make flyers has screwed up the whole system.
Stuck print jobs block everything behind them in the queue and require manual intervention. \Print Queue\Jobs is the counter to watch. If the queue starts growing without shrinking, the stuck job alarm should be firing.
\Print Queue\Jobs
Print driver health – this one is tricky. Driver issues on print servers are responsible for a disproportionate share of Spooler crashes. There’s no great performance counter for this, but monitoring the Application and System event logs for Spooler-related faults (Event IDs 1000, 7031, 7034) and correlating them with timestamps of driver installations helps identify patterns.
Driver isolation mode – since PrintNightmare, print driver isolation matters from a security perspective. Monitoring the registry key HKLM\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled and the Group Policy controlling driver installation should be part of your security-aligned monitoring.
HKLM\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled
Active Directory Certificate Services (ADCS) is the Windows PKI role that issues internal SSL certificates, code signing certificates, and most critically, the certificates used by your domain infrastructure.
It is also the service that, when misconfigured or ignored, produces the most spectacular cascading failures possible.
Certificate expiry is the gift that keeps giving – every few years, some certificate expires, something breaks, nobody can find documentation about why it was issued or what depends on it, and you spend three days tracing the dependency chain.
CA Service health (CertSvc) – the Certificate Authority service state. If this service stops, no new certificates can be issued. Existing valid certificates keep working until they expire, at which point things break quietly and in series.
Certificate expiry monitoring – this is the most important and most commonly missing check in Windows PKI environments. You need to monitor:
A certificate expiry alert at 60 days gives you time to plan. At 30 days, you’re reacting. At 7 days, you’re performing emergency surgery. At 0 days, your entire environment is having a very bad time.
Certificate Revocation List (CRL) availability – the CRL must be accessible to every client that validates certificates in your environment. If the CRL distribution point becomes unavailable, certificate validation fails for every certificate the CA has issued.
This is a lesser-known failure mode that produces symptoms scattered across every service using certificates, making diagnosis genuinely confusing if you don’t know to look for it.
If you’re running WSUS, you have a server that’s responsible for distributing patches across your entire Windows fleet. When WSUS breaks, clients either fail to update (security exposure) or hammer Microsoft’s update servers directly (bandwidth and policy violation).
WSUS service health (WsusService) – if the service stops, clients can’t check in. They’ll queue up and either fail silently or fall back to Windows Update directly.
IIS Application Pool for WSUS – WSUS runs on IIS. The WsusPool application pool has a memory limit set at 1.8GB by default, which is wildly insufficient in larger environments and causes it to crash regularly. Monitoring this app pool state and memory usage is essential. The fix is well-documented (increase the private memory limit or set it to 0 for unlimited), but you need to know when it’s happening.
WSUS database size and synchronization – the WSUS database (SUSDB) grows continuously. An un-maintained WSUS database will slow down client check-ins, admin console operations, and synchronization. If you’re running WSUS on Windows Internal Database (WID), the database is in C:\Windows\WID\Data and grows without bound unless you run cleanup regularly. Monitor the database size and last successful synchronisation timestamp.
C:\Windows\WID\Data
Client compliance reporting – the number of clients that haven’t checked in for more than a week is a useful operational metric. Clients that stop checking in might have WSUS client issues, network connectivity problems, or (more alarmingly) be compromised and blocking update checks.
Every section above has mentioned Event IDs. That’s not an accident. Event Log monitoring is how windows server monitoring tools get specific enough to be useful. Generic host monitoring tells you something is wrong. Event Log monitoring tells you what is wrong, when it started, and often gives you enough context to fix it without a guessing game.
The problem with Event Log monitoring is volume. Windows Server generates an enormous number of events. A domain controller with normal activity can generate tens of thousands of events per day. Trying to monitor “all events” produces noise that makes the signal invisible.
The strategy is targeted monitoring of high-signal Event IDs per role:
Event ID 41 (Kernel-Power, “System has rebooted without cleanly shutting down first”) deserves particular respect. If you get this on a production server outside a maintenance window, something rebooted it without warning – power loss, BSOD, watchdog trip. That’s an incident, not a blip.
All of the monitoring described above (DHCP scope utilisation, DNS resolution testing, DFS-R replication backlog, Hyper-V service states, certificate expiry, WSUS pool health) requires a platform that:
That’s a meaningful set of requirements. Most platforms in the “top 10” lists meet it in theory. The gap is in practice, how much work does it take to configure all of this, and do you trust the platform enough to believe the silence when nothing is alerting?
Monro Cloud Monitoring is built on the Zabbix engine, which is arguably the most capable open-source monitoring platform for Windows infrastructure.
But the raw Zabbix experience (setting up hosts, templates, triggers, user groups, permissions, media types, proxy configuration) is just S**T!
Monro Cloud solves that with automation built around simplicity. When you sign up, you receive an email with a custom-built Windows agent that is pre-configured for your environment specifically.
Not a generic installer. Not a “download this and figure out the configuration yourself.” A ready-to-run package. Host groups, user groups, permissions, email notification, and SMS are all pre-configured before you install a single agent.
Yep, 4 inputs and the whole environment is built for you.
This matters for windows server monitoring tools specifically because the role-specific monitoring described in this guide (DHCP service checks, DNS resolution tests, file server storage trending, Hyper-V service states, certificate expiry) can be configured in Zabbix templates that are applied per server role.
A DHCP server gets the DHCP template. A Hyper-V host gets the Hyper-V template. A file server gets file server checks.
The Zabbix trigger system is powerful enough to express the nuanced alerting that real Windows environments need:
None of this requires complex setup with Monro Cloud. The pre-configured agent and templates give you baseline coverage immediately. Role-specific additions are straightforward because the infrastructure is already there.
Among the windows server monitoring tools available today, very few hit this combination of depth, simplicity, and cost-sanity simultaneously.
Pricing reality check: $1.50 per device per month. For a Windows server environment with 30 servers, that’s $45/month to have everything described in this guide monitored, alerted, and reported (including free SMS alerts)
The alternative is spending weeks configuring a self-hosted platform, or paying $15+/device/month for a SaaS platform that does less for Windows-specific roles and sends you a bill that makes you question your life choices.
One well-configured platform should cover all of it. The key is whether the platform supports role-specific templates, service state monitoring, event log parsing, and custom Performance Counter collection.
A platform that can do all of that (and alert on role-specific conditions) is all you need. You don’t need a DHCP monitoring tool, a DNS monitoring tool, and a Hyper-V monitoring tool separately.
You need one windows server monitoring tool that is flexible enough to cover all of them from a single agent. The best windows server monitoring tools are the ones that arrive pre-configured and don’t require a PhD in the underlying platform to set up.
Service state monitoring. Most teams monitor CPU, memory, and disk. Almost nobody monitors whether the actual service the server exists to run is still running. A DHCP server with 5% CPU, 20% memory, and plenty of disk space but a crashed DHCPServer service is completely non-functional. You won’t know until the helpdesk calls.
The Hyper-V host itself exposes per-VM performance data through the Hyper-V namespace Performance Counters. You can collect CPU, memory, disk I/O, and network metrics for all VMs from the host alone without agents inside the VMs.
The tradeoff is that you get coarser data, you’ll see a VM is consuming resources but won’t have visibility into what inside the VM is causing it. For full depth, agents inside VMs are the right answer. For broad coverage fast, host-side counters are a pragmatic starting point.
Both, in the sense that you need monitoring to know it’s happening, and you need to fix WSUS once you know. The immediate fix is to increase the Private Memory Limit for the WsusPool application pool in IIS (from the default 1,843,200 KB to something much higher, or 0 for unlimited).
The monitoring fix is to watch the WsusPool application pool state and alert when it transitions to Stopped – which is the symptom of the crash that makes WSUS completely unavailable to clients.
Let’s Encrypt certificates are valid for 90 days and renew automatically when the renewal process is working correctly. The monitoring question is: are you monitoring whether the renewal process is actually working?
A renewal that fails silently leaves you with a certificate that expires in 90 days while you believe it’s handled. Monitor the certificate expiry date directly (not the renewal process) so that any renewal failure produces an alert from the certificate’s own expiry countdown.
A well-designed agent (including the Zabbix-based agent in Monro Cloud Monitoring) typically uses less than 1% CPU and under 50MB of memory on a normal Windows Server.
The collection is passive between intervals and bursts briefly during active checks. For most production servers, this overhead is genuinely unmeasurable against normal workload variance. The question is worth asking of any vendor, and any vendor that can’t give you a concrete answer probably hasn’t tested it seriously.
Related reading from Monro Cloud:
Monro Cloud Monitoring – Pre-configured Windows server monitoring at $1.50/device/month. Sign up, receive your custom agent by email, install it, done.
