BMC Impact Solutions 7.3 - Infrastructure Management Guide PDF

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

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

Address
BMC SOFTWARE INC

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or

800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada

Telephone
(01) 713 918 8800
Copyright 20062009 BMC Software, Inc.

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

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

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

Have the following information available so that Customer Support can begin working on your issue immediately:
s
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
BMC Impact Solutions Infrastructure Management Guide
Contents
Chapter 1
Managing BMC Impact Manager cells
23
General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Production cells and test cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Creating cell-specific configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
About mcell.dir, the cell directory file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Managing high availability cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Automatic failover process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Automatic switchback process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Manually failing over to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Manually switching back to the secondary server . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Explicitly connecting a CLI to a selected high availability cell server. . . . . . . . . . 47
Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 56
Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 58
Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Problem: The primary and secondary servers for my high availability cell are in
active mode simultaneously or are unsynchronized. . . . . . . . . . . . . . . . . . . . . . 63
Chapter 2
Managing a Knowledge Base
65
Knowledge Base structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Contents
About the unified Event Management and Service Impact Management

Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Knowledge Base index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Managing a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Integrating a unified KB with pre-7.2 cell definitions . . . . . . . . . . . . . . . . . . . . . . . 70
Creating a new production or test Knowledge Basemcrtcell . . . . . . . . . . . . . . . 71
Importing Knowledge Base information into a cellmkb . . . . . . . . . . . . . . . . . . . 71
Compiling a Knowledge Basemccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Loading a Knowledge Base into a running cellmcontrol . . . . . . . . . . . . . . . . . . . 72
Implementing changes to a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Versioning a Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Retrieving KB version information in rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Retrieving KB version information by using a commandmgetinfo . . . . . . . . . . 74
Chapter 3
Managing the BMC Impact Administration server
77
Configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 81
Guidelines for manual edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Defining permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Full Access role permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Adding customized role/permission mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Defining group roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
File-based authentication: updating user information . . . . . . . . . . . . . . . . . . . . . . . 91
Adding role names to the cells KB definition files. . . . . . . . . . . . . . . . . . . . . . . . . . 93
Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . 93
Synchronizing cell information with BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . 95
Updating cell information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Defining client logging for the iadmin script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Customizing colors for severities, statuses, and priorities. . . . . . . . . . . . . . . . . . . . 99
IAS Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Customizing the IAS thread pool handling IAS Clients . . . . . . . . . . . . . . . . . . . . 100
Defining standalone, primary, and secondary BMC Impact Administration
servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Defining a failover configuration for the Impact Administration cell . . . . . . . . . 105
Transaction and trace logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Example trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Configuring BMC Impact Administration server to support remote actions. . . 107
Configuring Lightweight Directory Access Protocol for BMC Impact
Administration server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Problem: Cell_info.list synchronization error during manual configuration of an
IAS failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
BMC Impact Solutions Infrastructure Administration Guide
Chapter 4
Managing the BMC Impact Portal
121
Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . .
Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . .
Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . .
Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . .
smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . .
smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . .
internal.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122
122
123
123
124
124
124
124
125
126
127
127
129
130
130
131
132
132
133
134
136
Chapter 5
139
Working with Infrastructure Management
Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . .

Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . .
Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying and understanding the Details and Administer tab data . . . . . . . . .
Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How a product component registers and communicates with the IAC . . . . . . .
Contents
140
142
142
142
144
145
146
148
149
150
152
156
157
158
159
160
163
164
165
165
165
169
172
172
Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 6
Managing the BMC Impact Explorer (BMC IX) console
177
Defining property files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

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

Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Creating a new presentation name resource file . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Digitally signing a .jar file with a digital test certificate. . . . . . . . . . . . . . . . . . . . . 194
Enabling or disabling presentation names in
BMC Impact Explorer tool tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Chapter 8
Configuring StateBuilder and gateways
197
Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

StateBuilder configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Exporting events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Modifying a statbld.conf file to export events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring tracing for StateBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Trouble-shooting the StateBuilder process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Appendix A
BMC SIM and EM CLI Reference
209
BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 211
Configuring CLI authentication through BMC Impact Administration Server . 212
BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 213
mccompCompiling rules in the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . 214
mcellStarting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
mcfgtraceConfiguring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
mclassinfoRequesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
mcollinfoGetting information about a specific collector . . . . . . . . . . . . . . . . . . 225
8
mcontrolPerforming cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . .

mcrtcellCreating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mcstatReturning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mdelcellDeleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mgetinfoRetrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . .
mgetrecObtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mkbUpdating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mkillStopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mlogchkPerforming consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mposter and msendManaging data and events . . . . . . . . . . . . . . . . . . . . . . . . .
mqueryRetrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mrecoverRecovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . .
mrextractExtracting cell state files to create new state files . . . . . . . . . . . . . . .
mrmergeMerging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetmsgModifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetrecSetting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . .
BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B
mcell.conf file parameters
228
231
235
237
238
243
245
248
249
251
257
262
264
265
267
268
269
272
272
273
Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deprecated MessageBuffer propagation parameters. . . . . . . . . . . . . . . . . . . . . . .
Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
274
274
276
278
280
281
283
284
287
287
288
290
291
292
292
293
Index
297
Contents
10
Figures
ConnectionPortRange syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Distributed event management using event propagation . . . . . . . . . . . . . . . . . . . . . . 33
Format of an entry in the mcell.dir file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Example of the mcell.dir file and its entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Passive connection format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Data object specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
mcell.modify file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Masking syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Format of configuration line in mcell.trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Knowledge Base directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Output from mgetinfo kbsources argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Relation among users, groups, roles, and permissions . . . . . . . . . . . . . . . . . . . . . . . . . 82
Excerpt from ldap_configuration.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Infrastructure Management navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Default service model BMC Impact Solutions (with active services) . . . . . . . . . . . . 144
Edit Relationships dialog with Edit This Relationship subdialog . . . . . . . . . . . . . . . 156
Actions right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
High availability (HA) view: two cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Actions right-click menu for OVO adapter cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
default.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Operator.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Default policy file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Listing of the contents of a keystore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Parameters used to print event in BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Example of printed events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Command to configure the export file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
gateway.export file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
gateway.explore file output for new events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
gateway.explore file output for modified events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
mccomp syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
mccomp example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Example output for mccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
mcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Starting a cell as a service on windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Starting the BMC Impact Manager service on Microsoft Windows . . . . . . . . . . . . . 217
mcfgtrace syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
mcfgtrace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
mclassinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figures
11
Raw output format for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

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

mkb command output on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mkill syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mlogchk syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mlogchk message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mposter syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msend syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definition changes using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling persistent buffering using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error message if buffers files are not writable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mquery syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of raw output specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verbose mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End of form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mquerySelect events with severity status . . . . . . . . . . . . . . . . . . . . . .
Example of mquerySelect events from collector . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting events using mquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mrecover syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fixing a broken cell using mrecover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mrextract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mrextract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mrmerge syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of mrmerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetmsg syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of msetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
command to send tracing output to text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures
248
248
248
249
249
250
250
250
251
252
252
254
255
255
256
257
258
258
259
259
261
261
261
263
263
264
264
265
266
267
268
269
272
285
13
14
Tables
BMC Impact Solutions configuration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Cell configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Substitution parameters for %X in path value parameters . . . . . . . . . . . . . . . . . . . . . . 29
Default mcell.propagate options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IP Address parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Files for cell reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
MC_CELL_METRIC slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Default values for client parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
MC_CELL_CLIENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
MC_CELL_MODIFIED_EVENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Trace configuration file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
MC_CELL_PROCESS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
BMC Impact Manager exit codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
SIM_NOTIFICATION_REGISTRY dialog box fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Knowledge Base subdirectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Knowledge Base file extensions and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configurable IAS files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
iadmin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
BMC Impact Explorer user group mapping to functionality . . . . . . . . . . . . . . . . . . . 83
Groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Cell entry format in cell_info.list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Server logging properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
IAS status monitoring properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
IAS thread pool properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
IAS synchronization properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
mcell.dir entries for a failover pair of Impact Administration cells . . . . . . . . . . . . . 105
IAS log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
LDAP configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Event operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Event Table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Status table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Report parameters (application.properties file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Report parameters (internal.properties) file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
application.properties file in smsIwc directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
application.properties file in smsConsoleServer directory . . . . . . . . . . . . . . . . . . . . . 134
aggregator.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
internal.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Supported application groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Icon listing for infrastructure management model . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Slot values: Details: General subtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Tables
15
Edit Relationship dialog: field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Edit This Relationship subdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Audit log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Audit log IAS properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Slots for specifying support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
run_state values for components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Component state and menu options for a normal or primary cell in a high
availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Component state and menu options for a secondary cell in a high availability
configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Components and actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
default.console_policy.prop parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Property descriptions from ix.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Event severity levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Event priority levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
xml files that define user interface elements in BMC IX . . . . . . . . . . . . . . . . . . . . . . . 186
Presentation names for BMC Impact Solution interfaces . . . . . . . . . . . . . . . . . . . . . . 188
Presentation name key formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
StateBuilder file name conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
statbld.conf Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Gateway configuration parameter predefined variables . . . . . . . . . . . . . . . . . . . . . . . 201
Gateway Configuration Parameter Text Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
gateway.export file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
BMC Impact Manager CLI command descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Common options for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Common return codes for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
mccomp options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
mcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
mcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
mcfgtrace option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
mcfgtrace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
mclassinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Type of slot value for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Reported facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Class flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Information amount limitation options for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . 222
mclassinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
mcollinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Information amount limitation options for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . 227
mcollinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
mcontrol option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
mcontrol controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Files for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
mcrtcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
mcrtcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
mcstat option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
mdelcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
16
mdelcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

To configure the BMC Impact Solutions environment, you configure the following
components after installation:
s
s
s
BMC Impact Manager cell

BMC Impact Explorer
BMC Impact Portal
Table 1 outlines the tasks that configure these components.

Table 1
BMC Impact Solutions configuration process
Task Description
1
Component
(optional) Configure the BMC Impact Portal. BMC Impact Portal
For more information, see

Chapter 4, Managing the
BMC Impact Portal
BMC Portal Getting Started
Configure BMC Impact Manager cells.
BMC Impact Manager
Chapter 1, Managing BMC

Impact Manager cells
Define user groups for access to the console BMC Impact

functions and objects.
Administration Server

BMC Impact Administration
server
Distribute the BMC Portal URL address so

users can install consoles.
BMC Portal Getting Started
s
s
s
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 Impact Portal
BMC Impact Solutions

Installation Guide
(optional) Customize BMC Impact Portal.
(optional) Customize BMC Impact Explorer. BMC Impact Explorer

BMC Impact Explorer (BMC
IX) console
(optional) Configure the StateBuilder, which BMC Impact Manager

manages the persistent storage of events.
Chapter 8, Configuring
StateBuilder and gateways
(optional) Customize the labels used in the

console interfaces.
Chapter 7, Defining
presentation names
s
s
s
BMC Impact Portal

BMC Impact Manager
BMC Impact Service
Model Editor

BMC Impact Portal
After you configure BMC Impact Manager, BMC Impact Portal, and BMC Impact
Explorer, you are ready to implement event management and service impact
management. For information, consult the following resources:
24
Production cells and test cells
Event management
For information about setting up adapters to collect events, see the BMC Impact
Event Adapters User Guide.
For information about setting up dynamic data, policies, event groups, and
image views, see the BMC Impact Solutions Event Management Guide.
For information about defining event data, writing event management rules,
defining collectors, or creating actions, see the BMC Impact Solutions Event
Management Guide.
Service impact management

For information about monitoring service impact management, see BMC Impact
Solutions Service Impact Management Guide.
For information about defining service models, see the BMC Impact Solutions
Service Modeling and Publishing Guide.

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

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

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

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

The more you customize your cell to fit your needs, the more efficiently the cell
works. All configuration tasks are optional. Table 2 describes the cell configuration
tasks.
Table 2
Task
Description
For more information, see
Create additional cells.
mcrtcellCreating a new cell on

page 231
When you install BMC Impact Manager on a system, one cell is

installed. You can create additional cells by running the
mcrtcell command.
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
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
If you created multiple cells for an environment, configure a high BMC Impact Solutions Getting Started
availability cell or cells.
Guide
Managing high availability cell
servers on page 44
Events can be processed locally or selectively propagated to other Configuring event slot
cells. To configure the event slots that must be propagated when propagation on page 31
they are changed configure the propagation configuration file.
If inbound connections to the cell are disallowed in a protected

environment, the connection has to be established within the
protected zone to allow a connection between an external client
and a cell in the protected zone.
To add a time stamp to a slot so that the date and time is recorded Configuring slots for time
when the slot is changed, configure the mcell.modify file.
stamping on page 37
If desired, you can encrypt communication among the various

BMC Impact Solutions components.
Configuring encryption on
page 38
Set the default client parameters executing CLI commands.
BMC Impact Manager CLI

configuration on page 269
Configuring passive connections

on page 36
27
Configuring mcell.conf parameters

The mcell.conf configuration file installed with the cell allows it to run without any
additional configuration. You can change the configuration parameters in the
mcell.conf file to customize the cell for your particular IT infrastructure and
environment. You can override some parameters using command line arguments
when you start the cell. For more information, see mcellStarting a cell on
page 216.
To configure the mcell.conf file using a text editor

1 Open the mcell.conf file in a text editor.
The default location is MCELL_HOME\etc.
2 Create line entries using the format Parameter=Value based on the syntax rules
described in Rules for cell configuration parameter syntax.
3 Save the changes.

4 Either reload the cell configuration or restart the cell for the changes to go into
effect. For more information, see Reloading cell configuration on page 43.
Rules for cell configuration parameter syntax

s
One parameter per line, in the form: Parameter=Value

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

file parameters.
28
Specification of path values

Parameters that have path values contain the string fileName or dirName, for
example TraceConfigFileName or SystemLogDirName.
Path values can be stated as:
s
absolute pathstarts with slash (/) or backslash (\), or on Windows, with a drive
designator (for example, D:)
runtime relative pathstarts with ./ or ../. The path is relative from the cells
working directory. The working directory is the root directory (/) when it runs as a
daemon or a service. When running in foreground, it is the directory where mcell
is started.
configuration relative pathall other path values are relative from the cells
configuration directory, or, for program paths, from the kb\bin directory.
Path values can contain the substitution parameters $VAR or %X. Any $VAR parameter
is substituted by the value of the environment variable VAR. Table 3 lists the possible
%X substitution parameters.
Table 3
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
Modifying SystemLogDirName, SystemTmpDirName, and

KBDirName
With the cell configuration parameters SystemLogDirName and SystemTmpDirName,
users can specify alternative path locations for the system defined log and tmp
directories. Their default values are %H/log and %H/tmp. To enable file name
specifications that refer to these alternative locations, use the substitution parameters
%L for the log and %T for the tmp directory. They are substituted by the specified path
to the log and tmp directory, respectively.
29
Creating cell-specific configuration files
If you change the default value for the SystemLogDirName parameter or the
KBDirName parameter in the mcell.conf file, you must also change the value in the
statbld.conf file. If you fail to do this, the cell loses persistency and the mcdb file is not
created, because the StateBuilder is configured from statbld.conf file and has no input
from the mcell.conf file. As a result, StateBuilder does not know where to find the log
files or the KB directory it requires.
ConnectionPortRange syntax
Figure 1 shows the syntax of ConnectionPortRange.
Figure 1
ConnectionPortRange syntax
PortRange = PortSequence{, PortSequence}

PortSequence = Port[-Port]
A range is a number of sequences, each of which is a consecutive range of ports. The

cell attempts to access all ports in the specified order. The default is to use any of the
ephemeral ports.
For example,
s
18281840 specifies a range of ports 1828 through 1840
1828, 1829, 1840 specifies the sequence of ports 1828, 1829, and 1840
Creating cell-specific configuration files

By default, one set of configuration files is installed during installation of the BMC
Impact Manager. These files are located in the MCELL_HOME\etc directory and
multiple cells on a host can use them. You can also create unique configuration files
for individual instances (cells) as needed.
To create cell-specific configuration files

1 Copy the configuration file that you want to be unique to the
MCELL_HOME\etc\cellName directory. cellName represents the name of the cell.
2 Using a text editor, edit the configuration file and customize it for that cell and
save it.
You can copy and edit any configuration file located in the MCELL_HOME\etc
directory.
3 Either reload the cell configuration or stop and start the cell so that the changes
take affect.
30
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:
s
$MCELL_HOME/etc/CellName contains cell-specific configurations (including the
Knowledge Base)
s
$MCELL_HOME/log/CellName contains the cell transaction logs and persistent state
of the cell
s
$MCELL_HOME/tmp/CellName contains the cells temporary files
High availability cells use the cell-specific directories, but the names of the log and
tmp directories are suffixed with # followed by the server number, 1 for the primary
server and 2 for the secondary server. The names become:
s
s
s
s
$MCELL_HOME/log/CellName# 1
$MCELL_HOME/log/CellName# 2
$MCELL_HOME/tmp/CellName# 1
$MCELL_HOME/tmp/CellName# 2

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

hierarchy
mc_modhist
propagates changes to the mc_modhist up (forward) within the cell hierarchy
This is a system defined slot that requires such propagation.

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

hierarchy
repeat_count
propagates changes to repeat_count up (forward) within the cell hierarchy
severity
propagates severity value changes up (forward) within the cell hierarchy
status
propagates status value changes in both directions, backward and forward, in the bf
cell hierarchy
If you have multiple instances of BMC Impact Manager installed, you might want to
use event propagation to distribute the event processing load among the cells or to
back up events on another cell for failover.
Figure 2 on page 33 illustrates a cell network that is collecting and processing
numerous events in a distributed environment.
32
Figure 2
Distributed event management using event propagation

cell
Some events are propagated

for management by other cells
in the cell network.
cell
cell
cell
cell
cell
event
sources
cell
event
sources
event
sources
event
sources
In this illustration, the lower-level cells process the source events and then propagate
(or forward) the events on to higher-level cells according to a Propagate rule or an
Event Propagation policy. As events pass through a series of cells, the cells discard
unneeded events, identify and leave behind unimportant events, and resolve some of
the problems reported by other events.
To enable event propagation, perform the following tasks:
s
s
s
s
enable cell-to-cell communication in mcell.dir

configure propagation parameters in mcell.conf
specify the slots whose modification has to propagate in mcell.propagate
either write a Propagate rule or define an Event Propagation policy
How unpropagated events are buffered

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

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

Attribute
Description
Type
type of component. It can be

s cell BMC Impact Manager cell name
s gateway.typeGateway of type type
s gateway.jServer - predefined jServer gateway type
s gateway.portal - BMC Impact Portal
s 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.
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).
EncryptionKey
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.
Example of the mcell.dir file

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

The following conventions apply when creating entries for the mcell.dir file:
s
Cells may be grouped into separate cell files readable only by certain users or
groups (domains).
35
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.

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

On the client side, the mcell.dir file has to indicate that the destination cell is located in
an isolated protected zone.
To configure the client for passive connections

1 Open the mcell.dir file in a text editor.
2 For the destination cell, replace Host:Port with 0 as shown in Figure 5.

Figure 5
cell
Passive connection format

cellName EncryptionKey 0
3 Save the changes.

4 Either reload the cell configuration or stop and start the cell.
36
Configuring slots for time stamping
When a cell or gateway client needs to connect to an isolated destination cell, it

cannot establish a connection because it does not have the IP address and port
number of the cell. Instead, the cell or gateway client registers the destination and
waits for a connection from it.
Configuring a cell for passive connections

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

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

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

Each event has an mc_modification_date slot that contains the time stamp of the
last modification of the event. Only select slot modifications set this time stamp. To
add a time stamp to a slot so that the date and time is recorded when the slot is
changed, you must configure the mcell.modify file. The mcell.modify file contains the
names of the slots that affect the mc_modification_date slot. When one of the slots
listed in the mcell.modify file is modified, the mc_modification_date slot is set with
the time stamp of this change.
37
Configuring encryption
To configure slots for time stamping

1 Open the mcell.modify file in a text editor.
2 Create a line entry containing the name of the slot whose modification is to be time
stamped. Figure 7 shows an example of the mcell.modify file.
Figure 7
mcell.modify file
# Configuration of slots affecting mc_modification_date when modified

# Format :
# SlotName
# Special name : CLASS : specifies all class-specific slots
status
severity
mc_priority
repeat_count
CLASS
When CLASS is used as a slot name, all class-specific slots or slots not defined in the
base class CORE_EVENT update the mc_modification_date slot with a time stamp.
3 Save the changes.

4 Either reload the cell configuration or stop and start the cell.
You can encrypt communication among the various BMC Impact Solutions
components. To enable encryption, make the appropriate settings in the following
locations:
s
s
s
s
38
the cells configuration file mcell.conf

the CLI configuration file mclient.conf
the BMC Impact Administration server used by BMC Impact Explorer
the cell directory file, which is MCELL_HOME\etc\mcell.dir by default
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:
s
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
s
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:
s
Characters of the encryption key are grouped in pairs. If the string has an odd
number of characters, the last character is ignored.
Each pair is converted to an 8-bit value. The first character of the pair determines
the four most significant bits, the second character determines the four least
significant bits.
39
A character in the hexadecimal range (0-9, A-F, a-f) is converted to the

corresponding hexadecimal value (for example, 8 gives the value 8, B gives the
value 11).
Any other character is converted to its ASCII code modulo 16.
Encryption behavior between cells and components

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

You must specify the encryption key if the following conditions apply:
s
s
you execute the CLI command on a host without an mcell.dir file

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

A client is allowed to connect to the cell if its IP address matches the general
AllowConnectionFrom as well as the client type-specific Allow*From.
Figure 8 shows an example of masking syntax.
Figure 8
Masking syntax
AddrMaskList = AddrMask {':' AddrMask}

AddrMask = Addr ['/' Mask]
Addr = Nr '.' [Nr '.' [Nr '.' [Nr]]]
Mask = Addr | Nr
Nr = 0..255
41
The following conventions apply:

s
s
s
s
An abbreviated Addr or Mask is expanded with zeros.

A numeric Mask (number without trailing dot) gives the number of 1 bit.
An omitted Mask defaults to all bits set to 1.
A connection is allowed if the source address ANDed with the Mask matches Addr
ANDed with the Mask.
When the Mask is all zeros, any address matches regardless of the value of Addr. For
all Mask bits whose value is one (1), the equivalent bits in Addr must match the
equivalent bits in the source address.
Table 5 lists the IP address parameters.
Table 5
IP Address parameters
Parameter
Description
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
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:
s
s
s
42
127.0.0.1
127.0.0.1/32
127.0.0.1/255.255.255.255
Reloading cell configuration
When you specify more than one address per mask pair, a system that matches at
least one of the pairs can accept a connection.
Connection attempt using invalid encryption key

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

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

To trigger the reconfiguration, perform one of the following actions:
s
Send a hang-up signal on UNIX.
Run the mcontrol command on UNIX or Windows. For information about the
mcontrol command, see mcontrolPerforming cell control operations on
page 228.
Table 6 lists the specific instances in which the reconfigure feature can be used and
the effect that results from its use.
Table 6
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
43
Managing high availability cell servers
Table 6
Files for cell reconfiguration (part 2 of 2)
Type
Name/Directory
Result of reconfiguration
KB program
kb\classes
\kb\rules
\kb\lib
\kb\bin
KB data
kb\data
\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.
Managing high availability cell servers

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

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

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

If there is a problem with the primary server, a failover to the secondary server is
required. By default, failover is automatic; however, if the cell is configured with
CellDuplicateAutoFailOver=No, this failover must be performed manually.
To manually fail over from a primary server to a secondary server

1 Terminate the primary server (if it is still running) by entering: mkill -n
CellName#1
WARNING
You must explicitly include the #1 suffix after the cell name or the mkill command will
terminate the secondary cell if the command cannot connect to the primary cell.
2 Start the secondary cell server by entering: mcontrol -n CellName#2 start
Manually switching back to the secondary server

After a primary cell server has been repaired, a switchback operation is required to
re-activate it. By default, switchback is automatic; however, if the cell is configured
with CellDuplicateAutoSwitchBack=No, switchback must be performed manually.
To manually switch back from a secondary server to a primary server

1 Clear the primary server log directory by entering the appropriate command for
your operating system:
s
s
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:
s
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.

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

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

Event processing metrics are internal counts maintained on cell performance
categories in connection with event processing. These metrics count the following
items:
s
s
s
s
s
s
number of events received, including erroneous ones

number of events containing errors
number of events dropped by rules (Filter, Regulate)
number of events removed from the event repository during cleanup
number of events propagated, including sendto
number of events added to the event repository, that is, entering the permanent
context
Calculation is performed on a 60-second basis, so every minute the counters are

restarted. Counts from the last five minutes are retained. Running counters are reset
only on demand.
47
Monitoring event performance
The resulting metrics are:

s
s
s
short termtotal count of the last complete one-minute interval

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

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

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

