Configuration items encapsulate the checks that DCM makes against a system to determine its compliance. Collectively, these checks are called evaluation criteria. To view or edit the configuration items present in a site, navigate to Site Database -> Computer Management -> Desired Configuration Management -> Configuration Items in the ConfigMgr navigation tree. There are four types of configuration items:

Software update configuration items are a special type of configuration item, as they are not listed with the rest of the configuration items in the console and you cannot directly create them like the three other types. These are created when defining a baseline, with their only evaluation criteria the installation status of a specific software update chosen from the update repository. To use software update configuration items, the ConfigMgr Software Update feature, discussed in Chapter 15, “Patch Management,” must be properly configured and working not only to define the software update configuration item, but also to detect its installation status.

There are two property types used to represent the evaluation criteria implemented by a configuration item:

Although not a perfect analogy, you can think of objects as “physical” or tangible items that the operating system uses and manipulates. Settings on the other hand describe how or with what parameters the operating system or an application goes about its many tasks.

The validation of each criterion and instance count is configured individually to contribute to the compliance status of the configuration item as a whole. Each configuration item has four potential severity levels of non-compliance:

If any criterion fails, the configuration item as a whole is marked as non-compliant for that system. The highest severity level for any failed check, including instance count checks, is used as the severity level for the configuration item. Results of these checks are sent back to ConfigMgr for reporting. Each failed check also produces an event message in the Windows Application Event Log, except for the Information—no Windows event message level.

The combination of the Objects and Settings property types provide a wide range of criteria that DCM can check to determine compliance. The addition of custom scripts, often used with Microsoft sample baselines, gives DCM unlimited customizability and flexibility. The “Console Authoring” section includes a detailed discussion on creating and editing configuration items using the ConfigMgr console.

DCM can restrict the evaluation of application and general configuration items based on Windows platform applicability. This configuration checks for specific Windows platforms and prevents evaluating the configuration item on platforms not specified.

You can organize configuration items in several ways. This includes categories and hierarchies and combining them into baselines:

As stated earlier in the “Configurations” section, configuration baselines group configuration items together; the baselines are then assigned to collections for evaluation. Configuration items are assigned to baselines using rules. Each rule is a list of a specific type of configuration item. Rules available include the following:

In addition to the configuration item rules, an additional rule exists to include other baselines. This essentially groups the baselines together and combines their evaluation.

To create a new baseline, perform the following steps:

To modify an existing baseline, navigate to Site Database -> Computer Management -> Desired Configuration Management -> Configuration Baselines. Right-click the desired baseline in the Details pane and then choose Properties from the context menu. The baseline properties dialog box contains the following pages:

You can also view information from all these tabs by selecting any baseline in the Details pane. This displays a Details pane at the bottom of the window with four tabs corresponding to those listed previously (with the exception of the Security tab). These tabs are view-only and offer a quick way to view the details of a baseline without opening the Properties dialog box.

In addition to using the Rules tab of a baseline’s Properties dialog box to add rules, you can select Add from the context menu of a baseline. This gives you a flyout menu (shown in Figure 16.4) with a choice for each of the rule types listed. Selecting one of these works the same as selecting a hyperlink under the Rules tab.

Figure 16.4. Baseline context menu

Assigning a baseline is what triggers its evaluation against a set of systems. Collections, being the standard targeting mechanism for ConfigMgr, are what baselines are assigned to. To assign a baseline to a collection, right-click it and then choose Assign to a Collection. This launches the Assign Configuration Baseline Wizard, as displayed in Figure 16.5. This wizard contains the following pages:

Figure 16.5. Assign Configuration Baseline Wizard

Using DCM, configuration baselines are assigned to ConfigMgr collections. The settings and values defined in each configuration item in a baseline are compared against the current configuration of the systems in the collection, according to the evaluation schedule for that baseline. The results of this comparison are returned to ConfigMgr, where you can run a variety of reports to determine how the systems fared on these comparison tests; this is also known as the compliance status of the system.

In addition to simply reporting on the compliance status of systems and collections, you can build collections using this same data to create remediation mechanisms. Because automatic remediation of discrepancies is not a function of DCM, you must implement some other mechanism to correct the configuration of systems. The synergistic functions of ConfigMgr 2007 allow you to create software distribution packages and programs to make these corrections.

