Free tool
Delivery Optimization Advisor
Which mode, which group, and where does a cache belong?
Describe your sites — how many machines, how fast the link — and the tool names the Delivery Optimization mode that suits your topology, says where a cache is justified, and writes out the policies to set, with their values. It also works out what one wave costs each link: what it costs if every machine downloads from the CDN, and what it would cost if one machine did. The gap between the two is the prize; where you land between them is what a pilot tells you.
No sign-up, no cookie: what you enter stays in your browser and is gone when you close the tab — none of it leaves. Only the visit itself is counted, by a cookieless audience measurement that does not identify you, described in the legal notice.
The estate
The mode is a single policy for the whole estate, and these questions are what decides it: where you reach the Internet, what that path lets through, and what you have to designate a group with. The sites below decide the rest.
Your sites
A site is a set of machines behind one link. Two buildings joined by dark fibre and seen from the WAN as a single egress point are one site here; two floors on two separate links are two.
The configuration
The two volumes shown are the ends of a range: everything from the CDN at one end, a single download per site at the other. No estate reaches either. Where you land between them depends on the pace of your waves, on the cache expiry window — three days by default — and on the share of machines actually eligible to seed, none of which this page can see. Measure a pilot site over a real wave before quoting a figure to anybody.
A decision aid, not an audit. The tool reasons on what you declare; it sees neither your firewall rules, nor your proxy, nor the DoSvc version actually installed — on which part of the behaviour depends, pushed down by Microsoft's cloud service. Check the effective configuration on one machine per site before making it a standard.
The strategy
Delivery Optimization: what you need to know to decide
Delivery Optimization is not "the P2P thing": it is the service that downloads Microsoft content, and peer sharing is only one of its three sources. What follows is what you need in order to choose — the modes, what the network has to allow, and the traps that make half of these deployments fail without showing anything.
A multi-source downloader, not "the P2P thing"
Delivery Optimization is the Windows service — DoSvc — that downloads Microsoft content: Windows Update, the Store, Microsoft 365 Apps, Intune Win32 applications, Edge, Defender definitions. It assembles each file in pieces of about a megabyte, in parallel, from three sources: Microsoft's CDN, a local cache if one exists, and other machines. Peer sharing is only an optional layer: even in mode 0, DoSvc is the downloader, applies the rate limits and feeds the telemetry. Only mode 99 cuts every contact with the cloud service.
Two filters decide what is actually shared, whatever the mode: the cloud service's content policy has to allow it, and the file has to exceed DOMinFileSizeToCache — fifty megabytes by default. A thirty-megabyte Win32 application is therefore never shared, whatever you configure.
The five modes
| Value | Name | Peer scope | What it is worth in an enterprise |
|---|---|---|---|
| 0 | HTTP only | No peers | Servers, and machines exposed to networks you do not control. The Windows Server default. |
| 1 | LAN | Same public IP address | The client default, and the right choice as soon as each site has its own egress. |
| 2 | Group | Same GroupID, crosses NATs | For a central egress — provided the GroupID is under control. |
| 3 | Internet | Any peer | Never: a consumer default. |
| 99 | Simple | None, no cloud contact | Isolated networks — and the automatic fallback when the service is unreachable. |
Mode 100 (Bypass) was removed in Windows 11: a policy inherited from Windows 10 that still pushes it does nothing, and the value is treated as 0.
What the network must allow
One of these flows blocked is enough to drop the whole estate into Simple mode, with no message and no alert. It is the misconfiguration found most often.
| Flow | Port | Direction | If blocked |
|---|---|---|---|
| DO cloud service — *.prod.do.dsp.mp.microsoft.com | TCP 443 | Outbound | No content policy and no peers: Simple mode |
| Metadata — dl.delivery.mp.microsoft.com, *.windowsupdate.com | TCP 80 | Outbound | No peer byte can be verified, so none is accepted |
| Piece exchange between peers | TCP 7680 | Inbound and outbound | No more sharing; downloads continue from the CDN |
| Teredo — NAT traversal | UDP 3544 | Outbound | Only affects modes 2 and 3 across different NATs |
| Local mDNS discovery | UDP 5353 | Local multicast | Local Peer Discovery unavailable (Windows 11) |
A cloud proxy breaks grouping by public address
LAN mode has one grouping key: the public IP address the service sees. Behind a cloud proxy — Zscaler, Netskope, Prisma Access, Umbrella — there is no per-site egress any more: each machine heads for the nearest point of presence, and the address that comes out is no longer a property of the building. An ISP handing out a rotating NAT pool produces exactly the same effect.
Two failures follow, and they are each other's mirror image. The site is cut into pieces: two neighbouring machines present two addresses and are never put in the same group. And two sites merge: leaving through the same point of presence, they present the same address and exchange pieces across the WAN. Neither shows — the downloads complete, from the CDN.
What fixes it
- Move to mode 2: the GroupID is a value you control, not an address the proxy chooses.
- Set it explicitly — DHCP option 234 for preference, failing that the Active Directory site.
- Add DORestrictPeerSelection = 1: the subnet is the only boundary the proxy cannot move.
- Unless the site's VLANs talk to each other at gigabit — there, cloistering costs more than it protects.
What still needs watching
- With no DHCP option and no AD site, both keys are missing at once: sharing will not hold.
- Neighbouring machines with different public addresses become "group" peers: those are subject to the bandwidth limits, LAN peers are not. [to confirm at the pilot]
- The cache is immune to the problem: it is designated by a policy, not by an observed address.
- And it has to be excluded from the proxy: the client-to-cache flow is clear HTTP on port 80, outside the proxy policy.
Microsoft Connected Cache — a cache, not a catalogue
MCC pre-loads nothing and manages no catalogue: it stores what clients asked it for. The first machine on the site pays for the download, the rest are served locally — including when peer sharing is not working, which is its real value.
Advantages
- Independent of the machines: no battery, no disk, no expiry window to watch.
- Also serves the content too small to be shared between peers.
- The Azure resource is free; the licence is the one of the machines served (E3, E5, F3, A3, A5).
- The Azure metrics say what the cache really avoided, independently of the clients.
Drawbacks
- A server to install, patch and monitor on each site concerned.
- No proxy allowed between client and cache: the proxy policy does not apply to that flow.
- An unstable FQDN or an unresolved short name produces a permanent CDN fallback, and an invisible one.
- A hundred gigabytes of dedicated disk at least, or the installation fails.
Measuring: two reading traps
BytesFromHTTP includes the bytes served by the cache. Read as "what came from the CDN", it makes most of the saving disappear: a site well served by a cache shows a very low peer percentage and an excellent WAN saving. The right indicator is 1 − BytesFromCDN / TotalBytes, where BytesFromCDN = BytesFromHTTP − BytesFromCacheServer.
Overall efficiency is dragged down by everything below fifty megabytes, which is never shared. Report both figures: overall efficiency, and efficiency on eligible files alone. And without diagnostic data at the "Required" level, the WUfB reports show nothing at all on the Delivery Optimization side.
What remains to be measured before committing to figures
- The real density threshold — the one above which sharing becomes significant on a site. The 200 to 300 machines quoted everywhere are an order of magnitude, not a law.
- The configuration pushed by the cloud service — part of the client's behaviour is adjusted by Microsoft depending on the DoSvc version: two machines with identical policies can differ.
- How a slow cache behaves — the fallback is documented for an unreachable node; for a merely slow one, it has to be measured.
- Upload regulation on your links — it yields to interactive traffic, but behaves differently on links with high jitter.
- The gains outside Windows Update — Microsoft 365 Apps and Intune Win32 applications give far lower results: smaller and more fragmented content.