Hi,

I've noticed that for some updates we have lots of computers that say in the web reports that they require the update, but when you look at the computer you find that the update was installed ages ago and that the computer has done several Software Update Evaluation Cycles since then installing other patches.

Why are some computers reporting some updates with incorrect states? I've examined their logs files and when they do a revaluation of software updates they correctly identify the update as installed but in the web report the status of the update is incorrect and normally has an old 'Last Status Message' date/time.

Any ideas?

Havent seen this have you opened a case with CSS ?

I am experiencing this as well. I have several devices that show on the deployment states reports as "Successfully Installed" but never compliant. Running a compliance report, I see that there is an update showing as missing. Looking at the device I see that the update was installed some time ago. I have a case open on this and so far, re-installing the update over the top does not work. Uninstalling and re-installing the update did not appear to work. On 3/31 we ran some script that was basically supposed to force it to resend the status messages from the device. Now looking at the device, the update that was an issue is now showing as installed, but there is another one that is suddenly showing as missing (but is actually installed) that was not before.

Could it be a corrupt WMI table or something? Is this information even stored in WMI?

Not yet but considering it ...

Fantastic! Someone else with the problem :)

Such an issue obviously makes reporting on compliance somewhat hard. If there is a discrepancy with the report saying that patches are required but are already installed, who is to say that it might report patches as installed but they really aren't!

Glad to know that you have opened up a support call. I'd be interested in knowing how things proceed if you wish to message me directly, maybe we can help each other.

I have tried myself re-running software updates evaluation schedules on the 'problem' computers but this is nigh useless as I can clearly see in the log files of the computer that it knows that the update is installed but nothing changes on the web report. My view is that the problem could be stale information in the SCCM database and not a problem of the computer. Well, that's my latest theory! It's either that or the client isn't updating it's own status messages correctly. Given that everything else with these problem computers seems to be ok with status messages, it leads me to believe the problem is in the SCCM database on the server.

I expect the information is stored in WMI as almost everything is. Certainly patch information is as I use 3rd party tools like SCCM Client Center to query patch status remotely and I believe that's WMI. However, I doubt status messages have anything to do with WMI on the client as they are more real-time than static. However, I could be completly wrong :)

Would you like to co-coperate on this?

Yes, you are not alone with this issue. We have the same problem. We have a script that runs to check compliance (web reports) on our computers. When those that show up, dont match the expected patching status, we kick off a software update eval . This usually fixes the issue. If that doesnt work, we just reinstall the agent. Lame huh. I hope someone finds a fix for this. We had a case opened. Wasted many hours with no answer

We just gave up as it isnt critical. I hope someone has the time to figure this one out.

I will definitely keep you posted via this thread. I would be willing to cooperate on this. As Czar_Log posted later in the thread though, this is kind of a low priorty nuisance, but since we have the call opened I'll continue to work on it as long as we work toward an answer.

OK, thanks. I'll stay subscribed to this thread and await updates from you :) If you want to email me direct about this topic then please feel free. I think you can do this via the forums.

I have a similar problem. When I run the "Compliance 1 - Overall Compliance" report I see updates in the report that are not part of the Update List. I went to the Update List and did a search and did not find any of the updates that are showing in the report. I went ahead and created another update list and ran the report against that "newly" created update list and the same collection and I am still showing "office updates" in the report. The update list only contains "Windows XP and Windows 2000" updates.

Any help would be greatly appreciated.

Were you able to get an answer from MS as to why the SUP reports are incorrect? I'm finding this out now as part of an audit I'm doing after a round of server patching.

I'm having the exact same issue that you have described.  I've just begun to evaluate this problem as we are being asked to provide compliance numbers for an audit. 

Were you able to resolve the conflicting reports?  If so, I'd really appreciate your resolution. 

I'm having the exact same issue that you have described.  I've just begun to evaluate this problem as we are being asked to provide compliance numbers for an audit. 

Were you able to resolve the conflicting reports?  If so, I'd really appreciate your resolution. 

I have used the below script to fix it.  Apparently clients will occassionally not report their full compliance.

http://t3chn1ck.wordpress.com/2010/01/11/fix-sccm-client-scan-state/

Yup, I used the same thing. Worked a treat!
Forgot to post that :(

I have try the scripts .But the client still shown not compliance. I checked the statemessage.log :-

Successfully forwarded State Messages to the MP]LOG]!.....

I have checked add/remove program already installed the patches.

 

Hi guys,

 

same problem here. The script fixed it for some machines, but not all of them. It does for example not run on x64 machines.