As an example, if you create and assign a baseline that checks for the existence of an antivirus product on every workstation in a collection, any systems that fail this check are deemed noncompliant. Typically, an organization reporting the noncompliant status of systems will want to correct those as soon as possible. The approach then is to create a new collection that queries the compliance status of systems against this baseline, and use a software distribution package to install the preferred antivirus product and assign the package to the collection. The “Remediation” section later in this chapter presents an example of this. For complete details of software distribution, see Chapter 14, “Distributing Packages.”

Microsoft understands there are many similarities and common requirements between IT organizations, and has released a large number of configuration baselines to use as a starting point, as a reference, or as complete solutions. These baselines are encapsulated in configuration packs (CPs). Analogous to management packs (MPs) in Operations Manager (OpsMgr), CPs are freely downloadable from Microsoft’s System Center Configuration Manager 2007 Configuration Pack Catalog at http://technet.microsoft.com/en-us/configmgr/cc462788.aspx. Types of available CPs include the following:

To import a baseline downloaded from the catalog, you must first extract it from the downloaded Microsoft Installer package. These installer packages do not actually install the configuration pack; they merely extract the necessary cabinet (.CAB) compressed file (similar to a self-extracting executable) to a folder of your choosing. Once this is extracted, perform the following steps to import the CP into ConfigMgr:

Configuration items in imported CPs are locked, preventing you from modifying them in any way. Locked configuration items are displayed with a lock icon. To use one of these configuration items as a starting point, duplicate it by right-clicking it and choosing Duplicate from the resulting context menu. The duplicated configuration item will be fully editable. It is also recommended to duplicate an existing, known-good configuration item or baseline before editing it. (Known-good refers to an item that has already successfully worked in an environment.) Using this approach provides a solid rollback and baselining mechanism.

Although the CPs available from Microsoft’s Configuration Pack Catalog are quite useful, they do not cover every possibility and are somewhat generic at times. Eventually, you will want to create your own criteria by modifying the CPs provided by Microsoft, or creating your own to evaluate your systems. The next sections discuss this activity, known as authoring.

The main purpose of the ConfigMgr console in DCM is to organize, assign, create, and edit configuration baselines and configuration items. The built-in toolset for these last two activities—creating and editing—is fairly complete; it allows you to define a wide range of evaluation criteria covering most of the scenarios needed.

To create a new configuration item, navigate to Site Database -> Computer Management -> Desired Configuration Management -> Configuration Baselines in the ConfigMgr console navigation tree and then select New. This results in a flyout menu where you can select to create one of the three creatable types of configuration items. The resulting Configuration Item Creation Wizards for all these types are similar to each other; each has the pages listed in Table 16.1.

Here are descriptions of the wizards:

• Identification— On this page, you set the name of the configuration item and assign any desired categories.

• Detection Method— This page, specific to only application configuration items and shown in Figure 16.7, allows you to configure how the installation of an application is detected. There are three methods:

• Assumption—When this method is selected, DCM simply assumes that the application is installed without a check. Choosing this option is essentially the equivalent of creating a general configuration item.

• Windows Installer (MSI) Detection—This method uses the list of products installed by Windows Installer to determine if an application is installed. If an application was not installed using an MSI, this method is not applicable.

Expected data for this method includes the Globally Unique Identifier (GUID) and the version number for the application. The easiest way to get this information is to click the Open button and select the MSI originally used to install the application. This automatically populates the fields. You can also instruct DCM that the installation was installed “per user” by checking the corresponding box shown in Figure 16.7. This check box is grayed out until you select Use Windows Installer (MSI) detection.

Figure 16.7. Configuration Item Detection Method page

Note

Manually Determining a Product’s GUID

Although not always apparent, most software applications today are installed using an MSI. The MSIs are typically hidden inside of executables and are not directly accessible. During installation, the MSI is extracted from the executable to a temporary folder and then installed from that folder. The easiest way to determine the application’s GUID and version if the MSI is hidden in this way—or not readily available for any reason—is to use WMI, and the easiest way to query WMI is the WMI console (WMIC).

WMIC is part of every Windows installation and invoked from the command line. The September 2006 issue of TechNet contains an excellent article on WMIC, titled “Gathering WMI Data without Writing a Single Line of Code,” available at http://technet.microsoft.com/en-us/magazine/2006.09.wmidata.aspx.

