Getting Started with Management Packs

Many of the management packs come packaged with reporting files. Both the management pack itself (.akm) and the report (.xml) are imported through the Import/Export Wizard. In order to import reports, the Microsoft Operations Manager 2005 Reporting components must be installed for the Management Group.

The first order of business before importing management packs is to obtain them. Most, if not all, of the applications that are released today by Microsoft come with management packs. Try to make it a best practice to refer to the Management Pack and Product Connector Catalog on the Web at http://www.microsoft.com/management/mma. New updates are posted to this location routinely.

Importing Management Packs

In order to import an MP, right-click the Management Packs section of the Administrator Console. Choose the Import/Export Management Pack option. From there, you're about a wizard and three steps away to importing your management pack:

Important 

For the purposes of this scenario, we are using the Microsoft Windows Servers Base Operating System MP, which has been expanded to the location of C:\MP\ Microsoft Windows Servers Base Operating System MOM 2005.

It's a good idea to place all your MPs in one location. This way, you know that any other Management Groups (that you may have to import management packs for) are all at the same version.

1. At the Import or Export Management Packs window, select Import Management Packs and/or reports.

2. Specify the location where your management packs (.akm files) are stored. Choose the correct Type of Import.

3. From the Select Management Packs location, highlight the management packs to be imported (see Figure 8-1). Choose the correct Import Options and click Next. In this case, because the MP is brand new (nothing to back up), the Backup existing Management Pack option is not selected.

   
   Figure 8-1

   Note 

   Review the "Import Options" section, which follows, for more detail about which methods to use when importing management packs.

4. The Import Status window displays the import operation of the management pack, as shown in Figure 8-2. Once completed, select Close.

   
   Figure 8-2

Note 

We hope that, by now, a cursory evaluation of your environment has been done to determine what exactly to monitor. Given that some MPs can contain upward of 1,000 or more rules, this can have an impact on your environment (agents, database, MOM server). Also, management packs are considerably more difficult to remove than install. Any MP imports should be done only after careful consideration and validity should be performed in a lab whenever possible.

It's important to understand the differences between the Import options when importing management packs. In the future, when new MPs are released, you may be tempted to replace the existing MP. In terms of the two Import options, Replace will not preserve any settings that you may have established, company knowledge, or any custom rules.

Update, on the other hand, preserves the following only:

• Enabled/Disabled: Whether a rule has been disabled or enabled in your environment.

• Custom Rules: Any rules that you may have added to an existing Rule Group.

• Company Knowledge: Any custom information added to augment the information provided in the Product Knowledge section.

Important 

Please note that the Update function does not preserve any threshold adjustments or override criteria. Make it a best practice to back up your MPs during an import procedure to save yourself any potential pain later. It's guaranteed that you will not remember most of the threshold changes you may have made along the way!

Group Types

Microsoft Operations Manager uses a couple of different groups to manage collections of like items. All rules reside in Rule Groups, while all agents reside in a Computer Group. The logic behind grouping things together like this is to ease administration. Although there may be cases where you are associating a single rule to a single computer, it's often not the case. It doesn't provide much flexibility either because all the associations are static and would be a one-to-one relationship.

Using Rule Groups associations to Computers Groups allows greater flexibility. Under this premise, if a new rule had to be deployed to the same set of computers, it would require only a new rule created in the existing Rule Group. If another computer needed the same set of rules, the agent could simply be added to the existing Computer Group.

Computer Groups

As mentioned earlier, a Computer Group is merely a collection of agents. This collection can be based on formula evaluations of specific computer attributes or static memberships. The Computer Group can also include other Computer Groups (or Subgroups). Although the primary role of a Computer Group is to have an association to a Rule Group (for knowing which set of rules to deliver to a particular set of agents), it can serve other purposes as well, such as providing State Roll-up or limiting the information an Operator can see based on console scopes. Regardless of which role the Computer Group is used for, the collection of agents is still the same.

Note 

In SMS terminology, the Computer Group would be referred to as a Collection. In the same manner, SMS collections can be composed of direct membership and/or query-based membership.

Formulas

Formulas for Computer Groups are composed of Computer Attributes, Computer Groups, and/or Discovered Groups. These components can be mixed with evaluators such as MatchRegEx or Match Wildcard. Simpler evaluations can be created to use the basic operators (=, <,>,<>) that you're probably already familiar with.

