The Desired Configuration Management (DCM) feature in System Center Configuration Manager 2007 (ConfigMgr) enables customers to define configuration standards and policies and audit compliance of Windows systems throughout their IT organizations against those defined configurations.

The focus of Desired Configuration Management in ConfigMgr is the collection and reporting of configuration compliance data. Administrators are able to import configuration packs or create DCM configuration items and baselines using the editing features within ConfigMgr. Configuration baselines can then be targeted and deployed to collections of systems. The ConfigMgr client agent accepts configuration items and baselines from the ConfigMgr site server and audits the system for compliance to the configuration item and baseline definitions which have been targeted to that system. Administrators can choose to have the client generate Windows events and/or generate ConfigMgr state messages in response to non-compliant configuration detection. The non-compliance data is forwarded to that client’s site server and available for reporting or as criteria for query-based collections.

The data collected assists organizations in answering questions such as:

  1. What important configuration items have recently been changed on a malfunctioning system?

  2. How many desktop systems have non-standard configurations?

  3. Have our Exchange servers all been configured according to corporate standards?

Document Purpose: The purpose of this document is to guide Microsoft partners, Line-of-Business developers and advanced ConfigMgr administrators through authoring DCM configuration items that use chained setting and object discovery, and/or include validation that relate the values of two or more settings. To accomplish this task requires use of the DCM Digest XML Schema Definition, the DCM Digest Metadata XML Schema Definition, and an XML editor capable of validating and enforcing XML Schema (XSD).

Key Terms & Concepts

The following terms and concepts are essential to understanding DCM CI authoring.

Term Definitions

Configuration Item (CI)

CIs are units of configuration management that can be detected, applied, and removed from ConfigMgr managed machines. DCM supports five types of configuration item:

  • Application configuration item

  • Operating System configuration item

  • General configuration item

  • Software Updates configuration item

Note
General configuration items are referred to as BusinessPolicy configuration item in the DCMDigest.xsd
Note
Software Updates CIs are created / administered through the Software Updates feature in ConfigMgr 2007 and can be referenced by configuration baselines. They cannot be directly authored via DCM or the DCM Digest.

General configuration item

General CIs are models of settings and objects which together represent a meaningful unit of configuration management whose identity is defined by enumeration of its settings and objects.

Examples of general configuration items might include:

  • Your organization’s security configuration policy

  • Compliance controls for Sarbanes-Oxley section 404

Application configuration item

Application CIs include all of the functionality of general configuration items but whose identity can be detected independently of its settings and objects. DCM in ConfigMgr 2007 supports two methods for detecting the presence of an application configuration item: (1) MSI; and (2) Script-based discovery. This CI-level discoverability allows application CIs to be referenced as prohibited or optional within the context of a configuration baseline.

Examples of application configuration items might include:

  • Microsoft Office Professional 2003

  • Microsoft Word

  • Your organization’s Finance Reporting Server LOB application

  • Hardware applications/appliances

Operating System configuration item

Operating System configuration items include all of the functionality of general configuration items but are tightly coupled with a specific version of the Windows operating system.

Examples of operating system configuration items might include:

  • Your organization’s Windows Server 2003 Datacenter server policy

Objects

Objects are configuration elements related to a CI which consist of an identity and one or more properties, including security access controls. DCM in ConfigMgr 2007 supports four object types: (1) file; (2) folder; (3) Global Assembly Cache (GAC) registered assemblies; and (4) registry keys. Objects may be defined for any Application, General, or Operating System configuration item.

Note
Objects are referred to as “Parts” in the DCMDigest.xsd.

Settings

Settings are configurable name/value pairs which influence the behavior of hardware and software. DCM can discover settings using any of the supported providers, including:

  • Registry

  • WMI (WQL query)

  • Microsoft SQL Server (SQL query)

  • Active Directory (LDAP)

  • XML (XPath query)

  • IIS Metabase

  • Script (JScript/VBScript/Powershell)

Settings may be defined for any Application, General, or Operating System configuration item.

Note
There is no relationship between objects and settings in DCM CIs. For example, it is not necessary to define a registry key object in order to define settings which happen to be located in that registry key location.

Validation

Validation consists of constraints applied to the settings and object properties discovered for a CI. Validation constraints may be applied on any setting or object property for any Application, General or Operating System configuration item.

Note
Objects are referred to as “Parts” in the DCMDigest.xsd.

Parent/Child configuration item

DCM supports derivation by extension for application, OS, and general configuration items, but not configuration baselines. A derived CI is called a Child CI and the original base CI is called its Parent CI. A Child CI can be used to add validation on the settings or object properties defined by its Parent CI. It can also add new settings and objects which were not defined for the Parent CI. This allows CI authors to define shared configuration data once in a common Parent CI.

