Skip to main content

⚙️🪟💻CP - Updates - Delivery Optimization

Why do we have this policy? 🚀​

Windows Update downloads can be massive. But here's the thing: those updates contain security patches. And those patches? You want them on your devices as fast as possible.

Because when a critical vulnerability gets patched, and your devices are still waiting 3 hours because they're all individually downloading 4GB of updates while crushing your internet connection... you have a problem. 🔥

Delivery Optimization solves this by letting devices share updates with each other on the local network (peer-to-peer). This means:

  • Faster updates → security patches arrive quicker
  • Less WAN load → your internet stays usable
  • More efficient → one download gets shared locally with hundreds of devices

So yes, it saves bandwidth. But more importantly: it ensures that security patches get to all devices quickly. And that's what really matters. 🛡️

The situation without Delivery Optimization:​

  • 100 devices each download a 4GB feature update
  • 400GB WAN traffic 💀
  • Internet is practically unusable for 6 hours
  • Updates take forever
  • Security patches arrive slowly
  • Users complain
  • You get blamed

With Delivery Optimization (as we configure it):​

  • First device downloads 4GB from Microsoft
  • Other 99 devices download from each other (local network)
  • ~4GB WAN traffic ✅
  • 396GB LAN traffic (but LAN is fast and free)
  • Internet keeps working normally
  • Updates complete within an hour instead of six
  • Security patches roll out fast
  • You're a hero 😎

Saving bandwidth is nice. But rolling out security patches quickly? That's crucial.

🛠️ Settings​

SettingValueWhy
DO Absolute Max Cache Size20 GBMaximum cache for downloaded updates. 20GB is enough for multiple updates at once.
DO Allow VPN Peer CachingNot allowedNo P2P over VPN. Devices on VPN are remote and should just download directly.
DO Delay Background Download From Http60 secondsWait 60 sec for P2P peers before using HTTP (background downloads).
DO Delay Cache Server Fallback Background120 secondsWait 2 minutes for cache server before using HTTP fallback (background).
DO Delay Cache Server Fallback Foreground120 secondsWait 2 minutes for cache server before using HTTP fallback (foreground).
DO Delay Foreground Download From Http60 secondsWait 60 sec for P2P peers before using HTTP (foreground downloads).
DO Disallow Cache Server Downloads On VPNEnabledBlock cache server downloads over VPN. Remote devices just download via HTTP.
DO Download ModeHTTP blended with peering behind the same NAT (Mode 1)P2P within the same local network. Simple, safe, effective.
DO Max Background Download Bandwidth0 KB/s (unlimited)No limit. Let updates come in as fast as possible. Security patches don't wait.
DO Max Cache Age7 daysKeep downloads in cache for 7 days so other devices can use them.
DO Max Foreground Download Bandwidth0 KB/s (unlimited)No limit. Foreground downloads = important. Let them through.
DO Min Battery Percentage Allowed To Upload40%Devices on battery only upload if battery > 40%. Prevents dead batteries.
DO Min RAM Allowed To Peer2 GBDevices need at least 2GB RAM to share. Prevents performance issues.

📖 Download Mode explanation​

We use Mode 1: HTTP blended with peering behind the same NAT

This means:

  • Devices on the same network share updates with each other
  • First device downloads from Microsoft
  • Other devices download from each other (P2P)
  • Stays within the local network (not over internet or VPN)

Why Mode 1?

  • ✅ Simple, no complex config needed
  • ✅ Stays within LAN boundaries (safe)
  • ✅ Huge bandwidth savings
  • ✅ Security patches roll out blazing fast within an office

👥 Assignment​

✅ Included groups:​

GroupStatusFilterFilter mode
All devicesActiveNoneNone

❌ Excluded groups:​

Why everyone? Because every Windows device benefits from faster updates. And especially from faster security patches.

🧠 Fun facts & tips​

Why those delays?​

You see we wait 60-120 seconds before falling back to HTTP. Seems long? It's not.

  • P2P discovery takes time → devices need to find each other on the network first
  • Cache servers need to respond → if you have one, give it time
  • 60 seconds waiting vs. downloading 400GB → easy choice

Those delays ensure that local sources (peers, cache servers) actually get used before we go to the internet.

VPN = no P2P​

We have two settings to block P2P/cache over VPN:

  1. DO Allow VPN Peer Caching → Not allowed
  2. DO Disallow Cache Server Downloads On VPN → Enabled

Why?

  • Device on VPN = remote device
  • Remote devices should just download directly
  • Not via peers (too slow)
  • Not via cache servers at the office (VPN tunnel = bottleneck)

Simple: VPN = direct download. LAN = P2P party. 🎉

Monitoring: does it actually work?​

On a Windows device, run this in PowerShell:

Get-DeliveryOptimizationStatus

This shows:

  • Download mode (should be 1)
  • Bytes downloaded from peers vs. HTTP
  • Bytes uploaded to peers

Example output:

DownloadMode       : LAN (1)
BytesFromPeers    : 2,147,483,648
BytesFromHTTP     : 536,870,912
BytesToPeers      : 4,294,967,296

Translation: 2GB from peers, 512MB from HTTP, 4GB shared with others.

That's a 4:1 ratio. Beautiful. And most importantly: security patches arrived fast. 🛡️

🎯 The bottom line​

Delivery Optimization isn't just about "saving bandwidth" (although that's nice too).

It's about:

  • Security patches that roll out fast
  • Devices helping each other instead of all downloading individually
  • A network that keeps working during Patch Tuesday
  • Users who don't complain about slow updates

Because a security patch that arrives 6 hours later is a security patch that arrives too late.

With this config: ✅ Updates get shared blazing fast within offices ✅ Security patches reach all devices quickly ✅ Internet stays usable ✅ You don't have to solve "update is stuck" tickets

🔗 Documentation​

Configure wisely. Patch with speed. And never trust a device that says "Installing updates: 100%..." for the 47th time. 🙃