Skip to content
WindowsDeep Dive Published Updated 8 min readViews unavailable

Windows DHCP Client Leases: Diagnose Discovery, Renewal, and Address Loss

Trace a Windows DHCP lease from adapter state and client events to DORA, T1/T2 renewal, relay paths, server evidence, and safe recovery.

A Windows device showing 169.254.x.x, an old address, or intermittent loss of connectivity does not automatically have a DHCP-server problem. The failure can occur before discovery leaves the client, on the local link, at a relay, during server selection, in address conflict detection, or while the client is renewing an existing lease. A useful diagnosis identifies the stage where client and server evidence diverge instead of repeatedly releasing every address on the machine.

This article covers IPv4 DHCP client behavior on Windows and its operational diagnostics. Server scope design and DHCP failover are separate topics. Begin with the exact adapter, network, timestamp, and whether the device is acquiring its first lease, renewing one, or resuming after sleep or network change. A laptop can have Wi-Fi, Ethernet, VPN, Hyper-V, and virtual adapters active at once; a valid lease on one interface says little about another.

Establish the affected interface and current lease

Before changing state, capture adapter names, interface indexes, IPv4 configuration, DHCP server, gateway, DNS servers, and lease timers. Use PowerShell to inventory physical and hidden adapters and the active IP configuration:

$out = Join-Path $env:TEMP 'dhcp-client-evidence'
New-Item -ItemType Directory -Path $out -Force | Out-Null
Get-NetAdapter -IncludeHidden |
    Select-Object Name, InterfaceDescription, ifIndex, Status, MacAddress, LinkSpeed |
    Export-Csv -NoTypeInformation -Path (Join-Path $out 'adapters.csv')
Get-NetIPConfiguration -All |
    Format-List * | Out-File -FilePath (Join-Path $out 'ip-configuration.txt') -Encoding utf8
ipconfig.exe /all 2>&1 |
    Out-File -FilePath (Join-Path $out 'ipconfig-all.txt') -Encoding utf8

Read the results per interface. DHCP Enabled: Yes means the interface is configured to use DHCP; it does not mean a server answered the most recent request. Check the DHCP server and lease obtained/expiry values alongside the link state and interface index. If the affected interface is static, troubleshooting ipconfig /renew is the wrong branch. If only a virtual adapter shows the address, identify which software created it before changing the host’s physical network settings.

A 169.254.0.0/16 IPv4 address is link-local configuration commonly associated with Windows being unable to obtain a DHCP lease. It permits limited same-link communication and is not a routable substitute for the intended network address. An address outside that range can still be stale, reserved to another client identity, or valid only on a different VLAN. Confirm the subnet and DHCP options expected for the exact port or wireless network.

Follow the DHCP exchange by phase

For an initial IPv4 lease, the client broadcasts DHCPDISCOVER, one or more servers may send DHCPOFFER, the client selects an offer with DHCPREQUEST, and the chosen server confirms with DHCPACK. A DHCP relay can forward the client broadcast across a routed boundary and communicate the subnet information used to select the correct scope. If discovery is visible at the client but not at the server or relay, focus on VLAN membership, wireless isolation, relay configuration, link-layer filtering, or the intervening path. If the server sees the request but returns no offer, investigate scope availability, policy, reservations, filters, and server-side logs.

Renewal is not simply the same four-message exchange repeated at every interval. The client normally tries to renew the lease with the original server at T1, typically by unicast. If that attempt does not succeed, it can enter rebinding at T2 and broadcast so another server can respond. These timers derive from the lease and RFC behavior, but deployments can have policy and failover nuances. A device that works after a forced renew may still lose service later if renewal traffic or the original server path remains broken.

Correlate captures from both the client and the DHCP server when possible. Capture filters should preserve DHCP client/server traffic on UDP 67 and 68 and retain enough packet context to see transaction identifiers, client identifier, requested address, server identifier, relay information, and DHCP options. The source MAC address is not always the only identity that matters: DHCP client identifiers, reservations, and cloned or replaced interfaces can affect which lease record is returned. Do not change the client ID or create a reservation until the existing server record and endpoint inventory are compared.

Inspect Windows DHCP client evidence

