The Windows 10 estate in our environment consists primarily of v1511 and v1607. All new computers (and any being re-imaged) get Windows 10 1607 installed, which is our ‘Production’ build. We have Windows 10 updates deployed to the All Unknown Computers collection which ensures that updates are installed during OSD. This is Windows 10 “Security Updates” and “Critical Updates” only and does NOT include feature updates.
The End User Computing team are yet to green light Windows 10 1703 hence the 1703 feature update has not been approved in the Windows 10 Servicing plans. However, we noticed recently that 2L Engineers click on “Check for updates” AFTER build has completed and not only are there additional updates to install but the Windows 10 1703 feature update get installed too. Now, this is interesting because, like I said, the feature update hasn’t been approved in the Windows 10 servicing plans. (Note, I’m specifically referring to the ‘Check for updates’ button and not the “Check online for updates from Microsoft Update” link.)
Now, I’ve done a lot of testing and reproduced the issue in my lab and confirmed the culprit was Dual Scan. Enabling certain Windows Update for Business (WUfB) group policy settings (or Registry or MDM settings) triggers the Dual Scan behaviour which scans both internal WSUS or SCCM SUP servers as well as Microsoft Update servers for patches and feature updates. Annoyingly, it ignores the local WSUS or SUP servers and gives precedence to Windows Update. This is exactly what was happening in our environment. Consider the following screenshot of WindowsUpdate.log from a newly installed Windows 10 1607 device after having clicked on the Check for updates button and installed the feature update. It confirms Windows 10 is reaching out to Microsoft Update servers:
So what actually triggered the Dual Scan behaviour? Generally speaking, using certain group policy settings related to WUfB enables Dual Scan. Microsoft mentions some of these settings in “Using ConfigMgr With Windows 10 WUfB Deferral Policies”. In our environment we had the Specify intranet Microsoft update service location setting set to our internal SUP server. In “Manage settings for software updates” Microsoft recommends that this setting should not be enabled using Group Policy because the machine policy received from SCCM will populate this setting in the local policy on the client computer and point to the SUP servers. Having the policy set using Group Policy in addition to the local policy being enabled by SCCM causes undesirable side effects, one of which is Dual Scan.
How do we stop this happening? For Windows 10 607 you will need to install the August cumulative update (or better yet KB4039396). For Windows 10 1703 you will need the October cumulative update installed. Then you will need to install the latest Windows 10 1709 administrative templates which includes a setting called “Do not allow update deferral policies to cause scans against Windows update” which will disable the Dual Scan behaviour. It’s important to note that simply updating the administrative templates will not be enough. You need the above cumulative updates/KB’s installed to be able to take advantage of the new group policy setting to disable Dual Scan.
After having taken the above actions in my lab I carried out further testing and found no additional updates, feature updates or otherwise, were available to install after OSD completed, thereby disabling Dual Scan successfully.
Me, Myself and IT 