Download.microsoft.com



A Guide to Patch Management in Education using Microsoft Software Update Services

Abstract

This paper is intended as an overview of Software Update Services, a tool for the management, and distribution of critical Windows patches. Software Update Services (SUS) supports patches which are created and released to resolve known security vulnerabilities and system stability issues in Microsoft Windows 2000, Windows XP, and Windows 2003 Server operating systems.

SUS utilizes the Microsoft Windows Update service. SUS enables IT managers and ICT coordinators to use Software Update Services to configure a virtual Windows Update server within their schools, colleges and LEAs to service intranet servers and clients.

This paper is intended for IT administrators, school managers and teachers, responsible for ICT, who want to understand how Software Update Services works. The guide will be useful for individual schools, colleges or University departments wishing to provide patch management. This document describes examples of Software Update Services as a solution to patch management concerns, as well as providing an overview of the client and server-side components.

In-depth technical information on the SUS solution in general can be found in the SUS SP1 Deployment Guide which is downloadable from:

Table of Contents

A Guide to Patch Management in Education using Microsoft Software Update Services 1

Abstract 1

Table of Contents 2

SECTION 1 – Security Patch Management 3

1.1 Introduction 3

1.2 Security Patch Management in Education 3

1.3 Microsoft and Patch Management 4

SECTION 2 - Microsoft Technologies for Patch Management 5

2.1 Windows Update 5

2.2 Microsoft Baseline Security Analyzer V1.1.1 5

2.3 Software Update Services 6

2.3.1 Client Features 8

2.3.2 Server Features 8

2.3.3 Software Update Services in Education 9

The following section of this document goes through this procedure step-by-step. 10

SECTION 3 – Deploying Software Update Services 11

3.1 STEP 1 - Downloading SUS from the Microsoft Website 11

3.2 STEP 2 - Installing a SUS Server 11

3.3 STEP 3 - Administration of the Server 11

3.3.1 STEP 3a - Configuration of the Server 11

3.3.2 STEP 3b - Synchronisation 12

3.3.2.1 Synchronization Options 13

3.3.2.2 Synchronization Process 13

3.3.3 STEP 3c - Approving Updates 14

3.4 STEP 4 - Client Configuration 16

3.4.1 STEP 4a - Automatic Update client behaviour via Policies 17

3.4.2 STEP 4b - Automatic Update client behaviour without Active Directory 19

3.4.3 STEP 5 - Specifying the Server 19

SECTION 4 - Streamlining the Patch and Update Management Process 21

4.1 Microsoft Update 21

4.2 Microsoft Baseline Security Analyzer 2.0 21

4.3 Software Update Service 2.0 21

Appendices 22

Appendix A – Logging in SUS 23

Reviewing Server History and Activity 23

Synchronization Log 23

Approval Log 23

Server Health 23

E-mail Notification 23

Appendix B - Configuration Options in a non-Active Directory Environment 24

Appendix C - System Events 25

Appendix D - Download behaviour 26

Installation Behaviour 26

Installation Notification 26

Scheduled Installation 26

SECTION 1 – Security Patch Management

1.1 Introduction

In recent years educational institutions have become increasingly dependent upon ICT for providing administrative capability as well as supporting teaching and learning. The major impact that viruses and worms can have on computer systems was highlighted earlier in 2003 with threats such as the Blaster Worm and Sobig virus.

Implementing, executing, and continually improving computer security is increasingly important as technology evolves and attackers develop new methods to exploit security vulnerabilities that negatively impact IT operations.

Secure information technology (IT) management and operations, including security patch management, is the primary line of defence available to educational institutions which are interested in protecting themselves from these threats. Security patch management, operating system and application hardening, proactive virus detection, intrusion detection, and regular review of security settings and account permissions are all crucial elements of secure IT management and operations. Each is part of an effective defence-in-depth strategy that is necessary to reduce an educational establishment’s exposure to computer crime today.

1.2 Security Patch Management in Education

Security patch management is an essential process for systems management and administration. As vulnerabilities are identified in software, vendors release patches which enable users to fix their system and prevent against exploitation. Every widely used piece of software suffers the threat of being attacked by hackers who try to locate vulnerabilities. The problem of hackers finding vulnerabilities and vendors needing to patch them is unlikely to improve in the near future.

The term patch management is used throughout this guide and it refers to the tools, utilities and processes for keeping computers up to date with new software updates which are developed during the product life cycle.

All organisations should ensure that they have a process in place to efficiently identify security vulnerabilities and respond quickly. The education sector should be no different. This process should include steps for applying updates, making configuration changes and introducing countermeasures to eradicate vulnerabilities in the infrastructure thereby alleviating the risk of attack. It is important that the process is as thorough as possible since many attacks only require one vulnerable computer on the network.

Attacks work on the principle that many network managers fail to fix vulnerabilities and consequently can be attacked unsystematically by scanning the internet for machines at risk.

