VSAE – Overcast

Service Discovery and Monitoring with Operations Manager

One of the most frequent requests we get from customers is to create monitor for application services. Often enough you will find management packs for well know applications, but if you can’t, you will need to create those by yourself. With that, you have basically two options: use the provided Authoring Template in the SCOM console, which has been extensively described on the internet or create monitors in the same authoring area of SCOM, but using an existing target, like Windows Operating system or Windows Computer.

The first option is good because SCOM will not only monitor the services, but it will also create a discovery for those services and make them available to be listed as independent objects in a State view, for example. The cons of this approach is that if you have a lot of services, a lot of work will be required to create all the monitors. It also uses a lot more resources to discover the services, since for each monitored service, you a discovery will be added. This template is also good if you want CPU and and memory monitoring for the services, which are available through the template as well.

With the second option, which much leaner in terms o resources, the con is that the services themselves do not become objects themselves. The monitors for each one of them will be visible in the Health Explorer only. Alerts will work normally though.

What should you do then?

Well, there is a third option, which will require some XML edition and authoring skills. I’ve been using this for different customers and it has a good feedback. To build this solution, I’m using Visual Studio 2015 with the Management Pack Authoring extensions.

It all starts with a Class definition:

This one defines a computer class that will host the services. And now the services themselves:

Next, I will need two discoveries, one to discover the computers and then, another one to discover the services. This could be condensed in a single script discovery, but WMI is less expensive than scripts in terms or CPU cycles.

First the computer discovery:

Make sure you pick the right service prefix in the WMI query part, to properly identify the computers that belong to that class.

This discovery will then scan all computers that are part of the Windows Server Operating System Class every 15 minutes. Once one machine with that services mentioned above is found, a new instance of the Company.Application.Class.Computer class will be created.

And the service discovery itself:

This discovery will scan all the previously discovered computers that belong to the Company.Application.Class.Computer class and look for the services according to the WMI query. Once any of the services is found, a new member of the Company.Application.Class.Service is discovered and the properties are mapped:

Having Service objects as entities by themselves makes it easy to monitor, since you can only create a single monitor that targets all the objects:

And that is pretty much it. The remaining pieces of the MP references, presentation and display strings. Make sure to customize the IDs and messages according to your needs.

The final MP can be found here.

Hope this helps!

SCOM, Management Pack bundles and VSAE

I have learned this neat trick at a customer site this week. With SCOM 2012 came the possibility of creating management pack bundles, which are capable of carrying the typical MP content, but also files, scripts,etc. The customer uses it to distribute and automate SCOM agent updates (due to some network restrictions, pushing and updating from the console is limited) and the builds also include the agent, so they are by default manual installations (they could be reverted, but…).

But we can imagine other situations, where you need to distribute a file or package, copy it to a certain location, run it, etc. A special Hosts file (yes, there are some apps that still need that kind of thing).

Well, to simplify the example, I will include the steps to create an MP, embed a simple text file, create a script that copies the file to another location in the target server every 900 minutes, package all that and import into SCOM.

First step. Understanding the elements:

Resources:

A file or file of any kind and a resource definition fragment

Write Actions:

Responsible for actually deploying the file to the agent or agents.

Rule:

Needed, to execute the Write Action in a Schedule

Script:

Responsible for taking care of the content on the agent

Let’s go to the steps. If you are not too familiar with Visual Studio Authoring Extensions, please review previous posts on my blog.

In Visual Studio 2012 or 2013, with VSAE installed, create a new solution:

And select as below:

Remember to name it before hitting OK!

Right-click your project name and add 4 new folders:

– Resources

– Scripts

– Write Actions

– Rules

It should look like that.

In the resources folder, right-click and add new Item.

Select Code on the left column then Empty Management Pack Fragment in the center column. Name it Resources.mpx

Replace all of the code with the code below:

NOTE: the Filename=”xxx” property must match exactly the name of the file that will be in the package.

Right-Click the Resources folder again and click on Add Existing item and add the example text file:

