TelAlert UMS Administrator Guide

Transcription

1 TelAlert UMS Administrator Guide Version 5.71

2 Copyrights Copyright , 2010 MIR3, Inc. TelAlert UMS Administrator Guide This document is copyrighted and all rights are reserved. The distribution and sale of this product are intended for the use of the original purchaser only per the terms of the Agreement. This document may not, in whole or part, be copied, photocopied, reproduced, translated, reduced, or transferred to any electronic medium or machine-readable form without prior written consent in writing from MIR3, Inc. MIR3, TelAlert, IN, inenterprise, inenterprisepro, inalertcenter, inalertcenterpro, incampusalert ingovalert, ingovalertpro, insalestalk, intechcenter, intechcenterpro, inwebservices, inconnect, inconsole and Enterprise Access Control are trademarks of MIR3, Inc. All other product and company names are marks of their respective holders. This document is the property of MIR3, Inc. and may not be distributed in any manner except with the express written permission of MIR3, Inc. Software Version: Sep2010 [ ] Document Revision: 3.0 MIR3, Inc Carmel Mountain Road San Diego, CA Phone: Fax: Web Site:

3 Preface The TelAlert Version 5.71 Administrator Guide describes how to use the TelAlert software. It can run on all major platforms (Sun Solaris, Windows, HP-UX and Linux). The information in this document is accurate regardless of the platform used to support the TelAlert system. This Guide does not include instructions about how to install, configure or integrate the TelAlert system with third-party data sources.

4 Table of Contents Introduction Overview TelAlert Overview TelAlert Text to Speech (TTS) Full Range of Voice Destinations Customizable Vocabulary in Four Languages Interactive Voice Response (IVR) Dialogic Telephony Card TelAlert Integrations TelAlert Integrations Make it Easy Do-it-Yourself Integrations for In-House Applications Supported Platforms Server and Client Platforms Client Platforms Operating Systems Not Supported for Version Guide Introduction Contents Audience Related Technical Documentation Product Support Contact Information TelAlert Solutions from MIR Guide Conventions Screen Captures File Locations. 11 Technical Overview Overview How TelAlert Works A Typical Alert TelAlert Programs and Processes Key TelAlert Files Key Configuration Concepts Sections, Definitions, Keywords, and Cross-Referencing Configuration Destination User Group Schedule Strategy Other Configuration File Sections.. 24

5 Implementation Planning Overview Your Accomplishments So Far Structure of the Administrator Guide Chapter 1: Introduction Chapter 2: Technical Overview Chapter 3: Implementation Planning Chapter 4: Configuration Basics Chapter 5: The Role of Ports in TelAlert Chapter 6: Dialing the Telephone Chapter 7: Configuring for Paging Notification Chapter 8: Configuring for Text to Speech (TTS) Notification Chapter 9: Configuring for Other Notification Media Chapter 10: Applying Filtering Techniques Chapter 11: Setting Up and Applying Schedules Chapter 12: Representing Users Chapter 13: Enabling Responses Chapter 14: Broadcasting to Groups and Creating Escalations Chapter 15: Processing Events Chapter 16: Miscellaneous Administrative Tasks Chapter 17: Security Features Chapter 18: Integrating XML Output The Alert Timeline Send and Release Send, Wait, and Release Send, Wait, Hold, and Release The Alert Timeline and Escalations Summary Organizational Scenarios Scenario One: Paging Only Small Organization Scenario Two: Paging, Voice, and Small Organization Scenario Three: A Larger Organization. 43 Configuration Basics Overview TelAlert Configuration Methods: telalert.ini; TADesktop Choosing a Configuration Method What Make TelAlert Re-Read its Configuration File Means Understanding Configuration Examples Singular vs. Plural Section Names Performing Common Configuration Tasks. 53 The Role of Ports in TelAlert Overview What is a Port? Basic Port Considerations. 58

6 5.4 If You Are Using a Terminal Server Testing Connectivity on a Terminal Server More Advanced Port Considerations Directing Specific Notifications to Specific Ports Providing Port Backup Controlling Port Deactivation Due To Errors What Remote Ports Are Used For.. 66 Dialing the Telephone Overview What s So Hard About Dialing the Phone? Local Dialing Alternate Numbers Inside and Outside Lines Special Dialing Scenarios Dialing After the Main Number is Answered Inserting Pauses During Dialing Dialing Logic Dialing Components Dialing Process Local Dialing Normal Local Dialing Ten-Digit Local Dialing Eleven-Digit Local Dialing Long Distance Dialing Normal Long Distance Dialing Other Long Distance Dialing Alternate Numbers Inside and Outside Lines Getting an Outside Line Getting an Inside Line Special Dialing Scenarios Dialing After the Main Number is Answered Dialing a Number, Then an Extension Dialing a Number, Then Accessing a Mailbox Inserting Pauses During Dialing Specifying Telephone Dialing Components at the Command Line Overriding the Need for Dialtone. 78 Configuring for Paging Notification Overview Getting Started Needed Information General Considerations Setting Up Text Paging Creating a Text Pager [Configurations] Definition.. 81

7 7.3.2 Pointing to a Modem Creating a Text Pager Destination Sending a Page by Invoking a Destination Sending a Page Without Invoking a Destination Sending to Text Pagers via [Configurations] Definitions of Type=InteractiveTextPager Sending Text Pages via Modem without TAP (Protocol=Chat) Setting Up Numeric Paging Sending Numeric Pages Using the TAP Protocol Sending Numeric Pages Without TAP Setting Up Two-Way Paging Creating a Two-Way Pager [Configurations] Definition Pointing to a Modem Creating Two-Way Pager Destinations Enabling Responses Enabling Polling Enabling Notifications Setting Up Requests: Unsolicited Messages From Two-Way Pagers Receiving Requests Having Requests Trigger [Notifications] Actions Simulating Requests for Testing Purposes Setting Up Internet-Based Paging One-Way Internet-Based Paging Two-Way Internet-Based Paging Initiating Pages via Responses to Two-Way -Based Text Pages Adding ID Numbers to Pages 105 Configuring for Voice Notification Overview Configuration for Voice Notification now in TelAlert Voice and Hardware Guide 107 Configuring for Other Notification Media Overview Getting Started Needed Information General Considerations Setting up Electronic Signboard Notification Signboard Overview Initial Signboard Firmware Setup Standard Signboard Setup (DeviceSubtype=2) TelAlert-Controlled Signboard Message Display Signboard [Port] Definition Signboard [Configurations] Definition Signboard [Destinations] Definitions Sending Messages to the Signboard.. 116

8 9.4.6 Controlling Signboard Text Color and Effects Configuring Multiple Signboards Alternative Signboard Setup (DeviceSubtype=1) Signboard [Port] Definition when DeviceSubtype= Signboard [Configurations] Definition when DeviceSubtype= Additional Signboard Firmware Setup when DeviceSubtype= Signboard [Destinations] Definitions when DeviceSubtype= Setting up Notification [Port] Definition [Configurations] Definition [Destinations] Definition Using as a Backup Notification Medium Handling Responses to With Readmail Setting up Command Line Notification Command-Line [Configurations] Definition Command-Line [Destinations] Definition Applications for Command-Line Notification POPUP Message Boxes on Windows Sending Messages to Other Systems UNIX Syslog Processes TelaConsole AS/400s Sending Messages to Web-Enabled Phones Sending Text Messages to Nextel Cellular Phones Sending One-Way Text Messages to GSM Cellular Telephones Sending Two-Way Text Messages to SMS Mobile Telephones Via a GSM Wireless Modem Set-Up During Installation New Technique in TelAlert Differences Between the Two Techniques Samples for Both Techniques Sending Messages to a DN400E Fax Modem Sending a File or a Line from stdin as a Message Sending a File as a Message Sending a Line from stdin as a Message SMPP SMPP Confirmed Delivery Option SMPP Sample Configuration WCTP Proxy Configuration. 150 Applying Filtering Techniques Overview Getting Started What is Filtering? Needed Information Other Considerations.. 153

9 10.3 A Simple Filter The Scenario Procedure Filtering Strategies Filtering and Default Logic RequiresFullMatch and Exclusive Value Combinations RequiresClientMatch The MatchKeyword Filtering and Groups Filtering and Schedules Filtering and Users Filtering by Message Priority Extended Example Default Logic Filtering Messages by IP Address Filtering out Duplicate and Transient Messages Filtering Out Duplicate Node Down Messages Suppressing Transient Messages Suppressing Unwanted Messages During Scheduled Downtime Suppressing Orphan Up Messages When a Device Does Not Come Back Online as Scheduled Filtering Messages by Source Pattern Matching Other Uses Pre-Defining Regular Expressions Setting Up and Applying Schedules Overview Getting Started What are Schedules? Needed Information Other Considerations A Simple Schedule The Scenario Procedure Scheduling Approaches Schedules and Default Logic Schedules and Groups Schedules and [Filter] Definitions Schedules and [User]Definitions Vacations and Holidays Adding Time to a Schedule: ExtraDuty Including Other Schedules in a Schedule Schedules and Message Priority Schedules Longer or Shorter than Seven Days.. 186

10 Changing a Rotation Schedule to Account for Unexpected Leave Reverse Schedules: Exclusive. 192 Representing Users Overview Getting Started What Are Users? What Are They For? Needed Information Other Considerations Creating a [User] definition: Essentials Values for Inheritance by Associated Destinations Direct Inheritance Minimum of the [User] Value and the [Destinations] Default Maximum of the [User] Value and the [Destinations] Default Maximum of the [User] Value, the [Destinations] Default, and the [Configurations] Value Values for Dial-in and Dial-out Access User-Based Administrative Techniques Viewing Messages: -show Getting Rid of Messages: -clear and -release Listing Users. 201 Enabling Responses Overview Getting Started What are Responses? Needed Information Other Considerations Taking Advantage of Pre-Defined Responses Responding Via the Command Line Creating Custom Responses Two-Way Pager Considerations Responses and the [Notifications] Feature Broadcasting to Groups and Creating Escalations Overview Getting Started What Are Groups? What Are They For? Needed Information Other Considerations Group Basics Building a Group from a List of Destinations Building a Group From a List of Other Groups Supported Group Attributes Broadcast Notification About Group IDs Use of -g and -l Compared. 215

11 Schedules and Broadcast Notifications Escalation A Simple Escalation Other Approaches to Strategy Escalations Involving Subgroups Balancing Workloads by Rotating the First Destination Schedules and Escalation Processing Events Overview Getting Started Needed Information Other Considerations Event Processing Defined What Is Event Processing? What Is an Event? Event Processing Overview About Notification and Related Keywords Triggering Actions Sending an SNMP Trap Writing to the System Log Issuing a Command Making One Event Trigger Multiple Actions Alert-Related and Miscellaneous Events: The [Notification] Section Event Keywords Supported in the [Notification] Section Event Substitution Parameters Supported in the [Notification] Section Process-Related Events: The [Heartbeat] Section Event Keywords Supported in the [Heartbeat] Section Event Substitution Parameters Supported in the [Heartbeat] Section Logging-Related Events: The [File] Section Handling Rollover of telaconfe.log and telainetde.log Handling telalert.sects and telalert.ini file Backups when TelAdmin is Used Miscellaneous [File] Functions Event Substitution Parameters Supported in the [File] Section Miscellaneous Administrative Tasks Overview Starting, Stopping, and Initializing TelAlert Configuring TelAlert to Run Automatically On Windows On UNIX Installing TelAlert Clients Configuring the Server To Accept Remote Clients Installing the TelAdmin Client 247

12 Installing Remote Command-Line Clients on Windows Installing Remote Command-Line Clients on UNIX Setting up the TelAlert Web Clients Installing the Web Clients Running Multiple Web Clients on the Same Machine Using the Web Clients with Web-Enabled Cell Phones Installing Online Help for the Web Clients Configuring telalerth with telalerth.ini Other Keywords Setting up Logging Default Log Files Setting Maximum Sizes WriteExecsToTrail Configuring Additional Logging Behavior Miscellaneous Administrative Tasks Specifying Maximum ID Assignments Viewing Listen Sockets 261 Security Features Overview TelAlert s Security-Conscious Architecture telalerte: The Central Hub of TelAlert The Media Controllers TelAlert Desktop Client Programs Password Encryption Scheduling of Client Connections Authentication for Admin and Client Connections Control Over Remote Connections Security Event Available in [Notifications] Control Over IVR Interactions Using SSL with Skytel Devices Obtain and Install Wrapper/Proxy Software Development Example 274 Integrating XML Output Overview Enabling XML Output Defining the Task A (Very) Brief Overview of XML The Parser Toolkit The Event Matrix The User Methods The Notification Objects Development Example Step 1: Create A New User Object 293

13

14

15 1 Introduction 1.1 Overview This chapter includes the following sections: A high-level look at TelAlert and related products. An overview of the TelAlert Administrator Guide and other TelAlert documentation. 1.2 TelAlert Overview TelAlert Mission-Critical Messaging Server is the core of MIR3 Application Mobilization Platform (AMP). The flexibility and reliability of TelAlert make it the Urgent Messaging System used by more than half of the Fortune 500. TelAlert Takes Messages from Any Source TelAlert works with virtually any kind of application, including network monitoring, enterprise management, help desk, and dispatch solutions anything capable of generating event-based messages and issuing user-defined Windows or UNIX commands. Applies Your Business Rules TelAlert lets you exert an unparalleled degree of control over how it processes messages. You can: Define groups for broadcast notifications or person-by-person escalations that ensure someone responds, even if the first addressee is unavailable. Set up rules governing how escalations proceed. Create schedules determining when each support technician is available to receive messages. Process messages based on priority. Create filters to weed out trivial messages and automatically direct important messages to the right people.

16 Sends Messages to the Right Destinations TelAlert can deliver text messages to a wide range of destinations, including: Cell phones equipped with text screens (WAP or SMS) Wireless PDAs (RIM, Palm, Visor) Pagers addresses Electronic Signboards And Accepts and Processes Responses TelAlert does much more than deliver messages. It also allows recipients to respond to messages a key factor in TelAlert's ability escalate an alert and ensure that someone takes control of the situation. Two-Way Pagers Recipients can choose from a customizable menu of reply options to accept or decline messages, update trouble tickets, ping a node, and more. More sophisticated functionality can be achieved through server-side scripting. WAP- and SMS-Enabled Cell Phones Recipients can wirelessly acknowledge and manage messages through the TelAlert Web Client. Applet-Based Remote Interactions TelAlert Messaging Services, Inc. Professional Services can develop custom applets for today's leading two-way wireless devices. Users benefit from familiar, graphical interfaces that provide powerful remote control over backoffice applications. 2 TelAlert Administrator Guide - Version 5.7

17 1.3 TelAlert Text to Speech (TTS) TelAlert Text to Speech (TTS) gives you all the capabilities of TelAlert, plus the license and hardware you need to deliver voice messages and let recipients interact with TelAlert and integrated applications via touch-tone telephone. See the TelAlert Voice and Hardware Guide for complete technical instructions relating to TelAlert TTS functionality Full Range of Voice Destinations TelAlert Voice can dial a telephone number, monitor call progress, validate the identity of the person who answers, and then speak its message. When appropriate, it will negotiate voic or answering machine systems and leave a recorded message Customizable Vocabulary in Four Languages The voice fonts TelAlert TSS are generated by AT&T s Natural Voices. These fonts are available in English, French, German, and Spanish. All languages are available in male and females voices. English is also available in American, UK and Indian Accent Interactive Voice Response (IVR) Users can enter keypad input to accept or decline messages when they are delivered by TelAlert over the telephone. Users can also dial in and interact with TelAlert and even the backoffice applications with which it is integrated via customizable IVR menus. This capability is delivered through a Dialogic telephony card. The TelAlert Voice Engine is no longer available Dialogic Telephony Card Windows users can choose to plugs a Dialogic telephony card into the machine on which TelAlert is installed or it can be configured on a remote Windows computer. Chapter 1: Introduction 3

18 1.4 TelAlert Integrations TelAlert is designed to work with other applications to take the messages they generate and, following your business rules, pass them to the right people, using the medium of your choice TelAlert Integrations Make it Easy It is easy to make TelAlert work with almost any application, whether it be a network monitoring, enterprise management, help desk, or dispatch solution. The following integrations have been developed and documented by TelAlert engineers. Many come with special scripts and other support files that help you get up and running as quickly as possible. Computer Associates TNG Advanced Help Desk Computer Associates Unicenter TNG HP Software Operations Manager (formerly HP OpenView IT/Operations ) HP Software Network Node Manager HP Software ServiceDesk HP Software ServiceCenter (formerly Peregrine) HP Software ServiceManager Remedy AR System Remedy Help Desk Tivoli Enterprise Console Tivoli NetView Do-it-Yourself Integrations for In-House Applications Even with applications for which no certified integration exists, integration with TelAlert is typically a simple matter, since most TelAlert integrations are carried out at the command line. For instance, perhaps your organization relies on an application it has developed in-house. If this application can be configured to issue UNIX or Windows commands in response to specified events, it can be integrated with TelAlert. If you choose to perform your own integration, you can also use the TelAlert API or Java class. 4 TelAlert Administrator Guide - Version 5.7

19 1.5 Supported Platforms The list below is current as of this writing. Please refer to the current TelAlert Release Notes for the most up to date platform support Server and Client Platforms HP-UX PA-RISC 1.1 (11.31 and higher) HP-UX PA-RISC 2.0 (11.31 and higher) HP-UX Itanium2 (11.31 and higher) Linux (glibc 2.5) (Intel x86 32bit) (Red Hat 5.4) Windows (32 bit Server) (2000) Windows (32 bit Server) (2003) Windows (32 bit Server) (2008) Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (SPARC 32/64 bit) Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (Intel X86 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (SPARC 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (Intel X86 32/64 bit) Client Platforms Client systems have 3 states, supported on the current version, supported with an older version and discontinued. All client versions are compatible with the 5.71 server software. Operating System Status AIX AIX Supported with TA 5.20 AIX (and higher) Supported with TA 5.20 AIX 5.2 (and higher) Supported with TA 5.60 Chapter 1: Introduction 5

20 HP-UX HP-UX PA-RISC 1.0 (9.04 and higher) Supported with TA 5.50 HP-UX PA-RISC 1.1 (9.04 and higher) Supported with TA 5.50 HP-UX PA-RISC 1.1 (10.20 and higher) Supported with TA 5.70 HP-UX PA-RISC 2.0 (10.20 and higher) Supported with TA 5.70 HP-UX PA-RISC 1.1 (11.31 and higher) HP-UX PA-RISC 2.0 (11.31 and higher) HP-UX Itanium2 (11.31 and higher) EXISTING EXISTING EXISTING Java Java 1.50 (TelAlert Admin "telalert") Java 1.50 (TelAlert EndUser "telalertc") Java 1.60 (TelAlert Admin "telalert") Java 1.60 (TelAlert EndUser "telalertc") EXISTING EXISTING EXISTING EXISTING Linux Linux (glibc 2.0) (Intel x86 32bit) Supported with TA 5.70 Linux (glibc 2.1) (Intel x86 32bit) Supported with TA 5.70 Linux (glibc 2.5) (Intel x86 32bit) (Red Hat 5.4) NEW Microsoft Windows (32 bit Server) (4.0/2000/XP Professional) Windows (32 bit Server) (2003) Windows (32 bit Server) (2008) EXISTING EXISTING NEW SGI SGI Irix Supported with TA 5.50 SGI MIPS ABI Supported with TA 5.50 SCO SCO Release 3 Supported with TA 5.50 SCO Release 5 Supported with TA TelAlert Administrator Guide - Version 5.7

21 Sun SunOS (SPARC 32bit) Supported with TA 5.50 Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit) Supported with TA 5.70 Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (Intel X86 32/64 bit) Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (SPARC 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (Intel X86 32/64 bit) Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (SPARC 32/64 bit) NEW NEW NEW NEW Other AT&T GIS (System 3000) Supported with TA 5.50 BSDI 4.1 Supported with TA 5.50 Digital Unix (Tru64 UNIX 5.1A BL4) Supported with TA 5.70 Tandem Guardian & Tandem OSS Supported with TA 4.03 IBM OS/2 Supported with TA 5.10 HP MPE/iX (WRQ format) Supported with TA Operating Systems Not Supported for Version 5.71 TelAlert no longer has access to the following platforms, so we cannot build 5.71 server or client software for them; nor can we provide bug fixes for prior versions. Customers with support contracts, who are running TelAlert version 5.1 or 5.2 on these platforms, can continue to receive technical support with configuration, operation, and other such issues that are not related to the operating system. We encourage migrating as soon as possible to a fully-supported platform. Server/Client platforms: HP-UX PA-RISC 1.1 (10.20 and higher) HP-UX PA-RISC 2.0 (10.20 and higher) AIX 5.2 (No AIX version is supported in this release) Linux (glibc 2.0) (Intel x86 32bit) Linux (glibc 2.1) (Intel x86 32bit) Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit) Digital Unix (Tru64 UNIX 5.1A BL4) Chapter 1: Introduction 7

22 1.6 Guide Introduction Thank you for using the MIR3 TelAlert Administrator Guide, your primary source for information about the use of recipient-related features in the TelAlert system. The purpose of this Guide is to provide detailed information on how to use these functions in the TelAlert system.. It assumes you have installed TelAlert and are ready to begin configuring and administering it Contents To help you learn how to use the TelAlert system effectively, the first page of each chapter includes a bulleted table of contents summarizing the information in the chapter. Each chapter also contains step-by-step instructions and procedures for using each function with the TelAlert system. The Guide provides recipient-directed information, including changing login IDs, passwords, and notification retrieval Audience The TelAlert Administrator Guide is designed for use by individuals who configure notifications using the TelAlert system Related Technical Documentation There are other sources of information available concerning deployment of the TelAlert system: TelAlert Voice and Hardware Guide - This guide contains complete instructions on sending Text to Speech (TTS) notifications using a TelAlert Dialogic telephony card. TelAlert Keyword and Command Reference - This guide contains information that was previously part of the Administrator Guide. It is a detailed reference to the keywords supported by the TelAlert configuration file, the commands and command line options supported by TelAlert, and the event and state messages issued by TelAlert. The TelAlert Desktop Guide - This guide contains details on using the TelAlert Desktop including TelAdmin, a GUI-based configuration tool that is included with TelAlert. TelAdmin allows you to configure TelAlert from within a graphical application rather than from a command line. 1.7 Product Support Contact Information Refer to Appendix: MIR3 Contact Information for MIR3 customer support. 1.8 TelAlert Solutions from MIR3 TelAlert is a trademark of MIR3, Inc., but is referred to without trademark symbols in the remainder of this document. 8 TelAlert Administrator Guide - Version 5.7

23 1.9 Guide Conventions This guide is written in Microsoft Word format and converted to PDF format to preserve the formatting. The following information provides you with the key to help you identify information as you navigate through this Guide: Example Purpose Use of Monospaced Fonts telalertc -i DestinationName -m "Message" Italicized text within a command line example represents a variable. In the above example, DestinationName is the invocation of an item in TelAlert s configuration file; message represents the message text to be sent by TelAlert. 2001/03/16 11:50:11>Event [21]Alert Completed (23), Status: [81]Message sent, TelamonTestPage Command line text Text representing information entered by the user at the command line or presented by TelAlert as output is shown in a monospaced font. Click OK. Within procedural (how-to) text, boldface words are characters you type or elements you can click. Within overview or conceptual text, bolded words may simply represent concepts that have been highlighted to emphasize their relative importance. 1. Go to the Add User page. Within procedural text, numbered steps denote actions that should be followed in sequence. Message Formatting In this guide, message text passed on the command line is enclosed in quotation marks. This is not required in all cases, but putting your message text in quotation marks is an excellent habit, as it ensures that neither TelAlert nor any shell you might be using will read the message as anything other than a string of text to be delivered. Chapter 1: Introduction 9

24 Example "Open telalert.ini and search for " " gives the file a.bak extension and then " {LauraTextPager} Configuration=SkyTelNationalTe xtpager PIN= Purpose File names and extensions The same monospaced font is used to represent file names and extensions. telalert.iniexamples Entries drawn from the TelAlert configuration file are also represented in a monospaced font. The ellipses () indicate information that may be present in the actual telalert.ini entry but which is omitted in the example because it is not relevant here. Click OK. Within procedural (how-to) text, boldface words are characters you type or elements you can click. Within overview or conceptual text, bolded words may simply represent concepts that have been highlighted to emphasize their relative importance. 2. Go to the Add User page. Within procedural text, numbered steps denote actions that should be followed in sequence. Click Save to save your work. Click Cancel to exit without saving. Within procedural text, bulleted text denotes available options. Within overview or conceptual text, bulleted text also denotes supporting information that is subordinate to the major topic being discussed in the Guide. The light bulb icon denotes a helpful tip. The information icon denotes reference material. The note icon indicates definitions or considerations that help you understand the related task. 10 TelAlert Administrator Guide - Version 5.7

25 Broken Lines in telalert.ini In telalert.ini excerpts presented here, some lines are too long to be presented as single lines. In such cases, the line is broken and continued below. The continuation is indented. It is assumed that, in the telalert.ini entry itself, the line will not actually be broken. Note that telalert(c) does not support breaking command lines. If you want to break a line in telalert.ini so that it continues on the next, you must place an ampersand (&) immediately preceding the line break. Otherwise, TelAlert will treat the continuation as a new line. Note too that if a broken line is to be commented out (using the # character) the continuation lines need to be commented out as well Screen Captures Due to the flexibility of permissions in the TelAlert system, some of the functionality represented in the screen captures for this Guide is not always visible to, or functional for, all users. The User Interface screen captures are intended for instructional use. The system administrator determines access to specific functions using the Enterprise Access Control (EAC) role-based access functions available in the TelAlert system File Locations By default, TelAlert is installed in /usr/telalert on UNIX systems. Note that some files, (including log files) are placed in /tmp. On Windows files are placed in c:\programfiles\telalert. Other TelAlert files are placed in directories relative to this location. You are not required to accept these defaults during installation, but all references to file locations in TelAlert documentation assume (for simplicity of representation) that these default settings have been used. Chapter 1: Introduction 11

26

27 2 Technical Overview 2.1 Overview A high-level look at TelAlert from a technical perspective: How it works The programs and processes comprising it Key TelAlert files The concepts underlying TelAlert configuration Some frequently asked questions and their answers 2.2 How TelAlert Works TelAlert follows instructions issued by applications and human users. These instructions fall into three main categories: Notification instructions include a message that TelAlert is to send to some recipient. Administrative instructions relate to starting and stopping TelAlert, modifying the way it works, and checking the status of the work it does. Responsive instructions come from message recipients and acknowledge receipt of the message, update the status of a problem, ask for more information, and so on. TelAlert can accept instructions via two command line interfaces, telalert and telalertc. In addition, specially integrated applications can call TelAlert API functions or Java methods to interact with TelAlert. The command line interfaces are the most common means of interaction, and so instructions typically take the form of commands. Telalert and telalertc parse command line parameters and pass formatted instructions to the main server process, telalerte. Telalerte validates these instructions against TelAlert configuration information and queues tasks to be performed by other server processes, which in turn are responsible for interactions with specific devices or connections: modem, Dialogic telephony card, electronic signboard, and sockets-based Internet connection.

28 2.2.1 A Typical Alert A typical scenario has TelAlert running on the same server machine as a network management application (referred to here as the controlling application ). This application has been configured to respond to certain network events by passing an appropriate command to TelAlert using telalertc. Thus, when the controlling application detects a node failure, for example, it issues a command to TelAlert, along with the message to be delivered. The following diagram shows how a network monitoring application, on detecting that a server is down, could use TelAlert to send a message to a single text pager: Figure 1. A Typical TelAlert Send First, the controlling application issues the following command: telalertc -i BobTextPager -m "node 2745 down" This command invokes telalertc(the command-line client), which passes the command to telalerte (the primary TelAlert server process). telalerte then looks in telalert.sects, the compiled version of the telalert.ini configuration file, to find the definition for the recipient, the configuration information for the modem to be used, etc. Next telalerte tells telalertm (TelAlert s modem daemon, the process that actually controls the modem) precisely what to do, providing it with instructions for dialing the specified service provider, the PIN for this particular recipient, and finally the message itself. All the while, telalerte records each step in the process in a file called telalert.trail. It also records this alert as active in the telalert.alert file. 14 TelAlert Administrator Guide - Version 5.7

29 2.3 TelAlert Programs and Processes TelAlert is comprised primarily of two command line programs and six daemon processes, some of which have been mentioned already in this chapter. Each is described in greater detail below. telaconf telaconf is the database management system that controls and stores information on changes you make to your configuration using TelAdmin, a component of the TelAlert Desktop, the graphical configuration environment for TelAlert. On Windows, telaconf runs as a service; use Control Panel/ Administrative Tools/Services on Windows to make sure the Startup parameter is set to Automatic. However, you should not use the Start button in the Services applet to actually start telaconf; instead, give the telaconf -start command from a command line. On UNIX, telaconf runs as a daemon. To have it start automatically when UNIX boots, look at telaconf.init.d file, which contains comments about how to customize it and copy it to the startup directory. It can also be manually started with the command telaconf -start. If an error message such as Error*Can t connect to host appears in either a popup box inside TelAdmin, or on the command line, there s a good chance that telaconf has not been started. telalertc telalertc is a command line program used to issue notification and response instructions to telalerte. It can be run on the same machine as the TelAlert server. It can also be installed on another machine and used to interact with telalerte remotely. telalertc is a client program designed for end users. It lacks certain administrative commands that control the way TelAlert works. telalert telalert is a command line program used to issue administrative instructions to telalerte. It can also be used to issue the same notification and response instructions as those supported by telalertc. Most administrative commands can be issued on any machine on which telalert is installed, regardless of whether it is the same machine on which telalerte is running. Certain key administrative commands including -start, -stop, -compile, and -init must originate on the telalerte machine; they cannot be given remotely. Chapter 2: Technical Overview 15

30 telalert vs. telalertc It is recommended that you use telalertc to issue all TelAlert commands other than the administrative commands unique to telalert even when issuing the command from the machine running the TelAlert server, where telalert is also available. The reason is simple: when you use telalertc, there is never a danger of accidentally stopping, re-starting, or re-initializing TelAlert. telalert is the sole means of issuing still other commands (including -clearall, -releaseall, -ackall, and -nakall) that you would not want to give accidentally. telalerth telalerth is a CGI application that allows a Web server to communicate with telalerte. For instance, if you set up a Web form for users to acknowledge or send alerts, telalerth takes the information sent via this form to the Web server and passes it to telalerte in a form telalerte can understand. telalerte telalerte is the TelAlert server, the central nervous system of TelAlert. A continually running daemon process, telalerte takes commands and messages received by telalert and renders them complete, incorporating information referred to in the TelAlert configuration file. It then passes complete instructions to the daemon responsible for carrying out the responsibility at hand. Telalerte tracks all TelAlert activity, recording it in a comprehensive events file called telalert.trail. It maintains a record of all active alerts in telalert.alert. telalerte is also the part of TelAlert that processes responses and requests. If a message recipient dials in and acknowledges receipt of a message using TelAlert s voice menus, this response is passed by telalertd (the daemon handling interactions with the TelAlert Dialogic telephony card) to telalerte, which updates the status of the alert (internally and, where applicable, with the monitoring application that originally issued the command) to reflect the acknowledgment. Similarly, if someone uses telalert to request a list of all active alerts, it is telalerte that retrieves this information and passes it to telalert for display. telalertm telalertm is the process responsible for dialing the modem of the server machine on which TelAlert is installed and, following instructions passed to it by telalerte, sending and receiving information over this connection. Telalertm handles only numeric and text paging and polling. 16 TelAlert Administrator Guide - Version 5.7

31 telalertr telalertr is the process responsible for controlling electronic signboards and other RS232 devices (excluding modems). telalerts telalerts is the process responsible for all sockets-based TelAlert interactions. It communicates with SMTP and SNPP servers to send and online pages, respectively. readmail TelAlert comes with an -reading program (readmail, or readmail.exe for Windows) that allows TelAlert to accept and process replies using . This includes replies to messages sent straightforwardly as s and replies to certain two-way pager notifications (PageNet and WebLink Wireless) that take the form of s. See the section Handling Responses to With Readmail in Chapter 9 of this manual for more information. 2.4 Key TelAlert Files Below is a description of some of the key files comprising a TelAlert installation. telalert.trail telalerte records all TelAlert activity in this file. When it reaches a specified size (100 K is the default), the file name is changed to telalert.trbak and telalerte begins a new trail file. This backup file will be overwritten each time the current trail file reaches 100 K. (The TrailSwitchCmd= line in the [Files] section lets you define an external process for archiving the data in these backup.trail files.) telalert.alert Maintained by telalerte, telalert.alert is a continuously updated file containing all the information TelAlert needs to process all active alerts. telalert[e/f/r/s/d/m/h/v].log By default, TelAlert maintains a separate log file for each of the daemon processes. telalerte.log is unnumbered, but each of the others (telalertd2.log, for instance) is marked with a number indicating the place (sequentially) of the definition under [Port] with which it is associated. The numbering is necessary because a TelAlert installation may feature more than one instance of the d, s, h, r, and m processes. Chapter 2: Technical Overview 17

32 telalert.ini This is TelAlert s configuration file. It contains a variety of information that TelAlert uses to carry out commands. This includes licensing details; information about ports, devices, groups, schedules, and users; and instructions about sending messages to specific destinations and general destination types. telalert.ini is divided into sections headed by words enclosed in straight [brackets]. Many of these sections are further subdivided into definitions headed by words enclosed in curly {braces}. Lines in the telalert.ini file that are neither section nor definition headings take the form keyword=value, where keyword is any of the many words TelAlert is programmed to recognize (including but not limited to section names), and value is the value you assign (including but not limited to definition names). The telalert.ini file can be configured directly, using a text editor. The other configuration/administration option is to use TelAdmin, a Windows application, to modify the telalert.sects file (the compiled version of the telalert.ini file; see below). For a more in-depth discussion of these two options, refer to the TelAlert Desktop Guide. telalert.sects This is the compiled version of the telalert.ini file. Strictly speaking, telalerte reads this file, not telalert.ini, in order to process commands. You can control the way TelAlert works by using TelAdmin to modify this file as opposed to editing the telalert.ini file directly. For more information on the two configuration options, refer to the TelAlert Desktop Guide. Figure 2. TelAlert Files, Processes, and Destinations 18 TelAlert Administrator Guide - Version 5.7

33 2.5 Key Configuration Concepts In order to understand your notification and response objectives, TelAlert relies on two sources of information. The first is the command interface (be it command line, API functions, or Java methods), which may be used by another program or a human user. The second is the TelAlert configuration file telalert.ini or, more directly, its compiled version, telalert.sects. These two sources are heavily dependent on one another. While it is possible to pass varying amounts of information directly on the command line, virtually all commands use configuration keywords to make explicit reference to information stored in the configuration file. For example, to send a message to Bob s text pager, you might use the following command: telalertc -c SkyTelNationalTextPager -pin m "node 2745 down" Here, -c tells TelAlert to understand SkyTelNationalTextPager as a reference to the [Configurations] definition of the same name. This definition contains information on how to use the SkyTel service, but the PIN for the intended individual recipient is passed here on the command line, as is the message itself (the text following -m, which is best enclosed in quotation marks). Alternatively, you could issue a command referring to a specific destination (see below) defined in the configuration file. For instance: telalertc -i BobTextPager -m "node 2745 down" Here, -i tells TelAlert to understand BobTextPager as referring to an individual [Destinations] definition (as opposed to a [Configurations] or [Group] definition, signaled by c and -g, respectively). Typically, {BobTextPager} would include the PIN and, by means of a keyword reference, needed configuration information (that stored in the definition of, for instance, {SkyTelNationalTextPager}). Command-line invocation of configuration data is key to much of TelAlert s flexibility and power most notably, its scheduling, group-send, escalation, and response functionality. The following discussions are intended to acquaint you with the concepts you need to understand to configure TelAlert. Each discussion focuses on the concept at hand but introduces related concepts where necessary to help you develop a sense of the big picture how the various pieces of configuration data combine to deliver some of TelAlert s most valuable benefits. Chapter 2: Technical Overview 19

34 2.5.1 Sections, Definitions, Keywords, and Cross-Referencing telalert.ini is divided into sections headed by words enclosed in straight [brackets]. Many (but not all) of these sections are further subdivided into definitions headed by words enclosed in curly {braces}. Lines in the telalert.ini file that are neither section nor definition headings take the form keyword=value, where keyword is one of the many words TelAlert is programmed to recognize (including but not limited to section names), and value is the value you assign (in some cases an integer; in others, True/ False or a definition name). Generally, a definition represents a specific instance of the concept underlying that section. For instance, an entry under [Configurations] contains configuration information for a specific instance of a general medium type such as a pager type, an gateway, or an electronic signboard. An entry under [Destinations] contains the information specific to a given destination (e.g., an individual s pager), as well as a keyword-based reference to the general configuration information for that type of pager. A [Destinations] definition might look something like this: {LauraTextPager} Configuration=SkyTelNationalTextPager PIN= The second line of this definition refers to the entry in the [Configurations] section called {SkyTelNationalTextPager}, which might look something like this: {SkyTelNationalTextPager} Type=TextPager AreaCode=800 Number= Speed=19200 Cross-references within the telalert.ini file flow from more specific to more general. That is, a very specific entry such as a [Destinations] definition usually contains one or more keyword references to more general entries: a [Configurations] definition, or a user or schedule, for example. This is not the same kind of inheritance at work in object-oriented programming (since a [Destinations] definition inherits only a small, explicitly invoked portion of the information stored under [Configurations]), but the effect and benefits are very similar: telalert.ini cross-referencing permits certain broadly applicable pieces of information to be written once, stored centrally, used in many different contexts, and altered throughout in one simple step. telalert.ini can also contain references to outside resources, including scripts and text files storing additional definitions. 20 TelAlert Administrator Guide - Version 5.7

35 Sectional Default Values Not all lines in every section belong to a definition. Lines appearing between the section name and the first definition name present default values that are valid for every definition. However, if a given definition contains the same keyword and another value, telalerte overrides the default entry and reads the definition-specific line Configuration The [Configurations] section contains entries defining basic configuration information for different media types (e.g., , a specific kind of pager, or an electronic signboard model). These definitions can be drawn from external files using $include relativepath/filename. TelAlert ships with a telalert.ini file filled with commented-out $includefile references and a set of files containing [Configurations] definitions for a wide range of paging service providers Destination The [Destinations] section contains entries defining specific destinations such as a text pager belonging to David, his home telephone number, the address of Joan, or a specific instance of a certain type of electronic signboard. Typically, some of the information for a [Destinations] definition is drawn from a [Configurations]entry. For instance, {DavidPager} might include a Configuration=TextPager line, where TextPager points to the [Configurations] definition of the same name, which may be shared by many destinations. Some destinations (a signboard, for instance) have nothing to do with any person. Others may make reference to a person by means of a User= line. Since it may be possible for TelAlert to contact a person via several different destinations, this optional line allows TelAlert to recognize destinations in terms of the person they have in common. Such an association may be useful if you want to analyze sent messages in terms of the people to whom (rather than destinations to which) they were sent. Chapter 2: Technical Overview 21

36 2.5.4 User Users, defined individually in the [User]section and referred to elsewhere in telalert.ini by User= lines, represent the people associated with destinations (some other parts of the telalert.ini file permit association with a user, as well). Generally speaking, this is an optional aspect of TelAlert configuration: most [Destinations] definitions do not have to be associated with a user. Creating such associations, however, is the key to several important techniques: By including a User= line in a [Destinations]definition, you cause it to inherit values contained in the invoked [User] definition: Schedule, Password, etc. This tells TelAlert how to assess the destination s validity (i.e., by referring to the schedule), or how to determine the identity of someone with whom it is interacting (i.e., by asking for a password when the person attempts to respond to a notification). Moreover, whenever [Destinations] definitions are associated with users, it is possible to track messages in terms of the people to whom they were sent. This is helpful because it may be possible to notify a single person via a number of different destinations. While the user concept can be very helpful, not all organizations use it when implementing TelAlert. Some simply create a general user {Operator} and invoke this user by keyword (User=Operator) wherever necessary. Others may have no need to use this keyword at all Group A group is a collection of destinations. Under the [Group] section of telalert.ini, each entry is identified by a name in {braces}, and all of the destinations in that group are invoked by means of a single keyword line. For instance: Destinations=BobHomePhone,LauraTextPager,John Sending a message to a group means sending it to all of the destinations comprising that group, either all at once or one at a time, according to specified rules. For instance, if a [Destinations]definition invokes a [Schedule] entry, TelAlert has to evaluate the schedule to see if the destination is valid at that time. The priority of the message may override the schedule for the destination, in which case TelAlert will send to it anyway; otherwise, it may move on to the second destination. Similarly, when TelAlert is instructed to send to one destination and wait for a positive acknowledgment before sending to another, it begins by looking through the list for the first [Destinations] definition that it can use, based on the rules that have been set up. When it succeeds in sending the message, it waits for acknowledgment for a specified time before locating the next valid entry and sending the message to this destination. [Group] definitions are critical to TelAlert s escalation capability (as is the concept of strategy; refer to the Strategy section, below). Only by setting up a [Group] definition and invoking it in a command can you ensure that a message reaches someone who can handle the problem, even if the initial send fails or goes unacknowledged. Alternatively, creating a group comprised of all the destinations associated with one person allows you to send a message to that person without specifying a particular destination. As long as each of these destinations is associated with a schedule, TelAlert will examine them one by one until it finds the right one to use, based upon its schedule. You can refer to one [Group] definition within another simply by listing its name as one of the values in the Destination= line. For this reason, a group should never be given the same name as a destination. 22 TelAlert Administrator Guide - Version 5.7

37 2.5.6 Schedule A schedule is a list of times during which a destination is considered available, or on duty. A [Destinations] definition can invoke a schedule by means of a keyword referring to an entry in the [Schedule] section. If a destination is linked with a [User] definition, however, this definition may invoke the schedule instead so that the destination refers to a user, which in turn refers to an entry under [Schedule]. Having one [Schedule] definition associated with a [Destinations] definition means that TelAlert will use that schedule to assess that destination and then either send the notification to it or not. But you can include more then one schedule reference in a [Destinations] definition, which allows TelAlert to decide what to do based on the message s priority. For example: {JohnPager} User=John Schedule=RegularSchedule AlternateSchedule=LateShift {RegularSchedule} and {LateShift} appear under [Schedule], with {LateShift} defined so that it includes the hours comprising {RegularSchedule} and additional hours as well. Then you might include the following line as part of the [User] definition representing John: AlternateSchedulePriority=80 Thus, when TelAlert processes a message of priority 80 or higher, it finds it is permitted to send it to {JohnPager}, even if it comes at a time outside of his normal schedule (assuming it falls within the hours of his alternate schedule) Strategy Entries under [Strategy] are relevant for a message sent to a group and are referred to in [Group] definitions. They determine two things: (1) how TelAlert recognizes an alert as complete and (2) under what conditions it escalates the alert by sending to a subsequent destination. The first is accomplished through a Complete= line. For instance, Complete=acked>0 tells TelAlert to consider the alert complete when it receives positive acknowledgment from any recipient. An Escalate= line tells TelAlert under what conditions to escalate the alert. For example, Escalate=Incomplete=0 tells TelAlert to escalate the alert to the next sub-group when the number of sends in an incomplete state (i.e., those marked Active, Pending, or AckWait) equals zero. Together, these two lines form a commonly used [Strategy] definition called {FirstAcknowledge}. Under the terms of {FirstAcknowledge}, the alert will be escalated until it has been acknowledged once (and thus has been completed); assuming no acknowledgment, it will be escalated until there are no more destinations to which it can be escalated. Chapter 2: Technical Overview 23

38 If the requirements for completion (set in the Complete= line) are met, TelAlert always ceases escalation, even if the conditions for escalation (set in the Escalate= line) remain unmet. TelAlert allows you to set a higher standard for completion in case you want to keep an alert active (for tracking purposes, say) even after escalation has ceased. A default strategy may be invoked under [Group] using a Strategy= line placed before the first definition. A group may also invoke its own strategy using a Strategy=line; these group-specific strategies override the default. In the absence of a reference to a [Strategy] definition, no escalation occurs; TelAlert sends to all destinations at once. Note that when you send a message to a group that includes one or more other groups, TelAlert uses the strategy defined in the group to which the message is addressed, and ignores any Strategy= lines in the subsidiary groups Other Configuration File Sections There are a number of other sections comprising the telalert.ini file. Some of these, like the ones described above, provide a means of controlling the way TelAlert interacts with users. Others pertain to TelAlert s internal functioning or its interaction with various optional components. Each of these is described briefly below. All the behavior governed by these other sections can be modified using TelAdmin, as well. For more information on these two configuration options, refer to the TelAlert Desktop Guide. [Access] Configures the prompts issued by TelAlert in both dial-in and dial-out calls. [Analog] Used to configure certain environmental monitors which connect via the Sensor Interface Unit. (Obsolete - TelAlert Classic Engine only.) [Battery] Specifies the battery charge level range to monitor and the means of notification when this range is exceeded. (Obsolete - TelAlert Classic Engine only.) [CallProgress] Contains values associated with the ability of the Dialogic telephony card to listen for and recognize various telephone rings and voice interaction cues. [Files] Allows you to configure TelAlert s standard logging activity. [Filter] In conjunction with a tags parameter, allows you to have TelAlert send to a select subset of a group of destinations based upon the nature of the message it is to deliver. 24 TelAlert Administrator Guide - Version 5.7

39 [Heartbeat] Contains values relating to TelAlert s ability to notify other applications or scripts regarding changes in the status of TelAlert. [License] Contains settings related to your TelAlert software license that allow TelAlert to function according to its terms. [Limits] Establishes values for miscellaneous parameters internal to the TelAlert software. [Menu] Specifies how the Dialogic telephony card prompts and receives input from users. [Message] Defines rules for modifying a message so it can be sent to a group of destinations with varying display capabilities. [Modem] Configures numerous modem parameters. [Notifications] Specifies when and how TelAlert should deliver information to the trouble ticketing or other application with which it is integrated. [Patterns] Specifies patterns that can be used to view, manage, and modify alerts in progress. [PhonePrefixes] Specifies the phone prefix information associated with the telephone lines used by TelAlert. [Port] Defines the connections TelAlert uses to send notifications. [Power] Specifies the power level range to be monitored and the means of notification when this range is exceeded. (Obsolete - TelAlert Classic Engine only.) Chapter 2: Technical Overview 25

40 [Process] Allows you to configure TelAlert s control over helper applications such as Readmail. [Relay] Allows you to configure TelAlert s control over devices connected to the TelAlert Relay Interface Unit. (Obsolete - TelAlert Relay Interface Unit only.) [Response] Defines any responses that recipients may be able to make after receiving a message. [Sensor] Allows you to configure certain environmental monitors, which connect to the TelAlert Sensor Interface Unit. (Obsolete - TelAlert Sensor Interface Unit only.) 26 TelAlert Administrator Guide - Version 5.7

41 3 Implementation Planning 3.1 Overview An introduction to the work of setting up TelAlert to meet your organization s unique notification needs. 3.2 Your Accomplishments So Far Chapter 1: Introduction and Chapter 2: Technical Overview provide a conceptual understanding of TelAlert, from both a product and a technical perspective. This chapter is designed to acquaint you with the major issues you will face as you prepare to implement TelAlert in ways that make sense for your company. It also explains how the organization of the Administrator Guide is connected to the work you have ahead of you. Here it is assumed that you have read the previous chapters and are familiar with basic TelAlert terminology. Further, by now you should have installed the product following instructions in the Chapter 16: Miscellaneous Administrative Tasks and checked your installation by sending a test page. Also, you should have read the integration guide pertaining to any third-party product(s) with which you plan to integrate TelAlert. As you will see, integration accompanies rather than follows general implementation, and, as you move ahead, it will be helpful to understand what kind of integration you need to perform. Integration Assumptions TelAlert is designed to work with a controlling application. Many such applications control TelAlert via the command line either directly, issuing a TelAlert command just as a human user might, or indirectly, invoking a script that builds and issues a TelAlert command. (Some others call TelAlert APIs or Java classes to communicate directly with TelAlert.) Because the command itself is the key to achieving the desired TelAlert behavior, the rest of the Administrator Guide focuses on these commands and associated parameters, ignoring the different ways they might be produced in different integrations. Integrations differ also in that some store a portion of the contact information required for sending notifications in the controlling application s database, while others store all such information in the TelAlert configuration file. In order to give you the most complete picture of TelAlert implementation capabilities, the Administrator Guide assumes the latter scenario.

42 3.3 Structure of the Administrator Guide The following is a brief outline of the structure of the Administrator Guide, which should help you identify the parts that will be relevant for you as you go about the work of configuring TelAlert Chapter 1: Introduction This chapter presents a general overview of TelAlert from a product perspective Chapter 2: Technical Overview This chapter presents a general overview of TelAlert from a technical perspective Chapter 3: Implementation Planning The present chapter focuses on familiarizing you with the work you must do to configure TelAlert to meet your organization s specific needs Chapter 4: Configuration Basics Beginning with version 5.0, TelAlert can be configured using either a text editor or a graphical interface provided by MIR3. This chapter discusses the differences between the two approaches, helping you choose the one that is right for your organization Chapter 5: The Role of Ports in TelAlert [Port] definitions are key to all notifications. This chapter explains their standard role and the settings you need to understand in order to take advantage of special port-related functionality, including port backup and notification via remote ports. The things you will learn in this chapter will be relevant to a great deal of the other work you will do while setting up TelAlert Chapter 6: Dialing the Telephone Many of TelAlert s paging and voice notification capabilities rely on dialing the telephone. This chapter explains all of the configuration settings that control how TelAlert dials the telephone, teaching you to handle a wide variety of special dialing scenarios, from overlapping area codes to special billing codes to inside and outside lines. The things you will learn in this chapter will be relevant to a great deal of the other work you will do while setting up TelAlert Chapter 7: Configuring for Paging Notification Paging is the most commonly used notification medium supported by TelAlert. Setting up paging involves setting up [Configurations] definitions for all the paging services and pager types your organization uses and then creating a [Destinations] definition corresponding to each of the pagers to which you want notifications to be sent. This chapter walks you through the procedures required to set up a number of different types of paging: numeric and alphanumeric (i.e., text), and two-way. It also covers the differences between sending pages using a standard modem connected to the machine on which TelAlert is running and Internet-based access to paging services. 28 TelAlert Administrator Guide - Version 5.7

43 3.3.8 Chapter 8: Configuring for Text to Speech (TTS) Notification Information on Configuring for TTS Notification is now in the TelAlert Voice and Hardware Guide Since TelAlert TTS functionality requires a TelAlert Dialogic telephony card, the information on software and hardware configuration for voice functionality now resides in the TelAlert Voice and Hardware Guide. Text to Speech (TTS) is the second most commonly used notification medium supported by TelAlert. If you plan to use TelAlert s voice capability, you should have purchased a TelAlert Dialogic telephony card and installed and tested it following the directions in the TelAlert Voice and Hardware Guide. Once TTS is in place, most of your work will consist of setting up specific [Configurations] and [Destinations] definitions appropriate for voice notifications. One important aspect of this process is determining how TelAlert should behave when a number it calls is answered for instance, whether it should expect to reach a voice mail system or a human user whom it must ask for identification before reading its message. All the information regarding the TelAlert Dialogic telephony card and software configuration for voice functionality is now covered in chapters 2 through 4 of the TelAlert Voice and Hardware Guide Chapter 9: Configuring for Other Notification Media Because paging and voice are the notification methods most often used by TelAlert users, the Administrator Guide deals with them in separate chapters. In this chapter, you will find coverage of the setup required for sending notifications via other supported media, including , command line destinations, electronic signboards, SpectraLink campus phone systems, other computer systems (UNIX syslog processes, AS/400s, and TelaConsole installations), and Webenabled and text-screen-equipped cellular phones Chapter 10: Applying Filtering Techniques Once you understand the basics of sending messages (covered in the chapters on paging, voice, and other notification media), you can use a variety of techniques to have TelAlert restrict the messages it sends, based on specified conditions. You can have TelAlert delay sending a message for a certain amount of time, send the message only after it has been asked to send one or more duplicates, send the message immediately and then suppress all duplicates, or send the message immediately and then send only a subset of duplicates. You can also use [Filter] definitions and -tags values to invoke additional rules for deciding which destinations in a group to choose when sending a message. This chapter covers these and other filtering techniques. Chapter 3: Implementation Planning 29

44 Chapter 11: Setting Up and Applying Schedules [Schedule] definitions can be invoked in [Destinations] or [User] definitions. At whatever level you invoke a schedule, TelAlert uses this information to evaluate affected destinations and determine which are valid at the time TelAlert sends a notification. Schedules can play a role in notifications sent to a single destination, but primarily they serve to determine which of a group of destinations are valid at any given time. They are an important part of implementing TelAlert s escalation capabilities, but, even when used solely in conjunction with simple group sends, they allow you to differentiate between on-duty and off-duty destinations so that the right people are notified every time. TelAlert s scheduling feature allows you to do more than simply indicate when a user or destination is to be considered on duty. As explained in this chapter, you can also set an AlternateSchedule and OverrideSchedule value for each, making it possible to extend the hours during which a destination is valid, depending on message priority Chapter 12: Representing Users [User] definitions are a means of representing people in your TelAlert configuration. This allows you to store certain user-specific information conveniently and apply it where necessary (in a [Destinations] definition, for instance) simply by referring to the appropriate [User] definition. This offers advantages for both sending messages and administering the sending of messages. Also, [User] definitions are required for certain types of notifications. This chapter explains all you need to know about defining users in the TelAlert configuration file Chapter 13: Enabling Responses Recipients of TelAlert messages can respond remotely using two-way pagers or touch-tone telephones; they can also issue a command line response on a machine on which telalertc is installed. The most basic aspects of TelAlert s support for responses require no setup; this chapter covers these but focuses on techniques for creating customized [Response] definitions. These can play a role in escalations; they can also be used in conjunction with [Notifications] definitions to initiate additional actions Chapter 14: Broadcasting to Groups and Creating Escalations Groups are collections of destinations. Setting up [Group] definitions is very simple; the principal challenge is looking at your organization and its notification needs and deciding what groups to create. The best way to approach this issue is to consider what groups already exist within your organization implicitly or explicitly among the pool of potential message recipients. You might form groups on the basis of a wide range of traits: e.g., functional area, physical location, shift, or level of responsibility/authority. You can use [Group] definitions to send messages to a number of destinations at once (broadcasting). You use a combination of [Group] and [Strategy] definitions to perform an escalation sending the message either to a series of individual destinations, one at a time, or to all the destinations comprising one subgroup, then to all the destinations comprising the next subgroup, and so on. This chapter covers all the details of creating [Group] and [Strategy] definitions and using them for broadcast notifications and escalations. 30 TelAlert Administrator Guide - Version 5.7

45 Chapter 15: Processing Events TelAlert is able to recognize a wide range of internal events some relating to notifications, some relating to input from environmental monitors, some relating to logging, and some relating to the state of TelAlert s constituent processes. This chapter explains the procedures for having TelAlert pay attention to designated events and process them according to rules you specify Chapter 16: Miscellaneous Administrative Tasks This chapter covers a variety of administrative tasks, including running TelAlert as a service on Windows, setting up the TelAlert Web client, installing clients, and starting, stopping, and initializing TelAlert Chapter 17: Security Features This chapter shows how security enhancements have been woven into the architecture of TelAlert, along with some practical examples of new security features Chapter 18: Integrating XML Output This chapter shows how TelAlert s XML output can be integrated with various third-party applications. 3.4 The Alert Timeline As you begin considering your own implementation, it may be helpful for you to think of TelAlert and its capabilities in terms of a timeline along which the events in the life of an alert can be plotted Send and Release Fundamentally, TelAlert is a means of taking a message from an external source (a controlling application or utility) and passing it to an external target (the message recipient). Once you have set up a [Destinations] definition and a [Configurations] definition for it to refer to, the controlling application can issue a command to TelAlert telling it to send a message to this destination. For example: telalertc -i JohnTextPager -m "node 2745 down" Assuming no special settings or command line options are used, this alert is completed as soon as the message is delivered: Figure 3. Simple Alert Timeline Chapter 3: Implementation Planning 31

46 This continues to be true as you add other [Configurations] and [Destinations] definitions to the mix, thus making other notification media available, and even as you begin sending messages to more than one destination and filtering these destinations according to the ones considered on-duty. Whether you are sending a message to one or many destinations, TelAlert s basic procedure is the same: it sends the message to the specified destination or destinations and then lets go of the alert. Note that TelAlert knows nothing about nodes, node numbers, or downtime. It simply takes the text of the message received from the controlling application, and sends it to the destination indicated by the command Send, Wait, and Release This basic procedure changes only when you introduce the element of a response. When a message recipient is expected to respond to a message, TelAlert has to keep the alert and message alive even after sending the message to all specified destinations; otherwise, it would not be able to receive a response. This extension of the timeline relies on the -ackwait command line option or the value assigned to AcknowledgeWait (which can be set in a [Configurations], [Destinations], or [Group] definition). Consider the following command: telalertc -i JohnTextPager -m "node 2745 down" -ackwait 10m As before, the message is going to be sent to a single destination. The addition of -ackwait 10m tells TelAlert to hang on to the message for ten minutes after it has been delivered, awaiting a response from the recipient. If, within the ten-minute window, TelAlert receives positive acknowledgment, it considers the alert complete and lets it go. Likewise, if the ten minutes elapses without any response, TelAlert lets go of the alert. Figure 4. Extended Alert Timeline: -ackwait What does this extension of the timeline accomplish? Since the message is being sent to a single destination, there is no question of any TelAlert-directed escalation taking place as the result of a response or non-response. But, for as long as the message and (as a consequence) the alert remain alive after message delivery (here, ten minutes), TelAlert can accept a response and pass it to a controlling application. Thus, your help desk application (for instance) will know whether the problem is being handled something it could not learn unless the alert were held after the point of delivery. 32 TelAlert Administrator Guide - Version 5.7

47 3.4.3 Send, Wait, Hold, and Release The timeline may be extended somewhat further in cases where the recipient can acknowledge and hold the message. Imagine that a message recipient is alerted to a problem of such severity that it should be tracked beyond the mere acknowledgment of the message. If he or she gives an acknowledge-and-hold response, TelAlert will keep the message active until it is given a release command. Figure 5. Extended Alert Timeline: -ackhold The limit to this held state is set by the value assigned to ReleaseWait. This specifies how long TelAlert will wait after beginning to hold the message before it releases it automatically. Using the -holdrefresh parameter with a command has a special effect on the ReleaseWait value: -holdrefresh causes TelAlert to reset the ReleaseWaittimer each time TelAlert receives a response other than one instructing it to release the message (these might be status reports that are written to a file in the controlling application, for instance). Thus, it is possible to extend the held state of the message indefinitely The Alert Timeline and Escalations The introduction of escalations achieved using [Group] and [Strategy] definitions changes the timeline model of a TelAlert alert slightly. Even here, however, the basic idea is the same: unless it is told to do otherwise, TelAlert considers the alert complete when it has finished sending all the messages that comprise it. In an escalation scenario, the main factor governing the life of the alert is the value assigned to the Complete keyword, which is included in the [Strategy] definition. As long as this criterion has not been met, TelAlert keeps the alert alive. An individual message recipient may positively acknowledge having received it and thus cause TelAlert to let go of that particular send (one of the multiple notifications that may result when an alert is sent to multiple destinations). However, if this individual acknowledgment does not meet the completion criterion for the alert, the alert itself remains alive. Likewise, an individual message recipient may acknowledge and hold a message. This affects the state of the alert itself only if the acknowledgment meets the completion criterion; otherwise it affects only the state of the individual send. In this case, TelAlert holds the message but continues to process other sends and responses associated with the alert until the completion criterion is met. When this happens, TelAlert stops processing sends and clears all messages in an ackwait state. It continues to hold the held message, however, and as a result the alert remains alive until the message is released, the ReleaseWait timer expires, or the alert is cleared by the sender or a TelAlert administrator. Chapter 3: Implementation Planning 33

48 3.4.5 Summary The timeline of a TelAlert alert is, by default, very short and simple. Unless it is configured to do otherwise, TelAlert sends all the messages and immediately releases the alert to which they are related. Extending the life of the alert beyond that point is essential if you want to track acknowledgement of messages, perform escalations, or let users interact with TelAlert. Most of the basic configuration issues involved in a TelAlert implementation do not affect this basic timeline model: it remains in effect regardless of the notification medium, the number of destinations invoked, the schedules associated with them, and the strategy at work. The key to extending the timeline is the enabling of responses. For instance, if the -ackwait parameter is used on the command line, TelAlert will hold on to the alert and wait for a response. If a message recipient acknowledges and holds the message, TelAlert holds the message pending a command to release it. As you proceed with your implementation, keep the timeline model in mind. It will help you understand what you can accomplish when tackling a configuration issue Organizational Scenarios In what follows, you will find high-level descriptions of three implementation scenarios, ranging from the very simple to the relatively complex. Because of the significant differences in needs, structures, and procedures in different organizations, it is impossible to provide you with a precise blueprint for the work you must do to implement TelAlert in your own. These descriptions are offered primarily so you can get some sense of the possibilities available to you and the work required in different instances. A Word About These Scenarios Here you will find some issues covered in enough detail so that you may be able to accomplish certain basic goals without looking elsewhere in this guide. But these scenarios are not intended as a substitute for the more complete coverage provided in subsequent chapters of this guide. In addition to giving you a sense of what lies ahead, these scenarios should help you navigate the rest of the TelAlert documentation and determine what coverage is pertinent for you and what you may safely ignore. All of these process summaries assume that TelAlert (and, where applicable, the Dialogic telephony card) is installed and configured to the point that it can send a test page. You should read all three, as the later ones build on (rather than repeat) the information contained in the first two. 34 TelAlert Administrator Guide - Version 5.7

49 3.4.7 Scenario One: Paging Only Small Organization Some people who implement TelAlert want to use it merely to page the members of a small support group under certain circumstances. The following describes the steps likely to be followed in such a case. 1. Set up [Configurations] Definitions for Paging In a small organization, it is common for everyone to use the same paging service provider, so you might have to create only one [Configurations] definition. Here, though, assume that there are three hands-on support employees with local-coverage paging and a manager who uses a national service from another provider. First, create the definition for the local service based on information found in the appropriate file in the Pagers directory: [Configurations] {ATTWichitaTextPager} Type=TextPager Speed=2400 AreaCode=316 Number= Now, go to [PhonePrefixes] and set LocalAreaCode to match the local area code (in this case, 316). This ensures that TelAlert will not dial the area code when it sends notifications using this definition. Next, create the [Configurations] definition for the national paging service. This too should be based on information contained in the file from the Pagers directory. [Configurations] {SkyTelNationalTextPager} Type=TextPager MaxMessagesPerCall=100 ServiceMaxMessageLength=242 ServiceSupportsMultiBlocks=True Speed=19200 AreaCode=800 Number= For a detailed discussion of these settings, refer to Chapter 7: Configuring for Paging Notification. Chapter 3: Implementation Planning 35

50 2. Set up Destinations Next, you then would set up four [Destinations] definitions, one for each pager to which TelAlert will be sending notifications. The following are for the three support employees. Notice that they all refer to the same [Configurations] definition. [Destinations] {JohnTextPager} Configuration=ATTWichitaTextPager PIN= {CynthiaTextPager} Configuration=ATTWichitaTextPager PIN= {DavidTextPager} Configuration=ATTWichitaTextPager PIN= You can name these definitions anything you like, but including the person s name, along with text and pager, in the name you assign may be helpful later, even if there currently are no other entries with which these might be confused. Next, create the destination for their manager: [Destinations] {RachelNationalTextPager} Configuration=SkyTelNationalTextPager PIN= For a detailed discussion of these settings, refer to Chapter 7: Configuring for Paging Notification. 3. Create Groups At this point, there are just a few [Group] definitions to create. Later, when you begin setting up escalation strategies, you may find that you want to add others or make changes to these (for instance, since strategies are associated with groups, you may want to create several versions of the same group and assign each a different strategy). First, under [Group], create an entry that points to the destinations for all three support employees. This might be used for standard notifications. [Group] {Support} Destinations= "JohnTextPager","CynthiaTextPager","DavidTextPager" 36 TelAlert Administrator Guide - Version 5.7

51 Now, because there are some problems that you will want to bring directly to the attention of the senior support employee (David) and the manager (Rachel), create a [Group] definition that points only to their destinations. [Group] {SupportTop} Destinations= "DavidTextPager","RachelNationalTextPager" Finally, create a [Group] definition that points to both another group {Support} and a destination {RachelNationalTextPager}. You might use this for the most urgent messages. [Group] {SupportAll} Destinations= "Support","RachelNationalTextPager" Note that, until you set up [Strategy] definitions, messages directed to these groups will go to all destinations all at once. For a detailed discussion of these settings, refer to Chapter 14: Broadcasting to Groups and Creating Escalations. 4. Set up Schedules Recognizing that not all support personnel are on duty around the clock, you may want to associate a [Schedule] definition (or two) with each destination so that messages are sent to on-duty destinations only. Under [Schedule], create two entries for each destination one a regular schedule, the other an alternate (i.e., extended) schedule to be used under special circumstances. For instance: [Schedule] {CynthiaPageSched} Monday=07:00-16:00 Tuesday=07:00-16:00 Wednesday=07:00-16:00 Thursday=07:00-16:00 Friday=07:00-16:00 {CynthiaAltPageSched} AddSchedules= "CynthiaPageSched" Monday=16:00-20:00 Tuesday=16:00-20:00 Wednesday=16:00-20:00 Thursday=16:00-20:00 Friday=16:00-20:00 Next, under each of the four destinations you created, set the following values: Schedule=name_of_schedule AlternateSchedule=name_of_alternate_schedule Chapter 3: Implementation Planning 37

52 Here, nameofschedule matches the name of the regular schedule you created for this destination under [Schedule]. For the destination {CynthiaTextPager}, name_of_schedule would be {CynthiaPageSched}, and name_of_alternate_schedule would be {CynthiaAltPageSched}.You can name a schedule anything you like, but, if it is unique to the person and/or destination in question, you should choose a name that makes the relationship clear. Note that, if some employees have the same schedule, their [Destinations] definitions can invoke the same regular or alternate schedules; you need not create unique entries for each. For instance, a [Schedule] definition called {OfficeHours} might suffice as the regular schedule for almost all users. To activate the alternate [Schedule] definitions, set an additional value in each [Destinations] definition: AlternateSchedulePriority=70 This means that alerts with a priority of 70 and higher will be delivered to the destination during both regular and extended duty hours. If you set an additional value OverrideSchedulePriorty=80 alerts of priority 80 and higher will be delivered to the destination at all times. (Of course, you can set whatever threshold you like. The priority of an alert can be determined at the command line.) For a detailed discussion of these settings, refer to Chapter 11: Setting Up and Applying Schedules. 5. Enable Responses In the present scenario, none of the destinations are of a type that permits a response; while you may invoke a set of possible responses when you send a message, there is no way for these options to be displayed to recipients. The set of invoked response options will be available to them should they decide to reply via the command line, however, and thus you might want to set up a basic menu of replies that users would understand to be available. Under [Response], create the following entry: [Response] {Basic} NumReplies=4 Acked=1 NotAcked=2 AckedHold=3 Released=4 Reply1= Yes Reply2= No Reply3= Hold Reply4= Release 38 TelAlert Administrator Guide - Version 5.7

53 Once this is in place, you (or the application controlling TelAlert) can invoke this set of responses on the command line when sending a message: telalertc -g Support -m "node 2745 down" -ackwait 1h -response Basic Any recipient of this message could go to a networked computer on which telalertc was installed and issue a reply, like so: telalertc -reply sendid yes Here, sendid is the integer uniquely identifying the message sent to this recipient. (The command telalertc -showalert will display the IDs of active sends.) Even if you do not want to use this set of responses when you send to regular text pager destinations, setting it up now prepares you for the addition of two-way pagers in the future. Response Menus vs. Response Commands You do not have to set up a [Response] definition for message recipients to be able to acknowledge the message on the command line. -ack, -nak, -ackhold, and -release are TelAlert commands all users can use with regard to any message in an ackwait state (or, in the case of -release, a held state) even if no responses were associated with the send. For a detailed discussion of these settings, refer to Chapter 13: Enabling Responses. 6. Create Strategies The final step in implementing TelAlert in this scenario is setting up [Strategy] definitions that enable alert escalation so that a message is sent first to one destination, then another, then another, until certain conditions are met. In an organization this size, you might need only one. Under [Strategy], create the following entry: [Strategy] {FirstAcknowledge} Complete=Acked>0 Escalate=Incomplete=0 According to this definition, escalation will cease upon the first positive acknowledgment of the message; this is because the first acknowledgment meets the definition of complete found in the [Strategy] definition. As long as no acknowledgment is given, escalation will continue until there are no more valid destinations to which TelAlert can send the message. Once this strategy is in place, it is merely a question of when and how to invoke it. You can do so at the command line (by including -strategy FirstAcknowledge). You can also refer to it within a [Group] definition, so that every message sent to that group is subject to this escalation strategy. Chapter 3: Implementation Planning 39

54 Perhaps this makes especially good sense for one of the groups you have already created, {SupportAll}. Simply set a Strategyvalue here, like so: [Group] {SupportAll} Destinations= "Support","RachelNationalTextPager" Strategy=FirstAcknowledge Now, any message sent to this group with -response Basicand -ackwait time appended at the command line will invoke this strategy. First the message will be sent to all valid destinations comprising {Support} simultaneously. If, after the specified amount of time has passed, no positive acknowledgment has been received, the message will be sent to {RachelNationalTextPager}. Note that, since the only way to respond in this scenario is via the command line, a relatively long -ackwait parameter is most suitable. Response-dependent escalations are more useful in situations supporting response via two-way pager or inbound voice (refer to Scenario Two below). In any event, however, this is an effective means of ensuring that a critical message reaches someone, up to and including the person holding ultimate responsibility. For a detailed discussion of these settings, refer to Chapter 14: Broadcasting to Groups and Creating Escalations Scenario Two: Paging, Voice, and Small Organization Assuming an organization of the same size, adding voice and to the list of notification media is a relatively simple matter. At its most basic, it consists of adding two new [Configurations] definitions and a set of new [Destinations] definitions for each destination to which you anticipate sending messages. Beyond this, you may want to work with your schedules, groups, and strategies to arrive at an overall configuration that allows you to take full advantage of the newly enabled media. This scenario builds on concepts introduced in Scenario One: Paging Only Small Organization, which we recommend you read first. Note that voice notification requires a TelAlert Dialogic telephony card. Set Outbound Voice Configuration First, under [Configurations], create a definition for outbound voice notification (your outbound voice destinations will in turn invoke this entry). The information comprising this definition relates to TelAlert s behavior after the phone is answered: [Configurations] {OutboundVoice} Type=InteractiveTTS ToneConfirmWait=3s AnswerConfirmationRequired=True UserRequired=True PreMsgWait=0.5s PostMsgWait=1s 40 TelAlert Administrator Guide - Version 5.7

55 When TelAlert attempts to make a voice notification using this [Configurations] definition and the phone is answered, it identifies itself and gives the person on the other end of the line three seconds (ToneConfirmWait=3s) to press the # key. Then, because UserRequired=True, it asks the user to key in his or her password, followed by the # key. Once TelAlert has verified the user s identity, it reads the message and provides a pre-defined set of responses, allowing the user to positively acknowledge, negatively acknowledge, or acknowledge and hold the message. These are built-in responses; they are not related to those made available through invocation of a [Response] definition. Note that the Type setting is what connects this [Configurations] definition to {TTS_Port1}, a definition under [Port]; this is how TelAlert knows to use a TTS port for notifications based on this [Configurations] definition. If you did not set up this [Port] definition when you installed and tested the TelAlert Engine, you will have to do so now. For a detailed discussion of these settings, refer to Chapter 3 of the TelAlert Voice and Hardware Guide. Add Voice Destinations Since the instructions for calling voice destinations differ from one case to the next, this information is kept in the [Destinations] definitions themselves. Here you might create one voice destination for each of the people for whom you created paging destinations earlier. For example: [Destinations] {JohnHome} User=John Configuration=OutboundVoice AreaCode=316 Number= Because UserRequired=True, each destination referring to that [Configurations] definition must contain a Uservalue. Thus, after setting up voice destinations for each of your support employees, you will need to set up corresponding entries under [User]: [User] {John} Active=True Password=letmein Alternatively, you could set User=Operator under each voice destination and set up a single entry, {Operator}, under [User]. This setup will not allow you to distinguish between users (all will be recognized as operator ), but it does ensure that no one can receive a voice notification without providing an authorizing password. For a detailed discussion of these settings, refer to Chapter 3 of the TelAlert Voice and Hardware Guide. Chapter 3: Implementation Planning 41

56 Apply Group, Schedule, and Strategy Definitions Once the voice [Configurations]and [Destinations] definitions are in place, you (or the application controlling TelAlert) can send a voice notification using a command such as this: telalertc -i JohnHome -m "node 2745 down" To send voice notifications to groups, invoke schedules, and perform escalations, you will have to do some more work, using techniques similar to those you used when setting up paging: 1. First, refer to these new voice destinations in [Group] definitions. One option you have is to set up voice-only groups that parallel existing groups of pagers. Alternatively, you can form groups comprised of different kinds of destinations. For instance, you could construct a group out of {DavidTextPager}and {RachelCellPhone} and use it so that any page not acknowledged by David within a certain time would result in a call to Rachel s mobile phone. 2. Second, create [Schedule] definitions for these destinations. You can do this by defining new regular and extended entries under [Schedule] and referring to them by setting Schedule and AlternateSchedule values under each voice [Destinations] definition. Or, if these voice destinations are to be valid at exactly the same times as your pagers, you can have each point to schedules you have already created. A third possibility is to refer to regular and extended schedules in each [User] definition and let them be brought into play through the destination s User setting. 3. Third, set a Strategy value for each of the [Group] definitions you create. For a detailed discussion of these settings, refer to Chapter 14: Broadcasting to Groups and Creating Escalations and Chapter 11: Setting Up and Applying Schedules. Set [Configurations] Definitions for With , the same model applies. First create the [Configurations] definition that will be used to send notifications: [Configurations] { } Type= Model=Internet Host=server.domain.com Service=smtp From= telalert@domain.com Together, Type= and Model=Internet point to the {Internet} definition under [Port], which you should set up now, if you have not done so already. 42 TelAlert Administrator Guide - Version 5.7

57 Add Destinations Next, create a destination for each person to whom you want to be able to send notifications. For example: [Destinations] {Cynthia } FullName= Cynthia Jasper Configuration= To= cynthia@domain.com With these definitions in place, you (or the application controlling TelAlert) can send an notification using a command such as this: telalertc -i Cynthia -m "node 2745 down" Note: it is not a good idea to invoke a [Response] definition when sending an notification, given the time that may elapse before the is received and read. Likewise, is not a good medium to use as part of an escalation. Some organizations reserve it for very low-priority alerts; others send all messages via a primary medium (pagers, for instance) and as a matter of course copy them to destinations. One way to do this is by creating a series of groups, each pairing a paging and a matching destination. You can then use these to build larger groups. For a detailed discussion of these settings, refer to Chapter 9: Configuring for Other Notification Media Scenario Three: A Larger Organization When implementing TelAlert in a considerably larger organization than the one just described, the main two additional challenges concern the work s increased volume and complexity. Higher Volume There are a number of reasons for the increased volume of work: You will very likely be creating more [Configurations] definitions, and you will certainly be creating many more destinations. For each destination, you may be creating one or two unique schedules, and for every human user you may decide to create a separate [User] definition and then associate each with the appropriate destinations. There will be more groups to create, and some of these may be comprised of a large number of destinations. Even if you opt to use only one [Response] and one [Strategy] definition, tending to the other parts of this implementation will demand considerably more effort than in a small organization. Chapter 3: Implementation Planning 43

58 Greater Complexity The greater complexity is partly the consequence of the greater volume. For instance: More destinations means more choices as to how to set up your groups. Likewise, the fact that significant numbers of destinations will be on duty at precisely the same times may lead you to set up a system of shared schedules something that, though rather complicated, will save on maintenance in the long run. At the same time, a larger organization is more likely to have needs that can be met only through more complex techniques: In order to achieve certain escalation effects, you may have to develop your [Group] and [Strategy]definitions at the same time, or you may need to return to your originally created groups and add to or modify them based on what you want to accomplish. As mentioned earlier, you might create several otherwise identical versions of a group, associating each with a different [Strategy] definition. You may find that there are times when you want a message to go to a particular person, via a destination that TelAlert chooses based on scheduling. This requires creating a set of groups, each referring to all of the destinations linked to each person. Once you have done this, you will have to decide if and when these groups should comprise larger ones and what escalation strategies, if any, should be applied. First Cover the Basics Because of this additional volume and complexity, it is essential that you first take care of the basics when implementing TelAlert in a larger organization. In a small company, the amount of rework necessitated by a piecemeal or trial-and-error approach may be negligible. In a large organization, however, you can run into a lot of problems if you fail to begin with a solid foundation on which to erect more complex configurational elements. First, create all your [Configurations] and [Destinations] definitions. Next, create [Schedule] definitions and associate these with the destinations in as hierarchical a way as possible (i.e., by sharing identical schedules whenever possible). Finally, set up a system of [User] definitions that makes sense for what you want to do. You may not need to create any such entries, but if you want TelAlert to require a password on outbound voice notifications, you must at least set up a standard [User] definition ({Operator}, for instance) and set this value in all appropriate destinations. Keep in mind that some additional functionality depends on defining destinations in terms of unique human users (i.e., User=John, User=Cynthia, etc.), and doing this now may make certain tasks easier down the road. 44 TelAlert Administrator Guide - Version 5.7

59 Then Focus on Outcomes Once you have your foundation in place, shift your focus to the outcomes you want to achieve. Most behaviors not already made possible by the foundation (e.g., sending to a single destination) are related to escalation and as such involve the creation and invocation of [Group], [Response], and [Strategy] definitions. This is the work that requires the most careful planning. As you proceed, you should be thinking explicitly about situations in which you will be sending notifications to more than one destination. Be sure to begin with what you see as the most important or most common situations. Here are some issues to consider that will affect the groups you construct and the strategies you apply: What is the goal of the notification? To what destinations is it appropriate to send the notification? Should the notification be sent to the destinations all at once or sequentially? Should the set of appropriate destinations be further broken down, so that the notification goes first to one subgroup and then to another? Or are all of the destinations roughly equivalent? Under what conditions should TelAlert stop escalating the alert? Under what conditions should TelAlert release the alert? Is it desirable that the notification be received by more than one person in the group? By everyone in the group? Is a response necessary? What response options will be provided? What responses can affect the processing of the alert? How would you like an urgent alert handled in a worst-case scenario for instance, if no support personnel could be contacted? Will a response from a message recipient be used to control an external application? Chapter 3: Implementation Planning 45

60 Work Towards an Economical Configuration Whether you are building your foundation or have begun erecting [Group] and [Strategy] definitions on top of it, it is a good idea to work towards as economical a configuration as possible i.e., one that does not needlessly repeat information but instead uses cross-references and inheritance to make single entries broadly available. Doing so means less work up front and easier maintenance down the road. This principle is mentioned above, with regard to representing work schedules. If everyone is on one of three work schedules, there is no point in creating more than three corresponding [Schedule] definitions. Even if work schedules are more varied, you can avoid entering one for every single destination. For instance, if you are setting up more than one destination for each human user, it may make sense to associate schedules with [User] definitions and include the relevant User value in each [Destinations] definition. There are several other common opportunities for creating an economical configuration. Below are some methods to keep in mind: If you want to include the members of one group in a larger one, include them as a subgroup. You can do this even if you want these destinations treated as if they had been listed individually by setting SubgroupEscalation=True in the larger [Group] definition. If you will be using the same strategy in most or all of your escalations, specify it under [Group] by setting a default Strategy value. Then include a Strategy setting in the definitions of only those groups for which you want another strategy to apply (this group-level strategy specification overrides the default). 46 TelAlert Administrator Guide - Version 5.7

61 4 Configuration Basics 4.1 Overview An overview of the concepts you will use to configure TelAlert How it works, including a comparison of all of the different tools for performing configuration tasks in Classic TelAlert TADesktop 4.2 TelAlert Configuration Methods: telalert.ini; TADesktop When the telalerte server daemon starts up, it creates a memory-cached copy of the disk binary file telalert.sects, and uses the 'Section' configuration data in the memory-cached telalert.sects copy for all operations. To change the configuration, you must update the disk telalert.sects copy, and then either command telalerte to 'reload' its cache from disk, or stop and restart telalerte. When TelAlert was installed, the first version of the binary telalert.sects file was 'compiled' from a human-readable text file named telalert.ini. (telalert.ini may actually be a set of files, where the primary telalert.ini file contains $include commands that reference other.ini files during the compliation process.) All subsequent configuration changes must be made by either changing telalert.ini and recompiling telalert.sects; or by directly changing telalert.sects. Here are your options: Editing telalert.ini with a text editor (not a word processor) of your choice -- this is the original method, and is still a popular option with TelAlert. Users that have chosen to use the TADesktop GUI, should NOT edit telalert.ini; in fact, we recommend TADesktop users remove all telalert.ini files to reduce the risk of inconsistent configuration specifications. Using the TADesktop GUI to modify telalert.sects. TelAdmin is used to edit all configuration Sections. The TADesktop Wizards can also be used to modify TelAlert s telalert.sects file.

62 Figure 6. TADesktop TelAdmin is a graphical configuration tool for Windows similar in design to Windows Registry Editor. TelAdmin is part of the TelAlert Desktop graphical configuration environment. Though TelAdmin runs only on Windows platforms (refer to the Release Notes for supported versions), it may be used to configure TelAlert installations running on UNIX by installing TA Desktop on a Windows machine and pointing it to the TelAlert server. 48 TelAlert Administrator Guide - Version 5.7

63 Figure 7. TelAlert Desktop Host Configuration The TelAlert Desktop also offers other features that make configuration of your TelAlert installation easier. Please refer to the TelAlert Desktop User s Guide for information on working with TelAdmin, on the differences between the two configuration methods, and on switching between configuration methods Choosing a Configuration Method A small TelAlert installation with a single administrator may use the administrator s personal preference to choose between editing telalert.ini and using TADesktop. Refer to the TelAlert Desktop User s Guide for notes on factors such as automatic file backups; physical proximity to the TelAlert server; etc., that should be considered when making your decision. A multi-administrator TelAlert installation, or an installation with multiple roles (user, supervisor, administrator) should probably use TelAdmin. TelAdmin is not a simple graphical configuration-file editor, but rather a front end for a TelAlert-proprietary multiuser transactional database system (the telaconfe server daemon). Using TelAdmin, multiple personnel may simultaneously update the configuration, and a record-locking system ensures that they do not accidentally overwrite each other s changes. Personnel can also manage multiple TelAlert servers from a single instance of TelAdmin. Finally, by implementing the optional [Owner] section and assigning the proper Owner keyword values in other Sections and object definitions, the system administrator may define access rights that control which other Administrators/supervisors/users may access which TelAlert Sections and definitions within TelAdmin. It is possible to implement roles/permissions without TADesktop by splitting telalert.ini into a large number of individual.ini files, each with separate OS access rights, but it s easier to use TADesktop. Chapter 4: Configuration Basics 49

64 4.2.2 What Make TelAlert Re-Read its Configuration File Means From time to time, this Administrator Guide reminds you that you must make TelAlert re-read its configuration file before your changes will take effect. As mentioned above, this means that you must make the telalerte server daemon reread its memory-cached copy of telalert.sects. How you do this depends on how you configure TelAlert: If you are editing telalert.ini directly, this means issuing a telalert -compile command followed by a telalert -reload command, or by issuing a telalert -init command (which implicitly does a -compile and -reload). Note that if the -compile step encounters errors, the disk copy of telalert.sects will not be updated, and the -reload will either be skipped, or will simply refresh the memory-cached copy with the same data it previously contained. Also note that if you made changes to either the [License], [Port] or [Process] section, you should do a telalert -stop and a telalert -start -init, since these changes affect the number of child processes managed by telalerte. If you are using TADesktop, after selecting the appropriate Configuratation section a window will appear allowing you to enter in the appropriate configuration data. After completing the data you click the Save button and the telalert.sects is updated. See "Configuring TelAdmin s Save and Backup Options" in the TelAlert Desktop User Guide for more details. Note: You may need to stop and restart the TelAlert service after certain configuration sections are updated. 4.3 Understanding Configuration Examples In this Administrator Guide, examples of configuration tasks usually include samples of keyword-value pairs as they would appear in a text telalert.ini file. The level of organization known as a Section is represented by [square brackets]. The level of organization known as a Definition is represented by {curly brackets}. (See Key Configuration Concepts in Chapter 2: Technical Overview for detailed discussion of these terms.) Consider the following example: [Configurations] {OutboundVoiceLive} Type=InteractiveTTS AnswerConfirmationRequired=True ToneConfirmWait=15 UserRequired=True 50 TelAlert Administrator Guide - Version 5.7

65 This text example s information can be applied to all of the configuration methods: If you are editing.ini files, find the [Configurations] section. Find the existing {OutboundVoiceLive} definition; if there isn t an existing definition with that name, create a new definition. Make sure the new definition begins AFTER any Section default keyword-value entries at the beginning of the section; it may be best to add the new definition at the END of the section, immediately preceding the [Section] header for the subsequent section. See <Emphasis>Modifying a Section s Defaults on page 4-5 If you are editing telalert.ini, the first line tells you that this is an entry to be made in the [Configurations] section. The second line ( ) indicates that there may be other lines, including other definitions, between the start of the section and this entry. (Never actually enter as a line in the file; it will cause an error when you perform the -init.) The rest is the entry to be made that is, to be typed, verbatim, at this point in the file. If you are using TelAdmin, the line [Configurations] tells you to expand the Configuration heading in the tree in TelAdmin s left pane. The line Type=InteractiveTTS tells you to select the InteractiveTTS subtree under Configuration in TelAdmin s left pane. The line enclosed in curly brackets tells you to select (or create) a definition named OutboundVoiceLive in the TelAdmin s right pane. The other lines tell you which keywords to modify, and what values to enter in each. For example, UserRequired=True tells you to choose True from the UserRequired dropdown list. See the TelAlert Desktop User Guide for further information. Figure 8. TADesktop Configuration section Chapter 4: Configuration Basics 51

66 Figure 9. TADesktop Configuration screen Singular vs. Plural Section Names To simplify editing telalert.ini, many section names can be headed with either a singular or plural version of their name. Below is the complete list of sections that can take either a singular or plural name: Analog or Analogs Configuration or Configurations Destination or Destinations File or Files Filter or Filters Group or Groups Menu or Menus Message or Messages Notification or Notifications Owner or Owners Pattern or Patterns 52 TelAlert Administrator Guide - Version 5.7