For example, the Formula for matching Microsoft Windows Servers Properties is AttributeValue (Microsoft Windows Current Version) = “5.0 “. Because some of the basic operators can't be used for "like" operations, a formula for finding all Windows 2000 and later servers would look like this: MatchWildcard(AttributeValue(Microsoft Windows Current Version) = “5.∗”). Using the AND/OR/NOT operators, these formulas can be brought together for multiple criteria matching.

Figure 8-3 shows the formula for a Computer Group matching any Microsoft Operations Manager 2005 Report Servers with a version of 5.x and at least Windows NT 4.0. The Attribute, Computer Group, and Discovered Group are used for selection purposes only.

Figure 8-3

State Roll-Up Policy

This definition of the Computer Group defines how to display the Computer Group when viewed in the MOM Operator Console. Depending on the chosen calculation, the Computer Group can display as best of each case, worst of each case, or a percentage of the healthiest computers.

The wording is a bit confusing on the percentage calculation so consider this scenario. If there were five computers in a Computer Group and 60 percent was used as the calculation, this would imply that of the five computers, 60 percent of the best state computers would be chosen. Because 60 percent of 5 equals 3, the top three healthiest computers are now the candidates. Of the top three, the worst state is depicted. If two of the three were in Warning state while one was in Error state, the Error state would be displayed. The State Roll-up Models picture in Figure 8-4 illustrates this idea.

Figure 8-4

Console Scopes

Console scopes were discussed in Chapter 6. Just to mention, Computer Groups make up console scopes. This tab simply displays the associated console scopes that are tied to this Computer Group. They cannot be edited in this tab.

Discovered Groups

Discovered Groups are handled through service discoveries by the management packs. For this reason, Discovered Groups cannot be altered for use. However, they do have value. A Discovered Group can be replicated as a usable Computer Group. Because the formula for this replica group is a simple MemberOf (Discovered Group) function, it remains dynamic. Any new computers that fall under the original Discovered Group criteria will automatically be evaluated for the same membership in the replica. The following example details how this is done:

1. In the console, under the Management Packs drop-down list, click Discovered Groups. A list of these Computer Groups appears on the right side.

2. Right-click the Windows Domain Controllers (or any other Discovered Group) and choose Create Replica Computer Group(s).

3. Locate the new Computer Group in the Computer Groups drop-down. It will retain the same name as the Discovered Group but will end with _Replica. For instance, the Windows Domain Controllers group is created as Windows Domain Controllers_Replica.

4. Open the Windows Domain Controllers_Replica Computer Group and click the Formula tab. Observe the formula and note that it states MemberOf (Windows Domain Controllers).

Rule Groups

The structure holding together rules is called the Rule Group (RG). These are used as container units to hold rules or child Rule Groups. In the same way you use Organizational Units in Active Directory to create collections of users or computers, Rule Groups hold collections of Rules. Once a Rule Group has been created, it can be associated to a Computer Group. The idea so far is that the Computer Group defines the machines you want your rules to target. The Rule Group defines the actions you want those computers to perform.

Following the Rules (and Other Elements)

At first glance, rules may seem to be the most basic element of monitoring. However, that's not the case with MOM. A rule can, in fact, comprise many elements: event criteria, override criteria, provider, and/or response. In some ways, a rule can be looked at as a collection of these elements.

Event Rules

Event Rules gather information from all the providers (mentioned previously) except for Performance Counter providers. An event can be considered anything from an application writing an event in the Application Log to a 15-minute interval cycle. The five types of Event Rules are as follows:

• Alert on or Respond to Event (Event): Most commonly used rule type. Responses (script runs, command executions, notifications) can be initiated when specific conditions occur.

• Filter Event (Pre-Filter): Used to filter out unwanted events. Generally these are coupled with other event types that collect a broad range of events.

• Detect Missing Event (Missing): Generates an event when a specific condition is not detected during a period of time.

• Consolidate Similar Events (Consolidation): Generally used when a multiple of the same condition routinely occurs. This event rule will generate a summary event for a group of duplicate events collected during a period of time.

