Share via

KB4284833 causing DHCP clients to lose thier addresses

Question

Thursday, July 5, 2018 2:54 AM | 5 votes

Hi all,

Is anyone else having DHCP issues post installing KB4284833 on their windows server 2016 servers?

We've seen 4 different offices having this issue post installing KB4284833. These servers are domain controllers with DNS and DHCP.

After installing this rollup clients are losing their IP. Not just windows 10 desktops (they are all 1709 or 1803 Enterprise desktops) but we also had a printer (i'm not sure what it was doing on DHCP, but it added an interesting bit to the story.) 

A reboot, or unplug/replug the network cable works. /ipconfig renew works too, but needs to be done 2 times and the first time there is an error. (which sadly i don't have in front of me.) That only fixes the issue for a short time as the computer will lose its IP address again.

We first saw the problem in our NYC offices a week ago. Then today in our Manila offices after we patched them today.

uninstalling KB4284833 from the windows 2016 servers with DHCP fixes the issue.

Anyone else seeing this? odd right? i didn't noticing anything in the KB notes talking about DHCP. I don't even get why this would happen. I didn't think devices kept checking the DHCP server. My understanding (maybe wrong) is it only checked at boot, connection loss and the expiration of the address.

UPDATE: It looks like this issue has been fixed in KB4345418

Addresses an issue with the DHCP Failover server that may cause enterprise clients to receive an invalid configuration when requesting a new IP address. This results in a loss of connectivity.

All replies (15)

Tuesday, July 17, 2018 1:08 PM ✅Answered

Hi all,

Is anyone else having DHCP issues post installing KB4284833 on their windows server 2016 servers?

We've seen 4 different offices having this issue post installing KB4284833. These servers are domain controllers with DNS and DHCP.

After installing this rollup clients are losing their IP. Not just windows 10 desktops (they are all 1709 or 1803 Enterprise desktops) but we also had a printer (i'm not sure what it was doing on DHCP, but it added an interesting bit to the story.) 

A reboot, or unplug/replug the network cable works. /ipconfig renew works too, but needs to be done 2 times and the first time there is an error. (which sadly i don't have in front of me.) That only fixes the issue for a short time as the computer will lose its IP address again.

We first saw the problem in our NYC offices a week ago. Then today in our Manila offices after we patched them today.

uninstalling KB4284833 from the windows 2016 servers with DHCP fixes the issue.

Anyone else seeing this? odd right? i didn't noticing anything in the KB notes talking about DHCP. I don't even get why this would happen. I didn't think devices kept checking the DHCP server. My understanding (maybe wrong) is it only checked at boot, connection loss and the expiration of the address.

UPDATE: It looks like this issue has been fixed in KB4345418

Addresses an issue with the DHCP Failover server that may cause enterprise clients to receive an invalid configuration when requesting a new IP address. This results in a loss of connectivity.

We've patched two DCs today with KB4345418 and so far it *seems* to be working (ie, no client loss of IP.)

As always you can skip right to the latest cumulative update by clearing out C:\Windows\SoftwareDistribution (or manually downloading and patching KB4345418.

Thursday, July 5, 2018 9:08 AM

Yes - we are experiencing this exact issue. We're rolling back the update from our DCs.

Neil Rawlinson

Thursday, July 5, 2018 12:54 PM

good to know others are having the same issue. That said, does MS know people are having this issue?

But the short take away is don't install KB4284833 on domain controllers. Luckily there aren't security fixes in this KB so it is safe to ignore.. i hope MS fixes this before there is a security patch.

Thursday, July 5, 2018 1:32 PM

We have been experiencing the exact same thing for the past week, since the update was installed on our two DC's

All windows computers was unable to renew IP, unless you renew manually did something.

Our Cisco IP phones sometimes had the very same problem renewing IP, but none of our Ubuntu or MAC machines seemed to have the problem.

I just uninstalled this update on both DC's and will report back on my findings but already after two hours it seems promising 

Thursday, July 5, 2018 9:34 PM

Thanks Jordan

We were also experiencing issues since we installed KB4284833 on our 2016 domain controllers last week.
Last night I successfully uninstalled KB4284833 and all the DHCP renew issues seemed be resolved.
I have 700 happy users now.

Thanks again :)

Friday, July 6, 2018 5:28 PM

We had the same issue after installing the windows update. We are using Windows Server DHCP Failover Cluster. You use this feature too? The issue comes from the DHCP Renewal time.

Explanation:

Our DHCP-Failover Cluster has two nodes. One Windows Server 2016 and one Windows Server 2012 R2 and it operates in Load-Balance mode. After installing the update on the Windows Server 2016 we noticed that some clients after one hour looses the network connection.

In a DHCP-Failovercluster the first lease-time is the Maximum Client Lead Time (MCLT) the default value is one hour. After 30 minutes normaly the client trys to renew the DHCP-Lease. The clients which get the dhcp-leases from the Windows Server 2012 R2 works fine. But the clients which get the lease from Windows Server 2016 looses the network connection after one hour.

We captured the network traffic on a client with the issue and analysed the DHCP Offer packet from the dhcp-server. And the issue is that the dhcp renewal-time is greater the the dhcp lease-time. The clients don't try to renew the dhcp-lease until the dhcp renewal-time is reached.

After removing the Windows Updates from the Windows Server 2016 the dhcp renewal-time is 30 minutes and the lease time is one hour. All fine and the issue was gone. Can you provide me where i can report the bug to Microsoft?

Monday, July 9, 2018 6:59 PM

Hello,

I am not trying to start a "me too" comment, but we installed KB4284833 onto our dedicated DHCP servers last week and started experiencing this exact same issue.  Many Cisco wireless access points failed to get an IP Address because the Renewal Time and Rebind Time were greater than the MCTL Lease time.  Reconfiguring failover on our scopes provided a work-around to this issue.    The other fix we found was to reduce the DHCP lease time to 30 minutes so the rebind/renewal time was less than 1 hour of the MCTL intial lease.

I opened a case with Microsoft (118062918493392) and we started investigating the issue but they want to be able to reproduce the issue with a single server and single client and I'm having difficulties getting any particular client to have the issue. 

Monday, July 9, 2018 9:26 PM

Just an update from my perspective, I've been able to reproduce this issue and i have wireshark packet captures of the DHCP traffic for the entire length of the issue.  I've send the wireshark pcaps and the Windows DHCP server logs to them.

Monday, July 9, 2018 11:18 PM

I have done the same thing...

The DHCP offer is invalid, so my hosts reject the offer.

From the debugs on my client(s):

*Mar  1 00:52:26.663: DHCP: Scan: Renewal time: 134676480

*Mar  1 00:52:26.663: DHCP: Scan: Rebind time: 235683840

*Mar  1 00:52:26.663: DHCP: Scan: Lease Time: 3600

*Mar  1 00:52:26.663: DHCP: Scan: Renewal or Rebind time larger than lease time

*Mar  1 00:52:26.663: DHCP: Error in pkt. punting

Currently on the phone with Microsoft. They said it is a known issue.

Tuesday, July 10, 2018 10:48 PM

Do we think the patches today fix the issue?

Thursday, July 12, 2018 12:02 AM

The 2 KBs known to cause this issue are: 

  • KB 4284833: June 21, 2018—KB4284833 (OS Build 14393.2339)
  • KB 4338814: July 10, 2018—KB4338814 (OS Build 14393.2363)

Microsoft is working on a resolution with an estimated release in mid-July 2018. Customers impacted by this issue may open assisted support case with Microsoft Enterprise Support for additional guidance. Microsoft will reply back to this thread once an update is available.

Friday, July 13, 2018 12:09 PM

Same problem here…

It took us 2 whole days to find a workaround.
(and the reason for the Problem:https://support.microsoft.com/en-ie/help/4284833/windows-10-update-kb4284833)

Temporarily Workaround:

Set the lease-time to 30 minutes 

Monday, July 16, 2018 6:12 AM

KB4338814 did not fix the issue for us, anyway.

I just found this thread, so had to first remove this update, and then proceed to removing KB4284833.

We have a dual Server 2016 DHCP cluster as well.

Tuesday, July 17, 2018 12:30 PM | 1 vote

This issue is resolved by KBs that contain the following release note text:

  • Addresses an issue with the DHCP Failover server that may cause enterprise clients to receive an invalid configuration when requesting a new IP address. This results in a loss of connectivity.

KBs for specific OS versions are listed below

Tuesday, July 17, 2018 2:18 PM

This issue is resolved by KBs that contain the following release note text:

  • Addresses an issue with the DHCP Failover server that may cause enterprise clients to receive an invalid configuration when requesting a new IP address. This results in a loss of connectivity.

KBs for specific OS versions are listed below

Thank #@%$ for that. I spent half the day trying to figure this out - we were only seeing the issue with VMs so have been tearing the Hyper-V servers apart. Client PCs haven't had any issues yet, but a bunch of VMs have been consistently losing IPs every hour or so. We only updated the servers over the weekend, so have only been affected for a couple of days. I pushed a couple of the VMs out to different subnets (where different devices provide DHCP) and they've been stable ever since (unusable for their job though, because they're unreachable on those subnets, but it was useful to figure out it was the DHCP server causing it).

FFS Microsoft, how the heck did it take you this long to figure this issue out? We now have to go and patch servers all over the place and hope this hasn't been wrecking our clients' networks. I've had colleagues trying to push us to bring our patching rounds forward from the current two weeks because 'we're just being paranoid'. Well guess what? I've never seen a server or workstation compromised because it was patched three or four weeks after a Patch Tuesday release, not once in fifteen years. Yet this is about the sixth time I've seen Microsoft screw up a patch that broke something critical, that would have been avoided if we'd waited an extra couple of weeks. Hey Microsoft, are you going to foot the bill for us spending all this time trying to figure out and fix a problem you created? No, I thought not.

Well done. I'm now absolutely concrete on this - patches now happen no sooner than 1 month after update releases. The more you screw things like this up Microsoft, the more vulnerable your entire install base. Oh, but you don't care, because you want everyone to move to Azure instead of running on-premises anyway? Sure, but why in the world would I trust Azure when you muppets are still writing the same $#!%%^ code and have the same lax attitude to testing (I mean, using your install base as guinnea pigs)? GCS has been knocking on our doors pretty loudly, and frankly at this point I trust them a whole heck of a lot more, they're a great deal cheaper, far more flexible and agile, with an order of magnitude higher reliability.

/rant