Creating a management pack is an entirely different process than tuning an existing one. It can be quite involved and, depending on the functionality you want to include, it can require the knowledge of an application architect, as well as advanced programming skills for scripting and managed code responses. You need knowledge of all the indicators that can be used to define health states, services, events, performance counters, registry keys, and other identifying information.
However, odds are that you will never have to author a management pack for an application as complex as SQL, MOM, or Exchange. If you need to author complex management packs, refer to the Management Pack Development Guide from Microsoft. At some point you may have to provide basic monitoring for a homegrown application or a single service at your company. That’s what this section is about, implementing a simple management pack to monitor the Windows Update Service.
To monitor an application, the application must either run as an installed service, have performance monitor objects, or have a
.dll that writes events to any of the event logs. Without one of these three, it is very difficult to monitor the application.
The Management Pack Wizard (
) is a MOM 2005 resource kit tool that walks you through the creation of new MOM roles and the processing rules that monitor that role based on defined components. It generates event rules that feed into health state and alerting, so the defined role will appear in the State view in the Operator console. If the application has performance monitor objects, the wizard can generate performance rules. The output of the wizard is the management pack
.akm file and the XML version of the management pack.
The wizard does not create computer groups, views, or tasks for the Operator console; in fact, when imported, a management pack created with this tool is not associated with any computer groups. This means that its rules will not be deployed and service discovery will not be performed until the rule group is associated with a computer group. It also does not create any alert rules, so if you want an action taken in addition to an alert being displayed in the Operator console, you will have to configure those as well. The wizard only runs on a management server, although at the appropriate points it will allow you to browse the services, events, and performance monitor counters on remote machines if the application of interest is not installed on the local machines.
This example uses the tool to create a management pack for the Windows Update Service. This application installs a service named Automatic Updates and an associated
wuaueng.dll that the event log messages can be pulled from. It doesn’t have any performance monitor objects. This is an important point to remember.
To start the tool, navigate to the
MOM 2005 Resource Kit\Tools\Management Pack Wizard directory and launch
mpwizard.exe. This brings up the first page (Figure 4-43), where the three types of monitoring (service, performance, or event) for this management pack are listed.
Knowing which types of monitoring will be performed beforehand is important because this tool presents pages based on the selections made here. Because the application does not have any associated performance monitor counters, don’t bother selecting the Performance Threshold Monitoring options. However, since the application installs a service and generates events, select those options. Click Next to go to the Role Name creation page (Figure 4-44). The role name that is defined here will appear in the State view of the Operator console for every computer that is running this service. For this example, the role is called AutomaticUpdate.
Roles are the objects in MOM 2005 that reside immediately underneath the computer objects (as shown in Figure 4-40). The health state of each role on a computer is included in the health state roll-up calculation for the computer as a whole.
Click Next to bring up the Role Components creation page (Figure 4-45). Two components that match the types of monitoring indicated on the Welcome page have been created: AutoUpService and AutoUpEvent. On this page, enter a component name in the upper box and then click Add.
Click Next to go to the page where the details of the service are defined. It is initially blank, so click the Add button to select the service that you want to monitor (Figure 4-46). This application only installs one service, so there is only one to monitor. This is very different from building a management pack for an application like Exchange 2003 that has more than four services to monitor. However, you would never use this tool to create a management pack for something like Exchange.
On this page you can attach to a remote computer to get a list of the services there. You’d need to do this if the service you want to monitor is not on the local machine. Also, at this point the tool is only looking for a sample of the service to be monitored. Based on this, it will create the service discovery rules that will discover instances of this service on all the computers associated with this rule group.
Click Add to go back to the Windows Service Monitoring page, which has now been populated with the Automatic Updates value in the Service column. Select the appropriate component that was created previously to associate with this service; in this case, the AutoUpService component (see Figure 4-47).
If you had selected the Performance option on the Welcome page, the wizard would go through the identification of performance objects and allow you to set thresholds and their associated red X and yellow warning triangle flags.
In this case though, since Automatic Updates has no performance objects, clicking Next brings you to the events identification (see Figure 4-48).
Figure 4-47. Create the association between the service to be monitored and the component that you created
The Event source drop-down menu lists all the event sources that are available on the local machine. Note again that you can bind to a remote machine if necessary. Select Automatic Updates here and all of the event IDs along with their descriptions are populated in the lower box (see Figure 4-49).
Figure 4-50. This page shows the event rules that will be created and the default alert severity that they will generate
This list is relatively short compared to some others (think of how many events are associated with the OS), so select all of them and click Add. This populates all the events into the Event Source Monitoring page with a default alert severity of Warning (see Figure 4-50).
Rules that indicate similar events, such as the two Installation Ready or the two Restart Require rules, can be combined. When two event rules are combined into a single rule, the criteria in the resulting event rule will include both event numbers. This is a useful thing to do when two events are similar and you would want to generate the same alert for both of them. By selecting any individual rule and editing it, the default name and the severity level can be changed (see Figure 4-51).
Figure 4-51. Change the default alert severity from Warning to Error for a patch installation failure
Combine the Installation Ready and Restart Required rules and edit the default alert severities of Success and Failure rules to be Success and Error, respectively. This creates a framework for the event rules, shown in Figure 4-52.
Click Next to go to a Summary page to review your choices. After that the management pack is built and the customary Finish page appears. It also tells you the location and the name of the newly minted management pack. The tool will create the
.akm and XML files in the same directory that it was launched from and with the name you created for the role.
Import the management pack into the preproduction environment using the Import/Export wizard. The rule group that has been created has seven event rules, no alert rules, and no performance rules (Figure 4-53). Five event rules map to the five shown in Figure 4-52, the other two (circled) are the service discovery timed event rule and the health state alert rule.
All of the rules have been generated by the wizard. The script that the service discovery timed event calls was generated by the wizard and will run when the rule group is associated with a computer group. You already know what happens once the rule group is associated with a computer group.
On the context menu for the AutomaticUpdate rule group, associate it with a computer group. For the widest possible distribution for this rule group, associate it with the Microsoft Windows Servers computer group, which contains all Windows servers of version NT 4.0 and higher (Figure 4-54).
Figure 4-54. Associating the Microsoft Windows Servers computer group with the AutomaticUpdate rule group
The AutomaticUpdate service discovery is a timed event that runs once an hour, so health state information does not show up immediately in the State view, but once it does, the AutomaticUpdate role is added to all computers that are running this service (Figure 4-55).