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.

<TypeDefinitions>
    <EntityTypes>
    <RelationshipTypes>
      <RelationshipType ID="QND.Compliance.HealthServiceReferenceOperatingSystem" Accessibility="Internal" Abstract="false" Base="System!System.Reference">
        <Source>SC!Microsoft.SystemCenter.HealthService</Source>
        <Target>Windows!Microsoft.Windows.OperatingSystem</Target>
      </RelationshipType>
    </RelationshipTypes>
    </EntityTypes>
</TypeDefinitions>

For the definition of our data source I prefer to be little more organized so I’m going to define a Probe embedding the script itself and then a DataSource based on the probe, I always build my data source this way to privilege code reusability, but obviously you’re free to directly embed the script in the data source. As you’ll see I always put my scripts inside a CDATA section this way I don’t have to encode / decode the script to edit them.

Let’s start, in the TypeDefinitions section let’s add a ModuleTypes section under the TypeDefinitions and then our probe module. The only member of our probe will be a ScriptPropertyBagProbe, the configuration section is straightforward and resembles the script parameters plus a script timeout value used by the ScriptPropertyBagProbe. We don’t need to define overridable parameters here since we do not plan to use the probe directly in the Management Pack Monitoring section:

<ModuleTypes>     
<ProbeActionModuleType ID="QND.OSQFEGet.PT" Accessibility="Public" Batching="false">
        <Configuration>
          <xsd:element name="OSVersion" type="xsd:string" />
          <xsd:element name="QFEList" type="xsd:string"  />
          <xsd:element name="WSHVersion" type="xsd:string" />
          <xsd:element name="ScriptTimeout" type="xsd:integer"  />
        </Configuration>
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="GetData" TypeID="Windows!Microsoft.Windows.ScriptPropertyBagProbe">
                <ScriptName>QND.GetOSCompliance.vbs</ScriptName>
                <Arguments>$Config/OSVersion$ "$Config/QFEList$" $Config/WSHVersion$</Arguments>
                <ScriptBody>
                  <![CDATA[Insert the script from Part 2 here ]]>
                </ScriptBody>
                <TimeoutSeconds>$Config/ScriptTimeout$</TimeoutSeconds>
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="GetData"/>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>   
</ModuleTypes>

Now that we have defined our probe type module let’s use it in a datasource, we are going to use the datasource in the monitor type. In the ModuleTypes section, let’s add the datasource right *before* the probe type. The datasource module will be composed with the previously defined probe type and a simple System.Scheduler module so that we can run our probe at specified intervals optionally synced at a specific time. So here we go:

      <DataSourceModuleType ID="QND.OSQFEGet.DS" Accessibility="Public" Batching="false">
        <Configuration>
          <xsd:element name="OSVersion" type="xsd:string"/>
          <xsd:element name="QFEList" type="xsd:string" />
          <xsd:element name="WSHVersion" type="xsd:string" />
          <xsd:element name="ScriptTimeout" type="xsd:integer" />
          <xsd:element name="IntervalSeconds" type="xsd:integer" />
          <xsd:element name="SyncTime" type="xsd:string" />
        </Configuration>
        <ModuleImplementation>
          <Composite>
            <MemberModules>
              <DataSource ID="Scheduler" TypeID="System!System.Scheduler">
                <Scheduler>
                  <SimpleReccuringSchedule>
                    <Interval>$Config/IntervalSeconds$</Interval>
                    <SyncTime>$Config/SyncTime$</SyncTime>
                  </SimpleReccuringSchedule>
                  <ExcludeDates />
                </Scheduler>
              </DataSource>
              <ProbeAction ID="GetData" TypeID="QND.OSQFEGet.PT">
                <OSVersion>$Config/OSVersion$</OSVersion>
                <QFEList>$Config/QFEList$</QFEList>
                <WSHVersion>$Config/WSHVersion$</WSHVersion>
                <ScriptTimeout>$Config/ScriptTimeout$</ScriptTimeout>
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="GetData">
                <Node ID="Scheduler"/>
              </Node>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
      </DataSourceModuleType>

Once again we don’t define overidable parameters; we’re going to do it in our unit monitor type.
That’s enough for today, in my next post I will add the unit monitor type, and some needed display strings and obviously the Management Pack manifest.

Hope that this post was helpful.