Using the Probe Based Script Event Rule – or – how to used a script to create events in the workflow


So – in my previous post on the basics of MOMScriptAPI.LogScriptEvent, we talked about how to take your own script – and log an event to the OperationsManager Windows Event Log.


One of the challenges with this – is that it will not allow us to add multiple parameters to the event.  Using the Probe Based Script Event rule – we can do this…. it is just a bit more complicated.  I haven't seen any good examples out there on the basics of authoring this type of rule – so here goes.


For starters – I am going to create this rule in the intended fashion – it is an Event Collection rule by nature.  So, I will run the most simple of scripts, on a schedule, and collect the event based output.  Then, in the more advanced scenario – I will edit the rule, to add an alert write action – which will be able to pull rich event data into the alert description, or custom fields.


Let’s get started.


Create the rule for a Test MP in your lab.  We will be using the Authoring Console to write this rule.  If you aren't familiar with the Authoring console yet – you need to get more familiar with it – and this is an excellent chance to get accustomed to the Auth Console for a very simple rule type like this.  We “could” make this basic rule in the OpsMgr UI, Authoring tab – but all the advanced functions we need are in the authoring console:


Start up the Authoring console.  Choose File, New, Empty Management Pack.  Give it an Identity (I will use Custom.Script.Test.MP)  Then give the MP a disaply name – which you will see in the console once imported.  Use your documented custom MP naming standard here.  I will use “Custom – Script Test MP”


In the Auth Console – choose the Health Model tab.  Click Rules.  Right click in the open space on the right, and choose New > Collection > Event Based > Script Based Event Collection.  Here is what pops up:


image


In the Element ID – this is prefaced my the MP ID, then “NewElement”.  So – we need to change “NewElement” to something meaningful… basically – something that represents this rule name.  I will use “Custom.Script.Test.MP.CustomRuleTestScript”  (This field does not allow spaces)


In the Display Name – this is what will show up in the console UI for the Rule Name – so name this according to your documented custom Rule naming standards.  I will use “Custom – Script Event Rule” (This field does allow spaces)


For the target – I will be using my favorite generic target - “Windows Server Operating System”. 


image


Set the Rule Category to “EventCollection”.    Here is how it looks filled out:


image


For testing – we will run this rule every 1 minutes:


image


Give the script a name – I used TestScript.vbs.  Set the TimeOut to 30 seconds (needs to be less than the interval, which in this case was every 60 seconds).


Paste in a sample script:


image


 


 


 


The script above is very simple – it does not do anything fancy – it simply runs, and submits PropertyBags in the form of Event information, which the Event Workflox in XML can consume, and collect.  We are only submitting three items in this basic example – Event ID, and two custom EventParameters.


If we wanted to test this script – to make sure it works correctly – just run it on a test machine with a SCOM agent installed – and examine the output:



C:\bin\scripts>cscript.exe /nologo TestScript1.vbs


<DataItem type="System.PropertyBagData" time="2009-07-27T11:58:39.4154203-05:00" sourceHealthServiceId="2B5A37C8-DB0A-7CAE-DB0E-451EA34FA250"><Property Name="EventID" VariantType="2">10</Property><Property Name="EventParam1" VariantType="8">SomeText1</Property><Property Name="EventParam2" VariantType="8">SomeText2</Property></DataItem>


This is the expected output above.


Next – on the Event Mapping screen… we need to fill in variables – or hard coded information we want in our script.


For the Computer field – we will use a Windows Computer property, to place the NetBIOS name of the Windows Computer hosting this Operating System, into the event.  Click the browse button at the right – and choose Target, then (Host=Windows Computer), then NetBIOS Computer Name.  It should look something like this:  $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$


For the Event Source and Event Log, those are our own custom source and log – since this isn't a real Windows Event… so I will use “MyCustomEventSource” and “MyCustomScriptEventLog” for examples here.  You can use anything you like.


Leave EventID at the default variable.


I will be using Category = 1, and setting Level = Error:


image


Now – create the rule, and then save the MP.


If we imported this simple MP into our lab management group - what we should should see – is that OpsMgr is collecting this event in the database every minute, for our test machine.  Create a view in MyWorkspace for event ID 10:


image


Notice the event details:


image


