Windows Delivery Optimization: Operate Peer Caches and Measure Fleet Savings

Delivery Optimization (DO) is Windows’ content-distribution client for supported update and application payloads. It can retrieve content from Microsoft-connected sources, managed caches, and eligible peers depending on policy, content, network conditions, and device configuration. It is not a guarantee that every download will be peer-served, nor is the cache a durable source of record. A fleet design should treat upstream availability, peer discovery, cache capacity, privacy boundary, bandwidth policy, and measurement as separate operational controls.

This article focuses on operating DO across Windows devices and diagnosing whether peer or cache behavior is actually helping. Exact policies and reporting depend on Windows release, management stack, update workload, and licensing. Validate the current client and Windows Update for Business or Intune documentation before applying settings. Do not infer fleet savings from the number of peers configured or the presence of files in a local cache.

Map the content path and the intended peer boundary

For each deployment, identify the content type, management source, source CDN or Microsoft endpoint, local peer group, and any Microsoft Connected Cache (MCC) instance. A download might use HTTP from Microsoft, a configured peer, or an in-network cache. The client selects eligible sources based on content availability and policy. NAT boundaries, VPN state, subnets, site codes, group IDs, firewall rules, and network profile influence whether a peer is discoverable and reachable.

Select a download mode and peer boundary from an explicit network design. A broad Internet peer mode is not equivalent to local-subnet peering and may not be appropriate for a constrained or privacy-sensitive environment. Group IDs should represent the intended network scope; a tenant-wide identifier reused across isolated networks can create unexpected peer discovery and offer little real locality. If devices are frequently offsite or on VPN, test those paths separately from office LAN traffic.

Delivery Optimization can reduce repeated WAN downloads when multiple clients request compatible content and can communicate with an eligible source. It does not guarantee a cache hit: content may be absent, expired, ineligible, or incompatible with the client request. A cloud-managed device can use different content and management endpoints from a domain-joined WSUS device. Document the actual update service and policy authority before troubleshooting; changing DO policy does not repair a missing update assignment or an inaccessible CDN.

Record effective configuration on representative devices

The DeliveryOptimization PowerShell module provides cmdlets for configuration, download status, logs, performance snapshots, and cache management. Capture effective state from each representative network cohort rather than assuming one client represents the entire fleet:

$out = Join-Path $env:TEMP 'delivery-optimization-evidence'
New-Item -ItemType Directory -Path $out -Force | Out-Null

Get-DOConfig | Format-List * |
    Out-File -FilePath (Join-Path $out 'do-config.txt') -Encoding utf8
Get-DODownloadMode |
    Format-List * |
    Out-File -FilePath (Join-Path $out 'download-mode.txt') -Encoding utf8
Get-DeliveryOptimizationStatus |
    Select-Object * |
    Export-Csv -NoTypeInformation -Path (Join-Path $out 'active-downloads.csv')
Get-DeliveryOptimizationPerfSnap |
    Format-List * |
    Out-File -FilePath (Join-Path $out 'performance-snapshot.txt') -Encoding utf8

Cmdlet availability and output fields can vary with Windows version and installed module state. Use Get-Command -Module DeliveryOptimization to inventory the supported commands and Get-Help <cmdlet> -Full on the target build before automating collection. Avoid assuming every property is present in a CSV schema. Record Windows build, active network category, client management authority, and timestamp with the output; otherwise the same percentage can describe different effective configurations.

Use Get-DeliveryOptimizationStatus to inspect active transfer-level state and byte attribution when available. Use performance snapshots and logs for aggregate context, not as a substitute for a controlled fleet report. A snapshot can be empty because no transfer is active; that is not evidence that the client never used DO. For longitudinal analysis, collect observations over a representative period and correlate them with update assignments and content size.

Read the metrics as an accounting model

Interpret the source byte counters with a defined denominator. Bytes from peers and connected caches can be compared with total bytes downloaded, but the result is meaningful only when the same content population and reporting interval are used. A cache-served byte count is not identical to bytes saved on the WAN if the cache itself retrieves content from the WAN, if clients make repeated requests, or if reports omit certain clients. Document whether the metric describes device download, upstream transfer reduction, or estimated savings.

The Windows Update for Business Delivery Optimization report can summarize observed configuration and byte distribution over its reporting window. Confirm reporting scope, device freshness, and data delay before comparing groups. A fleet-level average can hide a site with no peers or an MCC that is serving only a small fraction of eligible content. Segment by office, VPN/offsite, device class, and content workload when deciding whether to adjust policy.

