North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: windows update cache

  • From: Robert Bonomi
  • Date: Fri Sep 28 15:47:56 2007

> From owner-nanog@xxxxxxxxx  Fri Sep 28 13:05:54 2007
> Cc: Seth Mattinen <sethm@xxxxxxxxxxxx>, nanog@xxxxxxxxx
> From: Warren Kumari <warren@xxxxxxxxxx>
> Subject: Re: windows update cache
> Date: Fri, 28 Sep 2007 13:32:36 -0400
> To: Steve Gibbard <scg@xxxxxxxxxxx>
>
>
>
> On Sep 28, 2007, at 1:05 PM, Steve Gibbard wrote:
>
> >
> > On Fri, 28 Sep 2007, Seth Mattinen wrote:
> >
> >>
> >> Adrian Chadd wrote:
> >>> On Fri, Sep 28, 2007, Joe Johnson 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:
> a: their windows updates would break or
> b: you would carry on servicing them and paying for BW, etc

Silly idea: can one plug in _two_ servers in the registry item for WSUS
and will windows update try the second one ifit can't contact the first one?

If so, set up  local server in RFC 1918 space, make it the preferred one, with
MS's"real" server as the alernate.

If _not_, one could play the same game through DNS -- with a 'wsus.{isp}.com'
that resolves differently for queries from inside your address-space than it
does for queries from outside your space.  for an 'inside' query, it returns 
an A for the local server, for an 'exteral'query, it returns a CNAME pointing 
to MS's real server.

In both scenarios, the customer system keeps working without requiring any
further changes when the customer is 'no longer a customer'.  In the first
there is a query delay, while it fails over to te 2nd adress -- as upate
tends torun in background "no huhu" applies.  In the 2nd case, you take an
"occasional" hit from a former  customer doing a DNS query.  With a _large_
TTL on the CNAME record, this should be 'way down in the noise'

Has the potential to get a bunch of traffic off upstream links.