Managing software updates has gotten easier since cumulative updates were introduced starting with Windows 7. With Windows 10, feature and quality updates are cumulative—they contain the contents of all previously released updates for your Windows version. Windows 10 cumulative updates contain security patches, new Windows drivers, and quality fixes. So now all we need to do is ensure that our devices have the latest update, not just certain individual updates included in the roll-up, installed. Microsoft Intune uses Windows 10 Update Rings to get this job done.
Update rings are used to get your managed Windows 10 devices up to date—and keep them that way. They’re used to manage Windows Update for Business (WUfB) settings on Windows 10 computers. That’s it. Nothing is being approved or downloaded. There’s no other magic Intune is doing to provide granular control over which updates get installed.
That being said, there are still quite a few WUfB settings that you can control to tailor the update experience for your users. These range from the servicing channel to target the device with, optional updates, Windows drivers (not non-Microsoft drivers), deferral periods, and even feature uninstall periods that allow your users to reclaim disk space consumed backup files kept when applying a feature update.
There’s more to it than what I’ve shown here including setting active times to install updates, restart checks, user experience settings, and deadlines. Going beyond the update ring settings, you can manage the actual update ring itself. You can delete a ring, pause it to ensure devices stop installing updates for whatever reason, extend that pause indefinitely, or even uninstall the latest round of updates installed by update ring settings.
It’s really a simplified experience from how we’ve managed software updates on-premises in the past. Just let WUfB do all the heavy lifting while you manage the update (quality and/or feature) rollout strategy by assigning the appropriate polices to the appropriate devices via update rings. Again, no individual updates are selected, managed, or downloaded by Intune. You set the update policies and managed devices go to Windows Update to do your bidding.
Windows as a Service. Pretty cool.
You can read more about it in the docs at Windows update settings for Intune.
Update Ring Reporting
In the MEM admin center portal, you can quickly get the deployment status for all update rings for all devices and users from the Devices | Overview page. Scroll all the way over to the right on the top menu bar and you’ll see Software update status. Click that and you’ll be presented by an overview of all things software update rings. Here, you’ll get the bird’s eye view of how your update rings are progressing. How many devices have succeeded, errored, failed, or are pending. It’s an overview for all your devices on any update ring. If you want to get a little deeper, you can check on individual device status for a particular update ring. You can do that under Devices -> Monitor-> Per update ring deployment status-> <update ring>:
From there, you can dig deeper into the device or user status to see how things are going when applying a software update ring policy. If that’s all you need to know, then you’re done. If you’re left with questions like, which individual update is installed on which devices?, how many devices need to reboot to finish installing an update?, or how is my feature update rollout going?, then you’re speaking Update Compliance’s language.
Update Compliance
Update Compliance is a free Azure service that allows you to monitor Windows 10 update rollouts based on what WUfB is hearing from the Windows telemetry being sent by your devices. It’s another cross-service integration that runs in parallel to everything you’re doing with Intune. Intune doesn’t manage Update Compliance, but you do need to tell your devices to talk to it and that’s where Intune comes in.
Before going further, make sure that the devices you want to monitor meet the Update Compliance prerequisites!
Get Update Compliance
To get started using Update Compliance, you’re going to need to add it to your Azure subscription. It’s available in the Azure Marketplace and easy to set up. Just click GET IT NOW, log in with your Azure subscription (if prompted), and then just go with the flow as the service is added to your subscription.
You’ll need to create or select a Log Analytics Workspace to store your device update telemetry data. Again, straightforward to do following the prompts as the solution is created. If you’re already using Desktop Analytics or Azure Update Services, the choice is even easier as it’s recommended to use one of those workspaces for Update Compliance as well. So, create the workspace or choose the one that works for you. Click Create and wait for the Azure notification that an Update Compliance solution has been successfully created.
You are not charged for update data stored or accessed from Update Compliance workspaces.
While you’re in the Azure portal, go to the Log Analytics Workspace you just selected or created (Azure -> Log Analytics workspaces-> <your workspace>). Under General on the left-side, select Solutions and then click on WaaSUpdateInsights (<your workspace name>). Once there, select Update Compliance Settings under Settings. Now, grab that Commercial Id Key, you’re going to need that:
A CommercialID is a globally-unique identifier for your specific Update Compliance Log Analytics workspace. It’s how devices tell WuFB they belong to your organization, where to send update-related telemetry data, and it’s the first thing we’ll configure on managed devices using Intune.
Now Update Compliance is set up, but nothing is talking to it and its lonely. Let’s do something about that.
Configure and Enroll Devices
With CommercialID in hand, you’re ready to go to the MEM admin center portal and start putting your keyboard to work making a custom OMA-URI device configuration profile to enable Update Compliance settings. You’re going to need a total of four custom policy settings to configure devices to play nice with Update Compliance:
- Provider/MS DM Server/CommercialID. This identifies the device as one of yours when it talks to WUfB. See the option to Regenerate the ID Key in that screen shot above? If you do that, you’ll basically wipe all update compliance data for your organization, and you’ll have to redeploy the CommercialID setting to all your devices to start over from scratch.
- System/AllowTelemetry. What level of diagnostics data do you want to send to Microsoft?
- System/ConfigureTelemetryOptInSettingsUx. This policy setting prevents users from changing the telemetry level you just set with the above policy (Update Compliance requires a minimum level of Basic).
- System/AllowDeviceNameInDiagnosticData. This setting tells devices it’s OK to send their computer name along with their telemetry. You’re after device-level data, so it makes sense you’d need to know the device name. At least it does to me.
Yes, there is an Update Compliance Configuration Script available if you want to use GPOs to configure these settings. There’s no requirement to use Intune to do this “manually”, but it’s how I do it and considering you’ve stuck with me so far, I’m going to guess that’s what you want to do too.
Head over to the MEM admin center and create the device configuration profile: MEM admin center > Devices > Configuration profiles > + Create Profile. Select Windows 10 and later as the platform and Custom as the profile type. Give the profile a nice name and description and then click Next to get to the good stuff on the Configuration settings tab. Click Add to start adding rows of custom policy settings. You’ll need to add four rows with each containing information for: name, description, a case-sensitive OMA-URI path (watch out for trailing spaces!), a data type, and of course, the value you want to set. Add those rows like so (I’ll leave the names and descriptions up to you):
Commercial ID
|
OMA-URI path |
./Vendor/MSFT/DMClient/Provider/MS DM Server/CommercialID |
|
Data type |
String |
|
Value |
<Your commercial ID> |
Telemetry
|
OMA-URI path |
./Vendor/MSFT/Policy/Config/System/AllowTelemetry |
|
Data type |
Integer |
|
Value |
1 |
Enforce telemetry settings
|
OMA-URI path |
./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx |
|
Data type |
Integer |
|
Value |
1 |
Allow device name in telemetry
|
OMA-URI path |
./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData |
|
Data type |
Integer |
|
Value |
1 |
If you’re curious about what’s going on here, go read my earlier blog post about how to create custom OMA-URI policies.
Deploy the device configuration profile to your Windows 10 devices and then keep an eye on the configuration profile overview screen to be sure the policy gets applied successfully. You should also now see something like this as you peruse individual device status’.
One more verification step to be sure that your devices got the update compliance memo is to look for your Commercial ID in the Windows registry:
Update Compliance in Action
Now that you’ve set up Update Compliance and used Intune to configure your Windows 10 devices to send compliance data to the log analytics workspace, the exciting part begins. Go to the Update Compliance workspace summary at Azure portal > Log Analytics workspaces > <Your workspace> and then click Workspace summary under General.
AAAaand there’s nothing. The workspace is still lonely. &$%#.
Everything is OK, but this part is going to require some patience. Remember that all the update compliance data we’re going to see here is based on Windows telemetry being sent up to WUfB. It could take a few days before you get a complete picture of what’s going on in your organization. Eventually, you’ll start to see some meaningful information as your devices report telemetry and your workspace summary updates.
Select your workspace summary and Tada! here comes the update compliance data in one large, horizontally scrolling page. From left to right, here’s what you’ll see starting with the overview section (yes, I know my lab is a mess):
At first glance, you can now see how many devices are reporting telemetry and whether they’re running Windows Insider builds or not. Update status for both security updates and feature updates and the ability to drill-down further into several other interesting areas. There’s also some nice guidance on devices with issues and what to do about it.
In the middle, you’ll see a break-down of devices that need attention. Pretty handy that the information you’re probably most interested in is put front and center. From here you can start to investigate any of your organization’s device or update issues:
In addition to the data displayed in this section, you can also download the Setup Diagnostic Tool. That tool is handy if you need to troubleshoot why a Windows 10 upgrade was unsuccessful. Kind of out of scope for this blog post, but figured I’d let you know.
By selecting a row of data, you can drill-down into the update compliance data for more information. For example, let’s click on Failed under Update issues above so we can see what’s going on. A Log Analytics query opens and there’s the data you’re looking for. Looks like we had four Windows 10, 2004 devices fail to install KB4566782 (the cumulative monthly roll-up for August 2020) due to lack of disk space:
Sometimes there’s a lot more going on behind the scenes than the default reports show you. That DeploymentError column isn’t there by default. To see it, just click on Columns and select it. I also moved the ReleaseName column over a few spaces so it’d be in the screen shot.
Finally, all the way to the right is a great list of example queries to run against the Update Compliance data stored in your Log Analytics workspace. I talked a little bit about how this works in Using Log Analytics with Intune, but if you’re even slightly familiar with Kusto Query Language (KQL), you’ll be able to deep dive into your data within a few minutes.
Go ahead, click around and see the kinds of data that’s now at your fingertips. You can even create custom queries and workbooks to save in your workspace. Maybe a custom report for each of the monthly update roll-ups by Windows 10 version or specific feature update rollout tracking. Data is your friend here and you get more to work with from Update Compliance than you get by default with Intune’s Update Ring monitoring.
Go forth and use this information wisely to make informed decisions and manage your Windows as a Service rollout strategy—both for monthly quality and feature updates.
The Best of Both Worlds
There’s a lot of data in Update Compliance, but maybe you personally only care about a few specific reporting points. Something simple like my earlier example of a report that shows which devices are missing this month’s update roll-up. You can easily create workbooks like that in the Log Analytics workspace, and you can also create them from within the MEM admin center portal.
Go to MEM admin center > Reports > Workbooks and create a new workbook. Change the source Log Analytics workspace to the one you’re using for Update Compliance and query away.
Save the report and it’ll always be there for you right in the MEM admin center.
I’d recommend maybe making some nice, high-level reports like tracking monthly roll-ups and then use the Update Compliance workspace for going deeper into the data, but you can also always run those queries straight from Log analytics in the Report node too.
The queries don’t have to be anything fancy, here’s the one I’m using the August 2020 Update Rollup workbook above:
WaaSDeploymentStatus
| where ReleaseName contains “4566782” and isnotempty(Computer)
| summarize dcount(ComputerID) by DeploymentStatus
| render columnchart
I’m using that workbook query as an example, but the data for the current and previous update roll-up information is already detailed out for you in the Security Update Status reporting available to you by default in the Update Compliance workspace. The point is: update compliance data is now only ever a KQL query away and you can save your reports where it makes the most sense for you.
And that’s how you get detailed, device-level update compliance data with Intune.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
