Deploying Windows 10/11 feature updates with Microsoft Intune is much simpler than traditional methods. You no longer have to “push” out the full patch or ISO content via ConfigMgr or WSUS or worry about content distribution. But ever wondered how it actually works though? While it may seem like a simple thing on the surface, there is actually a lot going on behind the scenes. Today we are going to dig in and explore how this all works.
Table of Contents
- Prerequisites
- Stay or Upgrade
- Introducing the Windows Update Deployment Service
- Reporting
- Common Issues
- Additional Reading
- Summary
Prerequisites
There are a few prereqs in order for this to work in your environment.
This technology actually leverages a service called the Windows Update for Business Deployment Service (WUFB DS). You therefore must be licensed to use it. These are the licenses that currently support WUFB DS:
- 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 Virtual Desktop Access E3 or E5
- Microsoft 365 Business Premium
On the client side, you’ll need to ensure the following:
- Be running a “supported” version of Windows 10/11
- Be Intune enrolled either as Hybrid Joined or Azure AD Joined
- A Telemetry value of “Required” or higher. You can create and deploy this via a “Device Restrictions” profile.
- The Microsoft Account Sign-In Assistant service, wlidsvc, must be running and not disabled or blocked.
- Running Pro, Enterprise, or Education SKUs of Windows. LTSC/LTSB is not supported.
- The proper Windows Health Monitoring settings are enabled and deployed to devices.
There are a few other limitations and workflow considerations especially if you are in a co-management state so I highly recommend you read the full MS article.
Stay or Upgrade
So what exactly does this feature do? It allows you to do two primary things:
- Tell clients to “stay” on the Windows version you specify
- Tell clients to “upgrade” to the Windows version you specify, if it’s not already on it
Additionally, deploying one of these to devices enables additional reporting to the Intune console.
You get to this area in the Intune console by going to Devices > Windows > Feature updates for Windows 10 and later (preview).
Then you create a profile with the Windows 10 or 11 feature upgrade version you want.
You can also pick different deployment options to suit your needs
After this, you can then assign it to your assignments groups. But after you click the “Create” button and this goes out, what actually happens?
Introducing the Windows Update Deployment Service
When I was first getting into managing feature updates via modern management, I learned about the “TargetReleaseVersion” CSP. I even wrote a whole blog on how to use it while working with VMware Workspace ONE. This CSP was released alongside the Windows 10 2004 version which launched in June 2020. It keeps a client at or upgrades them to the version you specify. This is set in the registry where all of the other Windows Update for Business CSPs are stored.
But when I first deployed the Intune version of feature upgrades, I couldn’t find anything set on the client. There were no registry keys and nothing showing under the assigned policy when looking at the MDM-managed policies on the client. Strange. I then checked for updates and immediately the client would grab the feature upgrade. I had my suspicions though and I reached out to the Microsoft PMs to confirm. And sure enough, they (along with Mattias Melkersen) did confirm that yes this does actually leverage the Windows Update for Business Service. You can read the full Twitter thread here:
So here’s how it works:
- When you deploy a feature upgrade policy to a device, Intune is actually registering that device into the WUFB DS behind the scenes.
- WUFB DS then tells Microsoft Update that this client needs the specified version of Windows (i.e. Windows 10 22H2).
- Up to this point, all communication has been all server to server and nothing on the client. The next time the client runs its Windows Update scan (default time of 22 hours), it will talk to Windows Update which then consults the WUFB DS first to see if the device is registered with it. And if it is, it will get the Windows feature version information from that and either upgrade or stay on the assigned version.
Since this is all handled primarily on the server side, you don’t have to wait for any client policy to be synced down and applied to the device. Almost immediately after you deploy the profile, the device is registered in WUFB DS and so the next time you check for updates on the client it sees the update. Pretty cool!
Here is a very high-level overview of what this looks like:
And then a more detailed diagram of the flow:
So this service essentially makes Windows Updates programmable via Graph API. The IT admin or services such as Intune can leverage this API for their own orchestration purposes. This also enables Intune to do the various rollout options like immediate deployment, gradual rollouts or made available on a specified date.
And this “Feature Update” feature isn’t the only thing in Intune to take advantage of the WUFB DS. The node right below it, “Quality updates for Windows 10 and later (preview)”, also uses the WUFB DS.
Reporting
There are a few ways to check the status of the feature update deployment of each device.
The first is to verify that the profile is assigned and that the Windows OS version is still supported. You want to see two green check marks. Also, verify that the feature version you select is in fact the correct one. With both Windows 11 and Windows 10 having the same version number (i.e. 22H2), it can be easy to pick the wrong one.
Next, you need to use the built-in reports in Intune as these query WUFB DS directly. You can get there by going to Reports > Windows Updates (preview) and either refreshing the main Summary tab or by clicking on the Reports tab and then on the Windows Feature Update Report.
If you don’t see any data, try to wait a few minutes and try again. If you still don’t see any data after some time, then you may not have the proper telemetry or Windows health monitoring settings configured. Enabling Windows Health monitoring is very easy. If you have Endpoint Analytics, simply edit the already-deployed Intune data collection policy configuration profile, and add Windows Updates to it.
If you don’t have Endpoint Analytics, create a new device configuration profile with those same settings. Select Windows 10 and later, Templates, and Windows Health Monitoring.
After deploying to your devices, you can view the overall counts on the Summary tab.
To get individual device statuses, click on the Reports tab and then the Windows Feature Update Report. Select the Feature Update profile and click Generate.
Microsoft also just released the new Windows Update for Business reporting experience which provides a ton of useful data all in one place. Check out more details on this here.
Common Issues
I’ve seen a few common things if people have issues with getting this working.
Verify Specify Version and Assignments
I know this may sound obvious but first double-check your assignments. In fact, in the process of writing this blog and creating the demo for the screenshots, I misconfigured the profile without realizing it. I meant to upgrade my Windows 11 21H1 device to Windows 11 22H2 but accidentally configured the profile to be Windows 10 22H2. Oddly enough, the Windows Feature Upgrade report actually showed the deployment being successful even though it definitely was still on Windows 11 21H2. This may just be a bug in the report.
In addition to verifying the correct profile configuration, also verify that your device is properly added to your azure AD group. Azure AD can have multiple devices with the same name, especially with hybrid AAD devices, so double-check that your device is actually in the group.
Safeguard Holds
Safeguard holds are hidden, under-the-hood “blockers” that prevent your device from upgrading. These are managed and maintained by Microsoft and primarily come from the consumer side. They get data from billions of devices on how well devices do after upgrading and so if they get back data saying a particular software or driver is causing poor performance, they will flag it as a safeguard hold to prevent other devices from having the same issues.
This is great in that it improves user experience, but bad in that it is difficult to find out what these are Several members of the community have built scripts and tools to help identify these so definitely check out these resources to learn more:
Adam Gross has a PowerShell module that can help identify blocks. https://github.com/AdamGrossTX/FU.WhyAmIBlocked
Additional Reading
There is more to cover on this topic including how to leverage Graph API yourself to directly assign and deploy things with the Windows Update for Business Service.
The Windows Update Policies you should set and why – by Aria Carley
The New Windows Update for Business Reports – by Akash_Malhotra
Try Windows Update for Business with Microsoft Graph – by Angie Chen
Commercial driver and firmware servicing with the Windows Update for Business deployment service
Summary
The Windows Update for Business Deployment Service is an awesome piece of technology that can greatly simplify deploying feature upgrades and other updates to Intune-managed devices. We covered how Intune registers devices into the WUFB DS on your behalf and how this is all done server-side. This foundational technology is going to continue to be utilized by and expanded upon by Intune in the months and years to come.
