The overall theme of this series on SCCM Desired Configuration Management has been to provide you with a low-level understanding of the mechanics of DCM, give you a sense of the wider business context in which it is useful, and give you the tools to pursue your own enterprise IT management goals. This final post covers one additional freely-downloadable baseline, no great shakes in and of itself, but emblematic of what the future likely holds: plugging third party baselines into DCM to validate our organization’s compliance with a neutral standard. We then conclude with a technique for helping to make PCs self-remediating when they are found to be out-of-compliance.
ENERGY STAR Power Management Configuration Pack
Not all DCM baselines are security-related. As organizations, or society, decide that some aspect of enterprise computing is worthy of attention, baselines evolve to help IT auditors and administrators keep their eye on the ball. A simple example is PC power management. While not yet updated for Windows 7, the government’s ENERGY STAR recommendations for PCs are still worth looking at and this example shows how to adapt an older baseline for our own purposes.
The SCCM DCM management pack (a CAB file ConfigMgr2007MAEnergyStar.cab that you import into DCM and an MS Word doc) is available at: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c8324323-2159-4e49-988c-3505653eaa26. After running and unpacking the MSI download, copy ConfigMgr2007MAEnergyStar.cab to the SCCM server and import it similarly to what we did with the SCM security baseline:
As you can see, officially the baseline has never been updated for Windows 7. The Vista settings are still applicable but the Configuration Items are hard-coded for XP and Vista. To use the Vista CI, we’ll clone it to “ENERGY STAR Guideline: Windows 7”, change its applicability domain, and create a new baseline with two Configuration Items (including the screensaver recommendation, which is OS-independent):
Having done this and run the report, I found it less useful than hoped – it turns out there weren’t many recommended settings and I didn’t find the report terribly informative. However, one reason that third party baselines are worth looking at is that they provide you with ideas. In this case, it was interesting to see how the underlying energy efficiency query was done via script:
I won’t go into it here, but now that we have an example of how to perform a power efficiency audit, it should be easy to adapt the CI queries for our own organization’s needs (yes, there are “green IT initiative” products out there that can do an even better job, but they’re not cheap and you do basic due diligence yourself for free; I should mention, however, that SCCM 2007 R3 has nice power management and monitoring capabilities in its own right). The overall theme of this section is that you may need to incorporate third party compliance baselines in your DCM implementation and that they can be adapted for your own purposes.
Our final topic is that Holy Grail of enterprise IT: hands-off, self-managing systems. This series on DCM has discussed the notion of baselines and configuration drift. We haven’t yet discussed the obvious question of what to do about PCs that are found to be out of compliance. Besides generating reports, wouldn’t it be nice if non-compliant PCs could automatically repair themselves? Features built into SCCM and DCM make this easy to accomplish.
Before discussing the solution, here’s some background and context.
Systems Center Service Manager
Microsoft’s System Center Service Manager (SCSM), which became available in mid-2010, provides powerful integration with SCCM DCM (as well as many other parts of the SCCM suite) but it is pricey. SCSM can detect and provide high-level workflows for dealing with DCM configuration drift, including remediation, corporate incident response notification, and compliance with audit requirements. At present, though, many more companies use SCCM than SCSM, and SCSM’s additional licensing cost is likely to keep things this way for some time to come.
Nevertheless, a very nifty feature built into DCM, the ability to automatically create an SCCM collection based on compliance (or non-compliance) with an arbitrary DCM baseline, provides the ability to emulate a key aspect of SCSM’s DCM incident handling capability: auto-remediation of configuration drift. This is what we’ll be discussing in a moment.
Suppose a PC hasn’t had Windows Updates in a while and is behind on its antivirus signatures. This is analogous to DCM configuration drift and, in fact, could be the subject of a DCM baseline. It is also the very subject of Microsoft’s Network Access Protection (NAP) capability. In the case of NAP, PCs that don’t comply with certain indicators of PC health are not allowed to attach to the main LAN but instead are only permitted to talk to remediation servers such as WSUS. Though NAP has been around for years, it is tricky to use and has never achieved widespread adoption in enterprise networks.
Yet another way of accomplishing of auto-remediation is scripts that run on PCs and correct problems as they are encountered. SCCM clients can run arbitrary commands so auto-remediation by SCCM agents at runtime is certainly a possibility. The problem with scripted runtime solutions is that they tend to be one-offs, with no reporting capability or shared solution framework. Microsoft’s Systems Center Operations Manager (SCOM) provides the ability to monitor and address problems in real-time, but again it is a pricey offering that is separate from SCCM. It’s also mainly used for servers, not PCs.
DCM, dynamic SCCM collections and auto-remediation
Built right into the DCM GUI is the ability to create an SCCM collection based on non-compliance with a baseline. In turn, SCCM packages and things like OS deployment task sequences can be targeted at collections. This virtuous circle creates an easy way to perform simple, but effective, auto-remediation of configuration drift.
Here’s how to create a dynamic collection from within DCM:
Here’s our new collection:
Now it’s just a question of what actions to advertise to this collection. You might want to advertise certain SCCM packages or OS deployment task sequences (which are very flexible and provide the ability to run arbitrary commands, something very useful for complex auto-remediation scenarios).
I won’t go into the details behind the following example solution — at this point you should be well-prepared to follow through on your own — but if you have Operating System Deployment and Windows Updates capabilities configured into SCCM, which many companies do, you can create a Task Sequence to advertise all mandatory software updates and assign it to your collection of non-compliant laptops. You might call this “NAP remediation Lite” without the traditional headaches of NAP.
This concludes our series on SCCM’s Desired Configuration Management feature. SCCM 2012 adds additional capabilities to DCM, which might be a good topic for a future blog post. But even with what exists today in SCCM 2007 DCM, your imagination is the only limit. Thanks for coming along on the ride and happy baselining!