Monitoring Windows Updates with Update Compliance and Microsoft Intune
If you’re reading this blog post, it’s quite likely you’re familiar with Windows Update for Business. For those that aren’t familiar with it, the best way I can explain it is that Windows Update for Business (WUfB) is a bit of a mix between Windows Update and WSUS however one key thing that is possible with WSUS which is not possible with WUfB is the ability to approve/decline individual updates.
With WUfB your devices connect to Windows Update to retrieve updates however as an admin, you can control some aspects of what is downloaded which is where the ‘for Business’ bit comes in. With WUfB you can control the following items in the form of a ‘ring’ where you specify the settings and devices which are subject to those settings. You can use this to have numerous different rings across an organisation to allow testing of update compatibility:
The servicing channel the device is on:
Semi-Annual Channel
Windows Insider - Fast
Windows Insider - Slow
Windows Insider - Release Preview
Allow/block driver updates via Windows Update
Specify the deferral period for quality and feature updates
Set the feature update uninstall period (2 - 60 days)
User Experience Settings
Active Hours Start/End
Restart Checks
Allow/Prevent users from pausing updates
Allow/Prevent users from manually checking for updates
Auto-restart reminder notification intervals
Deadline settings
The main benefit that this brings is that there is no requirement to build and maintain a WSUS server, nor the requirement for end-user devices to be connected to a VPN in order to download those updates.
So that all sounds great, right? Well it is, however if you have a requirement to view any specific details, that’s kinda where WUfB falls short. In the Microsoft Endpoint Manager portal, you can see a per-device update status as shown below but that’s about it.
What if you want to see a bit more detail on why that device failed? Or let’s say Microsoft have released an update which fixes a specific issue that your organisation has been experiencing and you want to be able to report on devices that do/do not have that update.
That’s where Update Compliance comes into the picture.
Update Compliance
Update Compliance is free. It’s a solution which sits on top of a Log Analytics Workspace in Azure. At a high level, this works by using Intune or Group Policy to configure the Windows telemetry level to ‘Full’ and then configuring the device with the Log Analytics Workspace ‘CommercialID’. This ID is a unique value for your Log Analytics Workspace and tells the device to send it’s telemetry settings to that workspace.
Note that you will need an Azure subscription for this but you are not charged for ingestion and storage of Update Compliance data.
Make sense? Cool, let’s get it going.
Creating the Update Compliance Workspace
First, go ahead and create a Log Analytics Workspace then navigate to it.
On the Overview blade, press “View solutions”. You’ll be taken to a blank page. Press "+ Add”
Search for “Update Compliance” and press “Create”
Select the Log Analytics Workspace to use and press “Create”
After it’s created, navigate to the solution and you’ll see a message stating “Performing assessment”
Configuring devices to send data to Update Compliance
You’ll need to first grab the CommercialID from the solution. Navigate to the solution and then go to the “Update Compliance Settings” blade. Make a note of the CommercialID or keep the tab open as we’ll need that ID shortly.
In the Microsoft Endpoint Manager portal, create a new device configuration profile for Windows 10 and later devices. The profile type should be Custom. We’re going to be creating 4 OMA-URI policies.
CommerciallID - This is what’s used to tell your devices to communicate with your Update Compliance workspace.
AllowTelemertry - Configures the telemetry settings on the device (Full/Basic)
ConfigureTelemetryOptInSettingsUx - This policy will prevent users from modifying the telemetry settings.
AllowDeviceNameInDiagnosticsData - This tells Windows that it’s OK to send the name of the device to the workspace. You’d want this for your reporting, otherwise it will just be a list of GUIDs.
Now we’ll create the following OMA-URI policies
Commercial ID
OMA-URI Path:
./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID
Data Type:
String
Value:
Your CommercialID
Telemetry
OMA-URI Path:
./Vendor/MSFT/Policy/Config/System/AllowTelemetry
Data Type:
Integer
Value:
1
Telemetry Opt In Settings Ux
OMA-URI Path:
./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx
Data Type:
Integer
Value:
1
Allow device name to be sent in the telemetry
OMA-URI Path:
./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData
Data Type:
Integer
Value:
1
Now we’ll go ahead and confirm the settings have been applied on the device. In this example, I’ve deployed a Windows 10 1909 VM using Windows AutoPilot, with an ISO that was last updated in June, so that should provide good data in Update Compliance.
Once you’ve confirmed the settings have applied, you’ll probably go straight to Update Compliance and see…………
Nothing.
Don’t worry, that’s expected. It can take a while to process and update. When I say a while, I mean up to 72 hours so sit tight and check back on it in a bit.
Once the data has been sent to Log Analytics and has been analysed, you’ll then see a number of built-in dashboards as well as a number of built-in queries which you can use.
One quite handy query is the query to find devices where SafeGuard Hold is currently in place. SafeGuard Hold is designed to prevent devices which have known issues with the newest feature updates from being updated to that feature update until the issue is resolved and the hold can be removed.
From there on, what you do with that data is then up to you. Hopefully this post has been informative! Feel free to leave a comment if you have any questions.