1.3 Microsoft and Patch Management

Every Microsoft product group includes a team that develops software updates for problems which are discovered after the product has been released. When Microsoft is made aware of a security threat or vulnerability, the issue is evaluated and verified by both the appropriate product group and the Microsoft Security Response Centre (MSRC). The product group then creates and tests a security patch to remedy the issue.

A software update is then distributed through the Microsoft Download Centre and other services, such as Microsoft Windows® Update, Microsoft Office Update, Microsoft Software Update Services (SUS), and Microsoft Systems Management Server (SMS) with the SUS Feature Pack.

There have been several widely-publicized attacks and vulnerabilities relating to Microsoft software. Many organizations with proactive security patch management in place were not impacted by these attacks, because they acted on information that Microsoft made available in advance of the attacks.

For example, Code Red is a worm that rapidly spread and had the potential to cause great impact. It exploited an error in code to cause a buffer overrun in IIS, this enabled the exploit code to execute any code on web servers. In windows 2000 Server, IIS was a default component. On July 16th, 2001 the original Code Red worm infected 250,000 computers over a nine hour period. Microsoft realised the potential impact of this vulnerability and released MS01-033 on June 18th, 2001, 28 days before Code Red was released. Some organizations which had an efficient security patch management process avoided being affected by Code Red by simply following the instructions on the MSRC bulletin. Many organizations who failed to act on the advice within the bulletin paid a heavy price.

SECTION 2 - Microsoft Technologies for Patch Management

2.1 Windows Update

Windows Update is the online extension of Windows that helps keep computers up-to-date. Windows Update currently supports Windows 98, Windows Millennium Edition, Windows 2000, Windows XP, and Windows Server 2003. New content is added to the site regularly providing the most recent updates, security fixes and drivers to protect computers.

Using Windows Update is a simple three-step process:

• Enter Windows Update and click Scan for updates.

• While browsing through the available updates in each category, click Add to select an update and add it to the collection of updates to install. If necessary, read a full description of each item by clicking the ‘read more’ link.

• When all required updates are selected, click ‘Review and install updates’, and then click ‘Install Now’.

The Windows Update Catalog (WUC) extends the basic operations of Windows Update by allowing users or administrators to solicit updates for individual categories—operating systems or hardware—and download them to a fixed location for later deployment. WUC pre-packages the updates in a subdirectory structure, offers a download history displaying the updates that have been downloaded and where they reside, and a brief description of each.

WUC is available through the Windows Update site; a link should be visible at the bottom of the table of contents. If a link is not visible, change the settings under Personalize Windows Update to display the link to the Windows Update Catalog.

2.2 Microsoft Baseline Security Analyzer V1.1.1

The Microsoft Baseline Security Analyzer (MBSA) is a tool that allows users to scan one or more Windows-based computers for missing security patches and common security mis-configurations. MBSA is compatible with Windows NT 4 (SP4 onwards), Windows 2000, Windows XP, and Windows Server 2003 systems. It scans for common mis-configurations in the operating system, IIS, SQL, and desktop applications, and can check for missing security updates for Windows, IIS, SQL, and Exchange. MBSA v1.1.1 was released in June 2003.

MBSA v1.1.1 provides a way to check on the security updates that should be have been applied from a specific SUS server. Users can select this option in the MBSA user interface or in the MBSA command line interface. This portion of the scan will then be performed against the security updates that have been approved on the local SUS server, rather than against the complete list of available security updates listed in the mssecure.xml file downloaded by the tool at run time. The advantage of this is that an administrator may perform a scan to ensure that the approved patches have been deployed to the designated workstations. The mssecure.xml file is still required to identify the patch properties for each SUS approved patch.

MBSA offers a Graphical User Interface (GUI) as well as command line version for scanning one or more Windows-based computers. Individual users can quickly launch a system scan by selecting Scan a computer from the MBSA web based GUI. The scan will default to the local computer and include a security check for all common mis-configurations as well as security updates. For the individual user, running the scan will provide a comprehensive report scoring the computer’s security readiness, providing an explanation of each result, and detailing recommended procedures for correctly addressing the issue.

For small educational institutions, in addition to a single computer, MBSA scans can target a group of computers through domain membership or a range of IP addresses. Small educational organisations can benefit from the simplicity of MBSA’s GUI, although a more practical application may be invoked through MBSA’s command-line interface.

By combining MBSA’s command-line interface with available scheduling tools such as Task Scheduler, small institutions can script MBSA operations to occur on predetermined schedules with a defined set of options, on a defined set of targets. For example, a scan could include an entire domain with all available checks during a low resource utilization time. Conversely, a more advanced usage may be creating an MBSA script that ties into Group Policy and is executed as part of a user logon process.

