Server 2025 DHCP: server assigns lease then NAKs same client for same address seconds later, only under high client load

Jackie Ramsey 0 Reputation points
2026-09-07T14:56:53.4633333+00:00

Environment

  • Windows Server 2025 Standard, build 26100.33296 (August 2026 cumulative applied)
  • Domain controller, DHCP role, standalone (failover relationship removed during troubleshooting)
  • Clean OS install July 2026; DHCP config migrated from Server 2016 via Export-DhcpServer / Import-DhcpServer — no database files copied
  • Scope 10.5.112.0/20 (10.5.112.12–10.5.127.240), 12-hour lease
  • ~3,400 addresses available, ~600 active leases, 15% utilization
  • ~800 wireless clients, majority ChromeOS (vendor class chromeos), on a single VLAN behind a Cisco SVI with ip helper-address
  • K-12 high school: clients associate in large bursts at bell times

Problem

Under concurrent client load, the DHCP server issues a DHCPACK and then NAKs that same client for that same address within seconds. The address is then handed to a different client, whose lease is also revoked within seconds. This repeats continuously during periods of high client activity.

Example from the audit log — address 10.5.114.116, three different ChromeOS clients in five minutes:

11:45:16  NACK   10.5.114.116  900F0CC2F581
11:45:16  Assign 10.5.114.116  900F0CC2F581
11:45:22  NACK   10.5.114.116  900F0CC2F581
11:45:26  NACK   10.5.114.116  900F0CC2F581  (x2)
11:45:27  NACK   10.5.114.116  900F0CC2F581
11:45:27  Assign 10.5.114.116  900F0CC2F581   <- reassigned to same client
11:45:34  NACK   10.5.114.116  900F0CC2F581
11:45:35  NACK   10.5.114.116  E8C829E9BCB8
11:45:35  Assign 10.5.114.116  E8C829E9BCB8   <- different client
11:50:12  NACK   10.5.114.116  60A5E2B62FEC
11:50:12  Assign 10.5.114.116  60A5E2B62FEC   <- third client

Note the NACK and Assign entries for the same client and address repeatedly share a timestamp. In one case the Assign is logged before the NACK in the same second.

A second client walking multiple addresses in under two minutes:

11:18:43  NACK/Assign 10.5.114.147  900F0CC27195
11:18:54  NACK        10.5.114.147
11:18:58  NACK        10.5.114.147 (x2)
11:18:59  NACK/Assign 10.5.114.11
11:19:05  NACK        10.5.114.11
11:19:09  NACK        10.5.114.11 (x2)
11:19:10  NACK/Assign 10.5.114.11    <- same address again
11:19:22  NACK/Assign 10.5.114.136
11:20:09  NACK/Assign 10.5.114.136   <- again
11:20:21  NACK/Assign 10.5.115.46
11:20:41  NACK/Assign 10.5.115.46    <- again

Six DHCPACKs across four addresses in 118 seconds, each revoked within 5–11 seconds.

Reproducible on demand

Put a Chromebook to sleep and resume it. It loses its valid unexpired lease and cycles through 3–5 addresses over 30–45 seconds before settling. One client lost three consecutive 12-hour leases 16–18 minutes after each assignment (assigned 09:32:53, NAKed 09:50:57; assigned 09:51:44, NAKed 10:07:20; assigned 10:07:43).

At the time of each NAK the lease record showed AddressState: Active with a ClientId matching the client being denied.

Load dependency

NAK rate scales directly with concurrent client count:

Condition NAKs per 5 min
Morning arrival (~800 clients associating) 1,900–2,230
-------- --------
Morning arrival (~800 clients associating) 1,900–2,230
Mid-day class change 500–600
Mid-day steady 270–300
Building empty (school closed) 2–4

Leases are still being issued throughout — 200–500 per 5-minute interval — so the service is not hung. It simply does not appear to persist the bindings it creates.

Packet capture

Over-the-air capture confirms clients are behaving correctly. DHCPREQUEST frames contain Option 50 (requested address) and Option 54 (server identifier naming this server), i.e. the client is accepting this server's own offer, and the NAK follows roughly 16 ms later. giaddr is correct (10.5.112.1) on every frame.

Ruled out

