Software Update Services 2.0 Overview

On This Page

	Introduction
	What Is Planned to Be Included in SUS 2.0?
	Features at a Glance
	SUS 2.0 and the Update Management Process
	Managing Updates with SUS 2.0
	Next Steps

Introduction

The upcoming release of Software Update Services (SUS) 2.0 is intended to enable you to quickly deploy the latest critical updates and security updates to Microsoft Windows 2000-based servers and Windows Server 2003-based servers, as well as to desktop computers running Microsoft Windows 2000 Professional or Windows XP Professional.

By using the planned release of SUS 2.0, information technology (IT) administrators would be able to have full control in managing the distribution of updates that are released through Windows Update to computers in their network.

The SUS 2.0 solution would provide a management infrastructure consisting of the following:

•	Windows Update — the Microsoft Web site that includes all available Microsoft updates by product and update type.
•	Server component — Microsoft Software Update Services, referred to as the SUS 2.0 Server, would be installed on a computer running a Windows 2000 Server family or Windows Server 2003 family operating system inside your corporate firewall. The server component would provide the administration features that are needed to manage and distribute updates through a Web-based tool that administrators can access on any Windows computer in their corporate network.
•	Client component — Automatic Updates, the client component, would run on computers that receive updates for Microsoft products. This component would enable both server and client computers to connect either directly to Windows Update or to a server running SUS 2.0 to receive updates. The Automatic Updates component is planned to be included in Windows 2000 Service Pack 4 (SP4) and later, Windows XP and later, and Windows Server 2003.

What Is Planned to Be Included in SUS 2.0?

SUS 2.0 would build on the features of SUS 1.0, and it is currently planned to provide the following:

•	Expanded support for Microsoft products, including Office, SQL Server, Exchange, and hardware drivers
•	Expanded support for additional update categories
•	Ability to deploy updates to computers in any language that is supported by Windows client or server computers
•	Automatic prioritization and download of critical updates
•	Improved bandwidth efficiency through Background Intelligent Transfer Service (BITS) technology
•	Ability to target sets of updates to specific groups of computers
•	Ability for administrators to choose and determine the schedule for specific types of updates to download automatically
•	Improved reporting capabilities that enable administrators to monitor update deployment status and server health
•	Extensibility for managing both client and server components through the application programming interface (API) and scripts
•	SQL Server engine to be used as SUS 2.0 data repository
•	Easy migration from SUS 1.0 to SUS 2.0

Requirements

SUS 2.0 is planned to require the following.

Server

•	Windows 2000 Server SP4 or later or Windows Server 2003
•	Microsoft Internet Information Services (IIS) 5.0 or later, Microsoft Internet Explorer 6.0

Client

•	Windows 2000 Service Pack 3 (SP3) or later, Windows XP, and Windows Server 2003

Features at a Glance

SUS 2.0 is currently planned to provide the following features.

Client-Side Features

Automatic Updates would enable Windows to automatically download and install updates for Microsoft products. Key features on the client component would — according to plan — include the features in the following table.

Client-Side Features Planned for SUS 2.0

