Microsoft Delivery Optimization: Implementation, Benefits, and Recommended Practices

Still updating Windows clients like it’s 2009?
Your network’s buffering, your users are suffering, and your clients are patchy at best.
Learn how Microsoft Delivery Optimization makes updates less painful and more gainful.
Read now, thank yourself later.

Delivery Optimization (DO) is a cloud-managed, peer-to-peer content distribution technology built into Windows 10 and 11. It allows devices to download updates and apps not only from Microsoft’s internet servers but also from alternate sources such as other devices on the local network or a local cache server. This approach reduces redundant internet downloads, easing bandwidth strain when many devices need the same content. In this article, we explain why and how to implement Delivery Optimization, cover network infrastructure considerations, highlight the benefits of Microsoft Connected Cache, quantify the expected bandwidth savings, and discuss security implications and recommended practices.

Although DO works for on-prem environments, using Active Directory and Configuration Manager, we will focus on the cloud native scenarios in this article.

What is Delivery Optimization and Why Use It?

Delivery Optimization is Windows’ built-in solution for efficient internet content delivery, designed to minimize internet bandwidth usage for updates and app installations. It works as a reliable HTTP downloader that can download content from multiple sources in parallel – not just from Microsoft’s CDN, but also from other PCs on the network or a dedicated cache if available. By sharing the download burden among devices, DO significantly reduces the amount of data pulled over the WAN. For example, if one PC downloads an update from Microsoft, others on the LAN can grab portions or the entirety of that update from the first PC, saving your internet bandwidth. The peer-to-peer aspect is optional but enabled by default on Windows 10/11 Enterprise and Education editions, meaning organizations are already benefitting from DO’s bandwidth savings without extra setup.

Why is Delivery Optimization important? In a typical enterprise, many devices often download the same large files (Windows updates, Office updates, application installs). Traditional direct download means each device pulls those files separately from the internet, multiplying bandwidth usage. DO cuts down this duplication by caching content on local PCs:

• Reduced WAN Bandwidth Consumption: Once one device has downloaded a package, other devices can get it locally instead of each using internet bandwidth. This is especially beneficial for big Windows upgrades or service packs.
• Faster Content Delivery: By downloading from peers (which are usually on high-speed LAN) in addition to or instead of a potentially slower internet link, devices often see faster download completion. DO can split content into pieces and fetch from multiple peers in parallel, maximizing utilization of available local resources.
• No Additional Infrastructure Required: DO is integrated into Windows – no extra servers or complex setup is needed to start seeing benefits. Organizations can leverage DO to offload traffic from WAN to the LAN with minimal effort.
• Cloud Intelligence: Delivery Optimization uses a cloud service to coordinate peer discovery and content availability. It automatically finds the best local sources and falls back to the cloud only if needed. This means it works intelligently out-of-the-box, adjusting to your environment.

In summary, Delivery Optimization is important because it dramatically improves the efficiency of content distribution in Windows environments. It reduces network congestion and costs, improves download speeds for end-users, and scales especially well as the number of devices increases.

Demystified/simplified functional description

There is uncertainty regarding the functionality of DO, leading many IT professionals to hesitate in adopting it. The following is a simplified overview of how DO operates, intended to clarify common misunderstandings by presenting it as a human dialog.

Client1: After scanning for available updates, it looks like I need KB123456. Hey Windows Update, where can I find KB123456?

Windows Update: Sure thing! Here’s a link to the CDN for KB123456.

Client2: After scanning for available updates, it looks like I need KB123456. Hey Windows Update, where can I find KB123456 (and by the way, I’m DO enabled)?

Windows Update: Sure thing! I see that you’re DO enabled so I won’t send you a link to the CDN, instead, here’s an array of hashes for chunks of data you should retrieve to be able to assemble KB123456.

Client2: Thanks Windows Update! It looks like I have part 5, 62 & 101 in my own cache already, please point me to where I can get the other parts.

Windows Update: No problemo, here’s a list of clients on your own subnet that have downloaded those chunks of data in the past.

Client2: Greetings fellow clients, I’m looking for chunks matching these hashes.

<Incoherent chatter between clients >

Client2: I got all of them except chunk 99 & 123, can I get them from you, Windows Update?

Windows Update: Certainly, here you go!

I hope this tongue-in-cheek explanation made you realize that there is no cache of files available anywhere, even if some clients possess all the required chunks and could theoretically assemble them into files. Additionally, if a client does not have permission to access a file, the server will not provide the necessary information for retrieval from peers. This is relevant from an Intune perspective, where DO-enabled applications may include sensitive data within company-specific applications, such as a license file in a Win32 application package. Most DO content originates from public sources and does not typically present security concerns. For more information about how caching DO data does not expose sensitive information to unauthorized clients, related technology BranchCache may be referenced. BranchCache enables the caching of any files, including those that may be sensitive, while still maintaining access restrictions and the protection mechanisms are similar to those of DO.

How to Implement Delivery Optimization (Step-by-Step)

Implementing Delivery Optimization in your environment involves a few key steps. Below is a step-by-step guide to enable and configure DO for optimal results:

1. Verify Prerequisites and Existing Settings: Ensure that client devices are running Windows 10/11. Delivery Optimization has been available since Windows 10 version 1511 so there’s really no reason for you to be using a too old version. Also make sure that Delivery Optimization is not disabled by any policy. By default, DO is on for Windows 10/11 Enterprise, Education, and Pro editions. If it’s disabled or restricted and you intend to use DO, plan to enable it via policy.

2. Configure Network Infrastructure for DO: For Delivery Optimization to work properly, certain network allowances are needed. Review your firewall and proxy settings:

• Open the necessary ports: Make sure Windows devices can communicate via TCP port 7680 (which DO uses for peer-to-peer sharing). Intra-network firewalls or the Windows Firewall should allow inbound and outbound TCP on 7680 between peers. Also, if you plan to enable cross-network or internet peering (Download Mode 2 or 3), allow UDP port 3544 for Teredo, which is used by DO for NAT traversal when reaching peers across different networks.
• Allow DO service endpoints: Delivery Optimization coordinates via a cloud service. Ensure that your devices can reach Microsoft’s DO services over HTTPS (TCP 443). This includes endpoints like .do.dsp.mp.microsoft.com and content hosts like .dl.delivery.mp.microsoft.com and Windows Update domains. If your firewall/proxy filters by domain, add these to the allow-list so DO can contact the cloud service and Microsoft’s content delivery network.
• Proxy configuration: If you use an HTTP proxy, configure it to support DO. Allow byte-range requests through the proxy, as DO often downloads files in chunks via range requests. Also, it’s recommended to bypass the proxy for DO cloud service URLs (or allow direct connections). Cloud-based security proxies (e.g. Zscaler) can interfere with peer discovery by obscuring the client IP; consider bypassing them for DO traffic for best results.

