ConfigMgr: Manage Driver updates through Intune without moving WU Workload in Co-Management Scenario

January 21, 2024

As I was reading through Ben’s post on SCCM Co-management – Dual Scan and Scan Source Demystified, where he has discussed in detail about Dual Scan and Scan Source, I recollected numerous asks from customers to split the Windows Update workload in to sub workloads for feature, quality, drivers and others. While Windows Update for Business (WUfB) provides seamless update management, lack of native reporting in Intune, ability to slice the data based on Entra Id groups, troubleshooting and DO were top callouts that needs improvement.

Upcoming Windows Update Distribution Report:

We are building a new Windows Update Distribution Report in Intune that we demo’ed in recent technical take off which provides a comprehensive view on devices that are on each quality update level and % coverage for each update across the devices per feature version managed by Intune (including co-managed devices). This will be GA by end of Q1 2024.

The report further provides drill down for each quality update that aggregates devices based on windows 10/11 feature version and the update statuses.
The admins can get the list of devices that aggregate to the numbers shown in the previous two reports which they can export and use it for troubleshooting and analysis.
No additional configuration needed. and not dependent on telemetry services.
Reports for Intune managed and co-managed devices, irrespective of Windows Update workload.
Based on OS version updated at every device check-in.
Ability to slice the data based on device scope tags.

Further I have written a post on enriching WUfB Log Analytics Reports with Intune Data and filter based on Scope tags.

With these two, most customers should be able to move the Windows Update workload to Intune.

Driver Updates through Intune

For customers who still lean on ConfigMgr for Windows Update management, managing driver updates in CM through driver packaging is cumbersome. In such scenario where you want to manage only driver updates through Intune, without moving the Windows Update workload, you can leverage the Specify source for specific classes of Windows Updates policy settings to set the source of driver updates as Windows Updates (keeping other configurations out of scope for this post)

But the challenge is the local policies are tightly coupled with ConfigMgr settings, if the device is ConfigMgr only managed or co-managed. In Co-Management scenario, the Windows Update workload determines policy settings for feature, quality, driver and other updates source. For a given device, if the Windows Update workload is managed by CM, the source for all updates types are set to WSUS (registry values are set to 1 which means the updates are obtained through WSUS). If the Windows Update workload is moved to Intune, the source for all update types are set to Windows Update (registry values are changed to 0 which means the updates are now obtained through Windows Updates).

Everytime ConfigMgr software updates scan cycle runs, it resets the scan source and corresponding registry values according to the Windows Update workload authority for that device.

To overcome this, if the device is Hybrid Entra Id Joined, you can leverage Domain Group Policy Settings as domain GPO overrides local policies managed by ConfigMgr. The same has been documented in our Driver Management FAQ.

If the device is Entra Id Joined, setting these policies using Configuration Profiles ends up in indetermisistic state as Windows Update related settings are still governed by the Windows Update workload authority. You cannot use Configuration Profiles (Settings Catalog CSPs) from Intune as well as the settings are tightly couple with the Windows Update workload authority. In my testing the CSP settings from Intune were never applied until I moved the Windows Update workload to Intune. Hence, the workaround is to leverage PS Scripts in Intune proactive remediation to check if the desired update type source is set to Windows Update and if not, set it to Windows Update.

While ConfigMgr Software Update Scan cycle will still revert the settings to WSUS, there is no impact, if you do not have corresponding update type policies in ConfigMgr. On next run, proactive remediation script will set it back to Windows Update. This is safe for driver management as you generally do not manage drivers through WSUS. But using similar workaround for feature or quality might end up in incosistant update behaviour and hence I would strongly recommend not to rely on this for managing feature or quality updates from Intune, without the workload movement.
Also remember to create Update Policies in Intune and target to the devices in scope. Else, the device might get random updates from Windows Update.

Script

Please test with subset of devices, before targeting all devices. Also leverage only for driver updates.

Sample detection script:

Try{
$Value = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate").SetPolicyDrivenUpdateSourceForDriverUpdates
	If ($Value -ne 0) {
		echo "Exit 1"
	}
	Else {
		echo "Exit 0"
	}
}
Catch {
	echo "Exit 1"
}

Sample remediation script:

Function Set-RegistryKeyValue{
	param (
		$KeyPath,
		$ValueName,
		$Value,	
		$PropertyType,
		$LogFile
	)
	Try {
		If (!(Test-path $KeyPath)) {
			$Path = ($KeyPath.Split(':'))[1].TrimStart("\")
			([Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$env:COMPUTERNAME)).CreateSubKey($Path)
			New-ItemProperty -path $KeyPath -name $ValueName -value $Value -PropertyType $PropertyType -Force | Out-Null
		}
		Else {
			New-ItemProperty -path $KeyPath -name $ValueName -value $Value -PropertyType $PropertyType -Force | Out-Null
		}
	}
	Catch {
		$ExceptionMessage = $($PSItem.ToString()) -replace [Environment]::NewLine,"";
	}
}

Set-RegistryKeyValue -KeyPath "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -ValueName "SetPolicyDrivenUpdateSourceForDriverUpdates" -Value "0" -PropertyType "DWord"
Set-RegistryKeyValue -KeyPath "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -ValueName "UseUpdateClassPolicySource" -Value "1" -PropertyType "DWord"