Checked Result
DHCP failover Relationship removed entirely — no change in behavior
-------- --------
DHCP failover Relationship removed entirely — no change in behavior
Scope exhaustion 3,400+ free, 15% utilization
Conflict detection Tested at 0 and at 1 — no change to the assign/NAK cycle
DNS dynamic updates Zero DNS events (IDs 30/31/32) against 1,144 assigns
Database inconsistency Repair-DhcpServerv4IPRecord finds nothing
Database integrity Clean install, j50.chk current, normal JET log rotation, 3 MB dhcp.mdb
DHCP policies None defined at scope or server level
Relay path Single SVI, correct /20 mask, giaddr correct in capture
Rogue DHCP servers All other AD-authorized servers verified to have no DHCP role
Server resources CPU 8–15%, disk write latency 1.7 ms, queue 0–1, 25 GB free RAM
Patch level Issue present before and after August 2026 cumulative (26100.33296)
Client behavior Capture shows RFC-conformant DHCPREQUEST with Option 54
Wireless infrastructure Frame duplication in capture traced to multi-AP capture artifact

Questions

  1. Has anyone seen Server 2025 DHCP fail to persist lease bindings under burst client load — hundreds of clients transacting within a few minutes?
  2. Is there a diagnostic beyond the audit log that would show why a lease commit fails? The audit log records the ACK and the NAK but gives no reason code.
  3. Are there registry values governing DHCP request-processing concurrency, thread pool size, or JET commit behavior that would be worth adjusting for this load profile?
  4. Would a netsh trace on the server, or DHCP Server debug logging, capture the internal reason for the NAK?

Happy to provide full audit logs, the packet capture, and any additional output.Environment

  • Windows Server 2025 Standard, build 26100.33296 (August 2026 cumulative applied)
  • Domain controller, DHCP role, standalone (failover relationship removed during troubleshooting)
  • Clean OS install July 2026; DHCP config migrated from Server 2016 via Export-DhcpServer / Import-DhcpServer — no database files copied
  • Scope 10.5.112.0/20 (10.5.112.12–10.5.127.240), 12-hour lease
  • ~3,400 addresses available, ~600 active leases, 15% utilization
  • ~800 wireless clients, majority ChromeOS (vendor class chromeos), on a single VLAN behind a Cisco SVI with ip helper-address
  • K-12 high school: clients associate in large bursts at bell times

Problem

Under concurrent client load, the DHCP server issues a DHCPACK and then NAKs that same client for that same address within seconds. The address is then handed to a different client, whose lease is also revoked within seconds. This repeats continuously during periods of high client activity.

Example from the audit log — address 10.5.114.116, three different ChromeOS clients in five minutes:

11:45:16  NACK   10.5.114.116  900F0CC2F581
11:45:16  Assign 10.5.114.116  900F0CC2F581
11:45:22  NACK   10.5.114.116  900F0CC2F581
11:45:26  NACK   10.5.114.116  900F0CC2F581  (x2)
11:45:27  NACK   10.5.114.116  900F0CC2F581
11:45:27  Assign 10.5.114.116  900F0CC2F581   <- reassigned to same client
11:45:34  NACK   10.5.114.116  900F0CC2F581
11:45:35  NACK   10.5.114.116  E8C829E9BCB8
11:45:35  Assign 10.5.114.116  E8C829E9BCB8   <- different client
11:50:12  NACK   10.5.114.116  60A5E2B62FEC
11:50:12  Assign 10.5.114.116  60A5E2B62FEC   <- third client

Note the NACK and Assign entries for the same client and address repeatedly share a timestamp. In one case the Assign is logged before the NACK in the same second.

A second client walking multiple addresses in under two minutes:

11:18:43  NACK/Assign 10.5.114.147  900F0CC27195
11:18:54  NACK        10.5.114.147
11:18:58  NACK        10.5.114.147 (x2)
11:18:59  NACK/Assign 10.5.114.11
11:19:05  NACK        10.5.114.11
11:19:09  NACK        10.5.114.11 (x2)
11:19:10  NACK/Assign 10.5.114.11    <- same address again
11:19:22  NACK/Assign 10.5.114.136
11:20:09  NACK/Assign 10.5.114.136   <- again
11:20:21  NACK/Assign 10.5.115.46
11:20:41  NACK/Assign 10.5.115.46    <- again

