none
Inaccurate Compliance Reporting in SCCM 2007 and 2012 with non-SP1 2008 R2 servers RRS feed

  • Question

  • Note: This is a duplicate thread as posted here, but this relates to SCCM 2012 compliance reporting as well as 2007. It's posted in this forum for maximum exposure. Mods please let me know if there's a better way to achieve this.

    In brief: 

    A  server was reporting as compliant despite not installing updates for over 6 months. Installing SP1 for Server 2008 has resolved the issue and it's now correctly evaluating, downloading, installing and reporting compliance accurately.

    The long version:

    A single Citrix server was brought to my attention as not presenting expected software update deployments from SCCM 2007. On investigation, the server had not installed any updates for around 6 months, but was consitently reporting as compliant using "States 1 - Enforcement States for a Deployment". As the reports considered this server as compliant, it never appeared on my radar as problematic (I have over 1400 servers to patch).

    On investigation, I noted that the log files (on the surface) appeared error free: UpdatesHandler.log was reporting scan results as 0x0; UpdatesDeployment.log was correctly reporting evaluation against the missing deployment and all other log files appeared normal with no errors reported within SCCM or the event viewer. Then I noticed UpdatesStore.log hadn't reported any recent updates (for example any MS14-xxx updates), so it was clear there was an issue somewhere.

    After trying everything I could think of with no success (uninstall/reinstall client; recreated SCCM object; repair Windows Update; repair BITS; force state refresh; Software Update Readiness Tool; WMI integrity scans; trying the same deployment using my production SCCM 2012 instance and finally sfc /scannow (which reported some corruption but stated the fixes were successful)), I thought I'd try SP1 (as this server wasn't previously service packed). Sure enough after SP1 installed, updates were presented correctly, installing correctly and accurately reporting compliance.

    Now I have an idea where the solution is (installing SP1), I've since created a test deployment with an available and deadline date well into the future (2016), targeting all my 2008 Servers. I noted the report "States 1 - Enforcement States for a Deployment" was instantly reporting Compliance for 125 servers. On further investigation, I checked these 125 servers and all of them are NOT SP1.

    So in this instance SP1 is clearly essential for accurate compliance reporting and update evaluation for SCCM software updates in SCCM 2007 and SCCM 2012. I have a solution/workaround, but not a root cause, so my question is has anyone else seen this behaviour before and is there a less drastic solution than installing SP1? Given how many servers I have affected installing SP1 will cause major disruption in my environment.

    This is a major issue in my environment as compliance reporting is critical for audit purposes. With this issue, I've no confidence in the accuracy of my update compliance reporting and it's going to require a major amount of manual intervention to resolve.

    Just to re-interate, this problem has been noted in both SCCM 2007 and SCCM 2012 R2 for all Server 2008 R2 server which don't have SP1. Resolved by installing SP1 for Server 2008 R2.

    I'd appreciate any advice or suggestions.


    Tuesday, February 25, 2014 7:49 PM

Answers

  • After driving myself completely mad over this, it would appear my initial hunch was correct - SP1 is mandatory for Windows Update to work on Server 2008 R2, thanks to the end of life detailed here.

    Also, I suspect that as the "States 1 - Enforcement States for a Deployment" report was correct in respect to the updates that were installed up until stated end of support date, so as these updates were installed, compliance was reported. The problem I observed seemed to revolve around the issues evaluating updates after the end of support date. Technically, the report was correct, but in the real world it wasn't. Doesn't make the reporting behaviour any easier to understand though.

    Hopefully this helps someone else.

    • Marked as answer by mvjjkc Monday, March 3, 2014 11:29 PM
    Monday, March 3, 2014 11:29 PM