3. Choose and Set an Appropriate Download Mode: Delivery Optimization offers several download modes that control how peer-to-peer is used. You should select the mode that fits your network topology and security needs:

• Mode 1 (LAN Peering) – the default mode. Peers with devices on the same NAT/local network. This is a good starting point for most, meaning devices will share with others in the same site or subnet (essentially those sharing an external IP). For larger networks you might not want to group every internal network together and you should consider Mode 2.
• Mode 2 (Group Peering) – peers within a defined group ID that you configure. Use this for more complex topologies (e.g. multiple subnets or branch offices) to constrain peering to specific logical groups. If your organization spans many subnets or you want to ensure only corporate devices peer together (excluding any others on the same LAN), Mode 2 with a Group ID is ideal. You can set the group identifier via policy (as the auto-group mechanism will use the Entra tenant ID, which is the default if you don’t specify a custom ID).
• Mode 3 (Internet Peering) – allows peering not just within the LAN but also with devices across the internet. This mode maximizes peer sources, but in enterprise it’s less commonly used due to security concerns and the unpredictability of internet peers.
• Mode 0 (No peering, but use DO cloud metadata) – effectively turns off P2P and uses only Microsoft servers, but still uses Delivery Optimization’s intelligent downloading (useful if you temporarily or permanently don’t want peer sharing).
• Mode 99 (Simple HTTP only) – completely bypasses Delivery Optimization (not recommended except for isolated cases).

Decide on a mode based on your needs. For most organizations, Mode 1 (LAN) or Mode 2 (Group) is recommended to confine peering to your own network environment for security. For example, if you have a hub-and-spoke network and want peers only within each branch, you might choose Mode 2 and configure group IDs per branch. Set the chosen mode via an Intune configuration policy, using the DeliveryOptimization/DownloadMode CSP or the Intune settings catalog for Delivery Optimization to set the mode and related policies.

4. Tune Additional Delivery Optimization Policies (Optional): Depending on your network and devices, you may want to adjust some advanced settings for optimal performance:

• Peer Selection Restriction: By default, in LAN mode peers are identified by having the same external IP, and in Group mode by the group ID. If you need finer control (e.g., only peers on the same subnet even if behind same NAT), you can enable DORestrictPeerSelection to Subnet to limit peering to subnet-level. This is useful if, say, multiple subnets exist in one site but you prefer not to have cross-subnet traffic.
• VPN Peer Consideration: Delivery Optimization automatically disables peering when a device is on VPN (it assumes VPN means remote, to avoid inefficient or undesired peer traffic over VPN). If your scenario allows or requires P2P over VPN (for instance, many users are working from home on a split-tunnel VPN and you want those on the same VPN concentrator to peer), you can change this by enabling the DOAllowVPNPeerCaching policy. Be cautious: peering over VPN can sometimes flood VPN links, so only enable if you have carefully planned for it.
• Minimum Content File Size for Peering: By default, Delivery Optimization will only peer cache chunks from files that are 50 MB or larger. Smaller downloads simply come directly from source to avoid overhead. In large environments, lowering this threshold can increase peer sharing efficiency (more files eligible to be shared). For example, in an environment with >30 devices, Microsoft recommends reducing the DOMinFileSizeToCache to ~10 MB so more medium-sized files are shared. Conversely, in very large environments (100+ devices in group), you might even lower it to 1 MB so almost all content chunks can peer.
• Cache Size and Age: By default, Delivery Optimization will use up to 20% of a disk for cache and will purge files older than 3 days. For broader sharing, consider allowing a larger cache or longer retention. For instance, setting DOMaxCacheSize (or percentage) higher or DOMaxCacheAge to 7 days can improve the chance that peers still have the needed content when a new peer requests it. This should work in harmony with your patching strategy. If you have longer deferrals than 3 days, make sure the DOMaxCacheAge is allowing for this and isn’t purging the cache before the next ring.
• Bandwidth and Time-of-Day Throttling: If needed, utilize DO’s bandwidth controls. Policies like Max Download Bandwidth (foreground/background) and Minimum QoS let you restrict how much bandwidth DO can use, or ensure it doesn’t interfere with other traffic. In many cases DO dynamically self-throttles, but for slower links you might set a cap during business hours.
• Peer Timeout Settings: By default, DO starts downloads from both peers and the CDN source in parallel, then tapers off the slower source. You can adjust policies like DelayForegroundDownloadFromHttp or DelayCacheServerFallback to give peers more time to respond before pulling from the internet. Microsoft recommends small delays (e.g. 30–60 seconds) to improve peer utilization without risking huge latency.

These settings can be applied via the same Intune policies as the download mode and as always, it’s best to pilot any changes with a subset of devices to ensure they yield positive results in your environment.

5. (Optional) Deploy Microsoft Connected Cache for Enhanced Optimization: As an optional but highly effective augmentation, consider setting up Microsoft Connected Cache (MCC) in your network. (We detail Connected Cache benefits in a later section) In brief, Connected Cache is a software-based caching server that works with Delivery Optimization to store content on-premises. If you have a large office or limited WAN bandwidth, deploying a cache server means even the first device requesting content can get it from a local cache (if another peer has previously triggered that content to be cached). Microsoft Connected Cache can be installed on a Windows Server or even a Windows 10/11 or Linux device. Setting up a Connected Cache involves installing the MCC software, and configuring clients using a policy with the cache host’s address. We’ll discuss specific benefits in a bit, but as an implementation step, decide if MCC fits your scenario and plan deployment accordingly (for example, at each major site).

6. Monitor and Verify Delivery Optimization Performance: After configuration, it’s important to monitor DO to ensure it’s working effectively:

• On individual Windows 10/11 clients, you can check Settings > Windows Update > Advanced Options > Delivery Optimization > Activity Monitor. This built-in monitor shows how much data was downloaded from peers vs internet, average download speeds, etc. It’s a quick way to verify that devices are indeed getting bytes from peers or a cache.
• In an organizational view, use the Windows Update for Business reports in Intune. Microsoft offers a Delivery Optimization cloud report that aggregates data from all your devices. This report will show total bandwidth saved across the org by using DO (how many bytes came from P2P or local cache vs from CDN), plus configuration info and efficiency by groups. This can validate the impact of your DO setup.
• Use PowerShell cmdlets for on-demand checks or automation. For example, Get-DeliveryOptimizationStatus and Get-DeliveryOptimizationPerfSnap provide real-time and summary stats on DO usage on a device (bytes from peers, bytes from cache server, etc.).

Confirm that a healthy percentage of content is coming from peers or cache (depending on your expectations). If not, you may need to revisit configurations (e.g., ensure devices are in the same group, or that firewall rules aren’t blocking peer traffic).

7. Troubleshooting and Ongoing Management: Be prepared to troubleshoot common issues:

• If DO peering doesn’t seem to work (all downloads still coming from internet), check firewall ports (7680) and group settings. A blocked port or mis-configured DownloadMode is often the cause.
• If devices are contacting Microsoft but not each other, ensure they can reach the DO cloud service (for peer discovery metadata) and that no proxy is stripping necessary info. Also confirm that devices actually have content cached to share (peers only help if at least one device has downloaded the content already).
• Use the Delivery Optimization Troubleshooter PowerShell tool provided by Microsoft (available via the PowerShell Gallery) to run diagnostics on a client. This tool can check configuration and connectivity to identify issues.
• For advanced issues (e.g., specific error codes), consult Microsoft’s DO FAQ or community forums. The DO FAQ covers error codes and scenarios like WSUS integration, VPN behavior, etc., which can provide guidance on less common problems.

Going forward, manage DO settings as part of your standard endpoint policies and keep an eye on metrics. Delivery Optimization typically requires minimal babysitting once tuned, but changes in your network (like a new proxy or network segmentation) should be evaluated for potential impact on DO.

Network Infrastructure Considerations for Delivery Optimization

Setting up Delivery Optimization does involve some thoughtful network planning. Here are key considerations and recommended practices for your network infrastructure when enabling DO:

• Firewall and Ports: As noted in the implementation steps, opening the correct ports is crucial. All DO peer traffic uses TCP port 7680, which must be open for inbound and outbound on each Windows client (and not blocked between clients by any internal firewall). If that port is blocked, no peer-to-peer sharing can occur (clients will silently fall back to downloading directly from Microsoft). Additionally, if you want to enable cross-subnet or cross-site peering (Download Mode 2 or 3), Delivery Optimization will use UDP port 3544 with Teredo for NAT traversal. In many corporate environments, Teredo and internet-wide peering might be disabled, which is fine – just use LAN or Group modes so that peering stays local and no Teredo is needed. Also ensure clients can use HTTPS (443) to contact DO services on the internet; typically this is open by default since it’s standard web traffic, but enterprise SSL inspection devices or strict allow-lists should include the DO endpoints.
• Peer Discovery and Grouping: Understanding how peers find each other will help you design your groups. In LAN mode, the DO cloud service groups devices by public IP address – meaning all devices behind the same NAT appear in one peer group by default. This works well for single-location organizations or branch offices where each site has a unique external IP. In Group mode, you have finer control: you can define a Group ID (a GUID or policy-defined value) that you assign to devices, and only devices with the same Group ID will peer. Group mode can also leverage existing identity: by default if you don’t manually set an ID, Windows will use the Entra ID tenant info to implicitly group devices. It’s good to be aware of this default grouping: for instance, a corporate laptop and a personal PC on the same home network won’t peer via DO if the corporate device is Entra ID joined and the personal device is not, because the corporate device will seek peers in the same tenant. Takeaway: For most enterprises, default behavior already restricts peering to your org’s devices, but if you have multiple distinct networks or tenants, configure Group mode so that each network/tenant has its own peer group.
• Multiple Subnets or VLANs: If your offices have many subnets (e.g., departmental VLANs), Delivery Optimization by default might treat all those behind one NAT as a single group, which could lead to cross-VLAN traffic. If that’s a concern (perhaps due to router load or security), use the DORestrictPeerSelection policy set to “Subnet” to further constrain peers to only those with the same subnet address prefix. This way, devices will favor peers in their own IP subnet. Another approach is to use Group mode with different Group IDs per subnet or site, but that is more administrative overhead. In summary, design peer groups to align with network locality: you want peers to be “close” to each other in network terms to get the best performance and to avoid unnecessary traffic over routers.
• Proxy Servers and Internet Egress: If your organization routes traffic through an HTTP proxy or cloud web gateway, pay special attention to Delivery Optimization’s requirements with proxies. DO can work with proxies for the HTTP portion of downloads, but the peer discovery and coordination traffic ideally should bypass the proxy. The reason is that cloud-based proxies often mask the client’s IP, which confuses the DO service’s peer grouping (all clients might appear to come from the proxy’s IP). To preserve peer-to-peer, configure your proxy to exempt DO service URLs (*.do.dsp.mp.microsoft.com) from proxying, allowing clients to reach the service directly. Also ensure the proxy allows the Range header and partial content, as DO uses range requests heavily. An incorrectly configured proxy could cause DO to fall back to simple downloading or even fail updates with errors. For cloud proxy solutions in particular, Microsoft’s recommendation is to allow DO network traffic to go direct to the internet when possible.
• Bandwidth Management and QoS: Delivery Optimization itself has built-in bandwidth management (it can dynamically adjust based on network usage and policies). However, if your network infrastructure uses QoS rules or bandwidth shaping, consider categorizing DO traffic appropriately. DO download traffic from Microsoft appears as standard HTTPS (443) to Windows Update or Microsoft servers, and peer traffic is on custom port 7680. You might, for example, mark port 7680 traffic as low priority within a site if you want to ensure business-critical traffic isn’t impacted by peer sharing. Conversely, you might choose to prioritize local peer traffic over internet traffic, since local transfers offload the WAN. The strategy will depend on your network policies, but DO gives you the levers (through its own throttling policies) to adjust if needed.
• VPN and Remote Work Considerations: As mentioned, DO treats VPN connections cautiously. By default, devices on VPN won’t try to peer with others. This is usually desirable because peers might all be in separate homes (so no benefit) and you don’t want to hairpin large files through VPN concentrators. If you have split-tunnel VPN (where Windows Update traffic goes directly to internet), DO will still function for internet downloads (each remote client pulls from Microsoft, since presumably no local peers reachable). For remote scenarios, Connected Cache (discussed below) at cloud endpoints can help, but direct peer-to-peer among roaming devices is naturally limited. Plan that remote users may not get the same bandwidth savings unless they are grouped at a site or come into office occasionally to share with on-site peers. Also, if using VPN and you do want to allow peering (perhaps for users within the same VPN subnet), you must configure DOAllowVPNPeerCaching to true and possibly adjust DOVpnKeywords if your VPN adapter names don’t contain the default keywords.
• Device Resource Impact: Ensure devices meet the resource criteria for peering. Delivery Optimization by default only uses peers that have at least 4 GB of RAM and 32 GB of disk, and that are not on battery power (below a certain threshold). Most modern PCs meet these, but if you have very low-spec IoT-like devices, they might not participate in peer upload. You can adjust these limits (e.g., allow peers on battery above 60% charge to participate) via policies like DOMinBatteryPercentageAllowedToUpload. However, be mindful of not draining laptop batteries or saturating older machines – DO is pretty efficient and polite by default. In large deployments, you might actually lower the min disk or battery settings to include more devices in peering, but test the impact before you do.
• Overlap with Other Solutions: If you previously used technologies like BranchCache or third-party peer distribution, consider how Delivery Optimization will coexist. On Windows 10/11, DO automatically supersedes BranchCache for Windows Update and Store content – if DO is enabled, Windows Update won’t utilize BranchCache. It’s usually best to standardize on one solution to avoid confusion. Many organizations moving to cloud management stick with Delivery Optimization + Connected Cache, while those staying with Config Manager might use its Distribution Points and LEDBAT or Peer Cache. The good news is DO can detect some conflicts; for example, it won’t double-cache content if Config Manager Peer Cache is already doing so for Office updates. Still, part of your network consideration is to turn off or transition away from legacy content sharing methods if you plan to fully leverage Delivery Optimization, to simplify operations.

