BMC Impact Solutions Infrastructure Management Guide

BMC Impact Solutions Infrastructure Management Guide
Supporting
BMC Impact Manager version 7.3 BMC Impact Administration Server 7.3 BMC Impact Explorer version 7.3 BMC Impact Portal version 7.3
February 2009
www.bmc.com
Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada

Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031 Fax 713 918 8000
Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000
Copyright 20062009 BMC Software, Inc. BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners. AIX is a registered trademark of International Business Machines Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC. Linux is the registered trademark of Linus Torvalds. Oracle is a registered trademark of Oracle Corporation. Sun, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and several other countries. UNIX is the registered trademark of The Open Group in the US and other countries. BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.
Customer support
You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see Before contacting BMC.
Support website
You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can
I I I I I I I I
read overviews about support services and programs that BMC offers find the most current information about BMC products search a database for issues similar to yours and possible solutions order or download product documentation download products and maintenance report an issue or ask a question subscribe to receive proactive e-mail alerts when new product notices are released find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and telephone numbers
Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to customer_support@bmc.com. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.
Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:
I
product information product name product version (release number) license number and password (trial or permanent)
operating system and environment information machine type operating system type, version, and service pack or other maintenance level such as PUT or PTF system hardware configuration serial numbers related software (database, application, and communication) including type, version, and service pack or maintenance level
I I I
sequence of events leading to the issue commands and options that you used messages received (and the time and date that you received them) product error messages messages from the operating system, such as file system full messages from related software
Contents
Chapter 1 Managing BMC Impact Manager cells 23 General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Production cells and test cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Creating cell-specific configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 About mcell.dir, the cell directory file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Managing high availability cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Automatic failover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Automatic switchback process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Manually failing over to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Manually switching back to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Explicitly connecting a CLI to a selected high availability cell server. . . . . . . . . . 47 Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 56 Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 58 Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized. . . . . . . . . . . . . . . . . . . . . . 63 Chapter 2 Managing a Knowledge Base 65
Knowledge Base structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Contents
About the unified Event Management and Service Impact Management Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Knowledge Base index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Managing a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Integrating a unified KB with pre-7.2 cell definitions . . . . . . . . . . . . . . . . . . . . . . . 70 Creating a new production or test Knowledge Basemcrtcell . . . . . . . . . . . . . . . 71 Importing Knowledge Base information into a cellmkb . . . . . . . . . . . . . . . . . . . 71 Compiling a Knowledge Basemccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Loading a Knowledge Base into a running cellmcontrol . . . . . . . . . . . . . . . . . . . 72 Implementing changes to a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Versioning a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Retrieving KB version information in rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Retrieving KB version information by using a commandmgetinfo . . . . . . . . . . 74 Chapter 3 Managing the BMC Impact Administration server 77
Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 81 Guidelines for manual edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Defining permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Full Access role permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Adding customized role/permission mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Defining group roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 File-based authentication: updating user information . . . . . . . . . . . . . . . . . . . . . . . 91 Adding role names to the cells KB definition files. . . . . . . . . . . . . . . . . . . . . . . . . . 93 Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . 93 Synchronizing cell information with BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . 95 Updating cell information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Defining client logging for the iadmin script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Customizing colors for severities, statuses, and priorities. . . . . . . . . . . . . . . . . . . . 99 IAS Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Customizing the IAS thread pool handling IAS Clients . . . . . . . . . . . . . . . . . . . . 100 Defining standalone, primary, and secondary BMC Impact Administration servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Defining a failover configuration for the Impact Administration cell . . . . . . . . . 105 Transaction and trace logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Example trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Configuring BMC Impact Administration server to support remote actions. . . 107 Configuring Lightweight Directory Access Protocol for BMC Impact Administration server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Problem: Cell_info.list synchronization error during manual configuration of an IAS failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
BMC Impact Solutions Infrastructure Administration Guide
Chapter 4
Managing the BMC Impact Portal
121 122 122 123 123 124 124 124 124 125 126 127 127 129 130 130 131 132 132 133 134 136 139 140 142 142 142 144 145 146 148 149 150 152 156 157 158 159 160 163 164 165 165 165 169 172 172
Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . internal.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 5 Working with Infrastructure Management
Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying and understanding the Details and Administer tab data . . . . . . . . . Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How a product component registers and communicates with the IAC . . . . . . .
Contents
Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Chapter 6 Managing the BMC Impact Explorer (BMC IX) console 177
Defining property files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Selecting a single BMC IX instance for cross- and web-launching . . . . . . . . . . . . . . . 179 Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Configuring display and connection settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Defining global event severity and priority color values . . . . . . . . . . . . . . . . . . . . . . . 184 Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Chapter 7 Defining presentation names 187
Presentation names overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Creating a new presentation name resource file . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Digitally signing a .jar file with a digital test certificate. . . . . . . . . . . . . . . . . . . . . 194 Enabling or disabling presentation names in BMC Impact Explorer tool tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Chapter 8 Configuring StateBuilder and gateways 197
Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 StateBuilder configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Exporting events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Modifying a statbld.conf file to export events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 206 Configuring tracing for StateBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Trouble-shooting the StateBuilder process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Appendix A BMC SIM and EM CLI Reference 209
BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 211 Configuring CLI authentication through BMC Impact Administration Server . 212 BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 213 mccompCompiling rules in the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . 214 mcellStarting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 mcfgtraceConfiguring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 mclassinfoRequesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 mcollinfoGetting information about a specific collector . . . . . . . . . . . . . . . . . . 225
8 BMC Impact Solutions Infrastructure Administration Guide
mcontrolPerforming cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcrtcellCreating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcstatReturning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mdelcellDeleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetinfoRetrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetrecObtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkbUpdating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkillStopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mlogchkPerforming consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mposter and msendManaging data and events . . . . . . . . . . . . . . . . . . . . . . . . . mqueryRetrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrecoverRecovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . mrextractExtracting cell state files to create new state files . . . . . . . . . . . . . . . mrmergeMerging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetmsgModifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetrecSetting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix B mcell.conf file parameters
228 231 235 237 238 243 245 248 249 251 257 262 264 265 267 268 269 272 272 273 274 274 276 278 280 281 283 284 287 287 288 290 291 292 292 293 297
Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deprecated MessageBuffer propagation parameters. . . . . . . . . . . . . . . . . . . . . . . Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index
Contents
10
BMC Impact Solutions Infrastructure Administration Guide
Figures
ConnectionPortRange syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Distributed event management using event propagation . . . . . . . . . . . . . . . . . . . . . . 33 Format of an entry in the mcell.dir file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Example of the mcell.dir file and its entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Passive connection format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Data object specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 mcell.modify file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Masking syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Format of configuration line in mcell.trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Output from mgetinfo kbsources argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Relation among users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . 82 Excerpt from ldap_configuration.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Infrastructure Management navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Default service model BMC Impact Solutions (with active services) . . . . . . . . . . . . 144 Edit Relationships dialog with Edit This Relationship subdialog . . . . . . . . . . . . . . . 156 Actions right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 High availability (HA) view: two cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Actions right-click menu for OVO adapter cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 default.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Operator.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Default policy file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Listing of the contents of a keystore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Parameters used to print event in BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Example of printed events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Command to configure the export file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 gateway.export file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 gateway.explore file output for new events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 gateway.explore file output for modified events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 mccomp syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 mccomp example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Example output for mccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 mcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Starting a cell as a service on windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Starting the BMC Impact Manager service on Microsoft Windows . . . . . . . . . . . . . 217 mcfgtrace syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 mcfgtrace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 mclassinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figures 11
Raw output format for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Class tree for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Example of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Example output of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . 223 Example of mclassinfo command for list of classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Example of mclassinfo command output for list of classes . . . . . . . . . . . . . . . . . . . . . 223 Example of mclassinfo command for adding slot names . . . . . . . . . . . . . . . . . . . . . . 224 Example of mclassinfo command output for adding slot names . . . . . . . . . . . . . . . . 224 Example of mclassinfo command for adding slot flags . . . . . . . . . . . . . . . . . . . . . . . . 224 Example of mclassinfo command output for adding slot flags . . . . . . . . . . . . . . . . . 224 mcollinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Raw output format for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 mcollinfo example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 mcollinfo command for verbose mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 mcollinfo command for number of events for severity/status . . . . . . . . . . . . . . . . . . 227 mcontrol syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Retrying Pending propagations with mcontrol command . . . . . . . . . . . . . . . . . . . . . 230 Example of mcontrol command output for retrying pending propagations . . . . . . 230 Terminating a cell using the mcontrol command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Example of mcontrol command output for terminating a cell . . . . . . . . . . . . . . . . . . 231 Reconfiguring a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Example of mcontrol command output for reconfiguring a cell . . . . . . . . . . . . . . . . 231 mcrtcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Example of output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Example output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Example mcrtcell for recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 mcstat syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 mcstat example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Message for cell not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Message for cell running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 mdelcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Deleting a cell using mdelcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Output for mdelcell if cell is not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Output for mdelcell if cell is running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 mgetinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Example of mgetinfo param . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 mgetinfo param command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 mgetinfo services command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Output of mgetinfo connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 mgetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Example of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Output of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 mkb syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 mkb command on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 mkb output on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
12
mkb command on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkb command output on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkill syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mlogchk syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mlogchk message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mposter syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msend syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition changes using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling persistent buffering using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error message if buffers files are not writable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mquery syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of raw output specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verbose mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End of form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mquerySelect events with severity status . . . . . . . . . . . . . . . . . . . . . . Example of mquerySelect events from collector . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting events using mquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrecover syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing a broken cell using mrecover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrextract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mrextract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrmerge syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of mrmerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetmsg syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of msetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . command to send tracing output to text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
248 248 248 249 249 250 250 250 251 252 252 254 255 255 256 257 258 258 259 259 261 261 261 263 263 264 264 265 266 267 268 269 272 285
Figures
13
14
Tables
BMC Impact Solutions configuration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Cell configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Substitution parameters for %X in path value parameters . . . . . . . . . . . . . . . . . . . . . . 29 Default mcell.propagate options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 IP Address parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Files for cell reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 MC_CELL_METRIC slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Default values for client parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 MC_CELL_CLIENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 MC_CELL_MODIFIED_EVENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Trace configuration file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 MC_CELL_PROCESS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 BMC Impact Manager exit codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 SIM_NOTIFICATION_REGISTRY dialog box fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Knowledge Base subdirectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Knowledge Base file extensions and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Configurable IAS files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 iadmin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 BMC Impact Explorer user group mapping to functionality . . . . . . . . . . . . . . . . . . . 83 Groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Cell entry format in cell_info.list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Server logging properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 IAS status monitoring properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 IAS thread pool properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 IAS synchronization properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 mcell.dir entries for a failover pair of Impact Administration cells . . . . . . . . . . . . . 105 IAS log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 LDAP configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Event operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Event Table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Status table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Report parameters (application.properties file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Report parameters (internal.properties) file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 application.properties file in smsIwc directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 application.properties file in smsConsoleServer directory . . . . . . . . . . . . . . . . . . . . . 134 aggregator.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 internal.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Supported application groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Icon listing for infrastructure management model . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Slot values: Details: General subtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Tables 15
Edit Relationship dialog: field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Edit This Relationship subdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Audit log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Audit log IAS properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Slots for specifying support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 run_state values for components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Component state and menu options for a normal or primary cell in a high availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Component state and menu options for a secondary cell in a high availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Components and actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 default.console_policy.prop parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Property descriptions from ix.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Event severity levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Event priority levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 xml files that define user interface elements in BMC IX . . . . . . . . . . . . . . . . . . . . . . . 186 Presentation names for BMC Impact Solution interfaces . . . . . . . . . . . . . . . . . . . . . . 188 Presentation name key formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 StateBuilder file name conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 statbld.conf Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Gateway configuration parameter predefined variables . . . . . . . . . . . . . . . . . . . . . . . 201 Gateway Configuration Parameter Text Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 gateway.export file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 BMC Impact Manager CLI command descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Common options for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Common return codes for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 mccomp options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 mcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 mcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 mcfgtrace option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 mcfgtrace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 mclassinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Type of slot value for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Reported facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Class flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Information amount limitation options for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . 222 mclassinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 mcollinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Information amount limitation options for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . 227 mcollinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 mcontrol option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 mcontrol controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Files for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 mcrtcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 mcrtcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 mcstat option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 mdelcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
16
mdelcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetinfo option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetinfo information options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information from connect request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetrec option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkb options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkb new file options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkill option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mlogchk return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mposter and msend options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mposter and msend return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mquery options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mquery query options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mquery return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrecover option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrecover return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrextract options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrextract return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrmerge options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrmerge return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetmsg options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetmsg return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetrec options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetrec return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Manager CLI configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date and time format parameters for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heartbeat slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal cell monitors parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deprecated MessageBuffer propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell tracing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
238 239 239 240 243 244 245 246 249 251 252 257 257 260 262 263 263 264 265 266 266 267 268 268 269 270 274 274 276 278 279 280 281 284 286 287 287 288 290 291 292 292 293
Tables
17
18
Chapter
Managing BMC Impact Manager cells

1
This chapter describes how to manage and configure BMC Impact Manager cells. General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Managing high availability cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Manually failing over to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Manually switching back to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Automatic failover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Automatic switchback process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Explicitly connecting a CLI to a selected high availability cell server. . . . . . . . . . 47 Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 56 Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 58 Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized. . . . . . . . . . . . . . . . . . . . . . 63
Chapter 1 Managing BMC Impact Manager cells 23
General configuration overview
General configuration overview

To configure the BMC Impact Solutions environment, you configure the following components after installation:
I I I
BMC Impact Manager cell BMC Impact Explorer BMC Impact Portal
Table 1 outlines the tasks that configure these components. Table 1

1
BMC Impact Solutions configuration process

Component For more information, see Chapter 4, Managing the BMC Impact Portal BMC Portal Getting Started
Task Description
(optional) Configure the BMC Impact Portal. BMC Impact Portal
2 3
Configure BMC Impact Manager cells.
BMC Impact Manager
Chapter 1, Managing BMC Impact Manager cells Chapter 3, Managing the BMC Impact Administration server BMC Portal Getting Started BMC Impact Solutions Installation Guide
Define user groups for access to the console BMC Impact functions and objects. Administration Server Distribute the BMC Portal URL address so users can install consoles. BMC Impact Explorer can be deployed as a Java Web Start application from BMC Impact Portal or installed standalone.
I I I
BMC Impact Portal BMC Impact Explorer BMC Impact Service Model Editor
5 6
(optional) Customize BMC Impact Portal.
BMC Impact Portal
Chapter 4, Managing the BMC Impact Portal Chapter 6, Managing the BMC Impact Explorer (BMC IX) console Chapter 8, Configuring StateBuilder and gateways Chapter 7, Defining presentation names
(optional) Customize BMC Impact Explorer. BMC Impact Explorer
7 8
(optional) Configure the StateBuilder, which BMC Impact Manager manages the persistent storage of events. (optional) Customize the labels used in the console interfaces.
I I I
BMC Impact Portal BMC Impact Manager BMC Impact Service Model Editor
After you configure BMC Impact Manager, BMC Impact Portal, and BMC Impact Explorer, you are ready to implement event management and service impact management. For information, consult the following resources:
24
Production cells and test cells
Event management For information about setting up adapters to collect events, see the BMC Impact Event Adapters User Guide. For information about setting up dynamic data, policies, event groups, and image views, see the BMC Impact Solutions Event Management Guide. For information about defining event data, writing event management rules, defining collectors, or creating actions, see the BMC Impact Solutions Event Management Guide.
Service impact management For information about monitoring service impact management, see BMC Impact Solutions Service Impact Management Guide. For information about defining service models, see the BMC Impact Solutions Service Modeling and Publishing Guide.

A production cell is an EM or SIM cell that service operators and service managers use to monitor the events and services associated with your IT resources in real time. A test EM or SIM cell provides senior service managers and service administrators with a test environment in the following ways:
I
SIM cell Enables publishing of service models from a development sandbox to a test environment before promoting them to a production environment. Each BMC Impact Service Model Editor user has one dedicated test environment, which consists of a pair of test CMDB data sets and an alias to a test cell. Promoted service model components include those in a users sandbox and in production. For details about test environments and promotion, see the BMC Impact Solutions Service Modeling and Publishing Guide.
EM cell For event management, a test cell provides KB developers with a test environment for defining event classes, event management rules, policies, actions, and collectors and testing their behavior with test event data.
BMC Impact Portal does not collect events from test cells for reporting.
Chapter 1 Managing BMC Impact Manager cells
25
Production and test cell naming and creation

The only way to distinguish a test cell from a production cell is by the cell name. Adopt a naming convention for test and production cells that clearly identifies its purpose. You name a cell when it is created. One cell is created with each BMC Impact Manager instance that you install. You use the mcrtcell command to create additional production or test cells. The mcrtcell command can only be run on the local computer where the cell is being created. For more information about syntax and options available with mcrtcell, see mcrtcellCreating a new cell on page 231.
Production and test cell configuration

You register test and production cells in BMC Impact Portal. For instructions, see Registering production and test cells in the BMC Impact Portal on page 124. In BMC Impact Service Model Editor, each user associates a test cell to a test environment. For further information, see BMC Impact Solutions Service Modeling and Publishing Guide. In BMC Impact Explorer, assign the production and test cells to a group. The default groups are MyTest and MyProduction.
Viewing test cell data

You view test data in BMC Impact Explorer.
I
To view test event data, collectors, and actions, select a test cell in the Events view. To view and create test event management policies, select a test cell in the Administration view. To view test service model components, use the Find tool in the Services view and select a test cell.
26
Cell configuration tasks

The more you customize your cell to fit your needs, the more efficiently the cell works. All configuration tasks are optional. Table 2 describes the cell configuration tasks. Table 2
Task 1

For more information, see mcrtcellCreating a new cell on page 231
Description Create additional cells. When you install BMC Impact Manager on a system, one cell is installed. You can create additional cells by running the mcrtcell command.
2 3
If you created multiple cells for an environment, you can create separate configuration files for each cell. If you created multiple cells for an environment, configure the cells so that they can communicate with other cells in the network.
Creating cell-specific configuration files on page 30 BMC Impact Solutions Getting Started Guide
If you created multiple cells for an environment, configure a high BMC Impact Solutions Getting Started availability cell or cells. Guide Managing high availability cell servers on page 44
Events can be processed locally or selectively propagated to other Configuring event slot cells. To configure the event slots that must be propagated when propagation on page 31 they are changed configure the propagation configuration file. If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone. Configuring passive connections on page 36
7 8 9
To add a time stamp to a slot so that the date and time is recorded Configuring slots for time when the slot is changed, configure the mcell.modify file. stamping on page 37 If desired, you can encrypt communication among the various BMC Impact Solutions components. Set the default client parameters executing CLI commands. Configuring encryption on page 38 BMC Impact Manager CLI configuration on page 269
27
Configuring mcell.conf parameters

The mcell.conf configuration file installed with the cell allows it to run without any additional configuration. You can change the configuration parameters in the mcell.conf file to customize the cell for your particular IT infrastructure and environment. You can override some parameters using command line arguments when you start the cell. For more information, see mcellStarting a cell on page 216.
To configure the mcell.conf file using a text editor 1 Open the mcell.conf file in a text editor.
The default location is MCELL_HOME\etc.
2 Create line entries using the format Parameter=Value based on the syntax rules
described in Rules for cell configuration parameter syntax.
3 Save the changes. 4 Either reload the cell configuration or restart the cell for the changes to go into
effect. For more information, see Reloading cell configuration on page 43.
Rules for cell configuration parameter syntax

I
One parameter per line, in the form: Parameter=Value where the Value extends to the end of the line Typically, the value for a parameter is a Boolean value, a string, or a path. The supported Boolean values are Yes/No and On/Off. The Boolean values are not case sensitive, so, for example, On, ON, on, and even oN are equally valid. Do not enclose the value in quotation marks unless you want the quotation marks to be part of the value. Times are stated in seconds unless otherwise specified. By default, all parameter settings are disabled, that is, commented out with a # sign at the beginning of the line of code. Enable a parameter setting by removing the # sign that precedes it.
For more information on cell configuration parameters, see Appendix B, mcell.conf file parameters.
28
Specification of path values

Parameters that have path values contain the string fileName or dirName, for example TraceConfigFileName or SystemLogDirName. Path values can be stated as:
I
absolute pathstarts with slash (/) or backslash (\), or on Windows, with a drive designator (for example, D:) runtime relative pathstarts with ./ or ../. The path is relative from the cells working directory. The working directory is the root directory (/) when it runs as a daemon or a service. When running in foreground, it is the directory where mcell is started. configuration relative pathall other path values are relative from the cells configuration directory, or, for program paths, from the kb\bin directory.
Path values can contain the substitution parameters $VAR or %X. Any $VAR parameter is substituted by the value of the environment variable VAR. Table 3 lists the possible %X substitution parameters. Table 3
Parameter %H %C %B %L %T %P %N
Substitution parameters for %X in path value parameters

Description cell home directory cell configuration directory Knowledge Base binary directory, kb\bin log file directory temporary file directory program name cell name
Modifying SystemLogDirName, SystemTmpDirName, and KBDirName

With the cell configuration parameters SystemLogDirName and SystemTmpDirName, users can specify alternative path locations for the system defined log and tmp directories. Their default values are %H/log and %H/tmp. To enable file name specifications that refer to these alternative locations, use the substitution parameters %L for the log and %T for the tmp directory. They are substituted by the specified path to the log and tmp directory, respectively.
29
Creating cell-specific configuration files
If you change the default value for the SystemLogDirName parameter or the KBDirName parameter in the mcell.conf file, you must also change the value in the statbld.conf file. If you fail to do this, the cell loses persistency and the mcdb file is not created, because the StateBuilder is configured from statbld.conf file and has no input from the mcell.conf file. As a result, StateBuilder does not know where to find the log files or the KB directory it requires.
ConnectionPortRange syntax
Figure 1 shows the syntax of ConnectionPortRange. Figure 1 ConnectionPortRange syntax
PortRange = PortSequence{, PortSequence} PortSequence = Port[-Port]
A range is a number of sequences, each of which is a consecutive range of ports. The cell attempts to access all ports in the specified order. The default is to use any of the ephemeral ports. For example,
I I
18281840 specifies a range of ports 1828 through 1840 1828, 1829, 1840 specifies the sequence of ports 1828, 1829, and 1840
Creating cell-specific configuration files

By default, one set of configuration files is installed during installation of the BMC Impact Manager. These files are located in the MCELL_HOME\etc directory and multiple cells on a host can use them. You can also create unique configuration files for individual instances (cells) as needed.
To create cell-specific configuration files 1 Copy the configuration file that you want to be unique to the
MCELL_HOME\etc\cellName directory. cellName represents the name of the cell.
2 Using a text editor, edit the configuration file and customize it for that cell and
save it. You can copy and edit any configuration file located in the MCELL_HOME\etc directory.
3 Either reload the cell configuration or stop and start the cell so that the changes
take affect.
30 BMC Impact Solutions Infrastructure Management Guide
Configuring event slot propagation
When a cell starts, it searches for configuration files in the MCELL_HOME\etc\cellName directory. If no configuration file is found, the cell uses the configuration file in the MCELL_HOME\etc directory. For example, if you copy the mcell.conf file into the MCELL_HOME\etc\cellName directory and modify it, the cell reads that mcell.conf file and all other files in the MCELL_HOME\etc directory. All cells use the following cell-specific directories:
I
$MCELL_HOME/etc/CellName contains cell-specific configurations (including the
Knowledge Base)
I
$MCELL_HOME/log/CellName contains the cell transaction logs and persistent state
of the cell
I
$MCELL_HOME/tmp/CellName contains the cells temporary files
High availability cells use the cell-specific directories, but the names of the log and tmp directories are suffixed with # followed by the server number, 1 for the primary server and 2 for the secondary server. The names become:
I I I I
$MCELL_HOME/log/CellName# 1 $MCELL_HOME/log/CellName# 2 $MCELL_HOME/tmp/CellName# 1 $MCELL_HOME/tmp/CellName# 2

Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed, and in which direction (forward/backward), you configure the propagation configuration file mcell.propagate. The mcell.propagate file lists all of the slots whose modifications will be propagated. In addition, using the BMC Impact Solutions gateways, events can be propagated to a third-party program in a specific format that is described in a gateway configuration file, gateway.GWType. The default location for these files is MCELL_HOME\etc. When an event has been propagated to a destination and that event is later modified, the modifications are then propagated to the same destination. The event can be propagated through a Propagate rule. If the destination is a gateway, gateway configuration rules also apply.
31
For the mcell.propagate file to be effective, one or more Propagate rules must be running. For information about Propagate rules, see the BMC Impact Solutions Knowledge Base Development Reference Guide. The format is Slotname = Value, where:
Slotname = slot name or CLASS for class-specific slots Value = sequence of { b = backward f = forward }
You can specify a slot in the base CORE_EVENT class. However, if you want to specify a slot outside those in the base CORE_EVENT class you must use the CLASS specifier, which means that all class-specific slots are propagated in the direction given. Table 4 on page 32 lists the parameters in the mcell.propagate file and the defaults. Table 4
Parameter
CLASS mc_modhist
Default mcell.propagate options

Action Performed propagates changes to the class-specific slots up (forward) within the cell hierarchy propagates changes to the mc_modhist up (forward) within the cell hierarchy This is a system defined slot that requires such propagation. Default Values f f f
administrator propagates administrator value changes up (forward) within the cell hierarchy
mc_notes repeat_count severity status
propagates changes to notes attached to an event up (forward) within the cell hierarchy propagates changes to repeat_count up (forward) within the cell hierarchy propagates severity value changes up (forward) within the cell hierarchy
f f f
propagates status value changes in both directions, backward and forward, in the bf cell hierarchy
If you have multiple instances of BMC Impact Manager installed, you might want to use event propagation to distribute the event processing load among the cells or to back up events on another cell for failover. Figure 2 on page 33 illustrates a cell network that is collecting and processing numerous events in a distributed environment.
32
Figure 2
Distributed event management using event propagation

Some events are propagated for management by other cells in the cell network. cell
cell
cell
cell cell cell
cell
event sources
event sources
event sources
event sources
In this illustration, the lower-level cells process the source events and then propagate (or forward) the events on to higher-level cells according to a Propagate rule or an Event Propagation policy. As events pass through a series of cells, the cells discard unneeded events, identify and leave behind unimportant events, and resolve some of the problems reported by other events. To enable event propagation, perform the following tasks:
I I I I
enable cell-to-cell communication in mcell.dir configure propagation parameters in mcell.conf specify the slots whose modification has to propagate in mcell.propagate either write a Propagate rule or define an Event Propagation policy
How unpropagated events are buffered

When the cell is started, the buffers are set to a minimum workable size. The default minimum size is 5000 events for each destination buffer and 5000 requests for the propagation buffer.
33
About mcell.dir, the cell directory file
If the cell cannot propagate events, the cell stores the events to be propagated in the destination buffers and the requests for propagation of those events in the propagation buffer. When the buffers become full, the cell automatically expands the buffer size by a specified percentage (10 percent, by default), unless the buffer has exceeded a maximum size. By default, the maximum buffer size is unlimited, although the practical limit of the buffer size is the amount of available memory. Once the maximum defined buffer size is reached, additional requests will fail. When automatic expansion occurs, an MC_CELL_RESOURCE_EXPANSION event is generated. An expanded buffer will contain free space after propagation has resumed. To free memory resources, the buffer will be reduced when it contains more than the specified amount of free space. Reduction will leave enough free space to avoid the need for an immediate expansion. The buffer will never be reduced below the specified minimum size. When the buffer is reduced, an MC_CELL_RESOURCE_ REDUCTION event is generated. Parameters controlling the buffer size are located in the mcell.conf file. For information on configuring these parameters, see Propagation parameters on page 288.

The mcell.dir file is created during product installation. It acts as the cell directory file, contains the list of cells, the BMC Impact Portal, Impact Administration Servers, and gateways known on a specific computer. Upon startup, the cell reads the mcell.dir file and associates itself with the appropriate name, encryption key (if encryption is enabled), address information, and port number. In addition, it reads this information for the other cells to which it connects and for the BMC Impact Portal. The mcell.dir file for a cell has an entry for each cell and the BMC Impact Portal to which the cell connect. Figure 3 shows the format of an entry. Figure 3 on page 34 shows an example mcell.dir entry. Figure 3 Format of an entry in the mcell.dir file
# ## One line per component : # <Type> <Name> <EncryptionKey> <IpAddress/Port> # <Type> = cell | gateway.type # # cell ComponentName # gateway.portal bip.fullyqualifiedHostName # admin ImpactAdministrationServerName
EncryptionKey EncryptionKey UserID/Password
Host/1828 Host/3783 Host/3084
34
Each parameter in the file is defined as follows:

Attribute Type Description type of component. It can be I cell BMC Impact Manager cell name I gateway.typeGateway of type type I gateway.jServer - predefined jServer gateway type I gateway.portal - BMC Impact Portal I admin - named Impact Administration Server (IAS) Name is an abstract name for the component. Component names are not case-sensitive and may be any alphanumeric string, including underscores (_). A Portal name is, by convention, the fully qualified host name of the Portal host, prefixed with bip. EncryptionKey String to be used as part of the key for the encryption of the communication between a cell and the component. Default value is 0 (zero). Note: If the string has an odd number of characters, the last character is ignored. For an IAS component, the string must have the form UserID/Password, or be 0. If the value is non-zero, the indicated UserId and Password are used as IAS login credentials. IPAddress/Port Host name or IP address and port number on which the component is listening. Default port number for a cell is 1828 and for a Portal is 3783.
Name
Example of the mcell.dir file

Figure 4 shows an example of the mcell.dir file with typical component entries. Figure 4 Example of the mcell.dir file and its entries
# ## One line per component : # <Type> <Name> <EncryptionKey> <IpAddress/Port> # <Type> = cell | gateway.type # cell bos-71 mc cell local mc gateway.portal bip.bos-71.amc.com mc admin ias1 Mac/FreeAI1 cell sim1 mc
bos-71/1828 127.0.0.1/1828 bos-71/3783 bos-71/3084 pprod001:1828 bprod001:1828
Conventions for mcell.dir file entries

The following conventions apply when creating entries for the mcell.dir file:
I
Cells may be grouped into separate cell files readable only by certain users or groups (domains).
35
Configuring passive connections
A cell must be configured to communicate with, at a minimum, the cells to which it propagates events. A cell does not need to be configured to communicate with the cell from which it receives events, even for backward propagation. The mcell.dir file may define any number of entries, but each entry must be on a separate line. You can place mcell.dir files on remote mountable partitions or distribute them using rdist, tftp, or any other distribution mechanism.
Configuring passive connections

If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone. To connect to the cell, the client issues a passive connection; that is, it waits until the cell establishes the connection to the client.
NOTE
A passive connection is only possible with the server type clients, such as the cell and gateway clients.
Configuring the client for passive connections

On the client side, the mcell.dir file has to indicate that the destination cell is located in an isolated protected zone.
To configure the client for passive connections 1 Open the mcell.dir file in a text editor.
2 For the destination cell, replace Host:Port with 0 as shown in Figure 5.

Figure 5
cell
Passive connection format

cellName EncryptionKey 0
3 Save the changes. 4 Either reload the cell configuration or stop and start the cell.
36
Configuring slots for time stamping
When a cell or gateway client needs to connect to an isolated destination cell, it cannot establish a connection because it does not have the IP address and port number of the cell. Instead, the cell or gateway client registers the destination and waits for a connection from it.
Configuring a cell for passive connections

On the cell side, an indication is needed that a client could be waiting on a connection.
To configure a cell for passive connections

To configure a cell for passive connection, you must create a data object and specify how to control it, as shown in Figure 6. Figure 6 Data object specification
MC_CELL_PASSIVE_CLIENT ISA MC_CELL_HEARTBEAT ; END
The cell slot, as defined in the MC_CELL_HEARTBEAT superclass, gives the name of the passive client. The enable slot in the superclass specifies whether or not monitoring and reconnection is enabled. The cell attempts to connect to passive client targets as configured with the standard connection parameters. As soon as a connection is established, the connection is reversed. At that moment, the client takes up the connection and behaves as an ordinary client.
Monitoring passive targets

The cell may not be aware that a connection has been terminated when a connection from a passive client to a cell is terminated. The passive client cannot try to reestablish the connection, nor can it signal the cell to reestablish the connection. To avoid such situations, the cell monitors the passive client, based on the standard heartbeat monitor mechanism. Then, when a disconnect is detected, the cell attempts to connect to the passive client target.
Configuring slots for time stamping

Each event has an mc_modification_date slot that contains the time stamp of the last modification of the event. Only select slot modifications set this time stamp. To add a time stamp to a slot so that the date and time is recorded when the slot is changed, you must configure the mcell.modify file. The mcell.modify file contains the names of the slots that affect the mc_modification_date slot. When one of the slots listed in the mcell.modify file is modified, the mc_modification_date slot is set with the time stamp of this change.
37
Configuring encryption
To configure slots for time stamping 1 Open the mcell.modify file in a text editor.
2 Create a line entry containing the name of the slot whose modification is to be time
stamped. Figure 7 shows an example of the mcell.modify file. Figure 7 mcell.modify file
# Configuration of slots affecting mc_modification_date when modified # Format : # SlotName # Special name : CLASS : specifies all class-specific slots status severity mc_priority repeat_count CLASS
When CLASS is used as a slot name, all class-specific slots or slots not defined in the base class CORE_EVENT update the mc_modification_date slot with a time stamp.
3 Save the changes. 4 Either reload the cell configuration or stop and start the cell.
You can encrypt communication among the various BMC Impact Solutions components. To enable encryption, make the appropriate settings in the following locations:
I I I I
the cells configuration file mcell.conf the CLI configuration file mclient.conf the BMC Impact Administration server used by BMC Impact Explorer the cell directory file, which is MCELL_HOME\etc\mcell.dir by default
38
mcell.conf file settings that control encryption

The primary settings controlling encryption are in the cell configuration file mcell.conf. The following settings control encryption:
I I I
Encryption ForceEncryption EncryptionKey
If Encryption is set to Yes, encrypted communication to and from the cell is enabled, but not required. For example, if a BMC Impact Explorer does not have encryption enabled, then the communication with that particular BMC Impact Explorer console is not encrypted.
ForceEncryption requires encryption for all communications. If the BMC Impact Explorer attempts an unencrypted connection to the cell, the connection is rejected.
The encryption process uses the EncryptionKey value as part of the encoding key. If there is no encryption, the EncryptionKey value has no effect.
mclient.conf file settings that control encryption

All CLIs can use an mclient.conf file to determine encryption functionality. The parameters are
I I
Encryption EncryptionKey
For more information about the CLI configuration parameters, see BMC Impact Manager CLI configuration on page 269.
mcell.dir file settings that control encryption

The mcell.dir file contains a field for an EncryptionKey. At installation, the default EncryptionKey value is set to mc. BMC Software recommends that you modify the value for security. The string specified as the encryption key is transformed to a binary value as follows:
I
Characters of the encryption key are grouped in pairs. If the string has an odd number of characters, the last character is ignored. Each pair is converted to an 8-bit value. The first character of the pair determines the four most significant bits, the second character determines the four least significant bits.
39
A character in the hexadecimal range (0-9, A-F, a-f) is converted to the corresponding hexadecimal value (for example, 8 gives the value 8, B gives the value 11). Any other character is converted to its ASCII code modulo 16.
Encryption behavior between cells and components

This section describes the encryption behavior of cells and components during communication. The following actions occur when a BMC Impact Solutions component initiates communication with a cell: 1. The component scans the cell configuration file, mcell.dir, for that cells connection information. 2. BMC Impact Explorer retrieves the cells connection information from the BMC Impact Administration server. 3. The component opens a connection to the cell. If the cell has Encryption=yes, the component can use encrypted or non-encrypted communication. The component must use encrypted communication if the cell has ForceEncryption=yes and Encryption=yes. If the communication is encrypted, both the cell and the component must use the same EncryptionKey values to establish communication.
Information retrieval
A component must have the address and port of a cell to establish communications with it. To establish encrypted communications, the component must also have the encryption key of the cell. BMC Impact Explorer and the CLI commands determine the information in different ways:
I
BMC Impact Explorer acquires the information from the BMC Impact Administration server (cell_info.list). BMC Impact CLI commands obtain the information by determining the server location using one of the following methods: directly from the CLI command from CLI configuration parameters in mclient.conf from mcell.dir if you use the -n cellName option
40
Default values
The default value for cellName is the name of the host (hostName). The default value for the port is 1828. When the mcell.dir file is present, the default value is EncryptionKey=mc at installation. BMC Software recommends that you modify this value for security. If the mcell.dir file is absent on the host and you do not specify an encryption key, the CLI command uses 0 (zero) as the default value for EncryptionKey. This value enables encrypted communications.
NOTE
You can disable encryption by setting the configuration parameter to Encryption=No. You might want to use this setting to disable encryption while tracing.
Mandatory key specification conditions

You must specify the encryption key if the following conditions apply:
I I
you execute the CLI command on a host without an mcell.dir file the cell has an encryption key other than 0 (zero)
These conditions apply with the default installation. However, if the mcell.dir file is present on the host, and the file specifies the encryption key, you are only required to specify the cellName.
Limiting cell access

A client is allowed to connect to the cell if its IP address matches the general AllowConnectionFrom as well as the client type-specific Allow*From. Figure 8 shows an example of masking syntax. Figure 8 Masking syntax
AddrMaskList = AddrMask {':' AddrMask} AddrMask = Addr ['/' Mask] Addr = Nr '.' [Nr '.' [Nr '.' [Nr]]] Mask = Addr | Nr Nr = 0..255
41
The following conventions apply:

I I I I
An abbreviated Addr or Mask is expanded with zeros. A numeric Mask (number without trailing dot) gives the number of 1 bit. An omitted Mask defaults to all bits set to 1. A connection is allowed if the source address ANDed with the Mask matches Addr ANDed with the Mask.
When the Mask is all zeros, any address matches regardless of the value of Addr. For all Mask bits whose value is one (1), the equivalent bits in Addr must match the equivalent bits in the source address. Table 5 lists the IP address parameters. Table 5
Parameter AllowConnectionFrom=0./0
IP Address parameters
Description all systems allowed (same as 0.0.0.0/0)
AllowConnectionFrom=0./32
no system allowed (00.00.00.00 is not a valid IP address)
AllowConnectionFrom=198.12./255.255.
any system from the 198.12.xx.xx network can connect
AllowConnectionFrom=127.0.0.1/1
allows any host with an IP address lower than 128.0.0.0, because it indicates there is only 1 bit in the mask Only the highest-order bit is considered and must be the same as 127, which is a 0 bit.
AllowConnectionFrom=198.12.33./ 255.255.255.:198.12.92./255.255.255.
systems on the 198.12.33.xx and 198.12.92.xx networks may connect
The default is 0./0, indicating that the server should accept connections from any source. Usually this is useful only for testing or debugging, or for use with a system that is isolated from the network. To specify one single address, specify the address without a mask, or use a 32-bit mask. The following examples are equivalent ways of specifying a single address:
I I I
127.0.0.1 127.0.0.1/32 127.0.0.1/255.255.255.255
42
Reloading cell configuration
When you specify more than one address per mask pair, a system that matches at least one of the pairs can accept a connection.
Connection attempt using invalid encryption key

An attempt to connect to a cell using an invalid encryption key or from an disallowed address generates an internal event MC_CELL_UNALLOWED_CONNECT. This event contains a slot, reason, that includes the reason for the refused connection.

The cell does not automatically reconfigure itself, but you can customize and reload the configuration after you have made configuration changes without restarting the cell.
To reload cell configuration

To trigger the reconfiguration, perform one of the following actions:
I
Send a hang-up signal on UNIX. Run the mcontrol command on UNIX or Windows. For information about the mcontrol command, see mcontrolPerforming cell control operations on page 228.
Table 6 lists the specific instances in which the reconfigure feature can be used and the effect that results from its use. Table 6
Type cell directory
Files for cell reconfiguration (part 1 of 2)

Name/Directory mcell.dira Result of reconfiguration This internal directory is replaced with new contents from the mcell.dir file. Associated data objects are replaced as well. Connected clients and destinations remain connected, even if the corresponding directory entries are modified. Tracing is adapted and has the same effect as through the mcfgtrace CLI. The cell restarts automatically.
cell tracing cell configuration
mcell.tracea mcell.conf mcell.propagate mcell.modify kb\collectors
KB collector
The cell restarts automatically.
43
Managing high availability cell servers
Table 6
Type
Files for cell reconfiguration (part 2 of 2)

Name/Directory kb\classes \kb\rules \kb\lib \kb\bin Result of reconfiguration The cell restarts automatically.
KB program
KB data
a
kb\data \kb\records
The cell restarts automatically.
For mcell.dir and mcell.trace, a hang-up signal on a UNIX platform performs maximum reconfiguration without a cell restart. For information about restarting a cell, see Interpreting cell execution failure codes on page 56.
Managing high availability cell servers

If you have installed and configured primary and secondary cell servers as described in the BMC Impact Solutions Installation Guide and the BMC Impact Solutions Getting Started Guide, you may need some of the following advanced procedures to manage your high availability environment.
WARNING
The primary and secondary servers of a high availability pair must run on two different logical OS images of the same type. Primary and secondary servers of a high availability pair running on the same system or running on different operating systems is not supported.
The highest possible availability for a cell occurs when two server machines are close to each other with a highly reliable network connection. When the two server machines are on remote sites, the high availability cell functions more like a Disaster Recovery system. Only one of the two servers should be active at any time.
WARNING
It is highly recommended that you disable automatic failover and enable manual failover when the connection between the primary and secondary server is unreliable. Otherwise, there is a risk that both primary and secondary servers would be active at the same time when they cannot communicate with each other, due to network problems. Although it is technically possible to activate both servers, this is not supported. If both servers are activated, incompatible server states can occur. If the server states are incompatible, manual intervention is required to re-synchronize the primary and secondary servers. If this situation occurs, see Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized. on page 63.
44
Automatic failover process
WARNING
It is highly recommended that you disable automatic failover and enable manual failover when the connection between the primary and secondary server is unreliable. Otherwise, there is a risk that both primary and secondary servers would be active at the same time when they cannot communicate with each other. This situation is not supported. If this situation occurs, see Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized. on page 63.
Automatic failover process

If a high availability cell is configured with CellDuplicateAutoFailOver=Yes, it will automatically perform a failover when needed. Failover occurs when the secondary server loses its connection with the primary. If it cannot connect to the primary server within the time period specified in the CellDuplicateFailOverTimeOut parameter, the secondary server assumes that the primary server is no longer available and becomes active. The CellDuplicateFailOverStartTimeOut parameter specifies the period after startup after which the secondary server will become active when it has no connection with the primary server. This parameter should be set high enough to allow primary and secondary servers to be started at more or less the same time. Although you can start the secondary server before the primary server, if the secondary server is started first, it cannot connect to the primary server. Therefore, the value of the CellDuplicateFailOverStartTimeOut parameter should be set so that there is enough time for the primary server to start.
Automatic switchback process

If a high availability cell is configured with CellDuplicateAutoSwitchBack=Yes, it automatically performs a switchback when the primary server starts. When the primary server is started, it connects to the secondary server and determines its activity level. If the secondary is active, the switchback procedure is started. The secondary server switches to standby mode and transmits its state to the primary server. Once the primary server has determined that the secondary server is in standby mode, the primary server restarts itself and reloads the state that it received from the secondary server.
45
Manually failing over to the secondary server
Manually failing over to the secondary server

If there is a problem with the primary server, a failover to the secondary server is required. By default, failover is automatic; however, if the cell is configured with CellDuplicateAutoFailOver=No, this failover must be performed manually.
To manually fail over from a primary server to a secondary server 1 Terminate the primary server (if it is still running) by entering: mkill -n
CellName#1
WARNING
You must explicitly include the #1 suffix after the cell name or the mkill command will terminate the secondary cell if the command cannot connect to the primary cell.
2 Start the secondary cell server by entering: mcontrol -n CellName#2 start
Manually switching back to the secondary server

After a primary cell server has been repaired, a switchback operation is required to re-activate it. By default, switchback is automatic; however, if the cell is configured with CellDuplicateAutoSwitchBack=No, switchback must be performed manually.
To manually switch back from a secondary server to a primary server 1 Clear the primary server log directory by entering the appropriate command for
your operating system:
I I
For UNIX, enter: rm -f $MCELL_HOME/log/CellName#1/* For Windows, enter: del /f /s /q %MCELL_HOME%\log\CellName\*
2 Switch the secondary server to standby mode by entering:

mcontrol -n CellName#2 standby
3 Transfer the state file from the secondary to the primary server:
I
On UNIX, copy host2:$MCELL_HOME/log/CellName#2/mcdb to

host1:$MCELL_HOME/log/CellName#1/mcdb
On Windows, copy host2:%MCELL_HOME%\log\CellName#2\mcdb to

host1:%MCELL_HOME%\log\CellName#1\mcdb
4 Start the primary cell server.

Explicitly connecting a CLI to a selected high availability cell server
Explicitly connecting a CLI to a selected high availability cell server

A CLI will automatically connect to the primary cell server. If the primary cell server is not active, the CLI connects to the secondary server. It is possible to connect a CLI explicitly to either the primary or the secondary server, using the common CLI -n option. One method is to indicate the host and port of the desired server explicitly. For example:
mgetinfo -n host2/port2 -v activity
This example retrieves the activity level of the secondary cell server. Another method is to enter the cell name, followed by # and the server number (1 for primary and 2 for secondary). For example:
mgetinfo -n CellName#2 -v activity
Monitoring event performance

Event processing metrics are internal counts maintained on cell performance categories in connection with event processing. These metrics count the following items:
I I I I I I
number of events received, including erroneous ones number of events containing errors number of events dropped by rules (Filter, Regulate) number of events removed from the event repository during cleanup number of events propagated, including sendto number of events added to the event repository, that is, entering the permanent context
Calculation is performed on a 60-second basis, so every minute the counters are restarted. Counts from the last five minutes are retained. Running counters are reset only on demand.
47
Monitoring event performance
The resulting metrics are:

I I I
short termtotal count of the last complete one-minute interval medium termsum of the five last, completed one-minute intervals long termrunning total
Metrics are stored in MC_CELL_METRIC data objects, one object instance for each metric. Each metric mentions the subject. For each of the short-, medium-, and longterm results, it contains the length of the interval, in seconds, and the total count. An average per second is also provided, rounded to an integer. Other averages per second, minute, or hour can be calculated by the application from this information, if needed. A configuration parameter, CellMetricsEnabled, determines whether metrics are collected or not. The mcontrol CLI is used to switch metric collection on and off, and to reset the counters. Short- and medium-term metrics are reset whenever metrics are disabled. Metrics can be retrieved through rules by data object access, or through a command. The BMC Impact Explorer console and the mgetinfo CLI can use that command. The received event counter does not include incoming messages that cannot be parsed as events. It does include events of nonexistent classes or events with erroneous slots. These are added to the erroneous event counter. Internally generated events are counted as received events. Dropped events include those that are dropped when an event with the same universal ID exists. Table 7 lists the metrics data objects MC_CELL_METRIC slots. Table 7
Slot description long_average long_interval long_total medium_average medium_interval medium_total short_average short_interval short_total subject
MC_CELL_METRIC slots
Description metric description long-term average, per second long-term interval lengths, in seconds long-term total count medium-term average, per second medium-term interval lengths, in seconds medium-term total count short-term average, per second short-term interval lengths, in seconds short-term total count metric subject name
Subject names available are:
48
Monitoring client to cell interactions
ReceivedEvents ErrorEvents DroppedEvents StoredEvents RemovedEvents PropagatedEvents
CLI commands for collecting metrics are:

mcontrol metrics on|off|reset mgetinfo [-v] metrics
Monitoring client to cell interactions

Whenever a client connects, disconnects, or modifies an event, the cell generates an internal event to represent this operation. Such events are only generated for certain clients configured by means of the ReportConnectClients and ReportModifyClients settings. The parameter value is interpreted from left to right. Settings that conflict with previous settings override the previous ones. Table 8 lists the defaults for these two parameters. Table 8
Parameter ReportConnectClients ReportModifyClients
Default values for client parameters

Value browser, Console, mcontrol, mkill, mposter, msetmsg, msetrec mposter, msetmsg, msetrec
Every parameter corresponds to a reporting clients set. Such a set has a positive and a negative list. Clients that belong to the positive list will have their operation reported while operations performed by clients on the negative list will not be reported. Clients that are not named in the parameter are considered to be on the default list. The default list initially is the negative list. The default list can be modified through a special setting of the parameter. A value for a reporting configuration parameter consists of a comma separated sequence of client names. Every client name can be prefixed with a minus sign (-) or a plus sign (+). The client name prefixed with the minus sign (-) is added to the negative list. When not prefixed, or prefixed with a plus sign (+), it is added to the positive list.
49
Configuring cell tracing
The special value ALL in place of a client name refers to the default. Including ALL or +ALL modifies the default list so it becomes the positive list. With -ALL, the default list is the negative list. Both parameters could include -ALL, as this is the default setting for clients that are not explicitly mentioned. The superclass for client operation related events is MC_CELL_CLIENT. Table 9 lists the slots. Table 9
Slot client_location client_name client_type
MC_CELL_CLIENT slots
Data the location of the client as IPAddress:Port the client's name, as announced by the client, or noname type of client, such as adapter, CLI, console, cell
There are three subclasses of this class:

I
MC_CELL_ALLOWED_CONNECT to represent successful client connection MC_CELL_UNALLOWED_CONNECT to represent a refused connection
An attempt to connect using an invalid encryption key generates an internal event, MC_CELL_UNALLOWED_CONNECT, that contains the slot reason, which details why the connection is refused.
I
MC_CELL_DISCONNECT to represent a disconnect.
Another class, MC_CELL_MODIFIED_EVENT, represents the operation of modification of an event. Table 10 lists the slots. Table 10
Slot event requestor
MC_CELL_MODIFIED_EVENT slots
Data universal event ID of the event being modified identification of the user that performed the modification
Configuring cell tracing

To set up cell tracing, configure
I I
the trace configuration file, mcell.trace tracing parameters in the mcell.conf configuration file
You can also configure cell tracing using the mcfgtrace command. For further information, see mcfgtraceConfiguring tracing on page 218.
Configuring mcell.trace
Configuring mcell.trace
The trace configuration file, mcell.trace, configures the tracing of the cells operation. Tracing messages are divided in several levels. Every module of the cell can be configured differently. An output destination can be determined per message level and per module. Messages also can be disabled at the same granularity. The default location is MCELL_HOME\etc. The configuration commands in mcell.trace are incremental. Every new command adds to the configuration, possibly overriding previous commands either completely or partly. Figure 9 shows the format of a configuration line in the mcell.trace file.
.
Figure 9
<Module> SWITCH
Format of configuration line in mcell.trace file

<Level> <Switch> <Destination> <Destination>
Table 11 lists the parameters that must be defined in a configuration line. Table 11
Parameter Destination
Trace configuration file parameters (part 1 of 2)

Description destination file name or predefined value for the selected trace messages or switch predefined values: nodisables these tracing messages consolesends to the console device stderrsends to standard error stream
Levela
message severity value level predefined values:

I I I
FATAL ERROR WARNING
I I
INFORM VERBOSE
51
Configuring a destination for cell trace output
Table 11
Parameter Modulea
Trace configuration file parameters (part 2 of 2)

Description name of module, each of which corresponds to a particular category of information, such as filtering or configuration; values are as follows:
I I I I I I I I I I I I I
ACTION COLLECT COLLMAP CONFIG CONTROL DATAPROC DBDATAID DBEVTID DBEVTTM EVTLOG EVTPROC EXPORT FILTER
I I I I I I I I I I I I
HEARTBEAT INTEVT MC2TEC MCBAROC MESSAGES METRIC PROPAGATE QUERY RECOVERY RECTRL REGEX REGULATE
RESULT ROLES RULES SERVICE SRVMGT STATBLD SVCMGT SVRCOMM SVRDIR SYNCH SYSPROC TRACE
SWITCH Switch
a
keyword that enables access to a sublevel or category of messages for a module switch name
You can also specify ALL or * (wildcard) for these parameters.
Configuring a destination for cell trace output

You can use the tracing parameters to configure the cell to output information to a specified destination. The destination for cell trace output is determined by the value of the DESTINATION parameter in the mcell.trace file. Possible destinations for cell trace output are:
I I I I
the console the standard error stream an external file or files no trace output
In addition to sending trace output to one of these destinations, you also can send trace output to another cell. For information, see Sending trace output to another cell on page 53.
Sending trace output to a console

To send trace output to a console, open the mcell.trace file and set the DESTINATION parameter to the value console.
52
Sending trace output to another cell
Sending trace output to the standard error stream

To send trace output to the standard error stream of the command window where the cell is running, open the mcell.trace file and set the DESTINATION parameter to the value stderr. If the cell runs as a service or daemon, all trace output that is configured to go to stderr will be redirected to the file specified in the TraceDefaultFileName parameter in the mcell.conf file. If you specify for the trace output to go to stderr, the trace file is truncated every time the cell restarts, and a new trace file is written.
Sending trace output to an external file

To send trace output to an external file or files, open the mcell.trace file and set the DESTINATION parameter to the path and file name of the destination file. The cell keeps the trace file open on both UNIX and Windows systems. On UNIX, any attempt to remove the file will succeed. However, all trace output goes to an invisible file that becomes visible when the cell is restarted. A trace destination file can be located anywhere, but the BMC Impact Solutions process must have write access to that location.
WARNING
The MCELL_HOME\tmp\cellName directory is for temporary files only. A trace file placed in that directory will be deleted by the cell when it restarts. To maintain your trace file across cell sessions, place it in a different directory.
Disabling trace output

To disable trace output, open the mcell.trace file and set the DESTINATION parameter to the value no.

Sending trace output to a cell allows you to capture the traces of one or more cells in a centralized location. To send the trace of one cell to another cell, the trace of the originating cell should be produced as events. Those events can be sent to the destination cell using a propagate rule.
53
To enable sending cell trace information to another cell, you must

I
configure which module/level combinations of trace messages will be produced as events add a propagate rule to the Knowledge Base to specify which trace log events have to be propagated to which destination(s)
Once configured, the cell trace module will generate an internal event for each trace log message.
Definition of the class of trace log events

Each trace message is represented through a single MC_CELL_LOG_MSG event, as shown:
ENUMERATION MC_LOG_LEVEL 10 VERBOSE 20 INFORM 30 WARNING 40 ERROR 50 FATAL END MC_EV_CLASS: MC_CELL_LOG_MSG ISA MC_CELL_CONTROL DEFINES { log_time: INTEGER; -- Timestamp log_program: STRING; -- Name of the program generating the message log_module: STRING; -- Name of the module producing the message log_level: MC_LOG_LEVEL; -- Message level log_src_file: STRING; -- Source file name log_src_line: INTEGER; -- Source file line number log_msg_id: STRING; -- Unique message identifier (form BMC-IMCxxxxxxC) log_args: LIST_OF STRING; -- Message argument list log_text: STRING; -- Message text in origin's locale }; END
The log_time date and time slot is an integer in timestamp format. The textual representation of the log message log_text uses the originating cell's local message catalog.
54
Event processing errors
Configuring trace messages to be produced as log events

By default, a cell will not produce log events for its trace. This has to be enabled explicitly using the TraceEvents configuration parameter in the mcell.conf file. The value of this parameter is a comma-separated sequence of module:level combinations. Each one is optionally prefixed with a + or a - sign to indicate addition or removal, respectively, from the list. The special value ALL for module and for level indicate all modules and all levels. For example
TraceEvents=ALL:ALL,-ALL:VERBOSE
This setting specifies that events must be generated for messages from all modules, of all but the VERBOSE level.
WARNING
Event tracing should be configured with care, as it may produce an excessive number of events. In particular, VERBOSE level messages should not be configured as events.
For more information about the trace configuration parameters in mcell.conf, see Trace parameters on page 293.
Adding a propagate rule to the Knowledge Base to specify which trace log events have to be propagated to which destination(s)
The propagate rule syntax is described in the BMC Impact Solutions Knowledge Base Development Reference Guide. The following is an example of a propagate rule for trace log events:
propagate PropTraceEvents: MC_CELL_LOG_MSG to CentralAdminCell END
Event processing errors

When an error occurs during the processing of an event, the cells trace displays an error message. It also generates an internal event of class MC_CELL_PROCESS_ERROR, with the slots listed in Table 12.
55
Automatic notification of trace configuration changes
Table 12
Slot
MC_CELL_PROCESS_ERROR slots
Data the error number the part of the processing command that has the error an error description message the position in the rule source where the error occurred the mc_ueid of the event that was being processed
error_code error_goal error_message error_source event
Automatic notification of trace configuration changes

The cell automatically generates the following MC_CELL_LOG_CHANGED event when trace configuration is modified for a cell:
MC_EV_CLASS: MC_CELL_LOG_CHANGED ISA MC_CELL_CONTROL DEFINES { log_module: STRING; -- Name of the module log_level: MC_LOG_LEVEL; -- Message level log_destination: STRING; -- Destination file name }; END
If the modification applies to all modules, then log_module=ALL. If the modification applies to all message levels, then log_level=ALL. The log_destination slot contains the full path to the destination file, in normalized (UNIX) form. Other possible values are:
I I I
noindicates disabling stderrindicates redirection to the standard error stream consoleindicates redirection to the console terminal
Interpreting cell execution failure codes

When the cell runs as a daemon or a service, it has no standard output or error stream. Tracing that is configured to go to stderr will be redirected to a file in this case. The path for that file can be configured in mcell.conf. The default is MCELL_HOME\tmp\cellName\trace.
56
Interpreting cell execution failure codes
If the cell service setup fails, an error file, mcell.err, is generated. Additional service setup failures can be appended to the original file, resulting in a file content of multiple lines. Normally, each line corresponds to one failed service setup. This error file contains exit codes specific to BMC Impact Manager. Table 13 lists the exit codes for BMC Impact Manager. Table 13
Code 1 2 3 4 5 16 17 19 27 29 37 39 47 49 57 59 67 69 77 79 97
BMC Impact Manager exit codes

Description invalid command line options used bad home directory specification through option -l no home directory could be determined specified home directory is invalid internal initialization failure tracing configuration failed system process handling module initialization failure logging facility initialization failure service control module initialization failure Knowledge Base load failed message handling module initialization failure internal object initialization failure event processing module initialization failure saved state reload failed query handling module initialization failure service activation failed internal object module initialization failure metrics initialization failed data processing module initialization failure metrics activation failed service setup failed
57
Using the BMC IX Administration view to manage cells
Using the BMC IX Administration view to manage cells

You can also manage cells by using a pop-up menu in the navigation pane of the Administration view of BMC Impact Explorer to perform the following tasks:
I I I
connect and disconnect a cell view cell information register for state change events
For more information on using BMC Impact Explorer, see Chapter 6, Managing the BMC Impact Explorer (BMC IX) console and the BMC Impact Solutions Event Management Guide.
Connecting or disconnecting a cell

Use the Disconnect and Connect menu commands to connect or disconnect a cell from BMC Impact Explorer.
To connect or disconnect a cell 1 Right-click the cell icon or name. 2 Select Connect or Disconnect from the pop-up menu.
This menu item toggles between Connect and Disconnect, depending on the state of the cell when you right-click it. The result of your action in the Administration view is reflected in the Events and Services views.
Viewing cell information

Use the View Manager Info menu command to view information about and the metrics associated with the cell selected.
To view cell information 1 Right-click a cell. 2 Choose View Manager Info.
58
Registering for SIM notification events
The Impact Manager Info dialog box appears with cell property information presented on the Info tab.
3 To refresh the information in the Workload tab of this dialog box, click Refresh in
the top right corner of the tab.

BMC Impact Manager can generate events that notify you of changes to components in the SIM service model. These events are called SIM notification events. The four types of SIM notification events are
I I I I I
SIM_COMPONENT_CHANGE SIM_COMPONENT_DELETE SIM_COMPONENT_OVERWRITE SIM_RELATIONSHIP_CHANGE SIM_RELATIONSHIP_DELETE
NOTE
In the mc_sm_notify.baroc file under mcell_home/etc/cellName/kb/classes, you can view the definitions of the SIM_NOTIFICATION_EVENT base class and the event classes SIM_COMPONENT_CHANGE, SIM_COMPONENT_DELETE, SIM_COMPONENT_OVERWRITE, SIM_RELATIONSHIP_CHANGE, and SIM_RELATIONSHIP_DELETE.
The SIM_COMPONENT_DELETE and SIM_RELATIONSHIP_DELETE events are generated when you remove a configuration item or an impact relationship from the published service model. The SIM_COMPONENT_CHANGE and SIM_RELATIONSHIP_CHANGE events are generated when a configuration item or an impact relationship is altered by the cell because of a change in status or priority. BMC Impact Manager generates these notification events upon request by a client. For example, the BMC Impact Portal can register to receive notification events just as a gateway client can. Another BMC Impact Manager or even the BMC Impact Manager containing the SIM model can register to receive the notification events.
59
The following slots are reported:

I
Slots for configuration item: status manual_status computed_status self_status impact_status manual_status_comment manual_status_requestor consolidate_function root_causes schedule_status cost self_priority impact_priority computed_priority maintenance_mode
Slot for relationships: true_impact
To register for notification events, you create a SIM_NOTIFICATION_REGISTRY instance in the cell, telling it which notification events to look for and which clients to forward the events to. You perform this procedure through the BMC IX interface or through the mposter CLI.
NOTE
Refer to the BMC Impact Solutions: Knowledge Base Development Reference for mposter examples that show how to register for notification events.
To register for notification events in the BMC IX 1 In the Adminstration tab, expand the cell for which you want to create a
SIM_NOTIFICATION_REGISTRY data instance.
2 Expand the DATA folder. 3 Expand the MC_CELL_DATA folder.

4 Right-click SIM_NOTIFICATION_REGISTRY. 5 Select New. 6 Fill in the editable fields in the SIM_NOTIFICATION_REGISTRY dialog box.
Table 14
Field mc_udid client_data
SIM_NOTIFICATION_REGISTRY dialog box fields (part 1 of 2)

Description populated automatically
allows you to define a rule set for the SIM notification events that your client has registered for. For example, the rule could look for the text john in the client_data to determine if it is a state change requested by john.
The content of this slot is copied to the client_data slot of the corresponding SIM notification event. Each SIM_NOTIFICATION_REGISTRY data instance must have a different value for this slot. This slot is available only in BMC Impact Manager versions 7.0.x and later.
clients
comma-separated list of clients where the notification must be sent. The clients in the list must be defined in mcell.dir.
By default, the cell name is listed as the client in mcell.dir, so you do not need to change mcell.dir if you are sending events internally.
requested_notifications comma-separated list of SIM notification events for which notification is requested
I I I I I
SIM_COMPONENT_CHANGE SIM_COMPONENT_DELETE SIM_COMPONENT_OVERWRITE SIM_RELATIONSHIP_CHANGE SIM_RELATIONSHIP_DELETE
notification_mode
specifies how slot values that have not changed are reported in the SIM notification event
I
DELTA the slots whose values do not change are reported with their default values, not their current values. The default value is an empty string for symbolic values and -1 for numer ic values. See the .baroc class definition of the SIM notification event for the default slot values. FULL the current values of all slots are reported, including those that have not changed
61
Table 14
Field
SIM_NOTIFICATION_REGISTRY dialog box fields (part 2 of 2)

Description
notifications_at_registration instructs the cell whether or not to send the current component states at the moment of registration
I
YES instructs the cell to send the current component state at the moment of registration NO instructs the cell not to send the current component state at the moment of registration
asset_filter
filter contains one class name. When you specify a class name, only state change notifications for configuration items of this class or a sub-class are generated.
7 Click OK.
In the Administration tab, the new SIM_NOTIFICATION_REGISTRY instance is displayed under SIM_NOTIFICATION_REGISTRY.
To delete a SIM_NOTIFICATION_REGISTRY data instance 1 Right-click the SIM_NOTIFICATION_REGISTRY data instance. 2 Select Delete. To modify a SIM_NOTIFICATION_REGISTRY data instance 1 Right-click the SIM_NOTIFICATION_REGISTRY data instance. 2 Select Edit. 3 Make the necessary changes to the fields in the SIM_NOTIFICATION_REGISTRY
dialog box.
4 Click OK to accept the changes.
62
Trouble-shooting BMC Impact Manager
Trouble-shooting BMC Impact Manager

NOTE
If you are experiencing problems with BMC Impact Manager, you can turn on cell tracing to help diagnose the problem. For instructions, see Configuring cell tracing on page 50.
Problem: The cell will not start

If there is nothing in the log trace files to help you diagnose the problem, try running the cell in the foreground. This will frequently provide the information needed to correct the problem or enough information for BMC Support to diagnose the problem. To run the cell in the foreground, enter:
mcell n {cell_name} d
Possible solution: Delete the mcdb.0 and mcdb.lock files

It is possible that a statbld failure has occurred. To correct this problem, follow these steps:
1 Look for the following files in the MCELL_HOME\log\cellName directory:

I I
mcdb.0 mcdb.lock
2 If either or both of these files are present, delete them. 3 Restart the cell.
Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.
This problem can occur when the primary and secondary servers are running on a network that does not have a reliable connection, if you have started a high availability cell using any of the mcell -i initialization options (for example, -ia, -id or other variants), or if the primary server was started first and terminates before the secondary server is started.
63
Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are
Possible solution: Synchronize the mcdb and xact files of the primary and secondary servers
Follow these steps to correct the incompatible states between the primary and secondary servers:
1 If the problem was caused by an unreliable network, resolve the network issue. 2 Shut down both cell servers 3 Copy the mcdb and xact files of the preferred server to the other server. (The
preferred server can be either primary or secondary.)
4 Start the secondary cell server. 5 Start the primary cell server.
64
Chapter
2
66 66 66 70 70 70 71 71 71 72 72 72
Managing a Knowledge Base

This chapter describes how the Knowledge Base is organized and used in BMC Impact Manager. This chapter presents the following topics: Knowledge Base structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the unified Event Management and Service Impact Management Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Base index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating a unified KB with pre-7.2 cell definitions . . . . . . . . . . . . . . . . . . . . . . . Creating a new production or test Knowledge Basemcrtcell . . . . . . . . . . . . . . . Importing Knowledge Base information into a cellmkb . . . . . . . . . . . . . . . . . . . Compiling a Knowledge Basemccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading a Knowledge Base into a running cellmcontrol . . . . . . . . . . . . . . . . . . Implementing changes to a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Versioning a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2
65
Knowledge Base structure
Knowledge Base structure

The following sections explain the structure of the Knowledge Base (KB) and its directories.
About the unified Event Management and Service Impact Management Knowledge Base
For an overview of the unified template structure of the KB, see the BMC Impact Solutions Concepts Guide.
NOTE
The SIM code of the unified KB is active only if the cell is configured as a SIM cell and the ServiceModelEnabled parameter of the MCELL_HOME/etc/mcell.conf file is set to Yes. For additional information about the mcell.conf parameters, see Appendix B, mcell.conf file parameters. The Event Management-only KB, stored under MCELL_HOME/etc/default/EM/kb, remains for backward compatibility with versions of the mcrtcell CLI older than version 7.2.00. It contains the KB elements used by Event Management to process events.
When you create or install a new cell using the mcrtcell command, you always create or install a unified SIM KB in the newly-created cells KB directory path: MCELL_HOME/etc/CellName/kb. Modifications to the KB in the CellName/kb directory apply to the CellName cell only. If you modify the template KB in either MCELL_HOME\etc\default\SIM or MCELL_HOME\etc\default\EM any cell that you install or create will include those
modifications.
Knowledge Base directory structure

The Knowledge Base uses a defined directory structure to organize its files and executables. The Knowledge Base directories are in the following locations:
I
The Knowledge Base used by the cell during runtime is located in %MCELL_HOME%\etc\CellName\kb on Windows platforms and in $MCELL_HOME/etc/CellName/kb on UNIX platforms.
66
The template Knowledge Base resides in the MCELL_HOME\etc\default\SIM or MCELL_HOME\etc\default\EM directory. The Knowledge Base available (EM only or both EM and SIM) will depend on the type specified when the cell was created.
Cells are created during installation of a BMC Impact Manager instance or by using the mcrtcell command. For information about this command, see mcrtcell Creating a new cell on page 231.
NOTE
The environment variables created during installation that define paths to BMC Impact Manager configuration files and executables are listed in the BMC Impact Solutions Installation Guide.
Figure 10 lists the directory structure for a Knowledge Base. Figure 10

kb \bin \A \h1 \l2 \p4 \s5 \w4 \classes \collectors \data \lib \records \rules
In the Knowledge Base, each subdirectory is labeled to indicate the type of files or programs it stores, as listed in Table 15 on page 68.
Chapter 2
67
Table 15
Knowledge Base subdirectories (part 1 of 2)
Knowledge Base subdirectory Description bin stores the external scripts that can execute during rule processing and actions that can be run from BMC Impact Explorer The bin directory organizes the scripts and programs in subdirectories specific to the appropriate operating system, as follows:
I I I I I I
Aindependent, all UNIX, or non-Windows h1HP-UX l2 Linux p4 AIX s5 Solaris w4 Windows
The .load file in the bin directory specifies the order in which external scripts or programs are presented to clients. Actions are defined in .mrl files. There is one default file, .load, in the bin directory. Actions and their syntax are described in the BMC Impact Solutions Event Management Guide. classes stores event class, data class, and interface definitions Classes are stored in .baroc files. The .load file in the classes directory specifies the order in which classes are loaded. Parent classes must be loaded prior to child classes. Event and data classes are described in the BMC Impact Solutions Knowledge Base Development Reference Guide. collectors stores collector rule definitions Collector definitions are used to organize the event lists that are viewed in the BMC Impact Explorer console. Collector rules are defined in .mrl files. Collectors and their syntax are described in BMC Impact Solutions Event Management Guide. data instances of dynamic data stored in files that are loaded when the cell is initialized Dynamic data instances are stored in .baroc files. The .load file indicates the order in which the files are loaded into the cell. After the values are loaded into the cell any changes are maintained in the mcell.db. Dynamic data objects and their syntax are described in the BMC Impact Solutions Knowledge Base Development Reference Guide and in the BMC Impact Solutions Event Management Guide. lib stores primitives and functions used in the Knowledge Base For example, the SIM Knowledge Base contains the following files that cannot be modified:
I I
sim.wiccontains the compiled implementation of primitives and functions that are loaded by the cell at startup sim_decl.wiccontains the compiled definitions for primitives and functions; it is loaded by the compiler to compile rules that reference SIM primitives
For more information about functions and primitives, see the BMC Impact Solutions Knowledge Base Development Reference Guide. 68 BMC Impact Solutions Infrastructure Management Guide
Table 15
Knowledge Base subdirectories (part 2 of 2)
Knowledge Base subdirectory Description records stores global record definitions, which store dynamic information across all rule phases A global record stores persistent dynamic information in a .baroc file. Many rule processing phases use global records for retrieving dynamic information. The .load file indicates the order in which the files are loaded into the cell. The default copy of record definitions is stored in baroc files in the records directory. After the values are loaded they are maintained in the mcell.db. Dynamic data objects and their syntax are described in the BMC Impact Solutions Knowledge Base Development Reference Guide and in the BMC Impact Solutions Event Management Guide. rules stores the rule definitions for the Knowledge Base The source for rule definitions are the files with an .mrl extension. The compiled versions of rules are contained in files with the .wic or .pkg extension. The .load file indicates the order in which the rules are loaded into the cell. Rules and their syntax are described in the BMC Impact Solutions Knowledge Base Development Reference Guide and in the BMC Impact Solutions Event Management Guide.
Table 16 lists the file extensions and directory location for the each of the components contained in a KB. Table 16
Component event classes data classes data instances global records rules collectors action executables service model class definitions interface classes scripts and programs
Knowledge Base file extensions and directories

File extension .baroc .baroc .baroc .baroc .mrl .mrl .mrl .baroc .baroc not applicable Directory kb\classes kb\classes kb\data kb\records kb\rules kb\collector kb\bin kb\classes kb\classes kb\bin\platform
Chapter 2
69
Knowledge Base index files
Knowledge Base index files

The following files are included with the installation and are necessary for the Knowledge Base to run properly:
I
manifest.kbserves as an index file for the listed directories that compose the
Knowledge Base during compilation. This file is located in %MCELL_HOME%\etc\CellName\kb on Windows platforms and in $MCELL_HOME/etc/CellName/kb on UNIX platforms.
I
.loadserves as an index file for the individual files contained in the
corresponding subdirectory of the Knowledge Base directory structure. Load files are included in each subdirectory to determine load order for that particular directory. Files types within the .load file do not have extensions.
I
.loadwicBefore the compilation of the Knowledge Base, rules and collectors are created in .mrl files and are included in the .load files. After compilation, rule and collector files are stored in .wic files and a .loadwic file is created for the KB to use. The .wic files are machine-readable only.

To manage a Knowledge Base, you must perform several tasks by using the BMC Impact Manager command-line interface (CLI). This section briefly describes these tasks; for more information about syntax and options available for the CLI commands, see Appendix A, BMC SIM and EM CLI Reference.
NOTE
To protect the format of the default Knowledge Base, back it up prior to making any modifications. An adequate backup includes all directories and files in the kb directory or the directory where the changes occur. You can also use source-control programs such as CVS or Subversion to keep track of changes to the KB. Source control allows you to revert to older versions of the KB and to examine changes.
Integrating a unified KB with pre-7.2 cell definitions

In version 7.2.00, the unified Knowledge Base was introduced. You can integrate your cell definitions from cells older than version 7.2.00 with the unified KB of the current version of the cell.
70
Creating a new production or test Knowledge Basemcrtcell
1 Create a new cell using the mcrtcell CLI with either the -ae or -as option. 2 Copy the modifications or extensions youve made in old cells KB to the new cells
KB. To do so, you can manually edit the files or use your specific utilities.
3 Recompile the KB, and restart the cell.
Creating a new production or test Knowledge Basemcrtcell

Use the mcrtcell command to create a new production or test cell and Knowledge Base. The mcrtcell command can be run only on the local computer where the cell is being created. For more information about syntax and options available with mcrtcell, see Appendix A, BMC SIM and EM CLI Reference.
Importing Knowledge Base information into a cellmkb

You can use the mkb command to import an existing Knowledge Base. You can also use this command to import files containing definitions for event classes, interfaces, global records, data classes, collectors, or rules from an existing Knowledge Base. For more information about syntax and options available with mkb, see Appendix A, BMC SIM and EM CLI Reference.
NOTE
To use the mkb command to manipulate an existing KB, you must use the -f parameter to define the path to the manifest.kb file and specify the action that the mkb command should execute.
Compiling a Knowledge Basemccomp

Each time you change, add, or delete actions, classes, collectors, or rules, you must compile the KB. The cell recognizes changes to the KB only when the cell is restarted. Use the mccomp command to compile the Knowledge Base. The mccomp command parses event, data class and global records, and compiles the rules. For more information about syntax and options available with mccomp, see Appendix A, BMC SIM and EM CLI Reference.
Chapter 2
71
Loading a Knowledge Base into a running cellmcontrol
Effects of compiling a Knowledge Base with tracing enabled

If you enable tracing by using the -t option when compiling a KB and if TraceRuleToXact=Yes in mcell.conf, an event can be tracked in the transaction log, an .xact file, as it progresses through the rule execution. Entries in the log file related to rule tracing are include a TRCX header. However, deploying a KB compiled with the -t option can degrade performance by as much as 50 percent. BMC recommends that you do not use the -t option to compile the production KB.
NOTE
The TraceRuleLevel parameter in the mcell.conf file must be set to 2 for rules tracing to occur.
Loading a Knowledge Base into a running cellmcontrol

You must load a KB on a running cell each time that you edit collectors. Use the mcontrol reload kb command to reload the Knowledge Base while the cell is still running. For more information about the mcontrol command, see Appendix A, BMC SIM and EM CLI Reference..
Implementing changes to a Knowledge Base

You must stop and start the cell to implement any changes to a cells KB. For instructions on stopping and starting a cell, see the BMC Impact Solutions Getting Started Guide.
Versioning a Knowledge Base

KB versioning enables you to determine which KB and which version of the KB is loaded in a cell. You can implement version information for
I
KB source files For each KB source file that you specify, information about the source file is provided and the version of the compiler that was used to compile it. Logical KB modulesVersion information is provided for each logical module that you identify in the KB.
72
Versioning a Knowledge Base
A logical KB module is a collection of class definitions and rules that perform a specific task within the KB. For instance, all class definitions and rules that are related to Help Desk events could be called the HelpDesk KB module. A single KB can contain multiple such logical modules. The class definitions and rules that are not associated to a specific KB module are considered to be part of the global, unnamed KB module. If desired, you can make rules behave differently depending on the version of specific KB modules. This can be useful in patches, for example.
Enabling KB versioning
To enable versioning, you must create logical modules in the KB. To identify the files for a particular module, add the @kbversion annotation to the KB source files, using the following syntax:
@kbversion( [ ModuleName , ] VersionID )
Variable ModuleName
Description specifies the name of the module to which the current file belongs To indicate version information for the global module, either use the empty string as ModuleName or omit ModuleName.
VersionID
specifies the version (v.r.mm) For example, 1.2.10.
WARNING
Multiple @kbversion annotations for the same module will result in a compilation error. This also applies to a global version; only one annotation without a module name is allowed in a KB.
The mccomp command compiles the @kbversion annotations into the KB object files and includes the following information about each source file in the KB:
I I I I I I
release number of the compiler used to compile the file build number of the compiler used to compile the file build date of the compiler used to compile the file source file name source file size in bytes source file checksum
Chapter 2
73
Retrieving KB version information in rules
KB versioning example
@kbversion( HelpDesk , '1.2.01' )
This example specifies that the KB contains a logical module called HelpDesk, and that its version is 1.2.01.
Retrieving KB version information in rules

You can retrieve KB module version information in a rule by using the kbversion primitive. For information about the kbversion primitive, see the BMC Impact Solutions Knowledge Base Development Reference Guide.
Retrieving KB version information by using a command mgetinfo

You use the mgetinfo command with the kbmodules and kbsources arguments to retrieve version information from the cell's loaded KB.
mgetinfo -n cellName [-v] kbmodules|kbsources
Argument kbmodules kbsources
Returned results list of KB modules with version information list of KB source files with compiler version information
The information is displayed in raw format. You can use the -v switch to obtain the information in a more readable format. Figure 11 on page 75 shows a portion of the information returned from the kbsources argument.
74
Retrieving KB version information by using a commandmgetinfo
Figure 11
Output from mgetinfo kbsources argument
BMC Impact InfoRetrieval 7.3.00 (Build 1332814 - 27-Jan-2009) Copyright 1998-2009 BMC Software, Inc. as an unpublished work. All rights reserved. 7.3.00 1332814 27-Jan-2009 collectors/self_collector.mrl 329 215528602 7.3.00 1332814 27-Jan-2009 collectors/mc_bystatus_collectors.mrl 8682876756519 7.3.00 1332814 27-Jan-2009 collectors/mc_bylocation_collectors.mrl 2673155257002 7.3.00 1332814 27-Jan-2009 collectors/mc_evr_collectors.mrl 17193192677488 7.3.00 1332814 27-Jan-2009 collectors/bii4p_collectors.mrl 1861 72069569 7.3.00 1332814 27-Jan-2009 collectors/mc_sm_collectors.mrl 1351 3438665385 7.3.00 1332814 27-Jan-2009 collectors/catchall_collector.mrl 3813425794528 7.3.00 1332814 27-Jan-2009 rules/mc_startup.mrl 578 2337723164 7.3.00 1332814 27-Jan-2009 rules/im_internal.mrl 36351 4174289538 7.3.00 1332814 27-Jan-2009 rules/mc_intevt.mrl 3115 1930567566 7.3.00 1332814 27-Jan-2009 rules/mc_mccs.mrl 2296 2571308892 7.3.00 1332814 27-Jan-2009 rules/ips.mrl 2333 2499185120 7.3.00 1332814 27-Jan-2009 rules/mc_sm_start.mrl 1196 92543871 7.3.00 1332814 27-Jan-2009 rules/mc_sm_associate.mrl 3389 3376465454 7.3.00 1332814 27-Jan-2009 rules/mc_sm_maintenance.mrl 1885 797195742 7.3.00 1332814 27-Jan-2009 rules/mc_sm_elect.mrl 1055 4013285370 7.3.00 1332814 27-Jan-2009 rules/mc_sm_attach.mrl 1943 1558282738 7.3.00 1332814 27-Jan-2009 rules/mc_sm_shadow.mrl 3781 4283488066 7.3.00 1332814 27-Jan-2009 rules/mc_sm_slm.mrl 4512 1631402620 7.3.00 1332814 27-Jan-2009 rules/bii4p.mrl 10473 1881293223 7.3.00 1332814 27-Jan-2009 0 1073706332 7.3.00 1332814 27-Jan-2009 bin/mc_actions.mrl 1304 3908443203 7.3.00 1332814 27-Jan-2009 bin/im_operations.mrl 16424 2639831549 7.3.00 1332814 27-Jan-2009 bin/sim_operations.mrl 3992 3834546431
Chapter 2
75
Retrieving KB version information by using a commandmgetinfo
76
Chapter
Managing the BMC Impact Administration server

3
This chapter presents the following topics: Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 81 Guidelines for manual edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Defining permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Full Access role permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Adding customized role/permission mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 File-based authentication: updating user information. . . . . . . . . . . . . . . . . . . . . . . 91 Adding role names to the cells KB definition files . . . . . . . . . . . . . . . . . . . . . . . . . 93 Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . 93 Synchronizing cell information with BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . 95 Updating cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Defining client logging for the iadmin script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Customizing colors for severities, statuses, and priorities . . . . . . . . . . . . . . . . . . . 99 IAS Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Customizing the IAS thread pool handling IAS Clients . . . . . . . . . . . . . . . . . . . . 100 Defining standalone, primary, and secondary BMC Impact Administration servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Defining a failover configuration for the Impact Administration cell. . . . . . . . . 105 Transaction and trace logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Configuring BMC Impact Administration server to support remote actions . . 107 Configuring Lightweight Directory Access Protocol for BMC Impact Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Problem: Cell_info.list synchronization error during manual configuration of an IAS failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Chapter 3 Managing the BMC Impact Administration server
77
Configuration files
Configuration files
End users can configure the following IAS file listed in Table 17. These files are located under the IMPACT_SOLUTIONS_HOME/server/conf directory. Table 17
IAS file ias.properties
Configurable IAS files

Description contains required and optional configuration parameters for the IAS. This file is loaded whenever IAS starts or restarts. defines user information for file-based authentication defines LDAP server information for LDAP authentication enables you to add customized role/permission mappings contains the group/role mappings contains identifying information about each cell that is connected to the IAS specifies information for the IAS and BMC Atrium CMDB connection defines the logging properties for the server defines the logging properties for the client when you use the iadmin command defines different color properties for severity, status, and priority stores the authentication credentials used for remote execution actions defines LDAP server information used by IAS query option tlq defines the view and edit permissions for each tab view and menu option in BMC IX
user_definitions.xml ldap_configuration.xml role_permissions.xml group_roles.xml cell_info.list cmdb.properties server_logging.properties client_logging.properties color.properties credential_repository.xml ldap_configuration_query.xml default_role_permissions.xml
NOTE
The full path to the server directory under IMPACT_SOLUTIONS_HOME is /opt/bmc/Impact/server on UNIX and drive letter:\Program Files\BMC Software\Impact\server on MS Windows.
Command line interface

The IAS uses an iadmin command to launch the file management options. The iadmin script or command is located under the IMPACT_SOLUTIONS_HOME/server/bin directory.
78
Command line interface
You can use the iadmin command to manage the following configuration files:
I I I I I
user_definitions.xml group_roles.xml cell_info.list role_permissions.xml credential_repository.xml
Remember that you do not have to restart IAS to initialize your changes if you use the iadmin command. You can execute the iadmin command against an IAS on the local system. You cannot execute the iadmin command against an IAS on a remote system. The iadmin options are summarized below in Table 18 on page 79. You can display these options from the command line by entering iadmin -h. Table 18
Option -ac -mc -dc -lc -aru -mru -dru -lru -ar -dr -lr -mr -ag -dg -lg -mg -acr -mcr -dcr -lcr -cp
iadmin options (part 1 of 2)

Description add a cell to the cell_info.list file and register the cell with the BMC Impact Administration Server modify a cell delete a cell list connected cells add a new user modify the user group or groups to which an existing user belongs delete an existing user list all the users add a new mapping between a role and permissions delete an existing role/permissions mapping list all the roles modify the mapping between a role and a list of permissions add a new mapping between a group and a list of roles delete a group/role mapping for a specified group list all the groups modify the mapping between a group and a list of roles add a credential record to the credential_repository.xml modify a credential record delete a credential record list all credential records change the current password of an existing user. Requires that you enter the current password
79
Impact Administration cell
Table 18
Option -rp
iadmin options (part 2 of 2)

Description reset the password of an existing user. In this option, you enter the new password only. You do not enter the current password in a high availability setup, -reinit restarts the primary or secondary server with the latest configuration data. Use the [fullsync] option on the secondary server to copy the primary servers configuration to it and restart it with the new configuration. The [actions] option can reload the newly created remote actions defined in the .xml files in an high availability setup, synchronizes the secondary server before the expected synchronization interval returns the time required to execute an LDAP query. In addition, you choose to return a list of LDAP groups or to authenticate the LDAP user The CLI considers the LDAP configuration specified in the ldap_configuration_query.xml file in IAS. There is no need to restart the IAS after making changes to the ldap_configuration_query.xml file
-reinit [fullsync | actions]
-sync -tlq
NOTE
Refer to the BMC Impact Solutions Event Management Guide for a description of the -acr, -mcr, dcr, -lcr, and [actions] options in its discussion of remote execution.
When using iadmin to manage files, remember to:

I I I
enclose values within quotation marks if they contain spaces omit spaces in lists enclose password values within double quotation marks For example, if the password string is $able_baker, then enclose it within double quotation marks in the iadmin command string, as in the following excerpt:
password=$able_baker
I I
On Windows, execute the iadmin command from any path On Unix, set $MCELL_HOME environment using the command ./etc/mcell/setup_env.sh, then run the iadmin command from any path
Impact Administration cell

The default mcell.dir file of the IAC is as follows:
cell cell Admin IAC mc mc hostName:1827 hostName:1827
80
How to configure BMC Impact Administration server files
Admin is the default name of the Impact Administration cell. The default name is
provided at installation. It is the same name as the IAS instance name. Its default port number is 1827. You can change the default name of the IAC and the IAS instance name simultaneously during installation as an installation option. After installation, you can change the name of the IAC independent of the IAS instance name. You can change the default port number as long as the port number that you assign does not conflict with any other. IAC is the alias name that other cells use to propagate events to the Impact Administration cell. Each SIM or BEM cell that registers with an Impact Administration cell and a Master IAS should have an IAC entry in its mcell.dir file along with its own cell name, as in the following example:
cell cell cellName IAC mc mc hostName:1828 hostName:1827
How to configure BMC Impact Administration server files

This section describes the following configuration tasks:
Defining group roles and permissions Adding Impact Manager cells to the cell_info list Defining standalone, primary, and secondary BMC Impact Administration servers Defining HA configuration for Impact Administration cells Synchronizing cell information with BMC Atrium CMDB Receiving synchronized data from the BMC Portal Defining server-side logging levels Defining client-side logging levels Customizing the GUI color scheme for status, priority, and severity levels Setting LDAP authentication Configuring IAS to support remote actions Checking the time required to execute an LDAP query
Depending on the goal of the task, you may need to edit multiple files.
81
Guidelines for manual edits
Guidelines for manual edits

Use the iadmin script or command whenever possible. If you have to manually edit a file, follow these general steps:
1 Open the file in a text editor. 2 Make the changes in the proper format. 3 Save the file without changing its extension or file path. 4 Restart IAS. NOTE
When manually editing files to enable a high availability configuration, you must follow the special guidelines outlined in the topicDefining a failover configuration for the Impact Administration cell on page 105.
Users, groups, roles, and permissions

IAS supports a hierarchical classification scheme that defines the relation among permissions that are assigned to groups, which, in turn, are assigned roles. All of these elements are contained in user definitions. Figure 12 outlines this relationship: Figure 12 Relation among users, groups, roles, and permissions
You can create new users, groups, and roles. You cannot, however, create new permissions. You can only select from a predefined list of existing permissions.
Defining permissions
The default_role_permissions.xml file defines the view and edit permissions for each tab view and menu option in BMC IX. For each role, it lists the permissions in a comma-separated string as shown in the following extract for the Full Access role:
.... <properties> <entry key="Full Access">administration_tab_view_and_access, events_tab_view_and_access,services_tab_view_and_access, services_tab_access_component_event_list, events_tab_edit_drill_down,events_tab_edit_user_event_filter, events_tab_edit_user_slot_order, ..... </entry> .... </properties>
WARNING
Do not modify the default_role_permissions.xml file. Use the role_permissions.xml file instead.
Any permission that you add or modify must be taken from the predefined default_role_permissions.xml file. Table 19 on page 83 matches the default mapping of roles/permissions to BMC IX functionality. Table 19
Permission (P) or Right (R)
BMC Impact Explorer user group mapping to functionality (part 1 of 4)

Service Operator, Senior Service Manager, Senior
Service Administrator
Service Operator
Service Manager
Function Dashboards-Create, update, and delete all profiles Dashboards-Create and delete own profiles only Dashboards (SIEM) Edit
BMC Impact Explorer R X X X
Edit
View
Supervisors 83
Full Access
Read Only
Operators
Choices
Admins
Table 19

Service Operator
Service Manager
Function Dashboards (CIEM) Events tab ConfigurationEdit Relationship View ConfigurationEdit Personal Filters ConfigurationEdit Personal Attribute (Slot) Orders ConfigurationEdit Personal MetaCollectors ConfigurationEdit Global Event Filters ConfigurationEdit Global Attribute (Slot) Orders ConfigurationEdit Impact Manager Group on Impact Manager Configuration window Events tab-Show Impact Administration cell Events tabJump from an Event to Its Services Impacted View Events tabReopen Events
R R R R R
View View Edit Edit Edit
X X X X X
X X X X X
X X X X X
X X X X X
X X X X X
X X X X X
X X
X X X X X
X X X X X
X X X X X
Edit
R R
Edit Edit
X X
X X
X X
X X
X X
X X
Edit
Edit
Edit
Edit
84
Supervisors
Full Access
Read Only
Operators
Choices
Admins
Table 19

Service Operator
Service Manager
Function Events tabEvent Operation Supervisor Privileges (for example, close events owned by someone else) Events tabAssign Events Events tabAdd Image View Events tabDelete Image View Services tab Services tabSearch for Service Components Services tab-Create and delete components Services tabEvent List View of a Service Component Edit
R R R R R
Edit Edit Edit View Edit
X X X X X
X X X X X X X X X X X X X
X X X X X X
Edit
View
Services tabEdit My Edit Services Navigation Tree Services tab-Create, Edit, Delete Relationship between components Services tabSet or Remove Manual Status (of a component) Action Edit
Edit
Supervisors 85
Full Access
Read Only
Operators
Choices
Admins
Full Access role permissions
Table 19

Service Operator
Service Manager
Function Services tabSet or Clear Maintenance Mode (of a Component) Action Administration tab Timeframes Administration tab: all actions Edit
R R R R R
View Edit Edit
X X X X X
X X X X X
X X
X X
X X X X X
Infrastructure Edit Management subtab Infrastructure Edit Management subtab: all actions Alias Formula Editor Edit Remote Actions: Create remote actions Send Events to Cell Edit
R R
X X
X X
X X
R R
Edit
X X
X X
X X
Delete Events to Cell Edit
Full Access role permissions

Members of the Full Access user group can view, edit, and create all components and relationships, including the objects and relationships that were created by other users. Service Administrators, Service Managers - Senior, and Service Managers user groups can edit components and their associated relationships only if they already have write permission on the objects. If the user group member who creates a component does not specify otherwise, then the Read Users and Write Users slots of the component are populated by the user group of the BMC IX login account. To illustrate, if a user account belonging to the Service Administrators group creates a component, then by default its Read Users and Write Users slots are populated by the user group Service Administrators.
86
Supervisors
Full Access
Read Only
Operators
Choices
Admins
Adding customized role/permission mappings
Adding customized role/permission mappings

Use the role_permissions.xml file to add customized role/permission mappings. The com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file specifies this default file for containing customized role/permission mappings, as shown in the following excerpt:
com.bmc.sms.ixs.role.permission.mapping=role_permissions.xml
If you create a separate .xml file to contain your customized role/permission mappings, you must specify its name in the com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file. Then you must restart IAS to initialize the change. The user-defined .xml file does not override the default file. Its individual entries override matching ones in the default file. Any entries in the default file that are not overridden by matching ones in the user-defined file remain valid. When you use the iadmin script to add, modify, or delete a role/permission mapping, the change is saved to the role/permissions file specified by the com.bmc.sms.ixs.role.permission.mapping property.
To add a new role/mapping permission

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ar option, as in the following example:
iadmin -ar role=Test:permissions=services_tab_delete_component
To modify an existing role/mapping permission

You can modify the permissions associated with a role in a user-defined roles/permissions file. The modified entry is saved to the user-defined roles/permissions file, which overrides any corresponding role entry in the default file. From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mr option, as in the following example:
iadmin -mr role=Test:permissions=services_tab_view_and_access
87
Defining group roles
To delete an existing role/mapping permission

You can delete an existing role in a user-defined roles/permissions file.
NOTE
If the role to be deleted only exists in the default file, then an entry is added to the userdefined file. The entry contains the role name only, without any permissions associated with it. Because the user-defined entry overrides the default one, the role is effectively deleted.
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dr option, as in the following example:
iadmin -dr role=Test
The entry role=Test is written to the user-defined file and effectively overrides any identical role in the default file.
To list roles defined in roles/permissions mapping files

You can list all roles defined in both the default and in the user-defined roles/permissions mapping files. From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lr option, as in the following example:
iadmin -lr

The ias.properties file specifies the default group roles, which are identified in the group_roles.xml file:
com.bmc.sms.ixs.group.role.mapping=group_roles.xml
Default groups and user roles

IAS provides the following default groups and user roles, both of which are listed in Table 20. You can view these roles in the group_roles.xml file. Refer to Table 19 on page 83 for a complete listing of access permissions for group and role combination.
88
Table 20
Group Full Access Read Only
Groups and roles

Role Full Access. Has write access to all features Read Only. Has read-only access Service Administrators. Has write access to all features Service Managers Service Managers - Senior Service Operators Senior Service Operator Full Access, Service Administrators Service Operators, Senior Service Operators Service Manager, Senior Service Managers
Service Administrators Service Managers Service Managers - Senior Service Operators Service Operators - Senior Admins Operators Supervisors
NOTE
If you are using Lightweight Directory Access Protocol (LDAP) authentication, you must map your LDAP user groups to the IAS roles defined in the group_roles.xml file. See Configuring Lightweight Directory Access Protocol for BMC Impact Administration server on page 109 for more information.
You can update user groups and roles and create new ones by editing the group_roles.xml file, shown below:
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">  <properties> <entry key="Full Access">Full Access</entry> <entry key="Read Only">Read Only</entry> <entry key="Service Administrators">Service Administrators</entry> <entry key="Service Managers">Service Managers</entry> <entry key="Service Managers - Senior">Service Managers Senior</entry> <entry key="Service Operators">Service Operators</entry> <entry key="Service Operators - Senior">Service Operators Senior</entry> <entry key="Admins">Full Access,Service Administrators</entry> <entry key="Operators">Service Operators,Service Operators Senior</entry> <entry key="Supervisors">Service Managers - Senior,Service Operators - Senior</entry> </properties>
89
To add a new group with mapping roles NOTE

If youre adding a new role to the group, you must first create the role and add permissions to it using the iadmin -ar option before you create the group. See To add a new role/mapping permission on page 87.
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:
iadmin -ag group=NewGroup:roles=Role
To modify an existing group and/or mapping roles

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mg option, as in the following example:
iadmin -mg group=Service Administrators:roles=Service Administrators,Service Operators
Any roles that you add to a group must have already been defined in the
group_roles.xml file.
To delete an existing group

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dg option, as in the following example:
iadmin -dg group=Service Operators
You do not specify a role.
To list groups in the group_roles.xml file

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lg option, as in the following example:
iadmin -lg
90
File-based authentication: updating user information
To update user groups and roles (file editor) 1 Open the group_roles.xml file in an editor. 2 Update or delete the existing entries, or add a new entry where
I I
key is the name of the group
the values inside the <entry></entry> element are the roles
3 Save and close the group_roles.xml file. 4 Restart the IAS to initialize the changes.

You choose file-based authentication in test environments or in small production environments. Using file-based authentication, you can manage users of the BMC EM and SIM products independent of your corporate environment.
To enable file-based authentication 1 In the ias.properties file, ensure that the com.bmc.sms.ixs.enable.file.login
parameter is set equal to true.
2 In the user_definitions.xml file, define the users attributes. These include user id,
password, group names and their descriptions, and so forth. You can use the iadmin command to update user information in the
user_definitions.xml if you have enabled file-based authentication. You can add,
modify, or delete users, and you can modify the password of an existing user. The user_definitions.xml file defines a user ID, password, and group of a specified user, as in the default example below:
<?xml version="1.0" encoding="UTF-8"?> <userList xmlns="urn:bmc:schemas:impact" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:bmc:schemas:impact user_definitions.xsd "> <user userid="user"> <password encrypted="false">user</password> <groupList>Full Access</groupList> <description>This is optional</description> </user> </userList>
91
To add a user entry

When adding a user entry, enter a plain-text password with the <password encrypted> element set equal to false. When the file is initialized, the password becomes encrypted and the <password encrypted> element is changed to true. From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -aru option, as in the following example:
iadmin -aru loginId=qa:password=qa:usergroups=Full Access:description=Full Access User Group
NOTE
On UNIX platforms, execute the iadmin command that contains a password value without the bash shell.
To modify a user group of an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mru option, as in the following example:
iadmin -mru loginId=qa:usergroups=Read Only
To delete an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dru option, as in the following example:
iadmin -dru loginId=qa
To update the current password of an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -cp option, as in the following example:
iadmin -cp loginId=qa:oldPassword=qa:newPassword=bsm
To reset the current password of an existing user

When you reset a password, you do not specify the current password, only the new password.
92
Adding role names to the cells KB definition files
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -rp option, as in the following example:
iadmin -rp loginId=JoeUser:newPassword=bsm
To list all users in the user_definitions file

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lru option, as in the following example:
iadmin -lru
To change the current admin password

In the ias.properties file, type the new password in plain text format, as shown in the following example.
# admin password used internally for different components (such as BIP) talking to IAS com.bmc.sms.ixs.admin.password=e1KYemjVrpcnIw52M4m2tScjD3Yziba1JyMOd jOJtrUnIw52M4m2tScjDnYziba1JyMOdjOJtrUnIw52M4m2tQ== (encrypted) OR com.bmc.sms.ixs.admin.password=Nwadmpwd23
Adding role names to the cells KB definition files

After adding a new role name, you must add this role name to the cells KB definition files for the role to be effective. See To add the role name to the cells KB definition files on page 113 for more information.
Receiving synchronized data from the BMC Portal

BMC Portal 2.6.50 has a task named Synchronize Users with IAS. This a manual synchronization feature that pushes data one way from the BMC Portal to IAS. The synchronization is available in Standard and BMC Atrium installations.
93
Receiving synchronized data from the BMC Portal
The BMC Portal connects with IAS through IASs administrative account. The default password is IAS$Admin$. (There is no user name associated with administrative access.) During synchronization, only BMC Portal user groups that have defined permissions in BMC IX are exported. You can check for the permissions in the User Groups task off of the Configure tab in the BMC Portal. Look for permissions that begin Impact Explorer. BMC Portal groups are mapped to IAS roles with the same name. When a BMC Portal group is exported to IAS, a new role is created in IAS with the same name. To illustrate, if the BMC Portal group abc is exported to IAS, a role/permission mapping is created in IAS for abc and all the permissions that abc maps to in the BMC Portal. Then IAS creates a group/role mapping abc/abc. User passwords are not exported, but are set to the default value user. Any cells that are added to the BMC Portal are registered with IAS. For the Atrium installation scenario, BMC Atrium CMDB parameters are not synchronized with either the BMC Portal or IAS. They need to be added manually. In LDAP authentication, the IAS and BMC Portal connect separately to an LDAP server. The mappings of BMC Portal groups to LDAP group mappings are sent to IAS as group to role mappings. The BMC Portal uses the fully qualified distinguished name for an LDAP group (for example, ldapG1.bmc.com) while the IAS uses the common name (ldapG1). For example, if the BMC Portal group abc maps to several LDAP groupsfor example, ldapG1.bmc.com and ldapG2.bmc.comthen IAS creates the following group/role mappings: abc/abc, ldapG1/abc, and ldapG2/abc. To set up LDAP authentication in IAS, see Configuring Lightweight Directory Access Protocol for BMC Impact Administration server on page 109.
94
Synchronizing cell information with BMC Atrium CMDB
Synchronizing cell information with BMC Atrium CMDB

You can synchronize your cell information with the BMC Atrium CMDB by modifying the cmdb.properties, an excerpt of which is shown below:
...... # "true" if this IAS will synchronize with the CMDB server. com.bmc.sms.ixs.cmdb.enable.sync=false # host name for AR server com.bmc.sms.ixs.cmdb.host.name=localhost # port number for AR server com.bmc.sms.ixs.cmdb.port.number=0 # user id for AR server com.bmc.sms.ixs.cmdb.user.id=Demo # password for AR server com.bmc.sms.ixs.cmdb.password=
To synchronize with the BMC Atrium CMDB 1 Change the com.bmc.sms.ixs.cmdb.enable.sync property to true. 2 Enter the fully qualified domain name or the IP address of the host system where
the AR Server resides.
3 Enter the port number of the AR Server. If the AR Server is using portmapper, then
enter 0.
4 Enter the AR Server user Id that you use for accessing the BMC Atrium CMDB. 5 Enter the password in plain text. When IAS restarts, it encrypts the password and
displays the encryption in the file.
6 Restart the IAS.
95
Updating cell information

You can add cells to the IAS, modify cells, delete cells from the IAS, and list the cells that are currently registered with the IAS. This cell information is stored in the cell_info.list, an example of which is shown below:
cell test mc test.company.com:1828 Production * cell.Admin IAC mc localhost:1828 Production * cell.SIM qa mc qa.company.com:1828 qa.company.com:1888 Test "Full Access, Read Only"
Each cell entry contains the following information: Table 21

Entry cell
Cell entry format in cell_info.list

Description required. Each entry must begin with cell. The cell type is appended after cell, with a period separating cell and the type. The available cell types are SIM, BEM, and Admin. IAS retrieves the type from the cell and appends to the entry. matches the name in the mcell.dir file of the cell server. The default value is mc. system where the cell resides. It can be an unqualified or fully qualified host name, or an IP address. primary port number of the cell between 1000 - 65535. optional. If this is an HA pair, then enter the system name where the secondary cell resides. optional. If this is an HA pair, then enter the failover port number between 1000 - 65535 that the secondary cell uses. Production or Test. user group or groups who can access this cell. If all groups can access the cell, enter an asterisk. Otherwise enter the user group name, separating multiple groups with commas. If the group name contains a space, use double quotation marks to enclose the entire name.
name key primaryHost primaryPort failoverHost failoverPort environment usergroups
To add/register a cell
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ac option, as in the following example:
iadmin -ac name=testCell:key=mc:primaryHost=moondog:primaryPort=1828: failoverHost=suncat:failoverPort=1828:environment=Production:usergroups=*
96
The cell information is added to the cell_info.list. It is also added to the BMC Atrium CMDB if the cell is synchronized with BMC Atrium CMDB as defined in the cmdb.properties. To ensure that the cell is registered with the IAS, be sure that its mcell.dir file contains the IAC entry, as in the following example:
cell IAC mc myComputer.adprod.bmc.com:1827
The IAC entry enables event propagation between the cell and the Admin cell that is part of the IAS.
To modify a cell
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mc option. After you specify the cell name, you only to need to include the options that you are changing, as in the following example:
iadmin -mc name=testCell:failoverHost=null:environment=Test
In this example, the secondary cell is removed and thus failoverHost is defined by null. The environment is changed from Production to Test. If you were to change the primaryHost or primaryPort value, then IAS connects to the cell to retrieve its type. All updates are saved into the cell_info.list and to the BMC Atrium CMDB, if the cell is synchronized with the BMC Atrium CMDB.
To delete a cell
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dc option to delete a cell from the cell_info.list, as in the following example:
iadmin -dc name=testCell
If the cell is synchronized with the BMC Atrium CMDB, it is removed from the CMDB.
To list cells
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lc option, as in the following example:
iadmin -lc
97
Editing logging properties for IAS
Editing logging properties for IAS

IAS generates a default log file, ias<numeral>.log, under the IMPACT_SOLUTIONS_HOME/server/tmp/ias directory. This log file captures diagnostic trace messages generated by the servers activity. You can manually edit the
I I I I
logging level file name and path maximum size of each file number of log files in a cycle
This information defined in the server_logging.properties file describes the properties that you would typically modify: Table 22
Property .level
Server logging properties

Description message levels that the log captures. The default is INFO. The log ignores all levels lower than the specified one. The values range from SEVERE to FINEST.
java.util.logging.FileHandler.pattern specifies the file name, file path, and the generated numeral that distinguishes the log file cycle. The default pattern /tmp/ias/ias%g.log. java.util.logging.FileHandler.limit java.util.logging.FileHandler.count the maximum size of each log file in bytes. The default is 5 million bytes (about 5 MB). maximum number of log files in each cycle. The default is 10. After the maximum number of files is reached, a new cycle starts and the new log files override the existing ones in sequence.
After you make changes, save the server_logging.properties file, and restart IAS.
Defining client logging for the iadmin script

You can define the log message level that is directed to the command console when you execute the iadmin script. The default level is SEVERE, meaning that notices of only the most crucial changes are transmitted to the command console. All other notices are omitted. The client log information is defined in the client_logging.properties file. You can manually edit the log level by changing the value of the java.util.logging.ConsoleHandler.level property. All levels below the one you specified are omitted from the client log. After you make changes, save the client_logging.properties file.
98
Customizing colors for severities, statuses, and priorities
Customizing colors for severities, statuses, and priorities

You can modify the default colors that BMC IX uses in row backgrounds in tables to indicate event severities, service component statuses, and priority computation by changing the hexadecimal numbers that represent the amount of red, green, and blue (RGB) in the color. The default colors are defined in the color.properties file.
NOTE
These changes to the color properties do not affect the icon colors.
You should be consistent when changing the color values of the same parameter. For example, if you change the color for DOWN to indicate event severity, you should make the same change to the DOWN parameter for service component status. Otherwise, if you specify different colors, one color change overrides the other. After you make changes, save the color.properties file, and restart IAS.
IAS Status Monitoring

IAS Status Monitoring is used for auditing the IAS application at a predefined interval (known as IAS Application Audit Interval). During this audit, the following statistical information is generated:
I
I I I I
List of clients connected to IAS and the corresponding threads IDs of threads in IAS serving it Threads count (user, daemon) in the IAS application at that instant Peak thread count of the IAS application Memory consumption of the IAS application Other services information (like memory consumed and thread count) running on the machine hosting the IAS application Operating System information
This information helps in gathering factual information about the customer environment for IAS and fine tuning IAS. You can define the configuration settings for status monitoring in the ias.properties file.
99
Customizing the IAS thread pool handling IAS Clients
Table 23
Property
IAS status monitoring properties

Description Used to enable or disable the status monitoring audit log. The supported values are true or false. The default is true. Specifies the log file name and its format. "%g" the generation number to distinguish rotated logs. Specifies an approximate maximum amount to write (in bytes) to any one file. Specifies how many output files to cycle through, that is, the number of files to use. Specifies the audit frequency time interval in minutes.
com.bmc.sms.ixs.appAuditLogEnable com.bmc.sms.ixs.appAuditLogFilename com.bmc.sms.ixs.appAuditLogLimit com.bmc.sms.ixs.appAuditLogFileCount com.bmc.sms.ixs.applicationAuditInterval
Code examples follow that show sample IAS Status Monitoring configuration parameters.
# IAS Status Monitoring Enable com.bmc.sms.ixs.appAuditLogEnable=true # Status Monitoring Audit File Name com.bmc.sms.ixs.appAuditLogFilename=log/ias/IAS_App_Audit_File#%g.log # Status Monitoring Audit Log Limit com.bmc.sms.ixs.appAuditLogLimit=50000 # Status Monitoring Audit Log File Count com.bmc.sms.ixs.appAuditLogFileCount=10 # Status Monitoring Audit Log Interval com.bmc.sms.ixs.applicationAuditInterval=60
Customizing the IAS thread pool handling IAS Clients

You can define the configuration parameters for the IASClientThreadManager thread pool in the ias.properties file. Table 24
Property
IAS thread pool properties (part 1 of 2)

Description
com.bmc.sms.ixs.iasclient.threadManager.cor Specifies the Core ThreadPool Size. It indicates the number of e_Pool_Size threads to keep in the pool even if they are idle (Minimum Thread Pool size). com.bmc.sms.ixs.iasclient.threadManager.ma Specifies the Maximum ThreadPool Size. It indicates the x_Pool_Size maximum number of threads to allow in the thread pool.
100
Defining standalone, primary, and secondary BMC Impact Administration servers
Table 24
Property
IAS thread pool properties (part 2 of 2)

Description
com.bmc.sms.ixs.iasclient.threadManager.ke Specifies the maximum time that excess idle threads will wait ep_Alive_Time for new tasks before terminating. Excess idle threads occur when the number of idle threads in the thread pool is more than the core pool size. com.bmc.sms.ixs.iasclient.threadManager.ke Specifies the time unit for the keepAliveTime argument. The ep_Alive_Time_Unit possible values are DAYS, HOURS, MINUTES, or SECONDS.
NOTE
The property com.bmc.sms.ixs.thread.pool.size is not applicable in 7.3.00 and 7.2.x, if the patch for thread pool changes is applied. Do not modify the properties com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time and com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time_Unit as these are sensitive.
Code examples follow that show sample IAS ThreadPool configuration parameters.
# Core ThreadPool Size com.bmc.sms.ixs.iasclient.threadManager.core_Pool_Size=10 # Max ThreadPool Size com.bmc.sms.ixs.iasclient.threadManager.max_Pool_Size=50 # Keep Alive Time com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time=1000 # Keep Alive Time Unit com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time_Unit=SECONDS

NOTE
At installation, you can choose to install and implement a failover configuration for the IAS. If you select to define an failover setup for the Master IAS, the accompanying IAC is also defined as failover automatically.
By default the IAS is configured to work in standalone mode. However, after installation, you can choose to implement a failover configuration, in which you define a pair of primary and secondary servers to handle failover situations after which you need to restart both the servers.
Chapter 3
101
You must first install another BMC IAS on a second system. Rerun the installation, and make the appropriate Standard or Master IAS selection for the second system. The primary and secondary Impact Administration servers must have the same name.
To configure IAS failover manually

1. Edit the ias.properties files as mentioned below:
A On the primary IAS, go to the

IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file and set the parameters as mentioned below:
com.bmc.sms.ixs.server.mode=primary com.bmc.sms.ixs.backup.server=hostname_of_secondary_ias_server:ias_port_number (for example: pun-sms-sun31:3084) Note: you can also use the IP address instead of the host name. com.bmc.sms.ixs.backup.server="IP address of secondary":3084
B On the secondary IAS, go to the

IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file and set the parameters as mentioned below:
com.bmc.sms.ixs.server.mode=backup com.bmc.sms.ixs.primary.server=hostname:ias_port_number (for example: pun-sms-sun25:3084) Note: you can also use the IP address instead of the host name. com.bmc.sms.ixs.backup.server="IP address of primary":3084
2. Restart the primary and secondary IASs.
NOTE
If you define a standalone Master IAS as an HA pair, you must also define its accompanying administration cell as an HA pair.
102
When you define primary and secondary servers, you also define the synchronization properties for both. The synchronization process updates IAS records and files, such as the following files:
I I I I I
user_definitions.xml group_roles.xml role_permissions.xml cmdb.properties cell_info.list
During synchronization of failover pairs, data is carried from the primary to the secondary IAS and from the secondary to the primary. Each server of a failover pair has its own ias.properties and logging configuration files. These files are not synchronized.
NOTE
To enable synchronization between servers, they must be installed on the same type of platform: either all on MS Windows or all on the same UNIX operating system (for example, Solaris to Solaris, Linux to Linux).
When you execute the iadmin command on a primary or secondary IAS, the change is reflected on the corresponding secondary or primary IAS after the synchronization process is complete. To synchronize the servers immediately, use the iadmin -reinit fullsync | -sync command. See iadmin reinit/sync options on page 104 for more information.
IAS synchronization properties

You can define your IAS synchronization properties by modifying the following properties in its corresponding ias.properties file. Table 25
Property com.bmc.sms.ixs.transaction.history
IAS synchronization properties (part 1 of 2)

Description for failover definitions. The number of days that entries in the transaction log are kept before they are removed by synchronization. The default is 5 days. for standalone and failover definitions. Indicates whether the IAS maintains a backup copy (.bak extension) when it writes a file. The default is false. for failover definitions. Interval in minutes between synchronization requests from a secondary server to a primary server. The default is 15 minutes.
com.bmc.sms.configService.keepBackupFile
com.bmc.sms.ixs.sync.interval
Chapter 3
103
Table 25
Property
IAS synchronization properties (part 2 of 2)

Description for failover definitions. The IP address of the primary server along with its default port number in the following format: ipaddressOfPrimaryServer:portNumber. You define the primary server in the ias.properties file of the paired secondary server.
com.bmc.sms.ixs.primary.server
com.bmc.sms.ixs.backup.server
for failover definitions. The IP address of the secondary server along with its default port number in the following format: ipaddressOfSecondaryServer:portNumber. You define the secondary server in the ias.properties file of the primary IAS server.
com.bmc.sms.ixs.server.mode
the server role. Options are standalone (default), primary, and backup.
If you specify primary or backup, then of course you must complete the primary and backup server entries in the respective ias.properties files of the two servers.
iadmin reinit/sync options

You can use the following iadmin reinit/sync options to restart a server, copy the primary servers configuration to its secondary server, or start a synchronization between the two servers immediately. From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, you can
I
execute the iadmin -reinit command on the primary or secondary server to restart the server with the latest configuration data You usually execute the iadmin -reinit command on the primary server after you have manually edited any of its files.
execute the iadmin -reinit fullsync command on the secondary server only to copy the primary servers configuration to it and to restart it with the new configuration You should execute the iadmin -reinit fullsync command on the secondary server the first time you start it after installation.
execute the iadmin -sync command on the secondary server to start the synchronization process immediately instead of waiting until the next synchronization interval
104
Defining a failover configuration for the Impact Administration cell
Use the iadmin -reinit and iadmin -reinit fullsync commands to restart the respective server anytime you have manually edited one or more of the primary servers configuration files. Your typical use case would look as follows: 1. Manually edit the configuration files on the primary server. 2. Execute the iadmin -reinit command on the primary server. 3. Execute the iadmin -reinit fullsync command on the secondary server. BMC recommends that you use the iadmin CLI to edit files whenever possible, thereby eliminating the need to restart the server.
Defining a failover configuration for the Impact Administration cell

As a general practice, you configure the IAC as an failover pair whenever you configure the Master IAS as a failover pair. Use this table as a guideline for changing the respective mcell.dir files of the primary IAC on one host system and the secondary IAC on the second host system: Table 26
cell cell
mcell.dir entries for a failover pair of Impact Administration cells

Secondary IAC on Host 2 host1:1827 host2:1827 host1:1827 host2:1827 cell cell Admin IAC mc mc host1:1827 host2:1827 host1:1827 host2:1827 mc mc
Primary IAC on Host 1 Admin IAC
Remember that the primary IAC resides on the same host as the primary Master IAS and the secondary IAC resides on the same host as the secondary Master IAS. After you define the entries in the mcell.dir files, you must modify the respective mcell.conf files as you would any normal cell that you are configuring for failover.
Chapter 3
105
Transaction and trace logs
Transaction and trace logs

The IAS automatically generates the log files listed in Table 27. Table 27
File name transaction.log record_transaction.log ias0.log
IAS log files

Description stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for file synchronization stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for record synchronization stored under IMPACT_SOLUTIONS_HOME/server/tmp/ias. This is the diagnostic trace log. They are numbered incrementally. A new log file is created whenever IAS restarts or when the current log file reaches its specified maximum size. When the maximum log file count is reached, then the process repeats itself because only one cycle of logs is maintained. The new log file is always named ias0.log. The logger renames the existing log files in ascending chronological order. So the earliest log file is ias1. log and the oldest log file in the cycle has the greatest number.
You can edit the properties of the diagnostic trace log ias0.log in the server_logging.properties file.
Example trace output

An example trace excerpt, showing INFO level messages, is shown below:
I009-01-14 12:20:18:253 UTC INFO [WrapperStartStopAppMain] com.bmc.sms.ixscomm.jmx.IXSComm.startService() -> Credential Repository loaded successfully. 2009-01-14 12:20:18:253 UTC INFO [Thread-1] com.bmc.sms.ixscomm.server.IXSServer.run -> start to accept requests
Advanced tasks
This section describes two tasks that require background knowledge of third-party products and utilities. The task Configuring BMC Impact Administration server to support remote actions on page 107 requires knowledge of secure protocols, and the task Configuring Lightweight Directory Access Protocol for BMC Impact Administration server on page 109 requires knowledge of Lightweight Directory Access Protocol (LDAP).
Configuring BMC Impact Administration server to support remote actions

If the BMC Impact Administration server and the target application share an MS Windows platform, then remote actions are enabled by default. The IAS uses New Technology LAN Manager (NTLM), v. 2, to secure communications between MS Windows systems. If the BMC Impact Administration server and the target application share a UNIX Solaris or Linux platform, then remote actions are enabled by default also but through the Secure Shell (SSH), v. 2, protocol. SSH, v. 2, should be installed with the Solaris or Linux operation system. You may have to configure it for use if it is not already enabled. If either the BMC Impact Administration server or the target application is installed on an HP-UX or an AIX system, then you must download the SSH package from a third-party vendor to the HP-UX or AIX system. Then you must configure it to enable remote actions. If the BMC Impact Administration server resides on a UNIX or Linux system and the the target application sits on an MS Windows system, then you must download the SSH package to the MS Windows systems. Then configure it to enable remote actions. BMC recommends that you use SSH to secure communications.
Default protocols
IAS uses the default communication protocols that are specified in the
IMPACT_SOLUTIONS_HOME/server/conf/resources/centraladmin-strings.properties file.
For MS Windows, the IAS uses the PsExec protocol:

windows.execute.command=com.bmc.sms.marimba_cas_tools.PsExecTask windows.putfile=com.bmc.sms.marimba_cas_tools.PsExecTask windows.getfile=com.bmc.sms.marimba_cas_tools.PsExecTask
For the UNIX-based operating systems, the following defaults are used:
unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask unix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask unix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask
Chapter 3
107
You can specify multiple protocol values for each of these properties, as shown:
windows.execute.command=com.bmc.sms.marimba_cas_tools.PsExecTask,com.bmc.sms. marimba_cas_tools.SSHTask,com.bmc.sms.marimba_cas_tools.TelnetTask windows.putfile=com.bmc.sms.marimba_cas_tools.PsExecTask,com.bmc.sms. marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask windows.getfile=com.bmc.sms.marimba_cas_tools.PsExecTask,com.bmc.sms. marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask
In this instance, the IAS tries to execute the remote action using each of the specified protocols in sequence until the command succeeds. For example, for the windows.execute.command, the IAS first tries PsExec. If it fails, then it tries SSH. If it fails, then it uses Telnet. It repeats the pattern for each command.
NOTE
Make sure that youre familiar with security protocols before modifying these settings.
If the BMC Impact Explorer console, cell, or the task definition in the UserDefinedActions.xml file does not specify an operating system, then IAS uses the SSH protocol for all OS commands, as shown below:
all.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask all.putfile=com.bmc.sms.marimba_cas_tools.SCPTask all.getfile=com.bmc.sms.marimba_cas_tools.SCPTask
See the BMC Impact Solutions Event Management Guide for more information on task definitions. You can also specify multiple protocol values for these commands, as shown in the preceding example. To initialize any changes, restart the BMC Impact Administration server.
Enabling Telnet
By default, the Telnet protocol is turned off. Telnet is not a secure protocol. User name and password credentials that you enter are sent in plain text to the remote system. Also, the Telnet session times out during the creation of support packages. However, you can enable Telnet and ftp. You will need to start the Telnet service on the Windows system. You also need to modify the centraladmin-strings.properties file located under the IMPACT_SOLUTIONS_HOME/server/conf/resources path.
108
Configuring Lightweight Directory Access Protocol for BMC Impact Administration server
The relevant section of the centraladmin-strings.properties file is depicted below:

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask unix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask unix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask
To enable Telnet and ftp, modify the properties as follows:

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask,com.bmc.sms.marimba_cas_tools. TelnetTask unix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask unix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask
Restart the BMC Impact Administration server to initialize your changes.
Use Lightweight Directory Access Protocol (LDAP) authentication in a production environment. In this way, you can link your BMC Impact Administration server (IAS) authentication with your corporate infrastructure for user authentication and authorization management. Using LDAP authentication allows you to use the same user definitions across multiple BMC product lines. After you define your LDAP user and user groups, you can map your LDAP user groups to the IAS user groups. Any users you add to an LDAP user group share the permissions of the IAS user group to which you have mapped. The IAS supports Active Directory LDAP nested groups. You can use a single sign-on to access multiple products. You do not have to create a separate user definition and sign-on information for each product. To enable LDAP authentication for the IAS on a Windows system, your login account must have administrator privileges on the target system. On a UNIX system, you must be logged in as root or under a user account with write and execute permission on the IMPACT_SOLUTIONS_HOME/server directory. Set up your LDAP server according to your LDAP server procedures. Next, enable the LDAP login entry in the ias.properties file. Then you can enter your LDAP configuration information for each LDAP server that you are enabling.
Chapter 3
109
NOTE
If you are using a solution that requires the BMC Portal and/or BMC Atrium CMDB, you may need to set up LDAP authentication on the BMC Portal server and on the AR System server. Refer to the BMC Portal Getting Started guide for information on setting up LDAP authentication on the BMC Portal server. Refer to the BMC Remedy Action Request System 7.1 Integration with Plug-ins and Third-Party Products for information on setting up LDAP authentication on the AR System server.
To enable the LDAP login entry in the ias.properties file 1 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties
file, where IMPACT_SOLUTIONS_HOME/server is the installation directory of your server. Locate the com.bmc.sms.ixs.enable.ldap.login parameter, and set it equal to true:
#----------------------------------------------------------------# Enable/disable LDAP login module. # When it is enabled, "ldap_definition.xml" file has to be filled. #----------------------------------------------------------------com.bmc.sms.ixs.enable.ldap.login=true
2 Optional. To enable file-based user groups, defined in the user_definitions.xml file,

to map to roles in addition to LDAP user groups, modify the com.bmc.sms.ixs.allow.local.groups.for.ldap parameter, setting it equal to true, as in the following example:
com.bmc.sms.ixs.allow.local.groups.for.ldap=true
The user groups defined in the user_definitions.xml file are mapped to roles for the initial log-in and for user authorization.
NOTE
If you leave the default value false, then only roles that are mapped to the users LDAP groups are used for user authorization.
3 Save and close the ias.properties file. 4 Restart IAS. 5 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/jaas.conf file. Do
not modify this file. Verify that it contains an entry such as the following:
com.bmc.sms.ixscomm.authentication.ldap.LdapLoginModule Sufficient;
6 Close the file.

To add LDAP configuration information

You are now ready to add your LDAP configuration information to the IMPACT_SOLUTIONS_HOME/server/conf/ldap_configuration.xml file. Figure 13 on page 111 depicts a sample ldap_configuration.xml file with a single LDAP server configuration: Figure 13 Excerpt from ldap_configuration.xml file
<?xml version="1.0" encoding="UTF-8"?><ldapList xmlns="urn:bmc:schemas:impact" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:bmc:schemas:impact ldap_definitions.xsd"> <ldap alias="test"> <host>majestix.bmc.com</host> <port>389</port> <version>3</version> <baseDN>DC=pinfrastruct,DC=rd,DC=bmc,DC=com</baseDN> <connectionUserName>glin@pinfrastruct.rd.bmc.com</connectionUserName> <useridAttribute>sAMAccountName</useridAttribute> <useSSL>false</useSSL> <memberOfAttribute>memberOf</memberOfAttribute> <userSearchFilter>(objectClass=organizationalPerson)</userSearchFilter> <groupSearchFilter/> <connectionPassword encrypted="true">fisSCap4ZhOLOUENWPLe== </connectionPassword> </ldap> ...... </ldapList>
1 Make only one <ldap></ldap> entry for each LDAP configuration.

Multiple LDAP configurations can exist for one LDAP server with different baseDN parameter values.
2 Follow these guidelines for your <ldap></ldap> entries: A Specify a unique alias for each LDAP configuration. B Ensure that the LDAP group is defined in the group_roles.xml file on the IAS. 3 Using Table 28 on page 111 as a guide, complete the LDAP configuration
parameters. Table 28
host port version
LDAP configuration parameters (part 1 of 2)

Description the fully qualified host name where LDAP is installed. You should be able to verify the connection between the LDAP server and the IAS using the ping command. port number by which to connect to the LDAP server. Normally the nonsecure port number is 389. The secure (SSL) port number is 636. LDAP version number. The most recent version is version 3.
LDAP parameter
Chapter 3
111
Table 28
baseDN
LDAP configuration parameters (part 2 of 2)

Description directory of the LDAP structure from which the search routine starts in LDAP. This is the base Fully Qualified Distinguished Name (FQDN) from which all user and group queries occur. The Distinguished Name represents an object and the path to the object in the directory hierarchical namespace. Objects are ordered from most to least specific. login Id that the programs use to connect to the LDAP server. attribute in the user entry that contains the login Id. indicates whether LDAP authentication is using OpenSSL. attribute in the user entry that specifies whether the user belongs to certain user groups. search filter that the LDAP server uses to look up a user entry. If left blank, this parameter defaults to the following filter: (|(objectClass=person)(objectClass=user) (objectClass=inetOrgPerson)(objectClass= organizationalPerson))
LDAP parameter
connectionUserName userIdAttribute useSSL memberOfAttribute userSearchFilter
groupSearchFilter
search filter that the LDAP server uses to look up a user group entry. If left blank, this parameter defaults to the following filter: (|(objectClass=group)(objectClass= groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=grou pOfUrls))
connectionPassword
authentication password (encrypted) that is used to connect to the LDAP server. Note: Set the encrypted attribute equal to false and then enter the password in plain text. When IAS restarts, it encrypts the password and changes the encrypted attribute value from false to true.
4 After completing your changes, restart the IAS.

I
On Microsoft Windows, restart the IAS service through the Services window. On UNIX, execute the ias_service script from the appropriate path. (The default path is /opt/bmc/Impact/server/bin.) You must be logged on as a root user to start and stop the script.
The IAS connects to the LDAP servers one at a time in succession. When it finds a users matching login credentials, the IAS returns the match. It does not attempt to connect to other LDAP servers that might be defined in the ldap_configuration.xml file. Next, after you add your LDAP server or servers, you can add a user group and assign it a user role.
112
To add a new user group with mapping roles NOTE

If youre adding a new role to the group, you must first create the role and add permissions to it using the iadmin -ar option before you create the group. See To add a new role/mapping permission on page 87.
From the/bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:
iadmin -ag group=NewGroup:roles=Role
The new entry would look similar to the following in the group_roles.xml file:
<entry key="nameofUserGroup">IAS_defaultRoleName</entry>
To add the role name to the cells KB definition files

You add the role name to the Access Control List (ACL) of the collector definition and operation definition files in the connected cell or cells.
NOTE
If the ACL is empty, then every group has access.
1 Add the user group name to each of the following collector definition files that you
want the user group to access. Where indicated, associate the read, write, and execute permissions (r, w, x) with the group name entry:
I I I I I I I I
biip4p_collectors.mrl catchall_collector.mrl mc_bylocation_collectors.mrl mc_bystatus_collectors.mrl mc_evr_collectors.mrl mc_sm_collectors.mrl mcxpcoll.mrl self_collector.mrl
You may need to change the file permissions on these files before editing them.
Chapter 3
113
The following code examples show sample modifications to each file:
biip4p_collectors.mrl
collector PATROL : { r['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] w['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] x['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] } END
catchall_collector.mrl
collector 'All { r['Service w['Service x['Service } Events' : Administrators',nameofUserGroup] Administrators',nameofUserGroup] Administrators',nameofUserGroup]
mc_bylocation_collectors.mrl
collector 'By Location': { r['Service Administrators',nameofUserGroup] w['Service Administrators',nameofUserGroup] x['Service Administrators',nameofUserGroup] } END ............... collector 'By Location'.*: { r['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] w['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] x['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service Managers',nameofUserGroup] }:
114
mc_bystatus_collectors.mrl
collector 'By Status': { r['Service Administrators','Service Operators Senior',nameofUserGroup] w['Service Administrators','Service Operators Senior',nameofUserGroup] x['Service Administrators','Service Operators Senior',nameofUserGroup] } END
mc_evr_collectors.mrl
collector MC_Related_Events: { r['Service Administrators',nameofUserGroup] w['Service Administrators',nameofUserGroup] x['Service Administrators',nameofUserGroup] } END collector MC_Related_Events.*: { r['Service Administrators',nameofUserGroup] w['Service Administrators',nameofUserGroup] x['Service Administrators',nameofUserGroup] }: EVENT where [mc_relation_source: != ''] create $THIS.CLASS END
You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.
Chapter 3
115
mc_sm_collectors.mrl
collector { r['Full w['Full x['Full } END MC_SMC_Events: Access', 'Service Administrators'nameofUserGroup] Access', 'Service Administrators'nameofUserGroup] Access', 'Service Administrators'nameofUserGroup]
collector MC_SMC_Events.*: EVENT where [$THIS.mc_smc_id != ""] create cond($THIS.mc_smc_type == '', "Unknown", $THIS.mc_smc_type) END collector MC_SMC_Events.*.Impacts: EVENT where [$THIS.mc_smc_impact == 1] END collector MC_SMC_Events.*.History: SMC_STATE_CHANGE END
You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.
mcxpcoll.mrl
collector 'By Location'.*.*.*.*.*: PATROL_EV where [p_application: not_equals ''] create $THIS.p_application END { r[nameofUserGroup] w[nameofUserGroup] x[nameofUserGroup] }
self_collector.mrl
collector self : { r['Full Access', 'Read Only',nameofUserGroup] w['Full Access', nameofUserGroup] x['Full Access', nameofUserGroup] } END
116
2 Next, assign the group name to the appropriate event management operations in
the im_operations.mrl file. Each event operation can be performed by a predefined set of groups, as shown in Table 29. Table 29 Event operations
Group names Service Administrators, Service Operators - Senior, Service Operators Service Administrators, Service Operators - Senior, Service Operators Service Administrators, Service Operators - Senior, Service Operators Service Administrators, Service Operators - Senior, Service Operators Service Administrators, Service Operators - Senior Service Administrators, Service Operators - Senior Service Administrators, Service Operators - Senior
Event operation Acknowledge Take Ownership Decline Ownership Close Assign to Operation Set Priority Reopen
An example of a group name assignment to a specific event management action is shown below:
action im_operations.Acknowledge: { ['Service Administrators','Service Operators Senior','Service Operators',nameofUserGroup] }
3 Make the appropriate group name assignments to the mc_actions.mrl file and the
sim_operations.mrl file, following the syntax examples in the files.
4 Recompile the cells KB using the mccomp command, as in the following example:
mccomp -n cellName | manifestKBFilePath
You must include the path to the manifest.kb file.
5 Restart the cell using the mcell command. To retrieve LDAP groups or to authenticate an LDAP user
From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -tlq option, as in the following example that retrieves a list of LDAP groups:
iadmin -tlq group
Chapter 3
117
Troubleshooting
NOTE
When you execute the iadmin command using the -tlq option, you must have the correct LDAP server information in the ldap_configuration_query.xml file.
To authenticate a specific LDAP user, enter the user name and password, as in the following example:
iadmin -tlq username=<string>:password=<string>
The -tlq option also checks the time required to execute an LDAP query. To facilitate the iadmin -tlq option, you can modify the following properties in the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file.
LDAP property com.bmc.sms.ixs.search.time.limit com.bmc.sms.ixs.search.ldap.group Description the maximum time for an LDAP query to retrieve data from the LDAP server. The default is 5000 milliseconds. groups to be searched in the LDAP server when, for example, you are assigning events to groups. Only groups that are also defined in the group_roles.xml file are searched in LDAP.
Troubleshooting
Problem: Cell_info.list synchronization error during manual configuration of an IAS failover
When manually configuring an IAS high availability pair, you will find that the cell_info.list does not synchronize properly between the primary and secondary Impact Administration servers. You can work around this issue by
I
I I I
manually copying the cell entries of the Impact Administration server that you will convert to the secondary server saving them to an editor adding them to the newly created primary server using the iadmin command starting both the primary and secondary servers and executing the iadmin -reinit fullsync command on the secondary server
118
Before you begin

Configure the corresponding Impact Administration (Admin) cell in high availability mode.
To manually synchronize the cell_info.list 1 Execute the iadmin -lc command against the Impact Administration server system
that you will later configure as the secondary server. An example command with sample output is shown below:
bash-3.00# iadmin -lc BMC Impact Administration Server 7.3.00 [Build 1647631 - 29-Dec-2008] Copyright 1998-2009 BMC Software, Inc. as an unpublished work. rights reserved. List BMC Impact Managers: pun-sms-sun31 mc pun-sms-sun31.bmc.com:1828 Production * All
2 Copy the cell entry to a text editor, such as Notepad. In this example, the copy
would look as follows:
pun-sms-sun31 mc pun-sms-sun31.bmc.com:1828 Production *
3 Manually add the host cell entry from the secondary server to the primary servers
cell_info.list file using the iadmin -ac command, as in the following example:
iadmin -ac name= pun-sms-sun31:key=mc:primaryHost=pun-sms-sun31:Port=1828: environment=Production:usergroups=*
4 Configure IAS failover (primary and secondary servers). See To configure IAS
failover manually on page 102 for the steps.
5 Restart the primary and secondary servers. 6 Execute the iadmin -reinit fullsync command on the secondary server to copy the
primary servers configuration to it and to restart it with the new configuration
7 Wait for the synchronization process to complete.

The default synchronization interval time is 15 minutes. This value is defined in the com.bmc.sms.ixs.sync.interval property of the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file.
Chapter 3
119
120
Chapter
4
122 122 123 123 124 124 124 124 125 126 127 127 129 130 130 131 132 132 133 134 136

This chapter describes how to configure the BMC Impact Portal and contains the following topics: Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . internal.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4
121
Accessing the BMC Impact Portal
Accessing the BMC Impact Portal

Communication between the Web browser and the BMC Portal is encrypted and requires the use of the https:// communication protocol.
To access the BMC Portal 1 In the browsers address box, type the BMC Portal URL address using the
following syntax:
https://computerName:portNumber
I
computerNamerepresents the host name of the BMC Portal server portNumberrepresents the port number assigned to the BMC Portal; the default port number is 443
NOTE
The Transport Layer Security (TLS) protocol is used to secure communication between the BMC Portal Application Server and the Web browser.
2 In the security alert window, click Yes to accept the security certificate. 3 In the logon screen, type your logon user name and password, and then click Log
On.
If you receive the message user name and password invalid after entering a valid user name and password, the BMC Portal server might not be running. Start the BMC Portal and log on to it again.
WARNING
If you leave your BMC Portal session by selecting a different URL and then return to the session before the expiration of the timeout period, the BMC Portal fails to prompt you for your user name and password. To ensure the integrity of the session, log out of the session every time you leave your BMC Portal session.
Starting and stopping the BMC Portal

The installation process does not automatically start the BMC Portal service. The following topics describe how to start and stop the BMC Portal service on both Windows and UNIX.
122
Starting and stopping the BMC Portal on Windows
Starting and stopping the BMC Portal on Windows

You can start and stop the BMC Portal by using either of the following methods:
I I
using the Services window using the net start and net stop commands
To start or stop the BMC Portal from the Services window 1 Open the Services window. 2 From the scroll list, select BMC Portal. 3 To start the service, click Start Service. 4 To stop the service, click Stop Service. To start or stop the BMC Portal from the command line
From a command prompt, use the following methods to start and stop the BMC Portal:
I
To start the BMC Portal, enter the following command:

net start BMC Portal
To stop the BMC Portal, enter the following command:

net stop BMC Portal
Starting and stopping the BMC Portal on UNIX

The BMC Portal starts and stops as a daemon on UNIX platforms.
To start or stop the BMC Portal daemon on UNIX

To start or stop the BMC Portal on UNIX, use the BMCPortalAppserver script in the /etc/init.d directory and enter one of the following commands:
I I
./BMCPortalAppserver stop ./BMCPortalAppserver start
Chapter 4
123
Configuration tasks for BMC Impact Portal
Configuration tasks for BMC Impact Portal

This section contains some of the tasks you perform to configure the BMC Impact Portal.
Registering production and test cells in the BMC Impact Portal

Production and test cells must be registered in BMC Impact Portal so BMC Impact Explorer users can access the data defined to cells. Administrators can register a cell by using the BMC Impact Portal Viewable Impact Managers tab. For information on registering a cell in BMC Impact Portal, see the online Help or the BMC Portal Getting Started.
Customizing BMC Impact Portal configuration

You customize a BMC Impact Portal by editing the configuration parameters found in the internal.properties file located in the jboss/server/all/conf/properties/ smsConsoleServer directory. These configuration parameters can affect several services. If you make changes to the internal.properties file, you will need to stop and start the BMC Impact Portal. For more information about the internal.properties file and its configuration, see internal.properties file and parameters on page 136.
Configuring Dashboard Table View columns

You can change the columns displayed in the dashboard table views by editing the ..\smsIwc\application.properties file.
To configure Dashboard Table View columns 1 Open the application.properties file in a text editor. This file is located at
installationDirectory\tools\jboss\server\all\conf\properties\smsIwc\.
2 Edit the file to add or remove columns using the following format:
table_name=comma separated attribute (slot) names
124
Configuring Events Table columns
3 Save the application.properties file. WARNING

To preserve the .properties suffix, save as type All Files. Do not save the application.properties file as a .txt file. The configuration changes may not be recognized.
4 Restart the BMC Portal service.
Configuring Events Table columns

You can edit the columns that appear in the table in the Events tab by editing the ..\smsIwc\application.properties file. All columns in the events table are configurable.
To configure Events Table columns 1 Open the application.properties file in a text editor. This file is located at
2 Edit the appropriate events table column as shown in Table 30 on page 125.
Table 30
status mc_priority severity date_reception owner_name msg
Event Table column default values

event status of the selected component value of the possible priorities of the event (values 5, 4, 3, 2, or 1) value of the possible severities of the event (unknown, ok, info, warning, minor, major, or critical) date and time the event was received name of the owner of the component relevant information related to the event
Column heading Description


For more information on this file, see smsIwc/application.properties file and parameters on page 133.
Chapter 4 Managing the BMC Impact Portal 125
Configuring Status Table columns
Configuring Status Table columns

You can edit some of the columns in the tables in the Status tab by editing the ..\smsIwc\application.properties file. However, not all columns are configurable. The first three columns (status, type, and name) cannot be changed. A smaller version of each primary status table is displayed in the dashboard view, if the Status window is selected for one or more of the dashboard panes. By default, no columns beside the status, type, and name are configured for these smaller tables, but columns can be added in the application.properties file.
To configure Status Table columns 1 Open the application.properties file in a text editor. This file is located at
2 Edit the appropriate status table column as shown in Table 31.

Table 31
Table Providers
Status table column default values

Configuration file listing com.bmc.sms.iwc.status.table.providers Default columns last_status_modification description owner_name owner_contact none last_status_modification description owner_name owner_contact
Providers (dashboard view) Consumers
com.bmc.sms.iwc.status.table.providers. small com.bmc.sms.iwc.status.table.consumers
Consumers (dashboard view) Causes
com.bmc.sms.iwc.status.table.consumers. small none com.bmc.sms.iwc.status.table.causes last_status_modification description owner_name owner_contact


For more information, see smsIwc/application.properties file and parameters on page 133.
Configuring object link synchronization
Configuring object link synchronization

You can change the objectlinksync values by editing the ..\smsIwc\application.properties file.
To configure object link synchronization 1 Open the application.properties file in a text editor. This file is located at
2 To change the object link type, modify the com.bmc.sms.iwc.objectlinksync.types

entry.


Configuring reports
You can configure the following items for reports by editing the ..\smsConsoleServer\application.properties file:
I I I I
scheduling value of report goal lines length of time report data is retained length of time event data is retained
To configure reports 1 Open the application.properties or internal.properties files in a text editor. These file
are located at
installationDirectory\tools\jboss\server\all\conf\properties\smsConsoleServer\.
2 Edit the appropriate status table column as shown in Table 32 on page 128 and
Table 33 on page 129.
Configuring reports
Table 32
Report parameters (application.properties file)

Parameter Description com.bmc.sms.reportSummarizer.goal.default Availability report goal line, expressed as a .SMS_CS_RT_AVAIL percentage. Default value is 90.0%. com.bmc.sms.reportSummarizer.goal.default Mean Time to Repair goal line, expressed in .SMS_CS_RT_MTTR milliseconds. Default value is 300000 (5 minutes). com.bmc.sms.reportSummarizer.goal.default Mean Time Between Service Failures goal .SMS_CS_RT_MTBF line, expressed in milliseconds. Default value is 172800000 (2 days). com.bmc.sms.reportSummarizer.goal.default Mean Time Between Service Incidents goal .SMS_CS_RT_MTBSI line, expressed in milliseconds. Default value is 172800000 (2 days).
Parameter type Report Goals
Retention Age
com.bmc.sms.consoleserver.retention.policy. The number of days Status tab data will be age.SMS_CS_STATUS_EVENT retained. Default value is 395. com.bmc.sms.consoleserver.retention.policy. The number of days Availability data will age.SMS_CS_RT_AVAIL be retained. Default value is 395. com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time to Repair age.SMS_CS_RT_MTTR data will be retained. Default value is 395. com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time Between age.SMS_CS_RT_MTBF Failure data will be retained. Default value is 395. com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time Between age.SMS_CS_RT_MTBSI Service Incidents data will be retained. Default value is 395. com.bmc.sms.consoleserver.retention.policy. The number of days event data will be age.EG_EVENT retained in the BMC Datastore. Default value is 395.
128
Configuring the number of events displayed
Table 33
Report parameters (internal.properties) file

Parameter Description The frequency, in hours, that the report information is summarized. Default value is 1. The number of seconds that will be added to the starting hour for every scheduled summarization time. Default value is 30.
Parameter type
Report Schedule com.bmc.sms.reportSummarizer.scheduler. frequencyHours com.bmc.sms.reportSummarizer.scheduler. delaySeconds
com.bmc.sms.reportSummarizer.scheduler.is Determines whether or not the setting of StartingNextHour startingHour will be ignored. If set to true, startingHour will be ignored. Default value is true. com.bmc.sms.reportSummarizer.scheduler. startingHour Determines the desired starting hour. No summarization is made until this value is reached. If the startingHour has passed on that day, the summarization will start at that hour the next day. Default value is 0.
3 Save the application.properties and internal.properties files. WARNING


Configuring the number of events displayed

You can set the maximum and minimum number of events displayed in the Events tab by editing the ..\smsIwc\application.properties file.
To configure the number of events displayed 1 Open the application.properties file in a text editor. This file is located at
2 To change the minimum number of events shown on the Events table, edit the
value for com.bmc.sms.iwc.event.table.minimumevents. The default value is 5.
3 To change the maximum number of events shown on the Events table, edit the
value for com.bmc.sms.iwc.event.table.maximumevents. The default value is 50.
Changing the maximum number of recent items displayed


For more information, see smsIwc/application.properties file and parameters on page 133 and internal.properties file and parameters on page 136.
Changing the maximum number of recent items displayed

You can change the maximum number of objects displayed in the Recent Items group in the navigation tree by editing the ..\smsIwc\application.properties file.
To change the maximum number of recent items displayed 1 Open the application.properties file in a text editor. This file is located at
2 To change the maximum number of recent items displayed in the navigation tree,
edit the value for com.bmc.sms.iwc.ui.recentitems.maxsize.


For more information on this file, see smsIwc/application.properties file and parameters on page 133
Configuring the general properties displayed

You can change the general properties in the Configuration tab by editing the ..\smsIwc\application.properties file.
130
Setting up Image Views
To configure the general properties displayed 1 Open the application.properties file in a text editor. This file is located at
2 Add or remove property types associated with

com.bmc.sms.iwc.component.properties.generalProperties.properties.


For more information on this file, see smsIwc/application.properties file and parameters on page 133
Setting up Image Views

Image Views provide an alternative method for displaying components contained in a service model. Using a background image, you can organize the service model components to represent an area of your environment. For example, you can create an Image View that illustrates the geographic locations of a service model on a map. The background images used for Image Views are located in the following directory: BMC_PORTAL_KIT_HOME\appserver\websdk\tools\jboss\server\all\data\
smsConsoleServer\Image\Background
To add a background image, place a copy of the graphic file in this directory. You can use the following types of graphic files for background images:
I I I
GIF JPEG PNG
Use the Configure tab in the BMC Impact Portal to create, edit, and delete Image Views. For more information on setting up Image Views, see the BMC Impact Portal online Help.
Chapter 4
131
Modifying connection settings
Modifying connection settings

You can modify the settings that BMC Impact Portal server uses when connecting to BMC Impact Manager instances.
To modify BMC Impact Portal connection settings 1 In a text editor, open the
%BMC_PORTAL_KIT_HOME%\appserver\websdk\tools\jboss\server\all\conf\ properties\smsConsoleServer\application.properties file.
2 Search for the Cell connection configuration stanza, and review the connection
properties. The following figure depicts the default values for the connection properties.
CellName.timeout = 30 CellName.reconnect_attempts = 5 CellName.reconnect_frequency = 30 CellName.polling_frequence = 3600 CellName.encryption = on
3 Modify the connection properties. 4 Save the application.properties file. 5 Restart the BMC Portal service (or daemon) to initialize the file.
The BMC Impact Portal settings are reset.
Configuration file and parameter definitions for BMC Impact Portal

Normally, you make changes to BMC Impact Portal component configurations through the user interface. However, you can manually edit three sets of configuration files that contain configuration information for the BMC Impact Portal module. These files pertain to these components:
I I I
BMC Impact Portal BMC Impact Service Model Editor BMC Impact Publishing Server
132
smsIwc/application.properties file and parameters
smsIwc/application.properties file and parameters

Table 34 describes the application.properties file in the smsIwc directory and its parameters. Table 34
Filename File path
application.properties file in smsIwc directory (part 1 of 2)

application.properties in the ..smsIwc folder BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsIwc
contains the general BMC Impact Portal configurations for component properties and user Description interface presentation Parameter name
com.bmc.sms.iwc.ui. recentitems.maxsize
Description
Default value
sets the maximum number of objects that can display 5 in the Recent Items group folder in the navigation tree of the BMC Impact Portal Refer to Changing the maximum number of recent items displayed on page 130 for more information.
com.bmc.sms.iwc.status. table
sets the columns that will display in the status and dashboard table views Refer to Configuring Dashboard Table View columns on page 124 for more information.
See the application. properties file.
com.bmc.sms.iwc.component. properties.generalProperties. properties
determines which general properties are displayed in See the application. the Configure tab for selected components properties file for more information. Refer to Configuring the general properties displayed on page 130 for more information. determines which columns in the events table are visible in the BMC Impact Portal module Refer to Configuring Events Table columns on page 125 for more information. See the application. properties file.
com.bmc.sms.iwc.event.table
com.bmc.sms.iwc.domain. notification.impact.type
sets the impact definitions included in a component notification e-mail You can designate multiple types of impact definitions, separating each by a comma. If no impact type is set explicitly, the default is BMC_BaseElement.
BMC_BaseElement
com.bmc.sms.iwc.domain. recentitem.RecentItemsFolderIcon
specifies the default icon for the Recent Items folder
ServiceComponent .gif
Chapter 4
133
smsConsoleServer/application.properties file and parameters
Table 34
application.properties file in smsIwc directory (part 2 of 2)

determines which columns that you can add to the tables and dashboards under the Status tab in the BMC Impact Portal module Refer to Configuring Status Table columns on page 126 for more information. See the application. properties file.
com.bmc.sms.iwc.status. table.providers com.bmc.sms.iwc.status. table.consumers com.bmc.sms.iwc.status. table.causes com.bmc.sms.iwc.status. table.existinggroup
com.bmc.sms.iwc.status. table.causal.components com.bmc.sms.iwc.status. table.components.small com.bmc.sms.iwc.event. table.minimumevents com.bmc.sms.iwc.event. table.maximumevents sets the maximum and minimum number of events retrieved per component instance; this information is displayed on the Events tab minimum: 5 maximum: 50

Table 35 describes the application.properties file in the smsConsoleServer directory and its parameters. Table 35
Filename File path Description
application.properties file in smsConsoleServer directory (part 1 of 3)

application.properties in the ..smsConsoleServer folder BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/sms ConsoleServer contains the configurations for report scheduling, report goals, and report data retention Description defines where the user configuration data is stored Default value no value; the location BOSS_HOME/s erver/all/data/s msConsoleServ er is used false; no backup file is saved
Parameter name
com.bmc.sms.configService. dataLocation
com.bmc.sms.configService. keepBackupFile
if configuration data is changed, defines whether a backup file is saved
com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Availability report 90.000% l.default. as a percentage SMS_CS_RT_AVAIL com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time to l.default. Repair (MTTR) report SMS_CS_RT_MTTR
300000 milliseconds (5 minutes)
134
Table 35

172800000 milliseconds (2 days) 172800000 milliseconds (2 days)
com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time Before l.default. Failure (MTBF) report SMS_CS_RT_MTBF com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time Before l.default. Service Impact (MTBSI) report. Goal line value is SMS_CS_RT_MTBSI=172800000 expressed in milliseconds cellName.timeout
sets the timeout value for data queries by the BMC 30 seconds Impact Portal to the specified cell. The timeout value is measured in seconds sets the number of times for the BMC Impact Portal to try to reconnect to the specified cell when it is unavailable cell (such as the cell or host is down) 60 tries
cellName.reconnect_attempts
cellName.reconnect_frequency cellName.polling_frequency <cellname>.encryption com.bmc.sms.icon.webdir
sets the polling cycle, measured in seconds, for the BMC 30 seconds Impact Portal reconnection attempt to the specified cell sets the polling cycle, measured in seconds, for the BMC 1800 seconds Impact Portal data query attempt to the specified cell sets whether is encryption is enabled (off or on) for the connection with the specified cell defines the path in which the icon images for service model components are maintained on /smsConsoleSer ver/images/obje cts/
com.bmc.sms.event. maxDelayedHours com.bmc.sms.consoleserver. retention.policy.age. SMS_CS_STATUS_EVENT com.bmc.sms.consoleserver. retention.policy.age. SMS_CS_RT_AVAIL com.bmc.sms.consoleserver. retention.policy.age. SMS_CS_RT_MTTR com.bmc.sms.consoleserver. retention.policy.age. SMS_CS_RT_MTBF com.bmc.sms.consoleserver. retention.policy.age. SMS_CS_RT_MTBSI com.bmc.sms.consoleserver. retention.policy.age. EG_EVENT com.bmc.sms.service.os. unrestricted
defines the maximum number of hours an event can be 24 hours delayed and will still be processed sets the length of time, in days, that report data is retained for each report and that event data is retained in the BMC Datastore 395 days
sets whether the Object Store communication service should run in unrestricted mode when connecting to the Remedy server
true
Chapter 4
135
internal.properties file and parameters
Table 35

sets whether the Object Store communication service filters are read-only objects sets whether the Object Store communication service filters classes and attributes that are marked SIM=false true true
com.bmc.sms.service.os. restrict.read.access com.bmc.sms.service.os. filtersim com.bmc.sms.remedy. serverHostName com.bmc.sms.remedy. serverPortNumber
identifies the host computer on which the BMC Remedy Action Remedy Action Request System host resides server host name lists the port number on which BMC Remedy Action Request System runs default
Table 36 describes the aggregator.properties file and its parameters. Table 36

Filename File path Description
aggregator.properties file
aggregator.properties BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/sms ConsoleServer contains the configurations for BMC Impact Portal communications with cells, including port number used for cell communications, encryption key, and encryption enablement Description sets the port number through which the BMC Impact Portal communicates with the BMC IM cell sets the encryption key used to communicate with the BMC IM cell communication encryption indicator (true or false) Default value 3783
Parameter name
com.bmc.sms. eventaggregator. jserverPortNumber com.bmc.sms.eventaggregator. jserverEncryptionKey com.bmc.sms.eventaggregator. jserverEncryptionEnabled
mc true

Table 37 describes the internal.properties file and its parameters. Table 37
Filename File path
internal.properties file
internal.properties BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties /smsConsoleServer contains the configurations for BMC Impact Portal communications with the BMC Impact Administration Server, including the port number used for BMC Impact Administration Server communications and parameters for building an IP address in a multi-homed environment Description Default value
Description Parameter name
136
Table 37
internal.properties file
sets the port number through which the BMC Impact Portal communicates with the Administration Server 3084
com.bmc.sms.ixs.port.number
com.bmc.sms.ixs.enable.bind.ip com.bmc.sms.ixs.bind.ip.address
sets whether the BMC Impact Portal can bind an IP false address on a multi-homed (multi NIC card) system specifies the IP address on a multi-homed system to 0.0.0.0 which the BMC Impact Portal is bound
Chapter 4
137
138
Chapter
5
140 142 142 142 144 145 146 148 149 150 152 156 157 158 159 160 163 164 165 165 165 169 172 172 172 173 174 174
Working with Infrastructure Management

5
This chapter presents the following topics: Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying and understanding the Details and Administer tab data . . . . . . . . . Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How a product component registers and communicates with the IAC . . . . . . . Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5
139
Default Infrastructure Management service model

The default Infrastructure Management model consists of logical groupings of BMC infrastructure applications and components. Upon installation certain components send registration events and become automatically registered with the Infrastructure Management model. Figure 14 Default Infrastructure Management service model
In the color scheme, green indicates that the object has registered with the Impact Administration cell. Grey indicates that the object is a logical grouping, components whose status is unknown to the Impact Administration cell. Only registered components are viewable in the Find window and services graph. The bold lines that connect the components represent the active impact relationships. The bold lines that connect the components represent the active impact relationships. The arrows indicate the direction (provider to consumer) of the event feed. A dotted line indicates that the relationship is inactive. The following versions of BMC components register with this service model. They can be added as components instances to the respective logical group. Table 38
Group Id 100 101 102 103
Supported application groups (part 1 of 2)

Name EM_CELL EM_SERVER_1 EM_SERVER_2 SIM_CELL
140
Table 38
Group Id 104 105 106 110 111 112 120 121 122 123 124 125 126 127 130 131 132 133 134 140 141 142 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164
Supported application groups (part 2 of 2)

Name SIM_SERVER_1 SIM_SERVER_2 IAC (Impact Administration Cell) BMC Impact Portal Application Server IAS (Impact Administration Server) PS (BMC Impact Publishing Server) Adapter
LOG_FILE_ADAPTER SNMP_ADAPTER WINDOWS_EVENT_ADAPTER SYSLOG_ADAPTER TCP_ADAPTER TELNET_ADAPTER UDP_ADAPTER IIP7 IIP3 IIOVO IINNM IITIVOLI DBGW IIARS
IBRSD
BPM ARS ARS_SD CMDB BiiZ BIM SLM TM_ART TM_RCA TM_REM
EM_Server_Standby SIM_Server_Standby
ADAP_SERVER_1 ADAP_SERVER_2 ADAP_CELL
Chapter 5
141
Roles and permissions
Roles and permissions

The following group roles have full write permission to the components and features of the Infrastructure Management subtab:
I I
Service Administrators Full Access
Only members of either group can view the Infrastructure Management subtab. Refer to Defining permissions on page 83 for information on assigning roles.
Walkthrough
This section provides a walkthrough of Infrastructure Management, highlighting its main features. You can use this walkthrough to learn about and become familiar with Infrastructure Management.
Displaying the out-of-the-box real-time service model

Infrastructure Management automatically deploys a BMC infrastructure service model, called BMC Impact Solutions. It consists of logical groupings of BMC services and applications, together with registered components that send all relevant information and latest statuses. The out-of-the-box service model reflects the realtime states of the registered components.
To display the service model 1 In BMC Impact Explorer, click the Administration tab. 2 In the icon bar at the top of the navigation area on the left, click the Infrastructure
Management icon (the wrench or spanner icon).
3 Under Find Infrastructure Components in the bottom pane of the navigation area,
choose Find to list the services and applications. The logical groupings of components and applications are displayed, along with registered components.
142
Displaying the out-of-the-box real-time service model
Alternatively, you can open the BEM Infrastructure Management group to display the navigation tree, as shown in Figure 15 on page 143. Figure 15 Infrastructure Management navigation pane
4 Locate the BMC Impact Solutions object in the Find list, and then, using the mouse,
click and drag it into the graph viewing area in the top right pane to reveal the service model. You can also choose to select BMC Impact Solutions in the navigation tree under BEM Infrastructure Management to display it in the graph viewing area. You may need to click the Orientation icon at the top of the graph viewing area to reposition it vertically.
The default service model should look similar to the example in Figure 16 on page 144.
Chapter 5
143
Sampling context-sensitive information
Figure 16
Default service model BMC Impact Solutions (with active services)
The services and applications are color-coded to reflect their real-time status. You can check the multi-colored Status legend to see the status associated with each color. The grey-colored icons represent logical groupings, components whose status is unknown to the Impact Administration cell.
Sampling context-sensitive information

The Infrastructure Management interface offers a range of context-sensitive information that you can access from right-click pop-up menus and multi-layered notebook tabs. For example, you can expand the model and select a component under the SIM Cells heading.
I
Click the leaf component under SIM Cells to select it. Click the Details tab. Click the subtabs such as General, Status, Priority and Cost, Advanced, Related Components, SLM, and Schedule. These tabs provide component specific information. Click the Administer tab. Click the subtabs such as Configuration, Logs, and Support Package. You can access the Workload and Components tabs if you have selected either a SIM or an EM cell server. Click Edit Component in the Details=>General tab and change a property of the component.
144
Managing files on remote systems
Managing files on remote systems

From the Infrastructure Management interface, you can edit and save the configuration and log files of other SIEM applications and services, both of which are running on remote systems.
To edit and save configuration files 1 Click the leaf component under a service or an application, such as SIM Cells, to
select it.
2 From the Notebook tabs, choose Administer=>Configuration.

The drop list reveals the configuration files of the selected component.
3 To modify a file, select it from the list, and click Edit. The Credentials dialog box
displays.
The Additional command credentials check box applies mainly to UNIX systems, where you may need to log into the system under one user account, but then switch to another user account (for example, root) to execute the action.
4 In the dialog box, enter the credentials of the remote system, and click OK.
The configuration file is displayed in the editor.
Chapter 5
145
Packaging support files
5 Edit the file. 6 When youre done, you can click either of the following:
I I
File=>Save a Copy to save a copy of the file to your local system File=>Update Original to update the file on the remote system
To edit and save log files 1 Click the leaf component under a service or an application, such as SIM Cells, to
select it.
2 From the notebook tabs, choose Administer=>Logs.

The drop list reveals the log files of the selected component.
3 To modify a file, select it from the list, and click View. 4 In the dialog box, enter the credentials of the remote system, and click OK.
The log file is displayed in the editor.
5 Edit the file. 6 When youre done, click File=>Save a Copy to save a copy of the file to your local
system. You cannot update a log file on a remote system. You can save it only to the local system.

You can package selected debug files to help troubleshoot customer cases. Infrastructure Management automatically packages the selected files into a zipped file.
146
To package support files 1 Click on the leaf component under SIM Cells, for example, to select it. 2 From the Notebook tabs, choose Administer=>Support Package.
3 In the Destination field, enter the file path where the package should be saved on
the local system. You can use the Browse button to navigate to the directory. The file name of the support package is created automatically.
4 Optional. Enter a tracking number in the Issue Number field. 5 Optional. Enter a description of the issue in the Description field. 6 Click Create Package. 7 Enter the credentials of the remote system from which you are retrieving the files.
Chapter 5
147
Launching remote actions
A pop-up progress indicator shows the status of the retrieval. If it completes successfully, go to the specified directory and review the contents of the zipped package. The file contents vary based on the type of component. Here are typical files for a SIM server component.
8 Repeat steps 1 through 7 for an Impact Administration Server component,

verifying that the file contents of its zipped package are different from those of the SIM Cell.
Launching remote actions

From the Infrastructure Management interface, you can execute actions through the right-click pop-up menus on components and applications that are running on remote systems.
To launch remote actions

For this exercise, you must have a registered cell component installed on a remote system.
1 Right-click the leaf component under SIM Cells or EM Cells to select a cell residing
on a remote system.
2 Choose Actions to display a list of all possible actions for that component.
3 Choose Stop Cell Server Process, click Stop, and enter the logon credentials for the
remote system. If the selected component resides on an MS Windows system, your login credentials should have administrative rights to the system. The Additional Command Credentials are needed check box is disabled.
148
Common Infrastructure Management tasks
When the component on the remote system has stopped, its status changes to Unavailable.
4 Return to the Infrastructure Management interface, right-click the SIM Cells

component to display the pop-up menu, and choose Actions=>Start Cell Server
Process.
5 Verify that the cell has startedfor example, you can execute an mcstat command
to check the cells status. Then you can verify that the status of the selected component is changed to OK.
6 Repeat steps 1 through 5 for a BMC Impact Administration Server (IAS)

component. The actions permitted on this component are different from those of the EM or SIM Cell component. They are limited to Stop Process and Start Process.
You can also launch remote actions for selected components by clicking one of the Action toolbar icons of the Infrastructure Management view.
Depending on the type and state of the selected component, you can choose from among the following actions:
I I I I I I I
Start Cell Server Process (Start) Stop Cell Server Process (Stop) Restart Cell Server Process (Restart) Pause Events Admittance (Pause) Resume Events Admittance (Resume) Set to Active Set to Standby
Different actions are enabled based on the status and type of component. For example, if a component in an unknown state is already started and you choose Actions=>Start, you receive a status message notifying you that the component is started already. Refer to Remote actions on page 174 for more information.
Common Infrastructure Management tasks

This section describes the most common Infrastructure Management tasks. For the most part, you manipulate objects in the Infrastructure Management interface just as you would in the other BMC Impact Explorer Services tab views.
Chapter 5 Working with Infrastructure Management 149
Navigating the interface

In the Administration tab view, select the Infrastructure Management subtab, represented by the wrench icon at the far right in the icon row atop the navigation pane:
In the Of type drop-down list, click All if its not already displayed. Click Find to open the list of logical groupings and registered components in your infrastructure. Logical groupings and registered components are depicted by different icons: Table 39
Icon
Icon listing for infrastructure management model (part 1 of 2)

Definition logical services grouping IAS (Impact Administration Server) SIM cell SIM cell server 1 SIM cell server 2 (high availability implementation) SIM cell server standby (high availability implementation) EM Cell EM cell server 1 EM cell server 2 (high availability implementation) BEM cell server standby (high availability implementation) OVO Fetcher BMC Portal Server
150
Table 39
Icon
Icon listing for infrastructure management model (part 2 of 2)

Definition BMC Publishing Server Integration for BMC Remedy Service Desk
Select the BMC Impact Solutions grouping, which contains the default infrastructure model, and drag-and-drop it on the graph viewing area. You may need to select the Orientation icon to display it along a vertical axis.
Multiple graphs
You can display multiple graph views. For example, you can select registered components from the Results list in the navigation pane, and drag-and-drop them on the graph viewing area, creating new graph views. You can switch from one view to the other by selecting the tabs at the top of the graph viewing area.
Navigation tree
To help organize your model, you can display and manipulate the grouping and component hierarchy in the navigation tree view under the Infrastructure Management heading. You can select objects in the navigation tree and display them in the graph viewing area.
You can drag objects from the graph viewing area and drop into the navigation tree, creating a navigation link between the two.
TIP
You can press the CTRL or SHIFT key and then click an object in the navigation tree to display the object in the graph viewing area without closing any displayed objects.
Chapter 5
151
Displaying and understanding the Details and Administer tab data
You can create customized subgroups under the Infrastructure Management heading. After selecting the heading, right-click to open the Add a sub group menu item.
After you define your group, you can drag and drop component objects into it.

The Details subtabs display information that identifies the characteristics of the selected component and returns its status. They let you perform common BMC IX actions, such as changing provider-consumer relationships between components. The Administer subtabs display specific infrastructure information and let you perform unique infrastructure actions, such as editing configuration and log files and collecting debug files for troubleshooting. To view data about an object in the interface, first select it. Then you can scan the corresponding subtabs under Details and Administer. To view information on one of the Administer tabs, the selected object must be a registered infrastructure component, not a greyed-out logical services group icon.
Details tab data

General
In the General subtab, you can view the name, class, and subtype of the selected object. Depending on the subtype, you can also view other slot values, as described in Table 40.
152
Table 40
Slot
Slot values: Details: General subtab

Description contains a Boolean Yes/No indicator that says whether the selected component object can be edited in BMC IX. Infrastructure Management only contains objects that are not published. Therefore, Editable Here is always set to Yes in Infrastructure Management.
Editable Here
Master Repository
specifies the data source of the component object. For example, component objects that originate from a direct feed source, such as BMC IX, mposter, or an MRL, are designated in this format: CellcellName. The default name for Infrastructure Management is Cell_Admin. the current state of the object, which helps to determine its status, its icon shape, the icons color, as well as which actions can be performed against the object. This slot value is updated whenever the component changes its state, from start to stop, from start to paused, from stop to start, and so forth. indicates whether a component, such as a cell server or IAS, is standalone or, in an HA pair, either primary or secondary. identifies a selected cell component as Service Impact Management, Event Management, Impact Administration, or Integration. for a selected cell component, the IP address of the standalone cell server or of the primary cell server in an HA pair. for a selected cell component, the port number of the standalone cell server or of the primary cell server in an HA pair. for a selected cell component, the IP address of the secondary cell server in an HA pair. for a selected cell component, the port number of the secondary cell server in an HA pair.
Run State
Role Cell Type Cell Server 1 Cell Server 1 Port Cell Server 2 Cell Server 2 Port
From the General subtab, you can click Edit Component to open the Edit Service Component dialog in which you can modify the components properties.
Status
In the Status subtab, you can view the applicable status levels of the component: Service Level Agreement, manual status, maintenance mode, and computation statuses.
Priority and Cost

Under the Priority and Cost subtab, you can view the schedule status, impact priority, and impact cost.
Chapter 5
153
Advanced
In the Advanced subtab, you can view information on identification, creation and modification time, and read/write permissions for groups for the selected object.
Related Components
In the Related Components subtab, you can retrieve status causes, possible problems, providers, and consumers of the selected component type. You can modify the relationship by selecting Edit Relationship..., which opens the Edit Relationships dialog where you can add, modify, or remove relationships. Using the right-click menu options, you can highlight a retrieved component in the list, and add a link to the navigation tree by choosing the Add Navigation Link option. You can view the events associated with the component. This subtab also lets you view other components that have relationships with the selected component.
SLM
In the SLM subtab, you can list and view the details of Service Level Management agreements assigned to the component. This subtab view is not available for the Admin cell (IAC).
Schedule
In the Schedule subtab, you can view the times when the component is in service together with its priority costs when it is in service and when it is out of service. This subtab view is not available for the Admin cell (IAC).
Administer tab data

Configuration
The Configuration subtab lists the editable configuration files of the selected component. You can retrieve these files, even those associated with components on remote systems. Click Edit. Then enter the logon credentials for the system where the component resides. (On UNIX, your login account must have permission to access the target system. On MS Windows, you must have administrative privileges on the system.) The file opens in a default text editor.
154
You can edit any supported configuration file of an infrastructure component. The type of file varies with the component, but the files include:
I I I I I I I
mcell.dir .conf files filter files selector files mapping files trace.conf files cell_info.list
You should know the parameters of the file before trying to edit it. Refer to the components respective documentation. You can save the edited configuration file to a local or remote system. If saving to a local system, you can specify a different file path. If saving to a remote system, you update the configuration file in its current directory path. You cannot save it to a different file path.
Logs
Similar to configuration files, you can open and annotate log files of components on local systems in the Log subtab. You cannot save an edited or update a viewed log file to a remote system, however. You must save it to the local system.
Support Package
In the Support Package subtab, you can prepare a zipped package of predefined support files for troubleshooting purposes. See Creating the support package on page 169 for more information.
Workload
The Workload subtab dynamically tracks the event activity of the cell server component. It presents counts, averages, and percentages of different event actions, such as sent, received, dropped, and removed. You can refresh the table by clicking the Refresh button. This subtab view is available for SIM cell servers, but not for BEM cell servers.
Components
The Components subtab dynamically tracks the component instances that send events to the selected object. You refresh the table by clicking the Refresh button. This subtab view is available for SIM and BEM cell servers.
Chapter 5
155
Editing infrastructure relationships
Editing infrastructure relationships

To open the Edit Relationships dialog box, select an infrastructure object in the graph area. Then do one of the following:
I
I I
Select the Related Components subtab from the Details notebook tab. Click the Edit Relationship... button. Click Edit => Edit Relationship. Click the Edit Relationship toolbar icon.
The Edit Relationships dialog box is opened. Figure 17 on page 156 shows an open Edit Relationships dialog box with a selected SIM cell opened for editing in the Edit This Relationship subdialog. Figure 17 Edit Relationships dialog with Edit This Relationship subdialog
The Edit Relationships dialog box contains the following fields: Table 41
Field Component Name Related Component Type Relationships
Edit Relationship dialog: field descriptions (part 1 of 2)

Description name of the selected infrastructure component identifies the infrastructure component subtype that has a consumer or provider relationship to the selected component and for which you want to search lists the consumer, provider, or both consumer and provider relationships of the selected component subtype and component
156
Creating logical components
Table 41
Field
Edit Relationship dialog: field descriptions (part 2 of 2)

Description identifies the infrastructure object related to the selected component indicates the event flow of the object relationship. A consumer direction indicates that the component object receives events and data from the selected component. A provider direction indicates that the component object sends events and data to the selected component identifies current state of the relationship: active or inactive specifies the class that contains the relationship type identifies the status propagation model used for determining the propagated status from the providers main status indicates whether you can edit the object in BMC IX
Component Direction
State Type Propagation Model Editable
You can search on component types by selecting an Impact Administration subtype from the drop-down list. When you click Search, it retrieves the relationships associated with the selected subtype. Select an item in the Edit Relationships dialog, and right-click to open the pop-up menu. You can perform actions common to all object relationships: View Service Impact Graph, View Events, Edit Component, Add Navigation Link, and Add Relationship. You can edit any of the components relationships by selecting it and then choosing the Edit Relationship button at the bottom of the dialog. The Edit This Relationship subdialog contains the following fields: Table 42
Field Consumer/Provider indicator Type of Relationship Relationship Status Status Weight Description
Edit This Relationship subdialog

Description indicates the directional flow of the relationship between the selected component and the component subtype. You can modify the relationship Direct, Increasing, Decreasing, Just_Info, or Just_Warning Active or Inactive weight (numeric value) of a relationship used while calculating the status using weighted cluster mode Summary description of the relationship
Creating logical components

You can add logical components to the Infrastructure Management service model. Logical components in this context refer to components that do not have a predefined registration event associated with them, as do the BMC infrastructure components listed in Table 38 on page 140.
Deleting components
Although logical components are not registered with the IAC and therefore do not provide real-time status information, they can help to complement the BMC infrastructure model. For example, you can add logical integrations and server processes to the model to represent an idealized infrastructure environment.
NOTE
The names of logically created components do not display in Korean in the graph viewing area while its component object does.
Deleting components
You can delete both logical service groupings/objects and live, registered objects from the Infrastructure Management service model. To organize your service model around its real-time components, you can delete logical groupings that do not have registered components associated with them. Generally, you should delete the leaf objects, not objects that lie between other objects. If you delete objects that lie between other objects, some objects that should be deleted because of relationship associations with the other objects will nonetheless remain. BMC recommends that you do not delete components that have been registered automatically with the Infrastructure Management service model. However, if you delete a live, registered object, it is removed from the Infrastructure Management service model, and an event of the class Service Model Component Delete is sent to the IAC.
TIP
You can recover a deleted registered object by modifying the DATA/ADMIN_DATA/ ADMIN_REGISTRATIONS table of the IAC in the Administration tab view.
You change the enable parameter for the specific component from NO to YES in the Edit tab. Then you restart the component to reregister it.
158
Usage reporting
Usage reporting
NOTE
The File=>Usage Report menu option is only available in the Administration view. It does not display in the Events or Services view.
In the Administration view, you can choose the File=>Usage Report menu option to display and print a report that lists the BMC components which are registered with the BMC Impact Administration cell. These components include:
I I I I
SIM and BEM management servers SIM and BEM standalone cells SIM and BEM high availability cells integrations I BMC Impact Integration for HP Openview Network Node Manager I BMC Impact Integration for HP Openview Operations I BMC Impact Integration for BMC Remedy Action Request System I Integration for BMC Remedy Service Desk I BMC Impact Integration fro PATROL 3.x I BMC Impact Integration for PATROL 7.x
NOTE
By default, users belonging to the user group Full Access, Service Administrators, Service Managers, or Service Managers - Senior can access these reports.
You can save and print the report in any of the following formats:
I I
plain text file comma-separated values (CSV) for tabular data presentation
To display and save a usage report

Be sure that you are connected to the Admin cell. Otherwise the Usage Report... option is unavailable.
1 In the Administration view, choose File=>Usage Report. 2 You can choose to save the list in .csv or .txt format or to print the display screen.
Chapter 5
159
Executing remote actions

You can manage the infrastructure objects from the interface. Select the object, rightclick to open the pop-up menu, and choose Actions to display a list of the available actions. Figure 18 Actions right-click menu
Depending on the current state of the component, not all actions are available. You can also launch remote actions from the toolbar icons. Depending on the type of component and its current state, a range of actions are available to you. See Remote actions on page 174 for an explanation.
NOTE
You can connect to remote systems from the Configuration and Support Package subtabs of the Administer notebook tab.
Considerations when working with high availability cells

Your remote actions are restricted when working with a high availability (HA) configuration in which the primary cell server is down and the secondary cell server is in a passive state.
I
When the Impact Administration cell (IAC) is in an HA configuration, do not launch a remote action against any components in the Infrastructure Management view when the IAC primary server is down and its secondary server is in a passive state. In this case, the IAC rejects the actions.
NOTE
An IAC cell that is in standby mode is shown in yellow.
160
When BEM or SIM cell servers are in standby mode, you can perform only the permitted actions on them.
When the secondary cell server is in an active state while the primary cell server is down, which is the situation depicted by SIM Cell Server 1 and SIM Cell Server 2 in Figure 19 on page 161, the range of permitted actions increases. Figure 19 High availability (HA) view: two cell servers
Special considerations for UNIX systems

If the Impact Administration Server resides on a UNIX or Linux system and the target application resides on a Windows system, then you must configure the SSH or Telnet protocols on the Windows system to enable remote action. See Configuring BMC Impact Administration server to support remote actions on page 107 for more information. When launching remote actions against components that reside on UNIX systems, you may need to log in under one account to access the system and then log in under a separate account to launch the command. For example, you may not be able to log into the UNIX system as root. Instead, you log in under a separate user account. However, to execute the command, you may have to log in as root or as another user with the permission to execute the command. When you select the Additional command credentials check box in the Credentials Information dialog box, the dialog box expands to provide you with two sets of login credentials to handle this situation.
Chapter 5
161
Considerations when working with OVO adapter cells

Remote actions vary when information is fetched from an OVO adapter. An OVO adapter cell registers with the Admin cell and is listed under CI Sources and ADAP_Cell groups in the navigation tree under the Admin tab. The fetcher collects information from the OVO adapter in the form of nodes, node groups, or node hierarchies. The fetcher then maps the node attributes to the Impact Manager slots and sends events for the creation of corresponding CIs and relationships to the adapter cells, which in turn create the model. Figure 20 Actions right-click menu for OVO adapter cells
Setting the OVO User/Password

This action sets the user name and the password for the CI adapter remotely in the CI adapter configuration files. The user name is set in the <MCELL_HOME>\etc\ovcifetcher.conf file as USERNAME=<username> and the encrypted password is stored in <MCELL_HOME>\etc\.pass file.
Initialize OVO Publication

This action promotes the CIs from the adapter cell to the CMDB and publishes them to the SIM cell. In other words, it triggers the Publication Server for publication.
162
Fetch From OVO

All the fetch options from OVO are consolidated into this remote action. This action allows you to fetch the following from the OVO adapter.
I
All: Fetch all the nodes in the Node Group Bank, Node Hierarchy Bank, and Node Bank from the OVO.

Use the Reload menu command to access the commands for reloading a cells configuration. The Reload => All menu option is the equivalent of the mcontrol commands reload all option. This means the default data from the cell's KB\data directory is reloaded, taking it back to a default out of the box data state. This removes any custom data that the customer has created. However, the other options, such as Reload => Knowledge Base, Reload => Directory (mcell.dir), etc., do not reload data.
To reload all of the cell configuration 1 Right-click a cell. 2 Select Reload => All.
All configuration files and the KB are reloaded.
1 Right-click a cell. 2 Select Reload => Knowledge Base.

The KB is reloaded.
To reload the directory 1 Right-click a cell. 2 Select Reload => Directory (mcell.dir).
The mcell.dir file is reloaded.
Chapter 5
163
Forcing event propagation
To reload cell configuration 1 Right-click a cell. 2 Select Reload => Cell Configuration.
The configuration files mcell.conf, mcell.propagate, and mcell.modify are reloaded.
To reload trace configuration 1 Right-click a cell. 2 Select Reload => Trace Configuration.
The mcell.trace file is reloaded.
Forcing event propagation

You can use the Propagate Events command to force the selected cell to send the contents of the destination buffers to one or all its destination cells immediately.
To force propagation to all target cells 1 Right-click a cell. 2 Select Propagate Events => All Destinations to force propagation of the buffer
contents to all target cells.
To force propagation to a selected target cell 1 Right-click a cell. 2 Select Propagate Events => Select Destinations. 3 In the Propagate dialog box, specify the target cell to which you want to propagate
the buffer contents.
4 Click OK.
164
Collecting metrics
Collecting metrics
Use the Metrics Collection menu command to access the commands for working with metrics.
To turn metrics collection off 1 Right-click a cell. 2 Select Metrics Collection=> Disable. To reset collection counters 1 Right-click a cell. 2 Select Metrics Collection => Clear Values.
The collection counts are reset to 0.
Executing other actions

Where appropriate for the component, you can perform the actions that are available in the Services tab view. These actions include
I I I I I
viewing the graph of a selected component and its relationships viewing events associated with the selected component setting manual status and maintenance mode adding links to components from container folders refreshing the graph view after making an edit to a component or relationship
Configuring the audit log

By default, Infrastructure Management automatically maintains an audit log of all remote actions that an administrator performs on remote hosts. The audit log uses the following format:
TIME_STAMP LOG_LEVEL EXPLANATION IAS_USER OS_USER SUB_TYPE:OBJECT ACTION_ID
Table 43 on page 166 describes the audit log parameters:
Chapter 5
165
Table 43
Audit log parameters

month, day, year, hour, minute, and second that the log entry was created. Uses the format mm/dd/yyyy hh:mm:ss the severity level of the logged action. Valid values include
I I
Audit log parameter Description TIME_STAMP LOG_LEVEL
INFO: informational message SEVERE: error message
A typical SEVERE message documents the error exceptions that occur during the execution of a remote action, such as Unable to save file on remote machine IAS_USER OS_USER SUB_TYPE current BMC IX user name that has logged on and connected with the Impact Administration server user name that logs into the remote hosts operating system. This is the user name under which the action is executed on the remote host the component or application type on the BMC IX administrator is performing the remote action. In version 7.2, Infrastructure Management supports the subtypes listed under Supported component or application types on page 166 user-specified value in the Object slot of the component or application on the which remote action is being executed unique Id associated with the remote action. This unique Id is defined in the corresponding actions.xml file stored on the computer where the BMC Impact Administration Server resides. For example, the ImpactManager.xml file is an actions file that applies to BEM and SIM cells. It is stored under the IMPACT_SOLUTIONS_HOME/server/data/admin/actions folder on the IAS computer short text description of the logged action
OBJECT ACTION_ID
EXPLANATION
Supported component or application types

Infrastructure Management supports the following types in this product version:
I I I I I
EM_CELL EM_SERVER_1 EM_SERVER_2 SIM_CELL PORTAL SERVER
I I I I I
SIM_SERVER_1 SIM_SERVER_2 IAC IAS ADAPTERS
I I I I I
IBRSD BEM_SERVER_STANDBY SIM_SERVER_STANDBY PS INTEGRATIONS
166
Sample logs
A sample audit log for a remote startup action on a SIM cell might look as follows:
Mon 07/23/2007 16:50:15 INFO iasuser superuser SIM_CELL:PUNE_CELL start_im_windows Executing action
Similarly an audit log for a remote startup action on an IAS server might look like this:
Mon 07/23/2007 16:52:10 INFO iasuser superuser IAS_Server:PUNE_IAS_Server start_IASserver_window Executing action
Sample audit logs for the remote actions of restarting and stopping a SIM server cell follow:
Tue Aug 14 20:14:06 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun01 restart_im_WINDOWS Executing action. Tue Aug 14 20:14:40 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun01 stop_im_WINDOWS Executing action.
Configuration parameters
These audit logs are stored by default under the IMPACT_SOLUTIONS_HOME/server/log/ias directory on the Impact Administration server. You can configure the audit log by modifying the properties in the ias.properties file shown in Table 44 on page 168.
Chapter 5
167
Table 44
Property
Audit log IAS properties

Description Boolean true/false value that indicates whether auditing is enabled. The default is true.
com.bmc.sms.ixscomm.util.auditLogEnable
com.bmc.sms.ixscomm.util.auditLogFilename specifies the file path and name of the audit log file, using the %g indicator to show that the audit log files are cycled through a numerical sequence. For example, if auditLogFilename=AuditLog%g.log auditLogFilecount=10 auditLogLimit=5000 then the initial audit log is assigned the name AuditLog1.file. When its file size reaches 5000 bytes, a new audit log is generated with the same name but incremented by one: AuditLog2.file. As each log reaches the maximum size, a new audit log is created and incremented by one. When the maximum log file count (10 in this example) is reached, then the process repeats itself because only one cycle of logs is maintained. The first audit log of the new cycle starts at 1 (AuditLog1), overwriting the existing file. As new logs are generated in the new cycle, they overwrite the existing ones in sequence. By default the audit logs are stored in the IMPACT_SOLUTIONS_HOME/server/log/ias directory. You can specify another directory path in this parameter value: for example, auditLogFilename=log/AuditLog%g.log, provided that the specified directory exists under IMPACT_SOLUTIONS_HOME/server. com.bmc.sms.ixscomm.util.auditLogLimit size in bytes of the audit log file. The default is 5000 bytes (approximately 4.88 kilobytes). While there is no predefined maximum size, BMC recommends that each log file not exceed 5 MB.
com.bmc.sms.ixscomm.util.auditLogFileCount indicates the number of audit log files that are cycled through during a rotation. After the specified number is reached, the cycle repeats itself, overwriting in sequence the log files of the previous cycle. The default is 1.
After you modify any of the properties in the ias.properties file, you must restart the Impact Administration server.
168
Creating the support package

You can create a support package for troubleshooting purposes by collecting files from remote systems and saving them to a specified file path on the local or a remote system. The support package contains the following files:
I I I I I I I
.dir files .conf files filter files selector files mapping files trace files trace.conf files
In addition, it contains
I
default support files These are internal files of the infrastructure application. They are not included in the other categories. They vary among the applications, but they include .baroc, .mrl, .wic, and .cmd files. Generally, for a cell server, this package contains the files of its KB directory and its log directory. You can choose which files to include. They also include a sysinfo.text file that captures active port connections, OS and hardware configurations, and network card details. The absolute file path to each file is included.
additional support files This is a customizable list of files that the user can edit by adding or deleting files to or from the support package. It is designed to enable the user to add other files to the support package.
Specifying your support files

You can specify which support files you want to receive by editing the corresponding slot in the Edit Service Component dialog for the selected component. To specify which support files to include, select the component and choose Edit=>Edit Component or choose Edit Component from the right-click pop-up menu. The Edit Service Component dialog is displayed. Scroll down the list of slots. You can specify values in the slots specified in Table 45.
Chapter 5
169
Your support files should be on the system on which the component is running. Enter the full path to the file you want to include. If you are adding multiple files, separate the complete file paths with commas. There is no limit to the number of files that you can add. Table 45
Slot Additional Support Files Configuration files Dir files Filter files Map files Selector files Trace conf files Trace files
Slots for specifying support files

Description full path to other support files that you want to include full path to configuration files (.conf) full path to *.dir files, such as mcell.dir or admin.dir full path to *.filter files full path to *.map files full path to *.selector files full path to the *.trace file full path to the trace logs
To compile your support package, choose the Administer=>Support Package tab. Browse to the destination folder where you want to save the list of configuration and log files, and select it. You can enter the issue number (maximum of 16 characters) if one has been assigned.
WARNING
MS Windows does not support the creation of files that have any of the following special characters in their file names: , \, /, ?, *, ", |, <, >. If the BMC Impact Explorer is installed on MS Windows, do not enter any of the special characters in the Issue Number slot. Otherwise, the support package creation fails.
If you do enter the issue number, assign it as a prefix to the support package name. You can type a short, but informative, description of the package (maximum of 256 characters). Then click Create Package. The file name of the support package file follows this format:
OBJECT_NAME_support_package_TIMESTAMP.zip
The OBJECT_NAME value is taken from the object slot of the selected component. The time stamp is in the format: MMDDYY_HHMMSS.
170
UNIX processing note

Under UNIX, it may take several minutes to create a support package. Two causes can contribute to the delay in processing:
I
whether the component for which you are creating the support package resides in a different domain from the system on which you are running BMC IX. If it does lie in a different domain, expect a delay. the size of the zipped or tarred file. The greater the size, the longer the delay, especially as the file approaches 500 kb or larger.
Reviewing the audit log of the support package

Internally, the process of building a support package consists of these actions: 1. saving the OS-based compression utility (zip or zip.exe) to the remote system 2. creating the support package 3. removing the OS-based compression utility from the remote system 4. executing the get-file action to retrieve the support package from the remote system and putting on the system where IAS resides 5. getting the binary file from the IAS system to the local system where BMC IX resides Because this is a remote action, the audit log captures the process. If the support package creation is a success, you receive an audit log message that looks similar to the following MS Windows example:
Fri Aug 17 12:49:25 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhepun-01 saveRemoteFile : zip.exe Executing action. Fri Aug 17 12:49:28 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhepun-01 create_support_package_WINDOWS Executing action. Fri Aug 17 12:49:30 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhepun-01 remove_zip_WINDOWS Executing action. Fri Aug 17 12:49:31 IST 2007 SEVERE user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 remove_zip_WINDOWS Stderr returned with some error. Fri Aug 17 12:49:32 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhepun-01 get_file : Test1_support_package.zip Executing action. Fri Aug 17 12:49:33 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhepun-01 getBinaryFile : Test1_support_package.zip Executing action.
In a successful support package creation, the audit log does return an error message:
Fri Aug 17 12:49:31 IST 2007 SEVERE user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 remove_zip_WINDOWS Stderr returned with some error.
You can ignore this error because users can still retrieve the zipped support package automatically from the remote system without any manual intervention.
Background to Infrastructure Management
If you receive a SEVERE error message on any of the other support package actions, such as saveRemoteFile, create_support_package, get_file, and getBinaryFile, it indicates that the support package creation failed. Discard it, and try again.
Background to Infrastructure Management

The information in this section describes some of the internal workings of Infrastructure Management.
How a product component registers and communicates with the IAC

To register with the IAC, the component or application sends a configuration information event. This configuration event contains certain required slots such as mc_event_model_version, mc_object and mc_tool, os_class, and so forth. The component or application sends the configuration information event upon each startup or change in its configuration. After it registers with the IAC, the application or component sends status information such as startup, shutdown, and error events.
NOTE
All event information should be compliant with the event format strictures of version 1.1.00 of the Common Event Model (CEM). See the Common Event Model appendix in the BMC Impact Solutions Knowledge Base Development Guide for more information.
Registering a cell with the Admin cell

A cell is automatically registered with the Admin cell whenever you use the Installshield installation and specify an Impact Administration Server during the installation routine. However, when you add a cell using the mcrtcell CLI, you need to register the cell with the Impact Administration Server using the iadmin -ac command.
172
Recreating an Admin cell
To manually register a cell with the Admin cell 1 Add the cell using the mcrtcell CLI, as in the following example:
mcrtcell -p 2008 -as sparkles_cell
2 Next, use the iadmin -ac command to register the cell with the Impact
Administration Server. From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin -ac command as in the next example:
iadmin -ac name=sparkles_cell:key=mc:primaryHost=moondog:primaryPort=2008: failoverHost=suncat:failoverPort=2008:environment=Production: usergroups=*
The cell is added automatically to the IMPACT_SOLUTIONS_HOME/server/conf cell_info.list of the Impact Administration Server. It is also automatically added to the IMPACT_SOLUTIONS_HOME/server/data/admin admin.dir file of the Admin cell, as in the following example:
cell cell cell moondog_10 mc Admin mc sparkles_cell mc moondog.bmc.com:1828 moondog.bmc.com:1827 moondog.bmc.com:2008 suncat.bmc.com:2008
In the Event view, you see that the cell you have registered sends a registration event to the Admin cell.
Recreating an Admin cell

If you accidentally remove your Admin cell, you can recreate it through the mcrtcell CLI using the -aa switch, as in the following example:
mcrtcell -aa -p 10011 Admin
In this example, you create an Admin cell with the name Admin and assign it to port number 10011.
Chapter 5
173
Unregistering with the IAC
Unregistering with the IAC

You cannot formally unregister a component. To remove a component from the Infrastructure Management model, you must manually delete it. It is removed from the Infrastructure Management interface, but not from the model contained in the IAC. For example, its .log and .conf files persist in the IAC. The application or service, however, is no longer operational.
Remote actions
While events flow only from the components to the Infrastructure Management interface, administrators can initiate actions on the components from the interface. Depending on the type of component and its status, you can initiate several actions on the local or remote component.
How context-sensitive remote actions are processed

The current state of a selected component is shown in its run_state slot (Run State), which you can view in the Details=>General subtab in the Infrastructure Management tab. The different run_state values are described in Table 46 on page 174: Table 46
unknown active unavailable started stopped paused passive
run_state values for components

Description state of the component cannot be determined indicates that the cell is the active server component of an HA relationship the connection with the component is disrupted or the component is down the component is online; unable to determine if its the active component in an HA relationship the component has sent is stopped and has sent a status event indicating that it is stopped the component is in maintenance mode the secondary cell in an HA relationship is in standby mode
run_state value
The current run_state of the component determines which context-sensitive actions are disabled or enabled from the Actions option on the right-click menu. Table 47 on page 175 indicates which menu options are enabled (Yes) or disabled (blank) for each run_state of a normal cell or a primary cell in an HA configuration.
174
Remote actions
Table 47
Component state and menu options for a normal or primary cell in a high availability configuration
Menu options Start Cell Server Process Yes Yes Yes Yes Yes Yes Yes Yes None Yes Yes Yes Yes Stop Cell Server Process Restart Cell Server Pause Events Resume Events Process Admittance Admittance
run_state state_unknown state_active state_unavailable state_started state_stopped state_paused state_passive
Set to Standby
Set to Active
NOTE
If a component in an unknown state is already started and you choose Actions=>Start, you receive a status message notifying you that the component is started already.
Table 48 on page 175 indicates which menu options are enabled (Yes) or disabled (blank) for each run_state of a secondary cell in an HA configuration. Table 48 Component state and menu options for a secondary cell in a high availability configuration
Menu options Start Cell Server Process Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Stop Cell Server Process Restart Cell Server Pause Events Resume Events Process Admittance Admittance
run_state state_unknown state_active state_unavailable state_started state_stopped state_paused state_passive
Set to Standby
Set to Active
Chapter 5
175
Remote actions
Exceptions
Generally, most component objects receive the actions Start, Stop, Restart, Pause, and Resume. For cell servers, the Start, Stop, and Restart menu options in the Actions submenu are described as:
I I I
Start Cell Server Process Stop Cell Server Process Restart Cell Server Process
For other objects apart from cell servers, the Start, Stop, and Restart menu options in the Actions submenu are described as:
I I I
Start Process Stop Process Restart Process
For OVO adapter cells, the menu options in the Actions submenu are described as:
I I I
Set OVO User/Password Initialize OVO Publication Fetch From OVO
Different actions are available for different types of components. Table 49 lists the main exceptions: Table 49
Component HA cell
Components and actions

Exception all actions. The HA cell is the only component that allows the Set to Standby and Set to Active menu options
Impact Administration server receives the Restart action only (IAS) Publishing Server IBRSD normal cell receives the Start, Stop, and Restart actions receives the Stop, Start, and Restart options receives the Stop, Start, Restart, Pause Events Admittance, and Resume Events Admittance options
Logical components that you add to the Infrastructure Management service model receive no actions.
176
Chapter
6
178 179 179 183 184 185 186
Managing the BMC Impact Explorer (BMC IX) console

6
This chapter describes some aspects on how to configure the BMC Impact Explorer (BMC IX) console and contains the following topics: Defining property files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a single BMC IX instance for cross- and web-launching . . . . . . . . . . . . . . . Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring display and connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining global event severity and priority color values. . . . . . . . . . . . . . . . . . . . . . . Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6 Managing the BMC Impact Explorer (BMC IX) console
177
Defining property files
Defining property files

For the web launch option of the BMC IX console, a unique properties file is created in the directory of the BMC Impact Portal. For the application mode launch, this file is stored at MCELL_HOME\server\data\econsole. The IMPACT_SOLUTIONS_HOME\server\data\econsole\username.econ.config configuration file helps BMC IX to manage its tool bars. This file is based on the default.econ.config properties file that is created at the standard and Atrium installations. For every user, it records the tool bar locations in a separate file with the user name, such as ServiceOperators.econ.config. Figure 21 illustrates the username.econ.config file. Figure 21 default.econ.config file contents
#Mon Jan 20 17:51:13 CDT 2003 toolbar_orientation=0 toolbar_layout=North framework_bounds=444,256,512,384 user.region=US
Figure 22 illustrates a file Operator.econ.config created for a user named Operator. Figure 22 Operator.econ.config file contents
#Wed Feb 05 11:52:22 CST 2003 user.region=US toolbar_orientation=0 config_dialog_position_y=191 config_dialog_height=520 toolbar_layout=North config_dialog_position_x=288 config_dialog_width=394 framework_bounds=229,259,512,384
178
Selecting a single BMC IX instance for cross- and web-launching
Selecting a single BMC IX instance for crossand web-launching

By default, you can launch multiple instances of BMC IX in different contexts. To cross-launch a single BMC IX instance, add a new property to the resource section of the PortalInstall Dir\appserver\websdk\tools\jboss\server\all\modules\smsIX.sar\ smsIX.war\ix-xl.jnlp file. The name of the new property is ix_single_instance. When you add the property, set its value equal to true, as in the following example:
<property name =ix_single_instance value =true/>
To launch a single BMC IX instance through the web, add the ix_single_instance property to the resource section of the PortalInstall
Dir\appserver\websdk\tools\jboss\server\all\modules\smsIX.sar\ smsIX.war\ix.jnlp file. Set its value to true.
After modifying either the ix-xl.jnlp or ix.jnlp file, restart the Portal Application server to initialize the changes.
Defining console-wide policy files

Another aspect of control vested in the BMC Impact Portal is the policy file that BMC Impact Explorer retrieves each time a user connects to the BMC Impact Portal. This file contains parameters that define BMC Impact Explorer console-wide policies for all users. At installation, the default policy file, default.console_policy.prop, is created; it is located in the IMPACT_SOLUTIONS_HOME\server\data\policy directory. The policy file is never saved from the BMC Impact Explorer console, only retrieved. If a specific user has a particular need, it is possible to create an individual user policy file, username.console_policy.prop, based on the default and located in the same IMPACT_SOLUTIONS_HOME\server\data\policy directory. This individual user policy file will be returned to the BMC Impact Explorer console, rather than the default file, default.console_policy.prop, when the user logs on. For ease of maintenance, BMC Software recommends that the default be used for most users. Table 50 on page 180 summarizes the parameters in the default policy file.
179
Table 50
Parameter
default.console_policy.prop parameters
Description controls the tracking of local actions performed against events specifies the default filter used to display the event list when no view is selected specifies the default slot order used for the event list when no view is selected controls the slots shown as icons in the event list (values of hidden slots can be viewed only as icons) controls the hidden slots that are available for creating filters Note: Filters that rely on hidden slots may be broken in future releases because they rely on undocumented contents.
local_action_event_operations default_filter_name default_slotorder_name eventlist_icon_slots filter_hidden_slots
administration_editor_classes administration_editor_acls
controls the classes (with their subclasses) that are available to the Dynamic Data Editor specifies the ACLs that control access to the Dynamic Data Editor controls exclusion of slots when exporting controls the time interval between saves of configuration information (such as window sizes and locations) controls the time interval between saves of Services View navigation tree information
no_import_slots
config.save.freq ix.servicetree.save.timer
data_handle_chunk_size data_handle_sleep_interval data_paste_chunk_size data_paste_sleep_interval users_filter import_method_new

local_action_event_notes
parameters used to manage data-handling actions such as copying, pasting, exporting, and printing Boolean switch for the AssignTo users filter Boolean switch that indicates whether the import is done using the previous method or the new method, where false = previous method (deprecated)a controls creation of notes for events that have local actions performed against them; replaced with local_action_event_operations (deprecated)a controls creation of notes for events that have remote actions performed against them (deprecated)a controls creation of notes for events that change status by means of user-initiated action
remote_action_event_notes status_mod_event_note
a
Deprecated parameters remain in version 4.1 and earlier cells. However, the parameters do not exist in newer releases.
Figure 23 lists its contents, including the default values for each parameter.
180
Figure 23
Default policy file (part 1 of 2)
# This document keeps default Policies for different BMC Impact Explorer wide functions. # Format: # <policy_name>=<polcy specific value> # Policy which controls the creation of an event operation track for events which # have local actions performed against them. # value: on=operation track created when local action performed, off=operation track not created. local_action_event_operations=on # Policy which controls the creation of an event note for events which # have local actions performed against them. # deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose. # replaced with local_action_event_operations # value: on=note created when local action performed, off=note not created. local_action_event_notes=on # Policy which controls the creation of an event note for events which # have remote actions performed against them. # deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose. # The registering of history in mc_operations is configured at the im. # value: on=note created when remote action performed, off=note not created. remote_action_event_notes=on # Policy which controls the creation of an event note for events which # change status via user initiated action (e.g.: OPEN -> CLOSED). # deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose. # The registering of history in mc_operations is configured at the im. # value: on=note created when event status changes, off=note not created. status_mod_event_note=on # default filter and slot order when no view is ever selected. # value: the name of a defined filter and slotorder. default_filter_name=All Events default_slotorder_name=Basic Information # controls if ClassDetailProvider detail tabs show hidden slots #ClassDetailProvider_shows_hidden_slots=false # Policy which controls the slots shown as icons in the event lists. # Values of hidden slots can only be viewed as icons. # value: <className> "." <slotName> { "," <className> "." <slotName> } # default value: CORE_EVENT.mc_abstracted, CORE_EVENT.mc_abstraction, CORE_EVENT.mc_action_count, CORE_EVENT.mc_cause, CORE_EVENT.mc_effects, CORE_EVENT.mc_history, CORE_EVENT.mc_notes, CORE_EVENT.mc_smc_cause, CORE_EVENT.mc_smc_effects, CORE_EVENT.mc_smc_impact #eventlist_icon_slots=CORE_EVENT.mc_abstracted, CORE_EVENT.mc_abstraction, CORE_EVENT.mc_action_count, CORE_EVENT.mc_cause, CORE_EVENT.mc_effects, CORE_EVENT.mc_history, CORE_EVENT.mc_notes, CORE_EVENT.mc_smc_cause, CORE_EVENT.mc_smc_effects, CORE_EVENT.mc_smc_impact
181
Figure 23
Default policy file (part 2 of 2)
# Policy which controls the hidden slots that will be available for filter building. # Impartant remark: Filters that rely on hidden slots may be broken in future release without notice, because they rely on undocumented contents. # value: <className> "." <slotName> { "," <className> "." <slotName> } # default value: <empty list> #filter_hidden_slots= # Policy which controls what classes (with their subclasses) are visible in Administration's editor # value: <className> { "," <className> } # default value: DATA #administration_editor_classes=DATA #Policy which controls what acls control the classes (with their subclasses) in Administration's editor # value: <aclName> { "," <aclName> } # default value: MC_DATA_EDITOR #administration_editor_acls=MC_DATA_EDITOR # Slots that, though parsable, should be excluded from import (thus paste and export for import), because of specific semantics # value: <className> "." <slotName> { "," <className> "." <slotName> } no_import_slots=CORE_DATA.mc_udid, MC_SM_OBJECT.creation_mode, MC_SM_COMPONENT.ext_id, MC_SM_COMPONENT.home_cell, MC_SM_RELATIONSHIP.provider_id, MC_SM_RELATIONSHIP.consumer_id # Configuration information (such as window sizes and locations) will be saved on a periodic basis. # Policy which controls the time window (in seconds) for this operation. # default value: 5 minutes (300 seconds). config.save.freq=300 # Service Views navigation tree information stored as XML will be saved to the IXS on a periodic basis. # Policy which controls the time window (in seconds) for this operation. # default value: 5 seconds (5000 milliseconds). # Based on section 4.1.1.2.1 in Impact Explorer 4.1 Functional Specification ix.servicetree.save.timer=5
When you execute a local action, a remote action, or modify the status of an event, a note is written to the event as a value to the mc_notes slot and appears in the Notes tab of the details pane of BMC Impact Explorer Events View. The initial filter is set to display all events and the initial slot order is to display as basic information, as indicated on the event source tab in the event list display. The last entry in the policy file identifies those slots that should not be imported because of their specific semantics. The policy files console-wide application can be used to protect the individual users cell groupings from being accessed and modified by other users on a multi-user BMC Impact Explorer console. This enables a business to assign multiple users with limited use requirements to one BMC Impact Explorer console, fully utilizing one resource, rather than investing in several BMC Impact Explorer consoles that will be under utilized.
182
Configuring display and connection settings
Another beneficial aspect of the global nature of the policy file is that you can use it to create a customized default event filter and slot order for a BMC Impact Explorer console for new users and as the default filter and slot order when a user selects an improper filter.
Configuring display and connection settings

You can use the ix.properties file to configure the display and connection settings for BMC IX. Table 51 lists the property settings included in the ix.properties file. Table 51 Property descriptions from ix.properties file (part 1 of 2)
Description when set to true, enables debugging for the console sets the directory location and URL address for the BMC Impact Explorer Help file specifies the look and feel for BMC Impact Explorer according to the Java interface settings sets the amount of time, in seconds, a macro waits to connect to a cell sets the port number used by the Remote Method Invocation (RMI) service in BMC Impact Explorer enables the RMI service for BMC Impact Explorer for remote access to event data enables any connection to the RMI service for a BMC Impact Explorer If set to false, the RMI service can only accept connections from the local computer where the console is running.
mc_console_remote_object_name
Console property
framework_debug help_url java_plaf macro_connect_timeout remote_server_port remote_server_enabled all_connection_allowed
specifies the name of the remote object used by the RMI client This value must be matched in the -Dremote_object_name option in the run_client.bat or run_client.sh scripts.
user.region
specifies the region used for the console to provide II8N support By default, this information is retrieved from the environment setup of the computer.
collector_tree_color max_msg_history new_groups_name svc_view_tooltip
specifies the background color for the navigation tab on the Events tab of the console sets the maximum number of status bar history messages that are stored in the console specifies the default name assigned to newly created subgroups on the Services tab on the console length of time, in milliseconds, the console waits to display tooltips in the Services View
183
Defining global event severity and priority color values
Table 51
Property descriptions from ix.properties file (part 2 of 2)

Description sets the width for line indicators that connect service model components in the relationships pane of the console sets the width of the line indicators that indicate impact relationships between service model components in the relationships pane of the console
Console property
svc_view_link_thickness_normal svc_view_link_thickness_true_impact
Defining global event severity and priority color values

Event records are displayed in the BMC Impact Explorer Events View using colors that represent their level of severity and priority. The color.properties file, located in the IMPACT_SOLUTIONS_HOME\server\conf directory, defines severity and priority value colors for the events and contains the default color values. The color.properties file also can contain custom definitions for the status conditions of BMC Service Impact Manager components. Modify this file if you want to define custom colors for event severities and priorities. To avoid confusion, each user receives the same colors for events that the BMC Impact Explorer console interface displays. Refer to Customizing colors for severities, statuses, and priorities on page 99 for more information. Table 52 lists the default severity level colors and their values, as defined in color.properties. Table 52
Down Critical Major Minor Warning Information OK Unknown
Event severity levels and colors

Color Black Red orange light orange yellow blue green gray Hexadecimal RGB values in color.properties 000000,FFFFFF FF0000,FFFFFF FF9900,000000 FFCC33,000000 FFFF00,000000 3366CC,FFFFFF 33CC00,000000 CCCCCC,000000
Severity level
184
Event group configuration files
WARNING
I I
The entries are the default color properties. Do not delete these properties. If you customize the severities by increasing the number of levels to be greater than the number of default severity levels, the severity list on the Event and Services Views becomes truncated and partially illegible. Restrict your customizations to the same number or fewer severity levels.
Table 53 lists the default priority level colors and their values, as defined in color.properties. Table 53
Priority_1 Priority_2 Priority_3 Priority_4 Priority_5
Event priority levels and colors

Color red orange light orange yellow green Hexadecimal RGB values in color.properties FF0000,FFFFFF FF9900,FFFFFF FFCC33,000000 FFFF00,000000 33CC00,000000
Priority level
To globally change the default severity or priority colors, modify the color.properties file and stop and start the BMC Impact Administration Server.
NOTE
Modifications made to the color.properties file do not immediately appear in the BMC Impact Portal. By default, the BMC Impact Portal configuration.update.interval parameter checks for changes every 300 seconds.
Event group configuration files

The event group configuration file structure is listed in Table 54: Table 54
Folder \Images \Images\Backgrounds \Images\Icons \Map \Map \Map
Event group configuration files (part 1 of 2)

Contains Backgrounds and Icons directories background image files that are shared by all Map definitions image files which are shared by all Map definitions event group tree node template MapObjectTemplate.xml event group default image view configuration DefaultMapPage.xsl Map tree definition Maps.xml
185
XML files that define user interface elements
Table 54
Folder
Event group configuration files (part 2 of 2)

Contains Map.xml for Map_xxx as well as its MapPages directory
\Map\Map_xxx
\Map\Map_xxx\MapPages all map page definitions for Map Map_xxx
XML files that define user interface elements

Table 55 lists XML files that control some user interface characteristics in BMC Impact Explorer that cannot be edited in the BMC IX user interface. Use care when you edit these files to avoid unexpected and undesirable results. These files are located in IMPACT_SOLUTIONS_HOME\server\data\extdetails. Table 55
File name default.DataEditor.extdetails.xml
xml files that define user interface elements in BMC IX

Description defines the default tabs if the global.DataEditor.extdetails.xml file is not present or does not contain values defines the tabs that appear in the data editor defines the tabs that appear for events and components defines the policy type to policy editor mapping
global.DataEditor.extdetails.xml global.extdetails.xml global.PolicyEditor.extdetails.xml
global.SmcToolTips.extdetails.xml defines the tooltips that appear on a component instance
186
Chapter
7
188 188 189 190 191 192 192 194 195
Defining presentation names

This chapter describes how to add or modify user-friendly presentation names in the following BMC Impact Solutions interfaces: BMC Impact Explorer, BMC Impact Service Model Editor, and BMC Impact Portal. This chapter presents the following topics: Presentation names overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a new presentation name resource file. . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . Digitally signing a .jar file with a digital test certificate . . . . . . . . . . . . . . . . . . . . Enabling or disabling presentation names in BMC Impact Explorer tool tips . . . . .
Chapter 7
187
Presentation names overview
Presentation names overview

By default, BMC Impact Solution products use user-friendly data labels (presentation names) in the user interface instead of the internal object names. For example, the presentation name Occurred is used in the BMC Impact Explorer event list column title and the Summary tab instead of the internal slot name date_reception. Table 56 describes the objects for which presentation names are defined. Table 56
Interface BMC Impact Explorer Events View
Presentation names for BMC Impact Solution interfaces

Objects with presentation names
I I I I I
event class names slot names enumeration class names and values collector names action names service model class names (component types) and slot names service model management class and slot names service model enumeration class names and values policy type names event class names slot names - In the Event Selection Criteria column, the internal slot names are shown because this is the actual text of the ECF. event class names slot names enumeration class names and values service model class names (component types) and slot names service model management class and slot names service model enumeration class names and values service model class names (component types) and slot names service model management class and slot names service model enumeration class names and values
BMC Impact Explorer Services View BMC Impact Explorer Administration View
I I I I I I
BMC Impact Portal
I I I I I I
BMC Impact Service Model Editor
I I I
Presentation name resource file locations

Presentation names are defined within a presentation name resource file. The default presentation name resource file is the kb_core_resource.properties file. The location of the kb_core_resource.properties file depends on which BMC Impact Solutions application you are using.
I
For BMC Impact Explorer, the default presentation names are defined in the following two files:
I
InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\ kb_core_resource.properties
188
Default presentation name definitions
InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\ kb_deprecated_resource.properties (contains names for slots that appear on the
Deprecated tab of the BMC Impact Explorer Events View)

I
For BMC Impact Portal, the kb_core_resource.properties file is located in the

BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources /en_US/smsConsoleServer directory.
For BMC Impact Service Model Editor, the kb_core_resource.properties file is located in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all /conf/resources/en_US/smsConsoleServer directory.
Extracting the presentation name resource files for BMC Impact Explorer (Java Web Start)
The presentation name resource file for BMC Impact Explorer (Java Web Start) is provided in a .jar file and is digitally signed by BMC Software, Inc. with its digital certificate. To edit the presentation name resource file for BMC Impact Explorer (Java Web Start), you must uncompress the BMC_Portal_Kit_Home/appserver/websdk/tools /jboss/server/all/modules/smsIX.sar /smsIX.war/kbresource.jar into a temporary directory using the following command:
jar xvf kbresource.jar
This command extracts the kb_core_resource.properties and kb_deprecated_resource.properties files.
Default presentation name definitions

The kb_core_resource.properties file maps the internal names of all classes, slots, enumerations, and enumeration values to presentation names for the KB BAROC files that are loaded by default. The default BAROC files loaded are located in one of the following directories:
I
On UNIX: $MCELL_HOME/etc/default/SIM/kb/classes/.load or $MCELL_HOME/etc/default/EM/kb/classes/.load On Windows: %MCELL_HOME%\etc\default\SIM\kb\classes\.load or

%MCELL_HOME%\etc\default\EM\kb\classes\.load
NOTE
The event slot names shown on the Deprecated tab in the BMC Impact Explorer Events View do not have presentation names by default. This tab shows in parenthesis the recommended internal slot to use in place of the deprecated internal slot.
Chapter 7
189
Creating a new presentation name resource file
If you load a supplied BAROC file that is not loaded by default, you should define presentation names for the internal names. For instructions, see Defining presentation names on page 192. Collector names and action presentation names are also defined in kb_core_resource.properties by default. However, these entries are used by BMC Impact Explorer only and are used primarily for localization.
Creating a new presentation name resource file

NOTE
When you change or replace the original presentation name resource file for BMC Impact Explorer (Java Web Start application), you must provide one that is signed with your organizations digital certificate. For instructions on digitally signing a new presentation name resource .jar file, see Digitally signing a .jar file with a digital test certificate on page 194.
If you want to modify the exiting presentation names or create new ones, you can create a new presentation name resource file for any BMC Impact Solutions application by following these steps:
1 Create a file with a .properties extension. 2 Save the file. WARNING

To preserve the .properties suffix, save as type All Files. Do not save the .properties file as a .txt file. The configuration changes may not be recognized.
3 (BMC Impact Explorer only.) Place the resource file in the

InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\ directory.
4 (BMC Impact Explorer only.) Add the base name of the resource file to the value of
kb_info_resources parameter in the InstallDir\BMC Software\MasterCell\console\etc\ix.properties file using the
following format:
kb_info_resources=ResourceFileName,kb_core_resource, kb_deprecated_resource
5 Follow the procedure, Creating or modifying presentation name keys on

page 192, to add presentation name entries for your classes and slots to the new .properties file that you have created.
190
Presentation name resource files search order
Presentation name resource files search order

Each BMC Impact Solutions application searches the presentation name resource files differently.
Presentation name resource file search order for BMC Impact Explorer
BMC Impact Explorer searches a list of local resource files for presentation name keys. You specify the order in which resource files are searched by defining the search order in the kb_info_resource parameter located in the InstallDir\BMC Software\MasterCell\console\etc\ix.properties file. Because BMC Impact Explorer searches a set of files in the order you specify, you can override the presentation names in the default file by creating a new .properties file, defining presentation names in this file and listing the new .properties file before the default file in the kb_info_resource parameter. (For instructions on creating a new .properties file, see Creating a new presentation name resource file on page 190.) For example, if you created a new .properties file called my_ix_names.properties and you wanted BMC Impact Explorer to search this file first, you would modify the kb_info_resource parameter to look like this:
# Specifies the set of files to load for kb specific resources (base names only, comma separated list) kb_info_resources=my_ix_names, kb_core_resource, kb_deprecated_resource
Presentation name resource file search order for BMC Impact Portal
The BMC Impact Portal searches for presentation name keys in the files located in the
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources /en_US/smsConsoleServer and BMC_PORTAL_KIT_HOME/appserver/websdk/tools /jboss/server/all/conf/resources/en_US/smsIwc directories.
If you want to add custom classes or extend existing classes to add new attributes, you can add them to the kb_core_resource.properties file located in the
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources /en_US/smsConsoleServer directory. For more information about modifying
presentation name keys, see Defining presentation names on page 192.
Chapter 7
191
Presentation name resource file search order for BMC Impact Service Model Editor
The BMC Impact Service Model Editor looks for presentation name keys in the
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/ en_US/smsConsoleServer/kb_core_resource.properties file.
If you want to add custom classes or extend existing classes to add new attributes, you can add them to the kb_core_resource.properties file. For more information about modifying presentation name keys, see Defining presentation names on page 192.

Perform these procedures to define user-friendly presentation names for new event classes, component types, slots, enumerations, or policy types.
NOTE
If you customize presentation names in the default kb_core_resource.properties file, you will need to merge your customizations into a newer file when you upgrade.
Creating or modifying presentation name keys

The entries in kb_core_resource.properties have the form
key=value
where value is the presentation name. The value can contain space characters. Table 56 lists the formats for the presentation name key. Table 57
Object Class Slot
Presentation name key formats

Key format CLASS.InternalClassName SLOT.InternalClassName.InternalSlotName Note: Use the class name where the slot is originally defined (the superclass).
Enumeration Enumeration Value
ENUM.InternalEnumerationName ENUMVAL.InternalEnumerationName.InternalValueName
192
Creating or modifying presentation name keys
To create or modify presentation name keys 1 In a text editor, open either the kb_core_resource.properties file or the new
.properties file that you have created. For instructions on creating a new .properties file, see Creating a new presentation name resource file on page 190.
2 To define the presentation name for an event class, add a line with the following
format to the resource file:
CLASS.eventClassName=eventPresentationName Event
3 To define the presentation name for an event slot, add a line with the following
SLOT.eventClassName.slotName=slotPresentationName
4 To define the presentation name for a new policy type, add a line with the
following format to the resource file:
CLASS.policyTypeName=policyTypePresentationName Policy
5 To define the presentation name for a policy slot, add a line with the following
SLOT.policyTypeName.slotName=slotPresentationName
6 To define the presentation name for a service model component type, add a line
with the following format to the resource file:
CLASS.BMC_ClassName=ComponentTypeName
7 To define the presentation name for a service model component slot (attribute),
add a line with the following format to the resource file:
SLOT.BMC_ClassName.slotName=slotPresentationName
8 When you have finished adding or modifying the presentation names in the
.properties file, save and close the file.
WARNING
To preserve the .properties suffix, save as type All Files. Do not save the .properties file as a .txt file. The configuration changes may not be recognized.
Chapter 7
193
Digitally signing a .jar file with a digital test certificate
9 (BMC Impact Explorer only.) Deploy the revised files to all machines on which BMC
Impact Explorer is installed.
10 (BMC Impact Explorer only.) If you are using BMC Impact Explorer (Java Web Start
application), digitally sign the .jar file using the instructions in Digitally signing a .jar file with a digital test certificate on page 194.
11 Stop and start the BMC Impact Solutions application.
Digitally signing a .jar file with a digital test certificate

If you change or replace the original presentation name resource file for BMC Impact Explorer (Java Web Start application), you must provide one that is signed with your organizations digital certificate. To accomplish this task, you must have a JDK 1.2 or JDK 1.3 keytool and jarsigner (located in the J2SE SDK bin directory) in your environment path.
1 Create a new key in a new keystore: A Enter the following command.

keytool -genkey -keystore keystore_filename -alias my_alias
B Enter the requested information for each option.

For example: keytool -genkey -keystore myKeystore -alias myself. This command creates a new key in the keystore file named myKeystore on disk.
2 Create a self-signed test certificate by following these steps: A Enter the following command.
keytool -selfcert -alias <my_alias> -keystore <keystore_filename>
B Enter the password at the prompt.

Generating the certificate takes a few minutes.
3 Verify that the key and certificate creation were successful by following these
steps:
A List the contents of the keystore by entering the following command:

keytool -list -keystore <keystore_filename>
194
Enabling or disabling presentation names in BMC Impact Explorer tool tips
The resulting listing should appear as follows: Figure 24 Listing of the contents of a keystore file
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry: myself, Tue Jan 23 19:29:32 PST 2001, keyEntry, Certificate fingerprint (MD5): C2:E9:BF:F9:D3:DF:4C:8F:3C:5F:22:9E:AF:0B:42:9D
4 Sign the .jar file with the test certificate by following these steps: A Enter the following command.
jarsigner -keystore keystore_filename jar_filename alias
B Repeat this step for all the .jar files that you have created or changed. NOTE
A self-signed test certificate should only be used for internal testing, because it does not provide any guarantees about the identity of the user and, therefore, cannot be trusted. You can obtain a trust-worthy certificate from a certificate authority, such as VeriSign, use it to sign the .jar file when the application is put into production.
After you have defined presentation names, they are available for automatic download by users who are using the BMC Impact Explorer consoles that are Java Web Start applications.

A BMC Impact Explorer user can view the internal object names as tool tips when the mouse pointer is over
I I I I I I
a presentation name in a column header a presentation name that labels a slot value (for example, in an Event Details tab) the label of a drop-down list or field that shows a presentation name, a slot presentation name in a list box (as in the Edit Slot Order window) a class presentation name in the Class Chooser window a class presentation name in either of the Administration tab navigation trees
Chapter 7
195
Tool tips are not shown for

I I
classes in the Services tab Of type list classes or enumeration values in lists such as event and data lists or event selection criteria lists
To enable the display of internal names in tool tips, select the Show Internal Names in
Tool Tips on the Global tab of the Edit Configuration dialog.
To always display internal names instead of the presentation names in BMC Impact Explorer, set the value of the kb_disable_resources parameter in InstallDir\BMC Software\MasterCell\console\etc\ix.properties to true. There is no way to display presentation names in some BMC Impact Explorer views and internal names in others.
196
Chapter
8
198 199 199 200 205 205 206 207 207
Configuring StateBuilder and gateways

8
This chapter describes how to configure the StateBuilder and gateways for exporting events and contains the following topics: Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . StateBuilder configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . statbld return codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying a statbld.conf file to export events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . Configuring tracing for StateBuilder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trouble-shooting the StateBuilder process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 8
197
Understanding the StateBuilder and gateways
Understanding the StateBuilder and gateways

The StateBuilder is an executable, statbld.exe, located in the MCELL_HOME\bin directory. It records saved states of the cell at regular intervals. When it starts, the cell loads its last saved state (mcdb). All transactions it performs are stored in a transaction file (xact). As soon as the transaction file reaches a certain size, or after a certain period, the StateBuilder is started. It produces a new saved state from the previous file and from the transaction file. When the cell terminates and restarts, any trailing transaction file is first processed by the StateBuilder to produce a new saved state. A history of saved states and corresponding transaction files can be kept. The mcdb and xact files of that history have their timestamp in the file name. All mcdb and xact files are located in the MCELL_HOME\log\cellName directory. The StateBuilder runs as configured in the cells mcell.conf file, which is detailed in StateBuilder configuration file on page 199. The configuration of how the StateBuilder itself operates is in the statbld.conf file. Table 58 on page 198 lists the file naming conventions for the StateBuilder. Table 58
File mcdb mcdb.0 mcdb.t
StateBuilder file name conventions

Description state file the cell uses at startup new state file being generated saved state history files, where t = timestamp in hexadecimal epoch Timestamp t in the mcdb.t file corresponds to the time when the state is created.
mcdb.lock xact xact.n xact.t.n
lock file indicating StateBuilder activity transaction file generated by the cell terminated transaction file, where n=1 is the oldest transaction file terminated transaction history file corresponding to mcdb.t Timestamp t in the xact.t file refers to the mcdb.t file to which the transactions lead.
There is also a statbld.trace file for the configuration of StateBuilder tracing. For further information, see Configuring tracing for StateBuilder on page 207. The StateBuilder uses the gateway.export file in conjunction with its statbld.conf file to export event data. For more information, see the StateBuilder configuration fileand Exporting events on page 205.
198
StateBuilder configuration file
StateBuilder configuration file

The state configuration file, statbld.conf, is located in the MCELL_HOME\etc directory. Table 59 lists the statbld.conf parameters, which use the same syntax as all BMC Impact Solutions configuration files. Table 59
Parameter
Export ExportConfigFileName ExportDiscarded
statbld.conf Parameters
Description sets path to the gateway.export file Default value
%H/etc/%N/gateway. export
uses Boolean values to specify whether to export data No
indicates whether discarded events are included in the No export file Discarded events are those that were dropped in the first four rule phases: Refine, Filter, Regulate, and New (Update).
ExportTriggerArguments
sets the arguments to be passed to the executable serving as the export trigger program Value is interpreted as a sequence of space-separated arguments, so spaces within each argument are not allowed.
blank; no arguments
ExportTriggerProgram
sets the program to execute after exporting data The value is interpreted as a path. See the mcell.conf file for special syntax for a path.
blank
StateHistoryCount
sets the number of state files to retain in the history Each time a new saved state is produced, the oldest state is removed.
statbld return codes

Table 60 lists the return codes for statbld. Table 60
1 2 10 37 47
statbld return codes (part 1 of 2)

Description failed to build new mcdb failed to update history files early initialization failure process handling module initialization failure StateBuilder specific file access initialization failure
Return code
Chapter 8
199
Gateway configuration
Table 60
57 67 77 87 97
statbld return codes (part 2 of 2)

Description transaction file handling initialization failure failed to load KB classes server directory load failure internal table initialization failure detected running StateBuilder (mcdb.lock)
Return code
This section discusses general message formatting that applies both to StateBuilder export and to gateways. Gateway specific message formats are described in a gateway configuration file. The location of this file for gateway of a particular type is determined from the GwTypeConfigFileName parameter of the cell. Its default value is %H/etc/gateway.Type where Type represents the type of gateway. Example default parameter values for TEC and jServer gateways:
I
GwTECConfigFileName=%H/etc/gateway.TEC which means: $MCELL_HOME/etc/gateway.TEC GwjServerConfigFileName=%H/etc/gateway.jServer which means: $MCELL_HOME/etc/gateway.jServer
A gateway configuration file contains parameter settings in the form of parameter=setting. Parameters can be specified differently for new events and for event modifications. The parameter name must be suffixed with
I I
.new for new events .mod for event modifications
Without a suffix, the setting is assumed to be on both categories. Both the contents of a message and its format are specified using parameters.
Gateway predefined variables

Table 61 on page 201 lists the parameters that can refer to predefined variables.
200
Table 61
Variable $CLASS $CONTEXT
Gateway configuration parameter predefined variables

Description class name context name: I Permanentevent permanently in DB (until out of date) I Processeddiscarded by rule processing I Regulateddiscarded by regulation I Filtereddiscarded by filter I Refineddiscarded by refine I Receiveddiscarded immediately date stamp time stamp names of modified slots (empty for new) event ID in gateway cell name of cell connecting to gateway event ID in cell value of slot slot selected slot name (only for body parameter) selected slot value (only for body parameter) all modified slots (empty for new) all slots (only for slots parameter) all slots, but limited to class cls (only for slots parameter) mapped value of val using map val can be a literal or a variable reference
$DATE $TIME $MODNMS $GHANDLE $CNAME $CHANDLE $VALUE slot $NAME $VALUE $MODS $ALL $ALL cls $MAP.map val
Gateway text parameters

Text parameter values consist of literal text, possibly mixed with references to variables and with escape sequences, as shown in Table 62. Table 62
Character \\ \s \n \r \t \0ddd
Gateway Configuration Parameter Text Values

Name backslash space new line carriage return tab character code in octal (0, 1, 2, or 3 digits d)
Chapter 8
201
References to variables that are not followed by punctuation or space characters must be enclosed in curly brackets ( { } ). For example, $NAMEabc is invalid; ${NAME}abc is correct. Non-printable characters and hard spaces must be expressed with an escape sequence. String values for parameters are considered from the first non-white space character up to the first (non-escaped) white space character. Table 63 on page 202 lists the gateway.export file parameters. Table 63 gateway.export file parameters (part 1 of 2)
Parameter Communication protocol parameters Contents parameters cond Description sets the communication protocol. Both categories, new event and modification, use the same protocol. The last one specified is used. The default value is MCELL. sets the condition for a slot to be included in the $ALL variable. Use always to always include the slot. Use propagate to include the slot if its value is different from the default value for the slot and it is able to be parsed. The default value is propagate for new, and always for mod. lists slots that must be dropped from the $ALL and $MODS variable. List of comma separated slot names. Only real slot names can be used. The default value is [], so no slot is dropped. lists additional new slot definitions. List of comma separated settings in the format slotname=slotvalue. slotname represents the name for the new defined slot and slotvalue defines the value of the new slot. The default value is [], so no slot is added. sets and orders the slot names to be included. Non-base class slots must be prefixed with ClassName: . The list can also contain variable references to include those values among regular slots. The default value is [], so no slots are exported. modify lists slots whose modifications result in a message. Modifications of slots that are not included in this list are ignored. The default value is [], which means that every slot modification is included. Defines the map table with the name name List of comma separated settings in the format original_value=converted_value original_value represents a value that has to be replaced and converted_value is the replacement value. Both values must be literal values.
drop
add
slots
map.name
202
Table 63
Format parameters
gateway.export file parameters (part 2 of 2)

Parameter init Description text or value to be printed at the beginning of each export message. The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file. text or value to be printed for every slot to be included; can use the variable, $NAME (name of the slot) and $VALUE (value of the slot). The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file. text or value to be printed at the end of each event. The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file. sets the separator character or string to use between slot values. The default value is nothing. sets the characters leading to quotation when appearing in a slot value. If the parameter value is empty, slot values are never quoted. The default value is standard MRL quotation rules. sets the opening quotation character to use for values that must be quoted. The default value is a single quote (). sets the closing quotation character to use for values that must be quoted. The default value is a single quote ().
body
term
separator quotable
openquote closequote
escapequote determines how to escape a quotation mark inside a quoted value. The default value is a single quote ().
Gateway configuration value mapping

For some destinations, it is necessary to map values from a cell domain to a gateway domain. You can implement value mapping by defining a map table and using the value mapping function. You define a value map table using the parameter map suffixed with the name of the map table.
map.name=[original_value=converted value,original_value=converted value, etc.] name represents the name you give the map table; original_value is the value to be replaced and converted_value is the replacement value.
You convert a value applying a map table, by using the variable $MAP.
$MAP.name(value)
If the specified value cannot be found in the map table, it is not replaced.
Chapter 8
203
For example: You want to modify the value of the enumeration SEVERITY when it is sent to a certain gateway. Value WARNING will be replaced with LOW, and value CRITICAL with URGENT. To do this, create a map table to define the required mapping:
EXAMPLE
map.GW1severity=[WARNING=LOW,CRITICAL=URGENT]
All other values of SEVERITY are passed unchanged. To actually replace the values of slot severity, the slot has to be dropped and a new slot, with the same name, has to be added, mapping the value:
EXAMPLE
drop=[severity] add=[severity=$MAP.GW1severity($VALUE(severity))]
Example of printed events

To print events in BAROC format, set the parameters as shown in Figure 25. Figure 25 Parameters used to print event in BAROC format
init=$CLASS;\n body=\t$NAME=$VALUE;\n term=END\n
The BAROC format produces output similar to the example shown in Figure 26. Figure 26 Example of printed events
MC_CELL_TICK; server_handle=0; date_reception=1010183001; event_handle=2; source=; sub_source=; ... END
The slots are displayed, one per line, indented by a tab (\t). For every slot, the slot name and value are printed, separated by an equals sign (=) and terminated with semicolon and a new line (\n). To terminate, END is printed on a line at the end of the data.
204
Exporting events
In the example shown in Figure 27, the first two lines configure the export file so that it exports new events and modified events differently. Specifically, slots.new=[$ALL] exports all slots of new events to the database and slots.mod=[event_handle,$NAME,$VALUE] exports event_handle, slot name, and value of events that are modified to the export file. Figure 27 Command to configure the export file
slots.new=[$ALL] slots.mod=[event_handle, $NAME, $VALUE]
Exporting events
Events received in the cell can be exported to a flat file that resides on the same computer as the cell. The exported events then can be used in third-party products for archiving and data mining. Also, they can be exported to a program on another computer by using the BMC Impact Solutions Gateway. To export events, you configure the statbld.conf and gateway.export files.
Modifying a statbld.conf file to export events

To modify the statbld.conf file to generate an export file, set Export=Yes and remove the # sign that precedes it. If you retain the default value ExportDiscarded=No, events that were discarded in the first four rule phasesRefine, Filter, Regulate, and New/Updateare not included in the export file. Set ExportDiscarded=Yes to include these events in the export file. Use the ExportConfigFileName parameter in the statbld.conf file to set the location of the export configuration file. By default, the location is the gateway.export file in the cell-specific subdirectory of MCELL_HOME\etc. When the data files are generated, the cell can trigger a program, which can be used to import the data automatically into another product, such as a database. This can be controlled using the ExportTriggerArguments and the ExportTriggerProgram parameters, which are set also in the statbld.conf file. The arguments specified in ExportTriggerArguments are passed as arguments to the program, if any. These are always followed by the paths to the new event and modification export files, in that order.
Chapter 8
205
Modifying a gateway.export file to export events
The export process produces two separate files that are located in the MCELL_HOME\log\cellName directory. These two files are exp.TimeStamp.new, which contains all new events since the previous export, and exp.TimeStamp.mod, which contains all modifications of events after they have first passed through all rule phases. The TimeStamp part of the file name corresponds to the timestamp part used in the mcdb and xact file names and enables archiving of multiple export files. Because the primary goal of exporting events is to import the data into another format for other use, BMC Software recommends that you remove the export files as soon as their contents have been archived. The easiest way to do this is to have them removed by the program that is triggered at the end of the export.
Modifying a gateway.export file to export events

In a gateway.export file, you can configure what data goes into the export file and how that data is formatted. A default gateway.export file exists in the MCELL_HOME\etc directory. Copy the gateway.export file to the MCELL_HOME\etc\cellName directory and edit the copy. By default, the gateway.export file has the format shown in Figure 28. Figure 28 gateway.export file format
# Export Gateway Configuration # cond=always slots.new=[$ALL] slots.mod=[$MODS] body=$VALUE term=\n separator=, quotable=," openquote=" closequote=" escapequote="
Using the default values in the gateway.export file for new events produces output in the format shown in Figure 29. Figure 29 gateway.explore file output for new events
0,1010183001,1,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0, mc.exp.000000001,0,['exp:1'],[],[],[],[],[],0,[],exp, 10.0.9.10:1981,28698 0,1010183001,2,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0, mc.exp.000000002,0,['exp:2'],[],[],[],[],[],0,[],exp, 10.0.9.10:1981,600
206
Configuring tracing for StateBuilder
Using the default values in the gateway.export file for modified events produces output in the format shown in Figure 30. Figure 30 gateway.explore file output for modified events
mc.exp.000000001 exp 10.0.9.10:1981 28698 mc.exp.000000002 exp 10.0.9.10:1981 600 ACK 1010183062 mc.exp.000000003 exp 10.0.9.10:1981 28698
Configuring tracing for StateBuilder

You configure StateBuilder tracing in the MCELL_HOME\etc\statbld.trace file. The statbld.trace file uses the same parameters as the mcell.trace configuration file. For details on the cell tracing configuration, see the BMC Impact Solutions: Event Monitoring Operators Guide.
Trouble-shooting the StateBuilder process

If the StateBuilder process (MCELL_HOME/bin/statbld) fails to start, try the following solutions:
I
Check the MCELL_HOME/log/cell_name directory for the number of xact.n files, where n is 1, 2, 3. More than three xact.n files is an indication that the StateBuilder process is failing. If more than three xact.n files are present, follow these steps:
A Check the MCELL_HOME/log/cell_name directory to see if either of the following

files are present:
I I
mcdb.0 mcdb.lock
If either of these files are present, delete them.
Chapter 8
207
Trouble-shooting the StateBuilder process
B From a command line, manually run the StateBuilder process by entering:

statbld -n cell_name
I
Check the MCELL_HOME/log/cell_name directory to ensure that your xact.n files are named xact.1, xact.2, and so forth. If the file does not have the numeric extension (.n) (the file is only named xact), then rename the file to xact.1. Determine whether or not the MCELL_HOME/bin/statbld program exists and can be executed by the current user who is running the mcell process. Verify your systems available memory and compare it with the actual memory usage of the mcell process. On some UNIX platforms, available unused virtual memory must equal or exceed the virtual memory used by the mcell process.
208
Appendix
A
210 211 213 214 216 218 220 225 228 231 235 237 238 243 245 248 249 251 257 262 264 265 267 268 269 272 272
BMC SIM and EM CLI Reference

This appendix provides reference information on the BMC Impact Solutions and BMC Impact Portal command line interfaces (CLI) and their configuration. It contains the following topics: BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . mccompCompiling rules in the Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . mcellStarting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcfgtraceConfiguring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mclassinfoRequesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcollinfoGetting information about a specific collector . . . . . . . . . . . . . . . . . . mcontrolPerforming cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcrtcellCreating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mcstatReturning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mdelcellDeleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetinfoRetrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . mgetrecObtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkbUpdating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mkillStopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mlogchkPerforming consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mposter and msendManaging data and events . . . . . . . . . . . . . . . . . . . . . . . . . mqueryRetrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mrecoverRecovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . mrextractExtracting cell state files to create new state files . . . . . . . . . . . . . . . mrmergeMerging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetmsgModifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msetrecSetting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A
209
BMC Impact Manager CLI commands
BMC Impact Manager CLI commands

Use the commands from the command line interface (CLI). All of the cell-related CLI commands are located in MCELL_HOME/bin on UNIX and MCELL_HOME\bin on Windows. You can invoke the commands from a command prompt on Microsoft Windows, from a UNIX prompt, or from a script. A command can affect the cell, the Knowledge Base, or other files. Table 64 lists all of the available BMC Impact Manager commands along with a brief description of the purpose for each command. Table 64
Command mccomp mcell mcfgtrace mclassinfo mcollinfo mcontrol mcrtcell mcstat mdelcell mgetinfo mgetrec mkb mkill mlogchk mposter mrecover mrextract mrmerge mquery msend msetmsg msetrec
BMC Impact Manager CLI command descriptions

Description compiles rules in the Knowledge Base starts a cell modifies tracing configuration of a running cell obtains class information from a cell obtains collector information from a cell performs control operations on a running cell creates a new cell returns the status of a cell deletes a cell retrieves information about a running cell retrieves the content of a global record views/updates the Knowledge Base stops a cell performs consistency checks sends or manipulates data, records, and events recovers catastrophic loss of data extracts cell state files to create new state files merges extracted cell state files retrieves objects from a cell sends an event to a cell modifies an event in a cell sets the value of a global record Page 214 216 218 220 225 228 231 235 237 238 243 245 248 249 251 262 264 265 267 267 267 268
210
BMC Impact Manager CLI common command options
BMC Impact Manager CLI common command options

Many commands use the same options that perform the same functions in each command. Additional options that are specific to the command are listed in the section of this appendix that is dedicated to that command.
NOTE
A few commands have command-specific options that override the common CLI command options listed in Table 65. For example, the -p option for the mkb command prints the contents of the designated manifest.kb file, rather than assigning the specified value (Value) to the option Var. If a command has an option that overrides the common option, the command-specific option is noted in the section of this appendix dedicated to that command.
Table 65 describes the common command options that apply to all commands. Table 65
Option -c ConfigFile -h or -? -i UserID[/Password] [@Host[/Port]] -l HomeLocation -n cellName or -n @Host[/Port[#Key]] -p Var=Value -q -v -z
Common options for CLI commands

Description specifies a configuration file to use instead of the default MCELL_HOME\etc\mclient.conf file displays help information, including syntax and options
[optional] specifies that user authentication is required to execute the CLI specifies home directory (HomeLocation) for the command if it is not specified with MCELL_HOME starts the cell named cellName (as defined in mcell.dir). For more information, see Using the -n option. assigns the specified value (Value) to the option Var invokes quiet execution (no banner appears) activates verbose mode to display more information displays version information
Using the -n option

To interact with another cell, a cell uses the mcell.dir file, which maps cell names to a host name or to an IP address and port. With CLI commands, you can use the -n option to specify a cell by using either of the following formats that are used in the mcell.dir file:
I
Designate a cell name by specifying -n cellName.
Appendix A
211
Configuring CLI authentication through BMC Impact Administration Server
This format maps the cellName to the host, port, and encryption key in the mcell.dir file.
I
Designate the host, port, and encryption key by using -n @Host[/Port[#Key]], where Host is either a host name or an IP address Port is the port number Key is the encryption key
The importance of setting a valid encryption key when using the -n option
If you do not specify Key or Key and Port, the default values are applied. The default value for Key is 0, and the default value for Port is 1828. Accepting the default value for Port means that your cell has to listen on port 1828, which is normally the case with the default installation procedure. When BMC Impact Manager is installed, the default installation procedure sets Key to mc, instead of 0. Unless you change the encryption key to 0 during installation or afterwards by manually editing the $MCELL_HOME/etc/mcell.dir file, you need to specify the Key explicitly. Otherwise, if you do not specify the Key, the CLI will not be able to connect to the cell. For security purposes, you should set Key to a valid value other than the default.
Configuring CLI authentication through BMC Impact Administration Server

Any user can connect the CLI to the cell if all of the following conditions are met:
I I I
authenticated through the OS has read permission on mcell.dir has execute permission on the CLI
If you want users to use the -i CLI option to authenticate through the BMC Impact Administration Server (IAS) before they execute a CLI, you must prevent them from having read permission to mcell.dir. Otherwise, the CLI connects to the cell without any cell-specific authentication by retrieving the cell location and encryption key from the cell directory.
212
BMC Impact Manager CLI common return codes
When the -i option is specified, the Impact Manager user identification name must be given as an argument. The corresponding password can be included in the argument, following the user name, separated by a forward slash (/). If the password is not included in the argument, the CLI requests the password on the standard input stream, and suspends execution until the password is entered. To authenticate the user through the BMC Impact Administration server (IAS), use the -i option and specify the host (either by name or IP address) and port of an authenticating IAS, as shown:
[-i UserID[/Password][@Host[/Port]]]
If Host and Port are not specified, the values entered in the AuthenticationServerAddress parameter in mclient.conf are used. If the AuthenticationServerAddress parameter is not present in the mclient.conf file and no host and port number are specified when -i is entered, default Impact Administration Server port number on the local host is used. Any arguments entered with the -i option override the AuthenticationServerAddress parameter in mclient.conf.
NOTE
If the AuthenticationServerAddress parameter is present in the mclient.conf file with
no value specified and the host and port are not specified with -i on the command line, CLI execution will display a Failed to connect to IAS authentication server error message.
To enforce user authentication through IAS, the mcell.dir file must be unreadable for CLI users. However, the cell still needs this file to be able to connect to other cells, so the mcell.dir file has to remain readable for the user running the cell. To make the mcell.dir file unreadable for CLI users, but readable to the user running the cell, install and run the cell (using the mcell command) as one user. That user should be the only user to own and have read permission for the mcell.dir file. The CLI should be run as another user.
BMC Impact Manager CLI common return codes

Table 66 on page 214 describes the return codes common to all CLI commands. Some CLI commands have return codes that are specific to that command. If a CLI command has command-specific return codes, those codes are listed in the section of this appendix dedicated to that command.
Appendix A
213
mccompCompiling rules in the Knowledge Base
Table 66
Code 0 1 10 11 12 13 14 15 16 17 20 25 26 27 28
Common return codes for CLI commands

Description success bad usage (command includes nonexistent options or an invalid combination of options and arguments) initialization failure trace initialization failed configuration initialization failed outbound communication setup failed inbound communication setup failed message handling initialization failed persistency setup failed port range limitation failed connection to cell failed memory fault command failed syntax error invalid answer received

The mccomp command is the executable that calls the Knowledge Base compiler. The only required command option is the path to the manifest.kb file.
mccomp syntax
Figure 31 shows the syntax for mccomp. Figure 31 mccomp syntax
mccomp [-e ErrorLogFile] [-h|?] [-n CellName | ManifestKBFilePath] {-p Var=Value} [-l HomeLocation] [-t] [-v [VERBOSE|INFORM|WARNING|ERROR|FATAL]] [-z]
Table 67 lists the command-specific options for mccomp. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211.
214
Table 67
Option
mccomp options
Description redirects error messages to a user-specified file; used primarily in scripts
-e ErrorLogFile -n CellName | ManifestKBFilePath
specifies to use $MCELL_HOME/etc/CellName/kb/manifest.kb as the KB manifest file.

This option is ignored if ManifestKBFilePath is specified explicitly.
-t - v [VERBOSE|INFORM|WARNING |ERROR|FATAL]
generates tracing calls in the resulting compiled files for debugging purposes sets the verbosity level of messages. Only messages of the specified level or higher are printed. If -v is not used, the default level is INFORM. If -v is used without specifying a level, the default level is VERBOSE.
The -t option enables extra cell runtime tracing by the rules engine if the cell configuration parameter TraceRuleLevel=2. The trace output goes to the standard cell trace in the RULES module. You can include the output in the transaction file by setting TraceRuleToXact=Yes.
WARNING
A Knowledge Base compiled for runtime rule tracing using -t can experience considerable runtime performance degradation.
mccomp example
Figure 32 shows an example of mccomp. Figure 32 mccomp example
mccomp -n cell1
This command produces output similar to the example shown in Figure 33. Figure 33 Example output for mccomp
Parsing BAROC file classes/root.baroc Parsing BAROC file classes/intevt.baroc Compilation ended successfully
mccomp return codes

There are no command-specific return codes for mccomp. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.
Appendix A
215
mcellStarting a cell
The mcell command starts a specified cell.
mcell syntax
Figure 34 shows the syntax for mcell. Figure 34 mcell syntax
mcell [-h|-?] [-z] [-q] [-d] [-i [a][c][d][e]] [-r] [-n cellName] [-l HomeLocation] [-c ConfigFile] {-p Var=Value}
Table 68 lists the command-specific options for mcell. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 68
Option -c
mcell options
Description specifies a configuration file other than the default. If -c is used, all configuration files are assumed to be in the directory in which the specified configuration file is located. runs in foreground instead of as a service or daemon initializes the cell repository; can combine with suboptions:
I I I I I
-d -i
-i-ied -ieevents -iddata--initializes all data -icEventCounter -ia-iedcinitializes all data
Warning: Although these options are available, BMC Software recommends that you do not use an of the -i options except for -ia. Unexpected cell states can occur if you initialize only events or only data, because events and data may be correlated. If you need to restart a cell from an empty state, empty the cell's log directory (MCELL_HOME/log/CellName) and then start the cell without using any of the -i options. Note: If you start a cell using the -ia or -id options, you must re-register the cell with the BMC Impact Portal. Note: The -i option for the mcell command overrides the -i option in Table 65 Common options for CLI commands on page 211. -r runs in cell recovery mode
216
mcell example
On UNIX, mcell can be started from a command prompt as a daemon (running in background) or as a terminal program (running in foreground). On Microsoft Windows, mcell can be started from a command prompt as a service or as a terminal program. You can start the cell using any of the following methods:
I
To start the cell in the foreground rather than as a service or daemon on UNIX and Microsoft Windows platforms, type the command shown in Figure 35. Starting a cell
Figure 35
mcell -n cellName -d
NOTE
When starting BMC Impact Solutions software as a daemon process on UNIX platforms, use the method described in the BMC Impact Solutions Getting Started Guide.
To start the cell as a service on a Microsoft Windows platform, type the command shown in Figure 36. Starting a cell as a service on windows
Figure 36
net start mcell_cellName
When started from command prompt without the -d option, mcell contacts the Service Control Manager to start itself as a service. It uses mcell_cellName as the service name, with the cell name as specified with the -n option. Without the -n option, the host name is taken as cellName.
I
To start the BMC Impact Solutions service on Microsoft Windows and initialize the dynamic data in the cell, type the following command shown in Figure 37. Starting the BMC Impact Manager service on Microsoft Windows
Figure 37
net start mcell_cellName -ia
WARNING
If you start a cell with the mcell -ia or mcell -id commands, you must re-register the cell with the BMC Impact Portal.
Appendix A
217
mcfgtraceConfiguring tracing
mcell return codes

Table 69 lists the command-specific return codes for mcell. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 69
Code 2 3 4 5 19 29 37 39 47 49 57 59 67 69 77 79 97
mcell return codes

Description bad home directory option usage no home directory specified invalid home directory specification application system initialization failed logging facility initialization failed Knowledge Base load failed message handling module initialization failed internal object initialization failed event processing module initialization failed save state reload failed query handling module initialization failed service activation failed internal event module initialization failed metrics initialization failed data processing module initialization failed metrics activation failed service setup failed
The mcfgtrace command modifies the tracing configuration of a running cell and takes the same argument format as a line in the mcell.trace file. See BMC Impact Manager CLI trace configuration on page 272 for instructions on setting up CLI trace configuration files.
mcfgtrace syntax
Figure 38 shows the syntax for mcfgtrace.
218
Figure 38
mcfgtrace syntax
mcfgtrace [-h|-?] [-z] [-q] [-c ConfigFile] [-l HomeLocation] {-p Var=Value} [-i UserID[/Password][@Host[/Port]]] [-n cellName|-n @Host[/Port[#Key]]] [-v] (Module Level Destination | Module SWITCH Switch Destination)
The -n option is required if the cell is remote or if cellName differs from Host. See Using the -n option on page 211 for more information. Table 70 lists the command-specific option for mcfgtrace. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 70
Option Module Level Destination
mcfgtrace option
Description See mcfgtrace parameters on page 219.
mcfgtrace parameters
Table 71 lists the parameters for mcfgtrace. Table 71
Parameter Module Level SWITCH Destination
mcfgtrace parameters
Available values ALL | Module ALL | VERBOSE | INFORM | WARNING | ERROR | FATAL SwitchName no | stderr | console | DestinationFileName
mcfgtrace example
To activate maximum tracing for all modules and send the output to the file all.trace in the temporary directory for Cell1, which is by default MCELL_HOME\tmp\Cell1, type the command shown in Figure 39. Figure 39 mcfgtrace example
mcfgtrace -n Cell1 ALL ALL '%T/all.trace'
mcfgtrace return codes

There are no specific return codes for mcfgtrace. See BMC Impact Manager CLI common return codes on page 213 for a list of common return codes that apply to all CLI commands.
Appendix A
219
mclassinfoRequesting class information

The mclassinfo command retrieves class information about both event and data classes that are loaded in the cell. Information consists of class name, slot descriptions, and subclasses. You can retrieve the complete class tree in a hierarchical form, or you can retrieve only selected classes, instead of the whole hierarchy. You can retrieve associated definitions of enumerations used in the classes. These definitions are reported before the class tree.
mclassinfo syntax
Figure 40 shows the syntax for mclassinfo. Figure 40 mclassinfo syntax
mclassinfo [-a Amount] [-d] [-e] [-c ConfigFile] [-h|-?] [-l HomeLocation] [-i UserID[/Password][@Host[/Port]]] [-n cellName | -n @Host[/Port[#Key]]] [-o OutputFile] [{Class}] {-p Var=Value} [-r] [-q] [-u] [-v] [-x] [-z]
Table 72 lists the command-specific options for mclassinfo. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 72
Option -a Amount -d -e -o OutputFile -r -u -x Class
mclassinfo options
Description specifies the amount of information: 0, 1, 2, 3 (See Information amount on page 222); default is 2 reports data class definitions instead of event class reports enumeration definitions used in the classes produces the output in a file called OutputFile, instead of using standard output produces raw output for programs reports unique slots only, excluding redefined slots in subclasses reports enumeration definitions only (exclude classes) names of selected classes
mclassinfo output
You can request output in raw format for parsing by a program. You can also request standard output formatted for users, including verbose output that provides additional information. See Table 72 for the available options.
Raw output format

The output consists of the class tree, optionally preceded by the enumeration definitions, as shown in Figure 41 on page 221. The enumeration definitions are reported as EnumInfo. Figure 41 Raw output format for mclassinfo
= = EnumTypeCount (EnumTypeInfo)*EnumTypeCount EnumTypeName EnumValCount (EnumValName)*EnumValCount
EnumInfo EnumTypeInfo
The class tree is reported depth-first, left-to-right, as ClassInfo, as shown in Figure 42. Figure 42 Class tree for mclassinfo
ClassInfo ClassCompInfo
= ClassCompCount(ClassCompInfo)*ClassCompCount = ClassName ClassFlags ClassSlotCount (ClassSlotInfo)*ClassSlotCount ClassInfo ClassSlotInfo = ClassSlotName ClassSlotValType ClassSlotRepType ClassSlotFlags ClassSlotDefaultValueLength ClassSlotDefaultValueText ClassSlotValType = ClassSlotStructCode ClassSlotTypeCode ClassSlotStructCode = S | L ClassSlotTypeCode = i | r | p | s | e:EnumerationTypeName | c | c:BaseClass | q | q:BaseClass ClassSlotFlags = (r|R) (k|K) (p|P) (d|D) (h|H)
Slot value types (ClassSlotValType) are encoded by two characters. The first one indicates whether it is a simple slot (S) or a list (L). List slots are defined in BAROC as LIST_OF. The second character determines the type of the slot value. It corresponds to the BAROC definition as listed in Table 73. Table 73
Slot Type i r p s e;EnumerationTypeName c:BaseClass q:BaseClass
Type of slot value for mclassinfo

Definition INTEGER REAL POINTER STRING Enumeration ECF of BaseClass QUERY of BaseClass
A slot representation type (ClassSlotRepType) corresponds to the representation facet of the slot. If that facet is not specified, it is reported as an asterisk (*).
Appendix A
221
Flags contain Boolean facets of the slot. For every facet, one character is reported. An uppercase character means the facet is TRUE; a lowercase character means it is FALSE. Table 74 on page 222 lists the facets that are reported. Table 74
Facet r|R k|K p|P d|D h|H
Reported facets
Function read_only key parse dup_detect hidden
Table 75
Flag p|P
Class flags
Function publishable class
Standard output format

Standard output format is formatted for end-users but does not report the counts and represents the tree structure through indentation.
Information amount
The amount of reported information is limited as shown in Table 76. Table 76
Option -a 0 -a 1 -a 2 -a 3
Information amount limitation options for mclassinfo

Description reports only class names; no slot information is reported reports slot names adds slot names and representation type (default) adds slot flags and default value
mclassinfo examples
mclassinfo can be used as shown in the following examples.
222
Obtaining a list of classes

To obtain a list of classes used by a cell named grace, type the command shown in Figure 43. Figure 43 Example of mclassinfo command for a list of classes
mclassinfo -n grace -a 0
Figure 44
Example output of mclassinfo command for a list of classes
Class: CORE_EVENT Class: MC_CELL_CONTROL Class: MC_CELL_START Class: MC_CELL_STOP Class: MC_CELL_TICK Class: MC_CELL_STATBLD_START Class: MC_CELL_STATBLD_STOP Class: MC_CELL_DB_CLEANUP Class: MC_CELL_CONNECT Class: MC_CELL_CONNECT_RESOURCES_EXPANDED Class: MC_CELL_CONNECT_SUSPENDED Class: MC_CELL_CONNECT_RESUMED Class: MC_CELL_CLIENT .
Obtaining a List of Slot Names

To obtain a list of slot names used by a cell named grace, type the command shown in Figure 45. Figure 45 Example of mclassinfo command for list of classes
Figure 46 shows an example of the output. Figure 46

Class: Slot: Slot: Slot: Slot: Slot: Slot: . . .
Example of mclassinfo command output for list of classes

CORE_EVENT event_handle mc_ueid source sub_source hostname origin
Appendix A
223
Adding Slot names and representation types

To add slots names and representation types for use by a cell named grace, type the command shown in Figure 47 on page 224. Figure 47 Example of mclassinfo command for adding slot names

Example of mclassinfo command output for adding slot names

CORE_EVENT -Flags: p event_handle - Type: INTEGER mc_ueid - Type: STRING source - Type: STRING sub_source - Type: STRING hostname - Type: STRING origin - Type: STRING
Adding slot flags and default values

To add slot flags and default values for use by a cell named grace, type the command shown in Figure 49. Figure 49 Example of mclassinfo command for adding slot flags

Example of mclassinfo command output for adding slot flags

CORE_EVENT -Flags: p event_handle - Type: INTEGER - Flags: rkpdh - Def: 0 mc_ueid - Type: STRING - Flags: rkPdh - Def: source - Type: STRING - Flags: rkPdh - Def: sub_source - Type: STRING - Flags: rkPdh - Def: hostname - Type: STRING - Flags: rkPdh - Def: origin - Type: STRING - Flags: rkPdh - Def:.
224
mcollinfoGetting information about a specific collector
mclassinfo return codes

Table 77 lists the command-specific return codes for mclassinfo. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 77
Code 31
mclassinfo return codes

Description cannot read input file

The mcollinfo command retrieves information about collectors loaded in a cell. Information consists of collector name, permission settings, referenced classes and subcollectors. The complete collector tree is retrieved and reported in a hierarchical form. As an option, specific information about selected collectors can be retrieved instead of the whole tree.
mcollinfo syntax
Figure 51 shows the syntax for mcollinfo. Figure 51 mcollinfo syntax
mcollinfo [-a Amount] [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]] [-h|-?] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-r] [-o OutputFile] [-v] [-q] [-z] (-d | [-g] [-s] (Collector | -f InputFile))
The -n option is required if the cell is remote or if cellName differs from Host. See Using the -n option on page 211 for more information. Table 78 lists the command-specific options for mcollinfo. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 78
Option -a Amount -d -f {InputFile}
mcollinfo options (part 1 of 2)

Description specifies the amount of information (0, 1, 2); the default is 2. For more information, see Information amount on page 222. reports collector definitions reads collectors from InputFile instead of from command line
Appendix A
225
Table 78
Option -g
mcollinfo options (part 2 of 2)

Description reports collector object identifier (OID) produces the output in a file called OutputFile, instead of using standard output produces raw output for programs reports collector status and severity counters specifies the collector name or OID with optional + suffix for closure
-o OutputFile -r -s Collector
mcollinfo output
You can request output in raw format for parsing by a program. You can also request standard output formatted for users, including verbose output that provides additional information. See the preceding table for the available options.
Raw output format

Raw output consists of the collector tree, as shown in Figure 52 on page 226. The collector tree is reported depth-first, left-to-right, as CollInfo. Figure 52 Raw output format for mcollinfo
CollInfo = CollCompCount (CollCompInfo)*CollCompCount CollCompInfo = CollName CollPerm CollClassCount (CollClass)*CollClassCount CollInfo CollPerm : CollPermR CollPermW CollPermX CollPerm_ : CollRoleCnt (CollRole)*CollRoleCnt

Standard output is essentially the same as raw output, but standard output does not report the counts. Standard output represents the tree structure through indentation. By default, it reports permissions as a sequence of role numbers. Classes are reported as object identifiers (OIDs). In verbose-formatted output, it reports roles and classes with their names instead of numbers or OIDs.
226
Information amount
The amount of reported information is limited as shown in Table 79. Table 79
Option -a 0 -a 1 -a 2
Information amount limitation options for mcollinfo

Description reports only collector names add permissions add referenced classes
mcollinfo examples
Figure 53 shows an example of mcollinfo. Figure 53 mcollinfo example
mcollinfo -n dbg -o Net.Global 6.1
You can request user-formatted output in verbose mode as shown in Figure 54. Figure 54 mcollinfo command for verbose mode
mcollinfo -n dbg -v -o Net.Global Collector Net.Global OID=6.1
You can also request the number of events for each severity/status combination in the collector as shown in Figure 55. You must specify the collector name. Figure 55 mcollinfo command for number of events for severity/status
mcollinfo -n dbg -v -s Net.Global Collector Net.Global Severities=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Appendix A
227
mcontrolPerforming cell control operations
mcollinfo return codes

Table 80 lists the command-specific return code for mcollinfo. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 80
Code 31
mcollinfo return codes

Description cannot read input file

The mcontrol command performs control operations on a cell. The operation is stated as an argument.
mcontrol syntax
Figure 56 on page 228 shows the syntax for mcontrol. Figure 56 mcontrol syntax
mcontrol [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-v] Control [ -i UserID[/Password][@Host[/Port]] ]
The -n option is required if the cell is remote or if cellName differs from Host. See Using the -n option on page 211 for more information. Table 81 lists the command-specific option for mcontrol. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 81
Option Control
mcontrol option
Description specifies the control command to use. See Table 82 for the available control commands.
228
Table 82 lists the following controls that are available. Table 82

Control metrics [on|off|reset]
mcontrol controls (part 1 of 2)

Description on = enables metrics off = disables metrics reset = resets running counters If an argument is not specified, metrics are reported by default.
pause prop [{Destination}]
suspends reception of adapter messages; events are no longer accepted if one or more Destinations are mentioned, only propagations to these destinations are retried; if no Destinations are specified, all pending propagation destinations are retried reload cell configuration, for one or more categories; if you do not choose an argument, all categories reload
I I I I I I I
reload [{dir|trace|conf|collect |kb|data|all}]
dirmcell.dir tracemcell.trace confmcell.conf, propagate, modify collectcollector definitions kbKnowledge Base, classes, rules datadata instances allall the categories
restart shutdown standby start statbld
stops and restarts the cell terminates the cell in fast shutdown mode; same as mkill -s switches cell to standby mode resumes reception of adapter messages; cell operates normally again forces the cell to perform a StateBuild immediately instead of waiting for the next scheduled StateBuild; mcontrol waits until termination of the forced StateBuild and, if successful, returns the path to the resulting saved state file terminates the cell in normal mode; same as mkill turns rule tracing on or off
stop tracerule on|off
Appendix A
229
Table 82
Control
mcontrol controls (part 2 of 2)

Description modifies the configuration of which rule phases are enabled for tracing. The Phases value has the same format as the TraceRulePhases parameter. For example, mcontrol -n CellName tracerule phases -new, -abstract This command disables tracing of all new and abstract rules.
tracerule phases Phases
tracerule names Names
modifies the configuration of which rules are enabled for tracing. The Names value has the same format as the TraceRuleNames parameter. For example, mcontrol -n CellName tracerule names problem_rule
This command enables tracing of the rule named problem_rule (assuming that problem_rule is of a phase that has rule tracing enabled).
mcontrol examples
mcontrol can be used as shown in the following examples.
Retrying pending propagations

To retry pending propagations for a cell named grace, type the command shown in Figure 57. Figure 57 Retrying Pending propagations with mcontrol command
mcontrol -n grace -v prop
Figure 58 shows an example of the output. Figure 58 Example of mcontrol command output for retrying pending propagations
Command on server grace acknowledged
Terminating a cell
To terminate a cell named grace, type the command shown in Figure 59. Figure 59 Terminating a cell using the mcontrol command
mcontrol -n grace -v stop
230
mcrtcellCreating a new cell
Figure 60 shows an example of the output. Figure 60 Example of mcontrol command output for terminating a cell
Reconfiguring a cell
To reconfigure cell grace after mcell.dir has been modified, type the command shown in Figure 61. Figure 61 Reconfiguring a cell
mcontrol -n grace reload dir
Figure 62 shows an example of the output. Figure 62 Example of mcontrol command output for reconfiguring a cell
The cell grace reconfigures without stopping and restarting.
mcontrol return codes

There are no command-specific return codes for mcontrol. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.

Use the mcrtcell command to create a new cell or to recreate an Admin cell that you have accidentally removed. You can only run the mcrtcell command on the local computer where you are creating the new cell or recreating the Admin cell.
Cell names
Cell names must be unique throughout the enterprise.
WARNING
Cells with identical cell names on different computers within your enterprise will cause unexpected results.
Appendix A
231
The cell name cannot contain spaces or special characters. You can use any alphanumeric string and underscores (_) in a cell name, such as the following:
I I I
my_cell spike12 oracle
Do not give a cell the same name as any item in the MCELL_HOME\etc directory, such as the KB directory or the mcell.conf, mcell.dir, or mcell.trace files. Using the mcrtcell command to add cells ensures that the cell names are unique.
TIP
When naming cells, adopt a naming convention for test and production cells that clearly identifies its purpose. For example, you could assign test cells names that use test as a prefix or suffix. A clear naming convention is important because in BMC Impact Explorer views there is no way to distinguish test and production cells other than by the cell name.
mcrtcell actions
The mcrtcell command performs the following actions:
I
determines if an entry exists in the mcell.dir file that matches the cell being created If a matching entry exists, the creation fails. You can use the -f option to force the creation of the cell.
creates the etc\cellName directory, which contains a Knowledge Base copied from the etc\default\SIM\kb directory creates a services entry on Microsoft Windows, unless you specify the -m option adds an entry to the local mcell.dir file creates an entry in the startup scripts on UNIX platforms, unless you specify the -m option recreates an Admin cell using the -aa option
UNIX files
When you install the cell or run mcrtcell -ae|-as -p PortNumber cellName on a UNIX system, you create the files listed in Table 83 on page 233 that enable the cell to start on reboot and to stop on shut down. If you run mdelcell cellName, these files are automatically removed.
232
Table 83
Platform
Files for UNIX

File etc/cellName.d sbin/init.d/mc_cellName etc/init.d/cellName etc/rc2.d/K99cellName etc/rc2.d/S99cellName
AIX platforms HP-UX platforms Solaris platforms
Linux platforms
etc/rc.d/init.d/mc_cellName etc/rc.d/rc3.d/K99mc_cellName etc/rc.d/rc3.d/S99mc_cellName
After you configure the cell, you must stop and restart it for the changes to take effect. For instructions, see the BMC Impact Solutions Getting Started Guide.
mcrtcell syntax
Figure 63 shows the syntax for mcrtcell. Figure 63 mcrtcell syntax
mcrtcell [-ae|-as|-aa] NewcellName [-f] [-h|-?] [-l HomeLocation] [-m] -p PortNumber [-s SourceCell] [-z]
Specifying either the -ae or -as option creates a unified Knowledge Base, which contains the default BEM and SIM KBs (see the BMC Impact Solutions Knowledge Base Development Reference Guide for information about the unified KB). If you do not specify the -ae or -as option, you create a cell with an empty Knowledge Base, and the cell does not respond to requests.
NOTE
By default, mcrtcell creates a BEM cell. If you want to create a SIM cell, you must create a cell using mcrtcell and then set the ServiceModelEnabled configuration parameter to YES in the mcell.conf file. For more information about the ServiceModelEnabled configuration parameter, see Cell configuration parameters on page 274.
Table 84 lists the command-specific options for mcrtcell. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 84
Option -aa -ae
mcrtcell options (part 1 of 2)

Description recreates an Impact Administration cell with an Admin Knowledge Base creates a BMC Event Manager cell with a unified Knowledge Base
Appendix A
233
Table 84
Option -as -f
mcrtcell options (part 2 of 2)

Description creates a Service Impact Manager cell with a unified Knowledge Base forces the creation of a cell when the mcell.dir file contains an entry of the same name; reinstalls the Knowledge Base If you do not use this option, mcrtcell exits without creating a new cell when it finds a duplicate entry in the mcell.dir file.
-m -p PortNumber
prevents automatic restart on reboot specifies the cell port number (PortNumber) Note: The -p option for mcrtcell overrides the common CLI -p option listed in Table 65 Common options for CLI commands on page 211.
-s SourceCell NewcellName
specifies the cell (SourceCell) from which to copy a Knowledge Base specifies the name for the cell being created. For information about cell naming conventions, see Cell names on page 231.
mcrtcell example
Figure 64 shows an example of how to create a service using mcrtcell. Figure 64 Example of mcrtcell command
mcrtcell -p 2591 -as was05dal
Figure 65 shows the output produced. Figure 65 Example of output of mcrtcell
Service successfully created
Figure 66 shows an example of how to create another service using mcrtcell. Figure 66 Example of mcrtcell command
mcrtcell -s was05dal -p 2592 was04fra
NOTE
This command does not use the -ae or -as option. It makes a copy of the KB from the previous cell.
Figure 67 shows the output produced. Figure 67 Example output of mcrtcell
Service successfully created
234
mcstatReturning cell status
Figure 68 shows an example of how to create an Impact Administration cell using mcrtcell. Figure 68 Example mcrtcell for recreating an Admin cell
mcrtcell -aa -p 10011 Admin
In this example, an Impact Administration cell with the name Admin is created and assigned to port number 10011.
mcrtcell return codes

Table 85 lists the command-specific return codes for mcrtcell. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 85
-1 3 31 32 33 34 35 36 37 38
mcrtcell return codes
Code Description uname command failed MCELL_HOME environment variable not set or duplicate cell name or port definition in mcell.dir no MCELL_HOME environment variable is defined duplicate cell definition in mcell.dir existing cell with same name on a different host existing cell with same name on a different port existing cell with same name on a different host/port failed to create new directory cannot get OS failed to remove a cell

The mcstat command obtains the status of a cell. This command shows whether a cell is running or stopped.
Appendix A
235
mcstat Syntax
Figure 69 shows the syntax for mcstat. Figure 69 mcstat syntax
mcstat [-h|?] [-z] [-q] [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-v] [-t TimeOut ]
Table 86 lists the command-specific option for mcstat. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 86
Option -t TimeOut
mcstat option
Description specifies the length of time, in milliseconds, for the command to wait for answer before terminating; default is 60000, or 1 minute
mcstat example
To obtain the status for a cell named examplecell, type the command shown in Figure 70. Figure 70 mcstat example
mcstat -n examplecell
If the cell is not running, a message similar to the example in Figure 71 appears. Figure 71 Message for cell not running
Could not connect to Cell examplecell.
If the cell is running, the message shown in Figure 72 appears. Figure 72

Running
Message for cell running
mcstat return codes

There are no command-specific return codes for mcstat. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.
236
mdelcellDeleting a cell
mdelcellDeleting a cell
Use mdelcell to delete a specified cell on the local computer. Deleting a cell by using the mdelcell command removes the cell and its entry in the mcell.dir file. You can use this command only locally on the computer where the cell resides. Executing this command results in the following actions:
I I I
removes the entry in the mcell.dir file deletes the etc\cellName removes the entry from the services on Microsoft Windows or the startup scripts on UNIX
mdelcell syntax
Figure 73 shows the syntax for mdelcell. Figure 73 mdelcell syntax
mdelcell cellName [-i UserID[/Password][@Host[/Port]]] [-z] [-h|?] [-k] [-w TimeOut]
Table 87 lists the command-specific options for mdelcell. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 87
Option -k -w TimeOut
mdelcell options
Description keeps tmp and log directories of the cell specifies the length of time, in seconds, for the command to wait when terminating the cell.
mdelcell example
To delete a cell named grace, type the command shown in Figure 74. Figure 74 Deleting a cell using mdelcell
mdelcell grace
If grace is not currently running, this command produces output similar to the example shown in Figure 75 on Microsoft Windows platforms: Figure 75 Output for mdelcell if cell is not running
Service successfully removed
Appendix A
237
mgetinfoRetrieving information about a cell
On UNIX platforms, the command does not produce output when it runs successfully. If grace is currently running, this command produces output similar to the example shown in Figure 76. Figure 76 Output for mdelcell if cell is running
Warning! Cell grace was running and mdelcell tries to terminate it. Service successfully removed.
mdelcell return codes

Table 88 lists the command-specific return codes for mdelcell. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 88
Code -1 31
mdelcell return codes

Description uname command failed no MCELL_HOME environment variable is defined

The mgetinfo command retrieves information about a cell.
mgetinfo syntax
Figure 77 shows the syntax for mgetinfo. Figure 77 mgetinfo syntax
mgetinfo [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]] [-h|?] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]] {-p Var=Value} [-q] [-v] [-z] Information
The -n option is required if the cell is remote and defined in the mcell.dir file, or if the cell is local and named something other than Host. Table 89 on page 239 lists the command-specific option for mgetinfo. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211.
238
Table 89
Option
mgetinfo option
Description
Information specifies the Information option to use. See Table 90 for the available Information options.
Table 90 describes the mgetinfo information options. Table 90

activity
mgetinfo information options (part 1 of 2)

Description retrieves the activity status of the cell 0 = standby 1 = limited 2 = full activity. retrieves configuration of a cell, including the cell name, home directory, Knowledge Base directory, and the full paths of all configuration files the cell uses retrieves information about the current connections that are open from and to the cell; see Table 91 for description of that information lists KB modules with version information from the cells loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format. lists KB source files with version information from the cells loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format. reports the metrics, collected by the cell, that are stored in MC_CELL_METRIC data objects metrics output consists of I metric name I metric description I short term, medium term and long term metric, each consisting of period of time for which the metric is counted (in seconds) total count of metric items during the period average occurrence of the metric item over the time period (in items per second) The following metrics are defined: I ReceivedEventsnumber of received event messages I ErrorEventsnumber of received event messages that are incorrect (for example, causing a parse error) I DroppedEventsnumber of events that are dropped during processing through the rules I StoredEventsnumber of events that have passed all the rules and are stored in the Event database I RemovedEventsnumber of events that have been removed from the Event database by a database cleanup I DeletedEventsnumber of events that have been deleted by clients, such as CLI or the console I PropagatedEventsnumber of events that have been propagated to another destination I ConnectedSourcesnumber of adapter clients that are connected to the cell
Information
config connect kbmodules
kbsources
metrics
Appendix A
239
Table 90
param
mgetinfo information options (part 2 of 2)

Description retrieves the options found in the mcell.conf file This information does not necessarily represent the effective values of these options. If the value is set to an out-of-range value, that value is returned, but the effective value used internally will be the range boundary. NOTE: All parameter settings are returned in order of definition. There can be multiple settings for the same parameter. Only the last setting reported is effective.
Information
services version
reports service metrics counting the components and relationships displays the version number of the cell
A connect request displays the information shown in Table 91. Table 91 Information from connect request
Description IN for incoming and OUT for outgoing This information refers to the initiator of the connection. An incoming connection means a client contacted the cell, while an outgoing connection means the cell itself contacted another cell. In both cases, data can flow in both directions. type of client name of connected program source address destination address Incoming Connections name of user time delta sequence sequence Outgoing Connections time stamp sequence message message timestamp of last connection setup or trial sequence number of last outgoing message number of messages waiting for connection opening number of messages waiting for answer the name of the user; example: Admin between both sender and receiver in seconds, to be added to time stamps coming in to convert to the cell time sequence number of last incoming message sequence number of last answer the client type, such as unknown, cell, browser, adapter, CLI, and EIF, which are reported as literal values the name of the connected program (for example: Impact Explorer, mposter, cellName) IP address/port of source side of the connection for inbound connections, this is the client; for outbound, it is the cell IP address/port of destination side of the connection for inbound connections, this is the cell; for outbound, it is the destination
Connect information All Connections direction
240
mgetinfo examples
This section contains examples of mgetinfo.
mgetinfo config example

mgetinfo -n aspen config
This command produces output similar to the following:

cellName=aspen HomeDir=C:/mcell/server KBDir=C:/mcell/server/etc/aspen/kb/ ConfigFile=C:/mcell/server/etc/mcell.conf TraceConfigFile=C:/mcell/server/etc/mcell.trace TraceDefaultFile=C:/mcell/server/tmp/aspen/trace ServerDirectoryFile=C:/mcell/server/etc/mcell.dir PropagateConfigFile=C:/mcell/server/etc/mcell.propagate ModifyConfigFile=C:/mcell/server/etc/mcell.modify
mgetinfo metrics example

mgetinfo metrics
This command produces output similar to the following:

BMC Impact InfoRetrieval 7.x.xx (Build xxxxxx - xx-xxx-xxxx) Copyright 1998-xxxx BMC Software, Inc. as an unpublished work. ReceivedEvents Number of received event messages 60 0 ErrorEvents Number of events containing errors 60 0 DroppedEvents Number of events dropped by rules 60 0 StoredEvents Number of events entered in the DB 60 0 RemovedEvents Number of events removed by DB cleanup 60 0 DeletedEvents Number of events deleted by clients 60 0 PropagatedEvents Number of propagated events 60 0 ConnectedSources Number of connected sources 60 0 All 0 0 0 0 0 0 0 0 rights reserved. 300 1 0 3616974 300 0 0 3616974 300 1 0 3616974 300 0 0 3616974 300 0 0 3616974 300 0 0 3616974 300 0 0 3616974 300 0 0 3616974
12534 94 5700 6834 27451 0 102 0
0 0 0 0 0 0 0 0
The output for mgetinfo metric consists of the metric name, a metric description and short term, medium term and long term metrics, each consisting of
I I I
period of time for which the metric is counted (in seconds) total count of metric items during the period average occurrence of the metric item over the time period (in items per second)
For example, in the first line of the sample output,

I
the metric name is ReceivedEvents.
Appendix A
241
the description for ReceivedEvents is Number of received event messages the short term metric is 60 seconds during which 0 events were received, resulting in an average occurrence of 0 events received per second the medium term metric ran for 300 seconds during which 1 event was received, resulting in an average of 0 events received per second the long term metric ran for 3616974 seconds, during which 12534 events were received, resulting in an average of 0 events received per second
mgetinfo param example

Figure 78 shows an example of mgetinfo param. Figure 78 Example of mgetinfo param
mgetinfo -n aspen param
This command produces output similar to the example shown in Figure 79. Figure 79 mgetinfo param command output
Trace=Yes TraceSrc=No TraceRuleLevel=1 TraceConfigFileName=mcell.trace TraceDefaultFileName=%T/trace LicenseServer= CellOperationLevel=Consolidation CellOperationRelax=No . . .
mgetinfo services example

Figure 80 shows an example of mgetinfo services. Figure 80 Example of mgetinfo services
mgetinfo services
This command produces output similar to the example shown in Figure 81. Figure 81 mgetinfo services command output (part 1 of 2)
Number of MC SM Component Number of Connectivity 87 11
MC_SM_COMPONENT CONNECTIVITY 242
mgetrecObtaining a global record value
Figure 81
mgetinfo services command output (part 2 of 2)

Number Number Number Number Number Number of of of of of of IT Component Logical Component Service Level Agreement MC SM Relationship Impact Relationship Null Relationship 22 47 7 126 126 0
IT_COMPONENT LOGICAL_COMPONENT SERVICE_LEVEL_AGREEMENT MC_SM_RELATIONSHIP IMPACT_RELATIONSHIP NULL_RELATIONSHIP
mgetinfo connect example

Figure 82 shows an example of mgetinfo connect. Figure 82 Example of mgetinfo services
mgetinfo connect
This command produces output similar to the example shown in Figure 83. Figure 83 Output of mgetinfo connect
10.0.10.28:1828 Admin 0 2028 2071
IN browser ImpactExplorer 10.0.10.17:1545
mgetinfo return codes

Table 92 lists the command-specific return codes for mgetinfo. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 92
Code 31
mgetinfo return codes

Description not a SIM cell

Use the mgetrec command to obtain the value of a global record.
Appendix A
243
mgetrec syntax
Figure 84 shows the syntax for mgetrec. Figure 84 mgetrec syntax
mgetrec [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]] [-h|?] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] -r Record[.Slot] [-q] [-z]
The -n option is required if the cell is remote and defined in the mcell.dir file, or if the cell is local and named something other than Host. Table 93 lists the command-specific option for mgetrec. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 93
Option -r Record[.Slot]
mgetrec option
Description specifies the global record to be obtained, optionally limited to one of its slots
mgetrec example
Figure 85 shows an example of mgetrec. Figure 85 Example of mgetrec
mgetrec -r EM_KB_OPTIONS
The preceding command produces output similar to the example shown in Figure 86. Figure 86 Output of mgetrec (part 1 of 2)
startup_script_enabled ----NO ----dfilter_enabled ----NO ----dnotification_enabled ----NO ----dpropagation_enabled
244
mkbUpdating the Knowledge Base
Figure 86
Output of mgetrec (part 2 of 2)
----NO ----default_location -----
mgetrec return codes

There are no command-specific return codes for mgetrec. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.

Use the mkb command to create, view, or update the Knowledge Base. When you use the mkb command to create a new Knowledge Base, a manifest.kb file is also created. Use the mkb command primarily to check or modify a Knowledge Base with scripts, such as when you need to upgrade the Knowledge Base automatically for a number of cells installed across your network. After installing the files, compile using the mccomp command.
mkb syntax
Figure 87 shows the syntax for mkb. Figure 87
mkb [-f [-j [-r
mkb syntax
[-h|-?] [-z] [-q] [-v] [-n CellName | -n @Host[/Port[#Key]] ] ManifestFile] [-b BinFile] [-c ClassFile] [-d DataFile] [-a Arch] RecordFile] [-l LibFile] [-m Directory] [-o CollectorFile] [-p] RuleFile] [ -i UserID[/Password][@Host[/Port]] ]
Table 94 lists the command-specific options for mkb. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 94
Option -a Arch -b BinFile -c ClassFile
mkb options (part 1 of 2)

Description specifies the platform architecture binary file name imports the specified ClassFile.baroc that defines the class definitions
Appendix A
245
Table 94
Option
mkb options (part 2 of 2)

Description imports the specified DataFile.baroc that defines data instances specifies the path to the manifest.kb file imports RecordRile.baroc that defines the record definitions imports the specified library file (filename.wic). Note: The -l option for the mkb command overrides the -l option in Table 65 Common options for CLI commands on page 211.
-d DataFile -f manifest -j RecordFile -l LibFile
-m Directory -o CollectorFile -p
creates a new Knowledge Base directory hierarchy based on the contents of the designated manifest.kb file imports the specified CollectorFile.mrl that defines that collector definitions
prints the contents of the designated manifest.kb file, along with the names of the .load files in the various directories comprising the Knowledge Base
Note: The -p option for mkb overrides the common CLI -p option listed in Table 65 Common options for CLI commands on page 211.
-r RuleFile
imports the specified RuleFile mrl that defines the rule definitions
Use the options described in Table 95 to add new files to the Knowledge Base that you specified with the -f option. The new files are also described in Table 95. Table 95
-a Arch
mkb new file options

Description specifies the platform architecture:
I I I I I
mkb Option
h1 - HP-UX l2 - Linux p4 - AIX (Power PC) s5 - Solaris (Sparc) w4 - Microsoft Windows (Intel)
-b BinFile -c ClassFile
adds the binary file (BinFile) for the architecture adds the class file (ClassFile) to the designated Knowledge Base
-o CollectorFile adds the collector file (CollectorFile) to the designated Knowledge Base -d DataFile -l LibFile adds the data file (DataFile) to the designated Knowledge Base adds the library file (LibFile) to the designated Knowledge Base Note: The -l option for the mkb command overrides the -l option in Table 65 Common options for CLI commands on page 211. -r RuleFile adds the rule file (RuleFile) to the designated Knowledge Base
246
Each of the above options causes mkb to copy the designated files into the proper Knowledge Base directory and adds information to the .load file of that directory.
mkb examples
This section contains UNIX and Microsoft Windows examples.
UNIX example
Figure 88 shows an example of mkb on UNIX. Figure 88 mkb command on UNIX
mkb -f ./manifest.kb -p
This command produces output similar to the example shown in Figure 89 on a UNIX computer named spud. Figure 89 mkb output on UNIX
classes = \mcell\server\etc\spud\kb\.\classes load file: .load root.baroc intevt.baroc . . . patrol.baroc collectors = \mcell\server\etc\spud\kb\.\collectors load file: .load collectors.mrl internal.mrl Adapters.mrl catchall.mrl data = \mcell\server\etc\spud\kb\.\data load file: .load lib = \mcell\server\etc\spud\kb\.\lib load file: .load can not open file: \mcell\server\etc\spud\kb\.\lib\.load rules = \mcell\server\etc\spud\kb\.\rules load file: .load new.mrl records = \mcell\server\etc\spud\kb\.\records load file: .load intrec.wic Appendix A BMC SIM and EM CLI Reference 247
mkillStopping a cell
Microsoft Windows example

Figure 90 shows an example of mkb on Microsoft Windows. Figure 90 mkb command on Microsoft Windows
mkb -f kb\manifest.kb -m new_kb
This command produces output similar to the example shown in Figure 91 on Microsoft Windows. Figure 91 mkb command output on Microsoft Windows
manifest directory tree created successfully
mkb return codes

There are no command-specific return codes for mkb. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.
mkillStopping a cell
Use the mkill command to stop a running cell or gateway.
mkill syntax
Figure 92 shows the syntax for mkill. Figure 92 mkill syntax
mkill [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation][-v] [-s] [-i UserID[/Password][@Host[/Port]]]
If you do not specify a cell to stop, this command stops the default cell, Host. You must use the -n cellName option on multiple cell hosts.
248
mlogchkPerforming consistency checks
Table 96 lists the command-specific option for mkill. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 96
Option -s
mkill option
Description performs rapid shutdown termination; bypasses StateBuilder
mkill example
Figure 93 shows an example of mkill. Figure 93 Example of mkill
mkill -n examplecell
The preceding command produces output similar to the example shown in Figure 94. Figure 94 Output of mkill
server examplecell terminated
NOTE
The mkill -s command terminates a cell and bypasses the StateBuilder. If a user has cells set to run the StateBuilder before terminating, then mkill -s -n cellName overrides the StateBuilder option.
mkill return codes

There are no command-specific return codes for mkill. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.

The mlogchk command performs consistency checks on the persistency directory MCELL_HOME\log\cellName. This directory could be in an inconsistent state after abnormal cell or StateBuilder termination. It is an interactive tool that tells the operator what is wrong and what should be corrected. You must shut down the cell before running the checks because a running cell might modify the log directory during a check.
Appendix A
249
The mlogchk command does the following:

I
determines whether an mcdb.lock file exists and, if so checks for a running statbld and waits for termination reports trailing lock file and removes it (after confirmation)
determines whether an xact.1 file exists and, if so, reports and instructs the user to run statbld determines whether an mcdb.0 file exists and, if so, reports and proposes to rename or remove it
mlogchk syntax
Figure 95 shows the syntax for mlogchk. Figure 95 mlogchk syntax
mlogchk [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-v] [-i UserID[/Password][@Host[/Port]]]
There are no command-specific options for mlogchk.
mlogchk example
Figure 96 shows an example of mlogchk. Figure 96 Example of mlogchk
mlogchk -n spud -v
For a cell named spud, the preceding command produces output similar to the example shown in Figure 97. Figure 97 Output of mlogchk
Warning: Cell spud is running - this may influence the consistency check. To ensure correct results, you should shutdown the Cell now. Do you want to continue (y/n) ?
The output continues with the message shown in Figure 98 on page 251 if you respond with y.
250
mposter and msendManaging data and events
Figure 98
mlogchk message
No inconsistency found.
mlogchk return codes

Table 97 lists the command-specific return codes for mlogchk. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 97
Code 21
mlogchk return codes

Description cannot access cell log directory

NOTE
The mposter and msend commands can both be used to send or modify events, but mposter also can be used to send or modify data.
Use the msend command to manage events in a cell. Use the mposter command to manage data and events in a cell. You can create, modify, and delete data instances and events using the mposter command. BMC Software recommends that you use the msend command instead of the mposter command when you do not need to access or modify dynamic data or global records. The msend command is a more secure command because it is more restrictive than mposter.
WARNING
BMC Impact Solutions does not support using the mposter command to create or to edit service model component instances.Although it is possible to use the mposter command to create and to edit the service model class instances on a cell, these changes are made to only the BAROC service model running on the cell, not to the cells standard (reference) published service model in the CMDB. This causes a loss of service model integrity and subsequent service model publishings will fail.
You can use the mposter command to modify dynamic data objects in the cell even when the cell is paused.
Appendix A
251
mposter and msend syntax

Figure 99 shows the syntax for mposter. Figure 99 mposter syntax
mposter [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-y] [-f DirFile] [-v] [-i] [-I] [-x] [-u] [-w MSecAnswerWait] [-t MSecTerminationWait] [-j BufDir] [-d] [-e] [ - | {SourceFile} | -a Class [-o Source] [-m Message] [-r Severity] [-b SlotSetValue] | -l EventID [-b SlotSetValue]]
Figure 99 shows the syntax for msend. The syntax for msend very similar to mposter except that mposter supports the -d option. Figure 100 msend syntax
msend [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-y] [-f DirFile] [-v] [-i] [-I] [-x] [-u] [-w MSecAnswerWait] [-t MSecTerminationWait] [-j BufDir] [-d] [-e] [ - | {SourceFile} | -a Class [-o Source] [-m Message] [-r Severity] [-b SlotSetValue] | -l EventID [-b SlotSetValue]]
Table 98 lists the command-specific options for mposter and msend. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 98
Option -a Class -b SlotSetValue
mposter and msend options (part 1 of 2)

Description input from standard input stream sends an object of class Class adds SlotSetValue settings (format: slot=value;...) For example, -b "msg='this is a test';mc_tool=computer;"
- d -e -f DirFile -i -I -j BufDira
(Used with mposter only.) sends as data instead of as event specifies to use EIF instead of MCELL format specifies the directory file path; the default value is MCELL_HOME\etc\mcell.dir sets to interactive mode reinitializes persistent buffers sets the directory to be used for persisting events that are buffered until they are sent
252
Table 98
Option
mposter and msend options (part 2 of 2)

Description modify the specified event instead of a new event. The event ID is the event_handle slot for the event. For example -l 11532 Note: The -l option for this command overrides the -l option in Table 65 Common options for CLI commands on page 211.
-l EventID
-m Message -o Source -p Var=Value
sets event message to the specified Message text sets event source to the specified Source this common CLI option can be used to specify the directory path to the source file using the following syntax: -p ServerDirectoryName=ServerDirectoryPath The default value is $MCELL_HOME\etc\mcell.dir
-r Severity
sets the event severity value to the Severity specified For example, -r WARNING or -r CRITICAL
-t MSecTerminationWait -u -w MSecAnswerWait
sets the length of time in milliseconds to wait for trailing answers before terminating; default is 5000 leave messages unanswered sets the length of time in milliseconds to wait for message answer; default is 0. If set to 0, the mposter/msend command waits for the answer until the connection times out. examines timings immediately terminate upon connection failure
-x -y
a
It is possible for msend and mposter to use a different file other than /etc/itm/.reg/Buffers for the persistent buffer location. In the $MCELL_HOME/etc directory, create msend.conf and mposter.conf files that contain a MpServerRegisterFile parameter. The value for this parameter is the name of the file that will contain the location of the persistent buffer directory. For example: MpServerRegisterFile=/opt/mcell/buffers
NOTE
To send a punctuation mark as part of a text field using msend or mposter, enclose the value within a set of single quotation marks ( ) framed by a set of double quotation marks( ). For example, if you were sending a semicolon (;) as part of a text field it would look like this: msend -n CellName -m "'a;b'"
Appendix A
253
mposter examples
NOTE
All examples and information in this section also can apply to msend.
Figure 101 shows an example of mposter. Figure 101 Example of mposter

mposter -n aspen -v -
The information for the event is entered using BAROC-style input as shown:
HOST_DOWN; origin='HOST_DOWN'; msg='host blue is down'; END
The output of the mposter session is similar to the following:

Message 1 - evtid = 11142
Then the following would be input:

HOST_DOWN; origin='HOST_DOWN'; msg='host orange is down'; END
And the mposter output would be similar to the following:

Message 2 - evtid = 24233
In the example shown in Figure 102, mposter adds an instance of the DATA class AppByHost to the host aspen. The example uses dynamic data technology in the following ways:
I I I
specifying that the instance to add is an instance of AppByHost defining the host as aspen specifying that it defines applications as word or excel
You can use the mposter command to change any one of definitions without changing any of the others.
Figure 102 Definition changes using mposter

mposter -n aspen -a AppByHost -d -b "host='aspen'; applications=['word','excel']"
The preceding command does not produce any output.
NOTE
On Microsoft Windows, the mposter and msend commands accept only double quotes with the -b option. If you use single quotation marks with the -b option on Microsoft Windows, the event is not sent, and no error message appears. On UNIX, with the with the -b option, the command accepts both single and double quotation marks.
Enabling persistent buffering

To enable persistent buffering, first create a writeable directory (BufDir in Figure 103), then use the syntax shown in Figure 103. Figure 103 Enabling persistent buffering using mposter
mposter [current options] -j BufDir
The mposter.lck and persist.dat files are placed in BufDir after the mposter (or msend) command is executed. Multiple instances of mposter (and/or msend) can use the same BufDir directory if the destination cells are the same. To successfully start the mposter or msend CLI commands in a persistent buffering mode, you must ensure that you have write access to the buffers file. Using persistent buffering causes mposter/msend to launch an mposter/msend server.
Write access for persistent buffering

To successfully start the mposter or msend CLI commands in a persistent buffering mode, you must ensure that you have write access to the buffers file. You can locate the buffers file at:
I I
UNIX/etc/itm/.reg/Buffers Microsoft WindowsHKEY_LOCAL_MACHINE/SOFTWARE/BMC

Software/BMCImpact/mposter/Buffers
The Microsoft Windows registry key for the Buffers file is not created by default; it is created the first time the mposter (or msend) command is executed using the -j option.
Appendix A
255
If the Buffers file is not writable, you will receive the error message shown in Figure 104 Error message if buffers files are not writable
Launching mposter server... OK Getting Server Port number... OK (33992) Connecting mposter server... Fatal error! Cannot negotiate connection with mposter server. Check if the cell(s) name, location, port and encryption key are the same as those running server (protocol error: 4) Fatal error! Client initialization failed. A current cause of this problem is a wrong/unavailable cell destination (hostname, port, encryption key).
Decreasing the buffer size

The persistent directory may contain the following files:
I I
persist.dat mposterbuf.lck
The purpose of the mposterbuf.lck file is to provide a file-locking mechanism when multiple mposter-like servers are started at the same time. To change the maximum size of persist.dat edit the $MCELL_HOME/etc/mclient.conf file and add or edit the line MessageBufferSize=. The default size is 2,000 events.
Using msend to send events when a cell is not installed

You can use msend as a standalone utility to send events, even if a cell is not installed on the server. To set up msend on a server where a cell is not installed, you must copy the following files from a server where a cell is installed to the server on which you want to send events:
I
msend.exe (Windows) or msend (UNIX) located in the MCELL_HOME\server\bin directory [Windows only] the redistributable MSVC runtime DLLs, MSVCR71.dll and MSVCP71.dll, which are located in the MCELL_HOME\server\libnative directory
mposter and msend return codes

Table 99 lists the return codes for mposter and msend. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213.
256
mqueryRetrieving objects from a cell
Table 99
Code 2 3 4
mposter and msend return codes

Description failed to initialize in Server mode failed to find a valid cell failed to close the client connection

The mquery command retrieves objects from a cell.
mquery syntax
Figure 105 shows the syntax for mquery. Figure 105 mquery syntax
mquery [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [ -i UserID[/Password][@Host[/Port]] ] [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-v] [-r] [-f Format] ( [-d] [-a Class] [-w Where] [-s SlotList | -x SlotList] [-g Collector] [-o OrderSlot] | -Q Query | - | {File} )
Table 100 lists the command-specific options for mquery. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 100 mquery options (part 1 of 2)
Option -a Class -d -f Format -g Collector -o OrderSlot Description performs queries as read from standard input stream select from a specified Class (default is either CORE_EVENT or CORE_DATA). select data objects instead of event objects format using: quoted, BAROC, CSV, or XML selects only in a collector (optional + suffix for closure) sorts on the specified slot order (OrderSlot). Set the sort order by appending a suffix to the OrderSlot value that you specify. Append a plus sign (+) for ascending sort or a minus sign (-) for a descending sort. -Q Query -r perform the specified query sets output to be raw output. For more information, see Raw output format on page 226.
Appendix A
257
Table 100 mquery options (part 2 of 2)

Option -s SlotList Description selects specific slots from the comma-separated SlotList; the default is ALL). Use special value COUNT to retrieve only the number of selected items. Use special value DELETE to delete the selected items. specifies a where condition on the specified Class excludes specific slots from the comma-separated SlotList (selecting ALL) performs queries as read from one or more specified files
-w Where -x SlotList File
mquery output
Output of the mquery command is available in raw format for parsing by a program, and in printed format for users, with several variations.
Raw output format

The output consists of the number of solutions, terminated with RS (Record Separator, ASCII code 30), and followed by the solutions. Each solution is terminated with RS. A solution consists of a sequence of slot values, separated by FS (Field Separator, ASCII code 28). There is no FS after the last slot value (that is followed by the RS solution terminator). Empty slot values, or nonexistent slots, are represented by an empty value, such as two FS with nothing in between. Figure 106 shows an example of a raw output specification. Figure 106 Example of raw output specification
RawOutput = SolutionCount RS Solution RS ... Solution RS Solution = SlotValue FS ... SlotValue

By default, solutions are printed in sequential order. For every solution, the values of the requested slots are printed, one per line. Empty or nonexistent slot values take an empty line. A slot value containing a new line will occupy more than one line. It is not possible to detect these values in standard format.
Verbose mode
In verbose mode, every solution is preceded by a line of the form as shown in Figure 107 on page 258. Figure 107 Verbose mode options
-----N/M-----
258
where
I I
N is the number of the solution (starting from 1) M is the total number of solutions.
The last solution is followed by a line of the form as shown in Figure 108. Figure 108 End of form
-----END-----
Special quoted format

In this variant of the standard format, slot values are quoted when necessary.
Special BAROC format

In this variant of the standard format, every solution is represented by a BAROC instance. This consists of the class name, terminated by a semicolon (;) as shown in Figure 109. Figure 109 Special BAROC format
slotname=slotvalue;
Values have quotes when needed. Nonexistent slots are not printed. The solution is terminated with an END on a line.
Special XML format

In this variant of the standard format, every solution is represented by an XML instance. Nonexistent slots are not printed.
Special CSV format

In the Comma Separated Value (CSV) variant of the standard format, solutions are printed in multiple columns over several rows. In non-verbose mode, each solution is printed on one row. Slot values are placed in columns in the same order as in the column selection. If ALL slots are requested, the order is determined by the cell and depends on the class definitions. In verbose mode, solutions can be on multiple rows. For an explicitly specified selection of columns, the first row contains those column names. If you request ALL slots, every solution row is preceded by a row containing the slot names. This is required, as the returned slots may vary depending on the class of the object.
Appendix A
259
Columns are separated with a comma (,). A value that contains a comma (,) or a quote ("), or a new line, is quoted with a quote ("). A quote (") within such a value is doubled.
Query specification
You can specify a query either with command line options or with the -Q option through standard input. Using -Q with standard input, you must specify the query in MRL syntax. You can use the options described in Table 101 to specify the query with CLI. Table 101 mquery query options
Option -d -a Class Description retrieves data instances instead of events selects instances of class Class or its subclasses If omitted, a default value of CORE_EVENT or CORE_DATA is assumed (depending on whether the -d option is specified) -w Where imposes one or more conditions on the instance slot values The Where value is a general MRL expression as used in a Where clause. Several subexpressions can be combined with a comma (,) or AND. Quotes may be needed to escape from shell interpretation. -s SlotList selects the slots listed in SlotList, a comma-separated sequence of slot names Special values are
I I I
ALLgets all slots COUNTgets no slots, only a count of matching objects is returned DELETEall matching objects are deleted, returning a count of these
The default is ALL. -x SlotList excludes the slots listed in SlotList, a comma-separated sequence of slot names All slots are reported except for these. -g Collector retrieves only matching object instances that belong to one of the collectors specified in Collector This is a comma-separated sequence of collector object identifiers (OIDs), names, or both. Each one can be suffixed optionally with a + to include its subcollectors as well. -o OrderSlot sorts the slots mentioned in OrderSlot This is a comma-separated sequence of slot names. Each one can be suffixed optionally with a + to indicate ascending order or a - to indicate descending order. Without suffix, a + is assumed. Ordering is done first on the first slot, then on the next one, and so on.
260
mquery examples
This section contains examples of the mquery command.
Selecting events with a severity level

Use the command shown in Figure 110 to select all MC_CELL_CONTROL events with severity of at least MINOR, and non-closed status. This query returns the indicated slots and the effective class name. Figure 110 Example of mquerySelect events with severity status
mquery -a MC_CELL_CONTROL -w "severity: >= MINOR AND status: != CLOSED" -s "mc_ueid,CLASS,severity,msg"
The command shown in Figure 111 on page 261 selects all events from the ByHost collectors for hosts host1 and host2 including all of their subcollectors, if any. The result is ordered on status in ascending order beginning with OPEN, and for each equal status value, descending on severity beginning with DOWN. Figure 111 Example of mquerySelect events from collector
mquery -g "'By Host'.host1+,'By Host'.host2+" -s "mc_ueid,CLASS,severity,hostname,msg" -o "status,severity-"
NOTE
The current implementation of the mquery command has the following limitations:
I
The XML format is experimental and may change in future BMC Impact Solutions product releases. The list slot values in XML are printed as strings, not as XML lists.
Deleting events using the mquery command

You can use the value DELETE with the -s option to delete events, as shown in shown in Figure 112. Figure 112 Deleting events using mquery
mquery -n cellName -s DELETE -w "event_handle: == 123"
This command removes the event with handle 123.
Appendix A
261
mrecoverRecovering from a catastrophic data loss
mquery return codes

Table 102 lists the command-specific return codes for mquery. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 102 mquery return codes
Code 21 Description syntax error in input

Use the mrecover command to recover the state of a cell after a catastrophic loss of data. Typically, a catastrophic data loss is caused by a system failure. You use the mrecover command locally on the computer hosting the cell from which the data was lost. The process recovers the data from other cells that received events from the local cell and that sent events to the local cell. The command cannot recover unpropagated events sent directly from adapters.
NOTE
The mrecover command recovers only propagated events.
The mrecover command contacts each of the cells that you list in the TargetCell option and requests that each target cell produce an up-to-date saved state. The events that were propagated from the local cell are extracted from each target cell and stored locally. After all of the target cells have been prompted and the propagated events are retrieved, they are merged into a new saved state for the local cell. Then, the saved state is processed by the local cell during a recovery process. If the local cell is running or contains an mcdb file, the recovery process aborts. If the recovery process cannot connect to a target cell, you are prompted to choose to stop or continue the recovery process. If you choose to continue, you are prompted to choose to include events collected from the previous session. After the recovery process completes, the saved state is used to restart the recovered cell.
NOTE
If the data loss includes the BMC Impact Solutions product executables or the Knowledge Base definition of the cell, you must reinstall the cell software, the Knowledge Base, and a dedicated recovery Knowledge Base (if applicable) before using the mrecover command.
262
mrecover syntax
Figure 113 shows the syntax for mrecover. Figure 113 mrecover syntax
mrecover [-c ConfigFile] [-q] [-h|-?] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]]{-p Var=Value} [-z] {TargetCell} . . .
Table 103 lists the command-specific option for mrecover. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 103 mrecover option
Option TargetCell Description specifies the name of the cell that propagated events or to which events have been propagated
mrecover example
To fix a broken cell with input from cella, cellb, and cellc, type the command shown in Figure 114. Figure 114 Fixing a broken cell using mrecover
mrecover -n broken_cell cella cellb cellc
mrecover return codes

Table 104 lists the command-specific return codes for mrecover. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 104 mrecover return codes
Code 2 3 5 6 7 Description failed to send the command that started the StateBuilder on a remote cell could not obtain information from one or more neighbor cells could not launch an external program (mrmerge or mcell) mrmerge exited abnormally mcell (in recovery mode) exited abnormally
Appendix A
263
mrextractExtracting cell state files to create new state files
mrextractExtracting cell state files to create new state files

Events are extracted from the remote cell repository for the local cell being recovered. The mrextract command is one step in the recovery process. For more information, see mrecoverRecovering from a catastrophic data loss on page 262.
WARNING
This command is used by mrecover and should be avoided by end users.
The cell must be stopped before using the mrextract command.
mrextract syntax
Figure 115 shows the syntax for mrextract. Figure 115 mrextract syntax
mrextract [-c ConfigFile] [-h|-?] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]] [-o OutputFile] {-p Var=Value} [-q] [-s InputStateFile] [-z] {TargetCell} . . .
Table 105 lists the command-specific options for mrextract. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 105 mrextract options
Option -o OutputFile -s InputStateFile TargetCell Description sends output to the specified OutputFile file; the default is to send output to standard output specifies to use input from InputStateFile; the default is the cells mcdb specifies the name of the cell to which events have been propagated; separate multiple cell names with a space
mrextract example
Figure 116 shows an example of mrextract. Figure 116 Example of mrextract
mrextract -n CellTwo -o \tmp\mcdb.CellOne
264
mrmergeMerging event objects
mrextract return codes

Table 106 lists the command-specific return codes for mrextract. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 106 mrextract return codes
Code 37 47 67 97 Description failed to enable tracing cannot access state builder failure loading kb classes cannot start while state builder is active

The mrmerge command is one step in the cell recovery process. This command merges events recovered from other cells into a new saved state for the local cell being recovered. For more information, see mrecoverRecovering from a catastrophic data loss on page 262.
WARNING
This command is used by mrecover and should be avoided by end users.
mrmerge syntax
Figure 117 shows the syntax for mrmerge. Figure 117 mrmerge syntax
mrmerge [-h|-?] [-c ConfigFile] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]] {-p Var=Value} [-o OutputFile] {InputFile} [-q] [-z]
Appendix A
265
Table 107 lists the command-specific options for mrmerge. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 107 mrmerge options
Option -o OutputFile Description specifies the file (OutputFile) to which to send command output; the default output target is terminal; the path name of the recovery cells database file (mcdb) to be created by this command specifies the input file for the mrextract command
InputFile
mrmerge example
Figure 118 shows an example of mrmerge. Figure 118 Example of mrmerge
mrmerge -n Cellone -o $MCELL_HOME\log\Cellone\mcdb\tmp\mcdb.X1 \tmp\mcdb.X2
mrmerge return codes

Table 108 lists the command-specific return codes for mrmerge. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 108 mrmerge return codes
Code 37 47 67 97 Description failed to enable tracing cannot access StateBuilder failure loading kb classes cannot start while StateBuilder is active
266
msetmsgModifying an event
msetmsgModifying an event
Use the msetmsg command to modify the status value of an event in a specified cell. Use the -s option to modify the slot value.
msetmsg syntax
Figure 119 shows the syntax for msetmsg. Figure 119 msetmsg syntax
msetmsg [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [ -i UserID[/Password][@Host[/Port]] ] -u EventId -C -O -B -A -G -S "Slot=Value[{;Slot=Value}]"
Table 109 lists the command-specific options for msetmsg. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 109 msetmsg options
Option -u EventId -C -O -A -G -B Description specifies the event handle of the event to be modified sets the status value of the specified event to CLOSED sets the status value of the specified event to OPEN sets the status value of the specified event to ACK sets the status value of the specified event to ASSIGNED sets the status value of the specified event to BLACKOUT
-S "Slot=Value[{;Slot=Value}]" specified the slot to be modified and the changes to be made to the slots value
msetmsg example
To close an event whose event ID (event_handle) is 12981, type the following command:
msetmsg -n cellName -u 12981 -C
If this command is successful, it does not produce output.
Appendix A
267
msetrecSetting the value of a global record
msetmsg return codes

Table 110 lists the command-specific return codes for msetmsg. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 110
Code 31 32
msetmsg return codes

Description no event handle specified failed to set message
msetrecSetting the value of a global record

Use the msetrec command to set the field values in a global record. Global records are +defined in the records directory of a Knowledge Base. The cell uses global records as global variables in rules.
msetrec syntax
Figure 120 shows the syntax for msetrec. Figure 120 msetrec syntax
msetrec [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] -r Record -S Slot -V Value [-i UserID[/Password][@Host[/Port]]]
Table 111 lists the command-specific options for msetrec. For a list of common command options that apply to all CLI commands, see BMC Impact Manager CLI common command options on page 211. Table 111
Option -b -r Record -S Slot -V Value
msetrec options
Description specifies slot value assignment specifies the global record containing the Slot to be modified specifies the Slot to be modified specifies the Value to set for the specified Slot
268
BMC Impact Manager CLI configuration
msetrec example
Figure 121 shows an example of msetrec. Figure 121 Example of msetrec
msetrec -n <cellName> -r test_rec -S slot_list_int -V [4,5,6]
msetrec return codes

Table 112 lists the command-specific return codes for msetrec. For a list of common return codes that apply to all CLI commands, see BMC Impact Manager CLI common return codes on page 213. Table 112
Code 31
msetrec return codes

Description failed to set record slot

The mclient.conf file contains the default client options for configuring CLIs. Most of the cell configuration options also can be specified for CLIs. For a more information, see Cell configuration parameters on page 274. The configuration options use the following syntax: option=value, where value equals one of the following:
I I I I
Boolean: Yes | On | No | Off Number String Path
Appendix A
269
Table 113 describes the CLI configuration parameters. Table 113

Option AuthenticationServerAddress
BMC Impact Manager CLI configuration parameters (part 1 of 3)

Description Default value
If no value specifies the host name or IP address of an authentication server, optionally followed by a port is entered, the default number, using the following syntax: IAS port number on Host[/Port] the local host is used. specifies the name of the cell; an alternative for the Host -n cellName option the host name or IP address of the cell specifies the name of the cell directory file Host mcell.dir
ServerName ServerLocation ServerDirectoryName ServerPort
specifies the TCP/IP port number where the cell 1828 listens for all in-bound requests from sources, such as the BMC Impact Explorer, CLIs, and adapters enables or disables encryption to and from the cell Yes used by encryption process as part of the encoding no default key the maximum time, in seconds, that a CLI command attempts to establish a connection to a cell If the connection with the cell cannot be completely established within this timeframe, the command aborts. Note: If the cell is busy with a database cleanup, it may be impossible to connect the CLI with the default values. A database cleanup has a duration limit defined by the EventDBCleanupDurationLimit option, with a default value of 30 seconds. With a default ConnectionSetupTimeOut of 10 seconds, the connection cannot be established within the first 20 seconds of a cleanup. 10 (seconds)
Encryption EncryptionKey ConnectionSetupTimeOut
270
Table 113
Option

Description specifies the range of ports to use for outgoing connections It is the port used on the client side. This is useful only to pass the event through firewalls with high restrictions. Most firewall configurations ignore source port information but require destination port information. However, firewall configuration usually can restrict the source ports as well. The syntax is PortRange = PortSequence {, PortSequence} PortSequence = Port [- Port] Warning: On Windows platforms, when using ConnectionPortRange for a CLI running on the same machine as the cell, it is possible that the CLI will not be able to connect. This can occur when the CLI needs more than one attempt to connect (for instance, because the cell was too busy during the first attempt). Subsequent connection attempts will fail due to limitations of the OS. Default value empty
ConnectionPortRange
ConnectionPortReuse
indicates whether or not the ports specified in ConnectionPortRange should be reused as much as possible By default the cell tries to reuse ports from the specified range, in the given order. When ConnectionPortReuse=No, for every new connection within the same session, the next free port from the specified range is used. Only when it reaches the end of the range will it restart at the beginning of the range.
Yes
MessageBufferSize
the number of messages, or events, retained in the buffer when the cell is unable to send, or when waiting for an answer; a message that is not sent because the destination is down, for example, or a message that was sent but not yet answered, remains in the buffer the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed The amount of time, in seconds, that messages are retained in the buffer until they can be sent. Once the specified time elapses, the retained messages are removed from the buffer. Appendix A
2000
MessageBufferCleanupPercentage MessageBufferReconnectInterval
10 600
MessageBufferKeepWait
3600
271
Configuring tracing for BMC Impact Manager CLI commands
Table 113
Option

Description the time, in seconds, to keep sent messages buffered while waiting for an answer the number of times to resend unanswered messages Default value 300 1
MessageBufferKeepSent MessageBufferResendCount
Configuring tracing for BMC Impact Manager CLI commands

You configure CLI command tracing in the MCELL_HOME\etc\mclient.trace file. The mclient.trace file uses the same parameters as the mcell.trace configuration file. For details on the cell tracing configuration, see Configuring cell tracing on page 50.
BMC Impact Manager CLI trace configuration

Tracing of CLIs is configured in the MCELL_HOME\etc\mclient.trace file. To send tracing output to a text file, add the line of code shown in Figure 122 to the
mclient.trace file.
Figure 122 command to send tracing output to text file

ALL ALL out.txt
This line produces tracing to the MCELL_HOME\tmp\mclient\out.txt file.
272
Appendix
B
274 274 276 278 280 281 283 284 287 287 288 291 292 292 293
mcell.conf file parameters

This appendix discusses all of the parameters in the mcell.conf file and contains the following topics: Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B
273
Action result event parameters

Table 114
Parameter ActionResultInlineLimit

Description Type Default value the size limit, in bytes, for an action result to be number 4096 (4 KB) included directly in the action result event slots This applies to both the output stream (slot "output_val") and the error stream (slot "error_val"). If the respective result is larger than the indicated size, it is stored in a file. Instead of placing the value directly in the *_val slot, the reference to the file is placed in the corresponding *_ref slot.
ActionResultKeepPeriod
the period, in seconds, that an action result is kept on behalf of a (Browser) client The client should retrieve the result within that period. After the period has expired, the result is dropped. This is independent of the action result event. A generated action result event is not influenced by this parameter. It exists as long as other events.
number 120 (2 minutes)
Cell configuration parameters

Table 115
Parameter CellDescription CellOperationLevel
Cell configuration parameters (part 1 of 3)

Description used as the initial value of the cell_description slot of the internal MC_CELL_INFO record indicates the level on which the cell must operate The operation level determines from which clients the cell accepts connections and events. The default value can accept connections from any computer. Type string string Default value BMC Impact Manager Consolidation
CellOperationRelax
indicates whether the operation level should be lowered in case there is no license available for the desired level, as set by CellOperationLevel Typically, more license tokens are available for lower operation levels.
Boolean
No
274
Cell configuration parameters
Table 115
Parameter

Description specifies the range of ports to use for outgoing connections For forward propagation, this port is used on the client side (or on the propagating cell side). This is useful to pass the event through firewalls with high restrictions. Most firewall configurations ignore source port information but require destination port information. However, firewall configuration usually can restrict the source ports as well. Type string Default value empty
ConnectionPortRangea
ConnectionPortReusea indicates whether or not the ports specified in ConnectionPortRange should be reused as much as possible By default, the cell or command line interface (CLI) tries to reuse ports from the specified range, in the given order. When ConnectionPortReuse=No, for every new connection within the same session, the next free port from the specified range is used. Only when it reaches the end of the range will it restart at the beginning of the range. ProcessingLimit Percentage specifies limitation of event processing speed At 100% the cell accepts events as fast as it can. At x% it does not accept events during (100-x)% of the time. This limits the cells CPU utilization. ServerAllInterfaces determines whether the cell listens on one specific interface or on all available interfaces When ServerAllInterfaces=Yes, the cell communicates on all network interfaces on the host. When ServerAllInterfaces=No, the cell only communicates with the network interface that has the IP address specified in the mcell.dir file of that cell. ServerDirectoryNamea specifies the name of the cell directory file ServerPorta
Boolean
Yes
number
100
Boolean
Yes
path
mcell.dir 1828
specifies the TCP/IP port number at which the cell number listens for all in-bound requests from sources, such as the BMC Impact Explorer console, CLIs, and adapters
Appendix B
275
Cell failover configuration parameters
Table 115
Parameter

Description Type Default value Yes specifies whether the cell is an Event Management cell Boolean or a Service Impact Model cell. If ServiceModelEnabled=No, the cell operates as an Event Management cell. If ServiceModelEnabled=Yes, the cell operates as a Service Impact Model cell, if the SIM class definitions are loaded. If these class definitions are not available, the cell operates as an Event Management cell. Note: Do not try to configure a SIM cell unless you have the proper license.
ServiceModelEnabled
SystemLogDirName SystemTmpDirName
a
specifies the path to the default system-defined log directory specifies the path to the default system-defined tmp directory
path path
%H/log %H/tmp
Can also be used in the mclient.conf configuration file, which affects the behavior of all of the BMC Impact Solutions CLI commands. These parameters retain the same qualities and definitions in the mclient.conf file as they have in the mcell.conf file.

Table 116
Parameter CellDuplicateAutoFailOver
Cell failover configuration parameters (part 1 of 2)

Description determines whether the primary server automatically fails over to the secondary server. For automatic failover to occur, this parameter must be set to YES on both servers. Type Boolean Default value Yes
CellDuplicateAutoSwitchBack
determines whether the secondary server automatically switches back to the primary server when the primary server restarts after failover. For automatic switchback to occur, this parameter must be set to YES on both the primary and secondary servers.
Boolean
Yes
276
Table 116
Parameter
Cell failover configuration parameters (part 2 of 2)

Description specifies the length of time (in seconds) that the secondary server waits to become active after it is started. When the secondary server starts, it expects the primary to connect to it. If the primary server does not connect to the secondary within the time specified by the CellDuplicateFailOverStartTimeOut parameter, the secondary server will become active. The time specified for CellDuplicate FailOverStartTimeOut should be longer than the time specified for CellDuplicateFailOverTimeOut to allow operators to start up primary and secondary servers at almost the same time, in any order. Type number Default value 120
CellDuplicateFailOverStart TimeOut
CellDuplicateFailOverTimeOut
specifies the length of time (in seconds) that the secondary server waits to become active after the secondary server loses connection to the primary server.
number
40
CellDuplicateHeartbeatEnabled
Boolean can be used to disable the heartbeat of a high availability cell, to prevent the secondary cell server from becoming active when the primary cell server is active due to VMware clock discrepancies specifies the operation mode of the server. 1 = primary server 2 = secondary server 0 = the server is operating as a non-high availability cell. This is the only parameter that needs a different value between primary and secondary. number
Yes
CellDuplicateMode
Appendix B
277
Client communication parameters

Table 117
Parameter ClientCleanupInterval

Description the interval, in seconds, between clean-ups of pending clients After each such period, clients that did not give the cell a notice of life are disconnected. Type number Default value 300
ClientPollTimeOut
the maximum time, in milliseconds, the cell waits for a client request before it continues processing the time interval, in milliseconds, that the cell has to send a packet to a client on the lowest communication level the format used to display timestamps in the date slot A default value of CIM indicates use of the Common Information Model (CIM) format from the Desktop Management Force Group. DateFormat parameters use the syntax of %[letter]. Table 118 on page 279 lists the DateFormat parameters for Solaris; for other operating systems, see their documentation.
number
200 milliseconds
ClientSendTimeOut
number
1000 milliseconds
DateFormat
string
CIM
SynchronizeTimeOut
the maximum time, in milliseconds, the cell waits for synchronization before dropping a connection
number
5000 milliseconds
If the cell receives an event with an empty value for the date slot, it sets the date slot to the textually formatted value of the date_reception slot. That value is determined by the DateFormat parameter. This assignment is performed only once, when the event first enters the cell. If the cell is shut down and restarted, the value of date remains the same even if the DateFormat parameter has been modified in the interval. The CIM format is yyyymmddhhmmss.mmmmmmsutc, where:
yyyy = year mm = month dd = day hh = hour, based on 24-hour clock mm = minutes ss = seconds mmmmmm = microseconds s = + or -
278
utc = offset in minutes from UTC; UTC is the Universal Time Coordinate system
Table 118 lists the parameters from the Solaris platform. Other platforms, including UNIX and Microsoft Windows platforms, may have slight differences. Table 118
Parameter %% %a %A %b %B %c %C %d %D %e %h %H %I %j %k %l %m %M %n %p %r %R %S %t %T %u %U %V
Date and time format parameters for Solaris (part 1 of 2)

Description same as % locales abbreviated weekday name locales full weekday name locales abbreviated month name locales full month name locales appropriate date and time representation locales date and time representation as produced by date (1) day of month [1,31]; single digits are preceded by zero (0) date as %m/%d/%y day of month [1,31]; single digits are preceded by a space locales abbreviated month name hour (24-hour clock) [0,23]; single digits are preceded by zero (0) hour (12-hour clock) [1,12]; single digits are preceded by zero (0) day number of year [1,366]; single digits are preceded by zero (0) hour (24-hour clock) [0,23]; single digits are preceded by a blank hour (12-hour clock) [1,12]; single digits are preceded by a blank month number [1,12]; single digits are preceded by zero (0) minute [00,59]; initial 0 is permitted but not required insert a new line locales equivalent of A.M. or P.M. appropriate time representation in 12-hour clock format with %p time as %H:%M seconds [00,61] insert a tab time as %H:%M:%S weekday as a decimal number [1,7], where 1 represents Sunday week number of year as a decimal number [00,53], where Sunday is the first day of week 1 week number of the year as a decimal number [01,53], where Monday is the first day of the week If the week containing January 1st has four or more days in the new year, then it is considered week 1. Otherwise, it is week 53 of the previous year, and the next week is considered week 1.
%w %W %x
weekday as a decimal number [0,6], where 0 represents Sunday week number of year as a decimal number [00,53], where Monday is the first day of week 1 locales appropriate date representation
Appendix B
279
Encryption parameters
Table 118
Parameter %X %y %Y %Z
Date and time format parameters for Solaris (part 2 of 2)

Description locales appropriate time representation year within century [00,99] year, including the century. (for example, 2006) time zone name or abbreviation, or no bytes if no time zone information exists
Table 119 lists the encryption parameters. Table 119
Parameter AllowAdapterFrom
Description Type Default value 0./0 specifies the adapters within the range of IP addresses string These are adapters that use the BMC Impact Solutions communications protocol.
AllowBrowserFrom
specifies the BMC Impact Explorer and the BMC Impact Portal connections within the range of IP addresses specifies the cells within the range of IP addresses specifies the command line interfaces (for example, mkill or mcstat) within the range of IP addresses
string
0./0
AllowCellFrom AllowCLIFrom AllowConnectionFrom AllowEIFFrom Encryption EncryptionKey ForceEncryption
string string
0./0 0./0 0./0 0./0
specifies the client within the range of IP addresses that string is allowed to connect to a cell specifies the EIF event sources (for example, a postemsg) within the range of IP addresses specifies to use encryption specifies the encryption key specifies if encryption is to be forced string
Boolean Yes string (empty) Boolean No
280
Event repository cleanup parameters

Table 120 Event Repository cleanup parameters (part 1 of 3)
Parameter EventAutoClose Description Type Default value Yes automatically closes a duplicate event Boolean in the database when an event arrives with status=CLOSED, or it is closed in the Refine rule phase If the default value is left as Yes, the event is dropped and the duplicate is closed. If the value is set to No, there is no duplicate detection and the CLOSED event is not dropped. EventDBCleanupDurationLimit the maximum duration, in seconds, of a number single cleanup After expiration of that period, the cleanup is interrupted. Normal operation proceeds for an equal duration. Then cleanup is resumed, with the same limit again. EventDBCleanupInterval the time interval, in seconds, between periodic cleanups of the repository number 3600, or 1 hour minimum = 60; no maximum 10 minimum=5; no maximum 30
EventDBCleanupPercentage
the percentage of free space required at number termination of an EventDB cleanup With a default EventDBSize of 100000, this means that at least 10000 places must be available at termination of a completed cleanup.
EventDBCleanupOnDateReception indicates the preference for deleting events from the repository based on when they were received instead of when they were last modified
Boolean
No
Appendix B
281

Parameter EventDBCleanupPreferClosed Description Type Default value No indicates the preference for cleaning up Boolean closed events rather than older events When there is not enough free space after removing all expired events, additional, unexpired events are removed. These are selected, oldest first, either from any events or from the closed ones first. The default is no, meaning that the event status value is not taken into account when selecting events for removal. EventDBKeepClosed the minimum age, in seconds, of CLOSED events before they are removed from the repository Note: Any modifications to the EventDBKeepClosed parameter should be carefully considered. Events of these classes remain in the event repository until you manually delete them. EventDBKeepNonClosed the minimum age, in seconds, of nonclosed events before they are removed from the repository number 2592000, or 30 days minimum value=0; maximum value = 4294967295, or 136 years number 604800, or 7 days; no minimum; no maximum
282
Event cleanup process

Parameter EventDBSize Description the number of events to retain in the repository (the mcdb and xact files located in the MCELL_HOME/log/cellName directory path The default size is 100000. When the specified number is reached, the StateBuilder (STATBLD) process runs a cleanup procedure, which is described in Event cleanup process on page 283. The value of the EventDBSize may have an impact on memory consumption. When increasing the value of the EventDBSize, consider the size of your systems virtual memory and the number of programs running on the system. Contact your system administrator if in doubt. EventDBNoCleanupClosed EventDBNoCleanupNonClosed list of classes in which closed events will not be deleted from the repository list of classes in which non-closed events will not be deleted from the repository; comma separated string Boolean empty SMC_STATE_ CHANGE Type number Default value 100000 minimum value=100; no maximum
Event cleanup process

The related group of event cleanup parameters gives you control over which events are removed, limits the duration of the cleanup, and specifies a preference for cleaning up closed events rather than older events. A cleanup first removes expired events. Expired events are those that are older than the times in the EventDBKeepClosed and EventDBKeepNonClosed parameters, for closed and non-closed events, respectively. After this cleanup, if there is still less free space than specified in the EventDBCleanupPercentage parameter, additional, unexpired events are removed. As many events are removed as needed to reach the desired amount of free space. Older events are removed first, with one possible exception. If parameter
EventDBCleanupPreferClosed=Yes, closed events are removed first, even if some older unclosed events remain. In EventDBCleanupPreferClosed=No mode, all
events are considered, starting with the oldest first.
Appendix B
283
Heartbeat parameters
The mc_date_modification slot is considered to determine the time of an event. However, if parameter EventDBCleanupOnDateReception=Yes, the date_reception slot is considered instead. Cleanup is interrupted if it takes longer than the value of the
EventDBCleanupDurationLimit parameter. By default, this value is 30 seconds. If
the cleanup period was not long enough to remove all expired events, a new cleanup is scheduled for a later time with the same amount of time as the duration limit. If all expired events were removed, the next cleanup is scheduled after the normal interval value of EventDBCleanupInterval.
Table 121 Heartbeat parameters
Parameter HeartbeatEnabled HeartbeatInterval Description indicates whether the heartbeat monitoring mechanism is enabled or not the default interval between two beats, if not specified in the data object Type Boolean number number Default value Yes 60 3
HeartbeatMissedCritical the default number of consecutive missed beats that are needed to generate a critical event, if not specified in the data object HeartbeatMissedMinor the default number of consecutive missed beats that are needed to generate a minor event, if not specified in the data object
number
HeartbeatMissedWarning
the default number of consecutive missed beats number that are needed to generate a warning event, if not specified in the data object
The heartbeat feature allows a specific cell, called the monitoring cell, to monitor one or more cells, called the monitored cell or cells, for enabled access by the monitoring cell. The parameter in the mcell.conf file of the monitored cell should be HeartbeatEnabled=Yes. By default, the monitored cell sends a beat every 300 seconds. Heartbeats are configured through MC_CELL_HEARTBEAT dynamic data objects in the monitoring cell. An MC_CELL_HEARTBEAT dynamic data object contains information, such as the name of the cell to be monitored, the length of the expected time intervals between the heartbeats, and the number of heartbeats that must be missed to generate corresponding internal events in the monitoring cell.
284
The cell receives the dynamic data object either by loading it from the data directory, receiving it through an mposter call, or viewing it in the Administrative View of the BMC Impact Explorer. The monitoring cell sends a request to the monitored cell. The monitored cell sends a heartbeat back to the monitoring cell at the specified intervals. If the monitoring cell does not receive a heartbeat in the expected timeframe, the monitoring cell generates an alert that can be viewed in the BMC Impact Explorer console. The default settings for missing heartbeats are as follows:
I I I
1 missed heartbeat generate a warning event 2 missed heartbeats generate a minor event 3 missed heartbeats generate a critical event
For example, in Figure 123 on page 285, cell 1 is the monitoring cell, which sends a request to cell 2, the monitored cell. If it does not receive a response at a specified interval, then the monitoring cell sends an alert that can be seen in the BMC Impact Explorer. Figure 123 Example of Heartbeat Request
cell 1 cell 2
Heartbeat
After a monitoring cell terminates and restarts, it is aware of prior requests for heartbeats because it rereads the dynamic data objects that are stored in the cell repository mcdb. After it rereads the data, the monitoring cell attempts to resend the request to the monitored cell.
Appendix B
285
If the monitored cell terminates, the monitoring cell resends the request for heartbeats at the specified intervals. Table 122 lists the MC_CELL_HEARTBEAT slots. Table 122 Heartbeat slots
Slot cell enable last_time interval Description target monitored cell name 0 = disabled, 1 = enabled time last heartbeat was received length of interval between heartbeats Specify zero (0) to use the default, as determined by the HeartbeatInterval configuration parameter. missed_warning number of missed heartbeats before a WARNING event is generated Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedWarning configuration parameter. Specify -1 to disable generation of the corresponding event. missed_minor number of missed heartbeats before a MINOR event is generated Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedMinor configuration parameter. Specify -1 to disable generation of the corresponding event. missed_critical number of missed heartbeats before a CRITICAL event is generated Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedCritical configuration parameter. Specify -1 to disable generation of the corresponding event. missed number of consecutive missed heartbeats
NOTE
Deleting an instance of an MC_CELL_HEARTBEAT data object from a monitoring cell terminates the monitoring of the corresponding cell or cells.
286
Internal cell monitor parameters
Internal cell monitor parameters

Table 123 Internal cell monitors parameters
Parameter CellEventEnable Description a flag that indicates whether the cell should generate internal events, such as start, stop, and heartbeat; does not include events generated by the rules indicates whether an event processing error should produce a special internal event to flag that error, or not Type Boolean Default value Yes
CellErrorEvents
Boolean Boolean number
Yes Yes 600
CellMetricsEnabled determines whether metrics for cell performance are collected or not CellTickInterval the time interval, in seconds, between generation of cell heartbeat events (ticks) The purpose of such heartbeats is to send a sign of life from the cell. A zero (0) value disables cell ticks without disabling other internal events. This parameter operates only if the CellEventEnable is set to Yes. RuleLoopDetect
a flag that requires the cell to check for certain conditions Boolean that can induce infinite looping of events Setting this parameter to Yes can cause mild cell performance degradation.
No
KB parameters
Table 124 KB parameters
Parameter KBDirName Description the path to the active KB directory Type path Default value the KB directory in the cells cell-specific configuration directory kbrecovery
KBRecoveryDirName
the path to an alternate KB directory to be used path for recovery from catastrophic damage For more information, see mrecover Recovering from a catastrophic data loss on page 262.
Appendix B
287
Propagation parameters
The propagation parameters allow you to configure propagation and destination buffers. You can configure these parameters for individual destinations and also configure a default value for all other destinations. Use the asterisk (*) to specify all destinations. The following parameter definition illustrates how to configure these parameters for all destinations.
DestinationBufferReconnectInterval = *=600
This example specifies that the interval to try to reconnect is 600 seconds for all destinations. If the * is not explicitly defined, the default value for the parameter will be applied to all destinations. To configure parameters for individual destinations, the value for these parameters is formatted as a comma-separated sequence of destination-specific settings in the form of DestinationName=Value. DestinationNames #1 and #2 are reserved to indicate the primary and secondary nodes of a high availability cell. For example,
DestinationBufferReconnectInterval = #1=10,#2=10,*=600,SlowCell=1200
This example specifies that the interval to try to reconnect is 10 seconds for the high availability nodes, 1200 seconds for a cell called SlowCell and 600 seconds for all other destinations. If the * is not explicitly defined, the default value for the parameter will be applied to all unspecified destinations. Table 125 Propagation parameters (part 1 of 3)
Parameter DestinationBufferBaseSize Description the initial number of messages, or events, retained in the buffer Type Default value
number 5000
DestinationBufferExpandPercentage percentage of the actual buffer size that number 10 the buffer expands when events continue to be propagated after the buffer is full
288
Table 125 Propagation parameters (part 2 of 3)

Parameter DestinationBufferSizeLimit Description maximum allowed buffer size The default value of 0 means the buffer size is unlimited. In practice, the size is limited to 2^32-1, or to the available amount of memory. If the limit is set to a value lower than DestinationBufferBaseSize, the buffer will not expand beyond DestinationBufferBaseSize. DestinationBufferReducePercentage minimum percentage of free buffer size number 50 required to perform a reduction DestinationBufferKeepSenta DestinationBufferKeepWait the time, in seconds, to keep sent events number 300 buffered while waiting for an answer The amount of time, in seconds, that events are retained in the buffer until they can be sent. Once the specified time elapses, the retained events are removed from the buffer. DestinationBufferReconnectInterval the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed The cell continues to reestablish a connection as long as there are events in the buffer. DestinationBufferResendCount PropagateBufferBaseSize the number of times to resend unanswered events number 1 number 600 number 3600, or 1 hour Type Default value
number 0
the number of requests for propagation number 20000 to retain in the propagation buffer Such a request corresponds to firing a Propagate rule. There is one propagate buffer per cell with as many places for requests as set by the parameter.
PropagateBufferExpandPercentage
percentage of the actual buffer size that number 10 the buffer expands when events continue to be propagated after the buffer is full
Appendix B
289
Deprecated MessageBuffer propagation parameters
Table 125 Propagation parameters (part 3 of 3)

Parameter PropagateBufferSizeLimit Description maximum allowed buffer size The default value of 0 means the buffer size is unlimited. In practice, the size is limited to 2^32-1, or to the available amount of memory. If the limit is set to a value lower than PropagateBufferBaseSize, the buffer will not expand beyond PropagateBufferBaseSize. PropagateBufferReducePercentage PropagateConfigFileName
a
Type
Default value
number 0
minimum percentage of free buffer size number 50 required to perform a reduction the name of the propagation configuration file path mcell. propagate
Deprecated MessageBuffer propagation parameters

The MessageBuffer propagation parameters described in this section have been deprecated, but are retained for backward compatibility with earlier versions of BMC Impact Manager. These parameters may be removed in a later version of the product. If one of the DestinationBuffer parameters is not specified, or if it does not contain a default setting, the value of the corresponding MessageBuffer parameter is used as default. If the corresponding MessageBuffer parameter is not specified, an internal default value is used. Table 126 Deprecated MessageBuffer propagation parameters (part 1 of 2)
Parameter MessageBufferBaseSize MessageBufferKeepSenta
MessageBufferKeepWait
Description the initial number of messages, or events, retained in the buffer the time, in seconds, to keep sent messages buffered while waiting for an answer
Type
Default value
number 5000 number 300
The amount of time, in seconds, that messages number 3600, or 1 hour are retained in the buffer until they can be sent. Once the specified time elapses, the retained messages are removed from the buffer.
290
Reporting client connection parameters
Table 126 Deprecated MessageBuffer propagation parameters (part 2 of 2)

Parameter
MessageBufferReconnectInterval
Description the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed The cell continues to reestablish a connection as long as there are messages in the buffer.
Type
Default value
number 600
MessageBufferResendCount MessageBufferSize
the number of times to resend unanswered messages
number 1
the number of messages, or events, retained in number 20000 the buffer when the cell is unable to send, or when waiting for an answer; a message that is not sent because the destination is down, for example, or a message that was sent but not yet answered, remains in the buffer A cell maintains one buffer for each destination. Such buffers have the same size, as set by the parameter.
PropagateBufferSize
the number of requests for propagation to retain in the propagation buffer Such a request corresponds to firing a Propagate rule. There is one propagate buffer per cell with as many places for requests as set by the parameter.
number 20000
Reporting client connection parameters

Table 127 lists the parameters that report on client operations on the cell. Table 127 Reporting client connection parameters
Parameter Description Type Default value browser, Console, ImpactExplorer, mcontrol, mkill, mposter, msetmsg, msetrec mposter, msetmsg, msetrec ReportConnectClients reports connect and disconnect of string clients
ReportModifyClients
reports modifications of events by string clients
Appendix B
291
Service model parameters

Table 128 lists the parameters that control the service model. Table 128
Parameter ServiceModelPublish

Description controls whether or not Service Model Data is published Note: If ServiceModelPublish is disabled, the ServiceModelDirectFeed parameter has no impact. In this case, Service Model Data is always accepted through direct feed. Type Boolean Default value YES
ServiceModelDirectFeed
Boolean when ServiceModelPublish is enabled, ServiceModelDirectFeed controls whether or not Service Model Data is accepted through direct feed
YES
State Builder parameters

The running of the State Builder is controlled by the cell, using the parameters in the mcell.conf file. Table 129 lists the StateBuilder parameters. Table 129 State Builder parameters
Parameter StateBuildInterval StateBuildSize Description the time interval, in seconds, between two builds of saved states of the cell Type number Default value 3600 1000
the maximum size, in kilobytes, of a transaction number file before it is transformed into a new saved state when the StateBuilder runs again. If BMC Impact Manager seems to be consuming too much CPU, verify that State Builder is not running too frequently. Compare the time stamps of the mcdb.* files in the log directory of the cell. If the time between two state builds is less than 10 minutes, increase the StateBuildSize parameter.
StateBuildConfigFileName the StateBuilder configuration file name StateBuildAtTerminate StateBuildRunTimeOut
path
statbld.conf No 600 seconds
indication to run the StateBuilder when the cell Boolean terminates the timeout, in seconds, to consider when waiting for the StateBuilder to terminate number
292
Trace parameters
Trace parameters
Table 130 Cell tracing parameters (part 1 of 3)
Parameter Tracea TraceSrc TraceConfigFileName Description allows the generation of trace messages location of the file containing the configuration of the trace messages Type Boolean path Default value Yes No mcell.trace %T/trace
includes the file and line number in the trace messages Boolean
path TraceDefaultFileName destination file to redirect trace messages from stderr to, in case the cell runs as a daemon or service Note: If you direct trace files to the temporary directory of the cell (for example, TraceDefaultFileName=%T/trace - %T=cell_tmp), the trace file will be removed each time the cell starts because the cell always cleans up its tmp directory at startup. To keep trace files across cell sessions, do not use the tmp directory as the default destination file location. TraceRuleLevel sets the level of rule execution tracing:
I I I
number
0no rule tracing and no cell error catch (not recommended) 1no rule tracing; cell errors are caught in the standard cell trace (default) 2rule tracing enabled ALL
TraceRulePhases
When rule tracing is enabled, lists the rule phases to be string traced. The value ALL can be used to specify that all phases are to be traced. Each phase can be prefixed with a + or a - sign to indicate addition or removal from the list. The list is interpreted in sequential order. For example, the following parameter setting: TraceRulePhases=ALL,-refine,-regulate indicates that all rule phases will be traced except for the refine and regulate phases. NOTE: TraceRulePhases and TraceRuleName work together to determine which rules are traced. A rule is only traced if both the phase to which it belongs and the rule itself are configured for tracing.
Appendix B
293
Trace parameters

Parameter TraceRuleNames Description Type Default value ALL:ALL string When rule tracing is enabled, lists module:rule combinations to be traced. The value ALL can be used to specify that all modules and/or rules are to be traced. Each module:rule combination can be prefixed with a + or a - sign to indicate addition or removal from the list. The list is interpreted in sequential order. For example, the following parameter setting: TraceRuleNames=HelpDesk:ALL, -HelpDesk:rule1,SendMail:rule1 indicates that all rules in the HelpDesk module will be traced except for rule1. Additionally, rule1 from the SendMail module will be traced. NOTE: TraceRulePhases and TraceRuleNames work together to determine which rules are traced. A rule is only traced if both the phase to which it belongs and the rule itself are configured for tracing. TraceRuleHeader allows you to configure the header text of the trace text messages. You can configure the header text to contain references to parameters, using the following designations to represent the associated parameters:
I I I I I I I I
%F, %L: %P %R: %C # %H:
%I message id %F source file name %L source line number %M KB module name %R rule name %P rule phase %H handle of the main event being processed (event_handle slot) %C class name of the main event being processed
For example, the default parameter setting

TraceRuleHeader=%F, %L: %P %R: %C #%H:
results in a message similar to:

mc_intevt.mrl, 42: new StbldStop: MC_CELL_STATBLD_STOP #118: Rule execution starting
TraceRuleToXact
indicates whether to include rule tracing in the Boolean transaction file, as well as in the standard cell trace, in module RULES
No
294
Trace parameters

Parameter TraceFileSize Description Type Default value limit on the size of a trace destination file, expressed in number kilobytes When the trace file grows beyond the indicated size, it is renamed with a numerical suffix appended. A new trace file is started. Special value 0 (the default) means no limitation on file size. TraceFileHistory number of trace files to be kept in history When this number is reached, a new numbered trace file will remove the oldest one. TraceFileAppend
a
number
indicates whether to append to existing trace files or empty existing trace files at startup
Boolean
Yes
Appendix B
295
Trace parameters
296
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
.baroc files 68, 69 .jar files digitally signing 194 .load files 68, 70 .loadwic files 70 .mrl files 69 .pkg files 69 .wic files 69, 70 .xact files 72 @kbversion annotation 73 BIX tool tips enabling and disabling for presentation names 195 BMC Impact Administration server command line interface 78 configuration files 78, 119 customizing BMC IX colors 99 default mapping of roles and permissions 83 defining client logging 98 defining group roles 88 defining high availability for Impact Administration cell 105 defining permissions 83 defining primary and secondary servers 101 defining standalone servers 101 editing logging properties 98 high availability 101 iadmin command 78 iadmin command format 80 iadmin command options 79 iadmin reinit options 104 LDAP configuration 109 manual editing guidelines 82 Master server 102 relation to BMC Impact Portal 93 Standard server 102 supporting remote actions for infrastructure management 107 synchronization properties 103 synchronizing with BMC Atrium CMDB 95 synchronizing with BMC Impact Portal 93 transaction and trace logs 106 updating cell information 96 updating user information (file-based authentication) 91 BMC Impact Explorer configuration files, event group 185 defining presentation name search order using ix.properties file 191 remote cell administration 58 BMC Impact Manager CLI common options 211 configuration of 269 BMC Impact Portal communication and encryption parameters 135 configuration parameters 124 configuring the ixs.properties file 124
A
action result event parameters ActionResultInlineLimit 274 ActionResultKeepPeriod 274 actions directory 69 activating maximum tracing for all modules 219 adding slot flags and default values 224 slot names and representation types 224 administering remote cells Administration View (BIX) 58 Administration View managing cells from 58 metrics collection 165 Reload menu 163 administrator activities modifying cell connection settings 132 AllowAdapterFrom 280 AllowBrowserFrom 280 AllowCellFrom 280 AllowCLIFrom 280 AllowConnectionFrom 280 AllowEIFFrom 280 application.properties configuration file 125
B
bin directory 68 BIX defining presentation name search order using ix.properties file 191 extracting presentation name resource files 189
Index
297
BMC Impact Portal (continued) policy file 179 report goal line configuration parameters 134 BMC Portal starting from command line 123 starting from Services Window 123 starting on UNIX 123 stopping from command line 123 stopping on UNIX 123 URL address 124 URL address syntax 124 BMC Software, contacting 2 cells (continued) recovering data 262 remote administration 58 retrieving information 238 running in foreground 217 sending events to 251, 267 starting 217 starting a specified cell 216 starting and stopping 72 status 235 stopping with mkill 248 test, described 25 view information 58 CellTickInterval 287 class information request 220 classes directory 68 CLI, BMC Impact Manager. See BMC Impact Manager CLI client configuration for passive connections 36 client parameters 287 ClientCleanupInterval 278 ClientPollTimeOut 278 ClientSendTimeOut 278 DateFormat 278 SynchronizedTimeOut 278 ClientCleanupInterval 278 ClientPollTimeOut 278 ClientSendTimeOut 278 closing an event 267 collectors 225 directory 68, 69 com.bmc.sms.iwc.component.properties. generalProperties.properties file property 133 com.bmc.sms.iwc.domain.notification.impact.type property 133 com.bmc.sms.iwc.domain.recentitem. RecentItemsFolderIcon property 133 com.bmc.sms.iwc.event.table property 133 com.bmc.sms.iwc.event.table.maximumevents property 134 com.bmc.sms.iwc.event.table.minimumevents property 134 com.bmc.sms.iwc.status. 134 com.bmc.sms.iwc.status.table property 133 com.bmc.sms.iwc.status.table. existinggroup property 134 com.bmc.sms.iwc.status.table.causes property 134 com.bmc.sms.iwc.status.table.consumers property 134 com.bmc.sms.iwc.status.table.providers property 134 com.bmc.sms.iwc.ui.recentitems.maxsize property 133 command options mkill 248 mrmerge 265 commands mccomp 71, 214 mcell 216 mcfgtrace 217, 218 mclassinfo 220
C
cell defining high availability for Impact Administration 105 Impact Administration 105 cell configuration creating files for specific cells 30 files 4344 modifying cell connection settings 132 Cell Info dialog box (BIX) 165 cell names conventions for 231 cell objects, retrieving 251, 267 cell parameters CellDescription 274 CellOperationLevel 274 CellOperationRelax 274 ConnectionPortRange 275 ConnectionPortReuse 275 ProcessingLimitPercentage 275 ServerAllInterfaces 275 ServerDirectoryName 275 ServerPort 275 SystemLogDirName 276 SystemTmpDirName 276 cell tracing parameters, list of 293 CellDescription 274 CellErrorEvents 287 CellEventEnable 287 CellMetricsEnabled 287 CellOperationLevel 274 CellOperationRelax 274 cells creating new 231, 264 deleting 237 extracting state files from 264 heartbeats 287 naming, mcrtcell command 231 obtaining status using mcstat 236 posting events 251 production, described 25 reconfiguring 43, 231
298
commands (continued) mcollinfo 225 mcontrol 72, 228 mcrtcell 71, 231 mcstat 235 mdelcell 237 mgetinfo 74, 238 mgetrec 243 mkb 71, 245 mkill 248 mlogchk 249 mposter 251, 255 mquery 251, 267 mrecover 262 mrextract 264 mrmerge 265 msend 251, 267 msetmsg 267 msetrec 268 reference 210 communication and encryption AllowAdapterFrom 280 AllowBrowserFrom 280 AllowCellFrom 280 AllowCLIFrom 280 AllowConnectionFrom 280 AllowEIFFrom 280 BMC Impact Portal configuration parameters 135 encryption behavior 40 ForceEncryption 39 mcell.conf settings 39 mcell.dir settings 39 mclient.conf settings 39 compiling Knowledge Base 214 Knowledge Bases 71 Knowledge Bases with trace 72 version annotations 73 configuration activities for administrators modifying cell connection settings 132 configuration files cell 4344 cell-specific, creating 30 ix.properties 183 ixs.properties 124 mcell.conf 28, 31 mcell.modify 3738 mcell.propagate 31 mcell.trace 51 StateBuilder configuration 199 configuration parameters BMC Impact Portal configuration and encryption 135 HeartbeatEnabled 284 HeartbeatInterval 284 HeartbeatMissedCritical 284 HeartbeatMissedMinor 284 HeartbeatMissedWarning 284 configuring BIX using the ix.properties file 183 BMC Impact Portal using ixs.properties 124 clients for passive connections 36 error tracing for BMC Impact Manager 217, 218 reloading cell configuration 43 setting cell-specific configurations up 30 StateBuilder 199 connecting cells in a protected zone 36 ConnectionPortRange 271, 275 ConnectionPortReuse 271, 275 consistency checks 249 console_policy.prop 179 control operations 228 conventions for cell naming 231 creating a new cell 231 a new service with mcrtcell 234 another service 234 configuration files cell-specific 30 Knowledge Bases 71 customer support 3
D
data classes directory 69 data directory 68 data instances directory 69 DateFormat 278 deleting a cell 237 events using mquery 261 digital test certificate 194 digitally signing .jar files 194 directories bin 68 classes 68 collectors 68 data 68 for KB components 69 lib 68 record 69 rules 69 structure for Knowledge Bases 66 dynamic data model 284
Index
299
E
EM cell production 25 test 25 enabling persistent buffering 255 encryption behavior 40 mcell.conf settings 39 mcell.dir settings 39 mclient.conf settings 39 encryption key 39 error file mcell.err 57 establishing inbound connection in protected environment 36 event classes directory 69 event group configuration files 185 event parameters EventAutoClose 281 EventDBCleanupDurationLimit 281 EventDBCleanupInterval 281 EventDBCleanuponDateReception 281 EventDBCleanupPercentage 281 EventDBCleanupPreferClosed 282 EventDBKeepClosed 282 EventDBKeepNonClosed 282 EventDBNoCleanupClosed 283 EventDBNoCleanupNoCleanupNonClosed 283 EventDBSize 283 repository cleanup 281 event propagation enabling 33 illustrated 33 event repository cleanup parameters 281 EventAutoClose 281 EventDBCleanupDurationLimit 281 EventDBCleanupInterval 281 EventDBCleanupOnDateReception 281 EventDBCleanupPercentage 281 EventDBCleanupPreferClosed 282 EventDBKeepClosed 282 EventDBKeepNonClosed 282 EventDBNoCleanupClosed 283 EventDBNoCleanupNonClosed 283 EventDBSize 283 events deleting using mquery 261 exporting to a flat file 205 merging objects 265 modifying 267 posting with mposter 251 propagating using a gateway 31
examples mccomp 215 mcell 217 mcfgtrace 219 mclassinfo 222 mcollinfo 227 mcontrol 230 mcrtcell 234 mcstat 236 mdelcell 237 mgetinfo config 241 mgetinfo connect 243 mgetinfo param 242 mgetinfo services 242 mgetrec command 244 mkb 247 mkill 249 mlogchk 250 mquery 261 mrecover 263 mrextract 264 mrmerge 266 msetmsg 267 msetrec 269 ExportConfigFileName 199 ExportDiscarded 199 exporting event data from mcdb by StateBuilder 199 events to a flat file 205 ExportTriggerArguments 199 ExportTriggerProgram 199
F
files .baroc 68, 69 .load 68, 70 .loadwic 70 .mrl 69 .pkg 69 .wic 69, 70 .xact 72 application.properties 125 extensions for KB components 69 gateway.export 198, 205, 206 ixs.properties 124 kb_core_resource.properties 188 kb_deprecated_resource.properties 189 manifest.kb 70, 214 mcdb state 198 mcell.conf 31 mcell.dir 34??, 211 mcell.err error 57 mcell.modify 37, 124 mcell.propagate 31 mcell.trace 51
300
files (continued) mcfgtrace 217, 218 propagation configuration 31 sim.wic 68 sim_decl.wic 68 statbld.conf 198, 205 statbld.exe 198 statbld.trace 198, 207 StateBuilder configuration 199 trace configuration 51 xact transaction 198 filters using hidden slots 180 ForceEncryption 39 foreground, running cell in 217 infrastructure management (continued) permissions 142 registered components 140, 166, 172 related components 154 remote actions 148, 149, 160, 174 remote systems 145 roles 142 run states 174 specifying support files 169 support files 146, 169, 171 usage reporting 159 interface classes directory 69 ix.properties file defining presentation name search order for BIX 191 entry format 190 property descriptions 183 ixs.properties file parameters 136 using to customize BMC Impact Portal 124
G
gateway 31 gateway configuration 200 gateway.export file 198, 205, 206 global records directory 69 obtain a value 243 setting a value 268 goal line (reports) configuration parameters 134
J
jar files digitally signing 194 Java Web Start application extracting presentation name resource files 189
H
HeartbeatEnabled parameter 284 HeartbeatInterval parameter 284 HeartbeatMissedCritical parameter 284 HeartbeatMissedMinor parameter 284 HeartbeatMissedWarning parameter 284 heartbeats, cell 287
K
kb_core_resource.properties file entry format 192 modifying 193 kb_deprecated_resource.properties file 189 KBDirName 287 KBDirName parameter 287 kbmodules argument 74 KBRecoveryDirName parameter 287 kbsources argument 74 kbversion primitive described 74 keys creating and modifying presentation names 192 formats for presentation names 192 Knowledge Bases compiling 71, 214 compiling with trace 72 creating 71 directories 69 directory structure 66 file extensions 69 importing 71 index file 70 integrating with a unified KB 70 KBDirName 287
I
icons BMC Impact Explorer configuration files for event groups 185 image views overview 124 importing Knowledge Bases 71 infrastructure management Administer subtabs 154 audit log 165, 167, 171 default service model 140, 142 Details subtabs 152 editing infrastructure relationships 156 GUI view 144, 150 high availability cells 160 icons 150 manually deleting components 174 navigation tree 143, 151
Index
301
Knowledge Bases (continued) loading 72 managing 70 parameters KBRecovery 287 retrieving version information with kbversion 74 retrieving version information with mgetinfo 74 subdirectories 68 updating 245 versioning 72 versioning mechanism 73 mcfgtrace command (continued) parameters 219 syntax 218 mclassinfo command 220 adding slot flags and default values 224 adding slot names and representation types 224 examples 222 obtaining a list of classes 223 obtaining a list of slot names 223 options 220 output 220 return codes 225 syntax 220 mcollinfo command 225 example 227 options 225 output 226 return codes 228 syntax 225 mcontrol command 72, 228 commands mcontrol 229 examples 230 options 228 reconfiguring a cell 231 retrying pending propagations 230 syntax 228 terminating a cell 230 mcrtcell command 71, 231 actions 232 creating a service 234 creating another service 234 examples 234 options 233 return codes 235 syntax 233 mcstat command 235 example 236 options 236 return codes 236 mdelcell command 237 deleting a cell 237 example 237 options 237 return codes 238 syntax 237 menu, Reload 163 merging event objects 265 message buffer parameters MessageBufferKeepSent 289, 290 MessageBufferKeepWait 289, 290 MessageBufferReconnectIntervalparameters MessageBufferReconnectInterval 289, 291 MessageBufferResendCount 289, 291 MessageBufferSize 288, 290, 291 MessageBufferKeepSent 289, 290 MessageBufferKeepWait 289, 290
L
lib directory 68 loading Knowledge Bases 72
M
managing Knowledge Bases 70 manifest.kb file 70, 214 mccomp command 71, 214 example 215 options 214 return codes 215 syntax 214 mcdb state file 198 affects on recovery process 262 mcell command 216 example 217 options 216 return codes 218 syntax 216 mcell.conf file parameter rules 28 path substitution parameters 29 specifying paths 29 mcell.dir file 211 configuring clients for passive connections 36 description and usage 34?? example file 35 format of entries 34 keywords for entries 35 rules applied to entries 35 mcell.err file 57 mcell.modify file 37, 3738, 124 mcell.propagate file 31 default options 32 usage 31 mcell.trace file 51, 217, 218 mcfgtrace command 217, 218 example 219 options 219
302
MessageBufferReconnectInterval 289, 291 MessageBufferResendCount 289, 291 MessageBufferSize 288, 290, 291 metrics collection, tab for 165 mgetinfo command 74, 238 config example 241 connect example 243 options 238 param example 242 return codes 243 services example 242 syntax 238 mgetrec command 243 example 244 options 244 return codes 245 syntax 244 mkb command 71, 245 examples 247 options 245 return codes 248 syntax 245 mkill command 248 command options 248 examples 249 options 249 return codes 249 syntax 248 mlogchk command 249 examples 250 return codes 251 syntax 250 modifying cell connection settings 132 ModuleName parameter 73 monitoring passive connections 37 mposter command 251, 255 enabling persistent buffering 255 options 252 return codes 256 syntax 252 mquery command 251, 267 deleting events 261 examples 261 options 257 output 258 return codes 262 selecting events with a severity level 261 syntax 257 mrecover command 262 example 263 options 263 return codes 263 syntax 263 mrextract command 264 example 264 options 264 mrextract command (continued) return codes 265 syntax 264 mrmerge command 265 command options 265 example 266 options 266 return codes 266 syntax 265 msend command 251, 267 msetmsg command 267 closing an event 267 examples 267 options 267 return codes 268 syntax 267 msetrec command 268 example 269 options 268 return codes 269 syntax 268
N
name keys creating and modifying 192 naming conventions for cells 231
O
objects list of presentation names for 188 obtaining a global record value 243 obtaining a list of classes 223 obtaining a list of slot names 223 obtaining status of cell using mcstat 236 options mccomp 214 mcell 216 mcfgtrace 219 mclassinfo command 220 mcollinfo 225 mcontrol 228 mcrtcell 233 mcstat 236 mdelcell 237 mgetinfo 238 mgetrec 244 mkb 245 mkill 249 mposter 252 mquery 257 mrecover 263
Index
303
options (continued) mrextract 264 mrmerge 266 msetmsg 267 msetrec 268 output mclassinfo 220 mcollinfo 226 mquery command 258 PropagateBufferSize 289, 291 PropagateConfigFileName 290 propagating events using a gateway 31 propagation configuration file, mcell propagate 31 propagation parameters PropagateBufferSize 289, 291 PropagateConfigFileName 290 protected environments client configuration for passive connections 36 monitoring passive connections 37 protected zone, connecting cells in 36
P
parameters ActionResultInlineLimit 274 ActionResultKeepPeriod 274 BMC Impact Portal configuration 124 client 287 HeartbeatEnabled 284 HeartbeatInveral 284 HeartbeatMissedCritical 284 HeartbeatMissedMinor 284 HeartbeatMissedWarning 284 KBRecovery 287 mcfgtrace 219 Server 287 state 287 trace, list of 293 tracing, configuring 55 passive connections 36 client configuration 36 monitoring 37 passwords invalid, logging on to BMC Portal 122 pending progagations retrying 230 policy file BMC Impact Portal 179 console_policy.prop 179 posting events to a cell 251 presentation names about 188 creating a new resource file 190 creating and modifying name keys 192 default definitions 189 defining 192 enabling and disabling BIX tool tips for 195 extracting resource files for BIX (Java Web Start) 189 files 191 key formats 192 list of objects with 188 resource file locations 188 resource file search order 191 ProcessingLimitPercentage 30, 275 product support 3 production cells described 25
R
reconfiguring cell files for 43 cells with mcontrol command 231 records directory 69 Reload menu (BIX) Administration View (BIX) 163 reports BMC Impact Portal goal line configuration parameters 134 resource files creating 190 extracting for BIX (Java Web Start) 189 locations of 188 search order 191 retrieve objects from cell 251, 267 retrying pending progagations 230 return codes mccomp 215 mcell 218 mclassinfo 225 mcollinfo 228 mcrtcell 235 mcstat 236 mdelcell 238 mgetinfo 243 mgetrec 245 mkb 248 mkill 249 mlogchk 251 mposter 256 mquery 262 mrecover 263 mrextract 265 mrmerge 266 msetmsg 268 msetrec 269 statbld 199 RuleLoopDetect 287 rules directory 69
304
S
saved state 262 scripts and programs directory 69 selecting events with a severity level 261 server parameters 287 CellErrorEvents 287 CellEventEnable 287 CellMetricstEnabled 287 CellTickInterval 287 ConnectionPortRange 271, 275 ConnectionPortReuse 271, 275 ProcessingLimitPercentage 30, 275 RuleLoopDetect 287 ServerDirectoryName 275 ServerPort 275 ServerAllInterfaces 275 ServerDirectoryName 275 ServerPort 275 service models class definitions directory 69 setting a value in a global record 268 cell-specific configuration up 30 SIM cell production 25 test 25 sim.wic file 68 sim_decl.wic file 68 starting cells specific cell 216 with mcell 72 statbld return codes 199 statbld.conf file 198, 205 statbld.exe file 198 statbld.trace file 198, 207 State 292 state configuration parameters 287 ExportConfigFileName 199 ExportDiscarded 199 ExportTriggerArguments 199 ExportTriggerProgram 199 StateHistoryCount 199 state files, extracting 264 state parameters 287 StateBuildAtTerminate 292 StateBuildConfigFileName 292 StateBuildInterval 292 StateBuildRunTimeOut 292 StateBuildSize 292 StateBuildAtTerminate 292 StateBuildConfigFileName 292 StateBuilder 198 configuration parameters for event data export 199 StateBuildInterval 292 StateBuildRunTimeOut 292
StateBuildSize 292 StateHistoryCount 199 stopping cells with mkill 72, 248 support, customer 3 SynchronizedTimeOut 278 syntax mccomp 214 mcell 216 mcfgtrace 218 mclassinfo 220 mcollinfo 225 mcontrol 228 mcrtcell 233 mdelcell 237 mgetinfo 238 mgetrec 244 mkb 245 mkill 248 mlogchk 250 mposter 252 mquery 257 mrecover 263 mrextract 264 mrmerge 265 msetmsg 267 msetrec 268 SystemLogDirName parameter described 276 SystemTmpDirName parameter described 276
T
technical support 3 terminating a cell 230 test cells described 25 test certificate, digital 194 tool tips BIX, enabling and disabling 195 trace configuration file 51 configuring 51 parameters 51 Trace parameter 293 trace parameters list of 293 trace, disable encryption to 41 TraceConfigFileName parameter 293 TraceDefaultFileName parameter 293 TraceFileAppend parameter 295 TraceFileHistory parameter 295 TraceFileSize parameter 295 TraceRuleLevel parameter 293 TraceRuleToXact parameter 294 TraceSrc parameter 293
Index
305
tracing parameters configuring 55 Trace 293 TraceConfigFileName 293 TraceDefaultFileName 293 TraceFileAppend 295 TraceFileHistory 295 TraceFileSize 295 TraceRuleLevel 293 TraceRuleToXact 294 TraceSrc 293
U
updating the Knowledge Base 245 usage reporting 159
V
VersionID parameter 73 versioning compiling 73 Knowledge Bases 72 mechanism 73 retrieving version information with kbversion 74 retrieving version information with mgetinfo 74
X
xact transaction file 198
306
Notes
*97717* *97717* *97717* *97717*

*97717*

BMC Impact Solutions Infrastructure Management Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMC Impact Solutions Infrastructure Management Guide

Uploaded by

Copyright:

Available Formats

BMC Impact Solutions Infrastructure Management Guide

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC