A couple of random thoughts; could be none of them, could be a combination of all of them...
- State Messages lost in transmission. - State messages made it from the client to the MP; but malformed, and rejected. Suggestion #1) add a time constraint to the query; so that you only want boxes with lastmessageid=9 within the last 30 days--this is assuming you have a companion process where you look for machines that haven't been rebooted in 30 days, and reboot them. (dual checks; you only care about lastmessageid=9 within last 30 days... because you are having everyone reboot within the last 30 days anyway, regardless of something needing it) Suggestion #2) Since State messages can be easily malformed/lost; our PFE told us a while ago that every 6 months or so you'll want to have every box do a State Message Reset--I do this for a week; then off again for 6 months. That catches most boxes. I happen to use a DCM; because it's just a script in the CI, and I assign it for a week to about 1/7th of the boxes on Day 1, next set Day 2 (so that we don't get a state message backlog). The Baseline, the "recurrance" is every 31 days (because I really only want it to run once) But you could use a traditional package/program/advert. Sherry Kissinger Microsoft MVP - ConfigMgr [email protected] ________________________________ From: "[email protected]" <[email protected]> To: [email protected] Sent: Monday, July 22, 2013 8:13 AM Subject: [mssms] RE: Software Update Reboot Pending Query Oddities on CM2012 Bump… anyone? From:[email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, July 19, 2013 12:23 PM To: [email protected] Subject: [mssms] Software Update Reboot Pending Query Oddities on CM2012 Hello All, I have a query that I had previously used in CM2007 and am now using on CM2012 to determine when a system has one or more updates reporting as requiring a reboot. The query syntax is below: select distinct SMS_R_System.Name, SMS_R_System.description, SMS_R_System.LastLogonUserName, SMS_G_System_SYSTEM_CONSOLE_USAGE.TopConsoleUser, SMS_G_System_OPERATING_SYSTEM.Caption, SMS_G_System_COMPUTER_SYSTEM.Model, SMS_G_System_WORKSTATION_STATUS.LastHardwareScan, SMS_R_System.LastLogonTimestamp from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_SYSTEM_CONSOLE_USAGE on SMS_G_System_SYSTEM_CONSOLE_USAGE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID = SMS_R_System.ResourceId inner join SMS_UpdateComplianceStatus on SMS_UpdateComplianceStatus.machineid=sms_r_system.resourceid where SMS_UpdateComplianceStatus.LastEnforcementMessageID = 9 order by SMS_R_System.Name This query appears to function as intended. However, today I received a report from a user that stated they rebooted their system a week ago, yet that system was still on the report. I then made a second query to pull back the details of all updates that were flagged as requiring reboot: select distinct SMS_R_System.Name, SMS_R_System.description, SMS_G_System_SYSTEM_CONSOLE_USAGE.TopConsoleUser, SMS_R_System.LastLogonUserName, SMS_G_System_OPERATING_SYSTEM.Caption, SMS_G_System_COMPUTER_SYSTEM.Model, SMS_G_System_WORKSTATION_STATUS.LastHardwareScan, SMS_R_System.LastLogonTimestamp, SMS_UpdateComplianceStatus.LocalizedDisplayName, SMS_UpdateComplianceStatus.LastStatusCheckTime, SMS_UpdateComplianceStatus.LastStatusChangeTime from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_SYSTEM_CONSOLE_USAGE on SMS_G_System_SYSTEM_CONSOLE_USAGE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID = SMS_R_System.ResourceId inner join SMS_UpdateComplianceStatus on SMS_UpdateComplianceStatus.machineid=sms_r_system.resourceid where SMS_UpdateComplianceStatus.LastEnforcementMessageID = 9 order by SMS_R_System.Name That’s when I began noticing the oddities. The system in question was reporting back an update needed a reboot that was issued in February 2013. Stranger still, the last status check time for the update was in April, and the last status change time wasy from March. And finally, when I checked the update status of that system using the canned CM2012 compliance report, the update showed as *installed*. Looking at the status timestamps on numerous other systems often also shows their last communication as more than a month ago. I know these systems are on the network and communicating daily. Any thoughts as to what might be going on here? Is there a better way for me to report on pending reboots for software updates in 2012? I’m concerned I can’t trust the validity of this query anymore, and I don’t want to chastise people for not rebooting their systems (or forcibly reboot them) if I’m not 100% confident of the data I’m getting. Thanks in advance, Andrew ________________________________ This e-mail is intended only for the person or entity to whom it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the original message and all copies from your system. Statements and representations made in this message are not necessarily that of the Company. ________________________________ This e-mail is intended only for the person or entity to whom it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the original message and all copies from your system. Statements and representations made in this message are not necessarily that of the Company.
