Approval/Non-Approval best practices

I just installed WSUS for my home network consisting of about half a dozen
servers and half a dozen PCs. I'm a web and database developer - that's why
so many. And this is my first experience with WSUS.

My question is, what do I approve, what do I not approve, and what do I
decline?

I have found that if I don't approve or decline, the reports will show me
the updates that are required and I can choose to approve or not. If I have
declined an update, I don't get any indication if that update might be
required in the future.

So it seems to me that the best practice is to leave updates not approved
and only approve those that show up as needed later and only decline those
that I know I will never want to install on anything (such as WMP 11). But
the problem with this scenario is that I have to manually go through about
3000 updates if I want to pre-load updates that might be required or I have
to be very hands on with approvals. Or I could do a blanket pre-load of
hundreds of updates I may never need.

I'd be very interested in hearing suggestions and feedback on how to best
implement this solution.

Thanks,


Dale Preston

 

For a small SOHO network, I would recommend the following:

1. Establish your baseline OS/SP installation for desktops and servers. For
me it's Windows XP SP2 and Windows Server 2003 SP1 (soon to be SP2, but not
yet this week).

2. Decline all superceded updates. You're not going to install them on your
dozen systems. But, if for some reason you identify a need to, they are
easily undeclined. In the meantime, getting them out of the way will help
tremendously. Be careful not to decline those updates that were superceded
by Win2003SP2, unless you've already installed SP2 everywhere.

3. Make sure all of your systems are at your baseline OS/SP.

4. Ensure that every system has properly registered with the WSUS server,
and is thus properly reporting "Needed/Not Installed" updates.

5. Approve for installation all of the updates that are Needed/Not
Installed -- except those you choose not to install. For example, I'm not
distributing Win2003SP2 to my production servers, so it says "Not Approved"
for those groups. I'm not distributing .NET Framework v2.0/v3.0 to my
desktops until its needed -- that'll probably be some time. I'm not
installing the XP Network Diagnostic Tool, and I'm not installing IE7 on
Win2003SP1. All of those stay "Not Approved".

This is correct, which is why it's important to only decline those updates
that you will *never* need for any system in the network.

Exactly -- except the WMP11. Anything that is *current*, I suggest leaving
unDeclined. But it's really a matter of personal preference. As noted above,
you can always UNdecline WMP11 when the day comes that you have to install
it.

Not really... learn how to use the interface effectively. For example, I
created an Update View for Windows XP. Then I filter that view on Needed/Not
Approved. Now -- small caveat -- some of the updates might show in this
list, not because an XP system needs them, but because a server system needs
them. Unfortunately, because some updates are coded for both desktop and
server platforms, the update will be caught in both types of views (desktop,
server). It's not a big deal, though, because if the update is *needed*
you're going to approve it for installation anyway.

So, having this list, now, of updates needed by WinXP systems and not yet
installed, select all of them. Right click, select Approval, and Approve
them for your Windows XP group(s). Done.

Make a similar group for Windows Server 2003. Filter, Select All. Approve.
Done.

You can continue to use these views to keep track of what OS platforms need
updates now, or in the future, simply by refreshing the report for
Needed/Not Approved 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://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

 

I'd like to add another cautionary note here. We discovered recently that we
had inadvertently declined a needed update, resulting in some of our systems
being exposed to a known vulnerability. The update was declined because it was
marked as superceded by Windows 2003 service pack 2; however, the update applied
to all operating systems, and was only superceded on Windows 2003, so declining
it left our Windows XP boxes (those installed since the update was declined)
exposed.

So the lesson is to look carefully at updates before declining them.

Harry.

 

Lawrence,

Thanks again for all your help. I am pretty much following your suggestions
right down the list.

I just have one question. Because I may have to target a development effort
against an unpatched OS, for instance XP SP1 and not SP2, I may end up with
XP SP1 and SP2 both downloaded. Is it known what will happen in that event?
Will a new XP installation, pointed at my WSUS server for updates, install
SP1 and then SP2 or will it skip SP1 and go straight to the latest
superseding installation?

Dale

:

 

Thus the warning to make sure that all PCs have the new update before
declining a superseded update, huh? You make a good piont.

What I have decided is that I won't let the word "Unapproved" make me feel
like I have something undone. I am going to think of "Unapproved" more like
"Master update list".

I am thankful for the great reporting features - even if it is a little
bloated - because I can, with relative ease, find what updates need to be
approved out of that long list.

Dale

 

Ahh yes.. very good point, Harry! There are also a couple of updates that
are superceded by an "x64" update or service pack, but the update still
applies to the 32-bit systems it was originally distributed to.

I'll modify my suggestions -- which would be more in line with the official
documentation -- that those Win2003SP2 updates should only be declined
*after* all other updates are installed and are not reported as *Needed*. (I
wish they wouldn't mix platforms in the metadata like they're doing -- it
confuses a lot of things!)


--
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://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

 

In any case where a superceded update is approved along with the update that
superceded it, the WUA will skip over the superceded update and install the
latest update. So, in this scenario, it will skip over SP1 every time.

