Your branch office still saturates the WAN: how Delivery Optimization picks peers, and how to prove peering actually works

Delivery Optimization is the single most widely deployed piece of peer-to-peer software in the enterprise, and almost nobody checks whether it works. It is on by default. It never throws an error when it fails. It just quietly stops peering, and your branch office downloads the same four gigabyte feature update once per device. Nothing in the Intune console will tell you. This post explains what Delivery Optimization actually is, exactly how it decides who to peer with, and how to prove from a single device whether bytes really arrived from a peer.

The problem: 200 devices, 200 copies of the same update

Start with what the thing is, because the name is unhelpful. Delivery Optimization, abbreviated DO throughout, is not an update product. It is a downloader. Microsoft describes it as a reliable HTTP downloader with a cloud-managed solution that lets Windows devices pull content from alternate sources as well as from the normal internet servers.

Those alternate sources are two things. Other Windows devices, called peers. And a dedicated cache server, called Microsoft Connected Cache. The traditional internet servers are referred to throughout the Microsoft documentation as the HTTP source.

DO is not just for Windows Update. Microsoft publishes the full list of callers, and it is long: Windows Update quality and feature updates, drivers, language packs, Microsoft Store apps, Microsoft Defender definition updates, Intune Win32 apps, Microsoft 365 apps and updates, Microsoft Edge updates, Configuration Manager express updates, dynamic updates, Teams updates, Xbox Game Pass on PC, Windows Package Manager and the MSIX installer.

Here is the failure that costs money. A site has 200 Windows 11 devices behind one internet circuit. A feature update lands. In theory the first device pulls it from the content delivery network, and the other 199 pull most of it from that first device over the LAN. In practice the site pulls roughly 200 times the payload across the WAN, the circuit saturates for a working day, and the service desk gets tickets about Teams audio.

Nothing failed. That is the whole problem. DO is designed to fall back to the HTTP source seamlessly when peers are unavailable. The fallback is the feature. It also means a completely broken peering configuration produces exactly the same user experience as a perfect one, only slower and more expensive.

There are only four real failure modes, and they are all specific:

1. The download mode is wrong, so peering is disabled by policy.
2. The device cannot reach the DO cloud service, so it never receives a peer list.
3. Devices are in different peer groups, so the cloud service never matches them.
4. The peer port is blocked, so the peer list arrives and every connection to it fails.

Each one has a different fix, and each one leaves a different fingerprint on the device. The rest of this post is about reading those fingerprints.

Why it happens: how DO actually chooses a peer

Follow the chain in order. Nothing here is magic, and every hop can break independently.

First, a caller starts a download. Microsoft is explicit that DO only starts when an application or service integrated with DO starts a download. Nothing polls. Nothing runs on a schedule.

Second, the DO client on the device contacts the DO cloud service over HTTPS. It sends metadata about the content it wants. The service replies with a list of candidate peers and their IP addresses.

Third, and this is the part most people get wrong, the device connects to those peers directly over TCP. Microsoft states plainly that DO does not use multicast. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses, and client devices then connect to their peers to obtain download files over TCP/IP.

Fourth, DO downloads from peers and from the HTTP source in parallel, and tapers off the HTTP requests as the peers keep up. For background downloads Microsoft documents that DO drops the HTTP connections entirely once peers meet the minimum quality of service speed.

The six download modes, verified

Download mode is the master switch. It is one policy, DODownloadMode, and its value decides whether peering is even on the table. These are the documented values and behaviours.

Note the automatic behaviour buried in mode 99. Microsoft documents that DO switches to Simple mode by itself when the cloud services are unreachable. So a device reporting mode 99 may not be misconfigured at all. It may be telling you that *.do.dsp.mp.microsoft.com is blocked. Microsoft's own troubleshooting guidance says exactly that: if the download mode is 99, it could indicate your device is unable to reach the DO cloud services.

What a group actually is

In LAN mode the group is implicit. It is every device that reaches the internet from the same public IP address, which usually means behind the same network address translation device. That is fine for a flat office and useless for a hub-and-spoke network.

Group mode replaces that with an explicit identifier. Two policies control it, and their interaction is the single most common source of a group that never forms.

DOGroupId takes an arbitrary group ID that the device belongs to, and Microsoft states a GUID must be used. DOGroupIdSource instead tells Windows to derive the ID from something the device already knows. These are its documented values.

Three documented rules decide the outcome, and you need all three.

1. DOGroupId wins. Microsoft states that the DOGroupIdSource policy is ignored if the DOGroupId policy is also configured.
2. If neither is configured, the default order is AD Site (1), then authenticated domain SID (2), then Microsoft Entra tenant ID (5), in that order.
3. If DOGroupIdSource is set to DHCP Option ID (3) or DNS Suffix (4) and those methods fail, the default behaviour above is used instead.

