For many years, BIG-IP administrators could use the WMI performance monitor to make load balancing decisions based on the health and utilization of Microsoft IIS servers. While the monitor fulfilled an important role, modern application architectures increasingly rely on HTTP-based readiness and health endpoints instead of platform-specific monitoring technologies. The original WMI monitor was designed to collect performance data from Microsoft IIS servers and use that information to influence Dynamic Ratio load balancing decisions.
I wanted a modern alternative that preserved the original goal of the WMI monitor while using a simpler, application-aware approach. The result is an IIS-hosted health endpoint that evaluates server health locally and exposes the result through a standard HTTP response that BIG-IP can consume using an ordinary HTTP monitor.
In this article, I’ll walk through the challenges that led me to build this community-supported solution, the design decisions behind it, and the implementation details of the IIS10-Health-Check project. Then we’ll take a look at the finished architecture and, as always in this series, see how I did it.
Why Move Away from WMI?
Before diving into the solution, it’s helpful to understand the challenges that made the legacy approach increasingly difficult to maintain.
The BIG-IP WMI monitor relied on multiple components working together, including Windows Management Instrumentation (WMI), IIS-hosted F5 data gathering agents, Windows performance counters, authentication credentials, and communication between BIG-IP and the monitored IIS server. The architecture also required F5-specific IIS plug-ins such as F5Isapi.dll or F5.IsHandler.dll to expose performance information to BIG-IP.
While this design was innovative when first introduced, modern Windows environments have become significantly more security conscious and operationally standardized. Organizations increasingly restrict WMI access, harden service accounts, and seek to minimize dependencies on proprietary agents and platform-specific monitoring technologies. As a result, troubleshooting WMI-based monitoring can become more complex than the problem it’s intended to solve.
The WMI monitor was also designed around server performance metrics and Windows-specific monitoring components. Modern environments increasingly favor lightweight HTTP-based health validation that is simpler to deploy, secure, and operate.
F5 has since archived the WMI monitor documentation, making it clear that it is no longer a recommended solution for new deployments.
Rather than attempting to modernize the original WMI architecture, I chose to solve the underlying requirement differently.
The Goal
The objective was straightforward:
Enable BIG-IP to direct traffic only to IIS servers that are capable of servicing requests while eliminating the complexity associated with legacy WMI-based monitoring.
The solution needed to:
- Use standard BIG-IP HTTP or HTTPS monitors
- Require no BIG-IP plug-ins or special monitor types
- Avoid WMI dependencies
- Evaluate IIS server health locally
- Support resource-based decisions such as CPU utilization, available memory, free disk space, and IIS request queue length
- Return a simple up/down result that BIG-IP can immediately consume
Solution Overview
The resulting architecture is intentionally simple while remaining highly extensible.
Rather than relying on WMI, IIS plug-ins, or external data collection agents, the solution deploys a lightweight .NET-based health-check sidecar application alongside IIS. The implementation process is straight forward.
BIG-IP performs a standard HTTP or HTTPS monitor request against the health endpoint, and the application evaluates the local server’s condition before returning an appropriate HTTP status code.
The sidecar application evaluates a configurable set of health criteria defined in its configuration file. This allows administrators to adjust thresholds without modifying application code and provides a flexible foundation for future enhancements.
If all configured checks pass, the endpoint returns an HTTP 200 response and BIG-IP continues sending traffic to the server.
If one or more checks exceed configured thresholds, the endpoint returns HTTP 503, allowing BIG-IP to automatically remove the server from service until conditions improve.
Monitored Metrics
The current version of the solution focuses on four key workload and capacity indicators commonly associated with IIS server health and responsiveness.
CPU Utilization
The endpoint monitors overall system CPU utilization and compares the current value against a configurable threshold. Excessive CPU consumption can indicate that the server is approaching saturation and may no longer be able to efficiently process additional requests.
Available Memory (RAM)
Available system memory is evaluated to identify memory pressure conditions that could impact application responsiveness or server stability. Administrators can configure minimum available memory thresholds based on application requirements.
Free Disk Space
The solution monitors available disk capacity and can identify situations where the server is running critically low on free space. This helps prevent issues related to logging, temporary file creation, application updates, and normal operating system functions.
IIS Request Queue Length
The endpoint monitors the IIS request queue length to identify situations where incoming requests are accumulating faster than they can be processed. A growing queue often indicates resource contention or application bottlenecks and can serve as an early warning sign before users experience noticeable performance degradation.
Configurable Thresholds
All monitored metrics use configurable thresholds defined in the application’s configuration file. This allows administrators to tune monitoring criteria for individual applications and server roles without modifying application code.
How the Solution Works
The IIS10-Health-Check solution uses a lightweight .NET-based sidecar application hosted by IIS. A dedicated IIS application pool isolates the health service from the applications being load balanced, allowing health evaluation to occur independently of the workload being monitored.
When BIG-IP performs a monitor request, the sidecar endpoint gathers real-time operating system and IIS performance metrics directly from the local server. Rather than relying on WMI, external data collection agents, or proprietary IIS plug-ins, the application evaluates the server’s health locally and returns a simple HTTP response that BIG-IP can consume using a standard HTTP or HTTPS monitor.
The current implementation evaluates four key health indicators:
- CPU utilization
- Available system memory (RAM)
- Available disk space
- IIS Request Queue Length
Each metric is compared against configurable thresholds defined in the application’s configuration file. This allows administrators to tune acceptable operating limits based on the characteristics of their applications and infrastructure without modifying application code.
A simplified configuration workflow looks like this:
If all monitored values remain within their configured thresholds, the endpoint returns an HTTP 200 response and BIG-IP continues sending traffic to the pool member.
If any monitored metric exceeds its configured threshold, the endpoint returns an HTTP 503 Service Unavailable response, allowing BIG-IP to automatically remove the server from service until conditions return to acceptable levels.
This approach eliminates the need for:
- WMI connectivity
- WMI credentials
- F5 ISAPI handlers
- Data collection agents
- External WMI performance monitoring dependencies
Instead, the server evaluates its own health and exposes the result through a lightweight HTTP endpoint using a monitoring model that is simple to deploy, easy to troubleshoot, and aligned with modern health-check practices.
BIG-IP Configuration
One of the benefits of this approach is that no special monitor type is required.
A standard HTTP or HTTPS monitor can be used.
Example send string:
GET /healthcheck HTTP/1.1
Host: myapplication.example.com
Expected receive string:
200 OK
When your backend application servers run on web ports (such as HTTP 80, HTTPS 443, or a custom application port), but your health check sidecar is hosted on port 8080 (or your chosen custom management port), you configure the BIG-IP health monitor using an Alias Service Port.
For complete end-to-end reliability, I would recommend using a Dual-Monitor Strategy on BIG-IP:
- Sidecar Probe (Port 8080 or custom sidecar port): Monitors OS-level CPU and RAM performance.
- Application Probe (Port 80, 443, or custom application port): Probes the actual web application endpoint to verify application layer health.
Associate the monitors with the appropriate pool members and BIG-IP will automatically remove unhealthy nodes when the endpoint returns a failure status.
Benefits of the Approach
After implementing the solution, several advantages became immediately apparent.
Simplified Deployment
- No IIS plug-ins are required
- No F5-specific data collection agents are required
- No WMI configuration is required
Improved Security
The solution eliminates the need for dedicated WMI monitoring credentials and associated permissions.
Easier Troubleshooting
The endpoint can be tested directly from a browser, PowerShell session, or command line:
curl http://server/healthcheck
Administrators can immediately validate the server’s health state without having to troubleshoot WMI communications, authentication issues, or performance counter collection.
Standard Monitoring Model
Because the endpoint uses standard HTTP response codes, the design aligns with modern health monitoring practices used throughout cloud-native applications, load balancers, and container platforms.
Flexible Design
Thresholds can be adjusted through configuration, allowing the same solution to be used across a wide variety of IIS workloads and deployment scenarios.
Final Thoughts
The original WMI performance monitor gave BIG-IP valuable insight into IIS server performance, but it relied on WMI, IIS plug-ins, authentication requirements, and Windows-specific monitoring components that are no longer recommended for new deployments.
The IIS10-Health-Check project takes a simpler approach. A lightweight .NET sidecar application evaluates key server health metrics including CPU utilization, available memory, free disk space, and IIS request queue length, then exposes the result through a standard HTTP endpoint that BIG-IP can monitor natively.
By replacing proprietary monitoring dependencies with a straightforward HTTP-based health check, the solution is easier to deploy, easier to troubleshoot, and better aligned with modern operational practices while preserving the original goal of making intelligent traffic management decisions based on the health of the IIS server.