Patch Compliance Reporting Discrepancies On Re-released Update
MS09-043 was first released in August 2009. The patch was then re-released in November 2009. The patch code did not change, but its detection method did. The patch in the MS09-043 bundle that got superseded is KB947319. My customer ran a compliance report for MS09-043 and it showed that no clients need it. They also ran Configuration Manager built-in report 170 and it showed that MS09-043 was applicable to about 60 clients. We determined that the re-release of MS09-043 created two state messages for KB947319, one with the retired detection method and one with the new detection method. The record created with the old detection method was creating the discrepancies in the reports. Since the new detection method reported that the patch is not required, we could delete the obsolete compliance state record for KB947319. We troubleshot one of the client in the reports and also ran a number of queries on the SCCM database to determine the source of the discrepancy:
1. We ran this query to get the resource ID for the machine we were troubleshooting.
select * from system_disc where name0=’machine name’
Let say the machine ID was 123456.
2. We then ran this query to get the CI_IDs of the patches included in MS09-043.
select * from v_updateinfo where BulletinID='ms09-043'
We determined that there were two records for KB947319. In this case CI_ID 61457 was for the old superseded patch and it showed a status of 2, update required. CI_ID 67532 was for the current KB947319 patch and it showed a status of 1, not required.
3. To identify the record with the obsolete data, we ran:
select * from Update_ComplianceStatus where machineid=123456 and CI_ID=61457
Only one record was returned, so we changed the SQL statement to:
delete from Update_ComplianceStatus where machineid=123456 and CI_ID=61457
That deleted the obsolete scan status data for KB947319 for the client we were troubleshooting and the client on longer showed up on report 170.
4. To fix the other 59 clients that were showing the same discrepancy we ran:
delete from Update_ComplianceStatus where CI_ID=61457
The CI_IDs referenced above are unique per site and they are here for illustration purposes only. Microsoft does not support the direct manipulation of the Configuration Manager database. The above steps were taken after performing a Configuration Manager backup and under my guidance.