Demystifying “Dual Scan”

How Dual Scan came to be
With the combination of Windows Update for Business and Windows as a Service, we effectively created a new paradigm for update management, one that does not require administrators to approve every update manually before it can be deployed.  We believe that this automated management solution is the future, and we want to ensure that everyone who wants to move to modern (i.e., Cloud-first) update management can do so.  The biggest adoption blocker facing prospective customers of this new management paradigm was that they had their own third-party and line-of-business applications that were just as necessary as Microsoft updates, and Windows Update for Business wouldn’t serve those.  Until modern update management supported this scenario, those needs would certainly keep on-premises admins tethered to their current infrastructure.

What Dual Scan is
Dual Scan is a Windows Update (WU) client behavior that debuted in 1607 and was designed to bridge exactly this gap.  It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides 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, anything on WSUS that resides in the “Windows” product family is ignored by the Dual Scan client.  This is to avoid the “two masters” problem that can occur when there are multiple equally valid sources of truth for a given set of updates.  Dual Scan is automatically enabled when a combination of Windows Update group policies [or the MDM equivalents] is enabled:

  • Specify intranet Microsoft update service location (i.e., WSUS)
  • Either of the policies belonging to Windows Update for Business
    • Select when Feature Updates are received
    • Select when Quality Updates are received

How Dual Scan might affect you
Prospective Cloud-first customers might appreciate this feature, but what about those that want to continue managing updates the way they have for years?  To those customers, Dual Scan introduces an unwanted loss of control.  Prior to Windows 10, you couldn’t accidentally upgrade a managed machine to a new build simply by scanning against Windows Update (WU) because only quality updates were provided via that channel.  At that time, administrators were unconcerned about their clients scanning against WU because it could never lead to any significant changes in the client state.  With feature updates being offered on WU, there is now a possibility that a client managed through WSUS or Configuration Manager can receive a feature update that was not approved by its administrator.  This will happen if a managed user clicks the “Check online for updates from Microsoft Update.” link:


Because on-premises admins were justifiably concerned about this scenario, they elected to enable the WU for Business policy that allowed them to select when feature updates were received (specifically, setting Branch Readiness to Current Branch for Business), which had the intended effect: scans against Windows Update no longer pushed the unapproved feature updates.  However, this configuration also satisfied the criteria for enabling Dual Scan, which resulted in the machine essentially no longer being controlled by WSUS or Configuration Manager for the purposes of Windows updates.  Therein lies the confusion: how can you keep unapproved feature updates from installing while maintaining control of update management with your existing on-premises tools?    

What we are doing to improve this experience
We’ve gotten enough feedback on this scenario that we have committed to release a quality update for 1607 that allows you to leverage WU for Business controls even in the on-premises scenario; i.e., for “Check online for updates” scans.  You’ll be able to defer feature updates without automatically shifting into Dual Scan behavior.  This policy will be Not Configured by default, and you’ll have to enable it to ensure that your WU client behaves as intended.  We’ll provide more detailed guidance as to exactly how to do this when the quality update to 1607 is released this Summer.  The same update will be released to 1703 before it is declared Business Ready, and this functionality will be part of the Windows 10 platform going forward. 

What you can do in the meantime
If you need to unblock this scenario immediately, then we recommend the following workaround applied to all managed clients:

  1. Set all WU for Business policies to Not Configured.  This ensures that you are not in Dual Scan mode. 
  2. Verify that you have installed the November 2016 Cumulative Update for 1607, or any Cumulative Update more recent. 
  3. Enable the group policy System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features
  4. In an elevated command prompt, run “gpupdate /force”, followed by “UsoClient.exe startscan”
  5. Open the Windows Update UI (wait for the scan to complete), and observe:

Windows Update UI with no Check online link

These steps allow you to perform scans against WSUS/Configuration Manager and access the Microsoft Store, and will prevent feature updates from being installed unexpectedly on machines with this configuration.  This configuration does not allow for any update content to be installed via Windows Update, so if this is a key requirement for your deployment, then our recommendation is to wait for the update to 1607 coming in a few months.

You might have also heard something about “Remove access to all Windows Update features,” which sounds very much like the policy recommended above.  Please note that the behavior of “Remove access to all Windows Update features” is quite different, and should not prove useful in this scenario.

