This week, I present an overview of how a Software Update Services (SUS) server operates. To avoid introducing problems into existing Web content, I built a new Windows 2000 Service Pack 3 (SP3) system running Microsoft IIS, ran the IIS Lockdown utility, and installed the SUS server software using all the default settings. The installation took only a few minutes, created no problems, and didn't require a restart. The installer placed lots of Active Server Pages (ASP) files and several folders below the Inetpub\wwwroot directory, including autoupdate, dictionaries, and SUSAdmin folders.
Once installed, SUS opens the SUS administrator page ( http://
- the name of the proxy server, if any, SUS needs to use when accessing the Internet
- the SUS server’s name (the name users enter when requesting updates or the name you enter when you configure automatic updates with Group Policy)
- whether the SUS server should synchronize available updates with WindowsUpdate or another inhouse system
- the action to take when a newly published update replaces an earlier update (automatic or manual approval)
- where the SUS server will store updates it downloads from WindowsUpdate or another update server
- the languages for which SUS should download updates (e.g., English only, English, French, Arabic)
If you want to change any of these operational parameters after the initial installation, pull up the SUS admin page at http://
Synchronizing Updates
You can synchronize the new server’s content with WindowsUpdate (or an alternate SUS machine) by clicking the "Synchronize server" button in the left pane. When you click this button, the right pane displays two options: Synchronize Now and Synchronization Schedule. Synchronize Now initiates a manual download of new content. You can also define a schedule for SUS to automatically update its content from daily to once a week at a specific time. I configured the test system to support updates in English and French, and during the first synchronization, SUS indicated it needed to download 111 individual patches. My slow DSL line took more than an hour to download all 111 updates.
This synchronization step is inefficient because you have no control over the content that it downloads. In the initial SUS implementation, you can't approve or disapprove updates that are downloaded; you must accept every entry in the WindowsUpdate catalog, meaning you wait while the server downloads Windows .Net Server (Win.NET Server) 2003 updates in the languages you requested, plus another 10 or so languages, including Simplified and Traditional Chinese, Italian, Japanese, and Korean (I didn’t take the time to count them all), updates for all versions of Windows Media Player (WMP), Microsoft Internet Explorer (IE), Windows Messenger, and other products that you might not support. One of the first improvements Microsoft should make to this product is to add a feature that lets you screen and approve the updates to download and install.
You examine the download history by clicking the "View synchronization log" in the left pane. The log, which appears in the right pane, contains an entry for every update SUS downloaded, plus the status of each download. After the synchronization step, SUS organizes documentation forpatches available for Windows XP, Win2K, and IE in folders below \dictionaries\autoupdate. Click "Monitor server" in the left pane to display a summary of available updates by these product categories. To expedite client performance, SUS caches these entries in memory so they're available instantly when an automatic update client polls for updates. I noticed one other disparity: Although my test system downloaded .Net service packs in multiple languages and WMP updates, these fixes didn't appear in the Monitor server list. One possible explanation is that SUS only caches updates it expects to be in high demand.
Approving Updates
To view and approve updates for distribution, click the "Approve updates" button in the left pane, which displays a list of updates in the right pane. To approve an individual item, simply check the box that precedes the title. When more than just a few updates are on the list, the approval process is cumbersome, at best.
First, approving items would be much more efficient if you could sort downloaded updates by platform or product and release date, at a minimum, and also by Microsoft Knowledge Base number. Second, it’s difficult to scroll through 111 updates in the tiny window provided. Third, I didn’t find a way to remove updates I didn’t need, for instance updates that have been superceded by later releases and updates for products that you don't support. Specifically, I see no need to publish and host earlier IE updates when the August cumulative version supercedes all earlier releases. Likewise, a method should be available for removing the 10+ language versions of Win.NET Server or any other category of patch that doesn't apply to your network environment. Microsoft needs to clean up the download catalog to eliminate these unnecessary items. Fourth, before you can approve an individual fix, you'll likely want to read the Knowledge Base information. To do so, in the tiny Approval window, click the Details link for an individual update, then click the Info button on the list that appears. After reading the article, you'll want to return to the individual update so you can approve it. However, clicking the Back button in the browser returns you to the SUS Admin page, not to the approval list. At this point, you’ve lost your place and must relocate the update on the list of 111 items. This is pretty frustrating when it happens five or six times.
Although SUS fills a much-needed niche, the first implementation has some glaring flaws. I believe that most administrators will find download and approval tasks tedious and inefficient. I haven’t yet looked at how the Automatic Updates client interacts with the server, my subject for next week.