Here’s an example of a WMIC command to query for the GUID and version of all Microsoft Live products:

This command outputs the product name, GUID, and version for every product that has Live in its name.

• Script—This method uses a custom script—VBScript, JScript, or PowerShell based—to detect the installation of an application. The script should return some text to indicate the successful detection of an installed application and no text to indicate failure. A simple example VBScript to detect the installation of the Internet Explorer Administration Kit 7 follows:

Note

Script Success

Scripts used in DCM are considered to be successful if they output anything to the standard output—often referred to as StdOut. The exact contents of the output are not evaluated; it’s just that something is output. Conversely, if nothing is output, the script is considered unsuccessful.

• Objects— On this page, displayed in Figure 16.8, you choose which objects to evaluate for compliance on a system. To add a check for an object, click New at the bottom of the page (circled in the figure) and choose the type you would like to check for from the pop-up menu. Objects are discussed in the “Objects” section of this chapter.

Figure 16.8. Configuration Item Objects page

• Settings— Shown in Figure 16.9, you choose which settings to evaluate for compliance on a system. To add a check for a setting, click New at the bottom of the page and choose which type you would like to check for from the pop-up menu. The “Settings” section discusses possible settings.

Figure 16.9. Configuration Item Settings page

• Applicability— Only available on general and application configuration items, this page (displayed in Figure 16.10) sets the Windows platforms for which the configuration item is applicable. If the Windows version does not match, the configuration item is not evaluated. The list of Windows platforms includes all ConfigMgr-supported platforms and is broken down by version, service pack, and hardware platform. You can specify All Windows platforms, or use the list to select one or multiple platforms, making the configuration item applicable to specific Windows platforms.

Figure 16.10. Configuration Item Applicability page

• Microsoft Windows Version— Shown in Figure 16.11, this page is only available to operating system configuration items, but is very similar in function to the Applicability page described in the previous bullet. The primary difference is you can only specify a single Windows version. You can choose a Windows version from the drop-down at the top of the page or explicitly define the Windows version using the text boxes. If you chose a version from the list box at the top, the text boxes for the version are automatically populated.

Figure 16.11. Configuration Item Windows Version page

The primary evaluation criteria used in configuration items is defined using the Objects and Settings tabs. These are described in detail next.

Settings

As discussed in the “Configuration Items” section, settings are the result of queries against Active Directory, the IIS metabase, the Windows Registry, SQL Server databases, WMI WQL, an XML file, or a custom script. Each of these query types has the configurable properties listed in Table 16.3.

Table 16.3. Configurable Properties for Settings

64-bit Redirection

Several caveats come with 64-bit Windows. The one most administrators notice right away is the existence of a new folder called Program Files (x86). All 32-bit applications resolve the environment variable %ProgramFiles% to this new Program Files folder. To see this on a 64-bit system, launch the 64-bit command prompt by typing %windir%SysWoW64cmd.exe on a run line. Type echo %ProgramFiles% and examine the output. You can see that 64-bit applications, such as the default command prompt, resolve %ProgramFiles% to the traditional Program Files folder. The same behavior occurs when a 32-bit application tries to access %windir%System32—the application is transparently redirected to %windir%SysWOW64. This 64-bit redirection also happens in the Registry.

The exact why’s and how’s of this redirection in 64-bit Windows are detailed at http://msdn.microsoft.com/en-us/library/bb427430(VS.85).aspx. You do not really need to know these details; just that it takes place. ConfigMgr typically presents you with a check box or radio button to disable the redirection any time this redirection can have an adverse effect. This is the case with File or Folder objects, Registry objects, Registry settings, and XML settings.

 

Figure 16.12. Assembly object type

Figure 16.13. File or Folder object type

Figure 16.14. Registry object type

Figure 16.15. Active Directory setting type

Figure 16.16. IIS metabase setting type

Figure 16.17. Registry setting type

Figure 16.18. Script setting type

Figure 16.19. SQL query setting type

Figure 16.20. WMI query setting type

Figure 16.21. XML setting type

Validation Criteria

