Objective
Isolate missing IPv4 DHCP leases by checking the selected Windows adapter, access VLAN, relay, scope, server and actual DHCP exchange before applying a targeted fix.
- Required application access works after adapter renewal and temporary capture has been stopped and protected.
Prerequisites
- Record the affected adapter, expected VLAN/subnet, current DHCP configuration and a comparison client. Identify the responsible DHCP server or relay, the test time and local recovery access before attempting a lease release.
- Use PowerShell on the selected client, and use an authorized DHCP administration machine for the explicit server queries. Replace Ethernet, dhcp.example.com and 192.0.2.0 with the selected adapter, server and subnet ID. Lease release interrupts that adapter, so retain local recovery access. The bounded ETL capture can contain unrelated traffic and must be protected and stopped promptly.
Step-by-step procedure
Establish the baseline and scope
Record the affected adapter, expected VLAN/subnet, current DHCP configuration and a comparison client. Identify the responsible DHCP server or relay, the test time and local recovery access before attempting a lease release.
- The intended target, prior configuration, recovery path and service-specific acceptance criteria are recorded.
Identify the DHCP client and adapter
Check whether the affected adapter is configured for DHCP and record its address, gateway, DNS servers, server identifier and lease times. An automatically assigned 169.254 address is a symptom of missing usable DHCP configuration, not proof that the server service stopped. Identify the adapter name before any lease operation and compare with a known working client.
- Client configuration and the exact affected adapter are recorded.
Check link and access controls
Verify cable or wireless association, adapter state and the intended switch port or SSID. Compare a working client on the same segment and inspect NAC, port security or DHCP snooping where relevant. Preserve the current assignment and recovery access before changing ports. A physical link alone does not prove the correct VLAN or permitted DHCP exchange.
- The client's link and access-control context are verified against a relevant comparison.
Trace the client VLAN to the gateway
Confirm the client access VLAN/PVID and the tagged path over the actual uplinks, including APs or hypervisors. Check that the Layer 3 interface and scope correspond to this subnet. A VLAN can exist on one switch while being absent from an intermediate trunk; compare effective forwarding along the complete path rather than just saved names.
- The intended broadcast segment reaches its gateway or relay without changing unrelated VLANs.
Locate the missing DHCP exchange
Correlate one controlled initial lease attempt across client and server captures using the transaction and timing. Identify where Discover, Offer, Request or ACK stops; renewal traffic may follow a different unicast path. A missing packet at one capture point can indicate loss or incomplete observation. Limit capture duration and protect ETL files, which can include unrelated traffic.
- The failed stage is supported by correlated evidence rather than an assumed server outage.
Check relay and the return path
If the service is on another subnet, verify the relay on the correct client-facing Layer 3 interface, its intended server target and the return route. Compare client-side requests with those arriving at the server. An ordinary firewall permit does not replace relay functionality, and a correct helper address alone does not establish that replies reach the client.
- Relay forwarding and the reply path are checked for this subnet.
Inspect the correct server and scope
On an authorized administration machine with the DHCP Server module, target the actual server explicitly. Check the scope for the client subnet, free leases, exclusions, reservations, conflicts, policies and failover state where applicable. Replace the sample server and scope ID in the examples; do not expand a range into another network or delete leases merely to make the count look better.
- The intended scope is active, has capacity and applies the correct options and policies.
Correlate service and lease evidence
Check the service, event logs and any required AD authorization or failover state on the intended DHCP server. Compare the affected scope with a working segment and confirm that a successful test lease appears on the expected server. Avoid restarting a shared service for one failing client before isolating whether the request reaches it.
- Server health and lease evidence are correlated with the affected client and test time.
Verify the permitted DHCP traffic
Use the relevant client/server/relay exchange to inspect UDP 67/68 filtering, return routing and switch protections. Keep rules scoped to the intended paths and confirm the observed denial or drop before changing a policy. After the targeted fix, renew only the selected pilot adapter and verify its lease, gateway, DNS and required application access.
- The needed exchange succeeds and the pilot receives usable configuration without broad policy relaxation.
Validate the complete service
The pilot obtains a valid lease from the intended subnet and server, with the planned gateway, DNS and suffix. Record all acceptance results before extending the change.
- Scope capacity, relay/VLAN path and the relevant DHCP exchange support the observed successful result.
- Required application access works after adapter renewal and temporary capture has been stopped and protected.
Examples, targets and evidence limits
Use PowerShell on the selected client, and use an authorized DHCP administration machine for the explicit server queries. Replace Ethernet, dhcp.example.com and 192.0.2.0 with the selected adapter, server and subnet ID. Lease release interrupts that adapter, so retain local recovery access. The bounded ETL capture can contain unrelated traffic and must be protected and stopped promptly.
Observe full IP configuration
ipconfig /allObserve adapter IP configuration
Get-NetIPConfigurationObserve whether IPv4 interfaces use DHCP
Get-NetIPInterface -AddressFamily IPv4Identify the selected adapter and link state
Get-NetAdapter | Format-Table Name,Status,LinkSpeed,MacAddressState-changing pilot action: release only the named DHCP adapter using local recovery access
ipconfig /release "Ethernet"State-changing pilot action: renew that same adapter
ipconfig /renew "Ethernet"On the administration machine, query the intended DHCP server explicitly
Get-DhcpServerv4Scope -ComputerName 'dhcp.example.com'Inspect the selected server and subnet scope statistics
Get-DhcpServerv4ScopeStatistics -ComputerName 'dhcp.example.com' -ScopeId '192.0.2.0'State-changing capture: create the output directory and start your own 64 MB circular trace; full packets can contain unrelated data
New-Item -ItemType Directory -Path 'C:\Temp' -Force | Out-Null
pktmon start --capture --comp nics --pkt-size 0 --file-name "C:\Temp\dhcp-client.etl" --file-size 64 --log-mode circularStop only the Packet Monitor session started for this test
pktmon stopDiscover available DHCP event-log channels; compare event times with the test
Get-WinEvent -ListLog '*DHCP*' | Select-Object LogName,RecordCount,IsEnabledAfter a targeted fix, release only the selected adapter where the test requires it
ipconfig /release "Ethernet"Renew that adapter and retain the result
ipconfig /renew "Ethernet"Confirm the resulting lease and addressing
ipconfig /allValidation
The procedure is validated when:
- The pilot obtains a valid lease from the intended subnet and server, with the planned gateway, DNS and suffix.
- Scope capacity, relay/VLAN path and the relevant DHCP exchange support the observed successful result.
- Required application access works after adapter renewal and temporary capture has been stopped and protected.
Rollback
- Restore any diagnostic-only client, VLAN, relay or reservation change that failed acceptance, using the recorded baseline.
- Check that the restored configuration is actually usable; do not introduce an unverified static address in a live DHCP range.
- Stop your own capture and retain the evidence needed to explain the incident and the verified recovery.
Troubleshooting / common errors
- One failing client: compare adapter, driver, access controls and reservation before restarting the DHCP service.
- One failing VLAN: inspect its access/trunk path, relay and scope before changing all clients.
- Missing Offer or ACK: compare both capture points and server evidence; one incomplete trace is insufficient to locate the drop.
Official references
Retain the selected targets, prior state, diagnostic times, observed results and any unresolved follow-up with the change record.