In this blog, we will explore how Microsoft is reintroducing Quality updates installation during OOBE, this time with more control for IT admins. We’ll also explore how update deferrals work, what’s changing with Autopilot and AP-DP, and the technical flow behind it.
Quality Updates During OOBE
Last year (2024), Microsoft introduced a feature that forced quality updates after Autopilot enrollment during OOBE (Read the full deep dive here). The goal was simple: ensure devices were fully patched before first use. However, this approach quickly became a headache for IT admins because the Autopilot Enrollment took 20 minutes longer than expected, and there was no setting to turn it off or even configure it. The feedback was loud and clear: Microsoft needed a better approach.
In response, Microsoft rolled back the enforcement of these updates. But instead of abandoning the idea entirely, they returned to the drawing board. Now, Microsoft is reintroducing quality updates during OOBE, but this time, it will have more flexibility.
Previously, Autopilot (AP-DP)-enrolled devices had no choice but to install updates before reaching the desktop, leading to frustration. With this new method, organizations can now defer updates by configuring some settings in the Autopilot / AP-DP profile. This will give IT admins greater control over the process.
So, how does this new approach actually work under the hood? Microsoft has integrated update controls into Windows Autopilot and Autopilot Device Preparation (AP-DP) settings, ensuring updates happen on your terms while keeping devices secure. Let’s take a closer look.
Tracing the Discovery of EnableExpeditedUpdateDeferred
When we want to know more about what’s happening during the OOBE, we need to start looking at the msoobeplugin.dll
Why? Because that msoobeplugin.dll file held the first real clue that Microsoft was changing its approach. As I showed you in the previous blog post about this new update experience, the CommitExpeditionChoice function was responsible for setting registry values related to expedited updates.
As shown below, this function ensured that the enableexpeditedupdate registry key was set the moment the device received the NDUP Properties/Metadata from the Secure Data Exchange Services (SDX.Microsoft.com)
However, something had changed in newer builds. This function wasn’t just setting EnableExpeditedUpdate anymore; it was also configuring EnableExpeditedUpdateDeferred registry key now.
Enable Expedited Update Deferred…. That sounds exactly like what Microsoft announced, right? To defer the quality updates during OOBE.
This raised an immediate question: What determines whether EnableExpeditedUpdateDeferred gets set? If Microsoft had introduced a new deferral mechanism, we needed to understand the logic behind it.
Enrollment Status Page Controlling the Deferral?
At first, we considered whether this behavior was tied to the Enrollment Status Page (ESP). It seemed logical that a new function would be introduced within the ESP. (for Autopilot v1, as AP-DP doesn’t rely on the ESP)
This new setting looks like it could be the InstallQualityUpdates setting from the Windows10EnrollmentCompletionPageConfiguration, that was added two years ago. This setting suggested some control over update installation during OOBE.
Shall we examine if that could be the case? Looking at how Microsoft reintroduced the feature, it really does sound like it.
So, we zoomed into this idea first.
EnrollmentStatusTracking DDF file
We started this journey by Reviewing the EnrollmentStatusTracking DDF file, which can be found in the system32\ddfs folder.
We dug into the actual DDF file, stored on the device, which defines ESP policies. The InstallQualityUpdates (Install Quality Updates) was indeed present.
InstallQualityUpdates: According to its description:
“This node configures whether quality updates are installed during OOBE. If set to true, required policies are synced during the device setup phase of ESP, and an additional page is shown during OOBE to install the appropriate quality updates based on the synced policy settings. If set to false, Quality Update installation during OOBE is skipped.”
That sounds exactly like the policy we’re looking for… but there’s a catch. This applies only to Autopilot v1. After examining the DDF file, I moved over to the Intune Portal. Why? It seems that you can spot many funny things while browsing that page!
Inspecting the Intune Portal with Dev Tools (F12)
With the DDF examined, we started to monitor the network traffic and which JS it touched while configuring ESP settings in the Intune portal.
The results? InstallQualityUpdates was indeed mentioned: installQualityUpdatesToggle: “Install Windows quality updates (might restart the device) (preview)”
This corresponds to the DDF file we spotted before, but it does not mention or show how updates were deferred when configuring this setting. To be sure Autopilot wasn’t in control, I took another dive into the Autopilot Profile.
What About Autopilot Profiles?
I wanted to rule out if it was a real Autopilot setting or something that controlled something in the background. To do so, we investigated whether this quality update setting was stored directly within the Autopilot profile on the device. Looking at ExtractApiResult::GetAutopilotProfile, which retrieves Autopilot data from the device, we checked if the quality update setting was part of the profile.
- The retrieved values included standard fields like DeploymentProfileName, CloudAssignedTenantId, and ZtdRegistrationId.
- No reference to a quality update setting or deferral mechanism was found.
- With the Quality Update setting also being introduced in Autopilot V2, it strongly suggests that this will be an Intune policy rather than a static setting stored on the device.
If the setting isn’t stored directly in the profile, this means the switch in the Autopilot profile likely just tells the WUfB service what to do, much like how Microsoft previously enabled EnableExpeditedUpdate on the fly by pushing new NdupProperties.
Quality Updates During OOBE: How Defer works.
With ESP’s exact role in question, we turned our attention to how Windows retrieves update behavior in OOBE. The key to understanding this turned out to be Secure Data Exchange Service and how it relies on the NdupProperties to know what to do.
The process works as follows:
- During enrollment, the device queries the SDX and retrieves the Metadata/ NdupProperties. This contains update-related policies that dictate how the device should proceed.
- Windows checks the EnableExpeditedUpdate registry key.
- If EnableExpeditedUpdate = 1, the system starts the Windows Update scan.
- If EnableExpeditedUpdate = 0, updates are skipped entirely.
- The update scan is initiated by shellappruntime.exe, which triggers the ExpeditedUpdateStartUSOScan.
- After scanning, Windows checks EnableExpeditedUpdateDeferred.
- If EnableExpeditedUpdateDeferred = 1, updates are skipped.
- If EnableExpeditedUpdateDeferred = 0, updates proceed.
This means that the decision to defer or apply updates isn’t actively made by ESP, it happens dynamically based on what is returns in the NdupProperties. However, Microsoft has clarified that future configurations will be available through Autopilot settings.
Where We Found This in the Code
1. shellappruntime.exe Handles the Update Scan
- Reads EnableExpeditedUpdate to determine if updates should be applied.
- Triggers Windows Update scan (ExpeditedUpdateStartUSOScan) in MoUsoCoreWorker.exe.
- I assume that after scanning, it retrieves the EnableExpeditedUpdateDeferred policy in the same way the device talks with Autopatch to determine if it is targeted for Feature Updates.
One thing is for sure: If EnableExpeditedUpdateDeferred = 1, updates will be skipped. If EnableExpeditedUpdateDeferred = 0, updates proceed.
Besides the shellappruntime, it was obvious that the expeditedupdate.js that we looked at before was also showing, some key information.
2. CloudExperienceHost.ExpeditedUpdate.js Confirms Policy Application
- Retrieves NdupProperties from the service
- Logs whether updates should be expedited or deferred.
- Handles CommitExpeditionChoiceForDeferred, which ultimately sets EnableExpeditedUpdateDeferred.
Besides spotting the NDUP properties in the expediteupdate.js, the CloudExperienceHostAPI.winmd showed me pretty much the same story.
Mock-Up of Expected Autopilot Settings
Since Microsoft has already stated the fact that Autopilot and Autopilot DP profiles will allow administrators to control quality update behavior during OOBE, we’ve created a mock-up of what this might look like in the Intune portal.
- We’ve adjusted screenshots of Autopilot profile settings to include a potential “Defer Quality Updates” toggle.
And we did the same thing for AP-DP.
Even when those two settings could change the behavior of how quality updates will be triggered during the OOBE, it seems those two toggles scream out to a different service, telling it what to do and what to set up when the device checks in. If those toggles are set yo Yes, the new Update Experience screen will show up during OOBE.
Final Confirmation: NdupProperties Dictates Everything
- The decision to apply or defer updates is entirely based on what WUfB sends in NdupProperties.
- ESP does not actively control update deferral; it configures the background settings that WUfB retrieves, as we noticed with feature updates.
What’s Next?
Microsoft has confirmed that this change will roll out in mid-2025, meaning the setting is not yet in production. With it, the whole flow above could change…. But then again, this process sounds pretty logical. Stay tuned for further deep dives as we continue monitoring how the delivery of quality updates during OOBE proceeds.
Interested in TPM deep dive? Feel free to dive into what happens with Attestation on Windows 24h2!
