Update (10/23/17): Microsoft has provided a new GPO in 1709 ADMX that (helps) resolve this issue! Go here and learn what’s needed.
So, this is an extremely frustrating situation I recently ran into within the organization I work for. Following the Official Microsoft Installation Procedures, I installed SCCM CB 1702 and configured Windows 10 updates using System Center Configuration Manager (see here).
Despite triple checking my work and banging my head against the wall, I could not for the life of me figure out why some of our Windows 10 devices were still downloading/installing their updates from Microsoft Update (directly – versus installing the updates I’m deploying over SCCM). Notice I said some. Even though they were all receiving the exact same GPO’s – some devices were reaching out to Microsoft to download their updates even when a WSUS server was manually defined via SCCM.
The short answer? After finding a buried blog post from the Windows Server team back in January I have realized that Microsoft contradicted themselves.
Instead of repeating their blog post, please see the attached image (my emphasis in red).
Are you freaking kidding me, Microsoft? If anyone at any time has modified the local machine’s settings for Windows Update for Business, e.g. setting the configuration to Defer Upgrades (1507 & 1511), Defer Feature Upgrades (1607), changing to Current Branch for Business (1703), or even disabling these settings via GPO, the computer will now ALSO download updates directly from Microsoft? Allegedly referred to as a “dual scan” scenario, what this truly is is a terrible bug that was not caught months ago. Keep reading to learn of the official fix.
If you can’t tell, I’m frustrated. I’m frustrated because as mentioned in the beginning of this article, I followed the SCCM configuration steps outlined by Microsoft themselves. And despite following them to a T – our company was put into a terrible position where devices were saturating Internet links when Windows 10 updates were released. This is not okay.
What’s further frustrating is reading the comment section on the Microsoft Blog that brought this to my attention. So many good questions were asked. So much clarification was needed. Not a single reply was given by Microsoft – and then comments were closed.
Great support here, guys.
What you need to do to avoid this:
- Remove ANY GPO that modifies Windows Update settings. This includes disabling Windows Update, enabling Windows Update, setting it to “Check for Updates but not download”, etc. Doesn’t matter. Remove them all.
- Remove ANY GPO that refers to “Defer Updates” / “Defer Upgrades” / “Defer Feature Updates” / “Set As Current Branch” / “Set As Current Branch for Business”
- There are unfortunately numerous potential naming conventions for the same GPO as Microsoft has changed their mind on the specific wording since RTM (1507) was released. Which ADMX you have loaded into AD will change the GPO verbage.
- Create a GPP (Group Policy Preference) GPO which deletes the following registry keys:
Why so many? Why do they seem redundant? Because as mentioned above, Microsoft can’t seem to decide on a name for these features and each version of Windows has a different registry (or GPO setting) for the same functionality. Incredibly obnoxious, but this list is the only solution I could come up with to resolve the issue. See here if you want to get a headache trying to understand what all these mean. Side note: this link isn’t perfect. They misspelled a few keys.
Below are some screen shots our team sent out to the various office IT admins – asking them to never modify these settings when setting up a new machine. The problem here is that once a machine is managed by SCCM (and WSUS/updates are configured) these settings are supposed to be hidden. Unfortunately, if the setting was modified prior to the SCCM client being installed, it’s possible the setting remains. Now, since we have a GPO configured that deletes all potential reg keys, this shouldn’t be a problem (in theory) – however I would advise against modifying these settings regardless if you intend to patch your devices via SCCM.
In my experience, after following the (ridiculous) preceding steps, we finally have SCCM patching all Windows 10 devices successfully, and no longer downloading updates from the Internet.
Hope this helps!
Until next time..