SCOM Authoring–Simple Monitoring for IT Admins

If you are trying to transition from SCOM Authoring Console to Visual Studio Authoring Extensions, you may have found that the environment can be tough to start. However, when it catches up, you may even find it faster and easier to leverage daily monitoring requests.

You can get a bit of a ramp up in my previous articles:

http://overcast.fehse.ca/2014/02/quickstart-guide-to-scom-and-vsaeintroduction/

http://overcast.fehse.ca/2014/02/scom-vsae-authoringpart-1-vsae/

http://overcast.fehse.ca/2014/02/scom-vsae-authoringpart-2-classes-and-discoveries/

http://overcast.fehse.ca/2014/03/scom-vsae-authoringpart-3-interlude-snippet-templates/

In this article, I will try to put together the basic kit to monitor a custom application.

So, first a bit of structure. In order to optimize the usage of the snippets, it helps to have some structure. A few things come to mind:

– Have a naming convention

– Have a service offer document that reflects what you have in store

– Try to avoid custom monitors (you won’t be able to dodge that bullet, but you fight back a bit, at least)

 

For a basic monitoring, you will usually need some basic elements:

– Class (or classes): this will define your objects and their properties

– Discovery (or discoveries): the discoveries will find you objects in the environment

– Monitors and/or rules: will take care of doing the actual monitoring work and gathering data

– Views/Folders: what does a great MP made of? Presentation!

Now, let’s get to the juicy stuff. I will first create my Template project, where I will put all my templates and use as a starting point for new application monitoring projects.

I will call it SimpleApplicationTemplate. Open VS and click on File->New Solution:

image

I am going to use the 2012 MP template, just so it is backwards compatible with all 2012. You can also use the MPs in SCOM 2007, if you need to. Most of the basic objects are compatible. Please review the new objects in 2012. They won’t be compatible with SCOM 2007.

You should see something like this:

image

Let’s create a folder to hold our class/discovery definitions:

image

Let’s now add a new item in there:

image

Let’s call it FehseClass_DefinitionOnly

image

Note that VB will put a standard template content there, for a performance rule. We don’t care for that right now. Let’s era it all and use the code below.

For classes and discoveries, you can check Part II on the articles above. Also, For this article I will just ago ahead and shamelessly cheat. For that to work, I’m assuming I will have a registry key like this on the machines that are part of the application:

image

Also, my application class will be called:

FEHSEClass.[ApplicationNameID].Application and its display name will be “FEHSE [Application Name] Application”. For that to happen, some pieces of information will need to be provided:

 

Here’s the snippet for our standard application class:

<ManagementPackFragment SchemaVersion=”2.0″>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=”FehseClass.#text(‘AppNameID’)#.Application” Base=”Windows!Microsoft.Windows.LocalApplication” Accessibility=”Public” Abstract=”false” Hosted=”true” Singleton=”false”></ClassType>
</ClassTypes>
</EntityTypes>
</TypeDefinitions>
<LanguagePacks>
<LanguagePack ID=”ENU” IsDefault=”true”>
<DisplayStrings>
<DisplayString ElementID=”FehseClass.#text(‘AppNameID’)#.Application”>
<Name>FEHSE #text(‘AppDisplayName’)# Application</Name>
<Description></Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

An important thing to note is that I need two pieces of information for the application name. SCOM is picky about the characters you can use in the ID, so, to make things neat, I’m collecting the display name as well.

It should look like this in the console:

image

Now that you have the classes, let’s create a discovery. And puf! There you have it.

Here’s the Class discovery code. Note that I’m adding a new peace of information: the Registry key’s content, which will define the application existence:

<ManagementPackFragment SchemaVersion=”2.0″>
<Monitoring>
<Discoveries>
<Discovery ID=”FEHSEDis.#text(‘AppNameID’)#.Application” Enabled=”true” Target=”Windows!Microsoft.Windows.Server.OperatingSystem” ConfirmDelivery=”false” Remotable=”true” Priority=”Normal”>
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID=”FehseClass.#text(‘AppNameID’)#.Application” />
</DiscoveryTypes>
<DataSource ID=”DS” TypeID=”Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider”>
<ComputerName>$Target/Host/Property[Type=”Windows!Microsoft.Windows.Computer”]/NetworkName$</ComputerName>
<RegistryAttributeDefinitions>
<RegistryAttributeDefinition>
<AttributeName>AppName</AttributeName>
<Path>SOFTWARE\FEHSECORP\AppName</Path>
<PathType>1</PathType>
<AttributeType>1</AttributeType>
</RegistryAttributeDefinition>
</RegistryAttributeDefinitions>
<Frequency>3600</Frequency>
<ClassId>$MPElement[Name=”FehseClass.#text(‘AppNameID’)#.Application”]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name=”Windows!Microsoft.Windows.Computer”]/PrincipalName$</Name>
<Value>$Target/Host/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name=”System!System.Entity”]/DisplayName$</Name>
<Value>$Target/Host/Property[Type=”Windows!Microsoft.Windows.Computer”]/NetbiosComputerName$</Value>
</Setting>
</Settings>
</InstanceSettings>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type=”String”>Values/AppName</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type=”String”>#text(‘AppRegistryKey’)#</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</DataSource>
</Discovery>
</Discoveries>
</Monitoring>
<LanguagePacks>
<LanguagePack ID=”ENU” IsDefault=”true”>
<DisplayStrings>
<DisplayString ElementID=”FEHSEDis.#text(‘AppNameID’)#.Application”>
<Name>FEHSEDis #text(‘AppDisplayName’)# Application Discovery</Name>
<Description>FEHSEDis #text(‘AppDisplayName’)# Application Discovery (Key: #text(‘AppRegistryKey’)#)</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

Complicated? A bit. Lots of text. But you get used to it.

With that, here’s how you put things together:

Add now a Snippet Data object:

image

Select the Proper Snippet Template:

image

Click on add a new item and put some information there:

image

Hit save and check the contents:

image

If you double click the mpx (fragment file) you should see this:

image

Let’s add the class Discovery:

image

image

And populate it with the same info:

image

It is important that the AppNameID entries match between snippets. This is the base of your application monitoring. Remember: Structure!

Another interesting fact: the prompts will show up in the order they appear in the code, so, if you want them to be consistent, add a comment to the beginning of the snippet, like this:

image

This way, it will show like that:

image

Ok, so, you should have a good code under here:

image

If not, check the error output window:

image

Informational messages are usually ok.

Before you compile it, make sure you configure the basic MP information:

image

Hit save and the click on the blue link:

Edit it, if needed. (remove dots, perhaps).

image

Now hit build.

Hopefully, you’ll see something like this:

image

Your final XML will be in your project folder under bin\Debug by default, but that can be changed in the Solution Properties:

image

Let’s add this to SCOM:

image

And after a little while, you should see your instances there. I have added the registry key to a couple of servers only:

image

In part II (yes, part II, otherwise, it bores people to death) I will create a rule and a monitor template (tipically service and eventlog).

Hope this helps!