windows update cache

Joe Johnson joe at sendjoeanemail.com
Fri Sep 28 19:24:48 UTC 2007


> And, even if it did, once the customer leaves and goes to another ISP

> they would likely still be pointing at your server -- this means that:
> a: their windows updates would break or
> b: you would carry on servicing them and paying for BW, etc

AT&T doesn't care that their crapware stops working on my PC after I
leave, and (at least, back in the day) the updates to the built-in AV
software only run over their network (internal DNS). Setup the DNS for
the server to only exist on-net, so if they leave it stops resolving.
Then, if they don't uninstall your "software" (an installer package
thrown together to add the registry entries), what do you care?

Now, that's not very altruistic, but let's face it: this isn't a perfect
world hypothetical we're talking about. The best solution for making
sure people don't bog down the network with traffic to Windows Update is
to add more bandwidth. There is no extra layer of failure, no new
hardware, nothing changed to the routing path of traffic to the
internet, just a fatter pipe.

That's not the cheapest solution to El Salvador, so caching would
probably be best for Miguel. Since the last mile probably isn't as big
of an issue, it is great to move things to the inside of the network.
His choice just has to be which layer in the stack he wants that cache
to be located. Squid is a good idea for most things, but MS gets hinky
on the Windows Update stuff. They pull a bunch of crap with file content
that makes it a pain for someone in IT on my side to troubleshoot BITS
if the ISP is doing straight caching (like with squid). WSUS is
application-layer and aware of the end-machine. It stores the updates on
the server to provide a central location, and now runs on SQL 2005 (so
there is some level of scalability for the application).

I don't envy Miguel, though. This is a tough decision and he'll have to
test the loads and see how much he can pull from WSUS before it craps
out or test squid to see if it causes even more update headaches with
Automatic Updates.


-joe

-------------------------------------------------
Joseph A. Johnson, MCSE, MCP, A+
Chief Technology Officer
Riverside Consulting Group, Ltd.

Email:   joe at riversidecg.com
Web:     www.riversidecg.com
Phone:   312-231-8315






More information about the NANOG mailing list