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:

dual-scan-with-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 (48)

  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
        Hive: HKEY_LOCAL_MACHINE
        Key Path: Software\Microsoft\WindowsUpdate\UX\Settings
        Value name: DeferUpgrade

      2. Darin S says:

        What's really too bad, is that the registry key that backs the "Defer feature updates" checkbox in 1511/1607 is what SCCM leverages to identify a machine as CB or CBB (as of SCCM build 1610). We set HKLM\Software\Microsof\WindowsUpdate\UX\Settings\DeferUpgrade=1 in our image to default all machines to CBB, and then made collections to advertise the next CB to any users that unchecked the box. In our experience, the DeferUpgrade value hasn't enabled dual scan for us.

        However, the new UI value for the Readiness dropdown in does. Having HKLM\Software\Microsoft\WindowsUpdate\UX\Settings\BranchReadinessLevel=32 enables dual scan, while a setting the value to 16 or 0 disables dual scan. Note this is not the GPO policy key, but the UI key that backs the selection from the Settings panel. Seems really counter inutitive that choosing Current Branch would result in using internal WSUS servers which Current Branch for Business lands on getting scanned against Windows Update. Seems like it would the be other way around.

        Also, this combination of Powershell commands is really helpfull in figuring out if Dual Scan is enabled or not. Look for the IsDefaultAUService:True to see which service your machine will scan against.

        $MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
        $MUSM.Services

        1. Yes, Configuration Manager used the CB/CBB distinction for a while, but that is being phased out. The general guidance is that CB/CBB settings on the client only matter when you're talking directly to Windows Update. Note that this does not affect Servicing Plans, which are pivoted on the content itself, rather than the machine settings.

  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.
        https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/

        1. Matthew says:

          “Do not include drivers with Windows Updates" is also documented as a WUfB policy here:
          https://docs.microsoft.com/en-us/windows/deployment/update/waas-configure-wufb
          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
        Software\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdates
        Select when Quality Updates are received
        Software\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdates

        Pre-1607 GPO:

        Defer Upgrades and Updates
        Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgrade
        Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradePeriod
        Software\Policies\Microsoft\Windows\WindowsUpdate\DeferUpdatePeriod

        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?

        https://home.configmgrftw.com/windows-10-servicing-configmgr-confusion/
        "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.

          1. MikeCure says:

            Correct. What's noted here applies to ConfigMgr as Niehaus noted. If additional guidance is required as a result of the changes in the summer update, we'll make those accordingly.

  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!

  5. Kirk says:

    Can Store applications and Edge continue to update via the store in this interim suggested communication? The post says you can continue to access the Store, but does that include updating those Store apps?

    1. That's exactly what it means. Store access and automatic updates from that endpoint are unimpeded by the recommended workaround.

  6. Jose says:

    In regards to the steps to unblock the scenario, can you elaborate on what the CU from November has to do with the Dual Scan behavior?

    1. The recommended workaround involves a policy that was added in the 1611 Cumulative Update. If you don't have that update (or later) installed, then you should not expect to see the policy.

  7. James Selix says:

    Am I blind or missing something here? Where is a list of the policies that are considered to be WU for Business policies?
    "Set all WU for Business policies to Not Configured. This ensures that you are not in Dual Scan mode".

    There does not appear to be any links to a list of the policies in GPO that are considered to be WU for Business. These types of blogs annoy me in that they just talk about stuff but fail to actually show you the proper steps or if they do the notes are very vague. Where is a table of the policies in 1607 and GPO that are considered to be related to "WU for Business" Is it just the feature defer options? intranet address for WSUS? Again, where is this list of policies located at?

    Off topic but who in Microsoft thought dual scan was a good idea for enterprises? Enterprises need to fully control updates and how it affects users and applications esp with how bad of a job with QC the last year of updates have had. Glad Microsoft finally realized this but it shouldn't take nearly the WHOLE IT industry for this to change; perhaps listen to the IT admins of companies since we do this each day and have to deal w/the repercussions of a bad patch that gets pushed to thousands of users which then breaks their machine and stops productivity dead in it's tracks.

    1. As summarized a little earlier in the post, as of today the WU for Business policies are "Select when feature updates are received" and "Select when quality updates are received". Both of them live in the "Defer Windows Updates" folder, which is another reliable way to identify them. Thanks for clarifying this point.

  8. Raimond Barbaro says:

    Hi, regarding the new policy that will allow the deferral of feature updates without automatically shifting into Dual Scan behavior, was this ever implemented in 1703? Also has the 1607 quality update that includes it been released yet? If so do you have any instructions for enabling it?

    1. It is not yet released for 1607 or 1703. You'll see an update when each becomes available.

  9. Raimond Barbaro says:

    Hi Steve, regarding the article from your Server Team: "https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/" ? Is the guidance here still correct? In particular I'm not sure about these 2 settings:
    1. “Do not include drivers with Windows Updates”. The post indicates setting this to anything other than 'Not Configured' will activate Dual Scan (via corresponding registry key ExcludeWUDriversInQualityUpdate) . Can you please confirm this is still the case?
    2. Can you confirm the “Do Not Connect To Windows Update Internet Locations” policy setting definitely activates Dual Scan? Also does the “Do Not Connect To Windows Update Internet Locations” policy setting have any interaction with the “Specify settings for optional component installation and component repair” (Administrative Templates > System) setting if the latter is set to download content from Windows Update?
    Thanks.

    1. Raimond Barbaro says:

      I've tried disabling “Do Not Connect To Windows Update Internet Locations” as we'd like to allow Windows Store apps to continue updating. After gpupdate and restarting the client we found the output from the powershell commands Darin S posted above indicated WSUS was still the default AU service. A bunch of other online services did start to show up but WSUS was listed as as the default. Does this mean Dual Scan is still disabled?

      1. As mentioned in the blog post, if you are not configuring any policies that reside in the Defer Windows Updates folder, then you will not activate Dual Scan behavior. In such a case, WSUS should be the default AU service. The other way to know that Dual Scan is not enabled: your WSUS is able to deploy Windows updates to the client in question. If Dual Scan is in effect, then WSUS cannot do this.

    2. Please treat this post as the latest authoritative guidance on the dual scan scenario.

  10. Raimond Barbaro says:

    Another issue we encountered with Dual Scan occurred when we updated our ADMX/ADML from 1511 versions to 1607 or 1703 versions. Our Windows Update GPO still had the old (1511) 'Defer Upgrades and Updates" policy set to Disabled and as we had already installed the latest ADMX files we could no longer access the setting to change it to Not Configured. In the new ADMX/ADML files this setting was replaced with the 2 separate policies "Defer Feature Updates" and "Defer Quality Updates". We ended up performing surgery on the 2 new Windows Update ADMX and and ADML files and added the 'Defer Upgrades and Updates' related fragments to each from the 1511 ADMX and ADML files. I'm posting this because other people might be unaware that they are in this situation as when they updated from 1511 to 1607 (or 1703) ADMX/ADML files the 1511 'Defer Upgrades and Updates" policy would have ended up hidden from the UI but still be applied in the background (and the corresponding 'DeferUpgrades' registry key still being set on clients). In our case this hidden setting caused Dual Scan to activate even with all the other suggested policy set correctly. Steve, you might want to do something about this as it kind of breaks the assumption of backwards compatibility of GP Administrative Templates we all grew up with.

    1. Yes, we saw that migration issue after the fact, as well. The upcoming update will also change the client behavior so that Disabled does not trigger Dual Scan, so you won't need to perform such surgery going forward.

      1. Raimond Barbaro says:

        I still think you should provide guidance to people who haven't updated their ADMX/ML files yet, advising that the old ‘Defer Upgrades and Updates' policy should be disabled in all GPOs before doing the update or they won't be able to change it after the update. Either that or provide some tool or workaround for people who have already done the update and may be in this bind and not know it.

        1. That's a good consideration. We typically encourage disabling deprecated group policies prior to migration as a best practice to avoid unexpected behavior, though I don't know that this guidance has been provided for update/upgrade deferral specifically.

  11. Tero Alhonen says:

    Hi Steve,

    ETA for summer update to the WU client?

    Thanks,
    Tero

    1. We're aiming to have it available broadly before September. So far, it's looking good.

  12. Frank says:

    Even after configuring all these additional polices and setting System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features my machines (1703) are still showing this: Making request with URL https://sls.update.microsoft.com/SLS. It is hit and miss really, it will work for a whole day on our local WSUS then decide it wants to dual scan.

    What are we doing wrong????

    1. That is indeed bizarre: it should behave deterministically regardless of the settings you've chosen. The policy we're adding to 1607 in the August monthly update (actually releasing next week as a non-security update, if you want to pick it up early from Microsoft Update Catalog) will allow you to prevent dual scan entirely, and might be your best bet for eliminating this sporadic behavior.

  13. Raimond Barbaro says:

    In the article from your Server Team: “https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/” the guidance is to Disable the "Configure Automatic Updates" policy because it's now only used to control WUfB. Can you please confirm this is the case or can we somehow use it to control non-dual scan behaviour from a WSUS only source?

    1. Disabling this policy is equivalent to setting AU = 0, which means your PC will never automatically scan. This is unrelated to the scanning behavior (i.e., WSUS vs. WSUS and WU), and you'll have the same problem if you kick off a manual scan even with the PC configured this way. We'll have to update this old guidance to maintain parity in the descriptions.

  14. Raimond Barbaro says:

    Steve, one last request if I may, can you please consider providing more categories to use in views to filter out updates in WSUS. For example 32bit/64bit/Itanium, Expired Updates, non-English specific updates, non-English Language Packs. It would greatly aid admins in cleaning out unneeded updates from their WSUS databases/repositories.

    1. Thanks for the input. Unified Update Platform (UUP) makes a clear separation between x86 and x64 content. Until that conversion happens (timeline still TBD), you'll see all architectures bundled in each feature update.

  15. Raimond Barbaro says:

    Hi Steve, the ideal behaviour for Windows Update within enterprises running WSUS would be that no matter the update download source (Windows Update, Microsoft Update or WSUS) that only updates that have been approved in WSUS are actually downloaded/installed. IS this something we'll be able to do with the fall update (or is something that can be done now and I've missed something?).

    1. Thanks for the feedback, Raimond. After you install the August 2017 monthly update (releasing in about a month) on your 1607 machines, you'll be able to use the deferral settings to accomplish what you describe, except that interactions with Windows Update will be governed by these deferral settings, rather than WSUS approvals. Because of the reality of Windows 10 feature updates being offered on Windows Update, the controls must be on the client policy to enable the scenario you describe. As it stands, you can defer a given build up to one year after it is released, which is ideally enough time to deploy the build version (e.g., 1703) in your environment without interference from Windows Update.

      You can use the workaround described in this post to completely cut off communication with Windows Update; however, you'll also miss out on the ability to scan against it ad hoc to supplement what you've approved in your WSUS. We'd obviously prefer that you stay connected to Windows Update in some fashion, and are working to make that a good experience.

Skip to main content