It should look like this:

Now select the text file and change the property as below:

Right-Click the Scripts folder and create a new item.

Select Script as below and name it DeployFile.vbs:

Past the code below:

Option Explicit

Dim fso                          ‘File System Object
Dim wshShell                     ‘Windows shell script object
Dim objMOMAPI                    ‘MOM API object
Dim strScriptName                ‘Script name
Dim wshArguments                 ‘Arguments object
Dim strMsg                       ‘Generic message variable
Dim strComputerName              ‘Computer name
Dim srcFilePath                  ‘FQPN of source file to be copied to agent target
Dim dirTarget                    ‘Target folder to place the downloaded bundle file

‘Constants used for event logging with MOM.ScriptAPI
Const INFO         = 0
Const C_ERROR     = 1
Const WARNING     = 2

On Error Resume Next

Set fso           = CreateObject(“Scripting.FileSystemObject”)
Set wshShell      = CreateObject(“Wscript.Shell”)
Set objMOMAPI     = CreateObject(“MOM.ScriptAPI”)

strScriptName = “DeployFile.vbs”
strComputerName = wshShell.ExpandEnvironmentStrings(“%ComputerName%”)

Call objMOMAPI.LogScriptEvent(strScriptName, 999, INFO, “Script started”)

‘Only run this script on a specific server for unit testing
If strComputerName <> “DC01” Then
Call objMOMAPI.LogScriptEvent(strScriptName, 999, INFO, “Unit Testing DC01 not detected”)
wscript.Quit
End If

Set wshArguments = Wscript.Arguments

If wshArguments.Count = 2 Then
   srcFilePath    = wshArguments(0)
   dirTarget      = wshArguments(1)
Else
   strMsg = “Error: 2 Arguments was expected for this script.” _
          & vbCRLF & “Syntax: ” & strScriptName & ” <SourceFilePath> <TargetDirectory>”
   Call objMOMAPI.LogScriptEvent(strScriptName, 999, C_INFO, strMsg)
   strMsg = “Script ABORTED”
   Call objMOMAPI.LogScriptEvent(strScriptName, 999, INFO, strMsg)
   wscript.Quit (1)
End If
strMsg = “Will Try to copy file.” _
          & vbCRLF & “From: ” & srcFilePath & ” To: ” & dirTarget

Call objMOMAPI.LogScriptEvent(strScriptName, 999, INFO,strMsg)

fso.CopyFile srcFilePath, dirTarget
Call TrapVBScriptError (“FileCopy”)

Sub TrapVBScriptError (ByVal mstrErrorLabel)
If Err.Number <> 0 Then
ErrCount = ErrCount + 1
strMsg = mstrErrorLabel & ” Error ErrNo:” _
& Err.Number & ” ErrDesc: ” & Err.Description
Call objMOMAPI.LogScriptEvent(strScriptName, 999, C_ERROR, strMsg)
Err.Clear
End If

End Sub

‘——————————————–

This a simple script to copy the deployed file from its temporary locating to a controlled folder. Note the piece of code below:

I have restricted the copy to happen only on one of my agents. You might as well remove it if you want it to be to all the selected targets (see later).

Now Right-Click the Write-Actions folder and add a new item (Empty MP Fragment). Name it: DeployFile.mpx

Replace all the code with the code below:

<ManagementPackFragment SchemaVersion=”2.0″ xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<TypeDefinitions>
    <ModuleTypes>
      <WriteActionModuleType ID=”TextFile.WriteAction.DeployableFile” Accessibility=”Public” Batching=”false”>
        <Configuration>
          <xsd:element name=”FilePaths” type=”xsd:string” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” />
        </Configuration>
        <ModuleImplementation Isolation=”Any”>
          <Composite>
            <MemberModules>
              <WriteAction ID=”WA” TypeID=”Windows!Microsoft.Windows.ScriptWriteAction”>
                <ScriptName>DeployUR5.vbs</ScriptName>
                <Arguments>”$FileResource[Name=”ResourceID.testfilesentbySCOM.txt”]/Path$” “C:\SCOM_Copied_Files\” </Arguments>
                <ScriptBody>
                  $IncludeFileContent/Scripts/DeployFile.vbs$
                </ScriptBody>
                <TimeoutSeconds>300</TimeoutSeconds>
              </WriteAction>
            </MemberModules>
            <Composition>
              <Node ID=”WA” />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.BaseData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </WriteActionModuleType>
    </ModuleTypes>
