One of the biggest challenges you’ll face in computing today is the battle to protect your systems from virus and security vulnerabilities. Making sure that you’ve downloaded and installed all of the latest updates on your personal system is a big enough job. What do you do when you have to keep every workstation and server on your network up to date as well? That’s where Microsoft’s Software Update Services comes in.
Windows Update–the first weapon
One of the weapons Microsoft has provided in this battle is the Windows Update site. For several years, Microsoft has gathered a variety of updates to Windows and placed them on a single site, giving users an interface to get the updates they need.
Although the Windows Update site may seem like a neat idea, it’s far from perfect. Some corporate users have blocked access to the Windows Update site because sometimes it can cause more problems than it solves. Some of these problems include:
- Excessive bandwidth consumed by multiple users who all download the same patch.
- Potential problems with new patches blindly installed by users.
- Updates beyond the security patches that administrators may want to install.
Of course, preventing end users from directly accessing and updating systems via Windows Update meant that network administrators needed a new way to distribute updates to their users.
Automated Updates–the second weapon
Because of the concerns about the way Windows Update includes noncritical updates—and because of the need to push the updates to the client computers—Microsoft created the Automatic Updates installer. The utility runs constantly, periodically checking the Windows Update site. It can download the critical updates and inform the user that they are available, or updates can be downloaded and installed automatically.
By default, the user can determine whether the tool downloads updates or whether it downloads and installs them. This, however, can be changed through the use of group policies to prevent the user from seeing or interacting with the Automatic Updates utility.
Even though you can control the utility via group policy, it’s not perfect. Each client still updates from an Internet source—the Windows Update site. The utility also has the disadvantage of being an all-or-nothing operation. You must either set the utility to run in a way that downloads every critical update without intervention or you must disable it all together. This can be a problem for large organizations where it may be appropriate to do some testing of the patches before they are deployed across the organization.
Software Update Services–the big gun
With the release of Software Update Services (SUS), Microsoft evolved the Automated Updates utility so that it can use an internal server for updates. This offers two benefits. First, the updates are downloaded to the network one time, instead of one time for each computer. This is significant when several hundred PCs are involved, each of which would have downloaded the same updates from the Internet individually.
The second benefit of SUS is that you can control which updates are approved. Clients are allowed to download only approved updates. This allows you to precisely control which updates your clients can take.
Nice as it may sound, SUS isn’t perfect either. It processes only critical updates—and only those that are not an updated version or a service pack. SUS will not deliver Windows updates or driver updates. In other words, SUS will allow you to solve the urgent need of applying security patches, but it will not solve all of the needs of the organization for updates to Windows. You will have to find a different way to distribute those.
Understanding how SUS works
SUS downloads all of the updates for all of the languages that are selected during installation. This process can be performed manually or can be scheduled to occur at regular intervals. Typically, the first synchronization is performed manually to verify the process, and then future synchronizations are scheduled.
After the updates are downloaded to the SUS server, they are approved. During the installation process, you can select either automated approval or manual approval. If you selected automated approval, no action is necessary. If you selected manual approval, you must look through the list of downloaded updates periodically and manually approve them.
Once the updates are downloaded and approved, it’s time to have the Automatic Updates client installed on each of your PCs contact the SUS server. This is most often done through a group policy, but it can also be done manually, either through registry entries or by using the Automatic Updates template for the local policy editor.
The Automatic Updates client will do as instructed, typically downloading the updates and installing them at a predetermined time in the early morning. In fact, when you tell Automatic Updates to automatically install updates, it defaults to 3 A.M. Using group policies, you can force the workstation to install updates and reboot if necessary, even if the user is logged in and has not saved his or her files. This can be dangerous but provides reasonable assurance that the updates will definitely be applied.
The Automatic Updates client will contact the SUS server at a pseudorandom interval that is approximately 17 hours after the last contact or approximately five minutes after the client settings are changed. Using a pseudorandom interval helps prevent every client from attempting to contact the SUS server at the same moment. This could quickly overwhelm the SUS server.
Once the Automatic Updates client has determined which approved updates are available from the SUS server that applies to it, they are downloaded. The Automatic Updates client displays an icon on the toolbar if the user who is logged in is an administrative user. The icon allows the administrator to apply the updates immediately.
If an administrative user is not logged in, or if the administrative user does not install the updates immediately, the updates will be applied at the scheduled time. If a user is logged in at that time and a reboot is required, a message will appear warning that he or she must log off or be forcibly logged off to support the reboot.
Prerequisites for SUS
Like any good tool, SUS has a set of requirements that must be met for its use. Although Service Pack 1 for SUS has loosened the requirements a bit, there are still considerations for its deployment. These requirements are:
- Windows 2000 Service Pack 2—The server must have Windows 2000 Service Pack 2 installed.
- Automatic Updates client—Each client that is going to use the SUS server must have the Automatic Updates client installed. This is automatically included in Windows 2000 Service Pack 3 or can be downloaded and installed separately.
- Several hundred megabytes of storage—Even by limiting downloads to a single language, the updates that SUS downloads can be several hundred megabytes in size. The server you install SUS on must have several hundred megabytes of free storage.
- IIS Web Server—The IIS Web Server must already be installed when starting the SUS installation. If it isn’t, an error will occur during the installation process.
Installing SUS
The first step in the process of installing SUS is to download the Microsoft Installer file from the Microsoft SUS site. Then, double-click on the Installer to launch the Microsoft Software Service Setup Wizard. It works like almost every other wizard you’ve ever used when installing Microsoft software. Advance through the Welcome and License Agreement screens by clicking Next.
When you encounter the Choose Setup Type screen, you can choose Typical or Custom. Custom gives you a little more control over the installation, so click it.
Next, you’ll see the Choose File Locations screen shown in Figure A. Here, you can select the directories where you want to store the SUS service and the associated content.
Figure A |
![]() |
You can choose where to store update files. |
The next screen, Language Setting, enables you to choose the language of the updates you want to store. Specify whether you want to download updates for English, Specific Languages, or All Available Languages, and click Next to continue.
You’ll then see the Update Approval Settings screen, shown in Figure B. Specify whether you want to accept updates automatically or manually approve updates.
Figure B |
![]() |
SUS can automatically approve updates for you, or you can choose to approve them manually. |
Clicking Next will bring up the Ready To Install screen. Click the Install button to begin the installation process. After the files finish copying, you’ll see the final page of the wizard, which lists the URL your users will use to access SUS files on your network, as shown in Figure C. Click the Finish button to begin using SUS.
Figure C |
![]() |
Unlike most wizards, the final screen is actually useful, showing you the URL your users will use to access SUS. |
Configuring SUS
Once SUS is installed, it is time to do a bit of configuration. SUS must be synchronized with the Microsoft Windows Update servers to download content and should ideally be set up to download updates on a regular schedule. To do the configuration you will need to go to http://localhost/SUSAdmin. Obviously, you’ll swap out localhost with the name of the server you installed SUS on. A Web browser opens automatically after the installation process, as shown in Figure D.
To configure your SUS Server, click the Synchronize Server link in the left pane. When the Synchronize Server page appears (Figure E), click the Synchronize Now button to start the initial synchronization. This will ensure that the SUS server can contact the Microsoft Windows Update servers.
Synchronization progress will be displayed on the Web page, and you will receive a message when the initial synchronization is complete. Click OK to return to the Synchronize Server page. This process can take quite awhile, depending upon the speed of your network connection and the number of updates currently available.
After you complete the initial synchronization, click the Synchronization Schedule button to bring up the Synchronization Schedule dialog box. Here, you can set a synchronization schedule that causes the SUS server to contact the Microsoft servers for updated packages. You can choose to have SUS synchronize daily or weekly. The Daily option is appropriate for most organizations. When you finish, click the OK button.
Next, you should click the Set Options button to go to the Options page. Scroll down to the Select How You Want To Handle New Versions Of Previously Applied Updates section. Select the appropriate option to specify whether you want to automatically allow updates to approved packages. (This option is relevant only when you have chosen to manually approve updates.) Then, Click the Apply button.
The final step in the installation and configuration of your SUS server also applies only if you have chosen to manually approve updates. In that case, you must approve at least one update. Select the Approve Updates link from the left pane. When the page is displayed, select the check boxes to the left of the updates that you want to approve. Now, click the Approve button.
Directing the clients to use the SUS server
Thus far, we’ve just configured a server that can be contacted by an Automatic Updates client to retrieve updates. However, by default, the Automatic Updates client on your workstations and servers will not know how to reach your new SUS server. You can configure the Automatic Updates clients via registry updates on these machines, but the easiest way to tell them where to look is through group policies.
To configure the Automatic Updates client to contact the SUS server, start the Active Directory Users And Computers utility by running Start | Programs | Administrative Tools | Active Directory Users And Computers. Right-click on a container, or the domain tree container, that you’re associating the Automatic Updates group policy to and select Properties.
When the Properties window appears, select the Group Policy tab. Next, click the New button and enter a name for the group policy. Double-click on the new group policy. When the Group Policy Editor appears, click on the Administrative templates container of the Computer Configuration tree. Right-click on the Administrative Templates and select the Add/Remove Templates option.
Click Add, select the Wuau template, and click OK. Next, expand the Windows Components container and click the Windows Update folder. Double-click on the Specify An Intranet Microsoft Update Service Location option. Now, select the Enabled option and enter the URL for the SUS server in the appropriate text box. Click the OK button and close the Group Policy Editor and Active Directory Users And Computers utility.
Updates testing
The final step is to test that the updates are being delivered. The easiest way to do this is to configure a workstation to automatically download and install updates. From there, run Windows Update and take inventory of the critical updates that are available. Wait until the next day to see whether that number has gone down.
Note that even with SUS working, you may not get the critical updates to zero. Remember that SUS won’t deliver service packs, although Microsoft delivers Internet Explorer updates under the category of critical updates. As a result, you may still have a “critical” update even if SUS is working.