Recently I worked on the reporting service of SCCM 2012. I noticed that some client did not jet report their Compliance state back to SCCM 2012. Because of demanding reports back to our security officers I needed a faster and better way to get the Compliance reports in order.
SCCM comes with a fairly extensive set of pre-configured reports to provide information about the state of your infrastructure. There are different types of reports to become familiar with, but the ones we care about here can be found under Monitoring\Reports\Software Updates A.
If you don’t see this in your environment, it’s likely you are either viewing a Site Server that is not set up with the Reporting Service Point role. If this role is set up on another Site Server in your environment, target the Admin Console there instead. If not, the following article goes through the process of setting up Reporting Services in your SCCM hierarchy: Configuring Reporting in Configuration Manager
What is the problem?
SCCM can only report what it knows, the way SCCM determines what should be in a report is through state messages sent by its managed devices. The state messaging system is fairly complicated.
The idea is that for some reason or other (network hiccup, etc.) the state messages relating to a particular compliance setting did not make it to the Site Server, which has resulted in the Compliance report showing inaccurate information. By default, state messages should be resent every 30 days from all managed devices so any issues detected should resolve themselves over time. But in practice, I have found that sometimes it’s necessary to give the state message system a jump-start in order to resolve the reporting discrepancy.
On my way to get a solution to this I came across a TechNet blog describing the above problem, the old fashion way to solve this issue is to use a VB script that forces the State Messaging system to report back to the SCCM Site Server. Also a problem with SCCM 2012 is that there is no official documentation available for publishing VBScript that run automatically on managed devices.. Of course you could make a scheduled task on every server. But if you mange several hundred or even thousands systems. That will be an impractical solution.
What about PowerShell??
When I search on the Internet I came across a small PowerShell script that does the job, the first poster that created this small script had only a two-line solution, So why not try it? right below you will find the script, save this as yourscripname.ps1
$SCCMUpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
New-EventLog -LogName Application -Source SyncStateScript -ErrorAction SilentlyContinue
Write-EventLog -LogName Application -Source SyncStateScript -EventId 555 -EntryType Information -Message "Sync State ran successfully"
The first two lines is where the actual action occur, these will force the managed device to report back to the SCCM site. the third and forth line will generate an event in your event viewer, that is the way you could view if your script run successfully.
You could also check out the UpdateStore.log file on your SCCM client log file folder:
Opening the log file after running the script, we should see the following:
Initiated refresh of update compliance to site server. UpdatesStore 2/23/2015 6:03:10 AM 7332 (0x1CA4)
Successfully called refresh of update compliance from automation object. UpdatesStore 2/23/2015 6:03:10 AM 13484 (0x34AC)
Message received to resend all update status, processing… UpdatesStore 2/23/2015 6:03:10 AM 14184 (0x3768)
Successfully raised Resync state message. UpdatesStore 2/23/2015 6:03:11 AM 14184 (0x3768)
Resend status completed successfully. UpdatesStore 2/23/2015 6:03:11 AM 14184 (0x3768)
If this information is found at the same time as the script has run, we can say with confidently that it has done what we asked. From here, the only thing left to do is verify the Compliance report is now reporting correct information, which can be easily done by re-running the report.
Creating a Package:
open your SCCM Admin Console and browse to: Software Library\Application Management\Packages and right-click the Packages node. Select Create Package and enter the following information
The first you need to enter some basic information the Wizzard will help you trough,
Name of your package.. I used ReSync Package – PowerShell
Enter your source directory (note that this source should be a network share and everyone permission need to be set as read)
On the next page, select ‘Standard Program’ (assuming we are using a client computer and not a device such as a Windows phone):
After selecting the Standard Program, we need to enter information on the script and how we want to run it. The following screen provides that detail
finish all other steps that the wizard require. I did not need to change any default settings in the package.
And deploy the package to your preferred device collection for testing.