Skip to content
DoctorDODemo data
Signed in as Alex Morgan, alex.morgan@contosoai.example, Admin.

Demo data: ContosoAI (fictitious). Nothing here is a real company, device or person.

Report · demo data

Reporting

Delivery Optimization across 46,000 devices reporting and 42 sites over the last 30 days, with Microsoft’s Windows Update for Business reports beside it. As of 13 Oct 2026, 09:40 UTC.

Delivery efficiency

49.5%

of 664 TB came from peers and Connected Cache instead of the CDN.1

Below the company goal−10.5 ptsCompany goal 60% · 14 of 42 sites meet it · Change

12 Sept to 11 Oct · +0.9 pts over the period

Delivered
664 TB
to 46,000 devices
Kept off the internet
328 TB
from peers and Connected Cache
Devices reporting
46,000
98% of 46,914 Intune-managed
Findings
2 critical
5 warning · Recommendations

AI briefing · generated text · gpt-5-mini-2025-08-07

Briefing

Critical

Peers and cache delivered 49.5% of 664 TB: the Nordic sites reach 80.4% at Stockholm, and every Wi-Fi VLAN, every firewalled floor and the sites still on legacy distribution points sit far below.

Delivery Optimization works where the plumbing is whole: Stockholm keeps 80.4% of its bytes off the internet and Dublin HQ 69.0%. The CDN still supplied 336 TB (50.5%), and every one of those bytes crossed a WAN link to the Dublin breakout. Three causes explain most of the gap: Wi-Fi client isolation, a security baseline that closes TCP 7680 on some wired floors, and distribution points not yet migrated to Connected Cache. Four sites also carry long cache-fallback delays that hold up Autopilot.

What stands out

  • Working well · Sites

    The Nordic sites show what good looks like

    Stockholm 80.4%, Copenhagen 81.0%, Oslo 80.4% and Helsinki 81.4%: every subnet, Wi-Fi included, reaches a Connected Cache that serves, laptops are docked on wired floors whose inbound TCP 7680 rule is in place, devices keep content for seven days, and no foreground delay is set. Wi-Fi isolation is on there too; the cache and the wired floors carry the efficiency.

    • Delivery efficiency in segment Stockholm 80.4%
    • Delivery efficiency in segment Copenhagen 81.0%
    • Delivery efficiency in segment Oslo 80.4%
    • Delivery efficiency in segment Helsinki 81.4%

  • Critical · Sites

    Frankfurt closes TCP 7680 on every wired floor

    Frankfurt reaches 0.0% efficiency on 13.7 TB. A security baseline disables the Delivery Optimization inbound rule, so offered peers refuse and everything comes from the CDN over the WAN.

    • Delivery efficiency in segment Frankfurt 0.0%
    • Bytes downloaded in segment Frankfurt 13.7 TB
    • Devices failing "The inbound firewall rule for TCP 7680 is in force" 1,961 devices

  • Warning · Errors and connectivity

    Wi-Fi client isolation stops peering on every wireless VLAN

    24,315 devices fail the peer-connection check, almost all on Wi-Fi where the host firewall passes. Laptops, mostly on Wi-Fi, take their bytes from the CDN or the cache and give nothing back.

    • Devices failing "Peers accept connections on TCP 7680" 24,315 devices

  • Warning · Traffic

    Part-migrated sites send Wi-Fi devices to a cache they cannot reach

    6,938 devices are told to use a Connected Cache host that does not answer TCP 80; Manchester reaches only 35.8% efficiency while Dublin HQ reaches 69.0%.

    • Devices failing "The configured Connected Cache host answers on TCP 80" 6,938 devices
    • Delivery efficiency in segment Manchester 35.8%
    • Delivery efficiency in segment Dublin HQ 69.0%

  • Warning · Policy

    Long cache-fallback delays slow Autopilot at four sites

    Sydney, Perth, Bengaluru and Hyderabad keep foreground cache-server fallback delays of 3 to 10 minutes. Enrollment Status Page downloads are foreground, so where the cache host is unreachable each download waits out the delay.

    • Devices in segment Sydney 1,000 devices
    • Devices in segment Perth 90 devices
    • Devices in segment Bengaluru 2,700 devices

  • Note · Policy

    DOMinFileSizeToCache is 4 MB everywhere

    Microsoft’s table suggests 10 MB above 30 devices in a peer group and 1 MB above 100, and the default is 50 MB. 4 MB is below the table for the small branch subnets, so small files take turns in each uploader’s four slots.

    • Devices reporting DOMinFileSizeToCache 44,700 devices

  • Note · Traffic

    Remote workers never peer

    Remote workers (VPN) downloaded 16.0 TB across 1,300 devices, all from the CDN, as Simple mode (99) intends.

    • Bytes downloaded in segment Remote workers (VPN) 16.0 TB
    • Devices in segment Remote workers (VPN) 1,300 devices
    • Devices in download mode Simple (99) 1,300 devices

  • Note · Updates (WUfB)

    Most devices are on the latest security update

    WUfB reports 36,255 devices on the latest security update and 3,475 active update alerts.

    • Devices whose security update status is Latest 36,255 devices
    • Active update alerts in WUfB reports 3,475