Feature	Description
Built-in security	For content: The SUS 2.0 client would only trust specific content signed by Microsoft; therefore, it would not be possible to tamper with content. For client-server relationships: The SUS 2.0 client would require the SUS 2.0 server to authenticate itself to establish communication and would use secure protocols to encrypt data that is exchanged during a session. For computer privacy:The SUS client would not send any personally identifiable information to Microsoft. Data that is collected would be strictly generic and would be used to make incremental improvements to the service.
Automatic detection, download, and installation of applicable updates	Automatic Updates would determine if a computer is missing updates and then initiate download and installation automatically. In a managed environment, the client would be able to get updates directly from Windows Update or from a SUS 2.0 server. In a managed environment, administrators would be able to configure how often the client checks a SUS 2.0 server for new updates.
Scheduling and notification options for users	Scheduling and notification options for users would be configurable through Group Policy. Users with administrative privileges would be able to specify whether they want to be notified before automatic download or installation or set the installation schedule. In addition, users would have the ability to retrieve previously declined or hidden updates.
Efficient background downloading of updates	Automatic Updates is planned to be using BITS, an innovative bandwidth-throttling technology, which is built into Windows 2000 SP3 and later operating systems, to download updates to a computer. BITS technology would provide delta compression during downloads — only what has changed in a file would then be downloaded from the SUS 2.0 server or Windows Update, enabling efficient distribution of service packs through Automatic Updates.
No interruption for users during update installation	When configured to do so, Automatic Updates is intended to be able to install updates that do not require reboots or service interruptions as soon as it finds them and not wait until the scheduled automatic installation time. Conversely, Automatic Updates would consolidate updates that require computer restarts into a single restart. Automatic Updates would also eliminate the need for users to interact with end user license agreements (EULAs).In a SUS environment, EULAs would be accepted on the SUS 2.0 server by administrators on behalf of clients
Powerful and extensible management capabilities for administrators	In an Active Directory directory service environment, it is planned to offer administrators the possibility of configuring the behavior of Automatic Updates by using Group Policy. In other cases, it is planned to offer an administrator the ability to remotely configure Automatic Updates using registry keys through the use of a logon script or similar mechanism. In addition, administrators would be able to use scripts to manage clients through the Component Object Model (COM)—based API. A software development kit (SDK) is then planned to be available.
Self-updating for client computers	In an administrator-managed scenario, client computers would be able to update their Automatic Updates components automatically to newer versions without the need for an administrator to reconfigure the computer.
Improved update applicability rules	The SUS 2.0 client would have the ability to only download and install specific updates that are truly applicable to the computer. Instead of administrators having to guess at which updates should be installed, the SUS 2.0 client would work with the SUS 2.0 server to evaluate which updates should be applied to a specific system. For example, customers would not run the risk of installing an update that is intended for Windows 2000 on a Windows XP computer.

Server-Side Features

The SUS 2.0 server administration tool is planned to provide a powerful set of management features. The server component would include the features in the following table.

Server-Side Features Planned for SUS 2.0

Feature	Description
Built-in security	The pages of the SUS 2.0 administration tool are intended to be restricted to local administrators on the SUS 2.0 server. The synchronization would validate the digital signature on any downloads through the update server. If the signatures are not from Microsoft, the packages would be deleted. The protocol that would be used in this process would guarantee that SUS 2.0 servers would communicate safely and reliably with the Windows Update Web site.
More content	SUS 2.0 would be able to support updating all Microsoft products over time.
New data model	SUS 2.0 components are intended to process updates through a new data model in which complex relationships between updates (for example, superseding or dependencies between updates) can exist.
Update management infrastructure and scale-out support	SUS 2.0 is planned to provide administrators with the opportunity to create an update management infrastructure consisting of a hierarchy of SUS 2.0 servers. For example, SUS 2.0 servers would be able to be deployed as autonomous servers, or masters with subordinate replicas, or load balancing clusters. Therefore, SUS 2.0 would then be able to be scaled out to handle any number of clients. In addition, it is planned for administrators to have the flexibility of configuring computers to get updates directly from Windows Update or from an intranet SUS 2.0 server that distributes updates internally. Administrators would also be able to employ a combination of both setups, depending on their network configuration.
Predeployment check and approval	By sending a predeployment request to all computers in a specific target group, it is planned that an administrator would be able to estimate how many computers would need an update and how the deployment of the update would affect the network. The predeployment check would then enable the administrator to perform an update impact analysis before actually deploying the update for installation.
Targeting	Targeting is planned to enable administrators to create target groups of computers one level deep and then target specific updates to those groups from a single SUS 2.0 server.In addition, SUS 2.0 would be able to support the following: client-side and server-side targeting, registry-based policy support for Active Directory environments, and server-side lists for non-Active Directory environments.
Download behavior as defined by the administrator	In addition to the efficient background downloading that the BITS technology would facilitate, BITS technology would — as planned — enable servers to synchronize based on administrator-defined update preferences and schedules. Administrators would then be able to specify both the blocks of time when updates download (including the option to download only as updates are deployed) and the amount of network bandwidth that is used when the downloads occur.
Deadline-based installation (or uninstallation)	It is planned for administrators to be able to enforce a deadline for update installations. The user would in that case not be able to postpone the installation of the update beyond the specified deadline.
Uninstallation	If it is supported by the update, the administrator would be able to initiate uninstall of an update if it is determined that the update is not suitable for the production environment after it is deployed.
Reporting	It is planned to give administrators the possibility of monitoring both update activity and the health of their servers through SUS 2.0 reporting features.To monitor and manage update activity, SUS 2.0 would then provide standard reports that aggregate update deployment status per update, per computer, and per target groups, based on events that are sent from the client.In addition, administrators would then be able to access read-only views into the SUS 2.0 database if they want to create custom reports.
Management extensibility through the API	Administrators can use scripts to manage SUS 2.0 servers through the .NET-based API.Developers can create management applications that integrate with SUS 2.0 through SUS 2.0 APIs.An SDK is intended to be available.
Import and export capabilities	Administrators would be able to use import and export features to download and transport updates between two SUS 2.0 servers.The import and export feature would, in that case, also facilitate an update management infrastructure in disconnected networks where the network to be protected does not have physical Internet access or connectivity to another network with Internet access, for example, in an intelligence community.
Backup and restore of server database	Administrators are intended to be able to easily back up and restore their SUS 2.0 server's update content, deployment action events, and settings from their Microsoft SQL Server 2000, Service Pack 2 (SP2) or later or Microsoft Data Engine (MSDE) 2000 database.
Flexible server configuration options	For remote administration, server configuration options are planned to include using either Secure Sockets Layer (SSL) or Hypertext Transfer Protocol (HTTP) to connect to SUS 2.0 servers and support for ports other than the default port 80 for client and server communication.Administrators would then also be able to configure proxy server settings if the SUS 2.0 server connects to the Internet through a proxy server.
Migration tool for SUS 1.0 servers	The migration tool would enable SUS 1.0 customers to seamlessly migrate their previous administrative settings from a SUS 1.0 server to a SUS 2.0 server.

