Features removed on version 1703Windows Update will no longer postpone the download of certain critical updates if the device is connected to a network that was designated by the user as being "metered". Although meant to prevent the updates from utilizing data allotments, this behavior had been used as a workaround by users to defy the requirement for all updates to be automatically downloaded.

Don't you dare try to defy Microsoft! They know what's best for you and you'd better like it.

To be fair, that's Wikipedia-speak. The original PC World article cited as reference is much blander:

That last sentence, where Microsoft says it will automatically download updates to keep “Windows running smoothly,” is absent in the current version of Windows 10. Microsoft told WinSuperSite it made the change so that it has the ability force critical update patches if necessary. “We don’t plan to send large updates over metered connections, but could use this for critical fixes if needed in the future,” Microsoft said.

Update: Microsoft’s current metered connection FAQ reveals that with flagged connections, “Windows 10 will only download priority updates.” The new verbiage makes that caveat more visible.

Given that someone is always poking at Windows 10 to see if a new hole appears and most computers are always-online these days, it's not possible to keep the platform secure if Home users were able to block all updates indefinitely. It doesn't look like anything is changing, it's just being made more obvious to the user.

If they were being smart they'd have it figure out what your maximum downstream is, then back off and use a percentage of that to avoid tanking your bandwidth and latency. They wouldn't have nearly so many people trying to figure out how to disable it if it didn't cause massive disruptions.

There are options via Group Policy to do that now. Unfortunately he's on the Home edition of 10. Winaeromight have a work around for Home.

Oh great, two steps forward and one step back -- the backwards step being the 4-5 levels of options needed to access that point. This is exactly the sort of long beard the traditional Windows Control Panel applets grew and it looked like the new Settings interface was finally attempting to hire a barber. Instead, we now get two long beards, tangled into each other.

Oh great, two steps forward and one step back -- the backwards step being the 4-5 levels of options needed to access that point. This is exactly the sort of long beard the traditional Windows Control Panel applets grew and it looked like the new Settings interface was finally attempting to hire a barber. Instead, we now get two long beards, tangled into each other.

At least it's discoverable by looking around locally - things like the registry edit currently fixing things for me are hopeless without asking the internet.

Ryu Connor wrote:

QoS being setup on the home router should be able to provide some relief as well.

Possibly, yes. That was next on the list if internal fixes didn't work, and it's mainly troublesome because I don't know if the IP is consistent and it uses quite a range of ports.

EDIT: To be clear, you *ARE* *ONLY* using 80/443 as Ryu Connor explained, the range of ports you are referencing are just the corresponding short-lived and essentially random client-side ports.

That is, you connect to port windowsupdate.com:80, and you designate 47*** to be the port packets sent to you in response will use. This is a necessary component of TCP/IP: Without it you could not readily distinguish which response packets went to which socket/program. These client ports are temporary with no lasting meaning, hence "ephemeral": When people talk about ports, they almost always mean the server ports. (The response port cannot also be 80, as anything under 1024 is traditionally privileged and thus unavailable to userspace. Also, it would mean that two web servers couldn't use each other, among other conceptual problems)

---

Where this can be a problem is if you generate so many connections (you can easily open hundreds/thousands to port 80 on a singular host) that you can actually run out of client side ports to match them (it's only a 16-bit field, for *everything*). This was a bigger problem years ago when the defaults where sometimes just in the range of a few thousands, but can still be a problem today when there are ~10k+ available in virtually everything because certain protocols, if unconstrained by sane thresholds, will open up tons of connections (*cough* torrents). As you have described previously, that situation manifests itself as a loss or serious impairment of connectivity.