Deciphering “Dual Scan” Behavior in Windows 10

A few weeks ago I wrote about the relatively new “feature” from Microsoft that they are calling “Dual Scan.” You can (and should) read more about that here so that you understand, in detail, what they have done: ‘Dual Scan’ Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’.

The quick summary is that Microsoft introduced new behavior to the Windows Update Agent (WUA) recently that has the potential to significantly impact your Windows update routine, especially if you are not aware of the change. If you’re aware of the change, then you should be able to digest it and determine what, if anything you want or need to do in your environment to make sure that your Windows update routine is not impacted negatively. If you are currently using a WSUS server in your environment, then you might be impacted. If you do not use WSUS and if you do not plan to use a WSUS, then you probably do not need to concern yourself too much with all of this stuff.

They describe “Dual Scan” as follows:

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.

Problems with “Dual Scan”

I see three primary issues with “Dual Scan.”

  1. I have to question Microsoft’s motive with this change. I simply don’t believe that any enterprise that is currently using a Windows Server Update Services (WSUS) server wants to have two sources for updates. I honestly don’t think that enterprises are interested in getting Windows Updates from Windows while getting other update content from WSUS, so who is this change really for? Is it for Microsoft customers or does it actually somehow serve Microsoft in some yet to be understood or revealed way? Call me a cynic, but I’ve been working in the industry for a long time, and this is one of the most peculiar changes I recall ever seeing from Microsoft, and I have yet to really make sense of the motivation behind the decision to add the feature, and more importantly the decision for how to introduce it.
  2. The introduction of this new behavior left a lot to be desired. Essentially the way it was rolled out was after applying updates one month, all of a sudden the “Dual Scan” behavior was enabled on our systems without our knowledge or “consent.” I put “consent” in quotes because arguably we are consenting to everything that Microsoft does simply by using their products. All I mean when I say “consent” is that we did not enable the feature/functionality. It was simply enabled all of a sudden with no advance warning and no notification that anything had changed. And yet our computers, which are (and were) configured to use our local WSUS for their Windows update source, all of a sudden started scanning for updates against Microsoft’s public Windows update servers instead of our own WSUS. This was confusing, to say the least, and it required a number of hours to then figure out what was happening, why it was happening, and how to modify the behavior to suit our needs. Quite a bit of testing had to be done in order to make sure we fully understood the behavior. The problem here is that we (and many, many companies on the planet) use WSUS to control which updates are presented to our systems. And yet all of a sudden our systems could have been installing updates that we did not approve. And I can pretty much guarantee that in some organizations unapproved updates were installed on systems as a result of the way this change was introduced with no notification whatsoever.
  3. Determining if “Dual Scan” is enabled is easy to do only if you know how to do it. However, if you weren’t paying close attention, then you likely did not even know it was introduced/enabled, and you certainly would not know how to determine if it is enabled or not. And even if you were paying very close attention and discovered that the behavior was occurring, you still would have to go out of your way to find out the best way to determine if the behavior is affecting your systems or not. Microsoft did not provide any obvious way to see in Windows if the feature is enabled. Instead it requires the administrator to take it upon herself/himself to learn how to determine what’s happening “under the hood.”

How To Confirm If “Dual Scan” Is Or Is Not Enabled

As mentioned in my previous posting about “Dual Scan”, “Dual Scan” is automatically enabled when a combination of Windows Update group policies or their underlying registry entries are configured. Please refer to the previous posting for more details about which combination of policies cause it to be enabled. The problem is that even if you have determined that you have or do not have the combination of policies enabled that would cause “Dual Scan” to be enabled, you still need a way of determining if it *actually* is enabled or not.

Automated method for determining if “Dual Scan” is enabled:

Beginning with the March 2019 release of BatchPatch there is an action Get ‘Dual Scan’ configuration available under Actions > Windows updates as well as Actions > Get information. BatchPatch essentially automates the manual process that is described below for determining whether or not “Dual Scan” is enabled on a given computer.

Manual method for determining if “Dual Scan” is enabled:

Note, if you are NOT using a local WSUS, then you probably do not have to worry about any of this, as the “Dual” part of “Dual Scan” refers to WSUS plus Windows Update. If you do not have a WSUS, then you will not have “Dual Scan” enabled because you simply cannot have dual scanning when there is only a single scan source available/accessible to your computers.

If your computers are configured via Group Policy (using the ‘Specify intranet Microsoft update service location‘ policy) to use a WSUS server as their update source, then the following PowerShell script, when run on a target computer, should reveal Windows Server Update Services as your Default AU Service for that computer.

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

You may also use BatchPatch to execute this script by inserting the following text into a BatchPatch ‘Remote command (logged output)’, which is available under ‘Actions > Execute remote process/command’

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$ServiceManager = New-Object -ComObject 'Microsoft.Update.ServiceManager';$ServiceManager.Services"

Now, if your computers are configured to use a WSUS (using the ‘Specify intranet Microsoft update service location‘ policy) but you notice in the script results that ‘Windows Update’ or ‘Microsoft Update’ is your Default AU Service, which means that ‘IsDefaultAUService’ will be set to TRUE for either ‘Windows Update’ or ‘Microsoft Update’, then you know that “Dual Scan” is enabled on the computer, which means that effectively speaking its update source for Windows updates will NOT be your local WSUS and will instead be Windows Update or Microsoft Update. To disable “Dual Scan” please refer back to my previous “Dual Scan” posting to see how to do that.

This entry was posted in Blog, General, Tutorials and tagged , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.