Note
DCM sets no restriction on the number of levels of CI inheritance. However, in order to minimize the administrative burden of managing the ConfigMgr environment, CI authors are strongly encouraged to limit themselves to no more than 1 or 2 levels of derivation.

Configuration Baseline

A configuration baseline is a complex type of CI which is composed of references to other CIs. The CI references apply constraints on the referenced CIs by classifying them as required, optional, or prohibited within the context of the baseline. The configuration baseline is the primary unit of administrative work for DCM administrators and can be assigned to ConfigMgr collections for compliance monitoring

DCM Digest

The DCM Digest is an XML document that describes exactly one DCM configuration item or baseline. The XML Schema Definition called DCMDigest.xsd can be used with an XML editor like Microsoft Visual Studio 2005 to author valid DCM Digest XML. The XML Schema Definition called DCMDigestMetadata.xsd can be used to author chained discovery logic for settings and objects, or validation which relates the values of two or more settings.

Chained discovery

This term is used to describe the situation where the value from one setting or object property is used to discover another setting or object. For example, many applications store their install location in the registry. Using the concepts described in this document, a DCM configuration item author can look up the value of the install location setting in the registry and then use that value to locate a file object at that location.

Substitution [reference]

This term is used to describe the setting or object property value being used as part of chained discovery, or in a validation which relates the values of two or more settings.

Chained Discovery

As mentioned earlier, chained discovery is used when the values from one or more settings or object properties is required to discover another setting or object. Using the DCM Digest Metadata XML Schema Definition and the DCMSubVar.exe tool, configuration item authors can achieve the following scenarios:

  1. Substitute the exact value of a setting in any discovery element from “Table1 – Possible substitutions per object/setting” for an object or another setting.

  2. Substitute the exact value of an object property in any discovery element from “Table1 – Possible substitutions per object/setting” for another object or a setting.

  3. Concatenate string literals with the value of a setting or object property and substitute the resulting string in any discovery element from “Table1 – Possible substitutions per object/setting” for an object or a setting.

  4. Concatenate string literals, the values of one or more settings, and the values of one or more object properties and substitute the resulting string in any discovery element from “Table1 – Possible substitutions per object/setting” for an object or a setting.

Table 1 – Possible substitutions per object/setting

IIS WQL Script AD SQL XML FileFolder Assembly RegistryKey Setting/Registry Parts

Path

Namespace

DnName

Instances

FilePath

Path

AssemblyName

Key

PropertyID

Class

Attributes

Database

Filter

Filter

ValueName

Property

Filters

Query

Where

ColumnName

Using settings data for chained discovery of objects

To substitute the value of a setting in the discovery element for an object, use the <DiscoveryOrdering> element as shown in the following example:

Code block 1 - Chained discovery of an assembly object using setting substitution

  Copy Code
<DesiredConfigurationDigest xmlns="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2006/03/24/DesiredConfiguration" xmlns:sub="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2007/07/DesiredConfiguration/Extensions">
<BusinessPolicy AuthoringScopeId="Samples" LogicalName="ObjectChaining" Version="1">
<Annotation>
<DisplayName Text="Object Chaining" />
<Description Text="" />
</Annotation>
<Parts>
<ParentReferences>
</ParentReferences>
<Assembly LogicalName="Assemblytest">
<Annotation>
<DisplayName Text="string" />
<Description Text="string" />
</Annotation>
<sub:DiscoveryOrdering sub:Depth="1">
<sub:OrderedProperty sub:Name="AssemblyName">
<sub:Expression>
<sub:SimpleSettingReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:MemberLogicalName="AssemblySubA" />
</sub:Expression>
</sub:OrderedProperty>
</sub:DiscoveryOrdering> 
<AssemblyName>This_will_be_replaced_by_substitution</AssemblyName>
<AssemblyPropertyRules>
<Culture />
<Version />
<PublicKeyToken />
</AssemblyPropertyRules>
</Assembly>
</Parts>
<Settings>
<RootComplexSetting>
<SimpleSetting LogicalName="AssemblySubA" DataType="String">
<Annotation>
<DisplayName Text="Substitution setting" />
<Description Text="" />
</Annotation>
<ScriptDiscoverySource ScriptType="VBScript">
<ScriptBody>wscript.echo "CrystalDecisions.Web"</ScriptBody>
</ScriptDiscoverySource>
<Rules>
</Rules>
</SimpleSetting>
</RootComplexSetting>
</Settings>
</BusinessPolicy>
</DesiredConfigurationDigest>

The highlighted section above identifies the new schema extensions that control the chained discovery. Only the sub-elements in the <Expression> section of the <DiscoveryOrdering> element will vary when substituting settings, object properties, and string literals.

This table describes the schema extensions used for settings substitution.

Table 2 – Select DCM Digest Metadata elements described – Element Tag : Definition

Element Tags Definitions

<DiscoveryOrdering>

