Learn

Policy assignment

Which Delivery Optimization profile reaches which device, and when. Above all for Windows Autopilot: a profile that makes downloads wait for peers can hold up the Enrollment Status Page on a new device that has none to wait for.

How Intune delivers the policy

Delivery Optimization policy is device policy. Where you assign it decides when a new device gets it, and two profiles that set different values cause a conflict you resolve by hand.

Two ways to build the profile

The Delivery Optimization template under Configuration › Templates moved to the settings catalog format in April 2025: you can no longer create new versions of the old profile, and existing ones keep working.⁶ Microsoft’s list of the old template’s settings applies only to profiles created before 24 April 2025.⁷ Either way, and in a settings catalog profile, the settings are the Policy CSP’s ./Device/Vendor/MSFT/Policy/Config/DeliveryOptimization nodes, each of them device-scoped.¹²

Assign it to devices

Settings assigned to device groups “always go with the device, not the user”; settings assigned to user groups go with the user to each device they sign in to.⁸ Delivery Optimization configures the device, whoever is signed in, so assign it to devices. A profile assigned to users reaches a new device only once its user’s policies do, which in Autopilot is account setup, after the device’s own apps.DoctorDO’s reading

Fig. 1 · Where Intune’s profiles land during provisioningOrder only: Microsoft documents no durations.

Configuration profile (no content)Required app, trackedOrder only: Microsoft documents no durations

Describe this diagram

The Enrollment Status Page runs in three phases: device preparation, then device setup, then account setup.
Configuration profiles assigned to devices, a Delivery Optimization profile among them, are installed in the background during device setup. The ESP doesn’t track them, so nothing waits for them.
Required apps assigned to devices are tracked during device setup: the ESP waits for them.
Profiles assigned to users arrive in account setup, also in the background and also not tracked.
Required apps assigned to users are tracked during account setup.
Windows Autopilot device preparation doesn’t use the ESP. The device joins its device group at enrollment; policies assigned to that group are synced but not tracked, and may apply during the deployment or after it.

Windows Autopilot, with the Enrollment Status Page

The ESP tracks three phases: device preparation, device setup and account setup.¹ Device-targeted apps are tracked in device setup, user-targeted apps in account setup.² Profiles are another matter: “ESP doesn’t track security policies, such as device restrictions, but these policies are installed in the background.”¹ Nothing waits for a Delivery Optimization profile, so whether it is in place before the first required app starts downloading is a race Microsoft doesn’t describe.DoctorDO’s reading

Assigning to a dynamic device group adds its own wait: “Until the device is added to the group, apps and policies assigned to that group aren’t delivered.” Microsoft suggests assignment filters, user groups or enrollment time grouping where enrollment needs them fast.⁹ A group built on Autopilot device attributes is the exception: those attributes exist on registered devices, so membership is in place before provisioning.²⁸

Windows Autopilot device preparation

Device preparation doesn’t use the ESP.¹ The device joins the device group named in the policy at enrollment, and only the apps and scripts selected in the policy are installed during OOBE. For policies, it “syncs any policies assigned to the device group. However, Windows Autopilot device preparation doesn’t track if the policies are applied during the deployment. The policies might be applied either during the deployment or after the deployment is complete.”³

When two profiles disagree

Two configuration profiles that set the same setting to different values on one device are a conflict: Intune shows it, and you resolve it by hand.⁹ The setting might fail to apply at all.¹¹ The settings catalog’s per-setting status lists the devices in conflict.¹⁰ So a provisioning profile and a steady-state profile must never both reach a device: exclude each from the other’s scope.DoctorDO’s reading

Two profiles that set the same delay differently on one device are a conflict: Intune shows it, and the setting might not apply.

When Group Policy sets it too

MDMWinsOverGP makes the MDM value win over an equivalent Group Policy, for policies in the Policy CSP. Without it Microsoft warns of “a race condition and no guarantee which one wins”.¹³ Delivery Optimization’s settings are Policy CSP settings with a Group Policy mapping,¹² so they are covered.DoctorDO’s reading To see which one a device used, Get-DOConfig -Verbose lists each policy with its value and its provider, such as DownloadModeProvider:Mdm Provider, or Default Provider when nothing set it.¹⁴

The fallback delays