Action plan

Now · This week

  1. Re-enable inbound TCP 7680 at Frankfurt

    The security baseline disables the Delivery Optimization inbound rule on its wired floors.

    Expected: Lets Frankfurt’s wired devices peer; its 13.7 TB currently comes entirely from the CDN.

    Effort: low

    • Bytes downloaded in segment Frankfurt 13.7 TB
    • Devices failing "The inbound firewall rule for TCP 7680 is in force" 1,961 devices

  2. Allow TCP 7680 between Wi-Fi clients, or give them a cache

    Client (AP) isolation drops device-to-device traffic on the wireless VLANs.

    Expected: Peering on Wi-Fi, or a reachable Connected Cache, would take the laptops off the WAN.

    Effort: medium

    • Devices failing "Peers accept connections on TCP 7680" 24,315 devices

Next · This month

  1. Open TCP 80 from the Wi-Fi VLANs to the Connected Cache hosts

    Part-migrated sites name a cache host that only their wired floors can reach.

    Expected: Brings Manchester and the other part-migrated sites towards Dublin HQ’s efficiency.

    Effort: medium

    • Devices failing "The configured Connected Cache host answers on TCP 80" 6,938 devices

  2. Shorten the foreground cache-fallback delay at Sydney and Perth

    Autopilot downloads are foreground and wait out the delay when the cache host does not answer.

    Expected: Cuts provisioning time at the four slow sites; give Autopilot devices their own profile.

    Effort: low

    • Devices in segment Sydney 1,000 devices
    • Devices in segment Perth 90 devices

Later · To evaluate

  1. Finish the distribution point migration at the branches

    The smallest sites on the thinnest links (10 to 50 Mbps) are the last on legacy distribution points.

    Expected: A cache at the branch takes the monthly CDN bytes off a link that cannot carry a Patch Tuesday wave quickly.

    Effort: high

Limits of this briefing

  • Efficiency covers the last 30 days of collector reports; WUfB reports uses its own 28-day window and Microsoft’s formula, so the two are close but not equal.
  • Autopilot durations are not measured by DoctorDO; the cause is read from the delays and the cache reachability.
  • Fukuoka has 80 devices: its figures are a small sample.

Generated text. Written 13 Oct 2026, 07:04 UTC (3 hours ago) for alex.morgan@contosoai.example, by deployment gpt-5-mini (gpt-5-mini-2025-08-07) in 23.8 s, 11,842 tokens in and 2,104 out. It summarises the evidence it was given; the findings on Recommendations come from DoctorDO’s rules, not from a model. DoctorDO removed 1 citation or item it could not match to the evidence.

What was sent

Counts, byte totals, ratios and dates, with DoctorDO’s own names for rules, settings, error codes and checks: 248 metrics, 42 sites as tokens (S1, S2 and so on), 10 findings. No device name or ID, no address, no Group ID or cache-server name, and no site name. Site names were added back here, in your browser.

Sample data: nothing is sent.

Where the bytes came from

Every byte devices downloaded through Delivery Optimization in the period, by source.
Internet peers count towards efficiency here; Microsoft’s WUfB “bandwidth savings” leaves them out.3 Uploaded to LAN, Group and Internet peers, as each download job counts it: 84.5 TB.

Efficiency over the period

