While using Windows Updates for Business (WUfB) is not for everyone, its simplicity and familiar end-user experience make it quite attractive to many organizations. One thing that WUfB does not provide today is updates for third-party products. For that, you need to continue to use an on-premises solution like Microsoft Endpoint Manager Configuration Manager to complement WUfB.
Ultimately, deploying third-party updates when using WUfB is no different than deploying them using Configuration Manager by itself. Enabling third-party updates with WUfB requires the following three things:
- Enable and configure WUfB.
To enable WUfB, configure any WUfB related policy or setting using one of the following methods:
- Configure and enable software updates in Configuration Manager.
SeePlan for software updates in Configuration Managerif necessary.
- Configure and enable third-party updates in Configuration Manager.
Do this using a handful of different methods, including the following:
- System Center Update Publisher (SCUP).
- Thethird-party updatesfeature set built into Configuration Manager.
- A tool from a third-party.
So, how does Configuration Manager work with WUfB to deliver third-party updates? The answer is dual-scan. Note that although dual-scan did cause some confusion in the past that resulted in the unintended installation of updates, you should not be afraid of it once you see how it works (as described in this post).
Dual-scan is a feature of the Windows Update (WU) client. It enables the WU client to use WUfB and an on-premises WSUS instance to scan for update applicability and compliance. When you enable dual-scan, the WU client uses WUfB (and only WUfB) for Windows product updates and WSUS for non-Windows updates.
To enable dual-scan, enable a WUfB deferral policy on a system with a local WSUS server configured. This can be a WSUS server integrated into and automatically configured by, Configuration Manager (the scenario discussed here) or a stand-alone WSUS server. That's all there is to it.
If you don't want dual-scan, don't enable any WUfB deferral policies. This is where a disconnect usually happens, as these policies are for WUfB only. They have no effect or purpose if another solution for deploying Windows updates is used, like Configuration Manager or WSUS, but they enable dual-scan.
See Using ConfigMgr With Windows 10 WUfB Deferral Policies for further details on dual-scan and explicitly stopping it.
To prove out deploying third-party updates using Configuration Manager with WUfB enabled, I used one of the existing co-managed systems in my lab. The name of this system is ELKWIN2.
ELKWIN2 started life as a Windows 10 1909 system and was updated to 2004 using WUfB; it continues to receive quality updates from WUfB. You can see the Windows Update configuration in the following two screenshots from ELKWIN2, confirming the WUfB configuration.
Windows Update settingsConfigured update policies
Software Updates Configured
Even though WUfB is configured on ELKWIN2 using Intune, the Configuration Manager Software Updates configuration is still targeted to the system and still applies to the system. Since ELKWIN2 is configured for WUfB and has a local WSUS server configured, dual-scan is also enabled. The following two screenshots show the WSUS server configuration and local group policies configured by the Configuration Manager agent.
Resultant Set of Policies
Third-party Updates Configured
For this, I created a custom update (for a custom application) in SCUP and published it to the Windows Server Update Services (WSUS) server integrated with the Configuration Manager site in my lab. After synchronizing the update catalog in Configuration Manager, the update showed up in theAll Software Updatesview, ready for compliance scanning and deployment.
FakeApp 2.0 in System Center Updates Publisher
FakeApp 2.0 Upgrade in Configuration Manager
I then initiated a Software Update Scan Cycle from the Actionstab in the Configuration Manager Control Panel applet on ELKWIN2. Finally, I forced ELKWIN2 to send all queued state messages to the site and checked the reports.
Specific compliance state for an update (FakeApp 2.0 Upgrade)
Compliance state for a specific computer (ELKWIN2)
As the reports show, ELKWIN2 requires the FakeApp 2.0 Upgrade. Also, note that no Windows updates show at all for ELKWIN2. That's dual-scan at work. All that is necessary now is to download and deploy the update or configure an Automatic Deployment Rule to do this for us.
Even though WUfB doesn't support third-party updates, it's still possible to deploy and manage them using the ever-faithful Configuration Manager and the built-in Windows dual-scan functionality.
Nice write up, @Jason_Sandys.
Thanks Jason. This is really a great explanation.
We are working on similar situation were we moved few pilot user to WUfB and then realized that Edge Chromium updates are not getting delivered to pilot user using SCCM as the windows update workload is moved to Intune. Is there any workaround for Edge Chromium updates ?
Hi @ranjan manna. Edge Chromium has its own update engine that downloads and installs updates from Microsoft Update automatically following any deferrals that you have configured for quality updates. If you install Edge using the ConfigMgr built in method, this does, by default, disable automatic updates though so you'll need to re-enable.
Thanks for this blog. I have a question. In a co-managed environment, if SCCM/WSUS is used for WU (quality and feature), and if ‘Auto-update/Download updates from Microsoft' is turned on for the purpose of auto-updating Windows Defender, technically it opens up the option “Check Online for updates from Microsoft Update” in Windows update settings. This means the end-users can click that link in Windows Update settings to search and update manually on their own. What is the solution to a scenario like this?
Hi @Raja Boopathy. I don't specifically know which option you are talking about when you write ‘Auto-update/Download updates from Microsoft'. Are you referring to the option in the “Configure Automatic Update” Group Policy setting? If so, why do you have this enabled for defender updates instead of deploying them using ConfigMgr?
Hi @Jason_Sandys and Team – Apologies for my late response and thanks for your suggestion. We are looking into all such possible ways for this. I have another query if you could help please. We implemented co-management for Win10 1809 as per NCSC guidelines and with specific 1809 GPO's, MDM and WSUS/SCCM policies accordingly. Noticed one of the devices got 1909 upgraded and let's say human error. Once that 1909 upgrade was done to that device, it eventually got 2004 upgraded automatically in the next few days. Which means all the local GPO's, WSUS (intranet WU location) policies have been bypassed. Is it because that once we upgrade to newer edition, we need to rollout the appropriate GPO's as well?
So in this configuration Windows updates will come from Microsoft (Internet) and third party will come from WSUS while on-prem or VPN?
Hi @JeffAre, not specifically. This isn't about the client's location; this is simply about delivering updates for third-party products from ConfigMgr because WUfB cannot do that today. Whether the client is on-prem or not is irrelevant as that's a separate challenge that you can address with IBCM or a CMG (or possibly a VPN although I'd strongly recommend that orgs use a CMG even if they have a VPN solution in solution).