Summary
Keeping Windows-based systems current with the latest updates can be a complicated task for IT administrators. Now with the release of Microsoft Software Update Services (SUS) with integrated Service Pack 1 (SP1), administrators have a simplified and robust tool for deploying and managing critical Windows patches.
This white paper contains an overview of SUS and how it utilizes Windows patches to resolve known security vulnerabilities and stability issues in the Microsoft Windows 2000, Windows XP, and Windows Server™ 2003 operating systems. SUS leverages the successful public Microsoft Windows Update service. Information technology professionals use SUS to configure a virtual Windows Update server in their own Windows-based intranets to service corporate servers and clients.
This white paper is intended for information technology managers who want to understand how SUS operates. This overview presents customer scenarios in which SUS provides solutions for information technology professionals, as well as an overview of the client-side and server-side components.
Included in This Document
| • |
Introduction |
| • |
The SUS solution |
| • |
Customer scenarios |
| • |
Client-side: Automatic updates |
| • |
Server-side: SUS |
| • |
Related links |
Software Update Services Overview
Abstract
This white paper contains an overview of Software Update Services, a tool for management, and distribution of critical Windows patches. These patches resolve known security vulnerabilities and stability issues in Microsoft Windows® 2000, Windows XP, and Windows .NET Server operating systems. Software Update Services leverages the successful public Microsoft Windows Update service. Information technology professionals use Software Update Services to configure a virtual Windows Update server in their own Windows-based intranets to service corporate servers and clients.
This white paper is intended for information technology managers who want to understand how Software Update Services works. This overview presents customer scenarios in which Software Update Services provides solutions for information technology professionals, as well as an overview of the client and server-side components. System administrators who want to configure or deploy Software Update Services should read Software Update Services companion white paper on deployment.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.
© 2002 Microsoft Corporation. All rights reserved.
Microsoft, Windows, Windows Media, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
This document is best viewed onscreen in Microsoft Word 2000 or Microsoft Word XP in Print or Web Layout View.
Software Update Services or Systems Management Server
The Software Update Services Solution
Automatic Updates Client interaction
Review, test, and approve updates
Client-Side: Automatic Updates
Administrator Control via Policies
Configuring Automatic Updates setting
Configuring your server running Software Update Services
Configuration options in a non-Active Directory environment
Server-Side: Software Update Services
Installation and Configuration
Reviewing server history and activity
Software Update Services, a component of the Strategic Technology Protection Program (STPP), builds on the success of Windows Update to provide a solution for medium- sized enterprises to manage and distribute critical Windows patches. These patches resolve known security vulnerabilities and stability issues with Microsoft Windows operating systems. This solution updates Windows 2000 and higher Windows operating systems and is a particularly powerful update-management tool for Microsoft Active Directory® service-based networks. Although Software Update Services is well suited to an Active Directory environment, it is not a requirement.
Today corporations have to frequently check the Windows Update site or the Microsoft Security Web site for patches. Then they have to manually download patches that have been made available since they last visited the site, test the patches, and then distribute the patches manually or by using their traditional software-distribution tools. Software Update Services solves these problems by providing dynamic notification of critical updates to Windows computers as well as automatic distribution of those updates to your corporate Windows desktops and servers. For Software Update Services to function, only one corporate intranet computer requires access to the public Internet.
Software Update Services offers the following features:
· An administrator-controlled content synchronization service within the intranet. The synchronization service is a server-side component that retrieves the latest critical updates from Windows Update. As new updates are added to Windows Update, the server running Software Update Services automatically downloads and stores them, based on an administrator-defined schedule. If an administrator does not wish to set a schedule, they can manual synchronize their server running Software Update Services with Windows Update.
· An intranet-hosted Windows Update server. This easy-to-use server acts as the virtual Windows Update server for client computers. It contains the synchronization service and administrative tools for managing updates. It services requests for approved updates by the client computers connected to it using the HTTP protocol. This server can also host critical updates downloaded from the synchronization service and refer client computers to those updates.
· Administrator control over updates. The administrator can test and approve updates from the public Windows Update site before deployment on the corporate intranet. Deployment takes place on a schedule created by the administrator. If multiple servers are running Software Update Services, the administrator controls which computers access particular servers running Software Update Services. Administrators enable this level of control with Group Policy in an Active Directory environment, or through registry keys.
· Automatic Updates on computers (desktops or servers). Automatic Updates is a Windows feature that can be setup to automatically check for updates published on Windows Update. Software Update Services uses this Windows feature to publish administrator approved updates on an intranet. You can configure Windows to install updates on a schedule.
Software Update Services or Systems Management Server
The Microsoft Software Update Service is focused on obtaining critical updates for Windows 2000 and Windows XP inside your corporate firewall as quickly as possible. Many customers today are successfully using enterprise software distribution solutions like Systems Management Server for complete software management, including responding to security and virus issues. These customers should continue using these solutions.
To improve the Systems Management Server experience, Microsoft will be adding security-patch improvements to Systems Management Server in the third quarter of 2002. These improvements enable you to determine which computers need system updates. For more information, see the white paper, “Systems Management Server 2.0 for Getting and Staying Secure.”
Choosing a Solution
Here is the recommended process for evaluating your options:
· If you are currently using a solution that is successful in distributing patches, continue using that solution. Microsoft’s primary goal is keep Windows secure.
· If you are currently an SMS customer, you should wait and use the SMS security patch extensions that will also be released in the third quarter of 2002.
· If you are a medium-sized enterprise in need of a solution for managing your security updating needs, you should evaluate and deploy Microsoft Software Update Services. Its functionality and ease of usage will help solve your business needs by keeping Windows 2000 and Windows XP platforms safe and secure.
· If you are a larger organization that needs a solution for managing your security updating needs, you should evaluate and deploy Microsoft Systems Management Server 2.0 with the free SMS Value Pack, available in the third quarter of 2002. Larger organizations need greater platform support and greater control for their security updates, and SMS is best positioned to solve these unique needs.
The Software Update Services solution consists of both client-side and server-side components to provide a basic solution to critical patch management.
The solution is supported only on Microsoft Windows 2000 Professional, Server, Advanced Server (each with Service Pack 2), Microsoft Windows XP Professional, Home Edition, and the Microsoft Windows .NET Server family (on release).
Client-side Features
The client is based on the Windows Automatic Updates technology that was significantly updated for 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 built into Windows XP and newer operating systems, 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.
· Multi-user awareness: Automatic Updates is multi-user aware, which means that it displays different UI depending on which administrative user is logged on.
· Manageability: In an Active Directory environment, an administrator can configure the behavior 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.
Server-side 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 update 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 being deploying them.
· Content synchronization. The server is synchronized with the public Windows Update service either manually or automatically. The administrator can set a schedule or have the synchronization component of the server do it automatically at preset times. Alternatively, the administrator can 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 downloading, 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 download and test updates at a central site, then point computers requiring updates to one of the Windows Update download 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.
· Update status logging. You can specify the address of a Web server where the Automatic Updates client should send statistics about updates that have been downloaded, and whether the updates have been installed. These statistics are sent using the HTTP protocol and appear in the log file of the Web server.
Client-side Scenarios:
An IT administrator can configure machines running Automatic Updates differently based upon the machine’s role in the organization. This allows an IT administrator to update all desktops in an organization as soon as possible yet still minimize the down time of data center servers. The first three client-side scenarios describe three basic machine roles and how each might be best managed.
Managed desktop
The IT administrator has set the Automatic Updates policy so that Automatic Updates performs a scheduled installation every day at 3 A.M. When an update has been successfully downloaded, Automatic Updates logs an event that an update is ready to install at the next scheduled day and time. Prior to installation, Automatic Updates displays a countdown dialog box to the first found local administrator for a five-minute duration. If a local administrator is logged on to the system, the local administrator can stop the installation, and Automatic Updates schedules the installation for the next day at 3 A.M. Automatic Updates only displays this countdown to local administrators. If no local administrator logs on, or if no local administrator stops the countdown, the installation proceeds.
Managed server
The IT administrator has set the Automatic Updates policy so that Automatic Updates performs a scheduled installation every Saturday at 3 A.M. When an update has been successfully downloaded, Automatic Updates logs an event that an update is ready to install at the next scheduled day and time. Automatic Updates then adds an icon to the notification area and displays a balloon to the first found local administrator explaining that there are updates ready to install. Since the IT administrator used the policy to configure Automatic Updates, the local administrator cannot deselect any updates. The local administrator chooses not to install at this time and closes the balloon. The Automatic Updates icon remains in the notification area to allow the local administrator access to install the updates any time prior to the scheduled installation time. Provided the installation has not occurred, on Saturday at 3 AM, Automatic Updates displays the countdown dialog box to the first found local administrator. If no local administrator logs on, or if no local administrator stops the countdown, the installation proceeds.
Managed data center server
The IT administrator has set Automatic Updates to notify when updates are ready to install. When an update has been successfully downloaded, Automatic Updates logs an event that an update is ready to install. The event also indicates that the local administrator must manually install the update. An IT administrator remotely checks the system events on the data center server and sees an event stating that an update is ready to install. The IT administrator determines the next available planned system maintenance window and then executes their change notification plan. On the day and time of the scheduled maintenance, the local administrator logs on to the server and manually installs the critical update using Automatic Updates.
Automatic Updates Client interaction
The customer has set Automatic Updates to perform scheduled installations every Saturday at 3 A.M. On Thursday at 1 P.M., a critical update is ready to install. Automatic Updates then adds an icon to the notification area and displays a balloon explaining that updates are ready to install. The customer clicks the balloon to see the available updates. The customer reviews the updates and sees the ability to immediately perform the installation. Because a scheduled day and time is set, the Remind me later button is unavailable so that the reminder time is not confused with the scheduled time. The customer decides to install the updates by clicking the Install button. Automatic Updates immediately installs the updates.
Non-admin user
The IT administrator has set Automatic Updates to perform a scheduled installation every day at 3 A.M. An update completed its download and is ready to install during the day. The non-admin local user does not get an Automatic Updates icon in the notification area stating that the installation is ready. The user then turns the computer off for the night. In the morning, Automatic Updates detects that the scheduled installation time has passed and reschedules the installation for the next day at 3 A.M. This time, the computer is still on at 3 A.M and a local user is using the computer. Because this user is not a member of the local administrators group, there is no notification to the user that the installation is about to occur. If the update requires the system to be restarted the non-administrative user will be notified and allowed five minutes to save their work and log off before the automated computer restart.
Server-side Scenarios
Review, test, and approve updates
An IT administrator wants to test all critical updates published on Windows Update before deploying any updates to client computers on the network. In this scenario, the IT administrator has two servers running Software Update Services. The IT administrator sets an Automatic Updates policy so that a small number of computers designated to test updates point to the test server running Software Update Services. Another Automatic Update policy has the rest of the computers on the network pointed to the production server running Software Update Services. The IT administrator uses the synchronization feature of Software Update Services to download updates from Windows Update. The IT administrator uses the test server to approve a number of updates for testing. When testing of the updates has successfully completed, the administrator approves the updates on the production server
Automatic synchronization
An IT administrator who always wants all users to be up-to-date with the fixes from Microsoft as soon as they are available can set up a synchronization schedule to check the Windows Update server for new updates every day at, for example, 5 PM. Before going home at 6 PM, the IT administrator tests and approves newly downloaded updates on the servers. The next time the client computers connect to the server, they are able to download the latest updates.
Supported Platforms
Client computers using Windows 2000 Professional, Windows 2000 Server, or Windows 2000 Advanced Server (each with Service Pack 2), or Windows XP Professional or Windows XP Home Edition must update their operating system to use Automatic Updates with Software Update Services. The update for these platforms comes with the Software Update Services installation program. For installation instructions, see the white paper, “Software Update Services Deployment Guide” available at: http://go.microsoft.com/fwlink/?LinkId=6928.
Note: Microsoft includes the update required for the operating systems listed above in Windows 2000 Service Pack 3 and Windows XP Service Pack 1.
User Experience
Configuration options
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 1. Alternatively an IT administrator can configure Automatic Updates using Group Policy in an Active Directory environment or by configuring registry entries.
Figure 1. 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.
· To have updates automatically downloaded, and notify an administrative user before installing updates.
· To have updates automatically downloaded and installed based upon a specified schedule.
Notification is through a notification-area icon and balloon. Figure 2 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.
Download behavior
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 local administrator to log on before offering the notification that updates are ready to be downloaded.
Note BITS is included in Windows XP. To provide the same functionality on Windows 2000, the Automatic Update installer provides BITS for Windows 2000 SP2 machines.
Installation behavior
Automatic Updates installs updates based on the configuration options that the local administrator selected.
If Automatic Updates is configured to notify when updates are ready to install, the notification is sent to the system event log and to the notification area as shown in Figure 2.
Figure 2. Notification area display
When a local administrator clicks the balloon or notification area icon, Automatic Updates displays the available updates to install as shown in Figure 3. 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.
Figure 3. Automatic Updates Ready to Install dialog box
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.
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 2.. If the icon or balloon is clicked, the local administrator sees a dialog box similar to Figure 3 but with the Remind Me Later button disabled. Installation can be done 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, as shown in Figure 4.
Figure 4. Automatic Updates pre-install countdown dialog
If a restart is required and a user is logged on, a similar countdown dialog box is displayed, warning the user about the impending restart.
Administrator Control via Policies
The Automatic Updates behavior 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.
Configuring Automatic Updates setting
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 behavior, just like the user options in Control Panel. See Figure 5.
Figure 5. 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 Configure automatic updating):
· 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)
Note: Setting the policy to perform scheduled installations disables the Remind Me Later button in the Ready to Install Update dialog box.
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
http://windowsupdate.microsoft.com.
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.
Configuring your server running Software Update Services
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.
Figure 6. 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.
Note: Both the server running Software Update Services and the statistics server can be the same computer.
Policy templates
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, and will be included in the Windows .NET Server family, and Windows XP Service Pack 1 when they are made available.
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
· 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, http://intranetSUS).
· WUStatusServer
Sets the Windows Update intranet statistics server by HTTP name (for example, http://intranetSUS).
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.
Server-Side: Software Update Services
Software Update Services is an intranet-hosted version of the Windows Update service specifically designed to service computers running the Automatic Updates client within an intranet. It does this by downloading updates from the public Windows Update service and making them available under administrator control.
Supported Platforms
Software Update Services runs on Windows 2000 Server with Service Pack 2 or later, and on the Windows .NET Server family.
Software Update Services is only available in English and Japanese language versions. The English version runs on other localized Windows 2000 Server releases.
Installation and Configuration
This paper presents an overview of the server-side components Software Update Services. System administrators who want detailed information on how to configure or deploy Software Update Services should read Software Update Services companion white paper, “Software Update Services Deployment guide” available at: http://go.microsoft.com/fwlink/?LinkId=6928.
Installation
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.
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 15,000 client machines.
Configuration
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.
· 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.
Administrative Experience
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 to be published to computers running the Automatic Updates client.
· Monitoring of server status and logs.
These administrative tasks are performed via a series of Web pages hosted on the server running Software Update Services itself that can be accessed over a corporate intranet using a version of Internet Explorer 5.5 or newer. See Figure 7. For this version of Software Update Services, there is no UI for managing multiple servers as a set.
Figure 7. Software Update Services server administration
Home page
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
Synchronizing the server
There are two types of content that can be synchronized from the Windows Update server. These are:
· Update meta-data
· Update files
The update metadata contains the descriptions of available updates and the applicability rules that are used to apply them to a target computer. This metadata is always downloaded during a synchronization process.
The update files contain the files that are installed when an update is approved. They are referenced in the update metadata, and an administrator can choose to have these files hosted on the server running Software Update Services or on the public Windows Update servers.
Figure 8. Synchronization page
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. The two options are intended to give administrators flexibility in how their servers access the Internet. See Figure 8.
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.
During synchronization, your server running Software Update Services 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 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 intranet location, 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 logged to 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.
A synchronization log is always updated during synchronization. This log records all of the events listed here and is accessible in the administrative interface.
Approving updates
All updates downloaded to your server running Software Update Services need to be approved by a server administrator before the server makes them 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 9.
Figure 9. Approving updates
The Approve Updates page list 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 a local copy of the Read This First page that exists on your server running Software Update Services 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 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.
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 in XML files in an administrator-accessible folder on the server. New information is always appended to these files. The administrator can use the administrative interface to clear these files when they become too large.
This log contains the following synchronization information:
· 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.
The log can be accessed from the left navigation pane of the administrator's Software Update Services UI.
This log contains the following information:
· 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 who made this change; that is, the name of the administrator or the synchronization service.
The log can be accessed from the left navigation pane in the administrative UI.
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.
An e-mail notification service is provided to notify Software Update Services server administrators of new updates, revised previous updates, and so on.
For more information, see the following resources:
· Software Update Services website at http://go.microsoft.com/fwlink/?LinkId=6930.
· Microsoft Security at http://www.microsoft.com/security/.
· Microsoft Windows Update at http://www.windowsupdate.microsoft.com.
· Understanding Group Policy white paper: http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp.
Feedback
To provide feedback about Microsoft Software Update Services or this white paper, write to Software Update Services Feedback at: cwufdbk@microsoft.com.