<DiscoveryOrdering> : Mandatory opening tag for valid substitution in object or setting discovery data. For object discovery, the <DiscoveryOrdering> element must immediately follow the <Annotation> element of the object. For setting discovery, the <DiscoveryOrdering> element must immediately follow the <*DiscoverySource> element opening tag.

Attribute Information

Depth

Integer.

The Depth attribute identifies the discovery group to which the current setting or object is assigned. The Depth must be set to one greater than the highest Depth for any referenced setting or object.

By default, all settings and objects are implicitly assigned to Depth = 0. Any settings or objects which use values from the default group must be assigned Depth = 1. In turn, settings or objects which use values from Depth =1 must, themselves, be set to Depth = 2 and so on.

Note
All Depth values used in a configuration item must form a sequential order. For example, 0, 1, 2, 3 would be valid whereas 0, 2, 6 would be invalid.

<OrderedProperty>

The <OrderedProperty> element identifies which discovery property is being replaced. In the example above, the Assembly discovery property replaced is “AssemblyName”. To replace more than one discovery property, add additional <OrderedProperty> elements within a <DiscoveryOrdering> element.

Attribute Information

Name

The element name for the property being replaced. E.g. “Path” for a folder or file object; “Key” for a registry setting.

<Expression>

The <Expression> element defines the set of string literals, setting values, and/or object properties to be used as the substitution. In the above example, the <Expression> includes a single <SimpleSettingReference>. Use <Concatenation> to combine multiple string literals, settings, or object property references.

Attribute Information

N/A

N/A

<SimpleSettingReference>

Identifies the setting to be used for substitution.

Attribute Information

AuthoringScope

The AuthoringScopeId of the configuration item from which the substitution reference data is found.

LogicalName

The LogicalName of the configuration item from which the substitution reference data is found.

Version

The Version of the configuration item from which the substitution reference data is found.

MemberLogicalName

The LogicalName of the setting used for substitution.

Using settings data for chained discovery of settings

To substitute the value of a setting in the discovery element for another setting, use the <DiscoveryOrdering> element as shown in the following example:

Code block 2 - Chained discovery of a setting using setting substitution

  Copy Code
<SimpleSetting LogicalName="RegistrySetting1" DataType="String">
<Annotation>
<DisplayName Text="Registry setting 1" />
<Description Text="" />
</Annotation>
<RegistryDiscoverySource Hive="HKEY_LOCAL_MACHINE" Is64Bit="false">
<sub:DiscoveryOrdering sub:Depth="1">
<sub:OrderedProperty sub:Name="Key">
<sub:Expression>
<sub:SimpleSettingReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:MemberLogicalName="SettingSubB" />
</sub:Expression>
</sub:OrderedProperty>
</sub:DiscoveryOrdering>
<Key>To_be_replaced</Key>
<ValueName>To_be_replaced</ValueName>
</RegistryDiscoverySource>
<Rules />
</SimpleSetting>

Note in the code sample above that only the location of the <DiscoveryOrdering> element differs from the object discovery.

Using object property data for chained discovery of objects

To substitute the value of an object property in the discovery element for another object, use the <DiscoveryOrdering> element as shown in the following example:

Code block 3 - Chained discovery of a file object using substitution from another file object’s property

  Copy Code
<File ValidatePermissions="false" Is64Bit="false" LogicalName="FileSub">
<Annotation>
<DisplayName Text="Sample.exe" />
<Description Text="" />
</Annotation>
<sub:DiscoveryOrdering sub:Depth="1">
<sub:OrderedProperty sub:Name="Path">
<sub:Expression>
<sub:Concatenation>
<sub:LiteralContent>%ProgramFiles%\SampleApp\</sub:LiteralContent>
<sub:PartPropertyReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:ObjectType="File" sub:MemberLogicalName="Main_exe" sub:Property="Version" />
</sub:Concatenation>
</sub:Expression>
</sub:OrderedProperty>
</sub:DiscoveryOrdering>
<Path>To_be_replaced</Path>
<Filter>Sample.exe</Filter>
<Permissions IsFullySpecified="false" />
<PropertyRules>
<DateCreated />
<DateModified />
<Attributes />
<Size />
<Version />
<Company />
<ProductName />
<SHA1Hash />
</PropertyRules>
</File>

This table describes the schema extensions used for object property substitution.

Table 3 – Select DCM Digest Metadata elements described

Elllement Tag Definition

<PartPropertyReference>

Identifies the object property to be used for substitution.

Attribute Information

AuthoringScope

The AuthoringScopeId of the configuration item from which the substitution reference data is found.

LogicalName

The LogicalName of the configuration item from which the substitution reference data is found.

Version

The Version of the configuration item from which the substitution reference data is found.

ObjectType

The type of object from which the referenced property is found.

MemberLogicalName

The LogicalName of the object used for substitution.

Property