Measure both network outcomes and endpoint cost: WAN egress, cache-server egress and disk use, peer-served bytes, client download duration, failed retries, background bandwidth, and storage pressure. A policy can reduce central bandwidth while increasing peer traffic on a congested access VLAN or filling client disks. Determine the network’s busiest periods and test during representative contention, not only in an empty lab.

Size and operate the cache as expendable content

Local DO cache files can expire or be evicted according to quota, age, and service decisions. Treat the cache as disposable. Do not manually delete files under protected data directories to recover disk space; use the supported Delete-DeliveryOptimizationCache cmdlet with a specific scope and understand whether pinned content is included. Cache clearing removes potential reuse and should be a diagnostic or capacity-management action, not a routine repair for a slow update.

Use the documented cache management cmdlets to inspect status and adjust file expiry or pin state where supported. Pinning changes retention and can affect quota accounting; confirm version and semantics on the managed Windows release. Do not pin a broad set of update payloads as if the local cache were a durable update repository. Plan free-space thresholds and monitoring so a cache cannot silently compete with business data or operating-system servicing space.

For Microsoft Connected Cache, measure cache-server health independently from client DO state. Verify the server’s content availability, disk capacity, network reachability, and reported bytes served. A client showing a cache-enabled policy does not establish that MCC is reachable or that the requested content is present. Compare cache-side logs/metrics with the client’s transfer record and a repeatable package request.

Diagnose poor peer utilization without opening the network broadly

If the report shows few peer bytes, first establish eligibility: enough devices requested the same content in the observation period, source files were compatible, and peers shared the intended group and network boundary. Next check peer discovery, device firewall policy, routing, NAT, VPN, group identifiers, and client power state. A client can fall back to HTTP and complete successfully while peer utilization remains zero. Completion proves content acquisition, not peering.

If the client is slow, determine which stage is slow: metadata assignment, source discovery, connection to the CDN/MCC/peer, transfer rate, installation, or restart. DO can account for the download phase; Windows Update, Intune, Configuration Manager, and the servicing stack have separate responsibilities. Correlate timestamps across these components. Do not clear the update cache or reset Windows Update components solely because DO transferred zero bytes.

Check foreground and background bandwidth policies, VPN split tunneling, proxy path, and device network category. Restrictive rates may intentionally yield to user traffic. A measurement that runs while the laptop sleeps, roams, or moves to a metered network can look like a transfer failure even though the client paused by policy. Capture Get-DOConfig, active status, logs, network context, and policy provenance at the same time.

Roll out policy changes in cohorts

Test one change on a representative office subnet, an offsite/VPN cohort, and a constrained network. Specify the desired mode, group identifier, cache policy, bandwidth limits, and fallback source. Use a known supported update or package, record its content identity and size, and request it from multiple clients during the same interval. Compare client status with network-side counters and the relevant DO report after its normal ingestion delay.

For a source or policy change, measure time-to-download, WAN and cache egress, peer/cache hit rate, endpoint disk use, and user impact. Keep a control group on the previous policy where possible. Make rollback explicit by retaining the prior setting and its management scope. If the path depends on a proxy or VPN, validate that route before expanding a peer group to additional networks.

Do not change peer modes or firewall rules globally in response to a single slow device. Peering may be functioning exactly as designed if only one endpoint needs the content. Conversely, a fleet can report some peer bytes while a large site has a broken local distribution path. Use a cohort with enough repeated, compatible requests to test the property you care about.

Operational acceptance checklist

Inventory the content workload, management source, peer boundaries, MCC, and fallback CDN path.
Capture effective DO configuration and download state from each representative network cohort.
Define the byte denominator, report scope, and data latency before claiming savings.
Verify cache capacity and supported cache management; never manipulate internal files directly.
Correlate a client transfer with peer, MCC, WAN, update-agent, and servicing evidence.
Test bandwidth, sleep, roaming, VPN, and metered-network behavior in a pilot.
Roll out by site or cohort and retain an explicit policy rollback path.

Delivery Optimization is a fleet distribution strategy with fallback, not a promise that one computer will always download from another. Its success is measured by the source bytes, duration, reliability, and network cost of the actual workload under representative conditions.

Related:

Sources: