Char Jackson wrote:

On Sat, 23 Feb 2019 19:10:01 -0600, VanguardLH wrote:

Paul wrote:

VanguardLH wrote:
Paul wrote:

VanguardLH wrote:

Background Intelligent Transfer Service (BITS) will only use spare
bandwidth. If it is using half of your bandwidth means that you were
only using half and the other half would've been unused.
The OS Upgrade no longer uses BITS. You can try the BITSADMIN
utility (likely deprecated) and see what is going on.

So, if I *disable* the BITS service, the OS upgrade still proceeds?

It would depend as well, on the DoSvc Setting page settings.
If you're not careful, you could turn it off there, as well
as be able to turn it off in GPEDIT. The idea of doing it via
GPEDIT, is so they can't "sneak some through that way".

I was surprised that DoSvc had taken over from BITS. I
can't remember what I was doing, but I had the BITSADMIN
monitor running, the OS was "doing something", and none
of the download activities involved BITS. I have to
assume it was DoSvc running the show.

https://docs.microsoft.com/en-us/win...ization-portal

"Delivery Optimization allows devices to download updates
from alternate sources (such as other peers on the network),
in addition to Microsoft servers.

Delivery Optimization combines partial bits from local devices,
with partial bits from Microsoft servers to update devices
in the network environment. === In the form of a
thousand signed packages

The expected result is reduced bandwidth usage, === YES, by inspection
and a faster update process. === NO, not even close
"

So the staff at Microsoft are temporally challenged. That's got to
explain it. This scheme is "all about the gigabytes" and making
customer machines do the transfers instead. The update process
isn't faster. I think I used to be able to get some of the
DVDs in around 25 minutes or so.

When I tested the DoSvc Peer-to-Peer-LAN feature, it didn't work!

Paul

Ah, the "steal partial downloads from non-Microsoft others". To reduce
load on their own WSUS servers, they employ peer-to-peer incremental
updates.

https://docs.microsoft.com/en-us/win...y-optimization

My property is not Microsoft's. I don't let Microsoft use my computer
nor my bandwidth to incrementally deliver THEIR updates. My host is not
theirs to [ab]use. Like MANY other configuration settings and services
in Windows 10, Delivery Optimization was amongst those that I configure
to keep Microsoft using my host as theirs.

https://www.thewindowsclub.com/turn-...y-optimization

For the same reason that I chose not to become covertly volunteered to
assist Microsoft to deliver Microsoft's updates, I also will not abuse
the hosts of other users to acquire those Microsoft updates.

Do you feel the same way considering that one of the options is to send
to or receive from only "PCs on my local network"?

I totally agree about the "and PCs on the Internet" aspect of the
feature, but within my LAN it seems somewhat reasonable.

I currently have the feature enabled, but the sub-feature "PCs on my
local network" is selected, rather than the second option that includes
"and PCs on the Internet".

Thoughts?

For a multi-host intranet setup, I would use a server version of Windows
on one of them and use WSUS. However, in your setup, you are
distributing the effect of WSUS over multiple hosts to eliminate having
to pay more to get a server edition of Windows.

Hopefully whomever is using one of your intranet hosts decides to not
include the updates in their local cleanup. See:

https://www.thewindowsclub.com/can-i...y-disk-cleanup

I have to wonder what happens for a download of an update that is
corrupted or otherwise refuses to install. Instead of some hosts gets
updated, they get it from the host that has a bad copy of the update, so
all hosts fail to update. I've never had to troubleshoot why an update
fails when using delivery optimization since, after all, how would you
know on which intranet host was where is the bad update? If it were
local, you delete the Software Distribution folder and redo the WU
client to rebuild the local catalog to re-retrieve the failed update.

Delivery optimization is a self-organizing distributed cache of updates.
I haven't investigated to know if a cached update must exist in its
entirety one one host or if it may get split. Seems a means for malware
to manage to infect one host with a corrupted or substitute update and
then have Microsoft's delivery optimization to distribute the malware to
all the other hosts. You might be the only user of all your intranet
hosts but that's not the typical scenario under which delivery
optimization gets used.

https://tools.cisco.com/security/cen...?alertId=55567
https://www.rapid7.com/db/vulnerabil...cve-2017-11829

That one was found and hopefully fixed. Finding one doesn't mean
finding all vulnerabilities. This is another broadcasting protocal that
can affect multiple hosts. Windows 10 had been released in mid-2015 and
it was more than 2 years later that the above vulnerability was exposed.

For home users, yeah, WUDO (Windows Update Delivery Optimization) might
have some advantages -- but how slow is the Internet connection on these
home PCs to connect to Microsoft's own WSUS server? Yes, BITS
(Background Intelligent Transfer Service) is slow to get updates because
it was designed to be that way: not use much bandwidth or CPU cycles so
as not to impact responsiveness of the host to the user. However, users
can use the online catalog to download the updates (and then share with
their other hosts) or use WSUSoffline to build a local cache (that could
also be shared amongst your other hosts). Dial-up users are going to
suffer whether they use WUDO or not.

I would think Microsoft doing full-bandwidth transfers of update files,
especially the big ones, would impact the available bandwidth of the
intranet hosts to communicate with other or for Internet traffic. I
suspect BITS is still employed by WUDO to distribute the updates from
the local caches on each host to the other hosts, so the transfer
remains throttled. Well, that's what I would expect from Microsoft.
However, users have been complaining that WUDO was choking their network
making web surfing very slow or impossible. They had the default of
WUDO getting updates from other Intranet hosts. That means WUDO is not
using BITS to keep the update traffic in the background. So what
happens when you connect a new host that has to get all the updates from
wherever they are cached on the local/intranet hosts? Seems it will
flood the network with all those update transfers and at full speed,
much like an FTP transfer.

Getting information on how WUDO exactly works has been rather fruitless.
However, to be fair, I disabled it, so I haven't been motivated to dig
into how it works. It has choked users networks when getting updates
from web hosts, so how would that not also happen for getting the
updates from local hosts? It has been vulnerable, but is anyone
actually digging into it to find more, if any, vulnerabilities? How
much faster is "faster" when using a distributed cache in an intranet?
There are tons of performance tweaks that may boost performance but
often the change is so miniscule that users will never notice a change.
While you have multiple hosts in your intranet, I doubt that constitutes
the vast majority of home PC setups, and one home PC can't take
advantage of a local cache of updates since that cache would be on the
only host in the home network which already has a cache of updates in
the Software Distribution folder. Personally I don't trust the other
hosts in my intranet because my family aren't as safe as I and they
often commit actions that result in their hosts getting infected. So,
in my case, I configure the router to isolate the other intranet hosts:
all get Internet access but they cannot access each other. I'll fix
their hosts but I'm not letting them touch mine. It's the same idea
that a drowning man takes down the rescuer, so lifeguards tote a buoy on
a rope to toss to the drowning person. If you don't save yourself
first, you cannot save someone else.

I've read reports from users that claim the WU client shows zero updates
available and a poll at the catalog store also shows zero updates
available for the visiting client yet WUDO is consuming a large portion
of the network bandwidth. That hints that WUDO is retrieving updates
that are NOT for your host but for any host. Other hosts that need the
update could get it from the local distributed cache but your host
doesn't need the update. Your host is updating the local distributed
cache with updates your host doesn't need just to have them available
for other hosts that may need them. In effect, WUDO is acting like a
local WSUS server to accumulate a range of updates whether they apply to
your hosts, your other hosts, or none of your hosts. Fully updated
hosts still experienced traffic due to WUDO. Disabling WUDO eliminated
the sometimes excessive traffic which was unnecessary for an already
fully updated host.

The option to share updates only on local hosts might eliminate the
above network choking. If just one of the local hosts had the update
already then share it with the other hosts. The users reporting the
choking (high bandwidth usage) did not mention if they were sharing the
updates only locally or with web hosts. BITS was designed to minimize
impact on the updating host. WUDO does not.

WUDO isn't just for updates but also for Store apps. Since I have WUDO
disabled, I don't have a local distributed cache to look at. Are the
apps simply stored in a cache folder or are they protected against
tampering? Distributing apps to other hosts where the apps could be
modified by one of the hosts involved in the distributed cache could
mean other users don't get the app they expect to get. I'd have to dig
more into WUDO to determine how the updates and apps are protected
against tampering and just how the receiving hosts qualify that the
update or app is what Microsoft's WSUS server would've delivered.

To be honest, I don't think Microsoft came up with WUDO to help users
get their updates more quickly and safely but instead to relieve some of
the load on their own WSUS servers. Co-opting users isn't a new
concept. There was/is a peer-to-peer VPN (I think it was Hola) where
the free users where actually sharing a portion of their bandwidth with
the paid users. That is, freeloaders got the service for free albeit a
bit slower while sacrificing a portion of their bandwidth as a shared
node used by paid users. Not wanting to share a portion of your
bandwidth with other peers meant having to pay for that "privilege".

Bet you're sorry you asked.