As with all automated systems, many
assumptions are made about the environment where the system is
functioning. When these assumptions no longer hold true, the system
fails to operate as expected. DCM is an automated system and therefore
operates on certain assumptions. When issues arise, troubleshooting is
necessary to determine which assumption or assumptions are no longer
true.
Troubleshooting DCM, like the rest of
ConfigMgr, is largely a log file review exercise. Because DCM is a
client activity, the logs for DCM processing are on the client in the
client logs folder (%SystemRoot%\System32\CCM\Logs on 32-bit systems and %SystemRoot%\SysWOW64\CCM\Logs on 64-bit systems). Five log files are used by DCM to store activity; Table 1 describes these files.
Table 1. DCM Log Files
| Filename | Description |
|---|
| Dcmagent.log | Provides
high-level information about the evaluation of assigned configuration
baselines plus information regarding desired configuration management
processes |
| Ciagent.log | Provides information about downloading, storing, and accessing assigned configuration baselines |
| Sdmagent.log | Provides information about downloading, storing, and accessing configuration item content |
| Sdmdiscagent.log | Provides
high-level information about the evaluation process for the objects and
settings configured in the referenced configuration items |
| Discovery.log | Provides detailed information about the Service Modeling Language processes |
|
In addition to the normal logging available by default in the preceding logs, you can enable verbose and debug logging:
Verbose
logging adds extra detail and increases the descriptiveness of the log
entries made. Verbose logging also adds one additional client log file
that is specific to DCM, SmsClrHost.log, and one management point log
file, MP_GetSdmPackage.log. SmsClrHost.log includes details about
ConfigMgr’s use of the .NET Framework, which is required for DCM, and
MP_GetSdmPackage.log lists details about a management point’s retrieval
of DCM-specific package information. Debug logging is similar to verbose logging, but is typically meant for the developers of the component.
Enabling one or both of these can often provide you with that one extra clue that helps you solve an issue you are having.
You
can also enable an extra debug log file for DCM on the client. This
debug log file is not for the faint of heart, but can provide that
extra information needed to troubleshoot an issue. The format of this
file is XML. To enable this log file, add a REG_SZ value to
HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\SDMAgent named DebugFile and
set the value to the name of an output file (as an example, DCMdmp.xml).
None
of the preceding logging options should be enabled for normal operation
because they add overhead that can bog the client down.
|
In
addition to troubleshooting DCM itself, you will often have to
troubleshoot issues with the baselines and the configuration items they
contain. Issues involving the ability for DCM to evaluate a baseline or
configuration item are reported through the ConfigMgr status message
reporting mechanism. To view these status messages, perform the
following procedure:
1. | Navigate to Site Database -> System Status -> Status Message Queries in the ConfigMgr tree.
|
2. | In the resulting details pane on the right, right-click All Status Messages and select Show Messages.
|
3. | In the All Status Messages dialog box, enter the desired timeframe for which you would like to see status messages.
|
4. | Review the displayed messages looking for the message IDs listed in Table 1.
Table 1. DCM Status Message IDs| Message ID | Description |
|---|
| 11800 | Indicates a download failure for a configuration item | | 11801 | Indicates a hash failure for a configuration item | | 11802 | Indicates that the .NET Framework 2.0 is not installed | | 11850 | Indicates a download failure for SML content | | 11851 | Indicates the policy could not be uncompressed | | 11853 | Indicates
the client computer has evaluated one or more assigned configuration
baselines but cannot send the compliance results to its management point | | 11854 | A compliance change from noncompliant to compliant or from unknown to compliant | | 11855 | A compliance change to noncompliant with a noncompliance severity level of Information | | 11856 | A compliance change to noncompliant with a noncompliance severity level of Warning | | 11857 | A compliance change to noncompliant with a noncompliance severity level of Error | | 11858 | Indicates that packages for SML content could not be uncompressed | | 11859 | Indicates a failure in evaluating a configuration item | | 11860 | Indicates a failure in evaluating SML content | | 11861 | Indicates a failure in the SML discovery type process | | 11862 | Indicates the SML discovery type is halted | | 11859 | Indicates a failure in evaluating a configuration item | | 11860 | Indicates a failure in evaluating SML content |
|
Using the message IDs listed in Table 1,
you can narrow down issues DCM has when evaluating baselines and
configuration items. These status messages also provide the ability to
track and monitor the evaluation status of baselines in your site.
Note: .NET Framework
Not
having the correct version of the .NET Framework installed on a client
system can cause strange results that are difficult to troubleshoot.
The lack of the .NET Framework can clearly be identified by the status
messages returned by the client, but these are not always the first
place you look to troubleshoot issues.
Information
needed for DCM compliance scans often takes more than one client policy
refresh cycle to be fully staged to the client. During this period, the
status of the scan will not match your expectations for the result of
the scan; this is to be expected and should not be cause for alarm or
an extensive troubleshooting exercise. Patiently wait for an extra
policy refresh cycle, and DCM will dutifully report its results in full.
It
is often advantageous to trigger a DCM evaluation cycle on a remote
system without interactively connecting to that system and initiating
it from the Control Panel applet. The following code shows an example
of how to trigger every applicable baseline on a remote system using
VBScript:
system = "remote-system-name"
set objDCM = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ system & "\root\ccm\dcm:SMS_DesiredConfiguration") Set objSWbemServices = GetObject("winmgmts:\\" & system & "\root\ccm\dcm") Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM SMS_DesiredConfiguration")
For Each objSWbemObject In colSWbemObjectSet
objDCM.TriggerEvaluation objSWbemObject.Name,objSWbemObject.Version
Next
This
simple VBScript can easily be extended to connect to multiple systems
or to allow the choice of which baseline to trigger an evaluation on.