In summary, the network considerations for DO boil down to allowing the necessary traffic (ports, endpoints), aligning peer groups with your network structure, and ensuring no infrastructure (like proxies or firewalls) inadvertently hampers DO’s peer-to-peer communication. With these in place, Delivery Optimization will quietly and effectively reduce your WAN usage.

Benefits of Microsoft Connected Cache (MCC)

Microsoft Connected Cache is an enterprise in-network caching solution that works hand-in-hand with Delivery Optimization. In essence, Connected Cache turns a server or PC in your network into a local mirror for content delivered via DO. Let’s explore why this is beneficial and how it augments Delivery Optimization:

What is Connected Cache? It’s a software-based cache (using IIS ARR technology under the hood) that can be installed on Windows Server (or even Windows 10/11 or Linux, in newer versions) to store Microsoft content. When a Windows client with DO enabled requests content, if Connected Cache is present and configured, the client will try to download from the local cache server instead of directly from the internet. The cache server, on first request, will download the content from Microsoft’s CDN and store it, then serve it to the clients. Subsequent clients get that content directly from the on-premises cache at LAN speed.

Key benefits of using Connected Cache:

• Drastically Reduced Internet Bandwidth Usage: Connected Cache can yield huge bandwidth savings by ensuring that each piece of content (e.g., a Windows update package or Office install file) is downloaded from the internet only once, then reused by everyone. Organizations using DO + Connected Cache have reported bandwidth savings up to 98% for large deployments like Windows 11 upgrades and Intune app rollouts. This means if 100 PCs need a 4 GB update, with a cache you might download 4 GB once from the internet, and the remaining ~396 GB is served locally. The combination of DO’s peer-to-peer and a local cache covers all angles: even if no single peer has the whole file, the cache likely does, minimizing external downloads.

• Faster Download Speeds and Improved Deployment Times: Content delivered from a local cache is often much faster and lower-latency than pulling from the cloud, especially for remote offices with slower links. For example, if a branch office has a Connected Cache node, a Windows feature update that might have taken each PC an hour to download from the internet could be served over the LAN in minutes. Microsoft Connected Cache works transparently with DO – clients connect to the cache and peers in parallel, and whichever provides data faster wins. In practice, once the cache has a file, it will usually saturate the LAN and quickly feed all clients, dramatically speeding up mass deployments (such as OS upgrades or software rollouts).
• Lightweight and Cloud-Managed: MCC is a software-only solution with relatively low overhead. It can be installed on any Windows server/PC you designate. It uses IIS’s Application Request Routing to store content. It’s also cloud-managed in the sense that it doesn’t require you to build a management infrastructure – clients are directed to the cache via the DO cloud service or policy, and the cache fills itself on-demand. Administration is minimal: you monitor disk usage and ensure the service stays healthy, but it’s mostly self-sustaining.
• Complements Peer-to-Peer (P2P): Connected Cache is not a replacement for DO’s peer-to-peer; it’s a complementary, dedicated source. In fact, Delivery Optimization will use both peers and the cache together. When a client needs content, if a Connected Cache is configured, the DO client will query the cache and also query peer PCs simultaneously. The system then uses the fastest source. In many cases, the cache will serve large portions of content, while peers might fill in small missing pieces. This “hybrid” approach ensures that even if few peers are online or a peer goes offline, the cache is there as a reliable backup. It gives a more consistent and controllable content delivery – the IT admin can ensure the cache is on a reliable machine instead of relying purely on end-user PCs to hold updates.
• Ideal for Multiple Branch Offices and Cloud-Only Environments: If you have many branch offices, you can deploy a Connected Cache node at each site. This acts like a mini content server in each office, reducing cross-site bandwidth. This is especially valuable if you have moved to cloud management (Intune/Windows Update for Business) and no longer have on-prem servers for updates; without a cache, every PC at every site would hit the internet for updates, but with caches, each site behaves like it has its own local update server. Essentially, MCC gives you the benefits of a traditional on-prem update server while still using cloud update sources.
• Supports Various Content Types: Microsoft Connected Cache isn’t limited to Windows updates. It will cache any content delivered via Delivery Optimization. This includes Windows 10/11 quality and feature updates, Microsoft 365 (Office) apps updates, Microsoft Store app installs/updates, Intune Win32 app content, Windows Defender definition updates, and more.
• Bandwidth Savings and Metrics: With a cache in place, you amplify DO’s effectiveness. Instead of maybe 80% bandwidth savings with just peer-to-peer, you can approach the aforementioned ~98%. Microsoft has shared case studies of enterprises using Connected Cache in preview and seeing their internet egress for updates plummet. The Windows Update for Business reports can break out bytes served from Connected Cache vs CDN, quantifying the benefit. In remote sites with poor connectivity, the difference is very tangible (users notice faster updates, and IT notices the lack of WAN saturation during patch days).

How to implement and use Connected Cache: If you decide to use MCC, the typical process is:

• Install the Connected Cache software on a server (or multiple servers for redundancy) at desired location(s). Microsoft provides installation scripts to set up a cache on a Windows device or a supported Linux box.
• Configure clients via policy to know about the cache. In Intune, you set DOCacheHost policies by specifying the hostname of your cache server or enabling DOCacheHostSource to let clients find caches via DHCP.
• Once in place, monitor the cache’s usage. It will have logs/stats as PerfMon counters. Ensure the cache has sufficient disk space – it will by default manage its own cache size, but you may want to allocate plenty of disk to hold more content for longer.
• Benefits will ramp up as more content is reused. The first time new content (say a new Windows cumulative update) is released, one device (or the cache on behalf of one device) will download it from the internet. All other devices will then get it from the cache, making subsequent deployments very network-light.

Implementation example: Consider an organization with 1,000 PCs across 10 offices. Without DO or cache, on Patch Tuesday 1,000 PCs may each download a 500 MB update – 500 GB total internet traffic. With DO peer-to-peer (no cache), perhaps each office (100 PCs each) only downloads, say, 5 copies from the internet (2.5 GB per office, 25 GB total) because peers share the rest – that’s a 95% reduction. With a cache at each office, potentially each office only downloads 1 copy (500 MB each, 5 GB total), a 99% reduction compared to original, and nearly 80% less than even pure P2P. Multiply that by several update categories and app installs, and the bandwidth savings are enormous.

