Dynamic Host Configuration Protocol typically requires little maintenance, but when networking problems start, it’s imperative to track down the source.
DHCP is a critical function on the network, and guaranteeing its functionality and maintaining its security are essential. DHCP logs its own service records in Event Viewer, but it maintains lease information in separate logs. Learning to manage and utilize these logs enables you to troubleshoot the service more effectively.
How does DHCP work?
IP address management is an important but straightforward administrator task. There are two options for assigning IP address settings to a system on the network:
Static IP addressing. An administrator manually enters values, including IP address, subnet mask, default gateway and DNS servers. This approach is common on servers and network appliances.
Dynamic IP addressing. An administrator establishes a pool of IP addresses and related settings on a DHCP server, and client computers lease an IP address configuration during the startup process. Most client devices are configured dynamically.
Static addressing is a manual process, and dynamic addressing relies on DHCP servers. Most networks use a mix of both.
The advantages of a dynamic configuration are simplicity and consistency. Static IP addressing introduces the risk of typographical errors and duplicate addresses but provides fixed IP addresses for network devices.
The Windows DHCP service can offer clients IPv4 and IPv6 addresses and options. The service differentiates between the two using separate scopes and specific logging.
This article examines the Windows DHCP server logging mechanism managed by the DHCP service. It stores information about client lease attempts and service status, maintaining a useful troubleshooting and auditing record.
Lease generation
The DHCP lease generation process involves four steps. The client device initiates the exchange:
Client checks for a DHCP server: Client > DHCPDiscover > DHCPServer.
Server responds to the client: DHCPServer > DHCPOffer > Client.
Client accepts the offer: Client > DHCPRequest > DHCPServer.
Server finalizes the lease: DHCPServer > DHCPAck > Client.
The client begins the interaction with a DHCPDiscover broadcast, which checks for DHCP server availability on the network. The DHCP server hears the query and responds with a DHCPOffer that contains an available IP address configuration. The client accepts the offer with DHCPRequest. The server finalizes the exchange by acknowledging the request with DHCPAcknowledge.
The client device now has a full IP address configuration — usually an IP address, subnet mask, default gateway and two DNS servers. Administrators refer to this process as DORA: discover, offer, request, acknowledge.
Lease renewal
The lease is temporary and must be renewed periodically. The client begins the renewal with a DHCPRequest. The client requests to use the current configuration, and the server usually acknowledges the request with DHCPAck and renews the lease. If the DHCP server’s IP address settings for DHCP have changed, then it fails the request and forces the client to restart the DORA process. The client then receives the updated IP address settings.
The default lease time on a Windows DHCP server is eight days, and the renewal occurs at four days.
Introduction to DHCP logging
Configuring the DHCP server’s pool of IP addresses is not difficult but requires care to avoid typos while entering the values. Most client devices are configured as DHCP clients by default, so there’s rarely anything to do there.
Problems are rare, but logs help troubleshoot DHCP issues. Event Viewer tracks major DHCP events that affect the service. However, step-by-step DHCP lease events are stored in dedicated DHCP log files independent of Event Viewer. The logging mechanism identifies DHCP issues between the clients and the DHCP service.
Log entries include the following:
Successful client leases, renewals and releases.
Failed lease attempts.
Log start and stop events.
IP addresses in use.
Pool exhaustion.
DNS update events.
Windows enables DHCP logging by default, so you don’t need to provide any additional configuration to the service. The service maintains records by placing an entry in the appropriate log file for each exchange with a client computer.
Importance of DHCP logs
Use these log entries to troubleshoot situations where clients don’t successfully lease a configuration, the configuration is incorrect or the DHCP server does not respond as expected. You can also confirm service availability for service-level agreements using the logs. Finally, you can check these logs as part of a security audit to discover whether all connected clients are expected devices.
How to enable DHCP logging for auditing
The DHCP administrative console controls DHCP logging.
In Server Manager, go to Tools > DHCP to open the console. Drill down to the IPv4 node. Right-click the IPv4 node, select Properties > Advanced tab. The “Audit log file path” entry defines the log file location.
By default, the DHCP server log location is in the C:\Windows\system32\dhcp folder.
Windows saves the DHCP server logs each weekday in a separate file. Each log file is overwritten on the corresponding day of the week, enabling the administrator to look back one week at DHCP functions. The logs are specific to the IP version. The format for IPv4 logs is DhcpV6SrvLog-<DAY>.log, while the format for IPv6 logs is DhcpV6SrvLog-<DAY>.log.
The DHCP server stores its logs in separate files and, by default, overwrites old logs with the new log.
How to work with DHCP log files
Open the log files using a regular text editor. The log begins with an explanation of event IDs. These categories make finding the information you’re looking for easier.
Windows saves DHCP server log files with a .log file extension in comma-separated format, which you can open in Microsoft Excel for a more user-friendly view.
This partial list shows the event ID and its corresponding description of the logged activity that admins can find in the DHCP server audit log files.
The most interesting events for admins include any failure entries, such as these event IDs and their description:
13: An IP address was found in use on the network.
14: A lease request could not be satisfied because the address pool of the scope was exhausted.
15: A lease was denied.
These indicate a client attempted to lease a configuration, but the server could not fulfill the request.
The most referenced fields in the log file are ID, date, time, description, IP address, host name, media access control (MAC) address and user name.
The ID field relates to the event ID table and summarizes the general type of event. The date and time of the event and any available description come next. If possible, IP address, host name, MAC address and user name are listed. While not every event has an entry in the field header, the most common ones to appear are IP and MAC address.
How to check DHCP logs for troubleshooting
Here are some practical examples and methods for using DHCP logs to identify common network events. These apply to IPv4 and IPv6 DHCP scopes.
Successful processes
The following event IDs aid the troubleshooting process by indicating DHCP client events successfully occurred:
10: A new IP address was leased to a client.
11: A lease was renewed by a client.
12: A lease was released by a client.
Most entries should indicate a successful lease with event ID 10. Event ID 11 should also be prevalent, showing that clients successfully reinstated their current configuration. Expect many of these events, as most systems hold their IP settings for a long time.
Periodically, client machines release their IP configuration back to the server. Network troubleshooters may manually do this with the ipconfig /release command, usually as a precursor to the ipconfig /renew command, which manually initiates the DORA process. These releases are identified by event ID 12.
Duplicate IP addresses
Administrators must be careful not to use identical IP addresses on a network. Most Windows systems remove themselves from the network if they detect their IP address is already in use, reported with the following event ID:
13: An IP address was found to be in use on the network.
If properly configured, DHCP does not lease duplicate IP addresses. The issue typically arises when administrators don’t keep accurate records of static address assignments. It is common practice to assign static IPs to servers and network devices while Windows client systems get their IP settings from the DHCP server. If the DHCP scope includes static IP addresses, then the DHCP server has no way of knowing this and leases addresses in use.
There is an error message on the affected Windows device, but it’s easier to discover the duplicate IP by reviewing the logs.
Use this in combination with the “Conflict detection attempts” setting, which pings an address before offering the address for lease. If there is a response to the ping, the address is in use.
Scope exhaustion
The DHCP scope consists of the range of available IP addresses. The scope must contain enough addresses to support all clients that need a configuration. It’s possible that the number of clients on the segment exceeds the number of available addresses and the following event ID appears:
14: A lease request could not be satisfied because the scope’s address pool was exhausted.
You might not expect all clients to be on the network simultaneously, but short lease durations can be used to quickly free up unused addresses.
It’s easy to check the number of available and consumed addresses in the DHCP console, but the log file also displays an entry if a lease attempt fails due to scope exhaustion.
How to archive DHCP logs
DHCP log file names use abbreviated day names. Each week, the system overwrites the corresponding log with a new log of the same name, leaving IT just the seven most recent log files for review. If you do not archive them, then your DHCP records are relatively incomplete, which may be a problem when confirming service levels or investigating security events.
To keep logs longer than a week, copy or rename the current log file. I suggest copying it and appending the calendar date to the file name for easy reference. If your log is named DhcpSrvLog-Sun.log, copy it to DhcpSrvLog-Sun-07-31-2023.log to preserve it.
To automate log archiving, try PowerShell. The following code copies the Sunday log file with a file name that contains the date:
Copy-Item “C:\Windows\system32\dhcp\*Sun.log” “C:\Windows\system32\dhcp\archive\dhcplog-Sun-$(Get-Date -UFormat %d-%m-%Y).log”
Consider copying the log to an archive folder. I modified the destination path to C:\Windows\system32\dhcp\archive\. Use whatever makes sense for your organization.
What are best practices for DHCP logging?
Use the following guidelines and recommendations to optimize DHCP logging and to effectively manage and utilize these logs:
Proactively review the DHCP logs for scope and client information.
Maintain DHCP to avoid troubleshooting situations.
Implement automation to archive the logs for troubleshooting and auditing.
A solid DHCP design includes the following:
Configure scope options accurately.
Create plenty of IP addresses for the expected number of clients.
Set a lease duration to match client network activity.
Configure DHCP failover for Windows-based DHCP servers.
Authorize Windows-based DHCP servers in AD.
Use DHCP listeners if clients reside on different segments from DHCP servers.
Use DHCP logs the next time you investigate or troubleshoot your DHCP deployment.
Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to TechTarget Editorial and CompTIA Blogs.