BMC Impact Solutions Infrastructure Management Guideatmgmicrosoft.free.fr/depot/at/BMC doc/BMC...

www.bmc.com

BMC Impact SolutionsInfrastructure Management Guide

Supporting

BMC Impact Manager version 7.3 BMC Impact Administration Server 7.3BMC Impact Explorer version 7.3 BMC Impact Portal version 7.3

February 2009

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 INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2006–2009 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 legendU.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.

http://www.bmc.com

3

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

■ 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 [email protected]. (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:

■ 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

■ 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

http://www.bmc.com/support_home

mailto:[email protected]

4 BMC Impact Solutions Infrastructure Management Guide

ContentsChapter 1 Managing BMC Impact Manager cells 23

General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Production cells and test cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Creating cell-specific configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31About mcell.dir, the cell directory file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Managing high availability cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Automatic failover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Automatic switchback process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Manually failing over to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Manually switching back to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . 46Explicitly connecting a CLI to a selected high availability cell server. . . . . . . . . . 47

Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 56

Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 58

Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Problem: 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 5

About the unified Event Management and Service Impact Management Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Knowledge Base index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Managing a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Integrating a unified KB with pre-7.2 cell definitions . . . . . . . . . . . . . . . . . . . . . . . 70Creating a new production or test Knowledge Base—mcrtcell . . . . . . . . . . . . . . . 71Importing Knowledge Base information into a cell—mkb . . . . . . . . . . . . . . . . . . . 71Compiling a Knowledge Base—mccomp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Loading a Knowledge Base into a running cell—mcontrol . . . . . . . . . . . . . . . . . . . 72Implementing changes to a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Versioning a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Retrieving KB version information in rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Retrieving KB version information by using a command—mgetinfo . . . . . . . . . . 74

Chapter 3 Managing the BMC Impact Administration server 77

Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 81

Guidelines for manual edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Defining permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Full Access role permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Adding customized role/permission mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Defining group roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88File-based authentication: updating user information . . . . . . . . . . . . . . . . . . . . . . . 91Adding role names to the cell’s KB definition files. . . . . . . . . . . . . . . . . . . . . . . . . . 93Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . 93Synchronizing cell information with BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . 95Updating cell information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Defining client logging for the iadmin script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Customizing colors for severities, statuses, and priorities. . . . . . . . . . . . . . . . . . . . 99IAS Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Customizing the IAS thread pool handling IAS Clients . . . . . . . . . . . . . . . . . . . . 100Defining standalone, primary, and secondary BMC Impact Administration

servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Defining a failover configuration for the Impact Administration cell . . . . . . . . . 105

Transaction and trace logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Example trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Configuring BMC Impact Administration server to support remote actions. . . 107Configuring Lightweight Directory Access Protocol for BMC Impact

Administration server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Problem: Cell_info.list synchronization error during manual configuration of an IAS failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6 BMC Impact Solutions Infrastructure Administration Guide

Chapter 4 Managing the BMC Impact Portal 121

Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . 123Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . 124Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . 130Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . 132smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . 133smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . 134internal.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Chapter 5 Working with Infrastructure Management 139

Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . 142Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Displaying and understanding the Details and Administer tab data . . . . . . . . . 152Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172How a product component registers and communicates with the IAC . . . . . . . 172

Contents 7

Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Chapter 6 Managing the BMC Impact Explorer (BMC IX) console 177

Defining property files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Selecting a single BMC IX instance for cross- and web-launching . . . . . . . . . . . . . . . 179Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Configuring display and connection settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Defining global event severity and priority color values . . . . . . . . . . . . . . . . . . . . . . . 184Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter 7 Defining presentation names 187

Presentation names overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Creating a new presentation name resource file . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Digitally signing a .jar file with a digital test certificate. . . . . . . . . . . . . . . . . . . . . 194

Enabling or disabling presentation names inBMC Impact Explorer tool tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Chapter 8 Configuring StateBuilder and gateways 197

Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198StateBuilder configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Exporting events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Modifying a statbld.conf file to export events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 206

Configuring tracing for StateBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Trouble-shooting the StateBuilder process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Appendix A BMC SIM and EM CLI Reference 209

BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 211Configuring CLI authentication through BMC Impact Administration Server . 212BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 213mccomp—Compiling rules in the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . 214mcell—Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216mcfgtrace—Configuring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218mclassinfo—Requesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220mcollinfo—Getting information about a specific collector . . . . . . . . . . . . . . . . . . 225


mcontrol—Performing cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228mcrtcell—Creating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231mcstat—Returning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235mdelcell—Deleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237mgetinfo—Retrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 238mgetrec—Obtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243mkb—Updating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245mkill—Stopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248mlogchk—Performing consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249mposter and msend—Managing data and events . . . . . . . . . . . . . . . . . . . . . . . . . 251mquery—Retrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257mrecover—Recovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . 262mrextract—Extracting cell state files to create new state files . . . . . . . . . . . . . . . 264mrmerge—Merging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265msetmsg—Modifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267msetrec—Setting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . 272BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Appendix B mcell.conf file parameters 273

Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Deprecated MessageBuffer propagation parameters. . . . . . . . . . . . . . . . . . . . . . . 290Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Index 297

Contents 9

FiguresConnectionPortRange syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Distributed event management using event propagation . . . . . . . . . . . . . . . . . . . . . . 33Format of an entry in the mcell.dir file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Example of the mcell.dir file and its entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Passive connection format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Data object specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37mcell.modify file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Masking syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Format of configuration line in mcell.trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Output from mgetinfo kbsources argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Relation among users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . 82Excerpt from ldap_configuration.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Infrastructure Management navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Default service model BMC Impact Solutions (with active services) . . . . . . . . . . . . 144Edit Relationships dialog with Edit This Relationship subdialog . . . . . . . . . . . . . . . 156Actions right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160High availability (HA) view: two cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Actions right-click menu for OVO adapter cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162default.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Operator.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Default policy file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Listing of the contents of a keystore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Parameters used to print event in BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Example of printed events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Command to configure the export file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205gateway.export file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206gateway.explore file output for new events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206gateway.explore file output for modified events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207mccomp syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214mccomp example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Example output for mccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215mcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Starting a cell as a service on windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Starting the BMC Impact Manager service on Microsoft Windows . . . . . . . . . . . . . 217mcfgtrace syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219mcfgtrace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219mclassinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Figures 11

Raw output format for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Class tree for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Example of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . . . . . . . . 223Example output of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . 223Example of mclassinfo command for list of classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Example of mclassinfo command output for list of classes . . . . . . . . . . . . . . . . . . . . . 223Example of mclassinfo command for adding slot names . . . . . . . . . . . . . . . . . . . . . . 224Example of mclassinfo command output for adding slot names . . . . . . . . . . . . . . . . 224Example of mclassinfo command for adding slot flags . . . . . . . . . . . . . . . . . . . . . . . . 224Example of mclassinfo command output for adding slot flags . . . . . . . . . . . . . . . . . 224mcollinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Raw output format for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226mcollinfo example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227mcollinfo command for verbose mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227mcollinfo command for number of events for severity/status . . . . . . . . . . . . . . . . . . 227mcontrol syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Retrying Pending propagations with mcontrol command . . . . . . . . . . . . . . . . . . . . . 230Example of mcontrol command output for retrying pending propagations . . . . . . 230Terminating a cell using the mcontrol command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Example of mcontrol command output for terminating a cell . . . . . . . . . . . . . . . . . . 231Reconfiguring a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Example of mcontrol command output for reconfiguring a cell . . . . . . . . . . . . . . . . 231mcrtcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Example of output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Example output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Example mcrtcell for recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235mcstat syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236mcstat example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Message for cell not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Message for cell running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236mdelcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Deleting a cell using mdelcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Output for mdelcell if cell is not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Output for mdelcell if cell is running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238mgetinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Example of mgetinfo param . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242mgetinfo param command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242mgetinfo services command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Output of mgetinfo connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243mgetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Example of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Output of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244mkb syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245mkb command on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247mkb output on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247


mkb command on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248mkb command output on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248mkill syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Example of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Output of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249mlogchk syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Example of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Output of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250mlogchk message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251mposter syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252msend syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Example of mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Definition changes using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Enabling persistent buffering using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Error message if buffers files are not writable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256mquery syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Example of raw output specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Verbose mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258End of form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Special BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Example of mquery—Select events with severity status . . . . . . . . . . . . . . . . . . . . . . 261Example of mquery—Select events from collector . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Deleting events using mquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261mrecover syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Fixing a broken cell using mrecover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263mrextract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Example of mrextract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264mrmerge syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Example of mrmerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266msetmsg syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267msetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Example of msetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269command to send tracing output to text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Example of Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Figures 13

TablesBMC Impact Solutions configuration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Cell configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Substitution parameters for %X in path value parameters . . . . . . . . . . . . . . . . . . . . . . 29Default mcell.propagate options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32IP Address parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Files for cell reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43MC_CELL_METRIC slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Default values for client parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49MC_CELL_CLIENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50MC_CELL_MODIFIED_EVENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Trace configuration file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51MC_CELL_PROCESS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56BMC Impact Manager exit codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57SIM_NOTIFICATION_REGISTRY dialog box fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Knowledge Base subdirectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Knowledge Base file extensions and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Configurable IAS files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78iadmin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79BMC Impact Explorer user group mapping to functionality . . . . . . . . . . . . . . . . . . . 83Groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Cell entry format in cell_info.list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Server logging properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98IAS status monitoring properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100IAS thread pool properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100IAS synchronization properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103mcell.dir entries for a failover pair of Impact Administration cells . . . . . . . . . . . . . 105IAS log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106LDAP configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Event operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Event Table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Status table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Report parameters (application.properties file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Report parameters (internal.properties) file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129application.properties file in smsIwc directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133application.properties file in smsConsoleServer directory . . . . . . . . . . . . . . . . . . . . . 134aggregator.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136internal.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Supported application groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Icon listing for infrastructure management model . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Slot values: Details: General subtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Tables 15

Edit Relationship dialog: field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Edit This Relationship subdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Audit log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Audit log IAS properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Slots for specifying support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170run_state values for components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Component state and menu options for a normal or primary cell in a high

availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Component state and menu options for a secondary cell in a high availability

configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Components and actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176default.console_policy.prop parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Property descriptions from ix.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Event severity levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Event priority levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185xml files that define user interface elements in BMC IX . . . . . . . . . . . . . . . . . . . . . . . 186Presentation names for BMC Impact Solution interfaces . . . . . . . . . . . . . . . . . . . . . . 188Presentation name key formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192StateBuilder file name conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198statbld.conf Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Gateway configuration parameter predefined variables . . . . . . . . . . . . . . . . . . . . . . . 201Gateway Configuration Parameter Text Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201gateway.export file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202BMC Impact Manager CLI command descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Common options for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Common return codes for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214mccomp options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215mcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216mcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218mcfgtrace option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219mcfgtrace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219mclassinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Type of slot value for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Reported facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Class flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Information amount limitation options for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . 222mclassinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225mcollinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Information amount limitation options for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . 227mcollinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228mcontrol option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228mcontrol controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Files for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233mcrtcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233mcrtcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235mcstat option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236mdelcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237


mdelcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238mgetinfo option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239mgetinfo information options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Information from connect request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240mgetinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243mgetrec option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244mkb options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245mkb new file options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246mkill option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249mlogchk return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251mposter and msend options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252mposter and msend return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257mquery options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257mquery query options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260mquery return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262mrecover option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263mrecover return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263mrextract options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264mrextract return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265mrmerge options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266mrmerge return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266msetmsg options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267msetmsg return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268msetrec options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268msetrec return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269BMC Impact Manager CLI configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . 270Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Date and time format parameters for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Event Repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Heartbeat slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Internal cell monitors parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Deprecated MessageBuffer propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . 290Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Service model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Cell tracing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Tables 17

C h a p t e r 1
1 Managing BMC Impact Manager cells
This chapter describes how to manage and configure BMC Impact Manager cells.

General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Managing high availability cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Manually failing over to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Manually switching back to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . 46Automatic failover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Automatic switchback process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Explicitly connecting a CLI to a selected high availability cell server. . . . . . . . . . 47

Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 56

Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 58

Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Problem: 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 overviewTo configure the BMC Impact Solutions environment, you configure the following components after installation:

■ BMC Impact Manager cell■ BMC Impact Explorer■ BMC Impact Portal

Table 1 outlines the tasks that configure these components.

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:

Table 1 BMC Impact Solutions configuration process

Task Description Component For more information, see

1 (optional) Configure the BMC Impact Portal. BMC Impact Portal Chapter 4, “Managing the BMC Impact Portal”

BMC Portal Getting Started

2 Configure BMC Impact Manager cells. BMC Impact Manager Chapter 1, “Managing BMC Impact Manager cells”

3 Define user groups for access to the console functions and objects.

BMC Impact Administration Server

Chapter 3, “Managing the BMC Impact Administration server”

4 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.

■ BMC Impact Portal■ BMC Impact Explorer■ BMC Impact Service

Model Editor

BMC Portal Getting Started

BMC Impact Solutions Installation Guide

5 (optional) Customize BMC Impact Portal. BMC Impact Portal Chapter 4, “Managing the BMC Impact Portal”

6 (optional) Customize BMC Impact Explorer. BMC Impact Explorer Chapter 6, “Managing the BMC Impact Explorer (BMC IX) console”

7 (optional) Configure the StateBuilder, which manages the persistent storage of events.

BMC Impact Manager Chapter 8, “Configuring StateBuilder and gateways”

8 (optional) Customize the labels used in the console interfaces.

■ BMC Impact Portal■ BMC Impact Manager■ BMC Impact Service

Model Editor

Chapter 7, “Defining presentation names”


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:

■ 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 user’s 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.



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 “mcrtcell—Creating 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.

■ 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.


Cell configuration tasks

Cell configuration tasksThe 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 Cell configuration tasks

Task Description For more information, see

1 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.

“mcrtcell—Creating a new cell” on page 231

2 If you created multiple cells for an environment, you can create separate configuration files for each cell.

“Creating cell-specific configuration files” on page 30

3 If you created multiple cells for an environment, configure the cells so that they can communicate with other cells in the network.

BMC Impact Solutions Getting Started Guide

4 If you created multiple cells for an environment, configure a high availability cell or cells.

BMC Impact Solutions Getting Started Guide

“Managing high availability cell servers” on page 44

5 Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed configure the propagation configuration file.

“Configuring event slot propagation” on page 31

6 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 To add a time stamp to a slot so that the date and time is recorded when the slot is changed, configure the mcell.modify file.

“Configuring slots for time stamping” on page 37

8 If desired, you can encrypt communication among the various BMC Impact Solutions components.

“Configuring encryption” on page 38

9 Set the default client parameters executing CLI commands. “BMC Impact Manager CLI configuration” on page 269


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 “mcell—Starting 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

■ One parameter per line, in the form: Parameter=Valuewhere 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.”



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:

■ absolute path—starts with slash (/) or backslash (\), or on Windows, with a drive designator (for example, D:)

■ runtime relative path—starts with ./ or ../. The path is relative from the cell’s 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 path—all other path values are relative from the cell’s 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.

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.

Table 3 Substitution parameters for %X in path value parameters

Parameter Description

%H cell home directory

%C cell configuration directory

%B Knowledge Base binary directory, kb\bin

%L log file directory

%T temporary file directory

%P program name

%N cell name


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.

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,

■ 1828—1840 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.

Figure 1 ConnectionPortRange syntax

PortRange = PortSequence{, PortSequence}PortSequence = Port[-Port]


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:

■ $MCELL_HOME/etc/CellName contains cell-specific configurations (including the Knowledge Base)

■ $MCELL_HOME/log/CellName contains the cell transaction logs and persistent state of the cell

■ $MCELL_HOME/tmp/CellName contains the cell’s 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:

■ $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.



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.

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.

Table 4 Default mcell.propagate options

Parameter Action PerformedDefault Values

administrator propagates administrator value changes up (forward) within the cell hierarchy f

CLASS propagates changes to the class-specific slots up (forward) within the cell hierarchy

f

mc_modhist propagates changes to the mc_modhist up (forward) within the cell hierarchy

This is a system defined slot that requires such propagation.

f

mc_notes propagates changes to notes attached to an event up (forward) within the cell hierarchy

f

repeat_count propagates changes to repeat_count up (forward) within the cell hierarchy f

severity propagates severity value changes up (forward) within the cell hierarchy f

status propagates status value changes in both directions, backward and forward, in the cell hierarchy

bf



Figure 2 Distributed event management using event propagation

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:

■ 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.

event sources

event sources

event sources

event sources

Some events are propagatedfor management by other cellsin the cell network.

cell

cellcell

cell

cell

cell

cell


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 EncryptionKey Host/1828# gateway.portal bip.fullyqualifiedHostName EncryptionKey Host/3783# admin ImpactAdministrationServerName UserID/Password Host/3084



Each parameter in the file is defined as follows:

Example of the mcell.dir file

Figure 4 shows an example of the mcell.dir file with typical component entries.

Conventions for mcell.dir file entries

The following conventions apply when creating entries for the mcell.dir file:

■ Cells may be grouped into separate cell files readable only by certain users or groups (domains).

Attribute Description

Type type of component. It can be■ cell— BMC Impact Manager cell name■ gateway.type—Gateway of type type■ gateway.jServer - predefined jServer gateway type ■ gateway.portal - BMC Impact Portal■ admin - named Impact Administration Server (IAS)

Name 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.

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 bos-71/1828cell local mc 127.0.0.1/1828gateway.portal bip.bos-71.amc.com mc bos-71/3783admin ias1 Mac/FreeAI1 bos-71/3084cell sim1 mc pprod001:1828 bprod001:1828


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.

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.

3 Save the changes.

4 Either reload the cell configuration or stop and start the cell.

NOTE A passive connection is only possible with the “server” type clients, such as the cell and gateway clients.

Figure 5 Passive connection format

cell cellName EncryptionKey 0


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.

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.

Figure 6 Data object specification

MC_CELL_PASSIVE_CLIENT ISA MC_CELL_HEARTBEAT ; END


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.

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:

■ the cell’s 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

Figure 7 mcell.modify file

# Configuration of slots affecting mc_modification_date when modified# Format :# SlotName# Special name : CLASS : specifies all class-specific slotsstatusseveritymc_priorityrepeat_countCLASS



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:

■ 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

■ 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:

■ 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.



■ 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 cell’s connection information.

2. BMC Impact Explorer retrieves the cell’s 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:

■ 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



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.

Mandatory key specification conditions

You must specify the encryption key if the following conditions apply:

■ 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.

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.

Figure 8 Masking syntax

AddrMaskList = AddrMask {':' AddrMask}AddrMask = Addr ['/' Mask]Addr = Nr '.' [Nr '.' [Nr '.' [Nr]]]Mask = Addr | NrNr = 0..255



The following conventions apply:

■ 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.

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:

■ 127.0.0.1■ 127.0.0.1/32■ 127.0.0.1/255.255.255.255

Table 5 IP Address parameters


AllowConnectionFrom=0./0 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


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.

Reloading cell configurationThe 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:

■ Send a hang-up signal on UNIX.

■ Run the mcontrol command on UNIX or Windows. For information about the mcontrol command, see “mcontrol—Performing 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 Files for cell reconfiguration (part 1 of 2)

Type Name/Directory Result of reconfiguration

cell directory mcell.dira 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.

cell tracing mcell.tracea Tracing is adapted and has the same effect as through the mcfgtrace CLI.

cell configuration

mcell.conf The cell restarts automatically.

mcell.propagate

mcell.modify

KB collector kb\collectors The cell restarts automatically.


Managing high availability cell servers

Managing high availability cell serversIf 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.

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.

KB program kb\classes The cell restarts automatically.

\kb\rules

\kb\lib

\kb\bin

KB data kb\data The cell restarts automatically.

\kb\records

a 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.”

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.

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.

Table 6 Files for cell reconfiguration (part 2 of 2)

Type Name/Directory Result of reconfiguration


Automatic failover process

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.

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.


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

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:

■ 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:

■ 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.

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.


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 performanceEvent processing metrics are internal counts maintained on cell performance categories in connection with event processing. These metrics count the following items:

■ 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.


Monitoring event performance

The resulting metrics are:

■ short term—total count of the last complete one-minute interval■ medium term—sum of the five last, completed one-minute intervals■ long term—running 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 long-term 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.

Subject names available are:

Table 7 MC_CELL_METRIC slots

Slot Description

description metric description

long_average long-term average, per second

long_interval long-term interval lengths, in seconds

long_total long-term total count

medium_average medium-term average, per second

medium_interval medium-term interval lengths, in seconds

medium_total medium-term total count

short_average short-term average, per second

short_interval short-term interval lengths, in seconds

short_total short-term total count

subject metric subject name


Monitoring client to cell interactions

ReceivedEventsErrorEventsDroppedEventsStoredEventsRemovedEventsPropagatedEvents

CLI commands for collecting metrics are:

mcontrol metrics on|off|resetmgetinfo [-v] metrics

Monitoring client to cell interactionsWhenever 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.

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.

Table 8 Default values for client parameters

Parameter Value

ReportConnectClients browser, Console, mcontrol, mkill, mposter, msetmsg, msetrec

ReportModifyClients mposter, msetmsg, msetrec


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.

There are three subclasses of this class:

■ 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.

■ 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.

Configuring cell tracingTo set up cell tracing, configure

■ 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 “mcfgtrace—Configuring tracing” on page 218.

Table 9 MC_CELL_CLIENT slots

Slot Data

client_location the location of the client as IPAddress:Port

client_name the client's name, as announced by the client, or noname

client_type type of client, such as adapter, CLI, console, cell

Table 10 MC_CELL_MODIFIED_EVENT slots

Slot Data

event universal event ID of the event being modified

requestor identification of the user that performed the modification


Configuring mcell.trace

Configuring mcell.trace

The trace configuration file, mcell.trace, configures the tracing of the cell’s 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 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.

.

Table 11 lists the parameters that must be defined in a configuration line.

Figure 9 Format of configuration line in mcell.trace file

<Module> <Level> <Destination>SWITCH <Switch> <Destination>

Table 11 Trace configuration file parameters (part 1 of 2)


Destination destination file name or predefined value for the selected trace messages or switch

predefined values:no—disables these tracing messagesconsole—sends to the console devicestderr—sends to standard error stream

Levela message severity value level

predefined values:

■ FATAL■ ERROR■ WARNING

■ INFORM■ VERBOSE


Configuring a destination for cell trace output

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:

■ 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.

Modulea name of module, each of which corresponds to a particular category of information, such as filtering or configuration; values are as follows:

■ ACTION■ COLLECT■ COLLMAP■ CONFIG ■ CONTROL■ DATAPROC■ DBDATAID■ DBEVTID■ DBEVTTM■ EVTLOG■ EVTPROC■ EXPORT■ FILTER

■ 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 keyword that enables access to a sublevel or category of messages for a module

Switch switch name

a You can also specify ALL or * (wildcard) for these parameters.

Table 11 Trace configuration file parameters (part 2 of 2)



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.

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.

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.



To enable sending cell trace information to another cell, you must

■ 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:

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.

ENUMERATION MC_LOG_LEVEL 10 VERBOSE 20 INFORM 30 WARNING 40 ERROR 50 FATALEND

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


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

This setting specifies that events must be generated for messages from all modules, of all but the VERBOSE level.

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:

Event processing errors

When an error occurs during the processing of an event, the cell’s trace displays an error message. It also generates an internal event of class MC_CELL_PROCESS_ERROR, with the slots listed in Table 12.

TraceEvents=ALL:ALL,-ALL:VERBOSE

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.

propagate PropTraceEvents: MC_CELL_LOG_MSGto CentralAdminCell

END


Automatic notification of trace configuration changes

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:

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:

■ no—indicates disabling■ stderr—indicates redirection to the standard error stream ■ console—indicates redirection to the console terminal

Interpreting cell execution failure codesWhen 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.

Table 12 MC_CELL_PROCESS_ERROR slots

Slot Data

error_code the error number

error_goal the part of the processing command that has the error

error_message an error description message

error_source the position in the rule source where the error occurred

event the mc_ueid of the event that was being processed

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


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 BMC Impact Manager exit codes

Code Description

1 invalid command line options used

2 bad home directory specification through option -l

3 no home directory could be determined

4 specified home directory is invalid

5 internal initialization failure

16 tracing configuration failed

17 system process handling module initialization failure

19 logging facility initialization failure

27 service control module initialization failure

29 Knowledge Base load failed

37 message handling module initialization failure

39 internal object initialization failure

47 event processing module initialization failure

49 saved state reload failed

57 query handling module initialization failure

59 service activation failed

67 internal object module initialization failure

69 metrics initialization failed

77 data processing module initialization failure

79 metrics activation failed

97 service setup failed


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:

■ 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.


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

■ SIM_COMPONENT_CHANGE■ SIM_COMPONENT_DELETE

■ SIM_COMPONENT_OVERWRITE

■ SIM_RELATIONSHIP_CHANGE■ 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.

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 following slots are reported:

■ 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.

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.

NOTE Refer to the BMC Impact Solutions: Knowledge Base Development Reference for mposter examples that show how to register for notification events.



4 Right-click SIM_NOTIFICATION_REGISTRY.

5 Select New.

6 Fill in the editable fields in the SIM_NOTIFICATION_REGISTRY dialog box.

Table 14 SIM_NOTIFICATION_REGISTRY dialog box fields (part 1 of 2)

Field Description

mc_udid populated automatically

client_data 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

■ 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

■ 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



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.

notifications_at_registration instructs the cell whether or not to send the current component states at the moment of registration

■ 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.

Table 14 SIM_NOTIFICATION_REGISTRY dialog box fields (part 2 of 2)

Field Description


Trouble-shooting BMC Impact Manager

Trouble-shooting BMC Impact Manager

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:

■ 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.

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 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.


C h a p t e r 2
2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66About the unified Event Management and Service Impact Management

Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Knowledge Base index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Managing a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Integrating a unified KB with pre-7.2 cell definitions . . . . . . . . . . . . . . . . . . . . . . . 70Creating a new production or test Knowledge Base—mcrtcell . . . . . . . . . . . . . . . 71Importing Knowledge Base information into a cell—mkb . . . . . . . . . . . . . . . . . . . 71Compiling a Knowledge Base—mccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Loading a Knowledge Base into a running cell—mcontrol . . . . . . . . . . . . . . . . . . 72Implementing changes to a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Versioning a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


Knowledge Base structure

Knowledge Base structureThe 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.

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 cell’s 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:

■ 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.

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.



■ 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.

Figure 10 lists the directory structure for a Knowledge Base.

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.

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 Knowledge Base directory structure

kb\bin

\A\h1\l2\p4\s5\w4

\classes\collectors\data\lib\records\rules



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:

■ A—independent, all UNIX, or non-Windows■ h1—HP-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:

■ sim.wic—contains the compiled implementation of primitives and functions that are loaded by the cell at startup

■ sim_decl.wic—contains 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.



Table 16 lists the file extensions and directory location for the each of the components contained in a KB.

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 Knowledge Base file extensions and directories

Component File extension Directory

event classes .baroc kb\classes

data classes .baroc kb\classes

data instances .baroc kb\data

global records .baroc kb\records

rules .mrl kb\rules

collectors .mrl kb\collector

action executables .mrl kb\bin

service model class definitions .baroc kb\classes

interface classes .baroc kb\classes

scripts and programs not applicable kb\bin\platform

Table 15 Knowledge Base subdirectories (part 2 of 2)

Knowledge Base subdirectory Description


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:

■ manifest.kb—serves 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.

■ .load—serves 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.

■ .loadwic—Before 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.

Managing a Knowledge BaseTo 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.”

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.

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.


Creating a new production or test Knowledge Base—mcrtcell

1 Create a new cell using the mcrtcell CLI with either the -ae or -as option.

2 Copy the modifications or extensions you’ve made in old cell’s KB to the new cell’s 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 Base—mcrtcell

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 cell—mkb

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.”

Compiling a Knowledge Base—mccomp

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.”

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.


Loading a Knowledge Base into a running cell—mcontrol

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.

Loading a Knowledge Base into a running cell—mcontrol

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 cell’s 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

■ 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 modules—Version information is provided for each logical module that you identify in the KB.

NOTE The TraceRuleLevel parameter in the mcell.conf file must be set to 2 for rules tracing to occur.


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:

The mccomp command compiles the @kbversion annotations into the KB object files and includes the following information about each source file in the KB:

■ 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

@kbversion( [ ModuleName , ] VersionID )

Variable Description

ModuleName 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.


Retrieving KB version information in rules

KB versioning example

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.

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.

@kbversion( HelpDesk , '1.2.01' )

mgetinfo -n cellName [-v] kbmodules|kbsources

Argument Returned results

kbmodules list of KB modules with version information

kbsources list of KB source files with compiler version information



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 2155286027.3.00 1332814 27-Jan-2009 collectors/mc_bystatus_collectors.mrl 86828767565197.3.00 1332814 27-Jan-2009 collectors/mc_bylocation_collectors.mrl 26731552570027.3.00 1332814 27-Jan-2009 collectors/mc_evr_collectors.mrl 171931926774887.3.00 1332814 27-Jan-2009 collectors/bii4p_collectors.mrl 1861 720695697.3.00 1332814 27-Jan-2009 collectors/mc_sm_collectors.mrl 1351 34386653857.3.00 1332814 27-Jan-2009 collectors/catchall_collector.mrl 38134257945287.3.00 1332814 27-Jan-2009 rules/mc_startup.mrl 578 23377231647.3.00 1332814 27-Jan-2009 rules/im_internal.mrl 36351 41742895387.3.00 1332814 27-Jan-2009 rules/mc_intevt.mrl 3115 19305675667.3.00 1332814 27-Jan-2009 rules/mc_mccs.mrl 2296 25713088927.3.00 1332814 27-Jan-2009 rules/ips.mrl 2333 24991851207.3.00 1332814 27-Jan-2009 rules/mc_sm_start.mrl 1196 925438717.3.00 1332814 27-Jan-2009 rules/mc_sm_associate.mrl 3389 33764654547.3.00 1332814 27-Jan-2009 rules/mc_sm_maintenance.mrl 1885 7971957427.3.00 1332814 27-Jan-2009 rules/mc_sm_elect.mrl 1055 40132853707.3.00 1332814 27-Jan-2009 rules/mc_sm_attach.mrl 1943 15582827387.3.00 1332814 27-Jan-2009 rules/mc_sm_shadow.mrl 3781 42834880667.3.00 1332814 27-Jan-2009 rules/mc_sm_slm.mrl 4512 16314026207.3.00 1332814 27-Jan-2009 rules/bii4p.mrl 10473 18812932237.3.00 1332814 27-Jan-2009 0 10737063327.3.00 1332814 27-Jan-2009 bin/mc_actions.mrl 1304 39084432037.3.00 1332814 27-Jan-2009 bin/im_operations.mrl 16424 26398315497.3.00 1332814 27-Jan-2009 bin/sim_operations.mrl 3992 3834546431


C h a p t e r 3
3 Managing the BMC Impact Administration server
This chapter presents the following topics:

Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 81

Guidelines for manual edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Defining permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Full Access role permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Adding customized role/permission mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 87File-based authentication: updating user information. . . . . . . . . . . . . . . . . . . . . . . 91Adding role names to the cell’s KB definition files . . . . . . . . . . . . . . . . . . . . . . . . . 93Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . 93Synchronizing cell information with BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . 95Updating cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Defining client logging for the iadmin script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Customizing colors for severities, statuses, and priorities . . . . . . . . . . . . . . . . . . . 99IAS Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Customizing the IAS thread pool handling IAS Clients . . . . . . . . . . . . . . . . . . . . 100Defining standalone, primary, and secondary BMC Impact Administration

servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Defining a failover configuration for the Impact Administration cell. . . . . . . . . 105

Transaction and trace logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Configuring BMC Impact Administration server to support remote actions . . 107Configuring Lightweight Directory Access Protocol for BMC Impact

Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Problem: Cell_info.list synchronization error during manual configuration of an IAS failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


Configuration files

Configuration filesEnd users can configure the following IAS file listed in Table 17. These files are located under the IMPACT_SOLUTIONS_HOME/server/conf directory.

Command line interfaceThe 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.

Table 17 Configurable IAS files

IAS file Description

ias.properties contains required and optional configuration parameters for the IAS. This file is loaded whenever IAS starts or restarts.

user_definitions.xml defines user information for file-based authentication

ldap_configuration.xml defines LDAP server information for LDAP authentication

role_permissions.xml enables you to add customized role/permission mappings

group_roles.xml contains the group/role mappings

cell_info.list contains identifying information about each cell that is connected to the IAS

cmdb.properties specifies information for the IAS and BMC Atrium CMDB connection

server_logging.properties defines the logging properties for the server

client_logging.properties defines the logging properties for the client when you use the iadmin command

color.properties defines different color properties for severity, status, and priority

credential_repository.xml stores the authentication credentials used for remote execution actions

ldap_configuration_query.xml defines LDAP server information used by IAS query option –tlq

default_role_permissions.xml defines the view and edit permissions for each tab view and menu option in BMC IX

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

You can use the iadmin command to manage the following configuration files:

■ 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 iadmin options (part 1 of 2)

Option Description

-ac add a cell to the cell_info.list file and register the cell with the BMC Impact Administration Server

-mc modify a cell

-dc delete a cell

-lc list connected cells

-aru add a new user

-mru modify the user group or groups to which an existing user belongs

-dru delete an existing user

-lru list all the users

-ar add a new mapping between a role and permissions

-dr delete an existing role/permissions mapping

-lr list all the roles

-mr modify the mapping between a role and a list of permissions

-ag add a new mapping between a group and a list of roles

-dg delete a group/role mapping for a specified group

-lg list all the groups

-mg modify the mapping between a group and a list of roles

-acr add a credential record to the credential_repository.xml

-mcr modify a credential record

-dcr delete a credential record

-lcr list all credential records

-cp change the current password of an existing user. Requires that you enter the current password


Impact Administration cell

When using iadmin to manage files, remember to:

■ 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:

■ 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 cellThe default mcell.dir file of the IAC is as follows:

-rp reset the password of an existing user. In this option, you enter the new password only. You do not enter the current password

-reinit [fullsync | actions]

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 server’s 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

-sync in an high availability setup, synchronizes the secondary server before the expected synchronization interval

-tlq 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

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.

password=”$able_baker”

cell Admin mc hostName:1827 cell IAC mc hostName:1827

Table 18 iadmin options (part 2 of 2)

Option Description


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:

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.

cell cellName mc hostName:1828 cell IAC mc hostName:1827


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.

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.

NOTE When manually editing files to enable a high availability configuration, you must follow the special guidelines outlined in the topic“Defining a failover configuration for the Impact Administration cell” on page 105.


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:

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.

....<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.

Table 19 BMC Impact Explorer user group mapping to functionality (part 1 of 4)

Perm

issi

on (P

) or

Righ

t (R

)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y

Adm

ins

Ope

rato

rs

Supe

rvis

ors

BMC Impact Explorer R Dashboards-Create,

update, and delete all profiles

Edit X X X

R Dashboards-Create and delete own profiles only

Edit X X X X X

R Dashboards (SIEM) View X X X X X X



R Dashboards (CIEM) View X X X X X X X X X X

R Events tab View X X X X X X X X X X

R Configuration–Edit Relationship View

Edit X X X X X X X X X

R Configuration–Edit Personal Filters


R Configuration–Edit Personal Attribute (Slot) Orders


R Configuration–Edit Personal MetaCollectors

Edit X X X X X X X

R Configuration–Edit Global Event Filters

Edit X X X X X X

R Configuration–Edit Global Attribute (Slot) Orders

Edit X X X X X X

R Configuration–Edit Impact Manager Group on Impact Manager Configuration window

Edit X X X X X X X X X X

R Events tab-Show Impact Administration cell

Edit X X X

R Events tab–Jump from an Event to Its Services Impacted View

Edit X X X X X

R Events tab–Reopen Events

Edit X X X X


Perm

issi

on (P

) or

Righ

t (R

)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y

Adm

ins

Ope

rato

rs

Supe

rvis

ors



R Events tab–Event Operation Supervisor Privileges (for example, close events owned by someone else)

Edit X X X X

R Events tab–Assign Events

Edit X X X X

R Events tab–Add Image View

Edit X X X X X

R Events tab–Delete Image View

Edit X X X X X

R Services tab View X X X X X X

R Services tab–Search for Service Components

Edit X X X X X

R Services tab-Create and delete components

Edit X X X X

R Services tab–Event List View of a Service Component

View X X X X X X

R Services tab–Edit My Services Navigation Tree

Edit X X X X X

R Services tab-Create, Edit, Delete Relationship between components

Edit X X X X X

R Services tab–Set or Remove Manual Status (of a component) Action

Edit X X X X X

Table 19 BMC Impact Explorer user group mapping to functionality (part 3 of 4)Pe

rmis

sion

(P) o

r Ri

ght

(R)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y

Adm

ins

Ope

rato

rs

Supe

rvis

ors


Full Access role permissions

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.

R Services tab–Set or Clear Maintenance Mode (of a Component) Action

Edit X X X X X

R Administration tab View X X X X X

R Timeframes Edit X X X X X

R Administration tab: all actions

Edit X X X

R Infrastructure Management subtab

Edit X X X

R Infrastructure Management subtab: all actions

Edit X X X

R Alias Formula Editor Edit X X X

R Remote Actions: Create remote actions

Edit X X X

R Send Events to Cell Edit X X X

R Delete Events to Cell Edit X X X


Perm

issi

on (P

) or

Righ

t (R

)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y

Adm

ins

Ope

rato

rs

Supe

rvis

ors


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:

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:

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:

com.bmc.sms.ixs.role.permission.mapping=role_permissions.xml

iadmin -ar role=”Test”:permissions=”services_tab_delete_component”

iadmin -mr role=Test:permissions=”services_tab_view_and_access”


Defining group roles

To delete an existing role/mapping permission

You can delete an existing role in a user-defined roles/permissions file.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dr option, as in the following example:

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:


The ias.properties file specifies the default group roles, which are identified in the group_roles.xml file:

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.

NOTE If the role to be deleted only exists in the default file, then an entry is added to the user-defined 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.

iadmin -dr role=Test

iadmin -lr

com.bmc.sms.ixs.group.role.mapping=group_roles.xml


You can update user groups and roles and create new ones by editing the group_roles.xml file, shown below:

Table 20 Groups and roles

Group Role

Full Access Full Access. Has write access to all features

Read Only Read Only. Has read-only access

Service Administrators Service Administrators. Has write access to all features

Service Managers Service Managers

Service Managers - Senior Service Managers - Senior

Service Operators Service Operators

Service Operators - Senior Senior Service Operator

Admins Full Access, Service Administrators

Operators Service Operators, Senior Service Operators

Supervisors Service Manager, Senior Service Managers

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.

<!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>


To add a new group with mapping roles

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:

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:

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:

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:

NOTE If you’re 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.

iadmin -ag group=”NewGroup”:roles=”Role”

iadmin -mg group=”Service Administrators”:roles=”Service Administrators”,“Service Operators”

iadmin -dg group=”Service Operators”

iadmin -lg


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

■ 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 user’s 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>



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:

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:

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:

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:

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.

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.

iadmin -mru loginId=qa:usergroups=”Read Only”

iadmin -dru loginId=qa

iadmin -cp loginId=qa:oldPassword=”qa”:newPassword=”bsm”


Adding role names to the cell’s 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:

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:

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.

Adding role names to the cell’s KB definition files

After adding a new role name, you must add this role name to the cell’s KB definition files for the role to be effective. See “To add the role name to the cell’s 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.

iadmin -rp loginId=JoeUser:newPassword=”bsm”

iadmin -lru

# admin password used internally for different components (such as BIP) talking to IAScom.bmc.sms.ixs.admin.password=e1KYemjVrpcnIw52M4m2tScjD3Yziba1JyMOdjOJtrUnIw52M4m2tScjDnYziba1JyMOdjOJtrUnIw52M4m2tQ== (encrypted)

OR

com.bmc.sms.ixs.admin.password=Nwadmpwd23


Receiving synchronized data from the BMC Portal

The BMC Portal connects with IAS through IAS’s 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 groups—for example, ldapG1.bmc.com and ldapG2.bmc.com—then 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.


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:

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.

......# "true" if this IAS will synchronize with the CMDB server.com.bmc.sms.ixs.cmdb.enable.sync=false

# host name for AR servercom.bmc.sms.ixs.cmdb.host.name=localhost

# port number for AR servercom.bmc.sms.ixs.cmdb.port.number=0

# user id for AR servercom.bmc.sms.ixs.cmdb.user.id=Demo

# password for AR servercom.bmc.sms.ixs.cmdb.password=


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:

Each cell entry contains the following information:

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:

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"

Table 21 Cell entry format in cell_info.list

Entry Description

cell 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.

name matches the name in the mcell.dir file of the cell server.

key The default value is mc.

primaryHost system where the cell resides. It can be an unqualified or fully qualified host name, or an IP address.

primaryPort primary port number of the cell between 1000 - 65535.

failoverHost optional. If this is an HA pair, then enter the system name where the secondary cell resides.

failoverPort optional. If this is an HA pair, then enter the failover port number between 1000 - 65535 that the secondary cell uses.

environment Production or Test.

usergroups 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.

iadmin -ac name=testCell:key=mc:primaryHost=moondog:primaryPort=1828:failoverHost=suncat:failoverPort=1828:environment=Production:usergroups=*



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:

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:

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:

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:

cell IAC mc myComputer.adprod.bmc.com:1827

iadmin -mc name=testCell:failoverHost=null:environment=Test

iadmin -dc name=testCell

iadmin -lc


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 server’s activity. You can manually edit the

■ 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:

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.

Table 22 Server logging properties

Property Description

.level 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 the maximum size of each log file in bytes. The default is 5 million bytes (about 5 MB).

java.util.logging.FileHandler.count 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.


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.

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:

■ 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.

NOTE These changes to the color properties do not affect the icon colors.


Customizing the IAS thread pool handling IAS Clients

Code examples follow that show sample IAS Status Monitoring configuration parameters.

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 23 IAS status monitoring properties


com.bmc.sms.ixs.appAuditLogEnable Used to enable or disable the status monitoring audit log. The supported values are true or false. The default is true.

com.bmc.sms.ixs.appAuditLogFilename Specifies the log file name and its format. "%g" the generation number to distinguish rotated logs.

com.bmc.sms.ixs.appAuditLogLimit Specifies an approximate maximum amount to write (in bytes) to any one file.

com.bmc.sms.ixs.appAuditLogFileCount Specifies how many output files to cycle through, that is, the number of files to use.

com.bmc.sms.ixs.applicationAuditInterval Specifies the audit frequency time interval in minutes.

# IAS Status Monitoring Enablecom.bmc.sms.ixs.appAuditLogEnable=true

# Status Monitoring Audit File Namecom.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 Countcom.bmc.sms.ixs.appAuditLogFileCount=10

# Status Monitoring Audit Log Intervalcom.bmc.sms.ixs.applicationAuditInterval=60

Table 24 IAS thread pool properties (part 1 of 2)


com.bmc.sms.ixs.iasclient.threadManager.core_Pool_Size

Specifies the Core ThreadPool Size. It indicates the number of threads to keep in the pool even if they are idle (Minimum Thread Pool size).

com.bmc.sms.ixs.iasclient.threadManager.max_Pool_Size

Specifies the Maximum ThreadPool Size. It indicates the maximum number of threads to allow in the thread pool.


Defining standalone, primary, and secondary BMC Impact Administration servers

Code examples follow that show sample IAS ThreadPool configuration parameters.


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.

com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time

Specifies the maximum time that excess idle threads will wait 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.keep_Alive_Time_Unit

Specifies the time unit for the keepAliveTime argument. The 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.

# Core ThreadPool Sizecom.bmc.sms.ixs.iasclient.threadManager.core_Pool_Size=10

# Max ThreadPool Sizecom.bmc.sms.ixs.iasclient.threadManager.max_Pool_Size=50

# Keep Alive Timecom.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time=1000

# Keep Alive Time Unitcom.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.

Table 24 IAS thread pool properties (part 2 of 2)




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:

B On the secondary IAS, go to the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file and set the parameters as mentioned below:

2. Restart the primary and secondary IASs.

com.bmc.sms.ixs.server.mode=primarycom.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

com.bmc.sms.ixs.server.mode=backupcom.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

NOTE If you define a standalone Master IAS as an HA pair, you must also define its accompanying administration cell as an HA pair.



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:

■ 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.

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.

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).

Table 25 IAS synchronization properties (part 1 of 2)


com.bmc.sms.ixs.transaction.history 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.

com.bmc.sms.configService.keepBackupFile for standalone and failover definitions. Indicates whether the IAS maintains a backup copy (.bak extension) when it writes a file. The default is false.

com.bmc.sms.ixs.sync.interval for failover definitions. Interval in minutes between synchronization requests from a secondary server to a primary server. The default is 15 minutes.



iadmin reinit/sync options

You can use the following iadmin reinit/sync options to restart a server, copy the primary server’s 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

■ 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 server’s 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

com.bmc.sms.ixs.primary.server 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.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.

Table 25 IAS synchronization properties (part 2 of 2)



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 server’s 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:

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.

Table 26 mcell.dir entries for a failover pair of Impact Administration cells

Primary IAC on Host 1 Secondary IAC on Host 2

cell Admin mc host1:1827 host2:1827

cell IAC mc host1:1827 host2:1827

cell Admin mc host1:1827 host2:1827

cell IAC mc host1:1827 host2:1827


Transaction and trace logs

Transaction and trace logsThe IAS automatically generates the log files listed in Table 27.

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:

Advanced tasksThis 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).