There is one more trap. Microsoft documents that if you configure DOGroupIdSource to anything other than 0 to 5, the policy is ignored. Not rejected loudly. Ignored.

Restricting peer selection, and the Windows 11 default change

DORestrictPeerSelectionBy narrows peer selection further, on top of the download mode. Its documented values are 0 for None, 1 for Subnet mask, which restricts peer discovery to devices within the same subnet, and 2 for Local Peer Discovery using DNS Service Discovery over multicast DNS.

Microsoft states plainly that selecting either Subnet mask (1) or Local Peer Discovery (2) prevents peer discovery across subnets. It also documents a behaviour difference that catches people migrating from Windows 10: on Windows 10 no peer selection restriction is applied by default, while on Windows 11 the default behaviour for LAN download mode 1 restricts peers to the local subnet.

The silent disqualifiers

Even with a perfect mode and group, a device can refuse to peer because it fails a documented eligibility check. These are the defaults, and every one of them is a real reason for zero peer bytes.

Two of these deserve emphasis. The 50 MB default means a fleet whose largest regular download is a 40 MB Intune app will show zero peering forever, correctly. And the VPN rule is keyword-based: Microsoft documents the default keyword list as "VPN", "Secure" and "Virtual Private Network", matched against the network adapter Description and FriendlyName strings. An adapter called SecureConnect matches "Secure" and silently disables peering.

The ports, and what is actually listening

Microsoft publishes a ports table for DO. These are the documented entries.

Microsoft notes that port 7680 is automatically registered and opened by the DO service, and that blocking it disables peer-to-peer while leaving HTTP downloads over 80 and 443 working. That is the exact shape of the failure: everything still downloads, just never from a peer.

Windows ships two inbound Windows Defender Firewall rules for this. On a Windows 11 Enterprise device I checked, both are present and enabled by default:

If your Endpoint Security firewall profile in Intune sets the inbound default to Block and does not merge local rules, those two rules stop applying. That is a configuration you own, not a Windows default.

System files, the service, and where the state lives

DO runs as a single service. Its short name is DoSvc and its display name is Delivery Optimization. On the Windows 11 device I inspected, the service registry key reports these values, which you can read yourself.

So the binaries involved are these. All of them exist in C:\Windows\System32 on Windows 11, and I verified each one on disk before listing it.

There is no scheduled task. I enumerated every task under \Microsoft\Windows\ on a Windows 11 device and found nothing that drives DO. This is consistent with the documented design: DO only starts when an integrated caller starts a download, so there is nothing for a scheduler to trigger. If you were looking for a DO task to check the state of, there is not one, and that is expected.

How to verify: prove the bytes before you change anything

Everything in this section is read-only. Run it before you touch a single policy.

Step 1: what mode is this device actually in, and who set it

Two cmdlets answer this. Get-DODownloadMode returns the currently active download mode as a string. Get-DOConfig lists the local configuration and policies applied to DO, and Microsoft documents that each policy is listed with the current set value and the provider of that policy. That provider field is the part people miss, and it is how you tell a Group Policy value from an Intune value from a platform default.

Read the output as a chain. The cmdlet gives you the effective value. The provider field gives you the reason. If the two disagree with your intent, you have a policy conflict, not a network problem.

Step 2: the registry reference for the whole feature area

Every DO policy lands in one key. Microsoft publishes the registry key name for each setting in the Policy CSP documentation, and it is the same key for all of them. I also confirmed the value names directly from the shipping administrative template, C:\Windows\PolicyDefinitions\DeliveryOptimization.admx, which is the authoritative on-device source.

Two of the ADMX-backed settings split into four values each rather than one. The business-hours throttles write DOSetHoursToLimitForegroundDownloadBandwidth_From, _To, _In and _Out, and the same four suffixes for the background equivalent. If you are writing a detection script, look for the suffixed names, not the base name.

Here is what that key looks like in Registry Editor on a device where the policy is set by Group Policy.

Intune-applied settings do not land here. They land under the policy manager key, which is worth knowing because it is where you prove the MDM channel delivered the setting. On the Windows 11 device I checked, each value also has companion _ProviderSet and _WinningProvider values.

Step 3: prove the bytes

This is the step that settles arguments. Get-DeliveryOptimizationStatus returns a real-time snapshot of all current DO jobs, one object per file. These are the documented fields that matter for peering.

The distinction between NumPeers being zero and BytesFromPeers being zero is the most useful diagnostic split in the whole feature. Zero peers offered means the cloud service could not match this device to anyone. Peers offered but zero bytes received means the match worked and the connection failed, which points at port 7680.

Read the first block as a ratio, not an absolute. A device that has only downloaded small Intune apps will show zero peer bytes and be perfectly healthy, because of the 50 MB minimum. Read the second block as a discovery test. If NumberOfPeers is zero on both devices after Microsoft's own two-device procedure, the cloud service is not matching them.