Four settings make a download wait for peers or a cache before it uses the HTTP source. Unless they’re set, a download falls back to HTTP straight away.

The four HTTP fallback delays: what each delays, its default and its range
Setting	What it delays	Default	Range
`DODelayForegroundDownloadFromHttp`	The use of an HTTP source in a foreground (interactive) download that is allowed to use peers. Windows 10, version 1803.¹⁵	Not configured;¹⁵ the CSP reports 0.¹²	0 to 4,294,967,295 s¹²
`DODelayBackgroundDownloadFromHttp`	The same, for a background download. Windows 10, version 1803.¹⁵	Not configured;¹⁵ the CSP reports 0.¹²	0 to 4,294,967,295 s¹²
`DODelayCacheServerFallbackForeground`	The fallback from a cache server to the HTTP source, for a foreground download. Windows 10, version 1903.¹⁵	Not configured;¹⁵ the CSP reports 0.¹²	0 to 2,592,000 s¹²
`DODelayCacheServerFallbackBackground`	The same, for a background download. Windows 10, version 1903.¹⁵	Not configured;¹⁵ the CSP reports 0.¹²	0 to 2,592,000 s¹²

Intune describes the HTTP delays the same way for both priorities: “This configuration applies only to downloads that support a peer-to-peer download source. During this delay, the device searches for a peer with the content available. While devices wait for a peer source, the download appears to be stuck for the end user.”⁷

How the timers interact

With HTTP and cache-server delays both set, “both timers start from the beginning of the download (they are not additive)”: a 60-second cache delay behind a 60-second HTTP delay falls back at once when the HTTP delay ends. Set the cache delay higher than the HTTP delay.¹⁶
With peers and a Connected Cache both configured, the peer delays take precedence over the cache-server ones.¹⁵
Without a cache-server delay, a device falls back to the HTTP source after the first cache connection fails; with one, it keeps cycling through its cache servers until the delay expires. The delay applies to each new file download.¹⁶

Both timers start with the download, so they don’t add up: the HTTP source waits for the later one. A cache delay no longer than the HTTP delay buys the cache nothing.

Foreground and background

The priority belongs to the download, not to policy: content providers choose to run downloads in the foreground or background,¹⁹ and each download reports to the DO cloud service whether it is interactive or background.¹⁸ Foreground is the highest priority: those transfers compete for network bandwidth with other applications, while “Background transfers use a small percentage of network bandwidth.”²⁴ Microsoft’s Autopilot guidance: “Content downloaded during the Enrollment Status Page (ESP) can use foreground or background priority, depending on the content type and its configuration.”²⁰

The priority also sets how much of the link a download may take. By default Delivery Optimization “targets to use no more than 45% of the available bandwidth during a background download or 90% for an interactive, foreground download”, and “For LAN peers, the target download speed is not calculated and throttling is not applied.”¹⁹ The percentage limits do apply to Connected Cache.¹⁵

Delivery Optimization’s default targets: a foreground download uses up to 90% of the available bandwidth, a background one up to 45%. LAN peers aren’t throttled.

What a device downloads while it is provisioned, and at which priority
Content	Sources Delivery Optimization can use	Priority
Intune Win32 apps	HTTP, peers and Connected Cache, in public cloud environments.¹⁷	Set per assignment: Delivery optimization priority downloads the content in background or foreground mode.²² Left alone it is `notConfigured`, “not configured or background normal delivery optimization priority”.²³
Microsoft Store apps	UWP Store apps: HTTP, peers and Connected Cache. Win32 Store apps on Windows 11: HTTP only.¹⁷	Not documented. The delays apply only to downloads that can use peers,⁷ so Win32 Store apps don’t wait on them.DoctorDO’s reading
Microsoft 365 Apps	HTTP, peers (except SAC Extended channel) and Connected Cache, when installed or updated from the Office CDN.¹⁷²⁵	Microsoft says Delivery Optimization is used “during installation and for background or user-initiated (foreground) updates”,²⁵ not which priority an install uses.
Windows quality updates during OOBE	Windows Update: HTTP, peers and Connected Cache.¹⁷ With the ESP setting on, monthly security updates install during OOBE after the ESP completes.¹	Not documented.
Intune Management Extension	Installed during device preparation, to install Win32 apps.¹	Microsoft doesn’t say whether this download goes through Delivery Optimization.

