There is new required reading from Microsoft for all systems administrators who are managing Windows Updates in their organizations. We *strongly* recommend that all of you carefully read the following two articles so that you are aware of this new (and unexpected) behavior of the Windows Update client:
Demystifying “Dual Scan”
Improving Dual Scan on 1607
Microsoft has recently modified the behavior of Windows Update such that if you currently have your clients configured via group policy to point to an internal managed WSUS, it’s possible, depending on how things are configured, that scans for Windows Updates for your target computers might now be bypassing your WSUS and utilizing Microsoft’s public Windows Update servers instead. 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.
IMPORTANT:
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
The group policies mentioned above are located in group policy:
Computer Configuration\Administrative Templates\Windows Components\Windows Update\Defer Windows Updates |
In my particular case I have ‘Configure Automatic Updates’ and ‘Specify intranet Microsoft update service location’ enabled. These are the two standard/typical policies that any organization will have enabled if they are using a WSUS instead of Windows Update or Microsoft Update.
These two policies are located in group policy:
Computer Configuration\Administrative Templates\Windows Components\Windows Update |
Additionally, I also have the ‘Defer feature updates’ setting enabled on my Windows 10 computers. This setting is visible in the ‘Advanced options’ for Window Update Settings control panel, and it’s similar to the group policy ‘Select when Feature Updates are received’ mentioned above.
Note: The ‘Defer feature updates’ UI setting has an underlying registry entry, which will be set to 1 if the ‘Defer feature updates’ box is checked. If the box is unchecked then the value will either be set to 0 or will not exist at all:
Hive: HKEY_LOCAL_MACHINE Key Path: Software\Microsoft\WindowsUpdate\UX\Settings Value name: DeferUpgrade |
The behavior that resulted from having the combination of policies described above enabled on my computer is that all of a sudden my scans for Windows Updates were being performed on Microsoft’s public Windows Update server instead of my internal managed WSUS server. Frankly, I was absolutely *shocked* at this change in behavior. We believe that this behavior should not have been automatically enabled by Microsoft but rather should only have been enabled if/when the administrator turned on this capability. However, we obviously have no control over Microsoft, which means that now we instead must just focus on understanding how to effectively disable this behavior.
IMPORTANT: In late 2017 Microsoft actually removed the UI option checkbox for ‘Defer feature updates’ but it is still possible for the underlying registry entry that controls the actual behavior in Windows to be enabled. In fact, if you had the ‘Defer feature updates’ box checked in the past, then you will likely encounter this very same situation where the UI checkbox disappears even though the underlying registry value is still configured/enabled. This means that you could unknowingly have ‘Dual Scan’ enabled even if you think your settings are all correct. I encountered this issue on my 1607 test computer, and I had to manually alter the registry value since the UI option was removed. The ‘DeferUpgrade’ registry value must be either set to 0 or deleted altogether. If you delete it, make sure to only delete the ‘DeferUpgrade’ value. Do not delete the entire registry key path.
Hive: HKEY_LOCAL_MACHINE Key Path: Software\Microsoft\WindowsUpdate\UX\Settings Value name: DeferUpgrade |
How to Disable “Dual Scan”
Option 1:
One quick and simple way to disable “Dual Scan” so that your computers will only reach out to your internal WSUS and will not perform scans on the public Windows Update servers is to simply disable ‘Defer feature updates’ or set both of the following two policies to ‘Not configured’
‘Select when Feature Updates are received’
‘Select when Quality Updates are received’
Additionally, make sure that the aforementioned registry value for ‘DeferUpgrade’ is not set to 1. You may either set it to 0 or delete the value altogether.
Option 2:
If you want or need to leave one of the policies mentioned in ‘Option 1’ enabled, then you may instead enable a new policy ‘Do not allow update deferral policies to cause scans against Windows Update’. You can find it in group policy:
Computer Configuration\Administrative Templates\Windows Components\Windows Update |
If you don’t see this policy in your list of available policies in the Group Policy console then you most likely just need to apply the latest cumulative update for your OS, after which you should see the option. For version 1607 it arrived in August 2017, while for version 1703 it arrived in October 2017.
Additional Notes
- More details on how to determine where your computers are *actually* searching for updates: Deciphering Dual-Scan Behavior in Windows 10
- In April 2018 Microsoft posted a new blog entry on the topic of ‘Dual Scan’ that has some helpful information and is definitely worth reviewing:
Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed - If you try to enable the ‘Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communication settings\Turn off access to all Windows Update features’ group policy then you might start seeing:
Error -102: Failed to execute the search. HRESULT: -2145124306 in BatchPatch.0x8024002E -2145124306 SUS_E_WU_DISABLED non managed server access is disallowed
- If you try to enable the ‘Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do not connect to any Windows Update Internet locations’ you might start seeing:
Error -102: Failed to execute the search. HRESULT: -2145103860 in BatchPatch.0x8024500C -2145103860
- If your targets are configured to point to your WSUS but your WSUS is not online then you will likely see one of the following errors:
Error -102: Failed to execute the search. HRESULT: -21451079240x8024402c -2145107924 WU_E_PT_WINHTTP_NAME_NOT_RESOLVED
Error -102: Failed to execute the search. HRESULT: -2145123272
0X80240438 -2145123272