One of the features I personally liked in SCCM 2007 was the DCM (Desired Configuration Management) feature. This gave you as an admin the ability to build all kinds of configuration items which were evaluated against the systems of choice. So you could check for example how many machines were compliant with respect to specific software versions. So it was very easy to report on application version management. You could also write your own scripts, and use those scripts to check all kinds of stuff on your machines and report on their compliancy. So pretty powerful!
In SCCM 2012 Microsoft has decided to rename the feature to compliance and settings management. In my opinion not only cosmetic, but it also means that you can really manage the settings on systems for which you are measuring compliance. So in other word, the guys from Microsoft brought auto-remediation! Off course with SCCM 2007 you could fill collections with machines which were not compliant on a certain Configuration Item and advertise a program to solve that incompliance. But with SCCM 2012 those days are over. Only thing to note here is that the remediation stuff currently only supports WMI, Script and registry settings.
The next part of this blog will show you an example of a CI and a baseline which checks proxy settings of Internet explorer and remediates the setting if it evaluates false. So we start by building our CI with the new and improved GUI.
You can build CI’s for both Windows powered systems as Windows Mobile (device clients) powered systems. This post will only show a windows example.
I will only use 2008 because all my demo machines are installed with that OS
The registry key can very easily be found because of this new UI. This way typos are history.
I defined the correct registry key and assumed that the correct value for my proxy must be “correct.proxy:80”
After finishing the creation of the CI, it is now time to build a Baseline. I named this one Proxy Baseline. You can group all kinds of CI’s in this baseline and report on compliance.
Next step is creating a deployment so the baseline is linked to devices, computers or users. In this case I will target the baseline to all users. This means the baseline will be evaluated every time a user logs on to a system. We do not select the auto remediate function right away so I can show you the difference in resulting compliance reports.
The report shown above is the result of the evaluation of the Proxy baseline on one of my test machines where the registry setting is configured incorrectly. As you can see in the report this machine is non-compliant because the proxy is set to “Wrong.Proxy:80”.
Next step is enabling auto remediation for the proxy registry Deployment.
This updated baseline now checks the registry value and corrects it automatically as you can see in the above report. The value was changed and the report shows exactly what the SCCM client did. It changed the previous value “Wrong.Proxy:80” to the new remediated value “Correct.Proxy:80” So if we in the end check the internet proxy setting on the test machine it show us the correct proxy value!
I think Microsoft did a great job improving the SCCM 2007 DCM feature and can now be used not only for compliance reporting, but also for remediation. One small thing to end this post, the prebuild configuration packs, which were not very frequently updated for 2007 will be updated for the 2012 version. Microsoft is using their Best Practice Analysis rules (BPA) so every Configuration Pack build for 2012 will check and report compliance on all the different rules currently available in the BPA tests of Server 2008 R2, SQL 2008 R2, Exchange Server 2010 and Sharepoint Server 2007. This makes life a lot easier because you can import lots of CI’s just by downloading and importing these prebuild Configuration Packs.