</TypeDefinitions>
<LanguagePacks>
    <LanguagePack ID=”ENU” IsDefault=”true”>
      <DisplayStrings>
        <DisplayString ElementID=”TextFile.WriteAction.DeployableFile”>
          <Name>Deploy File Write Action</Name>
          <Description>Write action for deploying a file to a SCOM 2012 agent.</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPackFragment>

Note that I’m copying the file to this folder: C:\SCOM_Copied_Files\, which I’m sure exists on my target.

Now, let’s add the rule. This is the most intricate one, let’s go slowly. I could just give you the XML code, but wouldn’t be that fun. So, here we go.

Right-click the rules folder and select Add New item. I have named it FileDeploymentUsingSCOM.FehseRule.DeployTestFile. You can name it Cujo if you want, but I like it descriptive.

After clicking OK, you should see this very intuitive interface…

Click the new rule and note the Properties window on your right (probably):

Let’

Now, for the target. I have picked Microsoft.SystemCenter.Agent, which means everybody except for management servers.

Now will set the Data Sources and Write Actions. Click on the […] box by the Data Sources and then Click Add.

Set the parameters as below:

Property

Value

Data Source Type ID

System!System.SimpleScheduler

Data Source Configuration

Note the interval : 5 minutes. For testing only, probably.

Now click OK and select the […] by the Write Actions:

Click Add and set the as below:

Property	Value
Write Action Type ID	Click the […] and select TextFile.WriteAction.DeployableFile from the list
Write Action Configuration	<FilePaths>$FileResource[Name=’ResourceID.testfilesentbySCOM.txt’]</FilePaths>

Click OK

Last step in VS is sealing the MP.

Right-click the project and select Properties:

If you don’t have a have, check here on how to do it.

Click on

Hopefully, you will see this:

Import the MP into SCOM:

Once imported and running you should see this in the event log:

and also, the file in the final location.

Imagine the possibilities, since we can copy anything we want even to servers in a DMZ and execute a script to deal with those files or whatever you need to do.

Hope this helps!

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:

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:

<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:

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:

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!

SCOM VSAE Authoring–Part 3: Interlude: Snippet Templates

Previously in SCOM VSAE Authoring: our heroes continued their quest in search for a new way to author SCOM management packs. They went past through the first two challenges: VSAE and a basic discovery.

I have promised to talk about group discoveries and monitoring. I won’t. Yet. Before that, I want to talk about an important weapon to help thrive in the SCOM authoring endeavour: Snippet Templates!

A bit of history: in the Authoring Console, there was no mechanism to create templates. You could, of course, create a template MP and have it in store. However, all the IDs, once saved, can’t be easily changed. Not from the console itself. If you wanted to do that, you’d need to go XML (extremely mediaeval language) and get your hands dirty copying, searching and replacing text.

But fear not, Snippet templates to the rescue! Although not that powerful yet, in my opinion, the snippet templates allow for some automatic replacement of text, choices and references.

Let’s get our classes code, for example:

If this is very common type of discovery I’m going to use, it would be nice to have it ready and just change some of the key parameters.

Here is how to do it: first you will need to create a new item:

Notice that I’m creating it inside the Snippet Templates folder.

Select:

and name it! Before you hit Add, otherwise you’ll be stuck with that name, not easily changeable.

What you’ll see there is a Performance Collection rule snippet. We don’t care for that right now. You can start by removing the Monitoring section and replacing with our class module:

Ok, but we need some variables in there. You have a few options. If you start typing a hash tag, VS will show:

Here are my final results:

After saving that, you can create another type of snippet, called Snippet Data. That’s when you actually enter data and use the template you just created.

Did you name it? Aha!

After you added it, you need to select which template will be used:

Now you can easily populate the parameters:

A note about visual studio 2010 and its VSAE: the screen above is not exactly the same. It is not smart and will show each and every field, every time it appears in the XML code. However, you don’t have to populate each one of them. If you populate for example the MPElementname and click the title of the column, for sorting, it will populate all the MPElementName ones for you. So, the tip is to create a comment section in the MP fragment, with all the fields used in the code, just so your CSV files can populate them right away, with only the necessary fields. I will try to make a special short post about this later.

Once you’re done, hit the save button (that little square thingy that no kid knows what is anymore) and voila! The magic is done!

You probably imagine how powerful that can be if you compose more complicate templates, that not only create the classes from the parameters, but also the associated discoveries and possibly some rules and monitors.

You can also add choices:

A typical use would be the source eventlog, for example: Application System or Security.

And Aliases:

The idea is just so you don’t have to worry about the current alias for those libraries. This will take care of that.

I can certify you that this is saving a huge amount of time in the project I’m currently working on. Use your imagination and let VSAE work for you, instead of becoming a clicking monkey!

Hope this helps

SCOM VSAE Authoring–Part 2: Classes and Discoveries

An object class defines what the object is, its properties and how it relates to other objects in terms of hierarchy and inheritance. For my example class, I will try and discover servers that have the task scheduler service to start automatically.

Let’s define a new Class of objects called StdMPTemplate.FEHSE.Scheduler.Service:

Give it a name before you hit ok!

Ok, don’t panic. It is XML, all colourful and cheerful.. Take a deep breath and let’s take a look at what we see. The XML example brings some comments that will help you filling up the gaps. If you never did SCOM authoring before, it will be challenging, but not impossible. Happens that most of the time, what we want is what the snippet brings for us, with a few modifications needed:

Let’s change this what we really want now:

Note that I changed the class to be “Public” and to be “hosted”. To be hosted means that is will be hosted by another object, meaning the computer that will have the task scheduler service and also that I can refer to the host’s properties when needed.I have also changed the Base class to LocalApplication (typically used for services and other local applications).

Finally, I have added the Display Strings for the Class and the property:

Now, if you build your solution (Ctrl-Shift-B), you should get something like this:

And your debug folder should contain the XML file for the MP:

If you don’t have a good ‘build’ read the messages carefully. They will look like gibberish in the first few times, but you’ll eventually get them. Smile

So, now, what we need to do is to find a server that has the service we want, in this case, the task scheduler one.

Discoveries can be done basically in three different ways:

Registry – the fastest and less expensive in terms of computing power;

WMI – more expensive and dependent on WMI’s health

Script – more complex and expensive, but very flexible

For this case, we could pick any of the ones above, but since we know services appear in registry, we can use the first one for convenience.

So, let’s take a look at how the Discovery template works:

You’ll have a few things to fill up:

The part you won’t be able to pick from a list is the configuration part.

When you click on Configuration XML, you’ll get a bit of an empty window:

It is context sensitive, so, it will only allow you to enter things that are valid, as above. Nevertheless, it won’t be easy to pick the same way as you would in the old Authoring Console.

Here’s how I’ve configured it:

<ComputerName>$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/NetworkName$</ComputerName>
<RegistryAttributeDefinitions>
<RegistryAttributeDefinition>
<AttributeName>Service</AttributeName>
<Path>SYSTEMCurrentControlSetServicesSchedule</Path>
<PathType>0</PathType>
<AttributeType>0</AttributeType>
</RegistryAttributeDefinition>
<RegistryAttributeDefinition>
<AttributeName>Started</AttributeName>
<Path>SYSTEMCurrentControlSetServicesScheduleStart</Path>
<PathType>1</PathType>
<AttributeType>2</AttributeType>
</RegistryAttributeDefinition>
<RegistryAttributeDefinition>
<AttributeName>OSVersion</AttributeName>
<Path>SOFTWAREMicrosoftWindows NTCurrentVersionCurrentVersion</Path>
<PathType>1</PathType>
<AttributeType>3</AttributeType>
</RegistryAttributeDefinition>
</RegistryAttributeDefinitions>
<Frequency>900</Frequency>
<ClassId>$MPElement[Name=”StdMPTemplate.FEHSE.Scheduler.Service”]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name=”StdMPTemplate.FEHSE.Scheduler.Service”]/ComputerName$</Name>
<Value>$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/NetworkName$</Value>
</Setting>
<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=”System!System.Entity”]/DisplayName$</Name>
<Value>$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$</Value>
</Setting>
</Settings>
</InstanceSettings>
<Expression>
<And>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type=”String”>Values/Service</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type=”String”>True</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type=”String”>Values/Started</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type=”String”>2</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type=”String”>Values/OSVersion</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type=”String”>6.2</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</And>
</Expression>

To end this post, let’s take a look at the configuration piece by piece:

The registry definitions:

Is the equivalent of this:

The frequency for the discovery:

The instance settings:

equivalent to:

The expression:

Is equivalent to:

As you can see, you may need to sometimes resort to previous references, but once you have some,you will start to create a library and be able to re-purpose them.

After importing it, the discovery starts and you should see something like this:

On our next episode, I will continue with a group discovery and then for some monitoring!

Hope this helps!

Quickstart guide to SCOM and VSAE–Introduction

There are a few different ways to author content in MS’ Operations Manager. You can simply create new management packs from Templates in the console or even creating some low level custom monitors in there. But sometimes, what you need is not available there or would take too much time to be accomplished (too much click business!).

And that’s where the fun starts. Or the horror, for some most people. The first time I saw the SCOM 2007 Authoring Console, it looked familiar. Kinda/sorta…then I started noticing the differences and how things are a little still in there, not live like in the console. And dry. It is like another dimension where it seems to be the same thing, but everybody is dead. Well, enough with my Stephen King references. Seriously, it is a bit of a transition, since you have to abstract even more how the monitors/rules/discoveries will behave once made live in a real management group. But after a while, you get the groove and start creating some basic stuff more easily.

Then comes SCOM 2012 and Microsoft says the Authoring Tool, although being able to create content for 2012, it can’t reach its full potential. Enter the Visual Studio Authoring Extensions. When I first read that, I thought: awesome. I have used some VB, Visual Studio in the past. I’m not a programmer per se, but I can script, wrote code in the past, etc. I then eagerly installed VS (2010, at the time) and installed the extensions. The first impression: I believe I went through all phases very quickly: Denial, anger, fear and the acceptance: that will take a while to grasp.

Although the Authoring Console was a bit dry, it had some wizards, some visualization aids that were helpful. And would look a bit like the console. With VSAE, I felt a bit abandoned in the desert.

Months pass and I went back to it a few times to try and was able to do very little. I decided to create a Task Scheduler MP for Windows 2012. I confess, I did it using the authoring console.

But recently, two things happened. First, I saw this article by the guru Kevin Holman on how to create lots of workflows using VSAE. Second: I had to use it in a customer scenario, where they had around 100 event rules to be created and nobody wanted to click more than a 1000 times to do that. Well, it is time.

And right now, I’m starting another project, where I’m helping a customer to migrate almost 300 MOM 2005 (Yes, gentlemen, I said MOM 2005) workflows to SCOM 2012.

And here’s the challenge: how to do that fast and consistently. The AC requires as many clicks as the actual console. Or more. Editing bare XML can help, but is prone to errors and inconsistencies. Why not use the current tool and experiencing and learning how it would behave.

My initial tests are very promising and I will start a series of posts here, describing how it is progressing. Stay tuned!

Hope this helps