Microsoft Connected Cache, from Intune to the device.

Microsoft Connected Cache is a software-only cache for Microsoft content. Organisations can run Connected Cache for Enterprise and Education, or Connected Cache on a Configuration Manager distribution point.¹

Connected Cache for Enterprise and Education

Created and managed in the Azure portal or with Azure CLI, on physical or virtual host machines.² Microsoft describes it as the cache for customers moving towards modern management and away from distribution points.¹ It caches Windows updates, Microsoft 365 Apps, Intune and Store apps, and Defender definition updates, among others.²

• Host. A Windows 11 device for a branch office of 10 to 50 devices; Windows Server 2022 or later, or Ubuntu 24.04, for a large site.² Nothing else on it may use port 80, a distribution point included.³
• Licence. Windows Enterprise E3 or E5, Education A3 or A5, or Windows Enterprise per device, for each Windows desktop that downloads from it. The Connected Cache resource incurs no Azure cost.³
• Network. The node sets itself up through the Delivery Optimization cloud service, so TLS inspection of geo.prod.do.dsp.mp.microsoft.com stops it.⁴

Connected Cache on a Configuration Manager distribution point

An on-demand, transparent cache on an on-premises distribution point. It serves cloud-managed content only, to co-managed devices whose workloads have moved to Intune and to Intune-only devices, never deployments that start in Configuration Manager.⁵ From 16 June 2026 Intune is moving Win32 app downloads to HTTPS, region by region, which needs the latest Connected Cache update and a certificate the clients trust.⁵ See also Intune Win32 apps and Delivery Optimization, and coming from Configuration Manager.

A device that can’t get content from its cache falls back to the CDN.² With no delay, it falls back after the first failed connection to a cache server; with one, it keeps cycling through its cache servers until the delay runs out.⁷ The delays are DODelayCacheServerFallbackForeground and DODelayCacheServerFallbackBackground, in seconds, from Windows 10, version 1903, and not configured by default.⁶ Microsoft’s summary table suggests 60 seconds for background and 30 for foreground.⁷

Peers have their own pair, DODelayBackgroundDownloadFromHttp and DODelayForegroundDownloadFromHttp, and Microsoft’s pages disagree on how the pairs combine. The configuration guide says both timers start with the download and aren’t additive, so set the cache delay higher than the HTTP delay.⁷ The reference says the HTTP delay applies first and the cache delay after it.⁶

DoctorDO’s reading A cache delay higher than the HTTP delay is right under both readings. Equal values, such as 60 and 30 seconds for both pairs, give the cache no extra time by the configuration guide’s account. The download completes either way; the cache’s share is what’s at stake. DoctorDO flags it as DO-MCC-003.

Microsoft says to place a cache node by your network topology and where you have the most traffic.⁹ Its scenarios run from a branch office of 10 to 50 devices with limited or intermittent internet to sites with thousands of devices; at 100 Mbps a cache delivers about 360 GB in 8 hours.² Peering is best effort: Microsoft puts typical peer efficiency in large enterprises at 30% to 50%, and suggests Connected Cache alongside it for more predictable performance.⁸

DoctorDO’s reading DoctorDO’s network design judges each site as if it had no cache: one Patch Tuesday wave per device, less what peering serves, over the site’s own link at full speed. Two hours or more says Deploy a cache here, 30 minutes or more Consider one, anything less Peering is enough. Twenty or more devices built a month makes the case one step stronger; under 10 devices the advice stops at Consider. A branch whose own WAN is the bottleneck gets its own cache, and one behind a congested hub is served from the hub’s. The thresholds are DoctorDO’s, and the result is an estimate, not a measurement.

Open Network design in the demoChoose Analyse to see the Connected Cache placement, site by site.

Get-DeliveryOptimizationStatus gives each download’s bytes from the cache (BytesFromCacheServer) and the cache’s IP address (CacheHost); BytesFromHttp counts every HTTP source, the cache included. Get-DeliveryOptimizationPerfSnap adds CacheHostConnections.¹¹

# Bytes from the cache, and which cache, for each current download
Get-DeliveryOptimizationStatus |
  Select-Object FileId, DownloadMode, CacheHost, BytesFromCacheServer, BytesFromHttp

# Connections to Connected Cache servers now
Get-DeliveryOptimizationPerfSnap | Select-Object CacheHostConnections

To test a Connected Cache for Enterprise and Education node, open Microsoft’s verification address for it from a client: a small image file should start to download. The device’s Delivery Optimization activity monitor shows the cache’s share as From Microsoft cache server.¹² Across the estate, the Azure portal shows each node’s usage, and Windows Update for Business reports show the devices’² (see Delivery Optimization reports).

DoctorDO takes the cache’s bytes out of the HTTP figure, so its five sources add up to the whole. Each device’s page shows the cache in use and where the device got it (DOCacheHost, DHCP option 235, or the Delivery Optimization service), whether option 235 arrived, Microsoft’s verification download from the device, and the cache’s share of the bytes. What the collector reads is on What is collected.

See a device’s sources in the demo