Why provisioning feels it

A delay pays off when a peer or a cache can serve the download. A device being provisioned is the one most likely to have neither.

Microsoft’s guidance for Autopilot: devices being provisioned “can also use Delivery Optimization peer-to-peer (P2P), but they are transient peers and might not remain online long enough to provide content to later devices.” To avoid “unnecessary delays during time-sensitive provisioning”, set the foreground HTTP delay to 0 and the background one to 0 or a low value. “These settings allow devices to use peers while making Microsoft HTTP sources immediately available.”²⁰

Fig. 2 · One required app, with and without a delayThe same device; only the wait differs.

From the CDNLooking for peers (no bytes)Waiting: the delayOrder only: no durations

Describe this diagram

Without a delay: Without a delay, the required app starts downloading from the CDN at once while Delivery Optimization still looks for peers. Device setup ends when it is installed.
With a fallback delay: With a fallback delay, the same download first waits for a peer or a cache that never answers. Only when the delay expires does it come from the CDN, so device setup, and everything after it, ends later: by as much as the delay, for each download no peer or cache can serve.

What leaves a new device with nothing to wait for

Devices provisioned alongside it are “transient peers” that “might not remain online long enough to provide content to later devices”.²⁰ The first device at a site to get a new app has no peer for any of its downloads.DoctorDO’s reading
The device can’t reach the DO cloud service yet. The service matches peers,¹⁸ and the client must be able to reach it.¹⁶ Without a peer list, a delay can only expire.DoctorDO’s reading
A VPN is up: by default Delivery Optimization doesn’t peer when it detects one.¹⁶
Connected Cache discovery fails. With LocalPolicyMerge disabled, the DHCP client might not retrieve option 235, “especially common in Windows Autopilot provisioning scenarios”; Microsoft suggests DOCacheHost instead.¹⁶
Download mode 0, 99 or 100: no download may use peers. Microsoft describes the HTTP delays as applying to downloads that are allowed to,¹⁵ so DoctorDO reads them as having no effect there.DoctorDO’s reading

Microsoft CDN (HTTP)
Connected Cache
LAN · Group · Internet peers
No bytes
Policy
Blocked
Line weight follows bytes

Fig. 3 · A new device in a branch where no peer has its appThe same bytes from the CDN; the difference is when.

Without a delay

The device is being provisioned and none of the branch’s devices has the app yet. With no HTTP fallback delay, the download starts from Microsoft’s CDN straight away; Delivery Optimization still looks for peers alongside it.

With a fallback delay

The same device and branch, with an HTTP fallback delay in its profile. The download waits for a peer or a cache to serve it; none can, so when the delay expires it comes from the CDN anyway. Every byte is the same as without the delay; it arrives later.

Describe this diagram

Without a delay

Places

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 (no delay)

With a fallback delay

Places

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 the delay)
Branch devices → New device: Group peering, idle (no bytes) (nothing to share)
Intune → New device: Policy (HTTP delay set)

Fig. 4 · Provisioned off-site with a cache it can’t reachThe cache-server delay keeps it trying.

The device is provisioned at home with a cache host from policy. The cache is on the office network, out of reach. With a cache-server fallback delay set, Delivery Optimization keeps trying it for the length of the delay, then downloads from the CDN.

Describe this diagram

Places

Head office: Connected Cache
Off-site · at home: New device

Parts

Microsoft CDN (internet source)
Intune (policy source)
Connected Cache (connected cache server): Office network
New device: Retrying the cache

Connections

Connected Cache → New device: Connected Cache, blocked (not reachable)
Microsoft CDN → New device: HTTP download, active (after the cache delay)
Intune → New device: Policy (cache host)

The ESP’s time-out

The ESP shows an error when installation takes longer than its time-out, 60 minutes by default.¹ A delay of that length on one download that nothing can serve could use all of it by itself.DoctorDO’s reading Intune’s education deployment tutorial sets the background delay to 3,600 seconds,²⁹ exactly that length.

A 3,600-second delay on one download nothing local can serve uses the ESP’s whole default 60-minute time-out before a byte arrives.

A worked example: what a delay costs, and what it saves

Ten apps, 8.9 GB, one 100 Mbps internet link. A delay costs time when nothing local has the apps and saves the link when peers or a cache do. Every number here is DoctorDO’s estimate, not a Microsoft figure.