Table 27 IAS log files

File name Description

transaction.log stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for file synchronization

record_transaction.log stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for record synchronization

ias0.log 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.

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


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:

For the UNIX-based operating systems, the following defaults are used:

windows.execute.command=com.bmc.sms.marimba_cas_tools.PsExecTaskwindows.putfile=com.bmc.sms.marimba_cas_tools.PsExecTaskwindows.getfile=com.bmc.sms.marimba_cas_tools.PsExecTask

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTaskunix.putfile=com.bmc.sms.marimba_cas_tools.SCPTaskunix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask



You can specify multiple protocol values for each of these properties, as shown:

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.

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:

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.

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

NOTE Make sure that you’re familiar with security protocols before modifying these settings.

all.execute.command=com.bmc.sms.marimba_cas_tools.SSHTaskall.putfile=com.bmc.sms.marimba_cas_tools.SCPTaskall.getfile=com.bmc.sms.marimba_cas_tools.SCPTask


Configuring Lightweight Directory Access Protocol for BMC Impact Administration server

The relevant section of the centraladmin-strings.properties file is depicted below:

To enable Telnet and ftp, modify the properties as follows:

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.

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTaskunix.putfile=com.bmc.sms.marimba_cas_tools.SCPTaskunix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask,com.bmc.sms.marimba_cas_tools.TelnetTaskunix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTaskunix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask



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”:

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:

The user groups defined in the user_definitions.xml file are mapped to roles for the initial log-in and 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:

6 Close the file.

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.

#-----------------------------------------------------------------# 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

com.bmc.sms.ixs.allow.local.groups.for.ldap=true

NOTE If you leave the default value “false,” then only roles that are mapped to the user’s LDAP groups are used for user authorization.

com.bmc.sms.ixscomm.authentication.ldap.LdapLoginModule Sufficient;



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

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.

<?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>[email protected]</connectionUserName> <useridAttribute>sAMAccountName</useridAttribute> <useSSL>false</useSSL> <memberOfAttribute>memberOf</memberOfAttribute> <userSearchFilter>(objectClass=organizationalPerson)</userSearchFilter> <groupSearchFilter/> <connectionPassword encrypted="true">fisSCap4ZhOLOUENWPLe==

</connectionPassword> </ldap>......</ldapList>

Table 28 LDAP configuration parameters (part 1 of 2)

LDAP parameter Description

host 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 port number by which to connect to the LDAP server. Normally the nonsecure port number is 389. The secure (SSL) port number is 636.

version LDAP version number. The most recent version is version 3.



4 After completing your changes, restart the IAS.

■ 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 user’s 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.

baseDN 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.

connectionUserName login Id that the programs use to connect to the LDAP server.

userIdAttribute attribute in the user entry that contains the login Id.

useSSL indicates whether LDAP authentication is using OpenSSL.

memberOfAttribute attribute in the user entry that specifies whether the user belongs to certain user groups.

userSearchFilter 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))”

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=groupOfUrls))”

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.

Table 28 LDAP configuration parameters (part 2 of 2)

LDAP parameter Description



To add a new user group with mapping roles

From the/bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:

The new entry would look similar to the following in the group_roles.xml file:

To add the role name to the cell’s 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.

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:

■ 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.

NOTE If you’re 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.

iadmin -ag group=”NewGroup”:roles=”Role”

<entry key="nameofUserGroup">IAS_defaultRoleName</entry>

NOTE If the ACL is empty, then every group has access.



The following code examples show sample modifications to each file:

biip4p_collectors.mrl

catchall_collector.mrl

mc_bylocation_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

collector 'All Events' :{ r['Service Administrators',’nameofUserGroup’] w['Service Administrators',’nameofUserGroup’] x['Service Administrators',’nameofUserGroup’]}

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’]}:



mc_bystatus_collectors.mrl

mc_evr_collectors.mrl

You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.

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

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’]

}:EVENTwhere [mc_relation_source: != '']create $THIS.CLASSEND



mc_sm_collectors.mrl

You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.

mcxpcoll.mrl

self_collector.mrl

collector MC_SMC_Events:{r['Full Access', 'Service Administrators'’nameofUserGroup’]w['Full Access', 'Service Administrators'’nameofUserGroup’]x['Full Access', 'Service Administrators'’nameofUserGroup’]

}END

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

collector 'By Location'.*.*.*.*.*:PATROL_EV where [p_application: not_equals '']create $THIS.p_applicationEND

{r[‘nameofUserGroup’]w[‘nameofUserGroup’]x[‘nameofUserGroup’]}

collector self :{ r['Full Access', 'Read Only',‘nameofUserGroup’] w['Full Access', ‘nameofUserGroup’] x['Full Access', ‘nameofUserGroup’]}END



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.

An example of a group name assignment to a specific event management action is shown below:

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 cell’s KB using the mccomp command, as in the following example:

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:

Table 29 Event operations

Event operation Group names

Acknowledge Service Administrators, Service Operators - Senior, Service Operators

Take Ownership Service Administrators, Service Operators - Senior, Service Operators

Decline Ownership Service Administrators, Service Operators - Senior, Service Operators

Close Service Administrators, Service Operators - Senior, Service Operators

Assign to Operation Service Administrators, Service Operators - Senior

Set Priority Service Administrators, Service Operators - Senior

Reopen Service Administrators, Service Operators - Senior

action im_operations.Acknowledge: { ['Service Administrators','Service Operators - Senior','Service Operators',‘nameofUserGroup’] }

mccomp -n cellName | manifestKBFilePath

iadmin -tlq group


Troubleshooting

To authenticate a specific LDAP user, enter the user name and password, as in the following example:

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.

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

■ 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

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.

iadmin -tlq username=<string>:password=<string>

LDAP property Description

com.bmc.sms.ixs.search.time.limit the maximum time for an LDAP query to retrieve data from the LDAP server. The default is 5000 milliseconds.

com.bmc.sms.ixs.search.ldap.group 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.



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:

2 Copy the cell entry to a text editor, such as Notepad. In this example, the copy would look as follows:

3 Manually add the host cell entry from the secondary server to the primary server’s cell_info.list file using the iadmin -ac command, as in the following example:

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 server’s 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.

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. All rights reserved.

List BMC Impact Managers:

pun-sms-sun31 mc pun-sms-sun31.bmc.com:1828 Production *

pun-sms-sun31 mc pun-sms-sun31.bmc.com:1828 Production *

iadmin -ac name= pun-sms-sun31:key=mc:primaryHost=pun-sms-sun31:Port=1828:environment=Production:usergroups=*


C h a p t e r 4
4 Managing the BMC Impact Portal
This chapter describes how to configure the BMC Impact Portal and contains the following topics:

Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . 123Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . 124Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . 130Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . 132smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . 133smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . 134internal.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136


Accessing the BMC Impact Portal

Accessing the BMC Impact PortalCommunication 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 browser’s address box, type the BMC Portal URL address using the following syntax:

https://computerName:portNumber

■ computerName—represents the host name of the BMC Portal server

■ portNumber—represents the port number assigned to the BMC Portal; the default port number is 443

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.

Starting and stopping the BMC PortalThe 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.

NOTE The Transport Layer Security (TLS) protocol is used to secure communication between the BMC Portal Application Server and the Web browser.

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 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:

■ 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:

■ 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:

■ ./BMCPortalAppserver stop

■ ./BMCPortalAppserver start


Configuration tasks for BMC Impact Portal

Configuration tasks for BMC Impact PortalThis 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


Configuring Events Table columns

3 Save the application.properties file.

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


2 Edit the appropriate events table column as shown in Table 30 on page 125.



For more information on this file, see “smsIwc/application.properties file and parameters” on page 133.

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.

Table 30 Event Table column default values

Column heading Description

status event status of the selected component

mc_priority value of the possible priorities of the event (values 5, 4, 3, 2, or 1)

severity value of the possible severities of the event (unknown, ok, info, warning, minor, major, or critical)

date_reception date and time the event was received

owner_name name of the owner of the component

msg relevant information related to the event

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.


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


2 Edit the appropriate status table column as shown in Table 31.



For more information, see “smsIwc/application.properties file and parameters” on page 133.

Table 31 Status table column default values

Table Configuration file listing Default columns

Providers com.bmc.sms.iwc.status.table.providers last_status_modificationdescriptionowner_nameowner_contact

Providers(dashboard view)

com.bmc.sms.iwc.status.table.providers. small none

Consumers com.bmc.sms.iwc.status.table.consumers last_status_modificationdescriptionowner_nameowner_contact

Consumers(dashboard view)

com.bmc.sms.iwc.status.table.consumers. small none

Causes com.bmc.sms.iwc.status.table.causes last_status_modificationdescriptionowner_nameowner_contact

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.


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


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:

■ 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 type Parameter Description

Report Goals com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_AVAIL

Availability report goal line, expressed as a percentage. Default value is 90.0%.

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTTR

Mean Time to Repair goal line, expressed in milliseconds. Default value is 300000 (5 minutes).

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBF

Mean Time Between Service Failures goal line, expressed in milliseconds. Default value is 172800000 (2 days).

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBSI

Mean Time Between Service Incidents goal line, expressed in milliseconds. Default value is 172800000 (2 days).

Retention Age com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_STATUS_EVENT

The number of days Status tab data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_AVAIL

The number of days Availability data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTTR

The number of days Mean Time to Repair data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBF

The number of days Mean Time Between Failure data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBSI

The number of days Mean Time Between Service Incidents data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.EG_EVENT

The number of days event data will be retained in the BMC Datastore. Default value is 395.


Configuring the number of events displayed

Table 33 Report parameters (internal.properties) file

3 Save the application.properties and internal.properties files.



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


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.

Parameter type Parameter Description

Report Schedule com.bmc.sms.reportSummarizer.scheduler.frequencyHours

The frequency, in hours, that the report information is summarized. Default value is 1.

com.bmc.sms.reportSummarizer.scheduler.delaySeconds

The number of seconds that will be added to the starting hour for every scheduled summarization time. Default value is 30.

com.bmc.sms.reportSummarizer.scheduler.isStartingNextHour

Determines whether or not the setting of 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.



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


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.




Setting up Image Views

To configure the general properties displayed


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:

■ 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.



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.

3 Modify the connection properties.


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:

■ BMC Impact Portal■ BMC Impact Service Model Editor■ BMC Impact Publishing Server

CellName.timeout = 30CellName.reconnect_attempts = 5CellName.reconnect_frequency = 30CellName.polling_frequence = 3600CellName.encryption = on


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 application.properties file in smsIwc directory (part 1 of 2)

Filename application.properties in the ..smsIwc folder

File path BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsIwc

Descriptioncontains the general BMC Impact Portal configurations for component properties and user interface presentation

Parameter name Description Default value

com.bmc.sms.iwc.ui.recentitems.maxsize

sets the maximum number of objects that can display 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.

5

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 the Configure tab for selected components

Refer to “Configuring the general properties displayed” on page 130 for more information.

See the application.properties file for more information.

com.bmc.sms.iwc.event.table 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.


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


smsConsoleServer/application.properties file and parameters


Table 35 describes the application.properties file in the smsConsoleServer directory and its parameters.

com.bmc.sms.iwc.status.table.providerscom.bmc.sms.iwc.status.table.consumerscom.bmc.sms.iwc.status.table.causescom.bmc.sms.iwc.status.table.existinggroupcom.bmc.sms.iwc.status.table.causal.componentscom.bmc.sms.iwc.status.table.components.small

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.


com.bmc.sms.iwc.event.table.minimumeventscom.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: 5maximum: 50

Table 35 application.properties file in smsConsoleServer directory (part 1 of 3)

Filename application.properties in the ..smsConsoleServer folder

File pathBMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsConsoleServer

Description contains the configurations for report scheduling, report goals, and report data retention


com.bmc.sms.configService.dataLocation

defines where the user configuration data is stored no value; the location BOSS_HOME/server/all/data/smsConsoleServer is used

com.bmc.sms.configService.keepBackupFile

if configuration data is changed, defines whether a backup file is saved

false; no backup file is saved

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_AVAIL

sets the value of the goal line for the Availability report as a percentage

90.000%

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTTR

sets the value of the goal line for the Mean Time to Repair (MTTR) report

300000 milliseconds (5 minutes)

Table 34 application.properties file in smsIwc directory (part 2 of 2)



com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBF

sets the value of the goal line for the Mean Time Before Failure (MTBF) report

172800000 milliseconds(2 days)

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBSI=172800000

sets the value of the goal line for the Mean Time Before Service Impact (MTBSI) report. Goal line value is expressed in milliseconds

172800000 milliseconds(2 days)

cellName.timeout sets the timeout value for data queries by the BMC Impact Portal to the specified cell. The timeout value is measured in seconds

30 seconds

cellName.reconnect_attempts 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_frequency sets the polling cycle, measured in seconds, for the BMC Impact Portal reconnection attempt to the specified cell

30 seconds

cellName.polling_frequency sets the polling cycle, measured in seconds, for the BMC Impact Portal data query attempt to the specified cell

1800 seconds

<cellname>.encryption sets whether is encryption is enabled (off or on) for the connection with the specified cell

on

com.bmc.sms.icon.webdir defines the path in which the icon images for service model components are maintained

/smsConsoleServer/images/objects/

com.bmc.sms.event.maxDelayedHours

defines the maximum number of hours an event can be delayed and will still be processed

24 hours

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

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

com.bmc.sms.service.os.unrestricted

sets whether the Object Store communication service should run in unrestricted mode when connecting to the Remedy server

true



internal.properties file and parameters

