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

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 (http://support.microsoft.com/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 (https://tools.ietf.org/html/draft-ietf-dhc-failover-12). 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.


Comments (44)

  1. teamdhcp says:

    Thanks For the details Tom. We are actively investigating this issue and will get back to you shortly with our findings.

  2. teamdhcp says:

    Hi Raj
    Just wanted to clarify that "(error ID 36) Client ID hash mismatch " is just an informational message. It comes whenever your DHCP servers are in failover relationship and server receives a DHCP request which it is not supposed to answer (instead the partner
    DHCP Server is supposed to answer it). Hence this message shall not result in clients not getting the IP address. We would like to understand exactly what issue are you facing with respect to your 2012 R2 server.

  3. teamdhcp says:

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

  4. teamdhcp says:

    Thanks David! 🙂 Appreciate the note!

  5. teamdhcp says:

    Hi Mike, the fixes for 2012 R2 have been released. See http://support.microsoft.com/kb/2919355.
    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.

  6. teamdhcp says:

    Hi Raj
    The configuration looks alright to us from the DHCP Relay agent perspective. Did you get it reviewed by the Cisco expert. If not we would recommend you to do that.

  7. teamdhcp says:

    Hi Tom
    Can you provide some more details about your setup and under what conditions are you facing this issue. Ideally the choice Windows or non-windows devices shall not make any difference with respect to this issue.

  8. teamdhcp says:

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

  9. heyko says:

    I’ve the same issues like John. After applying KB2919355 on both 2012 R2 Machines there are still severeal Events with ID 20292 (Reject Reason Unknown) on both sides. Is there already a solution or a workaround in place?

  10. teamdhcp says:

    Hi Mike, the BAD Addresses would take some time to resolve itself. When the client which has this IP address leased renews its lease, the BAD address for that specific IP address will get resolved.

  11. teamdhcp says:

    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.

  12. teamdhcp says:

    Georg, we are analyzing the issue that Mike reported. Will post an update once the investigation completes.

  13. teamdhcp says:

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

  14. weedee says:


    Is there any list of ALL released DHCP server updates/hotfixes for Windows Server 2012 RTM?

  15. teamdhcp says:

    Hi LE2Strat, DHCP failover is supported since Windows Server 2012. These fixes are applicable to DHCP failover. So, Windows Server 2008 R2 SP1 is not affected.

  16. teamdhcp says:

    John, Heyko and others reporting event 20291 in their DHCP failover deplpoyments –

    KB 2955125 (http://support.microsoft.com/kb/2955135 ) has been released to address events 20291. Please apply this patch.

  17. teamdhcp says:

    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.

  18. Martin says:

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

  19. Peter Jakobsen says:

    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

  20. Anonymous says:

    227 Microsoft Team blogs searched, 65 blogs have new articles. 191 new articles found searching from

  21. Mike F1 says:

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

  22. Davidd says:

    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…

  23. Davidd says:

    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…

  24. mike says:

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

  25. Volk says:

    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.

  26. Volk says:

    Great news, thanks.

  27. mike says:

    Hi, after applying the hotfix KB2919355 on windows server 2012 R2 DHCP servers, both of primary and partner. i still can see a lot ip with bad_address names from the DHCP console. i assume that the IPs with bad_address are the previous ones before appling the hotfix. could you tell me what is the best practice to resolve it? remove those bad ones from address lease spaces or other ideas. thanks a lot

  28. mike says:

    is it normal that I still got Event 20291 and 20292 after applying the hotfix KB2919355 on windows server 2012 R2 DHCP servers?
    Thanks for your helps very much.

  29. LE2Strat says:

    What if we are seeing issue #1 with our 2008 R2 SP1 DHCP server? Is there a hotfix coming for that, or is that version not affected?

  30. Georg says:

    Dear Sir or Madam,
    is Mike already asked about three Posts ago.
    We applied the patch in KB2919355 on both Partner Servers running WinServer 2012 R2 and we still get 20291/20292 Errors.
    Further the leases mentioned in those erros wont be synced to the Partner Server.
    From my Point of view this is something to take care about.
    @teamdhcp: Would you be so Kind to give a hint on this issue?

  31. Byron says:

    Same issue as Mike and Georg.

  32. Jens-Peter says:

    Hi DHCP team,

    Thx. for the fix. We have been running this exact configuration in an evironment for more than one year and never noticed the issue until today. Found the fix and it seems to resolve the issue.


  33. Raj says:

    We are also experiencing problems with a failover cofigured server. When i look at the logs on the DHCP server, i see (error ID 36) Client ID hash mismatch and the PCs will not get an ip address from our 2012 r2 servers, we have to switch them over to
    our 2008 r2 (we haven't moved all the vlans over yet so they are still up) to get them to work properly.

  34. Raj says:

    Hi again,

    Thanks for the response.

    We've been doing some digging into our problems here. Using your network monitor software, i've found that the DHCP discovery is reaching our server, but when it responds with an offer of an IP address, the PC on the other end does not receive the offer and
    it keeps sending discovery packets.

    We are looking at our network too see if we can find something there now, we run a Cisco environment. We started looking at the network side because we found that on some switches, the PC will get an IP address just fine. We've compared configs on the 2 switches
    and have found nothing of note. It's very strange.

    Do you folks have any "recommended" settings on the Cisco switches that you would know of? We have Nexus 5500 cores and C2960X edge devices. Also, here is the config we got for the interfaces on the Nexus cores:

    interface VLAN
    no shutdown
    ip access-group ****** in
    no ip redirects
    ip address *************/24
    hsrp version 2
    hsrp 25
    priority 250
    ip ********************
    ip dhcp relay address ******* : This is the IP address of one of the dhcp servers

    ip dhcp relay address ******* : IP address of the SCCM PXE server
    ip dhcp relay address ******* : This is the IP address of the other dhcp server which is a partner of it.

  35. tom says:

    I just received a complaint that we are experiencing issue #2. I checked and we already have this patch installed on both 2012 servers. Both servers reside on the same subnet and I am load balancing many zones. This issue mostly happens I was told when
    we do firmware upgrades to cisco wireless controllers where all the APs reboot or mass resets of ShoreTel phones. Networks with just Windows PCs seem to hum along fine.

  36. tom says:

    Let me know if you need further details but the two 2012 servers host DNS and DHCP (domain controllers). They are both on the same subnet but the issue are on other subnets. The servers are on an old Enterasys E7 chassis but will soon be cisco. Our Edge
    is all cisco 2960x and 3560. I use ip helper-address Server1ip ip helper-address server2 ip on each subnet router. no other fancy stuff going on. We see this problem primarily on two types of networks.

    The networks that house the cisco wireless APs and are dhcp for the APs. The only time they reboot is during an update and then they all reboot and with 76% of the scope used the bad IP address consumes to entire scope so some don't get IPs which require us
    to delete the bad addresses and in the last instance they had to disable fail over and restart DHCP services to get it working again.

    Also the data networks with shoretel phones. the phones boot up get a dhcp from the data network and then find the phone vlan for that network via dhcp and switch their vlan to that and get the dhcp off that voice vlan. The data vlan they momentarily connect
    to will often fill with bad ipaddress.

    One server is a VM (vmware) while the other is a physical IBM server.

    Let me know if you need any further details.

  37. John says:

    still getting a lot of 20291 and 20292 events with 2919355 patch applied on 2012 R2 – reject reason unknown, some leases does not replicate. Any new insights into the case? Looks like similar problem to the one Mike George and Byron are/were experiencing.

  38. Rajk says:

    Hi Teamdhcp,
    We do have windows 2012 standard R2 , with KB2919355 installed. DHCP failover configured as hot standby with default setting with 5% reserve. However, we see the primary server stop distributing IP when there is 10% of IP is available. Why is that. Also we
    see bad_address still there in the leases. Is there any KB released to fix this issue. Or we need to have the buffer IPs ( free IPs) in order to enable the Hot standby. If i disable the failover relation ship the primary server starting the distribute the
    IPs. Is this known issue.

  39. teamdhcp says:

    Hello Rajk, no this is not expected behavior. Primary should continue to lease IP addresses even when 10% of IP addresses are available. What is the number of IP addresses in this scope.

  40. rajk says:

    The scope statistics shows 24 Ips are available . However, it is not responding to the DHCP request of clients.

  41. Rajk says:

    Hi Teamdhcp, We have KB2919355 installed already on our DHCP servers. But still we see the error Evend ID:20292 . Is there any fix for this error .

  42. Rajk says:

    Hi Teamdhcp, Reply to your question on number of IP addresses in the scope … we have around 22 IPs free out of 22x

  43. teamdhcp says:

    Hi Raj, if your scope has 220 IPs and you are using 5% as reserve address percentage, 11 IP addresses will be reserved for the standby server. So, the primary should be able to lease upto 209 IP addresses – i.e. till only 11 free IP addresses are free
    in the scope. If your observation is different from this, please contact Microsoft support so that they could look into why the behavior is not as expected.