Sample management pack for Operations Manager 2007 and System Center 2012 Operations Manager.
This management pack provides an example of configuring monitors and rules to run only during business hours. Examples are provided for a service monitor, a monitor running a script, and monitors and rules based on a Windows event. Two different monitor types are used for events. These have identical functionality but illustrate two different strategies for configuring monitor types.
Each monitor and rule must specify parameters for the System.ScheduleFilter module. StartTime and EndTime provide the time that the monitor or rule should begin functioning, while EndTime specifies the time that it should stop functioning. DaysOfWeekMask specifies the days of the week that the schedule applies to as described in the following article: http://msdn.microsoft.com/en-us/library/ee692976(v=MSDN.10).aspx.
Both event monitors trigger a critical state from an event with a number of 101 and a source of EventCreate. They return to healthy with an event number of 102. The service monitor watches the running state of the Alerter service, The script monitor will set a state according to the Successful parameter on the monitor type. If the Successful parameter is false, then a critical state is set. If the Succesful parameter is true, then a healthy state is set.
All rules and monitors are targeted at a class called MPAuthor.BusinessHours.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\BusinessHours. This registry key must be on the same agent computer where the test events are created.
This is a sample management pack for Operations Manager 2007 R2.
This management pack provides an example of monitoring network devices. This includes providing custom monitoring for different brands of SNMP devices and monitoring Syslog mesages from devices that do not support SNMP.
A class is created for each type of SNMP device based on Microsoft.SystemCenter.NetworkDevice. This provides a target for monitors and rules specific to each type. For devices that do not support SNMP, a class is created based on System.HardwareComponent. A device for each type of device is created based on this class that provides the target for monitors and rules specific to that type.
Discovery for SNMP devices is targeted at Microsoft.SystemCenter.NetworkDevice since this represents network devices that have already been discovered. The name of the target is used to determine the type of device and which class should be created. Discovery for devices not supporting SNMP is performed from a text log that lists the Name, IP Address, and Type for each device to discover. This discovery is targeted at a proxy agent that is discovered from a registry key at HKLM\SOFTWARE\MPAuthor\NetworkDevices. This registry key must also contain a value called ConfigFIle that contains a path to the configuration file.
The classes for the devices are all unhosted. Unhosted object are typically managed on the RMS, but the discovery scripts create a special containment relationship that causes the object to be managed on the proxy agent. Any monitors or rules targeted at these classes are loaded on the agent computer. The managed devices should be configured to send SNMP traps and Syslog messages to the proxy agent.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a script returning multiple values in a property bag. A single monitor type is used that accepts a parameter to specify the desired property. Also illustrated is the use of data source modules returning different data types. Rules and monitors can use the data source returning the type they require, while they all share the same script.
The script collects different pieces of data from a file. The name of the file must be specified in the FileName parameter of any rule or monitor.
All rules and monitors are targeted at a class called MPAuthor.PropertyBag.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\PropertyBag. This registry key must be on the same agent computer with the file.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a recovery running after a diagnostic. The recovery only runs if specific criteria is received from the diagnostic output. It also illustrates how to pass property bag data from the monitor to the diagnostic and the recovery.
In this example, the diagnostic runs in response to a service monitor. If the specified service is stopped, then the diagnostic runs. The service used is the WMI Performance Adapter (WmiApSrv), but this can be changed in the properties of the monitor. The diagnostic runs a script that collects an error code value from the registry at HKLM\SOFTWARE\MPAuthor\DiagnosticAndRecovery\ErrorCode. If the error code is 3, then the recovery will run. If it is any other value, the recovery will not run. The recovery is a script that restarts the service.
A sample diagnostic and recovery are provided for both VBScript and PowerShell. The functionality of each are identical and only one of the diagnostics should be enabled at a time.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a script processing the output of a data source. The data source is followed by a probe action that changes the output data type to a property bag. Monitors and rules using the data type specify the property bag values that they require. Two samples are provided, one using Windows PowerShell and the other using VBScript.
The specific example expects XML in the description of an event. This simulates a condition where all errors in the application create a Windows event with the same name number and source. The XML includes the specific number and description of the error. The expected XML format is below. Sample rules expect an event with a number of 101 and a source of EventCreate. The EventCreate utility can be used to create sample events.
All rules and monitors are targeted at a class called MPAuthor.ProcessDataSource.PowerShell.Target or MPAuthor.ProcessDataSource.VBScript.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\ProcessDataSource. This registry key must be on the same agent computer that the sample event is created on.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a monitor based on a registry value. A monitor type is included that will periodically check a specified registry value and compare it to a desired value. The monitor provides the path to the value, the duration to check, and the value to compare it to.
The included monitor checks the value at HKLM\SOFTWARE\MPAuthor\RegistryMonitor\TestValue and sets the monitor to a critical state if the value is not "ThisValue". A different registry value and desired value can be used by changing the configuration of the monitor.
All rules and monitors are targeted at a class called MPAuthor.RegistryMonitor.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\RegisterMonitor. This registry key must be on the same agent with the registry value being checked.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of linked reports. Two linked reports are included as follows:
Availability Report - The user is not required to provide values for any of the parameters other than the objects. The data included is from the previous seven days. The dialog box to select the objects is filtered to only include instances of MPAuthor.LinkedReports.Target.
Performance Report - The user must select the object and date range but does not need to select the details of the report. It is configured to include performance data from two rules - MPAuthor.LinkedReports.CollectScriptPerformance and MPAuthor.LinkedReports.CollectWMIPerformance.
All rules and monitors are targeted at a class called MPAuthor.LinkedReports.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\LinkedReports. This registry key must be on at least one agent computer. The sample rules and monitor will run on these agents.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of workflows running scripts that support cookdown. Two example rules are provided in both VBScript and PowerShell with with one supporting cookdown and the other not supporting cookdown.
The sample rules collect as performance data the file size for all files in a specified folder. The rules are targeted at the class MPAuthor.Cookdown.File, so the agent will run a separate instance of the rule for every file. The data source module for the rule not supporting cookdown requires the path of the file as a parameter. Since this will be different for every instance, the module cannot cookdown. The first data source module for the rule supporting cookdown also requires the file path, but this is used in a condition detection module. The data source module running the script does not require this parameter. Since the folder path parameter will be the same for all files, that data source module does cookdown.
Each rule will create an event in the Operations Manager event log to verify each running instance. The rules that cookdown should create a single event while the rules not supporting cookdown should create multiple events. Each of the rules is disabled and needs to be enabled before they run.
The event numbers created are as follows:
821 - No Cookdown - VBScript
822 - Cookdown - VBScript
823 - No Cookdown - PowerShell
824 - Cookdown - PowerShell
The discovery for MPAuthor.Cookdown.File is targeted at a class called MPAuthor.Cookdown.Target. This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\Cookdown. This key must have a value named FolderPath that contains the path of the folder containing the files. The folder must exist on the agent computer and contain one or more files to discover.
This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides several examples of different kinds of discovery. Several classes and relationships are included in the management pack to support the sample discoveries. A basic description is provided for each below, and a more complete description is provided for each Discovery in the management pack.
- Registry Discovery
Creates an instance of a particular class if certain conditions are true.
- Script Discovery
Script to discover instances of a particular class.
- Script Discovery for Unhosted Class
Script to discover instances of an unhosted class.
- WMI Discovery
WMI discovery to discover instances of a particular class.
- Discover Containment Relationship with Script
Script to discover instances of a containment relationship. A script is used because logic is required to parse the a property collected from a registry value.
- Discover Containment Relationship with Registry
Discover a containment relationship from registry values without using a script. This discovery can only be used when the property value collected from the registry does not need to be parsed.
- Group Population for a Group
Uses GroupPopulator to populate a group with all instances of a particular class.
- Group Population for Distributed Application
Uses GroupPopulator to populate a distributed application with all instances of a particular class.
- Group Population for Computer Group
Uses GroupPopulator to populate the a group with all instances of Microsoft.Windows.Computer that have an instance of another class.dfg
This posting is provided "AS IS" with no warranties.
Thanks for posting :)
ReplyDeleteErnie