Table 36 describes the aggregator.properties file and its parameters.


Table 37 describes the internal.properties file and its parameters.

com.bmc.sms.service.os.restrict.read.access

sets whether the Object Store communication service filters are read-only objects

true

com.bmc.sms.service.os.filtersim

sets whether the Object Store communication service filters classes and attributes that are marked SIM=false

true

com.bmc.sms.remedy.serverHostName

identifies the host computer on which the BMC Remedy Action Request System host resides

Action Remedy server host name

com.bmc.sms.remedy.serverPortNumber

lists the port number on which BMC Remedy Action Request System runs

default

Table 36 aggregator.properties file

Filename aggregator.properties


Descriptioncontains the configurations for BMC Impact Portal communications with cells, including port number used for cell communications, encryption key, and encryption enablement


com.bmc.sms.eventaggregator.jserverPortNumber

sets the port number through which the BMC Impact Portal communicates with the BMC IM cell

3783

com.bmc.sms.eventaggregator.jserverEncryptionKey

sets the encryption key used to communicate with the BMC IM cell

mc

com.bmc.sms.eventaggregator.jserverEncryptionEnabled

communication encryption indicator (true or false) true

Table 37 internal.properties file

Filename internal.properties


Description

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





com.bmc.sms.ixs.port.number sets the port number through which the BMC Impact Portal communicates with the Administration Server

3084

com.bmc.sms.ixs.enable.bind.ip sets whether the BMC Impact Portal can bind an IP address on a multi-homed (multi NIC card) system

false

com.bmc.sms.ixs.bind.ip.address specifies the IP address on a multi-homed system to which the BMC Impact Portal is bound

0.0.0.0

Table 37 internal.properties file


C h a p t e r 5
5 Working with Infrastructure Management

Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . 142Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Displaying and understanding the Details and Administer tab data . . . . . . . . . 152Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172How a product component registers and communicates with the IAC . . . . . . . 172Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174


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 Supported application groups (part 1 of 2)

Group Id Name

100 EM_CELL

101 EM_SERVER_1

102 EM_SERVER_2

103 SIM_CELL



104 SIM_SERVER_1

105 SIM_SERVER_2

106 IAC (Impact Administration Cell)

110 BMC Impact Portal Application Server

111 IAS (Impact Administration Server)

112 PS (BMC Impact Publishing Server)

120 Adapter

121 LOG_FILE_ADAPTER122 SNMP_ADAPTER123 WINDOWS_EVENT_ADAPTER124 SYSLOG_ADAPTER125 TCP_ADAPTER126 TELNET_ADAPTER127 UDP_ADAPTER130 IIP7131 IIP3132 IIOVO133 IINNM134 IITIVOLI140 DBGW141 IIARS142 IBRSD

150 BPM151 ARS152 ARS_SD153 CMDB154 BiiZ155 BIM156 SLM157 TM_ART158 TM_RCA159 TM_REM160 EM_Server_Standby

161 SIM_Server_Standby

162 ADAP_SERVER_1163 ADAP_SERVER_2164 ADAP_CELL

Table 38 Supported application groups (part 2 of 2)

Group Id Name


Roles and permissions

Roles and permissions

The following group roles have full write permission to the components and features of the Infrastructure Management subtab:

■ 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.

WalkthroughThis 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 real-time 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.


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.


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.

■ 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.


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.


Packaging support files

5 Edit the file.

6 When you’re done, you can click either of the following:

■ 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 you’re 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.



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.


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.


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 started—for example, you can execute an mcstat command to check the cell’s 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:

■ 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 tasksThis 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.


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 it’s 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 listing for infrastructure management model (part 1 of 2)

Icon 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



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.

BMC Publishing Server

Integration for BMC Remedy Service Desk

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.

Table 39 Icon listing for infrastructure management model (part 2 of 2)

Icon Definition


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.



From the General subtab, you can click Edit Component to open the Edit Service Component dialog in which you can modify the component’s 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.

Table 40 Slot values: Details: General subtab

Slot Description

Editable Here 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.

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: Cell-cellName. The default name for Infrastructure Management is Cell_Admin.

Run State the current state of the object, which helps to determine its status, its icon shape, the icon’s 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.

Role indicates whether a component, such as a cell server or IAS, is standalone or, in an HA pair, either primary or secondary.

Cell Type identifies a selected cell component as Service Impact Management, Event Management, Impact Administration, or Integration.

Cell Server 1 for a selected cell component, the IP address of the standalone cell server or of the primary cell server in an HA pair.

Cell Server 1 Port for a selected cell component, the port number of the standalone cell server or of the primary cell server in an HA pair.

Cell Server 2 for a selected cell component, the IP address of the secondary cell server in an HA pair.

Cell Server 2 Port for a selected cell component, the port number of the secondary cell server in an HA pair.



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.



You can edit any supported configuration file of an infrastructure component. The type of file varies with the component, but the files include:

■ 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 component’s 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.


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:

■ 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 Edit Relationship dialog: field descriptions (part 1 of 2)

Field Description

Component Name name of the selected infrastructure component

Related Component Type

identifies the infrastructure component subtype that has a consumer or provider relationship to the selected component and for which you want to search

Relationships lists the consumer, provider, or both consumer and provider relationships of the selected component subtype and component


Creating logical components

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 component’s 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:

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.

Component identifies the infrastructure object related to the selected component

Direction 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

State identifies current state of the relationship: active or inactive

Type specifies the class that contains the relationship type

Propagation Model identifies the status propagation model used for determining the propagated status from the provider’s main status

Editable indicates whether you can edit the object in BMC IX

Table 42 Edit This Relationship subdialog

Field Description

Consumer/Provider indicator

indicates the directional flow of the relationship between the selected component and the component subtype. You can modify the relationship

Type of Relationship Direct, Increasing, Decreasing, Just_Info, or Just_Warning

Relationship Status Active or Inactive

Status Weight weight (numeric value) of a relationship used while calculating the status using weighted cluster mode

Description Summary description of the relationship

Table 41 Edit Relationship dialog: field descriptions (part 2 of 2)

Field Description


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.

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.

NOTE The names of logically created components do not display in Korean in the graph viewing area while its component object does.

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.


Usage reporting

Usage reporting

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:

■ SIM and BEM management servers■ SIM and BEM standalone cells■ SIM and BEM high availability cells■ integrations

■ BMC Impact Integration for HP Openview Network Node Manager■ BMC Impact Integration for HP Openview Operations■ BMC Impact Integration for BMC Remedy Action Request System■ Integration for BMC Remedy Service Desk■ BMC Impact Integration fro PATROL 3.x■ BMC Impact Integration for PATROL 7.x

You can save and print the report in any of the following formats:

■ 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.

NOTE The File=>Usage Report menu option is only available in the Administration view. It does not display in the Events or Services view.

NOTE By default, users belonging to the user group Full Access, Service Administrators, Service Managers, or Service Managers - Senior can access these reports.


Executing remote actions


You can manage the infrastructure objects from the interface. Select the object, right-click 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.

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.

■ 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 You can connect to remote systems from the Configuration and Support Package subtabs of the Administer notebook tab.

NOTE An IAC cell that is in standby mode is shown in yellow.



■ 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.



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.



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.

■ 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 cell’s configuration.

The Reload => All menu option is the equivalent of the mcontrol command’s 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


2 Select Reload => All.

All configuration files and the KB are reloaded.


2 Select Reload => Knowledge Base.

The KB is reloaded.

To reload the directory


2 Select Reload => Directory (mcell.dir).

The mcell.dir file is reloaded.


Forcing event propagation

To reload cell configuration


2 Select Reload => Cell Configuration.

The configuration files mcell.conf, mcell.propagate, and mcell.modify are reloaded.

To reload trace configuration


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


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


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.


Collecting metrics

Collecting metrics

Use the Metrics Collection menu command to access the commands for working with metrics.

To turn metrics collection off


2 Select Metrics Collection=> Disable.

To reset collection counters


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

■ 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:

Table 43 on page 166 describes the audit log parameters:

TIME_STAMP LOG_LEVEL IAS_USER OS_USER SUB_TYPE:OBJECT ACTION_IDEXPLANATION



Supported component or application types

Infrastructure Management supports the following types in this product version:

Table 43 Audit log parameters

Audit log parameter Description

TIME_STAMP month, day, year, hour, minute, and second that the log entry was created. Uses the format mm/dd/yyyy hh:mm:ss

LOG_LEVEL the severity level of the logged action. Valid values include

■ 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 current BMC IX user name that has logged on and connected with the Impact Administration server

OS_USER user name that logs into the remote host’s operating system. This is the user name under which the action is executed on the remote host

SUB_TYPE 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

OBJECT user-specified value in the Object slot of the component or application on the which remote action is being executed

ACTION_ID 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

EXPLANATION short text description of the logged action

■ EM_CELL ■ SIM_SERVER_1 ■ IBRSD

■ EM_SERVER_1 ■ SIM_SERVER_2 ■ BEM_SERVER_STANDBY

■ EM_SERVER_2 ■ IAC ■ SIM_SERVER_STANDBY

■ SIM_CELL ■ IAS ■ PS

■ PORTAL SERVER ■ ADAPTERS ■ INTEGRATIONS



Sample logs

A sample audit log for a remote startup action on a SIM cell might look as follows:

Similarly an audit log for a remote startup action on an IAS server might look like this:

Sample audit logs for the remote actions of restarting and stopping a SIM server cell follow:

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.

Mon 07/23/2007 16:50:15 INFO iasuser superuser SIM_CELL:PUNE_CELL start_im_windows Executing action

Mon 07/23/2007 16:52:10 INFO iasuser superuser IAS_Server:PUNE_IAS_Server start_IASserver_window Executing action

Tue Aug 14 20:14:06 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 restart_im_WINDOWS Executing action. Tue Aug 14 20:14:40 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 stop_im_WINDOWS Executing action.



After you modify any of the properties in the ias.properties file, you must restart the Impact Administration server.

Table 44 Audit log IAS properties


com.bmc.sms.ixscomm.util.auditLogEnable Boolean true/false value that indicates whether auditing is enabled. The default is true.

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.


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:

■ .dir files■ .conf files■ filter files■ selector files ■ mapping files■ trace files■ trace.conf files

In addition, it contains

■ 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.



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.

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.

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:

The OBJECT_NAME value is taken from the object slot of the selected component. The time stamp is in the format: MMDDYY_HHMMSS.

Table 45 Slots for specifying support files

Slot Description

Additional Support Files full path to other support files that you want to include

Configuration files full path to configuration files (.conf)

Dir files full path to *.dir files, such as mcell.dir or admin.dir

Filter files full path to *.filter files

Map files full path to *.map files

Selector files full path to *.selector files

Trace conf files full path to the *.trace file

Trace files full path to the trace logs

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.

OBJECT_NAME_support_package_TIMESTAMP.zip



UNIX processing note

Under UNIX, it may take several minutes to create a support package. Two causes can contribute to the delay in processing:

■ 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:

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.

Fri Aug 17 12:49:25 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 saveRemoteFile : zip.exe Executing action. Fri Aug 17 12:49:28 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 create_support_package_WINDOWS Executing action. Fri Aug 17 12:49:30 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-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 :slondhe-pun-01 get_file : Test1_support_package.zip Executing action. Fri Aug 17 12:49:33 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 getBinaryFile : Test1_support_package.zip Executing action.


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 ManagementThe 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.

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.

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.


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:

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:

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:

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:

In this example, you create an Admin cell with the name “Admin” and assign it to port number 10011.

mcrtcell -p 2008 -as sparkles_cell

iadmin -ac name=sparkles_cell:key=mc:primaryHost=moondog:primaryPort=2008:failoverHost=suncat:failoverPort=2008:environment=Production:usergroups=*

cell moondog_10 mc moondog.bmc.com:1828cell Admin mc moondog.bmc.com:1827cell sparkles_cell mc moondog.bmc.com:2008 suncat.bmc.com:2008

mcrtcell -aa -p 10011 Admin


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:

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.

Table 46 run_state values for components

run_state value Description

unknown state of the component cannot be determined

active indicates that the cell is the active server component of an HA relationship

unavailable the connection with the component is disrupted or the component is down

started the component is online; unable to determine if it’s the active component in an HA relationship

stopped the component has sent is stopped and has sent a status event indicating that it is stopped

paused the component is in maintenance mode

passive the secondary cell in an HA relationship is in standby mode


Remote actions

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 47 Component state and menu options for a normal or primary cell in a high availability configuration

Menu options

run_state

Start Cell

Server Process

Stop Cell

Server Process

Restart Cell

Server Process

Pause Events Admittance

Resume Events Admittance

Set to Standby

Set to Active

state_unknown Yes

state_active Yes Yes Yes

state_unavailable Yes

state_started Yes Yes Yes

state_stopped Yes

state_paused Yes Yes Yes

state_passive None

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 Component state and menu options for a secondary cell in a high availability configuration

Menu options

run_state

StartCell

Server Process

StopCell

Server Process

RestartCell

Server Process

Pause Events Admittance

Resume Events Admittance

Set to Standby

Set to Active

state_unknown Yes

state_active Yes Yes Yes Yes

state_unavailable Yes

state_started Yes Yes Yes

state_stopped Yes

state_paused Yes Yes Yes

state_passive Yes Yes Yes


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:

■ 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:

■ Start Process■ Stop Process■ Restart Process

For OVO adapter cells, the menu options in the Actions submenu are described as:

■ 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:

Logical components that you add to the Infrastructure Management service model receive no actions.

Table 49 Components and actions

Component Exception

HA cell all actions. The HA cell is the only component that allows the Set to Standby and Set to Active menu options

Impact Administration server (IAS)

receives the Restart action only

Publishing Server receives the Start, Stop, and Restart actions

IBRSD receives the Stop, Start, and Restart options

normal cell receives the Stop, Start, Restart, Pause Events Admittance, and Resume Events Admittance options


C h a p t e r 6
6 Managing the BMC Impact Explorer (BMC IX) console
This chapter describes some aspects on how to configure the BMC Impact Explorer (BMC IX) console and contains the following topics:

Defining property files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Selecting a single BMC IX instance for cross- and web-launching . . . . . . . . . . . . . . . 179Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Configuring display and connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Defining global event severity and priority color values. . . . . . . . . . . . . . . . . . . . . . . 184Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186


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 22 illustrates a file Operator.econ.config created for a user named Operator.

Figure 21 default.econ.config file contents

#Mon Jan 20 17:51:13 CDT 2003toolbar_orientation=0toolbar_layout=Northframework_bounds=444,256,512,384user.region=US

Figure 22 Operator.econ.config file contents

#Wed Feb 05 11:52:22 CST 2003user.region=UStoolbar_orientation=0config_dialog_position_y=191config_dialog_height=520toolbar_layout=Northconfig_dialog_position_x=288config_dialog_width=394framework_bounds=229,259,512,384


Selecting a single BMC IX instance for cross- and web-launching

Selecting a single BMC IX instance for cross- and 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:

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.

<property name =“ix_single_instance” value =”true”/>


Defining console-wide policy files

Figure 23 lists its contents, including the default values for each parameter.

Table 50 default.console_policy.prop parameters


local_action_event_operations controls the tracking of local actions performed against events

default_filter_name specifies the default filter used to display the event list when no view is selected

default_slotorder_name specifies the default slot order used for the event list when no view is selected

eventlist_icon_slots controls the slots shown as icons in the event list (values of hidden slots can be viewed only as icons)

filter_hidden_slots 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.

administration_editor_classes controls the classes (with their subclasses) that are available to the Dynamic Data Editor

administration_editor_acls specifies the ACLs that control access to the Dynamic Data Editor

no_import_slots controls exclusion of slots when exporting

config.save.freq controls the time interval between saves of configuration information (such as window sizes and locations)

ix.servicetree.save.timer controls the time interval between saves of Services View navigation tree information

data_handle_chunk_size

parameters used to manage data-handling actions such as copying, pasting, exporting, and printing

data_handle_sleep_interval

data_paste_chunk_size

data_paste_sleep_interval

users_filter Boolean switch for the AssignTo users’ filter

import_method_new Boolean switch that indicates whether the import is done using the previous method or the new method, where false = previous method

local_action_event_notes (deprecated)a controls creation of notes for events that have local actions performed against them; replaced with local_action_event_operations

a Deprecated parameters remain in version 4.1 and earlier cells. However, the parameters do not exist in newer releases.

remote_action_event_notes (deprecated)a controls creation of notes for events that have remote actions performed against them

status_mod_event_note (deprecated)a controls creation of notes for events that change status by means of user-initiated action



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 Eventsdefault_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



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 file’s console-wide application can be used to protect the individual user’s 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.

# 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 Specificationix.servicetree.save.timer=5

Figure 23 Default policy file (part 2 of 2)


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 settingsYou 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)

Console property Description

framework_debug when set to true, enables debugging for the console

help_url sets the directory location and URL address for the BMC Impact Explorer Help file

java_plaf specifies the look and feel for BMC Impact Explorer according to the Java interface settings

macro_connect_timeout sets the amount of time, in seconds, a macro waits to connect to a cell

remote_server_port sets the port number used by the Remote Method Invocation (RMI) service in BMC Impact Explorer

remote_server_enabled enables the RMI service for BMC Impact Explorer for remote access to event data

all_connection_allowed 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 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 specifies the background color for the navigation tab on the Events tab of the console

max_msg_history sets the maximum number of status bar history messages that are stored in the console

new_groups_name specifies the default name assigned to newly created subgroups on the Services tab on the console

svc_view_tooltip length of time, in milliseconds, the console waits to display tooltips in the Services View


Defining global event severity and priority color values

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.

svc_view_link_thickness_normal sets the width for line indicators that connect service model components in the relationships pane of the console

svc_view_link_thickness_true_impact sets the width of the line indicators that indicate impact relationships between service model components in the relationships pane of the console

Table 52 Event severity levels and colors

Severity level Color Hexadecimal RGB values in color.properties

Down Black 000000,FFFFFF

Critical Red FF0000,FFFFFF

Major orange FF9900,000000

Minor light orange FFCC33,000000

Warning yellow FFFF00,000000

Information blue 3366CC,FFFFFF

OK green 33CC00,000000

Unknown gray CCCCCC,000000

Table 51 Property descriptions from ix.properties file (part 2 of 2)

Console property Description


Event group configuration files

Table 53 lists the default priority level colors and their values, as defined in color.properties.

To globally change the default severity or priority colors, modify the color.properties file and stop and start the BMC Impact Administration Server.

Event group configuration filesThe event group configuration file structure is listed in Table 54:

WARNING ■ 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 Event priority levels and colors

Priority level Color Hexadecimal RGB values in color.properties

Priority_1 red FF0000,FFFFFF

Priority_2 orange FF9900,FFFFFF

Priority_3 light orange FFCC33,000000

Priority_4 yellow FFFF00,000000

Priority_5 green 33CC00,000000

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.

Table 54 Event group configuration files (part 1 of 2)

Folder Contains

\Images Backgrounds and Icons directories

\Images\Backgrounds background image files that are shared by all Map definitions

\Images\Icons image files which are shared by all Map definitions

\Map event group tree node template MapObjectTemplate.xml

\Map event group default image view configuration DefaultMapPage.xsl

\Map Map tree definition Maps.xml


XML files that define user interface elements

XML files that define user interface elementsTable 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.

\Map\Map_xxx Map.xml for Map_xxx as well as its MapPages directory

\Map\Map_xxx\MapPages all map page definitions for Map Map_xxx

Table 55 xml files that define user interface elements in BMC IX

File name Description

default.DataEditor.extdetails.xml defines the default tabs if the global.DataEditor.extdetails.xml file is not present or does not contain values

global.DataEditor.extdetails.xml defines the tabs that appear in the data editor

global.extdetails.xml defines the tabs that appear for events and components

global.PolicyEditor.extdetails.xml defines the policy type to policy editor mapping