Note that the targets to be scanned do not require any MBSA software installed on them. The only requirement is for the user context in which MBSA is executed to have local administrator rights on each target machine (i.e. domain administrator rights within the same domain).

2.3 Software Update Services

SUS is a version of Windows Update designed for IT managers who want to approve each software update before installing them. SUS allows administrators to quickly and easily deploy Windows-related security patches and critical updates to any computer running Windows 2000 (SP2 onwards), Windows XP Professional, or Windows Server 2003. The Software Update Services solution consists of both client-side and server-side components to provide a simple solution to critical patch management.

SUS includes the following capabilities:

• Software updates can be approved uniquely on each SUS server, enabling testing in a separate environment as well as phased deployments across an LEA, school or college.

• Software updates can be distributed through SUS (saving bandwidth on shared Internet connections), or SUS clients can be configured to download software updates from Windows Update.

• Software updates can be copied onto a CD-ROM from a SUS server connected to the Internet and then transferred to SUS server architecture with no Internet access.

SUS servers require Windows 2000 Server (SP2 onwards) or Windows Server 2003, Internet Information Services (IIS) v5.0 onwards, and TCP port 80 for communications with SUS clients. Every SUS server can be configured to synchronize software update packages and approvals either manually or automatically from its parent SUS server or from the public Windows Update servers, enabling flexibility in how the environment is maintained.

The SUS client requires a special version of the Automatic Updates (AU) client. The clients are configured to connect to specific SUS servers and can be configured for automatic software update installations or end-user prompting.

For medium-sized networks, deploying SUS is driven by an institution’s scalability requirements for system updates. In theory, a single SUS server can accommodate the patch management needs of an entire medium-sized network (however, in practical applications, it may be considered worth deploying multiple SUS servers). If multiple servers were to be deployed the way in which they interact and the load placed on each server should be carefully considered. The normal way in which multiple servers would be configured is to synchronise the servers at regular intervals and split the clients into groups, each group would then have a SUS server to get their updates from instead of all clients going to the same server to obtain updates. In large deployments there may be one SUS server that communicates with Windows Update to get all of the updates and then acts as the Download SUS server. One or more Child SUS servers could then be deployed in a second tier; these would get their updates from the Download SUS server and service the clients. The server in this type of deployment can service its own group of clients as well.

This SUS server communicates directly with the Windows Update site to determine patch availability and can be configured to download updates locally or modify a local SUS metafile with patch information. Once the “root” SUS server has the appropriate updates, localized or referenced, tiered SUS servers, would be configured to synchronize with the “root” SUS server for available and approved updates. The synchronization process can be manual or scheduled.

Once the software updates are available for distribution on the SUS infrastructure, desktop clients are configured to interoperate with a SUS server via the familiar Windows Automatic Updates client. The Automatic Updates behaviour can be driven by configuration through Group Policy settings in an Active Directory environment or via registry keys in a non-Active Directory (non-AD) environment. Administrator-defined configuration options driven by Group Policy always take precedence over user-defined options. In addition, Automatic Updates Control Panel options are disabled on the target computer when administrative policies have been set.

The same AD and non-AD methodologies apply to specifying a server running Software Update Services. Computers running Automatic Updates then use this specified server to receive updates. Administrators can also use a Web server or SUS server to log statistical information from the Automatic Update clients about updates that have been downloaded as well as their installation status. These statistics are sent using HTTP, so the Web server can collect this information in its logs.

2.3.1 Client Features

The client requires the Automatic Update client v2.2 onwards. Any version prior to v2.2 cannot be configured to communicate with a SUS server. This updated AU client software builds on the Automatic Updates client which initially shipped with Windows XP. Automatic Updates is a proactive pull service that enables users with administrative privileges to automatically download and install Windows updates such as critical operating-system fixes and Windows security patches. The features include:

• Built-in security: Only users with local administrative privileges can interact with Automatic Updates. This prevents unauthorized users from tampering with the installation of critical updates. Before installing a downloaded update, Automatic Updates verifies that Microsoft has digitally signed the files.

• Just-in-time validation: Automatic Updates uses the Windows Update service technologies to scan the system and determine which updates are applicable to a particular computer.

• Background downloads: Automatic Updates uses the Background Intelligent Transfer Service (BITS), an innovative bandwidth-throttling technology which is used to download updates to the computer. This bandwidth-throttling technology uses only idle bandwidth so that downloads do not interfere with or slow down other network activity, such as Internet browsing.

• Chained installation: Automatic Updates uses the Windows Update technologies to install downloaded updates. If multiple updates are being installed and one of them requires a restart, Automatic Updates installs them all together and then requests a single restart.

• Manageability: In an Active Directory environment, an administrator can configure the behaviour of Automatic Updates using Group Policy. Otherwise, an administrator can remotely configure Automatic Updates using registry keys through the use of a logon script or similar mechanism.

• Multi-language support: The client is supported on localized versions of Windows.