Each object, other than the Registry object, has a validation tab; by using this tab, you specify the criteria for validating that the object exists. Add criteria in the top list box by clicking the New button. This results in a pop-up menu where you choose from one of the validation properties, as specified in Table 16.2. This opens the Configure Validation dialog box shown in Figure 16.22.

Figure 16.22. Configure Validation dialog box

The Name field is a display name for the rule and the Description field is optional. The Setting/Property field is read-only and already filled in based on the selection you made on the New pop-up menu. You have nine operators to choose from for numbers, dates, and versions:

• Between

• Equals

• Greater than

• Greater than or equal to

• Less than

• Less than or equal to

• None of

• Not equals

• One of

String values have 13 possible operators:

• Equals

• Not equals

• One of

• Begins with

• Ends with

• Contains

• Matches

• All Of

• None Of

• Does not begin with

• Does not end with

• Does not contain

• Does not match

For One of, All of, or None of, the Value field can contain a comma-separated list of values. For the Between operator, the second Value field is added to the tab to specify the maximum value. Using Windows environment variables for values is not valid. The Expression field is read-only and built for you based on the choices you make in the tab.

At the bottom of the dialog box on the Validation tab, you set the severity associated with this check failing (also known as a noncompliance event); these are the same levels previously described in the “Configuration Items” section.

Similar to the object validation criteria, every setting also has a validation tab. The primary difference is that with settings, you are not validating the existence of the setting; you are validating the value of the setting and specifying the expected value or values against which to validate the setting. This means you do not choose from a predefined set of properties to validate against; instead, the validation criteria specified are compared against the setting itself as defined on the General tab. As an example, for a Registry setting, the validation criterion that you specify on the Validation tab evaluates the Registry value you specify on the General tab.

One additional property to set for validation criteria on settings is the data type. With objects, you choose from a predefined list of properties so DCM knows what the data type is. With settings, there is no way for DCM to predetermine the data type to decide how the value is compared to expected values. Possible data types include the following:

• String

• Integer

• Date/Time

• Floating Point

• Version

The choice of data type also affects the operators available for the validation criteria, as noted earlier in this section.

The final section at the bottom of the Validation page is wholly enabled or disabled by checking Report a non-compliance event when this instance count fails. This setting performs an additional validation check by counting the number of objects that match the criteria specified on the General tab, and it raises another noncompliance event if the count does not fall within the criteria specified.

An example of this is definitely in order. Suppose that per organizational standard, each server must have at least two and no more than four SCSI drives, and these must be formatted with 512 bytes per sector. This is a check you will want in a DCM baseline. The following steps outline setting this up:

1. Navigate to Site Database -> Computer Management -> Desired Configuration Management -> Configuration Items in the ConfigMgr console tree.
2. Right-click the configuration item to add the check to and select Properties, or you can create a new one by right-clicking the Configuration Item in the tree and selecting New.
3. Open the Settings tab.
4. Click New near the bottom left of the tab and choose WQL Query from the pop-up menu.
5. On the General tab of the New WQL Query Settings Properties dialog box, fill in the criteria as follows (and as shown in Figure 16.23). This query returns a list of all the disk drives attached to the local system that are connected using a SCSI interface.

   • Namespace—rootcimv2

   • Class—Win32_DiskDrive

   • Property—BytesPerSector

   • WHERE clause—InterfaceType = ‘SCSI’.

   Figure 16.23. New WQL Query Settings Properties dialog box example

   
6. Open the Validation tab.
7. Select Integer for the Data Type setting at the top.
8. Choose New at the bottom left of the Details list.
9. Configure the Configure Validation dialog box as follows (and as shown in Figure 16.24):

   • Name—Check for 512 Bytes Per Sector

   • Operator—Equals

   • Value—512

   • Severity—Error

   Figure 16.24. Configure Validation dialog box example

   
10. Check the box labeled Report a non-compliance event when this instance count fails.
11. Change the Instance count operator to Between and enter 2 and 4 in the Values boxes.
12. Change the Severity to Error. Figure 16.25 displays the completed Validation tab.

    Figure 16.25. Validation example

    

This criterion causes a noncompliance event, with a severity of Error raised according to the stated criteria in step 12.

The biggest challenge when creating custom configuration items is translating the business requirement or user interface–based setting into items DCM expects and can act on. The most common place to store and query settings from is the Windows Registry. Other locations include WMI, Active Directory, and SQL Server. DCM, using one of the object or setting types can evaluate all of these and more.

