V5 Update and proxies

Hi folks.

My machine was one of the lucky ones to get an automatic upgrade to V5
windows update. Unfortunately, I'm in a corporate environment and all
traffic needs to go through a proxy.

As far as I understand, when you go to Windows Update, the current
user does all the checking for available updates. This uses the
current user's proxy settings. All is good.

When you click install, it hands everything off to the Automatic
Updates service (might as well, it's got to do the automatic
downloading, so why not get it to do the forced downloading, too).

The only problem is that the Automatic Updates service is an NT
service, so it doesn't have the current user's proxy settings. You can
use proxycfg to set up the proxy to talk to, and the bypass list, but
it can't send any authentication!

So, the only way I've got v5 to work is to run a proxy on my own
machine, provide that proxy with credentials to authenticate to the
real proxy, and use proxycfg to make automatic updates talk to my "in
between" proxy.

Is this the only way I can make v5 work in an authenticating proxy
environment?

This issue does raise other questions, though. Since the Automatic
Updates component is an NT service, we have to have an NT service
making outbound network calls. Fair enough. Anyone with a two way
firewall (one that blocks outbound traffic as well as inbound traffic;
Windows XP's firewall is only one way) will need to allow this service
to get through the firewall. Again, no problem. The issue is that the
Automatic Updates service is being hosted by svchost.exe, which is the
generic service host process. svchost.exe is used to host literally
dozens of services. Which means that if you need to open a firewall
for svchost.exe, you're opening it for a *lot* more services than you
actually need to. This is obviously a security risk - just what XPSP2
is dead against...

Does anyone have any thoughts on this?

I'm in the same situation in my netowrking enviroment.

I just don't know why the method of web updates were changed so much cos hte
V4 method worked great in these enviroments. Well hopefully in later releases
of V5 and the Automatic Update Service their will be extra settings to
authenticate to proxys

"Matthew Ellis" wrote:

> Hi folks.
>
> My machine was one of the lucky ones to get an automatic upgrade to V5
> windows update. Unfortunately, I'm in a corporate environment and all
> traffic needs to go through a proxy.
>
> As far as I understand, when you go to Windows Update, the current
> user does all the checking for available updates. This uses the
> current user's proxy settings. All is good.
>
> When you click install, it hands everything off to the Automatic
> Updates service (might as well, it's got to do the automatic
> downloading, so why not get it to do the forced downloading, too).
>
> The only problem is that the Automatic Updates service is an NT
> service, so it doesn't have the current user's proxy settings. You can
> use proxycfg to set up the proxy to talk to, and the bypass list, but
> it can't send any authentication!
>
> So, the only way I've got v5 to work is to run a proxy on my own
> machine, provide that proxy with credentials to authenticate to the
> real proxy, and use proxycfg to make automatic updates talk to my "in
> between" proxy.
>
> Is this the only way I can make v5 work in an authenticating proxy
> environment?
>
> This issue does raise other questions, though. Since the Automatic
> Updates component is an NT service, we have to have an NT service
> making outbound network calls. Fair enough. Anyone with a two way
> firewall (one that blocks outbound traffic as well as inbound traffic;
> Windows XP's firewall is only one way) will need to allow this service
> to get through the firewall. Again, no problem. The issue is that the
> Automatic Updates service is being hosted by svchost.exe, which is the
> generic service host process. svchost.exe is used to host literally
> dozens of services. Which means that if you need to open a firewall
> for svchost.exe, you're opening it for a *lot* more services than you
> actually need to. This is obviously a security risk - just what XPSP2
> is dead against...
>
> Does anyone have any thoughts on this?
>