msetrec
ReportModifyClients
mposter, msetmsg, msetrec
Every parameter corresponds to a reporting clients set. Such a set has a positive and a
negative list. Clients that belong to the positive list will have their operation reported
while operations performed by clients on the negative list will not be reported.
Clients that are not named in the parameter are considered to be on the default list.
The default list initially is the negative list. The default list can be modified through a
special setting of the parameter.
A value for a reporting configuration parameter consists of a comma separated
sequence of client names. Every client name can be prefixed with a minus sign (-) or
a plus sign (+). The client name prefixed with the minus sign (-) is added to the
negative list. When not prefixed, or prefixed with a plus sign (+), it is added to the
positive list.
49
Configuring cell tracing
The special value ALL in place of a client name refers to the default. Including ALL or
+ALL modifies the default list so it becomes the positive list. With -ALL, the default list
is the negative list. Both parameters could include -ALL, as this is the default setting
for clients that are not explicitly mentioned.
The superclass for client operation related events is MC_CELL_CLIENT. Table 9 lists the
slots.
Table 9
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
There are three subclasses of this class:

s
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.
s
MC_CELL_DISCONNECT to represent a disconnect.
Another class, MC_CELL_MODIFIED_EVENT, represents the operation of modification

of an event. Table 10 lists the slots.
Table 10
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 cell tracing

To set up cell tracing, configure
s
s
the trace configuration file, mcell.trace

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

<Level>
<Switch>
<Destination>
<Destination>
Table 11 lists the parameters that must be defined in a configuration line.

Table 11
Trace configuration file parameters (part 1 of 2)
Parameter
Description
Destination
destination file name or predefined value for the selected trace messages or
switch
predefined values:
nodisables these tracing messages
consolesends to the console device
stderrsends to standard error stream
Levela
message severity value level

predefined values:
s
s
s
FATAL
ERROR
WARNING
s
s
INFORM
VERBOSE
51
Configuring a destination for cell trace output
Table 11
Trace configuration file parameters (part 2 of 2)
Parameter
Description
Modulea
name of module, each of which corresponds to a particular category of

information, such as filtering or configuration; values are as follows:
s
s
s
s
s
s
s
s
s
s
s
s
s
ACTION
COLLECT
COLLMAP
CONFIG
CONTROL
DATAPROC
DBDATAID
DBEVTID
DBEVTTM
EVTLOG
EVTPROC
EXPORT
FILTER
s
s
s
s
s
s
s
s
s
s
s
s
HEARTBEAT
INTEVT
MC2TEC
MCBAROC
MESSAGES
METRIC
PROPAGATE
QUERY
RECOVERY
RECTRL
REGEX
REGULATE
s
s
s
s
s
s
s
s
s
s
s
s
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
You can also specify ALL or * (wildcard) for these parameters.
Configuring a destination for cell trace output

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

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

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

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

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

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

s
configure which module/level combinations of trace messages will be produced as

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

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

The textual representation of the log message log_text uses the originating cell's
local message catalog.
54
Event processing errors
Configuring trace messages to be produced as log events

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

When an error occurs during the processing of an event, the cells trace displays an
error message. It also generates an internal event of class MC_CELL_PROCESS_ERROR,
with the slots listed in Table 12.
55
Automatic notification of trace configuration changes
Table 12
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
Automatic notification of trace configuration changes

The cell automatically generates the following MC_CELL_LOG_CHANGED event when
trace configuration is modified for a cell:
MC_EV_CLASS: MC_CELL_LOG_CHANGED ISA MC_CELL_CONTROL
DEFINES {
log_module: STRING;
-- Name of the module
log_level: MC_LOG_LEVEL; -- Message level
log_destination: STRING; -- Destination file name
};
END
If the modification applies to all modules, then log_module=ALL.

If the modification applies to all message levels, then log_level=ALL.
The log_destination slot contains the full path to the destination file, in normalized
(UNIX) form. Other possible values are:
s
noindicates disabling
stderrindicates redirection to the standard error stream
consoleindicates redirection to the console terminal
Interpreting cell execution failure codes

When the cell runs as a daemon or a service, it has no standard output or error
stream. Tracing that is configured to go to stderr will be redirected to a file in this
case. The path for that file can be configured in mcell.conf. The default is
MCELL_HOME\tmp\cellName\trace.
56
Interpreting cell execution failure codes
If the cell service setup fails, an error file, mcell.err, is generated. Additional service
setup failures can be appended to the original file, resulting in a file content of
multiple lines. Normally, each line corresponds to one failed service setup. This error
file contains exit codes specific to BMC Impact Manager.
Table 13 lists the exit codes for BMC Impact Manager.
Table 13
BMC Impact Manager exit codes
Code
Description
invalid command line options used
bad home directory specification through option -l
no home directory could be determined
specified home directory is invalid
internal initialization failure
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
57
Using the BMC IX Administration view to manage cells
Using the BMC IX Administration view to

manage cells
You can also manage cells by using a pop-up menu in the navigation pane of the
Administration view of BMC Impact Explorer to perform the following tasks:
s
s
s
connect and disconnect a cell

view cell information
register for state change events
For more information on using BMC Impact Explorer, see Chapter 6, Managing the
BMC Impact Explorer (BMC IX) console and the BMC Impact Solutions Event Management
Guide.
Connecting or disconnecting a cell

Use the Disconnect and Connect menu commands to connect or disconnect a cell from
BMC Impact Explorer.
To connect or disconnect a cell

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

Use the View Manager Info menu command to view information about and the
metrics associated with the cell selected.
To view cell information

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

BMC Impact Manager can generate events that notify you of changes to components
in the SIM service model. These events are called SIM notification events. The four
types of SIM notification events are
SIM_COMPONENT_CHANGE
SIM_COMPONENT_DELETE
SIM_COMPONENT_OVERWRITE
SIM_RELATIONSHIP_CHANGE
SIM_RELATIONSHIP_DELETE
NOTE
In the mc_sm_notify.baroc file under mcell_home/etc/cellName/kb/classes, you can view the
definitions of the SIM_NOTIFICATION_EVENT base class and the event classes
SIM_COMPONENT_CHANGE, SIM_COMPONENT_DELETE, SIM_COMPONENT_OVERWRITE,
SIM_RELATIONSHIP_CHANGE, and SIM_RELATIONSHIP_DELETE.
The SIM_COMPONENT_DELETE and SIM_RELATIONSHIP_DELETE events are generated

when you remove a configuration item or an impact relationship from the published
service model. The SIM_COMPONENT_CHANGE and SIM_RELATIONSHIP_CHANGE events
are generated when a configuration item or an impact relationship is altered by the
cell because of a change in status or priority.
BMC Impact Manager generates these notification events upon request by a client.
For example, the BMC Impact Portal can register to receive notification events just as
a gateway client can. Another BMC Impact Manager or even the BMC Impact
Manager containing the SIM model can register to receive the notification events.
59
The following slots are reported:

s
Slots for configuration item:

status
manual_status
computed_status
self_status
impact_status
manual_status_comment
manual_status_requestor
consolidate_function
root_causes
schedule_status
cost
self_priority
impact_priority
computed_priority
maintenance_mode
Slot for relationships:

true_impact
To register for notification events, you create a SIM_NOTIFICATION_REGISTRY

instance in the cell, telling it which notification events to look for and which clients to
forward the events to.
You perform this procedure through the BMC IX interface or through the mposter
CLI.
NOTE
Refer to the BMC Impact Solutions: Knowledge Base Development Reference for mposter examples
that show how to register for notification events.
To register for notification events in the BMC IX

1 In the Adminstration tab, expand the cell for which you want to create a
SIM_NOTIFICATION_REGISTRY data instance.
2 Expand the DATA folder.

3 Expand the MC_CELL_DATA folder.
60
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
s
s
s
s
s
notification_mode
SIM_COMPONENT_CHANGE
SIM_COMPONENT_DELETE
SIM_COMPONENT_OVERWRITE
SIM_RELATIONSHIP_CHANGE
SIM_RELATIONSHIP_DELETE
specifies how slot values that have not changed are reported in the SIM
notification event
s
DELTA the slots whose values do not change are reported with their
default values, not their current values. The default value is an empty
string for symbolic values and -1 for numer ic values. See the .baroc class
definition of the SIM notification event for the default slot values.
FULL the current values of all slots are reported, including those that
have not changed
61
Table 14
SIM_NOTIFICATION_REGISTRY dialog box fields (part 2 of 2)
Field
Description
notifications_at_registration instructs the cell whether or not to send the current component states at the
moment of registration
s
YES instructs the cell to send the current component state at the
NO instructs the cell not to send the current component state at the
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.
asset_filter
7 Click OK.
In the Administration tab, the new SIM_NOTIFICATION_REGISTRY instance is
displayed under SIM_NOTIFICATION_REGISTRY.
To delete a SIM_NOTIFICATION_REGISTRY data instance

1 Right-click the SIM_NOTIFICATION_REGISTRY data instance.
2 Select Delete.
To modify a SIM_NOTIFICATION_REGISTRY data instance
1 Right-click the SIM_NOTIFICATION_REGISTRY data instance.
2 Select Edit.
3 Make the necessary changes to the fields in the SIM_NOTIFICATION_REGISTRY
dialog box.
4 Click OK to accept the changes.
62
Trouble-shooting BMC Impact Manager
Trouble-shooting BMC Impact Manager

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

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

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

s
s
mcdb.0
mcdb.lock
2 If either or both of these files are present, delete them.

3 Restart the cell.
Problem: The primary and secondary servers for my high

availability cell are in active mode simultaneously or are
unsynchronized.
This problem can occur when the primary and secondary servers are running on a
network that does not have a reliable connection, if you have started a high
availability cell using any of the mcell -i initialization options (for example, -ia, -id
or other variants), or if the primary server was started first and terminates before the
secondary server is started.
63
Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are
Possible solution: Synchronize the mcdb and xact files of

the primary and secondary servers
Follow these steps to correct the incompatible states between the primary and
secondary servers:
1 If the problem was caused by an unreliable network, resolve the network issue.
2 Shut down both cell servers
3 Copy the mcdb and xact files of the preferred server to the other server. (The
preferred server can be either primary or secondary.)
4 Start the secondary cell server.

5 Start the primary cell server.
64
Chapter

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

The following sections explain the structure of the Knowledge Base (KB) and its
directories.
About the unified Event Management and Service Impact

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

The Knowledge Base uses a defined directory structure to organize its files and
executables. The Knowledge Base directories are in the following locations:
s
66
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.
The template Knowledge Base resides in the MCELL_HOME\etc\default\SIM or

MCELL_HOME\etc\default\EM directory. The Knowledge Base available (EM only
or both EM and SIM) will depend on the type specified when the cell was created.
Cells are created during installation of a BMC Impact Manager instance or by using
the mcrtcell command. For information about this command, see mcrtcell
Creating a new cell on page 231.
NOTE
The environment variables created during installation that define paths to BMC Impact
Manager configuration files and executables are listed in the BMC Impact Solutions Installation
Guide.
Figure 10 lists the directory structure for a Knowledge Base.

Figure 10
kb
\bin
\A
\h1
\l2
\p4
\s5
\w4
\classes
\collectors
\data
\lib
\records
\rules
In the Knowledge Base, each subdirectory is labeled to indicate the type of files or
programs it stores, as listed in Table 15 on page 68.
Chapter 2
67
Table 15
Knowledge Base subdirectories (part 1 of 2)
Knowledge
Base
subdirectory Description
stores the external scripts that can execute during rule processing and actions that can be run
from BMC Impact Explorer
bin
The bin directory organizes the scripts and programs in subdirectories specific to the
appropriate operating system, as follows:
s
s
s
s
s
s
Aindependent, all UNIX, or non-Windows

h1HP-UX
l2 Linux
p4 AIX
s5 Solaris
w4 Windows
The .load file in the bin directory specifies the order in which external scripts or programs are
presented to clients. Actions are defined in .mrl files. There is one default file, .load, in the bin
directory. Actions and their syntax are described in the BMC Impact Solutions Event Management
Guide.
stores event class, data class, and interface definitions
classes
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:
s
s
sim.wiccontains the compiled implementation of primitives and functions that are

loaded by the cell at startup
sim_decl.wiccontains the compiled definitions for primitives and functions; it is loaded
by the compiler to compile rules that reference SIM primitives
For more information about functions and primitives, see the BMC Impact Solutions Knowledge
Base Development Reference Guide.
68
Table 15
Knowledge Base subdirectories (part 2 of 2)
Knowledge
Base
subdirectory Description
records
stores global record definitions, which store dynamic information across all rule phases
A global record stores persistent dynamic information in a .baroc file. Many rule processing
phases use global records for retrieving dynamic information. The .load file indicates the order
in which the files are loaded into the cell. The default copy of record definitions is stored in
baroc files in the records directory. After the values are loaded they are maintained in the
mcell.db. Dynamic data objects and their syntax are described in the BMC Impact Solutions
Knowledge Base Development Reference Guide and in the BMC Impact Solutions Event Management
Guide.
rules
stores the rule definitions for the Knowledge Base

The source for rule definitions are the files with an .mrl extension. The compiled versions of
rules are contained in files with the .wic or .pkg extension. The .load file indicates the order in
which the rules are loaded into the cell. Rules and their syntax are described in the BMC Impact
Solutions Knowledge Base Development Reference Guide and in the BMC Impact Solutions Event
Management Guide.
Table 16 lists the file extensions and directory location for the each of the components
contained in a KB.
Table 16
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
Chapter 2
69
Knowledge Base index files
Knowledge Base index files

The following files are included with the installation and are necessary for the
Knowledge Base to run properly:
s
manifest.kbserves as an index file for the listed directories that compose the
Knowledge Base during compilation. This file is located in

%MCELL_HOME%\etc\CellName\kb on Windows platforms and in
$MCELL_HOME/etc/CellName/kb on UNIX platforms.
s
.loadserves as an index file for the individual files contained in the
corresponding subdirectory of the Knowledge Base directory structure. Load files

are included in each subdirectory to determine load order for that particular
directory. Files types within the .load file do not have extensions.
s
.loadwicBefore the compilation of the Knowledge Base, rules and collectors are
created in .mrl files and are included in the .load files. After compilation, rule and
collector files are stored in .wic files and a .loadwic file is created for the KB to use.
The .wic files are machine-readable only.

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

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

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

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

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

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

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

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

KB versioning enables you to determine which KB and which version of the KB is
loaded in a cell. You can implement version information for
s
72
KB source files For each KB source file that you specify, information about the
source file is provided and the version of the compiler that was used to compile it.
Logical KB modulesVersion information is provided for each logical module that
you identify in the KB.
Versioning a Knowledge Base
A logical KB module is a collection of class definitions and rules that perform a

specific task within the KB. For instance, all class definitions and rules that are
related to Help Desk events could be called the HelpDesk KB module. A single KB
can contain multiple such logical modules. The class definitions and rules that are
not associated to a specific KB module are considered to be part of the global,
unnamed KB module.
If desired, you can make rules behave differently depending on the version of specific
KB modules. This can be useful in patches, for example.
Enabling KB versioning
To enable versioning, you must create logical modules in the KB. To identify the files
for a particular module, add the @kbversion annotation to the KB source files, using
the following syntax:
@kbversion( [ ModuleName , ] VersionID )
Variable
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.
The mccomp command compiles the @kbversion annotations into the KB object files
and includes the following information about each source file in the KB:
s
s
s
s
s
s
release number of the compiler used to compile the file

build number of the compiler used to compile the file
build date of the compiler used to compile the file
source file name
source file size in bytes
source file checksum
Chapter 2
73
Retrieving KB version information in rules
KB versioning example
@kbversion( HelpDesk , '1.2.01' )
This example specifies that the KB contains a logical module called HelpDesk, and
that its version is 1.2.01.
Retrieving KB version information in rules

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

mgetinfo
You use the mgetinfo command with the kbmodules and kbsources arguments to
retrieve version information from the cell's loaded KB.
mgetinfo -n cellName [-v] kbmodules|kbsources
Argument
Returned results
kbmodules
list of KB modules with version information
kbsources
list of KB source files with compiler version information
The information is displayed in raw format. You can use the -v switch to obtain the
information in a more readable format. Figure 11 on page 75 shows a portion of the
information returned from the kbsources argument.
74
Retrieving KB version information by using a commandmgetinfo
Figure 11
Output from mgetinfo kbsources argument
BMC Impact InfoRetrieval 7.3.00 (Build 1332814 - 27-Jan-2009)

Copyright 1998-2009 BMC Software, Inc. as an unpublished work. All rights reserved.
7.3.00 1332814 27-Jan-2009 collectors/self_collector.mrl 329 215528602
7.3.00 1332814 27-Jan-2009 collectors/mc_bystatus_collectors.mrl 8682876756519
7.3.00 1332814 27-Jan-2009 collectors/mc_bylocation_collectors.mrl 2673155257002
7.3.00 1332814 27-Jan-2009 collectors/mc_evr_collectors.mrl 17193192677488
7.3.00 1332814 27-Jan-2009 collectors/bii4p_collectors.mrl 1861 72069569
7.3.00 1332814 27-Jan-2009 collectors/mc_sm_collectors.mrl 1351 3438665385
7.3.00 1332814 27-Jan-2009 collectors/catchall_collector.mrl 3813425794528
7.3.00 1332814 27-Jan-2009 rules/mc_startup.mrl 578 2337723164
7.3.00 1332814 27-Jan-2009 rules/im_internal.mrl 36351 4174289538
7.3.00 1332814 27-Jan-2009 rules/mc_intevt.mrl 3115 1930567566
7.3.00 1332814 27-Jan-2009 rules/mc_mccs.mrl 2296 2571308892
7.3.00 1332814 27-Jan-2009 rules/ips.mrl 2333 2499185120
7.3.00 1332814 27-Jan-2009 rules/mc_sm_start.mrl 1196 92543871
7.3.00 1332814 27-Jan-2009 rules/mc_sm_associate.mrl 3389 3376465454
7.3.00 1332814 27-Jan-2009 rules/mc_sm_maintenance.mrl 1885 797195742
7.3.00 1332814 27-Jan-2009 rules/mc_sm_elect.mrl 1055 4013285370
7.3.00 1332814 27-Jan-2009 rules/mc_sm_attach.mrl 1943 1558282738
7.3.00 1332814 27-Jan-2009 rules/mc_sm_shadow.mrl 3781 4283488066
7.3.00 1332814 27-Jan-2009 rules/mc_sm_slm.mrl 4512 1631402620
7.3.00 1332814 27-Jan-2009 rules/bii4p.mrl 10473 1881293223
7.3.00 1332814 27-Jan-2009 0 1073706332
7.3.00 1332814 27-Jan-2009 bin/mc_actions.mrl 1304 3908443203
7.3.00 1332814 27-Jan-2009 bin/im_operations.mrl 16424 2639831549
7.3.00 1332814 27-Jan-2009 bin/sim_operations.mrl 3992 3834546431
Chapter 2
75
Retrieving KB version information by using a commandmgetinfo
76
Chapter
Managing the BMC Impact

Administration server
3
This chapter presents the following topics:

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

The IAS uses an iadmin command to launch the file management options. The iadmin
script or command is located under the IMPACT_SOLUTIONS_HOME/server/bin
directory.
78
Command line interface
You can use the iadmin command to manage the following configuration files:
s
s
s
s
s
group_roles.xml
cell_info.list
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
79
Impact Administration cell
Table 18
iadmin options (part 2 of 2)
Option
Description
-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 servers configuration to it and
restart it with the new configuration. The [actions] option can reload the
newly created remote actions defined in the .xml files
-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.
When using iadmin to manage files, remember to:

s
s
s
enclose values within quotation marks if they contain spaces

omit spaces in lists
enclose password values within double quotation marks
For example, if the password string is $able_baker, then enclose it within double
quotation marks in the iadmin command string, as in the following excerpt:
password=$able_baker
s
s
On Windows, execute the iadmin command from any path

On Unix, set $MCELL_HOME environment using the command
./etc/mcell/setup_env.sh, then run the iadmin command from any path
Impact Administration cell

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

server files
This section describes the following configuration tasks:
s
s
s
s
s
s
s
s
s
s
s
s
Defining group roles and permissions

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

Use the iadmin script or command whenever possible. If you have to manually edit a
file, follow these general steps:
1 Open the file in a text editor.

2 Make the changes in the proper format.
3 Save the file without changing its extension or file path.
4 Restart IAS.
NOTE
When manually editing files to enable a high availability configuration, you must follow the
special guidelines outlined in the topicDefining a failover configuration for the Impact
Administration cell on page 105.
Users, groups, roles, and permissions

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

R
Dashboards-Create,
update, and delete
all profiles
Edit
Dashboards-Create
and delete own
profiles only
Edit
Dashboards (SIEM)
View
83
Operators
Supervisors
Dashboards (CIEM)
View
Events tab
View
ConfigurationEdit
Relationship View
Edit
ConfigurationEdit
Personal Filters
Edit
ConfigurationEdit
Personal Attribute
(Slot) Orders
Edit
ConfigurationEdit
Personal
MetaCollectors
Edit
ConfigurationEdit
Global Event Filters
Edit
ConfigurationEdit
Global Attribute
(Slot) Orders
Edit
ConfigurationEdit
Impact Manager
Group on Impact
Manager
Configuration
window
Edit
Events tab-Show
Impact
Administration cell
Edit
Events tabJump
from an Event to Its
Services Impacted
View
Edit
Events tabReopen
Events
Edit
84
Read Only
Service Operator
Service Manager
Full Access
Choices
Function
Admins
Table 19
Events tabEvent
Operation
Supervisor
Privileges (for
example, close
events owned by
someone else)
Edit
Events tabAssign
Events
Edit
Events tabAdd
Image View
Edit
Events tabDelete
Image View
Edit
Services tab
View
Services tabSearch
for Service
Components
Edit
Services tab-Create
and delete
components
Edit
Services tabEvent
List View of a
Service Component
View
Services tabEdit My Edit

Services Navigation
Tree
Services tab-Create,
Edit, Delete
Relationship
between
components
Edit
Services tabSet or
Remove Manual
Status (of a
component) Action
Edit
Supervisors
Operators
Admins
Read Only
Service Operator
Service Manager
Full Access
Function
Choices
Table 19
X
X
85
Full Access role permissions
Services tabSet or
Clear Maintenance
Mode (of a
Component) Action
Edit
Administration tab
View
Timeframes
Edit
Administration tab:
all actions
Edit
Infrastructure
Edit
Management subtab
Infrastructure
Edit
Management subtab:
all actions
Alias Formula Editor Edit
Remote Actions:
Create remote
actions
Edit
Send Events to Cell
Edit
Delete Events to Cell Edit
Supervisors
Operators
Admins
Read Only
Service Operator
Service Manager
Full Access
Function
Choices
Table 19
Full Access role permissions

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

Use the role_permissions.xml file to add customized role/permission mappings. The
com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file specifies
this default file for containing customized role/permission mappings, as shown in
the following excerpt:
com.bmc.sms.ixs.role.permission.mapping=role_permissions.xml
If you create a separate .xml file to contain your customized role/permission

mappings, you must specify its name in the
com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file. Then
you must restart IAS to initialize the change.
The user-defined .xml file does not override the default file. Its individual entries
override matching ones in the default file. Any entries in the default file that are not
overridden by matching ones in the user-defined file remain valid.
When you use the iadmin script to add, modify, or delete a role/permission mapping,
the change is saved to the role/permissions file specified by the
com.bmc.sms.ixs.role.permission.mapping property.
To add a new role/mapping permission

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

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

You can delete an existing role in a user-defined roles/permissions file.
NOTE
If the role to be deleted only exists in the default file, then an entry is added to the userdefined file. The entry contains the role name only, without any permissions associated with
it. Because the user-defined entry overrides the default one, the role is effectively deleted.

execute the iadmin command using the -dr option, as in the following example:
iadmin -dr role=Test
The entry role=Test is written to the user-defined file and effectively overrides any
identical role in the default file.
To list roles defined in roles/permissions mapping files

You can list all roles defined in both the default and in the user-defined
roles/permissions mapping files.
execute the iadmin command using the -lr option, as in the following example:
iadmin -lr

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

IAS provides the following default groups and user roles, both of which are listed in
Table 20. You can view these roles in the group_roles.xml file. Refer to Table 19 on
page 83 for a complete listing of access permissions for group and role combination.
88
Table 20
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.
You can update user groups and roles and create new ones by editing the
group_roles.xml file, shown below:
<!DOCTYPE properties SYSTEM
"http://java.sun.com/dtd/properties.dtd">

<properties>
<entry key="Full Access">Full Access</entry>
<entry key="Read Only">Read Only</entry>
<entry key="Service Administrators">Service Administrators</entry>
<entry key="Service Managers">Service Managers</entry>
<entry key="Service Managers - Senior">Service Managers Senior</entry>
<entry key="Service Operators">Service Operators</entry>
<entry key="Service Operators - Senior">Service Operators Senior</entry>
<entry key="Admins">Full Access,Service Administrators</entry>
<entry key="Operators">Service Operators,Service Operators Senior</entry>
<entry key="Supervisors">Service Managers - Senior,Service
Operators - Senior</entry>
</properties>
89
To add a new group with mapping roles

