Overall Compliance Reports for updates shows Unknown Status in System Center Configuration Manager


Overall Compliance Reports for updates shows Unknown Status in System Center Configuration Manager

 

Getting Unknown Status in Overall Compliance reports, is one of the most common issue many of us face while running the software update reports for compliance. The general troubleshooting what we do is to try send the state message again or troubleshoot the state message flow.

 

This is the simple state message resync script (VBS) we use

RefreshServerComplianceState()
Sub RefreshServerComplianceState()
dim newCCMUpdatesStore
set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
newCCMUpdatesStore.RefreshServerComplianceState
wscript.echo "Ran RefreshServerComplianceState."
End Sub

 

 

Even after this we still would have issues with few machines where we see that the state is unknown. So a good understanding of the state message which are a part of the report is required .

For Software updates reports we have the following state messages.

 

300    SUM_ASSIGNMENT_COMPLIANCE
301    SUM_ASSIGNMENT_ENFORCEMENT
302    SUM_ASSIGNMENT_EVALUATION
400    SUM_CI_DETECTION
401    SUM_CI_COMPLIANCE
402    SUM_CI_ENFORCEMENT
500    SUM_UPDATE_DETECTION
501    SUM_UPDATE_SOURCE_SCAN

 

Since we are talking about the Overall compliance report here the state message in question is 500-SUM_UPDATE_DETECTION.Further, State Message IDs are used to define specific state messages for each topic type. For example, a State Message for a Software Updates (Topic Type 500) would have the Status Message ID of 0, 1, 2 or 3 which would then depict the actual state of the given update on a client machine as below:

 

Topic Type State Message ID State Message Description
500 0 Detection state unknown
500 1 Update is not required
500 2 Update is required
500 3 Update is installed

 

A complete list of the Topic Type’s and State Message ID’s is listed in the below article: http://technet.microsoft.com/en-us/library/bb932203.aspx

 

When a client Scan against the wsus server the State Messages being raised. Every time a State Message is raised, we look in the WMI to see if a State Message for this Topic ID and Topic Type already exists. If it does, we overwrite the State Message in WMI with the new State. If it does not exist, we create a new instance and save the current State.

We store the state message in the WMI Namespace: root\CCM\StateMsg and WMI Class: CCM_StateMsg

If you look for a state message it will be something like this for type 500 it would look something like this.

 

Once this state messages reach the server it updates the following table in database dbo.Update_ComplianceStatus. Please note that though you have many updates in your ConfigMgr server database, you wont see the same number of 500 messages. Client will for sure send 500 for all the updates that is required and installed. And also for some not required one, which I have seen is for some common updates , office updates etc. But not required information for all not required updates when compared with your synced catalogue are not send from the client as a state message.

The calculation of the same is done on the server. To find the same I had looked at the RDL file for the compliance report and could see that it is picking up from the v_Update_ComplianceStatusAll. If you see this view it has information for all the four state for all the updates for each resource ID

But if you look at the base table dbo.Update_ComplianceStatus you will not find entries for 0 and 1 for status which you would see it in the v_Update_ComplianceStatusAll view

Now to understand from where it is building this information we had checked the view v_Update_ComplianceStatusAll

 

 

SELECT       ci.CI_ID, cm.ResourceID, ISNULL(cs.Status, CASE WHEN ss.ScanPackageVersion >= ci.MinSourceVersion THEN 1 ELSE 0 END) AS Status, ISNULL(cs.LastStatusCheckTime, ss.ScanTime)AS LastStatusCheckTime, cs.LastStatusChangeTime, cs.EnforcementSource, cs.LastEnforcementMessageID, cs.LastEnforcementMessageTime, cs.LastEnforcementStatusMsgID, cs.LastErrorCode,ISNULL(cs.LastLocalChangeTime, ss.LastLocalChangeTime) AS LastLocalChangeTime
FROM           dbo.v_UpdateCIs AS ci CROSS JOIN
dbo.v_ClientMachines AS cm LEFT OUTER JOIN
dbo.Update_ComplianceStatus AS cs ON cs.CI_ID = ci.CI_ID AND cs.MachineID = cm.ResourceID AND (cs.Status > 0 OR
ci.CIType_ID = 9) LEFT OUTER JOIN
dbo.Update_ScanStatus AS ss ON ss.MachineID = cm.ResourceID AND ss.UpdateSource_ID = ci.UpdateSource_ID

So The status is set based on this logic ISNULL(cs.Status, CASE WHEN ss.ScanPackageVersion >= ci.MinSourceVersion THEN 1 ELSE 0 END) .

Now it is clear that

  • First we will look the dbo.Update_ComplianceStatus and compare with dbo.v_UpdateCIs and whatever has Status in first table it was updated in the view's Status value (1,2 or 3).
  • Then we will look at dbo.Update_ScanStatus and check ScanPackageVersion and MinSourceVersion from dbo.v_UpdateCIs and then if ScanPackageVersion >= MinSourceVersion THEN 1 ELSE 0 for Status value.

So here, one more state message is important which is send from the client which is 501 for SUM_UPDATE_SOURCE_SCAN. If the client has send the failed message and if the ScanPackageVersion is not updated to the latest in the dbo.Update_ScanStatus then those updates which has ScanPackageVersion < MinSourceVersion will be set to "0" which means unknown status. We can get in to such issues when there is a Scan Failures or if after the successful synchronization the client is yet to send the Scan status.

So the Logic is the 501 state message has to be with the latest MinSourceVersion  and a with success message.

In few cases I could see that the software scan was successful but the driver scan had failed with a warning like below.  Though everything related to update deployment was working fine

WARNING: Sync of Drivers failed (Software succeeded): 0x8024402b

The 501 state message send by client had the error and the ScanPackageVersion was not updated and hence the clients were showing unknown status for Not required updates.

The same can also happen if the WSUS to which the client is scanning is in a lower version of MinSourceVersion  than the top server.

Hope this information will be useful

Sudheesh Narayanaswamy

This posting /Script  is provided "AS IS" with no warranties and confers no rights

Comments (0)

Skip to main content