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. 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.

 
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 (59)

  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.

          1. Matt5150 says:

            Just found this posted yesterday, that claims the October update includes the new deferral policy for 1703. Is this true?
            https://blogs.technet.microsoft.com/configurationmgr/2017/10/10/using-configmgr-with-windows-10-wufb-deferral-policies/

            I don’t see it listed as a fix.
            https://support.microsoft.com/en-us/help/4041676/windows-10-update-kb4041676

          2. Yes, installing the October cumulative update should add this policy to the 1703 client.

  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.

          1. NickyMayB says:

            +1 for KB4035631 causing subsequent failures to communicate with WSUS from our 2016 WSUS clients. I’ll be doing further investigation tomorrow to confirm and then getting a support request in: will update here if I get anything useful back.

          2. NickyMayB says:

            Turns out that the issue wasn’t caused specifically by the August patches but by Server 2016 patches in general, as described here https://blogs.technet.microsoft.com/configurationmgr/2017/08/18/high-cpuhigh-memory-in-wsus-following-update-tuesdays/ – the workarounds described in that article have solved the problem for us.

          3. Yes, we made a judgment call to keep that traffic on the support-focused communication outlets, rather than cover it on the WSUS blog. Glad to hear that the provided guidance resolved your issue.

    3. Mikael says:

      Yes, confirm seeing the same problem

  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.

          1. Tim D says:

            Holding off on releasing this update to the ADMX is inconvenient at best. I, as well as many other admins fell prey to the dual scan scenario, however the solution to manually enable this setting on each local machine is generally not feasible for most more mature IT environments. Can MS please consider releasing this ADMX ahead of the next major release to provide us some relief here?

          2. Thanks for the feedback, Tim. We will certainly keep it in mind for future releases. The intention was twofold:
            1. Provide immediate relief to smaller businesses and those that are able to set the new policy locally
            2. Indicate to larger businesses that relief is coming. Until ADMX is released, it makes more sense to continue using the “block WU entirely” workaround

            Are you unable to use the short-term workaround until the ADMX is available?

  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).

      1. Brachus says:

        So if we are using ADMX files in a central store, how do we even access this new setting now?

        1. Until the ADMX is published, you can access the “Do not allow deferral policies to cause scans against Windows Update” policy locally on 1607 clients that have been updated to include it. Centrally, there is currently no way to configure this policy.

          1. James Busch says:

            That’s just crazy – the only people running WSUS are the ones that have hundreds of computers to manage. We aren’t going to run around to each machine to change this policy manually. We need the ADMX files released now!!! All of my machines are automatically upgrading to 1703 and I need to stop them!

          2. Understood, James. If that’s the case, then you’ll want to leverage the workaround policy presented in the original post (“Turn off access to all Windows Update features”) until your ADMX becomes available.

  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?

  10. andrewmrae says:

    It would have been good if it were obvious that setting things like ‘ExcludeWUDriversInQualityUpdate” would trigger the Dual Scan… !
    Unfortunately for me, it was too late when I found the list of Policies which caused this behaviour – https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online

    With this not being in the current GPO .ADMX templates – you could always push the policy out via registry change to the current 1607 and 1703 clients, which will affect the 1607 clients now, and the 1703 clients when the update to support this functionality is released.
    I guess that way you don’t have to remember to go back and set the GPO…

    REG ADD “HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate” /v “DisableDualScan” /t REG_DWORD /d 0x1 /f

    1. Yes, we fixed that bug (about excluding drivers causing dual scan) in 1703. With the new policy enabled, even “exclude drivers” won’t trigger Dual Scan. That’s true about pushing registry keys: it’s not as convenient as an ADMX, but it would get the job done.

  11. Andrew says:

    I have 11 sites and one Internet connection and a mixture of 1511 and 1607 clients. I have random 1511 clients sometimes upgrading to 1607 but not others. When this happens it clogs our WAN. What do I have to do to make it like the old days where I have total control over my patching? How can I ensure machines will NEVER upgrade to a newer version of Windows? How can I ensure clients only goto WSUS? I think these changes and lack of communication from MS not to mention confusing articles like this is unacceptable.

    1. Hi Andrew, and sorry for the confusion. For all versions of Windows 10, there is the potential for an ad hoc scan against Windows Update to result in downloading a feature update to a newer build. If you want to guarantee that your machines never download this content from Windows Update and clog your WAN, then you’ll want to use the “Turn off access to all Windows Update features” policy to block access entirely. Note that doing so will prevent you from getting quality updates through Windows Update, as well.

  12. Eric Singer says:

    Apologies if this is the wrong area to voice a grievance, but I disappointed in what’s been done to the WSUS client on Windows 10 / 2016. You guys took something that was mostly intuitive and turned into one of the more confusing and frustrating aspects of managing a system.
    The dual scan is SO unintuitive. I mean, the fact that you need to write a blog article, should be evident enough that it needs some serious TLC. Why don’t you guys create a simple drop down of “WSUS managed, Dual Scan, WSUS for Business or Unmanaged”? Then it wouldn’t matter what registry keys or GPO values were turned on, this would determine what mode the client is in? This would also protect against an admin that accidentally changes a feature (or registry setting) that would dynamically enable the wrong mode.
    Next, why not separate all the settings based on how applicable they are? Meaning, put dual scan settings in on hive (GPO folder), put WSUS for Business in another folder and put WSUS only in another. This way its more obvious which setting are for what?
    PLEASE bring back the update selector that existed in previous OS’s. I hate that I can do a simple “check for updates” and then pick which updates I want to apply. There may be times I want to test installing only one update to see if it’s the cause of an issue. And the last thing I want, is for it to start auto installing when I do click the box to check. BTW, this would also make it possible to easily bypass WSUS and check for new update that exist at MS, without having to worry about everything installing automatically.
    Finally, one of the log files you guys collect in the get-wsusupdatelog (or whatever its called) doesn’t use the same time stamp as everything else. If you’re merging logs, it would be nice to see that particular log have its time stamp updated to reflect the same time and data as the local computer and to also mention what log the data is being pulled from.

    1. Thanks for the feedback, Eric. Windows 10 changes the servicing game in ways that make existing tools work differently than you might expect. Your solution hits on a number of good points that were considered, but unfortunately the implementation is more complex than to allow such a simple interface to serve the purpose. With that said, we’ll keep your comments in mind for future changes to this platform.

  13. Shane says:

    Is there an ETA on when the 1709 ADMX files will be released so we can fix through Group Policy? We are wanting to stay on 1511 (since it works) but that obviously is coming to end of life in the next 2 months. I guess we are just in a pickle because we don’t want random upgrades to happen but yet 1511 is at end of life soon.

    “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.”

  14. Shane says:

    We are running version 1511 and don’t want to update to 1607/1703 until the mdmx template is out with the fix. Do you think the new mdmx file will be released for Group Policy before 1511 end of life in October?

    1. That’s the intention, though WSUS itself is not in control of when 1709 is released.

  15. Richard says:

    What if a person wants to receive updates from both Windows Update for Business and WSUS/SCCM at the same time. Is this scenario possible? I have had no luck getting this to work, I can only receive updates from WSUS/SCCM. I can see it searching Windows update in the logs, but it never downloads and fails with error 0x8024002E. Apologies if this is the wrong area, but I can’t find any information on this. Only disabling this behavior.

    1. This is literally the Dual Scan scenario. To enable it, you need only configure one of the deferral policies mentioned in the original post. Under Dual Scan, you will get all Windows content from Windows Update and all non-Windows (as well as non-Microsoft) content from WSUS/ConfigMgr. If this is the mix you’re looking for, then Dual Scan should suit your purpose nicely.

  16. Richard says:

    Thanks for the reply! So if I understand correctly we could receive updates and feature updates for windows from Windows Update for Business, but still receive our updates for Office 365 from SCCM/WSUS? To fully enable dual scan we would also need to disable the “Specify intranet Microsoft update service location” group policy?

  17. DFlower66 says:

    Can anyone tell me why I don’t see the option “Do not allow update deferral policies to cause scans against Windows Update”? I have installed the “Administrative Templates (.admx) for Windows 10 (1703) and Windows Server 2016”, RSAT on a Windows 10 machine but no luck so far…

    1. ADMX for centrally modifying this policy is added in 1709. RSAT does not include this functionality, but you should be able to locally modify the policy on the 1703 machine even today.

  18. Matt5150 says:

    Does this “Do not allow update deferral policies to cause scans against Windows Update” also do the same behavior as “Do not connect to any Windows Update Internet locations”?

    It looks like after applying this policy, running commands like “Get-WindowsUpdateLog” are no longer going to Microsoft sites. Log contains GUID information that wasn’t resolved from the Micrososft Symbol server.

  19. Shane says:

    Has anyone seen or know when the new admx templates will be released for group policy. I figured they would have been released the day that 1709 went public but don’t see anything. Was hoping we would be able to fix group policy soon.

Skip to main content