Improving Dual Scan on 1607


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:

Policy to disable Dual Scan

New policy available in 1607 with the August cumulative update installed

 
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":
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.
  • 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.

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.

 
Coming soon
We prioritized getting this update out to the broadest install base. In parallel, we are porting the changes to 1703 (they are already in v.next). Disable Dual Scan is currently only for Group Policy at this time: MDM is also in the works, and will be delivered later this year.

Comments (31)

  1. Chris Huckaby says:

    When can we expect guidance on the “Windows updates from Configuration Manager, supplemental updates from WU” scenario? Also, where should we look for it?

    1. We haven’t seen a release date yet, but we know that a change is in the works. We’ll update the scenario you called out on this page when updated guidance is available and will link to the appropriate page that Configuration Manager publishes.

  2. Tero Alhonen says:

    Hi Steve,

    The new “Do not allow update deferral policies to cause scans against Windows Update” policy is not part of KB4022723 or KB4025339 but it’s included in KB4025334 https://support.microsoft.com/en-us/help/4025334 download http://www.catalog.update.microsoft.com/Search.aspx?q=KB4025334

    Thanks,
    Tero

    1. Good catch, Tero. The KB article numbers were mixed up: we were one month behind. Updated the post to reflect that this change went into the July 18th update and will be part of that releasing on August 8th, as well as all future cumulative updates.

  3. Mark says:

    Would there be new ADMX templates available to deploy this policy through GPMC in DC ?

    1. Yes, new ADMX is published along with the next feature update release, whose exact date is not yet public knowledge.

      1. Matt5150 says:

        So the ADMX template update for a 1607 / 1703 setting will be supplied after 1709 or 1803 is released?

        1. Yes, in conjunction with the 1709 release (the naming of which does not imply a specific release date, by the way). Unfortunately this solution did not come together until well after 1703 had shipped, so we’re refreshing at the next available opportunity.

  4. Susan Bradley says:

    I just updated to 1703. When will this policy be injected into that release?

    1. You should see this policy in 1703 around the time that 1709 is released.

      1. CmdrKeen says:

        So, the patch wasn’t released in time to prevent most Dual Scan machines from upgrading to 1703, and there is no rush to release the same fix to 1703 until “around the time that 1709 is released.” So what is stopping this scenario from happening again on release of 1709?

        Can’t you understand how removing update control from Admins is a huge bird-flip to any businesses with an IT department?

        1. The delay is not for lack of understanding, but for want of prioritizing some relief (i.e., for 1607) over no relief in the short term. If you are on 1703, then you’ll potentially face the issue: the best course of action there is to block Windows Update entirely if you don’t want any feature updates (e.g., 1709) to be pushed to your clients. While not altogether ideal, we thought waiting until we could ship the 1607 and 1703 changes simultaneously would have put more folks in an undesirable state, given that 1607 was and is more prevalent. If there is feedback to suggest that waiting for both to be ready before shipping anything would have been preferred by admins, then we’d love to hear it.

        2. Regarding removing update control: the vision is that Cloud-first management obviates the need to explicitly approve every update that is deployed in your environment. Ideally the updates simply flow while the IT department monitors for issues, at which point it can pause the operations and mitigate as necessary. The policy described in this post is specifically catering to the on-premises admins who are not aligned with this Cloud-first management philosophy.

  5. stephane says:

    I’ve installed 1607 and installed KB4022723 with the RSAT and I still don’t see the new policy. Any ideas what I could have missed?

    THks

    1. Sorry for the confusion, stephane: we previously updated the link to point to KB4025334, but the text still showed 4022723. The content you need is in the July 18th update, as well as every update afterward. We recommend installing the latest, which would be KB4034658 (August 8th). Updated the post to avoid confusion.

      1. stephane says:

        I’ve installed KB4034658 and rebooted but I still can’t see the new policy in group policy management running on my 1607 wks.

  6. The Tester says:

    Anyone notice that this latest set up updates killed WSUS for 2016 servers???
    After installing KB4034658 and the servicing KB4035631, my 2016 machines cannot talk to the WSUS server.
    Uninstalling the KB does not fix the issue. The servicing KB cannot be uninstalled it seems.
    All W10 machines can connect no issues with the WSUS server.
    Nothing special on the setup. Assuming another failed update (after last year’s 2012R2 fiasco, I expected this).
    Looks like I have to restore the VM from a backup and wait for a patch again next month.
    I am hoping that restoring the WSUS server will fix it. Otherwise all the VM’s will need restoration.

    1. The Tester says:

      Edit, posting here as it could be related to the post above.
      Also this is the only place there were good comments after last year’s failed WSUS updates (needed manual steps to fix after the issue was identified and had to hunt to find out where the manual fix information was). Sorry, just left a bad taste, as it was not up to normal MS quality.

      1. We appreciate the expectation of normal MS quality and are striving to live up to it after last year’s misstep.

    2. Thanks for pointing this out. It’s much more likely that 4035631 caused the issue here: Servicing Stack Updates can be tricky to release flawlessly, and they unfortunately cannot be uninstalled. Can others confirm these results? If so, then we’ll get a bug filed for the SSU.

      1. Rod Coleman says:

        I can also confirm that KB4035631 has resulted in our Windows 2016 servers no longer communicating with our Windows 2012 R2 WSUS server. After install of KB4035631 and KB4034658, followed by reboot, Windows Update reports 0x8024401c.

        1. Can you share the forum thread where you’ve reported the issue? Have you filed an official support request? Any information you have about this failure and your investigation into it so far would be helpful.

  7. Stacy says:

    We are mainly running version 1511 right now (which I love and reliable). We have about 20 machines that we were testing 1607 on and we are getting random ones (not all) that randomly update to 1703. After reading all of this, I’m still confused on exactly when 1607 will have a fix to stop this crazy dual scan. We run WSUS for a reason, and that’s to manage what gets released for updates. Just looking for some relief. I honestly could care less about Windows Update and only want updates to go through WSUS. Thanks

    1. Your scenario is exactly the one targeted by this improvement to 1607 (and soon 1703), Stacy. Enable this policy and your clients will no longer scan against Windows Update when they have been configured to defer feature or quality updates.

      1. stephane says:

        That’s what I want to do, but I can’t see it in group policy management on the updated machine.

        Does that has to be done locally on each?

        1. That’s correct: after installing the update, you’ll see the new policy on each of the machines. Domain group policy (ADMX) will make this easier when it is released with 1709.

  8. John Panicci says:

    Steve,
    I’m a bit confused, When will ADMX files come out to allow me to set this policy via GPO? Are you saying I need to wait until 1709 is released and new ADMX files are released? I believe the update will modify Local Policy files to show these options in gpedit.msc

    1. That’s correct, John: local group policy reflects the new functionality immediately, but the convenience of managing via domain group policy will not be available until the next major update (i.e., 1709).

  9. narthup says:

    We are running an environment that has 1511, 1607 and now 1703 – managed by SCCM. With the dual scan issues we have seen many of machines randomly updating from WU. I wish the Microsoft would have given us some heads up and made this process more practical and easier to comprehend and roll out. Got a feeling that we are always trying to play catch up with the updates. What is Microsoft doing to make this process more streamlined?

    1. Understood that there are growing pains with the introduction of a new solution. The update stack has largely been untouched for years, and this recent churn can come as a surprise. With that said, we’re not clear on what you mean by a process being streamlined: can you provide some examples?

      1. narthup says:

        Thank you for your reply, Steve. Referring to the process being streamlined, I meat that it would be useful to be aware of these changes in advance. Patching all workstations/servers in an enterprise is always a challenge and if Microsoft can keep the Engineers who manage SCCM/WSUS and other patching management software informed of these changes – perhaps a location on Technet where information about these changes and new features are released and updated frequently?

Skip to main content