Troubleshoot DHCP Clients Receiving 169.254 APIPA Addresses

Before you begin

Applicable to supported Windows Server/client environments where the named role or feature is installed. Run read-only checks first from an elevated PowerShell or Command Prompt as appropriate. Replace example hostnames, domain names, addresses, ports and paths with values from the affected environment. Record the exact error, timestamp, OS build and scope of impact.

Production safety: obtain change approval and a verified backup before modifying AD DS, DNS, DHCP, firewall, IIS, storage or Hyper-V configuration. Ensure console/out-of-band access before network or remote-access changes.

Symptoms and likely root cause

A Windows client receives a 169.254.x.x address and cannot reach its normal gateway, file server or domain resources.

No usable DHCP lease: disconnected NIC, wrong VLAN, DHCP relay failure, exhausted scope, server binding/filter or client driver/service.

Diagnostic commands

ipconfig /all
Get-NetAdapter -IncludeHidden | Format-Table Name,Status,LinkSpeed,MacAddress
Get-Service Dhcp
ipconfig /release
ipconfig /renew
Get-WinEvent -LogName Microsoft-Windows-Dhcp-Client/Operational -MaxEvents 30

Run the commands in order and save the complete output. The commands above are intended to establish the failing layer before a configuration change is attempted.

How to interpret the results

169.254/16 indicates Windows self-assigned an address after failing to obtain a valid lease. Determine whether Discover leaves and Offer returns. Compare a working endpoint on the same VLAN.

Practical correction

Check cable/dock/switch port, NIC state/driver, VLAN, DHCP relay/IP helper, UDP 67/68 path and scope availability. Review server binding, policies, filters and BAD_ADDRESS. A temporary static address is allowed only when the network owner confirms an unused IP, mask, gateway and DNS.

Make one change at a time. Re-run the failed diagnostic after each change so the cause-and-effect relationship is clear.

Fallback and recovery

Remove any temporary static address after the test and restore DHCP. Do not assign a random static address or public DNS to mask a DHCP outage. Verify lease after reconnect/reboot.

Verification checklist

Success: client receives a valid subnet lease, reaches its gateway and resolves internal names; DHCP Client Operational logs show no repeated acquisition failure.

• Repeat the original failing operation from the affected client/user or service.
• Test from a second approved endpoint or subnet where relevant.
• Review the relevant event log/IIS log after the fix.
• Record the change, actual result and any remaining limitation.

Frequently asked question

Is APIPA always a DHCP server failure? No. Check adapter, VLAN, relay, scope and client logs.

Official technical reference

Microsoft Learn — troubleshoot problems dhcp client

Use the official documentation for exact version support, prerequisites and any procedure that differs between Windows Server releases.

Technician field note

This runbook describes a controlled diagnostic path; it is not a universal guarantee that every environment has the same cause. If evidence does not match the expected result, stop and investigate rather than applying unrelated fixes. Do not mark the incident resolved until the original symptom is verified as cleared.