Architecture of the Desired Configuration Monitoring - DCM Solution
The diagram below gives an overview of the DCM Solution architecture. This post basically explains what the different components of the DCM Architecture are and how they talk to each other to get the whole stuff working!
1. Install DCM. You can install the solution by using the Microsoft Windows Installer package DCMSolutionSetup.msi. You can install all the three components of the DCM Solution (Engine, UI Authoring tool and the Reports Component) based on the appropriate pre-requisites.
2. Create the DCM manifest. Use the DCM Authoring Tool to create the DCM knowledge (configuration document). Using this tool, you can add, remove, or modify configuration settings and rules based on data from the registry, metabase, Active Directory, WMI, and file system. The DCM Authoring Tool generates the XML manifest. This xml manifest also called the knowledge is consumed by the DCM Command line wrapper (the engine) for performing compliance checks.
3. Create the SMS 2003 package, program, and advertisement to deploy DCM. Once you have the DCM knowledge created (as part of step 2), you can deploy it along with the DCM engine using SMS 2003. The following are high-level steps for doing this:
a. Create an SMS 2003 package containing the DCM engine, supporting files and the knowledge.
b. Create an SMS 2003 program to schedule the DCM engine to run at a specified interval.
c. Create an SMS 2003 advertisement to advertise the package to the targeted collection of servers in your organization.
4. Deploy the SMS package to each managed node. Target the package to an SMS 2003 collection of servers in you organization.
5. Have SMS collect out-of-compliance data that is logged to WMI on each managed node. Once the engine is running at a scheduled interval on each of the deployed servers, any time out-of-compliance is detected; an entry will be logged to WMI and the Windows NT Event Log.
Use the included script to modify the SMS_def.mof on the site server, so that SMS can collect out-of-compliance data that is logged on each managed node through the hardware inventory process. The included script if executed will modify the SMS_def.mof file to include definitions of the DCM specific classes and compile the same.
6. Run reports. Once the data is collected by hardware inventory, the DCM specific data would be available in the SMS database. After this the DCM DTS packages will need to be executed so as to transfer the appropriate data from the SMS database to the DCM Solution database. After the data has been transferred to the DCM Solution database, run out-of-compliance/in-compliance reports included with DCM. In addition, if you have MOM installed, you can create a MOM rule to create an alert any time out-of-compliance is detected and logged into the Windows NT Event Log.
The above description gives you an idea of what is the architecture of DCM and how different components talk with each other. That should also give you enough information so that you can troubleshoot your DCM installation in your organization. Thanks!