2.3.2 Server Features

Software Update Services is based on the same back-end technology used on the public Windows Update site that has been servicing Windows customers since mid-1998. It runs on Windows 2000 Server with Service Pack 2 or later. Internet Information Services (IIS) must be enabled on the server.

Important: Make sure the server is already running the most up-to-date Windows security patches before setting it up as the server running Software Update Services.

The server features include:

• Built-in security: The administrative pages are restricted to local administrators on the computer that hosts the updates. The synchronization validates the digital certificates on any downloads to the SUS server. If the certificates are not from Microsoft, the packages are deleted.

• Selective content approval: Updates synchronized to your server running Software Update Services are not made automatically available to the computers that have been configured to get updates from that server. The administrator approves the updates before they are made available for download. This allows the administrator to test the packages prior to deploying them.

• Content synchronization: The server is synchronized with the public Windows Update service either manually or automatically. The administrator can set a schedule and/or use the Synchronize Now button to manually synchronize.

• Server-to-server synchronization: Because you may need multiple servers running Microsoft SUS inside your corporation in order to bring the updates closer to your desktops and servers for download, Microsoft SUS will allow you to point to another server running Microsoft SUS instead of Windows Update, allowing these critical software updates to be distributed around your enterprise.

• Update package hosting flexibility: Administrators have the flexibility of downloading the actual updates to their intranet, or pointing computers to a worldwide network of download servers maintained by Microsoft. Downloading updates might appeal to an administrator with a network closed to the Internet. Large networks spread over geographically disparate sites might find it more beneficial to use the Microsoft maintained download servers. These are the actual Windows Update download servers. In a scenario like this, an administrator would configure the SUS server to download only the metadata files, the client computers requiring updates will then contact the SUS server only to establish which updates are required and perform the download of the actual updates from one of the public Windows Update servers. Microsoft maintains a worldwide network of these type servers.

• Multi-language support: Although the Software Update Services administrative interface is available only in English or Japanese, the server supports the publishing of updates to multiple operating-system language versions. Administrators can configure the list of languages for which they want updates downloaded.

• Remote administration via HTTP or HTTPS: The administrative interface is Web-based and therefore allows for remote (internal) administration using Internet Explorer 5.5 or higher. By default this is done over HTTP, however if required the SUS server can be configured to utilize HTTPS.

• Update status logging: You can specify the address of the SUS server or any Web server with logging enabled which will be used by the Automatic Updates client to send statistics about updates that have been downloaded and/or installed. These statistics are sent using the HTTP protocol and appear in the log file of the Web server.

2.3.3 Software Update Services in Education

SUS provides a very good, efficient and relatively easy way of introducing patch management in to an educational establishment. One major advantage for education is that SUS is free to download from the Microsoft website.

Once the decision has been made to introduce SUS into an LEA, school or college, it must be decided where the server that will run SUS should be located. In a perfect world the institution would have the resources to designate a machine to only act as the SUS server. This is not always possible, especially in small schools that often rely on a single server for their entire infrastructure.

The assessment should be made based on the demands of the server that are already in place. If there is one server that is already being heavily utilized it would not be advisable for it to also be given the additional role of operating as a SUS server. In this case it would be strongly advisable to invest in another system and possibly share the role between the two servers.

SUS is not a particularly intensive service. For this reason the hardware specifications for a SUS server are relatively low. Wherever possible, it would always be advisable for security and scalability reasons to have a separate system dedicated to the SUS server application.

To simplify the process to its very minimum, any educational establishment should consider the deployment of SUS into its network following these very simple steps:

1. Download SUS from the Microsoft website

2. Install the SUS server software

3. Set up administration of the SUS Server

a. Server configuration after initial installation.

b. Synchronization (manual and automatic) of content between the public Windows Update service and the server running Software Update Services.

c. Selection and approval of synchronized content to be published to computers running the Automatic Updates client.

4. Configure the clients

a. Schedule/frequency

b. Administrative control via Policies

c. Administrative control without Active Directory

d. Policy templates

5. Specify the SUS Server

The following section of this document goes through this procedure step-by-step.

SECTION 3 – Deploying Software Update Services

3.1 STEP 1 - Downloading SUS from the Microsoft Website

For the server components, Microsoft Software Update Services (SUS) Server 1.0 with Service Pack 1 (SP1) can be downloaded from:



For the client component, the Automatic Update client (AU) V2.2 is required. You only need to download and install AU v2.2 if your computers are running Windows 2000 with SP2 or Windows XP without SP1. Windows 2000 SP3 onwards, Windows XP SP1 onwards and Windows Server 2003 already have the correct AU client installed. If you require to download the AU client v2.2, you can do so from:



3.2 STEP 2 - Installing a SUS Server

The installation process for the Software Update Services is through a Windows Installer package that installs the necessary server files and configures Internet Information Services. This is done by running the SUS executable file that has been downloaded on the server that has been set aside as the SUS server.

