Using ConfigMgr With Windows 10 WUfB Deferral Policies

Important: Configuration Manager current branch version 1706 is needed for any ConfigMgr environment using WUfB deferral policies. ConfigMgr client version 1702 will periodically delete all WUfB deferral policies, if configured. This could lead to unintended results.

As you are probably aware, Windows 10 version 1607 introduced new Dual Scan behavior for enterprises that wanted Windows Update (WU) to be their primary update source while Windows Server Update Services (WSUS) provided all other content. In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU. Stated another way, the Dual Scan enabled client ignores anything on WSUS from the “Windows” product family. If you configure a combination of Windows Update group policies (or their MDM equivalents, or the underlying registry keys corresponding to either set of policies), then Dual Scan will be automatically enabled. These policies are:

Specify intranet Microsoft update service location (i.e. WSUS)

and

Either of the “deferral” policies belonging to Windows Update for Business

Select when Feature Updates are received

Select when Quality Updates are received

To defer updates, many enterprise customers used the configuration above prior to 1607. For them, the new Dual Scan behavior was an unwelcomed change as it broke ConfigMgr software update deployments for any updates within the “Windows” product family. Demystifying “Dual Scan” provides details about Dual Scan as well as settings that enterprises can use to work around the new behavior.

The October cumulative update for 1703 includes new functionality and a new policy that allows Dual Scan to be disabled. The new policy, "Do not allow update deferral policies to cause scans against Windows Update", when enabled, will disable Dual Scan. This allows enterprises that wish to configure deferral policies, the ability to do so without being concerned that Dual Scan will override administrator intent.

It is important to understand the expected behavior as it relates to ConfigMgr.

Windows Update for Business deferral policy configured and deployed via ConfigMgr (Windows 10 version 1703 and higher) - If you configure and deploy WUfB deferral policy via ConfigMgr, Dual Scan will be automatically enabled*. That is, "Do not allow update deferral policies to cause scans against Windows Update" will be set to disabled on any ConfigMgr client where the WUfB deferral policy is deployed. Even if you enable "Do not allow update deferral policies to cause scans against Windows Update" at the domain level, that setting will be periodically overwritten by the ConfigMgr client. *Assumes that the “Specify intranet Microsoft update service location” policy is set to Enabled.

Windows Update for Business deferral policy and Dual Scan disable policy configured and deployed via GPO – If you configure WUfB deferral policy as well as disable Dual Scan (e.g. enable the new policy) via GPO, those settings will be preserved by the ConfigMgr client.

To summarize:

To use WUfB deferral policies while disabling Dual Scan, use GPO to configure all required settings.

And if you’re still managing some Windows 10 version 1607 clients, the August cumulative update for 1607also includes the new Dual Scan policy. You can use GPO to set deferral polices and disable Dual Scan when running ConfigMgr version 1706.

Does the following mean that only 1703 clients can use ConfigMgr for WUfB policies?
“Windows Update for Business deferral policy configured and deployed via ConfigMgr (Windows 10 version 1703 and higher) ”

Hi,
I have a customer where we use ConfigMgr for software updates. They are using Windows 1607.
Now I would like to use WUfB to upgrade to 1703.
I set the deferral GPOs and if I click “Search online for updates” 1703 is found and the machine upgrades just fine.
I was hoping the client would find this feature update without me clicking search online.
Three clients have been running for 4 days and none of them are upgraded. I cannot see anything in any logfiles either.
Is it possible to do this or am I just doing something that is not supported?

Now I can see that this works perfect.
I just can’t seem to find how to force the upgrade to happen. If I wait a few days the clients get the 1703 and upgrades just fine.
Don’t see anything in the WindowsUpdate.log though.