Stop Feature upgrades and properly manage them via WSUS

Question

In the last few months, systems have been randomly upgrading themselves, the update is not approved within WSUS and is obtained directly from Miccrosoft Servers.

The upgrade to 1709/1703 is not managed by WSUS and needs to be controlled. And the upgrade to the next feature update needs to be properly executed across the business the miniseries any downtime.

Configuring "Defer Feature Upgrades" GPO stopped the direct upgrade to build 1709 - but not the upgrade to 1703 because...

"Now that Microsoft, uh, recommends version 1703 build 15063.483, your “Defer feature updates” setting has expired, and you’re getting the business-ready version of Win10 Creators Update. (This, despite the fact that there’s a massive batch of bug fixes waiting in the wings for 1703.) There is no "Current Branch for Business" anymore, but that "Microsoft recommends" bullet applies in its stead. If you were deferring updates, your deferral just ran out (see screenshot)." - this is news to me!

Source: https://www.computerworld.com/article/3211375/microsoft-windows/win10-machines-with-defer-feature-up....

This is my current Windows Update Configuration under:

DeferQualityUpdates   REG_DWORD   0x0             (not enabled)
DeferFeatureUpdates   REG_DWORD   0x1         (enabled)
BranchReadinessLevel   REG_DWORD   0x20        (set to current branch for business)
DeferFeatureUpdatesPeriodInDays   REG_DWORD   0xb4   (180 days)
ElevateNonAdmins   REG_DWORD   0x0           (Users in the Users security group are allowed to approve or disapprove update )
WUServer   REG_SZ   http://WSUS:8530          (Specified intranet source)
WUStatusServer   REG_SZ   http://WSUS:8530

The upgrade to 1703 is not managed by WSUS and needs to be controlled. And the upgrade to the next feature update needs to be properly executed across the business the miniseries any downtime.

Is there a way to?

• Identify what servers a systems connects to when pulling the feature update and block communications? (i.e. Stop connections to Microsoft Servers through endpoint content control or Boundary Firewall - without effecting Office 365 updates)

What I've done so far

