Category Archives: VSAE Fragment

Authoring, VSAE Fragment

Filtered Registry Discovery Provider

2 Comments

AKA: Microsoft.Windows.FilteredRegistryDiscoveryProvider

This is the third post in the new VSAE Fragment category. The provider is used to discover a class type and its properties by reading keys and values from the Windows registry.

What does it do?

This particular fragment can be used to discover the class type discuss here. It demonstrates how to discover different types of properties: Integer, String, and Double (or decimal).

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Monitoring>
    <Discoveries>
      <Discovery ID="SCOMskills.Demo.FilteredRegistry.Discovery" Target="Windows!Microsoft.Windows.Computer" Remotable="true" Enabled="true">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="SCOMskills.Demo.FilteredRegistry.Class">
            <Property PropertyID="IntegerProperty"/>
            <Property PropertyID="StringProperty"/>
            <Property PropertyID="DoubleProperty"/>
            <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>
          </DiscoveryClass>
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider">
          <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
          <RegistryAttributeDefinitions>
            <!--===============================================================================-->
            <!--Define registry keys, values, and types.                                       -->
            <!--Path and attribute types: http://msdn.microsoft.com/en-us/library/jj130492.aspx-->
            <!--===============================================================================-->
            <RegistryAttributeDefinition>
              <AttributeName>SCOMskillsKeyExists</AttributeName>
              <Path>SOFTWARE\SCOMskills</Path>
              <PathType>0</PathType>
              <AttributeType>0</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>IntegerValue</AttributeName>
              <Path>SOFTWARE\SCOMskills\Integer</Path>
              <PathType>1</PathType>
              <!--reg_dword, any integer value-->
              <AttributeType>2</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>StringValue</AttributeName>
              <Path>SOFTWARE\SCOMskills\String</Path>
              <PathType>1</PathType>
              <!--reg string-->
              <AttributeType>1</AttributeType>
            </RegistryAttributeDefinition>
            <RegistryAttributeDefinition>
              <AttributeName>DoubleValue</AttributeName>
              <Path>SOFTWARE\SCOMskills\Double</Path>
              <PathType>1</PathType>
              <!--reg string, value can be a double or integer-->
              <AttributeType>3</AttributeType>
            </RegistryAttributeDefinition>
          </RegistryAttributeDefinitions>
          <Frequency>60</Frequency>
          <ClassId>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]$</ClassId>
          <!--========================================-->
          <!--Map registry filters to class properties-->
          <!--========================================-->
          <InstanceSettings>
            <Settings>
              <Setting>
                <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
                <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/IntegerProperty$</Name>
                <Value>$Data/Values/IntegerValue$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/StringProperty$</Name>
                <Value>$Data/Values/StringValue$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="SCOMskills.Demo.FilteredRegistry.Class"]/DoubleProperty$</Name>
                <Value>$Data/Values/DoubleValue$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
                <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$</Value>
              </Setting>
            </Settings>
          </InstanceSettings>
          <!--=========================================================-->
          <!--Discover class instance if SCOMskills registry key exists-->
          <!--=========================================================-->
          <Expression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type="Boolean">Values/SCOMskillsKeyExists</XPathQuery>
              </ValueExpression>
              <Operator>Equal</Operator>
              <ValueExpression>
                <Value Type="Boolean">true</Value>
              </ValueExpression>
            </SimpleExpression>
          </Expression>
        </DataSource>
      </Discovery>
    </Discoveries>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <!--============================================================-->
      <!--Provide friendly display names for elements in this fragment-->
      <!--============================================================-->
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Discovery">
          <Name>Filtered registry class discovery.</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Discovery" SubElementID="DS">
          <Name>Filtered registry discovery data source</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Authoring, VSAE Fragment

Microsoft Windows Local Application class type

2 Comments

AKA: Microsoft.Windows.LocalApplication

This is the second post in the new VSAE Fragment category. The purpose of these types of posts is to provide a practical demonstration of how to create your own fragment library. I find this useful in management pack authoring, because it’s much easier to add and modify an existing fragment than to create elements and modules from scratch each time.

What does it do?

This may be the most common base classes used for a seed class. It’s easy to implement, because it doesn’t require you to create a hosting relationships. This base class *will* rollup to the windows computer class, as a local application. So, do not choose this as a base if you do not want your application to rollup to windows computer! This is considered a concrete class, and rolls up to windows computer.

Go here for a fragment that will discover this class type using the filtered registry discovery module.

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <!--=======================================-->
        <!--Define application class and properties-->
        <!--=======================================-->
        <ClassType ID="SCOMskills.Demo.FilteredRegistry.Class" Abstract="false" Accessibility="Public" Base="Windows!Microsoft.Windows.LocalApplication" Hosted="true" Singleton="false">
          <Property ID="IntegerProperty" Key="false" Type="int" />
          <Property ID="StringProperty" Key="false" Type="string" />
          <Property ID="DoubleProperty" Key="false" Type="double" />
        </ClassType>
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <!--============================================================-->
      <!--Provide friendly display names for elements in this fragment-->
      <!--============================================================-->
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class">
          <Name>SCOMskills Demo Filtered Registry Class</Name>
          <Description>Demonstration of Microsoft.Windows.FilteredRegistryDiscoveryProvider</Description>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="IntegerProperty">
          <Name>Integer Property</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="StringProperty">
          <Name>String Property</Name>
        </DisplayString>
        <DisplayString ElementID="SCOMskills.Demo.FilteredRegistry.Class" SubElementID="DoubleProperty">
          <Name>Double Property</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

