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: Your Windows Update is In Progress.
Windows quality updates during the out-of-box experience
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 were required 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 Windows quality updates during the OOBE
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, which 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 in on 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 a similar 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.
I hope we will get the same setting for AP-DP. So i guess this is how it would look like.
Even when those two settings could change the behavior of how quality updates will be triggered during the OOBE, it seems those two toggles communicate with a different service, telling it what to do and what to set up when the device checks in. If those toggles are set to Yes, the new Update Experience screen will show up during OOBE.
And now, Microsoft has officially confirmed it.
Well, it turns out our mock-up in the previous paragraph was pretty accurate (except for the AP-DP Part). Microsoft has now officially confirmed in the message center that starting with the September 2025 Windows security update, quality updates will be installed by default during OOBE for devices running Windows 11, version 22H2 or later.
In the August (2508) Intune service release, a new Install Windows updates setting will appear in the Enrollment Status Page (ESP) profile to control this behavior:
- Set to “Yes” → Updates will be delivered during OOBE.
- Set to “No” → Updates will be skipped during OOBE.
If update rings are assigned, their settings will also apply, and the quality updates page will appear after ESP completes.
Important: Devices enrolling with Windows Autopilot Device Preparation or with ESP disabled cannot block updates; they will always receive the latest published security updates during OOBE. So I guess our mockup of that one was a bit of 😉
Microsoft’s preparation guidance:
- In the ESP profile, set Install Windows updates to “Yes” or “No” to control update behavior during OOBE.
- (Recommended) Use or create an update rings policy to manage pause/deferral settings for quality updates. Updates installed during OOBE will follow this policy.
- Assign the ESP profile and update rings policy to “All devices” or the relevant Autopilot-registered device groups.
What’s Next?
Microsoft has confirmed that this change will roll out in September 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.
If you want to know more, read our other blog at Patch My PC as well!
https://patchmypc.com/blog/quality-updates-out-of-box-experience-autopilot