Comments (19)

  1. Matthew says:

    There is a checkbox in Settings for “Defer feature updates” that also seems to enable dual scan mode. It can be checked by regular users.

    Settings -> Update & security -> Windows Update -> Advanced options

    1. Thanks for calling this out. In 1607 there is a UI bug that allows users to still modify this value even when configured to scan against WSUS. We have fixed the bug in 1703.

      1. Matthew says:

        Thanks for confirming that this is a bug! In the meantime, we have implemented a group policy preference on 1607 that will effectively uncheck that box:
        New -> Registry Item
        Action: Delete
        Key Path: Software\Microsoft\WindowsUpdate\UX\Settings
        Value name: DeferUpgrade

  2. Matthew says:

    Is “Do not include drivers with Windows Updates” also considered a WUfB group policy setting that can enable dual scan mode? That is how it seemed to work in our testing.

    1. This should not be the case, since “Do not include drivers with Windows Updates” is outside the “Defer Windows Updates” group policy folder. Can you confirm that this activates Dual Scan behavior with a fresh run on 1607?

      1. Matthew says:

        I will retest the “Do not include drivers with Windows Updates” setting. Its corresponding registry key, ExcludeWUDriversInQualityUpdate, is also mentioned in this post on the Windows Server Blog.

        1. Matthew says:

          “Do not include drivers with Windows Updates” is also documented as a WUfB policy here:

          I’m pretty sure in the results of our testing, but we tested a lot of different scenarios. So I will retest to make sure.

          1. Please ignore that documentation for now: it will be changed to reflect the reality of the scenario.

      2. Matthew says:

        I retested and confirmed that the “Do not include drivers with Windows Updates” policy setting alone was sufficient to enable dual scan mode.

        To test, I configured a freshly imaged system to use WSUS and not be in dual scan mode. I confirmed that it was not in dual scan mode. Then, I enabled the “Do not include drivers with Windows Updates” policy setting on the system. The next WU scan went out to Microsoft and downloaded updates that were not approved on WSUS.

        1. Thanks for confirming, Matthew. I’m guessing you tried this on 1607. Any chance you tested it on 1703?

          1. Matthew says:

            Yes, it was 1607. No, I’ve not tested on 1703.

  3. Anon says:

    For confirmation purpose, is Windows 10 v1511 subjected to any of the ‘Dual Scan mode’ settings with it’s update/upgrade deferment settings? Also, if an upgraded systems coming from v1511 to v1607 had the old WuFB settings for deferring updates/upgrades, would that have any affect to the now v1607 system?

    Thanks for the clarification

    1. Windows 10 version 1511 does not have Dual Scan capabilities, so you can use the “Defer Feature Updates” policies without concern for this behavior taking place. If you have those settings in place, and then migrate to 1607, then you can expect Dual Scan to come into effect. We recommend not using these policies for any machines currently running or planning to install 1607.

      1. Adam says:

        There appear to be different settings based on the version of GPO:

        1607 GPO:
        Select when Feature Updates are received
        Select when Quality Updates are received

        Pre-1607 GPO:

        Defer Upgrades and Updates

        Do the pre-1607 GPO settings affect Dual Scan?

        1. No, Dual Scan was introduced in 1607 (with the Anniversary Update). Note that even the pre-1607 policies will cause Dual Scan behavior on a 1607+ machine. It’s the platform build that matters, not the iteration of the WU for Business policies being used.

      2. Dieter says:

        Hello Steve, the Defer Upgrade GPO settings were recommended to be configured within SCCM.
        The Windows 10 Servicing Dashboard relies on those values to show CB and CBB systems.
        Is there an official update / guidance coming for SCCM admins as mentioned by Michael Niehaus?
        “As confirmed in the comments below by Mr. Niehaus, the Windows 10 Servicing dashboard in ConfigMgr relies on the Defer Upgrade GPO setting (or really the registry value behind this setting) to show CB and CBB systems.”

        “Michael Niehaus
        April 12, 2017 at 5:46 pm · Reply
        Yes, the dashboard is populated by exactly the values you say not to set Still, follow that guidance and ignore the dashboard, to avoid problems caused by setting those values in non-WU for Business scenarios (e.g. dual scan).

        Expect some changes soon too that we hope will simplify this whole discussion.”

        1. This blog post and summer update to the WU client are the changes to which Michael Niehaus alludes in his comment. The documentation for Windows 10 servicing will be revised to reflect this new understanding, and Configuration Manager may publish some guidance in response. If they do not, then you can assume that the WSUS post applies equally well to both WSUS and Configuration Manager environments.

  4. wr says:

    Hey, you have removed the “Coming soon” article, but it is still in the feed and keeps popping up in my reader again. Microsoft’s rss feeds are the most awful feeds in the world. Badly formed, glitchy..

    1. Weird, I unpublished it and marked it Private. I’ve deleted the page now, so it shouldn’t show in your feed anymore. Thanks for the note!

Skip to main content