The example

10 applications that total 8.9 GB, downloaded over a 100 Mbps internet connection. We read “100 MB” as 100 megabits per second (Mbps), the way internet links are sold. A link of 100 megabytes per second (MB/s) is 800 Mbps: eight times faster, and every download time below would be an eighth as long.DoctorDO’s reading

In decimal units, 8.9 GB is 8.9 × 10⁹ bytes, or 71.2 gigabits. At 100 Mbps that is 712 s (11.9 min) at the full line rate. Delivery Optimization doesn’t take the whole line: it targets no more than 45% of the available bandwidth for a background download,¹⁹ and a Win32 app downloads in the background unless its assignment says otherwise.²³ So with no delay and nothing local to help, one device takes 1,582 s (26.4 min) and pulls all 8.9 GB over the internet. That is the baseline, A.

Per device, in the example: 45 Mbps from the CDN alone, 10 Mbps when 10 share the link, 1,000 Mbps from a LAN peer. Bars to scale.

Three cases

A · No delay, everything from the CDN: 26.4 min and 8.9 GB from the internet.
B · A 60 s delay, and peers or a Connected Cache can serve 90% of each app: 12.6 min and 0.89 GB from the internet, saving 8.01 GB. Each app still waits out the delay for the 10% only the CDN has: 8.9 min of waiting in all, more than made up by the bytes that come over the LAN.
C · The same delay, and nothing local has the apps (the first device at a site, a fresh Autopilot site, or a cache it can’t reach): 36.4 min. The same 8.9 GB, plus 10 × 60 s = 10 min of waiting, saving nothing.

At the site the link is the limit. 10 devices provisioned at once, each pulling everything from the CDN, get 10 Mbps apiece: the downloads alone take 1 h 58.7 min, past the ESP’s default 60-minute time-out,¹ and 89 GB crosses the link. With peers or a cache serving 90%, the site is done in 21.9 min and the link carries 8.9 GB. If nothing local has the apps yet and the first device fetches them (C), with the other 9 then getting them from it, the site finishes in 57.1 min using 16.91 GB: the first device is 10 min slower, and the site finishes 1 h 1.6 min sooner than with every byte from the CDN.DoctorDO’s reading

Try your own numbers

The calculator starts from the example. Change any input; the estimate, both charts and the table follow. Without JavaScript this section shows the example as worked above.

The inputs · the example’s values; change them once the page has loaded

The estimate

One device: 26.4 min and 8.9 GB from the internet with no delay (A). With a 60 s delay and peers serving 90%, 12.6 min and 0.89 GB (B); if nothing local has the apps, 36.4 min, 10 min of it waiting (C).

10 devices at once: 1 h 58.7 min and 89 GB with no delay (A), 21.9 min and 8.9 GB with peers (B), 2 h 8.7 min with nothing local (C); if the first device fetches the apps and the rest then get them locally, 57.1 min and 16.91 GB.

PeersWaiting for the delayMicrosoft CDN (internet)Estimates, not Microsoft figures

Time to finish the downloads

One device

A · no delay26.4 min1,582 s (26.4 min) · peers 0 s, waiting 0 s, CDN 26.4 min
B · delay, local copy12.6 min758 s (12.6 min) · peers 64 s, waiting 8.9 min, CDN 2.6 min
C · delay, nothing local36.4 min2,182 s (36.4 min) · peers 0 s, waiting 10 min, CDN 26.4 min

The site · 10 devices at once

A · no delay1 h 58.7 min7,120 s (1 h 58.7 min) · peers 0 s, waiting 0 s, CDN 1 h 58.7 min
B · delay, local copy21.9 min1,312 s (21.9 min) · peers 64 s, waiting 8.9 min, CDN 11.9 min
C · delay, nothing local2 h 8.7 min7,720 s (2 h 8.7 min) · peers 0 s, waiting 10 min, CDN 1 h 58.7 min
First fetches, rest follow57.1 min3,423 s (57.1 min) · peers 64 s, waiting 18.9 min, CDN 37.1 min

Bytes from the internet, and from peers

One device

A · no delay8.9 GB WAN8.9 GB from the internet, 0 GB from peers
B · delay, local copy0.89 GB WAN0.89 GB from the internet, 8.01 GB from peers
C · delay, nothing local8.9 GB WAN8.9 GB from the internet, 0 GB from peers

