|
|
|
|
"EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
news:7E0D717B-B58D-4F36-8A4A-1C8A9BF7F2A4[ at ]microsoft.com...
[Quoted Text] > Needed count should not show patches that haven't been approved for
> install
> yet. If I don't want it to go out yet, then it isn't needed.
If they haven't been approved for installation, how do you expect to find
out if they're needed *before* you approve them?
Keep in mind, the act of approving an update for installation causes the
content to be downloaded. Unless you plan to approve *EVERY* update (and,
thus, download 100% of the available content -- about 60GB at last check),
this is simply not a feasable methodology.
Rather, first, you want to know if any machine *needs* the update, and if it
does, *then* approve the update for installation and download the content to
the WSUS Server. In this methodology you ensure maximum efficiency of the
disk storage on your WSUS server, and that you don't waste tens of GB of
disk space storing update content that you will never use.
--
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
.....
|
|
How I expect to use it is this:
Let's say that it's time to push patches.. So I approve the patches that I
want to go out (with a deadline of 2 years ago), run my trusty "psexec \\*
wuauclt.exe /detectnow". I want to use the needed counter to see what
machines are 100% patched and what machines haven't installed the approved
patches.
I understand your reasoning if I am in the patch view, but if I'm looking at
the list of computers and it says needed:1. I would expect that one patch
that I approved hasn't been applied to that machine yet. Not one patch that I
may or may not decide to apply later is needed.
I agree with you that the needed column should behave the way you described
when looking at patched, but when looking at the computer list, this makes no
sense.
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message > news:7E0D717B-B58D-4F36-8A4A-1C8A9BF7F2A4[ at ]microsoft.com... > > Needed count should not show patches that haven't been approved for > > install > > yet. If I don't want it to go out yet, then it isn't needed. > > If they haven't been approved for installation, how do you expect to find > out if they're needed *before* you approve them? > > Keep in mind, the act of approving an update for installation causes the > content to be downloaded. Unless you plan to approve *EVERY* update (and, > thus, download 100% of the available content -- about 60GB at last check), > this is simply not a feasable methodology. > > Rather, first, you want to know if any machine *needs* the update, and if it > does, *then* approve the update for installation and download the content to > the WSUS Server. In this methodology you ensure maximum efficiency of the > disk storage on your WSUS server, and that you don't waste tens of GB of > disk space storing update content that you will never use. > > > -- > 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> ..... > > > |
|
"EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
news:03ACCFA6-F927-4CB2-BDA8-D140799F96B1[ at ]microsoft.com...
[Quoted Text] > How I expect to use it is this:
>
> Let's say that it's time to push patches..
First thing we need to clarify. You don't push patches. You make updates
available for detection by client systems. The client systems initiate a
detection event at a regularly scheduled interval (22 hours, by default).
They download the content for any updates that are approved, and then
install those updates according to the policy you've configured. (Either
user installed, or at a scheduled installation time.) All status definitions
are reported by the client, based on the perspective of the client system.
> So I approve the patches that I want to go out (with a deadline of 2 years
> ago),
You really want them installed =now=, eh?
> run my trusty "psexec \\* wuauclt.exe /detectnow".
> I want to use the needed counter to see what
> machines are 100% patched and what machines haven't installed the approved
> patches.
Well, there's the first misunderstanding. Once your trusty 'psexec \\*
wuauclt.exe /detectnow' successfully runs (and it presumes that the command
*is* successfully running). The client will do just as I described above. It
will:
[a] determine if any updates are approved.
[b] download the content to be installed.
[c] schedule the updates for installation -or- notify a logged on
administrator that updates are available to be installed.
but, since you've configured expired deadlines on all of the
updates, the updates will be installed *immediately*,
the system will reboot *immediately*,
your users will be annoyed as all get out because you rebooted
their system without warning in the middle of the workday
(Aren't you glad they're not installing???)
[d] AFTER installation is complete AND the system is restarted,
[e] The system will report status back to the WSUS server. Normally this
could take 20-30 minutes, but since you're trying to do this on every PC in
the whole organization simultaneously, it might actually take several
hours -- depending on how many systems there actually are.
At which point the status will either change from "Needed" to "Installed" if
the update was successfully installed.
from "Needed" to "Failed", if the installation failed,
or from "Needed" to "Not Applicable" if a superceding update was
installed instead of a superceded update,
in which case, the old update is no longer needed, and is, as
reported, not applicable.
Your needed counter will decrease, but that's only half the story.
You also need to monitor the Installed/Not Applicable and Failed counters to
ensure that the installations were successful.
> I understand your reasoning if I am in the patch view, but if I'm looking
> at
> the list of computers and it says needed:
If it says "Needed", that means the patch is not installed on that system,
but needs to be installed. Ergo, it is =needed=.
> 1. I would expect that one patch
> that I approved hasn't been applied to that machine yet. Not one patch
> that I
> may or may not decide to apply later is needed.
If you consider that "Needed" == "Not Installed", and "Installed" ==
"Installed", this might help.
An update can only have one of four status conditions: "Not Applicable",
"Needed", "Failed", or "Installed".
> I agree with you that the needed column should behave the way you
> described
> when looking at patched, but when looking at the computer list, this makes
> no
> sense.
It's the same *DATA* in both reports -- just a different grouping and
sorting. WSUS doesn't store different status information by update than it
does by computer.
Consider a spreadsheet. Computers across the columns; Updates across the
rows. Every intersection of a computer and an update has ONE STATUS which is
contained in the cell where that row and column intersect. The status
applies to the entire WSUS environment, regardless of whether you're looking
at it by computer, or by update -- either "Not Applicable", "Needed",
"Failed", or "Installed". The status is about *that* update for *that*
computer.
Why would you expect it to be different from one view to the next? What
would you expect it to be, if not "Needed"?
--
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) wrote:
[Quoted Text] > If you consider that "Needed" == "Not Installed", and "Installed" ==
> "Installed", this might help.
>
> An update can only have one of four status conditions: "Not Applicable",
> "Needed", "Failed", or "Installed".
[...]
> What would you expect it to be, if not "Needed"?
I think there's a good case for distinguishing between updates that are due to
be installed and updates that are needed but haven't been approved. That is, I
think it would substantially improve WSUS if this could be done ... maybe in
version 4. :-)
Maybe something like this:
Not Applicable - doesn't apply to the system
Needed - does apply to the system, isn't installed, is approved
Not Approved - does apply to the system, isn't installed, isn't approved
Failed - tried to install and couldn't
Installed - installed
Or maybe "Approved" or "Pending" would be better than "Needed".
At the moment the only way to easily distinguish between the updates you
actually want installed and those you don't is to decline the latter - but
that's a very blunt instrument. In particular you can't decline an update for
just one group (at least as of WSUS 2).
Harry.
|
|
Not all patches go out to desktops. In the event that I need to patch servers
or a lab where I have 2-3 hours of scheduled downtime, I need them to go out
immediately (hence the psexec command). This way I can approve the patch, run
wuauclt on the machines, and have them start scanning and patching right
away. I keep and eye on the needed numbers to see what servers are having
issues, and when the count number gets to zero, I know I'm patched.
I used to use shavlik to push (since you're being "technical" ... I used
shavik to create scheduled tasks across the servers to start batch patch
installations)
I know WSUS wasn't really meant to install patches in this manner, but it
keeps track of the patches much better than shavlik, and the psexec is a
workaround to use wsus to do a.. push-like install.
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message > news:03ACCFA6-F927-4CB2-BDA8-D140799F96B1[ at ]microsoft.com... > > How I expect to use it is this: > > > > Let's say that it's time to push patches.. > > First thing we need to clarify. You don't push patches. You make updates > available for detection by client systems. The client systems initiate a > detection event at a regularly scheduled interval (22 hours, by default). > They download the content for any updates that are approved, and then > install those updates according to the policy you've configured. (Either > user installed, or at a scheduled installation time.) All status definitions > are reported by the client, based on the perspective of the client system. > > > So I approve the patches that I want to go out (with a deadline of 2 years > > ago), > > You really want them installed =now=, eh? > > > run my trusty "psexec \\* wuauclt.exe /detectnow". > > > I want to use the needed counter to see what > > machines are 100% patched and what machines haven't installed the approved > > patches. > > Well, there's the first misunderstanding. Once your trusty 'psexec \\* > wuauclt.exe /detectnow' successfully runs (and it presumes that the command > *is* successfully running). The client will do just as I described above. It > will: > [a] determine if any updates are approved. > [b] download the content to be installed. > [c] schedule the updates for installation -or- notify a logged on > administrator that updates are available to be installed. > but, since you've configured expired deadlines on all of the > updates, the updates will be installed *immediately*, > the system will reboot *immediately*, > your users will be annoyed as all get out because you rebooted > their system without warning in the middle of the workday > > (Aren't you glad they're not installing???) > > [d] AFTER installation is complete AND the system is restarted, > [e] The system will report status back to the WSUS server. Normally this > could take 20-30 minutes, but since you're trying to do this on every PC in > the whole organization simultaneously, it might actually take several > hours -- depending on how many systems there actually are. > > > At which point the status will either change from "Needed" to "Installed" if > the update was successfully installed. > from "Needed" to "Failed", if the installation failed, > or from "Needed" to "Not Applicable" if a superceding update was > installed instead of a superceded update, > in which case, the old update is no longer needed, and is, as > reported, not applicable. > > Your needed counter will decrease, but that's only half the story. > You also need to monitor the Installed/Not Applicable and Failed counters to > ensure that the installations were successful. > > > I understand your reasoning if I am in the patch view, but if I'm looking > > at > > the list of computers and it says needed: > > If it says "Needed", that means the patch is not installed on that system, > but needs to be installed. Ergo, it is =needed=. > > > 1. I would expect that one patch > > that I approved hasn't been applied to that machine yet. Not one patch > > that I > > may or may not decide to apply later is needed. > > If you consider that "Needed" == "Not Installed", and "Installed" == > "Installed", this might help. > > An update can only have one of four status conditions: "Not Applicable", > "Needed", "Failed", or "Installed". > > > I agree with you that the needed column should behave the way you > > described > > when looking at patched, but when looking at the computer list, this makes > > no > > sense. > > It's the same *DATA* in both reports -- just a different grouping and > sorting. WSUS doesn't store different status information by update than it > does by computer. > > Consider a spreadsheet. Computers across the columns; Updates across the > rows. Every intersection of a computer and an update has ONE STATUS which is > contained in the cell where that row and column intersect. The status > applies to the entire WSUS environment, regardless of whether you're looking > at it by computer, or by update -- either "Not Applicable", "Needed", > "Failed", or "Installed". The status is about *that* update for *that* > computer. > > Why would you expect it to be different from one view to the next? What > would you expect it to be, if not "Needed"? > > -- > 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> ..... > > > |
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23%23LMIojrHHA.532[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] >> What would you expect it to be, if not "Needed"?
> I think there's a good case for distinguishing between updates that are
> due to be installed and updates that are needed but haven't been approved.
> That is, I think it would substantially improve WSUS if this could be done
> ... maybe in version 4. :-)
This is a function of the automatic Auto-Detect rule in WSUS 3, which, to be
honest, isn't a heck of a lot different than the default configuration of
the Auto-Approve for Detection (for Critical/Security Updates) in WSUS 2.
The reality is that there's never been a distinction. Update that are due to
be installed have a "Downloaded Successful" substatus, which can be obtained
by clicking on the "Needed" hyperlink in the update or computer listing. In
addition, "updates that are due to be installed" have an approval status of
"Install". Updates that are "needed but haven't been approved" have an
approval status of "Not Approved".
I'm not understanding what you're looking for, since it seems to me to
already be right there in the interface.
> Maybe something like this:
>
> Not Applicable - doesn't apply to the system
> Failed - tried to install and couldn't
> Installed - installed
These three already exist, exactly as described.
> Needed - does apply to the system, isn't installed, is approved
> Not Approved - does apply to the system, isn't installed, isn't approved
The COMPUTER status, and the APPROVAL status are two independent things, and
this suggestion here is mixing those apples and oranges.
"Needed" absolutely *does* mean "does apply to the system and is not
installed". Whether or not the update is approved, or not approved, doesn't
change the fact that an update is not installed on a machine it should be
installed on.
Either way, those two combinations above are exactly what I just described
in my first paragraph.
COMPUTER APPROVAL
STATUS STATUS
Needed Install -- means "does apply to the
system, isn't installed, is approved"
Needed Not Approved -- means "does apply to the system,
isn't installed, isn't approved"
Pretty much the basic operation of the current and previous version.
> At the moment the only way to easily distinguish between the updates you
> actually want installed and those you don't is to decline the latter
No.. the *best* way to distinguish between
[a] the updates you actually want installed, and
[b] those you don't
is that the updates in [a] are approved for INSTALLATION,
and the updates in [b] are Not Approved.
And, if you don't want those "Not Approved" updates to cloud up the
"Needed" counts because they're *never* going to install, then you *should*
Decline those updates.
Others, such as .NET Framework v2.0, .NET Framework v3.0, Windows Server
2003 Service Pack 2, are a matter of discussion. Oh, sure, ideally I'd like
the WSUS server to be so intelligent that it doesn't report them as "Needed"
until I care whether they're "Needed". Unfortunately, that's the "Detect
Only" approval status that was removed from WSUS v2.0.
--
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
.....
|
|
"EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
news:40ECC616-C600-4E1E-A796-0019E5520C45[ at ]microsoft.com...
[Quoted Text] > Not all patches go out to desktops. In the event that I need to patch
> servers
> or a lab where I have 2-3 hours of scheduled downtime,
If you have 2-3 hours of /scheduled/ downtime, then why not just configure a
/scheduled/ installation event via policy?
> I need them to go out
> immediately (hence the psexec command). This way I can approve the patch,
> run
> wuauclt on the machines, and have them start scanning and patching right
> away. I keep and eye on the needed numbers to see what servers are having
> issues, and when the count number gets to zero, I know I'm patched.
I got no fault with your methodology. I'm just pointing out the implications
and ramifications of doing that en masse.
--
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 know WSUS wasn't really meant to install patches in this manner, but it
> keeps track of the patches much better than shavlik, and the psexec is a
> workaround to use wsus to do a.. push-like install.
>
> "Lawrence Garvin (MVP)" wrote:
>
>> "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
>> news:03ACCFA6-F927-4CB2-BDA8-D140799F96B1[ at ]microsoft.com...
>> > How I expect to use it is this:
>> >
>> > Let's say that it's time to push patches..
>>
>> First thing we need to clarify. You don't push patches. You make updates
>> available for detection by client systems. The client systems initiate a
>> detection event at a regularly scheduled interval (22 hours, by default).
>> They download the content for any updates that are approved, and then
>> install those updates according to the policy you've configured. (Either
>> user installed, or at a scheduled installation time.) All status
>> definitions
>> are reported by the client, based on the perspective of the client
>> system.
>>
>> > So I approve the patches that I want to go out (with a deadline of 2
>> > years
>> > ago),
>>
>> You really want them installed =now=, eh?
>>
>> > run my trusty "psexec \\* wuauclt.exe /detectnow".
>>
>> > I want to use the needed counter to see what
>> > machines are 100% patched and what machines haven't installed the
>> > approved
>> > patches.
>>
>> Well, there's the first misunderstanding. Once your trusty 'psexec \\*
>> wuauclt.exe /detectnow' successfully runs (and it presumes that the
>> command
>> *is* successfully running). The client will do just as I described above.
>> It
>> will:
>> [a] determine if any updates are approved.
>> [b] download the content to be installed.
>> [c] schedule the updates for installation -or- notify a logged on
>> administrator that updates are available to be installed.
>> but, since you've configured expired deadlines on all of the
>> updates, the updates will be installed *immediately*,
>> the system will reboot *immediately*,
>> your users will be annoyed as all get out because you
>> rebooted
>> their system without warning in the middle of the workday
>>
>> (Aren't you glad they're not installing???)
>>
>> [d] AFTER installation is complete AND the system is restarted,
>> [e] The system will report status back to the WSUS server. Normally
>> this
>> could take 20-30 minutes, but since you're trying to do this on every PC
>> in
>> the whole organization simultaneously, it might actually take several
>> hours -- depending on how many systems there actually are.
>>
>>
>> At which point the status will either change from "Needed" to "Installed"
>> if
>> the update was successfully installed.
>> from "Needed" to "Failed", if the installation failed,
>> or from "Needed" to "Not Applicable" if a superceding update was
>> installed instead of a superceded update,
>> in which case, the old update is no longer needed, and is, as
>> reported, not applicable.
>>
>> Your needed counter will decrease, but that's only half the story.
>> You also need to monitor the Installed/Not Applicable and Failed counters
>> to
>> ensure that the installations were successful.
>>
>> > I understand your reasoning if I am in the patch view, but if I'm
>> > looking
>> > at
>> > the list of computers and it says needed:
>>
>> If it says "Needed", that means the patch is not installed on that
>> system,
>> but needs to be installed. Ergo, it is =needed=.
>>
>> > 1. I would expect that one patch
>> > that I approved hasn't been applied to that machine yet. Not one patch
>> > that I
>> > may or may not decide to apply later is needed.
>>
>> If you consider that "Needed" == "Not Installed", and "Installed" ==
>> "Installed", this might help.
>>
>> An update can only have one of four status conditions: "Not Applicable",
>> "Needed", "Failed", or "Installed".
>>
>> > I agree with you that the needed column should behave the way you
>> > described
>> > when looking at patched, but when looking at the computer list, this
>> > makes
>> > no
>> > sense.
>>
>> It's the same *DATA* in both reports -- just a different grouping and
>> sorting. WSUS doesn't store different status information by update than
>> it
>> does by computer.
>>
>> Consider a spreadsheet. Computers across the columns; Updates across the
>> rows. Every intersection of a computer and an update has ONE STATUS which
>> is
>> contained in the cell where that row and column intersect. The status
>> applies to the entire WSUS environment, regardless of whether you're
>> looking
>> at it by computer, or by update -- either "Not Applicable", "Needed",
>> "Failed", or "Installed". The status is about *that* update for *that*
>> computer.
>>
>> Why would you expect it to be different from one view to the next? What
>> would you expect it to be, if not "Needed"?
>>
>> --
>> 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
>> .....
>>
>>
>>
|
|
Tried scheduling. Servers were in multiple time zones, so scheduling caused
the patches to fire in each respective time zone.. So setting a 6PM deadline
would behave differently on different machines.. Maybe another feature
request to be able to specify timezone? So I can say at 6:00 PST install.
(I know I can create different patch groups. A PST, Eastern, GMT, etc..) But
it was easier to manage with PSEXEC.
....
So we've strayed from the original request... But hopefully that clears up
why I think that needed shouldn't count patched that I haven't approved. If I
haven't approved, or declined.... let's say Desktop Search because we're
still testing it.. It shouldn't be in the needed list.
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message > news:40ECC616-C600-4E1E-A796-0019E5520C45[ at ]microsoft.com... > > Not all patches go out to desktops. In the event that I need to patch > > servers > > or a lab where I have 2-3 hours of scheduled downtime, > > If you have 2-3 hours of /scheduled/ downtime, then why not just configure a > /scheduled/ installation event via policy? > > > I need them to go out > > immediately (hence the psexec command). This way I can approve the patch, > > run > > wuauclt on the machines, and have them start scanning and patching right > > away. I keep and eye on the needed numbers to see what servers are having > > issues, and when the count number gets to zero, I know I'm patched. > > I got no fault with your methodology. I'm just pointing out the implications > and ramifications of doing that en masse. > > -- > 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 know WSUS wasn't really meant to install patches in this manner, but it > > keeps track of the patches much better than shavlik, and the psexec is a > > workaround to use wsus to do a.. push-like install. > > > > "Lawrence Garvin (MVP)" wrote: > > > >> "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message > >> news:03ACCFA6-F927-4CB2-BDA8-D140799F96B1[ at ]microsoft.com... > >> > How I expect to use it is this: > >> > > >> > Let's say that it's time to push patches.. > >> > >> First thing we need to clarify. You don't push patches. You make updates > >> available for detection by client systems. The client systems initiate a > >> detection event at a regularly scheduled interval (22 hours, by default). > >> They download the content for any updates that are approved, and then > >> install those updates according to the policy you've configured. (Either > >> user installed, or at a scheduled installation time.) All status > >> definitions > >> are reported by the client, based on the perspective of the client > >> system. > >> > >> > So I approve the patches that I want to go out (with a deadline of 2 > >> > years > >> > ago), > >> > >> You really want them installed =now=, eh? > >> > >> > run my trusty "psexec \\* wuauclt.exe /detectnow". > >> > >> > I want to use the needed counter to see what > >> > machines are 100% patched and what machines haven't installed the > >> > approved > >> > patches. > >> > >> Well, there's the first misunderstanding. Once your trusty 'psexec \\* > >> wuauclt.exe /detectnow' successfully runs (and it presumes that the > >> command > >> *is* successfully running). The client will do just as I described above. > >> It > >> will: > >> [a] determine if any updates are approved. > >> [b] download the content to be installed. > >> [c] schedule the updates for installation -or- notify a logged on > >> administrator that updates are available to be installed. > >> but, since you've configured expired deadlines on all of the > >> updates, the updates will be installed *immediately*, > >> the system will reboot *immediately*, > >> your users will be annoyed as all get out because you > >> rebooted > >> their system without warning in the middle of the workday > >> > >> (Aren't you glad they're not installing???) > >> > >> [d] AFTER installation is complete AND the system is restarted, > >> [e] The system will report status back to the WSUS server. Normally > >> this > >> could take 20-30 minutes, but since you're trying to do this on every PC > >> in > >> the whole organization simultaneously, it might actually take several > >> hours -- depending on how many systems there actually are. > >> > >> > >> At which point the status will either change from "Needed" to "Installed" > >> if > >> the update was successfully installed. > >> from "Needed" to "Failed", if the installation failed, > >> or from "Needed" to "Not Applicable" if a superceding update was > >> installed instead of a superceded update, > >> in which case, the old update is no longer needed, and is, as > >> reported, not applicable. > >> > >> Your needed counter will decrease, but that's only half the story. > >> You also need to monitor the Installed/Not Applicable and Failed counters > >> to > >> ensure that the installations were successful. > >> > >> > I understand your reasoning if I am in the patch view, but if I'm > >> > looking > >> > at > >> > the list of computers and it says needed: > >> > >> If it says "Needed", that means the patch is not installed on that > >> system, > >> but needs to be installed. Ergo, it is =needed=. > >> > >> > 1. I would expect that one patch > >> > that I approved hasn't been applied to that machine yet. Not one patch > >> > that I > >> > may or may not decide to apply later is needed. > >> > >> If you consider that "Needed" == "Not Installed", and "Installed" == > >> "Installed", this might help. > >> > >> An update can only have one of four status conditions: "Not Applicable", > >> "Needed", "Failed", or "Installed". > >> > >> > I agree with you that the needed column should behave the way you > >> > described > >> > when looking at patched, but when looking at the computer list, this > >> > makes > >> > no > >> > sense. > >> > >> It's the same *DATA* in both reports -- just a different grouping and > >> sorting. WSUS doesn't store different status information by update than > >> it > >> does by computer. > >> > >> Consider a spreadsheet. Computers across the columns; Updates across the > >> rows. Every intersection of a computer and an update has ONE STATUS which > >> is > >> contained in the cell where that row and column intersect. The status > >> applies to the entire WSUS environment, regardless of whether you're > >> looking > >> at it by computer, or by update -- either "Not Applicable", "Needed", > >> "Failed", or "Installed". The status is about *that* update for *that* > >> computer. > >> > >> Why would you expect it to be different from one view to the next? What > >> would you expect it to be, if not "Needed"? > >> > >> -- > >> 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> >> ..... > >> > >> > >> > > > |
|
"EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
news:42CCF22E-F707-49BA-828A-54719C70E1E3[ at ]microsoft.com...
[Quoted Text] > Tried scheduling. Servers were in multiple time zones, so scheduling
> caused
> the patches to fire in each respective time zone..
Yeah.. so... you got all these servers in *different* time zones in the same
OU?
Put 'em in different OUs, or create security groups, create the necessary
policies with the appropriate local time configured, and apply the policy to
the correct servers.
> So setting a 6PM deadline
> would behave differently on different machines..
Don't set the deadlines!!!! Use the /scheduled/ installation!
> Maybe another feature
> request to be able to specify timezone? So I can say at 6:00 PST install.
Maybe... but I'd lean towards separate OUs by location. (I'm surprised you
even have them configured in the same AD SITE!)
> (I know I can create different patch groups. A PST, Eastern, GMT, etc..)
> But
> it was easier to manage with PSEXEC.
Whatever.... I don't generally buy into the argument that 'interactive' is
easier to manage than 'automated', but to each their own. ;-)
> So we've strayed from the original request... But hopefully that clears up
> why I think that needed shouldn't count patched that I haven't approved.
> If I
> haven't approved, or declined.... let's say Desktop Search because we're
> still testing it.. It shouldn't be in the needed list.
And.... so then... how would you ever know if the update WAS needed???
--
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)" wrote:
[Quoted Text] > "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
> news:42CCF22E-F707-49BA-828A-54719C70E1E3[ at ]microsoft.com...
> > Tried scheduling. Servers were in multiple time zones, so scheduling
> > caused
> > the patches to fire in each respective time zone..
>
> Yeah.. so... you got all these servers in *different* time zones in the same
> OU?
>
> Put 'em in different OUs, or create security groups, create the necessary
> policies with the appropriate local time configured, and apply the policy to
> the correct servers.
The servers are next to each other in the rack but are in different time
zones. Technical reason for this is not in the scope of this discussion...
>
> > So setting a 6PM deadline
> > would behave differently on different machines..
>
> Don't set the deadlines!!!! Use the /scheduled/ installation!
>
Technical reason we can't schedule automatic reboots out of the scope of
WSUS. But... I can say that psexec is a good way to get the systems to do
what we want, when we want.
> > Maybe another feature
> > request to be able to specify timezone? So I can say at 6:00 PST install.
>
> Maybe... but I'd lean towards separate OUs by location. (I'm surprised you
> even have them configured in the same AD SITE!)
>
I agree that there are nifty things you can do with OUs and GPO, but that's
not really related to WSUS or the needed column. And even if *I wanted* to
tell you what we were doing and why, I couldn't.
> > (I know I can create different patch groups. A PST, Eastern, GMT, etc..)
> > But
> > it was easier to manage with PSEXEC.
>
> Whatever.... I don't generally buy into the argument that 'interactive' is
> easier to manage than 'automated', but to each their own. ;-)
>
Every environment is different so flexibility is alway good! Let's just say
I want to be 100% sure of the state of all machines before patching starts.
Details of why scheduled patching doesn't work in our environment.. Out of
scope of this discussion.
> > So we've strayed from the original request... But hopefully that clears up
> > why I think that needed shouldn't count patched that I haven't approved.
> > If I
> > haven't approved, or declined.... let's say Desktop Search because we're
> > still testing it.. It shouldn't be in the needed list.
>
> And.... so then... how would you ever know if the update WAS needed???
Good question.. Maybe like Harry Johnston mentioned earlier in the thread..
There could be another category to distinguish Approved Patches that haven't
been applied, and non-approved patches that are applicable to the system.
Installed, Failed, Needed, Non applicable, Pending (approved not applied
yet). What I care more about is patched that I approved that haven't gone
out. Or a filter button that says "Filter out any patches that have not been
approved". This way when I want to see all patches, I can, if not, then I
don't.
>
> --
> 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 Jun 15, 4:20 am, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Harry Johnston" <h...[ at ]scms.waikato.ac.nz> wrote in message > > news:%23%23LMIojrHHA.532[ at ]TK2MSFTNGP06.phx.gbl... > > >> What would you expect it to be, if not "Needed"? > > I think there's a good case for distinguishing between updates that are > > due to be installed and updates that are needed but haven't been approved. > > That is, I think it would substantially improve WSUS if this could be done > > ... maybe in version 4. :-) > > This is a function of the automatic Auto-Detect rule in WSUS 3, which, to be > honest, isn't a heck of a lot different than the default configuration of > the Auto-Approve for Detection (for Critical/Security Updates) in WSUS 2. > > The reality is that there's never been a distinction. Update that are due to > be installed have a "Downloaded Successful" substatus, which can be obtained > by clicking on the "Needed" hyperlink in the update or computer listing. In > addition, "updates that are due to be installed" have an approval status of > "Install". Updates that are "needed but haven't been approved" have an > approval status of "Not Approved". > > I'm not understanding what you're looking for, since it seems to me to > already be right there in the interface. > > > Maybe something like this: > > > Not Applicable - doesn't apply to the system > > Failed - tried to install and couldn't > > Installed - installed > > These three already exist, exactly as described. > > > Needed - does apply to the system, isn't installed, is approved > > Not Approved - does apply to the system, isn't installed, isn't approved > > The COMPUTER status, and the APPROVAL status are two independent things, and > this suggestion here is mixing those apples and oranges. > > "Needed" absolutely *does* mean "does apply to the system and is not > installed". Whether or not the update is approved, or not approved, doesn't > change the fact that an update is not installed on a machine it should be > installed on. > > Either way, those two combinations above are exactly what I just described > in my first paragraph. > > COMPUTER APPROVAL > STATUS STATUS > Needed Install -- means "does apply to the > system, isn't installed, is approved" > Needed Not Approved -- means "does apply to the system, > isn't installed, isn't approved" > > Pretty much the basic operation of the current and previous version. > > > At the moment the only way to easily distinguish between the updates you > > actually want installed and those you don't is to decline the latter > > No.. the *best* way to distinguish between > [a] the updates you actually want installed, and > [b] those you don't > > is that the updates in [a] are approved for INSTALLATION, > and the updates in [b] are Not Approved. > > And, if you don't want those "Not Approved" updates to cloud up the > "Needed" counts because they're *never* going to install, then you *should* > Decline those updates. > > Others, such as .NET Framework v2.0, .NET Framework v3.0, Windows Server > 2003 Service Pack 2, are a matter of discussion. Oh, sure, ideally I'd like > the WSUS server to be so intelligent that it doesn't report them as "Needed" > until I care whether they're "Needed". Unfortunately, that's the "Detect > Only" approval status that was removed from WSUS v2.0. > > -- > 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> ....
And since you are considering split in this way (Computer status/
Approval status) then why was so hard to create a report from COMPUTER
view - which can show that specific computer IS up-to-date (regarding
OUR point of view, not MS's)? Like in WSUS 2 version? It looks like
you (and MS) are trying to enforce your oppinion about what's up-to-
date. I like WSUS 3.0 - but this is a big error in it - uppon me.
Tila
|
|
"Tila" <kilinattila[ at ]gmail.com> wrote in message
news:1181908232.356035.127290[ at ]u2g2000hsc.googlegroups.com...
[Quoted Text] > And since you are considering split in this way (Computer status/
> Approval status) then why was so hard to create a report from COMPUTER
> view - which can show that specific computer IS up-to-date (regarding
> OUR point of view, not MS's)? Like in WSUS 2 version?
Because, as has been commented elsewhere numerous times, the dev team was
not aware of the negative implications of the "always on auto-detect rule"
until they were beyond the point of no return.
> It looks like
> you (and MS) are trying to enforce your oppinion about what's up-to-
> date.
No... we're just pointing out how the system DOES work. It's a new version.
It works differently. I understand some people don't like it; some people
will take time getting used to it; some people won't even notice.
> I like WSUS 3.0 - but this is a big error in it - uppon me.
Actually, until about 24 hours ago, I was a staunch supporter of those who
thought the WSUS 3 methodology was a critical flaw.
But in the past 24 hours, having given thought to what happens if you're
given exactly what you're asking for, I find myself asking this question:
What happens if the WSUS Administrator has missed approving an update?
In your desired scenario, the computer will show as 100% patched,
because it's based on what is *approved*, and not on what is *needed*.
The report, of which you ask for, will (erronously, I submit) mislead
you into believing your systems are 100% patched, when, in fact, they're
actually missing a critical update, or maybe even a security update! Because
of *human* error!
So... for the time being... and until anybody responds to my three or four
posts pointing out this consideration... I think my stripes may be
a-changing, and I'm going to adapt, and be thankful that the report is
*accurately* indicating that there are updates not installed, and that I'm
easily capable of confirming that the 3 updates not installed are, in fact,
the 3 that I have not approved for installation.
Besides... if you truly want a Compliance Report. You shouldn't be getting
it from the same source that's determining what you do or do not need to
install. You should be getting it from an independent tool.
--
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
.....
|
|
=?Utf-8?B?RWRC?= <EdB[ at ]discussions.microsoft.com> wrote in
news:E045A78D-4F11-4DBD-A595-CBDB3F6C230D[ at ]microsoft.com:
[Quoted Text] >
> "Lawrence Garvin (MVP)" wrote:
>
>> "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message
>> news:42CCF22E-F707-49BA-828A-54719C70E1E3[ at ]microsoft.com...
>> > Tried scheduling. Servers were in multiple time zones, so
>> > scheduling caused
>> > the patches to fire in each respective time zone..
>>
>> Yeah.. so... you got all these servers in *different* time zones in
>> the same OU?
>>
>> Put 'em in different OUs, or create security groups, create the
>> necessary policies with the appropriate local time configured, and
>> apply the policy to the correct servers.
>
> The servers are next to each other in the rack but are in different
> time zones. Technical reason for this is not in the scope of this
> discussion...
>
>>
>> > So setting a 6PM deadline
>> > would behave differently on different machines..
>>
>> Don't set the deadlines!!!! Use the /scheduled/ installation!
>>
>
> Technical reason we can't schedule automatic reboots out of the scope
> of WSUS. But... I can say that psexec is a good way to get the systems
> to do what we want, when we want.
>
>> > Maybe another feature
>> > request to be able to specify timezone? So I can say at 6:00 PST
>> > install.
>>
>> Maybe... but I'd lean towards separate OUs by location. (I'm
>> surprised you even have them configured in the same AD SITE!)
>>
>
> I agree that there are nifty things you can do with OUs and GPO, but
> that's not really related to WSUS or the needed column. And even if *I
> wanted* to tell you what we were doing and why, I couldn't.
>
>> > (I know I can create different patch groups. A PST, Eastern, GMT,
>> > etc..) But
>> > it was easier to manage with PSEXEC.
>>
>> Whatever.... I don't generally buy into the argument that
>> 'interactive' is easier to manage than 'automated', but to each their
>> own. ;-)
>>
>
> Every environment is different so flexibility is alway good! Let's
> just say I want to be 100% sure of the state of all machines before
> patching starts. Details of why scheduled patching doesn't work in our
> environment.. Out of scope of this discussion.
>
>> > So we've strayed from the original request... But hopefully that
>> > clears up why I think that needed shouldn't count patched that I
>> > haven't approved. If I
>> > haven't approved, or declined.... let's say Desktop Search because
>> > we're still testing it.. It shouldn't be in the needed list.
>>
>> And.... so then... how would you ever know if the update WAS
>> needed???
>
> Good question.. Maybe like Harry Johnston mentioned earlier in the
> thread.. There could be another category to distinguish Approved
> Patches that haven't been applied, and non-approved patches that are
> applicable to the system.
>
> Installed, Failed, Needed, Non applicable, Pending (approved not
> applied yet). What I care more about is patched that I approved that
> haven't gone out. Or a filter button that says "Filter out any patches
> that have not been approved". This way when I want to see all patches,
> I can, if not, then I don't.
>
That already exists!!! Go to the 'Updates' part of the tree and right
click. Choose 'New Update View'. Choose 'Updates are approved for a
specific group'. Choose 'All computers'.
Voila! you will get a pie chart showing you the installation status of
your approved updates. From there you can see which systems are lacking
which updates.
>>
>> --
>> Lawrence Garvin, M.S., MCTS, MCP
>> Independent WSUS Evangelist
>> MVP-Software Distribution (2005-2007)
>> https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095
>> EB07B36E
>>
>> Everything you need for WSUS is at
>> http://technet2.microsoft.com/windowsserver/en/technologies/featured/w
>> sus/default.mspx
>>
>> And, almost everything else is at
>> http://wsusinfo.onsitechsolutions.com
>> .....
>>
>>
>>
>
|
|
Thanks Asher_N. That's exactly what I wanted!
"Asher_N" wrote:
[Quoted Text] > =?Utf-8?B?RWRC?= <EdB[ at ]discussions.microsoft.com> wrote in > news:E045A78D-4F11-4DBD-A595-CBDB3F6C230D[ at ]microsoft.com: > > > > > "Lawrence Garvin (MVP)" wrote: > > > >> "EdB" <EdB[ at ]discussions.microsoft.com> wrote in message > >> news:42CCF22E-F707-49BA-828A-54719C70E1E3[ at ]microsoft.com... > >> > Tried scheduling. Servers were in multiple time zones, so > >> > scheduling caused > >> > the patches to fire in each respective time zone.. > >> > >> Yeah.. so... you got all these servers in *different* time zones in > >> the same OU? > >> > >> Put 'em in different OUs, or create security groups, create the > >> necessary policies with the appropriate local time configured, and > >> apply the policy to the correct servers. > > > > The servers are next to each other in the rack but are in different > > time zones. Technical reason for this is not in the scope of this > > discussion... > > > >> > >> > So setting a 6PM deadline > >> > would behave differently on different machines.. > >> > >> Don't set the deadlines!!!! Use the /scheduled/ installation! > >> > > > > Technical reason we can't schedule automatic reboots out of the scope > > of WSUS. But... I can say that psexec is a good way to get the systems > > to do what we want, when we want. > > > >> > Maybe another feature > >> > request to be able to specify timezone? So I can say at 6:00 PST > >> > install. > >> > >> Maybe... but I'd lean towards separate OUs by location. (I'm > >> surprised you even have them configured in the same AD SITE!) > >> > > > > I agree that there are nifty things you can do with OUs and GPO, but > > that's not really related to WSUS or the needed column. And even if *I > > wanted* to tell you what we were doing and why, I couldn't. > > > >> > (I know I can create different patch groups. A PST, Eastern, GMT, > >> > etc..) But > >> > it was easier to manage with PSEXEC. > >> > >> Whatever.... I don't generally buy into the argument that > >> 'interactive' is easier to manage than 'automated', but to each their > >> own. ;-) > >> > > > > Every environment is different so flexibility is alway good! Let's > > just say I want to be 100% sure of the state of all machines before > > patching starts. Details of why scheduled patching doesn't work in our > > environment.. Out of scope of this discussion. > > > >> > So we've strayed from the original request... But hopefully that > >> > clears up why I think that needed shouldn't count patched that I > >> > haven't approved. If I > >> > haven't approved, or declined.... let's say Desktop Search because > >> > we're still testing it.. It shouldn't be in the needed list. > >> > >> And.... so then... how would you ever know if the update WAS > >> needed??? > > > > Good question.. Maybe like Harry Johnston mentioned earlier in the > > thread.. There could be another category to distinguish Approved > > Patches that haven't been applied, and non-approved patches that are > > applicable to the system. > > > > Installed, Failed, Needed, Non applicable, Pending (approved not > > applied yet). What I care more about is patched that I approved that > > haven't gone out. Or a filter button that says "Filter out any patches > > that have not been approved". This way when I want to see all patches, > > I can, if not, then I don't. > > > > > That already exists!!! Go to the 'Updates' part of the tree and right > click. Choose 'New Update View'. Choose 'Updates are approved for a > specific group'. Choose 'All computers'. > > Voila! you will get a pie chart showing you the installation status of > your approved updates. From there you can see which systems are lacking > which updates. > > > >> > >> -- > >> Lawrence Garvin, M.S., MCTS, MCP > >> Independent WSUS Evangelist > >> MVP-Software Distribution (2005-2007) > >> https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095> >> EB07B36E > >> > >> Everything you need for WSUS is at > >> http://technet2.microsoft.com/windowsserver/en/technologies/featured/w> >> sus/default.mspx > >> > >> And, almost everything else is at > >> http://wsusinfo.onsitechsolutions.com> >> ..... > >> > >> > >> > > > > |
|
|
[Quoted Text] > > I like WSUS 3.0 - but this is a big error in it - uppon me.
>
> Actually, until about 24 hours ago, I was a staunch supporter of those who
> thought the WSUS 3 methodology was a critical flaw.
>
> But in the past 24 hours, having given thought to what happens if you're
> given exactly what you're asking for, I find myself asking this question:
>
> What happens if the WSUS Administrator has missed approving an update?
But we are also talking about updates DECLINED for some reason - and
not necessarily security updates, just "enhancements".
>
> In your desired scenario, the computer will show as 100% patched,
> because it's based on what is *approved*, and not on what is *needed*.
>
> The report, of which you ask for, will (erronously, I submit) mislead
> you into believing your systems are 100% patched, when, in fact, they're
> actually missing a critical update, or maybe even a security update! Because
> of *human* error!
This is why somebody already suggested a new "type" - needed, but
declined by admin. I agree, that all the updates should be either
approved or declined - I think, here was a missunderstoodable point.
So, if we just separate the updates in this two category: approved or
declined, do you agree, that now this report doesn't helps us?
> So... for the time being... and until anybody responds to my three or four
> posts pointing out this consideration... I think my stripes may be
> a-changing, and I'm going to adapt, and be thankful that the report is
> *accurately* indicating that there are updates not installed, and that I'm
> easily capable of confirming that the 3 updates not installed are, in fact,
> the 3 that I have not approved for installation.
>
> Besides... if you truly want a Compliance Report. You shouldn't be getting
> it from the same source that's determining what you do or do not need to
> install. You should be getting it from an independent tool.
But if WSUS can do this, why another 3rd party? - I think, that WSUS
can be written in that way, which satisfy the criteria above.
Tila
|
|
"Tila" <kilinattila[ at ]gmail.com> wrote in message
news:1181998590.697267.152110[ at ]g4g2000hsf.googlegroups.com...
[Quoted Text] >> > I like WSUS 3.0 - but this is a big error in it - uppon me.
>> Actually, until about 24 hours ago, I was a staunch supporter of those
>> who
>> thought the WSUS 3 methodology was a critical flaw.
>>
>> But in the past 24 hours, having given thought to what happens if you're
>> given exactly what you're asking for, I find myself asking this question:
>>
>> What happens if the WSUS Administrator has missed approving an
>> update?
> But we are also talking about updates DECLINED for some reason - and
> not necessarily security updates, just "enhancements".
Updates that are declined are a whole different animal. For starters, it
takes a positive response to a warning dialog box to cause an update to be
Declined, so the idea that somebody "accidental Declined" an update doesn't
float with me.
Update that are declined do not report as Needed, they report as "No Status"
because the client can't even see the update to know what status to report,
thus it has "No Status".
>> In your desired scenario, the computer will show as 100% patched,
>> because it's based on what is *approved*, and not on what is *needed*.
>>
>> The report, of which you ask for, will (erronously, I submit) mislead
>> you into believing your systems are 100% patched, when, in fact, they're
>> actually missing a critical update, or maybe even a security update!
>> Because
>> of *human* error!
>
> This is why somebody already suggested a new "type" - needed, but
> declined by admin.
There is *NO* way to determine if an update is Needed if it is Declined. You
should not decline an update unless you have a very specific reason. Updates
can easily be UNdeclined to determine if they're needed, but if they're
never going to be installed (a decision made by a WSUS Administrator), then
what difference does it make if anything needs them or not, the Admin
already decided they are *not* going to be installed!
Although I would suggest, for complaince reasons, if nothing else, a
documentation log should be kept of every declined update and why it was
declined. Most will be declined because of supercession or expiration. But
some might be intentionally declined if the admin doesn't like the idea of
yellow pie slices in their otherwise perfect world of green pies.
> I agree, that all the updates should be either approved or declined
I disagree. For exactly the reason you defend above. What if a "declined"
update is *needed* to be installed? How will the admin trace the status of
uninstalled/needed updates once they're declined. I'm much happer seeing
that five updates have not been installed to my server, and knowing
*exactly* which five those are, than seeing a misleading report that the
machine is 100% patched, when I know for a fact it isn't. I never mark an
active update as declined, I simply leave it as "Not Approved".. which is,
IMHO, the *correct* approval status for such updates.
> So, if we just separate the updates in this two category: approved or
> declined, do you agree, that now this report doesn't helps us?
Nope. Your argument is theoretical, and invalid, because there aren't just
two categories -- there are three. (Not Approved, Install, Decline).
The report helps perfectly, provided that you're willing to interpret it the
way it was designed to be interpreted. If you try to make the report mean
something it doesn't, you'll never get anything accomplished.
>> Besides... if you truly want a Compliance Report. You shouldn't be
>> getting
>> it from the same source that's determining what you do or do not need to
>> install. You should be getting it from an independent tool.
> But if WSUS can do this, why another 3rd party?
*THAT* is a question for your SOX auditor(s). :-)
--
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) wrote:
[Quoted Text] >> I think there's a good case for distinguishing between updates that are
>> due to be installed and updates that are needed but haven't been approved.
>> That is, I think it would substantially improve WSUS if this could be done
>> ... maybe in version 4. :-)
>
> This is a function of the automatic Auto-Detect rule in WSUS 3, which, to be
> honest, isn't a heck of a lot different than the default configuration of
> the Auto-Approve for Detection (for Critical/Security Updates) in WSUS 2.
Actually I'm still using WSUS 2. My criticism applies to both versions, AFAIK.
> I'm not understanding what you're looking for, since it seems to me to
> already be right there in the interface.
The problem with the current setup is that if you have deliberately unapproved
updates, it is hard (or harder than it needs to be) to find computers that
haven't received the patches you have approved. In the computer view, instead
of just seeing the computers that haven't updated, you see all your computers.
If any of your computers haven't checked in lately, the update view shows all
the recent updates.
So instead of being able to see the status of the network at a glance, you have
to look at each computer or each update individually. This can take hours.
>> Needed - does apply to the system, isn't installed, is approved
>> Not Approved - does apply to the system, isn't installed, isn't approved
>
> The COMPUTER status, and the APPROVAL status are two independent things, and
> this suggestion here is mixing those apples and oranges.
Independent, but related in a very important way so far as reporting is concerned.
> "Needed" absolutely *does* mean "does apply to the system and is not
> installed". Whether or not the update is approved, or not approved, doesn't
> change the fact that an update is not installed on a machine it should be
> installed on.
"Should" according to Microsoft. Not necessarily according to me. :-)
> And, if you don't want those "Not Approved" updates to cloud up the
> "Needed" counts because they're *never* going to install, then you *should*
> Decline those updates.
But, as I pointed out, you can't decline updates for one group and approve them
for another. Plus if I decline an update that I am going to want later on, it
could easily get lost amidst all the obsoleted updates which you have to decline
if you don't want redundant installations - but that's another story. :-)
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23W4WZIHsHHA.4860[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >>> I think there's a good case for distinguishing between updates that are
>>> due to be installed and updates that are needed but haven't been
>>> approved. That is, I think it would substantially improve WSUS if this
>>> could be done ... maybe in version 4. :-)
>> This is a function of the automatic Auto-Detect rule in WSUS 3, which, to
>> be honest, isn't a heck of a lot different than the default configuration
>> of the Auto-Approve for Detection (for Critical/Security Updates) in WSUS
>> 2.
> Actually I'm still using WSUS 2. My criticism applies to both versions,
> AFAIK.
Okay. I'll try to keep your not-yet-WSUS3-engaged perspective in mind. :-)
I found an interesting thing in the UI of WSUS3 now that I have my RTM
package up and running.
The updates that were originally reported as "Needed" when the updates were
first detected, but not approved (e.g. IE7, .NET3.0, 2003SP2), are now being
reported as "Not Installed" against the status of "Not Approved". So, it
seems there's some modicum of intelligence in the scenario where I
deliberately did not approve an update. That is, instead of suggesting that
I should be doing something (i.e. approving an update for installation
because it is "needed") the report is now simply acknowledging the fact. The
update is "Not Installed".
>> I'm not understanding what you're looking for, since it seems to me to
>> already be right there in the interface.
> The problem with the current setup is that if you have deliberately
> unapproved updates, it is hard (or harder than it needs to be) to find
> computers that haven't received the patches you have approved.
Yes, this was a significant limitation of WSUS2, primarily because "Not
Approved" was a step below "Detect Only", so if you set an update to "Not
Approved" in WSUS2, the client will not execute a detection against that
update, and you'll never know the status. But to find computers that have
not installed patches that are approved, that should continue to show up as
"Needed" in the reports. In addition, in both versions, you can click on the
"Needed" hyperlink to get the client's download status of the update.
In WSUS3 to find computers that haven't received patches that are approved,
you only need to create a custom update view for "Approved" updates, and the
pie chart for that update group will immediately display pie slices
according to whether the approved updates are installed, or not.
> In the computer view, instead of just seeing the computers that haven't
> updated, you see all your computers. If any of your computers haven't
> checked in lately, the update view shows all the recent updates.
>
> So instead of being able to see the status of the network at a glance, you
> have to look at each computer or each update individually. This can take
> hours.
So.... it sounds like you've just identified a *bunch* of reasons why you'll
want to upgrade to WSUS3 ASAP! :-)
>> "Needed" absolutely *does* mean "does apply to the system and is not
>> installed". Whether or not the update is approved, or not approved,
>> doesn't change the fact that an update is not installed on a machine it
>> should be installed on.
>
> "Should" according to Microsoft. Not necessarily according to me. :-)
Yeah.. well.... there's two groups of updates that "Should" has different
considerations for.
There's the Security/Critical Updates, where Microsoft's "should" is the one
we ought to be following,
and then there's the Other Updates, like (IE7, .NET3, 2003SP2) where I'm not
at all interested in Microsoft's "should".
Again, with WSUS3, you can create two update views. One for
Critical/Security Updates, where your objective would actually be a 100%
green pie, and another for "Other Updates", where it's going to be presumed
normal to see a yellow slice of pie chart representing those updates you've
chosen not to install (yet).
>> And, if you don't want those "Not Approved" updates to cloud up the
>> "Needed" counts because they're *never* going to install, then you
>> *should* Decline those updates.
>
> But, as I pointed out, you can't decline updates for one group and approve
> them for another.
True... but I'm not sure what that has to do with anything, or why it's an
issue. The idea that you're *never* going to install an update, and the idea
that you'd want to approve the update for one group but not another, are
mutually exclusive. Personally, I'm not suggesting to anybody that they
should mark a current update as declined. But if it's bugging you that much
that computers are reporting that a Not Approved update is Needed / Not
Installed, then that is the only option.
> Plus if I decline an update that I am going to want later on, it could
> easily get lost amidst all the obsoleted updates which you have to decline
> if you don't want redundant installations - but that's another story. :-)
Yep. Another reason I don't recommend declining active updates.
--
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) wrote:
[Quoted Text] > In WSUS3 to find computers that haven't received patches that are approved,
> you only need to create a custom update view for "Approved" updates, and the
> pie chart for that update group will immediately display pie slices
> according to whether the approved updates are installed, or not.
I'll reserve judgement until I'm able to try it out, but a pie chart doesn't
sound all that useful. I need to know which computers, not just how many.
Also, I don't see how this would separate out the groups for which an update is
wanted from those for which it isn't. (I may be biased; I've always preferred
text to graphics for almost all reporting purposes.)
>> But, as I pointed out, you can't decline updates for one group and approve
>> them for another.
>
> True... but I'm not sure what that has to do with anything, or why it's an
> issue.
Only in that this would be another way to resolve the reporting issues.
... on the other hand I'm leaning towards the view that it would be better to
remove the ability to decline updates altogether, except for the special case
where an update has been expired. (Declining an expired update is essentially a
special kind of approval - you're approving the expiration of the update!)
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:uAjb4sRsHHA.1212[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > Lawrence Garvin (MVP) wrote:
>
>> In WSUS3 to find computers that haven't received patches that are
>> approved, you only need to create a custom update view for "Approved"
>> updates, and the pie chart for that update group will immediately display
>> pie slices according to whether the approved updates are installed, or
>> not.
>
> I'll reserve judgement until I'm able to try it out, but a pie chart
> doesn't sound all that useful. I need to know which computers, not just
> how many.
Fine, then look at the bloody detail report. :-)
> Also, I don't see how this would separate out the groups for which an
> update is wanted from those for which it isn't. (I may be biased; I've
> always preferred text to graphics for almost all reporting purposes.)
You keep changing the criteria in the middle of the discussion.
Are you interested in Needed updates that are "Not Approved", or Needed
updates that *are* approved?
Either way, the answer is basically the same. Customize a view; customize a
report, make it work however you want to get it to tell you what you want it
to tell you.
>>> But, as I pointed out, you can't decline updates for one group and
>>> approve them for another.
>>
>> True... but I'm not sure what that has to do with anything, or why it's
>> an issue.
>
> Only in that this would be another way to resolve the reporting issues.
But an *inappropriate* way to resolve it.
> ... on the other hand I'm leaning towards the view that it would be
> better to remove the ability to decline updates altogether, except for the
> special case where an update has been expired. (Declining an expired
> update is essentially a special kind of approval - you're approving the
> expiration of the update!)
Declining an update is a critical functionality of WSUS. For example, I
decline *every* update for 64-bit Windows Server 2003 systems. I have no
64-bit systems, and it's highly unlikely that I will during the product
lifecycle of WSUS 3.0 (and certainly during the lifecycle of my current
deployment of WSUS 3). Those updates get summarily declined. As do all
*superceded* updates, although the new Server Cleanup Wizard will
automatically decline superceded updates if you wish it to.
Declining an active update, however, is something I never do.
--
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
news:uOY$JaCsHHA.1296[ at ]TK2MSFTNGP06.phx.gbl:
[Quoted Text] > "Tila" <kilinattila[ at ]gmail.com> wrote in message
> news:1181998590.697267.152110[ at ]g4g2000hsf.googlegroups.com...
>
>
>>> > I like WSUS 3.0 - but this is a big error in it - uppon me.
>
>>> Actually, until about 24 hours ago, I was a staunch supporter of
>>> those who
>>> thought the WSUS 3 methodology was a critical flaw.
>>>
>>> But in the past 24 hours, having given thought to what happens if
>>> you're given exactly what you're asking for, I find myself asking
>>> this question:
>>>
>>> What happens if the WSUS Administrator has missed approving an
>>> update?
>
>> But we are also talking about updates DECLINED for some reason - and
>> not necessarily security updates, just "enhancements".
>
> Updates that are declined are a whole different animal. For starters,
> it takes a positive response to a warning dialog box to cause an
> update to be Declined, so the idea that somebody "accidental Declined"
> an update doesn't float with me.
>
> Update that are declined do not report as Needed, they report as "No
> Status" because the client can't even see the update to know what
> status to report, thus it has "No Status".
>
>
>>> In your desired scenario, the computer will show as 100%
>>> patched,
>>> because it's based on what is *approved*, and not on what is
>>> *needed*.
>>>
>>> The report, of which you ask for, will (erronously, I submit)
>>> mislead
>>> you into believing your systems are 100% patched, when, in fact,
>>> they're actually missing a critical update, or maybe even a security
>>> update! Because
>>> of *human* error!
>>
>> This is why somebody already suggested a new "type" - needed, but
>> declined by admin.
>
> There is *NO* way to determine if an update is Needed if it is
> Declined. You should not decline an update unless you have a very
> specific reason. Updates can easily be UNdeclined to determine if
> they're needed, but if they're never going to be installed (a decision
> made by a WSUS Administrator), then what difference does it make if
> anything needs them or not, the Admin already decided they are *not*
> going to be installed!
>
> Although I would suggest, for complaince reasons, if nothing else, a
> documentation log should be kept of every declined update and why it
> was declined. Most will be declined because of supercession or
> expiration. But some might be intentionally declined if the admin
> doesn't like the idea of yellow pie slices in their otherwise perfect
> world of green pies.
>
>
>> I agree, that all the updates should be either approved or declined
>
> I disagree. For exactly the reason you defend above. What if a
> "declined" update is *needed* to be installed? How will the admin
> trace the status of uninstalled/needed updates once they're declined.
> I'm much happer seeing that five updates have not been installed to my
> server, and knowing *exactly* which five those are, than seeing a
> misleading report that the machine is 100% patched, when I know for a
> fact it isn't. I never mark an active update as declined, I simply
> leave it as "Not Approved".. which is, IMHO, the *correct* approval
> status for such updates.
>
It does depend on the update. I'm not ready to deploy IE7 and WMP11. I
declined those 2. I agree with you on patches. They should stay 'not
approved'.
>
>> So, if we just separate the updates in this two category: approved or
>> declined, do you agree, that now this report doesn't helps us?
>
> Nope. Your argument is theoretical, and invalid, because there aren't
> just two categories -- there are three. (Not Approved, Install,
> Decline).
>
> The report helps perfectly, provided that you're willing to interpret
> it the way it was designed to be interpreted. If you try to make the
> report mean something it doesn't, you'll never get anything
> accomplished.
>
>
>>> Besides... if you truly want a Compliance Report. You shouldn't be
>>> getting
>>> it from the same source that's determining what you do or do not
>>> need to install. You should be getting it from an independent tool.
>
>
>> But if WSUS can do this, why another 3rd party?
>
> *THAT* is a question for your SOX auditor(s). :-)
>
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] >> I'll reserve judgement until I'm able to try it out, but a pie chart
>> doesn't sound all that useful. I need to know which computers, not just
>> how many.
>
> Fine, then look at the bloody detail report. :-)
Fine; just so long as there is one! :-)
>> Also, I don't see how this would separate out the groups for which an
>> update is wanted from those for which it isn't. (I may be biased; I've
>> always preferred text to graphics for almost all reporting purposes.)
>
> You keep changing the criteria in the middle of the discussion.
I don't think so, though perhaps I haven't stated it explicitly or clearly
enough. I want to be able to easily see which computers have not yet installed
updates they need - that's for *my* definition of "need", not Microsoft's, and
it may vary between computer groups. (For example, the desktop machines need
..NET, but the servers don't.)
Anyway, as I said, I'll reserve judgement until we've moved to WSUS 3 and I can
actually play with this wonderful new interface I keep hearing about.
>>>> But, as I pointed out, you can't decline updates for one group and
>>>> approve them for another.
>>> True... but I'm not sure what that has to do with anything, or why it's
>>> an issue.
>> Only in that this would be another way to resolve the reporting issues.
> But an *inappropriate* way to resolve it.
Ahem, perhaps, but one you suggested in an earlier post in this thread: "And, if
you don't want those "Not Approved" updates to cloud up the "Needed" counts
because they're *never* going to install, then you *should* Decline those updates."
Harry.
|
|
Harry Johnston wrote:
[Quoted Text] > [...] I want to be able to easily see which computers have
> not yet installed updates they need - that's for *my* definition of
> "need", not Microsoft's, and it may vary between computer groups. (For
> example, the desktop machines need .NET, but the servers don't.)
Of course, I also want to be able to easily see which computers have not
installed updates that Microsoft thinks they need. Didn't think to say so until
I'd already sent the previous message; perhaps I *do* keep changing the criteria
in the middle of the discussion! :-)
I hope you can at least see how my suggestion of distinguishing between "needed
and approved" and "needed and not approved" in the reports would make it easy to
see the answer to both questions at once. It may not be a necessary feature,
but I stand by my assertion that it would be nice to have.
(Actually I've thought up another way of showing this information using a table
with computers on one axis and updates on the other; perhaps I should see if I
can work something up using the WSUS API.)
Harry.
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] >> ... on the other hand I'm leaning towards the view that it would be
>> better to remove the ability to decline updates altogether, except for the
>> special case where an update has been expired. [...]
>
> Declining an update is a critical functionality of WSUS. For example, I
> decline *every* update for 64-bit Windows Server 2003 systems.
I'm curious about your reasons for doing this. Won't this cause a lot of work
if you do ever install a 64-bit system? What's the downside to leaving them
"Not Approved"?
(The answer may be blindingly obvious to anyone who has actually used WSUS 3; I
apologise if so.)
Other potential problems with this practice (I realise they don't apply to your
particular situation) are the risk that somebody else might install a 64-bit
system on the network and not tell you, or that you might leave and your
replacement might not realise that those updates have been declined.
> [...] Those updates get summarily declined. As do all
> *superceded* updates, although the new Server Cleanup Wizard will
> automatically decline superceded updates if you wish it to.
Ooh, very cool - that'll save a lot of hard work.
... however, what happens when it is discovered that an update marked by
Microsoft as superceded shouldn't have been? This happened not long ago.
Obviously all WSUS administrators should be on Microsoft's mailing list for
bulletin updates, but if (for example) my mail server had glitched and missed
that particular message I'd never have known that I needed to reapprove that update.
Another thing that scares me about declining superceded updates is this message
from the WSUS server:
"This update supersedes other updates. Before declining superseded updates, it
is recommended that you approve the superseding update first and verify that the
superseded updates are no longer needed by any computers. For more information
see Approving Updates"
and under the help topic referenced:
"WSUS does not automatically decline superseded updates, and it is recommended
that you do not assume that superseded updates should be declined in favor of
the new, superseding update. Before declining a superseded update, make sure
that it is no longer needed by any of your client computers. "
and even more frightening:
"If an update no longer supersedes a previously released update due to new
changes. It is possible that through changes at each release, an update no
longer supersedes an update it previously superseded in an earlier version. In
this scenario, you will still see a message on the Details tab for the
superseded update that it has been superseded, even though the update that
supersedes it has been replaced by an update that does not."
I don't even understand what that paragraph means!
The bottom line is that it isn't clear to me what I'm actually supposed to do to
confirm that a particular update is no longer necessary; nor am I sure, even if
I did know what to do, that I would actually have enough available time in which
to do it. :-)
The upshot is that I'd be much happier to leave superceded updates approved for
detection ("Not Approved" in WSUS 3 parlance) so that if it turns out they are
still needed, now or in the future, I'll find out. Unfortunately this has
undesirable side-effects, e.g., the update files remain present on the server.
Since this is somewhat related to the issue of WSUS installing updates that are
already superceded, and you previously expressed some interest in this, I'll
mention that the two IE7 cumulative updates exhibit this behaviour. That is, if
both 933566 and 928090 are approved, and the client has neither, both will be
downloaded and installed even though one supercedes the other. (Windows XP sp2,
Internet Explorer 7.)
> Declining an active update, however, is something I never do.
I agree that this would be a mistake, and I'd be happier if it was a mistake
that it wasn't possible to make.
I guess what I really want is a version of WSUS specially for Dummies. :-)
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23UvUxwhsHHA.4868[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > I want to be able to easily see which computers have not yet installed
> updates they need - that's for *my* definition of "need", not Microsoft's,
There's no customization of the definition of needed. I like that the new
version is a bit more objective by reporting updates as "Not Installed",
although they still are reported as "Needed" initially. The key is simply to
interpret the reported status accordingly. The only thing the WUA can do is
tell you (a) whether the update is installed or not, (b) whether the update
*would* install if you approved it for installation (what the WUA and WSUS
reports as "Needed").
> and it may vary between computer groups. (For example, the desktop
> machines need .NET, but the servers don't.)
That's not a question of *need*, that's a question of *approval*. When you
*approve* an update, you've granted permission for it to be installed, IF
it's installable.
As noted in a previous message, you can create a custom update view called
"Approved Updates" which scans only the updates that have been approved for
installation (you can also subgroup it by product and/or classification, if
you wish), which will then display status according to what you have
authorized for installation, not what is universally available.
>>> Only in that this would be another way to resolve the reporting issues.
>
>> But an *inappropriate* way to resolve it.
>
> Ahem, perhaps, but one you suggested in an earlier post in this thread:
Let's clarify what I suggested in an earlier post. The poster (actually
several over the past few months), was complaining that the *default* update
groups will not show 100% installed (all green), if any computer in the
organization has not installed an update, even if the admin has no desire or
intention of ever installing that update. My response, simply, was that the
*only* way to make the *default* update groups show 100% was to decline
those updates that were never going to be installed. I also stated that I
did not recommend that as a practice, however, but it was the only solution.
> "And, if you don't want those "Not Approved" updates to cloud up the
> "Needed" counts because they're *never* going to install, then you
> *should* Decline those updates."
Correct... note the very important conditional in that sentence. "...IF you
don't want those "Not Approved" updates... then you *should* decline the
updates.." because that's the only way the desired result is going to be
achieved. I then went on, a couple of messages later, describing what the
negative ramifications of such a decision might be.
Additionally, subsequent to that, Asher_N (I believe), pointed out that it
was trivial to create a custom update view based only on *APPROVED* updates,
which would easily show 100% (all green) if the products/classifications
configured in that view were installed on all systems that they should be
installed upon. (I've since done that, and I'm quite pleased with the
results.)
Ergo, it turns out, that rather than complaining about what the default
groups don't do, the correct solution, it appears, is simply to customize
the interface so that it does do what the admin wants it to do.
End result, no need to decline active updates anywhere, for any reason.
--
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
.....
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23cS1%239hsHHA.2144[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] >> [...] I want to be able to easily see which computers have not yet
>> installed updates they need - that's for *my* definition of "need", not
>> Microsoft's, and it may vary between computer groups. (For example, the
>> desktop machines need .NET, but the servers don't.)
> Of course, I also want to be able to easily see which computers have not
> installed updates that Microsoft thinks they need.
And *that* would be accomplished by observing the yellow pie slices in the
default update groups "Critical Updates" and "Security Updates".
....or, if you're not into colored pie slices, by generating a Status Report
on the group and reading the list of computers from the detail.
> Didn't think to say so until I'd already sent the previous message;
> perhaps I *do* keep changing the criteria in the middle of the discussion!
> :-)
No prob... I'm workin' on keepin' up. ;-)
> I hope you can at least see how my suggestion of distinguishing between
> "needed and approved" and "needed and not approved" in the reports would
> make it easy to see the answer to both questions at once. It may not be a
> necessary feature, but I stand by my assertion that it would be nice to
> have.
And I'm asserting that it already exists, albeit the "Needed and Approved"
requires creation; the "Needed and Not Approved" exists by default.
--
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
.....
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23HhABKisHHA.3428[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] >>> ... on the other hand I'm leaning towards the view that it would be
>>> better to remove the ability to decline updates altogether, except for
>>> the special case where an update has been expired. [...]
>> Declining an update is a critical functionality of WSUS. For example, I
>> decline *every* update for 64-bit Windows Server 2003 systems.
> I'm curious about your reasons for doing this.
Because I have no 64-bit Win2003 systems, and I'm not likely to in the near
future. And, should I happen to get one unexpectedly, it's baseline will be
Service Pack 2, so all of these pre-SP2 updates are irrelevant, anyway.
Should that happen, I'll simply undecline the post-SP2 updates, see what
shows up as "Needed/NotInstalled" and approve them. Then, re-decline what's
left.
> Won't this cause a lot of work if you do ever install a 64-bit system?
I don't believe so. In fact, with WSUS3 it's even easier than with WSUS2, as
all I would need to do is create an auto-approval rule based on the product
"
> What's the downside to leaving them "Not Approved"?
Since all of the x64 updates, plus all of the Itanium updates, constitue
about 50% of the list of Windows Server 2003 updates, the primary downside
is that it clutters the hell out of the list.
The second downside: On WSUS 2 I was experimenting with auto-approve for
install rules for my servers, combined with using Option #3 for interactive
installations. The net effect was that I didn't have to approve updates, the
content was already on the servers when I did my maintenance work. The
downside, however, was that all of the x64 and ia64 updates were also
automatically approved. Declining them allowed me to purge the unneeded
x64/ia64 content from my filesystem.
> Other potential problems with this practice (I realise they don't apply to
> your particular situation) are the risk that somebody else might install a
> 64-bit system on the network and not tell you, or that you might leave and
> your replacement might not realise that those updates have been declined.
Well, in the case of my SOHO network, that's not really a risk. :-)
However, applying your scenario to a client's network. Imagine this for a
moment: "..the risk that somebody else might install a 64-bit [Windows
Server 2003] system on the network and not tell [me]." Frankly, if that
happens, the organization has a lot *BIGGER* problems than the fact that the
updates are declined on the WSUS server.
And... as for my replacement... well.... hmm.... am I really concerned about
the stupidities of my replacement if they don't know how to operate a basic
WSUS server<???>
>> [...] Those updates get summarily declined. As do all *superceded*
>> updates, although the new Server Cleanup Wizard will automatically
>> decline superceded updates if you wish it to.
>
> Ooh, very cool - that'll save a lot of hard work.
Yeah... but I think I still prefer to eyeball them first. You can
selectively choose whether to use this feature or not in the cleanup wizard.
I've extended the remarks about the supercession issues into a separate
message.
--
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
.....
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23HhABKisHHA.3428[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > ... however, what happens when it is discovered that an update marked by
> Microsoft as superceded shouldn't have been? This happened not long ago.
It's still happening.
> Another thing that scares me about declining superceded updates is this
> message from the WSUS server:
>
> "This update supersedes other updates. Before declining superseded
> updates, it is recommended that you approve the superseding update first
> and verify that the superseded updates are no longer needed by any
> computers. For more information see Approving Updates"
This is really a disclaimer more than a warning. It's about due diligence.
The problem is that doing this very thing has gotten people in trouble, when
the detection logic of one or the other update was flawed.
The way the system is supposed to work is that the WUA sees the *latest*
available approved update, downloads it, ignores the superceded updates, and
once the latest updates is installed, the remainder of the superceded
updates will be reported as "Not Applicable".
There's really two scenarios that have relevance here:
In the first scenario, where the update has never been approved, since
there's no content downloaded, it really doesn't matter what you do with the
update, except that it's continued presence (and uselessness) will clutter
up your update listing.
In the second scenario, where the update was previously approved,
declining the update permits the removal of the no-longer-needed content
from the filesystem.
> and under the help topic referenced:
>
> "WSUS does not automatically decline superseded updates, and it is
> recommended that you do not assume that superseded updates should be
> declined in favor of the new, superseding update. Before declining a
> superseded update, make sure that it is no longer needed by any of your
> client computers. "
This goes to the theoretical possiblity that update 'b' would superced
update 'a', but update 'b' also had a prerequisite update 'c'. If Update 'a'
were declined (and not installed), and update 'c' were not installed (for
whatever reason), approving update 'b' wouldn't do any good and it would
leave the system vulnerable, because update 'a' was declined. Now, in
reality, I've never seen this happen.
Furthermore, the WUA has this annoying thing of reporting *all* superceded
updates in a chain of superceeded updates as "Needed" until one of them is
installed. This has confuzed dozens of WSUS admins to no end, and this
newsgroup is replete with posts over the past two years of admins trying to
figure out why a client won't install a Cumulative Security Update for IE
(that's been superceded a dozen times over).
> and even more frightening:
>
> "If an update no longer supersedes a previously released update due to new
> changes. It is possible that through changes at each release, an update no
> longer supersedes an update it previously superseded in an earlier
> version. In this scenario, you will still see a message on the Details tab
> for the superseded update that it has been superseded, even though the
> update that supersedes it has been replaced by an update that does not."
>
> I don't even understand what that paragraph means!
It's an extremely theoretical situation, and is intended to suggest that the
supercession chain is not a lifetime guaranteed, static condition.
> The bottom line is that it isn't clear to me what I'm actually supposed to
> do to confirm that a particular update is no longer necessary; nor am I
> sure, even if I did know what to do, that I would actually have enough
> available time in which to do it. :-)
Here's my take on the thorough methodology: The proper way to handle this
whole scenario is this:
[a] Don't trust just the banner message. Read the metadata also.
[b] Identify the specific update(s) that supercede the subject update.
[c] Double check the superceding update's metadata to verify that it
also agrees that it supercedes the subject update.
[d] If you're being really thorough, you'd read the KB articles and/or
MSRC articles for both updates, check the specific file(s) replaced,
including the version numbers, thus verifying that the superceding update
actually does supercede the subject update.
Now, as you note, it's highly unlikely that either of us has enough
available time in which to do all of that. Given that the incidents of
incorrect supercession data are measured in a ratio well under 0.1%, and
Microsoft (team work between the WSUS team and the SE teams) has been
extremely responsive in correcting metadata errors concerning supercession
data in WSUS, I'm fairly confident in taking my chances that I'll not need
an update that's legitimately marked as superceded.
> The upshot is that I'd be much happier to leave superceded updates
> approved for detection ("Not Approved" in WSUS 3 parlance) so that if it
> turns out they are still needed, now or in the future, I'll find out.
> Unfortunately this has undesirable side-effects, e.g., the update files
> remain present on the server.
Not so true. If the update has *never* been approved for installation, there
are no update files on the filesystem.
I suspect, though, eventually you'll find that sifting through the pages and
pages in the detail reports of all of those "Not Approved/Not Applicable"
updates will become quite frustrating, and you'll want to make them "just go
away".
> Since this is somewhat related to the issue of WSUS installing updates
> that are already superceded, and you previously expressed some interest in
> this, I'll mention that the two IE7 cumulative updates exhibit this
> behaviour. That is, if both 933566 and 928090 are approved, and the
> client has neither, both will be downloaded and installed even though one
> supercedes the other. (Windows XP sp2, Internet Explorer 7.)
KB928090 records that it is superceded by KB931768.
KB931768 records that it is superceded by KB933566.
KB933566 records that it supercedes KB931768.
While I've not tested, or tried to replicate this, what you describe is a
flaw in the WUA. Furthermore, it has happened previously, shortly after the
release of WSUS 2 in June, 2005, we observed some similar behaviors with IE
6 updates. Out of that grew the conventional wisdom to simply decline all
superceded Cumulative Updates.
While the WUA should report both as "Needed", if it's actually downloading
both, then that's an indication of a defect in the detection logic of
KB933566. I'll do some testing on those three updates and see what I get.
--
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
news:#m4L$cisHHA.2004[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > "Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
> news:%23UvUxwhsHHA.4868[ at ]TK2MSFTNGP02.phx.gbl...
>
>> I want to be able to easily see which computers have not yet
>> installed updates they need - that's for *my* definition of "need",
>> not Microsoft's,
>
> There's no customization of the definition of needed. I like that the
> new version is a bit more objective by reporting updates as "Not
> Installed", although they still are reported as "Needed" initially.
> The key is simply to interpret the reported status accordingly. The
> only thing the WUA can do is tell you (a) whether the update is
> installed or not, (b) whether the update *would* install if you
> approved it for installation (what the WUA and WSUS reports as
> "Needed").
>
>> and it may vary between computer groups. (For example, the desktop
>> machines need .NET, but the servers don't.)
>
> That's not a question of *need*, that's a question of *approval*. When
> you *approve* an update, you've granted permission for it to be
> installed, IF it's installable.
>
> As noted in a previous message, you can create a custom update view
> called "Approved Updates" which scans only the updates that have been
> approved for installation (you can also subgroup it by product and/or
> classification, if you wish), which will then display status according
> to what you have authorized for installation, not what is universally
> available.
>
>
>>>> Only in that this would be another way to resolve the reporting
>>>> issues.
>>
>>> But an *inappropriate* way to resolve it.
>>
>> Ahem, perhaps, but one you suggested in an earlier post in this
>> thread:
>
> Let's clarify what I suggested in an earlier post. The poster
> (actually several over the past few months), was complaining that the
> *default* update groups will not show 100% installed (all green), if
> any computer in the organization has not installed an update, even if
> the admin has no desire or intention of ever installing that update.
> My response, simply, was that the *only* way to make the *default*
> update groups show 100% was to decline those updates that were never
> going to be installed. I also stated that I did not recommend that as
> a practice, however, but it was the only solution.
>
>> "And, if you don't want those "Not Approved" updates to cloud up the
>> "Needed" counts because they're *never* going to install, then you
>> *should* Decline those updates."
>
> Correct... note the very important conditional in that sentence.
> "...IF you don't want those "Not Approved" updates... then you
> *should* decline the updates.." because that's the only way the
> desired result is going to be achieved. I then went on, a couple of
> messages later, describing what the negative ramifications of such a
> decision might be.
>
> Additionally, subsequent to that, Asher_N (I believe), pointed out
> that it was trivial to create a custom update view based only on
> *APPROVED* updates, which would easily show 100% (all green) if the
> products/classifications configured in that view were installed on all
> systems that they should be installed upon. (I've since done that, and
> I'm quite pleased with the results.)
>
And the added advantage is that because you can't do the same thing on
the computer views, you now can have a view on the status of needed
updates, whether approved or not, by computer group, and use the update
view to show the status of your approved updates. Any discrepencies are
needed but unapproved updates.
> Ergo, it turns out, that rather than complaining about what the
> default groups don't do, the correct solution, it appears, is simply
> to customize the interface so that it does do what the admin wants it
> to do.
>
> End result, no need to decline active updates anywhere, for any
> reason.
>
>
|
|
You both are enumerating the "wants" and "difficulties providing those
wants" pretty successfully - and providing some good extra perspectives. I
just wanted to poke my head in and let you know I am reading along, and
combining your feedback with others we've had on the problem.
Carry on...
--
Matthew Wetmore
Developer, WSUS (Windows Server Update Services)
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message
news:%2375iF0isHHA.3640[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > "Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message > news:%23HhABKisHHA.3428[ at ]TK2MSFTNGP03.phx.gbl... > >> ... however, what happens when it is discovered that an update marked by >> Microsoft as superceded shouldn't have been? This happened not long ago. > > It's still happening. > >> Another thing that scares me about declining superceded updates is this >> message from the WSUS server: >> >> "This update supersedes other updates. Before declining superseded >> updates, it is recommended that you approve the superseding update first >> and verify that the superseded updates are no longer needed by any >> computers. For more information see Approving Updates" > > This is really a disclaimer more than a warning. It's about due diligence. > The problem is that doing this very thing has gotten people in trouble, > when the detection logic of one or the other update was flawed. > > The way the system is supposed to work is that the WUA sees the *latest* > available approved update, downloads it, ignores the superceded updates, > and once the latest updates is installed, the remainder of the superceded > updates will be reported as "Not Applicable". > > There's really two scenarios that have relevance here: > In the first scenario, where the update has never been approved, since > there's no content downloaded, it really doesn't matter what you do with > the update, except that it's continued presence (and uselessness) will > clutter up your update listing. > > In the second scenario, where the update was previously approved, > declining the update permits the removal of the no-longer-needed content > from the filesystem. > >> and under the help topic referenced: >> >> "WSUS does not automatically decline superseded updates, and it is >> recommended that you do not assume that superseded updates should be >> declined in favor of the new, superseding update. Before declining a >> superseded update, make sure that it is no longer needed by any of your >> client computers. " > > This goes to the theoretical possiblity that update 'b' would superced > update 'a', but update 'b' also had a prerequisite update 'c'. If Update > 'a' were declined (and not installed), and update 'c' were not installed > (for whatever reason), approving update 'b' wouldn't do any good and it > would leave the system vulnerable, because update 'a' was declined. Now, > in reality, I've never seen this happen. > > Furthermore, the WUA has this annoying thing of reporting *all* superceded > updates in a chain of superceeded updates as "Needed" until one of them is > installed. This has confuzed dozens of WSUS admins to no end, and this > newsgroup is replete with posts over the past two years of admins trying > to figure out why a client won't install a Cumulative Security Update for > IE (that's been superceded a dozen times over). > >> and even more frightening: >> >> "If an update no longer supersedes a previously released update due to >> new changes. It is possible that through changes at each release, an >> update no longer supersedes an update it previously superseded in an >> earlier version. In this scenario, you will still see a message on the >> Details tab for the superseded update that it has been superseded, even >> though the update that supersedes it has been replaced by an update that >> does not." >> >> I don't even understand what that paragraph means! > > It's an extremely theoretical situation, and is intended to suggest that > the supercession chain is not a lifetime guaranteed, static condition. > > >> The bottom line is that it isn't clear to me what I'm actually supposed >> to do to confirm that a particular update is no longer necessary; nor am >> I sure, even if I did know what to do, that I would actually have enough >> available time in which to do it. :-) > > Here's my take on the thorough methodology: The proper way to handle this > whole scenario is this: > [a] Don't trust just the banner message. Read the metadata also. > [b] Identify the specific update(s) that supercede the subject update. > [c] Double check the superceding update's metadata to verify that it > also agrees that it supercedes the subject update. > [d] If you're being really thorough, you'd read the KB articles and/or > MSRC articles for both updates, check the specific file(s) replaced, > including the version numbers, thus verifying that the superceding update > actually does supercede the subject update. > > Now, as you note, it's highly unlikely that either of us has enough > available time in which to do all of that. Given that the incidents of > incorrect supercession data are measured in a ratio well under 0.1%, and > Microsoft (team work between the WSUS team and the SE teams) has been > extremely responsive in correcting metadata errors concerning supercession > data in WSUS, I'm fairly confident in taking my chances that I'll not need > an update that's legitimately marked as superceded. > > >> The upshot is that I'd be much happier to leave superceded updates >> approved for detection ("Not Approved" in WSUS 3 parlance) so that if it >> turns out they are still needed, now or in the future, I'll find out. >> Unfortunately this has undesirable side-effects, e.g., the update files >> remain present on the server. > > Not so true. If the update has *never* been approved for installation, > there are no update files on the filesystem. > > I suspect, though, eventually you'll find that sifting through the pages > and pages in the detail reports of all of those "Not Approved/Not > Applicable" updates will become quite frustrating, and you'll want to make > them "just go away". > > >> Since this is somewhat related to the issue of WSUS installing updates >> that are already superceded, and you previously expressed some interest >> in this, I'll mention that the two IE7 cumulative updates exhibit this >> behaviour. That is, if both 933566 and 928090 are approved, and the >> client has neither, both will be downloaded and installed even though one >> supercedes the other. (Windows XP sp2, Internet Explorer 7.) > > KB928090 records that it is superceded by KB931768. > KB931768 records that it is superceded by KB933566. > KB933566 records that it supercedes KB931768. > > While I've not tested, or tried to replicate this, what you describe is a > flaw in the WUA. Furthermore, it has happened previously, shortly after > the release of WSUS 2 in June, 2005, we observed some similar behaviors > with IE 6 updates. Out of that grew the conventional wisdom to simply > decline all superceded Cumulative Updates. > > While the WUA should report both as "Needed", if it's actually downloading > both, then that's an indication of a defect in the detection logic of > KB933566. I'll do some testing on those three updates and see what I get. > > > -- > 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) wrote:
[Quoted Text] > Not so true. If the update has *never* been approved for installation, there
> are no update files on the filesystem.
Granted. Typically, though, when declining a superceded update, the update was
previously approved (and indeed installed).
> I suspect, though, eventually you'll find that sifting through the pages and
> pages in the detail reports of all of those "Not Approved/Not Applicable"
> updates will become quite frustrating, and you'll want to make them "just go
> away".
I think I see the other difference between our scenarios. I don't have time to
look at the detail reports at all, just the summaries ("show me needed, failed,
and unknown") so this issue doesn't trouble me in the slightest. :-)
> KB928090 records that it is superceded by KB931768.
> KB931768 records that it is superceded by KB933566.
> KB933566 records that it supercedes KB931768.
Ah. I hadn't noticed there was an update in the middle. So the situation was
928090 and 933566 were approved but 931768 was declined. That's an oddball
situation; I'll check what happens if all three are approved and get back to you.
Harry.
|
|
Harry Johnston wrote:
[Quoted Text] >> KB928090 records that it is superceded by KB931768.
>> KB931768 records that it is superceded by KB933566.
>> KB933566 records that it supercedes KB931768.
>
> Ah. I hadn't noticed there was an update in the middle. So the
> situation was 928090 and 933566 were approved but 931768 was declined.
> That's an oddball situation; I'll check what happens if all three are
> approved and get back to you.
I can confirm that if all three updates are approved, only the most recent is
downloaded and installed. So it is working as expected, except when the
administrator has done something dopey ... I wouldn't consider this to be a
WSUS/WUA fault.
My mistake; sorry.
Harry.
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] >> Other potential problems with this practice (I realise they don't apply to
>> your particular situation) are the risk that somebody else might install a
>> 64-bit system on the network and not tell you, or that you might leave and
>> your replacement might not realise that those updates have been declined.
> [...] However, applying your scenario to a client's network. Imagine this for a
> moment: "..the risk that somebody else might install a 64-bit [Windows
> Server 2003] system on the network and not tell [me]." Frankly, if that
> happens, the organization has a lot *BIGGER* problems than the fact that the
> updates are declined on the WSUS server.
I don't think this scenario is all that unlikely in an organisation with a
devolved IT structure, i.e., if the person running the WSUS server is in a
different division to the people installing other servers. I could even see it
happening within a smaller organisation or division where there are a several IT
folk; the person operating the WSUS server isn't necessarily going to be able to
keep track of everything the other IT people are doing.
Granted it could be argued that these are big problems, but sometimes they are
problems we have to cope with. :-)
> And... as for my replacement... well.... hmm.... am I really concerned about
> the stupidities of my replacement if they don't know how to operate a basic
> WSUS server<???>
If everything is properly documented, there wouldn't be a problem ... we don't
always have time to properly document nowadays, nor would a replacement
necessarily have time to look back through the old updates to see what has or
hasn't been approved (though admittedly a sensible admin would do so as a
priority). Granted this *is* definitely a big problem, it's *certainly* one
some of us have to cope with!
This all boils down once again to my desire for a WSUS for ... well, maybe not
dummies exactly, but people with far too much already on their plate. I want
Microsoft to do my work for me, dammit! :-)
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:eFCIGpssHHA.3364[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >>> KB928090 records that it is superceded by KB931768.
>>> KB931768 records that it is superceded by KB933566.
>>> KB933566 records that it supercedes KB931768.
>> Ah. I hadn't noticed there was an update in the middle. So the
>> situation was 928090 and 933566 were approved but 931768 was declined.
>> That's an oddball situation; I'll check what happens if all three are
>> approved and get back to you.
> I can confirm that if all three updates are approved, only the most recent
> is downloaded and installed. So it is working as expected, except when
> the administrator has done something dopey ... I wouldn't consider this to
> be a WSUS/WUA fault.
Thank you for the update.
--
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) wrote:
[Quoted Text] >> This all boils down once again to my desire for a WSUS for ... well, maybe
>> not dummies exactly, but people with far too much already on their plate.
>> I want Microsoft to do my work for me, dammit! :-)
>
> Actually.. I have been seriously considering authoring such a tome.
I'm sure it would be useful, but for the record what I'm expressing a desire for
isn't instruction on using the existing WSUS, but a new WSUS that is easier to
use. (Not that WSUS isn't incredibly valuable, and a huge improvement on the
way things used to be!)
Harry.
|
|
|