• Collect Specific Events (Collection): This rule simply collects specified events but does not perform any responses.

Performance Rules

Performance Rules collect data from the performance instrumentation of a Windows OS. Types of Performance Rules include the following:

• Sample Performance Data (Measuring): As the name implies, it collects the data points of a particular counter.

• Compare Performance Data (Threshold): This type of Performance Rule looks at defined thresholds of a counter and generates a response if the threshold is breached.

The behaviors of a Measuring Rule and a Threshold Performance Rule are nearly identical. The difference can be considered in this fashion. A Measuring Rule is used for reporting purposes only. Because the purpose of a Measuring Rule is strictly for data gathering, it does not have threshold criteria. On the other hand, the Threshold Performance Rule is strictly used to perform an action when a threshold is breached.

Because these rules act independently of each other, you may need to create two different rules for a situation such as what follows. If, for example, the CPU utilization of a server (or group of servers) needs to be tracked and monitored for a threshold breach, it would require two rules. The Measuring Rule collects the data during set intervals every day. The Threshold Rule generates an alert if the CPU utilization breaches 95 percent.

Alert Rules

Events and Performance Rules define what to look for. They also generate the alerts in the Operator Console. It's probably safe to say that not everyone looks in the console all the time. Generally there are alerts that may need some attention (such as those that are something other than Informational or Warning).

Alert Rules are a little less confusing because there's only one type. This rule type examines the information in alerts generated by events and responds based on a matching condition (for example, match severity of Error or higher). Responses to these alerts can be things such as e-mails or command executions.

Important 

It's important to note that to reduce administrative overhead, any notification responses should be generated from Alert Rules rather than Event Rules. This way, one Alert Rule can govern the response of e-mailing the same operators for multiple Event Rules that exist in its umbrella. Otherwise, a notification response would have to be added for each Event Rule.

Tasks

Tasks are the only element of the management pack that is not for use by the agent directly. Instead, Tasks are functional actions of the Operator Console for MOM users. Many of the tasks found in the Operator Console are imported with management packs. These are common administrative tasks (ping, Remote Desktop, and so on) that are used to support a particular technology. Task executions can happen either as requests handed to the agent to run or as an extension of the MOM Console.

A task can be easily created by using the task creation wizard. However, there are a few things to take into consideration when creating a custom task.

• Is the task safe to execute by MOM users? If the task is launched from the agent, the task will run under the privilege of the agent. Because the MOM agent often has LocalSystem access, use caution when creating tasks that run as the agent.

• Does the MOM user have enough rights to invoke the task successfully? If the task is launched from the Operator Console, it is executed interactively under the permissions of the user. Some tasks such as "Ping" operate fine under this condition. However, other tasks such as "Computer Management" may require advanced user rights.

If the answer is yes to either scenario, it may be worthwhile to consider the security implications for using this task within the Operator Console.

Notification Groups

By now, you're probably beginning to see some logic in terms of groups and how things are bound together in MOM. Every group is a collection of the same type of objects. This is no different for Notification Groups.

Most management packs (if not all) have a Notification Group that is imported as a part of the set. The SQL MP, for example, uses Database Administrators. While other management packs, such as Microsoft Windows DNS Server, may use the same Notification Group—Network Administrators — used by other managements packs such as Microsoft Windows Active Directory.

Simply put, a Notification Group is a collection of operators. The only purpose of a Notification Group is to associate with a notification response on an alert (or event). Much in the same way that rules cannot be directly associated to a computer, an operator cannot be directly associated to a response. This is illustrated in Figure 8-5 where OpsGuy1 and OpsGuy2 belong to the Network Administrators group.

Figure 8-5

An Operator in this case, defines an individual and their methods to receive notification. Each Operator can be notified via e-mail, page, or some type of external command. Furthermore, each notification type can be adjusted to occur only during set hours. For example, if you set up OpsGuy1 for e-mail and page, you could have e-mail notification for OpsGuy1 from 8 a.m. to 5 p.m., Monday through Friday. On Saturday and Sunday, be kind and page him 24 hours a day.

Scripts

As discussed earlier, an event can be a single line out of log file, a successful security audit logged to the event log, or an indication that an interval of time has passed (timed event). Microsoft Operations Manager has the capability to run scripts as a response to an event.

