Approval/Non-Approval best practices

Discussion in 'Update Services' started by Dale, Jul 14, 2007.

  1. Dale

    Dale Guest

    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

    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.


    Dale Preston
    Dale, Jul 14, 2007
    1. Advertisements

  2. 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

    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.

    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)

    Everything you need for WSUS is at

    And, almost everything else is at
    Lawrence Garvin \(MVP\), Jul 15, 2007
    1. Advertisements

  3. 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)

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

    Harry Johnston, Jul 15, 2007
  4. Dale

    Dale Guest


    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, Jul 15, 2007
  5. Dale

    Dale Guest

    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, Jul 15, 2007
  6. 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)

    Everything you need for WSUS is at

    And, almost everything else is at
    Lawrence Garvin \(MVP\), Jul 15, 2007
  7. 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:;[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: -- 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)

    Everything you need for WSUS is at

    And, almost everything else is at
    Lawrence Garvin \(MVP\), Jul 15, 2007
  8. Dale

    Dale Guest

    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.
    Dale, Jul 15, 2007
  9. 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)

    Everything you need for WSUS is at

    And, almost everything else is at
    Lawrence Garvin \(MVP\), Jul 15, 2007
  10. Dale

    Dale Guest

    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, Jul 15, 2007
  11. 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...

    -- 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)

    Everything you need for WSUS is at

    And, almost everything else is at
    Lawrence Garvin \(MVP\), Jul 16, 2007
  12. Dale

    Asher_N Guest

    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.
    Asher_N, Jul 16, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.