The actual functionality of DCM is
relatively straightforward—create a baseline of settings and assign
those to a set of systems. However, what do you do then? It really
depends on what you are going to do with the data DCM provides.
What
are your business goals for using DCM? Are you simply filling a check
box for the auditors? Do you want to use reports to help in
troubleshooting? Are you wanting to notify the on-call admin when
something is amiss? Or do you want nonstandard configurations corrected?
Each baseline you create may fulfill one or more of these goals;
therefore, the first step for each baseline is to identify its purpose,
the target audience, and the delivery method for results. These
criteria will define what criteria to include in the baseline.
Reporting
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:
Noncompliance details for a configuration item on a computer
Compliance for a computer by baseline
Summary compliance by configuration baseline
Summary compliance by configuration item
Summary compliance for a collection by computer
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. 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.
Note: DCM Scenarios
Of
the four scenarios DCM addresses (regulatory compliance, pre- and
post-change verification, configuration drift, and time to resolution),
only one is not clearly addressed by the reports included out of the
box with ConfigMgr—and that is configuration drift. Results from every
compliance scan are stored in the ConfigMgr database, so the data for a
configuration drift report is indeed available.
However,
because of the simplistic single query-based approach, it would be
difficult, if not impossible, to use the legacy reporting component to
actually create a configuration drift report. The new SRS-based
reporting included with ConfigMgr 2007 R2 introduces the ability to
create sophisticated and complex reports, including a configuration
drift report.
Implementation of this report (or set of reports) is left as an
exercise for the reader (or a hint to the ConfigMgr development team).
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.
On-demand Results
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, a new tab is available in the ConfigMgr
Control Panel applet on all clients, titled Configurations (shown in Figure 1).
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.
Alerting
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 . 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.
Remediation
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. 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:
1. | Create
a new collection by right-clicking Collections in the console tree
(navigate to Site Database -> Computer Management -> Collections)
and selecting New Collection from the resulting context menu.
|
2. | In the New Collection Wizard, name your new collection and add an optional comment. Click Next.
|
3. | On the Membership Rules page, click the new query rule button to create a new query membership rule.
|
4. | On the resulting Query Rule Properties page, name the query and click the button labeled Edit Query Statement.
|
5. | On the Query Statement Properties dialog box, click the Show Query Language button at the bottom.
|
6. | Paste the following query into the text box:
select SMS_R_System.ResourceId,
SMS_R_System.ResourceType,
SMS_R_System.Name,
SMS_R_System.SMSUniqueIdentifier,
SMS_R_System.ResourceDomainORWorkgroup,
SMS_R_System.Client
from
SMS_R_System inner join SMS_G_System_CI_ComplianceState on SMS_G_System_CI_ComplianceState.ResourceID = SMS_R_System.ResourceId
Where
SMS_G_System_CI_ComplianceState.ComplianceStateName = "Non-Compliant"
and SMS_G_System_CI_ComplianceState.LocalizedDisplayName = "<BaselineName>"
|
7. | Replace <BaselineName> with the name of the baseline or configuration item you want to remediate.
|
8. | Click OK on the Query Statement Properties dialog box and OK again on the Query Rule Properties dialog box.
|
9. | Finish the New Query Wizard by clicking Next and then Finish.
|
10. | Finish the New Collection Wizard by clicking Next until the Finish button is enabled. Then click Finish.
|
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.
Note: Auto-remediation Capability
At
first glance, the lack of a built-in auto-remediation capability in DCM
may seem like a huge missing piece. However, the question to pose here
is, Do you really want the configuration of your working, production
systems automatically changed?
In most cases the answer is no,
at least not without restrictions. Although group policy does indeed
affect changes to systems, the extent of what DCM can check is far
greater than group policy and the ramifications are therefore larger.
Additionally, for those configuration items such as the existence of an
antivirus product, using this approach may not always be
straightforward to remediate.
Although
the next version of DCM will hopefully include some built-in
auto-remediation enablers, the lack of auto-remediation in the current
version does not take away from its usefulness and power.
