Compartilhar via

3.2.4.5 Reporting Data Synchronization

  • Artigo

The DSS reports information on its descendant DSSs and their client computers to the USS during this step. This step is performed only if both the USS and the DSS support version 1.3 or higher of the protocol.

This step MAY<70> run before or in parallel with the Content Synchronization step. Also, this step MAY be triggered and run on its own without running the previous steps in the protocol.

The DSS MUST send information on its descendant DSSs and their client computers to the USS as follows:

  1. The DSS sends a GetRollupConfiguration request to obtain information on the USS's report rollup requirements. The request message is composed as follows:

    • cookie: Set to a Cookie structure with the following fields:

      1. Expiration (Year-Month-Date Hours:Minutes:Seconds) = 9999-12-31 23:59:59.9999999

      2. EncryptedData = zero length array

    The response is stored for use in the steps that follow.

  2. The DSS reports information on itself and any descendant DSSs to the USS as follows:

    1. The DSS constructs a DownstreamServerInfo structure representing itself, as follows:

      1. ServerId: The self-generated GUID identifying the DSS.

      2. FullDomainName: The FQDN of the DSS.

      3. LastRollupTime: The current time.

      4. ParentServerId: "00000000-0000-0000-0000-000000000000".

      5. IsReplica: TRUE if the DSS is configured as a replica server; otherwise, false.

      6. LastSyncTime: The LastSyncTime value from the Server State Table. If the value in the table is NULL, use 1753-01-01 00:00:00 (Year-Month-Date Hours:Minutes:Seconds).

      7. ServerSummary: Set to a DownstreamServerRollupServerSummary structure describing the status of updates on the DSS, and of client computers that get updates from the DSS. The member fields are set as follows:

        1. UpdateCount: The number of unique UpdateIdentity GUID values in the Revision Table (the Revision Number portion is ignored).

        2. DeclinedUpdateCount: The number of unique UpdateIdentity GUID values in the Revision Table, for which all entries with that UpdateIdentity GUID have the Hidden element set to TRUE.

        3. ApprovedUpdateCount: The number of unique UpdateIdentity GUID values in the Revision Table, for which at least one entry with that UpdateIdentity GUID has the Hidden element set to FALSE, and at least one entry in the Deployment Table has a matching UpdateIdentity GUID and an Action value of 0.

        4. NotApprovedUpdateCount: The number of unique UpdateIdentity GUID values in the Revision Table, for which at least one entry with that UpdateIdentity GUID has the Hidden element set to FALSE and no entry in the Deployment Table has a matching UpdateIdentity GUID and an Action value of 0.

        5. ApprovedUpdateCount: The number of entries in the Revision Table for which:

          1. At least one entry with that UpdateIdentity GUID has the Hidden element set to FALSE.

          2. At least one other entry in the Revision Table has the same UpdateIdentity GUID but a larger UpdateIdentity Revision Number.

          3. An entry in the Deployment Table has the same UpdateIdentity value and an Action value of 0.

        6. CriticalOrSecurityUpdatesNotApprovedForInstallCount: The number of unique UpdateIdentity GUID values in the Revision Table, for which:

          1. At least one entry with that UpdateIdentity GUID has the Hidden element set to FALSE.

          2. There is no entry in the Deployment Table with a matching UpdateIdentity GUID and an Action value of 0.

          3. The update that this entry represents is intended to repair a security issue on the client computers, or is otherwise considered to be critical to the operation of the client computers. How this determination is made is implementation-dependent.<71>

        7. WsusInfrastructureUpdatesNotApprovedForInstallCount: The number of unique UpdateIdentity GUID values in the Revision Table, for which:

          1. At least one entry with that UpdateIdentity GUID has the Hidden element set to FALSE.

          2. There is no entry in the Deployment Table with a matching UpdateIdentity GUID and an Action value of 0.

          3. The update that this entry represents is required for the client computers to continue to get updates from this DSS. How this determination is made is implementation dependent.<72>

        8. CustomComputerTargetGroupCount: The number of entries in the TargetGroup Table for which the IsBuiltin value is FALSE.

        9. UpdatesWithClientErrorsCount: The number of updates available on the DSS that at least one client computer has attempted and failed to install.

        10. UpdatesWithServerErrorsCount: The number of updates available on the DSS for which the DSS has failed to download content.

        11. UpdatesNeedingFilesCount: The number of updates for which the DSS downloads content but has not completed the download.

        12. UpdatesNeededByComputersCount: The number of updates available on the DSS to which at least one client computer is applicable but not yet installed on.

        13. UpdatesUpToDateCount: The number of updates available on the DSS known to be installed on all client computers to which it is applicable.

        14. ComputerTargetCount: The number of client computers that gets updates from this DSS.

        15. ComputerTargetsNeedingUpdatesCount: The number of client computers that gets updates from this DSS on which at least one update is known to be applicable but not yet installed.

        16. ComputerTargetsWithUpdateErrorsCount: The number of client computers that gets updates from this DSS and that has tried and failed to install at least one update.

        17. ComputersUpToDateCount: The number of client computers that is known to have successfully installed all updates available on this DSS that are applicable to it.

        The values for steps 2.1.7.9–2.1.7.17 are all computed from the values stored in the Revision Table, Deployment Table, and Update Status Table.

      8. ClientSummary: Set to an array of DownstreamServerRollupClientSummary structures. The array is populated by constructing one DownstreamServerRollupClientSummary structure for each entry in the Client Computer Activity Summary Table with a ServerID value equal to the GUID identifying this DSS.

        The fields of the structure are populated by copying the corresponding values from the table entry.

    2. The DSS constructs a list of DownstreamServerInfo structures, one for each entry in the DSS Table. The list MUST be ordered such that if one DSS synchronizes with another, the structure corresponding to the parent DSS appears before that of the child DSS.

      The fields in the DownstreamServerInfo structures are initialized using values from the corresponding DSS Table entry.

      The ClientSummary array is populated by searching the Client Computer Activity Summary Table for entries with a ServerID value matching the ServerID from the DSS Table entry, and then constructing a DownstreamServerRollupClientSummary for each such entry by copying the values from the table entry.

    3. The DSS appends the DownstreamServerInfo structure from step 1 to the end of the list constructed in step 2.

    4. If the number of DownstreamServerRollupClientSummary structures in any one member of the resulting list is greater than the RollupDownstreamServersMaxBatchSize value received from the USS in step 1, split the offending DownstreamServerInfo structure into two or more structures as follows:

      1. Split the ClientSummary array of the original DownstreamServerInfo structure into two or more subarrays, each containing at least one member, such that the number of DownstreamServerRollupClientSummary structures in any one subarray does not exceed the RollupDownstreamServersMaxBatchSize value from step 1.

      2. For each subarray, construct a new DownstreamServerInfo structure. All fields in this structure, excluding the ClientSummary array, are set to the value of the corresponding field in the original DownstreamServerInfo structure. The ClientSummary array is set to the subarray created in step 4.1.

      3. Remove the original DownstreamServerInfo structure from the list, and insert the new DownstreamServerInfo structures created in step 3 in its place.

    5. The DSS sends the DownstreamServerInfo structures to the USS using RollupDownstreamServers messages. Each request is composed as follows:

      1. cookie: Set to a Cookie structure with the following fields:

        1. Expiration (Year-Month-Date Hours:Minutes:Seconds) = 9999-12-31 23:59:59.9999999

        2. EncryptedData = zero length array

      2. clientTime: Set to the current time.

      3. downstreamServers: Populate the array using one or more DownstreamServerInfo structures from the list.

        An implementation can send the DownstreamServerInfo structures one at a time, or it can send them in batches. In either case, ordering MUST be preserved.

        Example: If structure A appears before structure B in the list, the request containing structure B MUST NOT be sent before the request containing structure A is sent. They MAY be sent in the same request; however, in this example, structure A MUST appear before structure B in the downstreamServers array.

        Furthermore, the number of DownstreamServerRollupClientSummary structures in one request, summed across all DownstreamServerInfo structures in the request, MUST NOT exceed the RollupDownstreamServersMaxBatchSize value.<73>

        For each RollupDownstreamServers request sent, the USS responds with a RollupDownstreamServers message. Upon receiving this response, the DSS removes from the Client Activity Summary Table all rows corresponding to the ServerID values that were sent as part of the request.

  3. If the DoDetailedRollup value from the GetRollupConfigurationResponse structure (received from the USS in step 1) is FALSE, stop. The following steps in the protocol MUST NOT be run. If the value is TRUE, continue.

  4. The DSS reports information on client computers that get updates from it or from any of its descendant DSSs as follows:

    1. For each entry in the Client Computers Table, the DSS constructs a ComputerRollupInfo structure, populating the fields as follows:

      1. ComputerId, LastSyncTime, LastSyncResult, LastReportedRebootTime, LastReportedStatusTime, LastInventoryTime, and ParentServerId: Use the corresponding value from the table entry. If a time stamp value in the table is NULL, use 1753-01-01 00:00:00 (Year-Month-Date Hours:Minutes:Seconds) instead.

      2. The Details field MUST NOT be added if the HasDetailsChanged element of the table entry is FALSE. If the HasDetailsChanged element is TRUE, the Details field MUST be populated as follows:

        TargetGroupIdList, RequestedTargetGroupNames, IPAddress, FullDomainName, OSMajorVersion, OSMinorVersion, OSBuildNumber, OSServicePackMajorNumber, OSServicePackMinorNumber, OSLocale, ComputerMake, ComputerModel, BiosVersion, BiosName, BiosReleaseDate, ProcessorArchitecture, SuiteMask, OldProductType, NewProductType, SystemMetrics, and ClientVersion: Use the corresponding value from the table entry.

    2. The DSS sends the ComputerRollupInfo structures to the USS using RollupComputers messages. Each request is composed as follows:

      1. cookie: Set to a Cookie structure with the following fields:

        1. Expiration (Year-Month-Date Hours:Minutes:Seconds) = 9999-12-31 23:59:59.9999999

        2. EncryptedData = zero length array

      2. clientTime: Set to the current time.

      3. computers: Populate the array using one or more of the ComputerRollupInfo structures.

        An implementation MAY send the ComputerRollupInfo structures one at a time, or it MAY send them in batches. If the implementation chooses to send them in batches, the number of ComputerRollupInfo structures sent in a single request MUST NOT exceed the RollupComputersMaxBatchSize value obtained from the GetRollupConfigurationResponse.<74>

        For each RollupComputers message sent, the USS responds with a RollupComputersResponse message, with the RollupComputersResult field set to an array of zero or more ChangedComputer structures. The DSS MUST process each ChangedComputer structure in each response as follows:

      4. If the value of the Change field is deleted, get the ComputerId value from the ChangedComputer structure, find the entry in the Client Computers Table with the matching ComputerId value, and remove it from the table.

        If the entry is not found in the table, do nothing.

      5. If the value of the Change field is NewParent, get the ComputerId value from the ChangedComputer structure, find the entry in the Client Computers Table with the matching ComputerId value, and set the HasDetailsChanged value to TRUE.

        If the entry is not found in the table, do nothing.

    3. Repeat step 4.1, but only for entries in the Client Computers Table having a HasDetailsChanged value of TRUE. Repeat step 4.2, using the resulting list of ComputerRollupInfo structures; repeat step 4.3 for the resulting responses.

  5. The DSS reports the status of each update on each client computer to the USS as follows:

    1. For each entry in the Client Computers Table, the DSS constructs a ComputerLastRollupNumber structure, populating the fields as follows:

      1. ComputerId: Use the ComputerId value from the table entry.

      2. RollupNumber: Use the LastSentStatusRollupNumber value from the table entry.

    2. For client computers that have reported their status, the DSS MUST send the ComputerLastRollupNumber structures to the USS using GetOutOfSyncComputers messages. This message is only sent when the DSS is aware of computers that are potentially out of sync. If no clients have reported their status, the implementation MAY skip this step.

      Each request is composed as follows:

      1. cookie: Set to a Cookie structure with the following fields:

        • Expiration (Year-Month-Date Hours:Minutes:Seconds) = 9999-12-31 23:59:59.9999999

        • EncryptedData = zero length array

      2. parentServerId: Set to the ServerID value from the Server Configuration Table.

      3. lastRollupNumbers: Populate the array using one or more of the ComputerLastRollupNumber structures.

        An implementation MAY send the ComputerLastRollupNumber structures one at a time, or it MAY send them in batches. If the implementation chooses to send them in batches, the number of ComputerLastRollupNumber structures sent in a single request MUST NOT exceed the GetOutOfSyncComputersMaxBatchSize value obtained from the GetRollupConfigurationResponse.<75>

        For each GetOutOfSyncComputers message sent, the USS responds with a GetOutOfSyncComputersResponse message with the GetOutOfSyncComputersResult field set to an array of zero or more strings, each identifying a client computer.

        For each string, the DSS MUST search the Client Computers Table for an entry with the matching ComputerId value. If an entry is found, set the LastStatusRollupTime to NULL. If no entry is found, do nothing.

    3. For each entry in the Client Computers Table, the DSS constructs a ComputerStatusRollupInfo structure, populating the fields as follows:

      1. InstanceId: Set to a new, randomly generated GUID.

      2. ComputerId: Set to the ComputerId value from the table entry.

      3. EffectiveLastDetectionTime: Search the Synchronization History Table for the row with the largest SynchronizationTime value that is less than the EffectiveLastDetectionTime value from the Client Computers Table row. If such a row is found, then use the SynchronizationTime value from that row; if no row is found, use 1753-01-01 00:00:00 (Year-Month-Date Hours:Minutes:Seconds).

      4. RollupNumber: Use the LastSentStatusRollupNumber value from the table entry, plus 1.

      5. IsFullRollup: If the LastStatusRollupTime value is NULL, set this to TRUE; else set this to FALSE.

      6. UpdateStatus: If the LastStatusRollupTime value is NULL, find all entries in the Update Status Table with a ComputerId value matching the ComputerId value from the Client Computer Table entry. If the LastStatusRollupTime value is not NULL, find all matching Update Status Table entries having a LastChangeTime value greater than the LastStatusRollupTime.

        For each entry, construct a ComputerStatusRollupUpdateStatus structure as follows. Set this field to an array containing the resulting ComputerStatusRollupUpdateStatus structures:

      7. UpdateId: Set to the UpdateID value from the Update Status Table entry.

      8. SummarizationState: Set to the State value from the Update Status Table entry.

      9. LastChangeTime: Set to the LastChangeTime value from the Update Status Table entry.

    4. The DSS sends the ComputerStatusRollupInfo structures to the USS using RollupComputerStatus messages. Each request is composed as follows:

      1. cookie: Set to a Cookie structure with the following fields:

        1. Expiration (Year-Month-Date Hours:Minutes:Seconds) = 9999-12-31 23:59:59.9999999

        2. EncryptedData = zero length array

      2. clientTime: Set to the current time.

      3. parentServerId: Set to the ServerID value from the Server Configuration Table.

      4. computers: Populate the array using one or more of the ComputerStatusRollupInfo structures.

        An implementation MAY send the ComputerStatusRollupInfo structures one at a time, or it MAY<76> send them in batches. If the implementation chooses to send them in batches, the number of ComputerStatusRollupInfo structures sent in a single request MUST NOT exceed the RollupComputerStatusMaxBatchSize value obtained from the GetRollupConfigurationResponse.

        For each RollupComputerStatus message sent, the USS responds with a RollupComputerStatusResponse message, each containing a Boolean RollupComputerStatusResult value.

        If the RollupComputerStatusResult value is FALSE, this indicates that the USS was too busy to accept the request, and the DSS MUST wait at least 1 minute before sending another request. The DSS MAY resend the same request (with the clientTime value updated to reflect the current time) after waiting.<77>

        If the RollupComputerStatusResult value is TRUE, this indicates that the USS successfully received the message. For each ComputerStatusRollupInfo structure that was sent as part of the request, the DSS MUST find the corresponding entry in the Client Computers Table and update the entry as follows:

      5. LastStatusRollupTime: Search the UpdateStatus array in the ComputerStatusRollupInfo structure for the entry with the largest LastChangeTime, and use this LastChangeTime.

      6. LastSentStatusRollupNumber: Set to the current LastSentStatusRollupNumber, plus 1.