• Scenarios where Connected Cache shines: Remote or branch offices with limited bandwidth – ensures updates don’t saturate the WAN link. Education environments where many devices might simultaneously pull large updates (e.g. computer labs) – a local cache prevents machines from each pulling multi-gigabyte files through a possibly constrained WAN connection. Organizations that have moved to Windows Update for Business (cloud updates) and removed local update servers (WSUS) – the cache adds back a level of on-premises content storage for efficiency without re-introducing heavy infrastructure.

In summary, Microsoft Connected Cache significantly boosts Delivery Optimization’s impact by providing a dedicated local source for content. It maximizes bandwidth savings and speeds up distribution, especially in scenarios with many devices requesting the same content. The combination of DO + MCC offers a comprehensive and flexible content delivery solution: distributed peer-to-peer plus centralized local caching. This is why Microsoft often recommends using them together for the best results in enterprise and education networks.

Services and Content That Can Leverage Delivery Optimization

Delivery Optimization isn’t just for Windows OS updates. It’s a unified distribution method used by many Microsoft services. Below is a list of major services and content types that leverage Delivery Optimization, and how they benefit:

• Windows Update (Windows 10 and 11) – Feature updates, quality updates, and drivers: Windows Update is one of the primary users of DO. When PCs download monthly Patch Tuesday updates or annual Feature Upgrades, DO enables them to share those bits, dramatically reducing bandwidth for Windows updates.
• Microsoft Store Apps – App installs and updates (UWP and Win32 apps): When users or IT deploy applications from the Microsoft Store (e.g., a company pushes a new version of Company Portal hosted in the Store, or users install a new app from Store), Delivery Optimization allows those app packages to be shared. If one machine has downloaded an appx package, another on the network can get it via DO. This is especially useful in classrooms or labs where the same apps are installed on many PCs. Both Universal Windows Platform (UWP) apps and the newer Win32 apps in the Store use DO on Windows 10/11.
• Microsoft 365 Apps (Office 365 ProPlus) – Office installation and updates: Office Click-to-Run (the installation technology for Office 365/Microsoft 365 Apps) can utilize Delivery Optimization. If Office is configured to fetch updates from the Office CDN, multiple devices in the office will share those update files via DO. Important: If you use local sources for Office updates, DO won’t be in play because content didn’t come from the cloud. But if you use cloud update channels (Current, Monthly Enterprise, etc.), Office updates are DO-friendly by default.
• Microsoft Edge Browser Updates – The new Chromium-based Edge on Windows updates on its own release cycle. These updates are delivered either through Windows Update or via Microsoft’s update service. Edge updates (which are essentially small installer packages) can be shared peer-to-peer through DO.
• Intune Win32 App Content – When deploying Win32 applications, Intune leverages Delivery Optimization on the client side. For example, if you push out an application like Adobe Reader (packaged as .intunewin) to 50 PCs at a site, those PCs will download the app package from Microsoft’s cloud endpoints. DO will allow them to share the downloading of that package, so not all 50 have to pull it separately. This greatly improves Intune’s scalability for software distribution – it’s essentially doing what ConfigMgr’s Peer Cache or BranchCache could do, but with the cloud. Additionally, Windows Autopilot provisioning benefits from DO: during Autopilot, devices download apps and updates, and if multiple devices are being provisioned simultaneously in one network, they will peer-share that content (and if Connected Cache is present, perform even better).
• Windows Defender Antivirus Updates – Microsoft Defender for Endpoint clients gets definition updates frequently (multiple times a day, small delta files). Those updates are delivered via Windows Update mechanisms. Delivery Optimization does support sharing of Defender updates among PCs. In practice, these files are small (a few megabytes), and DO’s default 50MB threshold means very small files might not peer. If you want even those to share, you could lower the min file size for DO as mentioned earlier. The benefit is minor in bandwidth (Defender updates aren’t huge), but it can reduce redundant downloads especially in environments with limited connectivity.
• Windows Feature On Demand (FOD) & Language Packs – These are optional Windows components and language packs that are pulled from Microsoft servers when needed. DO can cache and share these too, since they come from Windows Update servers.
• Windows Update for Business (WUfB) – When using WUfB, all Windows update content uses Delivery Optimization by default. Devices talk to Windows Update and coordinate P2P among each other for efficiency. The Delivery Optimization cloud report mentioned earlier specifically measures WUfB environments, showing how much came from peers vs CDN. Essentially WUfB and DO go hand-in-hand to provide a cloud-first yet bandwidth-friendly update solution.

In summary, almost all update and app content delivered from Microsoft to Windows 10/11 endpoints can take advantage of Delivery Optimization. The benefit across these services is consistent: reduced internet download needs and faster, scalable delivery. For each service:

• Windows Update: faster patching, less WAN usage.
• Office 365 Apps: bandwidth-friendly updates, especially across many clients.
• Store/Edge/Defender: efficient distribution of frequent app and security updates.
• Intune app deployments: ability to deploy large apps cloud-first without saturating networks.

From an IT perspective, this means you can confidently adopt cloud-based delivery of updates and software, knowing that Delivery Optimization will mitigate the bandwidth impact. It is advisable to ensure DO is enabled whenever you are using these Microsoft cloud services for software delivery, as it’s the behind-the-scenes workhorse making large-scale distribution feasible.

Expected Bandwidth Savings with Delivery Optimization

One of the primary motivations for using Delivery Optimization is the significant reduction in internet bandwidth consumption. So, what kind of savings can you expect? While exact numbers vary by scenario, organizations have reported substantial bandwidth reductions, often on the order of 70–90 percent depending on the content and deployment patterns. With the addition of Connected Cache, savings can approach 98-99% for well-populated networks.

Peer-to-Peer Savings: In a pure peer-to-peer Delivery Optimization setup (without a dedicated cache), the bandwidth savings largely depend on how many devices need the same content around the same time:

• In the best case, if you have many devices and they all eventually require a given update or app, ideally only one device (or a small number) downloads it from the internet, and all others get it via LAN. This scenario could be, say, a new Windows 11 feature update of 4 GB, with 50 PCs in an office. Perhaps the first 2 or 3 PCs to go online early in the day each pull some parts of it from Microsoft, but as soon as a few have it, the rest of the 50 PCs get most of their data from those peers. You might see on average each office PC only downloaded 0.1 GB from the internet and 3.9 GB from peers, a 97.5% saving.
• Microsoft Intune has built-in metrics to track this. For example, using the WUfB Delivery Optimization report, you can see the “Observed bandwidth savings” over the last 28 days. Many admins report seeing percentages in the 80-90% range for Windows update delivery once DO is fully deployed. This means if without DO you’d use 100 GB, with DO you might only have used 10-20 GB from internet (the rest served via peers or local cache).
• Small Offices or Few Devices: If you only have, say, 2 or 3 machines at a location, the savings will be smaller in absolute terms – one will likely download from internet and maybe the second gets from the first. That’s still a ~50% saving for 2 machines, which is not bad. DO shines as the numbers grow. DO is designed to perform best in large scale environments (many devices), where the odds of content being shared are higher.
• Software Distribution vs. Updates: Bandwidth savings also depend on the nature of content. Large, infrequent updates (like a 6 GB Windows upgrade) yield obvious big savings if shared. Small, frequent files (like daily 2 MB Defender updates) individually don’t tax bandwidth, but over time DO sharing those can still add up to a few gigabytes saved a month. The more homogeneous your environment (everyone running same software and updates), the higher the savings percentage because they all download similar things.