Daily delivery efficiency across the estate, with the days a policy change was first seen.
  • A policy change, first seen that day
45%50%55%49.5%12 Sept11 Oct

A change on the same day as a dip or a rise is an association, not proof of cause: content releases and patch weeks move efficiency too.

Sites compared

Every site at once: across, how much it downloaded; up, its delivery efficiency. The sites to look at sit low and to the right, a lot of traffic and little of it from peers or cache. The dashed line is the company goal of 60%.

No Connected Cache trafficConnected Cache served some of its bytesGoal, 60%

0%25%50%75%100%1 TB10 TB100 TBDownloaded in the period (log scale) →↑ Delivery efficiency
Efficiency is volume-weighted: peers and cache as a share of every byte the site downloaded. A site with few devices or little traffic moves a lot on little evidence.

Download modes in use

Devices by their own download mode. Simple (99) and HTTP only (0) never peer; Group (2) peers within a group across subnets.1
  1. Group (2)44,700 devices97%
  2. Simple (99)1,300 devices3%

Settings across devices

The most common value of each Delivery Optimization setting, who set it, and whether devices agree. DoctorDO judges them against the Large enterprise baseline with Microsoft Connected Cache deployed.
Delivery Optimization settings across devices
SettingMost commonSet byDevices agree
DODelayBackgroundDownloadFromHttp60Intune (MDM)3 values44,700 reporting
DODelayCacheServerFallbackForeground60Intune (MDM)9 values12,200 reporting
DODownloadMode2Intune (MDM)2 values46,000 reporting
DOGroupId(set)Intune (MDM)41 values44,700 reporting
DOMinFileSizeToCache4Intune (MDM)Yes44,700 reporting
DORestrictPeerSelectionBy1Intune (MDM)Yes44,700 reporting

Group IDs and cache-server names show as “(set)” here and are never sent to the AI briefing.

Policy changes and their effect

Settings that changed in the period, the day each was first seen, and how efficiency moved in the week after compared with the week before.
  1. 7 OctDODelayCacheServerFallbackForeground unset → 600Intune · 90 devices · overlaps another changeNo clear change +0.1 pts
  2. 3 OctDODelayCacheServerFallbackForeground 30 → 300Intune · 1,000 devices · overlaps another changeNo clear change +0.7 pts
  3. 29 SeptDOCacheHost unset → dp01.sin.contosoai.exampleIntune · 1,300 devices · overlaps another changeImproved +1.7 pts
  4. 24 SeptDOCacheHost unset → dp01.ork.contosoai.exampleIntune · 1,000 devices · overlaps another changeNo clear change +0.9 pts
  5. 17 SeptDOMinFileSizeToCache 50 → 4Intune · 46,000 devicesNo clear change -0.8 pts

Findings

All recommendations
What DoctorDO’s rules found, highest impact first. Deterministic and cited: the briefing above may explain them, but never changes them.
  • Critical 2
  • Warning 5
  • Info 3
  1. CriticalDO-NET-002Peers are offered but not reached on a subnet: client isolation suspected
  2. CriticalDO-NET-010Peers are refused because inbound TCP 7680 is blocked on the devices
  3. WarningDO-EFF-002No foreground delay before falling back to the CDN
  4. WarningDO-TOP-006One device carries 70% of what its peer group shares
  5. WarningDO-TOP-006One device carries 79% of what its peer group shares
  6. WarningDO-TOP-006One device carries 79% of what its peer group shares

Errors and connectivity

ErrorsConnectivity
6,021 of 46,000 devices reported a Delivery Optimization error; 24,481 fail at least one connectivity check.

Most widespread error codes

  1. DO_E_DOWNLOAD_NO_PROGRESS0x80D020025,891 devices97%
  2. WININET_E_TIMEOUT0x80072EE2160 devices3%

Checks failing or warning

  • Peers accept connections on TCP 7680Peers · differs within a site24,315 failof 44,700
  • The inbound firewall rule for TCP 7680 is in forcePeers · differs within a site1,961 failof 44,700
  • The configured Connected Cache host answers on TCP 80Connected Cache · differs within a site6,938 failof 37,800

Provisioning · demo data

Autopilot provisioning