The recommended minimum hardware to run Software Update Services is a Pentium III 733 MHz computer with 512 MB of RAM. This hardware configuration can support up to 15,000 client machines.

3.3 STEP 3 - Administration of the Server

The four main administrative tasks for Software Update Services are:

• Server configuration after initial installation.

• Synchronization (manual and automatic) of content between the public Windows Update service and the server running Software Update Services.

• Selection and approval of synchronized content in order to be made available for download to computers running the Automatic Updates client.

3.3.1 STEP 3a - Configuration of the Server

Configuration options include the following:

• Choice of whether the update files are hosted on the Internet Windows Update service or locally on your server running Software Update Services.

• Proxy-server information for the server to access the Internet.

• Option to specify the SUS server’s fully qualified domain name or IP address to be used by the SUS clients for actual download of updates.

• Options for handling previously approved content. This is important if previously approved content gets changed on the Windows Update service.

• The list of client languages you would like to support.

The administrative tasks are performed via a series of Web pages hosted on the server running Software Update Services which can be accessed over a corporate intranet using a version of Internet Explorer 5.5 or later. See Figure 1. For this version of Software Update Services, there is no UI for managing multiple servers as a set.

[pic]

Figure 1. Software Update Services server administration

The home page for the administrative tools displays dynamically generated information deemed interesting to Software Update Services server administrators. Some of the information presented includes:

• Bulletins about new or updated security updates

• Information on released service packs

• Information about updates available for the Software Update Services

3.3.2 STEP 3b - Synchronisation

The update files contain the files that are installed when an update is approved. An administrator can choose to have these files hosted on the server running Software Update Services or on the public Windows Update servers.

[pic]

Figure 2. Synchronization page

3.3.2.1 Synchronization Options

There are two main options:

• Synchronize Now (manual synchronization)

• Synchronization schedule

The manual synchronization option allows administrators to synchronize immediately at any time, whereas the scheduled option allows administrators to preset a day and time for synchronizing the server with the Windows Update service on the Internet. Note that manual synchronization can still be initiated even when a schedule has been configured.

The two options are intended to give administrators flexibility in how their servers access the Internet. See Figure 2.

If the server configuration specifies that the update files be hosted on the intranet, those files are synchronized together with the update metadata during synchronization.

3.3.2.2 Synchronization Process

During synchronization, the Software Update Services server does the following:

• Connects over the Internet to the public Microsoft Windows Update service and downloads the latest content-update metadata as a compressed package.

• Validates that the downloaded package contains a Microsoft digital certificate. If the validation succeeds, the package is opened. If the validation fails, the package is deleted.

• Compares the new meta-data with the local copy, and notes the new and updated files.

• If a previously available update has been removed from the public Windows Update service, the synchronization process revokes that update from the server running Software Update Services. When Windows Update revokes an update, client machines connecting to that server are no longer offered a previously approved update.

• If a previously available update has had its files updated, the synchronization process automatically updates it on the server. If it has already been approved, it may be auto-approved or unapproved depending on the server configuration settings that the administrator pre-set.

• If the server configuration includes the synchronization of update files, new files are downloaded to the pre-specified location on the server.

• If a previously downloaded file is missing from the SUS server, a new copy is downloaded.

• If a file specified by the meta-data cannot be downloaded, the associated meta-data is removed from the list of updates that can be approved.

• If a manual synchronization fails, it is recorded in the synchronization log. If a scheduled synchronization fails, it will attempt to re-synchronize 30 minutes later. By default it will retry 3 times. The administrator can configure the number of re-tries.

The synchronization log is always updated during synchronization. This log records all of the synchronization related events and is accessible via the administrative GUI.

3.3.3 STEP 3c - Approving Updates

All updates downloaded to your server running Software Update Services need to be approved by a server administrator in order to be made available to computers running the Automatic Updates client that are connected to that server.

The approval process is done through the Approve Updates page. See Figure 3.

[pic]

Figure 3. Approving updates

The Approve Updates page lists all the updates available on the server and includes the following details: name, date the update was released, size, status of each package (Currently Approved, Not Approved, Updated, New), brief description, a link to get more details, a note if the package requires the computer to restart after installation, a note if the package is dependent on any other packages, and a list of Windows platforms to which the package applies.

This list can be sorted by Date, Status (New, Approved, Not Approved, Updated, etc.), the Windows platform it applies to, and the title of the update.

The Details link provides additional information such as:

• Name and path to the actual package (.cab/.exe) with the installation bits for the update.

• Installation parameters to pass at the command line when installing the package. Using these parameters, administrators can manually install the package independent of Automatic Updates if they want.

• Languages that the package supports.

• A link to the on-line KB article to read more information about the update. Already-approved updates have the check boxes next to them already selected.

