Act · demo data
Recommendations
Every finding gives the setting, the value to set, its Microsoft source, and how many devices it applies to. Nothing changes until you import the policy into Intune and assign it.
- Microsoft CDN (HTTP)
- Connected Cache
- LAN · Group · Internet peers
- No bytes
- Policy
- Blocked
- Line weight follows bytes
critical
Organisation
DO-NET-002
Peers are offered but not reached on a subnet: client isolation suspected
41 sites
- Evidence
- At 41 sites: Dublin HQ · 2,778 devices on 10.10.128.0/20; Cork · 480 devices on 10.11.128.0/20; London · 1,680 devices on 10.12.128.0/20; Manchester · 645 devices on 10.13.128.0/20; Edinburgh · 274 devices on 10.14.128.0/20; Belfast · 106 devices on 10.15.128.0/20; Munich · 928 devices on 10.16.128.0/20; Berlin · 581 devices on 10.17.128.0/20; and 33 more. 2,778 devices whose own firewall lets Delivery Optimization in reached 71 of 22,224 offered peers (0%). 2,778 devices reached fewer than 1 in 5 of theirs.
- Change
- From two devices on 10.10.128.0/20, run Test-NetConnection -ComputerName <the other device's address> -Port 7680. If it fails while the host firewall rule is on, allow device-to-device traffic on TCP 7680 on that SSID or VLAN (switch off client isolation there, or add an exception), or give these devices a peer group they can reach.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnConfigure Delivery Optimization for Windows (opens in a new tab)What changes on the network
Before
The DO service offers these devices peers and their own firewall lets Delivery Optimization in, but the connections fail: something between them (client isolation, a private VLAN) drops TCP 7680. After
With device-to-device traffic on TCP 7680 allowed on the subnet, the site’s devices serve each other and take less from the CDN. Describe this diagram
Before
The DO service offers these devices peers and their own firewall lets Delivery Optimization in, but the connections fail: something between them (client isolation, a private VLAN) drops TCP 7680.
Places
- One subnet: Peers, Devices
Parts
- Microsoft CDN (internet source)
- Peers: Firewall rule passes
- Devices: Firewall rule passes
Connections
- Microsoft CDN → Devices: HTTP download, active
- Microsoft CDN → Peers: HTTP download, active
- Peers → Devices: LAN peering, blocked (TCP 7680 · isolation?)
After
With device-to-device traffic on TCP 7680 allowed on the subnet, the site’s devices serve each other and take less from the CDN.
Places
- One subnet: Peers, Devices
Parts
- Microsoft CDN (internet source)
- Peers: Firewall rule passes
- Devices: Firewall rule passes
Connections
- Microsoft CDN → Devices: HTTP download, active (less from the CDN)
- Microsoft CDN → Peers: HTTP download, active
- Peers → Devices: LAN peering, active (TCP 7680)
critical
Organisation
DO-NET-010
Peers are refused because inbound TCP 7680 is blocked on the devices
7 sites
- Evidence
- At 7 sites: Frankfurt · 180 devices on 10.18.1.0/24; Frankfurt · 180 devices on 10.18.2.0/24; Frankfurt · 180 devices on 10.18.3.0/24; Hamburg · 83 devices on 10.19.1.0/25; Seattle · 176 devices on 10.26.2.0/24; Boston · 186 devices on 10.29.1.0/24; Boston · 185 devices on 10.29.2.0/24; Chicago · 185 devices on 10.30.1.0/24; and 3 more. 180 of the 180 devices that tried to reach peers fail the inbound firewall rule check, and 4 of 1,440 connections succeeded (0%).
- Change
- Enable the Delivery Optimization (TCP-In) rule for the profiles in use, and remove or scope any block rule or policy that overrides it. Peers cannot fetch from these devices until then.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnConfigure Delivery Optimization for Windows (opens in a new tab)What changes on the network
Before
Peers are offered but the inbound rule for TCP 7680 is off, so devices take their content from the CDN over the WAN. After
With TCP 7680 open, the site’s devices serve each other on the LAN and take less from the CDN. Describe this diagram
Before
Peers are offered but the inbound rule for TCP 7680 is off, so devices take their content from the CDN over the WAN.
Places
- One site: LAN peers, Host firewall, Devices
Parts
- Microsoft CDN (internet source)
- LAN peers
- Host firewall (firewall): TCP 7680 blocked
- Devices
Connections
- Microsoft CDN → Devices: HTTP download, active
- LAN peers → Host firewall: LAN peering, blocked (TCP 7680)
- Host firewall → Devices: LAN peering, idle (no bytes)
After
With TCP 7680 open, the site’s devices serve each other on the LAN and take less from the CDN.
Places
- One site: LAN peers, Host firewall, Devices
Parts
- Microsoft CDN (internet source)
- LAN peers
- Host firewall (firewall): TCP 7680 open
- Devices
Connections
- Microsoft CDN → Devices: HTTP download, active (less from the CDN)
- LAN peers → Host firewall: LAN peering, active
- Host firewall → Devices: LAN peering, active
warning
Organisation
DO-EFF-002
No foreground delay before falling back to the CDN
All 46,000 devices
- Evidence
- DODelayForegroundDownloadFromHttp is not configured, so foreground downloads start pulling from the HTTP source immediately. Microsoft's starting point is 30 seconds. Microsoft: “a good starting point is 60 seconds for background settings and 30 seconds for foreground settings.”
- Change
- DODelayForegroundDownloadFromHttp: not configured → 30 seconds (Microsoft's starting point)
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
A foreground delay is added to user-initiated updates. Microsoft warns that a 5-minute value adds 5 minutes to an interactive update; 30 seconds is the suggested starting point. Microsoft gives a different value for devices being provisioned with Windows Autopilot: 0 for the foreground delay (DO-POL-009). Keep 30 seconds for steady state and 0 in a profile assigned to Autopilot devices. Registry value name is pending lab verification; use the Group Policy or Intune path.Microsoft LearnConfigure Delivery Optimization for Windows (opens in a new tab)What changes on the network
Before
With no foreground HTTP delay, devices fetch from the CDN before peers have a chance. After
Foreground downloads wait 30 seconds (Microsoft's starting point) s for peers before the CDN, so more bytes come from peers. Describe this diagram
Before
With no foreground HTTP delay, devices fetch from the CDN before peers have a chance.
Places
- One site: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices: 46,000 devices
Connections
- Intune → Devices: Policy (DODelayForegroundDownloadFromHttp = not configured)
- Microsoft CDN → Devices: HTTP download, active (at once)
- Peers → Devices: LAN peering, active
After
Foreground downloads wait 30 seconds (Microsoft's starting point) s for peers before the CDN, so more bytes come from peers.
Places
- One site: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices: 46,000 devices
Connections
- Intune → Devices: Policy (DODelayForegroundDownloadFromHttp = 30 seconds (Microsoft's starting point))
- Microsoft CDN → Devices: HTTP download, active (after 30 seconds (Microsoft's starting point) s)
- Peers → Devices: LAN peering, active
warning
Site
DO-TOP-006
One device carries 70% of what its peer group shares
Toulouse · 67 devices on 10.22.1.0/25
- Evidence
- TLS-D-00054 uploaded 390 GB of the 558 GB its peer group (subnet 10.22.1.0/25, 67 devices) shared: 70%.
- Change
- Let more devices share: check why the others upload little (battery, VPN, RAM, disk, download mode), keep a few always-on devices in the group, and consider a longer DOMaxCacheAge so they keep content for longer.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnDelivery Optimization FAQ (opens in a new tab)What changes on the network
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN. After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy. Describe this diagram
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN.
Places
- Toulouse: One device, Rest of the group
Parts
- Microsoft CDN (internet source)
- One device: Most uploads
- Rest of the group: 67 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- One device → Rest of the group: LAN peering, active (most of the uploads)
After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy.
Places
- Toulouse: Sharers, Rest of the group
Parts
- Microsoft CDN (internet source)
- Sharers
- Rest of the group: 67 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- Sharers → Rest of the group: LAN peering, active (shared by many)
warning
Site
DO-TOP-006
One device carries 79% of what its peer group shares
Atlanta · 46 devices on 10.32.1.0/26
- Evidence
- ATL-D-00031 uploaded 261 GB of the 330 GB its peer group (subnet 10.32.1.0/26, 46 devices) shared: 79%.
- Change
- Let more devices share: check why the others upload little (battery, VPN, RAM, disk, download mode), keep a few always-on devices in the group, and consider a longer DOMaxCacheAge so they keep content for longer.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnDelivery Optimization FAQ (opens in a new tab)What changes on the network
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN. After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy. Describe this diagram
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN.
Places
- Atlanta: One device, Rest of the group
Parts
- Microsoft CDN (internet source)
- One device: Most uploads
- Rest of the group: 46 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- One device → Rest of the group: LAN peering, active (most of the uploads)
After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy.
Places
- Atlanta: Sharers, Rest of the group
Parts
- Microsoft CDN (internet source)
- Sharers
- Rest of the group: 46 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- Sharers → Rest of the group: LAN peering, active (shared by many)
warning
Site
DO-TOP-006
One device carries 79% of what its peer group shares
Chennai · 46 devices on 10.39.1.0/26
- Evidence
- MAA-D-00031 uploaded 260 GB of the 329 GB its peer group (subnet 10.39.1.0/26, 46 devices) shared: 79%.
- Change
- Let more devices share: check why the others upload little (battery, VPN, RAM, disk, download mode), keep a few always-on devices in the group, and consider a longer DOMaxCacheAge so they keep content for longer.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnDelivery Optimization FAQ (opens in a new tab)What changes on the network
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN. After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy. Describe this diagram
Before
One device uploads most of what the group shares; when it is off, asleep or its four slots hold other content, the rest go to the CDN.
Places
- Chennai: One device, Rest of the group
Parts
- Microsoft CDN (internet source)
- One device: Most uploads
- Rest of the group: 46 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- One device → Rest of the group: LAN peering, active (most of the uploads)
After
With more devices able to share, the group keeps peering when its biggest uploader is off, asleep or busy.
Places
- Chennai: Sharers, Rest of the group
Parts
- Microsoft CDN (internet source)
- Sharers
- Rest of the group: 46 devices
Connections
- Microsoft CDN → Rest of the group: HTTP download, active
- Sharers → Rest of the group: LAN peering, active (shared by many)
warning
Site
DO-CAP-009
1,300 devices download but cannot upload to peers
Remote workers (VPN) · 1,300 devices
- Evidence
- They took 16.0 TB of the 16.0 TB downloaded here (100%): 1,300 devices in a download mode that never peers, 1,300 devices on VPN, 449 devices on battery, 6 devices with RAM below the minimum and 5 devices with a disk below the minimum.
- Change
- Put them in a download mode that peers (1 or 2) where they sit on a network with peers, allow peering on VPN where the tunnel leads to the corporate network (DOAllowVPNPeerCaching), or use Local Peer Discovery, which works on VPN, set DOMinBatteryPercentageAllowedToUpload (Microsoft suggests 40 to 60%) so laptops share while on battery, lower DOMinRAMAllowedToPeer if these devices should share and lower DOMinDiskSizeAllowedToPeer, or move the cache (DOModifyCacheDrive) to a larger drive.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnDelivery Optimization FAQ (opens in a new tab)What changes on the network
Before
These devices download but cannot upload to peers, so their demand falls on the rest of the group or on the CDN. After
With the reason removed where it can be (VPN peering, uploads on battery), these devices share what they download. Describe this diagram
Before
These devices download but cannot upload to peers, so their demand falls on the rest of the group or on the CDN.
Places
- Remote workers (VPN): Peers, Devices
Parts
- Microsoft CDN (internet source)
- Peers
- Devices: 1,300 devices, Cannot upload
Connections
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active
- Devices → Peers: LAN peering, idle (no bytes) (nothing back)
After
With the reason removed where it can be (VPN peering, uploads on battery), these devices share what they download.
Places
- Remote workers (VPN): Peers, Devices
Parts
- Microsoft CDN (internet source)
- Peers
- Devices: 1,300 devices
Connections
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active
- Devices → Peers: LAN peering, active (shares back)
info
Organisation
DO-EFF-003
Background downloads are not being steered towards peers
All 46,000 devices
- Evidence
- DOMinBackgroundQos is not configured. Microsoft's example sets it to 500 KB/s on a network whose average download speed is 1000 KB/s.
- Change
- DOMinBackgroundQos: not configured → 500 KB/s as a starting point, below your network's average download speed
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
DoctorDO does not measure the network's average download speed. The collector's Delivery Optimization performance reading is the bandwidth in use at the moment it runs, so it is not used for this value. Units are contested between Microsoft pages — see docs/15 section 5.3. The CSP denominates this policy in KB/s. Registry value name is pending lab verification; use the Group Policy or Intune path.Microsoft LearnMicrosoft Learn (opens in a new tab)What changes on the network
Before
The background QoS keeps content from peers, so it comes from the CDN instead. After
With the background QoS changed, more of the same content is served by peers. Describe this diagram
Before
The background QoS keeps content from peers, so it comes from the CDN instead.
Places
- One site: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices: 46,000 devices
Connections
- Intune → Devices: Policy (DOMinBackgroundQos = not configured)
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active (QoS floor too high)
After
With the background QoS changed, more of the same content is served by peers.
Places
- One site: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices: 46,000 devices
Connections
- Intune → Devices: Policy (DOMinBackgroundQos = 500 KB/s as a starting point, below your network's average download speed)
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active (QoS below measured)
info
Organisation
DO-POL-009
Fallback delays can hold up Windows Autopilot provisioning
10 sites
- Evidence
- At 10 sites: Austin · 1,100 devices; Berlin · 1,100 devices; Bengaluru · 2,700 devices; Hyderabad · 1,400 devices; Lyon · 610 devices; Manchester · 1,300 devices; Perth · 90 devices; Seattle · 1,600 devices; and 2 more. DODelayCacheServerFallbackForeground is 60 s. If this configuration reaches devices while Windows Autopilot provisions them, a download that no peer or cache can serve yet waits for the delay before it comes from the HTTP source. Microsoft: “To avoid unnecessary delays during time-sensitive provisioning, configure Delivery Optimization settings for both priority types: Set Delay foreground download from HTTP to 0 seconds. Set Delay background download from HTTP to 0 seconds or a low value.”
- Change
- DODelayCacheServerFallbackForeground: 60 → short, or 0, for devices being provisioned with Autopilot
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Read before you assign a change: Policy assignment: Delivery Optimization and Autopilot
DoctorDO cannot tell from configuration which devices Windows Autopilot provisions. If none of the devices that receive this configuration are, there is nothing to change. Content downloaded during the Enrollment Status Page can use foreground or background priority. Intune Win32 apps download at background priority unless their assignment sets Delivery Optimization priority to foreground, so the background delay governs them by default. Keep the delays in a profile of their own: one with 0 assigned to Autopilot devices, your steady-state values to every other device. Two profiles that set one setting to different values on the same device conflict, and the setting might not apply. Scope it with an assignment filter on enrollmentProfileName, a dynamic device group on (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")), or the Autopilot device preparation device group. All three keep matching after provisioning, so those devices keep the provisioning values until you move them. Microsoft's Autopilot guidance names only the HTTP delays. The cache-server delays are listed because, while one runs, a device that cannot reach its cache keeps trying it before it falls back to the HTTP source (DoctorDO's reading of the Connected Cache fallback timing). Before a broad change, test with a representative batch of devices provisioned at the same time and watch the total Enrollment Status Page duration, as Microsoft advises. Registry value name is pending lab verification; use the Group Policy or Intune path.Microsoft LearnConnected Cache: plan for Windows Autopilot provisioning (opens in a new tab)What changes on the network
Before
If Autopilot provisions devices that receive this profile, a foreground download no peer or cache can serve yet waits for the delay, then comes from the CDN anyway. After
With a provisioning profile that sets the delay to 0 for Autopilot devices, a required app no peer has yet comes from the CDN straight away; your other devices keep their steady-state delay. Describe this diagram
Before
If Autopilot provisions devices that receive this profile, a foreground download no peer or cache can serve yet waits for the delay, then comes from the CDN anyway.
Places
- A branch office: Branch devices, New device
Parts
- Microsoft CDN (internet source)
- Intune (policy source)
- Branch devices: No copy yet
- New device: Waiting for peers
Connections
- Microsoft CDN → New device: HTTP download, active (after 60 s)
- Branch devices → New device: Group peering, idle (no bytes) (nothing to share)
- Intune → New device: Policy (wait 60 s)
After
With a provisioning profile that sets the delay to 0 for Autopilot devices, a required app no peer has yet comes from the CDN straight away; your other devices keep their steady-state delay.
Places
- A branch office: Branch devices, New device
Parts
- Microsoft CDN (internet source)
- Intune (policy source)
- Branch devices: No copy yet
- New device: Provisioning
Connections
- Microsoft CDN → New device: HTTP download, active (at once)
- Branch devices → New device: Group peering, idle (no bytes) (nothing to share)
- Intune → New device: Policy (provisioning profile: 0)
info
Organisation
DO-CAP-010
DOMinFileSizeToCache is below Microsoft’s table for the size of the peer group
8 sites
- Evidence
- At 8 sites: Belfast · 84 devices on 10.15.1.0/25; Hamburg · 83 devices on 10.19.1.0/25; Hamburg · 77 devices on 10.19.128.0/20; Toulouse · 67 devices on 10.22.1.0/25; Toulouse · 53 devices on 10.22.128.0/20; Denver · 70 devices on 10.31.1.0/25; Denver · 70 devices on 10.31.128.0/20; Atlanta · 46 devices on 10.32.1.0/26; and 7 more. 84 devices in subnet 10.15.1.0/25 (a peer group of 84 devices) peer files from 4 MB (Intune on 84 devices); Microsoft's table suggests 10 MB for a group of that size.
- Change
- Unless these devices take Microsoft 365 Apps updates through Delivery Optimization (where Microsoft allows the minimum), set DOMinFileSizeToCache to 10 MB for them, or widen the peer group.
- Estimated impact
- Not estimated: no comparable healthy site to base a figure on.
Not an Intune setting: fix it where the cause is.Microsoft LearnConfigure Delivery Optimization for Windows (opens in a new tab)What changes on the network
Before
Where this setting applies: devices in scope, their peers and the CDN. After
The network stays the same; the recommended value reaches the devices through policy. A general picture: this finding changes a setting’s value, not the shape of the network.
Describe this diagram
Before
Where this setting applies: devices in scope, their peers and the CDN.
Places
- Devices in scope: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices
Connections
- Intune → Devices: Policy (current value)
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active
After
The network stays the same; the recommended value reaches the devices through policy.
Places
- Devices in scope: Peers, Devices
Parts
- Intune (policy source)
- Microsoft CDN (internet source)
- Peers
- Devices
Connections
- Intune → Devices: Policy (recommended value)
- Microsoft CDN → Devices: HTTP download, active
- Peers → Devices: LAN peering, active