My hope with this post is to plant an idea in your mind on what could be done with SCCM Compliance Settings over using Group Policy. Let’s start off with an over view of the 2 options we will be discussing today.
Group Policy (GPO)
You can trace Group Policy all the way back to the first version of Active Directory in Windows Server 2000, the use of ADM files can be traced back even further into NT4, and windows 95/98 using the System Policy Editor which was part of the NT 4.0 Resource Kit which you can download here for those of you still using NT as your domain. Don’t get me wrong along the way Microsoft has added more features into Group Policy, for example Group Policy Preferences which was part of the acquisitions of Desktop Standard in 2006 originally called PolicyMaker. This alone has made group policy quite a powerful tool since Server 2008, the centralisation of the task like Printer and Drive Mapping which previously the easiest way to deploy these settings was Logon Script. The addition of the Advance Group Policy Management tool in the MDOP was great for those large companies which had SA and then also know about it, and admins didn’t know a password for a domain admin account, but a step in a very good direction none the less. Let’s face it most vendors that are doing large-scale deployments provide ADM/x files to configure the application as it still is a very easy way to empower the admins.
One of my biggest gripes with Group Policy was very noticeable in Windows XP, and less so in the new Windows Versions is that it is a set and hope solution, what I mean by this is that if I define a policy to my whole fleet without completing a process which is not out of the box I have to hope that the settings have applied, and typically I find out a month later when somebody raises the issue that was meant to be resolved.
Much like Group Policy you can trace Compliance Settings back a few generations of SCCM/SMS, to SMS 2003 to be precise. I have to on good authority it was originally created to confirm that exchanges servers in a large company had the same settings as each other. In 2003 the feature was called Desired Configuration Monitoring it was very much a passive process of collecting information, from which you could pull a report from. In SCCM 2007 this feature was renamed to Desired Configuration Management, and improved slightly it was included as a component that ran under ccmexec, it was converted to XML files stored on the client computer rather than WMI Classes which were returned with Hardware Inventory. Again it was very much a passive reporting feature which required manual steps to remediate the problems, and in large environments it gave you some where to start. Then Microsoft moved to SCCM 2012 and like a good deal of the product this component was given a comprehensive overhaul, along with the Compliance Settings moniker. As part of the overhaul a few new options were added, such as Remediation, a larger range of detection types (AD, Registry Keys, Scripts, SQL/WQL queries to name a few), and the ability to create a Collection from each deployment dependent on the status message.
Until SCCM 2012 I didn’t see a huge use for DCM as I was managing sites of around the 5000 seat mark, which is just on the cusp of needing to have everything repeatable. But with SCCM 2012 I can see great potential for Compliance Settings to replace large parts of Group Policy Objects which will not only allow for the reporting of settings, but ideally reduce the logon/startup time for our computers. In addition to this it has the ability for staff to run the evaluation independent of the schedule & create a local report without using the commandline. One of the downsides is this is equivalent to a local group policy setting, which is trumped by the Domain Group Policy, so it is one or the other for each of the defined settings.
So let’s for example say you work for a company which wants to annoy your staff by defining a standard wallpaper for all staff.
So in Group Policy we would create a new Group Policy Object, and define the following setting:
To point to in this example c:\windows\demo.jpg and defined to be centered.
We then assign it to the desired OU and it’s deployed.
Then you get the staff that have managed to convince the people of power, that to complete their work they must have local admin access to the work computer, you know the type that install “freeware” software for Business purposes and deny it when you approach them for a licence key. These guys are super smart and work out that they can change the wallpaper by making a regkey change, or replacing a file. As stated above there is no way out of the box to report on this, so you get questions from your managers as to why these guys have different wallpapers and the inevitable how can I change theirs for them.
SCCM Compliance Settings
So with SCCM to define this we first need to get the RegKey that is being defined as part of the Group Policy Setting, for something like Desktop Wallpaper you can google Bing it and some bright spark will have published it, like this: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System Wallpaper – REG_SZ WallpaperStyle – REG_SZ
For the more complicated settings if they are default Windows polices you can download excel files which detail each policy and the regkey that is set from here and for Office products you can find the link here.
We now have the registry key for our new Configuration Item in SCCM 2012 to create this we need to open the SCCM 2012 Console and navigate to Assets and Compliance, Compliance Settings, Configuration Items.
From here we can select the Create Configuration Item task from the Ribbon
On the Create Configuration Item Wizard form enter a descriptive name something like
U – Desktop Wallpaper which represents that we are defining a user setting for the desktop wallpaper, in addition to this I would recommend put a brief blurb in the Description box as you will be wondering why you created the item 6 months later.
The other part you need to make sure is that if you are defining a registry key that the settings applies to the operating systems which you are targeting on the Supported Platform page.
When we get to the point of creating a new Setting this is where we can define multiple settings that must be met, for example a scripted item to confirm the wallpaper file hasn’t been changed, and a registry value to ensure that the registry key hasn’t been changed.
Something like this for the registry key item:
We can then create compliance rules around the setting, which is where we can set it to report on if a certain value exists, and that it meets a defined task. In this example we want Wallpaper to equal “C:\windows\demo.jpg” in addition to reporting on if the systems are compliant, we can also remediate the setting where desired, in this case we do want to remediate the setting as shown below:
We have now created the Compliance Item which we can deploy to our users/computers with a configuration baseline. Again use a descriptive name, so for this demo we will use U – Desktop Wallpaper and add the Configuration Item that we created earlier.
We then deploy this to our desired collections, and this is where we can create multiple deployments one which will remediate the setting, and the other to only report on it, along with how often we want the evaluation to run on the computers.
On the client side your users will see the following tab in the Configuration Manager Client in the control panel.
As you can see you have ability to evaluate each of the Assigned baselines, along with providing a local report of the compliance of the baseline.