However, how do you determine where to look in the first place? Many resources can help you with this endeavor. First and foremost is experience with Windows. An intimate knowledge of the Registry and of where Windows stores values will make your task much easier. The ability to write custom scripts and use WMI will also help tremendously. As the old cliché goes, “There’s no substitute for experience.”

Of course, even an intimate knowledge of these things does not mean you know every single Registry key or WMI class available. For that, there is TechNet and the World Wide Web in general. A number of excellent books are also available on these subjects.

Configuration items and baselines are stored in the SML XML format. SML is an industry-standard language specification that provides a rich method for modeling complex IT systems and services—see http://technet.microsoft.com/en-us/manageability/bb738088.aspx for in-depth coverage of SML, including the SML schema. Not all criteria modeled in SML can actually be displayed or edited with the built-in DCM toolset. However, because SML is the native language of DCM, these criteria are still evaluated and reported on properly.

DCM Digest is another XML format that DCM can use to define configuration items and baselines. DCM Digest is a Microsoft-proprietary modeling language that is dedicated to DCM; complete details of DCM Digest, including the schema, are available in the “DesiredConfigurationManagement_DigestAuthoring.doc” Microsoft Word document in the ConfigMgr SDK (downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyId=064A995F-EF13-4200-81AD-E3AF6218EDCC&displaylang=en_; you can also find the SDK by searching for ConfigMgr 2007 SDK at www.microsoft.com/downloads). ConfigMgr takes configuration data imported from DCM Digest, converts it, and stores it in the site database.

Authoring using one of these XML formats is beyond the scope of this book; please reference the links provided in this section for detailed information on this activity.

Why would anyone want to use SML or DCM Digest rather than the built-in editor? Here are several reasons:

