Demystifying "Dual Scan"

Update: a new post on the upcoming feature to support Dual Scan in the on-premises scenario has been published. Please refer to that post for details on how to use the new policy and what to expect going forward.

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 their MDM equivalents, or the underlying registry keys corresponding to either set of policies] is configured:

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

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

• Anonymous
  May 05, 2017
  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
  • Anonymous
    May 05, 2017
    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.
    • Anonymous
      May 05, 2017
      The comment has been removed
    • Anonymous
      June 07, 2017
      The comment has been removed
      • Anonymous
        June 12, 2017
        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.
• Anonymous
  May 05, 2017
  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.
  • Anonymous
    May 05, 2017
    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?
    • Anonymous
      May 05, 2017
      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/
      • Anonymous
        May 05, 2017
        “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-wufbI'm pretty sure in the results of our testing, but we tested a lot of different scenarios. So I will retest to make sure.
        • Anonymous
          May 05, 2017
          Please ignore that documentation for now: it will be changed to reflect the reality of the scenario.
    • Anonymous
      May 05, 2017
      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.
      • Anonymous
        May 05, 2017
        Thanks for confirming, Matthew. I'm guessing you tried this on 1607. Any chance you tested it on 1703?
        • Anonymous
          May 08, 2017
          Yes, it was 1607. No, I've not tested on 1703.
• Anonymous
  May 05, 2017
  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
  • Anonymous
    May 05, 2017
    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.
    • Anonymous
      May 08, 2017
      There appear to be different settings based on the version of GPO:1607 GPO:Select when Feature Updates are receivedSoftware\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdatesSelect when Quality Updates are receivedSoftware\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdatesPre-1607 GPO:Defer Upgrades and UpdatesSoftware\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradeSoftware\Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradePeriodSoftware\Policies\Microsoft\Windows\WindowsUpdate\DeferUpdatePeriodDo the pre-1607 GPO settings affect Dual Scan?
      • Anonymous
        May 09, 2017
        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.
    • Anonymous
      May 11, 2017
      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 · ReplyYes, 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."
      • Anonymous
        May 16, 2017
        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.
        • Anonymous
          May 16, 2017
          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.
• Anonymous
  May 08, 2017
  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..
  • Anonymous
    May 08, 2017
    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!
• Anonymous
  May 17, 2017
  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?
  • Anonymous
    May 24, 2017
    That's exactly what it means. Store access and automatic updates from that endpoint are unimpeded by the recommended workaround.
• Anonymous
  May 24, 2017
  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?
  • Anonymous
    May 24, 2017
    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.
• Anonymous
  June 05, 2017
  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.
  • Anonymous
    June 12, 2017
    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.
• Anonymous
  June 12, 2017
  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?
  • Anonymous
    June 20, 2017
    It is not yet released for 1607 or 1703. You'll see an update when each becomes available.
• Anonymous
  June 12, 2017
  The comment has been removed
  • Anonymous
    June 12, 2017
    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?
    • Anonymous
      July 19, 2017
      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.
  • Anonymous
    June 20, 2017
    Please treat this post as the latest authoritative guidance on the dual scan scenario.
• Anonymous
  June 12, 2017
  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.
  • Anonymous
    June 20, 2017
    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.
    • Anonymous
      June 28, 2017
      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.
      • Anonymous
        July 13, 2017
        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.
• Anonymous
  June 13, 2017
  Hi Steve,ETA for summer update to the WU client?Thanks,Tero
  • Anonymous
    June 20, 2017
    We're aiming to have it available broadly before September. So far, it's looking good.
• Anonymous
  June 26, 2017
  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????
  • Anonymous
    July 13, 2017
    The comment has been removed
    • Anonymous
      August 03, 2017
      Is there a KB that we can search on in the catalog for this?
      • Anonymous
        August 03, 2017
        If you want to get the update today, then you can look for KB4022723 on the Catalog. Otherwise, the change will be included in the August update coming next week. We'll put out a blog post to clarify this in the next few days.
• Anonymous
  June 28, 2017
  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?
  • Anonymous
    July 13, 2017
    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.
• Anonymous
  June 28, 2017
  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.
  • Anonymous
    July 13, 2017
    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.
• Anonymous
  July 06, 2017
  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?).
  • Anonymous
    July 13, 2017
    The comment has been removed
    • Anonymous
      July 26, 2017
      Thanks Steve. I'm not sure I understand why an ad-hoc scan against Windows Update couldn't still be allowed even when WSUS is set as the primary update source. What I was suggesting above was so that remote users could still download updates from Windows Update but only those that had been approved in WSUS. ie. WSUS determines which updates get installed while the download source could be any approved repository. If something like that was implemented I'd then suggest providing a button on clients that allows admins to run an ad-hoc scan that bypasses WSUS controls for non-feature updates ...or perhaps allow them to choose whether feature updates are included in the ad-hoc scan.
      • Anonymous
        August 01, 2017
        Thanks for the feedback (and clarification), Raimond.
    • Anonymous
      July 26, 2017
      Steve will the August 2017 update also make this change for 1703 machines?
      • Anonymous
        August 01, 2017
        No, the August 2017 update is only for 1607; a similar update to 1703 is coming soon.
• Anonymous
  August 09, 2017
  At first I loved Windows 10 (1511), but every version after that gets worse. All IT departments want is something reliable and consistent. First of all, IT should be able to decide what updates get pushed out and WHEN. I also get tired of the start menu changes on every feature update and pushing the "EDGE" browser that nobody cares about. Come on Microsoft, you guys were doing awesome until 1607 came out. Now managing windows 10 is a complete mess. Someone needs to turn things around there.
  • Anonymous
    August 10, 2017
    Thanks for the feedback, Bob. Windows 10 encourages a model that allows IT departments to do less--the idea is to monitor rather than tightly manage, and to only step in when issues arise. It's a paradigm shift from the historical permission-based deployments (i.e., nothing happens unless admins say so), but, once embraced, we think that it will ultimately reduce the cost of servicing. Getting there is certainly an iterative process, as we're learning more with each release, and we appreciate the feedback as we move forward.Can't say our team had much to do with the Edge and Start menu changes, but I'll see about relaying that input, as well.
• Anonymous
  August 16, 2017
  This worked great for me and my 1607 and SCCM deployment issue.HOWEVER! I just deployed 1703 to machines, and now that its running 1703, the problem is back.Do these settings need to be retracted for 1703, and which ones? because it fixes my issues for 1607, but now causes the exact problem for 1703 :(
  • Anonymous
    August 17, 2017
    Glad to hear it's working for you on 1607! The update for 1703 is in the pipeline, and should be available in the next few months. Until then, you're best served by using the workarounds listed in this post. Specifically, "Turn off access to all Windows Update features" will prevent the feature updates from being offered. In conjunction, you'll want to set any deferral policies to Not Configured.
    • Anonymous
      August 18, 2017
      Hey Steve - I think you misread my comments.I've applied these changes listed in this thread, and it fixed my 1607 issues.However, upgrading that same PC to 1703, and applying those same policies and settings - i'm now back to my SCCM/WSUS install(pushes) not applied and being rejected.in short-this fix was applied to 1607 and worked great. applying it to 1703 isn't working
      • Anonymous
        August 21, 2017
        welp - it just took. so I think i'm ok.perhaps the policies did not kick in, or SCCM didn't check in, in time
      • Anonymous
        August 28, 2017
        Hmm, can you be more specific as to what you mean by "this fix"?