Designing an Enterprise WSUS Deployment

Invest time in WSUS design and reap the reward of a robust, reliable patch management solution

From the February 2006 Edition
of Windows IT Pro
Dan Holme
Solutions +
InstantDoc #48889
Windows IT Pro

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:

Formulate your update plan.
Select a database engine.
Determine the locations for your WSUS servers.
Determine which update files you'll need and where to store them.
Develop a group-targeting strategy.
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.

End of Article

Previous 1 2 3 [4] Next

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

jvdbulck April 07, 2006 (Article Rating:

)

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=

jvdbulck May 15, 2006 (Article Rating:

)

You must log on before posting a comment.

If you don't have a username & password, please register now.