Authoring, VSAE Fragment

Visual Studio Authoring Extensions – Fragments, fragments, fragments!

1 Comment

All management pack authoring I do is by using fragments. In my opinion, fragments are the most flexible authoring element in the VSAE, as they offer full visibility into the XML code and the ability to create a library of useful fragments that can later be reused in other management packs.

I’m kicking off a new blog category named VSAE Fragment. The purpose of these types of posts is to give practical examples of using modules that are defined in OpsMgr management pack libraries, as well as how to piece together custom modules for composite workflows. MSDN already has a library of module examples here, but sometimes I find myself searching to fill in some blanks. Hopefully this will help others as much as they help me.

I’m starting the VSAE Fragment category by providing the most basic, and essential fragment I use in every new management pack: the mp.DisplayName fragment.

What does it do?

Provides a friendly management pack display name and description in the Operations console.

 

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SCOMskills.Demo">
          <Name>SCOMskills Demo</Name>
          <Description>A demo management pack.</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>
Authoring, VSAE Fragment

Starting a Fragment Library using Visual Studio Authoring Extensions

1 Comment

Started using Visual Studio Authoring Extensions recently for all MP authoring, and leaving the Authoring Console behind since it is no longer supported.

I still can’t get used to the templates that are included with VSAE, so I like to create empty management pack fragments. I do this in order to create a library of fragments that I can easily add to management packs in the future.

In this example, I will demonstrate how to start a fragment library by adding a powershell write action that will be used in a scheduled powershell rule.

Create a new Operations Manager 2012 add-on project and add a couple folders to the solution: modules and rules. Then create a new item in the modules folder.

image

Add a new empty management pack fragment.

image

Give it a logical name, like Powershell Write Action, and enter code similar to the following.

 

<ManagementPackFragment SchemaVersion=”2.0″ xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<TypeDefinitions>
<ModuleTypes>
<WriteActionModuleType ID=”YourMp.YourPowershellWriteAction” Accessibility=”Internal” Batching=”true”>
<Configuration>
<xsd:element minOccurs=”1″ name=”TimeoutSeconds” type=”xsd:integer” />
<xsd:element minOccurs=”1″ name=”YourScriptParamter1″ type=”xsd:string” />
<xsd:element minOccurs=”1″ name=”YourScriptParamter2″ type=”xsd:string” />
</Configuration>
<OverrideableParameters>
<OverrideableParameter ID=”TimeoutSeconds” Selector=”$Config/TimeoutSeconds$” ParameterType=”int” />
<OverrideableParameter ID=”YourScriptParamter1″ Selector=”$Config/YourScriptParamter1$” ParameterType=”string” />
<OverrideableParameter ID=”YourScriptParamter2″ Selector=”$Config/YourScriptParamter2$” ParameterType=”string” />
</OverrideableParameters>
<ModuleImplementation>
<Composite>
<MemberModules>
<WriteAction ID=”WA” TypeID=”Windows!Microsoft.Windows.PowerShellWriteAction”>
<ScriptName>ScriptName.ps1</ScriptName>
<ScriptBody>
<![CDATA[
Param(
[string]$YourScriptParamter1,
[string]$YourScriptParamter2
)
Do stuff
]]>
</ScriptBody>
<Parameters>
<Parameter>
<Name>YourScriptParamter1</Name>
<Value>$Config/YourScriptParamter1$</Value>
</Parameter>
<Parameter>
<Name>YourScriptParamter2</Name>
<Value>$Config/YourScriptParamter2$</Value>
</Parameter>
</Parameters>
<TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
</WriteAction>
</MemberModules>
<Composition>
<Node ID=”WA” />
</Composition>
</Composite>
</ModuleImplementation>
<InputType>System!System.BaseData</InputType>
</WriteActionModuleType>
</ModuleTypes>
</TypeDefinitions>
</ManagementPackFragment>

Of course, add you script in the script body section. This is an example that will pass in two parameters to the script.

Now add another new empty management pack fragment to the rules folder, and enter code similar to the following.

<ManagementPackFragment SchemaVersion=”2.0″ xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<Monitoring>
<Rules>
<Rule ID=”YourMp.YourPowershellRule” Enabled=”true” Target=”YourMp.YourClass” ConfirmDelivery=”true” Remotable=”true” Priority=”Normal” DiscardLevel=”100″>
<Category>Operations</Category>
<DataSources>
<DataSource ID=”Schedule” TypeID=”System!System.SimpleScheduler”>
<IntervalSeconds>600</IntervalSeconds>
<SyncTime />
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID=”WA” TypeID=”YourMp.YourPowershellWriteAction”>
<TimeoutSeconds>300</TimeoutSeconds>
<YourScriptParamter1>first parameter to pass into script</YourScriptParamter1>
<YourScriptParamter2>second parameter to pass into script</YourScriptParamter2>
</WriteAction>
</WriteActions>
</Rule>
</Rules>
</Monitoring>
</ManagementPackFragment>

This rule uses a scheduler as a data source and your new powershell write action module. Remember to fill in the script paramter elements after the script body – this is how the parameter are actually passed into the script.

If you continue saving new fragments to this library project, you can easily add these to your management pack projects in the future by adding an existing item and navigating to your library project.

This is your starter fragment library.

image