To approve a package or packages, the administrator must:

1. Select the checkbox beside the package(s) to be approved.

2. Click the Approve button at the bottom of the page.

This two-step process makes the update(s) available to any computers running the Automatic Updates client that are connected to that server for updates. The new list of approved updates replaces any previous ones. Update files currently being downloaded are not impacted by this change.

In order not to approve updates, the administrator must:

1. Clear the checkbox beside the package(s) they do not want to approve.

2. Click the Approve button at the bottom of the page.

Sometimes, one or more updates are dependent upon other updates; for example, an update to Windows Media™ Player depends on an Internet Explorer update. In those scenarios, the dependent updates must be approved together. These dependencies are displayed in the UI.

If an update that has a dependency is approved or disapproved, the approval process displays a warning message to the administrator to that effect. The warning message includes the names of the dependent updates. If the administrator chooses to continue with the approval or disapproval of the updates, the dependents are approved or disapproved respectively.

Approved updates are made available to client computers immediately, even though these computers might not pick them up until their next server polling cycle.

Disapproved updates are not made available to computers that connect to the server after the disapproval process. There is, however, no central uninstall feature to remove updates from computers that have already downloaded the removed updates, or which are in the process of downloading those updates.

All approval and disapproval tasks are logged to an approval log that is accessible from the left pane in the administrator's Software Update Services UI.

3.4 STEP 4 - Client Configuration

A local administrator can configure Automatic Updates using a wizard that is displayed 24 hours after connectivity to the update service is established on a computer, or by using the Automatic Updates configuration page in Control Panel (in Windows XP, go to System Properties; in Windows 2000, go to Automatic Updates Properties). The local System Properties configuration options are shown in Figure 4.

Alternatively an IT administrator can configure Automatic Updates using Group Policy in an Active Directory environment or by configuring registry entries in a non-Active Directory environment.

[pic]

Figure 4. Automatic Updates control panel with options

These options give the local administrator control over how they want updates downloaded and installed on their computer. They can select:

• To be notified before downloading updates, and notified again before installing the downloaded updates. (This option requires local administrator privileges)

• To have updates automatically downloaded, and notify an administrative user before installing updates. (This option requires local administrator privileges)

• To have updates automatically downloaded and installed based upon a specified schedule. (This option can be used with normal user privileges)

Notification is through a notification-area icon and balloon. Figure 5 depicts an installation notification icon and balloon. The download notification is similar to the installation notification. All notification events are logged in the system event log.

[pic]Figure 5. Notification display area

The download and client behaviours are detailed further in Appendix D.

3.4.1 STEP 4a - Automatic Update client behaviour via Policies

The Automatic Updates behaviour can be driven by configuring Group Policy settings in an Active Directory environment. Administrator-defined configuration options driven by Group Policy always take precedence over user-defined options. In addition, Automatic Updates Control Panel options are disabled on the target computer when administrative policies have been set.

This Group Policy setting (located in Computer Configuration\Administrative Templates\Windows Components\Windows Update) specifies whether this computer receives security updates and other important downloads through Automatic Updates. When enabled, it also specifies the download and installation behaviour, just like the user options in Control Panel. See Figure 6.

Figure 6. Group Policy setting to configure Automatic Updates service

If the Automatic Updates service is enabled via this Group Policy setting, one of the following three options must be set (in the drop-down menu below):

• Notify for download and notify for install: This option notifies a logged-on administrative user prior to the download and prior to the installation of the updates.

• Auto download and notify for install: This option automatically begins downloading updates and then notifies a logged-on administrative user prior to installing the updates.

• Auto download and schedule the install: Typically, if Automatic Updates is configured to perform a scheduled installation, the recurring scheduled installation day and time is also set.

Possible options for scheduled installation days and times are:

• Day: “Every day”, and “Every Sunday” to “Every Saturday”

• Time: 12 A.M. to 11 P.M. in 24-hour format (00:00 to 23:00)

Notes:

1. Setting the policy to perform scheduled installations disables the Remind Me Later button in the Ready to Install Update dialog box.

2. The Auto download and schedule the install option include two additional GPO settings (new to SUS SP1) which dictate reboot behaviour and reschedule of missed scheduled installations. See Appendix D Download Behaviour.

If this policy is disabled, Automatic Updates does not perform any system updating, and any available updates must be downloaded and installed manually by going to the Windows Update site at:

.

Important: If the “Remove access to use all Windows Update features” Group Policy setting (located in User Configuration\Administrative Templates\Windows Components\Windows Update) is enabled, Automatic Updates is disabled for that logged-on user. Because this is a user-based value, it makes a local administrator appear as a non-administrator so that user will not be able to install updates. With this policy enabled, Automatic Updates still runs and, if configured as such, a scheduled installation can still occur.

