For many years, systems administrators have needed a way to keep the network secure by automatically deploying security patches to all the computers in a network. Microsoft provided Windows Update a few years ago, but this program is only for individual users and small organizations because it doesn't include provisions for bandwidth utilization or management features for update testing and approval.
Fortunately, Microsoft has now released Software Update Services (SUS), which is one of the first fruits of the Strategic Technology Protection Program (STPP). For once, I must give Microsoft kudos. SUS fills a glaring gap in the management and security of the Windows family. In this article, I show you how SUS works and how to install and configure the various SUS components. In Part 2, I'll show you more complex SUS configurations, such as those that let you track update installation activity, balance bandwidth demands, and make allowances for scalability.
Understanding the Basics
SUS provides a way to automatically deploy crucial updates (hotfixes that solve non—security-related bugs), crucial security updates (security-related hotfixes), and security rollups to computers throughout a network—without requiring you to visit each computer or write any scripts. SUS is fairly flexible; you retain control over which updates to deploy, when to deploy them, and which computers should receive them. SUS doesn't deploy service packs for you, but the lack of deployment isn't a problem for Active Directory (AD) domains. Since Windows 2000 Service Pack 1 (SP1), Microsoft has supported service pack installation through IntelliMirror and group policies. With IntelliMirror and SUS, you can fully automate the process of keeping Windows XP and Win2K computers up-to-date.
SUS isn't perfect. It has some limitations:
- SUS doesn't support Windows NT or Windows 9x computers.
- SUS doesn't support Microsoft Office or Microsoft BackOffice products. SUS updates the OS, Microsoft IIS, and Microsoft Internet Explorer (IE) only.
- SUS currently supports many languages but not every language that XP and Win2K support.
- SUS doesn't have an uninstall option to automatically remove an update it has deployed, so testing the updates before installing them with SUS is important. However, you can use the manual uninstall method to remove updates.
SUS consists of three components: SUS, which runs on your server; Automatic Updates (AU), which runs on client machines; and Group Policy settings, which control AU clients from AD. The SUS server is basically an IIS Web site. You use Web pages to administer and monitor SUS, and AU clients use Web pages to download updates. Microsoft stores the updates on its Windows Update servers. SUS's Windows Update Synchronization Service handles the periodic synchronization between the SUS server and Microsoft Windows Update servers.
AU clients use HTTP to communicate with an SUS server. The SUS server also uses HTTP to periodically contact the Windows Update servers and synchronize the database of updates available for download. This database is called the catalog. You can perform catalog synchronizations on demand, or you can schedule them. The catalog doesn't contain the actual updates. It contains a description of the updates and information that the AU clients need to determine whether an update is applicable for their XP or Win2K installations.
You can configure the SUS server to download and install the updates for each language you choose to support, or you can leave the updates on the Windows Update servers, in which case the AU clients download and install the updates. No matter which configuration you choose, SUS checks the updates against Microsoft's public certificate before downloading and installing the updates to prevent imposters from using SUS to insert malicious code into your computers.
Although downloading and installation often occur in one step in many programs, they're two separate processes in SUS. For example, suppose you want to have the AU clients download and install the updates. The AU client periodically checks your SUS server for any newly approved updates. When the AU client finds an update that it needs to download, it begins the download process by connecting to the appropriate Windows Update server. You can configure the AU client to automatically download the update from the Windows Update server or to notify the user that an update is ready for download. In the latter case, the AU client waits for the user to initiate the download.
After the AU client downloads the update to a temporary folder, the installation process begins. The AU client checks the options you set to determine when to install the update. You can configure the AU client to automatically install updates according to a schedule you've set, or you can configure the AU client to notify the user that updates are available for installation and wait for the user to initiate the installation. After installing the updates, the AU client restarts the computer if required. If a user is currently logged on, the AU client gives the person 5 minutes to save his or her work, close all programs, and log off. The AU client then restarts the computer. Because the AU client uses the Qchain tool, it needs to restart the machine only once, even if it installed several updates.
Installing SUS
Now that you know the SUS basics, let's walk through a simple SUS installation in an AD domain. To use SUS, you need a server on which to run SUS. AD domain controllers (DCs) and machines running Microsoft Small Business Server (SBS) can't be SUS servers.
The SUS server as well as the DCs and workstations that SUS will manage all need to run Win2K SP2 or later and IE 5.5 or later. The SUS server also needs to run IIS 5.0 or later. You can install SUS on an IIS server that already hosts other Web sites. SUS can coexist with other Web sites because SUS uses only three IIS components: the Common Files folder, the Microsoft Management Console (MMC) Internet Information Services snap-in, and World Wide Web Server.