What the Enrollment Status Page logged on devices provisioned with Autopilot, and what Delivery Optimization served in the hours after, judged against each device’s own settings.
Devices with a summary
2,570
of 46,000 devices judged
With download figures
2,259
311 had none: the downloads were read too long after provisioning, or not at all
Sites
42
with a device that showed the ESP

Times are between the first and last status the ESP logged, for the ESP as a whole and for each app; they are not install times. DoctorDO does not read the time-out in your ESP profile, so 60 minutes is only the default ESP time-out.

Provisioning by site

Sites with the longest median first. Minutes are between the first and last status the ESP logged; bytes are what Delivery Optimization served in the hours after, by source.
Enrollment Status Page minutes and bytes by source, by site
SiteDevicesMedian min90th percentile minBytes by sourceHTTP share
Perth818122844.0 GB100%
Fukuoka49210718.7 GB100%
Sydney707787402 GB100%
Chennai9748956.2 GB100%
Bengaluru24064751.3 TB100%
Toulouse5579231.4 GB100%
Hyderabad1505361828 GB100%
Atlanta5488724.9 GB100%
Seattle854051481 GB100%
Denver6345831.3 GB100%

Showing 1 to 10 of 42

Microsoft CDNConnected CachePeers

HTTP share is the part of the bytes that came from the Microsoft CDN rather than a Connected Cache server or a peer. 311 of the 2,570 devices have no download figures. The downloads were read too long after provisioning, or not at all, so there are no figures for them. That is not zero bytes.

Apps by median time

The Win32 apps the ESP tracked, longest median first, by Intune app ID. The minutes are between the first and last status the ESP logged for that app, not its install time.
Apps the Enrollment Status Page tracked, by median minutes
Intune app IDDevicesMedian minErrors
d14343c5-bbda-4075-b39d-63568880611d2,5701.50
d27a4bf2-fdc0-4aa9-8c4c-526ab6db556f2,5701.50
410a22e4-4380-477a-b4ca-f92e3c6bd6002,5701.30
48805112-a9d5-42a3-9c37-936e80b366ce2,5701.30
a0354e19-01c4-40d7-829d-61658162954f2,5701.20
a9cc3afa-5d0a-4d93-969e-4cf9e5b3f2072,5701.20
eca17b95-c2dd-47cd-9581-f5ded84488632,5701.128
7318ebc4-c9da-4bb8-9655-f65ddb4a64a02,5701.10
b4ef6fc0-864c-483f-ac86-ef090b33b09e2,5701.10
c513f0b9-e4c7-4bd6-b4b6-30f8b6f5e8752,5701.10

Showing 1 to 10 of 12

Only the app’s ID is collected, never its name. An error is an InstallationState of 4; the Intune Management Extension log on the device says why.

Opportunities

What the engine found on the devices, and how many each applies to. Each is Measured, read on the device, or Modelled, an upper bound from documented behaviour.
  1. MeasuredApplies to 1,883 of 2,570 devices · wording from one of them

    4 downloads below the 4 MB peer-caching minimum

    7.0 MB in files smaller than DOMinFileSizeToCache (4 MB), which Delivery Optimization does not cache for peers. Microsoft suggests 10 MB above 30 devices and 1 MB above 100.

    Read on the device.

    Microsoft LearnConfigure Delivery Optimization (opens in a new tab)

  2. ModelledApplies to 722 of 2,570 devices · wording from one of them

    A download the cache cannot serve waits 60 s

    DODelayCacheServerFallbackForeground is 60 s. The cache-server and HTTP delays both start with the download, so a foreground download the cache server does not answer waits up to 60 s before HTTP.

    An upper bound from Microsoft’s documented behaviour, not a measured saving.

    Microsoft LearnConfigure Delivery Optimization: using Connected Cache (opens in a new tab)

  3. MeasuredApplies to 722 of 2,570 devices · wording from one of them

    A Connected Cache server is configured but served nothing

    6.3 GB came over HTTP and none from the cache server. Check the device's connectivity findings for the cache host.

    Read on the device.

  4. MeasuredApplies to 489 of 2,570 devices · wording from one of them

    The ESP ran 53 minutes, close to the default 60-minute time-out

    Measured from the first to the last status the ESP logged. The time-out set in your ESP profile is not read on the device; 60 minutes is the default, so a longer run means the profile allows more or this device reached its time-out.

    Read on the device.

    Microsoft LearnSet up the Enrollment Status Page (opens in a new tab)

  5. ModelledApplies to 416 of 2,570 devices · wording from one of them

    Foreground downloads can wait 120 s before HTTP

    DODelayForegroundDownloadFromHttp is 120 s. 17 foreground downloads ran soon after provisioning; 9 of the 10 largest came from HTTP alone, so each of those waited up to 120 s first. Microsoft's guidance for devices being provisioned: 0 s.

    An upper bound from Microsoft’s documented behaviour, not a measured saving.

    Microsoft LearnConnected Cache: plan for Windows Autopilot provisioning (opens in a new tab)

  6. MeasuredApplies to 400 of 2,570 devices · wording from one of them

    51% of provisioning's downloads came over HTTP

    3.2 GB of 6.3 GB came from the HTTP source. A device being provisioned is a transient peer: a cache server is the persistent local source Microsoft recommends for Autopilot.

    Read on the device.

    Microsoft LearnConnected Cache: plan for Windows Autopilot provisioning (opens in a new tab)

  7. MeasuredApplies to 28 of 2,570 devices · wording from one of them

    1 app failed during the Enrollment Status Page

    An InstallationState of 4 (Error) stops the ESP installing apps; the Intune Management Extension log says why.

    Read on the device.

    Microsoft LearnTroubleshooting the Enrollment Status Page (opens in a new tab)

