Making Sense of Compliance Settings (DCM)

  • Article

System Center Configuration Manager has a feature called Compliance Settings (previously Desired Configuration Manager or DCM).  Compliance Settings require a few components to work properly.

  • Client Settings must enable the Compliance Settings agent and set the intervals for evaluation.
  • Client Settings will usually require the PowerShell Execution Setting in the Computer Agent to be set to Bypass
  • Collection for applying these settings
  • Configuration Items
  • Configuration Baselines to aggregate settings

This is all stuff you can find on TechNet.  What I was unable to find when preparing for a customer recently was some solid advise about best practices around how to organize Compliance Settings (CS).  I wanted to post our solution for those searching in the future.  The customer had a list of items that must be configured a certain way on different server workloads.  Some were basic, systemic OS settings and some were application specific.  The customer has settings crossing all of the categories listed below.  Each category represents a baseline that we created.

  • Member Server
  • Windows Clusters
  • SQL Servers
  • Domain Controllers
  • SQL Clusters

The primary goal of this project was to make sure we monitored all the settings, but we also wanted to build the CS feature to easily allow future expansion and maximum reusability for Configuration Items (CIs).  We went with a tiered structure and categorized each CI to fit within that structure.  The structure included the following.

  • Member Servers - this would include all CIs that are required on all servers hosting a production workload.  CIs applicable to only some OS versions were limited in scope using the Supported Platforms properties of the CIs
  • Windows Clusters- this would include the Member Server Baseline and all CIs specific to a Windows Cluster
  • SQL Server - this would include the Member Server Baseline and all CIs specific to a SQL server
  • SQL Clusters - this would include the Member Server Baseline, SQL Server Baseline and all CI's specific to SQL clusters
  • Domain Controllers - this would include the Member Server Baseline and all CIs specific to domain controllers

This type of structure allows us to modify the member sever baseline and have that change drop all the way through the other baselines to define the new standard.  This hierarchy also eases the task of adding another application, like IIS servers.  We simply create CIs specific to the desired IIS configuration and include the member server baseline.  Another benefit to this hierarchy is that when multiple teams are responsible for their own baselines, you can setup security much easier.  The team responsible for SQL or IIS can add or change CIs within their scope and not have to involve other teams.

Hope this helps,

John Taylor