How do you DO?

Saving Your WAN Without Giving Your Security Team a Heart Attack

If you’ve successfully shifted (or are working on shifting) your workloads over to modern management—congratulations. Having Windows Update for Business (WUfB), Windows Autopatch, and Cloud Update handling your deployment rings in the background feels like a massive win. Your devices stay current, and even those unloved Microsoft Store (UWP) and Intune Win32 apps finally update automatically.

But there’s a massive catch: all that seamless cloud updating generates a ridiculous amount of background noise on the network.

On average, a single Windows 11 workstation fully loaded with the standard Microsoft stack—OS cumulative updates, Microsoft 365 Apps, Teams, and Edge—pulls down between 5 to 8 GB of data every single month.

For a user working from home, that’s fine. It’s their data cap, not yours. But when you multiply that 8 GB across 5,000, 10,000, or 50,000 endpoints sitting behind corporate firewalls or thin branch office pipes, things get ugly fast.

This is usually where the classic IT finger-pointing starts. The Network team watches the WAN links redline and begs you to fix it, while the Security team stares suspiciously at the exact built-in tool meant to solve the problem, ready to shut it down.

Enter Delivery Optimization

Microsoft actually planned for this exact bottleneck years ago by baking Delivery Optimization (DO) Peering right into the OS.

Field Note & Reading Link:

Microsoft recently published an official deep dive covering baseline policies and registry configurations: Configure Delivery Optimization for Windows to save bandwidth and speed up deployments. While Microsoft’s guide lays out the core mechanics and recommended defaults, the paragraphs below focuses on how to take those foundational concepts and tailor them to real-world network topographies and strict SecOps environments.

At its core, DO is just a cloud-coordinated peer-to-peer (P2P) distribution engine. Instead of having 500 laptops in the same building all hitting the internet to download a 1 GB Edge update from Microsoft’s CDN, DO forces them to share:

• The Seed: One machine (or many machines) downloads the update from the Microsoft CDN and caches it locally.
• The Check-In: Those machines check in with the cloud-managed DO service to let it know they have the payload ready.
• The Handshake: When other machines on the same network need that same update, the DO cloud service acts as a matchmaker and tells them, “Don’t hit the internet. Grab it straight from the machine down the hall over TCP port 7680.”

Letting the Network Dictate the Settings

The common trap that some admins fall into when trying to manage this traffic is hardcoding a global policy in Intune or GPO. They enforce Download Mode 2 (Group) and push a static Group ID string out to the entire fleet.

The problem is that static policies are completely blind to local topology. A rigid cloud policy treats a laptop the same whether it’s plugged into a 10 Gbps core switch at HQ, sitting on a choked branch office T1, or pulling over a narrow legacy VPN tunnel.

Instead of forcing a static config from the cloud down, you want to let the network infrastructure itself tell the endpoint where it sits and how it should behave. The infrastructure should be the source of truth, dynamically adapting client behavior as fast as your users move.

The Security Pushback on Peering

If you mention “peer-to-peer traffic” to a security engineer, expect them to flinch. The knee-jerk reaction is almost always: “You want endpoints talking directly to each other? Absolutely not. Turn it off.”

To be fair, you have to look at it through their eyes. Security teams spend a lot of time and money enforcing micro-segmentation, putting firewalls between departments, and blocking lateral movement. To them, open P2P protocols look like an absolute nightmare:

• Lateral Movement: If one machine gets hit with malware, an open P2P port looks like a convenient highway for it to spread sideways across the network.
• Data Exfiltration: Security tools are usually trained to flag internal devices bulk-transferring files to one another as a potential insider threat or data breach.
• Loss of Visibility: If devices are sharing files directly, standard network traffic analyzers lose sight of what is actually being moved.

It’s a classic deadlock. The Network team needs to save the WAN, but the Security team doesn’t want an unmonitored back alley bypassing their perimeter defenses.

The Defenses: How Microsoft Quiets the Security Panic

To get Security to back down, you have to show them the underlying architecture. Microsoft built an incredibly tight, zero-trust framework directly into the Delivery Optimization engine.

When your security team claims P2P traffic is a wild-west liability, drop these three technical facts on them:

