Using SCOM as a basic configuration audit system – Part 3 types


 

Previous posts on the subject:

 


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 overridable 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, some needed display strings and obviously the Management Pack manifest.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

About these ads
  1. Using SCOM as a basic configuration audit system – Part 6 monitoring « Quae Nocent Docent
  2. Using SCOM as a basic configuration audit system – Part 5 discoveries « Quae Nocent Docent
  3. Using SCOM as a basic configuration audit system – Part 4 more types and strings « Quae Nocent Docent

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 349 other followers

%d bloggers like this: