Getting Started with Management PacksMany 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 PacksIn 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:
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:
Group TypesMicrosoft 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 GroupsAs 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.
FormulasFormulas 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. State Roll-Up PolicyThis 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. Console ScopesConsole 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 GroupsDiscovered 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:
Rule GroupsThe 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 RulesEvent 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:
Performance RulesPerformance Rules collect data from the performance instrumentation of a Windows OS. Types of Performance Rules include the following:
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 RulesEvents 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.
TasksTasks 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.
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 GroupsBy 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. 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. ScriptsAs 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.
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.
Computer AttributesAttributes 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.
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. ProvidersProviders 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:
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. |