1. Peer-Untrusted Architecture (The Hash Chain):

Delivery Optimization assumes that every single peer on your network is compromised. A client device never blindly trusts a file sent by a neighboring laptop. Before a download even starts, the client establishes a secure HTTPS connection directly to the official Microsoft DO Cloud Service to pull down a Piece Hash File (PHF). This is a cryptographically signed manifest containing SHA-256 block-level hashes for every 1 MB chunk of the update. If a single bit is altered or modified by a rogue peer, the hash fails, the chunk is instantly tossed out, and the client falls back to the secure Microsoft CDN. (Review the DO Technical Workflow & Hash Chain Architecture).

2. The Rogue Peer Ban Hammer:

If a compromised machine tries to flood the network with junk data, DO handles it automatically. Under DO’s content verification safeguards, each 1 MB chunk is checked against the cloud-issued SHA-256 hash file. If a peer sends a threshold of invalid or corrupted pieces to a client, that client instantly bans the rogue peer from its source list for the next several hours. (See Microsoft’s official breakdown under How Delivery Optimization Works: Content Verification).

3. Restricted Asset Channels, Not File Shares:

DO doesn’t use risky, broad protocols like SMB or open network shares. It uses a highly restricted, compiled binary protocol operating strictly over TCP port 7680. Devices cannot browse or query each other’s caches; only the cloud-managed Microsoft DO service acts as the central matchmaker. (See the DO Security FAQ & Port Requirements).

When Security Says “No”: Centralizing with Microsoft Connected Cache

If you run into a brick wall where your security team simply will not approve P2P traffic under any circumstances, you don’t have to give up and watch your network melt. You just pivot to a centralized caching strategy.

Microsoft’s solution here is Microsoft Connected Cache (MCC). It gives you the exact same bandwidth savings as DO peering, but completely satisfies Security because endpoints never talk to each other. Instead, they pull content from a trusted, designated local server over standard web ports (80/443).

Depending on your environment, you have two ways to deploy this:

• The Co-Management Route (SCCM / ConfigMgr Connected Cache): If you still have Microsoft Configuration Manager (SCCM) distribution points on-premises, you can turn them into MCC servers with a single checkbox in the DP properties. SCCM handles the backend automatically, and your cloud-managed Intune/Autopilot devices will dynamically use that local cache based on your existing Boundary Groups.
• Going Cloud-Native (Microsoft Connected Cache Standalone): If you are a completely cloud-native shop, you can deploy the standalone version. Configured entirely from the Azure Portal, this runs as a containerized solution (leveraging Azure IoT Edge) on a local Windows or Linux host machine inside your data center or branch offices.

The Hybrid Architecture Strategy: Implementation & Traffic Routing

The ideal setup is an environment that uses your fastest lines where available, relies on secure P2P for slow physical offices, and completely leaves your VPN alone when users are remote. This strikes a pragmatic compromise using central caching where infrastructure exists and peering only where necessary.

By utilizing custom DHCP Options, you let the local network infrastructure dynamically tell the endpoint what its Delivery Optimization strategy should be.

Here is the breakdown of how to route this traffic cleanly:

1. Fast HQ Sites: Prioritizing the Central Cache Server
   1. The Network Configuration: Configure DHCP Option 235 (Text/String format) on your corporate HQ scopes and point it to the IP or FQDN of your local MCC server.
2. Slow WAN & Branch Sites: Ring-Fenced Micro-Peering via Option 234
   1. The Network Configuration: On the DHCP scopes for Branch Office A, generate a unique text GUID or string identifier and assign it to DHCP Option 234 (DOGroupID). For Branch Office B, generate a completely different string identifier and assign it to its respective Option 234 scope.
   1. The Result: When a machine boots up in Branch A, it receives GUID-A from DHCP Option 234 and will only peer with other machines in that exact physical building. It is mathematically impossible for it to cross the WAN link to pull chunks from a machine at HQ or Branch B.
