Introduction
Managing Windows Feature Updates via Intune and Windows Update for Business (WUfB) should be straightforward….at least, in theory. We configured a Feature Updates Policy to ensure all existing (not newly enrolled) Windows 11 23H2 devices were going to be upgraded to 24H2, but something unexpected happened.
At first, everything looked fine. The policy was applied, most devices were successfully upgraded to Windows 24h2, and the Windows Feature update reporting in Intune reflected the expected rollout. But then, after a couple of days, We noticed that one particular stubborn device still had not upgraded, while every other targeted device had. Weird!
It’s time for some deep troubleshooting.
1. Setting Up the Windows Feature Update Policy in Intune
We deployed a Feature Update Policy in Intune to ensure that all 23H2 devices would be upgraded to Windows 11 24H2.
Feature Update Policy Settings:
- Windows 11, version 24H2 (targeted deployment).
- Applicable devices: All devices running Windows 11 23H2.
- Deadline settings: These are applied for automatic update and restart scheduling.
- Update deferral: None (immediate rollout).
2. The Device Missing from Windows Feature Updates Reporting
Somehow, the device refused to play ball and did not accept the Windows feature Update policy at all. Since the problem device was online, I installed Fiddler, started Procmon, and pressed the “search for updates” button. After a few seconds, the device returned empty-handed and showed me it had received no updates.
Let’s dive in and examine what Fiddler and Procmon showed me! The moment the device starts searching for updates, it reaches out to the service (delivery.mp.microsoft.com)
While communicating with the service, the device will hand over some important device attributes. We can spot this flow in the DLLs. As shown below, the getDeviceAttributes will fetch all the required attributes from the device.
The same thing can be seen in the Windows update log, which can be generated with the get-windowsupdatelog PowerShell command.
If we format this list of attributes we noticed in the Windows Update log, it showed me some useful information:
As shown above, DSS_ENROLLED=QualityUpdate. That’s weird. Where does the Mousocoreworker get this information from? Luckily, I had procmon open and running, and within the same seconds the device reached out to the service, I noticed it checked the ctac.json in the system32 folder.
This JSON above showed me, which key I must inspect to find the WUfB-DS Enrollment Status.
Checked: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWufbDS
enrollmenttype, it should mention: QualityUpdate, FeatureUpdate… But it only showed me the QualityUpdate. The whole FeatureUpdate category was missing!
Was the device not enrolled with WUfB DSS? By the looks of it, it wasn’t. I wasn’t expecting that.
3. Digging Deeper: The Device Was Stuck “Enrolling” in Graph
Luckily, my Patch My PC colleague Bryan Dam delivered a wonderful presentation about Graph and Windows Feature Update and WUfB-DS in the past. So with that information, I knew where to start poking.
I opened the Graph Explorer and started querying the Graph API to determine the enrollment state. First, I needed to fetch the device ID. After I got the device ID, I fired off a GET request.
Graph API Query: https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/{device_id}
As shown above, the response showed me: “feature”: {“enrollmentState”: “enrolling”}. Does this mean the device was still getting enrolled for the feature updates? When doing the same on devices that were successfully upgraded to Windows 24h2 using the Feature Update policy, it showed me that they were “Enrolled” instead of “enrolling”
4. Fixing the Issue: Unenrolling and Re-Enrolling the Device
With the device being stuck enrolling, I decided to try to unenroll the device first from WUfB-DS… maybe it works…, or maybe it won’t.
Step 1: Unenroll from Windows Feature Update with the Graph API
To unenroll the device for the Windows Feature Updates update category, I performed a POST to this Graph URI
https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/unenrollAssets
{
“updateCategory”: “feature”,
“assets”: [
{
“@odata.type”: “#microsoft.graph.windowsUpdates.azureADDevice”,
“id”: “76ba670e-ee34-4d32-b8ab-f24283802953”
}
]
}
To be sure it was unenrolled, I performed the same step as I did first to determine the enrollment state again.
As shown above, it still showed me the Enrolling state. Was it still being unenrolled? (or I just didn’t have any patience!)
Step 2: Delete the device from WUfB – DS
With me, not having the patience those things require, I decided just to delete the device and enroll it again from WUfB-DS management. I did so by sending a delete command to DELETE the whole device from the WUfB-DS service. https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/76ba670e-ee34-4d32-b8ab-f24283802953
After the device was successfully deleted, I again performed a GET request to make sure it was gone.
Well, one thing was for sure… the device was no longer enrolled. With the device not being enrolled anymore, I decided to get myself a cup of coffee before re-enrollment (patience is key)
Step 3: Re-Enroll the Device
With the device no longer enrolled, I did a similar graph call, but now I have made sure I am going to add the device again.
https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/enrollassets
{
“updateCategory”: “feature”,
“assets”: [
{
“@odata.type”: “#microsoft.graph.windowsUpdates.azureADDevice”,
“id”: “76ba670e-ee34-4d32-b8ab-f24283802953”
}
]
}
After I enrolled the device again to the WUfB DS service, I decided to be patient and start doing something else. The next morning, I wondered if the status had changed.
Whoop!! The enrollment state has now changed from enrolling to enrolled! With the device now being enrolled, I switched back to the device
5. Success! Windows 11 24H2 Installed
I logged into the problem device and opened Windows Update. When opening Windows Update, I immediately spotted the 24h2 being installed and waiting for a pending restart (luckily, with Hotpatch, reboots would be a bit less)
6. Key Takeaways
- If a device doesn’t appear in Feature Update reporting, check Graph API.
- Verify the WUfB-DS Registry Keys.
- Check if your device has a valid device token
- If a device is stuck, unenroll and re-enroll it via Graph API.
- Be patient! WUfB DS sometimes needs more time to think about it.
- Sometimes, recreating the Windows Feature update policy and assigning it to the device group again helps.
7. Conclusion
This troubleshooting experience highlights an important lesson: just because a device is online and checking for updates doesn’t mean it’s properly enrolled in Windows Update for Business DS Service. If you ever find yourself with a device missing from feature update reporting, follow these steps to resolve the issue.