Note
If a script must access a network resource that requires a particular security context, the OnePoint service on the computer on which the script will be executed must be configured to use an appropriate service account.
Scripts that run on the Consolidator computer can access stored state information in the Consolidator's ScriptStateobject. They do not have access to ScriptStateobjects created by agent computers. This is true even for the local agent on the Consolidator computer.
Scripts can run in response to a processing rule match or on a timed basis.
State Variables
As a response to a processing rule, you can manipulate the state variables that the script creates. You can then use these state variables in a script to determine the appropriate action to take.
Use state variables to perform multi-event correlation. A state variable can keep track of how many times an event has occurred on one or more monitored computers.
For example, you want to monitor logon attempts and page your administrator if an excessive number of logon failures occur within a given period across all computers in your enterprise. A high number of logon failures in a short time might indicate a distributed attempt to break into the network. You can create a processing rule to increment a state variable every time a logon failure occurs. This increment is performed in highly optimized code rather than in a script and has minimal performance impact, even during the start of the business day when logon activity is very high. You can then run a script at regular intervals to check the state. If the number of failures is not excessive, the script resets the variable. If the number is excessive, the script pages your administrator.
Response Scripts
Response scripts answer an event, alert, or performance threshold. When you create a processing rule, you can specify a script to run in response to a processing rule match. Response scripts are synchronous, meaning that the agent or Consolidator waits for the script to complete before continuing to process the associated event, alert, or performance data.
Scripts could respond to an event, alert, or performance data with computer configuration changes. For example, using Windows Management Instrumentation (WMI), a script could change a computer configuration in response to an event. A company policy might prohibit employees from using dial-up networking. You can configure MOM to watch for an event indicating that dial-up networking is enabled on a computer. A script could respond by using WMI to turn off dial-up networking on that computer and then display a cautionary message to the computer user.
You can also create a processing rule that watches for successful logon events. When MOM processes a successful logon event, a script could analyze the number of failed logon events occurring on that computer in the last minute or so. If the number is high, the successful logon event might be indicative of a successful network security attack. If the script determines that the attack might have been successful, the script can generate a Security Breach alert and e-mail or page the network administrator.
Timed Scripts
Timed scripts are response scripts that run on a timed basis. They can run on the agent or Consolidator computer.
MOM can create timed events, and you can link a script as a response to a timed event. As an example, you could configure MOM to create an event that occurs every ten minutes. When the event occurs, the product could run a script that pings the Internet service provider (ISP) router. If the ISP connection is down, the script could create an alert that indicates the problem.
Did you find this information useful? Please send your suggestions and comments about the documentation to momsdk@microsoft.com.