Using WSUS with Windows 10 1607?

Note:  Consider this post obsolete and replaced by, which offers more detail and clarity around the behavior of Delivery Optimization in both Windows 10 1511 and 1607.

For those of you who have started deploying Windows 10 1607 (edit: and Windows 10 1511), you might notice a change in the behavior of the Windows Update agent for PCs that are configured to pull updates from WSUS.  Instead of pulling the updates from WSUS, PCs may start grabbing them from peers on your network, leveraging the Delivery Optimization service for referrals to other PCs that have already obtained the content.  This change should generally help reduce the amount of network traffic being generated for both quality (monthly) updates and feature updates, offloading that traffic from the WSUS server.  It will add some additional traffic between each client PC and the Delivery Optimization service on the internet, as it has to talk to this internet-only service in order to get a list of peers.

If the Windows Update agent can’t talk to the Delivery Optimization service (due to firewall or proxy configurations), or if there are no peers able to provide the content, it will then go ahead and grab the content from the WSUS server.

There is a new Group Policy setting available if you want to disable this behavior, e.g. because you are already using BranchCache for peer-to-peer sharing.  To do this, you need to set the “Download Mode” policy under “Computer Configuration –> Administrative Templates –> Windows Components –> Delivery Optimization” to specify “Bypass” mode, which will result in the client always using BITS to transfer the content from WSUS (with BranchCache jumping in to provide the peer-to-peer capabilities through its integration with BITS):


Of course to set this policy, you need the latest ADMX files, which can be downloaded from and are also included in Windows 10 1607 and Windows Server 2016.  (The “Bypass” setting wasn’t available in previous versions.)  See for details on how to update the Group Policy central store with these latest ADMX files, if you are using a central store.

Comments (22)
  1. Thanks for this information

  2. Russell says:

    Does this setting affect SCCM SUP in any way? I also found it confusing that Microsoft named this new release of Win 10 ADMX templates “Version 1.0”.

    1. No, no affect on SCCM, since it takes care of downloading updates itself.

  3. Quentin Gerlach says:

    Wait a sec — you’re saying that this ability only works if the clients can talk to an internet-only service that dishes out a list of peers?? We can’t setup some kind of intranet-only setup?? How does an enterprise know if their clients are only pulling from other clients that they approve of? This seems like a very slippery slope – unless I’m misunderstanding something….

    1. See my follow-up post for more detail. You can control what set of clients are considered, or you can choose to use BranchCache instead (or no peer-to-peer at all, although I wouldn’t suggest that).

  4. Sese says:

    Thanks for the tip! I was wondering why it took me hours to install two simple updates when I was building a 1607 reference image in MDT. I had to add Run Command Line task in the task sequence to cut the huge delay. The command I added was “reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization /v DODownloadMode /d 64 /t REG_DWORD /f”

    1. Just curious: Why did you pick the value 64? That doesn’t appear to be valid, so I would expect it to use the SKU default (see my next post for details).

  5. NickDorak says:

    The Help section in the GPO does not state what the default actions are for Disabled or Not Configured.

    1. See my follow-up post – it explains that in more detail.

  6. CervezaGallo says:

    If we are using SCCM and WSUS for updates – what’s the effect of the GPO?

    1. There is no impact with ConfigMgr – it takes care of downloading the update itself, then tells the Windows Update agent to install the already-downloaded package.

  7. Sebastian says:

    Our 1607 Clients don’t see the cumulative Update KB3176495, no matter if they are running 14393.0 or 14393.10.
    We have set the Download Mode to bypass through GPO.
    The update was downloaded by our WSUS yesterday, so it is ready for deployment.

    At first the 1607 clients want to go to the internet to download updates, when we hit the search for updates button.
    We get an error code 08x8024401b, which means that our proxy is blocking the download, which is correct.
    But at first they should communicate with WSUS not with the Internet.
    When we send a wuauclt /reportnow command from the client, we can see the timestamp in the WSUS Console.
    So communication to WSUS should work.
    But WSUS says no Updates required, 100% installed
    WSUS is running under W2012R2 (6.3.9600.18324).
    Will there be an update for WSUS to be able to deploy updates to 1607 clients?

  8. Do you have any tips or information for those affected by what seems to be a bug in version 1607 where clients cannot update from WSUS because downloads get stuck and event logs show services like the Windows Update service, BITS, and others related to Windows update repeatedly crashing? Since there have only been a couple updates for version 1607 that are already a part of my image the updates that are trying to get installed mainly relate to Office 2016 in my environment.

    1. We are currently investigating this issue. If you are running into this, please contact Microsoft Support. (Strangely enough, I can’t duplicate the issue.)

  9. PepperdotNet says:

    Thanks for this. I had already discovered this particular policy and enabled it before upgrading some of my local users to 1607. Unfortunately it seems that Windows Update in 1607 and WSUS do not like each other very much.

    What I am encountering now is that many of those 1607 clients exhibit very strange behavior as relates to WSUS:
    – Massive delays in reporting status, if it ever reports at all. “Last contact” is recent but “Last status report” is very old.
    – The console shows “Version” is 10.0.14393.0 no matter which CU the client has installed.
    – I’m finding that it is very rare that a 1607 client will actually install a Windows CU from WSUS, I’m having to go to each machine and deploy the .msu by hand to get them up to date. Windows update shows downloading updates with some random percentage between zero and 100 every time I go to look at it, it doesn’t finish and install in most cases. Once I manually install the Windows CU and reboot, the other updates (office, whatever) will download and install normally.

    My WSUS is running on Server 2012 R2 with the latest fixes including the one that everyone had a fit about with the manual steps after install to upgrade the database and fix the web.config file.

    1. Z says:

      I am getting basically the same issue as Pepper, while also running Windows Server 2012 R2. I have set everything you specified in: .

      Installing 1511 updates don’t seem to have the same issue at all, and PeerCacheing enabled or disabled does not seem to make a difference in speed.

      1. Richard P says:

        also seeing problems getting updates. I can get past this in a new build by installing the latest CU as a package but clinets updated via WSUS to 1607 from 1511 cannot download any updates.

        1. Bob says:

          I’m seeing the same thing. It appears only the CUs are handing. Defender definitions are installing from WSUS.

          Windows 10 clients that updated to 1607 connect to WSUS. It show updates needed but then hangs while downloading with 0% percentage downloaded. Windows update log shows “no information” for every entry. Killed bits and wuauserv, deleted “Software distribution” folder. Restarted services. Still same hanging. Very frustrating.

          Downloaded 1607 CUs from Microsoft. Tried to install directly on one test client. The install hung at the very start of installing. Task manager showed no update process running and stayed at near 0% use. Restarted. Windows update log has nothing installed. Yet when try to reinstall CU it fails stating “already installed” when it clearly never installed.

          Build a test server 2016 tp5 wsus server. Tried using that with windows 10 1607 clients. Same result. Handing on downloading of CU updated.

          Very frustrating

      2. Z says:

        I left two systems on for about 14 hours, the update status is still at 44%. I looked through the event log and noticed this piece of information under the setup log, and it seems to repeat the message every 10 minutes or so.

        Message 1: ” Initiating changes for package KB3176495. Current state is Resolved. Target state is Staged. Client ID: WindowsUpdateAgent ”

        Message 2: ” Package KB3176495 failed to be changed to the Staged state. Status: 0x800f0816

        Is anyone else having this problem noticed these logs?

  10. j.hutchinson says:

    i have server 2008 R2. applying this msi file to import the admx did nothing for me. currently my org is using Build 1511 for our lab pc’s and want 1607 via WSUS. is this only a server 2016 feature within GPO?

  11. j.hutchinson says:

    i have server 2008 R2. is this only a server 2016 feature within GPO?

    1. j.hutchinson says:

      please disregard that post. downloaded RSAT on Win 10 and the setting is there. thanks.

Comments are closed.

Skip to main content