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.

End of Article

Prev. page     1 2 3 [4]     next page -->



You must log on before posting a comment.

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

Reader Comments

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

jvdbulck- April 07, 2006

Article Rating 5 out of 5

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 3 out of 5

 
 

ADS BY GOOGLE