The ability to author configuration data outside of the console definitely has some advantages, as discussed in the “External Authoring” section of this chapter. However, working directly with XML is fraught with issues and not an attractive option to most administrators or to individuals responsible for creating the baselines who may not even be technically inclined. This is where third-party products can be particularly useful; one particular product recommended by Microsoft and the authors of this book is Silect Software’s CP Studio (http://www.silect.com/).

CP Studio offers all the advantages of authoring configuration data outside the console without the requirement of needing to know XML. CP Studio also gives you the ability to create configuration data from an existing system using a profiling process that converts the current state of the system into a baseline. This profiling process enables you to configure a system to your organization’s exact standards and use CP Studio to create a baseline matching that configuration. After importing the created baseline into DCM, you can now verify that all your systems are identically configured with little effort.

CP Studio has three major features:

• Golden Master Creation Wizard— This wizard creates a configuration item from the current configuration of a specified system. The wizard prompts you to select which parts of the system to consider in creating the new baseline. The wizard cannot review every setting on a system because there are countless possibilities, but it does a very good job nonetheless. Figure 16.26 shows this wizard and the possible settings it can use to build the configuration item.

Figure 16.26. Validation example in CP Studio

• Criteria Builder— Perhaps the lengthiest part of actually developing a configuration item using the ConfigMgr built-in toolset is jumping around to other tools to build and verify criteria. As an example, to create Registry key object or settings checks, you need to use regedit (or some other Registry editor); for WMI queries you need to use WBEMTest, the Microsoft WMI tools, WMIC (or another tool); and the same goes for each other type of possible criteria.

CP Studio includes built-in criteria builders and browsers for each type of criteria listed in Tables 16.2 and 16.3. Therefore, you do not have to use an external tool to browse for values or create criteria. The built-in criteria builders connect to the local system or remote systems and greatly speed the process. Figure 16.27 displays the WMI query builder.

Figure 16.27. The CP Studio WMI query builder

• Baseline Testing— CP Studio has a built-in testing module that applies a selected baseline, on demand to the local or remote systems, which gives you instant results. This also greatly speeds the development life cycle of a baseline, because using the ConfigMgr toolset you first have to assign the baseline to a test collection, wait for the policy to be downloaded, and then manually log in to the system.

CP Studio does not enable you to build criteria that you cannot build with the ConfigMgr toolset. What it does, however, is offer a layer of abstraction that makes building the criteria easier and much quicker. With the addition of the testing module and Golden Master Creation Wizard, CP Studio can significantly reduce your development cycle for baselines and configuration items.

Building baselines and configuration items—using the built-in toolset, raw XML, or CP Studio—are technical tasks in DCM. Deciding how to use the baseline and configuration items best in your organization is more of a conceptual task that requires planning and forethought. The next section covers some strategies for doing so.

Reporting is the only built-in way to view the results of DCM evaluation and the compliance status of your systems according to your baselines. A variety of reports is included out of the box to assist with this, including the following:

Baseline and configuration item evaluation is a completely client-side task. The results of this task are returned to the site using the new state message mechanism built in to ConfigMgr. State messages are asynchronous messages sent from the client to the management point to report information back to the site. State messages for DCM include XML attachments to report specific details about the evaluation of configuration baselines and items. ConfigMgr consolidates these state messages in the database and makes the results available to end users in reports. See Chapter 18 for an in-depth look at reporting in ConfigMgr. With the excellent flexibility of the built-in classic reporting and the new SQL Reporting Services (SRS) reporting, rich reporting is available through a web browser without giving any type of access to the console. This is great for middle and upper management or those annoying auditors who interrupt you every time they need to see this data.

Knowing is half the battle; therefore, reporting is also typically only half the battle. What you do with the information in a report is the other half. Actions can include alerting to make everyone aware of the issue and using an automated mechanism to correct the reported issues.

In addition to using the server-side reporting functionality in ConfigMgr, administrative users can also trigger client-side report generation. After you enable DCM in the console, as described in the “Configuring Desired Configuration Management” section of this chapter, a new tab is available in the ConfigMgr Control Panel applet on all clients, titled Configurations (shown in Figure 16.28). Each baseline assigned to the client is included in the list box. Using the Evaluate button at the bottom of the page, users can trigger the evaluation of selected baselines. Using the View Report button, administrative users can display a report showing the most current evaluation results of the selected baseline. A typical use of this on-demand reporting is for IT personnel to locally troubleshoot or remediate identified noncompliance issues.

Figure 16.28. Configurations Control Panel applet tab

DCM, like ConfigMgr as a whole, is not designed to be a real-time reporting or alerting system. However, it is perfectly reasonable to want the results of DCM to raise a real-time alert. The easiest way to accomplish this is in conjunction with Operations Manager.

Three of the four noncompliance severity levels for evaluation criteria drop events into a system’s application event log as well as reporting back to ConfigMgr (as discussed earlier in the “Configuration Items” section of this chapter). One of OpsMgr’s bread-and-butter functions is to skim the event logs of monitored systems. Thus, it is simply a matter of creating a monitor and alert in OpsMgr to look for specific noncompliant events reported by DCM. The steps to create such a monitor and alert are discussed in detail in System Center Operations Manager 2007 Unleashed (Sams, 2008).

If OpsMgr is not present in your environment, you could also utilize custom scripts, another product that skims the event logs, or the great new ability in Windows Server 2008 to perform an action in response to an event.

Simply knowing about an issue using an on-demand report or receiving an alert doesn’t help if the issue identified is causing a security hole or service interruptions for users—what you want is to fix the issue as quickly as possible without human intervention. As was briefly touched on in the “Configurations” section of this chapter, remediation refers to the process of correcting an issue identified, and auto-remediation is having the issue corrected in an automated manner. In both cases, DCM identifies the issue using a baseline assigned to a system in your organization.

The following example creates a ConfigMgr collection based on the noncompliant events raised by a baseline:

ConfigMgr populates this new collection with systems that have a noncompliant evaluation result from the specified baseline or configuration item.

You can modify the preceding criteria to query for the severity of the compliance failure by using the ComplianceStateName property of the SMS_G_System_CI_ComplianceState class. For complete details of this class, see http://msdn.microsoft.com/en-us/library/cc143662.aspx.

After creating the collection, you create a software distribution package that corrects the issue and assign that package to the collection. The package could be as simple as setting a Registry key to a correct value or reinstalling the antivirus software that an application administrator accidentally on purpose uninstalled. The actual actions performed by the package are up to you and should correct any noncompliant issues that the baseline can identify. Those systems failing the compliance checks in the baseline populate the collection, which assigns them to the package correcting the issue.