Connected Cache Enhanced Savings: When you introduce Connected Cache, as mentioned, organizations have achieved up to 98% bandwidth reduction during major update events with DO + MCC. For instance, during a Windows 11 upgrade rollout (summarizing what we covered earlier in the MCC section):

• Without DO or cache: Each PC downloads ~4 GB from internet. For 1,000 PCs = ~4,000 GB internet traffic.
• With DO (peers) but no cache: Suppose one PC per subnet downloads from internet and feeds 19 others (assuming groups of 20). That’s ~5% of the data from internet (~200 GB) and 95% via LAN – a huge improvement.
• With DO + Cache: Potentially each office of 200 PCs only pulls one copy (4 GB) from internet and serves 199 peers locally, dropping internet usage to ~2% of total or less. Across all offices maybe 5 copies in parallel = ~20 GB from internet, which is 99.5% reduction. Real-world might be a bit less perfect, but 90+% is routinely observed.

Network Impact: The bandwidth savings are great for WAN/internet links, but remember that DO shifts some traffic to the LAN. Typically, LANs have much higher capacity, so this is a good trade-off. In rare cases, if a LAN is very constrained or wireless, you might see increased local traffic – but you can adjust DO to mitigate any local network strain by using its throttling features. Generally, LAN bandwidth is cheaper and more plentiful than WAN, so using it via DO is beneficial.

In summary, you can expect Delivery Optimization to dramatically cut down external bandwidth usage, often by an order of magnitude. Whether it’s Windows updates, Office updates, or app installs, DO ensures that the more devices you have, the more you save relative to traditional downloading. With Connected Cache, those savings become even more consistent and approach the theoretical maximum (only one external download needed regardless of device count). This not only reduces costs (if you pay for metered bandwidth or have limited ISP capacity) but also prevents network congestion, allowing other business traffic to flow without being choked by large update downloads.

Security Implications and Mitigations

Any time peer-to-peer sharing is mentioned, it’s natural to consider security. Delivery Optimization is designed with security and privacy in mind, using multiple layers of protection to ensure that enabling P2P content sharing does not introduce risks of tampering or data exposure. In this section we discuss the security implications of DO and how potential risks are mitigated.

TL;DR Security: Delivery Optimization is secure by design. It only deals with trusted, signed content and verifies every byte downloaded from peers. It never shares user data, only official update payloads. Peering is typically confined to your organization’s devices, and you have controls to narrow that further. The risk of malware being introduced via DO is effectively negligible, because any unauthorized data would be rejected and never executed. In exchange for a bit of local network chatter, you get huge bandwidth savings without compromising security. Microsoft has been using DO for Windows Update and Office updates in the wild for years, including on millions of consumer devices (which potentially do internet-wide peering) – and there have been no reports of security breaches due to DO.

1. Content Integrity and Validation: A top concern might be “If my PC is downloading updates from a peer instead of directly from Microsoft, how do I know that content is safe and not altered?” Delivery Optimization addresses this by using strong cryptographic validation on every piece of content:

• All content delivered via DO (Windows updates, apps, etc.) is signed or hashed by Microsoft. Delivery Optimization relies on a metadata file from Microsoft that contains SHA-256 hashes for each block of the file. When a DO client downloads a chunk from a peer, it verifies the chunk’s hash against the official hash from Microsoft before accepting it.
• If any peer were to send corrupted or malicious data (whether due to error or a deliberate attempt), the hash mismatch would be detected immediately, and that chunk would be discarded. The client will then try another source for that chunk (either another peer or the CDN). In fact, if a peer provides bad data repeatedly, DO will ban that peer for the remainder of the download session.
• Once all chunks are downloaded (from whatever combination of peers/cache/CDN), the entire file is reassembled and the original signature is checked (e.g., the digital signature on a Windows update package is validated) before installation. This is the same check that would happen if the file came straight from Microsoft. In short, any content installed on the machine still undergoes the standard Windows authenticity checks (such as code signing).
• No execution of unverified code: Delivery Optimization only supplies the data; the installation or update mechanism (Windows Update service, Office updater, etc.) will not execute or apply the content unless it’s intact and signed. So the security level is effectively the same as traditional updates – the difference is just the transport mechanism.

2. Peer-to-Peer Scope and Privacy: Delivery Optimization’s peer sharing is limited to update and app content. It never shares personal files or user data. There is no mechanism for a user’s documents or any non-update content to leak via DO. Microsoft explicitly states that DO cannot be used to send or receive personal content; it only works with the specific Microsoft content packages and nothing else. So there’s no risk of sensitive corporate files accidentally being distributed to other machines through DO – it’s not a general file sharing service, it’s content-specific.

Additionally, DO does not reveal sensitive info about your device to peers. Peering is orchestrated by the cloud service, but devices do not exchange any personal identification with each other beyond what is needed to request and transfer the file chunks. Typically, a peer only knows that another peer wants a certain chunk of a certain content ID (which is just a GUID for a Microsoft file). Devices don’t learn each other’s machine names or user info through DO – the communications are low-level and focused on file bytes.

3. Network Isolation and Unauthorized Peers: By default, Delivery Optimization limits peer communication to appropriate scopes – usually within the same organization or local network. As discussed in network considerations, domain-joined devices will peer primarily with other domain-joined devices (or Entra ID-joined with the same tenant) due to group ID logic. This means it’s unlikely a corporate PC will ever download updates from an unknown outside machine, even in Internet peering mode, because it would prefer same-tenant peers. In LAN mode, it’s theoretically possible that two unrelated machines on the same public internet IP (e.g., in an apartment building or airport lounge) could peer, but Microsoft mitigates this:

• On Enterprise editions, the default is to use LAN (1) mode which already restricts to same NAT, and often enterprise PCs are behind corporate NAT separate from personal devices.
• If you use Group (2) mode tied to your domain or tenant, then only machines from your org will be considered peers, even if they share an IP network with others, because the group identifier won’t match outsiders.
• If Internet (3) mode is enabled (which is more common in consumer scenarios), there is a chance to peer with random internet PCs for updated bits. Enterprise admins typically don’t use mode 3; however, even in mode 3, the aforementioned content integrity checks ensure no malicious data can be injected. The main risk of mode 3 would be bandwidth theft (somebody outside pulling from you or vice versa), but again if you’re concerned you simply wouldn’t use Internet mode in an enterprise environment.

