Feature updates keep your Windows environment up to date, but knowing how they’re deployed is key to avoiding delays. This blog breaks down what a feature update is, how to configure it in Intune, and what happens behind the scenes, from Intune to the WUfB-DS / Autopatch Service, and the Decision engine on the device itself.
Let’s start with a small introduction to Feature Updates first. (Trust me, things will get fun after the first paragraph)
What is a Feature Update?
A feature update is a significant upgrade to the Windows operating system, such as moving from version 23H2 to 24H2. Unlike regular quality updates, which focus on bug fixes and security patches, feature updates introduce new features, performance improvements, and enhanced security.
However, feature updates aren’t applied during the Windows Autopilot out-of-box experience (OOBE). Instead, they kick in after the first Windows Update scan post-provisioning, usually within a day. This brings us to a critical decision: how do we ensure these updates happen in a way that balances control and automation?
While it might seem tempting to use the “Upgrade Windows 10 devices to the latest Windows 11 release” setting for simplicity, relying on this option means relinquishing control over which Windows version is installed.
This lack of control can lead to potential risks for environments that need to maintain stability and compatibility, such as unplanned updates introducing compatibility issues with critical applications or configurations.
By configuring a separate Feature Update Policy, you can determine the exact Windows version devices should upgrade to. This approach offers:
Predictability: You can ensure all devices are on the same tested and validated version.
Phased Rollouts (Rings): It allows you to stagger updates, testing on a small group of devices before wider deployment.
Risk Mitigation: You can avoid introducing issues from untested newer versions.
Let me explain in more detail how a Feature Update Policy works, why it’s the better choice for maintaining control, and what happens when it’s configured. We’ll also look at how it integrates into the post-OOBE process to ensure devices are updated on your terms.
Configuring Feature Updates in Intune
Let’s create a Feature Update for Windows 10 and later policy. To do so, we only need to fill in some required settings.
As shown above, I made sure to:
I configured the feature update to be deployed as a required update and not as an optional update (which is also a possibility if you want your end users to do it themselves)
I configured the option to ensure the update will be deployed as soon as possible (I hate waiting)
When we configured the policy, we expected it to be sent to the device when it syncs with Intune, just like the regular Windows Update ring for Windows 10 and later settings, right? Or is something else happening after we created this policy?
High-Level Architecture
After creating the policy, this is what is going to happen in the background from a high-level flow:
- Define the Policy in Intune: Set the target version (e.g., 24H2) and assign it to your devices.
- Intune Registers the Device: Intune communicates with the Windows Update for Business Deployment Service (WUFB DS / Autopatch) via the Graph API.(It is all Autopatch these days)
- WUFB DS Registers with Microsoft Update: The service informs Microsoft Update that the client device needs the specified Windows version.
- Wait for the Next Update Scan: The next time the device performs a Windows Update scan (default interval is 22 hours), it fetches the update information from WUFB-DS / Autopatch.
As shown above, most of the work is done by Microsoft services themselves. Once the device is registered and configured in the WUfB-DS / Autopatch service, it should be able to scan and retrieve the feature update. Well, at least that’s the expected behavior. What if that isn’t working?
Windows Updates Feature Update Reports
As most of the work is done on the service side, it’s important always to check the Windows Feature Update Report to ensure the service knows about the device. One thing is for sure: the feature update will not be offered/pushed if the report doesn’t mention the device.
So, before you take your device apart and start troubleshooting why the feature update is not being offered, generate the Windows Feature Update Report first.
If your device is on the list and in the pending or offering state, you are good to go. If not, patience is key. In addition to the Feature Update report, you could also examine this registry key to determine if the device is enrolled into WUfbDS / Autopatch.
If the device doesn’t indicate that the EnrollmentType is FeatureUpdate and it’s missing from the Feature Update report, it’s essentially stuck in no man’s land. In some cases, recreating the Feature Update policy has resolved the issue. So, if the device isn’t showing up in the report, you have two options: wait or try recreating the Feature Update policy.
Once the device is on the feature update list but the feature update is still not being offered (not scanned yet), we must look closely at what’s happening on the device itself. To do so, we will start with some good old scheduled tasks.
The Role of Scheduled Tasks
When the device needs to contact the Microsoft Update service to find the latest Updates, it uses an old-school scheduled task to do this in the background. We can spot those scheduled tasks in the UpdateOrchestrator scheduled task folder.
Default Behavior
The scheduled scan task for Windows Update scans runs every 22 hours by default, with a randomized offset of +/- 4 hours to prevent server overload. This means scans typically occur every 18 to 26 hours. You can see for yourself if you open the task scheduled and just start pressing f5 to refresh as a maniac. When doing so, you will notice that the “next run time” changes constantly.
Triggering the Update Process
When the scheduled task is executed, it will:
Triggers usoclient (Update Session Orchestrator Client) with the StartScan parameter:
This command initiates a scan for updates.
It invokes the Update Manager, the core engine for managing updates.
Invokes mousocoreworker.exe:
This process ensures all conditions are met before proceeding with updates (e.g., active hours, power state, OOBE completion).
For example, updates won’t install if the device is in active hours or running on battery power. More on this later on.
Let’s zoom in to the brains of the Unified Update Stack and what happens when the usoclient start scan is kicked off.
The Update Manager: The Brain Behind Updates
The Windows device’s update manager is one of the most important parts of the Update stack. This manager coordinates all update-related actions and could be called the brain behind it all! Ow, wait… Microsoft thought the same thing.
Here are a few examples of what the Update Manager is responsible for:
Scans Update Providers: It checks registered providers like WUFB DS, WSUS, and Microsoft Update.
Merges and Prioritizes Updates: Consolidates updates from multiple sources and determines which ones take priority.
Performs Update Actions: Executes download, install, and commit actions for updates.
Contacts the Decision Engine: Evaluates conditions like active hours, safeguard holds, and OOBE status to decide if those actions are allowed (IsActionAllowed)
Schedules Work: Ensures updates are executed at optimal times.
The decision engine…. Would you care to hear more about that one? As it really attracted my attention when looking at the update manager.
The Decision Engine and Decision Table
The Decision Engine evaluates whether an update can proceed. It uses a Decision Table containing hundreds of rules to do this. It’s pretty big…. if you don’t believe me download this TXT file below. It contains the whole decision engine and all the rules that apply.
When looking at the decision JSON from the link above, this part corresponds to the start scan usoclient parameter.
Here are some decisions that are part of the Start Scan decision flow:
Active Hours:
· If the system is within active hours, updates are deferred.
If you want to be sure the Feature update gets applied, check the Active Hours you configured in your Windows Update rings!
First Use:
- Minutes since first use: < 120 (update deferred for new devices).
- OOBE Completion: Updates won’t proceed until OOBE is complete.
It won’t process until the OOBE Is Complete…. That deserves a story on its own. If you want to know more about this registry key, check out this blog post.
OOBE Complete: Why OOBECompleteTimestamp Delays Hotpatch
Power Conditions:
- System on AC power: false (updates deferred if running on battery).
- System battery saver enabled: true (updates deferred to save power).
The Flow
Words.. all those words. For the people who are more graphical minded. This is the corresponding flow of how it looks like when the Usoclient kicks in and tries to start scanning when the device is just enrolled.
It will show you how and which Decisions are made when the device initiates the scan to determine if and which feature update is available.
With all the scan requirements in place, let’s examine why the updates still can’t be deployed with the start scan requirements met.
Why the Feature Update is not getting deployed
Common reasons for feature updates not rolling out as expected:
Throttled:
As you have seen in the architecture in the flow above…. Throttling can be one of the issues when the start scan is in progress…
especially when your name is Rudy and you configured some not supported Windows Update Orchestrator settings to speed things up a bit.
Guess what happens… when a scan will be attempted each minute even when the device is not totally ready to receive the featureupdate? Throttling will sure to kick in.
Safeguard Holds: Compatibility blocks applied by Microsoft for known issues. And I guess with the latest Safeguard issue: USB devices that support eSCL scan protocol may not be discoverable. It is something to beware of.
If you have configured the Feature update deferral period, the feature update will not kick in immediately.
DCAT Rejection: Backend services determine the device isn’t ready for the update. Check the Windows feature update device readiness report. For example, my VM that is not liked by the service.
With all the issues discussed, we still need to discuss the Detection Frequency policy.
Detection Frequency
If we want to speed things up, this policy can be configured to ensure the Detection frequency is changed from the default 22 hours to a bit less.
*There is a random variant of 0-4 hours applied to the scan frequency, which cannot be configured.
After the first successful USOClient start scan, the “schedule scan” scheduled task will be changed from 22 hours to the number of hours you specified.
As shown above, the scan task will be repeated every 3 hours, but we still need to add the “random variant.” So, instead of the three perfect hours, we could get a bit more.
Bringing It All Together
The flow from Intune to the device:
- Policy Configuration: The admin sets the feature update policy in Intune.
- WUFB DS Processing: The backend evaluates and registers the device for the update.
- Scheduled Task Execution: The device runs usoclient.exe StartScan based on the 22-hour schedule. (which can be changed with the detection frequency after initial deployment of the device)
- Update Manager Checks: Conditions like active hours, safeguard holds, and power state are evaluated.
- Download and Install: If all conditions are met, the update proceeds.
Conclusion
Understanding the intricate flow of feature updates helps troubleshoot issues effectively. Whether it’s safeguard holds, delayed scans, or active hours blocking updates, this knowledge equips you to pinpoint the problem and resolve it efficiently. With this process in mind, you’ll be better prepared to manage updates in your Windows environment.