Improving Dual Scan on 1607

08/04/2017

3 minutes to read

In this article

As mentioned in Demystifying "Dual Scan", configuring a combination of policies on Windows 10 1607 can result in those clients automatically [and unexpectedly] scanning against Windows Update, as well as subsequently ignoring deployment instructions from WSUS. We heard feedback from on-premises administrators that they needed the deferral policies only for ad hoc scans against Windows Update, a scenario which was not supported. The previous post mentioned a summer release of a policy on 1607 that would address the issue, and we are pleased to announce that this policy has arrived.

The package containing this policy is available today from KB4034658, which is the August cumulative update released to the WSUS channel on 8/8/2017. After installing this update (or any update released on July 18th or later), you will see this group policy under Windows Components/Windows Update:

[caption id="" align="alignleft" width="599"] New policy available in 1607 with the August cumulative update installed[/caption]



How Dual Scan works with this policy

In order for Dual Scan to be enabled, the Windows Update client now also requires that the "Do not allow update deferral policies to cause scans against Windows Update" is not configured. In other words, if this policy is enabled, then changing the deferral policies in a WSUS environment will not cause Dual-Scan behavior. This allows enterprise administrators to mark their machines as "Current Branch for Business," and to specify that feature updates should not be delivered before a certain amount of days, without worrying that their clients will start scanning Windows update unbidden. This means that usage of deferral policies is now supported in the on-premises environment. While the new policy (dubbed "Disable Dual Scan") is enabled, any deferral policies configured for that client will apply only to ad hoc scans against Windows Update, which are triggered by clicking "Check online for updates from Microsoft Update":





How to use this policy

There are several relevant scenarios in your update management strategy. For the sake of completeness, here are the most common update management scenarios, updated for use with this policy:

Windows updates from WU, non-Windows content from WSUS - the canonical Dual Scan scenario. Enabling the policy described in this post would disrupt Dual Scan operation and should not be done.

- the canonical Dual Scan scenario. Enabling the policy described in this post would disrupt Dual Scan operation and should not be done. Windows updates from WSUS, blocking WU access entirely - the "workaround" scenario. If you have blocked access to Windows Update, then enabling the policy described in this post is irrelevant. Note that this workaround is no longer necessary and that you can control WU access by combining deferral policies with Disable Dual Scan.

- the "workaround" scenario. If you have blocked access to Windows Update, then enabling the policy described in this post is irrelevant. Note that this workaround is no longer necessary and that you can control WU access by combining deferral policies with Disable Dual Scan. Windows updates from WU, not using WSUS at all - the "consumer" or "WU for Business" scenario. If WSUS is not part of your update management infrastructure, then neither the Disable Dual Scan policy nor the change that introduced Dual Scan will have any effect. The same is true if all your Windows clients are running 1511, as Dual Scan was introduced in 1607.

- the "consumer" or "WU for Business" scenario. If WSUS is not part of your update management infrastructure, then neither the Disable Dual Scan policy nor the change that introduced Dual Scan will have any effect. The same is true if all your Windows clients are running 1511, as Dual Scan was introduced in 1607. Windows updates from WSUS, supplemental updates from WU - the "on-premises" scenario. Here you expect your users to perform ad hoc scans every so often to get updates that are necessary, but have not been deployed by the enterprise admins. You want quality updates, but do not want feature updates offered during these scans. The policy to disable Dual Scan was created for this scenario: you can enable the new policy, along with your deferral policies, and those deferral policies will only take effect when scanning against Windows [or Microsoft] Update.

- the "on-premises" scenario. Here you expect your users to perform ad hoc scans every so often to get updates that are necessary, but have not been deployed by the enterprise admins. You want quality updates, but do not want feature updates offered during these scans. The policy to disable Dual Scan was created for this scenario: you can enable the new policy, along with your deferral policies, and those deferral policies will only take effect when scanning against Windows [or Microsoft] Update. Windows updates from Configuration Manager, supplemental updates from WU - a modified "on-premises" scenario. Here the expectations are the same as with the previous scenario, except that Config Manager recently took a change to remove some underlying policies that make this scenario work differently than described above. The Configuration Manager team has published its own guidance for this scenario.

Note that WSUS still ignores all deferral policies that have been configured, and that any deferral policies you do configure will only affect offering and download of updates for Microsoft products.



Now available: ADMX and MDM

We prioritized getting this update out to the broadest install base on 1607. In parallel, we ported the changes to 1703 and 1709. Installing the latest cumulative update on any of these platforms will allow you to access the Disable Dual Scan policy via MDM. You can also configure it centrally via the new administrative template that was released in conjunction with the 1709 feature update.