global.SmcToolTips.extdetails.xml defines the tooltips that appear on a component instance

Table 54 Event group configuration files (part 2 of 2)

Folder Contains


C h a p t e r 7
7 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.


Presentation names overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Creating a new presentation name resource file. . . . . . . . . . . . . . . . . . . . . . . . . . . 190Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Digitally signing a .jar file with a digital test certificate . . . . . . . . . . . . . . . . . . . . 194

Enabling or disabling presentation names in BMC Impact Explorer tool tips . . . . . 195


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.

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.

■ For BMC Impact Explorer, the default presentation names are defined in the following two files:

■ InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\kb_core_resource.properties

Table 56 Presentation names for BMC Impact Solution interfaces

Interface Objects with presentation names

BMC Impact Explorer - Events View

■ event class names■ slot names■ enumeration class names and values■ collector names■ action names

BMC Impact Explorer - Services View

■ 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 - Administration View

■ 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.

BMC Impact Portal ■ 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

BMC Impact Service Model Editor

■ service model class names (component types) and slot names■ service model management class and slot names■ service model enumeration class names and values


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)

■ 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:

■ 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.


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

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.

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:

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.

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 organization’s 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.

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.

kb_info_resources=ResourceFileName,kb_core_resource, kb_deprecated_resource


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:

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.

# 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


Defining presentation names

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.

Defining presentation namesPerform these procedures to define user-friendly presentation names for new event classes, component types, slots, enumerations, or policy types.

Creating or modifying presentation name keys

The entries in kb_core_resource.properties have the form

where value is the presentation name. The value can contain space characters.

Table 56 lists the formats for the presentation name key.

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.

key=value

Table 57 Presentation name key formats

Object Key format

Class CLASS.InternalClassName

Slot SLOT.InternalClassName.InternalSlotName

Note: Use the class name where the slot is originally defined (the superclass).

Enumeration ENUM.InternalEnumerationName

Enumeration Value ENUMVAL.InternalEnumerationName.InternalValueName


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:

3 To define the presentation name for an event slot, add a line with the following format to the resource file:

4 To define the presentation name for a new policy type, add a line with the following format to the resource file:

5 To define the presentation name for a policy slot, add a line with the following format to the resource file:

6 To define the presentation name for a service model component type, add a line with the following format to the resource file:

7 To define the presentation name for a service model component slot (attribute), add a line with the following format to the resource file:

8 When you have finished adding or modifying the presentation names in the .properties file, save and close the file.

CLASS.eventClassName=eventPresentationName Event

SLOT.eventClassName.slotName=slotPresentationName

CLASS.policyTypeName=policyTypePresentationName Policy

SLOT.policyTypeName.slotName=slotPresentationName

CLASS.BMC_ClassName=ComponentTypeName

SLOT.BMC_ClassName.slotName=slotPresentationName

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.


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 organization’s 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:


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>


Enabling or disabling presentation names in BMC Impact Explorer tool tips

The resulting listing should appear as follows:

4 Sign the .jar file with the test certificate by following these steps:


jarsigner -keystore keystore_filename jar_filename alias

B Repeat this step for all the .jar files that you have created or changed.

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.

Enabling or disabling presentation names inBMC Impact Explorer tool tips

A BMC Impact Explorer user can view the internal object names as tool tips when the mouse pointer is over

■ 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

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

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.


Enabling or disabling presentation names in BMC Impact Explorer tool tips

Tool tips are not shown for

■ 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.


C h a p t e r 8
8 Configuring StateBuilder and gateways
This chapter describes how to configure the StateBuilder and gateways for exporting events and contains the following topics:

Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198StateBuilder configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199statbld return codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Exporting events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Modifying a statbld.conf file to export events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 206

Configuring tracing for StateBuilder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Trouble-shooting the StateBuilder process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207


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 cell’s 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.

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 file”and “Exporting events” on page 205.

Table 58 StateBuilder file name conventions

File Description

mcdb state file the cell uses at startup

mcdb.0 new state file being generated

mcdb.t 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 lock file indicating StateBuilder activity

xact transaction file generated by the cell

xact.n terminated transaction file, where n=1 is the oldest transaction file

xact.t.n 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.


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.

statbld return codes

Table 60 lists the return codes for statbld.

Table 59 statbld.conf Parameters

Parameter Description Default value

Export uses Boolean values to specify whether to export data No

ExportConfigFileName sets path to the gateway.export file %H/etc/%N/gateway.export

ExportDiscarded indicates whether discarded events are included in the export file

Discarded events are those that were dropped in the first four rule phases: Refine, Filter, Regulate, and New (Update).

No

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.

3

Table 60 statbld return codes (part 1 of 2)

Return code Description

1 failed to build new mcdb

2 failed to update history files

10 early initialization failure

37 process handling module initialization failure

47 StateBuilder specific file access initialization failure


Gateway configuration


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:

■ GwTECConfigFileName=%H/etc/gateway.TECwhich means: $MCELL_HOME/etc/gateway.TEC

■ GwjServerConfigFileName=%H/etc/gateway.jServerwhich 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

■ .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.

57 transaction file handling initialization failure

67 failed to load KB classes

77 server directory load failure

87 internal table initialization failure

97 detected running StateBuilder (mcdb.lock)

Table 60 statbld return codes (part 2 of 2)

Return code Description



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 61 Gateway configuration parameter predefined variables

Variable Description

$CLASS class name

$CONTEXT context name:■ Permanent—event permanently in DB (until out of date)■ Processed—discarded by rule processing■ Regulated—discarded by regulation■ Filtered—discarded by filter■ Refined—discarded by refine■ Received—discarded immediately

$DATE date stamp

$TIME time stamp

$MODNMS names of modified slots (empty for “new”)

$GHANDLE event ID in gateway

$CNAME cell name of cell connecting to gateway

$CHANDLE event ID in cell

$VALUE slot value of slot slot

$NAME selected slot name (only for body parameter)

$VALUE selected slot value (only for body parameter)

$MODS all modified slots (empty for “new”)

$ALL all slots (only for slots parameter)

$ALL cls all slots, but limited to class cls(only for slots parameter)

$MAP.map val mapped value of val using map

val can be a literal or a variable reference

Table 62 Gateway Configuration Parameter Text Values

Character Name

\\ backslash

\s space

\n new line

\r carriage return

\t tab

\0ddd character code in octal (0, 1, 2, or 3 digits d)



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)


Communication parameters

protocol 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.

Contents parameters

cond 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.

drop 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.

add 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.

slots 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.

map.name 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.



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.

Format parameters

init 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.

body 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.

term 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.

separator sets the separator character or string to use between slot values. The default value is nothing.

quotable 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.

openquote sets the opening quotation character to use for values that must be quoted. The default value is a single quote (‘).

closequote sets the closing quotation character to use for values that must be quoted. The default value is a single quote (‘).

escapequote determines how to escape a quotation mark inside a quoted value. The default value is a single quote (‘).

Table 63 gateway.export file parameters (part 2 of 2)




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:

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 of printed events

To print events in BAROC format, set the parameters as shown in Figure 25.

The BAROC format produces output similar to the example shown in Figure 26.

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.

EXAMPLE map.GW1severity=[WARNING=LOW,CRITICAL=URGENT]

EXAMPLE drop=[severity]add=[severity=$MAP.GW1severity($VALUE(severity))]

Figure 25 Parameters used to print event in BAROC format

init=$CLASS;\nbody=\t$NAME=$VALUE;\nterm=END\n

Figure 26 Example of printed events

MC_CELL_TICK;server_handle=0;date_reception=1010183001;event_handle=2;source=;sub_source=;...END


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.

Exporting eventsEvents 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 phases—Refine, Filter, Regulate, and New/Update—are 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.

Figure 27 Command to configure the export file

slots.new=[$ALL]slots.mod=[event_handle, $NAME, $VALUE]


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.

Using the default values in the gateway.export file for new events produces output in the format shown in Figure 29.

Figure 28 gateway.export file format

# Export Gateway Configuration#cond=alwaysslots.new=[$ALL]slots.mod=[$MODS]body=$VALUEterm=\nseparator=,quotable=,"openquote="closequote="escapequote="

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


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.

Configuring tracing for StateBuilderYou 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 Operator’s Guide.

Trouble-shooting the StateBuilder processIf the StateBuilder process (MCELL_HOME/bin/statbld) fails to start, try the following solutions:

■ 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:

■ mcdb.0 ■ mcdb.lock

If either of these files are present, delete them.

Figure 30 gateway.explore file output for modified events

mc.exp.000000001exp10.0.9.10:198128698mc.exp.000000002exp10.0.9.10:1981600ACK1010183062mc.exp.000000003exp10.0.9.10:198128698


Trouble-shooting the StateBuilder process

B From a command line, manually run the StateBuilder process by entering: statbld -n cell_name

■ 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 system’s 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.


A p p e n d i x A
A 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 211BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 213mccomp—Compiling rules in the Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . 214mcell—Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216mcfgtrace—Configuring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218mclassinfo—Requesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220mcollinfo—Getting information about a specific collector . . . . . . . . . . . . . . . . . . 225mcontrol—Performing cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228mcrtcell—Creating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231mcstat—Returning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235mdelcell—Deleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237mgetinfo—Retrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 238mgetrec—Obtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243mkb—Updating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245mkill—Stopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248mlogchk—Performing consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249mposter and msend—Managing data and events . . . . . . . . . . . . . . . . . . . . . . . . . 251mquery—Retrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257mrecover—Recovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . 262mrextract—Extracting cell state files to create new state files . . . . . . . . . . . . . . . 264mrmerge—Merging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265msetmsg—Modifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267msetrec—Setting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . 272BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 272


BMC Impact Manager CLI commands

BMC Impact Manager CLI commandsUse 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 BMC Impact Manager CLI command descriptions

Command Description Page

mccomp compiles rules in the Knowledge Base 214

mcell starts a cell 216

mcfgtrace modifies tracing configuration of a running cell 218

mclassinfo obtains class information from a cell 220

mcollinfo obtains collector information from a cell 225

mcontrol performs control operations on a running cell 228

mcrtcell creates a new cell 231

mcstat returns the status of a cell 235

mdelcell deletes a cell 237

mgetinfo retrieves information about a running cell 238

mgetrec retrieves the content of a global record 243

mkb views/updates the Knowledge Base 245

mkill stops a cell 248

mlogchk performs consistency checks 249

mposter sends or manipulates data, records, and events 251

mrecover recovers catastrophic loss of data 262

mrextract extracts cell state files to create new state files 264

mrmerge merges extracted cell state files 265

mquery retrieves objects from a cell 267

msend sends an event to a cell 267

msetmsg modifies an event in a cell 267

msetrec sets the value of a global record 268


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.

Table 65 describes the common command options that apply to all commands.

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:

■ Designate a cell name by specifying -n cellName.

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 Common options for CLI commands

Option Description

-c ConfigFile specifies a configuration file to use instead of the default MCELL_HOME\etc\mclient.conf file

-hor-?

displays help information, including syntax and options

-i UserID[/Password][@Host[/Port]]

[optional] specifies that user authentication is required to execute the CLI

-l HomeLocation specifies home directory (HomeLocation) for the command if it is not specified with MCELL_HOME

-n cellName or-n @Host[/Port[#Key]]

starts the cell named cellName (as defined in mcell.dir). For more information, see “Using the -n option”.

-p Var=Value assigns the specified value (Value) to the option Var

-q invokes quiet execution (no banner appears)

-v activates verbose mode to display more information

-z displays version information


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.

■ 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:

■ 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.


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:

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.

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.

[-i UserID[/Password][@Host[/Port]]]

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.


mccomp—Compiling rules in the Knowledge Base


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.

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.

Table 66 Common return codes for CLI commands

Code Description

0 success

1 bad usage (command includes nonexistent options or an invalid combination of options and arguments)

10 initialization failure

11 trace initialization failed

12 configuration initialization failed

13 outbound communication setup failed

14 inbound communication setup failed

15 message handling initialization failed

16 persistency setup failed

17 port range limitation failed

20 connection to cell failed

25 memory fault

26 command failed

27 syntax error

28 invalid answer received

Figure 31 mccomp syntax

mccomp [-e ErrorLogFile] [-h|?] [-n CellName | ManifestKBFilePath] {-p Var=Value} [-l HomeLocation] [-t] [-v [VERBOSE|INFORM|WARNING|ERROR|FATAL]] [-z]



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.

mccomp example

Figure 32 shows an example of mccomp.

This command produces output similar to the example shown in Figure 33.

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.

Table 67 mccomp options

Option Description

-e ErrorLogFile redirects error messages to a user-specified file; used primarily in scripts

-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 generates tracing calls in the resulting compiled files for debugging purposes

- v [VERBOSE|INFORM|WARNING|ERROR|FATAL]

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.

WARNING A Knowledge Base compiled for runtime rule tracing using -t can experience considerable runtime performance degradation.

Figure 32 mccomp example

mccomp -n cell1

Figure 33 Example output for mccomp

Parsing BAROC file classes/root.barocParsing BAROC file classes/intevt.barocCompilation ended successfully


mcell—Starting a cell


The mcell command starts a specified cell.

mcell syntax

Figure 34 shows the syntax for mcell.

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.

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 mcell options

Option Description

-c 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.

-d runs in foreground instead of as a service or daemon

-i initializes the cell repository; can combine with suboptions:

■ -i—-ied■ -ie—events■ -id—data--initializes all data■ -ic—EventCounter■ -ia—-iedc—initializes 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



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:

■ 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.

■ To start the cell as a service on a Microsoft Windows platform, type the command shown in Figure 36.

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.

■ 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.

Figure 35 Starting a cell

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.

Figure 36 Starting a cell as a service on windows

net start mcell_cellName

Figure 37 Starting the BMC Impact Manager service on Microsoft Windows

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.


mcfgtrace—Configuring 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.


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.

Table 69 mcell return codes

Code Description

2 bad home directory option usage

3 no home directory specified

4 invalid home directory specification

5 application system initialization failed

19 logging facility initialization failed

29 Knowledge Base load failed

37 message handling module initialization failed

39 internal object initialization failed

47 event processing module initialization failed

49 save state reload failed

57 query handling module initialization failed

59 service activation failed

67 internal event module initialization failed

69 metrics initialization failed

77 data processing module initialization failed

79 metrics activation failed

97 service setup failed



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.

mcfgtrace parameters

Table 71 lists the parameters for mcfgtrace.

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.

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.

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)

Table 70 mcfgtrace option

Option Description

Module Level Destination See “ mcfgtrace parameters” on page 219.

Table 71 mcfgtrace parameters

Parameter Available values

Module ALL | Module

Level ALL | VERBOSE | INFORM | WARNING | ERROR | FATAL

SWITCH SwitchName

Destination no | stderr | console | DestinationFileName

Figure 39 mcfgtrace example

mcfgtrace -n Cell1 ALL ALL '%T/all.trace'


mclassinfo—Requesting 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.

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.

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.

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 mclassinfo options

Option Description

-a Amount specifies the amount of information: 0, 1, 2, 3 (See “ Information amount” on page 222); default is 2

-d reports data class definitions instead of event class

-e reports enumeration definitions used in the classes

-o OutputFile produces the output in a file called OutputFile, instead of using standard output

-r produces raw output for programs

-u reports unique slots only, excluding redefined slots in subclasses

-x reports enumeration definitions only (exclude classes)

Class names of selected classes



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.

The class tree is reported depth-first, left-to-right, as ClassInfo, as shown in Figure 42.

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.

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 (*).

Figure 41 Raw output format for mclassinfo

EnumInfo = EnumTypeCount (EnumTypeInfo)*EnumTypeCountEnumTypeInfo = EnumTypeName EnumValCount (EnumValName)*EnumValCount

Figure 42 Class tree for mclassinfo

ClassInfo = ClassCompCount(ClassCompInfo)*ClassCompCountClassCompInfo = ClassName ClassFlags ClassSlotCount

(ClassSlotInfo)*ClassSlotCount ClassInfoClassSlotInfo = ClassSlotName ClassSlotValType ClassSlotRepType

ClassSlotFlags ClassSlotDefaultValueLength ClassSlotDefaultValueText

ClassSlotValType = ClassSlotStructCode ClassSlotTypeCodeClassSlotStructCode = S | LClassSlotTypeCode = i | r | p | s | e:EnumerationTypeName

| c | c:BaseClass| q | q:BaseClass

ClassSlotFlags = (r|R) (k|K) (p|P) (d|D) (h|H)

Table 73 Type of slot value for mclassinfo

Slot Type Definition

i INTEGER

r REAL

p POINTER

s STRING

e;EnumerationTypeName Enumeration

c:BaseClass ECF of BaseClass

q:BaseClass QUERY of BaseClass



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.

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.

mclassinfo examples

mclassinfo can be used as shown in the following examples.

Table 74 Reported facets

Facet Function

r|R read_only

k|K key

p|P parse

d|D dup_detect

h|H hidden

Table 75 Class flags

Flag Function

p|P publishable class

Table 76 Information amount limitation options for mclassinfo

Option Description

-a 0 reports only class names; no slot information is reported

-a 1 reports slot names

-a 2 adds slot names and representation type (default)

-a 3 adds slot flags and default value



Obtaining a list of classes

To obtain a list of classes used by a cell named grace, type the command shown in Figure 43.

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 46 shows an example of the output.

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_EVENTClass: MC_CELL_CONTROL

Class: MC_CELL_STARTClass: MC_CELL_STOPClass: MC_CELL_TICKClass: MC_CELL_STATBLD_STARTClass: MC_CELL_STATBLD_STOPClass: MC_CELL_DB_CLEANUPClass: MC_CELL_CONNECT

Class: MC_CELL_CONNECT_RESOURCES_EXPANDEDClass: MC_CELL_CONNECT_SUSPENDEDClass: MC_CELL_CONNECT_RESUMED

Class: MC_CELL_CLIENT.

Figure 45 Example of mclassinfo command for list of classes


Figure 46 Example of mclassinfo command output for list of classes

Class: CORE_EVENTSlot: event_handleSlot: mc_ueidSlot: sourceSlot: sub_sourceSlot: hostnameSlot: origin...



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.


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 47 Example of mclassinfo command for adding slot names


Figure 48 Example of mclassinfo command output for adding slot names

Class: CORE_EVENT -Flags: pSlot: event_handle - Type: INTEGERSlot: mc_ueid - Type: STRINGSlot: source - Type: STRINGSlot: sub_source - Type: STRINGSlot: hostname - Type: STRINGSlot: origin - Type: STRING

.

.

.

Figure 49 Example of mclassinfo command for adding slot flags


Figure 50 Example of mclassinfo command output for adding slot flags

Class: CORE_EVENT -Flags: pSlot: event_handle - Type: INTEGER - Flags: rkpdh - Def: 0Slot: mc_ueid - Type: STRING - Flags: rkPdh - Def:Slot: source - Type: STRING - Flags: rkPdh - Def:Slot: sub_source - Type: STRING - Flags: rkPdh - Def:Slot: hostname - Type: STRING - Flags: rkPdh - Def:Slot: origin - Type: STRING - Flags: rkPdh - Def:.

.

.

.


mcollinfo—Getting 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.


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.


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 77 mclassinfo return codes

Code Description

31 cannot read input file

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))

Table 78 mcollinfo options (part 1 of 2)

Option Description

-a Amount specifies the amount of information (0, 1, 2); the default is 2. For more information, see “ Information amount” on page 222.

-d reports collector definitions

-f {InputFile} reads collectors from InputFile instead of from command line



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.


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.

-g reports collector object identifier (OID)

-o OutputFile produces the output in a file called OutputFile, instead of using standard output

-r produces raw output for programs

-s reports collector status and severity counters

Collector specifies the collector name or OID with optional + suffix for closure

Figure 52 Raw output format for mcollinfo

CollInfo = CollCompCount (CollCompInfo)*CollCompCountCollCompInfo = CollName CollPerm CollClassCount

(CollClass)*CollClassCount CollInfoCollPerm : CollPermR CollPermW CollPermX CollPerm_ : CollRoleCnt (CollRole)*CollRoleCnt

Table 78 mcollinfo options (part 2 of 2)

Option Description



Information amount

The amount of reported information is limited as shown in Table 79.

mcollinfo examples

Figure 53 shows an example of mcollinfo.

You can request user-formatted output in verbose mode as shown in Figure 54.

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.

Table 79 Information amount limitation options for mcollinfo

Option Description

-a 0 reports only collector names

-a 1 add permissions

-a 2 add referenced classes

Figure 53 mcollinfo example

mcollinfo -n dbg -o Net.Global6.1

Figure 54 mcollinfo command for verbose mode

mcollinfo -n dbg -v -o Net.GlobalCollector Net.GlobalOID=6.1

Figure 55 mcollinfo command for number of events for severity/status

mcollinfo -n dbg -v -s Net.GlobalCollector Net.GlobalSeverities=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


mcontrol—Performing 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.


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.


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 80 mcollinfo return codes

Code Description

31 cannot read input file

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]] ]

Table 81 mcontrol option

Option Description

Control specifies the control command to use. See Table 82 for the available control commands.



Table 82 lists the following controls that are available.

Table 82 mcontrol controls (part 1 of 2)

Control Description

metrics [on|off|reset] on = enables metricsoff = disables metricsreset = resets running counters

If an argument is not specified, metrics are reported by default.

pause suspends reception of adapter messages; events are no longer accepted

prop [{Destination}] 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 [{dir|trace|conf|collect|kb|data|all}]

reload cell configuration, for one or more categories; if you do not choose an argument, all categories reload

■ dir—mcell.dir■ trace—mcell.trace■ conf—mcell.conf, propagate, modify■ collect—collector definitions■ kb—Knowledge Base, classes, rules■ data—data instances■ all—all the categories

restart stops and restarts the cell

shutdown terminates the cell in fast shutdown mode; same as mkill -s

standby switches cell to standby mode

start resumes reception of adapter messages; cell operates normally again

statbld 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

stop terminates the cell in normal mode; same as mkill

tracerule on|off turns rule tracing on or off



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.


Terminating a cell

To terminate a cell named grace, type the command shown in Figure 59.

tracerule phases Phases 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 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).

Figure 57 Retrying Pending propagations with mcontrol command

mcontrol -n grace -v prop

Figure 58 Example of mcontrol command output for retrying pending propagations

Command on server grace acknowledged

Figure 59 Terminating a cell using the mcontrol command

mcontrol -n grace -v stop

Table 82 mcontrol controls (part 2 of 2)

Control Description


mcrtcell—Creating a new cell


Reconfiguring a cell

To reconfigure cell grace after mcell.dir has been modified, type the command shown in Figure 61.


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.

Figure 60 Example of mcontrol command output for terminating a cell


Figure 61 Reconfiguring a cell

mcontrol -n grace reload dir

Figure 62 Example of mcontrol command output for reconfiguring a cell


WARNING Cells with identical cell names on different computers within your enterprise will cause unexpected results.



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:

■ 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.

mcrtcell actions

The mcrtcell command performs the following actions:

■ 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.

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.



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.

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.

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 83 Files for UNIX

Platform File

AIX platforms etc/cellName.d

HP-UX platforms sbin/init.d/mc_cellNameSolaris platforms etc/init.d/cellName

etc/rc2.d/K99cellNameetc/rc2.d/S99cellName

Linux platforms etc/rc.d/init.d/mc_cellName

etc/rc.d/rc3.d/K99mc_cellName

etc/rc.d/rc3.d/S99mc_cellName

Figure 63 mcrtcell syntax

mcrtcell [-ae|-as|-aa] NewcellName [-f] [-h|-?] [-l HomeLocation] [-m] -p PortNumber [-s SourceCell] [-z]

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 mcrtcell options (part 1 of 2)

Option Description

-aa recreates an Impact Administration cell with an Admin Knowledge Base

-ae creates a BMC Event Manager cell with a unified Knowledge Base



mcrtcell example

Figure 64 shows an example of how to create a service using mcrtcell.

Figure 65 shows the output produced.

Figure 66 shows an example of how to create another service using mcrtcell.

Figure 67 shows the output produced.

-as creates a Service Impact Manager cell with a unified Knowledge Base

-f 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 prevents automatic restart on reboot

-p PortNumber 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 specifies the cell (SourceCell) from which to copy a Knowledge Base

NewcellName specifies the name for the cell being created. For information about cell naming conventions, see “ Cell names” on page 231.

Figure 64 Example of mcrtcell command

mcrtcell -p 2591 -as was05dal

Figure 65 Example of output of mcrtcell

Service successfully created

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 Example output of mcrtcell

Service successfully created

Table 84 mcrtcell options (part 2 of 2)

Option Description


mcstat—Returning cell status

Figure 68 shows an example of how to create an Impact Administration cell using mcrtcell.

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.


The mcstat command obtains the status of a cell. This command shows whether a cell is running or stopped.

Figure 68 Example mcrtcell for recreating an Admin cell

mcrtcell -aa -p 10011 Admin

Table 85 mcrtcell return codes

Code Description

-1 uname command failed

3 MCELL_HOME environment variable not set or duplicate cell name or port definition in mcell.dir

31 no MCELL_HOME environment variable is defined

32 duplicate cell definition in mcell.dir

33 existing cell with same name on a different host

34 existing cell with same name on a different port

35 existing cell with same name on a different host/port

36 failed to create new directory

37 cannot get OS

38 failed to remove a cell



mcstat Syntax

Figure 69 shows the syntax for mcstat.

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.

mcstat example

To obtain the status for a cell named examplecell, type the command shown in Figure 70.

If the cell is not running, a message similar to the example in Figure 71 appears.

If the cell is running, the message shown in Figure 72 appears.

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.

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 mcstat option

Option Description

-t TimeOut specifies the length of time, in milliseconds, for the command to wait for answer before terminating; default is 60000, or 1 minute

Figure 70 mcstat example

mcstat -n examplecell

Figure 71 Message for cell not running

Could not connect to Cell examplecell.

Figure 72 Message for cell running

Running


mdelcell—Deleting a cell

mdelcell—Deleting 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:

■ 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.

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.

mdelcell example

To delete a cell named grace, type the command shown in Figure 74.

If grace is not currently running, this command produces output similar to the example shown in Figure 75 on Microsoft Windows platforms:

Figure 73 mdelcell syntax

mdelcell cellName [-i UserID[/Password][@Host[/Port]]] [-z] [-h|?] [-k] [-w TimeOut]

Table 87 mdelcell options

Option Description

-k keeps tmp and log directories of the cell

-w TimeOut specifies the length of time, in seconds, for the command to wait when terminating the cell.

Figure 74 Deleting a cell using mdelcell

mdelcell grace

Figure 75 Output for mdelcell if cell is not running

Service successfully removed


mgetinfo—Retrieving 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.

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.


The mgetinfo command retrieves information about a cell.

mgetinfo syntax

Figure 77 shows the syntax for mgetinfo.

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.

Figure 76 Output for mdelcell if cell is running

Warning! Cell grace was running and mdelcell tries to terminate it.Service successfully removed.

Table 88 mdelcell return codes

Code Description

-1 uname command failed

31 no MCELL_HOME environment variable is defined

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



Table 90 describes the mgetinfo information options.

Table 89 mgetinfo option

Option Description

Information specifies the Information option to use. See Table 90 for the available Information options.

Table 90 mgetinfo information options (part 1 of 2)

Information Description

activity retrieves the activity status of the cell0 = standby1 = limited2 = full activity.

config 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

connect retrieves information about the current connections that are open from and to the cell; see Table 91 for description of that information

kbmodules lists KB modules with version information from the cell’s loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format.

kbsources lists KB source files with version information from the cell’s loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format.

metrics reports the metrics, collected by the cell, that are stored in MC_CELL_METRIC data objects

metrics output consists of ■ metric name■ metric description■ 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:■ ReceivedEvents—number of received event messages■ ErrorEvents—number of received event messages that are incorrect (for example,

causing a parse error)■ DroppedEvents—number of events that are dropped during processing through the

rules■ StoredEvents—number of events that have passed all the rules and are stored in the

Event database■ RemovedEvents—number of events that have been removed from the Event database by

a database cleanup■ DeletedEvents—number of events that have been deleted by clients, such as CLI or the

console■ PropagatedEvents—number of events that have been propagated to another

destination■ ConnectedSources—number of adapter clients that are connected to the cell



A connect request displays the information shown in Table 91.

param 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.

services reports service metrics counting the components and relationships

version displays the version number of the cell

Table 91 Information from connect request

Connect information Description

All Connections

direction 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 the client type, such as unknown, cell, browser, adapter, CLI, and EIF, which are reported as literal values

name of connected program

the name of the connected program (for example: Impact Explorer, mposter, cellName)

source address IP address/port of source side of the connectionfor inbound connections, this is the client; for outbound, it is the cell

destination address IP address/port of destination side of the connectionfor inbound connections, this is the cell; for outbound, it is the destination

Incoming Connections

name of user the name of the user; example: Admin

time delta between both sender and receiver in seconds, to be added to time stamps coming in to convert to the cell time

sequence sequence number of last incoming message

sequence sequence number of last answer

Outgoing Connections

time stamp timestamp of last connection setup or trial

sequence sequence number of last outgoing message

message number of messages waiting for connection opening

message number of messages waiting for answer

Table 90 mgetinfo information options (part 2 of 2)

Information Description



mgetinfo examples

This section contains examples of mgetinfo.

mgetinfo config example

This command produces output similar to the following:

mgetinfo metrics example

This command produces output similar to the following:

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

■ 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,

■ the metric name is ReceivedEvents.

mgetinfo -n aspen config

cellName=aspenHomeDir=C:/mcell/serverKBDir=C:/mcell/server/etc/aspen/kb/ConfigFile=C:/mcell/server/etc/mcell.confTraceConfigFile=C:/mcell/server/etc/mcell.traceTraceDefaultFile=C:/mcell/server/tmp/aspen/traceServerDirectoryFile=C:/mcell/server/etc/mcell.dirPropagateConfigFile=C:/mcell/server/etc/mcell.propagateModifyConfigFile=C:/mcell/server/etc/mcell.modify

mgetinfo metrics

BMC Impact InfoRetrieval 7.x.xx (Build xxxxxx - xx-xxx-xxxx)Copyright 1998-xxxx BMC Software, Inc. as an unpublished work. All rights reserved.ReceivedEvents Number of received event messages 60 0 0 300 1 0 3616974 12534 0ErrorEvents Number of events containing errors 60 0 0 300 0 0 3616974 94 0DroppedEvents Number of events dropped by rules 60 0 0 300 1 0 3616974 5700 0StoredEvents Number of events entered in the DB 60 0 0 300 0 0 3616974 6834 0RemovedEvents Number of events removed by DB cleanup 60 0 0 300 0 0 3616974 27451 0DeletedEvents Number of events deleted by clients 60 0 0 300 0 0 3616974 0 0PropagatedEvents Number of propagated events 60 0 0 300 0 0 3616974 102 0ConnectedSources Number of connected sources 60 0 0 300 0 0 3616974 0 0



■ 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.


mgetinfo services example

Figure 80 shows an example of mgetinfo services.


Figure 78 Example of mgetinfo param

mgetinfo -n aspen param

Figure 79 mgetinfo param command output

Trace=YesTraceSrc=NoTraceRuleLevel=1TraceConfigFileName=mcell.traceTraceDefaultFileName=%T/traceLicenseServer=CellOperationLevel=ConsolidationCellOperationRelax=No...

Figure 80 Example of mgetinfo services

mgetinfo services

Figure 81 mgetinfo services command output (part 1 of 2)

MC_SM_COMPONENT Number of MC SM Component 87CONNECTIVITY Number of Connectivity 11


mgetrec—Obtaining a global record value

mgetinfo connect example

Figure 82 shows an example of mgetinfo connect.


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.


Use the mgetrec command to obtain the value of a global record.

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

Figure 82 Example of mgetinfo services

mgetinfo connect

Figure 83 Output of mgetinfo connect

IN browser ImpactExplorer 10.0.10.17:1545 10.0.10.28:1828 Admin 0 2028 2071

Table 92 mgetinfo return codes

Code Description

31 not a SIM cell

Figure 81 mgetinfo services command output (part 2 of 2)



mgetrec syntax

Figure 84 shows the syntax for mgetrec.

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.

mgetrec example

Figure 85 shows an example of mgetrec.

The preceding command produces output similar to the example shown in Figure 86.

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]

Table 93 mgetrec option

Option Description

-r Record[.Slot] specifies the global record to be obtained, optionally limited to one of its slots

Figure 85 Example of mgetrec

mgetrec -r EM_KB_OPTIONS

Figure 86 Output of mgetrec (part 1 of 2)

startup_script_enabled-----NO-----dfilter_enabled-----NO-----dnotification_enabled-----NO-----dpropagation_enabled


mkb—Updating the Knowledge Base

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.

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.

-----NO-----default_location-----

Figure 87 mkb syntax

mkb [-h|-?] [-z] [-q] [-v] [-n CellName | -n @Host[/Port[#Key]] ] [-f ManifestFile] [-b BinFile] [-c ClassFile] [-d DataFile] [-a Arch] [-j RecordFile] [-l LibFile] [-m Directory] [-o CollectorFile] [-p] [-r RuleFile] [ -i UserID[/Password][@Host[/Port]] ]

Table 94 mkb options (part 1 of 2)

Option Description

-a Arch specifies the platform architecture

-b BinFile binary file name

-c ClassFile imports the specified ClassFile.baroc that defines the class definitions

Figure 86 Output of mgetrec (part 2 of 2)



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.

-d DataFile imports the specified DataFile.baroc that defines data instances

-f manifest specifies the path to the manifest.kb file

-j RecordFile imports RecordRile.baroc that defines the record definitions

-l LibFile 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.

-m Directory creates a new Knowledge Base directory hierarchy based on the contents of the designated manifest.kb file

-o CollectorFile imports the specified CollectorFile.mrl that defines that collector definitions

-p 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

Table 95 mkb new file options

mkb Option Description

-a Arch specifies the platform architecture:

■ h1 - HP-UX■ l2 - Linux■ p4 - AIX (Power PC)■ s5 - Solaris (Sparc)■ w4 - Microsoft Windows (Intel)

-b BinFile adds the binary file (BinFile) for the architecture

-c ClassFile adds the class file (ClassFile) to the designated Knowledge Base

-o CollectorFile adds the collector file (CollectorFile) to the designated Knowledge Base

-d DataFile adds the data file (DataFile) to the designated Knowledge Base

-l LibFile 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

Table 94 mkb options (part 2 of 2)

Option Description



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.

This command produces output similar to the example shown in Figure 89 on a UNIX computer named spud.

Figure 88 mkb command on UNIX

mkb -f ./manifest.kb -p

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: .loadcan 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


mkill—Stopping a cell

Microsoft Windows example

Figure 90 shows an example of mkb on Microsoft Windows.

This command produces output similar to the example shown in Figure 91 on Microsoft Windows.

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.

mkill—Stopping a cell

Use the mkill command to stop a running cell or gateway.

mkill syntax

Figure 92 shows the syntax for mkill.

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.

Figure 90 mkb command on Microsoft Windows

mkb -f kb\manifest.kb -m new_kb

Figure 91 mkb command output on Microsoft Windows

manifest directory tree created successfully

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]]]


mlogchk—Performing 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.

mkill example

Figure 93 shows an example of mkill.

The preceding command produces output similar to the example shown in Figure 94.

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.

Table 96 mkill option

Option Description

-s performs rapid shutdown termination; bypasses StateBuilder

Figure 93 Example of mkill

mkill -n examplecell

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.



The mlogchk command does the following:

■ 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.

There are no command-specific options for mlogchk.

mlogchk example

Figure 96 shows an example of mlogchk.

For a cell named spud, the preceding command produces output similar to the example shown in Figure 97.

The output continues with the message shown in Figure 98 on page 251 if you respond with y.

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]]]

Figure 96 Example of mlogchk

mlogchk -n spud -v

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) ?


mposter and msend—Managing data and events

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.


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.

You can use the mposter command to modify dynamic data objects in the cell even when the cell is paused.

Figure 98 mlogchk message

No inconsistency found.

Table 97 mlogchk return codes

Code Description

21 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.

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 cell’s standard (reference) published service model in the CMDB. This causes a loss of service model integrity and subsequent service model publishings will fail.



mposter and msend syntax

Figure 99 shows the syntax for mposter.

Figure 99 shows the syntax for msend. The syntax for msend very similar to mposter except that mposter supports the -d option.

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.

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 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 mposter and msend options (part 1 of 2)

Option Description

- input from standard input stream

-a Class sends an object of class Class

-b SlotSetValue adds SlotSetValue settings (format: “slot=value;...”)

For example,-b "msg='this is a test';mc_tool=computer;"

- d (Used with mposter only.) sends as data instead of as event

-e specifies to use EIF instead of MCELL format

-f DirFile specifies the directory file path; the default value is MCELL_HOME\etc\mcell.dir

-i sets to interactive mode

-I reinitializes persistent buffers

-j BufDira sets the directory to be used for persisting events that are buffered until they are sent



-l EventID 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.

-m Message sets event message to the specified Message text

-o Source sets event source to the specified Source

-p Var=Value 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 sets the length of time in milliseconds to wait for trailing answers before terminating; default is 5000

-u leave messages unanswered

-w MSecAnswerWait 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.

-x examines timings

-y immediately terminate upon connection failure

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'"

Table 98 mposter and msend options (part 2 of 2)

Option Description



mposter examples

Figure 101 shows an example of mposter.

The information for the event is entered using BAROC-style input as shown:

The output of the mposter session is similar to the following:

Then the following would be input:

And the mposter output would be similar to the following:

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:

■ 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.

NOTE All examples and information in this section also can apply to msend.

Figure 101 Example of mposter

mposter -n aspen -v -

HOST_DOWN;origin='HOST_DOWN';msg='host blue is down';

END

Message 1 - evtid = 11142

HOST_DOWN;origin='HOST_DOWN';msg='host orange is down';

END

Message 2 - evtid = 24233



The preceding command does not produce any output.

Enabling persistent buffering

To enable persistent buffering, first create a writeable directory (BufDir in Figure 103), then use the syntax shown in Figure 103.

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:

■ UNIX—/etc/itm/.reg/Buffers

■ Microsoft Windows—HKEY_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.

Figure 102 Definition changes using mposter

mposter -n aspen -a AppByHost -d -b "host='aspen'; applications=['word','excel']"

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.

Figure 103 Enabling persistent buffering using mposter

mposter [current options] -j BufDir



If the Buffers file is not writable, you will receive the error message shown in

Decreasing the buffer size

The persistent directory may contain the following files:

■ 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:

■ 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.

Figure 104 Error message if buffers files are not writable

Launching mposter server... OKGetting Server Port number... OK (33992)Connecting mposter server... Fatal error! Cannot negotiate connectionwith mposter server. Check if the cell(s) name, location, port andencryption key are the same as those running server (protocol error:4)Fatal error! Client initialization failed. A current cause of thisproblem is a wrong/unavailable cell destination (hostname, port,encryption key).


mquery—Retrieving objects from a cell


The mquery command retrieves objects from a cell.

mquery syntax

Figure 105 shows the syntax for mquery.

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 99 mposter and msend return codes

Code Description

2 failed to initialize in Server mode

3 failed to find a valid cell

4 failed to close the client connection

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 mquery options (part 1 of 2)

Option Description

- performs queries as read from standard input stream

-a Class select from a specified Class (default is either CORE_EVENT or CORE_DATA).

-d select data objects instead of event objects

-f Format format using: quoted, BAROC, CSV, or XML

-g Collector selects only in a collector (optional + suffix for closure)

-o OrderSlot 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 perform the specified query

-r sets output to be raw output. For more information, see “ Raw output format” on page 226.



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.


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.

-s SlotList 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.

-w Where specifies a where condition on the specified Class

-x SlotList excludes specific slots from the comma-separated SlotList (selecting ALL)

File performs queries as read from one or more specified files

Figure 106 Example of raw output specification

RawOutput = SolutionCount RS Solution RS ... Solution RSSolution = SlotValue FS ... SlotValue

Figure 107 Verbose mode options

-----N/M-----

Table 100 mquery options (part 2 of 2)

Option Description



where

■ 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.

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.

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.

Figure 108 End of form

-----END-----

Figure 109 Special BAROC format

slotname=slotvalue;



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 Description

-d retrieves data instances instead of events

-a Class 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

■ ALL—gets all slots■ COUNT—gets no slots, only a count of matching objects is returned■ DELETE—all 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.



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.

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.

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.

This command removes the event with handle 123.

Figure 110 Example of mquery—Select events with severity status

mquery -a MC_CELL_CONTROL -w "severity: >= MINOR AND status: != CLOSED"

-s "mc_ueid,CLASS,severity,msg"

Figure 111 Example of mquery—Select 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:

■ 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.

Figure 112 Deleting events using mquery

mquery -n cellName -s DELETE -w "event_handle: == 123"


mrecover—Recovering 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.


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.

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.

Table 102 mquery return codes

Code Description

21 syntax error in input

NOTE The mrecover command recovers only propagated events.

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.



mrecover syntax

Figure 113 shows the syntax for mrecover.

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.

mrecover example

To fix a broken cell with input from cella, cellb, and cellc, type the command shown in Figure 114.

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.

Figure 113 mrecover syntax

mrecover [-c ConfigFile] [-q] [-h|-?] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]]{-p “Var=Value”} [-z]{TargetCell} . . .

Table 103 mrecover option

Option Description

TargetCell specifies the name of the cell that propagated events or to which events have been propagated

Figure 114 Fixing a broken cell using mrecover

mrecover -n broken_cell cella cellb cellc

Table 104 mrecover return codes

Code Description

2 failed to send the command that started the StateBuilder on a remote cell

3 could not obtain information from one or more neighbor cells

5 could not launch an external program (mrmerge or mcell)

6 mrmerge exited abnormally

7 mcell (in recovery mode) exited abnormally


mrextract—Extracting cell state files to create new state files

mrextract—Extracting 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 “ mrecover—Recovering from a catastrophic data loss” on page 262.

The cell must be stopped before using the mrextract command.

mrextract syntax

Figure 115 shows the syntax for mrextract.

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.

mrextract example

Figure 116 shows an example of mrextract.

WARNING This command is used by mrecover and should be avoided by end users.

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 mrextract options

Option Description

-o OutputFile sends output to the specified OutputFile file; the default is to send output to standard output

-s InputStateFile specifies to use input from InputStateFile; the default is the cell’s mcdb

TargetCell specifies the name of the cell to which events have been propagated; separate multiple cell names with a space

Figure 116 Example of mrextract

mrextract -n CellTwo -o \tmp\mcdb.CellOne


mrmerge—Merging 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.


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 “ mrecover—Recovering from a catastrophic data loss” on page 262.

mrmerge syntax

Figure 117 shows the syntax for mrmerge.

Table 106 mrextract return codes

Code Description

37 failed to enable tracing

47 cannot access state builder

67 failure loading kb classes

97 cannot start while state builder is active

WARNING This command is used by mrecover and should be avoided by end users.

Figure 117 mrmerge syntax

