Monitoring Windows DHCP With PRTG

 Originally published on August 27, 2018 by Simon Bell
Last updated on March 03, 2022 • 10 minute read

The Dynamic Host Configuration Protocol (DHCP) Server is one of the unsung heroes of the Windows networking infrastructure. Without it, network administrators would have to spend hours maintaining lists of IP addresses, and manually assigning them to every new client that connects to their network. In anything other than the smallest environments, this would be simply impossible.

As with all critical infrastructure services, administrators need to monitor what’s happening with their DHCP servers – if the service isn’t working, your client devices won’t be issued an IP address, so will be unable to connect to the network. 

Using PRTG, we can quickly & easily check the three main “aspects” of the DHCP service:

  • Is the DHCP service running?
  • Is DHCP responding to requests and issuing IP addresses?
  • Are the address pools/scopes running low?

Monitoring the DHCP Server Service

The DHCP Server Service, like any other Windows Service, can be monitored using two dedicated sensor types. The most appropriate one to use will depend on your own environment & preferences, and the amount of information you want to retrieve.

The first is the SNMP Windows Service Sensor. As the name implies, it’s an SNMP-based sensor, so you will need SNMP to be installed and configured on the system to be monitored. This is a fairly simple sensor, and like all SNMP sensors, has a low impact on PRTG performance. The sensor displays the operating state of the selected service, in our case, the DHCP Server Service:



iSNMP stands for Simple Network Monitoring Protocol. Its usefulness in network administration comes from the fact that it allows information to be collected about network-connected devices in a standardized way across a large variety of hardware and software types. SNMP is a protocol for management information transfer in networks, for use in LANs especially, depending on the chosen version. Read more ...


Notifications can be configured to fire if the service is in any state other than Active (UP).

The second option for monitoring the service state is the WMI Service Sensor. This sensor utilises Windows WMI instrumentation to retrieve detailed information about the service being monitored:



This sensor, while requiring more resources on the PRTG server, does offer several advantages over the SNMP-based sensor. It provides more detailed diagnostics about the performance of the service (CPU usage, memory consumption, active threads & handles, etc). It can also be (optionally) configured to attempt to restart a service, if it stops.

With these two service sensors we can check to see if the DHCP Server Service is running. But that’s no guarantee that the DHCP Service is actually doing its job. For that, we need…

Monitoring the DHCP Server

The DHCP Sensor sends a broadcast message out on to the network – in the same way a newly connected client does – and monitors the response made by a DHCP server. By default, the response time of the server, and the length of the address lease issued are recorded. But the sensor configuration provides other options. Through the use of regular expressions, the sensor can return additional information, including

  • Whether the offered IP does / does not include certain values
  • Whether the IP of the responding server does / does not contain certain values
  • Whether a different DHCP Server responded, compared to the previous poll
  • Whether the offered IP address changes between polls


There are some restrictions / requirements regarding the use of this sensor:

  • It can only be deployed on a PRTG Probe device (Local, Remote or Clustered)
  • The Probe MUST be configured with a static IP address
  • Do not provision more than two DHCP sensors per Probe device.
  • This sensor cannot be provisioned on the Local (hosted) Probe of a PRTG Hosted by Paessler instance

More detailed diagnostic information about how the DHCP Server Service is performing can be obtained using a PerfCounter Custom Sensor, as Microsoft provide over 25 different PerfMon metrics for DHCP server. Including several specifically for monitoring the DHCP Failover feature, first introduced in Server 2012.

Monitoring IP Address Pools

All DHCP servers are configured with one or more “pools” of IP addresses, which they (semi) randomly assign to clients, upon request. Therefore, it’s important that administrators keep a watch on the size of the address pool, and the number of available addresses – if the pool runs out, no new clients can connect.

We have a couple of options available for monitoring address pools, both require the use of custom sensors.

Prior to Server 2012, Microsoft used to include an SNMP MIB file for monitoring DHCP. Unfortunately, they no longer do so. However, the MIB is still readily available online. Importing the MIB will provide additional information on the performance of the DHCP Server (numbers of offers, releases, requests, etc). But for monitoring the size of the address pool, we can simply use an SNMP Custom Sensor, without the need to import any MIBs.

In PRTG, create an SNMP Custom Sensor, specifying the OID for “available addresses” which is:

We then need to append the subnet address of the address pool, preceded by a dot (.) So for the subnet, the OID Value in the sensor settings would look like this:




Adding appropriate limits, based on the size of the environment, will allow PRTG to notify the administrator when the number of available addresses is running low:




The second option for monitoring the number of available addresses, is to use an EXE/Script Sensor to execute a PowerShell script that displays the number of available IP addresses as a percentage of the total pool size. Full details on how to do this, including the required code, are provided in this KB article - Sensor to Display DHCP Scope Status.

This is just one example of the many useful user contributed scripts available on our Sensor Hub page. It’s well worth checking out, if you have a need for a sensor that’s not included out-of-the-box in PRTG; there’s a good chance that one of our contributors has already done the hard work for you.