The deceptively simple SUS concept will probably be popular in the intended market of small to midsized organizations that don't have sophisticated reporting or client-targeting needs. (Larger organizations that require more comprehensive update management should consider Microsoft's newly released SMS 2.0 Software Update Services Feature Pack.) The SUS server maintains a synchronized catalog of Microsoft-obtained updates and pushes these updates to subscribing clients in your organization. The first synchronization takes a while because the SUS server must download all critical updates from the Microsoft Windows Update server, as Figure 1 shows. Subsequent scheduled synchronizations complete much faster because the software downloads only updates that are new since the previous synchronization. You manage the SUS update server through an IIS Web-based interface (by default, http://susserver/susadmin). From this interface, you can review and approve each update intended for the SUS client base.
Configure SUS Clients with Group Policy
The Automatic Updates client on each computer checks regularly with the SUS server for approved and applicable updates, then obtains the updates and installs them according to that client's settings. You can configure client settings such as whether to automatically download and install updates or prompt the end user to approve each update in each client computer's registry; however, most organizations will appreciate the capability to use AD's Group Policy to centrally configure the Automatic Updates client.
On a computer that has SUS-enhanced Automatic Updates installed, go to the Microsoft Management Console (MMC) Group Policy snap-in and expand the Computer Configuration node. Right-click Administrative Templates and click Add/Remove Templates to load the new Windows Update administrative template (%windir%\inf\wuau.adm). Next, expand the Computer Configuration Windows Components node and select Windows Update to display the two new SUS configuration items. Edit the properties of the first item, Configure Automatic Updates, to specify the folder location, notification parameters, and schedules of automatic updates. For example, you can notify your users when updates are ready for installation or you can schedule automatic installations. In the second item, Specify the Intranet Microsoft Update Service Location, define the location of the SUS update server (e.g., http://susserver) and statistics server that you want clients to use. The statistics server collects SUS update report data. You can set both to the same server; however, you might want to configure a separate statistics server to handle reporting from multiple SUS update servers (e.g., for different geographic offices).
SUS Reporting
SUS reporting consists of recording client-update downloads to a standard IIS Web log on your specified SUS servers (by default, these files reside in \%systemroot%\logfiles\w3svcx). Unfortunately, SUS offers no predefined reports or any type of data aggregation or other summary-level reporting to convey your organization's patch compliance. You can, however, troll the logs to determine whether a specific machine has requested a specific patch.
After you configure Group Policy, refresh the policy on a client and verify the SUS settings. Open the Control Panel System applet and select the Automatic Updates tab to review a client's settings. Figure 2 shows a client configuration in which SUS automatically downloads and installs approved patches every Saturday at 4:00 a.m.
To begin deploying updates, you don't need to perform much additional SUS configuration. This simple approach to patch deployment will be welcome news if you've ever manually installed multiple patches. (New Microsoft Internet Explorer—IE—updates typically include three separate patches for IE 6.0, IE 5.5, and IE 5.0, and your installation logic must check the version and push the appropriate update.) SUS transparently handles patch management for you, ensuring that the appropriate clients get the correct version of an approved patch.
Configuring SUS Server Options
You can configure your SUS clients to synchronize their updates (and, optionally, approved items) from another local SUS server or directly from Windows Update servers. Doing so helps you scale SUS and offers a good solution for placing SUS servers in multiple offices. For example, you can configure a master SUS server at corporate headquarters to pull its catalog from Microsoft, then configure child SUS servers at satellite offices that pull their catalogs from the corporate SUS parent. Such a configuration eliminates the need for each SUS server to be connected to the Internet. However, at least one SUS server must have Internet access to communicate with the Windows Update server.
Update Testing and Targeted Distribution
If you want to use SUS to roll updates to a set of test servers before rolling out to a wider production set, you must install multiple SUS update servers. (Alternatively, you can save updates to a local machine and manually install them for testing; however, this solution doesn't use the SUS deployment mechanism.) If you use multiple servers, be cautious when sharing existing IIS servers with SUS because SUS runs IIS Lockdown on installation, which might cause the failure of other Web applications on a shared server.
After you finish configuring your SUS servers, separate your test computers from your production computers by placing them in different AD organizational units (OUs). Configure an OU Group Policy to point the test OU computers to the staging SUS update server and the production OU computers to the production SUS update server.
Service Packs
The current version of SUS doesn't support the deployment of service packs. However, you can use AD's Group Policy and IntelliMirror software-distribution features to install XP or Win2K service packs. You can define Group Policy software installation for computers or users, commonly at an OU level. To deploy a mandatory software update such as a service pack to every machine regardless of who's logged on, you assign the software to the computer, as Figure 3 shows. Group Policy software installation supports Windows Installer (.msi) files, which come with most current service packs and other Microsoft corporate products. To verify or troubleshoot installation at the client, you can review the Application event log for a failed or successful Application Installation message.
Security Cornerstone
Patches and patch-assessment tools aren't designed to provide full protection from viruses, intrusions, and all malicious activity. For the best protection, you should consider deploying a multilayered defense that incorporates competent niche products that address specific threat vectors—for example, antivirus software on every desktop and mail or Internet gateway, an intrusion-detection system, and vulnerability scanners. Without a doubt, you should consider the elimination of known vulnerabilities from your OS and applications a cornerstone of your security foundation.
Keeping your software up-to-date is more important than ever. After you get SUS running, you'll be able to maintain a current and applicable set of patches for all new production machines. Update scanning will occur regularly, and approved patches will automatically flow to machines. This consistent and methodical approach will help ensure that new systems introduced into your production environment months after a flurry of patching will instantly be at the same patch level as their peers.
End of Article
Prev. page
1
[2]
next page -->