The site · 10 devices at once

A · no delay89 GB WAN89 GB from the internet, 0 GB from peers
B · delay, local copy8.9 GB WAN8.9 GB from the internet, 80.1 GB from peers
C · delay, nothing local89 GB WAN89 GB from the internet, 0 GB from peers
First fetches, rest follow16.91 GB WAN16.91 GB from the internet, 72.09 GB from peers

Worked example results: time and internet bytes for each scenario, for one device and for the site
Scenario	Time to finish the downloads	Versus A	From the internet	Internet bytes saved	ESP time-out
One device
A · No delay, everything from the CDN	1,582 s (26.4 min)	the baseline	8.9 GB	—	Within 60 min
B · Delay set, peers or a cache have the content	758 s (12.6 min)8.9 min of it waiting	824 s (13.7 min) saved	0.89 GB	8.01 GB	Within 60 min
C · Delay set, nothing local has the content	2,182 s (36.4 min)10 min of it waiting	+600 s (10 min) added	8.9 GB	0 GB	Within 60 min
The site: 10 devices at once
A · No delay, everything from the CDN	7,120 s (1 h 58.7 min)	the baseline	89 GB	—	Over 60 min
B · Delay set, peers or a cache have the content	1,312 s (21.9 min)8.9 min of it waiting	5,808 s (1 h 36.8 min) saved	8.9 GB	80.1 GB	Within 60 min
C · Delay set, nothing local has the content	7,720 s (2 h 8.7 min)10 min of it waiting	+600 s (10 min) added	89 GB	0 GB	Over 60 min
First device fetches, the rest follow	3,423 s (57.1 min)18.9 min of it waiting	3,697 s (1 h 1.6 min) saved	16.91 GB	72.09 GB	Within 60 min

Downloads only: installs and the rest of the Enrollment Status Page come on top. “ESP time-out” compares one device’s downloads with the default 60 minutes. In the seeded row, the first device fetches the apps on its own, then the others start.

How we worked it out

Size in bits: 8.9 GB × 10⁹ bytes × 8 = 71.2 Gb.
At the full line rate: 71.2 Gb ÷ 100 Mbps = 712 s (11.9 min).
Background priority: Delivery Optimization targets no more than 45% of the available bandwidth, 45 Mbps, so A takes 1,582 s (26.4 min) on one device.
10 devices sharing the link: each gets the smaller of 45 Mbps and 100 ÷ 10 = 10 Mbps, so A takes 7,120 s (1 h 58.7 min) for the site.
One after another: 8.9 GB ÷ 10 apps = 0.89 GB per download, each with its own delay.
B, per download: peers serve 90% (0.8 GB) at 1,000 Mbps in 6.4 s, then the device waits until the 60 s delay ends, and the CDN sends the remaining 0.09 GB: 76 s per download, 758 s (12.6 min) in all.
C, per download: 60 s waiting, then everything from the CDN. Waiting alone: 10 × 60 s = 600 s (10 min).

Assumptions

