If you stay as busy as I do, you probably feel that there just aren't enough hours in the day to get everything done, especially when it comes to downloading and deploying the latest Windows patches that Microsoft constantly seems to be releasing these days. Fortunately, Microsoft acknowledges that patch management is a royal pain and has come up with a couple of solutions.
These solutions are SMS Server and the System Update Service (SUS). SMS Server is a fairly expensive server application designed for deploying patches and other types of programs across large networks. The System Update Service, on the other hand, is a free, patch deployment utility, but it’s not nearly as flexible as SMS Server. If you’re currently using SMS Server, you should continue to use it because it’s superior to the System Update Service. If an SMS Server just isn’t in the budget, though, this article will tell you how you can download, install, and configure the System Update Service.
You can download SUS slipstreamed with Service Pack 1 directly from Microsoft's Web site. The download consists of a 32.2-MB self-extracting executable. You’ll want to download this file to an empty folder on the server that will act as your SUS distribution server. The server must be running Windows 2000 Server with Service Pack 2 or higher, or Windows Server 2003. SUS requires that the server be running in Application Server mode, which means that IIS must be running.
Begin the installation process by double-clicking the sus10sp1.exe file that you downloaded. When you do, Windows will extract the necessary files and launch the Setup Wizard. Click Next to bypass the wizard’s welcome screen, and you’ll be presented with the software’s end-user license agreement. Accept the license agreement, click Next, and you’ll be asked whether you prefer a typical or custom installation. For demonstration purposes, choose the Custom Installation option.
The next screen you’ll encounter is easy to accidentally bypass because the top portion simply asks for the path where you want to install SUS. However, you really need to pay attention to the bottom portion of this screen. It asks where you’d like to store the software updates.
Your choices are to either store the updates locally or to keep the updates on a Windows Update Server at Microsoft. I recommend storing the updates locally. Doing so will consume a considerable amount of disk space, but it offers much better performance than the alternative option. Unfortunately, I can’t really tell you how much disk space this option will consume because it depends entirely on the updates that Microsoft sends out.
After making your choice, click Next and the wizard will ask you which languages you want to store updates for. The default choice is All Available Languages, but I suggest choosing either the English Only option or the Specific Languages option. The reason is because of disk space and efficiency. For example, imagine that a new service pack came out tomorrow and was 200 MB.
If you have SUS configured to store updates in all available languages, there might be a dozen different localizations of the service pack. This means that SUS would have to download the same 200-MB service pack a dozen times and would require 2.4 GB of hard drive space. That’s fine if you need all of those languages, but if you don’t, save yourself the download time and the disk space by choosing a more appropriate option.
Click Next, and you’ll see another rather tricky configuration screen. This screen asks if you want to automatically approve new versions of previously approved updates, or if you’d prefer to approve those updates manually. There are a couple of reasons this question is a bit tricky. The most obvious is that a lot of network administrators like to maintain total control of which patches are installed. In such a case, it’s best to manually approve updates. At the same time, though, automatic approvals save time and ensure that updates are applied to clients more quickly.
Another reason this question tends to be a bit tricky is because a patch will sometimes supersede a preexisting patch. This means that a patch you’ve previously approved must be removed and replaced with a corrected patch. Allowing SUS to automatically approve new versions of previously approved updates allows buggy patches to be removed so that they may be replaced with a corrected version. For this reason, I recommend allowing automatic approval of new versions of previously applied patches.
Click Next, and the wizard will display the URL that SUS clients should be pointed to—usually http://server_name. Make note of this URL and click Install to begin the file copy process. When the wizard finishes copying the necessary files, it will display one last screen. Before you click Finish, be sure to read the screen because it contains the URL used for SUS administration. SUS uses a Web-based interface rather than an MMC console, so it’s important to know this URL, which is usually http://server_name/SUSAdmin.
The SUS Administration consoleAfter you click Finish, the wizard will automatically open Internet Explorer and take you to the SUS Administration console. After signing in to the console, click Set Options, which lets you specify the SUS configuration options. I won’t bore you with the details because most of the options available on this screen are the same ones you already worked through during the initial setup. This screen just lets you change any settings that you might not be happy with. It also gives you the chance to specify whether a proxy server should be used to connect to the Internet, as shown in Figure A.
|The Set Options link allows you to correct options chosen during Setup and lets you specify whether a proxy server should be used to access the Internet.|
Creating a synchronization schedule
Once the initial installation is complete, you need to create a synchronization schedule. This schedule determines how often the SUS server downloads updates from Microsoft. Click on the Synchronize Server link followed by the Synchronization Schedule button. You’ll then see the Schedule Synchronization dialog box, shown in Figure B.
|The Schedule Synchronization dialog box allows you to determine how often software patches should be downloaded.|
As you can see in the figure, your SUS server is, by default, set to never synchronize according to a schedule. To create the schedule, select the Synchronize Using This Schedule radio button. Next, select the time of day you want to have the synchronization occur. Synchronization can be bandwidth-intensive, so you should pick a time for synchronization that will not be disruptive to your users or to your nightly backup operations.
In addition to selecting a time for the synchronization to run, you must choose the days. You can synchronize either daily or weekly. The last option that must be set is the number of retry attempts. By default, if a scheduled synchronization fails, SUS will retry three times, waiting half an hour between each attempt. You can use the Failure drop-down list to choose the number of retries that you feel is right for your network.
Once you’ve set all the options, click OK to create the schedule. At this point, I recommend clicking the Synchronize Now button. Doing so will perform a manual synchronization so you don’t have to wait until the next scheduled synchronization to receive the latest patches. The initial synchronization can take awhile to complete, but subsequent synchronizations shouldn’t take quite so long.
Configuring the domain policy
So far, I’ve shown you how to install and configure SUS on a server. If you stop now, SUS will compile a catalog of updates, but those updates will never be distributed or installed on the workstations. To allow the updates to be distributed, you’ll have to modify the group policy for the domain.
Go to a domain controller and open the Active Directory Users And Computers console. When the console opens, right-click on your domain and select the Properties command from the resulting shortcut menu to see the domain’s properties sheet. Select the properties sheet’s Group Policy tab, verify that the appropriate group policy is selected, and click the Edit button. Windows will now load the Group Policy console.
Navigate through the console tree to Computer Configuration | Administrative Templates | Windows Components | Windows Update. Select the Windows Update container, and you’ll see four options appear in the pane to the right. Right-click on the Configure Automatic Updates option and select the Properties command from the resulting shortcut menu. This will open the Configure Automatic Updates Properties sheet.
On the properties sheet, click the Enabled button to enable automatic updates. Then check out the Configure Automatic Updating drop-down list. There are three available options: The Notify For Download And Notify For Install option is a completely manual approach that requires clients to click an icon to download and install updates; the Auto Download And Notify For Install option automatically downloads the updates, but prompts clients to install them; I recommend using the Auto Download And Schedule The Install option because it’s fully automatic.
After selecting your installation option, you must set a schedule for the day and time you want the installations to occur, as shown in Figure C.
|The Configure Automatic Updates Properties sheet allows you to control how updates are applied to clients.|
After clicking OK, you'll be returned to the Group Policy console. Right-click the Microsoft Update Service Location container and select the Properties command from the shortcut menu. You’ll then see the Specify Internet Microsoft Update Service Location properties sheet. This sheet is very simple to complete. Click the Enable button and then enter the URL for your SUS Server into the Set The Intranet Update Service For Detecting Updates field and the Set The Intranet Statistics Server field. Click OK to continue.
Next, right-click the Reschedule Automatic Updates Scheduled Installations option and select the Properties command from the resulting shortcut menu. You may have noticed earlier that I scheduled my updates to occur at 3:00 A.M. If the system isn’t powered on at that time, though, it will miss the updates.
The Reschedule Automatic Updates Scheduled Installations properties sheet allows you to force missed updates to occur the next time the machine is booted. Just select the Enabled option and enter the number of minutes that the system should wait after boot-up to process a missed update.
The last option you must configure is No Auto-Restart For Scheduled Automatic Updates. Some updates will inevitably require a reboot. If you enable this option, the system will notify users of an impending reboot and will force the reboot. The exception is that if the user has Administrator rights, he or she can veto the reboot.
Looking to the future with WUS
It doesn’t seem fair to write this article without telling you about the Windows Update Service (WUS). WUS is going to be the replacement for SUS in the near future. According to Microsoft, WUS will be available sometime during the second half of 2004. However, there’s a lot of industry speculation that WUS will debut in Microsoft’s next server release, which is scheduled to ship in the first half of 2005 and is currently code-named R2.
Although the release date is a bit shaky at the moment, some solid information exists regarding WUS. It will be available for free download as a feature pack for Windows Server 2003 and Windows Server R2. Microsoft’s philosophy behind creating WUS is that it wants to combine the power of SMS Server with the simplicity of Windows Update.
Another nice benefit to WUS is that it will update more Microsoft products than SUS did. It’s a little strange if you think about it: SUS updates only Windows, but WUS updates a variety of software on your system. So what exactly does WUS update?
The release is too far off for me to be able to give you a comprehensive list. What I do know is that WUS will be able to update Microsoft Office, SQL Server, and Exchange Server 2003. According to Microsoft, SUS might be able to update other products when it ships, and over time, SUS will be able to update all current Microsoft products.
There are also rumors that WUS will be more scalable than SUS. Microsoft is allegedly creating WUS with parent / child server capabilities. An administrator will supposedly be able to set bandwidth-throttling rules and time schedules so that updates don’t completely drain a network of bandwidth or occur at a time when they will interfere with other processes.
One other feature that WUS will have is a fairly nice reporting capability. Although the WUS-generated reports won’t be anywhere near as comprehensive as those offered by SMS Server, administrators should be able to tell at a glance which machines have and haven’t been patched.