By the way I created a collection based on the following query to check for machines that did not send their state messages for some time.

#---------------------

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_PatchStatusEx on SMS_G_System_PatchStatusEx.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_PatchStatusEx.LastStateName = "Reboot pending" and SMS_R_System.Client = 1 and SMS_G_System_PatchStatusEx.LastStatusTime <= SMS_G_System_OPERATING_SYSTEM.LastBootUpTime

#---------------------

If found the query in another forum.

Still I'm also having the problem on machines that do send their status messages :(

We have the same problem, the script will resolve some machines, but there are others that still report patches are missing even though you have touched the machine, spending 30 minutes to validate that the patch is REALLY installed but the reporting says it's not.   

When you are working with 1000's of systems, hundreds of machines innaccurately reporting compliance is not something you want to try and explain to upper management.

Heya Folks,

Just thought i might provides some insight...

Few things to check in situations listed above:

1)

The Management point DNS record should be FQDN if the Management point is in another domain

E.g.

http://<mpservername>/sms_mp/.sms_aut?mplist   ----> is incorrect for cross domain

http://<mpservername.domainname.com>/sms_mp/.sms_aut?mplist ----> will work....

ccmexec.log will have a lot of name resolution errrors in this case.  Add entries in HOST file/DNS for FQDN and Netbios name (One entry each)

2)

During initial set-up you can use a WSUS server that was already active in your environment, but client computers connecting to the WSUS server will scan for all software updates in the WSUS database. This might result in client computers returning compliance state information for software updates outside of the configured classifications, categories, and languages. Before using an existing WSUS server as an active software update point site system, it is recommended that the software updates metadata is deleted from the WSUS database if possible. The WSUS server will be synchronized with new software updates metadata based on the settings configured for the active software update point.

3) 

WMI curruption -- When it comes to Software Update, ‘State Messages’ are key elements. When state messages are received two things happen – first, state messages are stored in WMI.  Then, on a 15 minute cycle (Default) the state system will empty WMI for any state message that has not yet been sent and forward up to the Management Point. So if WMI fails SCCM reporting fails.

4)

Finally check if all the SUP - Software Update Points are taking their updates from the same WSUS server.. Sometimes WSUS server configurations could  be different. Use GPEDIT.MSC/ADMINISTRATIVE TEMPLATE/WINDOWS COMPONENTS/WINDOWS UPDATE and see if the intranet WSUS server entries are correct....

Remember: The final compliance is all state messages its either '2' for Applicable but Not installed or '3' for is installed...So if the patch is installed but the state has not made its way up the chain to the central server...

Check WSUS server as mentioned above

Check WMI

Check Name resolution - Add entries in HOST file/DNS for FQDN and Netbios name

Telnet to the WSUS server port and see if it responds (8530 or 8531 - SSL) for default installation 

Topaz Paul

topazcaleb@gmail.com

• Edited by Topaz Paul Thursday, October 20, 2011 1:56 AM

Heya Folks,

Just thought i might provides some insight...

Few things to check in situations listed above:

1)

The Management point DNS record should be FQDN if the Management point is in another domain

E.g.

http://<mpservername>/sms_mp/.sms_aut?mplist   ----> is incorrect for cross domain

http://<mpservername.domainname.com>/sms_mp/.sms_aut?mplist ----> will work....

ccmexec.log will have a lot of name resolution errrors in this case.  Add entries in HOST file/DNS for FQDN and Netbios name (One entry each)

2)

During initial set-up you can use a WSUS server that was already active in your environment, but client computers connecting to the WSUS server will scan for all software updates in the WSUS database. This might result in client computers returning compliance state information for software updates outside of the configured classifications, categories, and languages. Before using an existing WSUS server as an active software update point site system, it is recommended that the software updates metadata is deleted from the WSUS database if possible. The WSUS server will be synchronized with new software updates metadata based on the settings configured for the active software update point.

3) 

WMI curruption -- When it comes to Software Update, ‘State Messages’ are key elements. When state messages are received two things happen – first, state messages are stored in WMI.  Then, on a 15 minute cycle (Default) the state system will empty WMI for any state message that has not yet been sent and forward up to the Management Point. So if WMI fails SCCM reporting fails.

4)

Finally check if all the SUP - Software Update Points are taking their updates from the same WSUS server.. Sometimes WSUS server configurations could  be different. Use GPEDIT.MSC/ADMINISTRATIVE TEMPLATE/WINDOWS COMPONENTS/WINDOWS UPDATE and see if the intranet WSUS server entries are correct....

