Microsoft Windows DDI Team Blog

Windows Server DNS, DHCP and IPAM solution!

DHCP Failover fixes in KB 2919393 for Windows Server 2012 and KB 2919355 for Windows Server 2012 R2

DHCP Failover fixes in KB 2919393 for Windows Server 2012 and KB 2919355 for Windows Server 2012 R2

  • Comments 38
  • Likes

The following fixes in DHCP Server for Windows Server 2012 have been released as part of Windows rollup update KB 2919393 and for Windows Server 2012 R2 for KB 2919355.


Issue no 1: DHCP Failover server issues reserved IP address to a client with a different MAC address

This  issue pertains to the case when a  DHCP Scope which is a part of a failover relationship has an exclusion range and a reservation exists in the scope for one of the IP addresses within the exclusion range. The sequence of events leading to this issue is as follows:

  • The reserved IP address is leased out to the reserved client.
  • That client releases the IP address (DHCP RELEASE message) by sending a DHCP release messages. This causes the DHCP server to mark the IP addresses as available.
  • A different client sends a DISCOVER packet to the DHCP Server. The DHCP server OFFERs the reserved IP to this client though the MAC address of the client does not match the one in the reservation..
  • Now the client sends a REQUEST packet to the server.
  • DHCP Server now sends back a NAK message taking into account that it is a reserved IP Address.
  • Client starts the DORA (DISCOVER OFFER REQUEST ACK) sequence again leading to the same consequences.
  • The client is perpetually stuck into a DISCOVER-OFFER-REQUEST-NAK cycle and never gets an IP Address.

With time this may lead to many clients stuck in DISCOVER-OFFER-REQUEST-NAK cycle and losing network connectivity.

Issue no 2: Some IP addresses are perpetually stuck in BAD ADDRESS state on one of the DHCP failover servers while in Active state on the other server. DHCP Server admin channel contains BINDING ACK reject events 20291 and 20292 for these IP addresses. The sequence of events which leads to this issue is as follows:

  • A DHCP Server is migrated to a DHCP Server 2012 or DHCP Server 2012 R2 without migrating the lease records. The new DHCP server does not have any leases in it’s database.
  • Server is configured for failover leading to a state where none of the failover partners have any lease records.
  • A new client requests an IP address. One of the failover partners leases out the first free IP address in it’s database. This IP address is already in use by another client who had obtained it from the DHCP server before migration.
  • The client performs a duplicate address detection test which fails. The client declines the lease (DHCP DECLINE) and hence the address is marked as BAD_ADDRESS on the DHCP server.
  • The same update is sent to the partner server and that server also marks that IP address as a BAD_ADDRESS.
  • When the client to whom the IP Address was issued originally sends a RENEW request to one of the failover partners the server sends an ACK and marks the IP Address as Active.

Now when the update of BAD_ADDRESS to Active state is sent to the partner server, the BINDING update is rejected leading to inconsistency between the 2 DHCP servers. 

Both these issues have been fixed in the rollup update for Windows Server 2012 in KB 2919393 and for Windows Server 2012 R2 is KB 2919355.

DHCP failover relation need not be recreated to apply this patch. DHCP server restart is required.

UPDATE: Some customers reported events 20291 getting logged even after applying KB 2919355. KB 2955135 ( ) has been released to address this issue with DHCP failover. Customers who have DHCP failover deployments with Windows Server 2012 R2 and experiencing events 20291 should apply this patch.


We are aware of a remote scenario that is not addressed by the KB 2919355. It occurs when a client sends multiple request packets within the same second and the second client request is a release request. You will notice the following pattern in the DHCP audit logs.


10,09/05/14,17:49:29,Assign,, Test,547F544A05CC,,362119506,0,,,,,,,,,0



In DHCP failover, whenever one of the server responds with an ACK to a client request, the same is updated in the database of the DHCP server with a timestamp and is sent to the partner for synchronization. This timestamp is at granularity of a second. If the partner server receives two synchronization updates from the other DHCP server with the same timestamp, it will reject the second request. This is as per the DHCP failover IETF document ( If the second request from the  client is a release request then this causes the failover servers to go out of sync as the partner server will reject the synchronization update but the first server (which received the client request) will apply the update to its database.

This will cause the failover servers to generate 20291 and 20292 events.

This is considered a remote scenario as a client sending two requests within the same second seems unlikely. However, we would like to understand if customers are seeing this scenario in their deployment. Customers seeing such an issue should contact Microsoft support which will enable collecting of required logs etc to diagnose the issue further.


  • Thanks, I noticed a million of these events on my setup, mostly from the WIFI scopes, will test the R2 patch once is out

  • Why can't I find anything regarding these two fixes in KB2919393?

    Is there other fixes regarding the DHCP server 2012 HA in KB 2919393?

    The two problems mentioned above have been a problem since the switch to DHCP server 2012 HA, so they are very welcome.


    Peter Jakobsen

  • Hi Peter, the KB 2919393 will be updated with details of the DHCP failover fixes. There are no other DHCP server fixes in 2919393.

  • Any timeframe as to when the hotfix will be available for DHCP server 2012 R2?

  • Hi Mike, the plan for release of these fixes for DHCP server in 2012 R2 is in the works. We will post an update once its finalized.

  • So is Issue #1 considered "bad practice"? ie - reserving IPs in an exclusion range? I was thinking about doing that just now and found this blog about it. I'm trying to find a way to reserve a "block" of addresses in my pool for two computer labs, without having the addresses scattered throughout the existing pool. Reservations in an exclusion seemed the logical way to do it, but maybe not...

  • Hi David, No, its not considered a bad practice and the blog does not say its a bad practice either. Its just that there was a bug with this kind of configuration and failover - which has now been for Windows Server 2012.

  • Sweet. Thanks for the info. You guys have done a great job on the Windows DHCP server. I just switched from ISC's dhcpd to Windows last year, and can't say that I miss it much. Failover is totally cool...

  • Thanks David! :-) Appreciate the note!

  • Is there any available workaround to fix the issue 2? thanks

  • A couple of questions and thanks ahead of time for the reply.
    1. Any updates on when patch for 2012 R2 is planning on being released?
    2. I am in the process of migrating all services (AD/DNS/DHCP) from 2003 to 2012 R2 in a dual-server configuration. Old configuration was 80/20 and relay agents were already configured for subnets.
    All DHCP scopes on one of the 2003 servers were reconfigured from 80% to 100% scope coverage and have been migrated from the 2003 box to one of the 2012 R2 servers, including leases and reservations. Since then, the 2012 has been serving up DHCP for ~3 weeks with no issues. My next step was to configure DHCP HA with load sharing by following dn338990 (importing only server settings into the second server). Would importing server settings and pausing the second server be an option? In case the first server goes down I can get the second one up and running... What other options do I have until this issue is resolved? Configuring 80/20 and then going back does not seem like a good idea for 170 scopes and I am concerned about having a single box serving 2300 clients.

  • Hi Volk, the patch for 2012R2 has been released as part of KB 2919355. See
    I assume #2 is a non issue now that the fixes are released? Let us know.

  • Hi Mike, the fixes for 2012 R2 have been released. See
    The workaround for issue #2 is to migrate the scopes _with_ _leases_. But that would require you to redo the migration and recreate the failover relationship. Now that the fixes are released, you should not be needing the workaround.

  • Great news, thanks.

  • Updated the article with details for patch update for Windows Server 2012 R2.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment