Event notification policies vary from one organization to another. In some cases, it is a restricted process, in others it is highly automated. In general, it is a good idea to carefully define a notification strategy tailored to your unique requirements. For example, do you want to:
Send an e-mail after an event?
Send a page after an event?
Redirect a message after an event?
This section describes strategies you should consider before implementing event notification.
AppManager provides several options for sending an e-mail message in response to an event:
Messaging API (MAPI) mail messages
Simple Mail Transfer Protocol (SMTP) mail messages
Lotus Notes mail messages
To determine which type is best for your environment, consider the following:
Your e-mail software. For example, to send MAPI mail, you must have Microsoft Exchange or Outlook installed. To send SMTP mail, you must have an SMTP mail server. For Notes mail, you must have a Lotus Domino server and the Notes mail client installed.
Where you are sending the e-mail. For example, consider how you have set up mailing lists, aliases, and network connectivity. If you defined e-mail aliases for different groups and the addresses are all internal, you can use MAPI or Notes mail so that you are not sending messages through your Internet gateway to deliver internal mail.
Where the e-mail originates (from a central location or at each monitored server). Consider the requirements for each type of mail and how those requirements suit your environment. For example, MAPI mail requires you to install a MAPI client (such as Outlook) on the server that sends the mail message. Notes mail must be sent from a Domino server, so the mail must be sent from each server you are monitoring.
In most cases, SMTP mail provides the best method for e-mail notification. It does not require a client to be installed, so it can be easily configured to run from either the management server or the managed computers you are monitoring. The major drawback to using SMTP mail is that your SMTP gateway can have security rules that limit the users who can send mail through the gateway or the servers from which SMTP mail messages can originate. You should check with your SMTP gateway administrator to ensure the user account(s) that the AppManager agent services run under have permission to send mail on the servers from which the mail originates.
Depending on your environment you can use more than one mail method for event notification. For example, assume you have several Exchange servers you want to monitor on one continent and your SMTP gateway on another continent and IT staff that supports the Exchange servers is located in the same location as the Exchange servers, but the main administrative staff is located elsewhere. You might want the events associated with the Exchange servers forwarded to the IT staff using MAPI mail to avoid sending mail to another continent to reach the SMTP gateway then back to the local site for notification. Events that need to reach the main administrative staff might be configured to send SMTP mail and be routed through the SMTP gateway for distribution.
Depending on the paging system you use and the types of messages it can receive, there are several ways you can use AppManager to forward event information or custom information to the paging system. In most cases, you can send event information to a pager by:
The Action_Page Knowledge Script relies on the %SYSTEMROOT%/NetIQpage.ini file located on each monitored server. The NetIQpage.ini file is pre-configured with information necessary to send paging messages to several common paging systems.
To use Action_Page, install the client software for the paging application on the server where you run Action_Page. You typically install the client software on the AppManager management server and the management server initiates the paging action.
For more information on how to edit the NetIQpage.ini file and use the Action_Page Knowledge Script, select the Page Knowledge Script in the Action tab in the Operator Console and press F1.
Some paging applications accept SMTP mail messages to send pages. If your paging application accepts SMTP mail, you can configure an action to be initiated on the management server or on the individual servers being monitored.
To use SMTP, configure the Action_SMTPMail Knowledge Script with the recipient’s name in the proper format. Different paging applications have their own formatting requirements for SMTP mail recipients. For example, the recipient’s name parameter can be an individual’s name, alias, group, pager number, or PIN depending on the paging application (such as, 5443221@skytel.com or bridge12@samplepage.com).
For the SMTP server machine name, type the name of the SMTP gateway server. The SMTP server sends the message to the appropriate paging system domain and the domain delivers the e-mail message to the pager.
Some paging applications accept MAPI or Lotus Notes mail messages to send pages. As mentioned in Sending an Email Event Notification, both MAPI and Notes mail messages have special requirements for sending mail:
MAPI mail. To use MAPI mail, you must install and configure client software. It is usually best to set up MAPI mail as an action that executes on the management server.
Notes mail. To use Notes mail, you must run Notes from the Domino server(s) you are monitoring.
Some paging applications can accept input from other sources such as ASCII log files or the Windows Event Log. For these applications, you can use the Action_WriteMsgToFile or the Action_NTEventLog Knowledge Script, respectively. You should review your paging application’s documentation and the AppManager Help to see how to properly configure these Knowledge Scripts.
In addition, some unsupported Knowledge Scripts that interface with paging applications without using the NetIQpage.ini are available from the Knowledge Depot on the NetIQ Support Web site.
You can also write custom Knowledge Scripts that use the paging system’s API to perform tasks. If you decide to write your own scripts and create your own interface, see the Developing Custom Knowledge Scripts Guide for AppManager, available on the AppManager Documentation page, for information.
In larger organizations, administrators often integrate AppManager events into another management console or redirect events to a Help Desk application or tracking system. To help make this as transparent as possible, AppManager supports a variety of “connectors” to the most common event management consoles and help desk applications. For example, AppManager has connectors for:
Computer Associates Unicenter NSM
HP OpenView Network Node Manager (NNM)
HP OpenView Operations
Micromuse Netcool
Microsoft Operations Manager (MOM)
Tivoli Enterprise
You can use these connectors to integrate events into the management console applications you want to use. Connectors are installed on AppManager management servers, and they forward events to the management console as events are sent from the agents. For more information on AppManager connectors, visit the NetIQ Web site or contact a NetIQ technical representative.
If NetIQ Corporation does not currently have a connector for your management console application, you can often use Action Knowledge Scripts to transfer the event information to the application. For example, you can use Action Knowledge Scripts to:
Send an SNMP trap
Save information to the Windows Application Log
Write information to an ASCII log file
You can also create your own custom Knowledge Scripts and call a COM object or use a command-line interface to transfer the event information to the application of your choice.
Sending an SNMP trap is a simple and cost-effective solution for transferring event information to another application. It does not require any additional client software to configure or maintain or any additional client licenses for your event console or help desk application. If you use SNMP traps, you can run them as automated actions associated with a Knowledge Script, and configure two network paths for events to travel to separate applications.
You can configure automated Knowledge Script actions that write to the Windows Event Log or to an ASCII log file, or send command-line arguments to run on the managed computer or the management server. These methods usually require you to install, configure, and maintain a client executable for the product to which you want to connect on each managed computer that will be raising events. Therefore, you may incur additional licensing costs.
For these reasons, if you decide to forward events through the Windows Event Log, ASCII log files, COM, or a command-line interface, you may want to configure the event-forwarding action to take place at the management server to reduce costs.