DoctorDO states no total for the minutes provisioning could save: downloads overlap, the time-out in your ESP profile is not on the device, and a download’s duration includes the time it waited. A Modelled opportunity is an upper bound from documented behaviour (the HTTP delay and the cache-server fallback delay both start with the download), not something measured.

Two views of the same estate

DoctorDO and Microsoft side by side

The collector measures each reporting device; WUfB reports aggregates Windows diagnostic data for every enrolled device.3 Close figures confirm each other; a wide gap points at devices without the collector, or at a site the collector does not see.

DoctorDO collector

49.5%

WUfB reports

61.2%

Difference 11.7 pts · Microsoft’s snapshot 13 Oct 2026, 02:10 UTC
DoctorDO and WUfB reports compared
DoctorDOWUfB reports
Efficiency / savings49.5%61.2%
Devices46,00046,000
Window30 days28 days, rolling
Counts Internet peersYesNo

By content type (WUfB)

Microsoft’s content categories by volume, with each one’s bandwidth savings.
  1. Quality Updates44,818 devices104 TB74%
  2. Feature Updates11,393 devices73.4 TB55%
  3. Office42,561 devices45.1 TB60%
  4. Intune Apps39,551 devices27.9 TB51%
  5. Driver Updates14,402 devices13.3 TB43%
  6. Edge Updates45,498 devices10.0 TB57%
  7. Teams Updates41,773 devices6.1 TB47%
  8. Other35,002 devices6.4 TB28%

Microsoft marks savings at or under 60% as a warning and under 10% as an error.3

Security updates (WUfB)

46,000 devices in Microsoft’s update status, and 3,475 active update alerts.
  • On the latest 36,255
  • One behind 7,667
  • Several missing 2,078

Top active alerts

  • DiskFullError1,469 alerts · 1,469 devices
  • DownloadFailureError1,039 alerts · 931 devices
  • PostRestartIssueWarning645 alerts · 609 devices
  • DiskFullWarning322 alerts · 322 devices

Microsoft documentation

References

  1. 1Delivery Optimization reference (download modes, Group ID, delays) (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-reference
  2. 2Configure Delivery Optimization for Windows (opens in a new tab)learn.microsoft.com/windows/deployment/do/delivery-optimization-configure
  3. 3Delivery Optimization data in Windows Update for Business reports (opens in a new tab)learn.microsoft.com/windows/deployment/update/wufb-reports-do
  4. 4Microsoft Connected Cache for Enterprise and Education (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-microsoft-connected-cache
  5. 5Azure OpenAI in Foundry: structured outputs (opens in a new tab)learn.microsoft.com/azure/foundry/openai/how-to/structured-outputs
  6. 6Data, privacy and security for Azure OpenAI in Foundry Models (opens in a new tab)learn.microsoft.com/azure/ai-foundry/responsible-ai/openai/data-privacy