[MS-WSUSOD]:
Windows Server Update Services Protocols Overview
Intellectual Property Rights Notice for Open Specifications Documentation
Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit
Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Revision Summary
Date / Revision History / Revision Class / Comments9/23/2011 / 1.0 / New / Released new document.
12/16/2011 / 1.0 / None / No changes to the meaning, language, or formatting of the technical content.
3/30/2012 / 2.0 / Major / Updated and revised the technical content.
7/12/2012 / 2.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/25/2012 / 2.0 / None / No changes to the meaning, language, or formatting of the technical content.
1/31/2013 / 2.0 / None / No changes to the meaning, language, or formatting of the technical content.
8/8/2013 / 3.0 / Major / Updated and revised the technical content.
11/14/2013 / 3.1 / Minor / Clarified the meaning of the technical content.
2/13/2014 / 4.0 / Major / Updated and revised the technical content.
5/15/2014 / 4.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/30/2015 / 5.0 / Major / Significantly changed the technical content.
10/16/2015 / 5.0 / None / No changes to the meaning, language, or formatting of the technical content.
9/26/2016 / 6.0 / Major / Significantly changed the technical content.
Table of Contents
1Introduction
1.1Conceptual Overview
1.1.1Software Updates
1.1.2Update Server
1.1.3Update Client
1.1.4Downstream Server (DSS)
1.1.5Upstream Server (USS)
1.1.6Reporting Data
1.2Glossary
1.3References
2Functional Architecture
2.1Overview
2.1.1System Purpose
2.1.2Functional Overview
2.1.2.1Black Box Diagram
2.1.2.2White Box Diagram
2.1.3Applicability
2.1.4Relevant Standards
2.2Protocol Summary
2.3Environment
2.3.1Dependencies on This System
2.3.2Dependencies on Other Systems
2.3.2.1Network Connectivity
2.3.2.2Underlying Protocols
2.3.2.3Persistent Storage Facility
2.3.2.4External Configuration System
2.3.2.5External Restartable HTTP Download Service
2.4Assumptions and Preconditions
2.5Use Cases
2.5.1Actors
2.5.2Use Case Summary Diagram
2.5.3Use Case Descriptions
2.5.3.1Configure Update Server - Server Management Tool
2.5.3.2Manage Computer Groups - WSUS Administrator
2.5.3.3Approve Update - WSUS Administrator
2.5.3.4Monitor Update Installation - WSUS Administrator
2.5.3.5Synchronize Server - Server Management Tool
2.5.3.6Configure Update Client - Computer User
2.5.3.7Start Update Scan - Computer User
2.5.3.8Install Updates - Computer User
2.6Versioning, Capability Negotiation, and Extensibility
2.7Error Handling
2.7.1Failure Scenarios
2.7.1.1Network Failure
2.7.1.2Data Stores Corrupted
2.7.1.3Update Content Corrupted
2.8Coherency Requirements
2.8.1Timers
2.8.2Non-Timer Events
2.8.3Initialization and Reinitialization Procedures
2.9Security
2.10Additional Considerations
3Examples
3.1Example 1: Update Synchronization to DSS
3.1.1Registration and Authorization
3.1.2Configuration Synchronization
3.1.3Configuration Updates Synchronization
3.1.4Software Updates Synchronization
3.2Example 2: Initial Deployment Synchronization to Replica DSS
3.3Example 3: Initial Update Synchronization to Update Client
3.4Example 4: Differential Update Synchronization to Update Client
3.5Example 5: Rollup of Reporting Data to USS
3.6Example 6: Update Client Is Pointed to a New Update Server
4Microsoft Implementations
4.1Product Behavior
5Change Tracking
6Index
1Introduction
This document describes how the Windows Server Update Services (WSUS) protocols interact with each other and provide specific scenarios to highlight the WSUS design goals. The details of the communication at the protocol level are specified in the member protocol technical documents and are not duplicated in this document unless they are specifically used to clarify a concept.
It is often difficult for IT administrators to keep the computers on their organization's network updated in a timely manner with software updates that are critical for secure operation. A software update is any update, update rollup, service pack, feature pack, critical update, security update, or hotfix that improves or fixes a software product. IT administrators require centralized management for distribution of software updates. In addition to keeping software up-to-date, IT administrators require automated updates in order to test the updates before making them generally available and to provide statistics about the dissemination of the updates.
These requirements establish a feedback loop to improve administrator confidence about the compliance of the managed computers around critical and security updates. From a scalability perspective, an update service will provide a solution that tailors the updates to specific computer configurations without having to evaluate every available update. This is essential because updates that a single computer requires are based on the hardware and software configuration and usually represent a minority of all available updates. WSUS is designed to meet this need.
1.1Conceptual Overview
This section provides a conceptual overview of Windows Server Update Services (WSUS). This document assumes that the reader has the following background knowledge:
SOAP web service-based protocols
Use of XML to package data
WSUS enables IT administrators to distribute and manage software updates from a central location to a large number of computers. Administrators are able to approve software updates to groups of computers and retrieve status reports to monitor the state of update installations across those computers. WSUS consists of one or more WSUS servers and many WSUS clients. The WSUS server enables administrators to synchronize updates from a parent WSU server, organize computers into groups for efficient update management, approve updates for installation, and generate reports on update installation activity. Multiple servers can be configured as a hierarchy to allow a variety of deployment options, either with autonomous control or with centralized control. The WSUS client can detect updates that are applicable from the available set of updates on the server, install those updates, and report installation activity back to the server.
WSUS requires communication between the WSUS client and server to enable clients to discover updates that are available on the server. In addition, WSUS requires communication between servers to propagate update information, the updates, and administrative intent in a hierarchical deployment.
1.1.1Software Updates
A software update is either an update to an application or an update to a driver for a hardware device. WSUS treats any type of update the same way; it defines a software update as update metadata plus the update content. The metadata contains information about other updates that it depends on, rules that define under which conditions the update can be applied to a target computer, information about binary files that are used in the update installation process, and information about how the binary files ought to be applied on the target computer to complete the installation.
1.1.2Update Server
WSUS has a hierarchical topology that consists of servers called update servers and client computers that are called update clients. An update server is a computer that implements both the Windows Server Update Services: Server-Server Protocol, as specified in [MS-WSUSSS], and the Windows Server Update Services: Client-Server Protocol, as specified in [MS-WUSP], for providing update to other update servers and client computers.
1.1.3Update Client
Individual update clients report the update installation activity to its update server, as specified in [MS-WUSP] section 3.2.4. Data from individual update clients are propagated by a downstream server (DSS) to its upstream server (USS), based on the DSS and USS configuration as specified in [MS-WSUSSS] section 3.2.4.5. The reporting data provides the basis on which update installation reports can be generated by administrators to gauge the penetration and health of update distribution.
1.1.4Downstream Server (DSS)
WSUS has a hierarchical topology of servers with individual child servers that are configured either as an autonomous downstream server (DSS) or as a replica DSS, as described in [MS-WSUSSS] section 1.3. A DSS synchronizes update metadata and content as specified in [MS-WSUSSS] section 3.2.4.2and section 3.2.4.4, respectively. If the DSS is configured as a replica DSS, it additionally synchronizes the deployments , as specified in [MS-WSUSSS] section 3.2.4.3.
The update metadata, content, and deployment that are synchronized in this way on a WSUS server are used to determine available, applicable software updates for an individual update client. The protocol between an update client and its update server is specified in [MS-WUSP].
1.1.5Upstream Server (USS)
A USS is an update server that provides updates to other update servers. The following figure shows an example of a WSUS hierarchy. The upstream servers in a hierarchy provide information about updates to downstream servers. Any update server in the hierarchy can serve simultaneously as a DSS with respect to its upstream server and as a USS with respect to its downstream servers.
For example, in the following figure, update server C acts as a DSS when it communicates with its upstream server A and acts as a USS when it communicates with its downstream servers D or E.
Figure 1: Typical hierarchical topology of update servers and client computers
An update server groups its client computers into target groups. An update server can be configured to deploy the updates to its client computers by assigning the updates to the target groups for deployment and, optionally, by specifying an installation or removal deadline. This mapping of the individual update revisions to target groups is known as a deployment.
1.1.6Reporting Data
In WSUS, the term reporting data is used to describe data about update installation activity. Reporting data is generated by the update client on the target computer and it is sent to update servers. When WSUS is configured as a hierarchy, it can send the reporting data from a DSS to a USS. The reporting data provides the basis on which update installation reports can be generated by administrators to gauge the penetration and health of update distribution.
1.2Glossary
This document uses the following terms:
administrative intent: A combination of target groups, group membership, and update approvals that defines the WSUS administrator's choices regarding which available updates should be installed on each of the managed computers.
anchor: An opaque data element generated by an update server to identify the occurrence of a software update-related event in a manner that distinguishes temporally separate occurrences of the event.
client computer: A computer that gets its updates from an update server. A client can be a desktop computer, a server, or the update server. For more information, see [MS-WUSP] and [MS-WSUSSS].
content: A package that contains all the associated files for an update that is to be installed on a client computer.
deployment: An administratively specified decision to make a specific update revision available to a specific target group.
detectoid: A logical condition that is evaluated on a client computer to detect the presence of software, drivers, or their updates. A detectoid is identified by a GUID and described by metadata. It is represented as an update with no associated content.
downstream server (DSS): An update server that synchronizes its updates from another update server.
globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the GUID. See also universally unique identifier (UUID).
man in the middle (MITM): An attack that deceives a server or client into accepting an unauthorized upstream host as the actual legitimate host. Instead, the upstream host is an attacker's host that is manipulating the network so that the attacker's host appears to be the desired destination. This enables the attacker to decrypt and access all network traffic that would go to the legitimate host. The attacker is able to read, insert, and modify at-will messages between two hosts without either party knowing that the link between them is compromised.
metadata: XML-formatted data that defines the characteristics of an update, including its title, description, rules for determining whether the update is applicable to a client computer, and instructions for installing the update content.
replica DSS: A DSS that obtains both updates and update deployments from its USS.
reporting data: A description of update installation activity.
SOAP: A lightweight protocol for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation-specific semantics. SOAP 1.2 supersedes SOAP 1.1. See [SOAP1.2-1/2003].
synchronization: The process by which a downstream server (DSS) obtains update metadata, target groups, and update deployments from an upstream server (USS) in order to reconcile its state with the USS.
target group: A named collection of client computers whose members are defined administratively.
update: The combination of metadata and associated content for a software update. An update is identified by a GUID.
update classification: A scheme to classify updates such as Critical, Security, Service Pack, and so on. An update classification is identified by a GUID and described by metadata. It can be treated as an update with no associated content.
update client: A computer that implements the Windows Server Update Services: Client-Server Protocol to get updates from an update server. The client can be a desktop computer, a server, or the update server itself.
update metadata: A combination of XML-formatted metadata and associated content that contains information about an update.
update server: A computer that implements the Windows Update Services: Server-Server Protocol or the Windows Server Update Services: Client-Server Protocol to provide updates to client computers and other update servers.
upstream server (USS): An update server that provides updates to other update servers.
WSUS administrator: A user who deploys the latest Microsoft product updates to computers running the Windows operating system. WSUS administrators can fully manage the distribution of updates that are released through Microsoft Update to computers on their network. They are responsible for creating target group and update deployments.
1.3References
[MS-GPOD] Microsoft Corporation, "Group Policy Protocols Overview".
[MS-GPOL] Microsoft Corporation, "Group Policy: Core Protocol".
[MS-WSUSSS] Microsoft Corporation, "Windows Update Services: Server-Server Protocol".
[MS-WUSP] Microsoft Corporation, "Windows Update Services: Client-Server Protocol".
[MSDN-BITS] Microsoft Corporation, "Background Intelligent Transfer Service",
[RFC2616] Fielding, R., Gettys, J., Mogul, J., et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
[SOAP1.2-1/2003] Gudgin, M., Hadley, M., Mendelsohn, N., et al., "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation, June 2003,
2Functional Architecture
2.1Overview
WSUS is composed of two protocols:
Windows Update Services: Client-Server Protocol, as specified in [MS-WUSP]. This protocol enables update-client-to-update-server communication. Its purpose is to transfer update metadata, deployments, and content from an update server to an update client, and to report status information from an update client to an update server. These operations might rely on the update server that has acquired update metadata, deployments, and content from another update server by using the Windows Update Services: Server-Server Protocol.
Windows Update Services: Server-Server Protocol, as specified in [MS-WSUSSS]. This protocol enables server-to-update-server communication. Its purpose is to transfer update metadata, deployments, and content from an upstream server (USS) to a downstream server (DSS), and to send aggregated status information from a DSS to a USS. These operations might rely on the DSS that has acquired status information from update clients by using the Windows Update Services: Client-Server Protocol.
2.1.1System Purpose
WSUS enables the WSUS administrator to control automated delivery of updates to computers in an environment where the computers are managed by one or more WSUS administrators. WSUS is designed to quickly and efficiently distribute updates to computers without the need for an administrator to manually install the updates.