MOM supports the following kinds of scripts: VBScript, Jscript, and Perl. Although most situations can be detected by the various Providers MOM has to offer, sometimes the information is not readily available via those means. These are typical scenarios where it may be more suitable to have a script search for a problem condition.

Note 

If you're familiar with scripting, you may be used to having certain things available to you in a script. For example, the Wscript object available in WSH (such as Wscript.Echo) is not available in the MOM environment.

Scripts created in MOM can use parameters. This is extremely useful for two big purposes. First, script modifications can be shielded by allowing changes to the parameters instead of the code. Typos not required! Second, the same script can be used for different sets of values. For example, if you are using a script to look for low disk space on drive C: against two different sets of computers that operate under different thresholds, parameters in the script would be useful to quickly set different values. This way, the same script can be used with different values for each Computer Group.

Important 

In order to use parameters in a script, the parameter must be defined in the script and the Parameter tab with the same name. For instance, the script Microsoft Windows Base OS CPU Overload Script has the parameter CPUPercentageThreshold defined.

In the script itself, the value for CPUPercentageThreshold is pulled by using ScriptContext.Parameters.Get ("CPUPercentageThreshold").

Computer Attributes

Attributes are, in many ways, a type of mini-inventory system. Because a Computer Attribute can query for any registry key or value, it can detect quite a number of things. This table illustrates a few attributes that are in the more common management packs.

Name	Description
Microsoft SQL Server 2000	Checks for the existence of HKLM Software\ Microsoft/Microsoft SQL Server\80\ MSSQLLicenselnfo\MSSQL8.00
Microsoft Windows Server Clusters	Checks for the existence of HKLM/Cluster
Microsoft DNS Server	Retrieves value of HKLM\System\CurrentControl Set\Services\DNS\Start and converts to an integer
Microsoft Operations Manager 2005 Server	Retrieves value of HKLM\Software\Microsoft\ Microsoft Operations Manager\2.0\Setup\ ServerVersion and converts to a string

The MOM agent retrieves the values specified in the Computers Attributes section, if they exist. After the values are retrieved, they are populated in the MOM database. Now they're ready for use in Computer Group formulas.

There is a significant advantage to using formulas with attributes as Computer Group membership criteria. By default, discovery for attributes runs every 60 minutes. For example, if DNS service was removed from a domain controller, eventually the agent would no longer detect the registry key for DNS. Because the Computer Group formula stipulates that AttributeValue(Microsoft DNS Server) is part of the criteria, it would no longer belong to the Windows 2003 DNS Servers Computer Group. On the other hand, if the server was manually added, it would have to be manually removed as well.

Providers

Providers are another piece of the entire system. These "provide" sources of information to the MOM agent. In order for a rule, Event, or Performance, to gather data, the Provider must be defined first. Many of the providers that you'd probably use in your custom rules are provided for you. These are generally imported as part of the management pack.

Providers can access the following data sources:

• Windows NT Event Log: This provider can pull data from the Application, Directory Service, DNS Server, File Replication Service, Security, and System event logs.

  Important 

  It may appear that the Windows NT Event Log is limited to the types in the drop-down list. However, if an event log exists that is not defined in the drop-down list, it can be manually entered in the Log type field.

• Windows NT Performance Counter: Just as it sounds, this provider pulls data from any performance counter available on the computer. During the creation of this provider, remote computers may be specified to pull additional counters that are not readily available locally.

• Application Log: This should not be confused with the Application Event Log. This is strictly for IIS web server logs, IIS FTP server logs, Syslog port, or a single-line log file. A single-line log file simply means that the MOM agent will read the log as new lines are written. This is a very common provider in the SMS MP.

• WMI Events: WMI queries can be specified in this provider to pull back properties from a specific namespace.

• WMI Numeric Events: This provider can sample numeric data from WMI from classes such as Win32_Process.

• Timed Event: This is the provider that is used for providing events at specific intervals. Intervals can be specified in days, hours, minutes, or seconds. For instance, if the interval is specified at 2 hours, this provider will generate a Timed Event every two hours.

The Providers that come out of the box with MOM 2005 are specifically geared toward Windows systems (except the Syslog Port). In order to monitor other systems, third-party vendors provide other means to gather data.