Two more documented cmdlets are worth knowing. Get-DeliveryOptimizationPerfSnapThisMonth returns the same class of data limited to the current calendar month, which is the right window for a Patch Tuesday post-mortem. And Get-DeliveryOptimizationStatus -PeerInfo, added in Windows 10 version 2004, returns a real-time list of potential peers per file including the documented ConnectionEstablished flag. That flag is the cleanest possible answer to "is the port blocked".

Step 4: Event Viewer, and the honest answer about Event IDs

This is where I have to correct a common assumption, including one I started with. There is no Microsoft-Windows-DeliveryOptimization/Operational event log channel on Windows 11. I enumerated every event log on a Windows 11 Enterprise device and found no Delivery Optimization channel at all.

What does exist is an event provider. Two of them, in fact, named DeliveryOptimization and Microsoft-Windows-DeliveryOptimization. The second links to the Application log, and its manifest defines exactly one event. Its description template is "The policy '%1' was set with the value '%2', which is invalid and will be ignored." That is the entire published event surface.

Step 5: the log files that do carry the detail

The real diagnostic detail is in Event Tracing for Windows trace files, not text logs. They live in the service profile of the account DoSvc runs as.

You do not open ETL files in a text editor. Microsoft documents Get-DeliveryOptimizationLog for this, and states that if no path is specified it reads all logs from the DoSvc log directory, which requires administrator permissions.

That hr = 80072ee7 is worth decoding, because it turns a vague network complaint into a specific one. 0x80072EE7 wraps WinINet error 12007, which Microsoft documents as ERROR_INTERNET_NAME_NOT_RESOLVED, "The server name could not be resolved." A name resolution failure against geo.prod.do.dsp.mp.microsoft.com means DNS or a proxy is eating the DO cloud service. No cloud service means no peer list, which means no peering.

Step 6: the port test Microsoft actually documents

If peers are being offered but no bytes arrive, test the port directly between two devices. Microsoft documents both a Telnet test and the modern equivalent.

That idle-shutdown behaviour is the reason a single failed port test proves nothing. Confirm the target is listening before you conclude the firewall is at fault. This is the most common false positive in DO troubleshooting.

The fix: mode, group, port, and the delay policies

Decide the mode first, because everything else follows from it.

If a site is one flat network behind one NAT device, LAN mode (1) is enough, and it is already the default. If a site has multiple subnets or VLANs, or you want remote offices to peer, Microsoft documents Group mode (2) as the answer, and calls it the recommended option for most organisations looking to achieve the best bandwidth optimisation.

For Group mode, pick one Group ID strategy and apply it consistently. Microsoft documents the DHCP option approach as querying DHCP Option ID 234 and using the returned GUID value as the Group ID, which is attractive because it makes the group follow the network rather than the device object. The alternative is an explicit DOGroupId GUID per site, which is more work and completely deterministic.

Configuring it in Intune, click by click

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, then Manage devices, then Configuration, then Create, then New Policy.
3. For Platform, select Windows 10 and later.
4. For Profile type, select Templates, then Delivery Optimization.
5. Select Create.
6. On the Basics page, give the profile a name and a description, then select Next.
7. On the Configuration settings page, set Download Mode to Group (2), then set Select the source of Group IDs or Group ID according to the strategy you chose. Then select Next.
8. On the Scope tags page, add scope tags if you use them, then select Next.
9. On the Assignments page, target a pilot group first, not All Devices. Then select Next.
10. On the Review + create page, select Create.

If you prefer the raw CSP, every setting has a documented OMA-URI under one path. The device-scope prefix is the same for all of them.

Configuring it in Group Policy, click by click

1. Open the Group Policy Management Console and edit a GPO scoped to the site.
2. Expand Computer Configuration, then Policies, then Administrative Templates, then Windows Components, then Delivery Optimization.
3. Open Download Mode, set it to Enabled, and choose Group (2) from the drop-down.
4. Open Select the source of Group IDs, set it to Enabled, and choose DHCP Option ID (3). Alternatively skip this and use Group ID with an explicit GUID per site.
5. Open Minimum P2P Content File Size (in MB) and set it to 10 for a site above 30 devices, or 1 above 100 devices.
6. Open Delay background download from http (in seconds) and set 60. Open Delay Foreground download from http (in seconds) and set 30.
7. Open Minimum Background QoS (in KB/s) and set a value below your observed average download speed.
8. Close the editor and let the GPO replicate, then run gpupdate /target:computer on a pilot device.

The administrative template file behind that node is DeliveryOptimization.admx, and Microsoft documents it as the ADMX file name for every one of these settings. Both a Group Policy path and an Intune path exist for DO, which is not true of every feature, so you are free to choose.

