Scripts can run on the agent-managed computer or Management Server computer. Because agents can run using a local system account by default, scripts that run on the agent-managed computer can access only information local to the agent-managed computer.
Note
If a script must access a network resource that requires a particular security context, the action account on the computer on which the script will be executed must be configured to use an appropriate service account.
Scripts that run on the Management Server computer can access stored state information in the Management Server's ScriptStateobject. They do not have access to ScriptStateobjects created by managed computers. This is true even for the local agent on the Management Server computer.
Scripts can run in response to a rule match or on a timed basis.
State Variables
As a response to a 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 can indicate a distributed attempt to break into the network. You can create a 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 of failures is excessive, the script pages your administrator.
Response Scripts
Response scripts answer an event, alert, or performance threshold. When you create a rule, you can specify a script to run in response to a rule match. Response scripts are synchronous, meaning that the agent or Management Server waits for the script to complete before continuing to process the associated event, alert, or performance data.
Scripts 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 Microsoft® Operations Manager (MOM) to watch for an event that indicates 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 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, for example. If the number is high, the successful logon event can 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 Issue 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-managed or Management Server computer.
MOM can create timed events, and you can link a script as a response to a timed event. For example, you could configure MOM to create an event that occurs every 10 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 momdocs@microsoft.com.