mrmerge [-h|-?] [-c ConfigFile] [-l HomeLocation] [-n cellName | -n @Host[/Port[#Key]]] {-p “Var=Value”} [-o OutputFile] {InputFile} [-q] [-z]



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.

mrmerge example

Figure 118 shows an example of mrmerge.

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 107 mrmerge options

Option Description

-o OutputFile specifies the file (OutputFile) to which to send command output; the default output target is terminal; the path name of the recovery cell’s database file (mcdb) to be created by this command

InputFile specifies the input file for the mrextract command

Figure 118 Example of mrmerge

mrmerge -n Cellone -o $MCELL_HOME\log\Cellone\mcdb\tmp\mcdb.X1 \tmp\mcdb.X2

Table 108 mrmerge return codes

Code Description

37 failed to enable tracing

47 cannot access StateBuilder

67 failure loading kb classes

97 cannot start while StateBuilder is active


msetmsg—Modifying an event

msetmsg—Modifying 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.

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.

msetmsg example

To close an event whose event ID (event_handle) is 12981, type the following command:

If this command is successful, it does not produce output.

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 msetmsg options

Option Description

-u EventId specifies the event handle of the event to be modified

-C sets the status value of the specified event to CLOSED

-O sets the status value of the specified event to OPEN

-A sets the status value of the specified event to ACK

-G sets the status value of the specified event to ASSIGNED

-B 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 slot’s value

msetmsg -n cellName -u 12981 -C


msetrec—Setting 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.

msetrec—Setting 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.

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 110 msetmsg return codes

Code Description

31 no event handle specified

32 failed to set message

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 msetrec options

Option Description

-b specifies slot value assignment

-r Record specifies the global record containing the Slot to be modified

-S Slot specifies the Slot to be modified

-V Value specifies the Value to set for the specified Slot


BMC Impact Manager CLI configuration

msetrec example

Figure 121 shows an example of msetrec.

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.


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:

■ Boolean: Yes | On | No | Off■ Number■ String■ Path

Figure 121 Example of msetrec

msetrec -n <cellName> -r test_rec -S slot_list_int -V ‘[4,5,6]’

Table 112 msetrec return codes

Code Description

31 failed to set record slot



Table 113 describes the CLI configuration parameters.

Table 113 BMC Impact Manager CLI configuration parameters (part 1 of 3)

Option DescriptionDefault value

AuthenticationServerAddress specifies the host name or IP address of an authentication server, optionally followed by a port number, using the following syntax:

Host[/Port]

If no value is entered, the default IAS port number on the local host is used.

ServerName specifies the name of the cell; an alternative for the -n cellName option

Host

ServerLocation the host name or IP address of the cell Host

ServerDirectoryName specifies the name of the cell directory file mcell.dir

ServerPort specifies the TCP/IP port number where the cell listens for all in-bound requests from sources, such as the BMC Impact Explorer, CLIs, and adapters

1828

Encryption enables or disables encryption to and from the cell Yes

EncryptionKey used by encryption process as part of the encoding key

no default

ConnectionSetupTimeOut 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)



ConnectionPortRange 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.

empty

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

2000

MessageBufferCleanupPercentage 10

MessageBufferReconnectInterval the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed

600

MessageBufferKeepWait 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.

3600




Configuring tracing for BMC Impact Manager CLI commands

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.

This line produces tracing to the MCELL_HOME\tmp\mclient\out.txt file.

MessageBufferKeepSent the time, in seconds, to keep sent messages buffered while waiting for an answer

300

MessageBufferResendCount the number of times to resend unanswered messages

1

Figure 122 command to send tracing output to text file

ALL ALL out.txt




A p p e n d i x B
B 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293


Action result event parameters

Action result event parameters

Cell configuration parameters

Table 114 Action result event parameters

Parameter Description Type Default value

ActionResultInlineLimit the size limit, in bytes, for an action result to be 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.

number 4096 (4 KB)

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)

Table 115 Cell configuration parameters (part 1 of 3)


CellDescription used as the initial value of the cell_description slot of the internal MC_CELL_INFO record

string BMC Impact Manager

CellOperationLevel 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.

string 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


Cell configuration parameters

ConnectionPortRangea 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.

string empty

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.

Boolean Yes

ProcessingLimitPercentage

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 cell’s CPU utilization.

number 100

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.

Boolean Yes

ServerDirectoryNamea specifies the name of the cell directory file path mcell.dir

ServerPorta specifies the TCP/IP port number at which the cell listens for all in-bound requests from sources, such as the BMC Impact Explorer console, CLIs, and adapters

number 1828




Cell failover configuration parameters


ServiceModelEnabled specifies whether the cell is an Event Management cell 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.

Boolean Yes

SystemLogDirName specifies the path to the default system-defined log directory

path %H/log

SystemTmpDirName specifies the path to the default system-defined tmp directory

path %H/tmp

a 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 Cell failover configuration parameters (part 1 of 2)

Parameter Description TypeDefault value

CellDuplicateAutoFailOver 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.

Boolean 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





CellDuplicateFailOverStartTimeOut

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 CellDuplicateFailOverStartTimeOut 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.

number 120

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 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

Boolean Yes

CellDuplicateMode specifies the operation mode of the server.

1 = primary server2 = secondary server0 = 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 0

Table 116 Cell failover configuration parameters (part 2 of 2)



Client communication parameters


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 = yearmm = monthdd = dayhh = hour, based on 24-hour clockmm = minutesss = secondsmmmmmm = microsecondss = + or -

Table 117 Client communication parameters


ClientCleanupInterval 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.

number 300

ClientPollTimeOut the maximum time, in milliseconds, the cell waits for a client request before it continues processing

number 200 milliseconds

ClientSendTimeOut the time interval, in milliseconds, that the cell has to send a packet to a client on the lowest communication level


DateFormat 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.

string CIM

SynchronizeTimeOut the maximum time, in milliseconds, the cell waits for synchronization before dropping a connection




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 Date and time format parameters for Solaris (part 1 of 2)


%% same as %

%a locale’s abbreviated weekday name

%A locale’s full weekday name

%b locale’s abbreviated month name

%B locale’s full month name

%c locale’s appropriate date and time representation

%C locale’s date and time representation as produced by date (1)

%d day of month [1,31]; single digits are preceded by zero (0)

%D date as %m/%d/%y

%e day of month [1,31]; single digits are preceded by a space

%h locale’s abbreviated month name

%H hour (24-hour clock) [0,23]; single digits are preceded by zero (0)

%I hour (12-hour clock) [1,12]; single digits are preceded by zero (0)

%j day number of year [1,366]; single digits are preceded by zero (0)

%k hour (24-hour clock) [0,23]; single digits are preceded by a blank

%l hour (12-hour clock) [1,12]; single digits are preceded by a blank

%m month number [1,12]; single digits are preceded by zero (0)

%M minute [00,59]; initial 0 is permitted but not required

%n insert a new line

%p locale’s equivalent of A.M. or P.M.

%r appropriate time representation in 12-hour clock format with %p

%R time as %H:%M

%S seconds [00,61]

%t insert a tab

%T time as %H:%M:%S

%u weekday as a decimal number [1,7], where 1 represents Sunday

%U week number of year as a decimal number [00,53], where Sunday is the first day of week 1

%V 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 weekday as a decimal number [0,6], where 0 represents Sunday

%W week number of year as a decimal number [00,53], where Monday is the first day of week 1

%x locale’s appropriate date representation


Encryption parameters

Encryption parametersTable 119 lists the encryption parameters.

%X locale’s appropriate time representation

%y year within century [00,99]

%Y year, including the century. (for example, 2006)

%Z time zone name or abbreviation, or no bytes if no time zone information exists

Table 119 Encryption parameters


AllowAdapterFrom specifies the adapters within the range of IP addresses

These are adapters that use the BMC Impact Solutions communications protocol.

string 0./0

AllowBrowserFrom specifies the BMC Impact Explorer and the BMC Impact Portal connections within the range of IP addresses

string 0./0

AllowCellFrom specifies the cells within the range of IP addresses string 0./0

AllowCLIFrom specifies the command line interfaces (for example, mkill or mcstat) within the range of IP addresses

string 0./0

AllowConnectionFrom specifies the client within the range of IP addresses that is allowed to connect to a cell

string 0./0

AllowEIFFrom specifies the EIF event sources (for example, a postemsg) within the range of IP addresses

string 0./0

Encryption specifies to use encryption Boolean Yes

EncryptionKey specifies the encryption key string (empty)

ForceEncryption specifies if encryption is to be forced Boolean No

Table 118 Date and time format parameters for Solaris (part 2 of 2)



Event repository cleanup parameters

Event repository cleanup parametersTable 120 Event Repository cleanup parameters (part 1 of 3)


EventAutoClose automatically closes a duplicate event 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.

Boolean Yes

EventDBCleanupDurationLimit the maximum duration, in seconds, of a 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.

number 30

EventDBCleanupInterval the time interval, in seconds, between periodic cleanups of the repository

number 3600, or 1 hourminimum = 60; no maximum

EventDBCleanupPercentage the percentage of free space required at 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.

number 10minimum=5; no maximum

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


Event repository cleanup parameters

EventDBCleanupPreferClosed indicates the preference for cleaning up 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.

Boolean No

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.

number 604800, or 7 days; no minimum; no maximum

EventDBKeepNonClosed the minimum age, in seconds, of non-closed events before they are removed from the repository

number 2592000, or 30 daysminimum value=0;maximum value =4294967295, or 136 years

Table 120 Event Repository cleanup parameters (part 2 of 3)



Event cleanup process

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.

EventDBSize 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 system’s virtual memory and the number of programs running on the system. Contact your system administrator if in doubt.

number 100000minimum value=100;no maximum

EventDBNoCleanupClosed list of classes in which closed events will not be deleted from the repository

string empty

EventDBNoCleanupNonClosed list of classes in which non-closed events will not be deleted from the repository; comma separated

Boolean SMC_STATE_CHANGE

Table 120 Event Repository cleanup parameters (part 3 of 3)



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.


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.

Table 121 Heartbeat parameters


HeartbeatEnabled indicates whether the heartbeat monitoring mechanism is enabled or not

Boolean Yes

HeartbeatInterval the default interval between two beats, if not specified in the data object

number 60

HeartbeatMissedCritical the default number of consecutive missed beats that are needed to generate a critical event, if not specified in the data object

number 3

HeartbeatMissedMinor the default number of consecutive missed beats that are needed to generate a minor event, if not specified in the data object

number 2

HeartbeatMissedWarning the default number of consecutive missed beats that are needed to generate a warning event, if not specified in the data object

number 1



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:

■ 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

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.

Request

Heartbeat

cell 1 cell 2



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 Description

cell target monitored cell name

enable 0 = disabled, 1 = enabled

last_time time last heartbeat was received

interval 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.


Internal cell monitor parameters

Internal cell monitor parameters

KB parameters

Table 123 Internal cell monitors parameters


CellEventEnable 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

Boolean Yes

CellErrorEvents indicates whether an event processing error should produce a special internal event to flag that error, or not

Boolean Yes

CellMetricsEnabled determines whether metrics for cell performance are collected or not

Boolean Yes

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.

number 600

RuleLoopDetect a flag that requires the cell to check for certain conditions that can induce infinite looping of events

Setting this parameter to Yes can cause mild cell performance degradation.

Boolean No

Table 124 KB parameters


KBDirName the path to the active KB directory path the KB directory in the cell’s cell-specific configuration directory

KBRecoveryDirName the path to an alternate KB directory to be used for recovery from catastrophic damage

For more information, see “mrecover—Recovering from a catastrophic data loss” on page 262.

path kbrecovery


Propagation parameters

Propagation parametersThe 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.

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,

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.

DestinationBufferReconnectInterval = *=600

DestinationBufferReconnectInterval = #1=10,#2=10,*=600,SlowCell=1200

Table 125 Propagation parameters (part 1 of 3)


DestinationBufferBaseSize the initial number of messages, or events, retained in the buffer

number 5000

DestinationBufferExpandPercentage percentage of the actual buffer size that the buffer expands when events continue to be propagated after the buffer is full

number 10


Propagation parameters

DestinationBufferSizeLimit 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.

number 0

DestinationBufferReducePercentage minimum percentage of free buffer size required to perform a reduction

number 50

DestinationBufferKeepSenta the time, in seconds, to keep sent events buffered while waiting for an answer

number 300

DestinationBufferKeepWait 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.

number 3600, or 1 hour

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.

number 600

DestinationBufferResendCount the number of times to resend unanswered events

number 1

PropagateBufferBaseSize 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

PropagateBufferExpandPercentage percentage of the actual buffer size that the buffer expands when events continue to be propagated after the buffer is full

number 10




Deprecated MessageBuffer propagation parameters

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.

PropagateBufferSizeLimit 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.

number 0

PropagateBufferReducePercentage minimum percentage of free buffer size required to perform a reduction

number 50

PropagateConfigFileName the name of the propagation configuration file

path mcell.propagate


Table 126 Deprecated MessageBuffer propagation parameters (part 1 of 2)


MessageBufferBaseSize the initial number of messages, or events, retained in the buffer

number 5000

MessageBufferKeepSenta the time, in seconds, to keep sent messages buffered while waiting for an answer

number 300

MessageBufferKeepWait 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.

number 3600, or 1 hour




Reporting client connection parameters

Reporting client connection parametersTable 127 lists the parameters that report on client operations on the cell.

MessageBufferReconnectInterval 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.

number 600

MessageBufferResendCount the number of times to resend unanswered messages

number 1

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

A cell maintains one buffer for each destination. Such buffers have the same size, as set by the parameter.

number 20000

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


Table 127 Reporting client connection parameters


ReportConnectClients reports connect and disconnect of clients

string browser, Console, ImpactExplorer, mcontrol, mkill, mposter, msetmsg, msetrec

ReportModifyClients reports modifications of events by clients

string mposter, msetmsg, msetrec

Table 126 Deprecated MessageBuffer propagation parameters (part 2 of 2)



Service model parameters

Service model parametersTable 128 lists the parameters that control the service model.

State Builder parametersThe 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 128 Service model parameters


ServiceModelPublish 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.

Boolean YES

ServiceModelDirectFeed when ServiceModelPublish is enabled, ServiceModelDirectFeed controls whether or not Service Model Data is accepted through direct feed

Boolean YES

Table 129 State Builder parameters


StateBuildInterval the time interval, in seconds, between two builds of saved states of the cell

number 3600

StateBuildSize the maximum size, in kilobytes, of a transaction 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.

number 1000

StateBuildConfigFileName the StateBuilder configuration file name path statbld.conf

StateBuildAtTerminate indication to run the StateBuilder when the cell terminates

Boolean No

StateBuildRunTimeOut the timeout, in seconds, to consider when waiting for the StateBuilder to terminate

number 600 seconds


Trace parameters

Trace parametersTable 130 Cell tracing parameters (part 1 of 3)


Tracea allows the generation of trace messages Boolean Yes

TraceSrc includes the file and line number in the trace messages Boolean No

TraceConfigFileName location of the file containing the configuration of the trace messages

path mcell.trace

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.

path %T/trace

TraceRuleLevel sets the level of rule execution tracing:

■ 0—no rule tracing and no cell error catch (not recommended)

■ 1—no rule tracing; cell errors are caught in the standard cell trace (default)

■ 2—rule tracing enabled

number 1

TraceRulePhases When rule tracing is enabled, lists the rule phases to be 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.

string ALL


Trace parameters

TraceRuleNames 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.

string ALL:ALL

TraceRuleHeader allows you to configure the header text of the trace messages. You can configure the header text to contain references to parameters, using the following designations to represent the associated parameters:

■ %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 settingTraceRuleHeader=%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

text %F, %L: %P %R: %C #%H:

TraceRuleToXact indicates whether to include rule tracing in the transaction file, as well as in the standard cell trace, in module RULES

Boolean No

Table 130 Cell tracing parameters (part 2 of 3)



Trace parameters

TraceFileSize limit on the size of a trace destination file, expressed in 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.

number

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.

number 0

TraceFileAppend indicates whether to append to existing trace files or empty existing trace files at startup

Boolean Yes


Table 130 Cell tracing parameters (part 3 of 3)



Trace parameters


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

Aaction result event parameters

ActionResultInlineLimit 274ActionResultKeepPeriod 274

actionsdirectory 69

activating maximum tracing for all modules 219adding

slot flags and default values 224slot names and representation types 224

administering remote cellsAdministration View (BIX) 58

Administration Viewmanaging cells from 58metrics collection 165Reload menu 163

administrator activitiesmodifying cell connection settings 132

AllowAdapterFrom 280AllowBrowserFrom 280AllowCellFrom 280AllowCLIFrom 280AllowConnectionFrom 280AllowEIFFrom 280application.properties configuration file 125

Bbin directory 68BIX

defining presentation name search order using ix.properties file 191

extracting presentation name resource files 189

BIX tool tipsenabling and disabling for presentation names 195

BMC Impact Administration servercommand line interface 78configuration files 78, 119customizing BMC IX colors 99default mapping of roles and permissions 83defining client logging 98defining group roles 88defining high availability for Impact Administration

cell 105defining permissions 83defining primary and secondary servers 101defining standalone servers 101editing logging properties 98high availability 101iadmin command 78iadmin command format 80iadmin command options 79iadmin reinit options 104LDAP configuration 109manual editing guidelines 82Master server 102relation to BMC Impact Portal 93Standard server 102supporting remote actions for infrastructure

management 107synchronization properties 103synchronizing with BMC Atrium CMDB 95synchronizing with BMC Impact Portal 93transaction and trace logs 106updating cell information 96updating user information (file-based authentication)

91BMC Impact Explorer

configuration files, event group 185defining presentation name search order using

ix.properties file 191remote cell administration 58

BMC Impact Manager CLIcommon options 211configuration of 269

BMC Impact Portalcommunication and encryption parameters 135configuration parameters 124configuring the ixs.properties file 124

Index 297


BMC Impact Portal (continued)policy file 179report goal line configuration parameters 134

BMC Portalstarting from command line 123starting from Services Window 123starting on UNIX 123stopping from command line 123stopping on UNIX 123URL address 124URL address syntax 124

BMC Software, contacting 2

Ccell

defining high availability for Impact Administration 105

Impact Administration 105cell configuration

creating files for specific cells 30files 43–44modifying cell connection settings 132

Cell Info dialog box (BIX) 165cell names

conventions for 231cell objects, retrieving 251, 267cell parameters

CellDescription 274CellOperationLevel 274CellOperationRelax 274ConnectionPortRange 275ConnectionPortReuse 275ProcessingLimitPercentage 275ServerAllInterfaces 275ServerDirectoryName 275ServerPort 275SystemLogDirName 276SystemTmpDirName 276

cell tracing parameters, list of 293CellDescription 274CellErrorEvents 287CellEventEnable 287CellMetricsEnabled 287CellOperationLevel 274CellOperationRelax 274cells

creating new 231, 264deleting 237extracting state files from 264heartbeats 287naming, mcrtcell command 231obtaining status using mcstat 236posting events 251production, described 25reconfiguring 43, 231

298 BMC Impact Solutions Infrastructure Managemen

cells (continued)recovering data 262remote administration 58retrieving information 238running in foreground 217sending events to 251, 267starting 217starting a specified cell 216starting and stopping 72status 235stopping with mkill 248test, described 25view information 58

CellTickInterval 287class information request 220classes

directory 68CLI, BMC Impact Manager. See BMC Impact Manager CLIclient configuration for passive connections 36client parameters 287

ClientCleanupInterval 278ClientPollTimeOut 278ClientSendTimeOut 278DateFormat 278SynchronizedTimeOut 278

ClientCleanupInterval 278ClientPollTimeOut 278ClientSendTimeOut 278closing an event 267collectors 225

directory 68, 69com.bmc.sms.iwc.component.properties.

generalProperties.properties file property 133com.bmc.sms.iwc.domain.notification.impact.type

property 133com.bmc.sms.iwc.domain.recentitem.

RecentItemsFolderIcon property 133com.bmc.sms.iwc.event.table property 133com.bmc.sms.iwc.event.table.maximumevents property

134com.bmc.sms.iwc.event.table.minimumevents property

134com.bmc.sms.iwc.status. 134com.bmc.sms.iwc.status.table property 133com.bmc.sms.iwc.status.table. existinggroup property 134com.bmc.sms.iwc.status.table.causes property 134com.bmc.sms.iwc.status.table.consumers property 134com.bmc.sms.iwc.status.table.providers property 134com.bmc.sms.iwc.ui.recentitems.maxsize property 133command options

mkill 248mrmerge 265

commandsmccomp 71, 214mcell 216mcfgtrace 217, 218mclassinfo 220

t Guide


commands (continued)mcollinfo 225mcontrol 72, 228mcrtcell 71, 231mcstat 235mdelcell 237mgetinfo 74, 238mgetrec 243mkb 71, 245mkill 248mlogchk 249mposter 251, 255mquery 251, 267mrecover 262mrextract 264mrmerge 265msend 251, 267msetmsg 267msetrec 268reference 210

communication and encryptionAllowAdapterFrom 280AllowBrowserFrom 280AllowCellFrom 280AllowCLIFrom 280AllowConnectionFrom 280AllowEIFFrom 280BMC Impact Portal configuration parameters 135encryption behavior 40ForceEncryption 39mcell.conf settings 39mcell.dir settings 39mclient.conf settings 39

compilingKnowledge Base 214Knowledge Bases 71Knowledge Bases with trace 72version annotations 73

configuration activities for administratorsmodifying cell connection settings 132

configuration filescell 43–44cell-specific, creating 30ix.properties 183ixs.properties 124mcell.conf 28, 31mcell.modify 37–38mcell.propagate 31mcell.trace 51StateBuilder configuration 199

configuration parametersBMC Impact Portal configuration and encryption 135HeartbeatEnabled 284HeartbeatInterval 284HeartbeatMissedCritical 284HeartbeatMissedMinor 284HeartbeatMissedWarning 284

configuringBIX using the ix.properties file 183BMC Impact Portal using ixs.properties 124clients for passive connections 36error tracing for BMC Impact Manager 217, 218reloading cell configuration 43setting cell-specific configurations up 30StateBuilder 199

connectingcells in a protected zone 36

ConnectionPortRange 271, 275ConnectionPortReuse 271, 275consistency checks 249console_policy.prop 179control operations 228conventions

for cell naming 231creating

a new cell 231a new service with mcrtcell 234another service 234configuration files

cell-specific 30Knowledge Bases 71

customer support 3

Ddata classes

directory 69data directory 68data instances

directory 69DateFormat 278deleting

a cell 237events using mquery 261

digital test certificate 194digitally signing .jar files 194directories

bin 68classes 68collectors 68data 68for KB components 69lib 68record 69rules 69structure for Knowledge Bases 66

dynamic datamodel 284

Index 299


EEM cell

production 25test 25

enablingpersistent buffering 255

encryptionbehavior 40mcell.conf settings 39mcell.dir settings 39mclient.conf settings 39

encryption key 39error file

mcell.err 57establishing inbound connection in protected environment

36event classes

directory 69event group

configuration files 185event parameters

EventAutoClose 281EventDBCleanupDurationLimit 281EventDBCleanupInterval 281EventDBCleanuponDateReception 281EventDBCleanupPercentage 281EventDBCleanupPreferClosed 282EventDBKeepClosed 282EventDBKeepNonClosed 282EventDBNoCleanupClosed 283EventDBNoCleanupNoCleanupNonClosed 283EventDBSize 283repository cleanup 281

event propagationenabling 33illustrated 33

event repositorycleanup parameters 281

EventAutoClose 281EventDBCleanupDurationLimit 281EventDBCleanupInterval 281EventDBCleanupOnDateReception 281EventDBCleanupPercentage 281EventDBCleanupPreferClosed 282EventDBKeepClosed 282EventDBKeepNonClosed 282EventDBNoCleanupClosed 283EventDBNoCleanupNonClosed 283EventDBSize 283events

deleting using mquery 261exporting to a flat file 205merging objects 265modifying 267posting with mposter 251propagating using a gateway 31


examplesmccomp 215mcell 217mcfgtrace 219mclassinfo 222mcollinfo 227mcontrol 230mcrtcell 234mcstat 236mdelcell 237mgetinfo config 241mgetinfo connect 243mgetinfo param 242mgetinfo services 242mgetrec command 244mkb 247mkill 249mlogchk 250mquery 261mrecover 263mrextract 264mrmerge 266msetmsg 267msetrec 269

ExportConfigFileName 199ExportDiscarded 199exporting

event data from mcdb by StateBuilder 199events to a flat file 205

ExportTriggerArguments 199ExportTriggerProgram 199

Ffiles

.baroc 68, 69

.load 68, 70

.loadwic 70

.mrl 69

.pkg 69

.wic 69, 70

.xact 72application.properties 125extensions for KB components 69gateway.export 198, 205, 206ixs.properties 124kb_core_resource.properties 188kb_deprecated_resource.properties 189manifest.kb 70, 214mcdb state 198mcell.conf 31mcell.dir 34–??, 211mcell.err error 57mcell.modify 37, 124mcell.propagate 31mcell.trace 51

t Guide


files (continued)mcfgtrace 217, 218propagation configuration 31sim.wic 68sim_decl.wic 68statbld.conf 198, 205statbld.exe 198statbld.trace 198, 207StateBuilder configuration 199trace configuration 51xact transaction 198

filtersusing hidden slots 180

ForceEncryption 39foreground, running cell in 217

Ggateway 31gateway configuration 200gateway.export file 198, 205, 206global records

directory 69obtain a value 243setting a value 268

goal line (reports) configuration parameters 134

HHeartbeatEnabled parameter 284HeartbeatInterval parameter 284HeartbeatMissedCritical parameter 284HeartbeatMissedMinor parameter 284HeartbeatMissedWarning parameter 284heartbeats, cell 287

Iicons

BMC Impact Explorer configuration files for event groups 185

image viewsoverview 124

importing Knowledge Bases 71infrastructure management

Administer subtabs 154audit log 165, 167, 171default service model 140, 142Details subtabs 152editing infrastructure relationships 156GUI view 144, 150high availability cells 160icons 150manually deleting components 174navigation tree 143, 151

infrastructure management (continued)permissions 142registered components 140, 166, 172related components 154remote actions 148, 149, 160, 174remote systems 145roles 142run states 174specifying support files 169support files 146, 169, 171usage reporting 159

interface classesdirectory 69

ix.properties filedefining presentation name search order for BIX 191entry format 190property descriptions 183

ixs.properties fileparameters 136using to customize BMC Impact Portal 124

Jjar files

digitally signing 194Java Web Start application

extracting presentation name resource files 189

Kkb_core_resource.properties file

entry format 192modifying 193

kb_deprecated_resource.properties file 189KBDirName 287KBDirName parameter 287kbmodules argument 74KBRecoveryDirName parameter 287kbsources argument 74kbversion primitive

described 74keys

creating and modifying presentation names 192formats for presentation names 192

Knowledge Basescompiling 71, 214compiling with trace 72creating 71directories 69directory structure 66file extensions 69importing 71index file 70integrating with a unified KB 70KBDirName 287

Index 301


Knowledge Bases (continued)loading 72managing 70parameters

KBRecovery 287retrieving version information with kbversion 74retrieving version information with mgetinfo 74subdirectories 68updating 245versioning 72versioning mechanism 73

Llib directory 68loading

Knowledge Bases 72

Mmanaging

Knowledge Bases 70manifest.kb file 70, 214mccomp command 71, 214

example 215options 214return codes 215syntax 214

mcdb state file 198affects on recovery process 262

mcell command 216example 217options 216return codes 218syntax 216

mcell.conf fileparameter rules 28path substitution parameters 29specifying paths 29

mcell.dir file 211configuring clients for passive connections 36description and usage 34–??example file 35format of entries 34keywords for entries 35rules applied to entries 35

mcell.err file 57mcell.modify file 37, 37–38, 124mcell.propagate file 31

default options 32usage 31

mcell.trace file 51, 217, 218mcfgtrace command 217, 218

example 219options 219


mcfgtrace command (continued)parameters 219syntax 218

mclassinfo command 220adding slot flags and default values 224adding slot names and representation types 224examples 222obtaining a list of classes 223obtaining a list of slot names 223options 220output 220return codes 225syntax 220

mcollinfo command 225example 227options 225output 226return codes 228syntax 225

mcontrol command 72, 228commands

mcontrol 229examples 230options 228reconfiguring a cell 231retrying pending propagations 230syntax 228terminating a cell 230

mcrtcell command 71, 231actions 232creating a service 234creating another service 234examples 234options 233return codes 235syntax 233

mcstat command 235example 236options 236return codes 236

mdelcell command 237deleting a cell 237example 237options 237return codes 238syntax 237

menu, Reload 163merging event objects 265message buffer parameters

MessageBufferKeepSent 289, 290MessageBufferKeepWait 289, 290MessageBufferReconnectIntervalparameters

MessageBufferReconnectInterval 289, 291MessageBufferResendCount 289, 291MessageBufferSize 288, 290, 291

MessageBufferKeepSent 289, 290MessageBufferKeepWait 289, 290

t Guide


MessageBufferReconnectInterval 289, 291MessageBufferResendCount 289, 291MessageBufferSize 288, 290, 291metrics collection, tab for 165mgetinfo command 74, 238

config example 241connect example 243options 238param example 242return codes 243services example 242syntax 238

mgetrec command 243example 244options 244return codes 245syntax 244

mkb command 71, 245examples 247options 245return codes 248syntax 245

mkill command 248command options 248examples 249options 249return codes 249syntax 248

mlogchk command 249examples 250return codes 251syntax 250

modifyingcell connection settings 132

ModuleName parameter 73monitoring passive connections 37mposter command 251, 255

enabling persistent buffering 255options 252return codes 256syntax 252

mquery command 251, 267deleting events 261examples 261options 257output 258return codes 262selecting events with a severity level 261syntax 257

mrecover command 262example 263options 263return codes 263syntax 263

mrextract command 264example 264options 264

mrextract command (continued)return codes 265syntax 264

mrmerge command 265command options 265example 266options 266return codes 266syntax 265

msend command 251, 267msetmsg command 267

closing an event 267examples 267options 267return codes 268syntax 267

msetrec command 268example 269options 268return codes 269syntax 268

Nname keys

creating and modifying 192naming conventions

for cells 231

Oobjects

list of presentation names for 188obtaining a global record value 243obtaining a list of classes 223obtaining a list of slot names 223obtaining status of cell

using mcstat 236options

mccomp 214mcell 216mcfgtrace 219mclassinfo command 220mcollinfo 225mcontrol 228mcrtcell 233mcstat 236mdelcell 237mgetinfo 238mgetrec 244mkb 245mkill 249mposter 252mquery 257mrecover 263

Index 303


options (continued)mrextract 264mrmerge 266msetmsg 267msetrec 268

outputmclassinfo 220mcollinfo 226mquery command 258

Pparameters

ActionResultInlineLimit 274ActionResultKeepPeriod 274BMC Impact Portal configuration 124client 287HeartbeatEnabled 284HeartbeatInveral 284HeartbeatMissedCritical 284HeartbeatMissedMinor 284HeartbeatMissedWarning 284KBRecovery 287mcfgtrace 219Server 287state 287trace, list of 293tracing, configuring 55

passive connections 36client configuration 36monitoring 37

passwordsinvalid, logging on to BMC Portal 122

pending progagationsretrying 230

policy fileBMC Impact Portal 179console_policy.prop 179

posting events to a cell 251presentation names

about 188creating a new resource file 190creating and modifying name keys 192default definitions 189defining 192enabling and disabling BIX tool tips for 195extracting resource files for BIX (Java Web Start) 189files 191key formats 192list of objects with 188resource file locations 188resource file search order 191

ProcessingLimitPercentage 30, 275product support 3production cells

described 25


PropagateBufferSize 289, 291PropagateConfigFileName 290propagating

events using a gateway 31propagation configuration file, mcell propagate 31propagation parameters

PropagateBufferSize 289, 291PropagateConfigFileName 290

protected environmentsclient configuration for passive connections 36monitoring passive connections 37

protected zone, connecting cells in 36

Rreconfiguring

cell files for 43cells with mcontrol command 231

records directory 69Reload menu (BIX)

Administration View (BIX) 163reports

BMC Impact Portal goal line configuration parameters 134

resource filescreating 190extracting for BIX (Java Web Start) 189locations of 188search order 191

retrieve objects from cell 251, 267retrying pending progagations 230return codes

mccomp 215mcell 218mclassinfo 225mcollinfo 228mcrtcell 235mcstat 236mdelcell 238mgetinfo 243mgetrec 245mkb 248mkill 249mlogchk 251mposter 256mquery 262mrecover 263mrextract 265mrmerge 266msetmsg 268msetrec 269statbld 199

RuleLoopDetect 287rules

directory 69

t Guide


Ssaved state 262scripts and programs directory 69selecting

events with a severity level 261server parameters 287

CellErrorEvents 287CellEventEnable 287CellMetricstEnabled 287CellTickInterval 287ConnectionPortRange 271, 275ConnectionPortReuse 271, 275ProcessingLimitPercentage 30, 275RuleLoopDetect 287ServerDirectoryName 275ServerPort 275

ServerAllInterfaces 275ServerDirectoryName 275ServerPort 275service models

class definitions directory 69setting

a value in a global record 268cell-specific configuration up 30

SIM cellproduction 25test 25

sim.wic file 68sim_decl.wic file 68starting cells

specific cell 216with mcell 72

statbld return codes 199statbld.conf file 198, 205statbld.exe file 198statbld.trace file 198, 207State 292state configuration parameters 287

ExportConfigFileName 199ExportDiscarded 199ExportTriggerArguments 199ExportTriggerProgram 199StateHistoryCount 199

state files, extracting 264state parameters 287

StateBuildAtTerminate 292StateBuildConfigFileName 292StateBuildInterval 292StateBuildRunTimeOut 292StateBuildSize 292

StateBuildAtTerminate 292StateBuildConfigFileName 292StateBuilder 198

configuration parameters for event data export 199StateBuildInterval 292StateBuildRunTimeOut 292

StateBuildSize 292StateHistoryCount 199stopping cells

with mkill 72, 248support, customer 3SynchronizedTimeOut 278syntax

mccomp 214mcell 216mcfgtrace 218mclassinfo 220mcollinfo 225mcontrol 228mcrtcell 233mdelcell 237mgetinfo 238mgetrec 244mkb 245mkill 248mlogchk 250mposter 252mquery 257mrecover 263mrextract 264mrmerge 265msetmsg 267msetrec 268

SystemLogDirName parameterdescribed 276

SystemTmpDirName parameterdescribed 276

Ttechnical support 3terminating a cell 230test cells

described 25test certificate, digital 194tool tips

BIX, enabling and disabling 195trace configuration file 51

configuring 51parameters 51

Trace parameter 293trace parameters

list of 293trace, disable encryption to 41TraceConfigFileName parameter 293TraceDefaultFileName parameter 293TraceFileAppend parameter 295TraceFileHistory parameter 295TraceFileSize parameter 295TraceRuleLevel parameter 293TraceRuleToXact parameter 294TraceSrc parameter 293

Index 305


tracing parametersconfiguring 55Trace 293TraceConfigFileName 293TraceDefaultFileName 293TraceFileAppend 295TraceFileHistory 295TraceFileSize 295TraceRuleLevel 293TraceRuleToXact 294TraceSrc 293

Uupdating the Knowledge Base 245usage reporting 159

VVersionID parameter 73versioning

compiling 73Knowledge Bases 72mechanism 73retrieving version information with kbversion 74retrieving version information with mgetinfo 74

Xxact transaction file 198

t Guide

*97717**97717**97717**97717*

*97717*

BMC Impact Solutions Infrastructure Management Guideatmgmicrosoft.free.fr/depot/at/BMC doc/BMC...

Documents

Transcript of BMC Impact Solutions Infrastructure Management Guideatmgmicrosoft.free.fr/depot/at/BMC doc/BMC...