Using SCOM as a Basic Configuration Audit System – Part 5

In my first post I defined the following baselines to be checked for compliance:

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

While the first two are already discovered by standard management packs, the latter is missing, so we’re going to define a new class and discover it. There are plenty of choices here, but I chose to follow the pattern established by the Windows Server 2008 Management Pack in which the R2 operating system is derived from the Windows 2008 operating system.

This will be the new hierarchy:

Using SCOM as a Basic Configuration Audit System – Part 4

We are almost done with the types; we still need to define the HealthService to operating system relationship discovery data source and the monitor type for compliance checking.

The discovery data source is based on a handy condition detection module I found in the documentation: System.Discovery.RelationshipSnapshotDataMapper. In reality the documentation is not so clear since it misses an example that fits our situation, but with some management pack digging it’s not so difficult to end up with the correct usage. What we’re going to do is to combine a scheduler with the condition detection module to compose a data source we can use in discovery. The data source type just wraps the scheduler and the data mapper together and exposes the needed parameters, when we’ll define the discovery itself we’re just going to combine the key properties of both classes to obtain the relationship.

Using SCOM as a Basic Configuration Audit System – Part 3

Now that we have the core data provider in place we need to formalize the design defining the proper management pack constructs. In this post we will first define the loose relationship between the Operating System and the Health Service in such a way we can add a dependency monitor to the health service to project the compliance status, secondly we will define the data source embedding the script and the unit monitor type for compliance checking.

To define a loose relationship we’re going to define simple System.Reference relationship under the TypeDefinitions section. The source for the relationship is the HealthService and the target is the generic Microsoft.Windows.OperatingSystem class, I chose to define the relationship as “Internal” since I don’t think I will use it outside this Management Pack, but you define it as “Public” if you think this relationship is useful in general.

Using SCOM as a Basic Configuration Audit System – Part 2

The first step for our compliance management pack is to develop the core checking script. This is not to say that this must be the approach for every MP, probably a better start would be the health model, nevertheless I want to immediately check if there’s any show stopper in the core stuff so I will address the health model in the following post.

To build the script we need to keep in mind that:

• The output will be used to assess compliance on one side and to return data that can be used in reporting and in alerts to show what’s going on.
• The script must be generic enough to work across different OS versions, this is why we’re using vbscript

Using SCOM as a Basic Configuration Audit System – Part 1

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”.