Back in May of this year, Microsoft addressed an issue where a client system could scan for updates on Windows Update despite the system being set for deferred updates in WSUS.
Following a situation like this, the system would then not comply with the deployment instructions from WSUS in the future causing a potential feature update upgrade the adminsitrator is not expecting.
Earlier this week on Patch Tuesday, Microsoft released a cumulative update for for WSUS admins, that added a new Group Policy that prevented this issue from reoccurring.
The new Group Policy will be located under Windows Components/Windows Update after the August Cu is applied to the client system.
Image via Microsoft
According to Microsoft, here is how the new policy will work for on-premises environments:
"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"
They have also provided the following five scenarios to help with your management strategy for this Group 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.
-- 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.
-- 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.
-- 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.
-- 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. We recommend holding off using Disable Dual Scan (or any deferral policies) until updated guidance for that product has been released.
For more information visit Improving Dual Scan on 1607 on the WSUS Product Team Blog.
Looking for an awesome, no-nonsense technical conference for IT Pros, Devs, and Devops? Check out IT/Dev Connections!