Microsoft Feature Updates (FU) is one of those things I always get called upon by customers to help with. The reason why you might decide to use FU is because it gives you more granular control than the standard out-of-the-box Intune ring updates. Although it seems really easy to use, there are a few recurrent ‘gotchas’ that if missed could prevent an update from happening, getting you in an undesired state of patching (or lack thereof). This article looks at addressing the most common mis-configurations, tricks and catch-22s that I’ve seen, and straightforward ways to overcome them.

1 Licensing Feature Updates

Unlike popular belief, Feature Updates is not part of Microsoft Intune’s license, but a component of WUFB DS (Windows Update for Business Deployment Service). WUFB DS has its own licensing requirements, but on bright side the you can use it regardless of whether you use Intune or not.. According to its official page, to run WUFB DS you require at least:

• Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5)
• Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5)
• Windows 10/11 Virtual Desktop Access (VDA) per user
• Microsoft 365 Business Premium

If you want to check if your tenant is licensed, you can do it by clicking on the button below and authenticating with your tenant credentials.

After running the query, look for the following entry and check if provisioningStatus is equal to Success:

                {
                    "servicePlanId": "7bf960f6-2cd9-443a-8046-5dbff9558365",
                    "servicePlanName": "WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE",
                    "provisioningStatus": "Success",
                    "appliesTo": "User"
                }

In case you get the below error click Modify permissions and consent accordingly (Work with Graph Explorer).

2 Assigning Feature Updates Policies

When you assign an Intune Update ring, you can do so for groups of users or groups of devices. If assigned to a group of users, any user login into the device will override any previous settings with its own, independent of the device being shared or not. That means you can assign Ring Update policies to groups of Users.

Since the WUFB DS is based on AAD Object IDs, deploying policies to a group of users might work for devices with primary users, but it does not for shared devices. Personally, I had issues with a customer where FU to Windows 11 was deployed to a group containing All Company Users, but after some time we noticed that around 200 devices were not moving to Windows 11. Those devices were later identified as Shared devices (where no primary user is assigned), that happened because the same translation user /device that works for Ring Updates does not for Feature Updates.

So, when using Feature Updates, I recommend you only target groups of devices.

3 New Feature Updates requires manual interaction

This is probably my biggest beef with Feature Updates. You don’t have a wildcard Latest option for feature (or operating systems) updates. Let’s say you have all your devices grouped correctly and assignments in place for those groups. Whenever Windows 10 or 11 (23H2) is released next year, your devices will not move to that version unless you create a new Feature Update policy or change your existing one to target that version. On Update rings, since you are only adding a deferral to install (PSA: you should if you are not), once that deferral elapses, all the devices will migrate to the latest feature Update available without further interaction required.

The image below depicts how I’ve been ensuring feature upgrades automatically for our customers over time without having to change the policies once since we started managing their tenant.

4 Operating System upgrades block unsupported devices from updating

If you decide all your devices should go to Windows 11 and deploy a feature update, all the devices that can’t go to Windows 11 (due to incompatibility) will not be offered any newer feature updates on their current OS and will lock in the current version which they are running.

Solution: find the unsupported devices, group them, exclude them from the W11 and then deploy specific W10 new feature updates to whichever version you want to target.

5 Hydration for new devices does not occur automatically

If you are planning to keep using FU to manage features, bear in mind that the first time you deploy a new feature update (or Expedite Quality Update) it might take a day or more, so all the infrastructure is configured and the WUFB DS service is ready to start managing your devices.

For automation junkies like me, you can easily use the enrollment API to automate the hydration of new devices.

6 Feature Updates does not ignore feature deferrals on rings

Microsoft advises that if you are managing feature updates via WUFB DS you should remove all feature deferrals from your Rings, so they will not impact the deployments.

It is interesting to note that if you are using Expedite (Quality) Updates, the policy ignores and overrides any quality update deferral periods for the update version you deploy.

7 90 days waiting period

If you decide, for some reason, that you do not want to use WUFB DS anymore and want to remove all the assignments for your devices, be aware that all registered devices have a cool-down period of 90 days. That period was planned so that when you unassign an old policy and assign a new one the device won’t receive an unwanted feature update.

Another option to avoid this would be to unenroll devices directly via Graph by clicking the button below and replacing the String (identifier) field with the Azure AD Device ID of the objects you want to unenroll.

Thanks for reading.