3. Over the VPN: Protecting the Tunnel from Melting
   1. The Network Configuration: Most modern VPN gateways do not pass through local DHCP broadcast options anyway. Because remote clients won’t see Option 234 or 235, the DO engine automatically defaults back to standard internet downloading.
   1. The Client Configuration: To be absolutely sure, make sure you configure the VPN Keywords / Subnet Exclusions policy within Intune or GPO to explicitly disable all P2P and local cache hosting whenever a device lands on a VPN subnet range.
4. In the Wild: Keeping Public Wi-Fi and Home Networks Clean

For major corporate campuses with fast local networks, a dedicated cache server is the best option.

(Note: Option 234 reads input as a custom text/string value. If formatted incorrectly on the DHCP server side, the Windows DO client will ignore it and fall back to its next configured source).

If a remote client attempts to pull updates from an on-premises MCC server or peer with an on-prem machine across a narrow split-tunnel VPN, you end up hairpinning gigabytes of data right back through your corporate internet gateway. That defeats the entire purpose of modern management.

When an enterprise laptop leaves the corporate network entirely and connects to home Wi-Fi or a hotel network, it receives no corporate DHCP options. It automatically falls back to pulling encrypted, compressed updates directly from the Microsoft CDN over the local internet pipe.

The Compliance Shield: Locking Down the Windows Firewall

To get a final sign-off from Security, you can back up your DO configuration with ironclad Windows Defender Firewall rules targeting TCP Port 7680. This gives you ultimate containment.

• Blocking the Wild (Public & Private Profiles): Create an inbound firewall rule targeting the Public and Private firewall profiles. Set the action to Block inbound TCP Port 7680. This completely immunizes the machine when it is sitting on home Wi-Fi or a public hotspot.
• Safeguarding the Core (Domain Profile at HQ): At your fast HQ buildings where the MCC server handles the workload, you may want to kill P2P entirely (network and security may not want that traffic spanning across subnets). Create an inbound firewall rule targeting the Domain profile, scope it specifically to your HQ building subnets, and set the action to Block TCP Port 7680. Endpoints can freely talk out to the local MCC server over standard web ports (80/443), but lateral P2P traffic within the building is dropped instantly by the OS.

Enabling the Grand Design: One Policy to Rule Them All

The best part about this entire architecture? You don’t need to build a complex web of competing policies for different offices. You can configure a single unified policy in Intune or GPO and target it globally to all devices.

By configuring a single profile that includes both your peer configurations and Microsoft cache parameters, a single policy behaves exactly how it needs to, whether a user is at HQ, a remote branch, a hotel, or on the VPN. You deploy once and let your network infrastructure do the rest of the heavy lifting.

Configure these three critical settings within your global baseline policy (MDM CSP / OMA-URI values) to activate the setup:

• Set the Correct Download Mode (DownloadMode): Set your global Download Mode to Group (Integer Value = 2). This is the prerequisite foundation that allows devices to look at local boundaries rather than standard LAN-wide broadcasting.
• For Peering Boundaries (DOGroupIDSource): Set this policy to DHCP Option ID (Integer Value = 3). This tells the endpoint to actively read DHCP Option 234 to discover its local micro-peering Group ID.
• For Caching Servers (DOCacheHostSource): Set this policy to DHCP (Integer Value = 2). This instructs the endpoint to read DHCP Option 235 to find its local Microsoft Connected Cache host.

Community Credits & Deep-Dive Reading

If you are building out this architecture for your own environment, you can check out the official documentation and community playbooks directly:

• Official Microsoft References:
  • Delivery Optimization FAQ
  • Windows Update Security Framework
  • Getting Started with Microsoft Connected Cache
• Community Shout-out:
  • Huge shout-out to the team over at MSEndpointMgr. If your enterprise sits behind a rigid cloud proxy, their masterclass guide Delivery Optimization & Zscaler – A How-To Guide is an absolute necessity for configuring your SSL bypass rules and ensuring your proxies don’t mask client source IPs during cloud matchmaking.

The Bottom Line: Disabling Delivery Optimization because of security anxiety is a failure of engineering. By implementing localized, network-driven parameters backed up by OS-level firewall blocks, you satisfy the CISO’s zero-trust goals while preventing your network links from collapsing during the next major Windows patch Tuesday.