SUS 2.0 and the Update Management Process

This section describes the Microsoft recommended approach to the update management process, and it provides examples of how administrators would be able to use the planned SUS 2.0 features to ensure success during each of the four phases of the process. Note that many of the features may be able to be employed in more than one phase. For more information about planned SUS 2.0 administration features, see "Server-Side Features" earlier in this document.

1. Assess

The administrator's goals for the Assess phase are to understand what may constitute a threat to the production environment and to understand ways to prepare the production environment to support routine and emergency update management. Through the first step, the Assess phase is essentially an ongoing process.

For example, administrators have to assess how many servers and clients they would need to update, what their storage and network bandwidth requirements are, and what time is acceptable to deploy an average update. They also have to determine what platforms, products, and languages they would want to update. Based on these factors, they would be able to determine the most efficient topology for scaling out their SUS 2.0 components. SUS 2.0 is intended to provide numerous options for setting up SUS 2.0 components, including the ability to store update content locally on SUS 2.0 servers or download content on demand from Windows. Administrators would also be able to configure Automatic Updates to download and install missing updates on a computer automatically. SUS 2.0 would provide options for managing clients in both Active Directory and non—Active Directory environments.

SUS 2.0 is planned to provide standardized aggregate reports that administrators would be able to run on an ongoing basis. These reports would then provide a list of computers that have contacted a SUS 2.0 server and, subsequently, the operating system, language, and service pack level of those computers. The reports would also identify which updates are installed or missing by computer and determine the health of a server.

2. Identify

The administrator's goals for the Identify phase are to discover new updates in a convenient manner, determine whether updates are relevant to the production environment, and determine update priority.

The SUS 2.0 administration tool is intended to enable administrators to create subscriptions. Subscriptions are intended to give administrators the option of determining which updates synchronize with Windows Update (or upstream SUS 2.0 servers) in terms of product and classification; for example, a subscription could contain a download request for only Windows XP critical updates and Office XP security updates. Administrators would also be able to set the synchronization schedule for each subscription. For example, administrators could create one subscription for critical updates to be downloaded daily and another subscription for optional updates to be downloaded weekly.

To determine whether an update is relevant to the production environment, it is planned for administrators to be able to look at properties of an update. Administrators would then also be able to run a predeployment check on an update, which is intended to help an administrator estimate how many computers would need the update and how the deployment of the update would impact the network before installation of the update in the production environment.

3. Evaluate and Plan

The administrator's goals for the Evaluate and Plan phase are to test updates in an environment that (although separate) resembles the production environment to see whether business-critical systems and applications would possibly be compromised, determine the tasks necessary to deploy updates into production, plan the update releases, build the releases, and then conduct acceptance testing of the releases.