• Understood 1703 is now recommended for business (but I still don't want it)

• Attempted to configure "Do not connect to any Windows Update Internet Locations" local GPO, but it blocked access to WSUS too, despite the following note: This policy applies only when this PC is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy - this is already configured on a Group Policy level but it's being ignored

• Considered blacklisting the following application/files on endpoint management console to prevent the Windows upgrade assistant from running - but haven't had time to test:

  

Solution

Repeating the same answer for Windows 10 circumvents WSUS, which I had given on Server Fault here as well since the OP is making the same mistake.

The solution is very simple, ensure that your copy of Windows 10 does not have any of the following value names listed under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, if you are running Windows 10 OS - impact version: 1511 & 1607.

 DeferFeatureUpdates
 DeferFeatureUpdatesPeriodInDays
 DeferQualityUpdates
 DeferQualityUpdatesPeriodInDays
 PauseFeatureUpdatesStartTime
 PauseQualityUpdatesStartTime
 ExcludeWUDriversInQualityUpdate

Quoting further from the same article "Why WSUS and SCCM managed clients are reaching out to Microsoft Online":

What just happened here? Aren’t these update or upgrade deferral policies?

Not in a managed environment. These policies are meant for Windows Update for Business (WUfB).

Windows Update for Business aka WUfB enables information technology administrators to keep the Windows 10 devices in their organization always up to date with the latest security defenses and Windows features by directly connecting these systems to Windows Update service.

We also recommend that you do not use these new settings with WSUS/SCCM.

If you are already using an on-prem solution to manage Windows updates/upgrades, using the new WUfB settings will enable your clients to also reach out to Microsoft Update online to fetch update bypassing your WSUS/SCCM end-point.

To manage updates, you have two solutions:

1. Use WSUS (or SCCM) and manage how and when you want to deploy updates and upgrades to Windows 10 computers in your environment (in your intranet).
2. Use the new WUfB settings to manage how and when you want to deploy updates and upgrades to Windows 10 computers in your environment directly connecting to Windows Update.

— "Why WSUS and SCCM managed clients are reaching out to Microsoft Online" : This post was authored by Shadab Rasheed, Technical Advisor, Windows Devices & Deployment (9 January 2017), Microsoft Windows Server Team .

NOTE: Be advised that the mentioned Microsoft article's list of Registry value names has typos.

Comments

[Am_I_Helpful]

Please check this solution -> serverfault.com/questions/891295/windows-10-circumvents-wsus‌​/…

[IT Apprentice]

@Am_I_Helpful this would of been helpful if you made a comment rather than linking me to an article. This only generates more questions. I've just read: The solution is very simple (LOL): Ensure that you copy of Windows 10 1703 does not have any of the following value names listed under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windo‌​wsUpdate

[IT Apprentice]

I have several configured as shown above in attempt to stop these updates... I'm awfully confused, I put these measures in place to stop updates.. now I have to remove them..?

[Am_I_Helpful]

It seems you just skimmed through the answer, without even realising that it answers your question as well. Do not configure any policy like DeferFeatureUpdates and DeferFeatureUpdatesPeriodInDays. If these 2 are not configured, your client systems will never talk to outside world and will stay in talk only to WSUS for updates!

[Ramhound]

@Am_I_Helpful - Please be nice. The author is clearly confused. All you have to say is to make sure those policies remain, not configured.

[Am_I_Helpful]

@Ramhound - Thanks Ramhound for the point you made. I tried to be nice(check my username, :)). There was no such comment which was rude/offensive from my side (in my view). Instead, you should also take into account OP's this comment , which shows the immaturity, and sort of rudeness, and unwillingness to accept things.

[Ramhound]

@Am_I_Helpful - Two wrongs don't make a right.. The author clearly is over their head, doesn't give them an excuse for not being nice themselves, but that is a different problem.

[IT Apprentice]

"Do not configure any policy like DeferFeatureUpdates and DeferFeatureUpdatesPeriodInDays. If these 2 are not configured, your client systems will never talk to outside world and will stay in talk only to WSUS for updates!" - I removed those WUFB policies andthey all upgraded to build 1709 (LOL), I'm willing to accept that I'm not going to ship these laptops with build 1607 anymore

[Ramhound]

I remove what I thought was a passive-aggressive action, specifically the "LOL" in your answer, at the very least it wasn't professional. I also improved the sentence following it and combined it with another statement. I do ask you verify this answer applies to 1607 because that is indeed what the author is using.

[Am_I_Helpful]

@Ramhound - Thanks again for the edit; but, I don't see this line I do ask you verify this answer applies to 1607 because that is indeed what the author is using. in my answer. Do you want me to add the same, or would you please like to make the suggested edit?

[Ramhound]

No, I am asking you to verify your answer applies to 1607. You specifically call out 1703 in your answer.

[Am_I_Helpful]

@Ramhound - OK, Thanks for the advice. I've restored the original content from the blog post which mentions that this is applicable to version 1511 and version 1607(though I personally have verified it for version 1703 too).

[Ramhound]

If it works for 1703, and you verified it works, mention that in the answer. Be sure you correct the typos though, don’t have a device, where I can compare the content easily

[IT Apprentice]

I will not be marking this as an answer as the problem remains with no wufb configured - community.spiceworks.com/topic/…

[Am_I_Helpful]

@Naisbitt - IMHO, I don't see how it could not work! Rather, what I'm able to see is that DeferFeatureUpdates policy and others is still set. Anyway, good luck to you mate for finding the solution.

[Am_I_Helpful]

@Naisbitt - I would suggest you to take the help of good system-administrators who'd configure the required group policy as per the Microsoft's blog which I have shared.