3.4 Example 4: Differential Update Synchronization to Update Client
The goal of this example is for a particular update client to synchronize update metadata and deployments from a particular update server after having already synchronized at a previous point in time. In this case, the update client has cached data from previous synchronizations with the update server, which it uses to optimize the synchronization. This example is part of the Start Update Scan use case. This scenario supports the use case described in section 2.5.3.7.
The scenario described in this example can initiated on a schedule by an automated agent, or by a user by means of a client management tool. After this scenario occurs successfully, the update client has synchronized update metadata and deployment and can cache this data to make subsequent synchronizations faster.
The following sequence diagram illustrates the interactions between client and server during this scenario.

Figure 10: Sequence diagram for differential update synchronization to an update client
This sequence diagram assumes that the client has a valid authorization cookie from a previous synchronization.
This message sequence is as follows:
(Optional) The update client makes a series of HTTP GET requests to determine the availability of applicable update client software. If so, it downloads the software using HTTP GET requests and updates itself. The message details are specified in [MS-WUSP] section 3.1.5.1.<3>
A differential update synchronization is less likely to find applicable update client software if a previous update synchronization was performed recently.The update client sends a SyncUpdates message, specified in [MS-WUSP] section 3.1.5.3 for updates to the update server, which responds with update information. There can be multiple iterations of this message and response.
The update client sends a SyncUpdates message for drivers to the update server, which responds with the driver update information.
If updates are determined to be applicable, the update client sends a GetExtendedUpdateInfo message to the server, which responds with extended update information. Message details are specified in [MS-WUSP] section 3.1.5.9.
If the client determines that additional data, such as a decryption key, is required for the update, the client sends a GetExtendedUpdateInfo2 message to the server, which responds with the extended update information for each of the new updates. Message details are specified in [MS-WUSP] section 2.2.2.2.10.
If there is a new update, the message GetFileLocations will be sent to get the new FileLocation information. The message details are specified in [MS-WUSP] section 3.1.5.10.
The update client sends a ReportEventBatch message to the update server, which responds with the status. Message details are specified in [MS-WUSP] section 3.1.5.11.
Note In addition to the messages shown in the diagram, a client implementation can send the messages GetAuthorizationCookie and GetCookie ([MS-WUSP] section 3.1.5.3 and section 3.1.5.4 respectively) at any time during the message sequence to request or renew a cookie. These messages are sent either because a cookie has expired or because a fault has occurred. See [MS-WUSP] section 2.2.2.4 for information on faults.