|
|
So, 3 days ago I updated my WSUS 2.0 server to SP1 in preparation to
distribute the WU 3.0 client to my PCs while I plan for the WSUS 3.0
migration. A side project was to distribute the MSI update along with
the client to take care of the 100% CPU issue.
I installed KB936301 on the WSUS server and verified that it appears
in Add/Remove as an update. I ran the self update vbs script from the
WSUS server to verify that the update tree was working. So far, so
good. I waited a day and then approved KB927891 (MSI patch) to the
clients. They got the update but almost immediately I start getting
complaints that the PCs are running slow so I check out a couple and
sure enough at reboot, the CPU is pinned by svchost. I check the
version of WUAUENG in SYSTEM32 and see that it's still at 5.8.0.2607
which I find out is the 2.0 client version.
I understand that without the 3.0 client the MSI patch alone isn't
effective in controlling the CPU issue and has seemed to exasperate
the situation.
I recall seeing the BITS update in the console way back when as a pre
approved update to WSUS (had a different icon) so I filtered for WSUS
updates but all I see is the two old BITS updates and the XP update
from 2005. Clients check in daily to WSUS.
What am I doing wrong as far as self updates go? Do I need to approve
it?
Should I expect to see the updated client in the WSUS console as a pre
approved update?
Is this perhaps an IIS issue? - I see evidence of self update activity
from my clients in the IIS logs but nothing to suggest it is or isn't
working. I have the directory security for the self update virtual
directory set to allow anon, read and directory browsing. This hasn't
changed since I put WSUS in 2 years ago.
I should note that the original attempt to update the WSUS 2.0 server
to SP1 failed causing me to have to recover it. I ran a cmd to repair
the perf counters and re attempted the upgrade which succeeded. The
clients are talking to the server and updates are rolling OK. Just no
3.0 client. WSUS is a client of itself and works just fine. The server
has both 927891 and the updated client ver 7.0.6000.374
Any ideas? I can provide logs etc if needed to help troubleshoot. I
don't think I'm alone with this problem.
TIA
JPenrose
|
|
hmmm...not sure how I managed to get this posted here above a similar post
for the same thing.
Question still stands though...
"netadmin[ at ]kuntz.com" wrote:
[Quoted Text] > So, 3 days ago I updated my WSUS 2.0 server to SP1 in preparation to
> distribute the WU 3.0 client to my PCs while I plan for the WSUS 3.0
> migration. A side project was to distribute the MSI update along with
> the client to take care of the 100% CPU issue.
>
> I installed KB936301 on the WSUS server and verified that it appears
> in Add/Remove as an update. I ran the self update vbs script from the
> WSUS server to verify that the update tree was working. So far, so
> good. I waited a day and then approved KB927891 (MSI patch) to the
> clients. They got the update but almost immediately I start getting
> complaints that the PCs are running slow so I check out a couple and
> sure enough at reboot, the CPU is pinned by svchost. I check the
> version of WUAUENG in SYSTEM32 and see that it's still at 5.8.0.2607
> which I find out is the 2.0 client version.
>
> I understand that without the 3.0 client the MSI patch alone isn't
> effective in controlling the CPU issue and has seemed to exasperate
> the situation.
>
> I recall seeing the BITS update in the console way back when as a pre
> approved update to WSUS (had a different icon) so I filtered for WSUS
> updates but all I see is the two old BITS updates and the XP update
> from 2005. Clients check in daily to WSUS.
>
> What am I doing wrong as far as self updates go? Do I need to approve
> it?
> Should I expect to see the updated client in the WSUS console as a pre
> approved update?
> Is this perhaps an IIS issue? - I see evidence of self update activity
> from my clients in the IIS logs but nothing to suggest it is or isn't
> working. I have the directory security for the self update virtual
> directory set to allow anon, read and directory browsing. This hasn't
> changed since I put WSUS in 2 years ago.
>
> I should note that the original attempt to update the WSUS 2.0 server
> to SP1 failed causing me to have to recover it. I ran a cmd to repair
> the perf counters and re attempted the upgrade which succeeded. The
> clients are talking to the server and updates are rolling OK. Just no
> 3.0 client. WSUS is a client of itself and works just fine. The server
> has both 927891 and the updated client ver 7.0.6000.374
>
> Any ideas? I can provide logs etc if needed to help troubleshoot. I
> don't think I'm alone with this problem.
>
> TIA
> JPenrose
>
>
|
|
On May 25, 1:13 pm, JPenrose <JPenr...[ at ]discussions.microsoft.com>
wrote:
[Quoted Text] > hmmm...not sure how I managed to get this posted here above a similar post
> for the same thing.
>
> Question still stands though...
>
>
>
> "netad...[ at ]kuntz.com" wrote:
> > So, 3 days ago I updated my WSUS 2.0 server to SP1 in preparation to
> > distribute the WU 3.0 client to my PCs while I plan for the WSUS 3.0
> > migration. A side project was to distribute the MSI update along with
> > the client to take care of the 100% CPU issue.
>
> > I installed KB936301 on the WSUS server and verified that it appears
> > in Add/Remove as an update. I ran the self update vbs script from the
> > WSUS server to verify that the update tree was working. So far, so
> > good. I waited a day and then approved KB927891 (MSI patch) to the
> > clients. They got the update but almost immediately I start getting
> > complaints that the PCs are running slow so I check out a couple and
> > sure enough at reboot, the CPU is pinned by svchost. I check the
> > version of WUAUENG in SYSTEM32 and see that it's still at 5.8.0.2607
> > which I find out is the 2.0 client version.
>
> > I understand that without the 3.0 client the MSI patch alone isn't
> > effective in controlling the CPU issue and has seemed to exasperate
> > the situation.
>
> > I recall seeing the BITS update in the console way back when as a pre
> > approved update to WSUS (had a different icon) so I filtered for WSUS
> > updates but all I see is the two old BITS updates and the XP update
> > from 2005. Clients check in daily to WSUS.
>
> > What am I doing wrong as far as self updates go? Do I need to approve
> > it?
> > Should I expect to see the updated client in the WSUS console as a pre
> > approved update?
> > Is this perhaps an IIS issue? - I see evidence of self update activity
> > from my clients in the IIS logs but nothing to suggest it is or isn't
> > working. I have the directory security for the self update virtual
> > directory set to allow anon, read and directory browsing. This hasn't
> > changed since I put WSUS in 2 years ago.
>
> > I should note that the original attempt to update the WSUS 2.0 server
> > to SP1 failed causing me to have to recover it. I ran a cmd to repair
> > the perf counters and re attempted the upgrade which succeeded. The
> > clients are talking to the server and updates are rolling OK. Just no
> > 3.0 client. WSUS is a client of itself and works just fine. The server
> > has both 927891 and the updated client ver 7.0.6000.374
>
> > Any ideas? I can provide logs etc if needed to help troubleshoot. I
> > don't think I'm alone with this problem.
>
> > TIA
> > JPenrose- Hide quoted text -
>
> - Show quoted text -
Wow, hard to believe not one expert took a stab at this. Maybe the
post was too long to read...
The solution was to allow the WSUS server (as a client of itself) to
install the approved KB936301 update through WSUS delivery and not by
launching the exe. Add/Remove now states the full name of the update
instead of just UPDATE. Restart AU and WUAU then wait for clients to
check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along
with MSI.DLL v3.
FYI; WSUS does not reveal the client update in its update list since
it was self created by installing KB936301 and not downloaded from MU
like the BITS update.
-J
|
|
|
[Quoted Text] > The solution was to allow the WSUS server (as a client of itself) to
> install the approved KB936301 update through WSUS delivery and not by
> launching the exe. Add/Remove now states the full name of the update
> instead of just UPDATE. Restart AU and WUAU then wait for clients to
> check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along
> with MSI.DLL v3.
>
> FYI; WSUS does not reveal the client update in its update list since
> it was self created by installing KB936301 and not downloaded from MU
> like the BITS update.
That is what I am tring to do! But, when my SBS checks in to the WSUS it
shows the KB936301 as 'not needed'.
I have no clue how I can install this.
Franz
|
|
On May 29, 11:29 am, "Franz Leu" <franz.spam-removal....[ at ]norfolk.spam-
removal.ch> wrote:
[Quoted Text] > > The solution was to allow the WSUS server (as a client of itself) to
> > install the approved KB936301 update through WSUS delivery and not by
> > launching the exe. Add/Remove now states the full name of the update
> > instead of just UPDATE. Restart AU and WUAU then wait for clients to
> > check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along
> > with MSI.DLL v3.
>
> > FYI; WSUS does not reveal the client update in its update list since
> > it was self created by installing KB936301 and not downloaded from MU
> > like the BITS update.
>
> That is what I am tring to do! But, when my SBS checks in to the WSUS it
> shows the KB936301 as 'not needed'.
> I have no clue how I can install this.
>
> Franz
* Are you absolutely sure that your WSUS is 2.0 SP1 ver 2.0.0.2620?
Have you manually installed KB 936301 - http://go.microsoft.com/fwlink/?LinkID=91238
-
* In Add/Remove under the Windows Update Agent Self update (version
1.2.0.0) do you see any evidence of an update to that installation?
Mine appears as a sub item of WUASu.
* What do the IIS logs say? Can you see client activity for
Selfupdate?
* Is this perhaps a permissions issue on the Selfupdate virtual folder
in the Default website? I gave the Everyone group READ to the
selfupdate folder and made sure Directory Browsing was enabled for the
IIS VF.
* I have zero experience with WSUS running on SBS so perhaps there is
an element of that installation getting in the way?
Sorry if you've been asked this stuff before but I can't try and help
you if I don't know what you've tried/observed/installed etc.
-J
|
|
On May 29, 12:18 pm, JPenrose <netad...[ at ]kuntz.com> wrote:
[Quoted Text] > On May 29, 11:29 am, "Franz Leu" <franz.spam-removal....[ at ]norfolk.spam- > > > > > > removal.ch> wrote: > > > The solution was to allow the WSUS server (as a client of itself) to > > > install the approved KB936301 update through WSUS delivery and not by > > > launching the exe. Add/Remove now states the full name of the update > > > instead of just UPDATE. Restart AU and WUAU then wait for clients to > > > check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along > > > with MSI.DLL v3. > > > > FYI; WSUS does not reveal the client update in its update list since > > > it was self created by installing KB936301 and not downloaded from MU > > > like the BITS update. > > > That is what I am tring to do! But, when my SBS checks in to the WSUS it > > shows the KB936301 as 'not needed'. > > I have no clue how I can install this. > > > Franz > > * Are you absolutely sure that your WSUS is 2.0 SP1 ver 2.0.0.2620? > Have you manually installed KB 936301 http://go.microsoft.com/fwlink/?LinkID=91237> - > * In Add/Remove under the Windows Update Agent Self update (version > 1.2.0.0) do you see any evidence of an update to that installation? > Mine appears as a sub item of WUASu. > * What do the IIS logs say? Can you see client activity for > Selfupdate? > * Is this perhaps a permissions issue on the Selfupdate virtual folder > in the Default website? I gave the Everyone group READ to the > selfupdate folder and made sure Directory Browsing was enabled for the > IIS VF. > * I have zero experience with WSUS running on SBS so perhaps there is > an element of that installation getting in the way? > > Sorry if you've been asked this stuff before but I can't try and help > you if I don't know what you've tried/observed/installed etc. > > -J- Hide quoted text - > > - Show quoted text -
Sorry, the link I included is for 64bit. Here is the x86 ver for
Server 2k3 - http://go.microsoft.com/fwlink/?LinkID=91237 -
-J
|
|
"JPenrose" <netadmin[ at ]kuntz.com> wrote in message
news:1180450433.435872.308570[ at ]j4g2000prf.googlegroups.com...
[Quoted Text] > On May 25, 1:13 pm, JPenrose <JPenr...[ at ]discussions.microsoft.com>
> wrote:
>> hmmm...not sure how I managed to get this posted here above a similar
>> post
>> for the same thing.
>>
>> Question still stands though...
> Wow, hard to believe not one expert took a stab at this. Maybe the
> post was too long to read...
That might have been one reason. I'll point out a few others that might also
be relevant. :-)
>> > I installed KB936301 on the WSUS server and verified that it appears
>> > in Add/Remove as an update. I ran the self update vbs script from the
>> > WSUS server to verify that the update tree was working.
The 'selfupdate.vbs' script has been broken since before WSUS went gold in
June 2005. Running the script may be causing more harm than good. It's
certainly my observation that it does no good. Best case scenario: Nothing
changed.
>> > They got the update but almost immediately I start getting
>> > complaints that the PCs are running slow so I check out a couple and
>> > sure enough at reboot, the CPU is pinned by svchost.
So.. let me make sure I'm understanding this. You're applying a patch to a
system to fix a problem that's preventing patches from being installed, and
the installation of the patch fails using the non-functional automated
method?
>> > I check the
>> > version of WUAUENG in SYSTEM32 and see that it's still at 5.8.0.2607
>> > which I find out is the 2.0 client version.
That it is.
>> > I understand that without the 3.0 client the MSI patch alone isn't
>> > effective in controlling the CPU issue and has seemed to exasperate
>> > the situation.
Correct. The MSI patch was targeted at a very specific scenario, but to get
the best resolution, you need to update to the v7.0 WUA also.
>> > I recall seeing the BITS update in the console way back when as a pre
>> > approved update to WSUS (had a different icon) so I filtered for WSUS
>> > updates but all I see is the two old BITS updates and the XP update
>> > from 2005. Clients check in daily to WSUS.
I'm not following what this has to do with anything...
>> > What am I doing wrong as far as self updates go? Do I need to approve
>> > it?
The "selfupdate" update needs to be applied to the *WSUS Server*. This
updates the contents of the /selfupdate virtual directory on the website.
Then, once these files are updated, the *client* systems will detect the
availability of updated files, download them, and install them.
>> > Should I expect to see the updated client in the WSUS console as a pre
>> > approved update?
Only if you're distributing the update via normal WSUS distribution
channels, and you've acquired the update via synchronization with MU.
>> > I see evidence of self update activity
>> > from my clients in the IIS logs but nothing to suggest it is or isn't
>> > working.
This is not conclusive of anything. The WUA executes a selfupdate check at
*every* detection event.
>> >WSUS is a client of itself and works just fine. The server
>> > has both 927891 and the updated client ver 7.0.6000.374
Okay, so that demonstrates that there's nothing wrong with the *server*,
since a client did successfully selfupdate.
So, let's troubleshoot this as your basic "client won't selfupdate" issue.
Run the Client Diagnostic Tool on a client that's not selfupdating, and post
the results. Inspect the WindowsUpdate.log for the selfupdate detection
event, and post the relevant log entries -- which will either show a failed
selfupdate event, a successful selfupdate event (one time only), or no
selfupdate required.
> The solution was to allow the WSUS server (as a client of itself) to
> install the approved KB936301 update through WSUS delivery and not by
> launching the exe. Add/Remove now states the full name of the update
> instead of just UPDATE. Restart AU and WUAU then wait for clients to
> check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along
> with MSI.DLL v3.
Understand that this process does not directly update the *client* on the
WSUS server, it updates the contents of the /selfupdate virtual directory.
Once that virtual directory is updated, the *cleint* sees the availability
of the updated files, and downloads the files and updates itself. It*is* a
two-step process.
> FYI; WSUS does not reveal the client update in its update list since
> it was self created by installing KB936301 and not downloaded from MU
> like the BITS update.
Huh?
--
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
.....
|
|
On May 29, 7:43 pm, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "JPenrose" <netad...[ at ]kuntz.com> wrote in message > > news:1180450433.435872.308570[ at ]j4g2000prf.googlegroups.com... > > > On May 25, 1:13 pm, JPenrose <JPenr...[ at ]discussions.microsoft.com> > > wrote: > >> hmmm...not sure how I managed to get this posted here above a similar > >> post > >> for the same thing. > > >> Question still stands though... > > Wow, hard to believe not one expert took a stab at this. Maybe the > > post was too long to read... > > That might have been one reason. I'll point out a few others that might also > be relevant. :-) > > >> > I installed KB936301 on the WSUS server and verified that it appears > >> > in Add/Remove as an update. I ran the self update vbs script from the > >> > WSUS server to verify that the update tree was working. > > The 'selfupdate.vbs' script has been broken since before WSUS went gold in > June 2005. Running the script may be causing more harm than good. It's > certainly my observation that it does no good. Best case scenario: Nothing > changed. > > >> > They got the update but almost immediately I start getting > >> > complaints that the PCs are running slow so I check out a couple and > >> > sure enough at reboot, the CPU is pinned by svchost. > > So.. let me make sure I'm understanding this. You're applying a patch to a > system to fix a problem that's preventing patches from being installed, and > the installation of the patch fails using the non-functional automated > method? > > >> > I check the > >> > version of WUAUENG in SYSTEM32 and see that it's still at 5.8.0.2607 > >> > which I find out is the 2.0 client version. > > That it is. > > >> > I understand that without the 3.0 client the MSI patch alone isn't > >> > effective in controlling the CPU issue and has seemed to exasperate > >> > the situation. > > Correct. The MSI patch was targeted at a very specific scenario, but to get > the best resolution, you need to update to the v7.0 WUA also. > > >> > I recall seeing the BITS update in the console way back when as a pre > >> > approved update to WSUS (had a different icon) so I filtered for WSUS > >> > updates but all I see is the two old BITS updates and the XP update > >> > from 2005. Clients check in daily to WSUS. > > I'm not following what this has to do with anything... > > >> > What am I doing wrong as far as self updates go? Do I need to approve > >> > it? > > The "selfupdate" update needs to be applied to the *WSUS Server*. This > updates the contents of the /selfupdate virtual directory on the website. > Then, once these files are updated, the *client* systems will detect the > availability of updated files, download them, and install them. > > >> > Should I expect to see the updated client in the WSUS console as a pre > >> > approved update? > > Only if you're distributing the update via normal WSUS distribution > channels, and you've acquired the update via synchronization with MU. > > >> > I see evidence of self update activity > >> > from my clients in the IIS logs but nothing to suggest it is or isn't > >> > working. > > This is not conclusive of anything. The WUA executes a selfupdate check at > *every* detection event. > > >> >WSUS is a client of itself and works just fine. The server > >> > has both 927891 and the updated client ver 7.0.6000.374 > > Okay, so that demonstrates that there's nothing wrong with the *server*, > since a client did successfully selfupdate. > > So, let's troubleshoot this as your basic "client won't selfupdate" issue. > Run the Client Diagnostic Tool on a client that's not selfupdating, and post > the results. Inspect the WindowsUpdate.log for the selfupdate detection > event, and post the relevant log entries -- which will either show a failed > selfupdate event, a successful selfupdate event (one time only), or no > selfupdate required. > > > The solution was to allow the WSUS server (as a client of itself) to > > install the approved KB936301 update through WSUS delivery and not by > > launching the exe. Add/Remove now states the full name of the update > > instead of just UPDATE. Restart AU and WUAU then wait for clients to > > check in. AFter 24 hours the PCs had WUAUENG.DLL v 7.0.6000.374 along > > with MSI.DLL v3. > > Understand that this process does not directly update the *client* on the > WSUS server, it updates the contents of the /selfupdate virtual directory. > Once that virtual directory is updated, the *cleint* sees the availability > of the updated files, and downloads the files and updates itself. It*is* a > two-step process. > > > FYI; WSUS does not reveal the client update in its update list since > > it was self created by installing KB936301 and not downloaded from MU > > like the BITS update. > > Huh? > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
Thanks for the reply Lawrence, I always look for your input first when
I'm scanning a thread for info...
Ok, in short the clients all seem to have ver 7.0.6000.374 of
wuaueng.dll + the 927891 MSI patch and I'm seeing nearly no
complaints about high CPU which was the goal from the start.
Answers and clarification
I didn't apply 927891 to correct a problem that prevented patch
delivery, WSUS 2.0 worked just fine. I was getting complaints about
high CPU usage on and off for quite some time so I applied 927891 via
the regular wsus delivery method thinking that they already had the
updated wu client which was supposed to be installed via self update 2
days prior. My understanding is that I need both halves of the
solution or I won't see any improvement. The MSI patch delivered on
time on schedule no problem. The issue was that no one had the new
client b/c the selfupdate was stalled/broken/w/e.
If you filter the updates view and ask to see only WSUS updates you'll
(or at least I) see 2 updates for BITS (one for server and one for XP)
and one called update for windows XP. This is where I expected to see
the new client listed. Apparently only updates aquired via MU show up
there.
I applied 936301 directly to the WSUS server but that didn't seem to
do the trick to get clients self updating. Only when I approved the
update in the WSUS console for the server and allowed it to install
did I get selfupdate to happen. This is the part that I didn't
understand; when applied to the server by launching the exe it
finished OK and I saw an entry called 'update' in the Add/Remove, when
I allow WSUS to service itself with an approved update it succeeded
again but this time the full name of the update is listed now in Add/
Remove and clients checked in and checked out with a new au client.
Stricty speaking the WSUS server itself didn't self update. I applied
the AU 3.0 client manually. Maybe it would have had I issued the
update from the server the first time. Perhaps the thing I applied
originally was the wrong patch.
I think the orginal application of the WSUS 2.0 SP1 update failed to
update the selfupdate VD again perhaps I used the wrong patch. Once
applied the next time using wsus approval it worked.
Once again, thanks for replying. It seems to have worked in the end
which for someone as busy as I am works for me.
Cheers!!
-JPenrose
|
|
|
[Quoted Text] > ... Only when I approved the
> update in the WSUS console for the server and allowed it to install
> did I get selfupdate to happen.
This is what I am trying to do !
Did your WSUS server show the update as 'needed' before you installed the
client manually to the server?
Franz
|
|
"JPenrose" <netadmin[ at ]kuntz.com> wrote in message
news:1180533058.336184.273040[ at ]p47g2000hsd.googlegroups.com...
[Quoted Text] > Ok, in short the clients all seem to have ver 7.0.6000.374 of
> wuaueng.dll + the 927891 MSI patch and I'm seeing nearly no
> complaints about high CPU which was the goal from the start.
Excellent!
> I didn't apply 927891 to correct a problem that prevented patch
> delivery, WSUS 2.0 worked just fine. I was getting complaints about
> high CPU usage on and off for quite some time so I applied 927891 via
> the regular wsus delivery method thinking that they already had the
> updated wu client which was supposed to be installed via self update 2
> days prior. My understanding is that I need both halves of the
> solution or I won't see any improvement. The MSI patch delivered on
> time on schedule no problem. The issue was that no one had the new
> client b/c the selfupdate was stalled/broken/w/e.
Aha! :-)
> If you filter the updates view and ask to see only WSUS updates you'll
> (or at least I) see 2 updates for BITS (one for server and one for XP)
> and one called update for windows XP. This is where I expected to see
> the new client listed. Apparently only updates aquired via MU show up
> there.
No.. only updates classified as "WSUS Updates" are located in that
classification. It's a very critical classification, because there's a
default auto-approval rule for this classification. KB927891 is not
something we'd want automagically installed on *every* system in an
organization, therefore classification here would not be appropriate.
> I applied 936301 directly to the WSUS server but that didn't seem to
> do the trick to get clients self updating. Only when I approved the
> update in the WSUS console for the server and allowed it to install
> did I get selfupdate to happen.
Interesting.... but not entirely surprising.
> This is the part that I didn't
> understand; when applied to the server by launching the exe it
> finished OK and I saw an entry called 'update' in the Add/Remove, when
> I allow WSUS to service itself with an approved update it succeeded
> again but this time the full name of the update is listed now in Add/
> Remove and clients checked in and checked out with a new au client.
Without having actually looked at this package, I'm going to speculate that
executing the EXE updated the WUA on the WSUS server, but did *not* update
the /selfupdate folder tree in the %programfiles% folder. Approving the
update in the WSUS Admin Console triggered the deployment of the necessary
files into the /selfupdate folder tree.
> Stricty speaking the WSUS server itself didn't self update. I applied
> the AU 3.0 client manually.
That does appear to be what happened.
> Maybe it would have had I issued the
> update from the server the first time.
I hope so.
> Perhaps the thing I applied
> originally was the wrong patch.
Not the wrong patch; just an incorrect methodology. :-)
--
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
.....
|
|
"Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
message news:%23izNAQsoHHA.4552[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] >> ... Only when I approved the
>> update in the WSUS console for the server and allowed it to install
>> did I get selfupdate to happen.
>
> This is what I am trying to do !
> Did your WSUS server show the update as 'needed' before you installed the
> client manually to the server?
Franz, I wouldn't really worry about what status is reporting. You know the
update is needed.
Just approve the darn thing! :-)
If it doesn't detect/install after being approved, let's focus our efforts
on troubleshooting *that* issue.
--
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
.....
|
|
On May 30, 11:01 am, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Franz Leu" <franz.spam-removal....[ at ]norfolk.spam-removal.ch> wrote in > messagenews:%23izNAQsoHHA.4552[ at ]TK2MSFTNGP04.phx.gbl... > > >> ... Only when I approved the > >> update in the WSUS console for the server and allowed it to install > >> did I get selfupdate to happen. > > > This is what I am trying to do ! > > Did your WSUS server show the update as 'needed' before you installed the > > client manually to the server? > > Franz, I wouldn't really worry about what status is reporting. You know the > update is needed. > > Just approve the darn thing! :-) > > If it doesn't detect/install after being approved, let's focus our efforts > on troubleshooting *that* issue. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
I totally agree with Lawrence but, to answer your question Franz, my
WSUS server did indeed display the update as Needed.
-J
|
|
On May 30, 11:01 am, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Franz Leu" <franz.spam-removal....[ at ]norfolk.spam-removal.ch> wrote in > messagenews:%23izNAQsoHHA.4552[ at ]TK2MSFTNGP04.phx.gbl... > > >> ... Only when I approved the > >> update in the WSUS console for the server and allowed it to install > >> did I get selfupdate to happen. > > > This is what I am trying to do ! > > Did your WSUS server show the update as 'needed' before you installed the > > client manually to the server? > > Franz, I wouldn't really worry about what status is reporting. You know the > update is needed. > > Just approve the darn thing! :-) > > If it doesn't detect/install after being approved, let's focus our efforts > on troubleshooting *that* issue. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
I totally agree with Lawrence but, to answer your question Franz, my
WSUS server did indeed display the update as Needed.
-J
|
|
|
[Quoted Text] > Franz, I wouldn't really worry about what status is reporting. You know
> the update is needed.
>
> Just approve the darn thing! :-)
Actually, that was the first thing i did. However that does not change a
thing if it detects as 'not needed'.
>
> If it doesn't detect/install after being approved, let's focus our efforts
> on troubleshooting *that* issue.
You're absolutely right. You seem like the first here that sees the picture
of the situation. ;-)
I will try what others did: Install the update manually to the server and
see what happens.
Franz
|
|
"Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
message news:u$MkUS1oHHA.4592[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >> Franz, I wouldn't really worry about what status is reporting. You know
>> the update is needed.
>>
>> Just approve the darn thing! :-)
>
> Actually, that was the first thing i did. However that does not change a
> thing if it detects as 'not needed'.
Maybe... maybe not. Maybe it's just being *reported* incorrectly???
The real question is: After approving the update for installation, was it
detected/downloaded/installed. If the *detection* of an approved update that
is known to be needed fails... that's something that ought to be dealt with.
>> If it doesn't detect/install after being approved, let's focus our
>> efforts on troubleshooting *that* issue.
>
> You're absolutely right. You seem like the first here that sees the
> picture of the situation. ;-)
> I will try what others did: Install the update manually to the server and
> see what happens.
I thought we'd already determined that installing the update manually to the
server was not the correct action to take?
--
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 Garvin (MVP)" <onsitech[ at ]community.nospam> schrieb im Newsbeitrag
news:OTByGI8oHHA.668[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
> message news:u$MkUS1oHHA.4592[ at ]TK2MSFTNGP05.phx.gbl...
>>> Franz, I wouldn't really worry about what status is reporting. You know
>>> the update is needed.
>>>
>>> Just approve the darn thing! :-)
>>
>> Actually, that was the first thing i did. However that does not change a
>> thing if it detects as 'not needed'.
>
> Maybe... maybe not. Maybe it's just being *reported* incorrectly???
>
> The real question is: After approving the update for installation, was it
> detected/downloaded/installed. If the *detection* of an approved update
> that is known to be needed fails... that's something that ought to be
> dealt with.
Nothing happens. WSUS has it ready, approved for all groups. The Server
doesn't want it. Period.
>
>>> If it doesn't detect/install after being approved, let's focus our
>>> efforts on troubleshooting *that* issue.
>>
>> You're absolutely right. You seem like the first here that sees the
>> picture of the situation. ;-)
>> I will try what others did: Install the update manually to the server and
>> see what happens.
>
> I thought we'd already determined that installing the update manually to
> the server was not the correct action to take?
You're right, and I haven't done it yet.
However, I am not alone with this issue. Some others made it to work this
way.
Robert Li (MSFT) from MS is checking things out right now. I reported the
stats of the server to him using the MPSRPT tool.
Anyhow, I will wait for his response.
If you have any other suggestion ... feel free to enlighten me ;-)
Thanks, Franz
|
|
Update.
Unfortunately, Robert Li seems not to be able to help because all the logs
are in German ?!?
So, I am back to square 1.
Franz
"Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> schrieb im Newsbeitrag
news:OTByGI8oHHA.668[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in > message news:u$MkUS1oHHA.4592[ at ]TK2MSFTNGP05.phx.gbl... >>> Franz, I wouldn't really worry about what status is reporting. You know >>> the update is needed. >>> >>> Just approve the darn thing! :-) >> >> Actually, that was the first thing i did. However that does not change a >> thing if it detects as 'not needed'. > > Maybe... maybe not. Maybe it's just being *reported* incorrectly??? > > The real question is: After approving the update for installation, was it > detected/downloaded/installed. If the *detection* of an approved update > that is known to be needed fails... that's something that ought to be > dealt with. > >>> If it doesn't detect/install after being approved, let's focus our >>> efforts on troubleshooting *that* issue. >> >> You're absolutely right. You seem like the first here that sees the >> picture of the situation. ;-) >> I will try what others did: Install the update manually to the server and >> see what happens. > > I thought we'd already determined that installing the update manually to > the server was not the correct action to take? > > -- > 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> .... > >
|
|
"Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
message news:upBqgODpHHA.4192[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] > Update.
>
> Unfortunately, Robert Li seems not to be able to help because all the logs
> are in German ?!?
> So, I am back to square 1.
I'll put this on my agenda for this weekend, and try it on an English
language system. I still have a WSUS 2.0 system installed, which has been
sitting idle for several weeks, that was scheduled for retirement this
weekend.
I'll see if I can successfully install this update on that system, before I
pull the plug.
--
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,
Could you find some time to check what your 'old' WSUS does with the
KB936301?
Franz
"Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> schrieb im Newsbeitrag
news:uCEIgrGpHHA.4212[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in > message news:upBqgODpHHA.4192[ at ]TK2MSFTNGP06.phx.gbl... >> Update. >> >> Unfortunately, Robert Li seems not to be able to help because all the >> logs are in German ?!? >> So, I am back to square 1. > > I'll put this on my agenda for this weekend, and try it on an English > language system. I still have a WSUS 2.0 system installed, which has been > sitting idle for several weeks, that was scheduled for retirement this > weekend. > > I'll see if I can successfully install this update on that system, before > I pull the plug. > > -- > 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 Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message
news:%23vE1Md9pHHA.4132[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
> message news:u2yNl%234pHHA.588[ at ]TK2MSFTNGP06.phx.gbl...
>> Could you find some time to check what your 'old' WSUS does with the
>> KB936301?
> I'm working on it tonight, Franz.
>
> Turns out I had already uninstalled my WSUS2, so I'm reinstalling a fresh
> WSUS2SP1 on SBS2003 with a fresh install of the WUA v5.8.
>
> I'll sync to get the WSUS3.0 client and KB936301 and see what happens.
I encountered/discovered a "bug" in the process of downgrading a WUA 7.0
client to WUA 5.8.
I'm corresponding with the dev team now to find out if there's a 'fix', or
if I need to 'workaround' the issue.
--
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 Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message
news:uGg1rAEqHHA.1244[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] >> "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
>> message news:u2yNl%234pHHA.588[ at ]TK2MSFTNGP06.phx.gbl...
>>> Could you find some time to check what your 'old' WSUS does with the
>>> KB936301?
>> I'm working on it tonight, Franz.
>>
>> Turns out I had already uninstalled my WSUS2, so I'm reinstalling a fresh
>> WSUS2SP1 on SBS2003 with a fresh install of the WUA v5.8.
>>
>> I'll sync to get the WSUS3.0 client and KB936301 and see what happens.
> I encountered/discovered a "bug" in the process of downgrading a WUA 7.0
> client to WUA 5.8.
>
> I'm corresponding with the dev team now to find out if there's a 'fix', or
> if I need to 'workaround' the issue.
Unfortunately, the dev did not reply to my plea for help, so I'm going to
reinitate this test tonight on an SBS2003 Virtual Machine I have set up
elsewhere, which has never had WUA7 or WSUS3 installed on it.
--
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 Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message
news:uMj3dCKqHHA.4400[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] >>> "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in
>>> message news:u2yNl%234pHHA.588[ at ]TK2MSFTNGP06.phx.gbl...
>>>> Could you find some time to check what your 'old' WSUS does with the
>>>> KB936301?
I have tested on a fresh install of SBS2003SP1, with a fresh install of
WSUS2SP1, running the v5.8.0.2607 build of the Windows Update Agent, and the
update (KB936301) was reported as =NEEDED= on this SBS2003SP1 installation.
Following confirmation of the client reporting the update as Needed, I
approved the update for installation on the SBS2003SP1 system, and initiated
a manual detection (wuauclt /detectnow). The WUA did *not* download the
update for installation. However, there were dozens of other updates, also
"Needed", by this SBS2003SP1 system. So I removed the approval for KB936301,
and added approvals for all other "Needed" updates, to ensure the WSUS
server was fully updated, except for KB936301 in the event there were
additional undetected dependencies.
However, this may also have been due to the update not being fully
downloaded from microsoft.com at the time I forced the detection.
I completed the installation of all other required updates, and rebooted the
server.
KB936301 still reports as Needed; and is now downloaded to the WSUS server
content store. I re-approved the update, and initiated another detection.
The WUA v5.8.0.2607 client did *NOT* detect the update, nor download the
update -- yet it does report as needed.
There does seem to be a critical flaw in the detection engine of this update
package.
CC: WSUS Dev Team
--
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,
Any news from the Dev Team?
I am still suffering from the svchost issue.
Franz
"Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> schrieb im Newsbeitrag
news:OMbP0HMqHHA.1148[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] > "Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message > news:uMj3dCKqHHA.4400[ at ]TK2MSFTNGP03.phx.gbl... > >>>> "Franz Leu" <franz.spam-removal.leu[ at ]norfolk.spam-removal.ch> wrote in >>>> message news:u2yNl%234pHHA.588[ at ]TK2MSFTNGP06.phx.gbl... > >>>>> Could you find some time to check what your 'old' WSUS does with the >>>>> KB936301? > > I have tested on a fresh install of SBS2003SP1, with a fresh install of > WSUS2SP1, running the v5.8.0.2607 build of the Windows Update Agent, and > the update (KB936301) was reported as =NEEDED= on this SBS2003SP1 > installation. > > Following confirmation of the client reporting the update as Needed, I > approved the update for installation on the SBS2003SP1 system, and > initiated a manual detection (wuauclt /detectnow). The WUA did *not* > download the update for installation. However, there were dozens of other > updates, also "Needed", by this SBS2003SP1 system. So I removed the > approval for KB936301, and added approvals for all other "Needed" updates, > to ensure the WSUS server was fully updated, except for KB936301 in the > event there were additional undetected dependencies. > > However, this may also have been due to the update not being fully > downloaded from microsoft.com at the time I forced the detection. > > I completed the installation of all other required updates, and rebooted > the server. > > KB936301 still reports as Needed; and is now downloaded to the WSUS server > content store. I re-approved the update, and initiated another detection. > The WUA v5.8.0.2607 client did *NOT* detect the update, nor download the > update -- yet it does report as needed. > > There does seem to be a critical flaw in the detection engine of this > update package. > > CC: WSUS Dev Team > > -- > 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,
Any news on that?
Franz
"Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> schrieb im Newsbeitrag
news:esu5yS8rHHA.5008[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text]
|
|
|
|
|