IT Security Support
Links for Administrators Keeping Windows Workstations and Servers Up to Date

Keeping Windows Workstations and Servers Up to Date

Elliot Gingold, Client Services 3/7/03

After security problems occur, one often hears the “told you so” response that the victim machines would not have been vulnerable had the administrators had applied the such and such patch. Until recently, however, keeping up with patches was extremely difficult and administrators could not be fairly blamed when vulnerabilities went untreated. Even machines on Microsoft’s internal network went unpatched and were caught by compromises.

Following the bad press that Microsoft (and other OS vendors) were forced to endure, considerable efforts have been made to improve this situation. A number of systems have been released for enabling semi or completely automatic application of OS updates as they are issued. In fact, the number of different systems made available in itself was a cause of confusion. Recently, Microsoft announced that they will be attempting to consolidate their update products. This note covers the two approaches which I believe are the most applicable in most University of Melbourne situations - Software Update Service (SUS) and the web based Windows Update.

Some administrators have been reluctant to apply security patches as they believe such patches can sometimes cause more problems than they solve. My view is that the slogan "be paranoid, but not very paranoid" is appropriate here. It is true that some patches have not been fully tested, and their application has led to unforseen and unfortunate consequences. The official advice is this: to fully test any patches before widespread deployment. However, in my experience administrators at least in this institution do not have the time (or the facilities) to do testing of this sort. Instead, this worthy sentiment becomes a mantra for doing nothing and thus leaving machines vulnerable to attack. My approach is to delay a few days when a patch becomes available and to keep my eyes open for reports of problems. But when the patch is dealing with a live and widespreadly exploited vulnerability, I err on the side of getting it fixed quickly!

Be aware that the services described below are aimed at OS updates (extending only to applications delivered as part of the OS install such as Internet Explorer and IIS). Keeping applications such as Office up-to-date must still be done manually unless your Department is lucky enough to afford products such as St Bernards Update Expert.

What is the difference between SUS and Windows Update?

Windows Update is a web based service provided by Microsoft. On Windows 2000 and beyond machines, you will find a shortcut pointing to it in the Start Menu. Clicking on this option takes you to a web page which controls the scanning for required updates and the update process. It is up to you to use this service - nothing happens automatically.

SUS is based on a background process which takes place on your machine. About once a day it will go out and find if there are any new updates for your system. Depending on how it is configured, it will either notify you of the updates, download them, or even install them without any intervention. If it is set to merely notify or download, completion of the installation can be completed with a minimum of effort. To save on download time and charges, SUS can be set to use a local mirror rather than try to get each patch from Microsoft. For machines in our Active Directory tree, they are set by default to point towards such a mirror located on campus at id-sus.unimelb.edu.au.

Which do I use?

Both systems have their place in our environment. I would definitely avoid SUS for Servers as administrators would definitely want the finer control possible with the Windows Update system. I am sure many would avoid all such tools for servers and use script based approaching for applying patches! For workstations, however, the choice is not so clearcut.

The first point to remember is that administrator privileges are necessary on a workstation for installing patches to the OS. A user without administrator privileges on visiting on Windows Update site gets a message informing them that they cannot perform updates. The same problem exists with SUS, unless it is set to act fully automatically. In this case, however, the patches are installed under the privileges of the System account. Thus, if one is looking after large number of workstations (in labs or offices) whose regular users do not have administrator privileges, use of Windows Update requires visits to each and every machine by an administrator. SUS, on the other hand, can be left to get on with the job.

Against this, there is no doubt that the Windows Update web site provides superior tools for the administrator. In addition, web based updating is available for NT4 machines as well as current OSes. SUS requires a service packed w2k or XP. And, although this is promised, SUS does not currently install Service Packs. While administrators would probably choose to use SUS for those machines “out there”, I am sure that I am not alone in relying on the web based service for machines that I directly interact with.

What follows is a brief description of the use of the Windows Update web service (it is mostly self evident) and a slightly fuller discussion on how to implement SUS is our environment.

Windows Update Web Service

