Export (0) Print
Expand All

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 released service packs:

  • 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

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 SP3, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<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

Windows 2000 Server SP3

X

X

     

Windows Server 2003

X

X

X

X

 

Windows Server 2003 with SP1

X

X

X

X

 

Windows Server 2003 SP2and Windows Server 2003 with SP3

X

X

X

X

X

Windows Server 2008

     

X

 

Windows Server 2008 with SP2

     

X

X

Windows Server 2008 R2

       

X

Windows Server 2012

       

X

Windows Server 2012 R2

       

X

<3> Section 2.1: All Windows implementations support HTTPS for securing ports, although SSL is not configured by default when WSUS is installed.

<4> Section 2.1: In all Windows implementations, 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 Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, ports used by the Web services are administratively configured during the initial setup of the USS.

<6> Section 2.1: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations support HTTP1.1 Byte Range requests.

<7> Section 2.2.4.2: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations 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.4: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations 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, Windows Server 2008, and Windows Server 2012 R2 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, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 implementations abort 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: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations 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 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 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 Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the update server receives such notifications from client computers when the ReportEventBatch method is called as part of the WUSP, as specified in [MS-WUSP]. Entries are added or modified when such notifications are received.

<18> Section 3.1.1: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the update server receives notifications from client computers when the ReportEventBatch method is called as part of the WUSP, as specified in [MS-WUSP]. Entries are added or modified when such notifications are received.

<19> Section 3.1.1: In Windows implementations, client computers notify the update server when they have successfully installed or failed to install an update. This is done using the WUSP (as specified in [MS-WUSP]).

<20> Section 3.1.1: In Windows 8 Windows Server 2012, and Windows Server 2012 R2, 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.

<21> Section 3.1.4.1.3.1: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, this field is not present.

<22> Section 3.1.4.1.3.3: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, this field is not present.

<23> Section 3.1.4.2: Windows implementations return an incorrect parameter name of machineName instead of accountName when the accountName parameter is invalid.

<24> 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.

<25> Section 3.1.4.4.3.1: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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.

<26> 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.

<27> Section 3.1.4.5: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the anchor is required to follow the format described in section 3.1.4.4, under the Windows behavior description for the NewConfigAnchor field.

<28> Section 3.1.4.5.3.1: All Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations set this to the anchor returned in the last successful GetRevisionIdList operation response.

<29> Section 3.1.4.6: All Windows implementations use XmlUpdateBlobCompressed if the size of the uncompressed XML metadata is more that 5,120 bytes.

<30> Section 3.1.4.6.3.5: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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.

<31> Section 3.1.4.6.3.5: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, this field is not present.

<32> Section 3.1.4.8: 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.

<33> Section 3.1.4.8: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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.

<34> Section 3.1.4.11: In Windows implementations, this value is always set to 5,000.

<35> Section 3.1.4.11: In Windows implementations, this value is always set to 1,500.

<36> Section 3.1.4.11: In Windows implementations, this value is always set to 20,000.

<37> Section 3.1.4.11: In Windows implementations, this value is always set to 500.

<38> Section 3.1.4.12: 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.

<39> Section 3.1.4.12.3.2: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations 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".

<40> Section 3.1.4.12.3.3: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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.

<41> Section 3.1.4.12.3.5: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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]).

<42> Section 3.1.4.13: 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.

<43> Section 3.1.4.13: 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.

<44> Section 3.1.4.13.3.2: In all Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the DSS will omit this field for a given client computer if none of the values have changed.

<45> Section 3.1.4.13.3.3: WSUS 3.0 SP1 sets this field to "Windows".

<46> Section 3.1.4.13.3.3: WSUS 3.0 SP1 sets this field to an empty string.

<47> Section 3.1.4.13.3.3: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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 WUSP (as 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.

<48> Section 3.1.4.15: In Windows implementations, the USS will do this if it is under extremely heavy load.

<49> 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.

<50> Section 3.2.3: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the fully qualified domain name (FQDN) of the USS is configured by the administrator using the WSUS administration UI.

<51> 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.

<52> 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 will wait until the response is received before aborting the protocol. If no call is currently in progress, the update server will abort the protocol immediately.

<53> Section 3.2.3: All Windows implementations provide an API through which other applications can trigger reporting data synchronization.

<54> Section 3.2.4.4: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, 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.

<55> Section 3.2.4.4: The Windows implementation does not batch multiple FileDigest values into a single call.

<56> Section 3.2.4.4: In Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implementations, the Background Intelligent Transfer Service (for more information, see [MSDN-BITS]) is used to perform the download.

<57> 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.

<58> 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.

<59> 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.

<60> Section 3.2.4.5: Windows implementations send the DownstreamServerInfo structures in batches, minimizing the number of requests required to send all the information.

<61> Section 3.2.4.5: Windows implementations send the ComputerRollupInfo structures in batches, minimizing the number of requests required to send all the information.

<62> Section 3.2.4.5: Windows implementations send the ComputerLastRollupNumber structures in batches, minimizing the number of requests required to send all the information.

<63> Section 3.2.4.5: Windows implementations send the ComputerStatusRollupInfo structures in batches, minimizing the number of requests required to send all the information.

<64> 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 aborted with a failure.

<65> Section 5.1: On Windows 2000 Server 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 Windows Server 2012 R2, 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 Windows Server 2012 R2, both the SHA-1 and SHA-256 hashes are required.

 
Show:
© 2015 Microsoft