Hi,
I'm having a really hard time with the Windos updates. Is there any product
or way around the cache those updates? I know there are for enterprises,
but are there for ISPs?
I'm having a really hard time with the Windos updates. Is
there any product or way around the cache those updates? I
know there are for enterprises, but are there for ISPs?
Windows Updates are not really cacheable because MS changes the contents
of their patches without changing the names of the files. You can read
more here:
http://usefulthings.org.uk/www/caching-windowsupdate-in-squid
--Michael Dillon
Windows Software Update Services doesn't require the end-user to be part
of a domain to get updates. You just need to define the WSUS server as
the source for updates by changing a few registry entries and make sure
the server is available via HTTP or HTTPS to your customers. You can
read more at Microsoft's site.
Also, WSUS is free to run on any Windows server.
-joe
Great if you're running a windows IT type LAN; crap if you're running an
ISP!
http://www.advproxy.net/ - its a Squid distribution for ipcop with an
optional Windows update cache redirector. I don't know how well it'll scale
but it seems to work fine for small home/office environments.
You can always get an Akamai cluster 
That'll serve windows updates
to you, amongst other things.
That said, I know how to make Squid properly cache stuff like Windows Updates;
I just need some spare time over the new year to code it up. Sponsorship to
make it happen sooner is definitely welcome.
Adrian
(One of the remaining public Squid developers.)
Adrian Chadd wrote:
How's it find the WSUS server again?
Adrian
Adrian Chadd wrote:
Great if you're running a windows IT type LAN; crap if you're running an
ISP!Why? It talks TCP/IP.
How's it find the WSUS server again?
Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\WindowsUpdate
Value 0
Name: WUServer
Type: REG_SZ
This seems like a question of how much control ISPs have over customers' PCs at this point. In my day (when we had to push packets up hill through 28.8 kbps modems, both ways...), we used to send out CDs to all our customers that would install web browsers and mail clients, and change the computers' dial-up networking settings to match our network. Changing some registry strings for Windows Update would have been trivial.
The ISPs I've dealt with recently as an end user tend to just send out a cable or DSL to ethernet bridge and let DHCP do the rest. This is progress, as it means devices can move from place to place and just work, but I don't think it provides a way to change registry settings.
-Steve
Steve Gibbard wrote:
To make it work you'd have to get people to change the registry settings
on their computer to use your WSUS server, which can be done. But what do
you do with them after they've cancelled service with you and moved to
some other ISP? Either they end up with a Windows Update that doesn't
function anymore, or they end up using your bandwidth for the rest of
their computer's life to get their updates.
Perhaps it could be done by setting up a windowsupdate.com zone on your
own DNS servers that your customers use and point all of the DNS entries
to your own WSUS server, but I'm sure that comes with it's own set of
problems as well.....
Forrest
Adrian Chadd wrote:
Windows Software Update Services doesn't require the end-user to be part
of a domain to get updates. You just need to define the WSUS server as
the source for updates by changing a few registry entries and make sure
the server is available via HTTP or HTTPS to your customers. You can
read more at Microsoft's site.
Also, WSUS is free to run on any Windows server.Great if you're running a windows IT type LAN; crap if you're running an
ISP!Why? It talks TCP/IP.
This seems like a question of how much control ISPs have over customers' PCs at this point. In my day (when we had to push packets up hill through 28.8 kbps modems, both ways...), we used to send out CDs to all our customers that would install web browsers and mail clients, and change the computers' dial-up networking settings to match our network. Changing some registry strings for Windows Update would have been trivial.
The ISPs I've dealt with recently as an end user tend to just send out a cable or DSL to ethernet bridge and let DHCP do the rest. This is progress, as it means devices can move from place to place and just work, but I don't think it provides a way to change registry settings.
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:
b: you would carry on servicing them and paying for BW, etc
W
(Yes, yes, unless the new ISP gives them a CD that changes the registry settings too...)
Microsoft does not currently have a solution for ISPs. I suggest contacting one of Microsoft's security programs for information
about their current recommendations how ISPs can support customers
using Microsoft products.
Windows Software Update Services doesn't require the end-user to be
part of a domain to get updates. You just need to define the WSUS server
as
the source for updates by changing a few registry entries and make
sure the server is available via HTTP or HTTPS to your customers. You
can
read more at Microsoft's site.
Even though you can make it work, I believe you will be running afoul of
the WSUS Lic. agreement if it's not a corporate LAN/Domain. I don't have
the text of it in front of me, but I remember this issue coming up on
<nntp://microsoft.public.windows.server.update_services>
Since automating clients to use wsus requires either a registry or
local/group policy change on the clients, you would have to find some way
of manipulating this facet as well.
I would say the best course is to contact the wsus/mu team via the above
mentioned newsgroup and see if they'll become more cache friendly with a
future version of wsus. The squid trick seems ideal if only you could be
assured of having the latest files.
~JasonG
Why is it crap? It works on TCP/IP, provides an exact local copy of the
updates without risking MS changing the content of a file without
changing the name, and provides a reporting tool to check update status
on client machines (can anyone say "stop to botnet"?). Even without the
reporting features, you can provide full Microsoft Update to people who
only would normally check Windows Update using WSUS, so you can also
make sure they patch other vulnerable programs.
-joe
Windows Software Update Services doesn't require the end-user to be
part of a domain to get updates. You just need to define the WSUS
server as the source for updates by changing a few registry entries
and make sure the server is available via HTTP or HTTPS to your
customers. You can read more at Microsoft's site.
Even though you can make it work, I believe in doing so you will be
running afoul of the WSUS license agreement if it's not a corporate
LAN/Domain. I don't have the text of it in front of me, but I remember
this issue coming up on
<nntp://microsoft.public.windows.server.update_services>
Since automating clients to use wsus requires either a registry or
local/group policy change on the clients, you would have to find some way
of manipulating this facet as well.
I would say the best course is to contact the wsus/mu team via the above
mentioned newsgroup and see if they'll become more cache friendly with a
future version of wsus. The squid trick seems ideal if only you could be
assured of having the latest files.
~JasonG
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
Yup, transproxying windows updates access works fine.
What I'd like to see is more use of service discovery, but what happens when
someone hacks your WSUS server? Or hijacks your DNS? Or your squid box?
(Come on DNSSEC..)
Adrian
Well, I'll announce when the Squid "static content pretending to be
dynamic content" patches are officially in on the squid blog
(http://squidproxy.wordpress.com/) . It'll also cache other stuff besides
Windows Updates. Now, you might think "Why would I bother?" but then
most small to medium sized networks generally haven't a clue whats actually
going on -on- their network and don't realise what fraction of their traffic
is or could be windows updates and the like, especially in particular
environments like dormitory networks where the rush to grab patches can
and does hurt.
Caching still makes sense. I'll post more numbers as I get these things
deployed. The silly thing is that people -are- using Squid and the like
-very- successfully these days and still see 30% byte savings in some
places - but never really talk about it.
(It also works for stuff like caching Linux updates too; that works Real
Well(tm) when you're running a farm of all the same Linux boxes and
don't want to run a local mirror.)
WSUS is a great idea if you control the client PC. Please don't take me
back to the days where clients manually configured proxy servers on their
machine and then changed ISPs, only to call you when your proxy server
denied them the internet.
Adrian