When evaluating updates in a test environment, administrators would have the opportunity to run many of the SUS 2.0 features they would be using in the actual deployment. This would then include creating subscriptions, setting the schedule for automatically synchronizing their SUS 2.0 servers, creating target groups of computers and then targeting updates to download and install to those groups, running predeployment checks, and then scheduling the automatic update installations. During and after testing, administrators would be able to use the standardized reports that SUS 2.0 provides to monitor the success of their test update installations.

4. Deploy

The administrator's goals for the Deploy phase are to test, approve, and schedule update installations and then review the process after the deployment is complete.

To survey the production environment to ensure that it can handle updates before they are deployed, SUS 2.0 is planned to enable administrators to review the properties for an update and use the predeployment check to determine the impact before updates are installed. To establish the order in which updates are rolled out into production, administrators would then be able to use SUS 2.0 to create the upstream and downstream, independent and replica SUS 2.0 server configuration that is the most efficient, based on their network and staffing resources. In addition, it is intended that administrators be able to configure how clients communicate with SUS 2.0 servers or Windows Update by using Group Policy or by managing servers or clients extensibly through the API.

Through the SUS 2.0 administration tool, administrators would be able to specify target groups of computers and then target updates to deploy to those groups. It is planned for administrators to be able to then initiate the update installation (to start on a deadline, if desired) or initiate the uninstall if an updates proves to be unsuitable after it is deployed in the production environment. The administrator would then be able to use reporting to determine the success of the update deployment by computer or target group.

When the Process Is Complete

After administrators complete each phase in succession, they essentially move back into the Assess phase, where they should continue to inventory existing computing assets, assess possible security threats and vulnerabilities, determine the preferable source for information about updates, and assess the existing software distribution infrastructure and operational effectiveness.

Managing Updates with SUS 2.0

SUS 2.0 is currently planned to enable the following scenarios.

Planned Scenarios for SUS 2.0 Server

Microsoft is planning to enable the following scenarios for SUS 2.0 server:

•	Deploy multiple and different updates to sets of computers with a fine level of control Using the SUS 2.0 administration tool, administrators would be able to create one or more target groups of computers and then target one or more updates to install onto the computers in those groups. Administrators would also be able to set a deadline (date and time) by which the selected updates would install to the specified target groups. In an Active Directory environment, administrators would, according to current plan, be able to use Group Policy to assign client computers to a target group that is created using SUS 2.0 administration. New, Group Policy—enabled client computers would then be able to use client-side targeting. When these computers connect to a SUS 2.0 server, they would be able to communicate the group they want to belong to, in which case the server would automatically add them to the group.
•	Seamlessly and efficiently download updates from Microsoft based on administrator preferences The SUS 2.0 administration tool is intended to give administrators the ability to create a subscription, in which they can specify which updates to download from Microsoft and the schedule on which the specified updates download. When the subscription runs, the SUS 2.0 server that contains the subscription would then synchronize the updates that are specified in the subscription with the updates in the matching categories that are available on Windows Update. When specifying updates in the subscription, administrators would be able to choose platforms, products, languages, and update categories. For example, a subscription could contain a download request for only English Windows XP critical updates and English Office XP security updates.
•	Determine applicability of updates across a corporate network The SUS 2.0 administration tool is currently planned to provide administrators with the ability to perform an update impact analysis (or predeployment check) — for all computers or for specific groups of computers — before deploying an update in their production environment. While determining applicability among a set of updates, administrators would then be able to use the update status reports to monitor their progress in approving the updates.
•	Review status of deployments across a set of computers The SUS 2.0 administration tool is planned for administrators to be able to generate an update status report that can show all updates for which a certain action (or all actions) has been performed (for example, install or uninstall) and the date the action occurred. In addition, administrators would then be able to generate this report to show the status of updates across all computers or for a specific target group.
•	Initiate uninstall of updates if necessary If administrators determine that an update is not suitable for the production environment after deploying the update, it is planned for them to be able to uninstall the update if the update supports uninstall. As with installation, administrators would then be able to set a deadline by which the update would uninstall automatically. To find out if an update supports uninstall, administrators would be able to check the details for the update through the administration tool interface.
•	Manage SUS 2.0 components extensibly through scripts It is planned for administrators to be able to take advantage of the ability to manage both server-side and client-side SUS 2.0 components through the API. The server API is planned to be .NET-based, while the client API would be COM-based. An SDK is planned to be available for both components.

