This week is all about controlling Windows 10 feature updates. A couple of months ago a new policy type was introduced to control Windows 10 feature updates. And even more recent, support for Windows Autopilot devices was added to that policy type. That latest addition was the trigger for this blog post. In this post I’ll start with a short introduction about the different options for controlling Windows 10 feature updates, followed by more details about the Windows 10 feature updates policy. I’ll end this post by looking at the configuration options.
Introducing the control options for Windows 10 feature updates
Now let’s with an introduction about the options to control Windows 10 feature updates by using Microsoft Intune. I’m deliberately naming it controlling – and not managing – as it’s more controlling the (pace of the) installation of Windows 10 feature updates. I see managing more as being in full control of the Windows 10 (feature) updates on a device. Via Microsoft Intune it’s possible to utilize Windows Update for Business to simplify the Windows 10 update management experience in general. Utilizing Windows Update for Business is focused more on controlling the Windows 10 updates cycle, instead of approving individual updates for (specific) devices. Controlling the Windows version and controlling the installation of the quality and security updates.
It’s also good to keep in mind that Microsoft Intune only stores the policy assignments and not the updates themselves. Windows 10 devices will access Windows Update directly for the updates itself. Within Microsoft Intune the following policy types are provided to control updates:
- Windows 10 update rings: The Windows 10 update rings policy is a collection of settings that configures setting to control when Windows 10 updates get installed. This policy type already exists for a while and enables administrators to create update rings that specify how and when Windows 10 devices should be updated with feature and quality updates. As long as the latest update is installed, the Windows 10 devices are up to date.
- Windows 10 feature updates: (Currently public preview) The Windows 10 feature updates policy brings devices to the specified Windows version and freezes the feature set on those devices until the administrator chooses to update them to a later Windows version. While the feature version remains static, devices can continue to install quality and security updates that are available for their feature version.
As the Windows 10 feature updates policy is a new feature, the remainder of this post will focus on that feature.
Introducing the Window 10 feature updates policy
A Windows 10 feature updates policy is a pretty simplistic policy – from a configuration perspective – to control the Windows 10 feature updates on a device. When a device receives a Windows 10 feature updates policy, the device will update to the Windows version that is configured in the policy. When a device is already running a later Windows version then the Windows version that is configured in the policy, that device remains on its current Windows version. The device will not downgrade to a previous Windows version.
During the period that the Windows 10 feature updates policy is assigned to the device, the device will basically freeze on the configured Windows version (unless – as previously mentioned – the device is already running a later Windows version). That also provides the administrator more flexibility for controlling the Windows version of the device. With a Windows 10 update rings policy the administrator was limited in controlling the timeframe that a device could stay on a specific Windows version. The administrator could defer the period when the device would install a new feature update with 365 days and then pause the update assignment for another 35 days, but that was it. The Windows 10 feature updates policy actually freezes the device to the configured Windows version until the administrator modifies or removes the assigned policy.
The assigned Windows 10 feature updates policy only controls the feature updates on the device. That means that while the installed Windows version is frozen, the device can still receive and install quality and security updates for their installed Windows version. These updates will apply for the duration of support for the installed Windows version.
Limitations for the Windows 10 feature updates policy
Before looking at the current prerequisites and the configuration steps of a Windows 10 feature updates policy, it’s good to be familiar with the current limitations of this policy type.
- When deploying a Windows 10 feature update policy to a device that also receives a Windows 10 update rings policy, the following configurations should be in place within the configured update ring:
- The Feature update deferral period (days) setting must be set to 0.
- The feature updates of the Windows 10 update rings policy must be running.
- A Windows 10 feature update policy cannot be applied during the Windows Autopilot process, instead the policy will apply at the first Windows Update scan after a device has finished provisioning (which is typically a day).
Also, keep in mind that this is still preview functionality. It might behave different than expected in some scenarios. At the time of writing this post I’ve seen scenarios in which this policy type might not work correctly when skipping a Windows version.
Prerequisites for the Windows 10 feature updates policy
When starting with the implementation of a Windows 10 feature updates policy, the following prerequisites must be met – at this moment – by the assigned devices to guarantee the described behavior.
- The device must be running Windows 10 version 1703 or later
- The device must be enrolled in Microsoft Intune and should be (hybrid) Azure AD joined
- The device must have telemetry turned on, with a minimum setting of Basic
Configuring the Windows 10 feature updates policy
The configuration of the Windows 10 feature updates feature is actually pretty straight forward and doesn’t require a lot of configuring. The following 5 steps walk through the configuration of the Windows 10 feature updates feature and all the available configuration options.
- Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows > Windows 10 feature updates to open the Windows – Windows 10 feature updates blade
- On the Windows – Windows 10 feature updates blade, click Create profile to open the Create feature update deployment wizard
- On the Deployment settings page, provide the following information and click Next
- Name: Provide a valid name for the Windows 10 feature updates deployment
- Description: (Optional) Provide a description for the Windows 10 feature updates deployment
- Feature update to deploy: Select the Windows 10 version that should stick on the devices (current options are Windows 10 1803, Windows 10 1809, Windows 10 1903 and Windows 10 1909)
- On the Assignments page, click Select groups to include to assign the Windows 10 feature update deployment to a group of devices and click Next
- On the Review + create page, review the configuration of the Windows 10 feature update deployment and click Create
Now let’s end this post by having a quick look at the administrator experience. Once the policy is assigned to the device, the device will check-in and install the Windows feature update according to the configured policy. The eventual result can be verified by navigating to Devices > Windows > Windows 10 feature updates > [CreatedWindows10FeatureUpdatesPolicy] > End user update status. That report provides an overview of the assigned devices and their (feature) update status (as shown below).
For more information about configuring updates in Microsoft Intune, refer to the documentation about Manage Windows 10 software updates in Intune.
65 thoughts on “Controlling Windows 10 feature updates”
If we are upgrading from windows 10 1903 to 1909 using ConfigMgr and the 1909 feature update is about 3.5GB….
I know the 3.5GB gets downloaded to site server and DPs but to the target device does the entire 3.5GB get downloaded or only whatever amount is needed for each device (obviously up to 3.5GB)?
For smaller downloads and faster installation times, you can look at express updates. Do keep in mind that it does require more storage space on the server-side.
Hi Peter, nice post. One thing I have noticed is that it does not seem to work that well with White Glove. If the WuFB policy is device targeted then the 0 days deferral is applied during White Glove device provisioning. Then when the user enrols the device through OOBE they receive an offer to upgrade to the next version of windows, this is true even if you have a Feature Update policy assigned to hold the device on the current OS version. Is this a scenario you have tested? Would be good to understand if you have seen the same thing :-).
No, I’m sorry, I haven’t tested that specific scenario, yet. Maybe somebody else can chime in with their experiences.
I already use update rings and features updates in our organization and I assure you that it works just as you mention in the post. Thanks!
What I would like to ask is whether you fully trust the report presented in End user update status.
I don’t feel safe in the number of devices, updated data and how to mitigate errors.
Do you advise using Power BI + Data Warehouse for a more detailed view?
That report definitely provides a quick overview of the current status. But indeed if you need more (detail) information you might want to look at using the data warehouse.
Hi Peter, Great article as always, it has been helpful!
I am just starting to use this now and I can see the update ring control works pretty well.
Do you know if this feature works with MDM managed Hybrid joined devices, as the pre-reqs are quite explicit in saying MDM managed and Azure AD Joined or registered.
That’s a good question, when literally following the documentation that’s not supported. To be sure you might want to double-check with Microsoft and/or test.
I tested this and can confirm that WUfB works with co-managed or hybrid joined device.
The only thing I notice is that the Feature Update report in the Report blade is not very accurate.
For devices that’s already received feature update, it still showing ‘in progress’ in the Update Aggregated State
I have tried to use this Windows Feature update but no matter what I do, device still pulls the latest Feature Update even after setting this to 1903.
How is it working for you Shimal? I have both Windows Update ring and Feature Update for the devices. I have set feature update deferral 0 in Windows ring and have assigned both Update ring and feature update policy to same group.
I have also configured the telemetry as required to full. Is there anything I need to turn on. The only thing I have noticed is that I do not see the feature update policy under the device configuration when on device but can see the Update ring policy though.
I’ve not had any major issues when I met the requirements and made the configurations. What type of devices are you trying to configure and what is the result of your policy?
Actually it‘s saying „ Devices must be enrolled in Intune MDM and be Hybrid AD joined, Azure AD joined, or Azure AD registered.“ https://docs.microsoft.com/de-de/mem/intune/protect/windows-update-for-business-configure#prerequisites-for-windows-10-feature-updates
But my real world experience is something else…. Everything is working fine as long as the clients are outside the LAN connected directly to the internet. When they come back into the company network they start to update the OS almost immediately. I already removed suspicous GPOs.
So i‘m not sure if that feature really works with hybrid AD joined scenarios.
Thank you for the updated information. That hybrid Azure AD joined devices are also supported, is recently added to the docs. Regarding your challenges, are you maybe deploying policies and/or updates via different channels on the internal LAN?
thank you for your answer! Actually we´re deploying our updates manually with SCCM and we are not deploying any policies concerning feature updates.
To restrict the internal clients accessing WU on their own we´re using the GPO setting “Turn off access to all Windows Updates features” in the System/Internet Communication Settings/Internet Connections Settings Folder. When I remove that setting for a machine connected to the internal network (even when everything worked fine for weeks from the outside) it starts updating the OS. I already set the MDMWinsOverGPO setting hoping to overwrite something coming from the domain without luck…
Could it be that those settings are conflicting?
Whatever i setup, windows 10 Enterprise 1803 keeps updating to 1909. I’ve set the preview to 1809 and 1903, but it keeps pulling the 1909 build as soon as we set the deferral to 0.
How come this does not work?
Can you provide some more details about the configurations (is it cloud only, do you have other WSUS-like configurations, etc.)?
Devices are enrolled in Autopilot\Intune with Windows update ring (deferral set to 0) and Windows update feature preview set to 1903. Telemetry setting on Basic. Installed 1803 out of the box. When Intune settings are applied we hit check for updates and then it will go straight to 1909.
I have the idea that the feature update policy is somehow not being applied… Is this supposed to be the TargetReleaseVersion policy?
I messed around with that in the registry and then suddenly it worked, but i cannot reproduce. Now it’s still not working, when i install a new test machine.
Is that also the case when not touching the device for a day (after initial enrollment)?
I’ve had some issues with this too after the 2004 release which is the first time I tried this method to use the Feature Updates (Preview) setting.
I think I may have found why mine did not work but waiting on confirmation I set everything up as per MS guidelines and it looks the same as the above article.
However all our previous Update rings are targeted at groups of users and that worked fine, I then used the same user groups for these Feature Update settings but it does not appear to have done anything and we have devices updating to 2004.
I found on another blog that these new Feature Update (Preview) settings need to be targeted directly at device groups not user groups. I’ve not had it confirmed my MS but their doc was not specific in it’s wording and as most of our config is targeting users we did the same for these settings too.
Not sure if anyone else has found this?
I’ve actually only tested this with a device group and also specifically mentioned the device group. The reason for using device groups was simple for me: even if it would be technically possible (not saying that it’s possible) to assign the policy to a user group, it might create unwanted behavior when a user signs in to the device of another user (or a shared device).
Yeah I’ve inherited a tenant where all the windows updates are pushed to users based on country groups they reside in and there are a lot of users.
I think I’m going to have to redesign how they are done to switch to device groups. Although not being able to exclude a group in these settings may make things a little difficult as I’d want our pilot users to be in a group of their own for early testing but they would be picked up by a dynamic group based on their country if I do it that way.
Sounds like a plan, JB. And yes, you’re correct that there are currently no options for excluding groups. Also, keep in mind that this is still preview functionality.
Hi All, we use intune and SCCM in our company in comanagement and these days we test a lot upgrading OS by intune. I can confirm we apply the Feature Update policy to computers, not users. I think this is not working with users and as Peter mentioned a user can connect to multiple devices, expecially the support team. Don’t know if it helps but it seems to work that way.
Thank you for letting us know, Fabrice!
Many thanks for your input guys I appreciate it. Now I have some more work to do 🙂
Hi All, I am still experimenting the feature upgrade policy and currently am searching for a way to identify on a specific computer if the ‘TargetReleaseVersion’ setting is in place, and also what is the value configured. I tried WMI classes, Registry, RSOP, Intune devicemanagement console and never found this info. Did you find something ?
I haven’t checked, but according to the docs it’s and ADMX-backed setting. That means that it should be available in WMI (via the MDM Bridge) and in the registry (via the ADMX).
I have some Windows 10 (1809/1703) devices that are enrolled but with some settings of the update ring showing as not applicable.
Deadline for feature updates: Not applicable
There’s a way to cleand this records on devices to get a new update ring configuration?
How troubleshoot this kind of issue?
Could it be Windows version related? If I’m not mistaken the deadline for feature updates setting is made available for Windows 10 version 1709 and later (see also: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-configuredeadlineforfeatureupdates).
We had been experiencing something similar to Mark’s experience where a newly provisioned device into AAD and Intune/MEM will try to update to current (2004) instead of our desired build (1909). One possible issue is that Feature Updates can only be scheduled to a group, not to ‘All Devices’ and it will take some processing time for a new computer to show into any group.
What we have done to work around this is applied the Feature Update to a created group (or groups) which constitute all computers. In Update Rings, we apply the same Feature Deferral of 0 to that group. To catch the new pre-processed machines, we have a separate Update Ring set to a 365 day Feature Deferral set to All Devices which excludes the group which has the Feature Update deployed.
Before we implemented this, we’d have dozens of reimaged or newly joined computers wanting to break our feature lock each day. Since implementing it about a month ago, I haven’t gotten a report of a single failed update – news only as good as the reporting people give me, but still…
Thank you for sharing your experience, Jeremy!
I had this exact same thing happen and used the exact same workaround. So far, so good.
(the idea of a feature update policy is GREAT, as long as the newly minted machines know they are to get it)
Peter – do you know where intune sets this on the client? It’s not in PolicyManager\Current\Device\Update where I would have expected it (using the Update/TargetReleaseVersion CSP). It’s also not setting it in the GPO key:
Any ideas? My hunch is that it is an admx policy as I see an “AdmxInstalled” reg key but it’s empty. So it’s kinda weird and doesn’t act like a normal admx backed CSP.
Lmk your thoughts.
Could it be that those devices were deployed via for example ConfigMgr and received those settings earlier?
@peter – No, it’s clean AAD joined system managed by intune. No co-management.
My apologies, I initially misread your question. Have you checked the registry below Software\Microsoft\PolicyManager?
I heard that there is no policy applied to device.
What happends is that device is registered to special Windows update channel that only offers the selected feature update version from Windows update.
I found this info posted to intune training guys video. Check from 20:00 Where they talk about this.
Link to video here:
Thanks for the link. Useful nugget of info there 🙂
Regarding question how to verify whether this is applied to client the response is that you can’t 😛
I found info that when you enable this feature:
1) There are no policies configured on the client
2) Intune registers client to specific update channel in Microsoft update
3) Microsoft update controls what version is offered to client in that channel
I found this info from “Intune Training” channel in youtube. It was on the “Using Intune to Manage Windows 10 Feature Updates – Enterprise Feature Update Management” -video.
Thank you for the information, Jussi!
I have below queried regards to Windows patch upgrade , System is enrolled to MS Intune.
• Once patch updates in system, first notification will come as soon as patch updated. How frequently they get notifications before it goes to force restart.
• How force restart time calculates? For example my patch updated on 1st oct and as per the policy I need to restart my machine within 3 days, however I have not restart machine till 3rd Oct afternoon and I have opened laptop on say 6th Oct 2020, will it consider 4 hours(Remind user prior to required auto-restart with dismissible reminder) once I logged in on 6th Oct or as soon as I logged in to system on 6th oct will it restart immediately(as force restart time crossed)
• Notification which prompt for restart, consider if i set a time frame for reboot then does logs gets created for this, if it’s created on which path this logs get saved.
• Does any logs get created for forced time changes, if yes what is the path where this logs gets save.
Infrastructure is not co-managed it’s completely Intune.
Controlling Windows 10 features updates functionality will not help you with that. As shown throughout this post, that functionality is mainly focussed on controlling the Windows 10 feature update that a device is running and basically sticking that version on the device. A Windows 10 update ring will be more close to what you’re looking for.
I have been looking at this and seeing the following errors. This is on all devices in scope. The environment is co-managed SCCM/Intune, with Hybrid Azure joined devices, auto-enrolment configured with GPO and SCCM
Device Registration Invalid Global Device Id
Device is not able to register or authenticate properly with the Deployment Service due to having an invalid Global Device ID.
If an update ring is applied to the device this works successfully.
Any suggestions on why this is reported and the policy is not arriving?
I assume you switched the Windows Update Policies workload already to Intune. If so, there shouldn’t be a requirement for an update ring to be applied to the device. When you do see that behavior, I would advise to log a ticket with Intune support.
When does this policy actually take place? I have a feature lock at 1909 but yet a brand new autopilot machine whether at 1909 or 2004 still upgrades to 20H2.
The feature update policy applies at the first Windows Update scan after a device has finished provisioning, which is typically a day.
If using Feature Update Rings for over a year, but started with 1909. When it is time to move to new Feature, from 1909 -> 2004, is it best to edit/change existing ring or create new Ring and remove Groups from old one?
I think that mainly depends on how you’re planning on upgrading to the latest feature update. All at once, or in smaller groups.
Could you tell me the expected behaviour if a device is left in an update ring that deploys a feature update. I created an update ring to deploy feature update 21H1 on 31/05/2021 and it deployed successfully, the machine was still left in the update ring with the policy applied and tried to install the same feature update (21H1) on 03/06/2021 and 04/06/2021 both times the install failed. can you tell me the expected behaviour for feature and quality updates that are applied for a second tim to a machine after successful install?
That should not be a problem according to the documented behavior here: https://docs.microsoft.com/en-us/mem/intune/protect/windows-10-feature-updates
We seem to have a problem with the trigger of the updates. The wuauserv is set to “Manual (trigger start)”
On a lot of devices no updates are installed. If I start the service manually the updates are downloaded and installed. What could be the problem here? Some device in the same update ring do get updates.
Are you saying that no updates are installing, or are you saying that the latest feature update is not installing?
Starting the service manually does not seem to be the solution either. We’ve got a lot of devices that don’t update. No ‘normal’ updates and no feature updates. Sometimes we have to support users and then it turns out that there are still a lot of updates waiting to be downloaded and installed.
Some other devices in the same updatering (like my own laptop), do receive the udates without any user interaction. This really puzzles us. Is there a way to see some logs of this process?
Update: information on log files is here: https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-logs
I’m going to study this first.
Good to hear that you already found the logs Paul!
It seems that updates are working now. We have been working on getting rid of some conflicts between configuration profiles. Sometime there are too many places where you can make settings that are more or less the same.
What we changed/fixed are the telemetry settings. besides that we also added a deadline in our update ring.
Thank you for the update Paul!
This is very interesting thread, my organization has a very peculiar thing happening. Some background first:
Co-managed environment with WuFB delivering all updates and Feature updates capped to 21H1
Have functioning deployment rings etc…
The feature updates worked perfectly and our initial fleet of 1909 pc’s were upgraded to the 21H1 capped feature as per the policy.
But recently we discovered that around 60+ machines have magically upgraded to 21H2!
I have checked the policies and compliance, the Feature updates for 21H1 have been applied to the ‘All users’ – with exclusions for any pilot rings etc…
The affected machines are not recently imaged or new hardware models but a mixed bag of old and newer hardware types and models. Our default MECM image is still 1909 -we don’t use Autopilot exclusively for the moment.
I see no rhyme or reason why machines seems to spontaneously upgrade to 21H2!!??
In that case I would start by looking if the device is registered with the Windows Update for Business deployment service.
Not sure what you mean by that exactly, the machines are co-managed Azure AD hybrid joined, the workloads are successfully managed by Intune/MEM – the Update rings and feature updates policies appear in place and are applying successfully. The initial 21H1 feature updates cap worked perfectly for many months… then suddenly it doesn’t…
As you said earlier in this post, its not so much ‘managed’ but ‘controlled’.. but it seems this ‘preview’ feature has gotten out of control…
Have a look at my latest post for some context: https://www.petervanderwoude.nl/post/getting-started-with-the-windows-update-for-business-deployment-service/