The Software Update Services installation package includes a policy template file, Wuau.adm, which contains the Group Policy settings described earlier in this paper. These settings can be loaded into Group Policy Editor for deployment. These policies are also included in the System.adm file in Windows 2000 Service Pack 3, the Windows 2003 Server family, and Windows XP Service Pack 1.

3.4.2 STEP 4b - Automatic Update client behaviour without Active Directory

In a non–Active Directory environment, an administrator can set registry settings to configure Automatic Updates. The settings must be added to the registry of each Windows client at this location:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Further details of the exact configuration and changes that can be implemented via the registry can be found in Appendix B.

3.4.3 STEP 5 - Specifying the Server

Administrators can use Group Policy in an Active Directory environment or can configure registry keys to specify a server running Software Update Services. Computers running Automatic Updates then use this specified server to get updates. Administrators can also use a Web server to log statistical information from Automatic Updates about updates that have been downloaded and their installation status. These statistics are sent using the HTTP protocol, so the Web server can collect this information in its logs. The statistics server must be a computer running IIS 5.0 or greater with logging enabled.

[pic]

Figure 7. Group Policy setting to specify your server running Software Update Services

If you specify a server running Software Updates Services, computers running Automatic Updates use that server for updates. If you do not specify a server running Software Update Services, Automatic Updates gets updates from the public Windows Update service. If you specify a server running Software Update Services and specify a Web server for collecting statistics, computers running Automatic Updates send success or failure information about the download and installation status to the log files of the Web server.

Notes:

1. Both the server running Software Update Services and the statistics server can be the same computer.

2. Both SUS server and Statistics server settings must be specified.

SECTION 4 - Streamlining the Patch and Update Management Process

Microsoft strives to constantly improve the toolset available to customers for patch and update management. As noted previously, customer feedback indicates the need for tool consolidation and integration. Accordingly, improved, consolidated, and integrated versions of several familiar tools are scheduled for release in early 2004. These include:

4.1 Microsoft Update

Microsoft Update, scheduled for release in Spring 2004, will consolidate the patches and updates into one repository. At launch, Microsoft Update will support patches, updates, and service packs for Windows 2000, XP, Server 2000 & 2003 operating systems as well as Microsoft Office 2003, Microsoft SQL Server 2000, and Microsoft Exchange Server 2003.

4.2 Microsoft Baseline Security Analyzer 2.0

MBSA 2.0, slated for release in Spring of 2004, offers tight integration with SUS 2.0 and Microsoft Update. MBSA 2.0 represents a major achievement moving on to a true enterprise-ready scanning technology by including support for centralized storage to either a SQL database or a network share. Further enterprise-ready improvements include a configurable and pluggable engine check through a common engine framework, enhanced support for SMS, and integration with stand-alone tools like IISLockdown and SQLScan.

4.3 Software Update Service 2.0

Building upon the strengths of SUS 1.0, the next version will increase administrative flexibility while simplifying overall patch and update management. SUS 2.0 should be available by Spring 2004 and will include numerous improvements and enhancements.

The initial release of SUS 2.0 will support the patches available on Microsoft Update, (mentioned above). By the end of 2004, Microsoft plans to include support for all applications on Microsoft Update, (with the possible exception of MSN and Xbox). Further improvements include: an enhanced reporting environment per machine, per machine group, or per update information detail; and download and install success or failure reports with error detail.

SUS 2.0 will support system rollbacks to previous configurations if an installed update causes undesirable results. Also, updates may be targeted to specific machine groups through Active Directory Group Policy or static list-based non–Active Directory definitions.

Appendices

Appendix A – Logging in SUS

Reviewing Server History and Activity

Because most Software Update Services tasks involve the synchronization and approval of updates, two logs (synchronization and approval) are provided to the administrator. These logs are stored as XML files in an administrator-accessible folder on the server. New information is always appended to these files. The administrator can use the SUS administrative GUI to view these files and to clear them when they become too large.

Synchronization Log

This log contains the following synchronization information and can be accessed from the left navigation pane of the administrator's Software Update Services UI.:

• Time that the last synchronization was performed.

• Time of the next sync if scheduled synchronization is enabled.

• The update packages that have been downloaded and/or updated since the last synchronization.

• The update packages that failed synchronization and an associated error message to detail why the update failed to download.

Approval Log

This log contains the following information and can be access from the left navigation pane in the administrative UI:

• A record of each time the list of approved packages was changed.

• The list of items that changed.

• The new list of approved items.

• A record of the administrator user account who made this change

Server Health

The health of the server running Software Update Services, with respect to providing updates to client computers, can be reviewed through the Monitor Server page accessible via the left navigation pane in the administrative UI.

E-mail Notification

An e-mail notification service is provided to notify Software Update Services server administrators of new updates, revised previous updates, and so on.

Appendix B - Configuration Options in a non-Active Directory Environment

In a non–Active Directory environment, an administrator can set registry settings to configure Automatic Updates. The following settings are added to the registry of each Windows client at this location:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

