Re: windows update cache
Adrian Chadd wrote: On Fri, Sep 28, 2007, Seth Mattinen 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 Data:http://secret.server:8530 Value 1 Name:WUStatusServer Type:REG_SZ Data:http://secret.server:8530 Works for me at $dayjob without AD and I don't need to play with weird solutions. (Disclaimer: I am not a windows expert, it's my weak point actually, so I have no idea if this is portable, I'm just saying it uses standard TCP/IP to talk to WSUS.) ~Seth
Re: windows update cache
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. One could try to transparently proxy requests to windows update over to the WSUS server. No idea if that'll work though. I'm no windows expert, nor was I trying to provide some total solution, I was just trying to point out it uses TCP on port 8530 and one could try to use that to their advantage. ~Seth
Re: windows update cache
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. ~Seth
Re: windows update cache
> From [EMAIL PROTECTED] Fri Sep 28 13:05:54 2007
> Cc: Seth Mattinen <[EMAIL PROTECTED]>, nanog@nanog.org
> From: Warren Kumari <[EMAIL PROTECTED]>
> Subject: Re: windows update cache
> Date: Fri, 28 Sep 2007 13:32:36 -0400
> To: Steve Gibbard <[EMAIL PROTECTED]>
>
>
>
> 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.
Re: i think the cogent depeering thing is a myth of some kind
> since i appear to be reaching the aforementioned web server by a path that > includes cogent-to-nlayer, i think this part of the plain text is inaccurate. route-views has no paths showing cogent/limelight and cogent/nlayer. > 7 p6-0.core01.sjc04.atlas.cogentco.com (66.28.4.234) 4.183 ms > 8 g3-3.ar1.pao1.us.nlayer.net (69.22.153.21) 2.637 ms is someone in paix-pa(?) helping nlayer out? -- --tariq
