This blog post will highlight some of the concepts around co-management, recap on what it actually is and detail how the Windows Update workload is affected by Dual Scan and the newer Scan Source policy.
We won’t go into how you can enable co-management or setup co-management, but you can view a great guide here https://learn.microsoft.com/en-us/mem/configmgr/comanage/how-to-enable
We will also spend some time looking at how you can still deliver 3rd-party patching from Configuration Manager whilst making use of the benefits of controlling Microsoft Updates from Intune. This is especially attractive if you want a super granular transition for managing your all your patching from Microsoft Intune.
As a supplemental guide to fully understanding what co-management is, we recommend viewing this webinar Co-Management Moving Workloads to Intune Webinar – March 2023 – YouTube
Accompanying Deck https://patchmypc.com/wp-content/uploads/2023/03/2023-03-01-Co-management-Webinar.pptx
Note: The Table of Contents can be found in the right side bar of this post when viewed from a desktop or at the top of the post when viewed from a mobile/tablet.
What is co-management?
Co-management is a feature that attaches Microsoft Configuration Manager clients to the Microsoft cloud. “Moving to the Cloud” means different things to each of us. Quite often our journey to the cloud is complex. There is no magic button that shifts everything from on-premises to the cloud and then mystically the operational bill is cut in half. Often the path is much more complex with multiple twists, decision making junctures and stepping stones that disappear into the bog of eternal stench with one wrong move.
The Kool-Aid was served back-in-the-day when co-management was sold as one of the primary ways to move to the cloud. Co-management was never designed as a “lift and shift” feature when it was first released with Configuration Manager 1710.
Quite simply put, co-management allowed admins to start orchestrating their move to Microsoft Intune by allowing them to move specific workloads at a time from one management agent (SCCM Client) to another (Windows MDM). Both agents are “aware” of the other so the orchestration works pretty well. It would only allow settings to be applied from one management agent – thus avoiding policy conflict from the two different MDM platforms.
Co-management only works between the Configuration Manager client and the Windows MDM agent. To caveat that statement, the Intune Management Extension is also co-management aware, so technically there are 3 agents at play.
Workloads
Workloads is a concept that allows us to move individual “workloads” from Configuration Manager to Intune. You can find the co-management settings in the Configuration Manager console under the Administration > Cloud Services > Cloud Attach node and on the Workloads tab.
What are the workloads we can move? The options have changed much over recent years, today we have the following:-
- Compliance Policies
- Device Configuration
Resource Access Policies(no longer supported in Configuration Manager)- Endpoint Protection
- Client Apps
- Office Click-2-Run Apps
- Windows Update Policies
Microsoft has a great doc explaining what moving each of the these workloads means, we won’t duplicate that information in this post. Go check out Co-management workloads – Configuration Manager | Microsoft Learn
The great thing about workloads is that you can move them, individually, at a pace that suits you and your adoption of Microsoft Intune.
3rd-party updates workload?
It is important to note that when you move the workload for Windows Update Policies to Intune, you are only moving the workload for Microsoft 1st-party updates. When the Windows Update policy is moved to Intune, 3rd-party updates still come from Configuration Manager. 3rd-party updates are normally built as Win32 apps in Intune. In order to target updates to devices from Intune, as Win32 apps, you must set the Client Apps workload to either Intune, or Pilot Intune.
If you want to stop clients receiving 3rd-party updates from Configuration Manager, you should adjust your 3rd-party Software Update deployments to not target devices that have had their Windows Update workload moved to Intune.
Alternatively, if you want a definitive stop to receiving 3rd-party updates from Configuration Manager, go ahead and disable Software Updates in Client Settings.
In testing, this removed all the Windows Update policies and registry keys from the client that the Configuration Manager client had previously set. Be sure to check for tattooed policy that Geoff was responsible before when he created that GPO 74 years ago. The image below depicts the policy/registry key removed for Windows Update.
Pilot Group
One statement we hear often is “I’m not ready to move the Windows Update workload to Intune for all my Windows devices”. The great news is you don’t even have to move the workload for every windows device at once. Creating a pilot collection to target devices with co-management workloads is a great step to test the water.
Staging is used to select which collections will be targeted when the workload is moved to the Pilot Intune phase.
Capabilities
Every co-management workload has an associated numerical value. We refer to this as the capability value. You can very easily see the capability value assigned to the client in the Configuration Manager control panel applet and also the CoManagementHandler.log log file.
The available capability values changed drastically in Configuration manager 2111. If you like deep diving down rabbit holes, check out this post at Co-management Workloads and Capabilities (Revisited) (msendpointmgr.com)
As different workloads are moved to Intune, the capability will be re-evaluated on the client and the value will change accordingly. This capability is how the different MDM agents/clients know which workload they should enforce or ignore.
Capability compliance evaluation bug
There is a known bug when the workload configurations are evaluated by the Configuration Manager client. You can see this error in the CoManagementHandler.log.
Could not find one of the mandatory rules
Failed to merge/resolve rules. Error 0x8000ffff
Failed to process GET for assignment (ScopeId_######/ConfigurationPolicy_###### : 1). Error 0x8000ffff
To workaround this, simple evaluate the the CoMgmtSettingsProd configuration first before evaluating the configuration that failed.
Policy conflict
One of the early challenges, was correctly identifying policy conflicts when moving different workloads to Microsoft Intune. Unless you had very well documented policies, you would often find devices not applying policy correctly because of legacy Group Policy settings tattooed in the registry. This challenge still exists today as folks start to embrace co-management.
The MDMWinsOverGP Configuration Service Provider (CSP) has been designed with good intention. It allows admins to control whether a CSP configured in Intune would win over an identical policy set locally. Unfortunately, this is only true if there is an equivalent CSP policy to override the local policy set by a Group Policy Object (GPO) or Configuration Baseline. Some “left over” tattooed policies can actually break features, like Windows Update.
Here are 3 examples of policies, that left configured on the device, will adversely affect/break Windows Update from working as you move the Windows Update workload to Microsoft Intune.
NoAutoUpdate
NoAutoUpddate is a setting that some admins would use to prevent duplicate Windows Update balloon notifications from appearing on Windows 7 devices. We don’t see this policy used often anymore, we do still find this registry key tattooed in some customer environments. Enabling this policy, setting it to 1, will actually disable automatic updates.
DisableDualScan
DisableDualScan is one of the main focus points of this blog and it is another policy setting that can adversely affect the delivery of Windows Updates when you move workloads to Microsoft Intune in a co-management scenario. Enabling this policy does not allow update deferral policies to cause scans against Windows Update. DisableDualScan is enabled (set to 1) when the Windows Update workload is set to Configuration Manager. When you move the workload to Microsoft Intune, this value will change to 0 to allow the client to Dual Scan (against both the Windows Update Service and WSUS).
If we run rsop.msc on the client we can see this policy enforced by Local Group Policy (via Configuration Manager.)
Important: Dual Scan, is no longer supported on Windows 11. On Windows 10, it is replaced by the new Windows scan source policy.
DoNotConnectToWindowsUpdateInternetLocations
Another breaking policy setting is DoNotConnectToWindowsUpdateInternetLocations. This setting will stop the client reaching out to the internet for Windows Updates.
Note: This setting might be configured and intended. Some admins did enable this policy to prevent users “Checking Online for Updates” and downloading an un-planned Feature Update. Leaving this policy enabled will break stuff as you move the Windows Updates workload to Intune, so keep an eye out for it.
Default AU Service
As we step through different logs in this blog, it is important to note what the different Microsoft Update Service Manager services are. We can run a simple PowerShell cmdlet to view them.
PowerShell Example
(New-Object -ComObject "Microsoft.Update.ServiceManager").Services | Select-Object Name, ServiceId, ServiceUrl, IsDefaultAUService
The service ID is particularly interesting when viewing the WindowsUpdate.log
Note: To generate the WindowsUpdate.log on the desktop, run the PowerShell cmdlet Get-WindowsUpdateLog
The service ID’s are:-
- 7971f918-a847-4430-9279-4a52d1efe18d = Microsoft Update
- 8b24b027-1dee-babb-9a95-3517dfb9c552 = DCat Flighting Prod
- 855e8a7c-ecb4-4ca3-b045-1dfa50104289 = Windows Store (DCat Prod)
- 3da21691-e39d-4da6-8a4b-b43877bcb1b7 = Windows Server Update Services (WSUS)
- 9482f4b4-e343-43b6-b170-9a65bc822c77 = Windows Update
When viewing the WindowsUpdate.log, searching for the following line will tell you which service is being used for an update operation
ProtocolTalker ServiceId =
As the image below depicts, the WindowsUpdate.log has been filtered to show you how different services are contacted to check for different types of updates, depending on how Dual Scan (and Scan Source) has been configured.
When Dual Scan has been enabled, the default automatic update service will be set to “Microsoft Update”. If the workload has not been moved to Intune, the default automatic update service should still be set to “Windows Server Update Services” .
The Windows Update Agent can switch between multiple services. The “default” service will give you an indication if the device is reaching out to the internet for updates to the Windows Update Service. If the default service is set to “Microsoft Update”, it is a good indication that Dual Scan (or Scan Source) has been enabled.
Dual Scan
Dual Scan is perhaps the main reason we are at this party together. When the Windows Update workload is moved to Intune, Dual Scan is enabled. Dual Scan enables Windows 10 devices to scan both WSUS (on-premises) and the Windows Update service (a.k.a WU – or the cloud). Some other things need careful consideration when Dual Scan is enabled.
3rd-party patching
Dual Scan is super beneficial for admins who want to make the most out of the Windows Update service in the cloud, via WUfB/Intune to intelligently manage the delivery of Microsoft, 1st-party, updates but who also want to ease into 3rd-party patching from the cloud a little slower. Companies like Patch My PC can deliver 3rd-party updates from Microsoft Intune as a Win32 app, which is pretty awesome, but customers also need to apply a little due diligent thought before making the move – especially if they have been patching from Configuration Manager successfully. This isn’t to say the move isn’t easy, it’s super simple, but there are some challenges that need consideration.
As we mentioned earlier, when you move the workload for Windows Update Policies to Intune, you are only moving the workload for Microsoft 1st-party updates. 3rd-party updates are normally built as Win32 apps, in Intune. In order to target updates to devices from Intune, as Win32 apps, you must set the Client Apps workload to either Intune, or Pilot Intune.
Another consideration when moving both the Client apps and Windows Update Policies workloads to Intune, is bandwidth.
Bandwidth planning
Carefully sizing a Configuration Manager hierarchy, planning placement of Distribution Points (including a Cloud Management Gateway, a Cloud Distribution/Management Point) and working with the network team to ensure adequate bandwidth is available to deliver content to clients, is critical.
In the world of WSUS, you typically download the updates once from the Content Delivery Network (CDN) and distribute them across that carefully built hierarchy without bringing down your network. As you move the update workload to Windows Update leveraging WUfB/Intune, your Windows devices will now all be reaching out to the CDN individually. The same is true for delivering Win32 apps from Intune for 3rd-party updates. While this is super useful, your Windows devices will be pulling Win32 app content directly from Azure storage. Have you made suitable accommodation for the extra bandwidth those clients will use, sitting nicely within your WAN?
Be smart
You can be totally smart and well prepared for the move, but it requires careful planning. Technologies like Delivery Optimization and Connected Cache certainly demand attention. The folks over at 2Pint have done a lot of work in this area. Optimal Delivery Optimization settings for Intune managed devices can be found at Delivery Optimization Recommendations for Microsoft Intune (2pintsoftware.com)
A quick overview of the types of download content supported by delivery Optimization can be found at What is Delivery Optimization? – Windows Deployment | Microsoft Learn
Connected Cache Server
When you configure clients to use the Connected Cache server, they no longer request content from the internet. Instead, clients request the content from the cache server. The following content is supported for a Connected Cache server:-
- Microsoft Store apps (UWP)
- Windows feature and quality updates (WUfB only, not WSUS)
- For co-management workloads:-
- Windows Update: Windows feature and quality updates (WUfB only, not WSUS)
- Office Click-to-Run apps: Microsoft 365 Apps and updates
- Client apps: Microsoft Store apps/updates (UWP) and Win32 apps
- Endpoint Protection: Windows Defender definition updates
You can read more about the Microsoft Connected Cache server at Microsoft Connected Cache – Configuration Manager | Microsoft Learn
Note: While Connected Cache requires a Configuration Manager Distribution Point ‘today’, we hope to see Microsoft release a standalone Connected Cache feature very soon.
A standalone Connected Cache server will be pretty awesome for folks who have moved all their management eggs to Intune but still have a significant number of devices behind the same NAT’d WAN connection. Read more at Microsoft Connected Cache overview – Windows Deployment | Microsoft Learn
Dual Scan – going deeper
When Windows devices have their Windows Update workload set to Configuration Manager, the registry value HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate DisableDualScan DWORD is set to 0. This means ALL updates come from WSUS. When the workload is moved to either Intune or Pilot Intune, the DisableDualScan value changes to 0.
Windows 10
We can observe the impact Dual Scan has when the Windows Update Agent performs a scan on a Windows 10 device. The WindowsUpdate.log indicates that, in this instance, the Update Orchestrator initiated the Windows Update scan using the service URL https://fe2cr.update.microsoft.com/v6/. The log snippet below has been shortened for simplicity but after Windows Update has been contacted and updates evaluated, the service URL is then changed to the local WSUS server https://bb-cm1.byteben.com:8531/ClientWebService/client.asmx and it is indicated that Windows content for WUfB is blocked.
Note: To generate the WindowsUpdate.log on the desktop, run the PowerShell cmdlet Get-WindowsUpdateLog
The above test was performed with Configuration Manger 2309 and Windows 10 22H2
Windows 11
We know that Windows 11 does not support Dual Scan, but when the Windows Update policies workload is moved to Intune for a Windows 11 device, DisableDualScan is still set to 0 in the registry. For prosperity reasons perhaps (shrugs).
Scan Source
The elephant in the room. There has been some confusion over the part Dual Scan still plays given that the setting is now deprecated.
Dual Scan is not supported on Windows 11. On Windows 10 it is replaced by the new Windows Scan Source Policy and is not recommended for use on version 2004 or greater.
That being said, Dual Scan is still configured by the Configuration Manager client when co-management is in the picture, irrelevant of the Windows version. This is most probably an intentional decision by Microsoft, given some organizations are still supporting older versions of Windows 10.
When the Windows Update workload is moved to Intune for a Windows 11 device, we can/should see the following policies configured in the registry.
SetPolicyDrivenUpdateSourceForDriverUpdates
Configure this policy to specify whether to receive Windows Driver updates from Windows Update endpoint, managed by Windows Update for Business policies, or through your configured WSUS server.
1 = (Default) Detect, download and deploy Driver Updates from WSUS.
0 = Detect, download and deploy Driver Updates from Windows Update.
SetPolicyDrivenUpdateSourceForFeatureUpdates
Configure this policy to specify whether to receive Windows feature updates from Windows Update endpoint, managed by Windows Update for Business policies, or through your configured WSUS server.
1 = (Default) Detect, download and deploy Feature Updates from WSUS.
0 = Detect, download and deploy Feature Updates from Windows Update
SetPolicyDrivenUpdateSourceForOtherUpdates
This policy controls the source for other Microsoft updates, available from the Windows Update service, that are not part of the default Operating System. Updates in the MSI format are normally in scope for this workload. Read more at https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wufb#types-of-updates-managed-by-windows-update-for-business.
Important: This policy is often misunderstood. It does not control or dictate the source for 3rd-party updates, which will always scan against WSUS if a Windows Update Server is specified in the registry.
Configure this policy to specify whether to receive Other Updates from Windows Update endpoint, managed by Windows Update for Business policies, or through your configured WSUS server.
UseUpdateClassPolicySource
For the scan source policies to take effect, the UseUpdateClassPolicySource value specified at HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU must be enabled and set to 1.
Windows 11
Let take a look at how Scan Source is configured for co-managed Windows 11 devices when we spun up the lab. The following tests were performed with Configuration Manger 2309 and Windows 11 23H2.
Co-management not configured for a device
If you have not configured a Windows 11 device for co-management but Software Updates are configured in the Client Settings, the expectation is for all Scan Source Policies to be set 1 (intent for all Microsoft updates to come from WSUS) and the UseUpdateClassPolicySource should be enabled (set to 1).
The image above also shows that the Configuration Manager Client has set local policy to achieve the desired configuration state.
Co-management configured for a device and the workload has not moved to Intune
Again. If you have configured a Windows 11 device for co-management, but have not moved the Windows Update Policies workload to Intune, the expectation is for all Scan Source Policies to be set 1 (intent for all Microsoft updates to come from WSUS). It is also expected that the UseUpdateClassPolicySource should be enabled (set to 1).
At the time of writing this blog, many people are reporting inconsistencies with Scan Source policies where both Windows 10 and Windows 11 devices are reaching out to the Windows Update service. This is occurring even though all indications are that the device is configured to only talk to WSUS i.e. the workload has not been moved to Intune.
Co-management configured for a device and the workload has moved to Intune
If you have configured a Windows 11 device for co-management and you have moved the Windows Update policies workload to Intune, the expectation is for all Scan Source policies to be set 0 (intent for all Microsoft updates to come from the Windows Update service). It is also expected, or so we thought, that the UseUpdateClassPolicySource should be enabled (set to 1) too. That theory sounds pretty sound right?
Well, Scan Source is actually explicitly disabled using a local policy set by the Configuration Manager client.
This confused us a little…well, a lot actually. When Scan Source is not configured, the Microsoft docs indicate that all Windows Updates, for Windows 11 devices, will still come from WSUS. If Configuration Manager is disabling Scan Source, should we interpret that as Scan Source policy as not configured?
What’s interesting here is that even though Scan Source policies are disabled by Configuration Manager client policy, the Windows Update agent is still talking to both WSUS and other internet services too. We can see this from the log snippet below where ProtocolTalker switches between different ServiceIds.
If we zoom in on the detail a little, we can see the device communicating with the DCAT Prod Flighting service. During the scan we see driver updates are evaluated.
We then see a switch to WSUS but all Microsoft Update categories are filtered, indicating only 3rd-party updates will be scanned only in WSUS.
Confused? Come join us by the camp fire of fun. Even though the Configuration Manager client is disabling Scan Soure….it appears to be working as expected when the workload is move to Intune.
Confirmed bug 1 – Scan Source is “wonky”
Microsoft has acknowledged that Scan Source is not being configured correctly, “there are a few wonky things”. We have made some assumptions on how we think it should work above but we will reserve judgement until we see an update or bug fix. Thank you Aria for giving us some hope this will be resolved.
https://x.com/ariaupdated/status/1741970744773329037?s=20
As mentioned earlier, some folks in the community are also seeing devices, when the workload is with Configuration Manager, still reaching out to Windows Update for updates. Come join the conversation at https://x.com/PaulEAndrews/status/1741869611346432472?s=20
Bryan Dam also came across the “Scan Source Saga” and shared some good thoughts and workarounds in his blog. Check it out at Windows 11 Fails to Detect Updates After July’s Cumulative Update – Patch Tuesday Blog
Confirmed bug 2 – KB25073607
The Configuration Manager Client should be setting UseUpdateClassPolicySource when the Windows Update policies workload is moved to Intune. That is what this KB states, but it doesn’t explicitly say what it should be setting it to. Again, our assumption is that the UseUpdateClassPolicySource policy should be enabled (set to 1). Many customers have found that their Windows 11 22H2 devices were not honouring the configured Scan Source policies.
This “should” be fixed in Configuration Manager 2309 and later. A hotfix was release in October 2023 for Configuration Manager version 2303. This revised update uses KB article ID 25506239,
At the time of writing this post, it is not understood if this fix should have fixed the UseUpdateClassPolicySource issue for all Windows 11 versions or just version 22H2.
Conclusion
Co-management is a great concept. It kinda feels like some things were looked over when the switch to Scan Source was made in Windows 11 from Dual Scan. Perhaps that’s just an unfair misinterpretation on my part due to a lack of documentation or explanation of the hand-over from Dual Scan to Scan Source. The road got bumpy real quick. The frustration comes from feedback – it simply isn’t acceptable in large organizations for devices to reach out and get updates that admins hadn’t planned for. These kinds of things crush confidence and do not lend well to admins wanting to move quickly to Intune.
I always ask and seek the answer to the question, “How does it work and how should it be configured?” If documentation was clear and detailed for new features and technology transitions, when somethings goes wrong, we can plan for and initiate a “Plan B”. We can’t invoke our “Plan B” if we have to fight through smoke and mirrors to guess what “Plan B” might look like.
Things should improve
Rumours are that Scan Source is actively being addressed. Some admins have shared that the December 2023 CU seemed to “improve” the condition where devices were reaching out to Windows Update unintentionally. We will continue our testing and update this post accordingly.
Scan Source is a big part of why we are here today. We bow our heads to Dual Scan who served us well in her time. Pushing out your 3rd-party updates from WSUS is still solid, in our testing of Scan Source, it behaved well and as expected (always coming from WSUS).
Update 18th September 2024 – New WUAHandler.dll saves the day? (not quite)
Microsoft released KB28458746 for ConfigMgr 2403 which we thought would address many of the Windows Update issues users were experiencing. Effectively, Microsoft will now stop configuring ScanSource Policies which appeared to be affecting the Windows Update Agents ability to switch between different Windows Update sources on some co-managed devices. The KB doesn’t specifically call this issue out, most of the detail and focus is around fixing an issue where Feature On Demand tools, like .NET 3.5 and other optional features would not download for co-managed devices because of the ScanSource Policy configuration the ConfigMgr client was enforcing.
The files updated by this KB on the client are shown below.
In the payload of this recent KB, we noticed that WUAHandler.dll was modified. If you inspect previous versions of WUAHandler.dll you can see that it is configured to set the “PolicyDrivenUpdateSource” policies.
The hotfix version of WUAHandler.dll now only enables ScanSource by setting “UseUpdateClassPolicySource”, it does not configure any of the “PolicyDrivenUpdateSource” policies like it did previously (DualScan policy is still being enforced too just for the record).
After clients were patched with this KB, Client Version 5.00.9128.1014, we confirmed that value was being set as expected.
The only issue is, the KB did not “undo” the previous ScanSource Policies that ConfigMgr had configured. You may see undesirable ScanSource values still on clients – that local policy will live on forever in the devices in “C:\Windows\System32\GroupPolicy\Machine\Registry.pol” until a higher source policy overrides it. This may not be a show stopper. Those local policy values for “PolicyDrivenUpdateSource” might be correct on your co-managed devices, but if they are not then applying this KB may result in the Windows Update Agent now scanning against a source you had not planned on.
When the Windows Update workload for co-managed devices is shifted to WUfB, ConfigMgr was setting the “PolicyDrivenUpdateSource” values to 0 – indicating all first-party updates should come from Windows Update. If the Windows Update workload was not moved, the value was being set to 1 – indicating all first-party workloads would come from WSUS.
After applying this new KB, Microsoft recommends that admins use a GPO (or Intune Settings catalog policy) to set ScanSource Policies to what they would like them to be. As GPO/Intune Policy is a more authoritive policy source, they will override the previous values the ConfigMgr client had set.
We are good then right?
It gets even messier, honestly. We removed Registry.pol and forced a GPUpdate on a test device and that removed those old ScanSource policies….but then we witnessed ConfigMgr went ahead and started applying them again…this was completely not expected. We are still trying to understand what is happening here. Again, this policy will be overwritten with YOUR desired settings if you set the GPO or Intune Settings catalog policy to configure Scan Source polices.
What does this mean Ben? Well, we are still testing different scenarios in the lab, but the new fix does not appear to fix much. ConfigMgr is now backing away (for the most part) from configuring ScanSource and leaving it up to admins to fix with their own policies.
A friend of ours in the community, Daniel, came across some more, undocumented, Windows Update Cache registry keys. These were also affecting which update source the Windows Update Agent reached out to for updates. Daniel and his team had to remove those keys before the Windows Update agent would start doing “as it was told”.
HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate\*
HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate\*
We then saw another user in the community in a Reddit post claim that further, undocumented, policy needed to be removed on their devices:-
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing -Name LocalSourcePath
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing -Name RepairContentServerSource
Where does that leave us? Honestly, head scratching still. We have half a dozen cases where customers have reached out claiming the Windows Update Agent is not behaving as expected. We are still looking into this pandora black box of magic but nothing conclusive has revealed itself – yet. We will keep digging, but at the moment I’m left thinking the following approach “might” be worth considering, but I would strongly encourage full testing.
1. Create a GPO or set this policy from the settings catalog in Intune
If you have moved the Windows Update workload to WUfB:-
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForDriverUpdates -Value 0 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForFeatureUpdates -Value 0 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForOtherUpdates -Value 0 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForQualityUpdates -Value 0 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU -Name UseUpdateClassPolicySource -Value 1 -Type REG_DWORD
If you still want all updates to come from WSUS:-
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForDriverUpdates -Value 1 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForFeatureUpdates -Value 1 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForOtherUpdates -Value 1 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name SetPolicyDrivenUpdateSourceForQualityUpdates -Value 1 -Type REG_DWORD
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU -Name UseUpdateClassPolicySource -Value 1 -Type REG_DWORD
2. Rename Registry.Pol to remove old ConfigMgr local policy
Renaming the following file should have no adverse effect, it is where local machine policy is read from and then applied. It will be rebuilt when machine policy is next updated (GPUpdate /Force).
“C:\Windows\System32\GroupPolicy\Machine\Registry.pol” to “C:\Windows\System32\GroupPolicy\Machine\Registry.old”
3. Delete the undocumented GPCache Keys
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate
4. Remove Windows Servicing Policy (if exists)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing -Name RepairContentServerSource
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing -Name LocalSourcePath
5. Restart WUAgent
Restart-Service -Name wuauserv
In summary, we are still as baffled as our customers and community colleagues on why update servicing is so temperamental for co-managed devices. We continue to move forwards into the abyss of the unknown, trying to shed light on the battle that rages between ConfigMgr and the Windows Update workload. What we can say with certainty…moving the co-management workload slider for Windows Updates is not the “one-click” solution like it used to be in the simple days of Windows 10 and DualScan.
Things to remember
Remember, moving the Windows Update policies workload to Intune only affects Microsoft 1st-party updates. If you want to deploy Win32 apps from Intune, simply move over the Client Apps workload. The Client Apps workload, unlike the others, is not a “this or that” switch. It simply allows Win32 apps to be processed by the Intune Management Extension. You can still target applications from Configuration Manager, too.
Finally
If you want to fly to the cloud, un-hindered by Configuration Manager and the complexities of Scan Source, simply deploy a Client Setting with the Software Updates component disabled. From that point, you are cloud only for Windows Updates. Ensure you are prepared for this, the pre-requisites are met for WUfB, and your devices are registered with the Windows Update service.
References
https://learn.microsoft.com/en-us/mem/configmgr/comanage/overview
https://byteben.com/bb/co-management-series-merging-the-perimeter-part-5-enabling-co-management/
https://msendpointmgr.com/2023/02/04/co-management-workloads-capabilities/
https://learn.microsoft.com/en-us/windows/deployment/update/wufb-wsus#default-scan-behavior
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update
https://learn.microsoft.com/en-us/mem/configmgr/hotfix/2303/25073607
https://patchtuesday.com/blog/critical-patches/windows-11-fails-to-detect-updates-after-julys-cumulative-update/
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/why-you-shouldn-t-set-these-25-windows-policies/ba-p/3066178
https://learn.microsoft.com/en-us/windows/deployment/update/deployment-service-prerequisites