To start this, logon to the machine with administrator privileges and select Windows Update from the Start Menu. Press scan for Updates and follow instructions - you may be asked to download windows update software on to your machine. You will find both critical security upgrades and others listed. Links to full information about each update are present to help you decide if you want to install it at this time. If you remove it from the install list it will reappear next time you do a scan. Be aware that applying patches will almost inevitably require a system reboot!

Administrators will find the “View Installation History” option very useful. Note that updates performed both using this service and SUS are listed here. I am, however, unsure of how it handles manual updates, especially inappropriate ones which replace current versions of files with earlier ones and hence undo the upgrade.

The NT4 update web page is laid out in a different manner to that for the more recent OSes but appears to contain the same functionality.

SUS

The SUS client software can be installed on w2k sp2 workstations. With sp3 and sp4, it is automatically installed, as it is for XP sp1. Hence there should be no need for installation instructions. The default installation points to the Microsoft repository. However, we have included in a setting in the Domains Group Policies which point machines in the unimelb and student domains to our local SUS server. Administrators with machines outside these domains can still make use of the local mirror, but this unfortunately requires registry edits on the client machines. More information about configuring SUS clients in a non AD environment is included below.

As introduced above, there are a number of modes in which SUS can be run on client machines. However, for machines of users without administrator privileges, only the automatic mode is feasible. Configuration of such clients is best achieved by setting a Group Policy for the OUs in which the client machines reside. To do so you must load into your group policy editor an additional template file. This file, wuau.adm, can be downloaded from http://microsoft.com/downloads/details.aspx?FamilyId=D26A0AEA-D274-42E6-8025-8C667B4C94E9&displaylang=en and should be placed in the winnt\inf folder on the machine(s) on which you are running the Group Policy editor (generally as part of Active Directory Users and Computers console). To be able to use this template, open up any group Policy for editing (or simply create a new one), right click on Computer Configuration/Administrative templates and select Add/Remove Templates. You will then be able to add the wuau.adm template into your editor. This change will apply in all future uses of the editor on your machine.

Please note: If you already have an earlier version of the template added, please replace it with the current one. This is greatly improved and offers options that greatly improve the automatic use of SUS.

You will find the following settings:

Configure Automatic Update should enabled and step to “4- Auto download and schedule install”. You may also schedule an install time - this is often to be set for late at night as a reboot is needed.

Specify intranet Microsoft update service location should be left as Not configured as the setting will flow down from the domain (unless you want to set up your own SUS server).

Reschedule Automatic Updates scheduled installations should be enabled, and set to some figure. This simply means that if the computer misses an update time, it reschedules the install to a convenient after the machine is again switched on.

No auto restarts for scheduled Automatic Updates installation must be enabled. This allows the user to decide when the machine reboots, rather than it rebooting itself without user intervention. This corrects the most serious flaw in earlier versions. Note that if no user is logged in the reboot occurs automatically (hence the recommended late night timing).

With these setting a lab full of machines will look virtually look after themselves!

A few points about the use of SUS:

(1) Our SUS server mirrors the Microsoft server automatically. However, we must approve of all updates before they are sent to clients. Our policy has been the one outlined above, namely waiting a few days before approval unless the problem is serious.

(2) SUS does not handle service packs.

(3) When using SUS manually, you may personally (as administrator) approve or disapprove updates. If you do neither, or simply do not notice the SUS notification or the SUS icon in your tray, it will not go out and look for more updates until you act.

(4) When using SUS automatically as above and are asked to reboot, no further scans for updates will take place until the reboot happens. This could, unfortunately, lead to a system that is not rebooted often getting a long way behind if the original reboot request was dismissed and forgotten.

Finally, from the SUS deployment guide, registry edits for those who have not yet joined the AD:

*************************************************************************

You can add the settings below to the registry at this location:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

RescheduleWaitTime

Range: n; where n = time in minutes (1-60)

Registry value type: REG_DWORD

NoAutoRebootWithLoggedOnUsers

Set this to 1 if you want the logged on users to choose whether or not to reboot their system

Registry value type: REG_DWORD

NoAutoUpdate

Range = 0|1. 0 = Automatic Updates is enabled (default), 1 = Automatic Updates is disabled.