Six DHCPACKs across four addresses in 118 seconds, each revoked within 5–11 seconds.

Reproducible on demand

Put a Chromebook to sleep and resume it. It loses its valid unexpired lease and cycles through 3–5 addresses over 30–45 seconds before settling. One client lost three consecutive 12-hour leases 16–18 minutes after each assignment (assigned 09:32:53, NAKed 09:50:57; assigned 09:51:44, NAKed 10:07:20; assigned 10:07:43).

At the time of each NAK the lease record showed AddressState: Active with a ClientId matching the client being denied.

Load dependency

NAK rate scales directly with concurrent client count:

Condition NAKs per 5 min
Morning arrival (~800 clients associating) 1,900–2,230
Mid-day class change 500–600
Mid-day steady 270–300
Building empty (school closed) 2–4

Leases are still being issued throughout — 200–500 per 5-minute interval — so the service is not hung. It simply does not appear to persist the bindings it creates.

Packet capture

Over-the-air capture confirms clients are behaving correctly. DHCPREQUEST frames contain Option 50 (requested address) and Option 54 (server identifier naming this server), i.e. the client is accepting this server's own offer, and the NAK follows roughly 16 ms later. giaddr is correct (10.5.112.1) on every frame.

Ruled out

Checked Result
DHCP failover Relationship removed entirely — no change in behavior
Scope exhaustion 3,400+ free, 15% utilization
Conflict detection Tested at 0 and at 1 — no change to the assign/NAK cycle
DNS dynamic updates Zero DNS events (IDs 30/31/32) against 1,144 assigns
Database inconsistency Repair-DhcpServerv4IPRecord finds nothing
Database integrity Clean install, j50.chk current, normal JET log rotation, 3 MB dhcp.mdb
DHCP policies None defined at scope or server level
Relay path Single SVI, correct /20 mask, giaddr correct in capture
Rogue DHCP servers All other AD-authorized servers verified to have no DHCP role
Server resources CPU 8–15%, disk write latency 1.7 ms, queue 0–1, 25 GB free RAM
Patch level Issue present before and after August 2026 cumulative (26100.33296)
Client behavior Capture shows RFC-conformant DHCPREQUEST with Option 54
Wireless infrastructure Frame duplication in capture traced to multi-AP capture artifact

Questions

  1. Has anyone seen Server 2025 DHCP fail to persist lease bindings under burst client load — hundreds of clients transacting within a few minutes?
  2. Is there a diagnostic beyond the audit log that would show why a lease commit fails? The audit log records the ACK and the NAK but gives no reason code.
  3. Are there registry values governing DHCP request-processing concurrency, thread pool size, or JET commit behavior that would be worth adjusting for this load profile?
  4. Would a netsh trace on the server, or DHCP Server debug logging, capture the internal reason for the NAK?

Happy to provide full audit logs, the packet capture, and any additional output.