Line rate. Times use the link’s full rate times the share below. Real throughput is lower (protocol overhead, other traffic, the source’s own speed), so real times are longer.DoctorDO’s reading
Priority. Delivery Optimization “targets to use no more than 45% of the available bandwidth during a background download or 90% for an interactive, foreground download”;¹⁹ the PowerShell defaults agree, 45% background and 90% foreground.¹⁴ The calculator takes that share of the line rate. LAN peers aren’t throttled;¹⁹ the limits apply to downloads from “Microsoft CDNs and Microsoft Connected Cache (MCC)”.¹⁵
The delay is a maximum. Intune describes “a maximum time to delay a background download of content over HTTP”;⁷ “After the max delay is reached, the download will resume using HTTP, either downloading the entire payload or complementing the bytes that couldn’t be downloaded from Peers”;²⁹ with a 5-minute delay an update “might take up to 5 minutes longer”.²⁵ Microsoft doesn’t say whether a device that finds no peer stops waiting early, so C waits the whole delay: the worst case.DoctorDO’s reading
One delay per download. The CSP describes “the time to wait before starting to download from the HTTP source” for downloads that use peers,¹² and the cache-server delay “applies to each new file download”.¹⁶ Each app is taken as one download of equal size. Whether the apps download one after another or together isn’t documented in these sources, so both are offered: one after another, every download waits (the worst case, apps × delay); all at once, the delays overlap (about one).DoctorDO’s reading
Several sources at once. “Each 1-MB piece can come from a different source.”¹⁸ Peers or the cache are taken to be found at once, and the CDN, once allowed, sends the bytes only it has, helping with the rest only if the local source would otherwise finish last.DoctorDO’s reading
Connected Cache. A device asks the cache, which “forwards the requests to the CDN and fills the cache”,²⁰ so the first device at a site with a cache doesn’t wait. A cache it can’t reach is case C: the device “continues to cycle through the configured cache servers for the duration of the configured delay period”.¹⁶ There the delay that counts is the later of the HTTP and cache-server delays, which run together.¹⁶DoctorDO’s reading
The site. Devices start together and share the internet link equally; transfers on the LAN don’t compete with each other (a switched LAN, a cache with room to serve them all). In the seeded row the first device stays online to share, which Microsoft warns provisioning devices might not.²⁰DoctorDO’s reading
How much is local. In Microsoft’s own test, the second device on a LAN got 99.8% of a 3.4 GB download from a peer.³⁰ The example’s 90% is DoctorDO’s choice.DoctorDO’s reading

With and without a delay

The trade-off: no delay against a delay, with the worked example’s numbers
	No delay (0)	With a delay
Time to provision one device	Downloads start at once; nothing waits. 26.4 min in the example (A).	Up to the delay added to every download that nothing local can finish: 10 × 60 s = 10 min in the example (C). Microsoft: with a 5-minute delay a user-initiated update “might take up to 5 minutes longer”.²⁵
Internet (WAN) usage	Peers and a cache are still used alongside the CDN,²⁰ but the CDN starts at once and serves whatever it sends first: up to all 8.9 GB a device (A).DoctorDO’s reading	Peers and the cache get first claim: 0.89 GB a device in place of 8.9 GB when they hold 90% of each app (B).
A fresh site, or the first device	No cost: there was nothing to wait for.	Pure waiting: “the download appears to be stuck for the end user”,⁷ then the same bytes from the CDN (C).
A populated site, or a Connected Cache	10 devices share the 100 Mbps link: 1 h 58.7 min each if the CDN serves everything (A at the site).	Most bytes move onto the LAN: the link carries 8.9 GB in place of 89 GB and the site is done in 21.9 min (B at the site).
What the user sees in the ESP	Progress from the start.	A download that looks stuck for up to the delay,⁷ each time it has nothing local to wait for.DoctorDO’s reading
Risk of an ESP time-out	None from the delay. A busy shared link can still be the limit: the site’s downloads alone take 1 h 58.7 min (A).	At 3,600 s, one download nothing local can serve waits out the whole default 60-minute time-out.¹DoctorDO’s reading

Assignment patterns

Keep provisioning fast without giving up peering on settled devices. Each pattern below is documented; the costs in the last column are mostly DoctorDO’s reading.

Ways to give devices being provisioned different delays, and what each costs
Pattern	How	Cost
Foreground 0 everywhere	One profile for every device: foreground HTTP delay 0, background 0 or low. Microsoft’s values for provisioning,²⁰ so nothing needs to know which devices are being provisioned.	Interactive downloads stop waiting for peers in steady state too; they still use peers alongside the HTTP source.²⁰ Background delays stay low, so steady-state peering gets less help.DoctorDO’s reading
Assignment filter on the enrollment profile	A provisioning profile filtered to `enrollmentProfileName`; the steady-state profile on All devices, excluding the same filter. Filters work for the Delivery Optimization template and the settings catalog.²⁶²⁷	Evaluated at check-in, with no group processing to wait for.⁹ The property is set when the device enrolls,²⁷ so those devices keep the provisioning values afterwards.DoctorDO’s reading
Dynamic group of Autopilot devices	The provisioning profile on a device group with `(device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))`, excluded from the steady-state profile.²⁸	Membership is in place before provisioning: Microsoft recommends Autopilot attributes because they exist on registered devices.²⁸ Registered devices stay members, provisioned or not.DoctorDO’s reading
Autopilot device preparation’s device group	The provisioning profile on the static device group the policy names; devices join it at enrollment.³⁵	Policies are synced, not tracked, so the profile may land during the deployment or after it.³ Removing a device from the group makes Intune re-evaluate it,⁵ along with everything else assigned to that group.DoctorDO’s reading

