none
WSUS settings ignored on Windows 10 1607, client downloads KB3194496 directly from M$ RRS feed

  • Question

  • I found a client today that was updating KB3194496 directly from Microsoft servers instead of WSUS. We run WSUS on a Server 2008 R2 machine.

    I already found out that Win10 clients needed to go to M$ to get the Anniversary Update Version 1607 and other "upgrades", so I had some clients get 1607 from M$ over the last couple of weeks. But as far as I have seen, the clients should go back to the WSUS for any subsequent updates.

    This is a 800 MB update I think. Will all my clients on 1607 do this? So much for using WSUS. Can this behavior be stopped?

    Incidentally, this client updated with 100% status report to the WSUS server earlier today... I am not sure before or after going to the M$ server. So it is somehow using both WSUS and M$ updating. I have never heard of this, and I need a M$ comment on this. I am frustrated... and is this fixed on either Server 2012 or 2016?

    Monday, October 3, 2016 5:28 PM

Answers

  • Hi,

    the links I posted, should show that we support WSUS 3.0 SP2 fully, Anne recommended an upgrade/migration in case you want to deploy the feature updates (next Windows 10 versions).

    Steve replied to the "Updates being downloaded from Microsoft Update instead of WSUS" issue already:

    Yes, there is a new feature in 1607 called Dual Scan that is intended to allow you to connect to Windows Update for Business and still get third-party/other updates from WSUS as needed.  This mode automatically goes into effect when WU for Business policy is enabled and the machine is configured to be managed by WSUS--we wanted to avoid creating a whole new policy for this scenario, so we used a combination of existing policies.

    The confusion came when folks were [reasonably] using the Defer Upgrades setting in a WSUS environment.  Running 1511, there is no impact; however, as soon as you upgrade to 1607 with these settings active, your machine begins scanning both WU and WSUS.

    In short, this is a known issue, and we'll be shipping a patch to the client to correct it.

    Thursday, September 22, 2016 10:35 PM
    Avatar of Steve Henry [MSFT]

    Microsoft

    Setting the policies I mentioned above + removing any deferupgrade (WUfB) settings should prevent this from reoccurring until the patch comes (no ETA yet).

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Saturday, October 8, 2016 6:05 AM

