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:
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:
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:
Let’s create a folder to hold our class/discovery definitions:
Let’s now add a new item in there:
Let’s call it FehseClass_DefinitionOnly
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:
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:
<ClassType ID=”FehseClass.#text(‘AppNameID’)#.Application” Base=”Windows!Microsoft.Windows.LocalApplication” Accessibility=”Public” Abstract=”false” Hosted=”true” Singleton=”false”></ClassType>
<LanguagePack ID=”ENU” IsDefault=”true”>
<Name>FEHSE #text(‘AppDisplayName’)# Application</Name>
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:
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:
<Discovery ID=”FEHSEDis.#text(‘AppNameID’)#.Application” Enabled=”true” Target=”Windows!Microsoft.Windows.Server.OperatingSystem” ConfirmDelivery=”false” Remotable=”true” Priority=”Normal”>
<DiscoveryClass TypeID=”FehseClass.#text(‘AppNameID’)#.Application” />
<DataSource ID=”DS” TypeID=”Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider”>
<LanguagePack ID=”ENU” IsDefault=”true”>
<Name>FEHSEDis #text(‘AppDisplayName’)# Application Discovery</Name>
<Description>FEHSEDis #text(‘AppDisplayName’)# Application Discovery (Key: #text(‘AppRegistryKey’)#)</Description>
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:
Select the Proper Snippet Template:
Click on add a new item and put some information there:
Hit save and check the contents:
If you double click the mpx (fragment file) you should see this:
Let’s add the class Discovery:
And populate it with the same info:
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:
This way, it will show like that:
Ok, so, you should have a good code under here:
If not, check the error output window:
Informational messages are usually ok.
Before you compile it, make sure you configure the basic MP information:
Hit save and the click on the blue link:
Edit it, if needed. (remove dots, perhaps).
Now hit build.
Hopefully, you’ll see something like this:
Your final XML will be in your project folder under bin\Debug by default, but that can be changed in the Solution Properties:
Let’s add this to SCOM:
And after a little while, you should see your instances there. I have added the registry key to a couple of servers only:
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!