My suggestion would be to create a special target group for applying SP1
only, do not approve SP2 in that group, and then place your machine(s) in
that group.

However, another consideration == Concerning targeting development efforts
to XP SP1 systems -- XP SP1 systems have reached EoL and are no longer
supported by Microsoft. They are, by definition, inherently insecure,
because all security updates are released for XP SP2 only.

Unlike operating systems, which receive security updates for five years in
the "Extended" lifecycle, superceded service packs do not receive security
updates. You can do some testing to prove this on your own. Place an XP SP1
system under WSUS with SP2 not approved, and approve all Security Updates
for installation. Take note of the point at which those Security Updates are
no longer detected as needed.

From this page:
http://support.microsoft.com/default.aspx?scid=fh;[ln];lifecycle#Service Pack Support

Under Security Updates | Security Update Policy

Both the Mainstream Support and the Extended Support phases require that the
product's supported service pack level be installed to continue to receive
and install security updates.

And from this page: http://support.microsoft.com/gp/lifesupsps -- service
pack support for XP SP1 was retired in September, 2004.


As such, I would argue that continuing to support a development project on
an inherently (and known) insecure platform is not a good thing.


--
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://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

 

I understand but, unfortunately, I don't always control the environment.
For some systems I build, the environment is what it is and can't be changed.
Luckily, for most of these exceptions, they are off of the Internet but even
for those that are not, there is still some development and support
requirements for such legacy systems.

When I develop to those environments, I do it in virtual machines running on
virtual networks.

 

It *can* if you produce a version of the product designed for a later
(supported/secure) service pack build, and refuse to produce updates for the
(unsupported/insecure) service pack build(s).

There's a great dichotomy between developers and users.

One one hand I see users "stuck" in older versions of operating systems and
service packs who desperately want to upgrade, but cannot because they're
committed to a Line Of Business application that the vendor simply will not
update to support the latest platforms. I wish those developers would simply
roll up the carpet and move to some deserted island somewhere. I have zero
respect for a developer who won't maintain their *active* product to the
latest security standards.

But here, I see a developer who is perpetuating that improper maintenance of
unsupported/insecure platforms by continuing to release updates -- and thus
encouraging a very bad practice on the part of the customer? This I don't
understand. It's very confusing to me.

I wasn't referrering to *your* development environment. I automatically
assumed that your development/testing environment exists in an isolated
network.

I was refering to the potential liability risks of continuing to develop and
deploy updates for an application targeted to a *known* insecure operating
system platform -- Internet connected or not! (It doesn't take an Internet
connection for a subversive user on the LAN to take advantage of one of
those unpatched security vulnerabilities!)

Not to mention the extra cost involved in maintaining multiple platform
versions -- which I'm sure you pass along to the customer.. ;-)

--
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://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

 

You forgot one piece of the equation in software development - a piece even
bigger than the developer: The accountant. That is who almost always makes
the decisions you're putting on the shoulders of the poor developer.

dale

 

I guess the question goes to whether you are an *employee* of the company
with the accountant...

Or a contractor/vendor of the company with the accountant.


In the former, I can sympathize with your situation --

<soapbox mode = on>
stupid bean counters don't know a technical faux paus if it bit them in the
backside -- but more significantly is the business executive who lets the
bean counters lead him/her down the road of bad business decisions...
</soapbox>

-- On the other hand, I'll also argue that there's a moral and ethical
responsibility on the part of developers and IT professionals everywhere to
present those business executives with a *balanced* viewpoint, and when the
bean counters are making stupid recommendations == like upgrading software
to run on an unsupported/insecure platform == somebody needs to stand up and
point out that the emperor is naked.

However, if you're a contractor/vendor of that company .... and you're
coddling to their decision not to upgrade their systems in the interest of
retaining the customer and/or the revenue ... then at some point that
contractor/vendor has to let personal ethics outweigh the desire for easy
revenue or a "happy" (but doomed) customer, and stand up and say "I'm sorry,
that version is no longer being supported. This version requires *<fill in
the blank>*, and my company is no longer willing to be involved in working
with the older version because it is unsafe and insecure."

I've also found that if you make doing the wrong thing less economically
pleasant than doing the right thing -- everything comes around. For example,
I've had clients, from time to time, who seem to want to hang onto these
Windows 98 systems because the person using the computer only checks email
with Outlook Express three times a week, or only reviews a simple Excel
spreadsheet every Friday. They don't want to invest the money in a new PC
for that user. I politely point out that maintaining my services to support
that Windows 98 system over the next year will be *twice* the cost of a new
system plus my services, that it usually becomes a no-brainer -- and I don't
have to worry about what happens when their Windows 98 system becomes the
gateway to a network crisis.




--
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://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

 

You may want to make the accountants understand liability. If I was
forced by a software vendor to maintain my systems at unsuported/unsecure
OS levels, and my company was penetrated using a known flaw, I'd sue the
snot out of the software developper.