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