Remember: The final compliance is all state messages its either '2' for Applicable but Not installed or '3' for is installed...So if the patch is installed but the state has not made its way up the chain to the central server...

Check WSUS server as mentioned above

Check WMI

Check Name resolution - Add entries in HOST file/DNS for FQDN and Netbios name

Telnet to the WSUS server port and see if it responds (8530 or 8531 - SSL) for default installation 

Topaz Paul

topazcaleb@gmail.com

• Edited by Topaz Paul Thursday, October 20, 2011 1:56 AM

Heya Folks,

Just thought i might provides some insight...

Few things to check in situations listed above:

1)

The Management point DNS record should be FQDN if the Management point is in another domain

E.g.

http://<mpservername>/sms_mp/.sms_aut?mplist   ----> is incorrect for cross domain

http://<mpservername.domainname.com>/sms_mp/.sms_aut?mplist ----> will work....

ccmexec.log will have a lot of name resolution errrors in this case.  Add entries in HOST file/DNS for FQDN and Netbios name (One entry each)

2)

During initial set-up you can use a WSUS server that was already active in your environment, but client computers connecting to the WSUS server will scan for all software updates in the WSUS database. This might result in client computers returning compliance state information for software updates outside of the configured classifications, categories, and languages. Before using an existing WSUS server as an active software update point site system, it is recommended that the software updates metadata is deleted from the WSUS database if possible. The WSUS server will be synchronized with new software updates metadata based on the settings configured for the active software update point.

3) 

WMI curruption -- When it comes to Software Update, ‘State Messages’ are key elements. When state messages are received two things happen – first, state messages are stored in WMI.  Then, on a 15 minute cycle (Default) the state system will empty WMI for any state message that has not yet been sent and forward up to the Management Point. So if WMI fails SCCM reporting fails.

4)

Finally check if all the SUP - Software Update Points are taking their updates from the same WSUS server.. Sometimes WSUS server configurations could  be different. Use GPEDIT.MSC/ADMINISTRATIVE TEMPLATE/WINDOWS COMPONENTS/WINDOWS UPDATE and see if the intranet WSUS server entries are correct....

Remember: The final compliance is all state messages its either '2' for Applicable but Not installed or '3' for is installed...So if the patch is installed but the state has not made its way up the chain to the central server...

Check WSUS server as mentioned above

Check WMI

Check Name resolution - Add entries in HOST file/DNS for FQDN and Netbios name

Telnet to the WSUS server port and see if it responds (8530 or 8531 - SSL) for default installation 

Topaz Paul

topazcaleb@gmail.com

• Edited by Topaz Paul Thursday, October 20, 2011 1:56 AM

I have been investigating this same issue this week,

so far I am having success after I installed the wmi stability hotfix + reboot, then after a while I would get the correct compliancy result for these clients.

2003+XPx64: kb933061
XP: kb933062
Vista/server 2008: which one is it?
Server 2008 R2/W7: 981314 + 977357 + 2465990 (SP1)

fyi: check also http://ccmexec.com/2011/08/suggested-hotfixes-for-wmi-related-issue-on-windows-platforms/#comments

Hi everyone.

I have used this script to repair and fix the issue on Windows Server 2003.

However, has anyone been able to correct and fix the problem on Windows Server 2008 or on x64 OS?

I am hesitant to proceed with WMI Hotfixes as the problem I have having is not specifically listed in any of the hotfixes.

Thanks in advance for anyone who can help me with this. We have 300 + servers that we manage and about 12 are causing issues on our compliance reports.

I have a few machines with the same issue. I can confirm that the updates are installed but on the report it shows differently. I was able to successfully fix the report by performing a Policy Hard-Reset. I used the "SCCM Client Center" version 2.0.3.0 by Roger Zander to connect to the client, then select Client Actions - Reset Policy (Hard-Reset). After running this command, it will take a while for the report to change. First, the report will go blank, then it will re-populate again. Hope this helps some of you!

I have a similar problem. When I run the "Compliance 1 - Overall Compliance" report I see updates in the report that are not part of the Update List. I went to the Update List and did a search and did not find any of the updates that are showing in the report. I went ahead and created another update list and ran the report against that "newly" created update list and the same collection and I am still showing "office updates" in the report. The update list only contains "Windows XP and Windows 2000" updates.

Any help would be greatly appreciated.

This is still a problem in SCCM 2012 R2!

I run the Compliance 1 - Overall Compliance" report and drill down to a non-compliant or compliant systems and they display updates that aren't even in the Software Update Group!