|
|
I have one client PC not updating.
The output from the WSUS Client Diagnostics Tool is:
WSUS Client Diagnostics Tool
Checking Machine State
Checking for admin rights to run tool . . . . . . . . . PASS
Automatic Updates Service is running. . . . . . . . . . PASS
Background Intelligent Transfer Service is running. . . PASS
Wuaueng.dll version 7.0.6000.374. . . . . . . . . . . . PASS
This version is WSUS 2.0
Checking AU Settings
AU Option is 3 : Notify Prior to Install. . . . . . . . PASS
Option is from Policy settings
Checking Proxy Configuration
Checking for winhttp local machine Proxy settings . . . PASS
Winhttp local machine access type
<Direct Connection>
Winhttp local machine Proxy. . . . . . . . . . NONE
Winhttp local machine ProxyBypass. . . . . . . NONE
GetCurrentUserIEProxy. . . . . . . . . . . . . . . . . . FAIL
VerifyProxy() failed with hr=0x80070002
The system cannot find the file specified.
Press Enter to Complete
|
|
In article <B3DC1923-A3B4-4313-9E91-F927F2263C99
[ at ]microsoft.com>, Steve[ at ]discussions.microsoft.com says...
Did this client have a name change since it was first
connected to WSUS?
I ran Windows Update as if connected to SUS on the
client, it downloaded updated software to the client and
in a few minutes it appeared on the WSUS server, then
downloaded all the required updates.
|
|
"Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
news:B3DC1923-A3B4-4313-9E91-F927F2263C99[ at ]microsoft.com...
[Quoted Text] >I have one client PC not updating.
>
> The output from the WSUS Client Diagnostics Tool is:
> Checking Proxy Configuration
> Checking for winhttp local machine Proxy settings . . . PASS
> Winhttp local machine access type
> <Direct Connection>
> Winhttp local machine Proxy. . . . . . . . . . NONE
> Winhttp local machine ProxyBypass. . . . . . . NONE
> GetCurrentUserIEProxy. . . . . . . . . . . . . . . . . . FAIL
>
> VerifyProxy() failed with hr=0x80070002
>
> The system cannot find the file specified.
0x80070002 - ERROR FILE NOT FOUND
The machine probably cannot find the auto-proxy file specified in the IE
configuration.
Luckily that shouldn't affect your WUA operation, but it apparently affects
the ability of the Client Diagnostic Tool to properly complete.
As a workaround, I suggest you disable ALL proxy configurations for IE, and
rerun the Client Diagnostic Tool to focus on the WSUS issues. Then, having
resolved that, you can return to troubleshooting why the system can't find
the IE proxy config file, or whatever else is causing the failure in
detecting the IE proxy config settings.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Thanks for the replies.
I should have mentioned in the original post, the odd thing is I don't have
any proxy
settings in IE as we don't use a proxy so I'm not sure what to disable. Its
a WIndows XP SP 2 PC which was upgraded from IE 6 to IE 7.
The PC does show up in WSUS console as haveing 12 updates outstanding. It
just won't dowmnload them.
Thanks
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "Steve" <Steve[ at ]discussions.microsoft.com> wrote in message > news:B3DC1923-A3B4-4313-9E91-F927F2263C99[ at ]microsoft.com... > >I have one client PC not updating. > > > > The output from the WSUS Client Diagnostics Tool is: > > > Checking Proxy Configuration > > Checking for winhttp local machine Proxy settings . . . PASS > > Winhttp local machine access type > > <Direct Connection> > > Winhttp local machine Proxy. . . . . . . . . . NONE > > Winhttp local machine ProxyBypass. . . . . . . NONE > > GetCurrentUserIEProxy. . . . . . . . . . . . . . . . . . FAIL > > > > VerifyProxy() failed with hr=0x80070002 > > > > The system cannot find the file specified. > > 0x80070002 - ERROR FILE NOT FOUND > > The machine probably cannot find the auto-proxy file specified in the IE > configuration. > > Luckily that shouldn't affect your WUA operation, but it apparently affects > the ability of the Client Diagnostic Tool to properly complete. > > As a workaround, I suggest you disable ALL proxy configurations for IE, and > rerun the Client Diagnostic Tool to focus on the WSUS issues. Then, having > resolved that, you can return to troubleshooting why the system can't find > the IE proxy config file, or whatever else is causing the failure in > detecting the IE proxy config settings. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E> > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx> > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com> ..... > > > |
|
One odd thing I dont know if this throws any light on the problem. If I log
the PC off the domain and just log on as administrator as a local user of the
PC, the client diagnostics tool runs OK and the Updates are detected. If I
log on as the user (set as a PowerUser) of the domain then this is where the
problem is.
"Steve" wrote:
[Quoted Text] > Thanks for the replies. > > I should have mentioned in the original post, the odd thing is I don't have > any proxy > settings in IE as we don't use a proxy so I'm not sure what to disable. Its > a WIndows XP SP 2 PC which was upgraded from IE 6 to IE 7. > > The PC does show up in WSUS console as haveing 12 updates outstanding. It > just won't dowmnload them. > > Thanks > > > "Lawrence Garvin (MVP)" wrote: > > > "Steve" <Steve[ at ]discussions.microsoft.com> wrote in message > > news:B3DC1923-A3B4-4313-9E91-F927F2263C99[ at ]microsoft.com... > > >I have one client PC not updating. > > > > > > The output from the WSUS Client Diagnostics Tool is: > > > > > Checking Proxy Configuration > > > Checking for winhttp local machine Proxy settings . . . PASS > > > Winhttp local machine access type > > > <Direct Connection> > > > Winhttp local machine Proxy. . . . . . . . . . NONE > > > Winhttp local machine ProxyBypass. . . . . . . NONE > > > GetCurrentUserIEProxy. . . . . . . . . . . . . . . . . . FAIL > > > > > > VerifyProxy() failed with hr=0x80070002 > > > > > > The system cannot find the file specified. > > > > 0x80070002 - ERROR FILE NOT FOUND > > > > The machine probably cannot find the auto-proxy file specified in the IE > > configuration. > > > > Luckily that shouldn't affect your WUA operation, but it apparently affects > > the ability of the Client Diagnostic Tool to properly complete. > > > > As a workaround, I suggest you disable ALL proxy configurations for IE, and > > rerun the Client Diagnostic Tool to focus on the WSUS issues. Then, having > > resolved that, you can return to troubleshooting why the system can't find > > the IE proxy config file, or whatever else is causing the failure in > > detecting the IE proxy config settings. > > > > -- > > Lawrence Garvin, M.S., MCTS, MCP > > Independent WSUS Evangelist > > MVP-Software Distribution (2005-2007) > > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E> > > > Everything you need for WSUS is at > > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx> > > > And, almost everything else is at > > http://wsusinfo.onsitechsolutions.com> > ..... > > > > > > |
|
I changed the domain use to an administrator and the client diagnostics tool
ran and the updates were detected so so something is wrong with permissions
somwhere I guess.
"Steve" wrote:
[Quoted Text] > I have one client PC not updating.
>
> The output from the WSUS Client Diagnostics Tool is:
>
>
> WSUS Client Diagnostics Tool
>
> Checking Machine State
> Checking for admin rights to run tool . . . . . . . . . PASS
> Automatic Updates Service is running. . . . . . . . . . PASS
> Background Intelligent Transfer Service is running. . . PASS
> Wuaueng.dll version 7.0.6000.374. . . . . . . . . . . . PASS
> This version is WSUS 2.0
>
> Checking AU Settings
> AU Option is 3 : Notify Prior to Install. . . . . . . . PASS
> Option is from Policy settings
>
> Checking Proxy Configuration
> Checking for winhttp local machine Proxy settings . . . PASS
> Winhttp local machine access type
> <Direct Connection>
> Winhttp local machine Proxy. . . . . . . . . . NONE
> Winhttp local machine ProxyBypass. . . . . . . NONE
> GetCurrentUserIEProxy. . . . . . . . . . . . . . . . . . FAIL
>
> VerifyProxy() failed with hr=0x80070002
>
> The system cannot find the file specified.
>
>
> Press Enter to Complete
|
|
"Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
news:C398DB75-02DC-45F9-9E43-87E4A3A36FD8[ at ]microsoft.com...
[Quoted Text] >
> One odd thing I dont know if this throws any light on the problem. If I
> log
> the PC off the domain and just log on as administrator as a local user of
> the
> PC, the client diagnostics tool runs OK and the Updates are detected. If I
> log on as the user (set as a PowerUser) of the domain then this is where
> the
> problem is.
Which is merely confirmation that somebody's configured the SBS2003 server
to force a proxy policy on the domain clients, and it's not effective on a
local logon account.
Try rerunning the Internet Connection Wizard on the SBS2003 server, and set
the desired values correctly -- specifically that there's no proxy server
being used.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
|
|
Lawrence
Thanks again for the reply.
It is only this one client that has the problem. The others (configured the
same way to my knowledge) dont exhibit the problem. I reran the Internet
Connection WIzard but it never asked me about a proxy server. The sequence I
got was:
Connection type : Broadband
Broadband Connection: Local router
Router Connection: Local IP Addres of router
Network Connection : ISP and Local Netwqork conection specified
Firewall
Web Server Certificate
Where would I see the proxy server settings?
Thanks again
Steve
"Lawrence Garvin (MVP)" wrote:
[Quoted Text]
|
|
"Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
news:1004D022-112C-4C43-B8D1-A17F730FE482[ at ]microsoft.com...
[Quoted Text] > It is only this one client that has the problem. The others (configured
> the
> same way to my knowledge) dont exhibit the problem. I reran the Internet
> Connection WIzard but it never asked me about a proxy server.
Then I'd look for a LOCAL policy configured on that machine that's
interfering with the configuration.
It could also be malware causing the problem.
> Where would I see the proxy server settings?
If they existed, I would have thought they'd have been in that wizard. I
should have paid more attention to the fact that it was only this one
computer exhibiting this problem. Had I caught that, I would have never
worried about the server configs. No harm done, though. Just wasted some of
your time.
Now the thing to decide: Is it worth the effort to continue the diagnostics
on this one PC, or do you just want to take the shortcut and rebuild the
machine.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence
[Quoted Text] > Then I'd look for a LOCAL policy configured on that machine that's
> interfering with the configuration.
Yes but didnt we previously rule out any local issues because when I log on
with a local user it works as does making it an Administrator user on the
domain.
Maybe you conclusion is right though and rebuilding this PC is the answer. I
am mainly using this PC to host some printers however so leaving the user it
logs on with as an administrator maybe isnt too bad either.
Thanks for your help once again.
Steve
"Lawrence Garvin (MVP)" wrote:
> "Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
> news:1004D022-112C-4C43-B8D1-A17F730FE482[ at ]microsoft.com...
>
> > It is only this one client that has the problem. The others (configured
> > the
> > same way to my knowledge) dont exhibit the problem. I reran the Internet
> > Connection WIzard but it never asked me about a proxy server.
>
> Then I'd look for a LOCAL policy configured on that machine that's
> interfering with the configuration.
>
> It could also be malware causing the problem.
>
> > Where would I see the proxy server settings?
>
> If they existed, I would have thought they'd have been in that wizard. I
> should have paid more attention to the fact that it was only this one
> computer exhibiting this problem. Had I caught that, I would have never
> worried about the server configs. No harm done, though. Just wasted some of
> your time.
>
> Now the thing to decide: Is it worth the effort to continue the diagnostics
> on this one PC, or do you just want to take the shortcut and rebuild the
> machine.
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
>
> Everything you need for WSUS is at
> http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>
|
|
"Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
news:1B6A53A2-4304-495A-8524-4EC7AF7BF330[ at ]microsoft.com...
[Quoted Text] > Lawrence
>
>> Then I'd look for a LOCAL policy configured on that machine that's
>> interfering with the configuration.
>
> Yes but didnt we previously rule out any local issues because when I log
> on
> with a local user it works as does making it an Administrator user on the
> domain.
That we *did*. Thank you for keeping *my* memory straight! :-)
So... it's definitely a *domain* issue, but it's not domain-wide. It's
apparently not a proxy configuration created in the CEICW, since the CEICW
doesn't include any proxy configuration stuff (and, even if it did, that
would then be affecting *all* clients).
The CDT (and WSUS/WUA interface) works perfectly in a local account, which
tells us it's not the WUA subsystem, or client configuration, itself.
But, in the domain account, the CDT 'hangs', complaining that an IE (and I'm
assuming it's a proxy config file) file cannot be found.
Have you tried a different domain account on this workstation. I'd be
curious whether it's impacting the *computer*, or just the *account*.
Also, what happens when you log onto this domain account on a *different*
computer in the domain?
> Maybe you conclusion is right though and rebuilding this PC is the answer.
> I
> am mainly using this PC to host some printers however so leaving the user
> it
> logs on with as an administrator maybe isnt too bad either.
Let's isolate the problem to the =PC= first, by ruling out, definitively,
that the problem is related to the domain account.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence
[Quoted Text] > Have you tried a different domain account on this workstation. I'd be
> curious whether it's impacting the *computer*, or just the *account*.
OK I tried that and it fails also.
> Also, what happens when you log onto this domain account on a *different*
> computer in the domain?
Tried that also and that works.
So it only happens with the unique combination of THAT workstation with THAT
domain account!!!!
Format and start again?????????????????
Steve
"Lawrence Garvin (MVP)" wrote:
> "Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
> news:1B6A53A2-4304-495A-8524-4EC7AF7BF330[ at ]microsoft.com...
> > Lawrence
> >
> >> Then I'd look for a LOCAL policy configured on that machine that's
> >> interfering with the configuration.
> >
> > Yes but didnt we previously rule out any local issues because when I log
> > on
> > with a local user it works as does making it an Administrator user on the
> > domain.
>
> That we *did*. Thank you for keeping *my* memory straight! :-)
>
> So... it's definitely a *domain* issue, but it's not domain-wide. It's
> apparently not a proxy configuration created in the CEICW, since the CEICW
> doesn't include any proxy configuration stuff (and, even if it did, that
> would then be affecting *all* clients).
>
> The CDT (and WSUS/WUA interface) works perfectly in a local account, which
> tells us it's not the WUA subsystem, or client configuration, itself.
>
> But, in the domain account, the CDT 'hangs', complaining that an IE (and I'm
> assuming it's a proxy config file) file cannot be found.
>
> Have you tried a different domain account on this workstation. I'd be
> curious whether it's impacting the *computer*, or just the *account*.
>
> Also, what happens when you log onto this domain account on a *different*
> computer in the domain?
>
> > Maybe you conclusion is right though and rebuilding this PC is the answer.
> > I
> > am mainly using this PC to host some printers however so leaving the user
> > it
> > logs on with as an administrator maybe isnt too bad either.
>
> Let's isolate the problem to the =PC= first, by ruling out, definitively,
> that the problem is related to the domain account.
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
>
> Everything you need for WSUS is at
> http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>
>
|
|
"Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
news:0B31A65C-5ED0-4B6F-9482-7770E2C36187[ at ]microsoft.com...
[Quoted Text] > Lawrence
>
>> Have you tried a different domain account on this workstation. I'd be
>> curious whether it's impacting the *computer*, or just the *account*.
>
> OK I tried that and it fails also.
>
>> Also, what happens when you log onto this domain account on a *different*
>> computer in the domain?
>
> Tried that also and that works.
Okay.. that tells us that the restriction is on the *COMPUTER* and not the
account.
> So it only happens with the unique combination of THAT workstation with
> THAT
> domain account!!!!
Uh....no... you just said above that it also fails on that computer with a
*different* domain account.
> Format and start again?????????????????
Nope... just need to find the errant computer policy that's being applied to
this system and remove it.
Formating and reinstalling won't help if there is a policy still there.
It'll just be reapplied to the new system.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence
[Quoted Text] > Uh....no... you just said above that it also fails on that computer with a
> *different* domain account.
Yes sorry. My statement was confusing again. What I meant was it only
happens on that computer with that TYPE of domain account. i.e a non
administrator account. The two that fail are both set using the User
Template. If I use an Administrator account it works as mentioned earlier.
> Nope... just need to find the errant computer policy that's being applied to
> this system and remove it.
Do you have any ideas where I could start looking on that PC?
Thanks yet again
Steve
"Lawrence Garvin (MVP)" wrote:
> "Steve" <Steve[ at ]discussions.microsoft.com> wrote in message
> news:0B31A65C-5ED0-4B6F-9482-7770E2C36187[ at ]microsoft.com...
> > Lawrence
> >
> >> Have you tried a different domain account on this workstation. I'd be
> >> curious whether it's impacting the *computer*, or just the *account*.
> >
> > OK I tried that and it fails also.
> >
> >> Also, what happens when you log onto this domain account on a *different*
> >> computer in the domain?
> >
> > Tried that also and that works.
>
> Okay.. that tells us that the restriction is on the *COMPUTER* and not the
> account.
>
> > So it only happens with the unique combination of THAT workstation with
> > THAT
> > domain account!!!!
>
> Uh....no... you just said above that it also fails on that computer with a
> *different* domain account.
>
>
> > Format and start again?????????????????
>
> Nope... just need to find the errant computer policy that's being applied to
> this system and remove it.
>
> Formating and reinstalling won't help if there is a policy still there.
> It'll just be reapplied to the new system.
>
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
>
> Everything you need for WSUS is at
> http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>
>
|
|
Steve wrote:
[Quoted Text] > Yes sorry. My statement was confusing again. What I meant was it only
> happens on that computer with that TYPE of domain account. i.e a non
> administrator account. The two that fail are both set using the User
> Template. If I use an Administrator account it works as mentioned earlier.
Try creating a local (not domain) non-administrative user and see what happens.
If the same problem occurs we can eliminate user group policy as a factor.
Harry.
|
|
|