Controlling Windows 10 feature updates

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.
  • 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 Azure AD joined or Azure AD registered.
  • 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.

  1. 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
  2. On the Windows – Windows 10 feature updates blade, click Create profile to open the Create feature update deployment wizard
  3. 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)
  1. 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
  2. On the Review + create page, review the configuration of the Windows 10 feature update deployment and click Create

Administrator experience

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).

More information

For more information about configuring updates in Microsoft Intune, refer to the documentation about Manage Windows 10 software updates in Intune.

40 thoughts on “Controlling Windows 10 feature updates”

  1. Hi there,

    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)?

    Thank you

  2. 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 :-).

  3. Hi William,
    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.
    Regards, Peter

  4. Hi Peter,
    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?

    Thank you,

  5. Hi Sidnei,
    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.
    Regards, Peter

  6. 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.

    Thanks
    Shimal

  7. Hi Shimal,
    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.
    Regards, Peter

  8. Hi Shimal/Peter,

    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.

  9. 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.

  10. Hi Axel,
    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?
    Regards, Peter

  11. Hi Amrit,
    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?
    Regards, Peter

  12. Hi Peter,
    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…
    Best regards,
    Axel

  13. 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?

  14. 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?

    https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-targetreleaseversion

    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.

  15. Hi
    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?

  16. Hi JB,
    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).
    Regards, Peter

  17. 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.

  18. 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.

  19. 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.
    Regards,Peter

  20. 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 ?
    Regards, Fabrice.

  21. Hi Fabrice,
    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).
    Regards, Peter

  22. Hi Peter,
    I have some Windows 10 (1809/1703) devices that are enrolled but with some settings of the update ring showing as not applicable.
    Ex:
    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?

    Thank you!

  23. 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…

  24. 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:
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

    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.

  25. Hi,

    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:
    https://youtu.be/DRI2OkJQJO4

  26. Hi,

    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.

    Br Jussi

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.