In "Software Update Services, Part 1" (November 2002, http://www.secadministrator.com, InstantDoc ID 26767), I introduced you to the basic components of Microsoft Software Update Services (SUS) and showed you how to set up SUS to automatically deploy crucial updates to computers on your network. In this article, I examine scalability and stability concerns—how to test updates before you deploy them in your production environment, handle large numbers of Automatic Updates (AU) clients and limited bandwidth, deploy different AU lists to multiple computers, and track update installation activity.
Rolling Out SUS to Your Production Environment
Most people agree that before you install a new update on computers, you should first test it in your production environment. Typically, you should install a new fix with a limited rollout on some noncrucial computers and observe those computers for a week or so. At the same time, you should read the Windows & .NET Magazine UPDATE newsletters (http://www.winnetmag.com/email) to learn about problems early adopters have encountered. You can then roll out the update to your larger production environment.
You can use two simple methods to implement the rollout process with SUS. The low-tech method involves simply downloading and installing the update manually on your test systems. When you're ready to roll out the update to your production environment, approve the update on your SUS server, as Part 1 describes. This method is appropriate for small networks, but SUS also supports a more controlled and automated method for coordinating testing and deployment of crucial updates.
To use this more sophisticated method, you need to set up two SUS servers—let's call them SUSTest and SUSProd. Configure your production computers to pull their updates from SUSProd by editing an appropriate Group Policy Object (GPO) that you apply to all your production computers; maneuvering to Computer Configuration, Administrative Templates, Windows Components, Windows Update; and entering SUSProd as the Set intranet update service for detecting updates option. Next, create another GPO, link it to your test computers, and enter SUSTest as the Set intranet update service for detecting updates option. To test an update, simply approve it on SUSTest and all your test computers will install it. After you're satisfied that the update is safe for wider deployment, log on to SUSProd and approve the update.
To reduce the likelihood of errors (e.g., accidentally approving the update in SUSProd before you approve it in SUSTest), you can create separate user accounts such as SUSTestAdmin and SUSProdAdmin and place each user in the local Administrators group on the corresponding SUS server. Let's hope that Microsoft will enhance SUS so that you can manage both your test and production environments from one SUS server and that you can someday use SUS to require that an update be approved in the test environment before you can approve it in production. But, for now, the dual SUS server method isn't a bad solution. If you need to approve different updates for different types of computers (e.g., servers, workstations, domain controllers—DCs) in your production environment, you need to set up different SUS servers for each of type of system and configure those systems to pull updates from their corresponding SUS servers.
Understanding Bandwidth Capacity
Pulling updates across the network can eat up bandwidth. Fortunately, Microsoft thought about this problem when it designed SUS. When you implement SUS, you must consider two aspects of bandwidth capacity. First, when SUS servers synchronize their databases of available updates with Microsoft Windows Update servers, your Internet connection's bandwidth is affected. Second, when AU clients download those updates—either from your SUS server or directly from a Windows Update server—the bandwidth of your internal network and Internet connection is affected. You have options to control both situations. SUS always downloads the catalog (i.e., a list of available updates and their descriptions), but you can choose whether it downloads the update packages to the SUS server. To configure this option, open Microsoft Internet Explorer (IE), go to an SUS Web site such as http://sustest/susadmin, and select the Set Options link. Under the Select where you want to store updates setting, you can specify the Maintain the updates on a Microsoft Windows Update server setting and enter a folder name under Save the updates to a local folder.
Specifying the Maintain the updates on a Microsoft Windows Update server setting lets you avoid the initial hit of a 500MB download, but in the long run, you'll almost certainly save Internet bandwidth by specifying the Save the updates to a local folder setting. After the initial synchronization, you have to download future updates only once from the Internet, regardless of how many computers you need to update or how many SUS servers you have. Because such a scenario can create a disk space problem, I recommend using the Maintain the updates on a Microsoft Windows Update server setting only when you must support many different locales but just a few computers per locale.