7 Appendix B: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
Windows Server 2003 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Windows Server 2012 R2 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.3: This protocol is implemented by the Windows Server Update Services (WSUS) component in Windows 2000 Server operating system Service Pack 3 (SP3) and later.
<2> Section 1.7: The relationship between Windows versions and WSUS versions is specified as follows.
|
Operating system version |
WSUS 2.0 supported |
WSUS 2.0 SP1 supported |
WSUS 3.0 supported |
WSUS 3.0 SP1 supported |
WSUS 3.0 SP2 supported |
WSUS 10.0 supported |
|---|---|---|---|---|---|---|
|
Windows 2000 Server SP3 |
X |
X |
|
|
|
|
|
Windows Server 2003 |
X |
X |
X |
X |
|
|
|
Windows Server 2003 operating system with Service Pack 1 (SP1) |
X |
X |
X |
X |
|
|
|
Windows Server 2003 operating system with Service Pack 2 (SP2) and Windows Server 2003 operating system with Service Pack 3 (SP3) |
X |
X |
X |
X |
X |
|
|
Windows Server 2008 |
|
|
|
X |
|
|
|
Windows Server 2008 operating system with Service Pack 2 (SP2) |
|
|
|
X |
X |
|
|
Windows Server 2008 R2 |
|
|
|
|
X |
|
|
Windows Server 2012 |
|
|
|
|
X |
|
|
Windows Server 2012 R2 |
|
|
|
|
X |
|
|
Windows Server 2016 |
|
|
|
|
X |
X |
|
Windows Server 2019 |
|
|
|
|
|
X |
<3> Section 2.1: All applicable Windows Server releases support HTTPS for securing ports, although SSL is not configured by default when WSUS is installed.
<4> Section 2.1: In all applicable Windows Server releases, the DSS adds "xpress" to the HTTP "Accept-Encoding" request-header to request the encoding in "Win 2K3 Compression Algorithm", as specified in [MS-DRSR]. The USS compresses the reply in the requested algorithm.
<5> Section 2.1: In applicable Windows Server releases, ports used by the Web services are administratively configured during the initial setup of the USS.
<6> Section 2.1: Applicable Windows Server releases support HTTP1.1 Byte Range requests.
<7> Section 2.2.4.7: Applicable Windows Server releases construct the EncryptedData field by converting the DSS identity, the target groups that the DSS belongs to, and the cookie expiration time into a sequence of bytes, and then by encrypting the sequence of bytes using the TripleDES algorithm.
<8> Section 2.2.4.8: Applicable Windows Server releases construct the EncryptedData field by converting the DSS identity, the target groups that the DSS belongs to, the cookie expiration time, protocol version, and server's identity into a sequence of bytes, and then by encrypting the sequence of bytes using the TripleDES algorithm.
<9> Section 2.2.9.3: Windows Server 2003 and later implementations abort the protocol when this error is encountered. They do not automatically retry the operation.
<10> Section 2.2.9.3: Windows Server 2003 and later implementations stop the protocol when this error is encountered. They do not automatically retry the operation.
<11> Section 3.1.1: Windows implementations remove entries from this table after 90 days, by default. The threshold can be configured administratively, down to a minimum of 1 day.
<12> Section 3.1.1: In Windows implementations, entries are removed from this table only when specified by the administrator.
<13> Section 3.1.1: Applicable Windows Server releases use the version number of the WSUS component. If the update server is using WSUS 3.0 RTM, the value is "3.0.6000.374". If the update server is using WSUS 3.0 SP1, the value is "3.1.6001.65". If the update server is using an earlier version, the value is "2.0.0.0".
<14> Section 3.1.1: In Windows implementations, a new entry is added to this table when a new client computer calls the GetAuthCookie method on the update server for the first time as part of the Windows Server Update Services: Client-Server Protocol (as specified in [MS-WUSP]). Existing entries are removed only when specified by the administrator.
<15> Section 3.1.1: In Windows implementations, these values are populated when the client computer calls the RegisterComputer method as part of the Windows Server Update Services: Client-Server Protocol (as specified in [MS-WUSP]), and it is assumed that the values can be interpreted as specified in [MS-WUSP]. The data in this table is made available to the administrators of the update server for informational purposes.
<16> Section 3.1.1: In Windows implementations, this field is updated when the client computer calls the ReportEventBatch method of the WUSP (as specified in [MS-WUSP]).
<17> Section 3.1.1: In applicable Windows Server releases, the update server receives such notifications from client computers when the ReportEventBatch method is called as part of the Windows Server Update Services: Client-Server Protocol specified in [MS-WUSP]. Entries are added or modified when such notifications are received.
<18> Section 3.1.1: In applicable Windows Server releases, the update server receives notifications from client computers when the ReportEventBatch method is called as part of the Windows Server Update Services: Client-Server Protocol specified in [MS-WUSP]. Entries are added or modified when such notifications are received.
<19> Section 3.1.1: In applicable Windows Server releases, client computers notify the update server when they have successfully installed or failed to install an update. This is done using the Windows Server Update Services: Client-Server Protocol, specified in [MS-WUSP].
<20> Section 3.1.1: The IsSecure field is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<21> Section 3.1.1: The IsEncrypted field is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<22> Section 3.1.1: The DecryptionKey field is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<23> Section 3.1.1: In Windows 8 operating system and Windows Server 2012 and later, WUA clients authenticate the downloaded files against SHA-256 hashes prior to using their contents, in addition to the SHA-1 hashes. All other versions of WUA only authenticate the SHA-1 hashes contained in the existing Digest attribute and ignore the AdditionalDigest elements if they are present.
<24> Section 3.1.1.1: The FragmentType property is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<25> Section 3.1.1.1: The IsEncrypted property is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<26> Section 3.1.4.1.3.1: In applicable Windows Server releases, this field is not present.
<27> Section 3.1.4.1.3.3: In applicable Windows Server releases, this field is not present.
<28> Section 3.1.4.2: Windows implementations return an incorrect parameter name of machineName instead of accountName when the accountName parameter is invalid.
<29> Section 3.1.4.3: Windows implementations set the cookie expiration time to be 240 minutes from the time the cookie is created or the expiration time of the AuthorizationCookie, whichever is lower.
<30> Section 3.1.4.4: The MaxUpdatesPerRequestInGetUpdateDecryptionData configuration element is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<31> Section 3.1.4.4.3.1: In applicable Windows Server releases, this field is of the form nnnn ',' yyyy '-' MM '-' dd ' ' hh ':' mm ':' ss '.' sss where
nnnn is a positive decimal integer value between 1 and 2,147,483,647 that is used internally to identify a point in time. The value is 1 initially and is incremented by 1 each time a Deployment is created or deleted.
yyyy, MM, dd,hh, mm, ss, and sss are the current year, month, day, hour, minute, second, and fraction of a second, respectively.
<32> Section 3.1.4.4.3.1: WSUS 2.0 omits this element. WSUS 3.0 and its service pack releases specify this element to correspond to the protocol version specified in section 1.7.
<33> Section 3.1.4.4.3.1: The MaxUpdatesPerRequestInGetUpdateDecryptionData configuration element is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<34> Section 3.1.4.5: In applicable Windows Server releases, the anchor is required to follow the format described in section 3.1.4.4, under the Windows behavior description for the NewConfigAnchor field.
<35> Section 3.1.4.5.3.1: All applicable Windows Server releases set this to the anchor returned in the last successful GetRevisionIdList operation response.
<36> Section 3.1.4.6: All Windows implementations use XmlUpdateBlobCompressed if the size of the uncompressed XML metadata is more than 5,120 bytes.
<37> Section 3.1.4.6.2.1: On Microsoft Windows, the response is limited to 2000000 bytes.
<38> Section 3.1.4.6.3.5: In applicable Windows Server releases, this field is present only for updates that are available on the Microsoft Update website. For such updates, this URL points to a location on the Microsoft Update website from which the file can be downloaded.
<39> Section 3.1.4.6.3.5: In applicable Windows Server releases, this field is not present.
<40> Section 3.1.4.7: The GetDriverIdList method is not available in Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.
<41> Section 3.1.4.7: In applicable Windows Server releases, the anchor is required to follow the format described in section 3.1.4.4.3.1, under the Windows behavior description for the NewConfigAnchor field.
<42> Section 3.1.4.7.3.4: All applicable Windows Server releases set this to the anchor returned in the first successful GetDriverIdList operation response.
<43> Section 3.1.4.8: The GetDriverSetData method is not available in Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.
<44> Section 3.1.4.10: In Windows Server 2003 and Windows Server 2008 implementations, the anchor is required to follow the format defined in section 3.1.4.4 under the Windows behavior description for the NewConfigAnchor field.
<45> Section 3.1.4.10: In applicable Windows Server releases, the anchor is required to follow the format defined in section 3.1.4.4 under the Windows behavior description for the NewConfigAnchor field.
<46> Section 3.1.4.13: In Windows implementations, this value is always set to 5,000.
<47> Section 3.1.4.13: In Windows implementations, this value is always set to 1,500.
<48> Section 3.1.4.13: In Windows implementations, this value is always set to 20,000.
<49> Section 3.1.4.13: In Windows implementations, this value is always set to 500.
<50> Section 3.1.4.14: In Windows implementations, the USS calculates the difference between the current time (according to its system clock) and the clientTime value. If the absolute value of the difference is greater than 1 minute, the USS adds the difference to all other time stamps contained in the request.
<51> Section 3.1.4.14.3.2: Applicable Windows Server releases use the version number of the WSUS component. If the update server is using WSUS 3.0, the value is "3.0.6000.374". If the update server is using an earlier version, the value is "2.0.0.0".
<52> Section 3.1.4.14.3.3: In applicable Windows Server releases, two target groups are created during initial setup of the WSUS component: the "All Computers" and the "Unassigned Computers" groups. Because these groups are created during the initial setup of the update server, they are not counted by this field. If any additional target groups are created (by the administrator or by an application that interacts with the update server), those groups will be counted.
<53> Section 3.1.4.14.3.5: In applicable Windows Server releases, the OSMajorVersion, OSMinorVersion, OSBuildNumber, OSServicePackMajorNumber, OSServicePackMinorNumber, OSLocale, SuiteMask, OldProductType, NewProductType, SystemMetrics, and ProcessorArchitecture fields are populated using the corresponding values passed by the client computer to the RegisterComputer method on the update server as part of the WUSP (as specified in [MS-WUSP]).
<54> Section 3.1.4.15: In Windows implementations, the USS calculates the difference between the current time (according to its system clock) and the clientTime value. If the absolute value of the difference is greater than 1 minute, the USS adds the difference to all other time stamps contained in the request.
<55> Section 3.1.4.15: In Windows implementations, the USS maintains a list containing the ComputerId fields of client computers whose records have recently been deleted from the persisted store.
When the USS receives a call to RollupComputers, it checks the ComputerId from each ComputerRollupInfo structure against this list. If the ComputerId is found on the list, an entry of this form is added to the RollupComputersResult with this ComputerId.
<56> Section 3.1.4.15.3.2: In applicable Windows Server releases, the DSS will omit this field for a given client computer if none of the values have changed.
<57> Section 3.1.4.15.3.3: WSUS 3.0 SP1 sets this field to "Windows".
<58> Section 3.1.4.15.3.3: WSUS 3.0 SP1 sets this field to an empty string.
<59> Section 3.1.4.15.3.3: In applicable Windows Server releases, the OSMajorVersion, OSMinorVersion, OSBuildNumber, OSServicePackMajorNumber, OSServicePackMinorNumber, OSLocale, ComputerModel, BiosVersion, BiosName, BiosReleaseDate, SuiteMask, OldProductType, NewProductType, and SystemMetrics fields are populated using the corresponding values passed by the client computer to the RegisterComputer method on the update server as part of the Windows Server Update Services: Client-Server Protocol specified in [MS-WUSP].
The ComputerMake field is populated using the ComputerManufacturer value passed by the client computer to the RegisterComputer method.
The ClientVersion field is populated by combining the ClientVersionMajorNumber, ClientVersionMinorNumber, ClientVersionBuildNumber, and ClientVersionQfeNumber values passed by the client computer to the RegisterComputer method with "." inserted between each of the four values.
<60> Section 3.1.4.17: In Windows implementations, the USS will do this if it is under extremely heavy load.
<61> Section 3.1.4.17: In Windows implementations, the USS calculates the difference between the current time (according to its system clock) and the clientTime value. If the absolute value of the difference is greater than 1 minute, the USS adds the difference to all other time stamps contained in the request.
<62> Section 3.1.4.18: The GetUpdateDecryptionData method is not available in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
<63> Section 3.2.3: In applicable Windows Server releases, the FQDN of the USS is configured by the administrator using the WSUS administration UI.
<64> Section 3.2.3: In all Windows implementations, a DSS initiates this protocol either by a configuration-defined timer event (for example, every night at 1:00 A.M.) or by a manual request from the administrator UI. It also provides an API through which other applications can trigger the synchronization.
<65> Section 3.2.3: All Windows implementations provide an option in the WSUS administrator UI that allows the administrator to cancel a synchronization that is in progress.
If a cancel request is made while a SOAP call is in progress (a request has been sent but the response has not yet been received), the update server waits until the response is received before stopping the protocol. If no call is in progress, the update server stops the protocol immediately.
<66> Section 3.2.3: All Windows implementations provide an API through which other applications can trigger reporting data synchronization.
<67> Section 3.2.4.4: In applicable Windows Server releases, whenever a new entry is added to the Revision Table or to the Deployment Table, the update server will determine if any of the files associated with the update meet the preceding criteria. If so, the update server will start to download all such files.
In addition, if either the CatalogSyncOnly flag or the LazySync flag in the Server Configuration is changed, the update server will reexamine all files to see if any of them need to be downloaded. It will then start the download for all files that need to be downloaded.
<68> Section 3.2.4.4: The Windows implementation does not batch multiple FileDigest values into a single call.
<69> Section 3.2.4.4: In applicable Windows Server releases, the Background Intelligent Transfer Service (for more information, see [MSDN-BITS]) is used to perform the download.
<70> Section 3.2.4.5: In Windows implementations, this step is run immediately following the completion of the Deployments Synchronization step if the DSS is configured as a replica server, or following the Metadata Synchronization step if the DSS is configured as an Autonomous Server. All Windows implementations also provide an API through which other applications can trigger Reporting Data Synchronization without running the preceding steps in this protocol.
<71> Section 3.2.4.5: An update is considered to be critical if it is a member of the "Critical Updates" or the "Security Updates" Update Classification.
<72> Section 3.2.4.5: In Windows implementations, such updates are identified by an attribute matching the XPATH query "/Update/Property/@IsMandatory" and having a value of TRUE.
<73> Section 3.2.4.5: Windows implementations send the DownstreamServerInfo structures in batches, minimizing the number of requests required to send all the information.
<74> Section 3.2.4.5: Windows implementations send the ComputerRollupInfo structures in batches, minimizing the number of requests required to send all the information.
<75> Section 3.2.4.5: Windows implementations send the ComputerLastRollupNumber structures in batches, minimizing the number of requests required to send all the information.
<76> Section 3.2.4.5: Windows implementations send the ComputerStatusRollupInfo structures in batches, minimizing the number of requests required to send all the information.
<77> Section 3.2.4.5: Windows implementations wait between 1 and 5 minutes (chosen randomly) and then resend the failed message. If the request is still unsuccessful after three retries (four total attempts), the protocol is stopped with a failure.
<78> Section 5.1: On Windows 2000 Server operating system and Windows Server 2003, the DSS accepts only content files whose SHA-1 hash matches the SHA-1 hash specified by the USS in the update metadata. On Windows 8, Windows Server 2012 and later, it accepts only content files whose SHA-1 and SHA-256 hashes match the SHA-1 and SHA-256 hashes specified by the USS in the update metadata. On Windows 8, Windows Server 2012 and later, both the SHA-1 and SHA-256 hashes are required.