4. Firewall and Access Control: The use of DO opens port 7680 on the local machine for peer connections. Administrators should ensure that endpoint firewalls only allow that port for legitimate traffic. The Windows Firewall by default has a rule for Delivery Optimization allowing it on private networks. In a domain environment, that covers domain network locations. It does not open it on public networks if the machine is marked as such. You can enforce firewall profiles to block DO on untrusted networks if needed. However, since DO already won’t find non-org peers in group mode, the firewall aspect is mostly about local LAN. Ensure your corporate firewall policies allow or block DO traffic appropriately when devices are off-network. For instance, if a laptop is taken home (and maybe not on VPN), it might still attempt DO with internet or local peers at home. If that’s not desirable, an admin could use policy to restrict DO to “enterprise network” only by setting Download Mode to Group and designing the group so that outside of corp network it falls back to HTTP only.

One can also leverage network segregation: If you have guest networks, those devices likely won’t be in the same NAT or same domain group as corporate devices, so they won’t peer with each other. Similarly, if you have IoT or unmanaged devices, they won’t be part of the DO groups.

5. Data Security and Compliance: Delivery Optimization does not expose any user data and the content it shares is encrypted or signed updates, so the risk of data leakage is minimal. Nonetheless, compliance-conscious organizations might ask: “Are there any logs of what was shared and with whom?” DO does produce event logs and diagnostic logs that include things like peer IPs and amounts of data. This is mostly harmless information (e.g., “peer 10.0.0.5 provided 100MB”). There isn’t a privacy concern there beyond normal network telemetry. Microsoft’s privacy statement for DO indicates it might send up info about download stats to Microsoft (like how much came from peers) but this is aggregate data and used for service improvement, not sensitive personal info.

If your organization has strict policies around peer-to-peer (perhaps an outright ban in policy for any P2P), you’d need to get an exception for DO or configure DO in a way that it’s essentially not P2P (mode 0 or using only a connected cache). However, it’s worth educating stakeholders that DO’s P2P is very controlled and secure – not at all like torrenting arbitrary files.

6. Avoiding Malicious Abuse: Could an attacker abuse Delivery Optimization in any way? Since DO is only dealing in content that the Windows Update service (or other Microsoft services or yourself) is already authorized to distribute, an attacker can’t inject new malicious content into DO. They would have to compromise Microsoft’s own update mechanism, which is extremely unlikely given all updates are signed and delivered over secure channels. The worst an attacker on the same network might attempt is to impersonate a DO peer or cache. But:

• Peers are found via the DO cloud service, not just by arbitrary broadcasting, so an attacker would have to trick Microsoft’s service into thinking it has content it doesn’t, which is not feasible without the actual content and matching hashes.
• The client verifies everything it downloads. So even if an attacker set up a rogue “peer” that hands out incorrect data, the clients will ignore it (thanks to hash checks).
• A rogue peer that somehow intercepts traffic (Man-in-the-middle) would still need to present data with correct hashes and likely even use TLS in parts (the initial metadata is obtained securely from Microsoft). DO doesn’t blindly trust any peer; it uses a trust-but-verify model with a strong verification.

7. Configuration to Enhance Security: For organizations particularly sensitive, you can tighten DO further:

• Use Group mode with a custom Group ID that only your devices know. For example, set a specific GUID as Group ID on all corp devices. This guarantees they only peer with each other.
• Enable DORestrictPeerSelection to Domain or Subnet as needed. This adds assurance that even if say two companies share a building and an IP space (highly unlikely if you’re security sensitive), their domain separation stops cross-peering.
• If even internal P2P is not acceptable to some degree, consider using Connected Cache as the sole method (i.e., set DownloadMode to 2 (Group) and configure DO to prefer cache by setting a very low peer count or even disabling pure P2P). That way all clients only talk to the trusted cache server. This is more restrictive but still saves bandwidth (this essentially mimics a traditional server-client model but using DO protocols).
• Keep Delivery Optimization updated (it updates with Windows). Microsoft continues to patch any vulnerabilities. Historically, there have been few if any notable security issues with DO – it’s a fairly straightforward service.

8. Security of Connected Cache: Since Connected Cache is part of the DO ecosystem: The cache server stores copies of the content. That content on the cache is also just the same encrypted/signed packages. The cache does not decrypt or inspect them; it just serves bytes. There’s minimal additional risk having them on a server. One consideration: ensure your cache server is secured (harden the OS, limit access) because if an attacker did compromise the cache, they could potentially serve bogus data to the cache’s clients. But again, the clients would still validate it. At worst, a compromised cache that can’t be trusted could be a denial of service (serving junk that clients reject, causing them to time out or fall back to internet). Regular patching of cache servers and monitoring their integrity is advisable.

9. Privacy: From an end-user privacy perspective, DO does not share any personal information. The DO cloud service might use some device info like OS version or region to optimize peers (and obviously knowledge of content needed/hashes). This is outlined in Microsoft documentation about endpoints (for example, DO service knows a device’s general location to find nearby peers or caches). These communications are minimal and solely for service functionality. It’s under the Windows data collection policies and can be categorized as required diagnostic data for update delivery.

As a recommended practice, monitor Delivery Optimization activity through its logs or the WUfB report, as extremely anomalous patterns (like an unknown device trying to behave as peer) might indicate misconfiguration. But such cases are rare. Most organizations can deploy DO confidently, knowing that the integrity and safety of their update process remains intact. Many even consider DO a security win in some ways: by easing bandwidth, it allows you to deploy critical patches faster to all machines (no backlog due to bandwidth), thus reducing your window of vulnerability during patch rollout.

Recommended Practices and Common Challenges

Finally, to wrap up, here are some recommended practices for deploying Delivery Optimization successfully, along with solutions to a few common challenges that organizations might face:

Recommended Practices:

• Start with Default Settings, Then Optimize: Delivery Optimization’s out-of-the-box settings (LAN mode, 50MB threshold, 20% cache size, etc.) are a sensible baseline for many environments. Begin with these defaults and observe the effectiveness via monitoring. Only tweak advanced settings if necessary to address a specific need (such as smaller peer groups or lower thresholds for more aggressive sharing). This avoids over-complicating the initial deployment. Many organizations find the default config already yields high savings.
• Group Peering by Logical Boundaries: Use Group Download Mode (2) with a proper Group ID strategy if you have a distributed network. This ensures that, for example, machines in different regions aren’t attempting to peer over slow WAN links. Always verify that the grouping is working as intended (check a client’s DO log to see what group ID it picked and ensure it matches your plan).
• Implement Connected Cache for Larger Offices or Bandwidth-Constrained Sites: If you have any site with, say, more than 50-100 machines or with a metered/expensive connection, strongly consider putting a Connected Cache there. It’s a lightweight addition that can greatly improve DO efficiency and is easy to deploy (with support for cloud management). Even a spare PC with a big hard drive can serve as a cache if a server is not available. Monitor the cache performance – if one cache node gets overloaded, you can always deploy a second one and split subnets between them.
• Educate IT Staff and Users (if needed): It’s worth letting your IT support teams know what Delivery Optimization is and that it’s enabled. This helps them understand any unusual network activity. Generally, DO is silent and users won’t know it’s happening. But if someone runs a network monitor, they might wonder “why is my PC connecting to other PCs on port 7680?” – having documentation internally to explain “this is expected due to Delivery Optimization for updates” can prevent misinterpretation as a malicious event. For users, it’s rarely necessary to mention, unless you allow peer sharing over the internet (not typical in enterprise) which might slightly use their upload bandwidth at home. Even then, DO is smart about uploads (it won’t consume all upload bandwidth, and you can cap it).
• Monitor and Use Analytics: Utilize the built-in Delivery Optimization reports and logs to track how well it’s working. Look at metrics like PercentPeerCaching (via PowerShell or WUfB reports) to see percentage from peers. If it’s low, investigate why (maybe peers not finding each other, or content not aligning). Over time, these metrics can justify the value of DO (showing bandwidth saved in quantifiable terms to leadership).
• Combine with Scheduling if Necessary: In some cases, even with DO, you might want to schedule when updates are allowed to download (e.g., only at night). DO doesn’t inherently schedule downloads (it works whenever a client requests content). But you can use Windows Update for Business policies or ConfigMgr maintenance windows to ensure large downloads happen in off-peak hours. DO will then make those off-peak downloads efficient. Also DO itself has a notion of foreground vs background downloads – Windows Update by default uses background mode which is low-impact on user network usage. You can further enforce background limits for DO so that even peer sharing doesn’t overwhelm a network during business hours.
• Keep DO Enabled on All Applicable Devices: Sometimes, certain IT imaging or tweaking guides suggest disabling Delivery Optimization (perhaps out of misunderstanding). Avoid turning it off enterprise-wide, or you will lose benefits. Only consider disabling peering on specific segments if absolutely required. Microsoft actually advises against setting Download Mode 99 (simple HTTP) except in offline scenarios, and discourages disabling DO service entirely. The service is part of Windows’ normal operation.

Common Challenges and How to Address Them:

• “Delivery Optimization isn’t reducing bandwidth as much as expected” Possible causes: Peers aren’t finding each other (due to network or config issues), content not aligning (e.g., staggered update rollouts where not everyone downloads same thing at same time), or too strict settings. Solutions: Check that all peers have correct Download Mode and Group ID – a misconfigured client might not participate. Ensure firewall/proxy isn’t blocking DO. If using Intune, confirm the devices have the policy reporting correctly. Also examine timing – if updates are deployed gradually, peers might not overlap; consider adjusting maintenance times so groups of machines update closer together to maximize overlap. Utilizing Connected Cache can mitigate timing issues, since the cache will hold content for later requests even if peers from earlier have shut down.
• “Our VPN users or remote users aren’t benefiting” Explanation: By design, DO won’t form peers over VPN by default, and remote users may each download individually. Solution: If remote offices have local breakout (no VPN needed for updates) and enough local population, consider placing a Connected Cache in those locations or instructing those machines to use group mode so they at least peer with any local neighbors. For pure work-from-home users widely dispersed, DO can’t do much P2P (unless you enabled Internet mode, which has other implications). In such cases, rely on DO’s efficient HTTP downloader which at least does things like use parallel HTTP connections and compression to be better than legacy BITS transfers. You can also schedule those updates for nighttime to ease load. Essentially, accept that DO is most powerful in clustered environments; for scattered individuals, the effect is naturally limited.
• “I see some peer traffic, but it’s not using the nearest peers (odd choices)” Analysis: DO’s peer selection is cloud-assisted, but it might pick peers that aren’t literally the absolute nearest in network terms. It tends to group by NAT or group ID, but if you have a large flat network, any in that group are fair game. This usually isn’t an issue on LAN (all fairly fast). If it becomes a concern (maybe you have a large routed campus and want to ensure subnets peer within themselves), that’s where DORestrictPeerSelection=Subnet comes in. Enabling that will force it to prefer same subnet peers. Usually not needed, but it’s an option if you notice weird traffic patterns.
• “Some devices show as ‘OFF’ for Delivery Optimization in telemetry” Cause: Possibly someone turned off the DO service or set a policy to disable it (Download Mode = 0 still uses DO’s downloader but no P2P; Download Mode = 100 or another misguided setting could inadvertently bypass DO entirely). Fix: Ensure no conflicting policies. We’ve seen environments where a local IT admin, not understanding DO, sets a registry to disable it or uses a third-party “debloat” script on Windows that disables DO (thinking it’s like a torrent). You’ll want to reverse those changes. Delivery Optimization is core part of Windows Update, and disabling it can even cause certain downloads to fail.
• “Our network team is wary of P2P – how to convince them?” Discussion: This is more of an organizational challenge. The best approach is sharing the technical details we’ve covered: DO uses safe, encrypted transfers and respects network boundaries. Provide them the Microsoft documentation on DO’s security and perhaps start with a pilot. Show the bandwidth stats: often network teams quickly see the benefit when their internet monitoring shows a drop in Windows update traffic after DO is enabled. And because DO uses a single port (7680) and known endpoints, it’s something they can monitor and control if needed. Once they understand it’s not “Napster on our network” but rather “controlled Microsoft update sharing” they usually become supportive.
• “Peer caching seems to not work on our very old PCs” Hopefully this would be a theoretical example as you shouldn’t have any Windows 7 or Windows 10 versions prior to 1511 clients in your environment and if you do, DO is not your biggest concern…
• Logging and Troubleshooting: If an individual client isn’t working, check the Event Viewer under Applications and Services Logs > Microsoft > Windows > DeliveryOptimization. There are analytic logs that can be enabled to see what DO is doing. This can pinpoint, say, that it cannot reach the DO cloud service (proxy issue) or that it’s not finding peers (maybe group ID mismatch). Microsoft’s troubleshooting guide provides common error codes and solutions.

In conclusion, following these recommended practices – appropriate configuration, enabling supportive infrastructure like Connected Cache, monitoring results, and addressing issues proactively – will ensure you get the most out of Delivery Optimization. Many organizations have successfully deployed DO and essentially made large software distribution a non-event in terms of bandwidth, all while keeping security and control intact. By understanding and leveraging Delivery Optimization, you can significantly improve the efficiency of content delivery in your IT environment, delivering updates and software faster and cheaper, without compromising on safety or reliability.