This is pretty basic.  Lets examine the XML for our rule:  I highlighted in blue and bold, all the stuff we just did in the UI – so you can see where it matches up:


      <Rule ID="Custom.Script.Test.MP.CustomRuleTestScript" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>EventCollection</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.EventProvider">
            <IntervalSeconds>60</IntervalSeconds>
            <SyncTime />
            <ScriptName>TestScript.vbs</ScriptName>
            <Arguments />
            <ScriptBody><![CDATA[Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
Call oBag.AddValue("EventID",10)
Call oBag.AddValue("EventParam1","SomeText1")
Call oBag.AddValue("EventParam2","SomeText2")
Call oAPI.Return(oBag)
           ]]></ScriptBody>
            <TimeoutSeconds>30</TimeoutSeconds>
            <EventOriginId>$MPElement$</EventOriginId>
            <PublisherId>$MPElement$</PublisherId>
            <PublisherName>MyCustomEventSource</PublisherName>
            <Channel>MyCustomScriptEventLog</Channel>
            <LoggingComputer>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$</LoggingComputer>
            <EventNumber>$Data/Property[@Name='EventID']$</EventNumber>
            <EventCategory>1</EventCategory>
            <EventLevel>1</EventLevel>

            <UserName />
            <Description />
            <Params />
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
        </WriteActions>
      </Rule>


 


 


 


The above is very simple – a rule, using the built-in TimedScript.EventProvider Data source, which runs a script every 60 seconds, and submits some PropertyBags as event data.


TimeoutSeconds was configured on the Script page in the UI.


EventOriginId and PublisherId will be left at defaults.


PublisherName = “Event source” in the UI.


Channel = “Event log” in the UI.


EventNumber = “Event ID” in the UI.


EventCategory = “Category” in the UI.


EventLevel = “Level” in the UI.  (0=Success, 1=Error, 2=Warning, 4=Information)


UserName, Description, and Params are not exposed in the UI – but can be filled in by variable output of your custom script for advanced scenarios, or you could hard code these in your XML if needed.


Ok – done with the simple stuff……   🙂


Now – what if we don't want to COLLECT the event – we want to ALERT, if this event is created as an option of our script?  Well – we can do that – just not in the regular Console UI.  We need to edit the <WriteActions> part of the XML, along with several other parts of XML – OR – we can add this very simply in the Authoring Console.


So – back to the Authoring console. 


Right click the custom rule we just created – and choose Properties.


Select the Modules Tab.


In the Actions area – click the Create button.


Scroll down – and highlight the System.Health.GenerateAlert.  For “Module ID” – type in “Alert” and click OK (see graphic)


image


Back on the Modules Tab – Highlight “Alert” under Actions, and click the Edit button.


On the pop-up – click “Configure”


Now you can fill out the details on this familiar screen.  Give it a good Alert Name.  Set the Priority and Severity as desired.


image


Click Alert Suppression, and suppress duplicate alerts based on your choosing.  I will use Event ID, and Logging Computer.


Click OK several times to accept these changes, and then save your MP.


At this point – you can import the MP and it works as designed…. you will run the script – create the script based event data, collect the event in the OpsMgr database, and then also – generate an Alert each time the script runs, based on the event data.  Here is an example of the alert generate:


image


Now – lets make the alert richer.  The whole point of this exercise was to be able to add multiple parameters as variables to the Alert – for instance – to be able to add them as Custom Fields in the alert.


In order to do this – we need to add a few things to the rule:


First – we need to add the Parameter to the data source:


In the Authoring Console – right click the rule and choose properties. 


Select the Modules tab. 


Highlight the Data Source and click Edit. 


Click Configure.


Go to the Event Mapper Tab, and click the “Parameters” button.  We will past in the following parameters – separated by a SPACE:



$Data/Property[@Name='EventParam1']$ $Data/Property[@Name='EventParam2']$


These are the parameters directly from our script:


Call oBag.AddValue("EventParam1","SomeText1")
Call oBag.AddValue("EventParam2","SomeText2")

This will allow our Alert workflow to call these parameter variables – and place the resolved text into the Alert description or custom fields.


Lets do that! 


In the Authoring Console - on the Modules tab of the custom rule, highlight the Alert Action, and click Edit.


Click the Configure button.


Add the parameter variables to the Alert Description field, and Custom Field 8 and Custom Field 9.  These should be in the syntax of:


$Data/Params/Param[1]$


$Data/Params/Param[2]$ 


etc….


image


image


Click OK on the screens to save your changes, save, and import your test MP.


The alerts will now have richer data available – with the alert description and custom fields now populated with your custom script based event parameters:


image


image


 


Below – you will find my final XML attached (with the rule disabled so it wont flood your environment should you import it)

Custom.Script.Test.MP.zip

Comments (0)

Skip to main content