Put the delays in a profile of their own

Keep download mode, Group ID and cache settings in one profile for every device, and only the four delays in two small profiles: one with provisioning values for Autopilot devices, one with steady-state values for the rest, each excluding the other’s devices. Nothing else then depends on which of the two a device gets, and no setting is ever set twice.DoctorDO’s reading

A filter for Autopilot devices can match the deployment profile’s name, for example (device.enrollmentProfileName -startsWith "Autopilot Profile"), or any device that has one: (device.enrollmentProfileName -ne $null).²⁷ Device preparation sets enrollmentProfileName to the device preparation policy’s name, for use in filters and dynamic groups.⁴

Shared settings in one profile for every device; only the delays in two profiles that each exclude the other’s devices.

Moving devices on after provisioning

Microsoft documents no filter property or group rule that ends when provisioning does.DoctorDO’s reading The enrollment profile name is applied when the device enrolls,²⁷ and the Autopilot attributes belong to the registered device.²⁸ If you want settled Autopilot devices on your steady-state delays, it takes a step of your own: remove them from device preparation’s static group, which makes Intune re-evaluate them,⁵ or change their group tag and key a dynamic group on (device.devicePhysicalIds -any (_ -eq "[OrderID]:your tag")).²⁸ Otherwise the simplest safe choice is the first pattern: foreground 0 for everyone.DoctorDO’s reading

Set Win32 app priority on purpose

Each Win32 app assignment chooses background or foreground download, and background is what an assignment gets unless you change it.²²²¹²³ The delay a download meets is the one for its priority, so decide the priority of every app the ESP waits for, then keep that delay low for devices being provisioned.DoctorDO’s reading

With Connected Cache

Microsoft positions Connected Cache as “a persistent local content source for Windows Autopilot provisioning”, and Autopilot provisioning centres are among the sites it is sized for.²⁰ Its Autopilot guidance names only the HTTP delays.²⁰ For devices that may be provisioned away from the cache, keep the cache-server delays short: while one runs, an unreachable cache is retried, not skipped.¹⁶DoctorDO’s reading Wherever you set both, keep the cache delay above the HTTP delay.¹⁶

What DoctorDO shows

DoctorDO reads each device’s effective Delivery Optimization configuration. It can see a delay; it can’t see Autopilot.

Recommendation DO-POL-009 appears on Recommendations when the effective configuration has a foreground HTTP delay, a background one of 60 minutes or more, or, with a cache host configured, the matching cache-server delays. It is advisory, and a warning at or above the ESP’s default 60-minute time-out.DoctorDO’s reading
It is worded conditionally. The collector has no documented way to tell, on the device, that Autopilot provisioned it, so DoctorDO can’t say whether a profile reaches devices while they are provisioned; only you can.DoctorDO’s reading
The large-enterprise baseline on Intune policies recommends Microsoft’s steady-state starting point, at least 60 seconds background and 30 seconds foreground;¹⁶ its Connected Cache overlay asks for cache-server delays above those; and recommendations DO-EFF-001 and DO-EFF-002 suggest the HTTP delays where they’re missing. Those are steady-state values: assign them away from devices being provisioned.DoctorDO’s reading
Devices shows each device’s delay values and who set them, as Get-DOConfig reports them, and where its bytes came from.DoctorDO’s reading

Checklist

What to check in Intune before you assign Delivery Optimization to devices that Autopilot provisions.

Find every profile that sets a delay, in the settings catalog and the Delivery Optimization template, and note its assignments, filters and exclusions. Per-setting status shows conflicts.¹⁰
Check Group Policy too. On a provisioned device, Get-DOConfig -Verbose shows each value’s provider.¹⁴
Give devices being provisioned a foreground delay of 0 and a background delay of 0 or a low value.²⁰
Check the Delivery Optimization priority of every Win32 app the ESP waits for: background unless you changed it.²³
Keep the provisioning and steady-state profiles apart, each excluding the other’s devices, so no setting is set twice.⁹
With Connected Cache, use DOCacheHost rather than DHCP option 235 where a baseline disables LocalPolicyMerge, and keep the cache delay above the HTTP delay;¹⁶ short, for devices that may be provisioned off-site.DoctorDO’s reading
Let new devices reach the DO cloud service and each other during OOBE. See Firewall rules.
Test with a batch provisioned at the same time and watch the total ESP duration.²⁰

