Before we dive into the actual process of creating a MOM response in script or managed code, it's worth discussing when you should choose one approach over the other. Both response types can run on either the MOM management server or an agent-managed computer. One of the most important factors in your decision of response type is deployment. Scripts are much easier to deploy over managed code because they reside in the MOM operations database, while managed assemblies must be manually deployed. But do not discount the managed code response type entirely; managed code has all the benefits of the CLR and access to the ⋅NET Framework. The following table lists features of the MOM SDK.
Feature | Script Responses | Managed Code Responses |
---|---|---|
Programmatic access to the response context. | Yes, using the ScriptContext object. | Yes, using the Context class. |
Ability to create a new alert. | Yes | Yes |
Ability to create a new state monitoring alert. | Yes | Yes |
Ability to create a new MOM event. | Yes | No |
Ability to create a new MOM performance data item. | Yes | No (not supported) |
Ability to create and submit computer discovery data. | Yes | No |
Supported programming languages | All COM-compatible scripting languages, including third-party extensions | All ⋅NET Framework languages, including third-party extensions. |
The programming language of the response must be explicitly specified. | Yes | No, all assemblies store instructions using the Microsoft Intermediate language (MSIL). |
Ability to store response as native code. | No | Yes, via NGen.exe. |
Stored in MOM database. | Yes | No |
Feature | Script Responses | Managed Code Responses |
---|---|---|
Ability to directly invoke a component from a MOM rule. | No | Yes |
Distribution mechanism. | Management packs. | Custom setup project unless the assembly already resides on the computer. |
Deployment mechanism. | MOM agents. | Manual deployment, unless the assembly already resides on the computer. |
Update mechanism. | MOM agent updates. | Manual re-deployment. |
Source code can be viewed in the MOM UI. | Yes | No |
Source code can be edited in the MOM UI. | Yes | No |
Ability to call COM components. | Yes, automation components only. | Yes, using COM interop. |
Ability to call ⋅NET assemblies. | Yes, when the assembly is COM-compliant and interop marshalling code is available. | Yes |
MOM script responses allow you to extend the capabilities of rules and provide specialized actions in response to an event, alert, or performance threshold. To create a new script:
Launch the Administrator Console, right-click Scripts, and select Create Script.
Designate the script's name, description, and language (see Figure 11-3), and then click Next.
Figure 11-3
Type in your script (see the sample script that follows), as shown in Figure 11-4, and click Next.
Figure 11-4
Specify any parameters that are to be passed into your script (see Figure 11-5), and click the Finish button.
Figure 11-5
The script is now created and can be accessed and manipulated just like any other pre-existing script (see Figure 11-6). Typically, you would now go and set a rule's response to Launch a Script and then select your newly created script.
Figure 11-6
Option Explicit Dim objSvc Dim retval Set objSvc = GetObject("WinMgmts::Win32_Service='Messenger'") retval = objSvc.StartService() If (retval <> 0) Then Dim objEvt Set objEvt = ScriptContext.CreateEvent objEvt.Message = "The Messenger service failed to start." objEvt.EventType = 2 ' 2 = EVENTLOG_WARNING_TYPE ScriptContext.Submit(objEvt) Set objEvt = Nothing End If Set objSvc = Nothing
Managed code responses allow you to create rules that call a method within a ⋅NET assembly. Again, one of the burdens if you do choose the managed code response type is that you must manually deploy the assemblies to every machine that needs to call the managed response. The MOM SDK specifically mentions the following namespaces could be very useful for managed code responses:
System namespace: Information about the operating system.
System.Diagnostics namespace: Access to the Windows NT event logs, performance counters, and processes.
System.Management namespace: WMI-related classes.
If you create an assembly method that references the Microsoft.EnterpriseManagement.Mom.Runtime library and accepts an instance of the Microsoft.EnterpriseManagement.Mom.Runtime.Context class as a parameter, your assembly's method will have access to the features similar to those available to unmanaged script responses through the ScriptContext object. You must have the 1.1 ⋅NET Framework or later installed on any machines where MOM could invoke your managed response. When you're building your ⋅NET assembly you can compile it with version 1.0 or later. See the code that follows for a VB.NET example of a managed code response's source code.
Imports Microsoft.EnterpriseManagement.Mom Imports Microsoft.EnterpriseManagement.Mom.Runtime Public Class MomAwareMCRs Public Sub MomAwareTest(ByVal oContext As Context) End Sub End Class