First published on MSDN on Feb 02, 2016
Note: These screenshots are difficult to read. The exported configuration items are attached along with a few additional examples. They are intended only for import in a lab environment.
Compliance Settings, formerly Desired Configuration Management in ConfigMgr 2007, has been a key ConfigMgr capability for years and remains one of the most capable, but often underutilized, feature in the product. Part of the reason might be that Compliance Settings is a ‘build it yourself’ component that can leave an admin struggling to fully understand capabilities and implementation details.
Tools, such as Security and Compliance Manager (SCM), provide examples of effectively configuring Compliance Settings to address specific needs. Administrators are able to leverage given examples to help decrease their Compliance Settings learning curve. But even with SCM the examples given may not cover all of the available capabilities.
Many examples exist for mainstream detection methods, such as registry or file system. It may well be a struggle to find examples of less mainstream options such as reading an XML file or the IIS metabase. Having also been frustrated with the lack of examples I finally decided to illustrate each one. The purpose of this post, then, is not to cover the capabilities of Compliance Settings in detail but, by illustration, to show examples of how the various methods could be used. Even with the examples below there is much more that could be illustrated. Hopefully the examples will be enough to help you explore the full capabilities without the headache of having to figure it all out from scratch.
The goal of configuring an Active Directory detection is to craft the proper LDAP query. The dialogues here help with that. The individual Distinguished Name, Search filter, Search scope and Property values are the only configurable items and, once configured, are combined to generate the resulting LDAP string. Once this string is complete it is possible to configure further rules to either check for an existence of the property, as in the example, or check for a specific value associated with the property.
An assembly allows detection of specific items in the OS global assembly cache (GAC). The GAC specifically stores assemblies that have been designed to be shared by several applications on the computer. The idea is that if a required assembly is not present, of an incorrect version, etc., it could cause problems with key applications. The example given shows a configuration to simply detect whether a required assembly is present in the GAC.
The file detection is able to check files or folders for their presence and various attributes. The example given checks a folder for a specific value for CreatedDate.
The IIS Metabase contains configuration detail for hosted web pages. The example given checks for the existence of a specific property. Note that the path format simply is a navigation of the metabase tree as might be seen using a tool like metabase explorer.
The registry detection allows checking for the existence of a registry key or registry setting and also detection of specific configurations for a given setting. With this detection method it is also possible to configure automatic remediation of a misconfigured setting.
The SQL detection method allows for running a query against SQL servers. The example given shows using this method to detect a given setting returned by a simple SQL query. Notice that the trick here is to cast your output as a known column name that can then be used in any evaluations.
Similar to the SQL format the WQL query allows for checking for the existence/configuration of an element found in WMI. With this detection method it is also possible to configure automatic remediation of a misconfigured setting.
The XML detection allows for opening and reading the contents of an XML file for a specific path and configuration. The XPath query used simply walks the path of the XML to the specific item of interest. If the XPath query doesn’t make sense spend just a few minutes looking at a properly formatted XML snip and you should be able to quickly understand how the pathing works.
The final detection method to discuss is the script. If you can’t configure your detection job with one of the previous detection methods then the script method is available. With the script method the detection possibilities are virtually limitless. With this detection method it is also possible to configure automatic remediation of a misconfigured setting. If remediation is required a remediation script must also be supplied.
The sample PowerShell script below is used to detect whether the WordPad process (or any process) is running multiple times. The script initially sets the $compliance variable to true to indicate compliant and then proceeds to test the condition. If a non-compliant scenario is found the $compliance variable is changed to False.
$Processes = Get-Process $ProcessName -erroraction 0
ForEach ($Process in $Processes)
if (-not $Process.responding)
$CountofSuspendedProcesses = $CountofSuspendedProcesses + 1
if ($CountofSuspendedProcesses -gt 0)
In all cases the script returns the variable being used for tracking compliance testing. The variable used can be anything as long as the script returns a value. The returned value is then tested by the compliance rule to determine compliance.
And that’s it. With these examples it should be very possible to configure the exact type of compliance scenarios that should be tested in any environment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.