Planned Scenarios for Automatic Updates

SUS 2.0 is currently planned to enable the following scenarios for Automatic Updates:

•

One-click configuration experience for Automatic Updates Through one click in the Automatic Updates page in Control Panel, users with administrative rights would be able to specify whether they want to receive a notification from Automatic Updates before an update downloads or installs. Other options, including setting the time for updates to install automatically, would in this case be just as easy to configure on the Automatic Updates page.

•

Automatically get up to date with critical updates and other Microsoft updates It is planned that users would not have to search for critical updates and information — Automatic Updates would deliver them directly to their computers. Automatic Updates would then recognize when users are online and use their Internet connection to search for downloads from the Windows Update Web site.

Planned Deployment Scenarios

SUS 2.0 is intended to be flexible enough to meet the update management needs of a wide range of organizations — from small businesses with dial-up connectivity to the largest businesses with thousands of users distributed across multiple sites. Depending on the size of the organization, its location, and its connectivity infrastructure, administrators would be able to determine the most efficient way to scale out their SUS 2.0 servers — this might be one or many SUS 2.0 servers.

The following are common scenarios that are planned to be enabled for deploying SUS 2.0 components in small, medium, and disconnected networks.

Single SUS 2.0 Server (Small-Sized or Simple Network)

In a small-sized or simple network scenario, administrators would — according to the planned release — be able to set up a server running SUS 2.0 inside their corporate firewalls, which would then synchronize content directly with the external public Windows Update site, and distribute updates to client computers, as shown in the following figure.

Single SUS 2.0 Server

Multiple SUS 2.0 Servers (Medium-Sized or More Complex Network)

The following are two planned, common scenarios for deploying SUS 2.0 components in a medium-sized or more-complex network.

Multiple Independent SUS 2.0 Servers

Administrators would, in this planned scenario, be able to deploy multiple servers that are configured so that each server is managed independently and so that each server synchronizes its content to Windows Update, as shown in the following figure.

Multiple Independent SUS 2.0 Servers

The deployment method in this scenario would be appropriate for situations in which different local area network (LAN) or wide area network (WAN) segments are managed as separate entities — a branch office, for example. It would also be appropriate in cases where one server running SUS 2.0 is configured to deploy updates only to clients running a certain operating system (such as Windows 2000), while another server is configured to deploy updates only to clients running another operating system (such as Windows XP). In these situations, the two servers would not need to synchronize content.

Multiple Internally Synchronized SUS 2.0 Servers

It is planned for administrators to be able to deploy multiple servers running SUS 2.0 that synchronize all content within their organization's intranet. In this case, one server would be set up as the parent, or upstream, server — the source to which the other servers would then be synchronized. Additional servers running SUS 2.0 — the child, or downstream, servers — would synchronize content from the upstream server. The child servers would then be able to perform manual or automatic synchronizations, and the synchronizations could include updates, along with the list of approved updates, or updates only, without the list. When applicable, it is intended that the servers would be able to be located throughout a geographically dispersed network to provide the best connectivity to all clients.

As illustrated in the second figure, administrators would be able to design the deployment of multiple internally synchronized servers to expose a single server to the Internet (an expanded version of the first figure) or completely isolate their intranet from the Internet by scaling out the design as shown in the following figure.

Multiple Internally Synchronized SUS 2.0 Servers

Disconnected SUS 2.0 Servers (Highly Secure Network, No Internet Connectivity)

If their networked, Windows-based computers are not connected to the Internet, administrators would, in this planned scenario, be able to set up an internal server running SUS 2.0, as illustrated in the following figure. In this example, a server is created that is connected to the Internet but isolated from the intranet. After downloading, testing, and approving the updates on this server, an administrator would then hand-carry media to servers running SUS 2.0 and to distribution points within the intranet. Although the following figure illustrates this model in its simplest form, it could be scaled to any-size deployment.

Disconnected SUS 2.0 Servers With No Intranet Connectivity to the Internet

Next Steps

For information about SUS 1.0, see Software Update Services on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22631. Although SUS 2.0 would greatly expand the feature set of SUS 1.0, you can do the following now:

•	To compare SUS 1.0 with other Microsoft Management Solutions, under More Information, click Choosing a Security Update Management Solution.
•	To evaluate SUS 1.0, under Highlights, click Software Update Services Interactive Simulation.