The values Microsoft actually recommends

Microsoft publishes a summary table of basic configuration recommendations. These are its documented values, not mine.

The port, and what not to do about it

Do not create a firewall rule for 7680. Windows already ships two, DeliveryOptimization-TCP-In and DeliveryOptimization-UDP-In, and Microsoft documents that port 7680 is automatically registered and opened by the DO service. Your job is to confirm nothing in your own Endpoint Security firewall profile or your network firewall is overriding them.

Two things to check on the network side. Allow TCP 7680 between the subnets you want to peer, in both directions. And if the peer group spans NAT boundaries in Group or Internet mode, allow UDP 3544 for Teredo, plus the documented Teredo server hostname win1910.ipv6.microsoft.com. Microsoft lists that hostname explicitly under "For group peers across multiple NATs (Teredo)".

The DO service endpoints must also be reachable. Microsoft documents these hostnames for the firewall allowlist: *.do.dsp.mp.microsoft.com for client-to-cloud communication, and *.dl.delivery.mp.microsoft.com plus *.windowsupdate.com for DO metadata.

Where Microsoft Connected Cache fits

Connected Cache is a software-only caching solution that delivers Microsoft content, and Microsoft documents two main offerings: one for internet service providers, in preview, and one for Enterprise and Education, generally available. Both are created and managed in the Azure portal. There is also a separate Connected Cache in Configuration Manager.

The important architectural point is that it does not replace peering. Microsoft states that when DO is configured to use peers and Connected Cache, the client connects to both in parallel, with no prioritisation between the two. If neither can supply the content, DO falls back to the HTTP source.

One ordering detail if you use both peers and Connected Cache. Microsoft documents that when both the HTTP delay policies and the cache-server delay policies are configured, both timers start from the beginning of the download and are not additive. If both are 60 seconds, fallback from the cache server to the HTTP source is immediate once the HTTP delay expires. The documented guidance is to set the cache-server delay higher than the HTTP delay.

Proof it worked: a real read-only run

The companion script for this post is Get-DeliveryOptimizationEfficiency.ps1. It reports the effective download mode with its documented meaning, the Group ID surface and how the group would be derived, the cache location and its size and thresholds, the state of both in-box firewall rules and whether anything is listening on 7680, and then the actual peering efficiency from three independent sources. It is read-only. It never calls a Set cmdlet, never clears or pins the cache, never touches a firewall rule, and never passes -Flush to the log cmdlet because -Flush stops the service.

The output below is a genuine run on a domain-joined, Intune-managed Windows 11 Enterprise device. Identifiers are replaced. It is a useful example precisely because the device is not healthy.

Read that as a narrowing exercise. The mode allows peering. The port is open and listening. So if there are no peer bytes, the failure must be discovery. The next section of the same run says exactly that.

That is the whole method in one screen. Zero peers offered plus an open port plus a name-resolution failure against the DO cloud service equals a proxy or DNS problem, not a Delivery Optimization problem. Without the byte counters you would have guessed. With them you have a specific hostname to take to the network team.

Note also what the same run proves about Connected Cache. This device pulled 4.66 GB from a cache server this month with no DOCacheHost configured at all, which is consistent with Microsoft's documented behaviour of downloading from a Connected Cache server hosted by an internet service provider. Peering was broken. Caching was not. Those are genuinely separate paths.

Community deep-dives worth reading

I fetched and read both of these before citing them.

References

• What is Delivery Optimization? - Microsoft Learn. The content-type support matrix and the NAT default.
• Delivery Optimization reference - Microsoft Learn. Every policy, every default, the download mode table and the Bypass deprecation.
• Configure Delivery Optimization for Windows - Microsoft Learn. The ports table, the firewall hostnames and the recommended-values summary.
• Monitor Delivery Optimization - Microsoft Learn. The cmdlets and every field they return.
• Troubleshoot Delivery Optimization - Microsoft Learn. The two-device test and the port 7680 check.
• Delivery Optimization Frequently Asked Questions - Microsoft Learn. Why the service is not listening on 7680, and the documented P2P efficiency ranges.
• Policy CSP - DeliveryOptimization - Microsoft Learn. OMA-URIs, allowed values and the registry key name for each setting.
• Windows Delivery Optimization settings in Microsoft Intune - Microsoft Learn. The profile creation steps and the April 2025 template change.
• Microsoft Connected Cache overview - Microsoft Learn.
• Error Messages (Wininet.h) - Microsoft Learn. Where 12007 and ERROR_INTERNET_NAME_NOT_RESOLVED are defined.

The companion script lives at github.com/Imran76Awan/Windows-11-Scripts under delivery-optimization-peer-caching-internals. It is read-only by design, it fails loudly rather than printing a clean report from a failed read, and it runs on both Windows PowerShell 5.1 and PowerShell 7.