• RescheduleWaitTime

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

• NoAutoRebootWithLoggedOnUsers

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

• NoAutoUpdate

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

• AUOptions

Range = 2|3|4. 2 = notify of download and installation, 3 = auto download and notify of installation, and 4 = auto download and scheduled installation. All options notify the local administrator.

• ScheduledInstallDay

Range = 0|1|2|3|4|5|6|7. 0 = Every day; 1 through 7 = the days of the week from Sunday (1) to Saturday (7).

• ScheduledInstallTime

Range = n; where n = the time of day in 24-hour format (0-23).

• UseWUServer

Set this to 1 to enable Automatic Updates to use the Software Update Services server as specified in the WUServer value.

To determine which server running Software Update Services your clients and servers go to for their updates, place the following two settings in the registry at this location:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

• WUServer

Sets the Windows Update intranet server by HTTP name (for example, ).

• WUStatusServer

Sets the Windows Update intranet statistics server by HTTP name (for example, ).

Appendix C - System Events

Automatic Updates writes events to the system event log to notify users of operations being performed. These events can be collected and analyzed by other event-log monitoring tools. The events cover the following scenarios:

• Unable to connect. Automatic Updates is unable to connect to the update service (Windows Update or the server running Software Update Services) and therefore cannot download and install updates according to the set schedule. Windows will continue to try to establish a connection.

• Install ready – no recurring schedule. Downloaded updates that are ready to install are listed in the event. To install the updates, an administrator needs to log on to the computer, where they see the notification area icon and install the updates.

• Install ready – recurring schedule. Downloaded updates that are ready to install are listed in the event. Additionally, the date and time for the scheduled installation of those updates is listed.

• Install Success. Successfully installed updates are listed.

• Install Failure. Updates that failed to install are listed.

• Restart required – no recurring schedule. To complete the installation of the listed updates, the computer must be restarted. Until the computer has been restarted, Windows cannot search for or download new updates.

• Restart required –recurring schedule. To complete the installation of the listed updates, the computer will be restarted within five minutes. Until the computer has been restarted, Windows cannot search for or download new updates.

Appendix D - Download behaviour

Automatic Updates downloads updates based on the configuration options that the local administrator selected. It uses the Background Intelligent Transfer Service (BITS) in Windows to perform the download by using idle network bandwidth. If Automatic Updates is configured to notify when updates that are ready to download, Automatic Updates sends the notification to a logged-on local administrator. If no local administrator is logged on, Automatic Updates waits for a local administrator to log on before offering the notification that updates are ready to be downloaded.

Installation Behaviour

Automatic Updates installs updates based on the configuration options that the local administrator selected.

Installation Notification

If Automatic Updates is configured to notify when updates are ready to install, the notification is sent to the system event log and notification area as shown in Figure 5.

When a local administrator clicks the balloon or notification area icon, Automatic Updates displays the available updates to install as shown in

[pic]Figure 8. Automatic Updates Ready to Install dialog box

Figure 8. The local administrator must then click the Install button to allow the installation to proceed. If the update requires a restart of the computer to complete the installation, a message is displayed stating that a restart is required. Until the system is restarted, Automatic Updates cannot detect any additional updates that might be applicable to the computer.

The Remind Me Later button provides a way for the installation to be deferred. The options are: 30 minutes, 1 hour, 2 hours, 4 hours, tomorrow, and 3 days.

Scheduled Installation

If Automatic Updates is configured to install on a set schedule, updates are automatically downloaded and marked as ready to install. If a local administrator is logged on, Automatic Updates notification is sent to the system event log and to the notification area as shown in Figure 5. Installation can be done by a local administrator at any time prior to the scheduled install time by clicking the Install button.

At the scheduled day and time, Automatic Updates installs any updates marked as ready to install and restarts the computer (if necessary), even if there is no local administrator logged on. If a local administrator is logged on, Automatic Updates displays a warning that an installation is about to begin

If you want to prevent Automatic Updates from performing an auto-reboot upon completion of a scheduled installation (of a reboot requiring update) whilst users are logged in then enable the No auto-restart for Scheduled Automatic Updates Installations GPO setting or configure the NoAutoRebootWithLoggedOnUsers registry key as described in Appendix B.

The Reschedule Automatic Updates Scheduled Installation GPO setting or RescheduleWaitTime registry key (see Appendix B) allows machines which have missed a scheduled installation to reschedule the installation to occur at start-up of the Automatic Updates service plus the number of minutes specified in the setting. This number can range between 1 to 60 minutes.

Both the No auto-restart for Scheduled Automatic Updates Installations and Reschedule Automatic Updates Scheduled Installation GPO settings are included with the wuau.adm Group Policy template new to SUS SP1. This template is not included with the SUS SP1 installation files and needs to be downloaded separately from:



................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download