Windows records client events in the Microsoft-Windows-DHCP Client Events Operational and Admin channels. First discover channel state and event volume; do not clear logs before preserving them. The Get-NetAdapter -IncludeHidden output helps map the interface ID and MAC address referenced by events to the adapter in the incident. Compare event times with sleep/resume, docking, Wi-Fi roaming, link renegotiation, VPN startup, and Group Policy or network configuration changes.

$logs = Get-WinEvent -ListLog '*DHCP Client Events*' -ErrorAction SilentlyContinue
$logs | Select-Object LogName, IsEnabled, RecordCount

foreach ($log in $logs | Where-Object IsEnabled) {
    Get-WinEvent -FilterHashtable @{
        LogName   = $log.LogName
        StartTime = (Get-Date).AddHours(-4)
    } -ErrorAction SilentlyContinue |
        Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message
}

Run this from an elevated PowerShell session if channel visibility requires it, and save the output before altering the lease. Event IDs and details can vary by Windows version; use the provider, interface, timestamp, and message rather than copying a single event number from another machine. A client event that says a request was sent establishes local stack activity, not that the packet crossed a switch or that a relay forwarded it.

Check DHCP Client service state only if the evidence suggests the client service is stopped or failing. Get-Service Dhcp and the System log can show service or dependency problems, but restarting the service can disrupt every DHCP-managed adapter. Prefer capturing current event and interface state first. On a managed device, also inspect endpoint security, VPN, network access control, and configuration-management tools that could alter adapter policy.

Separate client, relay, and server causes

If the client never transmits a discover or renew request, inspect its DHCP setting, service, adapter state, driver, media connection, and local filter stack. If it transmits but receives nothing, compare the client capture with a capture on the server’s network segment. A missing server-side request suggests a path or relay issue. A request at the server with no offer points to the server’s scope and policy evaluation. An offer leaving the server but not reaching the client points back to the reverse relay or access path.

On the DHCP server, verify that the scope for the client subnet is active and has available addresses. Check superscope or failover relationship state where configured, exclusion ranges, reservations, policies, MAC filters, and server authorization in Active Directory. For a relay design, verify the relay’s configured destination and interface/subnet mapping. giaddr and relay-agent information can be decisive when a server has multiple candidate scopes. A lease for the wrong subnet is usually a topology or relay selection issue, not a reason to manually assign an address on the endpoint.

Do not confuse DHCP with DNS registration. DHCP can provide DNS server and suffix options, and the server or client may participate in dynamic DNS updates, but an address lease can succeed while name resolution fails. If ipconfig /all shows a valid address, gateway, and DHCP server but hostnames fail, use the DNS-client diagnostic path separately. A successful lease is also not proof that the gateway, VLAN ACL, or upstream route permits application traffic.

Use release and renewal as a controlled test

ipconfig /renew <interface> is a state-changing test: it asks Windows to renew configuration and can interrupt active sessions. ipconfig /release <interface> removes the lease from that interface and can leave the device without connectivity if the server does not answer. Avoid the unscoped forms on production endpoints with multiple active adapters because they may affect more interfaces than intended. Capture the initial address and lease evidence first, coordinate a maintenance window for remote machines, then target only the affected interface.

For a bounded test, record the time and run a targeted renew after starting client and server-side captures. Confirm whether a DHCPREQUEST was sent, whether an ACK or NAK returned, what address and options were applied, and whether the route and DNS state match the expected network. Verify connectivity to the local gateway and a known internal service before interpreting an Internet test. Do not assign a static address merely to bypass a failed dynamic path unless the address is formally allocated and a rollback is defined; an accidental duplicate can create a second outage.

Repeatable incident workflow

  1. Identify the exact adapter, VLAN or SSID, address mode, lease timer, and last known good timestamp.
  2. Save adapter and IP configuration, DHCP client logs, and relevant service state before releasing a lease.
  3. Determine whether the problem is initial discovery, T1 renewal, T2 rebinding, or address conflict.
  4. Capture at the client and server/relay boundary and compare the same DHCP transaction identifier and client identity.
  5. Correct the first failing layer: endpoint, access network, relay, scope, policy, or server availability.
  6. Test the lease on the intended interface and verify gateway, DNS options, and application reachability independently.
  7. Observe a normal renewal interval or server-side lease state to prove the fix persists.

DHCP recovery is complete only when the client retains the intended lease through the normal renewal path and reaches the required network services. A one-time successful /renew is a useful observation, not a substitute for proving that relay, scope capacity, and renewal traffic remain healthy.

Related:

Sources:

Comments