How Delivery Optimization works Group IDs Ports Coming from Configuration Manager Intune policies Recommendations

Microsoft documentation

References

1Set up the Enrollment Status Page (opens in a new tab)learn.microsoft.com/intune/device-enrollment/windows/setup-status-page
2Troubleshooting the Enrollment Status Page (opens in a new tab)learn.microsoft.com/troubleshoot/mem/intune/device-enrollment/understand-troubleshoot-esp
3Overview of Windows Autopilot device preparation (opens in a new tab)learn.microsoft.com/autopilot/device-preparation/overview
4Windows Autopilot device preparation: what’s new (opens in a new tab)learn.microsoft.com/autopilot/device-preparation/whats-new
5Enrollment time grouping in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/device-enrollment/setup-time-grouping
6Delivery Optimization settings in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/device-configuration/templates/configure-delivery-optimization-windows
7Delivery Optimization settings for Windows devices in Intune (opens in a new tab)learn.microsoft.com/intune/device-configuration/templates/ref-delivery-optimization-settings-windows
8Assign policies in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/device-configuration/assign-device-profile
9Common questions, answers, and scenarios with policies and profiles in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/device-configuration/troubleshoot-device-profiles
10Use the Intune settings catalog to configure settings (opens in a new tab)learn.microsoft.com/intune/device-configuration/settings-catalog/
11Manage endpoint security in Microsoft Intune (avoid policy conflicts) (opens in a new tab)learn.microsoft.com/intune/device-security/endpoint-security-policies
12Policy CSP - DeliveryOptimization (opens in a new tab)learn.microsoft.com/windows/client-management/mdm/policy-csp-deliveryoptimization
13Policy CSP - ControlPolicyConflict (opens in a new tab)learn.microsoft.com/windows/client-management/mdm/policy-csp-controlpolicyconflict
14Monitor Delivery Optimization (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-monitor
15Delivery Optimization reference (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-reference
16Configure Delivery Optimization for Windows (opens in a new tab)learn.microsoft.com/windows/deployment/do/delivery-optimization-configure
17What is Delivery Optimization? (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization
18How Delivery Optimization works (opens in a new tab)learn.microsoft.com/windows/deployment/do/delivery-optimization-workflow
19Delivery Optimization frequently asked questions (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-faq
20Microsoft Connected Cache for Enterprise and Education overview (plan for Windows Autopilot provisioning) (opens in a new tab)learn.microsoft.com/windows/deployment/do/mcc-ent-edu-overview
21Win32 app management in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/app-management/deployment/win32
22Add, assign, and monitor a Win32 app in Microsoft Intune (opens in a new tab)learn.microsoft.com/intune/app-management/deployment/add-win32
23win32LobAppDeliveryOptimizationPriority enum type (Microsoft Graph) (opens in a new tab)learn.microsoft.com/graph/api/resources/intune-apps-win32lobappdeliveryoptimizationpriority?view=graph-rest-1.0
24BG_JOB_PRIORITY enumeration (Delivery Optimization) (opens in a new tab)learn.microsoft.com/windows/win32/delivery_optimization/bg-job-priority-
25Delivery Optimization and Microsoft 365 Apps (opens in a new tab)learn.microsoft.com/microsoft-365-apps/updates/delivery-optimization
26Platforms, policies, and app types supported by assignment filters (opens in a new tab)learn.microsoft.com/intune/fundamentals/filters/ref-supported-workloads
27App and device properties, operators, and rule editing for assignment filters (opens in a new tab)learn.microsoft.com/intune/fundamentals/filters/ref-device-properties
28Create device groups for Windows Autopilot (opens in a new tab)learn.microsoft.com/autopilot/enrollment-autopilot
29Delivery Optimization settings (Intune for Education deployment tutorial) (opens in a new tab)learn.microsoft.com/intune/solutions/education/tutorial-school-deployment/ref-delivery-optimization-settings-windows
30Testing Delivery Optimization (opens in a new tab)learn.microsoft.com/windows/deployment/do/delivery-optimization-test