• subscribe
January 30, 2006 12:00 AM

Designing an Enterprise WSUS Deployment

Invest time in WSUS design and reap the reward of a robust, reliable patch management solution
Windows IT Pro
InstantDoc ID #48889

Ready, Set...
Before you implement WSUS, you need to evaluate your update strategy, objectives, resources, and procedures; select servers and database engines; and determine which updates you want to download, where to store them, and to which computers you'll deploy them. Only then can you select the best update topology for your organization.

Go!
Implementing WSUS in an enterprise is challenging. In a later article, I'll explain how to install and configure WSUS and the Automatic Updates client in an enterprise setting.

Project Snapshot

PROBLEM: Plan an enterprise deployment of WSUS.
WHAT YOU NEED: A network topology diagram; an inventory of Microsoft OSs and applications in each site; an inventory of servers and workstations in each site
DIFFICULTY: 2 out of 5
PROJECT STEPS:

  1. Formulate your update plan.
  2. Select a database engine.
  3. Determine the locations for your WSUS servers.
  4. Determine which update files you'll need and where to store them.
  5. Develop a group-targeting strategy.
  6. Design a topology.

Dan Holme (danh@intelliem.com) is the director of training at Intelliem, which delivers solutions-focused training and consulting services that support Windows and Active Directory implementations at enterprises.



ARTICLE TOOLS

Comments
  • Jan
    6 years ago
    May 15, 2006

    Some items and behaviours of WSUS described
    under the hierarchical topology are inaccurate.

    Article quote: "Downstream servers don't know
    about updates that the upstream server
    doesn't approve"
    That's not correct!
    When you link a downstream server to an upstream
    server and approve updates on the
    downstream server, these updates will automatically be downloaded through the
    upstream server even when the update has not
    been approved on the upstream server.

    I thought of a workaround for this behaviour:
    Take an upstream server that synchronises updates with Microsoft servers on
    the Internet.
    Take a second upstream server that's setup
    as a disconnected server.
    Export (by using some sort of script
    language or batch file) the update
    approvals and update files from the
    upstream server linked to the internet
    and import them on the disconnected
    upstream server.
    Point all your downstream servers
    (NOT replica servers) to the disconnected
    upstream server. When you now approve a
    patch on one of the downstream servers
    that's not yet been approved on the upstream server, the patch will not be
    downloaded because the upstream server is
    disconnected.

    If you need more info, you can check out this
    Technet post:
    http://www.microsoft.com/technet/community/
    newsgroups/dgbrowser/en-us/default.mspx?dg
    =microsoft.public.windows.server.update_services

    (post from 4/7/2006 called Hierarchical topology - from upstream to downstream=

  • Jan
    6 years ago
    Apr 07, 2006

    Exactly what you need to start deploying WSUS in the enterprise!

You must log on before posting a comment.

Are you a new visitor? Register Here