Windows for business | Windows Server | Networking | Network connectivity and file sharing
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Domic Vo 32,140 Reputation points Independent Advisor
    2026-09-07T15:39:31.98+00:00

    Hello,

    This behavior in Windows Server 2025 DHCP is not caused by client misbehavior but by the server failing to persist lease commits under burst load. The ACK/NAK cycle you’re seeing is a concurrency and JET commit issue in the DHCP service, and at present there is no supported registry or configuration tweak that fully resolves it. The only reliable path is to escalate to Microsoft support, as this is a product-level defect.

    The audit logs and packet captures you’ve shared confirm that clients are RFC-compliant: they send DHCPREQUEST with Option 50 and Option 54, accept the server’s own offer, and then receive a NAK within milliseconds. The lease database shows AddressState: Active with the correct ClientId at the time of denial, which rules out rogue DHCP servers, scope exhaustion, or relay misconfiguration. Conflict detection attempts, failover removal, and database integrity checks also don’t change the outcome. This points directly to the DHCP service failing to commit leases under high concurrency.

    Microsoft’s own troubleshooting guidance emphasizes checking relay paths, failover, and conflict detection, but in your case all of those have already been ruled out. The scaling pattern you observed - NAKs rising linearly with concurrent client count (2,000+ NAKs in five minutes during morning arrival) - is consistent with a server-side concurrency bottleneck in lease commit handling. There are references in community discussions to registry keys under HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters (such as speculative “FastNack”), but these are undocumented and not supported by Microsoft. Adjusting them risks destabilizing the service further and is not recommended in production.

    At this point, the only practical mitigations are architectural rather than configuration-based. Splitting the client load across multiple DHCP servers or scopes, reducing burst concurrency with staged association policies, or offloading wireless clients to a dedicated DHCP appliance can reduce the symptom frequency. However, these are workarounds, not fixes. Since you’re already on the August 2026 cumulative update (build 26100.33296) and the issue persists, the next step is to open a case with Microsoft Support and provide them with your audit logs and packet captures. This will allow escalation to the product team, who can confirm whether a hotfix or servicing update is planned.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    DV.

    Was this answer helpful?

    0 comments
  2. James Gamble 0 Reputation points
    2026-09-07T15:36:53.7166667+00:00

    Hola Jackie,

    I dug a bit further into the Windows Server 2025 update history and DHCP-specific documentation, and I think you’ve already collected enough evidence to make this a very strong Microsoft support case.

    Your current build, 26100.33296, is the August 11, 2026 cumulative update KB5120233. Microsoft doesn’t currently list a DHCP Server issue among the known issues for that update, and the Windows Server 2025 release-health information doesn’t show an open DHCP problem that matches this ACK/NAK pattern.

    That doesn’t rule out an undocumented regression, but it does mean there isn’t a published fix or known issue I can point to yet.

    You also mentioned that the problem existed before and after the August update. The previous Server 2025 cumulative update was KB5099536, released on July 14, 2026, build 26100.33158. That update included some networking-related changes, but Microsoft doesn’t document any DHCP Server lease processing or database changes there either. Because this was a clean Server 2025 install in July and the problem spans both builds, I’d be more interested in whether the behavior reproduces on an earlier Server 2025 build or on Server 2022 than in blaming KB5120233 specifically.

    The strongest evidence is still what you’ve already captured:

    • The server ACKs the address.
    • The client sends a valid DHCPREQUEST with Options 50 and 54 for the same server.
    • The NAK follows roughly 16 ms later.
    • At the time of the NAK, the lease remains Active and is associated with the same ClientId.
    • The NAK rate rises dramatically with client concurrency, from only a handful when the building is empty to roughly 1,900–2,230 in five minutes during the morning burst.

    That makes it pretty hard to reconcile the data with normal scope exhaustion, client misbehavior, DNS updates, or a database capacity issue. I’d collect two more things before changing any undocumented registry settings.

    First, capture directly on the DHCP server NIC. The wireless capture proves the Chromebook is behaving correctly, but a server-side capture will tell you whether the DHCP server is actually receiving duplicate DHCPREQUESTs or multiple relayed copies of the same transaction.

    You can use: netsh trace start capture=yes report=no persistent=no tracefile=C:\Temp\dhcp.etl maxsize=1024

    Reproduce a short burst, then stop it with: netsh trace stop

    Second, I’d correlate the DHCP audit log with the DHCP Server event channels. Microsoft documents DHCP Server events here. You can quickly see what DHCP event logs are enabled with: Get-WinEvent -ListLog *DHCP* | Select-Object LogName,IsEnabled,RecordCount

    If you can do one controlled comparison, I think it would be extremely valuable:

    Run the same scope and relay configuration on Server 2022 and hit it with the same burst of clients.

    If Server 2022 handles the bell-time load cleanly while Server 2025 immediately starts recycling leases and generating NAKs, that gives Microsoft a very clean version-specific reproduction.

    I’d also test the next Server 2025 cumulative update when it becomes available, but I wouldn’t wait on that or assume it contains a fix unless Microsoft explicitly documents one.

    My suspicion is still an internal Server 2025 DHCP race or lease-state synchronization problem under concurrency, but the good news is that you’ve already done most of the hard work. The packet captures, lease-state checks, load correlation, clean database, and eliminated failover path make this a much stronger escalation than a typical “DHCP is flaky under load” report.

    Thanks,

    James

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.