This blog will focus on how one simple Delivery Optimization Policy in Intune could mess up all of your Autopilot and Autopilot (AP-DP) enrollments.
Introduction
Some Autopilot Device Preparation (AP-DP) failures are easy to diagnose. A misconfigured application (detection rules), a firewall blocking network requests (or WNS being blocked), or a not responding DNS server could really break your enrollments. But what happens when everything seems fine, yet the deployment still refuses to finish successfully?
That was exactly the scenario we stumbled into. In this case, multiples devices that appeared to be properly configured somehow failed the Autopilot Device Preparation (AP-DP) enrollment. As shown below, the AP-DP enrollment showed us that it couldn’t complete the device setup.
There were no obvious failures or apparent network issues, yet the Windows Autopilot Device Preparation deployment refused to continue.
Identifying the Stalled App with AP-DP Monitor
To narrow down the issue, we used the Autopilot Device Preparation Monitor in Intune, which helps track where the AP-DP provisioning process gets stuck. The monitor quickly revealed that Microsoft 365 Apps for Enterprise (Office) was the application causing the delay and eventually Autopilot to fail.
Since the Microsoft 365 Apps was a required app, AP-DP would not finish successfully until it was installed. That gave us our first clue: something was preventing Office from completing its installation. I know the Office/MS365 CSP option is pretty well known to break apart during deployments, but my gut told me it was something else.
Examining Running Processes in the Task Manager
Before diving into logs, we checked Task Manager during the deployment to see what was happening with the Office installation.
Sure enough, the Click-to-Run (OfficeClickToRun.exe) setup was running, but it wasn’t doing anything else. The process appeared to be waiting for something before continuing. This suggested that the Office installer wasn’t completely failing; it was just stuck in a stalled state, unable to continue.
Is this going to be another Energy Saver issue, like we noticed some time ago, or again, something else??? At this point, network issues were still considered a potential cause. If the installer was unable to fetch the required files, it would sit idle, waiting for a retry. Not again DNS!!! ?
Checking CDN Access Before Analyzing Installation Logs
Since Office downloads its installation files from Microsoft’s Content Delivery Network (CDN), we needed to rule out any network-related issues. (if it’s not DNS, it’s probably DNS.). We first retrieved the exact CAB file download URL from the logs that are located in the C:\Windows\Temp folder.
Once we opened the logs, we started searching for the proper CDN URL:
This URL pointed to Microsoft’s Office CDN, so we manually tested it by attempting to download the file directly through a browser.
After entering the CDN URL in the browser, the CAB file was downloaded without any issues.
With the file being downloaded successfully without issues, it confirmed that:
· The CDN was somehow accessible.
· There were no DNS or firewall blocks.
· The network was not interfering with the installation.
With external network issues ruled out (well for 90%), we returned to the installation logs in the temp folder to investigate further.
Analyzing Installation Logs and the First Red Flag
After ensuring that network access / DNS wasn’t the problem, we continued checking the log files. The key errors we found mentioned: Failed to Delete Native OOBE Keys and
Besides the Native error we also spotted this error: Failed to delete WoW Oobe keys.
At first, I had the stupid idea that I was looking at an oobecompletetimestamp issue again, but when I scrolled down into the log file, I noticed something else.
As shown above, the next error showed me that the download failed due to fatal error: 0x80d02002.
This indicated that the Office Setup itself failed to retrieve its installation files and saw no progress within the defined period. Instead, something on the device itself was delaying the download request, causing the process to stall indefinitely. The funny thing? This error code refers to Delivery Optimization (DO)!
What Is Delivery Optimization?
Delivery Optimization (DO) is Windows’ built-in method for managing downloads by using peer-to-peer distribution. Instead of downloading content directly from Microsoft’s servers every time, devices on the same network can share files to reduce bandwidth usage.
If no peers are available, DO should fall back to downloading from the internet. However, this fallback behavior depends on policy settings. If configured incorrectly, the system may keep searching for peers instead of switching to HTTP immediately, which could cause application installation delays…. as seen in our AP-DP deployments.
Investigating Delivery Optimization as the Cause
Since the logs confirmed that Office was waiting for its download, and combining this with the DO error 0x80d02002, there was only one conclusion: Delivery Optimization (DO) seems to be interfering. If you are expecting delivery optimization to be the culprit, the best thing you can do is run the following PowerShell command: Get-DeliveryOptimizationStatus
As shown below, this was the result we got when running the Get-DeliveryOptimizationStatus command.
This DeliveryOptimization command confirmed our suspicion:
Priority: Foreground
BytesFromHttp = 0 (well that ain’t good)
NumPeers = 0 –> No peer-to-peer sources were available.!!
That meant the system was waiting for a peer-to-peer delivery that would never happen. Normally, if no peers are available, the system should fall back to a direct HTTP download.
But it didn’t switch to HTTP in a reasonable time; instead, it waited indefinitely (well, almost… after 60 minutes exactly, things started coming to life). To confirm the issue, we opened a browser and started checking the Intune Delivery Optimization Policy.
Checking the Intune Delivery Optimization Policy
We checked the Intune policy settings applied to the device. That’s when we found the problem.
The device had the following Delivery Optimization policies applied:
DO Delay Foreground Download from HTTP = 3600 seconds (1 hour)
DO Delay Background Download from HTTP = 3600 seconds (1 hour)
This was the hidden culprit. To be sure these settings were applied to the device, we also checked the policymanager\current\device\deliveryoptimization registry key on the device. As expected, we noticed the same foreground delivery optimization settings.
With this foreground setting configured to 3600 and Office being installed as a foreground application, it was required to wait up to an hour before switching from peer-to-peer to HTTP.
The default and recommended value is 60, NOT 3600! We can spot the same in the Delivery Optimization Settings documentation.
Let me explain a bit more about foreground and background downloads from HTTP.
How the MS365 Apps use Foreground and Background Delivery Optimization
Unlike background updates, where downloads happen gradually, some installation processes require immediate access to content. This is where Foreground and Background Delivery Optimization (DO) come into play. Understanding the differences between these two modes is important when deploying applications, specifically Microsoft 365 apps, during Autopilot.
Understanding Foreground vs. Background DO
Background DO (Low-Priority, Passive Downloads)
- Used for passive updates, such as Windows Update fetching patches in the background.
- The system downloads files only when resources allow, ensuring it doesn’t impact other tasks.
- Example:
(Think of downloading a game update while you’re working, it’s happening quietly in the background without slowing down your device.)
Foreground DO (High-Priority, Immediate Downloads)
- Used when a process needs content immediately, such as when an installation or update requires fast access to files.
- These downloads take priority over background tasks and must be completed as quickly as possible.
- Example:
(Think of clicking “Install Now” on an app, you want it immediately, so it downloads at full speed.)
Microsoft’s Known Issues with Foreground and Background DO
Luckily, Microsoft has documented specific Delivery Optimization settings that could impact the Microsoft 365 Apps installation:
Delay Background Download from HTTP – Controls how long the system waits before falling back to an internet download for background updates.
Delay Foreground Download from HTTP – This is a Similar setting, but it applies to user-initiated updates (Foreground DO).
Key issue:
If these values are set too high (e.g., 5 minutes), user-initiated Office updates can be delayed, as the system keeps searching for peer devices instead of downloading immediately.
How This Affects MS 365 Apps Installations
Now, let’s connect the dots.
- Microsoft 365 Apps installations during Autopilot rely on fast downloads, meaning they should use Foreground DO.
- If Delay Foreground Download from HTTP is misconfigured, an Office installation may wait unnecessarily instead of downloading immediately.
- Microsoft documentation confirms that this can delay installations by several minutes.
This explains why Office installations may sometimes take longer than expected. It’s not an issue with the MS 365 Apps themselves but rather how DO prioritizes and delays downloads.
When you encourage your users to use the Company Portal to install the Microsoft 365 apps instead, that one could also be stuck downloading or installing
If all of your apps are stuck on downloading or installing in the Company portal, you again need to check what Delivery Optimization is doing. In this case, the priority was set to background. Guess what happens if the Do Delay Background HTTP download is also set to 3600
Fixing the Delivery Optimization Policy
The solution was pretty easy, as we only needed to adjust the Delivery Optimization policies to allow HTTP fallback much sooner. We changed the values in Intune:
DO Delay Foreground Download from HTTP → 60 seconds
DO Delay Background Download from HTTP → 600 seconds
After redeploying the test device, the results were immediate. The Microsoft 365 Apps began downloading within a minute and were installed successfully. With the Ms365 now being installed successfully, AP-DP proceeded without issues.
Conclusion
This Autopilot issue highlighted how Delivery Optimization misconfigurations can silently break Autopilot deployments.
The MS 365 Apps weren’t failing due to network connectivity, DNS (Always DNS right?), or CSP misconfiguration, it was being delayed by a Delivery Optimization policy that forced it to wait too long before switching to HTTP downloads.
- Foreground downloads must switch to HTTP quickly if no peers exist. (60 Seconds)
- The AP-DP Monitor was crucial in identifying which app was failing.
- Log analysis (MS 365 App Install Log) confirmed that a single Intune policy was enough to block installation.
This wasn’t a regular Enrollment Status Page failure; it was an AP-DP issue that required understanding how the Ms365 Apps download interacted with the Delivery Optimization policies.