The property of the object containing the data to be used for substitution.

Using object property data for chained discovery of settings

As with “Using settings data for chained discovery of settings”, the only difference between this and the preceding example is the location of the <DiscoveryOrdering> element tag.

Concatenate string literals with object property and settings data

You can use the <Concatenation> element within a <DiscoveryOrdering> to combine several pieces of data together to create a single discovery substitution reference.

Code block 4 – Concatenation of string literals, object property, and settings data

  Copy Code
<sub:DiscoveryOrdering sub:Depth="1">
<sub:OrderedProperty sub:Name="Path">
<sub:Expression>
<sub:Concatenation>
<sub:LiteralContent>%ProgramFiles%\SampleApp\</sub:LiteralContent>
<sub:PartPropertyReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:ObjectType="File" sub:MemberLogicalName="Main_exe" sub:Property="Version" />
<sub:LiteralContent>\SubFolder\</sub:LiteralContent>
<sub:SimpleSettingReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:MemberLogicalName="SubstitutionSetting" />
</sub:Concatenation>
</sub:Expression>
</sub:OrderedProperty>
</sub:DiscoveryOrdering>

This table describes the schema extensions used for object property substitution.

Table 4 – Select DCM Digest Metadata elements described

Element Tag Definition

<Concatenation>

Combines the data from one or many <LiteralContent>, <PartPropertyReference> and <SimpleSettingReference> elements.

Attribute Information

None

None

<LiteralContent>

This element is used to define a string literal which can be combined with other discovered data and string literals in a <Concatenation> element.

Attribute Information

None

None

Substitution in Validation

In addition to chained discovery extensions, the DCM Digest Metadata XML Schema Definition also defines schema extensions to allow authoring of rules that compare the data of two or more settings. In this way, setting and object property data can be compared together. For example, an application may store its Application Version setting in the registry. The value of the Application Version setting can be retrieved and used to validate the Version attribute of a file related to the application.

Code block 5 - Substitution in validation

  Copy Code
<SimpleSetting LogicalName="AssemblySubA" DataType="String">
<Annotation>
<DisplayName Text="Substitution setting" />
<Description Text="" />
</Annotation>
<ScriptDiscoverySource ScriptType="VBScript">
<ScriptBody>wscript.echo "CrystalDecisions.Web"</ScriptBody>
</ScriptDiscoverySource>
<Rules>
<Rule LogicalName="SubstitutionRule" Operation="Equals" OperandA="To_be_replaced" OperandB="" Severity="Critical">
<Annotation>
<DisplayName Text="This rule will compare the value of one setting with value of the current setting." />
<Description Text="" />
</Annotation>
<sub:RuleOperands>
<sub:Operand>
<sub:SimpleSettingReference sub:AuthoringScope="Samples" sub:LogicalName="ObjectChaining" sub:Version="1" sub:MemberLogicalName="RegistrySetting1" />
</sub:Operand>
</sub:RuleOperands>
</Rule>
</Rules>
</SimpleSetting>

This table describes the schema extensions used for substitution in validation.

Table 5 – Select DCM Digest Metadata elements described

Element Tag Definition

<RuleOperands>

Mandatory element tag for substitution references in validation criteria for a setting or object.

Attribute Information

None

None

<Operand>

This element identifies the string literal, object property, or settings data to replace the Operand values for validation criteria. As with substitution in discovery, the <Concatenation> element can be employed to combine multiple values in a single <Operand> element.

Attribute Information

None

None

Using the DCMSubVar.exe tool

  1. Start with your DCM Digest XML file which has been updated using the schema extensions defined by the DCMDigestMetadata.xsd.

  2. From a command prompt, navigate to the location where you have installed the DCMSubVar.exe tool and run the following command:

    DcmSubVar [input] [output]

    [input]: Path of input Digest document

    [output]: Path of output SML document (partially interpreted)

Code block 6 - DCMSubVar command

  Copy Code
C:\Program Files\ConfigMgr 2007 ToolKit\DCM Tools>DCMSubVar C:\DCM20007\Pre_Substitution_CI.xml C:\DCM2007\Substitution_CI.xml

The tool will output a partially-interpreted configuration item XML file for use in DCM.

Use DCMMVTool.exe to validate and test partially-interpreted configuration items

Once you have completed generation of your partially-interpreted configuration item XML, you can use the DCM Model Verification Tool (DCMMVTool.exe) to check the configuration item XML for errors and to test the configuration item on an actual system before uploading to your ConfigMgr site.

The DCMMVTool.exe tool is described in greater detail in the Desired "Configuration Management Model Verification Tool" section.

Import your tested configuration item to ConfigMgr

At this point, you have completed your DCM configuration item using substitution references. You may now import the final configuration item via the SDK or create a Cabinet file (.cab) with your configuration item XML and import via the ConfigMgr console.