Search This Blog

Monday 3 June 2013

Using SCOM as a Basic Configuration Audit System – Part 1


As of 01/05/2017, this blog will not be updated or maintained

I’m going to start a series of articles, I don’t know how many yet, on how to use your OpsMgr infrastructure to check for proper configuration of the managed systems. Then number of posts will be based on how much I can write in one hour. 

The basic need started with the growing number of patches needed to guarantee a complete and hassle free monitoring experience “Things to make and do for agent health”. 


Obviously OpsMgr is not the first choice tool to solve this kind of problem, it has not any standardized building block or formal architecture whereas System Center Configurations Manager has. So if you have SCCM agents deployed on the same systems managed by OpsMgr this series of posts is not for you, you better use the SCCM DCM feature to address the compliance checking and if you have Service Manager in place then you can have the formal plumbing, too.

This first instalment will set the scope of this project and some background on the health model needed.
At the end of our effort we’ll have a management pack that will address these requirements:

  • it needs to check for a minimum service pack level given a specific operating system
  • it needs to check for the presence of a set of patches for a given operating system and service pack level
  • optionally it needs to integrate the health model of OpsMgr agent (HealthService) with the compliance level
  • it needs to report on non-compliant systems with a detailed status regarding missing patches

For the sake of these posts I will concentrate on Windows Server 2008 and Windows Server 2008 R2, but the same technique can be applied to other systems (for example Windows 2003), for this reason I will use vbscript instead of powershell for any scripting needed. Moving away for the official support statement for OpsMgr I will target any reporting need to SQL Server 2008 schema, so the reports will work on SQL Server 208 and superior, but not on SQL Server 2005.

Regarding the health model I’ll need to set a new baseline (with baseline I’m referring to the operating system + service pack combination) for R2 SP1, the baselines I’m going to tackle are:

  • Windows Server 2008
  • Windows Server 2008 R2 RTM
  • Windows Server 2008 R2 with Service Pack 1

For these baselines I’ll set up a monitor (targeted at the OS) under the configuration branch to assess the proper agent compliance.


At the same time I’ll establish a loose relationship with the HealthService to project the compliance status to the agent health. This projection will be disabled by default.


The next post will address the core scripting needed to assess the compliance level.

Hope that this post was helpful.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.