Chapter 3 left off with agents deployed and their health confirmed. Some agent heartbeat data was returned from the agents to the management server. This is because the MOM 2005 management pack is automatically imported when the management server is installed and distributed to the agents. This management pack was expanded in Figure 3-40.
Microsoft supplies management packs for most of its server products; see http://www.microsoft.com/management/mma/catalog.aspx for the current listing. They also ship 11 of the most commonly used management packs on the MOM 2005 product CD. If you are working with the MOM 2005 Workgroup edition, all of these are imported during setup.
For the MOM 2005 full edition of the product, you must import all management packs and reports manually. To start importing a management pack, first make sure that you have downloaded the most current version. Create a network share to store these management packs. In Figure 4-1, it is called the File transfer folder
. In this folder, create three subfolders: CurrentMP, OldMP, and VendorSupplied. Place all the downloaded management packs in the VendorSupplied folder. Each of the management pack executables creates a folder as it extracts. In the contents of the extracted management pack folder, each management pack file ends with the .akm extension, and reports have the same name but end with Reports.xml.
On one of the management servers, open the Administrator console and right-click the Management Packs node to bring up the context menu. Select Import/Export Management Packs. You can also select the Import/Export Management Packs hyperlink in the Results pane, but then you won’t know how to manually navigate the consoles. This starts the Import/Export Management Packs wizard (point 1 in Figure 4-1). After the Welcome page, choose either “Import Management Packs and/or reports” or Export Management Packs (see Figure 4-2). You cannot choose to export report definitions through this tool. It can be done with the Report Utility (rptutil.exe) tool found in the root of the MOM 2005 installation directory (usually C:\Program Files\Microsoft Operations Manager 2005).
On the next page of the wizard, browse to the folder that contains the management pack file that you want to import. In this case, \\MPTransferFolder\VendorSupplied has been mapped to the Y: drive, as shown in Figure 4-3. You are prompted for the type of import to perform: management packs only, reports only, or management packs and reports. Notice that the options for importing reports are disabled in this
Figure 4-3. Because Reporting Services are not installed in this management group, only management packs can be imported
figure because the management group does not have MOM 2005 Reporting Services installed. If you install Reporting Services later, you will need to re-run the Import/Export wizard and select “Import reports only.”
This next page of the wizard is critical to version control of management packs (Figure 4-4). The top box lists all the management packs in the folder. Figure 4-4 shows the base OS management pack selected. When the Import/Export wizard executes, it will search the operations database for the presence of this management pack by its globally unique ID (GUID), not by its name. Therefore, you can have two different management packs with identical names active in the same management group at the same time. Similarly, each rule in a management pack is identified by its GUID, not its name. This is a feature that can be made to work in your favor when you need to alter a vendor-produced management pack rule to create a custom rule.
In the Import Options box, you have two choices: update the existing management pack or replace it, or back up the existing management pack. Your first choice depends whether you need to preserve existing data in a management pack or overwrite it completely. Unless the management pack is completely useless, you should always select to back it up. Save your backup to the \\MPTransferFolder\OldMP directory. The Import/Export tool will create the backup .akm file with a timestamp appended, allowing multiple versions of the .akm file to exist in the same folder at the same time. For example, this particular run of the Import/Export tool created a backup file named MICROSOFTWINDOWSBASEOPERATINGSYSTEM_02.23.05 21.27.52.akm. This management pack is being imported into a preproduction management group, so there is no existing data to preserve. To ensure that the management pack is in a known state after the import has completed, choose the Replace option.
After reviewing the Summary page, click through it. The Import/Export wizard presents you with an Import Status window for immediate feedback on the success or failure of the import process (see Figure 4-5).
If you wish, you can export the entire text of the import process using the Create Log File option. If you do, give it the same name and timestamp (ManagementPackName_MM.DD.YY.HH.MM.SS.akm) as the backup file and place it in the OldMP directory.
Referring back to Figure 4-1, the management pack is now in the preproduction environment and is represented by the RAW MP (MP.1.0) object.
In the Administrator console, several new objects now exist in the Management Packs node , as shown in Figure 4-6:
In the Computer Groups node, groups now exist that will be used to gather computers with common attributes together, such as the Microsoft Windows 2003 Servers group. Membership in a computer group is calculated based on a formula containing attributes that define the computer group on the discovered servers. When a match is found, the discovered computer is added to the computer group. Computer groups are used to target the application of processing rules.
A rule group bearing the name of the management pack that was just imported. Rule groups contain three top-level rule types: event rules that monitor the event logs or that run on a timed basis, alert rules that can execute a specific notification for all the alerts raised in the rule group, and performance rules that can be used to collect performance monitor statistics and generate alerts if a threshold is crossed.
Application-specific task definitions for use in the Operator console.
Scripts that are called by event processing rules.
Computer attribute entries that define data that is used in the computer group membership calculation formula. For example, the Microsoft Windows Base OS management pack creates an attribute called Windows Current Version. This attribute defines the Windows registry path search to collect the running version of the OS on a managed computer.
Providers, which are predefined sources of data, such as a specific performance monitor counter or a timed event, that are used by the rules.
When a new management pack is imported, the agents request configuration data from the management server. The management server responds with the agent settings (see Chapter 3), the list of additional management servers in the management group, and the registry key-based attributes to collect. The agent then returns the registry key information to the management server and the computer group membership is calculated.
For example, in the LKFPreProdMG, after the Windows Base OS management pack is imported, a computer attribute definition named Microsoft Windows Current Version returns the value found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\CurrentVersion. When the membership for the computer group Microsoft Windows 2003 Servers is calculated, a computer is placed into that group if this formula is evaluated as true for that computer:
AttributeValue(Microsoft Windows Current Version)="5.2"
Each computer group is associated with one or more sets of rule groups. At the next agent configuration request interval (default is 1 minute), the management server responds to the agent configuration request with all the processing rules that apply to the computer group members.
Computer groups do not need to be created only for applications. They can be created based on geographic location; administrative responsibilities; or on a line of business application, such as SAP or PeopleSoft, that include multiple components. MOM carries out this registry-based computer attribute discovery on all monitored computers, which allows you to classify machines into broad groupings. Computer groups can be nested and individual computers can belong to more than one group. For example, all agent-managed Windows 2003 domain controllers are also in the Windows 2003 Servers, the Windows Server, and the MOM 2005 Agents computer groups.
Some of the rules that are pushed out to the agents are service discovery rules . These rules gather additional data about the service components, the relationships between computers, and the roles of computers. The data that service discovery gathers is used to monitor the health of components that support a service as well as other things.
For example, for an IIS server to be healthy, the WWW, SMTP, and FTP services need to be healthy. MOM must be aware of the relationship between a frontend Outlook Web Access (OWA) server and its backend mailbox server.
Service discovery data enables MOM 2005 to render diagrams that show the relationships between computers, to dynamically add and remove computers from computer groups, and to identify computers that can be targets of certain types of tasks. Much of the state roll-up process draws on the data that is provided by service discovery.
Service discovery is performed by scripts that are run by event rules at timed intervals. The timing for running the service discovery rules is predetermined by the management pack author and it is not something that should be changed. A timed event provider is a timer that can be used to trigger a rule, task, or response to occur at predefined time intervals.
So at this point, Leaky Faucet has imported management packs into the LKFPreProd management group. MOM has performed both the registry key-based attribute discovery and the more in-depth script-based service discovery, and the computer group membership has been calculated. All appropriate event, alert, and performance rules are being executed by the agents. Leaky Faucet is now at point 2 in the management pack life cycle workflow (see Figure 4-1)--and they are ready to tweak the management pack processing rules to meet their needs.
The default configurations of the rules in a management pack represent what the management pack author defines as the health of that application. Microsoft puts considerable effort into authoring management packs that yield just the right amount of information, by tuning and tweaking the rules as best as possible for the application. Based on this, you may ask yourself, “Who am I to believe that I know more about what a healthy Exchange server or domain controller looks like than the vendor?” Why should you change any of the rules at all if that is how Microsoft says it should be?
The answer is simple: you must examine the rules from the perspective of applying them in your environment. You may choose to accept the default settings for some or even most of the rules, but keep in mind that Microsoft authored and tuned the management packs for a generic environment, not yours. To get the most out of any management pack, you will need to go through the rules and decide if they are:
- Necessary for your environment
Some management packs contain child rule groups for versions of the software that are not in your environment. For example, the Base OS management pack contains rule groups for Windows NT, 2000, and 2003. If you only have 2003 in your environment, then the NT and 2000 rules will get in the way.
- Raising alerts of the appropriate severity
Most event and performance threshold rules generate alerts and the alerts are created with a default severity. By default, it is the rule that monitors if a user cannot map a printer generates an error alert, but in your environment that may only be an informational alert.
- Being seen by the right people
Alerts appear in the Operator console, but they can also be forwarded to mailboxes, public folders, pagers, and any other communication channel that can be called from a command prompt or script.
- Applied identically to all computers in the associated computer groups
By default, all rules in a rule group are applied the same way to the computer groups that are associated with that rule group. However, you might have a subset of those computers to which you want the rule applied in a different manner. Perhaps you don’t want the rule applied at all, or perhaps there should be different matching criteria. For example, say you want MOM to generate an alert when the percent processor utilization on any server in the domain exceeds 75 percent for more than 10 minutes. But you don’t want to be alerted when this condition occurs on a server that is being load tested, or in that case, you want a threshold of 90 percent. Overrides allow you to make that kind of change. This type of tuning is very difficult to perform in the preproduction environment because you don’t have the same load on the managed computers. Extensive use of overrides should wait until the management pack is in production. For more information see the "Overrides" section later in this chapter.
Review the management pack guide for the management pack you are working with. Management pack guides contain information on the rules , scripts, and the overall configuration of the management pack. However, not all management packs have a guide, only the more complicated ones do.
Management packs will need to be tuned many times, especially when you are new to MOM. At this point, you are rough-tuning the rules and management packs. Once you have more experience with the data these rules produce in your environment, you can go through them again and refine them further. In this first pass, only consider if a rule or rule group should be enabled or disabled, if the alert is of the correct severity, and if the correct notifications are being sent out. The goal of this is to ensure that only the necessary rules are processed and that the data produced by the rules is what you want.
There are three main rule categories: event rules , alert rules, and performance rules. There are also different flavors of event and performance rules.
- Event rule
Monitors Windows event logs for the presence or absence of events. When a match is found, the event rule takes whatever action is defined in the responses tab for that rule.
- Alert/response rule
This is the most generic type of event rule. It monitors a provider data source for a match, or it may use a timed event provider. A timed event provider is a timer that causes tasks or responses to occur at predefined intervals.
- Filter rule
Filter event rules do one of three things:
- A pre-filter rule
Watches for an event and deletes it; the event never makes it to the operations database and no alert or action can be taken based on that event.
- A database filter
Keeps the event data for use in correlating other data. The sum of this event data may raise an alert or cause other action to be taken, but the filter does not insert the individual event into the operations database.
- A conditional filter
Causes an event to be disregarded unless another rule would process that event.
- Detect missing event rule
This type of rule alerts you when something did not happen in the time frame that it was supposed to. For example, say backups generate a 123456 event in the application event log when they complete successfully and your backups should finish between 3 a.m. and 6 a.m. You can configure this rule to look for the 123456 event in the application log between the hours of 3 a.m. and 6 a.m. and raise an alert if the event is not there.
- Consolidate similar events rule
This event rule looks for multiple occurrences of similar events (you define what similar is) occurring within a given time frame on one computer and generates a summary in a single event.
- Collection event rule
Use this rule to collect events from a certain source and store them in the operations database for later examination.
- Performance rule
This rule always watches performance monitor counter providers for data.
- Sample performance data
This type of rule is much like the event collection rule. It collects performance monitor data for later use.
- Compare performance data
This is the performance threshold rule. The MOM agent compares samples of performance monitor data to set values (thresholds) and raises an alert when the sample shows that the counter has crossed the preset threshold.
There is only one type of alert rule and oddly enough, it doesn’t create alerts. Alert rules are used to provide a common response for a number of event or performance rules . For example, in the Microsoft SQL Server\SQL Server 2000\SQL Server 2000 Event Collection\SQL Server Agent rule group there is an alert rule called Critical Error or higher - Database Administrators. This alert rule fires when a critical error alert or greater is generated by any of the rules on the SQL Server agent rule group. This alert rule runs a notification response to the database administrators notification group. Using alert rules saves you from configuring a response for every event and performance rule that generates an alert.
The examination and tuning process can be tedious and is made all the harder if there is no management pack guide for the management pack you are evaluating. Always check to see if there is a management pack guide. See the "Additional Management Pack Configuration" section later in this chapter. The management pack guides outline all the rules of a management pack, including the rule severity, the path to the rule, whether the rule is enabled or disabled, and, in some cases, the response.
You will have to go through the rules, one at a time, in the Administrator console. Consider the following as you go through the rough-tuning process.
Some rule groups contain rules for different versions of an application or OS that may not even be running in your environment. By disabling them, the processing load is reduced on the management server and the agent. The unneeded rule group could also be deleted, but that is a little drastic. If you ever need the functionality supplied by that rule group, you can simple re-enable it.
For example, the Base OS management pack contains rule groups for Windows NT 4.0. If there is no NT 4.0 server in your environment, disable the rule group and all child rule groups. To do this, bring up the context menu for that rule group, select Properties and then clear the Enabled checkbox (Figure 4-7).
Make sure you go to the Knowledge Base tab and edit the Company Knowledge base to include what modification was made, why it was made, when it was made, what environment it was made in, and who made it. This can be as simple as “This rule group was disabled in the preproduction environment because there are no NT4.0 servers to be monitored. 2/26/05, CJF.” When a rule group has been disabled, its folder icon is disabled (Figure 4-8).
Once you have disabled the obviously unnecessary rule groups, go through the remaining rules and repeat the same process. There will likely be rules that you don’t want to be active.
For example, in the Leaky Faucet environment, Windows servers are patched via SMS, so there is no need to use the Automatic Update Service. Consequently, communication with that site is blocked at the firewall. When Max reviews the Windows Server Base Operating System management pack he discovers a rule called “Windows is unable to connect to the Automatic Update service” in the Core System Components and Services rule group. Because of the environmental configuration, this rule will raise an alert every time the automatic update service attempts to connect to the web site, which it will do once a day unless it is disabled. To prevent generating unnecessary alerts from servers whose Automatic Update Service is still running (perhaps by mistake), Max disables this individual rule.
To disable the individual rules, clear the “This rule is enabled” checkbox on the General tab of the Rule Properties (Figure 4-9). Be sure to make note of the what, why, when, where, and who of the modification. When a rule is in a disabled state, a red X appears through the rule icon.
An enabled rule will be applied to all computers that are in the associated computer groups. Disabled rules are not applied to those computers. There will likely be cases when you want a rule applied to some computers but not others in the same computer group. To do this, you can use the “Enable rule-disable overrides for this rule” feature.
On the General tab of the Rule Properties tab, there is a checkbox for enabling overrides (see Figure 4-10) just below the “This rule is enabled” checkbox. An override is a way of allowing an exception to a rule without having to create an additional rule. For example, for the event rule shown in Figure 4-10, by enabling the “Enable rule-disable overrides for this rule,” the rule for a specific computer can be disabled, even if that computer is a member of the computer group that the rule is applied to. Figure 4-10 shows the “Windows is unable to connect to the Automatic Updates service” rule.
Let’s say that Leaky Faucet needs to keep this rule enabled because SMS has not been deployed to the remote site servers and the remote site administrators have implemented Software Update Services (SUS). However, the servers that Max and his team administer are using SMS. Rather than creating separate rule groups and computer groups, rule-disable overrides are enabled for this rule (point 1 in Figure 4-10). Once enabled, Max uses the Set Criteria button (point 2 in Figure 4-10), which defines a set of computers (his) that this rule is disabled for. This leaves the rule active for the remote site servers.
The defined criteria are simply a pairing of computers and/or computer groups with an enable/disable flag.
There are four types of overrides: rule disable, performance threshold, script parameter, and state alert severity. I will cover these more in the discussion on tuning managment packs once they are in production (see "Transfer the Management Pack to Production" later in this chapter).
Not all rules generate alerts. For those that do, be sure to check the severity setting on the Alert tab of the Rule Properties. Make sure that the severity of the alert is what you want it to be by using the default as guidance. The management pack authors assigned the default severity when it was developed. So, if the generation of any particular event returns a critical error in any monitored application, you shouldn’t change the alert severity to “information alert.” If a change to the default severity level is necessary for your environment, do not make it here. Instead, bring up the context menu, copy the rule, and paste the new rule into the same rule group as the original. This will create a copy of the rule with the rule name prepended with “Copy of.” This rule will have a different GUID, but otherwise it is identical to the original. Rename the rule by removing the “Copy of” prefix and replacing it with some specific tag that identifies it as a company-modified rule.
For example, in the Leaky Faucet environment, a copy of the “Software update installation failed” event rule has been made and prepended with the LKFPreProd tag (point 1 in Figure 4-11). The original rule is then disabled so that it will not be distributed to the agents. Adjustments must be made to the company-tagged version of the rule; in this case the alert severity is changed from Critical Error to Error (point 2 in Figure 4-11).
This process will protect your customized rules when you have to update the existing management pack, since user-modified rules are not overwritten by this type of import. Also, by keeping the rule in the same rule group, you take advantage of the pre-existing rule-group-to-computer-group association, which ensures the modified rule will be executed by the correct computers. This is where having two identical rules in the same rule group comes in handy.
Alerts serve no purpose if they aren’t visible to responders. You could ensure visibility by having someone watch the Operator console all day long, but that’s not practical.
While the management pack is still in the preproduction phase, configure notifications in the Administrator console (see Figure 4-12). Notifications need to go to the people that can investigate or fix the issue. If an alert indicates an outage of a major system, such as an Exchange mailbox store going offline, you may want an executive sponsor of that system notified to communicate the outage to the rest of management. Ultimately, who you place in the notification groups is up to you. In the Notification node, you create and manage operator objects and notification groups. In the management pack, you will need to examine the alert rules response tab and adjust it to send a notification to a notification group. If the notifications are to be sent via SMTP, you must enter a valid SMTP server and return address in the Administrator console → Administration node → Global Settings → Email Server tab properties. For the purposes of sending SMTP mail, any SMTP server will do; it doesn’t have to be Exchange. The SMTP service in IIS works well and its licensing is included in the OS. Another benefit is that if the monitored Exchange SMTP server is down, the notification will still go out.
Leaky Faucet is concerned about unexpected service terminations on all Exchange servers. If an Exchange-related service stops, they want MOM to send a page to the Windows platform administrators who are Exchange administrators. If a non-Exchange related service stops, they want an email sent only to the help desk with an alert severity of Error, because the default severity (Service Unavailable) is too extreme. Leaky Faucet must modify the rules in the Exchange 2003 Unexpected Service Termination Rules rule group and configure notifications to accomplish this.
To modify the rules, the first step is to create an operator object. This is not a domain account, although it can appear that way. Instead of naming the objects for people, you can just as easily name a pager (e.g., Email On-call pager) or a distribution list with an SMTP address or a monitored shared public folder.
An operator object has only a few properties. It has a name, an SMTP address, a pager address (also SMTP), an entry for calling an external command, notification group membership, and it can be enabled or disabled (see Figure 4-13).
The “Email On-call pager” entry has been defined as an operator. It will receive notifications via the information entered into the Page Configuration tab of the Operator Properties. Help desk operators will receive an email when an alert is generated and will work to solve the problem.
The Email, Page, and Command tabs that are configurable via the operators object properties are almost identical.
Figure 4-14 shows the Page tab for the “Email On-call pager” operator object in the Leaky Faucet environment.
On this tab and the email tabs, Max can enable this communication channel, provide the SMTP address to send the notification to, and specify if this channel is used at all times or according to a schedule. On the Command tab, Max provides the operator ID. Lastly, on the Notification Groups tab, Max adds the operator to the desired notification group—in this case the Mail Administrators notification group. The help desk operator objects have been added to the Level 1 Operators notification group.
To complete the configuration of this notification process, Max must modify the alert rule in the Unexpected Service Termination Rules rule group. To find this rule group, in the Administrator console he navigates to Rule Groups → Microsoft Exchange Server → Exchange 2003 → Availability and State Monitoring → Unexpected Service Termination → Unexpected Service Termination Rules. This rule group has two event rules and one alert rule, which are straightforward examples of event rules.
- Unexpected Exchange-related service termination event rule
This rule monitors the Windows system event log (Data Provider tab) on an Exchange server for event IDs 7031 or 7034 from the service control manager that involve any of the Exchange critical services, such as IIS, SMTP, WWW, and Information store. The event-matching criteria can be found on the Criteria tab by clicking the Advanced button. When it finds one of these event IDs, the rule generates an alert of severity Service Unavailable as indicated on the Alert tab.
- Unexpected service termination (not Exchange-related) event rule
This rule looks identical to the Exchange-related rule, except that in the criteria formula the value for parameter 1 (point 1 in Figure 4-15) is “doesn’t match regular expression” whereas in the other the value is “matches regular expression.”
When a rule can be described in a single sentence it follows this pattern: “The rule monitors provider for event/value and when it finds a match it generates an alert/executes a response.” The parameters on all the other tabs simply serve to modify the data produced by three core components of an alert definition. The Exchange-related service termination rule needs no modification to function properly.
For the non-Exchange-related service termination rule, Max needs to change the alert severity to Error. Following the rule modification procedure, there are three event rules, the original Exchange-related rule, the disabled original non-Exchange-related rule, and the modified copy of the non-Exchange rule, which is now tagged with the LKF prefix.
The job of the single alert rule in this rule group is to send a notification to the Mail Administrators group if an alert of severity Error or higher occurs. For an alert rule, the provider and criteria functionality is combined on the Alert Criteria tab. The notification is configured on the Responses tab. Since the event rules in this rule group will generate alerts of severity Error or Service Unavailable and an alert rule can only address one alert type, Leaky Faucet will need two enabled alert rules. Max will need to do the following:
Copy the single alert rule and change the name to “LKF Notification sent to Exchange administrators if Severity Level is Critical Error or higher.”
On the Alert Criteria tab, go to the Advanced Properties, select the criteria “Severity is at least Error” and remove it (see Figure 4-16). This will bring the Field, Condition, and Value parameters into the lower drop-down boxes for editing.
Change the Value field to Critical Error and add it back to the list. The criteria description on the Alert Criteria tab will reflect this change (as shown in Figure 4-17). No other change to this rule is required since the action on the Responses tab is to notify the mail administrator’s notification group.
Copy the original alert rule again and rename it to “LKF Notification sent to Helpdesk Operators if Severity Level is at most Error.”
Change the alert criteria from “Severity is at least Error” to “Severity is at most Error.”
Modify the notification group on the Responses tab from the Mail Administrators group to the Level 1 Operators group and disable the original rule.
Commit the changes.
Once the configuration is complete, the sequence of events from a service stopping to the Windows administrator receiving an alert is:
The SMTP service on an Exchange server unexpectedly stops.
A 7031 or 7034 event is placed into the system event log on that server.
The MOM agent on the Exchange server detects the event, compares it to the Unexpected Exchange-related service termination event rule criteria, finds a match, and generates an alert of severity Critical Error.
The MOM agent detects the generation of the Critical Error alert from the Unexpected Service Termination Rules rule group, and compares it to the alert criteria in the alert rule “LKF Notification sent to Exchange administrators if Severity Level is Critical Error or higher.” Finding a match, the agent executes the action configured on the Responses tab, which is to send a notification of the alert to the Mail Administrators notification group.
The alert is also forwarded to the management server, which passes it to the operations database and makes it available in the Operator console.
The agent on the management server reads the membership in the mail administrator’s notification group, then reads the configuration for sending a notification to the “Email On-call pager” operator object. This is configured for sending the notification via page to the SMTP address emailoncallpager@bigpagercompany.net.
The management server then formats the SMTP message according to the configuration defined on the “Notification sent to Exchange administrators if Severity Level is Error or higher” alert rule for the rule group. The page can either use a default format or a custom-defined one. This is on the Alert rule properties → Responses tab → Edit the responses → Page tab.
The SMTP email notification is sent to the emailoncallpager@bigpagercompany.net SMTP address via the SMTP server that the management group is configured to use.
The alert is available in the Operator console for the systems administrator to examine.
Some of the more advanced management packs, such as Exchange, Active Directory, or SQL Server 2000, require additional configuration to be fully functional. If the additional configuration is not too extensive, the necessary steps will be presented in the Results pane when the desired rule group is selected (Figure 4-18). If the additional configuration is extensive or the management pack is particularly complex, there will be a management pack configuration guide. This is the case with the Exchange 2003 management pack for MOM 2005 . This management pack has a 130-page configuration guide and an additional tool that can be used to facilitate configuration of the management pack and all of its components.
Unfortunately, Microsoft does not bundle the management pack guide with the management pack download, so you have to search Microsoft’s web site. The Exchange 2003 management pack guide is available at http://www.microsoft.com/downloads/details.aspx?FamilyId=2215EEAB-41D7-423D-9F54-01F0DF4647E9. For a listing of all management packs and their guides, go to the product documentation page, http://www.microsoft.com/management/mma/catalog.aspx.
Before deploying any Microsoft management pack into production, read its documentation to avoid any unnecessary errors that might arise from management pack misconfiguration.
Tuning management packs and processing rules is more of an art than a science, and you need to have experience with MOM 2005 and deep knowledge of your environment to be successful. When you are modifying rules and need to test a change, use the Event Creator (EventCreator.exe
) tool in the MOM Resource Kit. This tool creates and places an event in the event log of your choice, as shown in Figure 4-19. The target machine can be configured, as well as the log to create the event in; the source of the event; and the event ID, type, category, and username. You should know all of these parameters since the event processing rule for that event is already configured.
Figure 4-18. Basic management pack information and configuration steps are included with the management pack itself
Another useful tool to run in your preproduction environment is the Microsoft Operations Manager MPNotifier management pack . This simple management pack consists of two event rules, an alert rule, and a script.
Once every 24 hours (1,440 minutes) the Microsoft MPNotifier Version Check script is called, which collects an XML file from a Microsoft web site (http://www.microsoft.com/management/mma/momnotifier.xml). This file contains the current version of all the Microsoft-authored management packs. The versions of the existing management packs are compared to the current ones in the XML file and an error is generated if your existing management pack versions are behind the currently released version from Microsoft.
Many other rule parameters can be tweaked, but there is no reliable way to tell which rules and rule parameters will need further tuning or exactly how to tune them until the management pack is deployed into production .
Get Essential Microsoft Operations Manager now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