All replies

  • Good news:

    This client successfully installed 3194496. Great. I manually rebooted it and watched it happen.

    Very bad news:

    But... Houston, we have (another) problem. The "Update Status" window shows this:

    "Updates are available.

    • Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB3194496)."

    Huh? The Update History shows that this can't be right:

    "Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB3194496)

    Successfully installed on 10/3/2016"

    This client is a Windows 10 Pro desktop. It stays connected to the network all the time, although it is shutdown when not in use.

    The Advanced Options are set to:

    Give me updates for other M$ products...

    Defer feature updates

    Use my sign in info to automatically...

    Tuesday, October 4, 2016 7:49 AM
  • Welcome to the club, I have a case open with MS for the same issue.  Let me tell you, it's really awesome to have 20 plus PC's ignoring WSUS and endlessly downloading stuff from the internet, but never completing and pegging your internet connection.  We've had to block WUS IP's at our firewall in order to stabilize internet access.
    Tuesday, October 4, 2016 6:12 PM
  • had the same issue. Wsus installet but when KB3194496 was downloading from the client they use all of my internet connection when the uploads arrived at 45%. I tried to disabled WUDO on the clients but nothing changes. I have more than 50PC. why?

    Tuesday, October 4, 2016 10:14 PM
  • in 2012 isn't fixed because i had the same problem with WSUS installed on 2012 Standard win 10 pro client. The update is using all of my internet connection when arrives at 45% of the total. 

    https://drive.google.com/open?id=0B9teX-OaD_SJSDZOTDQtTmNHMFU

    Tuesday, October 4, 2016 10:25 PM
  • Hi Someone special,

    1. Since you are updating Win10 clients, it's suggested to upgrade your WSUS server to 4.0 version as soon as possible, WSUS server 2008R2 won't support all updates for Win10 clients;

    2. During my pervious test, win10 1607 clients have some issues updating from WSUS server, such as cumulative update 1607, with no internet access, clients will stuck at 0% downloading from WSUS server. So, it may due to clients unable to download from WSUS server, then download from Internet. (My WSUS server is 2012R2 with latest version)

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, October 5, 2016 4:53 AM
    Moderator
  • my WSUS version running on win server 2012 Standard is 6.2.9200.17646 but i had the same problem, internet connection is used during the download
    Wednesday, October 5, 2016 6:32 AM
  • Hi all,

    try the following for the Delivery Optimization setting:

    Windows 10 1511 doesn’t have a Bypass mode, you can use “HTTP only” mode 0 to skip Delivery Optimization peer checks on closed networks

    In Windows 10 1607 we should configure Bypass mode:

    “Bypass” (mode 100).

    More details:

    https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/


    We could change the world, if God would give us the source code.

    Wednesday, October 5, 2016 7:21 AM
  • Hi Someone special,

    1. Since you are updating Win10 clients, it's suggested to upgrade your WSUS server to 4.0 version as soon as possible, WSUS server 2008R2 won't support all updates for Win10 clients;


    Anne, That may be true, but I have a few comments.

    #1, this is something I knew about prior to posting. It would help to post a link to the exact statements from M$ regarding the deprecation of Windows 2008 R2 regarding WSUS and Windows 10 updates. I think it bears repeating.

    #2, I would like to remind you that Windows 2008 R2 is still a supported operating system. It doesn't seem to make sense that it is not supported for the new PCs arriving on the network. M$ has pushed the vendors to market Windows 10 for new PCs... yet it suffers a severe issue with interoperability. Updating is a major function of PCs, and has been for a decade or more. To bring to market a defective OS like Windows 10 that cannot properly operate in a corporate environment.... is simply difficult to swallow. None of the marketing that I saw mentioned that it was only going to work with Server 2012. It's already a bit ridiculous that they show up as "Windows Vista." Who figured out that silly joke? Even that should get a hotfix.

    #3 In #2, I presuppose that Microsoft has planned for the obsolescence of Server 2008 R2 by preventing Windows 10 to update properly. This must be one of those back room, "we have to get Server 2016 rolled out quickly to corporate" ideas. But the problem is that Server 2016 is not ready, and Windows 10 is just ever so slightly so. While we might plan to upgrade perfectly fine hardware (or VMs) to Server 2016 from 2008 R2, it sure would be nice to do so in baby steps. This seems to me to be a gut-wrenching, hard way to learn this lesson. We can't even test the Windows 10 clients at this rate.... not without a bunch of extra legwork. Why can't this OS be plug and play? I guess IT people are supposed to run into the boss's office this week screaming,

    "Microsoft has done it again. We need money for a new server, and we all know how IT and management like to do this in an emergency... and as of October 2016, we've got one! Yippee! Let's call our vendor now and ask for a new Server 2012 system and see if they laugh."

    I'd rather not get fired ... or sent to the looney bin.

    In any case, it sounds like Server 2012's WSUS has a problem supporting Windows 10 anniversary updaters, too, even if it is more supported. Will this issue get fixed at the client level? After a manual fix or something? Is this happening with Server 2016 RTM? Three strikes and yer out??

    Thursday, October 6, 2016 6:56 AM
  • Hi,

    Steve Henry, the current WSUS Product Manager, published a series of blog posts on this topic (in chronological order):

    https://blogs.technet.microsoft.com/wsus/2015/12/03/important-update-for-wsus-4-0-kb-3095113/

    https://blogs.technet.microsoft.com/wsus/2016/01/22/for-those-on-wsus-3-0-sp2-or-sbs-2011/

    https://blogs.technet.microsoft.com/wsus/2016/09/15/update-on-wsus-3-0-sp2-end-of-life/

    Please have a look through them and post back any questions that are still open.

    Thank you,

    Andrei


    We could change the world, if God would give us the source code.

    Thursday, October 6, 2016 7:25 AM
  • https://blogs.technet.microsoft.com/wsus/2016/09/15/update-on-wsus-3-0-sp2-end-of-life/

    Please have a look through them and post back any questions that are still open.

    Thanks a bunch Andrei. I posted a moderated response to the link I quote above, so hopefully Steve will say something about this issue. My contention is that the KB3194496 update should be in WSUS 3.2 and not be a manual-only update. The previous cumulative update to Windows 10 1607 came over WSUS.


    But to be honest, I wanted KB3194496 to mature for a few weeks before I approved it for Windows 10 1607 clients.... and imagine my consternation when at least one of them robbed me of this opportunity, and despite settings to the contrary, installed it without my input... while a user was logged in and using it, too.


    I guess the switch from BITS to Delivery Optimization could be going poorly. Someone introduced a bug somewhere into the Windows client is my best guess. I told Steve that it may not be his WSUS problem... and the blame may be the people writing the update code for Windows 10 1607.


    Thanks for all of the people who reported the same issue on WSUS 4.0. :) That deflects some of my blame for running WSUS 3.2!

    Thursday, October 6, 2016 7:39 PM
  • Hi,

    the links I posted, should show that we support WSUS 3.0 SP2 fully, Anne recommended an upgrade/migration in case you want to deploy the feature updates (next Windows 10 versions).

    Steve replied to the "Updates being downloaded from Microsoft Update instead of WSUS" issue already:

    Yes, there is a new feature in 1607 called Dual Scan that is intended to allow you to connect to Windows Update for Business and still get third-party/other updates from WSUS as needed.  This mode automatically goes into effect when WU for Business policy is enabled and the machine is configured to be managed by WSUS--we wanted to avoid creating a whole new policy for this scenario, so we used a combination of existing policies.

    The confusion came when folks were [reasonably] using the Defer Upgrades setting in a WSUS environment.  Running 1511, there is no impact; however, as soon as you upgrade to 1607 with these settings active, your machine begins scanning both WU and WSUS.

    In short, this is a known issue, and we'll be shipping a patch to the client to correct it.

    Thursday, September 22, 2016 10:35 PM
    Avatar of Steve Henry [MSFT]

    Microsoft

    Setting the policies I mentioned above + removing any deferupgrade (WUfB) settings should prevent this from reoccurring until the patch comes (no ETA yet).

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Saturday, October 8, 2016 6:05 AM
  • Yes, there is a new feature in 1607 called Dual Scan that is intended to allow you to connect to Windows Update for Business and still get third-party/other updates from WSUS as needed. 

    Running 1511, there is no impact; however, as soon as you upgrade to 1607 with these settings active, your machine begins scanning both WU and WSUS.

    In short, this is a known issue, and we'll be shipping a patch to the client to correct it.

    Setting the policies I mentioned above + removing any deferupgrade (WUfB) settings should prevent this from reoccurring until the patch comes (no ETA yet).

    Ok, so I caught you guys. "Known issue" indeed. Thanks for saying, "It's a bug, Some one Special, thanks for reporting it." :) This took 5 days to confirm that the client is going rogue here and that there are some idiosyncratic adjustments I can make to work around it.

    I guess disabling "Defer upgrades" isn't enough. I am not exactly sure if I had selected "WU for Business" policy. I know I had perused the limited number of Windows 10 client policies and found them wanting.... the last I checked. But that may have been in 2015 for all I know. I actually recently saw the M$ website that described "WU for Business," but this may have predated Windows 10 rollout.

    I definitely remember trying to download the Windows 10 administrative templates back in 2015, and I gave up because the blogs said that they were not available yet and I should keep checking back (yeah, right). I found that quite distasteful at the time... and in the meantime, Windows 10 has really started to show up in my network as the free update from Windows 7 was being pushed.

    Am I alone is finding this client rollout a bit... buggy? Have you ever heard the old saying that you shouldn't try and reinvent the wheel? How about, you've got the cart before the horse? Maybe don't jump the gun?

    Sunday, October 9, 2016 3:07 AM
  • Andrei,

    Also, when I did a Google search for "Dual Scan" and "Windows 10" it did not bring up anything. I assume that the search engines will take note of this and link to this Technet question. I have never heard of Dual Scan in reference to Win10, or that it was enabled after 1607. Windows Update for Business is new to me, but I suppose it is what I intend to use in my environment.

    Sunday, October 9, 2016 3:15 AM
  • Thank you for reporting this problem. More details about WUfB and Delivery Optimization are documented on the following blog from the 16th of August: https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/ It might shed some light on the whole situation. Best regards, Andrei

    We could change the world, if God would give us the source code.

    Tuesday, October 11, 2016 7:10 AM
  • Any ideas when this issue will be resolved?
    Friday, October 28, 2016 7:23 PM
  • My MS-Case solved the Problem! Solution in the following GPO: Do Not configure "Turn off Windows Update device driver searching" (Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings\)

    Now my Clients report and download to/from the internal WSUS! Good luck!


    Monday, October 31, 2016 10:32 AM
  • @Huck5678 what is the problem that you are facing?

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Monday, October 31, 2016 10:34 AM
  • If I configure a Windows 10 1607 PC to be CBB via Group Policy it ignores WSUS and downloads Windows Updates directly from the Internet.
    Thursday, November 3, 2016 2:33 AM
  • Windows 10 1607 is currently CB and it cannot be configured to be CBB. You will only be able to do this when it will be flagged as CBB, which should normally be this month (release date+4 months, so 1607+4=1611).

    This page should be updated when that happens.

    https://technet.microsoft.com/en-us/windows/release-info.aspx

    So for now we should remove those keys as they will turn on Dual Scan, which causes your system to go online for updates.


    We could change the world, if God would give us the source code.

    Thursday, November 3, 2016 7:01 AM
  • Can someone point to the final resolution or another thread that answers this question:

    We have server 2012 r2 running WSUS 4.0 and all appropriate KB patches applied per various Microsoft articles such as 3095113, 2919355 and 3159706.  We are running Windows 10 Pro 1607 and 1511 and both OS's report to WSUS but all client PCs randomly obtain updates from the Internet consuming all available bandwidth.

    I have downloaded the 1607 admx files for group policy and that only contains group, internet, LAN and None as possible settings.  Any advice would be appreciated.

    Thursday, November 3, 2016 2:52 PM
  • Hi Alkshalsk,

    check if you have any of the following policies enabled and disable them:

    • DeferQualityUpdate
    • DeferQualityUpdatePeriodInDays
    • PauseQualityUpdate
    • DeferFeatureUpdate
    • DeferFeatureUpdatePeriodInDays
    • PauseFeatureUpdate
    • ExcludeWUDriversInQualityUpdate

    Afterwards please create your own thread to follow-up this in more details.

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Thursday, November 3, 2016 3:33 PM
  • So, say for instance most of my users have the CBB setting defined by group policy (except for pilot users, which would be CB).  If I manually upgrade one of my CBB user's via ISO that's currently running 1511 to 1607 (still CB) I have to remember to switch their group policy setting to CB or their Windows Update will switch to Dual Scan?  It seems like this setting should only apply when Windows Update is looking for new feature updates.  What is the purpose of Dual Scan in this situation? 
    Thursday, November 3, 2016 5:42 PM
  • Any ETA when the fix referenced here will be available?
    Thursday, December 1, 2016 1:54 AM
  • How do we take advantage of the DeferUpgrade setting and completely shut off "Dual Scan" mode on 1607?

    We have CBB machines that access a WSUS server on the LAN and have a poor bandwidth connection to the Internet. We need to completely shut off "Dual Scan" mode on these machines. It seems like this isn't possible to do in 1607. Is this what the upcoming patch is intending to address? If that's the case, we need this patch ASAP. Otherwise we need to remain on 1511 indefinitely.

    Wednesday, December 14, 2016 1:59 PM
  • Hi Andrei, Thanks for your post on this which appears to be the authoritative one on the issue.

    Do you know if there is yet any date or details on when this will be fixed? Removing all WUfB settings in GP(including the new 'Select when Feature Updates are received' policy in 1607) is still the only way to get clients working with WSUS. This is not a solution going forward as it effectively puts them on CB - OK if WSUS is in control, but not if they get nudged to look at WU for any reason when there is a CB upgrade available.

    Thanks,

    Jon

    Tuesday, January 17, 2017 9:50 AM