NOTE
If youre adding a new role to the group, you must first create the role and add permissions to
it using the iadmin -ar option before you create the group. See To add a new
role/mapping permission on page 87.

execute the iadmin command using the -ag option, as in the following example:
iadmin -ag group=NewGroup:roles=Role
To modify an existing group and/or mapping roles

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

execute the iadmin command using the -dg option, as in the following example:
iadmin -dg group=Service Operators
You do not specify a role.
To list groups in the group_roles.xml file

execute the iadmin command using the -lg option, as in the following example:
iadmin -lg
90
File-based authentication: updating user information
To update user groups and roles (file editor)

1 Open the group_roles.xml file in an editor.
2 Update or delete the existing entries, or add a new entry where
s
key is the name of the group
the values inside the <entry></entry> element are the roles
3 Save and close the group_roles.xml file.

4 Restart the IAS to initialize the changes.

You choose file-based authentication in test environments or in small production
environments. Using file-based authentication, you can manage users of the BMC EM
and SIM products independent of your corporate environment.
To enable file-based authentication

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

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

execute the iadmin command using the -mru option, as in the following example:
iadmin -mru loginId=qa:usergroups=Read Only
To delete an existing user

execute the iadmin command using the -dru option, as in the following example:
iadmin -dru loginId=qa
To update the current password of an existing user

execute the iadmin command using the -cp option, as in the following example:
iadmin -cp loginId=qa:oldPassword=qa:newPassword=bsm
To reset the current password of an existing user

When you reset a password, you do not specify the current password, only the new
password.
92
Adding role names to the cells KB definition files

execute the iadmin command using the -rp option, as in the following example:
iadmin -rp loginId=JoeUser:newPassword=bsm
To list all users in the user_definitions file

execute the iadmin command using the -lru option, as in the following example:
iadmin -lru
To change the current admin password

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

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

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

You can synchronize your cell information with the BMC Atrium CMDB by
modifying the cmdb.properties, an excerpt of which is shown below:
......
# "true" if this IAS will synchronize with the CMDB server.
com.bmc.sms.ixs.cmdb.enable.sync=false
# host name for AR server
com.bmc.sms.ixs.cmdb.host.name=localhost
# port number for AR server
com.bmc.sms.ixs.cmdb.port.number=0
# user id for AR server
com.bmc.sms.ixs.cmdb.user.id=Demo
# password for AR server
com.bmc.sms.ixs.cmdb.password=
To synchronize with the BMC Atrium CMDB

1 Change the com.bmc.sms.ixs.cmdb.enable.sync property to true.
2 Enter the fully qualified domain name or the IP address of the host system where
the AR Server resides.
3 Enter the port number of the AR Server. If the AR Server is using portmapper, then
enter 0.
4 Enter the AR Server user Id that you use for accessing the BMC Atrium CMDB.
5 Enter the password in plain text. When IAS restarts, it encrypts the password and
displays the encryption in the file.
6 Restart the IAS.
95
Updating cell information

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

Table 21
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.
To add/register a cell
execute the iadmin command using the -ac option, as in the following example:
iadmin -ac name=testCell:key=mc:primaryHost=moondog:primaryPort=1828:
failoverHost=suncat:failoverPort=1828:environment=Production:usergroups=*
96
The cell information is added to the cell_info.list. It is also added to the BMC Atrium
CMDB if the cell is synchronized with BMC Atrium CMDB as defined in the
cmdb.properties.
To ensure that the cell is registered with the IAS, be sure that its mcell.dir file contains
the IAC entry, as in the following example:
cell
IAC
mc
myComputer.adprod.bmc.com:1827
The IAC entry enables event propagation between the cell and the Admin cell that is
part of the IAS.
To modify a cell
execute the iadmin command using the -mc option. After you specify the cell name,
you only to need to include the options that you are changing, as in the following
example:
iadmin -mc name=testCell:failoverHost=null:environment=Test
In this example, the secondary cell is removed and thus failoverHost is defined by
null. The environment is changed from Production to Test. If you were to change the
primaryHost or primaryPort value, then IAS connects to the cell to retrieve its type.
All updates are saved into the cell_info.list and to the BMC Atrium CMDB, if the cell
is synchronized with the BMC Atrium CMDB.
To delete a cell
execute the iadmin command using the -dc option to delete a cell from the
cell_info.list, as in the following example:
iadmin -dc name=testCell
If the cell is synchronized with the BMC Atrium CMDB, it is removed from the
CMDB.
To list cells
execute the iadmin command using the -lc option, as in the following example:
iadmin -lc
97
Editing logging properties for IAS
Editing logging properties for IAS

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

that you would typically modify:
Table 22
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.
After you make changes, save the server_logging.properties file, and restart IAS.
Defining client logging for the iadmin script

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

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

IAS Status Monitoring is used for auditing the IAS application at a predefined
interval (known as IAS Application Audit Interval). During this audit, the following
statistical information is generated:
s
s
s
s
s
List of clients connected to IAS and the corresponding threads IDs of threads in
IAS serving it
Threads count (user, daemon) in the IAS application at that instant
Peak thread count of the IAS application
Memory consumption of the IAS application
Other services information (like memory consumed and thread count) running on
the machine hosting the IAS application
Operating System information
This information helps in gathering factual information about the customer

environment for IAS and fine tuning IAS.
You can define the configuration settings for status monitoring in the ias.properties
file.
99
Customizing the IAS thread pool handling IAS Clients
Table 23
IAS status monitoring properties
Property
Description
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.
Code examples follow that show sample IAS Status Monitoring configuration
parameters.
# IAS Status Monitoring Enable
com.bmc.sms.ixs.appAuditLogEnable=true
# Status Monitoring Audit File Name
com.bmc.sms.ixs.appAuditLogFilename=log/ias/IAS_App_Audit_File#%g.log
# Status Monitoring Audit Log Limit
com.bmc.sms.ixs.appAuditLogLimit=50000
# Status Monitoring Audit Log File Count
com.bmc.sms.ixs.appAuditLogFileCount=10
# Status Monitoring Audit Log Interval
com.bmc.sms.ixs.applicationAuditInterval=60
Customizing the IAS thread pool handling IAS Clients

You can define the configuration parameters for the IASClientThreadManager thread
pool in the ias.properties file.
Table 24
IAS thread pool properties (part 1 of 2)
Property
Description
com.bmc.sms.ixs.iasclient.threadManager.cor Specifies the Core ThreadPool Size. It indicates the number of

e_Pool_Size
threads to keep in the pool even if they are idle (Minimum
Thread Pool size).
com.bmc.sms.ixs.iasclient.threadManager.ma Specifies the Maximum ThreadPool Size. It indicates the
x_Pool_Size
maximum number of threads to allow in the thread pool.
100
Table 24
IAS thread pool properties (part 2 of 2)
Property
Description
com.bmc.sms.ixs.iasclient.threadManager.ke Specifies the maximum time that excess idle threads will wait
ep_Alive_Time
for new tasks before terminating. Excess idle threads occur
when the number of idle threads in the thread pool is more
than the core pool size.
com.bmc.sms.ixs.iasclient.threadManager.ke Specifies the time unit for the keepAliveTime argument. The
ep_Alive_Time_Unit
possible values are DAYS, HOURS, MINUTES, or SECONDS.
NOTE
The property com.bmc.sms.ixs.thread.pool.size is not applicable in 7.3.00 and 7.2.x,
if the patch for thread pool changes is applied.
Do not modify the properties
com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time and
com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time_Unit as these are
sensitive.
Code examples follow that show sample IAS ThreadPool configuration parameters.
# Core ThreadPool Size
com.bmc.sms.ixs.iasclient.threadManager.core_Pool_Size=10
# Max ThreadPool Size
com.bmc.sms.ixs.iasclient.threadManager.max_Pool_Size=50
# Keep Alive Time
com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time=1000
# Keep Alive Time Unit
com.bmc.sms.ixs.iasclient.threadManager.keep_Alive_Time_Unit=SECONDS
Defining standalone, primary, and secondary BMC Impact

Administration servers
NOTE
At installation, you can choose to install and implement a failover configuration for the IAS. If
you select to define an failover setup for the Master IAS, the accompanying IAC is also
defined as failover automatically.
By default the IAS is configured to work in standalone mode. However, after

installation, you can choose to implement a failover configuration, in which you
define a pair of primary and secondary servers to handle failover situations after
which you need to restart both the servers.
Chapter 3
101
You must first install another BMC IAS on a second system. Rerun the installation,
and make the appropriate Standard or Master IAS selection for the second system.
The primary and secondary Impact Administration servers must have the same
name.
To configure IAS failover manually

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

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

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

You can define your IAS synchronization properties by modifying the following
properties in its corresponding ias.properties file.
Table 25
IAS synchronization properties (part 1 of 2)
Property
Description
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.
Chapter 3
103
Table 25
IAS synchronization properties (part 2 of 2)
Property
Description
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.
iadmin reinit/sync options

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

Administration cell
As a general practice, you configure the IAC as an failover pair whenever you
configure the Master IAS as a failover pair. Use this table as a guideline for changing
the respective mcell.dir files of the primary IAC on one host system and the secondary
IAC on the second host system:
Table 26
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
Admin
mc
host1:1827 host2:1827
cell
IAC
mc
host1:1827 host2:1827
cell
IAC
mc
host1:1827 host2:1827
Remember that the primary IAC resides on the same host as the primary Master IAS
and the secondary IAC resides on the same host as the secondary Master IAS.
After you define the entries in the mcell.dir files, you must modify the respective
mcell.conf files as you would any normal cell that you are configuring for failover.
Chapter 3
105
Transaction and trace logs
Transaction and trace logs

The IAS automatically generates the log files listed in Table 27.
Table 27
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.
You can edit the properties of the diagnostic trace log ias0.log in the
server_logging.properties file.
Example trace output

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

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

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

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

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask,com.bmc.sms.marimba_cas_tools.
TelnetTask
unix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask
unix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask
Restart the BMC Impact Administration server to initialize your changes.
Configuring Lightweight Directory Access Protocol for BMC

Impact Administration server
Use Lightweight Directory Access Protocol (LDAP) authentication in a production
environment. In this way, you can link your BMC Impact Administration server (IAS)
authentication with your corporate infrastructure for user authentication and
authorization management. Using LDAP authentication allows you to use the same
user definitions across multiple BMC product lines. After you define your LDAP user
and user groups, you can map your LDAP user groups to the IAS user groups. Any
users you add to an LDAP user group share the permissions of the IAS user group to
which you have mapped. The IAS supports Active Directory LDAP nested groups.
You can use a single sign-on to access multiple products. You do not have to create a
separate user definition and sign-on information for each product.
To enable LDAP authentication for the IAS on a Windows system, your login account
must have administrator privileges on the target system. On a UNIX system, you
must be logged in as root or under a user account with write and execute permission
on the IMPACT_SOLUTIONS_HOME/server directory.
Set up your LDAP server according to your LDAP server procedures. Next, enable
the LDAP login entry in the ias.properties file. Then you can enter your LDAP
configuration information for each LDAP server that you are enabling.
Chapter 3
109
NOTE
If you are using a solution that requires the BMC Portal and/or BMC Atrium CMDB, you may
need to set up LDAP authentication on the BMC Portal server and on the AR System server.
Refer to the BMC Portal Getting Started guide for information on setting up LDAP
authentication on the BMC Portal server. Refer to the BMC Remedy Action Request System 7.1
Integration with Plug-ins and Third-Party Products for information on setting up LDAP
authentication on the AR System server.
To enable the LDAP login entry in the ias.properties file

1 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties
file, where IMPACT_SOLUTIONS_HOME/server is the installation directory of
your server. Locate the com.bmc.sms.ixs.enable.ldap.login parameter, and set it
equal to true:
#----------------------------------------------------------------# Enable/disable LDAP login module.
# When it is enabled, "ldap_definition.xml" file has to be filled.
#----------------------------------------------------------------com.bmc.sms.ixs.enable.ldap.login=true
2 Optional. To enable file-based user groups, defined in the user_definitions.xml file,

to map to roles in addition to LDAP user groups, modify the
com.bmc.sms.ixs.allow.local.groups.for.ldap parameter, setting it equal to true,
as in the following example:
com.bmc.sms.ixs.allow.local.groups.for.ldap=true
The user groups defined in the user_definitions.xml file are mapped to roles for the
initial log-in and for user authorization.
NOTE
If you leave the default value false, then only roles that are mapped to the users LDAP
groups are used for user authorization.
3 Save and close the ias.properties file.

4 Restart IAS.
5 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/jaas.conf file. Do
not modify this file. Verify that it contains an entry such as the following:
com.bmc.sms.ixscomm.authentication.ldap.LdapLoginModule Sufficient;
6 Close the file.

110
To add LDAP configuration information

You are now ready to add your LDAP configuration information to the
IMPACT_SOLUTIONS_HOME/server/conf/ldap_configuration.xml file. Figure 13
on page 111 depicts a sample ldap_configuration.xml file with a single LDAP server
configuration:
Figure 13
Excerpt from ldap_configuration.xml file
<?xml version="1.0" encoding="UTF-8"?><ldapList xmlns="urn:bmc:schemas:impact"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:bmc:schemas:impact ldap_definitions.xsd">
<ldap alias="test">
<host>majestix.bmc.com</host>
<port>389</port>
<version>3</version>
<baseDN>DC=pinfrastruct,DC=rd,DC=bmc,DC=com</baseDN>
<connectionUserName>glin@pinfrastruct.rd.bmc.com</connectionUserName>
<useridAttribute>sAMAccountName</useridAttribute>
<useSSL>false</useSSL>
<memberOfAttribute>memberOf</memberOfAttribute>
<userSearchFilter>(objectClass=organizationalPerson)</userSearchFilter>
<groupSearchFilter/>
<connectionPassword encrypted="true">fisSCap4ZhOLOUENWPLe==
</connectionPassword>
</ldap>
......
</ldapList>
1 Make only one <ldap></ldap> entry for each LDAP configuration.

Multiple LDAP configurations can exist for one LDAP server with different
baseDN parameter values.
2 Follow these guidelines for your <ldap></ldap> entries:

A Specify a unique alias for each LDAP configuration.
B Ensure that the LDAP group is defined in the group_roles.xml file on the IAS.
3 Using Table 28 on page 111 as a guide, complete the LDAP configuration
parameters.
Table 28
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.
Chapter 3
111
Table 28
LDAP configuration parameters (part 2 of 2)
LDAP parameter
Description
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=grou
pOfUrls))
connectionPassword
authentication password (encrypted) that is used to connect to the LDAP server.

Note: Set the encrypted attribute equal to false and then enter the password in plain
text. When IAS restarts, it encrypts the password and changes the encrypted attribute
value from false to true.
4 After completing your changes, restart the IAS.

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

NOTE
If youre adding a new role to the group, you must first create the role and add permissions to
it using the iadmin -ar option before you create the group. See To add a new role/mapping
permission on page 87.
From the/bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory,

execute the iadmin command using the -ag option, as in the following example:
iadmin -ag group=NewGroup:roles=Role
The new entry would look similar to the following in the group_roles.xml file:
<entry key="nameofUserGroup">IAS_defaultRoleName</entry>
To add the role name to the cells KB definition files

You add the role name to the Access Control List (ACL) of the collector definition and
operation definition files in the connected cell or cells.
NOTE
If the ACL is empty, then every group has access.
1 Add the user group name to each of the following collector definition files that you
want the user group to access. Where indicated, associate the read, write, and
execute permissions (r, w, x) with the group name entry:
s
s
s
s
s
s
s
s
biip4p_collectors.mrl
catchall_collector.mrl
mc_bylocation_collectors.mrl
mc_bystatus_collectors.mrl
mc_evr_collectors.mrl
mc_sm_collectors.mrl
mcxpcoll.mrl
self_collector.mrl
You may need to change the file permissions on these files before editing them.
Chapter 3
113
The following code examples show sample modifications to each file:
biip4p_collectors.mrl
collector PATROL :
{
r['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
Managers',nameofUserGroup]
w['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
x['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
}
END
catchall_collector.mrl
collector 'All
{
r['Service
w['Service
x['Service
}
Events' :
Administrators',nameofUserGroup]
mc_bylocation_collectors.mrl
collector 'By Location':
{
r['Service Administrators',nameofUserGroup]
w['Service Administrators',nameofUserGroup]
x['Service Administrators',nameofUserGroup]
}
END
...............
collector 'By Location'.*:
{
r['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
w['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
x['Service Administrators','Service Operators Senior','Service Operators','Service Managers - Senior','Service
}:
114
mc_bystatus_collectors.mrl
collector 'By Status':
{
r['Service Administrators','Service Operators Senior',nameofUserGroup]
w['Service Administrators','Service Operators Senior',nameofUserGroup]
x['Service Administrators','Service Operators Senior',nameofUserGroup]
}
END
mc_evr_collectors.mrl
collector MC_Related_Events:
{
}
END
collector MC_Related_Events.*:
{
}:
EVENT
where [mc_relation_source: != '']
create $THIS.CLASS
END
You can add a user group to this .mrl file, but be sure not to edit any other parameter
or value.
Chapter 3
115
mc_sm_collectors.mrl
collector
{
r['Full
w['Full
x['Full
}
END
MC_SMC_Events:
Access', 'Service Administrators'nameofUserGroup]
collector MC_SMC_Events.*:
EVENT
where [$THIS.mc_smc_id != ""]
create cond($THIS.mc_smc_type == '', "Unknown", $THIS.mc_smc_type)
END
collector MC_SMC_Events.*.Impacts:
EVENT
where [$THIS.mc_smc_impact == 1]
END
collector MC_SMC_Events.*.History:
SMC_STATE_CHANGE
END
You can add a user group to this .mrl file, but be sure not to edit any other parameter
or value.
mcxpcoll.mrl
collector 'By Location'.*.*.*.*.*:
PATROL_EV where [p_application: not_equals '']
create $THIS.p_application
END
{
r[nameofUserGroup]
w[nameofUserGroup]
x[nameofUserGroup]
}
self_collector.mrl
collector self :
{
r['Full Access', 'Read Only',nameofUserGroup]
w['Full Access', nameofUserGroup]
x['Full Access', nameofUserGroup]
}
END
116
2 Next, assign the group name to the appropriate event management operations in
the im_operations.mrl file. Each event operation can be performed by a predefined
set of groups, as shown in Table 29.
Table 29
Event operations
Event operation
Group names
Acknowledge
Service Administrators, Service Operators - Senior, Service Operators
Take Ownership
Decline Ownership
Close
Assign to Operation
Service Administrators, Service Operators - Senior
Set Priority
Reopen
An example of a group name assignment to a specific event management action is

shown below:
action im_operations.Acknowledge:
{
['Service Administrators','Service Operators Senior','Service Operators',nameofUserGroup]
}
3 Make the appropriate group name assignments to the mc_actions.mrl file and the
sim_operations.mrl file, following the syntax examples in the files.
4 Recompile the cells KB using the mccomp command, as in the following example:
mccomp -n cellName | manifestKBFilePath
You must include the path to the manifest.kb file.
5 Restart the cell using the mcell command.

To retrieve LDAP groups or to authenticate an LDAP user
execute the iadmin command using the -tlq option, as in the following example that
retrieves a list of LDAP groups:
iadmin -tlq group
Chapter 3
117
Troubleshooting
NOTE
When you execute the iadmin command using the -tlq option, you must have the
correct LDAP server information in the ldap_configuration_query.xml file.
To authenticate a specific LDAP user, enter the user name and password, as in the
following example:
iadmin -tlq username=<string>:password=<string>
The -tlq option also checks the time required to execute an LDAP query.
To facilitate the iadmin -tlq option, you can modify the following properties in the
IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file.
LDAP property
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.
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
s
s
s
s
118
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
Problem: Cell_info.list synchronization error during manual configuration of an IAS failover
Before you begin

Configure the corresponding Impact Administration (Admin) cell in high availability
mode.
To manually synchronize the cell_info.list

1 Execute the iadmin -lc command against the Impact Administration server system
that you will later configure as the secondary server. An example command with
sample output is shown below:
bash-3.00# iadmin -lc
BMC Impact Administration Server 7.3.00 [Build 1647631 - 29-Dec-2008]
Copyright 1998-2009 BMC Software, Inc. as an unpublished work.
rights reserved.
All
List BMC Impact Managers:

pun-sms-sun31
mc pun-sms-sun31.bmc.com:1828
Production
2 Copy the cell entry to a text editor, such as Notepad. In this example, the copy
would look as follows:
pun-sms-sun31
mc pun-sms-sun31.bmc.com:1828
Production
3 Manually add the host cell entry from the secondary server to the primary servers
cell_info.list file using the iadmin -ac command, as in the following example:
iadmin -ac name= pun-sms-sun31:key=mc:primaryHost=pun-sms-sun31:Port=1828:
environment=Production:usergroups=*
4 Configure IAS failover (primary and secondary servers). See To configure IAS
failover manually on page 102 for the steps.
5 Restart the primary and secondary servers.

6 Execute the iadmin -reinit fullsync command on the secondary server to copy the
primary servers configuration to it and to restart it with the new configuration
7 Wait for the synchronization process to complete.

The default synchronization interval time is 15 minutes. This value is defined in
the com.bmc.sms.ixs.sync.interval property of the
IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file.
Chapter 3
119
Problem: Cell_info.list synchronization error during manual configuration of an IAS failover
120
Chapter

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

Communication between the Web browser and the BMC Portal is encrypted and
requires the use of the https:// communication protocol.
To access the BMC Portal

1 In the browsers address box, type the BMC Portal URL address using the
following syntax:
https://computerName:portNumber
s
computerNamerepresents the host name of the BMC Portal server
portNumberrepresents the port number assigned to the BMC Portal; the

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

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

You can start and stop the BMC Portal by using either of the following methods:
s
s
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:
s
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:
s
./BMCPortalAppserver stop
./BMCPortalAppserver start
Chapter 4
123
Configuration tasks for BMC Impact Portal
Configuration tasks for BMC Impact Portal

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

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

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

You can change the columns displayed in the dashboard table views by editing the
..\smsIwc\application.properties file.
To configure Dashboard Table View columns

1 Open the application.properties file in a text editor. This file is located at
installationDirectory\tools\jboss\server\all\conf\properties\smsIwc\.
2 Edit the file to add or remove columns using the following format:
table_name=comma separated attribute (slot) names
124
Configuring Events Table columns
3 Save the application.properties file.

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

You can edit the columns that appear in the table in the Events tab by editing the
..\smsIwc\application.properties file. All columns in the events table are configurable.
To configure Events Table columns

2 Edit the appropriate events table column as shown in Table 30 on page 125.
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

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

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

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

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

WARNING

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

You can change the objectlinksync values by editing the
To configure object link synchronization

2 To change the object link type, modify the com.bmc.sms.iwc.objectlinksync.types

entry.

WARNING

page 133.
Configuring reports
You can configure the following items for reports by editing the
..\smsConsoleServer\application.properties file:
s
s
s
s
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.
Chapter 4
127
Configuring reports
Table 32
Report parameters (application.properties file)
Parameter type
Parameter
Description
Report Goals
com.bmc.sms.reportSummarizer.goal.default Availability report goal line, expressed as a

.SMS_CS_RT_AVAIL
percentage. Default value is 90.0%.
com.bmc.sms.reportSummarizer.goal.default Mean Time to Repair goal line, expressed in
.SMS_CS_RT_MTTR
milliseconds. Default value is 300000 (5
minutes).
com.bmc.sms.reportSummarizer.goal.default Mean Time Between Service Failures goal
.SMS_CS_RT_MTBF
line, expressed in milliseconds. Default
value is 172800000 (2 days).
com.bmc.sms.reportSummarizer.goal.default Mean Time Between Service Incidents goal
.SMS_CS_RT_MTBSI
line, expressed in milliseconds. Default
value is 172800000 (2 days).
Retention Age
com.bmc.sms.consoleserver.retention.policy. The number of days Status tab data will be

age.SMS_CS_STATUS_EVENT
retained. Default value is 395.
com.bmc.sms.consoleserver.retention.policy. The number of days Availability data will
age.SMS_CS_RT_AVAIL
be retained. Default value is 395.
com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time to Repair
age.SMS_CS_RT_MTTR
data will be retained. Default value is 395.
com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time Between
age.SMS_CS_RT_MTBF
Failure data will be retained. Default value
is 395.
com.bmc.sms.consoleserver.retention.policy. The number of days Mean Time Between
age.SMS_CS_RT_MTBSI
Service Incidents data will be retained.
Default value is 395.
com.bmc.sms.consoleserver.retention.policy. The number of days event data will be
age.EG_EVENT
retained in the BMC Datastore. Default
value is 395.
128
Configuring the number of events displayed
Table 33
Report parameters (internal.properties) file
Parameter 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.is Determines whether or not the setting of

StartingNextHour
startingHour will be ignored. If set to true,
startingHour will be ignored. Default value
is true.
com.bmc.sms.reportSummarizer.scheduler.
startingHour
Determines the desired starting hour. No

summarization is made until this value is
reached. If the startingHour has passed on
that day, the summarization will start at
that hour the next day. Default value is 0.
3 Save the application.properties and internal.properties files.

WARNING

page 133.
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.
Chapter 4
129
Changing the maximum number of recent items displayed

WARNING

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.

WARNING

parameters on page 133
Configuring the general properties displayed

You can change the general properties in the Configuration tab by editing the
130
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.

WARNING

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:
s
s
s
GIF
JPEG
PNG
Use the Configure tab in the BMC Impact Portal to create, edit, and delete Image
Views. For more information on setting up Image Views, see the BMC Impact Portal
online Help.
Chapter 4
131
Modifying connection settings
Modifying connection settings

You can modify the settings that BMC Impact Portal server uses when connecting to
BMC Impact Manager instances.
To modify BMC Impact Portal connection settings

1 In a text editor, open the
%BMC_PORTAL_KIT_HOME%\appserver\websdk\tools\jboss\server\all\conf\
properties\smsConsoleServer\application.properties file.
2 Search for the Cell connection configuration stanza, and review the connection
properties. The following figure depicts the default values for the connection
properties.
CellName.timeout = 30
CellName.reconnect_attempts = 5
CellName.reconnect_frequency = 30
CellName.polling_frequence = 3600
CellName.encryption = on
3 Modify the connection properties.

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:
s
s
s
132
BMC Impact Portal

BMC Impact Service Model Editor
BMC Impact Publishing Server
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
contains the general BMC Impact Portal configurations for component properties and user
Description interface presentation
Parameter name
Description
Default value
com.bmc.sms.iwc.ui.
recentitems.maxsize
sets the maximum number of objects that can display 5

in the Recent Items group folder in the navigation tree
of the BMC Impact Portal
Refer to Changing the maximum number of recent
items displayed on page 130 for more information.
com.bmc.sms.iwc.status.
table
sets the columns that will display in the status and

dashboard table views
See the
application.
properties file.
Refer to Configuring Dashboard Table View

columns on page 124 for more information.
com.bmc.sms.iwc.component.
properties.generalProperties.
properties
determines which general properties are displayed in See the

application.
the Configure tab for selected components
properties file for
more information.
Refer to Configuring the general properties
displayed on page 130 for more information.
com.bmc.sms.iwc.event.table
determines which columns in the events table are

visible in the BMC Impact Portal module
See the
application.
properties file.
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
BMC_BaseElement
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.
com.bmc.sms.iwc.domain.
recentitem.RecentItemsFolderIcon
specifies the default icon for the Recent Items folder
Chapter 4
ServiceComponent
.gif
133
smsConsoleServer/application.properties file and parameters
Table 34
application.properties file in smsIwc directory (part 2 of 2)
table.providers
table.consumers
table.causes
table.existinggroup
determines which columns that you can add to the

tables and dashboards under the Status tab in the
BMC Impact Portal module
See the
application.
properties file.
Refer to Configuring Status Table columns on

table.causal.components
table.components.small
com.bmc.sms.iwc.event.
table.minimumevents
com.bmc.sms.iwc.event.
table.maximumevents
sets the maximum and minimum number of events

retrieved per component instance; this information is
displayed on the Events tab
minimum: 5
maximum: 50

Table 35 describes the application.properties file in the smsConsoleServer directory and
its parameters.
Table 35
application.properties file in smsConsoleServer directory (part 1 of 3)
Filename
application.properties in the ..smsConsoleServer folder
File path
BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/sms
ConsoleServer
Description
contains the configurations for report scheduling, report goals, and report data retention
Parameter name
Description
Default value
com.bmc.sms.configService.
dataLocation
defines where the user configuration data is stored
no value; the
location
BOSS_HOME/s
erver/all/data/s
msConsoleServ
er 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.goa sets the value of the goal line for the Availability report 90.000%
l.default.
as a percentage
SMS_CS_RT_AVAIL
com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time to
l.default.
Repair (MTTR) report
SMS_CS_RT_MTTR
134
300000
milliseconds
(5 minutes)
Table 35
com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time Before
l.default.
Failure (MTBF) report
SMS_CS_RT_MTBF
172800000
milliseconds
(2 days)
com.bmc.sms.reportSummarizer.goa sets the value of the goal line for the Mean Time Before
l.default.
Service Impact (MTBSI) report. Goal line value is
SMS_CS_RT_MTBSI=172800000
expressed in milliseconds
172800000
milliseconds
(2 days)
cellName.timeout
sets the timeout value for data queries by the BMC

30 seconds
Impact Portal to the specified cell. The timeout value is
measured in seconds
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)
cellName.reconnect_frequency
sets the polling cycle, measured in seconds, for the BMC 30 seconds
Impact Portal reconnection attempt to the specified cell
cellName.polling_frequency
sets the polling cycle, measured in seconds, for the BMC 1800 seconds
Impact Portal data query attempt to the specified cell
<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
/smsConsoleSer
ver/images/obje
cts/
com.bmc.sms.event.
maxDelayedHours
defines the maximum number of hours an event can be 24 hours

delayed and will still be processed
com.bmc.sms.consoleserver.
retention.policy.age.
SMS_CS_STATUS_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
sets whether the Object Store communication service

should run in unrestricted mode when connecting to
the Remedy server
true
60 tries
SMS_CS_RT_AVAIL
SMS_CS_RT_MTTR
SMS_CS_RT_MTBF
SMS_CS_RT_MTBSI
EG_EVENT
com.bmc.sms.service.os.
unrestricted
Chapter 4
135
internal.properties file and parameters
Table 35
restrict.read.access

filters are read-only objects
true
filtersim

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 Remedy
Action Request System host resides
server host name
com.bmc.sms.remedy.
serverPortNumber
lists the port number on which BMC Remedy Action

Request System runs
default
Table 36 describes the aggregator.properties file and its parameters.

Table 36
aggregator.properties file
Filename
aggregator.properties
File path
BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/sms
ConsoleServer
Description
contains the configurations for BMC Impact Portal communications with cells, including port
number used for cell communications, encryption key, and encryption enablement
Parameter name
Description
Default value
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 describes the internal.properties file and its parameters.
Table 37
internal.properties file
Filename
internal.properties
File path
BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties
/smsConsoleServer
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
Parameter name
136
Description
Default value
Table 37
internal.properties file
com.bmc.sms.ixs.port.number
sets the port number through which the BMC

Impact Portal communicates with the
com.bmc.sms.ixs.enable.bind.ip
sets whether the BMC Impact Portal can bind an IP false

address on a multi-homed (multi NIC card) system
com.bmc.sms.ixs.bind.ip.address
specifies the IP address on a multi-homed system to 0.0.0.0

which the BMC Impact Portal is bound
Chapter 4
3084
137
138
Chapter
Working with Infrastructure

Management
5

Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . .
Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . .
Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Navigating the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying and understanding the Details and Administer tab data . . . . . . . . .
Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How a product component registers and communicates with the IAC . . . . . . .
Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recreating an Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unregistering with the IAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5
140
142
142
142
144
145
146
148
149
150
152
156
157
158
159
160
163
164
165
165
165
169
172
172
172
173
174
174
139
Default Infrastructure Management service model
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
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
100
EM_CELL
101
EM_SERVER_1
102
EM_SERVER_2
103
140
Name
SIM_CELL
Table 38
Supported application groups (part 2 of 2)
Group Id
Name
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
141
LOG_FILE_ADAPTER
SNMP_ADAPTER
WINDOWS_EVENT_ADAPTER
SYSLOG_ADAPTER
TCP_ADAPTER
TELNET_ADAPTER
UDP_ADAPTER
IIP7
IIP3
IIOVO
IINNM
IITIVOLI
DBGW
IIARS
142
IBRSD
150
159
BPM
ARS
ARS_SD
CMDB
BiiZ
BIM
SLM
TM_ART
TM_RCA
TM_REM
160
EM_Server_Standby
161
SIM_Server_Standby
162
ADAP_SERVER_1
ADAP_SERVER_2
ADAP_CELL
122
123
124
125
126
127
130
131
132
133
134
140
151
152
153
154
155
156
157
158
163
164
Chapter 5
141
Roles and permissions
Roles and permissions

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

Infrastructure Management automatically deploys a BMC infrastructure service
model, called BMC Impact Solutions. It consists of logical groupings of BMC services
and applications, together with registered components that send all relevant
information and latest statuses. The out-of-the-box service model reflects the realtime states of the registered components.
To display the service model

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

The Infrastructure Management interface offers a range of context-sensitive
information that you can access from right-click pop-up menus and multi-layered
notebook tabs.
For example, you can expand the model and select a component under the SIM Cells
heading.
s
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.
144
Click the leaf component under SIM Cells to select it.
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.
Chapter 5
145
Packaging support files
5 Edit the file.

6 When youre done, you can click either of the following:
s
File=>Save a Copy to save a copy of the file to your local system
File=>Update Original to update the file on the remote system
To edit and save log files

1 Click the leaf component under a service or an application, such as SIM Cells, to
select it.
2 From the notebook tabs, choose Administer=>Logs.

The drop list reveals the log files of the selected component.
3 To modify a file, select it from the list, and click View.

4 In the dialog box, enter the credentials of the remote system, and click OK.
The log file is displayed in the editor.
5 Edit the file.

6 When youre done, click File=>Save a Copy to save a copy of the file to your local
system.
You cannot update a log file on a remote system. You can save it only to the local
system.

You can package selected debug files to help troubleshoot customer cases.
Infrastructure Management automatically packages the selected files into a zipped
file.
146
To package support files

1 Click on the leaf component under SIM Cells, for example, to select it.
2 From the Notebook tabs, choose Administer=>Support Package.
3 In the Destination field, enter the file path where the package should be saved on
the local system. You can use the Browse button to navigate to the directory.
The file name of the support package is created automatically.
4 Optional. Enter a tracking number in the Issue Number field.

5 Optional. Enter a description of the issue in the Description field.
6 Click Create Package.
7 Enter the credentials of the remote system from which you are retrieving the files.
Chapter 5
147
Launching remote actions
A pop-up progress indicator shows the status of the retrieval. If it completes

successfully, go to the specified directory and review the contents of the zipped
package. The file contents vary based on the type of component. Here are typical
files for a SIM server component.
8 Repeat steps 1 through 7 for an Impact Administration Server component,

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

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

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

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

component. The actions permitted on this component are different from those of
the EM or SIM Cell component. They are limited to Stop Process and Start Process.
You can also launch remote actions for selected components by clicking one of the
Action toolbar icons of the Infrastructure Management view.
Depending on the type and state of the selected component, you can choose from
among the following actions:
s
s
s
s
s
s
s
Start Cell Server Process (Start)

Stop Cell Server Process (Stop)
Restart Cell Server Process (Restart)
Pause Events Admittance (Pause)
Resume Events Admittance (Resume)
Set to Active
Set to Standby
Different actions are enabled based on the status and type of component. For
example, if a component in an unknown state is already started and you choose
Actions=>Start, you receive a status message notifying you that the component is
started already. Refer to Remote actions on page 174 for more information.
Common Infrastructure Management tasks

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

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

Definition
logical services grouping
IAS (Impact Administration Server)
SIM cell
SIM cell server 1
SIM cell server 2 (high availability implementation)
SIM cell server standby (high availability implementation)
EM Cell
EM cell server 1
EM cell server 2 (high availability implementation)
BEM cell server standby (high availability implementation)
OVO Fetcher
BMC Portal Server
150
Table 39
Icon listing for infrastructure management model (part 2 of 2)
Icon
Definition
BMC Publishing Server
Integration for BMC Remedy Service Desk
Select the BMC Impact Solutions grouping, which contains the default infrastructure
model, and drag-and-drop it on the graph viewing area. You may need to select the
Orientation icon to display it along a vertical axis.
Multiple graphs
You can display multiple graph views. For example, you can select registered
components from the Results list in the navigation pane, and drag-and-drop them on
the graph viewing area, creating new graph views. You can switch from one view to
the other by selecting the tabs at the top of the graph viewing area.
Navigation tree
To help organize your model, you can display and manipulate the grouping and
component hierarchy in the navigation tree view under the Infrastructure
Management heading.
You can select objects in the navigation tree and display them in the graph viewing
area.
You can drag objects from the graph viewing area and drop into the navigation tree,
creating a navigation link between the two.
TIP
You can press the CTRL or SHIFT key and then click an object in the navigation tree to display
the object in the graph viewing area without closing any displayed objects.
Chapter 5
151
Displaying and understanding the Details and Administer tab data
You can create customized subgroups under the Infrastructure Management

heading. After selecting the heading, right-click to open the Add a sub group menu
item.
After you define your group, you can drag and drop component objects into it.
Displaying and understanding the Details and Administer tab

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

General
In the General subtab, you can view the name, class, and subtype of the selected
object. Depending on the subtype, you can also view other slot values, as described in
Table 40.
152
Table 40
Slot 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
Master Repository
specifies the data source of the component object. For example,

component objects that originate from a direct feed source, such as
BMC IX, mposter, or an MRL, are designated in this format: CellcellName. The default name for Infrastructure Management is
Cell_Admin.
Run State
the current state of the object, which helps to determine its status, its
icon shape, the icons color, as well as which actions can be performed
against the object. This slot value is updated whenever the component
changes its state, from start to stop, from start to paused, from stop to
start, and so forth.
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.
From the General subtab, you can click Edit Component to open the Edit Service
Component dialog in which you can modify the components properties.
Status
In the Status subtab, you can view the applicable status levels of the component:
Service Level Agreement, manual status, maintenance mode, and computation
statuses.
Priority and Cost

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

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

To open the Edit Relationships dialog box, select an infrastructure object in the graph
area. Then do one of the following:
s
s
s
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
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
156
Description
lists the consumer, provider, or both consumer and provider

relationships of the selected component subtype and component
Creating logical components
Table 41
Edit Relationship dialog: field descriptions (part 2 of 2)
Field
Description
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 providers main status
Editable
indicates whether you can edit the object in BMC IX
You can search on component types by selecting an Impact Administration subtype

from the drop-down list. When you click Search, it retrieves the relationships
associated with the selected subtype.
Select an item in the Edit Relationships dialog, and right-click to open the pop-up
menu. You can perform actions common to all object relationships: View Service
Impact Graph, View Events, Edit Component, Add Navigation Link, and Add
Relationship.
You can edit any of the components relationships by selecting it and then choosing
the Edit Relationship button at the bottom of the dialog. The Edit This Relationship
subdialog contains the following fields:
Table 42
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
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.
Chapter 5
157
Deleting components
Although logical components are not registered with the IAC and therefore do not
provide real-time status information, they can help to complement the BMC
infrastructure model. For example, you can add logical integrations and server
processes to the model to represent an idealized infrastructure environment.
NOTE
The names of logically created components do not display in Korean in the graph viewing
area while its component object does.
Deleting components
You can delete both logical service groupings/objects and live, registered objects
from the Infrastructure Management service model.
To organize your service model around its real-time components, you can delete
logical groupings that do not have registered components associated with them.
Generally, you should delete the leaf objects, not objects that lie between other
objects. If you delete objects that lie between other objects, some objects that should
be deleted because of relationship associations with the other objects will nonetheless
remain.
BMC recommends that you do not delete components that have been registered
automatically with the Infrastructure Management service model. However, if you
delete a live, registered object, it is removed from the Infrastructure Management
service model, and an event of the class Service Model Component Delete is sent to
the IAC.
TIP
You can recover a deleted registered object by modifying the DATA/ADMIN_DATA/
ADMIN_REGISTRATIONS table of the IAC in the Administration tab view.
You change the enable parameter for the specific component from NO to YES in the Edit tab.
Then you restart the component to reregister it.
158
Usage reporting
Usage reporting
NOTE
The File=>Usage Report menu option is only available in the Administration view. It does
not display in the Events or Services view.
In the Administration view, you can choose the File=>Usage Report menu option to
display and print a report that lists the BMC components which are registered with
the BMC Impact Administration cell. These components include:
s
s
s
s
SIM and BEM management servers

SIM and BEM standalone cells
SIM and BEM high availability cells
integrations
s BMC Impact Integration for HP Openview Network Node Manager
s BMC Impact Integration for HP Openview Operations
s BMC Impact Integration for BMC Remedy Action Request System
s Integration for BMC Remedy Service Desk
s BMC Impact Integration fro PATROL 3.x
s BMC Impact Integration for PATROL 7.x
NOTE
By default, users belonging to the user group Full Access, Service Administrators, Service
Managers, or Service Managers - Senior can access these reports.
You can save and print the report in any of the following formats:
s
s
plain text file

comma-separated values (CSV) for tabular data presentation
To display and save a usage report

Be sure that you are connected to the Admin cell. Otherwise the Usage Report...
option is unavailable.
1 In the Administration view, choose File=>Usage Report.

2 You can choose to save the list in .csv or .txt format or to print the display screen.
Chapter 5
159
Executing remote actions

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

Your remote actions are restricted when working with a high availability (HA)
configuration in which the primary cell server is down and the secondary cell server
is in a passive state.
s
When the Impact Administration cell (IAC) is in an HA configuration, do not

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

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

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

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

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

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

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

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.
Chapter 5
163
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.
164
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
s
s
s
s
s
viewing the graph of a selected component and its relationships

viewing events associated with the selected component
setting manual status and maintenance mode
adding links to components from container folders
refreshing the graph view after making an edit to a component or relationship
Configuring the audit log

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

s
s
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 hosts 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
Supported component or application types

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

You can create a support package for troubleshooting purposes by collecting files
from remote systems and saving them to a specified file path on the local or a remote
system.
The support package contains the following files:
s
s
s
s
s
s
s
.dir files
.conf files
filter files
selector files
mapping files
trace files
trace.conf files
In addition, it contains
s
default support files

These are internal files of the infrastructure application. They are not included in
the other categories. They vary among the applications, but they include .baroc,
.mrl, .wic, and .cmd files. Generally, for a cell server, this package contains the files
of its KB directory and its log directory. You can choose which files to include.
They also include a sysinfo.text file that captures active port connections, OS and
hardware configurations, and network card details. The absolute file path to each
file is included.
additional support files

This is a customizable list of files that the user can edit by adding or deleting files
to or from the support package. It is designed to enable the user to add other files
to the support package.
Specifying your support files

You can specify which support files you want to receive by editing the corresponding
slot in the Edit Service Component dialog for the selected component.
To specify which support files to include, select the component and choose Edit=>Edit
Component or choose Edit Component from the right-click pop-up menu. The Edit
Service Component dialog is displayed. Scroll down the list of slots. You can specify
values in the slots specified in Table 45.
Chapter 5
169
Your support files should be on the system on which the component is running. Enter
the full path to the file you want to include. If you are adding multiple files, separate
the complete file paths with commas. There is no limit to the number of files that you
can add.
Table 45
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
To compile your support package, choose the Administer=>Support Package tab.

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

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

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

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

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

A cell is automatically registered with the Admin cell whenever you use the
Installshield installation and specify an Impact Administration Server during the
installation routine.
However, when you add a cell using the mcrtcell CLI, you need to register the cell
with the Impact Administration Server using the iadmin -ac command.
172
Recreating an Admin cell
To manually register a cell with the Admin cell

1 Add the cell using the mcrtcell CLI, as in the following example:
mcrtcell -p 2008
-as
sparkles_cell
2 Next, use the iadmin -ac command to register the cell with the Impact
Administration Server. From the /bin subdirectory of your
IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin -ac
command as in the next example:
iadmin -ac
name=sparkles_cell:key=mc:primaryHost=moondog:primaryPort=2008:
failoverHost=suncat:failoverPort=2008:environment=Production:
usergroups=*
The cell is added automatically to the IMPACT_SOLUTIONS_HOME/server/conf

cell_info.list of the Impact Administration Server. It is also automatically added to
the IMPACT_SOLUTIONS_HOME/server/data/admin admin.dir file of the Admin
cell, as in the following example:
cell
cell
cell
moondog_10
mc
Admin
mc
sparkles_cell mc
moondog.bmc.com:1828
moondog.bmc.com:1827
moondog.bmc.com:2008 suncat.bmc.com:2008
In the Event view, you see that the cell you have registered sends a registration event
to the Admin cell.
Recreating an Admin cell

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

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

The current state of a selected component is shown in its run_state slot (Run State),
which you can view in the Details=>General subtab in the Infrastructure Management
tab. The different run_state values are described in Table 46 on page 174:
Table 46
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 its 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
The current run_state of the component determines which context-sensitive actions

are disabled or enabled from the Actions option on the right-click menu.
Table 47 on page 175 indicates which menu options are enabled (Yes) or disabled
(blank) for each run_state of a normal cell or a primary cell in an HA configuration.
174
Remote actions
Table 47
Component state and menu options for a normal or primary cell in a high availability
configuration
Menu options
Start
Cell
Server
Process
run_state
state_unknown
Stop
Cell
Server
Process
Restart
Cell
Server Pause Events Resume Events
Process Admittance
Admittance
Set to
Standby
Set to
Active
Yes
state_active
Yes
Yes
Yes
Yes
Yes
Yes
state_started
state_stopped
Yes
Yes
state_unavailable
Yes
Yes
state_paused
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 on page 175 indicates which menu options are enabled (Yes) or disabled
(blank) for each run_state of a secondary cell in an HA configuration.
Table 48
Component state and menu options for a secondary cell in a high availability
configuration
Menu options
run_state
state_unknown
Start
Cell
Server
Process
Stop
Cell
Server
Process
Restart
Cell
Server Pause Events Resume Events
Process Admittance
Admittance
Set to
Standby
Set to
Active
Yes
state_active
Yes
Yes
Yes
Yes
Yes
Yes
state_paused
Yes
Yes
state_passive
Yes
Yes
state_unavailable
Yes
state_started
state_stopped
Yes
Yes
Yes
Yes
Chapter 5
175
Remote actions
Exceptions
Generally, most component objects receive the actions Start, Stop, Restart, Pause, and
Resume.
For cell servers, the Start, Stop, and Restart menu options in the Actions submenu are
described as:
s
s
s
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:
s
s
s
Start Process
Stop Process
Restart Process
For OVO adapter cells, the menu options in the Actions submenu are described as:
s
s
s
Set OVO User/Password

Initialize OVO Publication
Fetch From OVO
Different actions are available for different types of components. Table 49 lists the
main exceptions:
Table 49
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 receives the Restart action only

(IAS)
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
Logical components that you add to the Infrastructure Management service model
receive no actions.
176
Chapter
Managing the BMC Impact Explorer

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

For the web launch option of the BMC IX console, a unique properties file is created
in the directory of the BMC Impact Portal. For the application mode launch, this file
is stored at MCELL_HOME\server\data\econsole.
The IMPACT_SOLUTIONS_HOME\server\data\econsole\username.econ.config
configuration file helps BMC IX to manage its tool bars. This file is based on the
default.econ.config properties file that is created at the standard and Atrium
installations. For every user, it records the tool bar locations in a separate file with the
user name, such as ServiceOperators.econ.config.
Figure 21 illustrates the username.econ.config file.
Figure 21
default.econ.config file contents
#Mon Jan 20 17:51:13 CDT 2003

toolbar_orientation=0
toolbar_layout=North
framework_bounds=444,256,512,384
user.region=US
Figure 22 illustrates a file Operator.econ.config created for a user named Operator.

Figure 22
Operator.econ.config file contents
#Wed Feb 05 11:52:22 CST 2003

user.region=US
toolbar_orientation=0
config_dialog_position_y=191
config_dialog_height=520
toolbar_layout=North
config_dialog_position_x=288
config_dialog_width=394
framework_bounds=229,259,512,384
178
Selecting a single BMC IX instance for cross- and web-launching
Selecting a single BMC IX instance for crossand web-launching

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

Another aspect of control vested in the BMC Impact Portal is the policy file that BMC
Impact Explorer retrieves each time a user connects to the BMC Impact Portal. This
file contains parameters that define BMC Impact Explorer console-wide policies for
all users. At installation, the default policy file, default.console_policy.prop, is created;
it is located in the IMPACT_SOLUTIONS_HOME\server\data\policy directory.
The policy file is never saved from the BMC Impact Explorer console, only retrieved.
If a specific user has a particular need, it is possible to create an individual user policy
file, username.console_policy.prop, based on the default and located in the same
IMPACT_SOLUTIONS_HOME\server\data\policy directory. This individual user
policy file will be returned to the BMC Impact Explorer console, rather than the
default file, default.console_policy.prop, when the user logs on. For ease of
maintenance, BMC Software recommends that the default be used for most users.
Table 50 on page 180 summarizes the parameters in the default policy file.
179
Table 50
default.console_policy.prop parameters
Parameter
Description
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
data_handle_sleep_interval
data_paste_chunk_size
parameters used to manage data-handling actions such as copying,

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

You can use the ix.properties file to configure the display and connection settings for
BMC IX. Table 51 lists the property settings included in the ix.properties file.
Table 51
Property descriptions from ix.properties file (part 1 of 2)
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
183
Defining global event severity and priority color values
Table 51
Property descriptions from ix.properties file (part 2 of 2)
Console property
Description
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
Defining global event severity and priority

color values
Event records are displayed in the BMC Impact Explorer Events View using colors
that represent their level of severity and priority. The color.properties file, located in
the IMPACT_SOLUTIONS_HOME\server\conf directory, defines severity and priority
value colors for the events and contains the default color values. The color.properties
file also can contain custom definitions for the status conditions of BMC Service
Impact Manager components.
Modify this file if you want to define custom colors for event severities and priorities.
To avoid confusion, each user receives the same colors for events that the BMC
Impact Explorer console interface displays. Refer to Customizing colors for
severities, statuses, and priorities on page 99 for more information.
Table 52 lists the default severity level colors and their values, as defined in
color.properties.
Table 52
Event severity levels and colors
Severity level
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
184
Color
Hexadecimal RGB values in color.properties
gray
CCCCCC,000000
Event group configuration files
WARNING
s
The entries are the default color properties. Do not delete these properties.
If you customize the severities by increasing the number of levels to be greater than the
number of default severity levels, the severity list on the Event and Services Views
becomes truncated and partially illegible. Restrict your customizations to the same
number or fewer severity levels.
Table 53 lists the default priority level colors and their values, as defined in
color.properties.
Table 53
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
To globally change the default severity or priority colors, modify the color.properties
file and stop and start the BMC Impact Administration Server.
NOTE
Modifications made to the color.properties file do not immediately appear in the BMC Impact
Portal. By default, the BMC Impact Portal configuration.update.interval parameter
checks for changes every 300 seconds.
Event group configuration files

The event group configuration file structure is listed in Table 54:
Table 54
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
185
XML files that define user interface elements
Table 54
Event group configuration files (part 2 of 2)
Folder
Contains
\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
XML files that define user interface elements

Table 55 lists XML files that control some user interface characteristics in BMC Impact
Explorer that cannot be edited in the BMC IX user interface.
Use care when you edit these files to avoid unexpected and undesirable results.
These files are located in IMPACT_SOLUTIONS_HOME\server\data\extdetails.
Table 55
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
186
Chapter

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a new presentation name resource file. . . . . . . . . . . . . . . . . . . . . . . . . . .
Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . .
Digitally signing a .jar file with a digital test certificate . . . . . . . . . . . . . . . . . . . .
Enabling or disabling presentation names in BMC Impact Explorer tool tips . . . . .
Chapter 7
188
188
189
190
191
192
192
194
195
187
Presentation names overview
Presentation names overview

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

s
s
s
s
s
BMC Impact Explorer Services View
s
s
s
BMC Impact Explorer Administration View
s
s
s
BMC Impact Portal
s
s
s
s
s
s
BMC Impact Service

Model Editor
s
s
s
event class names

slot names
enumeration class names and values
collector names
action names
service model class names (component types) and slot names
service model management class and slot names
service model enumeration class names and values
policy type names
event class names
slot names - In the Event Selection Criteria column, the internal
slot names are shown because this is the actual text of the ECF.
event class names
slot names
enumeration class names and values
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.
s
For BMC Impact Explorer, the default presentation names are defined in the
following two files:
s
188
InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\
kb_core_resource.properties
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)

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

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

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

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

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

Each BMC Impact Solutions application searches the presentation name resource files
differently.
Presentation name resource file search order for BMC

Impact Explorer
BMC Impact Explorer searches a list of local resource files for presentation name
keys. You specify the order in which resource files are searched by defining the
search order in the kb_info_resource parameter located in the
InstallDir\BMC Software\MasterCell\console\etc\ix.properties file.
Because BMC Impact Explorer searches a set of files in the order you specify, you can
override the presentation names in the default file by creating a new .properties file,
defining presentation names in this file and listing the new .properties file before the
default file in the kb_info_resource parameter. (For instructions on creating a new
.properties file, see Creating a new presentation name resource file on page 190.)
For example, if you created a new .properties file called my_ix_names.properties and
you wanted BMC Impact Explorer to search this file first, you would modify the
kb_info_resource parameter to look like this:
# Specifies the set of files to load for kb specific resources (base names only,
comma separated list)
kb_info_resources=my_ix_names, kb_core_resource, kb_deprecated_resource

Impact Portal
The BMC Impact Portal searches for presentation name keys in the files located in the
/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
/en_US/smsConsoleServer directory. For more information about modifying
presentation name keys, see Defining presentation names on page 192.
Chapter 7
191

Impact Service Model Editor
The BMC Impact Service Model Editor looks for presentation name keys in the
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/
en_US/smsConsoleServer/kb_core_resource.properties file.
If you want to add custom classes or extend existing classes to add new attributes,
you can add them to the kb_core_resource.properties file. For more information about
modifying presentation name keys, see Defining presentation names on page 192.

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

The entries in kb_core_resource.properties have the form
key=value
where value is the presentation name. The value can contain space characters.
Table 56 lists the formats for the presentation name key.
Table 57
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
192
Creating or modifying presentation name keys
To create or modify presentation name keys

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

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

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

For example: keytool -genkey -keystore myKeystore -alias myself. This command
creates a new key in the keystore file named myKeystore on disk.
2 Create a self-signed test certificate by following these steps:

keytool -selfcert -alias <my_alias> -keystore <keystore_filename>
B Enter the password at the prompt.

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

keytool -list -keystore <keystore_filename>
194
Enabling or disabling presentation names in BMC Impact Explorer tool tips
The resulting listing should appear as follows:

Figure 24
Listing of the contents of a keystore file
Keystore type: jks

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

BMC Impact Explorer tool tips
A BMC Impact Explorer user can view the internal object names as tool tips when the
mouse pointer is over
s
s
s
s
s
s
a presentation name in a column header

a presentation name that labels a slot value (for example, in an Event Details tab)
the label of a drop-down list or field that shows a presentation name,
a slot presentation name in a list box (as in the Edit Slot Order window)
a class presentation name in the Class Chooser window
a class presentation name in either of the Administration tab navigation trees
Chapter 7
195
Enabling or disabling presentation names in BMC Impact Explorer tool tips
Tool tips are not shown for

s
s
classes in the Services tab Of type list

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

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

The StateBuilder is an executable, statbld.exe, located in the MCELL_HOME\bin
directory. It records saved states of the cell at regular intervals. When it starts, the cell
loads its last saved state (mcdb). All transactions it performs are stored in a
transaction file (xact). As soon as the transaction file reaches a certain size, or after a
certain period, the StateBuilder is started. It produces a new saved state from the
previous file and from the transaction file. When the cell terminates and restarts, any
trailing transaction file is first processed by the StateBuilder to produce a new saved
state. A history of saved states and corresponding transaction files can be kept. The
mcdb and xact files of that history have their timestamp in the file name.
All mcdb and xact files are located in the MCELL_HOME\log\cellName directory. The
StateBuilder runs as configured in the cells mcell.conf file, which is detailed in
StateBuilder configuration file on page 199. The configuration of how the
StateBuilder itself operates is in the statbld.conf file.
Table 58 on page 198 lists the file naming conventions for the StateBuilder.
Table 58
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.
There is also a statbld.trace file for the configuration of StateBuilder tracing. For
further information, see Configuring tracing for StateBuilder on page 207.
The StateBuilder uses the gateway.export file in conjunction with its statbld.conf file to
export event data. For more information, see the StateBuilder configuration fileand
Exporting events on page 205.
198
StateBuilder configuration file
StateBuilder configuration file

The state configuration file, statbld.conf, is located in the MCELL_HOME\etc directory.
Table 59 lists the statbld.conf parameters, which use the same syntax as all BMC
Impact Solutions configuration files.
Table 59
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
ExportDiscarded
indicates whether discarded events are included in the No

export file
%H/etc/%N/gateway.
export
Discarded events are those that were dropped in the

first four rule phases: Refine, Filter, Regulate, and
New (Update).
sets the arguments to be passed to the executable
serving as the export trigger program
ExportTriggerArguments
blank; no arguments
Value is interpreted as a sequence of space-separated

arguments, so spaces within each argument are not
allowed.
sets the program to execute after exporting data
ExportTriggerProgram
blank
The value is interpreted as a path. See the mcell.conf

file for special syntax for a path.
sets the number of state files to retain in the history
StateHistoryCount
Each time a new saved state is produced, the oldest

state is removed.
statbld return codes

Table 60 lists the return codes for statbld.
Table 60
statbld return codes (part 1 of 2)
Return code
Description
failed to build new mcdb
failed to update history files
10
early initialization failure
37
process handling module initialization failure
47
StateBuilder specific file access initialization failure
Chapter 8
199
Gateway configuration
Table 60
statbld return codes (part 2 of 2)
Return code
Description
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)
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:
s
GwTECConfigFileName=%H/etc/gateway.TEC
which means: $MCELL_HOME/etc/gateway.TEC
GwjServerConfigFileName=%H/etc/gateway.jServer
which means: $MCELL_HOME/etc/gateway.jServer
A gateway configuration file contains parameter settings in the form of

parameter=setting.
Parameters can be specified differently for new events and for event modifications.
The parameter name must be suffixed with
s
.new for new events
.mod for event modifications
Without a suffix, the setting is assumed to be on both categories. Both the contents of
a message and its format are specified using parameters.
Gateway predefined variables

Table 61 on page 201 lists the parameters that can refer to predefined variables.
200
Table 61
Gateway configuration parameter predefined variables
Variable
Description
$CLASS
class name
$CONTEXT
context name:
s Permanentevent permanently in DB (until out of date)
s Processeddiscarded by rule processing
s Regulateddiscarded by regulation
s Filtereddiscarded by filter
s Refineddiscarded by refine
s Receiveddiscarded 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
Gateway text parameters

Text parameter values consist of literal text, possibly mixed with references to
variables and with escape sequences, as shown in Table 62.
Table 62
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)
Chapter 8
201
References to variables that are not followed by punctuation or space characters must
be enclosed in curly brackets ( { } ). For example, $NAMEabc is invalid;
${NAME}abc is correct. Non-printable characters and hard spaces must be expressed
with an escape sequence. String values for parameters are considered from the first
non-white space character up to the first (non-escaped) white space character.
Table 63 on page 202 lists the gateway.export file parameters.
Table 63
gateway.export file parameters (part 1 of 2)

Parameter
Communication protocol
parameters
Description
sets the communication protocol. Both categories, new event and
modification, use the same protocol. The last one specified is used. The
default value is MCELL.
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
Contents
parameters
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.
202
Table 63
gateway.export file parameters (part 2 of 2)

Parameter
Format
parameters
Description
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 ().
Gateway configuration value mapping

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

To actually replace the values of slot severity, the slot has to be dropped and a new
slot, with the same name, has to be added, mapping the value:
EXAMPLE
drop=[severity]
add=[severity=$MAP.GW1severity($VALUE(severity))]
Example of printed events

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

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

In a gateway.export file, you can configure what data goes into the export file and how
that data is formatted. A default gateway.export file exists in the MCELL_HOME\etc
directory. Copy the gateway.export file to the MCELL_HOME\etc\cellName directory
and edit the copy.
By default, the gateway.export file has the format shown in Figure 28.
Figure 28
gateway.export file format
# Export Gateway Configuration

#
cond=always
slots.new=[$ALL]
slots.mod=[$MODS]
body=$VALUE
term=\n
separator=,
quotable=,"
openquote="
closequote="
escapequote="
Using the default values in the gateway.export file for new events produces output in
the format shown in Figure 29.
Figure 29
gateway.explore file output for new events
0,1010183001,1,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0,
mc.exp.000000001,0,['exp:1'],[],[],[],[],[],0,[],exp,
10.0.9.10:1981,28698
0,1010183001,2,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0,
mc.exp.000000002,0,['exp:2'],[],[],[],[],[],0,[],exp,
10.0.9.10:1981,600
206
Configuring tracing for StateBuilder
Using the default values in the gateway.export file for modified events produces
output in the format shown in Figure 30.
Figure 30
gateway.explore file output for modified events
mc.exp.000000001
exp
10.0.9.10:1981
28698
mc.exp.000000002
exp
10.0.9.10:1981
600
ACK
1010183062
mc.exp.000000003
exp
10.0.9.10:1981
28698
Configuring tracing for StateBuilder

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

If the StateBuilder process (MCELL_HOME/bin/statbld) fails to start, try the following
solutions:
s
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:
s
s
mcdb.0
mcdb.lock
If either of these files are present, delete them.
Chapter 8
207
Trouble-shooting the StateBuilder process
B From a command line, manually run the StateBuilder process by entering:

statbld -n cell_name
s
Check the MCELL_HOME/log/cell_name directory to ensure that your xact.n files are
named xact.1, xact.2, and so forth. If the file does not have the numeric extension (.n)
(the file is only named xact), then rename the file to xact.1.
Determine whether or not the MCELL_HOME/bin/statbld program exists and can be

executed by the current user who is running the mcell process.
Verify your systems available memory and compare it with the actual memory
usage of the mcell process.
On some UNIX platforms, available unused virtual memory must equal or exceed
the virtual memory used by the mcell process.
208
Appendix

This appendix provides reference information on the BMC Impact Solutions and
BMC Impact Portal command line interfaces (CLI) and their configuration. It contains
the following topics:
BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . .
BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . .
mccompCompiling rules in the Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . .
mcellStarting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mcfgtraceConfiguring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mclassinfoRequesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mcollinfoGetting information about a specific collector . . . . . . . . . . . . . . . . . .
mcontrolPerforming cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mcrtcellCreating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mcstatReturning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mdelcellDeleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mgetinfoRetrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . .
mgetrecObtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mkbUpdating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mkillStopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mlogchkPerforming consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mposter and msendManaging data and events . . . . . . . . . . . . . . . . . . . . . . . . .
mqueryRetrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mrecoverRecovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . .
mrextractExtracting cell state files to create new state files . . . . . . . . . . . . . . .
mrmergeMerging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetmsgModifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
msetrecSetting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . .
BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A
210
211
213
214
216
218
220
225
228
231
235
237
238
243
245
248
249
251
257
262
264
265
267
268
269
272
272
209
BMC Impact Manager CLI commands
BMC Impact Manager CLI commands

Use the commands from the command line interface (CLI). All of the cell-related CLI
commands are located in MCELL_HOME/bin on UNIX and MCELL_HOME\bin on
Windows.
You can invoke the commands from a command prompt on Microsoft Windows,
from a UNIX prompt, or from a script. A command can affect the cell, the Knowledge
Base, or other files.
Table 64 lists all of the available BMC Impact Manager commands along with a brief
description of the purpose for each command.
Table 64
BMC Impact Manager CLI command descriptions
Command
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
210
Description
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.
NOTE
A few commands have command-specific options that override the common CLI command
options listed in Table 65. For example, the -p option for the mkb command prints the
contents of the designated manifest.kb file, rather than assigning the specified value (Value)
to the option Var. If a command has an option that overrides the common option, the
command-specific option is noted in the section of this appendix dedicated to that command.
Table 65 describes the common command options that apply to all commands.
Table 65
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
-h
or
-?
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
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:
s
Designate a cell name by specifying -n cellName.
Appendix A
211
Configuring CLI authentication through BMC Impact Administration Server
This format maps the cellName to the host, port, and encryption key in the
mcell.dir file.
s
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

Any user can connect the CLI to the cell if all of the following conditions are met:
s
s
s
authenticated through the OS

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

Table 66 on page 214 describes the return codes common to all CLI commands. Some
CLI commands have return codes that are specific to that command. If a CLI
command has command-specific return codes, those codes are listed in the section of
this appendix dedicated to that command.
Appendix A
213
mccompCompiling rules in the Knowledge Base
Table 66
Common return codes for CLI commands
Code
Description
success
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

The mccomp command is the executable that calls the Knowledge Base compiler. The
only required command option is the path to the manifest.kb file.
mccomp syntax
Figure 31 shows the syntax for mccomp.
Figure 31
mccomp syntax
mccomp [-e ErrorLogFile] [-h|?] [-n CellName | ManifestKBFilePath] {-p Var=Value}

[-l HomeLocation] [-t] [-v [VERBOSE|INFORM|WARNING|ERROR|FATAL]] [-z]
Table 67 lists the command-specific options for mccomp. For a list of common
command options that apply to all CLI commands, see BMC Impact Manager CLI
common command options on page 211.
214
Table 67
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.
The -t option enables extra cell runtime tracing by the rules engine if the cell
configuration parameter TraceRuleLevel=2. The trace output goes to the standard
cell trace in the RULES module. You can include the output in the transaction file by
setting TraceRuleToXact=Yes.
WARNING
A Knowledge Base compiled for runtime rule tracing using -t can experience considerable
runtime performance degradation.
mccomp example
Figure 32 shows an example of mccomp.
Figure 32
mccomp example
mccomp -n cell1
This command produces output similar to the example shown in Figure 33.
Figure 33
Example output for mccomp
Parsing BAROC file classes/root.baroc

Parsing BAROC file classes/intevt.baroc
Compilation ended successfully
mccomp return codes

There are no command-specific return codes for mccomp. For a list of common return
codes that apply to all CLI commands, see BMC Impact Manager CLI common
return codes on page 213.
Appendix A
215
mcellStarting a cell
The mcell command starts a specified cell.
mcell syntax
Figure 34 shows the syntax for mcell.
Figure 34
mcell syntax
mcell [-h|-?] [-z] [-q] [-d] [-i [a][c][d][e]] [-r] [-n cellName]
[-l HomeLocation] [-c ConfigFile] {-p Var=Value}
Table 68 lists the command-specific options for mcell. For a list of common command
options that apply to all CLI commands, see BMC Impact Manager CLI common
command options on page 211.
Table 68
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:

s
s
s
s
s
-i-ied
-ieevents
-iddata--initializes all data
-icEventCounter
-ia-iedcinitializes all data
Warning: Although these options are available, BMC Software recommends that
you do not use an of the -i options except for -ia. Unexpected cell states can occur if
you initialize only events or only data, because events and data may be correlated.
If you need to restart a cell from an empty state, empty the cell's log directory
(MCELL_HOME/log/CellName) and then start the cell without using any of the -i
options.
Note: If you start a cell using the -ia or -id options, you must re-register the cell
with the BMC Impact Portal.
Note: The -i option for the mcell command overrides the -i option in Table 65
Common options for CLI commands on page 211.
-r
216
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:
s
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.
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.
To start the cell as a service on a Microsoft Windows platform, type the command
shown in Figure 36.
Figure 36
Starting a cell as a service on windows
net start mcell_cellName
When started from command prompt without the -d option, mcell contacts the
Service Control Manager to start itself as a service. It uses mcell_cellName as the
service name, with the cell name as specified with the -n option. Without the -n
option, the host name is taken as cellName.
s
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 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.
Appendix A
217
mcfgtraceConfiguring tracing
mcell return codes

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

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

The mclassinfo command retrieves class information about both event and data
classes that are loaded in the cell. Information consists of class name, slot
descriptions, and subclasses.
You can retrieve the complete class tree in a hierarchical form, or you can retrieve
only selected classes, instead of the whole hierarchy.
You can retrieve associated definitions of enumerations used in the classes. These
definitions are reported before the class tree.
mclassinfo syntax
Figure 40 shows the syntax for mclassinfo.
Figure 40
mclassinfo syntax
mclassinfo [-a Amount] [-d] [-e] [-c ConfigFile] [-h|-?] [-l HomeLocation]
[-i UserID[/Password][@Host[/Port]]] [-n cellName | -n @Host[/Port[#Key]]]
[-o OutputFile] [{Class}] {-p Var=Value} [-r] [-q] [-u] [-v] [-x] [-z]
Table 72 lists the command-specific options for mclassinfo. For a list of common
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
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.
220
Raw output format

The output consists of the class tree, optionally preceded by the enumeration
definitions, as shown in Figure 41 on page 221. The enumeration definitions are
reported as EnumInfo.
Figure 41
Raw output format for mclassinfo
EnumInfo
EnumTypeInfo
=
=
EnumTypeCount (EnumTypeInfo)*EnumTypeCount
EnumTypeName EnumValCount (EnumValName)*EnumValCount
The class tree is reported depth-first, left-to-right, as ClassInfo, as shown in

Figure 42.
Figure 42
Class tree for mclassinfo
ClassInfo
ClassCompInfo
= ClassCompCount(ClassCompInfo)*ClassCompCount
= ClassName ClassFlags ClassSlotCount
(ClassSlotInfo)*ClassSlotCount ClassInfo
ClassSlotInfo
= ClassSlotName ClassSlotValType ClassSlotRepType
ClassSlotFlags ClassSlotDefaultValueLength
ClassSlotDefaultValueText
ClassSlotValType
= ClassSlotStructCode ClassSlotTypeCode
ClassSlotStructCode = S | L
ClassSlotTypeCode
= i | r | p | s | e:EnumerationTypeName
| c | c:BaseClass
| q | q:BaseClass
ClassSlotFlags
= (r|R) (k|K) (p|P) (d|D) (h|H)
Slot value types (ClassSlotValType) are encoded by two characters. The first one
indicates whether it is a simple slot (S) or a list (L). List slots are defined in BAROC as
LIST_OF. The second character determines the type of the slot value. It corresponds to
the BAROC definition as listed in Table 73.
Table 73
Type of slot value for mclassinfo
Slot Type
Definition
INTEGER
REAL
POINTER
STRING
e;EnumerationTypeName
Enumeration
c:BaseClass
ECF of BaseClass
q:BaseClass
QUERY of BaseClass
A slot representation type (ClassSlotRepType) corresponds to the representation

facet of the slot. If that facet is not specified, it is reported as an asterisk (*).
Appendix A
221
Flags contain Boolean facets of the slot. For every facet, one character is reported. An
uppercase character means the facet is TRUE; a lowercase character means it is FALSE.
Table 74 on page 222 lists the facets that are reported.
Table 74
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
Standard output format

Standard output format is formatted for end-users but does not report the counts and
represents the tree structure through indentation.
Information amount
The amount of reported information is limited as shown in Table 76.
Table 76
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
mclassinfo examples
mclassinfo can be used as shown in the following examples.
222
Obtaining a list of classes

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

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

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

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

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

Figure 48
Class:
Slot:
Slot:
Slot:
Slot:
Slot:
Slot:
.
.
.
Example of mclassinfo command output for adding slot names

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

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

Figure 50
Class:
Slot:
Slot:
Slot:
Slot:
Slot:
Slot:
.
.
.
224
Example of mclassinfo command output for adding slot flags

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

Table 77 lists the command-specific return codes for mclassinfo. For a list of common
Table 77
mclassinfo return codes
Code
Description
31
cannot read input file

The mcollinfo command retrieves information about collectors loaded in a cell.
Information consists of collector name, permission settings, referenced classes and
subcollectors. The complete collector tree is retrieved and reported in a hierarchical
form. As an option, specific information about selected collectors can be retrieved
instead of the whole tree.
mcollinfo syntax
Figure 51 shows the syntax for mcollinfo.
Figure 51
mcollinfo syntax
mcollinfo [-a Amount] [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]]

[-h|-?] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]]
[-l HomeLocation] [-r] [-o OutputFile] [-v] [-q] [-z]
(-d | [-g] [-s] (Collector | -f InputFile))
Table 78 lists the command-specific options for mcollinfo. For a list of common
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
Appendix A
225
Table 78
mcollinfo options (part 2 of 2)
Option
Description
-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
mcollinfo output
You can request output in raw format for parsing by a program. You can also request
standard output formatted for users, including verbose output that provides
additional information. See the preceding table for the available options.
Raw output format

Raw output consists of the collector tree, as shown in Figure 52 on page 226. The
collector tree is reported depth-first, left-to-right, as CollInfo.
Figure 52
Raw output format for mcollinfo
CollInfo = CollCompCount (CollCompInfo)*CollCompCount

CollCompInfo = CollName CollPerm CollClassCount
(CollClass)*CollClassCount CollInfo
CollPerm : CollPermR CollPermW CollPermX
CollPerm_ : CollRoleCnt (CollRole)*CollRoleCnt

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

6.1
You can request user-formatted output in verbose mode as shown in Figure 54.
Figure 54
mcollinfo command for verbose mode
mcollinfo -n dbg -v -o Net.Global

Collector Net.Global
OID=6.1
You can also request the number of events for each severity/status combination in
the collector as shown in Figure 55. You must specify the collector name.
Figure 55
mcollinfo command for number of events for severity/status
mcollinfo -n dbg -v -s Net.Global

Collector Net.Global
Severities=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Appendix A
227
mcontrolPerforming cell control operations
mcollinfo return codes

Table 80 lists the command-specific return code for mcollinfo. For a list of common
Table 80
mcollinfo return codes
Code
Description
31
cannot read input file

The mcontrol command performs control operations on a cell. The operation is stated
as an argument.
mcontrol syntax
Figure 56 on page 228 shows the syntax for mcontrol.
Figure 56
mcontrol syntax
mcontrol [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value}

[-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-v] Control
[ -i UserID[/Password][@Host[/Port]] ]
Table 81 lists the command-specific option for mcontrol. For a list of common
Table 81
mcontrol option
Option
Control
228
Description
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 metrics
off = disables metrics
reset = 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
s
s
s
s
s
s
s
dirmcell.dir
tracemcell.trace
confmcell.conf, propagate, modify
collectcollector definitions
kbKnowledge Base, classes, rules
datadata instances
allall 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
Appendix A
229
Table 82
mcontrol controls (part 2 of 2)
Control
Description
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).
mcontrol examples
mcontrol can be used as shown in the following examples.
Retrying pending propagations

To retry pending propagations for a cell named grace, type the command shown in
Figure 57.
Figure 57
Retrying Pending propagations with mcontrol command
mcontrol -n grace -v prop

Figure 58
Example of mcontrol command output for retrying pending propagations
Command on server grace acknowledged
Terminating a cell
To terminate a cell named grace, type the command shown in Figure 59.
Figure 59
Terminating a cell using the mcontrol command
mcontrol -n grace -v stop
230
mcrtcellCreating a new cell

Figure 60
Example of mcontrol command output for terminating a cell
Reconfiguring a cell
To reconfigure cell grace after mcell.dir has been modified, type the command shown
in Figure 61.
Figure 61
Reconfiguring a cell
mcontrol -n grace reload dir

Figure 62
Example of mcontrol command output for reconfiguring a cell
The cell grace reconfigures without stopping and restarting.
mcontrol return codes

There are no command-specific return codes for mcontrol. For a list of common

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

[-m] -p PortNumber [-s SourceCell] [-z]
Specifying either the -ae or -as option creates a unified Knowledge Base, which
contains the default BEM and SIM KBs (see the BMC Impact Solutions Knowledge Base
Development Reference Guide for information about the unified KB). If you do not
specify the -ae or -as option, you create a cell with an empty Knowledge Base, and the
cell does not respond to requests.
NOTE
By default, mcrtcell creates a BEM cell. If you want to create a SIM cell, you must create a cell
using mcrtcell and then set the ServiceModelEnabled configuration parameter to YES in the
mcell.conf file. For more information about the ServiceModelEnabled configuration
parameter, see Cell configuration parameters on page 274.
Table 84 lists the command-specific options for mcrtcell. For a list of common
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
Appendix A
233
Table 84
mcrtcell options (part 2 of 2)
Option
Description
-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.
mcrtcell example
Figure 64 shows an example of how to create a service using mcrtcell.
Figure 64
Example of mcrtcell command
mcrtcell -p 2591 -as was05dal
Figure 65 shows the output produced.

Figure 65
Example of output of mcrtcell
Service successfully created
Figure 66 shows an example of how to create another service using mcrtcell.

Figure 66
Example of mcrtcell command
mcrtcell -s was05dal -p 2592 was04fra
NOTE
This command does not use the -ae or -as option. It makes a copy of the KB from the previous
cell.
Figure 67 shows the output produced.

Figure 67
Example output of mcrtcell
Service successfully created
234
mcstatReturning cell status
Figure 68 shows an example of how to create an Impact Administration cell using

mcrtcell.
Figure 68
Example mcrtcell for recreating an Admin cell
mcrtcell -aa -p 10011 Admin
In this example, an Impact Administration cell with the name Admin is created and
assigned to port number 10011.
mcrtcell return codes

Table 85 lists the command-specific return codes for mcrtcell. For a list of common
Table 85
mcrtcell return codes
Code Description
-1
uname command failed
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

The mcstat command obtains the status of a cell. This command shows whether a cell
is running or stopped.
Appendix A
235
mcstat Syntax
Figure 69 shows the syntax for mcstat.
Figure 69
mcstat syntax
mcstat [-h|?] [-z] [-q] [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]]

{-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]] [-v] [-t TimeOut ]
Table 86 lists the command-specific option for mcstat. For a list of common
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
mcstat example
To obtain the status for a cell named examplecell, type the command shown in
Figure 70.
Figure 70
mcstat example
mcstat -n examplecell
If the cell is not running, a message similar to the example in Figure 71 appears.
Figure 71
Message for cell not running
Could not connect to Cell examplecell.
If the cell is running, the message shown in Figure 72 appears.

Figure 72
Message for cell running
Running
mcstat return codes

There are no command-specific return codes for mcstat. For a list of common return
236
mdelcellDeleting a cell
mdelcellDeleting a cell
Use mdelcell to delete a specified cell on the local computer. Deleting a cell by using
the mdelcell command removes the cell and its entry in the mcell.dir file. You can use
this command only locally on the computer where the cell resides. Executing this
command results in the following actions:
s
s
s
removes the entry in the mcell.dir file

deletes the etc\cellName
removes the entry from the services on Microsoft Windows or the startup scripts
on UNIX
mdelcell syntax
Figure 73 shows the syntax for mdelcell.
Figure 73
mdelcell syntax
mdelcell cellName [-i UserID[/Password][@Host[/Port]]] [-z]

[-h|?] [-k] [-w TimeOut]
Table 87 lists the command-specific options for mdelcell. For a list of common
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.
mdelcell example
To delete a cell named grace, type the command shown in Figure 74.
Figure 74
Deleting a cell using mdelcell
mdelcell grace
If grace is not currently running, this command produces output similar to the
example shown in Figure 75 on Microsoft Windows platforms:
Figure 75
Output for mdelcell if cell is not running
Service successfully removed
Appendix A
237
mgetinfoRetrieving information about a cell
On UNIX platforms, the command does not produce output when it runs
successfully.
If grace is currently running, this command produces output similar to the example
shown in Figure 76.
Figure 76
Output for mdelcell if cell is running
Warning! Cell grace was running and mdelcell tries to terminate it.
Service successfully removed.
mdelcell return codes

Table 88 lists the command-specific return codes for mdelcell. For a list of common
Table 88
mdelcell return codes
Code
Description
-1
uname command failed
31
no MCELL_HOME environment variable is defined

The mgetinfo command retrieves information about a cell.
mgetinfo syntax
Figure 77 shows the syntax for mgetinfo.
Figure 77
mgetinfo syntax
mgetinfo [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]]

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

Table 90
mgetinfo information options (part 1 of 2)
Information
Description
activity
retrieves the activity status of the cell

0 = standby
1 = limited
2 = 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 cells loaded KB; information is displayed
in raw format. When combined with the -v switch, it is returned in a more verbose and
readable format.
kbsources
lists KB source files with version information from the cells loaded KB; information is
displayed in raw format. When combined with the -v switch, it is returned in a more verbose
and readable format.
metrics
reports the metrics, collected by the cell, that are stored in MC_CELL_METRIC data objects
metrics output consists of
s metric name
s metric description
s 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:
s ReceivedEventsnumber of received event messages
s ErrorEventsnumber of received event messages that are incorrect (for example,
causing a parse error)
s DroppedEventsnumber of events that are dropped during processing through the
rules
s StoredEventsnumber of events that have passed all the rules and are stored in the
Event database
s RemovedEventsnumber of events that have been removed from the Event database by
a database cleanup
s DeletedEventsnumber of events that have been deleted by clients, such as CLI or the
console
s PropagatedEventsnumber of events that have been propagated to another
destination
s ConnectedSourcesnumber of adapter clients that are connected to the cell
Appendix A
239
Table 90
mgetinfo information options (part 2 of 2)
Information
Description
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
A connect request displays the information shown in Table 91.

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 connection

for inbound connections, this is the client; for outbound, it is the cell
destination address
IP address/port of destination side of the connection

for 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
240
mgetinfo examples
This section contains examples of mgetinfo.
mgetinfo config example

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

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

mgetinfo metrics
This command produces output similar to the following:

BMC Impact InfoRetrieval 7.x.xx (Build xxxxxx - xx-xxx-xxxx)
Copyright 1998-xxxx BMC Software, Inc. as an unpublished work.
ReceivedEvents
Number of received event messages
60
0
ErrorEvents
Number of events containing errors
60
0
DroppedEvents
Number of events dropped by rules
60
0
StoredEvents
Number of events entered in the DB
60
0
RemovedEvents
Number of events removed by DB cleanup 60
0
DeletedEvents
Number of events deleted by clients
60
0
PropagatedEvents Number of propagated events
60
0
ConnectedSources Number of connected sources
60
0
All
0
0
0
0
0
0
0
0
rights reserved.
300 1
0
3616974
300 0
0
3616974
300 1
0
3616974
300 0
0
3616974
300 0
0
3616974
300 0
0
3616974
300 0
0
3616974
300 0
0
3616974
12534
94
5700
6834
27451
0
102
0
0
0
0
0
0
0
0
0
The output for mgetinfo metric consists of the metric name, a metric description and
short term, medium term and long term metrics, each consisting of
s
s
s
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,

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

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

Figure 80 shows an example of mgetinfo services.
Figure 80
Example of mgetinfo services
mgetinfo services
Figure 81
mgetinfo services command output (part 1 of 2)
MC_SM_COMPONENT
CONNECTIVITY
242
Number of MC SM Component
Number of Connectivity
87
11
mgetrecObtaining a global record value
Figure 81
mgetinfo services command output (part 2 of 2)
IT_COMPONENT
LOGICAL_COMPONENT
SERVICE_LEVEL_AGREEMENT
MC_SM_RELATIONSHIP
IMPACT_RELATIONSHIP
NULL_RELATIONSHIP
Number
Number
Number
Number
Number
Number
of
of
of
of
of
of
IT Component
Logical Component
Service Level Agreement
MC SM Relationship
Impact Relationship
Null Relationship
22
47
7
126
126
0
mgetinfo connect example

Figure 82 shows an example of mgetinfo connect.
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
2028 2071
mgetinfo return codes

Table 92 lists the command-specific return codes for mgetinfo. For a list of common
Table 92
mgetinfo return codes
Code
Description
31
not a SIM cell

Use the mgetrec command to obtain the value of a global record.
Appendix A
243
mgetrec syntax
Figure 84 shows the syntax for mgetrec.
Figure 84
mgetrec syntax
mgetrec [-c ConfigFile] [-i UserID[/Password][@Host[/Port]]]

[-h|?] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]]
-r Record[.Slot] [-q] [-z]
The -n option is required if the cell is remote and defined in the mcell.dir file, or if the
cell is local and named something other than Host.
Table 93 lists the command-specific option for mgetrec. For a list of common
Table 93
mgetrec option
Option
Description
-r Record[.Slot]
specifies the global record to be obtained, optionally limited to one

of its slots
mgetrec example
Figure 85 shows an example of mgetrec.
Figure 85
Example of mgetrec
mgetrec -r EM_KB_OPTIONS
The preceding command produces output similar to the example shown in Figure 86.
Figure 86
Output of mgetrec (part 1 of 2)
startup_script_enabled
----NO
----dfilter_enabled
----NO
----dnotification_enabled
----NO
----dpropagation_enabled
244
mkbUpdating the Knowledge Base
Figure 86
Output of mgetrec (part 2 of 2)
----NO
----default_location
-----
mgetrec return codes

There are no command-specific return codes for mgetrec. For a list of common return

Use the mkb command to create, view, or update the Knowledge Base. When you use
the mkb command to create a new Knowledge Base, a manifest.kb file is also created.
Use the mkb command primarily to check or modify a Knowledge Base with scripts,
such as when you need to upgrade the Knowledge Base automatically for a number
of cells installed across your network. After installing the files, compile using the
mccomp command.
mkb syntax
Figure 87 shows the syntax for mkb.
Figure 87
mkb
[-f
[-j
[-r
mkb syntax
[-h|-?] [-z] [-q] [-v] [-n CellName | -n @Host[/Port[#Key]] ]

ManifestFile] [-b BinFile] [-c ClassFile] [-d DataFile] [-a Arch]
RecordFile] [-l LibFile] [-m Directory] [-o CollectorFile] [-p]
RuleFile] [ -i UserID[/Password][@Host[/Port]] ]
Table 94 lists the command-specific options for mkb. For a list of common command
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
Appendix A
245
Table 94
mkb options (part 2 of 2)
Option
Description
-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
Use the options described in Table 95 to add new files to the Knowledge Base that
you specified with the -f option. The new files are also described in Table 95.
Table 95
mkb new file options
mkb Option
Description
-a Arch
specifies the platform architecture:

s
s
s
s
s
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
246
adds the rule file (RuleFile) to the designated Knowledge Base
Each of the above options causes mkb to copy the designated files into the proper
Knowledge Base directory and adds information to the .load file of that directory.
mkb examples
This section contains UNIX and Microsoft Windows examples.
UNIX example
Figure 88 shows an example of mkb on UNIX.
Figure 88
mkb command on UNIX
mkb -f ./manifest.kb -p
This command produces output similar to the example shown in Figure 89 on a

UNIX computer named spud.
Figure 89
mkb output on UNIX
classes = \mcell\server\etc\spud\kb\.\classes
load file: .load
root.baroc
intevt.baroc
.
.
.
patrol.baroc
collectors = \mcell\server\etc\spud\kb\.\collectors
load file: .load
collectors.mrl
internal.mrl
Adapters.mrl
catchall.mrl
data = \mcell\server\etc\spud\kb\.\data
load file: .load
lib = \mcell\server\etc\spud\kb\.\lib
load file: .load
can not open file: \mcell\server\etc\spud\kb\.\lib\.load
rules = \mcell\server\etc\spud\kb\.\rules
load file: .load
new.mrl
records = \mcell\server\etc\spud\kb\.\records
load file: .load
intrec.wic
Appendix A
247
mkillStopping a cell
Microsoft Windows example

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

Microsoft Windows.
Figure 91
mkb command output on Microsoft Windows
manifest directory tree created successfully
mkb return codes

There are no command-specific return codes for mkb. For a list of common return
mkillStopping a cell
Use the mkill command to stop a running cell or gateway.
mkill syntax
Figure 92 shows the syntax for mkill.
Figure 92
mkill syntax
mkill [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value}

[-n cellName | -n @Host[/Port[#Key]]]
[-l HomeLocation][-v] [-s] [-i UserID[/Password][@Host[/Port]]]
If you do not specify a cell to stop, this command stops the default cell, Host.
You must use the -n cellName option on multiple cell hosts.
248
mlogchkPerforming consistency checks
Table 96 lists the command-specific option for mkill. For a list of common command
Table 96
mkill option
Option
Description
-s
performs rapid shutdown termination; bypasses StateBuilder
mkill example
Figure 93 shows an example of mkill.
Figure 93
Example of mkill
mkill -n examplecell
The preceding command produces output similar to the example shown in Figure 94.
Figure 94
Output of mkill
server examplecell terminated
NOTE
The mkill -s command terminates a cell and bypasses the StateBuilder. If a user has cells set
to run the StateBuilder before terminating, then mkill -s -n cellName overrides the
StateBuilder option.
mkill return codes

There are no command-specific return codes for mkill. For a list of common return

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

s
determines whether an mcdb.lock file exists and, if so

checks for a running statbld and waits for termination
reports trailing lock file and removes it (after confirmation)
determines whether an xact.1 file exists and, if so, reports and instructs the user to
run statbld
determines whether an mcdb.0 file exists and, if so, reports and proposes to rename
or remove it
mlogchk syntax
Figure 95 shows the syntax for mlogchk.
Figure 95
mlogchk syntax
mlogchk [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value}

[-n cellName | -n @Host[/Port[#Key]]]
[-l HomeLocation] [-v] [-i UserID[/Password][@Host[/Port]]]
There are no command-specific options for mlogchk.
mlogchk example
Figure 96 shows an example of mlogchk.
Figure 96
Example of mlogchk
mlogchk -n spud -v
For a cell named spud, the preceding command produces output similar to the
example shown in Figure 97.
Figure 97
Output of mlogchk
Warning: Cell spud is running - this may influence the consistency check.
To ensure correct results, you should shutdown the Cell now.
Do you want to continue (y/n) ?
The output continues with the message shown in Figure 98 on page 251 if you
respond with y.
250
mposter and msendManaging data and events
Figure 98
mlogchk message
No inconsistency found.
mlogchk return codes

Table 97 lists the command-specific return codes for mlogchk. For a list of common
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.
Use the msend command to manage events in a cell. Use the mposter command to
manage data and events in a cell. You can create, modify, and delete data instances
and events using the mposter command.
BMC Software recommends that you use the msend command instead of the mposter
command when you do not need to access or modify dynamic data or global records.
The msend command is a more secure command because it is more restrictive than
mposter.
WARNING
BMC Impact Solutions does not support using the mposter command to create or to edit
service model component instances.Although it is possible to use the mposter command to
create and to edit the service model class instances on a cell, these changes are made to only
the BAROC service model running on the cell, not to the cells standard (reference) published
service model in the CMDB. This causes a loss of service model integrity and subsequent
service model publishings will fail.
You can use the mposter command to modify dynamic data objects in the cell even
when the cell is paused.
Appendix A
251
mposter and msend syntax

Figure 99 shows the syntax for mposter.
Figure 99
mposter syntax
mposter [-h|?] [-z] [-q] [-c ConfigFile] {-p Var=Value}

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

BufDira
sets the directory to be used for persisting events that are

buffered until they are sent
Table 98
mposter and msend options (part 2 of 2)
Option
Description
-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
It is possible for msend and mposter to use a different file other than /etc/itm/.reg/Buffers for
the persistent buffer location. In the $MCELL_HOME/etc directory, create msend.conf and
mposter.conf files that contain a MpServerRegisterFile parameter. The value for this
parameter is the name of the file that will contain the location of the persistent buffer
directory. For example:
MpServerRegisterFile=/opt/mcell/buffers
NOTE
To send a punctuation mark as part of a text field using msend or mposter, enclose the value
within a set of single quotation marks ( ) framed by a set of double quotation marks( ).
For example, if you were sending a semicolon (;) as part of a text field it would look like this:
msend -n CellName -m "'a;b'"
Appendix A
253
mposter examples
NOTE
All examples and information in this section also can apply to msend.
Figure 101 shows an example of mposter.

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

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

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

Message 2 - evtid = 24233
In the example shown in Figure 102, mposter adds an instance of the DATA class
AppByHost to the host aspen. The example uses dynamic data technology in the
following ways:
s
s
s
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.
254
Figure 102 Definition changes using mposter

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

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

To successfully start the mposter or msend CLI commands in a persistent buffering
mode, you must ensure that you have write access to the buffers file. You can locate
the buffers file at:
s
s
UNIX/etc/itm/.reg/Buffers
Microsoft WindowsHKEY_LOCAL_MACHINE/SOFTWARE/BMC
Software/BMCImpact/mposter/Buffers
The Microsoft Windows registry key for the Buffers file is not created by default; it is
created the first time the mposter (or msend) command is executed using the -j
option.
Appendix A
255
If the Buffers file is not writable, you will receive the error message shown in
Figure 104 Error message if buffers files are not writable
Launching mposter server... OK
Getting Server Port number... OK (33992)
Connecting mposter server... Fatal error! Cannot negotiate connection
with mposter server. Check if the cell(s) name, location, port and
encryption key are the same as those running server (protocol error:
4)
Fatal error! Client initialization failed. A current cause of this
problem is a wrong/unavailable cell destination (hostname, port,
encryption key).
Decreasing the buffer size

The persistent directory may contain the following files:
s
s
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:
s
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
256
mqueryRetrieving objects from a cell
Table 99
mposter and msend return codes
Code
Description
failed to initialize in Server mode
failed to find a valid cell
failed to close the client connection

The mquery command retrieves objects from a cell.
mquery syntax
Figure 105 shows the syntax for mquery.
Figure 105 mquery syntax
mquery [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value}
[ -i UserID[/Password][@Host[/Port]] ] [-n cellName |
-n @Host[/Port[#Key]]] [-l HomeLocation] [-v] [-r] [-f Format] ( [-d]
[-a Class] [-w Where] [-s SlotList | -x SlotList] [-g Collector] [-o OrderSlot] |
-Q Query | - | {File} )
Table 100 lists the command-specific options for mquery. For a list of common
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.
Appendix A
257
Table 100 mquery options (part 2 of 2)

Option
Description
-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
mquery output
Output of the mquery command is available in raw format for parsing by a program,
and in printed format for users, with several variations.
Raw output format

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

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

M is the total number of solutions.
The last solution is followed by a line of the form as shown in Figure 108.
Figure 108 End of form
-----END-----
Special quoted format

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

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

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

In the Comma Separated Value (CSV) variant of the standard format, solutions are
printed in multiple columns over several rows. In non-verbose mode, each solution is
printed on one row. Slot values are placed in columns in the same order as in the
column selection. If ALL slots are requested, the order is determined by the cell and
depends on the class definitions.
In verbose mode, solutions can be on multiple rows. For an explicitly specified
selection of columns, the first row contains those column names. If you request ALL
slots, every solution row is preceded by a row containing the slot names. This is
required, as the returned slots may vary depending on the class of the object.
Appendix A
259
Columns are separated with a comma (,). A value that contains a comma (,) or a quote
("), or a new line, is quoted with a quote ("). A quote (") within such a value is
doubled.
Query specification
You can specify a query either with command line options or with the -Q option
through standard input. Using -Q with standard input, you must specify the query in
MRL syntax. You can use the options described in Table 101 to specify the query with
CLI.
Table 101 mquery query options
Option
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
s
s
s
ALLgets all slots

COUNTgets no slots, only a count of matching objects is returned
DELETEall matching objects are deleted, returning a count of these
The default is ALL.

-x SlotList
excludes the slots listed in SlotList, a comma-separated sequence of slot names

All slots are reported except for these.
-g Collector retrieves only matching object instances that belong to one of the collectors specified in
Collector
This is a comma-separated sequence of collector object identifiers (OIDs), names, or both.
Each one can be suffixed optionally with a + to include its subcollectors as well.
-o OrderSlot sorts the slots mentioned in OrderSlot
This is a comma-separated sequence of slot names. Each one can be suffixed optionally with
a + to indicate ascending order or a - to indicate descending order. Without suffix, a + is
assumed. Ordering is done first on the first slot, then on the next one, and so on.
260
mquery examples
This section contains examples of the mquery command.
Selecting events with a severity level

Use the command shown in Figure 110 to select all MC_CELL_CONTROL events with
severity of at least MINOR, and non-closed status. This query returns the indicated
slots and the effective class name.
Figure 110 Example of mquerySelect events with severity status
mquery
-a MC_CELL_CONTROL
-w "severity: >= MINOR AND status: != CLOSED"
-s "mc_ueid,CLASS,severity,msg"
The command shown in Figure 111 on page 261 selects all events from the ByHost
collectors for hosts host1 and host2 including all of their subcollectors, if any. The
result is ordered on status in ascending order beginning with OPEN, and for each
equal status value, descending on severity beginning with DOWN.
Figure 111 Example of mquerySelect events from collector
mquery
-g "'By Host'.host1+,'By Host'.host2+"

-s "mc_ueid,CLASS,severity,hostname,msg"
-o "status,severity-"
NOTE
The current implementation of the mquery command has the following limitations:
s
The XML format is experimental and may change in future BMC Impact Solutions
product releases.
The list slot values in XML are printed as strings, not as XML lists.
Deleting events using the mquery command

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

Table 102 lists the command-specific return codes for mquery. For a list of common
Table 102 mquery return codes
Code
Description
21
syntax error in input

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

Table 104 lists the command-specific return codes for mrecover. For a list of common
Table 104 mrecover return codes
Code
Description
failed to send the command that started the StateBuilder on a remote cell
could not obtain information from one or more neighbor cells
could not launch an external program (mrmerge or mcell)
mrmerge exited abnormally
mcell (in recovery mode) exited abnormally
Appendix A
263
mrextractExtracting cell state files to create new state files
mrextractExtracting cell state files to create new state files

Events are extracted from the remote cell repository for the local cell being recovered.
The mrextract command is one step in the recovery process. For more information,
see mrecoverRecovering from a catastrophic data loss on page 262.
WARNING
This command is used by mrecover and should be avoided by end users.
The cell must be stopped before using the mrextract command.
mrextract syntax
Figure 115 shows the syntax for mrextract.
Figure 115 mrextract syntax
mrextract [-c ConfigFile] [-h|-?] [-l HomeLocation]
[-n cellName | -n @Host[/Port[#Key]]] [-o OutputFile] {-p Var=Value}
[-q] [-s InputStateFile] [-z] {TargetCell} . . .
Table 105 lists the command-specific options for mrextract. For a list of common
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

cells mcdb
TargetCell
specifies the name of the cell to which events have been

propagated; separate multiple cell names with a space
mrextract example
Figure 116 shows an example of mrextract.
Figure 116 Example of mrextract
mrextract -n CellTwo -o \tmp\mcdb.CellOne
264
mrmergeMerging event objects
mrextract return codes

Table 106 lists the command-specific return codes for mrextract. For a list of common
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

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

Table 108 lists the command-specific return codes for mrmerge. For a list of common
Table 108 mrmerge return codes
Code
37
failed to enable tracing
47
cannot access StateBuilder
67
failure loading kb classes
97
266
Description
cannot start while StateBuilder is active
msetmsgModifying an event
msetmsgModifying an event
Use the msetmsg command to modify the status value of an event in a specified cell.
Use the -s option to modify the slot value.
msetmsg syntax
Figure 119 shows the syntax for msetmsg.
Figure 119 msetmsg syntax
msetmsg [-h|-?] [-z] [-q] [-c ConfigFile]
{-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]]
[ -i UserID[/Password][@Host[/Port]] ] -u EventId -C -O -B -A -G
-S "Slot=Value[{;Slot=Value}]"
Table 109 lists the command-specific options for msetmsg. For a list of common
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

ASSIGNED
-B

BLACKOUT
-S "Slot=Value[{;Slot=Value}]" specified the slot to be modified and the changes

to be made to the slots value
msetmsg example
To close an event whose event ID (event_handle) is 12981, type the following
command:
msetmsg -n cellName -u 12981 -C
If this command is successful, it does not produce output.
Appendix A
267
msetrecSetting the value of a global record
msetmsg return codes

Table 110 lists the command-specific return codes for msetmsg. For a list of common
Table 110
msetmsg return codes
Code
Description
31
no event handle specified
32
failed to set message
msetrecSetting the value of a global record

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

Table 112 lists the command-specific return codes for msetrec. For a list of common
Table 112
msetrec return codes
Code
Description
31
failed to set record slot

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

Number
String
Path
Appendix A
269
Table 113 describes the CLI configuration parameters.

Table 113
BMC Impact Manager CLI configuration parameters (part 1 of 3)

Default
value
Option
Description
AuthenticationServerAddress
If no value
specifies the host name or IP address of an
authentication server, optionally followed by a port is entered,
the default
number, using the following syntax:
IAS port
number on
Host[/Port]
the local
host is
used.
ServerName
specifies the name of the cell; an alternative for the Host

-n cellName option
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

1828
listens for all in-bound requests from sources, such
as the BMC Impact Explorer, CLIs, and adapters
Encryption
enables or disables encryption to and from the cell
EncryptionKey
used by encryption process as part of the encoding no default

key
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.
270
Yes
10
(seconds)
Table 113

Default
value
Option
Description
ConnectionPortRange
specifies the range of ports to use for outgoing

connections
empty
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.
ConnectionPortReuse
indicates whether or not the ports specified in

ConnectionPortRange should be reused as
much as possible
Yes
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.
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
MessageBufferCleanupPercentage
2000
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.
3600
Once the specified time elapses, the retained

messages are removed from the buffer.
Appendix A
271
Configuring tracing for BMC Impact Manager CLI commands
Table 113

Default
value
Option
Description
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
Configuring tracing for BMC Impact Manager CLI commands

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

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

ALL ALL out.txt
This line produces tracing to the MCELL_HOME\tmp\mclient\out.txt file.
272
Appendix

This appendix discusses all of the parameters in the mcell.conf file and contains the
following topics:
Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event cleanup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Builder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B
274
274
276
278
280
281
283
284
287
287
288
291
292
292
293
273
Action result event parameters

Table 114
Parameter
Description
Type
Default value
ActionResultInlineLimit
the size limit, in bytes, for an action result to be number 4096 (4 KB)
included directly in the action result event slots
This applies to both the output stream (slot
"output_val") and the error stream (slot
"error_val"). If the respective result is larger
than the indicated size, it is stored in a file.
Instead of placing the value directly in the *_val
slot, the reference to the file is placed in the
corresponding *_ref slot.
ActionResultKeepPeriod
the period, in seconds, that an action result is

kept on behalf of a (Browser) client
number 120 (2 minutes)
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.
Cell configuration parameters

Table 115
Cell configuration parameters (part 1 of 3)
Parameter
Description
Type
Default value
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
string
Consolidation
Boolean
No
The operation level determines from which clients the

cell accepts connections and events. The default value
can accept connections from any computer.
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.
274
Cell configuration parameters
Table 115
Parameter
Description
Type
Default value
ConnectionPortRangea
specifies the range of ports to use for outgoing

connections
string
empty
Boolean
Yes
number
100
Boolean
Yes
path
mcell.dir
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.
ConnectionPortReusea indicates whether or not the ports specified in
ConnectionPortRange should be reused as much as
possible
By default, the cell or command line interface (CLI)
tries to reuse ports from the specified range, in the
given order. When ConnectionPortReuse=No, for
every new connection within the same session, the
next free port from the specified range is used. Only
when it reaches the end of the range will it restart at
the beginning of the range.
ProcessingLimit
Percentage
specifies limitation of event processing speed

At 100% the cell accepts events as fast as it can. At x%
it does not accept events during (100-x)% of the time.
This limits the cells CPU utilization.
ServerAllInterfaces
determines whether the cell listens on one specific

interface or on all available interfaces
When ServerAllInterfaces=Yes, the cell
communicates on all network interfaces on the host.
When ServerAllInterfaces=No, the cell only
communicates with the network interface that has the
IP address specified in the mcell.dir file of that cell.
ServerDirectoryNamea specifies the name of the cell directory file

ServerPorta
specifies the TCP/IP port number at which the cell

number
listens for all in-bound requests from sources, such as
the BMC Impact Explorer console, CLIs, and adapters
Appendix B
1828
275
Cell failover configuration parameters
Table 115
Parameter
Description
Type
Default value
ServiceModelEnabled
specifies whether the cell is an Event Management cell Boolean

or a Service Impact Model cell.
Yes
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.
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
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
Type
Default
value
CellDuplicateAutoFailOver
determines whether the primary server

automatically fails over to the secondary
server.
Boolean
Yes
Boolean
Yes
For automatic failover to occur, this parameter

must be set to YES on both servers.
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.
276
Table 116
Cell failover configuration parameters (part 2 of 2)
Parameter
Description
Type
Default
value
CellDuplicateFailOverStart
TimeOut
specifies the length of time (in seconds) that

the secondary server waits to become active
after it is started.
number
120
number
40
When the secondary server starts, it expects

the primary to connect to it. If the primary
server does not connect to the secondary
within the time specified by the
CellDuplicateFailOverStartTimeOut
parameter, the secondary server will become
active.
The time specified for CellDuplicate
FailOverStartTimeOut should be longer
than the time specified for
CellDuplicateFailOverTimeOut to allow
operators to start up primary and secondary
servers at almost the same time, in any order.
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.
CellDuplicateHeartbeatEnabled
Boolean
can be used to disable the heartbeat of a high
availability cell, to prevent the secondary cell
server from becoming active when the primary
cell server is active due to VMware clock
discrepancies
CellDuplicateMode
specifies the operation mode of the server.
number
Yes
1 = primary server
2 = secondary server
0 = the server is operating as a non-high
availability cell.
This is the only parameter that needs a
different value between primary and
secondary.
Appendix B
277
Client communication parameters

Table 117
Parameter
Description
Type
Default value
ClientCleanupInterval
the interval, in seconds, between clean-ups of

pending clients
number
300
After each such period, clients that did not give

the cell a notice of life are disconnected.
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
number
1000 milliseconds
DateFormat
the format used to display timestamps in the

date slot
string
CIM
number
5000 milliseconds
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.
SynchronizeTimeOut
the maximum time, in milliseconds, the cell

waits for synchronization before dropping a
connection
If the cell receives an event with an empty value for the date slot, it sets the date slot
to the textually formatted value of the date_reception slot. That value is
determined by the DateFormat parameter. This assignment is performed only once,
when the event first enters the cell. If the cell is shut down and restarted, the value of
date remains the same even if the DateFormat parameter has been modified in the
interval.
The CIM format is yyyymmddhhmmss.mmmmmmsutc, where:
yyyy = year
mm = month
dd = day
hh = hour, based on 24-hour clock
mm = minutes
ss = seconds
mmmmmm = microseconds
s = + or -
278
utc = offset in minutes from UTC; UTC is the Universal Time Coordinate system
Table 118 lists the parameters from the Solaris platform. Other platforms, including
UNIX and Microsoft Windows platforms, may have slight differences.
Table 118
Date and time format parameters for Solaris (part 1 of 2)
Parameter
Description
%%
same as %
%a
locales abbreviated weekday name
%A
locales full weekday name
%b
locales abbreviated month name
%B
locales full month name
%c
locales appropriate date and time representation
%C
locales 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
locales 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
locales 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
locales appropriate date representation
Appendix B
279
Encryption parameters
Table 118
Date and time format parameters for Solaris (part 2 of 2)
Parameter
Description
%X
locales 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 lists the encryption parameters.
Table 119
Parameter
Description
Type
AllowAdapterFrom
specifies the adapters within the range of IP addresses string
Default value
0./0
These are adapters that use the BMC Impact Solutions

communications protocol.
AllowBrowserFrom
specifies the BMC Impact Explorer and the BMC

Impact Portal connections within the range of IP
addresses
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 string

is allowed to connect to a cell
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
ForceEncryption
specifies if encryption is to be forced
Boolean No
280
(empty)
Event repository cleanup parameters

Table 120 Event Repository cleanup parameters (part 1 of 3)
Parameter
Description
Type
EventAutoClose
automatically closes a duplicate event Boolean

in the database when an event arrives
with status=CLOSED, or it is closed in
the Refine rule phase
Default value
Yes
If the default value is left as Yes, the

event is dropped and the duplicate is
closed. If the value is set to No, there is
no duplicate detection and the CLOSED
event is not dropped.
EventDBCleanupDurationLimit
the maximum duration, in seconds, of a number

single cleanup
30
After expiration of that period, the

cleanup is interrupted. Normal
operation proceeds for an equal
duration. Then cleanup is resumed,
with the same limit again.
EventDBCleanupInterval
the time interval, in seconds, between

periodic cleanups of the repository
EventDBCleanupPercentage
the percentage of free space required at number

termination of an EventDB cleanup
number
3600, or 1
hour
minimum = 60;
no maximum
10
minimum=5;
no maximum
With a default EventDBSize of

100000, this means that at least 10000
places must be available at termination
of a completed cleanup.
EventDBCleanupOnDateReception indicates the preference for deleting
events from the repository based on
when they were received instead of
when they were last modified
Appendix B
Boolean
No
281

Parameter
Description
Type
EventDBCleanupPreferClosed
indicates the preference for cleaning up Boolean

closed events rather than older events
Default value
No
When there is not enough free space

after removing all expired events,
additional, unexpired events are
removed. These are selected, oldest
first, either from any events or from the
closed ones first.
The default is no, meaning that the
event status value is not taken into
account when selecting events for
removal.
EventDBKeepClosed
the minimum age, in seconds, of

CLOSED events before they are
removed from the repository
number
604800, or 7
days;
no minimum;
no maximum
number
2592000, or
30 days
minimum
value=0;
maximum
value =
4294967295, or
136 years
Note: Any modifications to the

EventDBKeepClosed parameter
should be carefully considered. Events
of these classes remain in the event
repository until you manually delete
them.
EventDBKeepNonClosed
282
the minimum age, in seconds, of nonclosed events before they are removed
from the repository
Event cleanup process

Parameter
Description
Type
Default value
EventDBSize
the number of events to retain in the

repository (the mcdb and xact files
located in the
MCELL_HOME/log/cellName
directory path
number
100000
minimum
value=100;
no maximum
The default size is 100000.

When the specified number is reached,
the StateBuilder (STATBLD) process
runs a cleanup procedure, which is
described in Event cleanup process
on page 283.
The value of the EventDBSize may have
an impact on memory consumption.
When increasing the value of the
EventDBSize, consider the size of your
systems virtual memory and the
number of programs running on the
system. Contact your system
administrator if in doubt.
EventDBNoCleanupClosed
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
Event cleanup process

The related group of event cleanup parameters gives you control over which events
are removed, limits the duration of the cleanup, and specifies a preference for
cleaning up closed events rather than older events.
A cleanup first removes expired events. Expired events are those that are older than
the times in the EventDBKeepClosed and EventDBKeepNonClosed parameters, for
closed and non-closed events, respectively. After this cleanup, if there is still less free
space than specified in the EventDBCleanupPercentage parameter, additional,
unexpired events are removed. As many events are removed as needed to reach the
desired amount of free space.
Older events are removed first, with one possible exception. If parameter
EventDBCleanupPreferClosed=Yes, closed events are removed first, even if some
older unclosed events remain. In EventDBCleanupPreferClosed=No mode, all
events are considered, starting with the oldest first.
Appendix B
283
Heartbeat parameters
The mc_date_modification slot is considered to determine the time of an event.

However, if parameter EventDBCleanupOnDateReception=Yes, the
date_reception slot is considered instead.
Cleanup is interrupted if it takes longer than the value of the
EventDBCleanupDurationLimit parameter. By default, this value is 30 seconds. If
the cleanup period was not long enough to remove all expired events, a new cleanup
is scheduled for a later time with the same amount of time as the duration limit. If all
expired events were removed, the next cleanup is scheduled after the normal interval
value of EventDBCleanupInterval.
Table 121 Heartbeat parameters
Parameter
Description
Type
Default value
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
number
HeartbeatMissedMinor
the default number of consecutive missed beats

that are needed to generate a minor event, if not
number
HeartbeatMissedWarning
the default number of consecutive missed beats

number
that are needed to generate a warning event, if not
The heartbeat feature allows a specific cell, called the monitoring cell, to monitor one
or more cells, called the monitored cell or cells, for enabled access by the monitoring
cell.
The parameter in the mcell.conf file of the monitored cell should be
HeartbeatEnabled=Yes. By default, the monitored cell sends a beat every 300
seconds.
Heartbeats are configured through MC_CELL_HEARTBEAT dynamic data objects in the
monitoring cell. An MC_CELL_HEARTBEAT dynamic data object contains information,
such as the name of the cell to be monitored, the length of the expected time intervals
between the heartbeats, and the number of heartbeats that must be missed to generate
corresponding internal events in the monitoring cell.
284
The cell receives the dynamic data object either by loading it from the data directory,
receiving it through an mposter call, or viewing it in the Administrative View of the
BMC Impact Explorer. The monitoring cell sends a request to the monitored cell. The
monitored cell sends a heartbeat back to the monitoring cell at the specified intervals.
If the monitoring cell does not receive a heartbeat in the expected timeframe, the
monitoring cell generates an alert that can be viewed in the BMC Impact Explorer
console.
The default settings for missing heartbeats are as follows:
s
s
s
1 missed heartbeat generate a warning event

2 missed heartbeats generate a minor event
3 missed heartbeats generate a critical event
For example, in Figure 123 on page 285, cell 1 is the monitoring cell, which sends a
request to cell 2, the monitored cell. If it does not receive a response at a specified
interval, then the monitoring cell sends an alert that can be seen in the BMC Impact
Explorer.
Figure 123 Example of Heartbeat
Request
cell 2
cell 1
Heartbeat
After a monitoring cell terminates and restarts, it is aware of prior requests for
heartbeats because it rereads the dynamic data objects that are stored in the cell
repository mcdb. After it rereads the data, the monitoring cell attempts to resend the
request to the monitored cell.
Appendix B
285
If the monitored cell terminates, the monitoring cell resends the request for heartbeats
at the specified intervals. Table 122 lists the MC_CELL_HEARTBEAT slots.
Table 122 Heartbeat slots
Slot
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

HeartbeatMissedMinor configuration parameter. Specify -1 to disable generation
of the corresponding event.
missed_critical number of missed heartbeats before a CRITICAL event is generated

HeartbeatMissedCritical configuration parameter. Specify -1 to disable
generation of the corresponding event.
missed
number of consecutive missed heartbeats
NOTE
Deleting an instance of an MC_CELL_HEARTBEAT data object from a monitoring cell
terminates the monitoring of the corresponding cell or cells.
286
Internal cell monitor parameters
Internal cell monitor parameters

Table 123 Internal cell monitors parameters
Parameter
Description
Type
Default value
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
number
600
a flag that requires the cell to check for certain conditions Boolean
that can induce infinite looping of events
No
the time interval, in seconds, between generation of cell

heartbeat events (ticks)
The purpose of such heartbeats is to send a sign of life
from the cell. A zero (0) value disables cell ticks without
disabling other internal events. This parameter operates
only if the CellEventEnable is set to Yes.
RuleLoopDetect
Setting this parameter to Yes can cause mild cell

performance degradation.
KB parameters
Table 124 KB parameters
Parameter
Description
Type
Default value
KBDirName
the path to the active KB directory
path
the KB directory in the

cells cell-specific
configuration directory
KBRecoveryDirName
the path to an alternate KB directory to be used path

for recovery from catastrophic damage
kbrecovery
For more information, see mrecover

Recovering from a catastrophic data loss on
page 262.
Appendix B
287
Propagation parameters
The propagation parameters allow you to configure propagation and destination
buffers.
You can configure these parameters for individual destinations and also configure a
default value for all other destinations. Use the asterisk (*) to specify all destinations.
The following parameter definition illustrates how to configure these parameters for
all destinations.
DestinationBufferReconnectInterval = *=600
This example specifies that the interval to try to reconnect is 600 seconds for all
destinations. If the * is not explicitly defined, the default value for the parameter will
be applied to all destinations.
To configure parameters for individual destinations, the value for these parameters is
formatted as a comma-separated sequence of destination-specific settings in the form
of DestinationName=Value. DestinationNames #1 and #2 are reserved to indicate
the primary and secondary nodes of a high availability cell.
For example,
DestinationBufferReconnectInterval = #1=10,#2=10,*=600,SlowCell=1200
This example specifies that the interval to try to reconnect is 10 seconds for the high
availability nodes, 1200 seconds for a cell called SlowCell and 600 seconds for all
other destinations. If the * is not explicitly defined, the default value for the parameter
will be applied to all unspecified destinations.
Table 125 Propagation parameters (part 1 of 3)
Default
value
Parameter
Description
Type
DestinationBufferBaseSize
the initial number of messages, or

events, retained in the buffer
number 5000
DestinationBufferExpandPercentage percentage of the actual buffer size that number 10

the buffer expands when events
continue to be propagated after the
buffer is full
288

Default
value
Parameter
Description
Type
DestinationBufferSizeLimit
maximum allowed buffer size
number 0
The default value of 0 means the buffer

size is unlimited. In practice, the size is
limited to 2^32-1, or to the available
amount of memory.
If the limit is set to a value lower than
DestinationBufferBaseSize, the
buffer will not expand beyond
DestinationBufferBaseSize.
DestinationBufferReducePercentage minimum percentage of free buffer size number 50
required to perform a reduction
DestinationBufferKeepSenta
the time, in seconds, to keep sent events number 300

DestinationBufferKeepWait
The amount of time, in seconds, that

events are retained in the buffer until
they can be sent.
number 3600, or 1
hour
Once the specified time elapses, the

retained events are removed from the
buffer.
DestinationBufferReconnectInterval
the time interval, in seconds, in which

the cell attempts reconnection to a
destination if the original connection
failed
number 600
The cell continues to reestablish a

connection as long as there are events
in the buffer.
DestinationBufferResendCount
the number of times to resend

unanswered events
PropagateBufferBaseSize
the number of requests for propagation number 20000

to retain in the propagation buffer
number 1
Such a request corresponds to firing a

Propagate rule. There is one propagate
buffer per cell with as many places for
requests as set by the parameter.
PropagateBufferExpandPercentage
percentage of the actual buffer size that number 10

the buffer expands when events
continue to be propagated after the
buffer is full
Appendix B
289
Deprecated MessageBuffer propagation parameters

Default
value
Parameter
Description
Type
PropagateBufferSizeLimit
maximum allowed buffer size
number 0
The default value of 0 means the buffer

size is unlimited. In practice, the size is
limited to 2^32-1, or to the available
amount of memory.
If the limit is set to a value lower than
PropagateBufferBaseSize, the
buffer will not expand beyond
PropagateBufferBaseSize.
PropagateBufferReducePercentage
minimum percentage of free buffer size number 50

required to perform a reduction
PropagateConfigFileName
the name of the propagation

configuration file
path
mcell.
propagate
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.
Deprecated MessageBuffer propagation parameters

The MessageBuffer propagation parameters described in this section have been
deprecated, but are retained for backward compatibility with earlier versions of BMC
Impact Manager. These parameters may be removed in a later version of the product.
If one of the DestinationBuffer parameters is not specified, or if it does not contain
a default setting, the value of the corresponding MessageBuffer parameter is used as
default. If the corresponding MessageBuffer parameter is not specified, an internal
default value is used.
Table 126 Deprecated MessageBuffer propagation parameters (part 1 of 2)
Default
value
Parameter
Description
Type
MessageBufferBaseSize
the initial number of messages, or events,

retained in the buffer
number 5000
MessageBufferKeepSenta
the time, in seconds, to keep sent messages

number 300
MessageBufferKeepWait
The amount of time, in seconds, that messages number 3600, or 1

hour
are retained in the buffer until they can be sent.
Once the specified time elapses, the retained
messages are removed from the buffer.
290
Reporting client connection parameters
Table 126 Deprecated MessageBuffer propagation parameters (part 2 of 2)

Default
value
Parameter
Description
Type
MessageBufferReconnectInterval
the time interval, in seconds, in which the cell

attempts reconnection to a destination if the
original connection failed
number 600
The cell continues to reestablish a connection

as long as there are messages in the buffer.
MessageBufferResendCount
the number of times to resend unanswered

messages
MessageBufferSize
the number of messages, or events, retained in number 20000

the buffer when the cell is unable to send, or
when waiting for an answer; a message that is
not sent because the destination is down, for
example, or a message that was sent but not
yet answered, remains in the buffer
number 1
A cell maintains one buffer for each

destination. Such buffers have the same size,
as set by the parameter.
PropagateBufferSize
the number of requests for propagation to

retain in the propagation buffer
number 20000
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.
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.
Reporting client connection parameters

Table 127 lists the parameters that report on client operations on the cell.
Table 127 Reporting client connection parameters
Parameter
Description
Type
Default value
ReportConnectClients reports connect and disconnect of string

clients
browser, Console,
ImpactExplorer, mcontrol,
mkill, mposter, msetmsg,
msetrec
ReportModifyClients
mposter, msetmsg, msetrec
reports modifications of events by string

clients
Appendix B
291
Service model parameters

Table 128 lists the parameters that control the service model.
Table 128
Parameter
Description
Type
Default value
ServiceModelPublish
controls whether or not Service Model Data is

published
Boolean
YES
Boolean
when ServiceModelPublish is enabled,
ServiceModelDirectFeed controls whether or
not Service Model Data is accepted through direct
feed
YES
Note: If ServiceModelPublish is disabled, the

ServiceModelDirectFeed parameter has no
impact. In this case, Service Model Data is always
accepted through direct feed.
ServiceModelDirectFeed
State Builder parameters

The running of the State Builder is controlled by the cell, using the parameters in the
mcell.conf file. Table 129 lists the StateBuilder parameters.
Table 129 State Builder parameters
Parameter
Description
Type
Default value
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 number

file before it is transformed into a new saved
state when the StateBuilder runs again.
1000
If BMC Impact Manager seems to be

consuming too much CPU, verify that State
Builder is not running too frequently. Compare
the time stamps of the mcdb.* files in the log
directory of the cell. If the time between two
state builds is less than 10 minutes, increase the
StateBuildSize parameter.
StateBuildConfigFileName the StateBuilder configuration file name
path
statbld.conf
StateBuildAtTerminate
indication to run the StateBuilder when the cell Boolean

terminates
No
StateBuildRunTimeOut
the timeout, in seconds, to consider when

waiting for the StateBuilder to terminate
600 seconds
292
number
Trace parameters
Trace parameters
Table 130 Cell tracing parameters (part 1 of 3)
Parameter
Description
Type
Default value
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
path
TraceDefaultFileName destination file to redirect trace messages from
stderr to, in case the cell runs as a daemon or service
%T/trace
Note: If you direct trace files to the temporary

directory of the cell (for example,
TraceDefaultFileName=%T/trace - %T=cell_tmp), the
trace file will be removed each time the cell starts
because the cell always cleans up its tmp directory at
startup.
To keep trace files across cell sessions, do not use the
tmp directory as the default destination file location.
TraceRuleLevel
sets the level of rule execution tracing:

s
s
s
TraceRulePhases
number
0no rule tracing and no cell error catch (not

recommended)
1no rule tracing; cell errors are caught in the
standard cell trace (default)
2rule tracing enabled
When rule tracing is enabled, lists the rule phases to be string

traced. The value ALL can be used to specify that all
phases are to be traced. Each phase can be prefixed
with a + or a - sign to indicate addition or removal
from the list. The list is interpreted in sequential order.
ALL
For example, the following parameter setting:

TraceRulePhases=ALL,-refine,-regulate
indicates that all rule phases will be traced except for
the refine and regulate phases.
NOTE: TraceRulePhases and TraceRuleName
work together to determine which rules are traced. A
rule is only traced if both the phase to which it belongs
and the rule itself are configured for tracing.
Appendix B
293
Trace parameters

Parameter
Description
Type
TraceRuleNames
string
When rule tracing is enabled, lists module:rule
combinations to be traced. The value ALL can be used
to specify that all modules and/or rules are to be
traced. Each module:rule combination can be prefixed
with a + or a - sign to indicate addition or removal
from the list. The list is interpreted in sequential order.
Default value
ALL:ALL
For example, the following parameter setting:

TraceRuleNames=HelpDesk:ALL,
-HelpDesk:rule1,SendMail:rule1
indicates that all rules in the HelpDesk module will
be traced except for rule1. Additionally, rule1 from
the SendMail module will be traced.
NOTE: TraceRulePhases and TraceRuleNames
work together to determine which rules are traced. A
rule is only traced if both the phase to which it belongs
and the rule itself are configured for tracing.
TraceRuleHeader
allows you to configure the header text of the trace

text
messages. You can configure the header text to contain
references to parameters, using the following
designations to represent the associated parameters:
s
s
s
s
s
s
s
s
%F, %L: %P
%R: %C
# %H:
%I message id
%F source file name
%L source line number
%M KB module name
%R rule name
%P rule phase
%H handle of the main event being processed
(event_handle slot)
%C class name of the main event being
processed
For example, the default parameter setting

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

mc_intevt.mrl, 42: new StbldStop:
MC_CELL_STATBLD_STOP #118: Rule execution
starting
TraceRuleToXact
294
indicates whether to include rule tracing in the

Boolean
transaction file, as well as in the standard cell trace, in
module RULES
No
Trace parameters

Parameter
Description
Type
TraceFileSize
Default value
limit on the size of a trace destination file, expressed in number

kilobytes
When the trace file grows beyond the indicated size, it
is renamed with a numerical suffix appended. A new
trace file is started.
Special value 0 (the default) means no limitation on
file size.
TraceFileHistory
number
number of trace files to be kept in history
Boolean
Yes
When this number is reached, a new numbered trace

file will remove the oldest one.
TraceFileAppend
a
indicates whether to append to existing trace files or

empty existing trace files at startup
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.
Appendix B
295
Trace parameters
296
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
.baroc files 68, 69
.jar files
digitally signing 194
.load files 68, 70
.loadwic files 70
.mrl files 69
.pkg files 69
.wic files 69, 70
.xact files 72
@kbversion annotation 73
A
action result event parameters
ActionResultInlineLimit 274
ActionResultKeepPeriod 274
actions
directory 69
activating maximum tracing for all modules 219
adding
slot flags and default values 224
slot names and representation types 224
administering remote cells
Administration View (BIX) 58
Administration View
managing cells from 58
metrics collection 165
Reload menu 163
administrator activities
modifying cell connection settings 132
AllowAdapterFrom 280
AllowBrowserFrom 280
AllowCellFrom 280
AllowCLIFrom 280
AllowConnectionFrom 280
AllowEIFFrom 280
application.properties configuration file 125
B
bin directory 68
BIX
defining presentation name search order using
ix.properties file 191
extracting presentation name resource files 189
BIX tool tips

enabling and disabling for presentation names 195
BMC Impact Administration server
command line interface 78
configuration files 78, 119
customizing BMC IX colors 99
default mapping of roles and permissions 83
defining client logging 98
defining group roles 88
defining high availability for Impact Administration
cell 105
defining permissions 83
defining primary and secondary servers 101
defining standalone servers 101
editing logging properties 98
high availability 101
iadmin command 78
iadmin command format 80
iadmin command options 79
iadmin reinit options 104
LDAP configuration 109
manual editing guidelines 82
Master server 102
relation to BMC Impact Portal 93
Standard server 102
supporting remote actions for infrastructure
management 107
synchronization properties 103
synchronizing with BMC Atrium CMDB 95
synchronizing with BMC Impact Portal 93
transaction and trace logs 106
updating cell information 96
updating user information (file-based authentication)
91
BMC Impact Explorer
configuration files, event group 185
defining presentation name search order using
ix.properties file 191
remote cell administration 58
BMC Impact Manager CLI
common options 211
configuration of 269
BMC Impact Portal
communication and encryption parameters 135
configuration parameters 124
configuring the ixs.properties file 124
Index
297
BMC Impact Portal (continued)
policy file 179
report goal line configuration parameters 134
BMC Portal
starting from command line 123
starting from Services Window 123
starting on UNIX 123
stopping from command line 123
stopping on UNIX 123
URL address 124
URL address syntax 124
BMC Software, contacting 2
C
cell
defining high availability for Impact Administration
105
Impact Administration 105
cell configuration
creating files for specific cells 30
files 4344
Cell Info dialog box (BIX) 165
cell names
conventions for 231
cell objects, retrieving 251, 267
cell parameters
CellDescription 274
CellOperationLevel 274
CellOperationRelax 274
ConnectionPortRange 275
ConnectionPortReuse 275
ProcessingLimitPercentage 275
ServerAllInterfaces 275
ServerDirectoryName 275
ServerPort 275
SystemLogDirName 276
SystemTmpDirName 276
cell tracing parameters, list of 293
CellDescription 274
CellErrorEvents 287
CellEventEnable 287
CellMetricsEnabled 287
CellOperationLevel 274
CellOperationRelax 274
cells
creating new 231, 264
deleting 237
extracting state files from 264
heartbeats 287
naming, mcrtcell command 231
obtaining status using mcstat 236
posting events 251
production, described 25
reconfiguring 43, 231
298
cells (continued)
recovering data 262
remote administration 58
retrieving information 238
running in foreground 217
sending events to 251, 267
starting 217
starting a specified cell 216
starting and stopping 72
status 235
stopping with mkill 248
test, described 25
view information 58
CellTickInterval 287
class information request 220
classes
directory 68
CLI, BMC Impact Manager. See BMC Impact Manager CLI
client configuration for passive connections 36
client parameters 287
ClientCleanupInterval 278
ClientPollTimeOut 278
ClientSendTimeOut 278
DateFormat 278
SynchronizedTimeOut 278
ClientCleanupInterval 278
ClientPollTimeOut 278
ClientSendTimeOut 278
closing an event 267
collectors 225
directory 68, 69
com.bmc.sms.iwc.component.properties.
generalProperties.properties file property 133
com.bmc.sms.iwc.domain.notification.impact.type
property 133
com.bmc.sms.iwc.domain.recentitem.
RecentItemsFolderIcon property 133
com.bmc.sms.iwc.event.table property 133
com.bmc.sms.iwc.event.table.maximumevents property
134
com.bmc.sms.iwc.event.table.minimumevents property
134
com.bmc.sms.iwc.status. 134
com.bmc.sms.iwc.status.table property 133
com.bmc.sms.iwc.status.table. existinggroup property 134
com.bmc.sms.iwc.status.table.causes property 134
com.bmc.sms.iwc.status.table.consumers property 134
com.bmc.sms.iwc.status.table.providers property 134
com.bmc.sms.iwc.ui.recentitems.maxsize property 133
command options
mkill 248
mrmerge 265
commands
mccomp 71, 214
mcell 216
mcfgtrace 217, 218
mclassinfo 220
commands (continued)
mcollinfo 225
mcontrol 72, 228
mcrtcell 71, 231
mcstat 235
mdelcell 237
mgetinfo 74, 238
mgetrec 243
mkb 71, 245
mkill 248
mlogchk 249
mposter 251, 255
mquery 251, 267
mrecover 262
mrextract 264
mrmerge 265
msend 251, 267
msetmsg 267
msetrec 268
reference 210
communication and encryption
AllowAdapterFrom 280
AllowBrowserFrom 280
AllowCellFrom 280
AllowCLIFrom 280
AllowConnectionFrom 280
AllowEIFFrom 280
BMC Impact Portal configuration parameters 135
encryption behavior 40
ForceEncryption 39
mcell.conf settings 39
mcell.dir settings 39
mclient.conf settings 39
compiling
Knowledge Base 214
Knowledge Bases 71
Knowledge Bases with trace 72
version annotations 73
configuration activities for administrators
configuration files
cell 4344
cell-specific, creating 30
ix.properties 183
ixs.properties 124
mcell.conf 28, 31
mcell.modify 3738
mcell.propagate 31
mcell.trace 51
StateBuilder configuration 199
configuration parameters
BMC Impact Portal configuration and encryption 135
HeartbeatEnabled 284
HeartbeatInterval 284
HeartbeatMissedCritical 284
HeartbeatMissedMinor 284
HeartbeatMissedWarning 284
configuring
BIX using the ix.properties file 183
BMC Impact Portal using ixs.properties 124
clients for passive connections 36
error tracing for BMC Impact Manager 217, 218
reloading cell configuration 43
setting cell-specific configurations up 30
StateBuilder 199
connecting
cells in a protected zone 36
ConnectionPortRange 271, 275
ConnectionPortReuse 271, 275
consistency checks 249
console_policy.prop 179
control operations 228
conventions
for cell naming 231
creating
a new cell 231
a new service with mcrtcell 234
another service 234
configuration files
cell-specific 30
Knowledge Bases 71
customer support 3
D
data classes
directory 69
data directory 68
data instances
directory 69
DateFormat 278
deleting
a cell 237
events using mquery 261
digital test certificate 194
digitally signing .jar files 194
directories
bin 68
classes 68
collectors 68
data 68
for KB components 69
lib 68
record 69
rules 69
structure for Knowledge Bases 66
dynamic data
model 284
Index
299
E
EM cell
production 25
test 25
enabling
persistent buffering 255
encryption
behavior 40
mcell.conf settings 39
mcell.dir settings 39
mclient.conf settings 39
encryption key 39
error file
mcell.err 57
establishing inbound connection in protected environment
36
event classes
directory 69
event group
configuration files 185
event parameters
EventAutoClose 281
EventDBCleanupDurationLimit 281
EventDBCleanupInterval 281
EventDBCleanuponDateReception 281
EventDBCleanupPercentage 281
EventDBCleanupPreferClosed 282
EventDBKeepClosed 282
EventDBKeepNonClosed 282
EventDBNoCleanupClosed 283
EventDBNoCleanupNoCleanupNonClosed 283
EventDBSize 283
repository cleanup 281
event propagation
enabling 33
illustrated 33
event repository
cleanup parameters 281
EventAutoClose 281
EventDBCleanupDurationLimit 281
EventDBCleanupInterval 281
EventDBCleanupOnDateReception 281
EventDBCleanupPercentage 281
EventDBCleanupPreferClosed 282
EventDBKeepClosed 282
EventDBKeepNonClosed 282
EventDBNoCleanupClosed 283
EventDBNoCleanupNonClosed 283
EventDBSize 283
events
deleting using mquery 261
exporting to a flat file 205
merging objects 265
modifying 267
posting with mposter 251
propagating using a gateway 31
300
examples
mccomp 215
mcell 217
mcfgtrace 219
mclassinfo 222
mcollinfo 227
mcontrol 230
mcrtcell 234
mcstat 236
mdelcell 237
mgetinfo config 241
mgetinfo connect 243
mgetinfo param 242
mgetinfo services 242
mgetrec command 244
mkb 247
mkill 249
mlogchk 250
mquery 261
mrecover 263
mrextract 264
mrmerge 266
msetmsg 267
msetrec 269
ExportConfigFileName 199
ExportDiscarded 199
exporting
event data from mcdb by StateBuilder 199
events to a flat file 205
ExportTriggerArguments 199
ExportTriggerProgram 199
F
files
.baroc 68, 69
.load 68, 70
.loadwic 70
.mrl 69
.pkg 69
.wic 69, 70
.xact 72
application.properties 125
extensions for KB components 69
gateway.export 198, 205, 206
ixs.properties 124
kb_core_resource.properties 188
kb_deprecated_resource.properties 189
manifest.kb 70, 214
mcdb state 198
mcell.conf 31
mcell.dir 34??, 211
mcell.err error 57
mcell.modify 37, 124
mcell.propagate 31
mcell.trace 51
files (continued)
mcfgtrace 217, 218
propagation configuration 31
sim.wic 68
sim_decl.wic 68
statbld.conf 198, 205
statbld.exe 198
statbld.trace 198, 207
StateBuilder configuration 199
trace configuration 51
xact transaction 198
filters
using hidden slots 180
ForceEncryption 39
foreground, running cell in 217
G
gateway 31
gateway configuration 200
gateway.export file 198, 205, 206
global records
directory 69
obtain a value 243
setting a value 268
goal line (reports) configuration parameters 134
H
HeartbeatEnabled parameter 284
HeartbeatInterval parameter 284
HeartbeatMissedCritical parameter 284
HeartbeatMissedMinor parameter 284
HeartbeatMissedWarning parameter 284
heartbeats, cell 287
I
icons
BMC Impact Explorer configuration files for event
groups 185
image views
overview 124
importing Knowledge Bases 71
infrastructure management
Administer subtabs 154
audit log 165, 167, 171
default service model 140, 142
Details subtabs 152
editing infrastructure relationships 156
GUI view 144, 150
high availability cells 160
icons 150
manually deleting components 174
navigation tree 143, 151
infrastructure management (continued)

permissions 142
registered components 140, 166, 172
related components 154
remote actions 148, 149, 160, 174
remote systems 145
roles 142
run states 174
specifying support files 169
support files 146, 169, 171
usage reporting 159
interface classes
directory 69
ix.properties file
defining presentation name search order for BIX 191
entry format 190
property descriptions 183
ixs.properties file
parameters 136
using to customize BMC Impact Portal 124
J
jar files
digitally signing 194
Java Web Start application
extracting presentation name resource files 189
K
kb_core_resource.properties file
entry format 192
modifying 193
kb_deprecated_resource.properties file 189
KBDirName 287
KBDirName parameter 287
kbmodules argument 74
KBRecoveryDirName parameter 287
kbsources argument 74
kbversion primitive
described 74
keys
creating and modifying presentation names 192
formats for presentation names 192
Knowledge Bases
compiling 71, 214
compiling with trace 72
creating 71
directories 69
directory structure 66
file extensions 69
importing 71
index file 70
integrating with a unified KB 70
KBDirName 287
Index
301
Knowledge Bases (continued)
loading 72
managing 70
parameters
KBRecovery 287
retrieving version information with kbversion 74
retrieving version information with mgetinfo 74
subdirectories 68
updating 245
versioning 72
versioning mechanism 73
L
lib directory 68
loading
Knowledge Bases 72
M
managing
Knowledge Bases 70
manifest.kb file 70, 214
mccomp command 71, 214
example 215
options 214
return codes 215
syntax 214
mcdb state file 198
affects on recovery process 262
mcell command 216
example 217
options 216
return codes 218
syntax 216
mcell.conf file
parameter rules 28
path substitution parameters 29
specifying paths 29
mcell.dir file 211
configuring clients for passive connections 36
description and usage 34??
example file 35
format of entries 34
keywords for entries 35
rules applied to entries 35
mcell.err file 57
mcell.modify file 37, 3738, 124
mcell.propagate file 31
default options 32
usage 31
mcell.trace file 51, 217, 218
mcfgtrace command 217, 218
example 219
options 219
302
mcfgtrace command (continued)

parameters 219
syntax 218
mclassinfo command 220
adding slot flags and default values 224
adding slot names and representation types 224
examples 222
obtaining a list of classes 223
obtaining a list of slot names 223
options 220
output 220
return codes 225
syntax 220
mcollinfo command 225
example 227
options 225
output 226
return codes 228
syntax 225
mcontrol command 72, 228
commands
mcontrol 229
examples 230
options 228
reconfiguring a cell 231
retrying pending propagations 230
syntax 228
terminating a cell 230
mcrtcell command 71, 231
actions 232
creating a service 234
creating another service 234
examples 234
options 233
return codes 235
syntax 233
mcstat command 235
example 236
options 236
return codes 236
mdelcell command 237
deleting a cell 237
example 237
options 237
return codes 238
syntax 237
menu, Reload 163
merging event objects 265
message buffer parameters
MessageBufferKeepSent 289, 290
MessageBufferKeepWait 289, 290
MessageBufferReconnectIntervalparameters
MessageBufferReconnectInterval 289, 291
MessageBufferResendCount 289, 291
MessageBufferSize 288, 290, 291
MessageBufferKeepSent 289, 290
MessageBufferKeepWait 289, 290
MessageBufferReconnectInterval 289, 291
MessageBufferResendCount 289, 291
MessageBufferSize 288, 290, 291
metrics collection, tab for 165
mgetinfo command 74, 238
config example 241
connect example 243
options 238
param example 242
return codes 243
services example 242
syntax 238
mgetrec command 243
example 244
options 244
return codes 245
syntax 244
mkb command 71, 245
examples 247
options 245
return codes 248
syntax 245
mkill command 248
command options 248
examples 249
options 249
return codes 249
syntax 248
mlogchk command 249
examples 250
return codes 251
syntax 250
modifying
cell connection settings 132
ModuleName parameter 73
monitoring passive connections 37
mposter command 251, 255
enabling persistent buffering 255
options 252
return codes 256
syntax 252
mquery command 251, 267
deleting events 261
examples 261
options 257
output 258
return codes 262
selecting events with a severity level 261
syntax 257
mrecover command 262
example 263
options 263
return codes 263
syntax 263
mrextract command 264
example 264
options 264
mrextract command (continued)

return codes 265
syntax 264
mrmerge command 265
command options 265
example 266
options 266
return codes 266
syntax 265
msend command 251, 267
msetmsg command 267
closing an event 267
examples 267
options 267
return codes 268
syntax 267
msetrec command 268
example 269
options 268
return codes 269
syntax 268
N
name keys
creating and modifying 192
naming conventions
for cells 231
O
objects
list of presentation names for 188
obtaining a global record value 243
obtaining a list of classes 223
obtaining a list of slot names 223
obtaining status of cell
using mcstat 236
options
mccomp 214
mcell 216
mcfgtrace 219
mclassinfo command 220
mcollinfo 225
mcontrol 228
mcrtcell 233
mcstat 236
mdelcell 237
mgetinfo 238
mgetrec 244
mkb 245
mkill 249
mposter 252
mquery 257
mrecover 263
Index
303
options (continued)
mrextract 264
mrmerge 266
msetmsg 267
msetrec 268
output
mclassinfo 220
mcollinfo 226
mquery command 258
P
parameters
ActionResultInlineLimit 274
ActionResultKeepPeriod 274
BMC Impact Portal configuration 124
client 287
HeartbeatEnabled 284
HeartbeatInveral 284
HeartbeatMissedCritical 284
HeartbeatMissedMinor 284
HeartbeatMissedWarning 284
KBRecovery 287
mcfgtrace 219
Server 287
state 287
trace, list of 293
tracing, configuring 55
passive connections 36
client configuration 36
monitoring 37
passwords
invalid, logging on to BMC Portal 122
pending progagations
retrying 230
policy file
BMC Impact Portal 179
console_policy.prop 179
posting events to a cell 251
presentation names
about 188
creating a new resource file 190
creating and modifying name keys 192
default definitions 189
defining 192
enabling and disabling BIX tool tips for 195
extracting resource files for BIX (Java Web Start) 189
files 191
key formats 192
list of objects with 188
resource file locations 188
resource file search order 191
ProcessingLimitPercentage 30, 275
product support 3
production cells
described 25
304
PropagateBufferSize 289, 291

PropagateConfigFileName 290
propagating
events using a gateway 31
propagation configuration file, mcell propagate 31
propagation parameters
PropagateBufferSize 289, 291
PropagateConfigFileName 290
protected environments
client configuration for passive connections 36
monitoring passive connections 37
protected zone, connecting cells in 36
R
reconfiguring
cell files for 43
cells with mcontrol command 231
records directory 69
Reload menu (BIX)
Administration View (BIX) 163
reports
BMC Impact Portal goal line configuration parameters
134
resource files
creating 190
extracting for BIX (Java Web Start) 189
locations of 188
search order 191
retrieve objects from cell 251, 267
retrying pending progagations 230
return codes
mccomp 215
mcell 218
mclassinfo 225
mcollinfo 228
mcrtcell 235
mcstat 236
mdelcell 238
mgetinfo 243
mgetrec 245
mkb 248
mkill 249
mlogchk 251
mposter 256
mquery 262
mrecover 263
mrextract 265
mrmerge 266
msetmsg 268
msetrec 269
statbld 199
RuleLoopDetect 287
rules
directory 69
S
saved state 262
scripts and programs directory 69
selecting
events with a severity level 261
server parameters 287
CellErrorEvents 287
CellEventEnable 287
CellMetricstEnabled 287
CellTickInterval 287
ConnectionPortRange 271, 275
ConnectionPortReuse 271, 275
ProcessingLimitPercentage 30, 275
RuleLoopDetect 287
ServerPort 275
ServerAllInterfaces 275
ServerPort 275
service models
class definitions directory 69
setting
a value in a global record 268
cell-specific configuration up 30
SIM cell
production 25
test 25
sim.wic file 68
sim_decl.wic file 68
starting cells
specific cell 216
with mcell 72
statbld return codes 199
statbld.conf file 198, 205
statbld.exe file 198
statbld.trace file 198, 207
State 292
state configuration parameters 287
ExportConfigFileName 199
ExportDiscarded 199
ExportTriggerArguments 199
ExportTriggerProgram 199
StateHistoryCount 199
state files, extracting 264
state parameters 287
StateBuildAtTerminate 292
StateBuildConfigFileName 292
StateBuildInterval 292
StateBuildRunTimeOut 292
StateBuildSize 292
StateBuildAtTerminate 292
StateBuildConfigFileName 292
StateBuilder 198
configuration parameters for event data export 199
StateBuildInterval 292
StateBuildRunTimeOut 292
StateBuildSize 292
StateHistoryCount 199
stopping cells
with mkill 72, 248
support, customer 3
SynchronizedTimeOut 278
syntax
mccomp 214
mcell 216
mcfgtrace 218
mclassinfo 220
mcollinfo 225
mcontrol 228
mcrtcell 233
mdelcell 237
mgetinfo 238
mgetrec 244
mkb 245
mkill 248
mlogchk 250
mposter 252
mquery 257
mrecover 263
mrextract 264
mrmerge 265
msetmsg 267
msetrec 268
SystemLogDirName parameter
described 276
SystemTmpDirName parameter
described 276
T
technical support 3
terminating a cell 230
test cells
described 25
test certificate, digital 194
tool tips
BIX, enabling and disabling 195
trace configuration file 51
configuring 51
parameters 51
Trace parameter 293
trace parameters
list of 293
trace, disable encryption to 41
TraceConfigFileName parameter 293
TraceDefaultFileName parameter 293
TraceFileAppend parameter 295
TraceFileHistory parameter 295
TraceFileSize parameter 295
TraceRuleLevel parameter 293
TraceRuleToXact parameter 294
TraceSrc parameter 293
Index
305
tracing parameters
configuring 55
Trace 293
TraceConfigFileName 293
TraceDefaultFileName 293
TraceFileAppend 295
TraceFileHistory 295
TraceFileSize 295
TraceRuleLevel 293
TraceRuleToXact 294
TraceSrc 293
U
updating the Knowledge Base 245
usage reporting 159
V
VersionID parameter 73
versioning
compiling 73
Knowledge Bases 72
mechanism 73
retrieving version information with kbversion 74
retrieving version information with mgetinfo 74
X
xact transaction file 198
306
Notes
*97717*
*71779*
*71779*
*71779*
*71779*

BMC Impact Solutions 7.3 - Infrastructure Management Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMC Impact Solutions 7.3 - Infrastructure Management Guide PDF

Uploaded by

Copyright:

Available Formats

BMC Impact Solutions

Contacting BMC Software

United States and Canada

BMC SOFTWARE INC

713 918 8800 or

(01) 713 918 8000

713 918 8000

Outside United States and Canada

(01) 713 918 8800

Copyright 20062009 BMC Software, Inc.

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

operating system and environment information

sequence of events leading to the issue

commands and options that you used

product error messages

BMC Impact Solutions Infrastructure Management Guide

Managing BMC Impact Manager cells

General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Managing a Knowledge Base

Knowledge Base structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

About the unified Event Management and Service Impact Management

Managing the BMC Impact Administration server

BMC Impact Solutions Infrastructure Administration Guide

Managing the BMC Impact Portal

Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Working with Infrastructure Management

Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . .

Registering a cell with the Admin cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Managing the BMC Impact Explorer (BMC IX) console

Defining property files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Defining presentation names

Presentation names overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Configuring StateBuilder and gateways

Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

BMC SIM and EM CLI Reference

BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

BMC Impact Solutions Infrastructure Administration Guide

mcontrolPerforming cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . .

mcell.conf file parameters

Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BMC Impact Solutions Infrastructure Administration Guide

Raw output format for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

BMC Impact Solutions Infrastructure Management Guide

mkb command on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BMC Impact Solutions Infrastructure Management Guide

Edit Relationship dialog: field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

BMC Impact Solutions Infrastructure Management Guide

mdelcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BMC Impact Solutions Infrastructure Management Guide

Managing BMC Impact Manager

General configuration overview

General configuration overview

BMC Impact Manager cell

Table 1 outlines the tasks that configure these components.

BMC Impact Solutions configuration process

(optional) Configure the BMC Impact Portal. BMC Impact Portal

For more information, see

Configure BMC Impact Manager cells.

BMC Impact Manager

Chapter 1, Managing BMC

Define user groups for access to the console BMC Impact