NSMADMG

Unicenter Network and Systems Management
Administrator Guide
3.1
This documentation and related computer software program (hereinafter referred to as the Documentation) is for the end users informational purposes only and is subject to change or withdrawal by Computer Associates International, Inc. (CA) at any time. This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright laws of the United States and international treaties. Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the license for the software are permitted to have access to such copies. This right to print copies is limited to the period during which the license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the users responsibility to return to CA the reproduced copies or to certify to CA that same have been destroyed. To the extent permitted by applicable law, CA provides this documentation as is without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose or noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of such loss or damage. The use of any product referenced in this documentation and this documentation is governed by the end users applicable license agreement. The manufacturer of this documentation is Computer Associates International, Inc. Provided with Restricted Rights as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.
2003 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contents
Chapter 1: Managing Your eBusiness Infrastructure

Todays Challenges .......................................................................... 11 The Unicenter NSM SolutionIntegration and Innovation ...................................... 12 Welcome to Unicenter Network and Systems Management .................................. 13 Managing the Extended Enterprise ........................................................ 14 User Interfaces ........................................................................... 18 Unicenter NSM Infrastructure Solutions ....................................................... 19 WorldView ............................................................................. 110 End-to-End Management ................................................................ 111 Agent Technology ...................................................................... 113 Performance Management ............................................................... 115 Enterprise Management ................................................................. 115 ManagedPC ............................................................................ 121 The Software Development Kit ........................................................... 122 Getting Help ........................................................................... 123 Documentation Road Map ................................................................... 123 Types of Documentation ................................................................. 123
Chapter 2: Advanced Visualization

Discover the IT Infrastructure ................................................................. 22 Creating the Common Object Repository ................................................... 23 Phase 1: Discovering and Classifying Network Devices ...................................... 25 Phase 2: Discovering Agents and Agent Objects ............................................ 216 Visualize Your Network Infrastructure ....................................................... 216 The Unicenter Explorer Window ......................................................... 217 Terminology............................................................................ 218 Exploring the Network with the 2D Map .................................................. 220 Locating and Modifying Managed Objects ................................................ 223 Exploring the Network with the 3D Map .................................................. 228 Viewing Objects with the Association Browser ............................................. 232
Contents
iii
Viewing Current Status ................................................................. Viewing Object Details and Properties .................................................... Viewing MIBs and WBEM Data with ObjectView .......................................... Creating and Viewing Business Process Views ............................................ Customizing the Maps .................................................................. Modify the Class Hierarchy ................................................................. Reviewing Class Definitions ............................................................. Adding or Modifying Classes ............................................................ Viewing Your Enterprise Across Time ........................................................ Unicenter Controller .................................................................... Importing and Exporting Data with Trix...................................................... Protecting the Repository with Data Scoping Rules ............................................ User IDs and Data Scoping Evaluations................................................... Win32 Applications ................................................................. Accessing the Repository ............................................................ Data Scoping Classes ................................................................... Using Data Scoping ..................................................................... Datargen Examples (Windows Only) ................................................. Data Scoping Inheritance Rules .......................................................... Data Scoping Order of Rule Precedence .................................................. Examples .......................................................................... Rule Performance Issues ................................................................ Data Scoping from Outside Unicenter NSM ............................................... Create Database User ID............................................................. Create Data Scoping Rules ........................................................... Maintain Data Scoping Security ...................................................... Data Scoping in the 2D Map (Windows Only) ............................................. Troubleshooting on UNIX/Linux ........................................................ Changing the Inbound and Outbound Session Limits .................................. Permissions for Jasmine Catalog .....................................................
232 233 234 235 238 239 240 241 243 243 245 248 250 250 252 252 253 255 258 258 259 260 260 261 261 262 262 263 263 264
Chapter 3: Agent Technology

Understand Agent Technology ............................................................... Agents ................................................................................. Distributed State Machine (DSM) ......................................................... Managed Objects ........................................................................ States ................................................................................... 31 31 32 33 33
iv
Administrator Guide
Configure Agent Technology ................................................................. 35 Agent Level ............................................................................. 35 DSM Level .............................................................................. 36 WorldView Level ........................................................................ 36 View Agent Technology ...................................................................... 37 Agent Technology Services Manager ....................................................... 38 Agent View ............................................................................. 39 DSM View ............................................................................. 310 Event Browser .......................................................................... 311 Global Configuration Utility ............................................................. 312 MIB Browser ........................................................................... 313 Node View ............................................................................. 314 Pollset Browser ......................................................................... 315 Remote Ping ............................................................................ 316 Repository Monitor ..................................................................... 317 SNMP Administrator .................................................................... 318 Verify Agent Status ......................................................................... 319 Confirming the Current Status ........................................................... 319 Viewing the Sequence of Events .......................................................... 319 Editing Managed Objects ................................................................ 320 Correlate Events ............................................................................ 320 Use Network Monitoring .................................................................... 321 Polling ................................................................................. 321 Checking Interface Connectivity .......................................................... 323
Chapter 4: Performance Management

How Performance Management Works ........................................................ 42 Performance Agent....................................................................... 43 Resource Accounting Service .............................................................. 45 Terminology............................................................................. 47 Accessing the Performance Components ....................................................... 49 Performance Configuration ................................................................... 49 Understand the Architecture .............................................................. 49 Configure Your Performance Domain ..................................................... 413 Configure the Performance Agent ........................................................ 417 Work with Profiles ...................................................................... 421 Configure SNMP Data Gathering and Proxy Machines ..................................... 422 Configure a Selected Machine/Device .................................................... 425 Maintain Configuration Servers and the Performance Agent ................................ 428
Contents
Performance Scope ......................................................................... Configure Scope Options ................................................................ View Resources for a Specific Machine ................................................... Create Charts of Monitored Data ......................................................... Set Thresholds ......................................................................... View Errors ............................................................................ Performance Trend ......................................................................... Conduct Trend Analysis ................................................................ Automate Chart Generation ............................................................. Correlate Cube Data .................................................................... Chargeback ................................................................................ Chargeback Implementation ............................................................. Identify Your Organizational Structure ................................................... Chargeback Concepts ................................................................... Resource Allocation ................................................................. Chargeback ........................................................................ Budget ............................................................................. Resource Allocation Walk-Through ...................................................... Chargeback Accounting Walk-Through .................................................. Generating Bills and Customizing Invoices ............................................ Reporting Transactions .............................................................. Creating Graphical Reports .......................................................... Budget Accounting Walk-Through ....................................................... Chargeback Period Concepts ............................................................ Where Resource Files Are Stored ......................................................... Security Management ................................................................... Resource Accounting Service ............................................................ Performance Utilities ....................................................................... Performance Cube to CSV File Conversion Utility ......................................... Chart Definition File Conversion Utility .................................................. Cube Spider Utility .....................................................................
432 433 433 434 435 436 436 437 440 440 441 442 442 443 444 450 450 450 453 454 455 455 455 457 458 458 459 460 460 460 461
Chapter 5: Event Management

Establish Date and Time Controls for Automated Event Processing .............................. 52 Trap Important Event Messages and Assign Actions ............................................ 53 Message Enhancement .................................................................. 512 Correlating Event Console Messages ..................................................... 512 Using Advanced Event Correlation ................................................... 513 Put Event Management Policies into Effect ................................................... 513 Event Agent ........................................................................... 514
vi
Administrator Guide
Monitor Message Traffic ..................................................................... 517 Filtering Sensitive Console Messages ..................................................... 518 Browsing Event Logs from Mobile Devices ................................................ 519 Provide Wireless Message Delivery........................................................... 520 Understanding Wireless Messaging Policy ................................................ 520 Sending a Message ...................................................................... 523 Responding to a Message ................................................................ 524 Implementing Command Messaging...................................................... 525 Creating Message Policy: The Wireless Messaging Policy Writer............................. 526 Troubleshooting the Wireless Messaging Policy Writer ..................................... 529 Customize Your Unicenter Console ........................................................... 531 View Multiple Remote Console Logs ......................................................... 533 Use SNMP to Monitor Activity ............................................................... 534 SNMP Traps ............................................................................ 534 Automatic Formatting of SNMP Traps .................................................... 535 Sending Traps with catrap ............................................................... 537 What Is a MIB? ......................................................................... 538 Maintenance Considerations ................................................................. 542 Cleaning Up Log Files ................................................................... 542 Using a Local Copy of the Event Management Policy ....................................... 542 Exits for User-Defined Functions ......................................................... 542 Security Enhancements .................................................................. 542 Submit Commands on Behalf of Another User ............................................. 543
Chapter 6: Workload Management

How Workload Management Works........................................................... 62 Workload Subsystems .................................................................... 62 Workload Profiles ........................................................................ 64 Types of Job Scheduling .................................................................. 65 Specify Where to Perform Work ............................................................... 66 Identify Resource Requirements for Workload Balancing ........................................ 67 Schedule Work by Dates...................................................................... 68 Form Groups of Related Tasks (Jobsets) ....................................................... 610 Identify Work to Perform .................................................................... 613 Schedule Work by Special Events ............................................................ 619 Run a Job on Demand ....................................................................... 621 Test Your Workload Policy Definitions ....................................................... 622 Autoscan .................................................................................. 624 Qualifying for Selection During Autoscan ................................................. 624 Cleanup and Backlogging ................................................................ 625
Contents
vii
Workload Processing ....................................................................... Maintenance Considerations ................................................................ Workload Logs ......................................................................... Tracking File ........................................................................... Undefined Calendars During Autoscan ................................................... Workload Database ..................................................................... Submit Jobs on Behalf of Another User ................................................... Agent/Server Configurations ............................................................... Cross-Platform Scheduling .................................................................. Components of Cross-Platform Scheduling ............................................... Implementation ........................................................................ Important Configuration Environment Variables .............................................. Environment Variables for Jobs and Actions .............................................. Monitor Workload Status ................................................................... Jobflow Tracking on Windows ...........................................................
626 628 628 629 629 630 630 631 633 634 635 638 640 641 642
Chapter 7: Problem Management

Establish the Configuration .................................................................. 71 Establish Basic Problem Management Policies ................................................. 73 Setting Up Categories .................................................................... 73 Setting Up Status Codes .................................................................. 73 Setting Up Responsibility Areas........................................................... 74 Establish Problem Escalation Policies.......................................................... 75 Open New Problems ........................................................................ 77 Establish Policies for Automatically Opening Problems ......................................... 77 Message Records and Message Actions .................................................... 78 Track Problems ............................................................................ 710
Chapter 8: Report Management

Decide Which Reports to Manage ............................................................. Select the Required Pages .................................................................... Identify a Report Profile and Recipient ........................................................ Route Reports to Report Management for Distribution .......................................... Track Report Bundles ........................................................................ Maintenance Considerations ................................................................. 82 82 83 84 84 86
viii
Administrator Guide
Chapter 9: Spool Management

Implement Spool Management ................................................................ 92 Stop and Start the Spooler ................................................................ 92 Define a Print Device ..................................................................... 93 Modify a Print Request ................................................................... 93 Verify Spool Management Implementation ................................................. 94 Control the Flow of Data to Printers ....................................................... 94
Chapter 10: Unicenter Reports

What Is the Reports Builder? ................................................................. 101 Configuring the Reports Builder .......................................................... 102 Selecting Data .......................................................................... 103 Filtering Data ........................................................................... 104 Adding Calculations .................................................................... 104 Accessing Report Information ............................................................ 104 Catalog Management Outside the Reports Builder ......................................... 105 Saving Database Passwords .............................................................. 105 What Is the Reports Administrator? .......................................................... 106 What Is the Reporter Server? ................................................................. 106
Chapter 11: Tape Management

Define Tape Volumes ....................................................................... 112 Initialize Tape Volumes ..................................................................... 113 Reinitializing Tape Volumes ............................................................. 114 Displaying an Internal Label ............................................................. 115 Managing Special Tape Marks ........................................................... 116 Transparent End-Of-Volume (TEOV) Assistance ........................................... 116 Handling Special External Labels ......................................................... 118 Access a Resident Tape ...................................................................... 119 Declaring Intentions ..................................................................... 119 Calling for an Input Tape ............................................................... 1110 Verifying Tape Access (Input and Output) ............................................... 1111 Retain Tape Files .......................................................................... 1112 Assign Tape Drives ........................................................................ 1112 Defining Eligible Devices for Automatic Volume Recognition (AVR) ........................ 1113 Displaying Tape Device Status .......................................................... 1115 Reserve Tape Drives ....................................................................... 1116
Contents
ix
Implement Surrogate Tape Processing....................................................... Enabling Surrogate Mounts ............................................................ Disabling Surrogate Mounts ............................................................ Retaining Surrogate Status ............................................................. Requiring Operator Verification ........................................................ Regulate Trusted Offenders ................................................................ Process Unlabeled Tapes ................................................................... Enabling Unlabeled Tape Processing .................................................... Accessing Unlabeled Resident Volumes ................................................. Establish a Vault Storage System............................................................ Vault Creation ........................................................................ Media Selection ....................................................................... Scheduled Media Movement ........................................................... Special Media Movement .............................................................. Physical Movement and Inventory Tracking ............................................. Audit Trails ........................................................................... Schedule Volume Movement ............................................................... Select the Media ........................................................................... Move Volumes Into/Out of a Vault ......................................................... View Slot Storage for a Volume Set ......................................................... Customize the Daily Processing Cycle ....................................................... Report on Tape Activity.................................................................... Generating the Scratch and Clean Listing ................................................ Printing an Earlier Vault Report ........................................................ Change System Options....................................................................
1117 1118 1118 1118 1119 1120 1121 1121 1122 1123 1124 1124 1125 1125 1126 1128 1128 1128 1128 1129 1129 1130 1130 1132 1133
Chapter 12: Storage Management

Features ................................................................................... 122 Management Functions ..................................................................... 124 Wizards ................................................................................... 126 Components ............................................................................... 127 BrightStor ARCserve Backup Manager ................................................... 127 BrightStor ARCserve Backup Server ...................................................... 127 Domains ............................................................................... 129 Perform Data Backup ...................................................................... 1210 Selecting the Best Backup Scheme for Your Requirements ................................. 1210 Determining Database Backup Sources .................................................. 1210 Selecting the Backup Method ........................................................... 1211 Specifying Rules for Media Overwrite/Append .......................................... 1213 Compressing and Encrypting Your Backup Data ......................................... 1217
Administrator Guide
Verifying Your Backup Data ............................................................ 1217 Specifying Pre/Post Commands ......................................................... 1218 Perform Data Restore ...................................................................... 1219 Selecting Backup Media for a Restore .................................................... 1220 Selecting a Destination for Your Restored Data ........................................... 1222 Merging Media ........................................................................ 1223 File Conflict Resolution Options ......................................................... 1223 Recover from a Disaster .................................................................... 1224 Maintaining Current Backups ........................................................... 1225 Backing Up the BrightStor ARCserve Backup Database .................................... 1225 Restoring the BrightStor ARCserve Backup Host for Windows ............................. 1225 Restoring the BrightStor ARCserve Backup Database for Windows ......................... 1226 Restoring the BrightStor ARCserve Backup Host for UNIX/Linux .......................... 1227 Restoring the BrightStor ARCserve Backup Database for UNIX/Linux ...................... 1228 Manage Jobs Using the Job Status Manager .................................................. 1229 Accessing Job Status Information ........................................................ 1229 Adding a Job to the Job Queue .......................................................... 1233 Changing a Jobs Execution Date, Time, or Status ......................................... 1233 Stopping an Active Job ................................................................. 1233 Modifying a Job........................................................................ 1234 Changing the Way Jobs Are Listed in the Job Queue ....................................... 1234 Monitoring an Active Job ............................................................... 1235 Customize Your Jobs ....................................................................... 1236 Customizing Your Jobs Using Filters ..................................................... 1236 Customizing Your Jobs Using Schedule Options .......................................... 1240 Customizing Your Jobs Using Job Scripts ................................................. 1241 Customizing Your Jobs Using Options ................................................... 1241 Manage Devices and Media ................................................................. 1252 Defining Device Groups ................................................................ 1253 Using the Device Sharing Feature........................................................ 1254 Using Parallel Streaming ............................................................... 1255 Spanning Media Automatically ......................................................... 1256 Viewing Media Information ............................................................. 1256 Maintaining Media ..................................................................... 1256 Formatting Media ...................................................................... 1257 Erasing Data from Media ............................................................... 1258 Re-Tensioning a Cartridge Tape ......................................................... 1259 Compressing Data on Media ............................................................ 1259 Using Media-to-Media Copy ............................................................ 1260 Managing Removable Drives............................................................ 1260 Managing Devices and Media in Unicenter Tape Management Mode ....................... 1261
Contents
xi
Define Media Pools and Rotation Schemes ................................................... Describing a Save Set .................................................................. Describing a Scratch Set ................................................................ Specifying the Retention Period ......................................................... Creating a Media Pool ................................................................. Supplying Serial Numbers ............................................................. Assigning Media to a Media Pool ....................................................... Using the Media Pool Manager ......................................................... Defining a Simple Rotation Scheme ..................................................... Using the GFS Rotation Scheme ......................................................... Manage and Report on the Database ........................................................ Opening the Database Manager ......................................................... Microsoft SQL Server Support .............................................................. Supplying SQL Connections ............................................................ Running a Database Consistency Check ................................................. Logs and Reports.......................................................................... BrightStor ARCserve Backup Logs ...................................................... Activity Log .......................................................................... Job Log ............................................................................... Tape Log ............................................................................. Media Server Log...................................................................... Viewing Reports Using the Reports Manager............................................. Administer the BrightStor ARCserve Backup Server .......................................... Configuring the BrightStor ARCserve Backup Job Engine ................................. Configuring the BrightStor ARCserve Backup Tape Engine ................................ Configuring the BrightStor ARCserve Backup Database Engine ............................ Viewing Information about the BrightStor ARCserve Backup Engines ...................... Understanding Engine Status ........................................................... Using the BrightStor ARCserve Backup Manager ......................................... Selecting the Network Shares Browser Option ............................................ Recording Hard Links for NTFS Volumes ................................................ Confirming When Overwriting Media ................................................... Backing Up the Windows Registry ...................................................... Using Alert with the Logs .............................................................. Changing the BrightStor ARCserve Backup System Account ............................... Setting the Database Access Mode ...................................................... Use the Alert Manager ..................................................................... Understanding Basic Components of Alert ............................................... Running the Alert Manager ............................................................ Configuring Alert ..................................................................... Using Alerts Broadcast Option .........................................................
1262 1263 1263 1264 1264 1264 1265 1266 1266 1267 1273 1273 1276 1276 1276 1276 1277 1278 1278 1279 1279 1280 1283 1283 1284 1285 1288 1288 1289 1290 1290 1290 1290 1291 1291 1291 1291 1292 1293 1293 1294
xii
Administrator Guide
Using the Pager ........................................................................ 1294 Using the SNMP Option ................................................................ 1294 Using the Trouble Ticket ................................................................ 1295 Using Email ........................................................................... 1295 Using the Unicenter Option ............................................................. 1295 Determining the Application Event Priority .............................................. 1295 Testing the Recipients .................................................................. 1296 Alerts Activity and Event Logs ......................................................... 1297
Chapter 13: Security Management

How Security Management Works ........................................................... 132 Managing Security Policies .............................................................. 132 Understanding the Commit Process....................................................... 133 Implement Security Management ............................................................ 136 Phase 1: Review Security Management Options................................................ 137 Options to Consider for Your Operations .................................................. 138 Default Permission Option ........................................................... 138 System Violation Mode .............................................................. 139 Access Violation and Enforcement ................................................... 1310 Authorized User List (for QUIET Mode) .............................................. 1312 Dynamic Update of Local User and User Group Profiles ............................... 1313 Local/Remote Standard Security Facility (CAISSF) Support ............................ 1314 Other Options for the Windows Platform................................................. 1316 Dynamic Update of Remote User Profiles ............................................. 1316 Trusted Domain Support............................................................ 1317 Remote Audit ...................................................................... 1319 Guest ID Support .................................................................. 1320 WINLOGON Logon Support ........................................................ 1320 Windows NT/SAM Password Maintenance .......................................... 1321 Rule Server for Rule Processing ...................................................... 1322 User Group Server for Rule Processing ............................................... 1322 Security Management Automatic Startup ............................................. 1322 Other Options for UNIX/Linux Platforms ................................................ 1323 Node Support Implementation ...................................................... 1323 Network Information Service (NIS) Integration Support ............................... 1326 Password Processing: Restriction Bypass, Validation Exit, and Time-out Specification .... 1330 su Command: Secure Target User .................................................... 1332 setuid Operation: Secure Target User ................................................. 1332 Customizing Your Options for Phase 2 ................................................... 1333
Contents
xiii
Phase 2: Populate the Database, QUIET Mode ................................................ Initializing and Populating the Database ................................................. Executing the Initial Commit Process .................................................... Starting the Security Management Daemons ............................................. Phase 3: Create Rules for Production, WARN Mode .......................................... Defining Users ........................................................................ Defining User Groups.................................................................. Defining Asset Groups ................................................................. Asset Protection: Determining Access to Assets........................................... Defining Access Permissions ........................................................... Setting CAISSF Scoping Options ........................................................ Performing a Commit Process .......................................................... Phase 4: Set Options for Production, FAIL Mode ............................................. Enabling the Security Logon Intercept for Windows ...................................... Activating Security Intercepts for UNIX/Linux Platforms ................................. Performing the Commit Process ........................................................ Reactivate a Suspended User ID ............................................................ Deactivate Security Management ........................................................... Optional Features ......................................................................... User Profile Synchronization (UPS) ..................................................... UPS-Related Security Management Options .......................................... Mapping User IDs for UPS Events ................................................... UPS/Command Propagation Facility Interface ....................................... Configuring UPS .................................................................. Distributed Computing Environment (DCE) Synchronization .............................. DCE-Related Security Management Options ......................................... Database Synchronization (DBS) ........................................................ DBS-Related Security Management Options .......................................... Windows Backup Domain Controller Support............................................ Native Operating System Database Update .............................................. Password Change Notification (PCN) Facility ............................................ FTP Proxy ............................................................................ Rexec Proxy ........................................................................... Security Management Reports ..............................................................
1334 1334 1335 1336 1337 1337 1340 1342 1344 1356 1357 1359 1360 1360 1360 1361 1361 1361 1362 1362 1364 1368 1369 1370 1371 1372 1374 1375 1382 1383 1384 1385 1386 1387
Appendix A: ManagedPC
Prepare for ManagedPC Installation .......................................................... A2 Launch the ManagedPC Installation .......................................................... A2 Notes for Client Installations ............................................................. A4 Configure ManagedPC ...................................................................... A5
xiv
Administrator Guide
Downloading Files Using Boot Sequencing ................................................ A8 Creating Custom DOS Boot Images for Downloading ..................................... A10 Associating Customized DOS Boot Images with ManagedPCs.............................. A12 Using the Set ManagedPC Boot Option................................................... A13
Appendix B: Virus Scan

Downloading Virus Signature Updates ........................................................ B1 Deleting Old Scan Logs....................................................................... B2
Appendix C: Advanced Event Correlation

What Is Event Correlation? ................................................................... C1 Why Use AEC? .............................................................................. C2 How AEC Works ............................................................................ C3 Understanding Event Definitions .......................................................... C4 Installing AEC ............................................................................... C4 Configuring AEC ............................................................................ C5 Starting the IDE .......................................................................... C6 Components of a Correlation Rule ......................................................... C6 Event Pipeline Rule Components ...................................................... C6 Components of a Boolean Logic Rule ..................................................C10 Using Boolean Logic in AEC Rules ...........................................................C11 Boolean Logic Rules .....................................................................C11 Example ...............................................................................C13 Timing Parameters ......................................................................C14 How AEC Uses Timing Parameters ...................................................C15 Example ............................................................................C15 Configuration Wizards ......................................................................C16 Using Tokens...............................................................................C16 Internal Tokens .........................................................................C16 User-Defined Tokens ....................................................................C17 Local User-Defined Tokens ...........................................................C17 Using the Matching Regular Expression ...............................................C19 Using Additional Token Evaluation ...................................................C19 Global Constants ........................................................................C21 Calendar Support ...................................................................C21 Examples...............................................................................C22 Template Rules .............................................................................C22 Example ...............................................................................C22
Contents
xv
Using Regular Expressions .................................................................. C23 Advanced Template String Editor............................................................ C24 Advanced Configuration .................................................................... C24 Overriding Maturity .................................................................... C25 Suppressing Processed Messages ........................................................ C25 Reformatting Processed Messages ........................................................ C25 Resetting Rules Dynamically ............................................................ C26 Correlation Among Rules and RC Suppression Flag ....................................... C26 Flexible Configuration of Certain Reported Fields ......................................... C27 Using Tokens to Report the Originating Node ......................................... C27 Using Reset Request Event for Dynamic Resetting of Rules Using Event Messages ........ C27 Event Filtering ......................................................................... C28 AND Concept for Pipeline............................................................... C28 Calendar Support ...................................................................... C28 Event Counters and Thresholds .......................................................... C29 Event Sequencing ...................................................................... C29 Generate Root Cause for Every Matched Event ............................................ C30 Restart Timer on Match ................................................................. C30 Rule Chaining .......................................................................... C30 Rolling Event Window .................................................................. C30 Impact Analysis ............................................................................ C31 Impact Events .......................................................................... C32 Aggregate Impact Messages ............................................................. C33 Implementing AEC ......................................................................... C34 Using the Configuration Wizard ......................................................... C35 DLL Utilities ........................................................................... C35 Engine Status ....................................................................... C35 Event Log Player ................................................................... C36 Examples .................................................................................. C36 Ping Failure (Single Rule) ............................................................... C36 Identifying the Correlation .......................................................... C37 Resulting Messages ................................................................. C47 Ping Failure (Multiple Rules) ............................................................ C47 Identifying the Correlation .......................................................... C48 Resulting Messages ................................................................. C58 Operator Server Shutdown (Three Item Pipeline) .......................................... C58 Identifying the Correlation .......................................................... C59 Resulting Messages ................................................................. C73 Operator Service Shutdown (Multiple Tokens) ............................................ C73 Identifying the Correlation .......................................................... C73 Resulting Messages ................................................................. C83
xvi
Administrator Guide
Appendix D: Migration Tools

Data Transfer Wizard
.......................................................................
D1
Appendix E: Repository Bridging

Understand Repository Bridge ................................................................ E2 Bridge Architectures ......................................................................... E3 Fanout .................................................................................. E3 Aggregation ............................................................................. E4 Architectural Guidelines .................................................................. E5 Access Repository Bridge ..................................................................... E7 Bridge Control ........................................................................... E8 Bridge Configuration GUI ................................................................ E9 Bridge Instance ......................................................................... E10 Write a Bridge Configuration ................................................................ E10 Identify the Source Repository ........................................................... E11 Identify the Destination Repository ....................................................... E12 Configure Batch Mode Operation ......................................................... E13 Configure the Logging Facility ........................................................... E14 Configure Event Management Integration ................................................. E15 Configure Startup Options ............................................................... E15 Define the Bridging Policy ............................................................... E17 Save the Configuration .................................................................. E18 Possible Implementations ................................................................... E18 Overview of a Distributed Organization................................................... E18 Problem Notification .................................................................... E19 Restricted View of Resources ............................................................. E19 Troubleshooting ............................................................................ E20 Configuration File Not Displayed ........................................................ E20 Configuration Changes Not Used......................................................... E20 State Objects Not Bridged ................................................................ E21 Log Errors and Objects Not Bridged ...................................................... E21 Integrity Violation Error ................................................................. E22 Bridge Service Does Not Start ............................................................ E22
Contents
xvii
Appendix F: Desktop Management Interface (DMI)

DMI Overview .............................................................................. Components ................................................................................ Service Provider ............................................................................ MIF Database ............................................................................... Management Interface (MI) .................................................................. Component Interface (CI) .................................................................... Unicenter Support for DMI User Interface ..................................................... F1 F2 F2 F2 F3 F3 F3
Appendix G: Unicenter Management for Microsoft Operations Manager

Terminology ................................................................................ G1 Management Components ................................................................... G2 WorldView ............................................................................. G3 Event Management .......................................................................... G3 Management Using MOM Alerts ............................................................. G4 Converting MOM Alerts to Unicenter NSM Events ......................................... G4 Determining Object Status ................................................................ G5 Viewing and Resolving MOM Alerts ...................................................... G7
Appendix H: CAICCI
Data Security and CAICCI ................................................................... H1 Proprietary Encryption Option (PEO) ......................................................... H1 Enabling PEO ........................................................................... H2 Implementing PEO ...................................................................... H2 Compatibility with Previous Versions of CAICCI ........................................... H2 How PEO Works .................................................................... H3 PEO APIs ............................................................................... H3 EmCci_Init7 ............................................................................. H4 EmCci_Encrypt7 ........................................................................ H5 EmCci_Decrypt7 ........................................................................ H7 EmCci_Free7 ............................................................................ H8 CAICCI Secure Sockets Facility (CCISSF) ...................................................... H9 Learning About OpenSSL ................................................................ H9 Enabling CCISSF ........................................................................ H9 Environment Variable ............................................................... H10 Remote Daemon Configuration File .................................................. H10
xviii
Administrator Guide
Determining the Effective Security Value ................................................. H11 Compatibility with Previous Versions of CAICCI ......................................... H11 Configuring CCISSF .................................................................... H12 Default Certificate .................................................................. H12 Certificate Revocation Lists (CRLs)................................................... H13 The ccisslcfg Utility ................................................................. H14 The ccicrypt Utility ................................................................. H15 Using a Passphrase ................................................................. H15 Programming a Customized SSL Environment............................................ H16 Default Functions ...................................................................... H17 password_cb .......................................................................... H17 verifyCert ............................................................................. H18 Custom Libraries ...................................................................... H18 User-Exported Symbols ............................................................. H19 User Available Functions ............................................................... H19 get_cert_info .......................................................................... H19 enum_cert_info ........................................................................ H20 output_cert_info ....................................................................... H21 CCISSL_CLIENT_Auth_Callback_Env ................................................... H21 Header Information for User Customization .............................................. H23
Index
Contents
xix
Chapter
Managing Your eBusiness Infrastructure

Unicenter Network and Systems Management (Unicenter NSM) is The Software That Manages eBusiness. Regardless of the business modelBusinessto-Business (B2B), Business-to-Consumer (B2C), eMarketplace (eMP), Application Service Provider (ASP), or Managed Service Provider (MSP), Unicenter NSM continues to deliver innovative technology to manage the core infrastructure. Unicenter NSM keeps eBusiness up, running, and secure while connecting customers, suppliers, partners, and employees.
Todays Challenges
eBusiness presents tremendous challenges as systems and networks, security, storage, databases, applications, information, and business processes need to be managed in an integrated and concise manner. eBusiness applications distributed across large-scale, complex, and dynamic environments require integrated eBusiness solutions. Several factors contribute to the increasingly complex task of enterprise management:
Rapidly growing infrastructure Networksincluding the Internet, intranets, and extranetsare growing rapidly as more computers, cash machines, and kiosks are connected. Communications encompass plain old telephone service (POTS), email, groupware, video conferencing, and electronic commerce. Management solutions must be able to quickly embrace new technologies and at the same time provide unwavering levels of security, service, reliability, and availability.
Increased diversity of information architectures and elements Technological approaches to networking, database, application, hardware and software platforms continue to diverge. Enterprise desktops can range from personal computers, to netPCs, to network computers (NCs), to lean clients, to MS Windows-based or ASCII text terminals. Management software must be able to bridge these differences to provide comprehensive, consolidated administration of the entire IT infrastructure.
11
The Unicenter NSM SolutionIntegration and Innovation
Rising costs and productivity Efficiency and productivity are keys to survival in this dynamic business climate. Controlling costs while delivering better targeted goods and services more quickly than the competition is crucial to business success. Flat organizations, mergers, and management changes often result in staffs charged to do more with less, so organizations must anticipate failures, bottlenecks or related problems before they impact the business. Systems must become predictive and self-manageable by integrating intelligence and autonomy.

The goal of enterprise management software is to help organizations simplify administration of their IT environments by providing comprehensive control of the IT infrastructure. IT organizations need to manage the entire infrastructure that participates in the delivery of products and services. To be successful, enterprise management must encompass everything from router management, network discovery, database performance and space management, and application response time, to the traditional disciplines of tape, storage, help desk, security, and workload. Effective enterprise management should provide these disciplines on all platforms and for all resource types. True enterprise management requires comprehensive solutions based on an architecture that is open and extensible so that the entire IT infrastructure, including non-IT technology, can be managed transparently.

The solution must provide flexible, end-to-end coverage of enterprise assets. The solution must include integration services to make extended end-to-end enterprise management practical. The solution must also provide a means to evaluate and accelerate the infrastructure effectiveness from a business perspective. Administrators should be able to answer business-relevant questions such as How secure is the application running on the web server for registering new customers? Are all the cash registers running and updating inventory? Why are dairy products spoiling in our new refrigeration units?
An architecture complemented by the broadest array of functionally rich management solutions makes Unicenter NSM the only enterprise manager capable of managing IT infrastructures today. Unicenter NSM provides the security, reliability, availability, and performance associated with traditional IT environments, as well as the openness and extensibility to leverage existing technologies and adopt new ones as your eBusiness evolves. Unicenter NSM is The Software That Manages eBusiness.
12
Administrator Guide
Welcome to Unicenter Network and Systems Management

Unicenter NSM is a comprehensive, open, and scalable solution for managing IT environments and the associated infrastructure. Integrated end-to-end management of all IT resources is the Unicenter NSM hallmark. Whether the information infrastructure consists of traditional resources such as network devices, databases, and business applications, or non-traditional resources such as Pocket PCs, Unicenter NSM provides a strategy for managing your enterprises assets. You can manage the enterprise as a whole or divide it into localized or functional domains, each with its own Business Process Views and requirements. Every enterprise has unique business requirements and characteristics, and no single product can meet all needs. That is why Unicenter NSM is flexible, extensible, and customizable. Unicenter NSM leverages its common underlying infrastructure, known as CA Common Services, to maximize functional interoperability and to minimize cost. Out-of-the-box integration enables Unicenter NSM to:
Address the constantly expanding set of enterprise assets and infrastructure, including end-to-end management of networks, systems, databases, applications, and non-IT devices Provide a comprehensive and integrated set of management functions Manage IT resources and information within a broad-based business context, including policy-based process management Incorporate a common paradigm and framework for proactive management that is practical, predictive, and easy to use
Unicenter NSM delivers a rich set of management functions which are built on top of an object-oriented, open architecture and a highly scaleable, manager/agent infrastructure. Information visualization combined with proven management functions makes Unicenter NSM the best solution for managing eBusiness.
13
Managing the Extended Enterprise

End-to-end management is a prerequisite for optimizing your infrastructure investment. Unicenter NSM allows IT organizations to manage all of their resources using a single management approach. The Unicenter NSM management strategy encompasses heterogeneous networks, systems, applications, databases, and even non-IT devices. An important aspect of the Unicenter NSM strategy is combining network with system management capabilities. Unicenter NSM delivers capabilities far beyond those offered by traditional SNMP frameworks, while still delivering traditional network management functions such as discovery, status and topology displays, and SNMP support. The network management function in Unicenter NSM uses the Common Object Repository to store information. The common object repository supports the display, navigation, and control of objects from different management functions. It is instrumental in ensuring the uniform enforcement of management policies, user interface, and interaction. Global Catalog Every Unicenter NSM installation has a central catalog known as the Global Catalog. Created at installation, the Global Catalog contains information about the availability and location of all Unicenter NSM components. The Global Catalog should be installed on a high availability server before installing any other components such as WorldView, Event Management, or Agent Technology Distributed State Machine (DSM). WorldView, Enterprise Management, DSM, and other information sources register with the Global Catalog as providers at installation. Providers enable applications, data, and business components to appear as native within the object infrastructure so that all data can be accessed and integrated, regardless of origin, format, or location. Any Unicenter Explorer Client pointing to the Global Catalog can see the entire Unicenter NSM installation. The Unicenter Explorer Client running on your PC, for example, may be using a Global catalog on a server somewhere else. Your local browser can access any provider known to the Global Catalog. See the Unicenter Explorer Procedures (accessed through the Unicenter Explorer Help) for instructions on maintaining the Global Catalog. CA Reference in the Online Books program group provides a detailed description of the various commands available for maintaining the Global Catalog
14
Administrator Guide
Using Unicenter NSM, organizations can create software agents for devices that do not support standard management protocols such as SNMP. In fact, you can create agents to monitor a wide range of devices, such as IDNX switches, modem banks, video multiplexors, long-range radio transceivers, secure telephone transceivers, frame relay switches, and DoD encryption devices. Unicenter NSM empowers organizations to monitor and manage their entire networking infrastructure, not just typical TCP/IP networks, allowing non-IT devices to be instrumented for management. The robust management functions of Unicenter NSM span across traditionally discrete resources. The discovery services in Unicenter NSM, for example, discover systems, databases, and applications, in addition to network devices and topology. This complete inventory of IT resources allows administrators to manage from the perspective of the big picture. In addition to TCP/IP, management functions must support heterogeneous environments including SNA, DECnet, and IPX networks; Windows NT, UNIX/Linux, and proprietary servers; NCs, Windows desktops and mainframes; hierarchical, relational and object databases; diverse network devices; web servers from different vendors; and applications from many different companies. Unicenter NSM provides a solution that manages all of these resources in a cohesive, integrated manner. The ability to extend and customize integrated functions is central to the concept of end-to-end management in Unicenter NSM. For example, discovery agents are extensible to discover any custom IT resource (such as in-house built applications) or even non-IT resources such as POS devices, telephony, and even transportation systems. Scaleable Infrastructure Providing end-to-end coverage requires a highly scaleable infrastructure to efficiently manage the diverse scope of resources, which can range from hundreds to thousands across every major computing platform. The Unicenter NSM architecture makes it possible to develop and deploy both CA and non-CA management functions in a manner that best suits the enterprise and requirements of each individual IT organization. To address scalability requirements, Unicenter NSM provides efficient agent architecture for monitoring resources and invoking policy. Unicenter NSM can correlate information across disciplines, devices, and the enterprise as a whole, not only taking automatic actions but also anticipating problems. Recent advances in software agents, based on adaptive pattern recognition, extend conventional technology.
15
Predictive Agents
CAs U.S. Patented Neugents Technology Intelligent eBusiness Components
Neural networking agents known as Neugents enable Unicenter NSM to behave as a self-learning system. Neugents can recognize complex patterns in vast amounts of data, correlate seemingly unrelated events, predict business outcomes, and learn and adapt continuouslyeven when faced with dynamic business changes. Through Neugents, Unicenter NSM integrates advanced business intelligence logic into eBusiness infrastructure. Incorporating technologies from statistics and artificial intelligence, Neugents use pattern recognition to predict opportunities, detect problems, and offer solutions. The integration of learning agents with a cross enterprise framework is critical to the efficient management of huge, complex environments. Neugents are available as an option to Unicenter NSM.
Advanced Visualization Unicenter NSM uses visualization technology to turn massive amounts of data into useful and relevant information. The WorldView component of Unicenter NSM presents a 2D and 3D view of the infrastructure to facilitate intuitive management of the enterprise. Anyone familiar with Explorer-style and browser-based GUIs can move effortlessly through systems and networks, without special navigational skills or prior knowledge of physical topology. Organizations can use the interface that is most appropriate to their management requirements. For example, organizations that deploy the optional Neugents technology would probably prefer the 3D Map. The data visualization, animation and virtual reality capabilities of the 3D Map complement pattern recognition technology, and the underlying patterns detected in data, especially time sequences, are more easily depicted using an extra dimension. On the other hand, a network operator who is frequently on the road troubleshooting and opening new facilities may prefer a more conventional 2D view solely of network topology. Delivering an extensible architecture with predictive and self-learning capabilities is just the beginning. Unicenter NSM also delivers a wide range of rich management functions for administering various IT resources. The integration of all management functions allows you to leverage your existing investments in technologies, tools, data, and proven business logic.
16
Administrator Guide
Network Management Network managers struggle daily with the variety of devices supplied by different vendors, diverse communications protocols, and complex network topologies. The various platforms, communications protocols, application software, servers, mainframes, desktops, and databases that can be connected to a network are infinite. Unicenter NSM blends the management of network elements with system, database, and application assets to provide a comprehensive, integrated enterprise management infrastructure. The system treats network elements as part of a continuum of interrelated components with a full understanding of the dependencies between them. From a single, central console, Unicenter NSM can manage networks running every major protocol, automatically discover network elements using these protocols, and map their network topology. You can visualize the network as a discrete entity in relation to other enterprise assets or within the context of business processes. Unicenter NSM makes network management accessible to multiple audiences within the enterprise. Internet Management Web sites are quickly becoming the electronic front doors for many companies. The World Wide Web has created an entirely new class of electronic services and information. By extending its robust management functionality to web sites and across the Internet, Unicenter NSM allows enterprises to conduct business with confidence in cyberspace. E-commerce is possible only if web applications enjoy the same degree of security and control as provided for the databases and applications sitting on the other side of the firewall. Therefore, managing web assets is really no different than managing other critical enterprise resources. The architecture of Unicenter NSM allows IT departments to transparently encompass web-based (Internet, extranet or intranet) resources. An effective web presence requires professionally managed servers in terms of reliability, availability and performance, including:

Securing content from loss or corruption, whether intentional or not Eliminating network, systems, databases or applications choke points Providing automated, policy-based responses to common events such as usage spikes and virus attacks Planning for and positioning servers around the Internet to minimize traffic hops and application response time
17
User Interfaces
Administrative access to Unicenter NSM providers is available through the following user interfaces. Note: All customization that is described in the Administrator Guide and in other documentation applies to the Unicenter Classic GUI. Customization for the Unicenter Explorer is available only in tndbrowser.cfg. No customization is available for the Unicenter Browser interface. Unicenter Explorer Implemented in Java, Unicenter Explorer integrates and hosts all user interface components and plug-ins for complete management. You can run the Unicenter Explorer management console on various platforms in a heterogeneous environment. Unicenter Explorer includes standard menus, context menus, a left-hand pane for navigation and a right-hand pane for the display of information on objects selected in the left-hand pane, configurable caption titles, and a paper-look design. You can launch Unicenter Explorer through the Unicenter TND program group. UNIX/Linux users can run the uniexplorer script in $JI_SYSTEM/bin to access it. Procedures based on this GUI appear in the online help. Unicenter Browser The Unicenter Browser is an Internet- and intranet-based user interface that provides virtually all of the functionality found in the WorldView Classic user interface. Since it is a Java applet, it does not require client installation, which makes it accessible from virtually anywhere. Windows users can access it locally on the system where the Common Object Repository resides through Start, Programs, Unicenter TND, Unicenter Browser Interface. UNIX/Linux users can run the tngui script in $CAIGLBL0000/wv/scripts to access it. Remote systems can access it by entering a URL address on any Java-enabled web browser in the form:
http://wvserver/ubi/ubi.html
where wvserver is the name or IP address of the web server on which the server components reside. You can use many of the procedures for the WorldView Classic GUI, contained in CA Procedures located in the Online Books program group, with this interface. Note: You must install the Unicenter Browser from the Product Explorer before it appears in the Unicenter TND program group.
18
Administrator Guide
Unicenter NSM Infrastructure Solutions
Unicenter Classic Unicenter Classic refers to the traditional Windows-based user interface delivered with previous versions of Unicenter TNG. Unicenter Classic includes the WorldView and Enterprise Management program groups accessed through Start, Programs, Unicenter TND. Procedures based on Unicenter Classic GUI are contained in the online CA Procedures. Unicenter Classic also includes the cautil command line interface. WorldView Classic WorldView Classic refers to the traditional Windows-based user interface. WorldView Classic includes the WorldView program group accessed through Start, Programs, Unicenter TND. Procedures based on the WorldView Classic GUI are contained in CA Procedures located in the Online Books program group. WorldView Classic also includes the cautil command line interface.

From network discovery to scheduling, from multi-platform security to database agents, from Web-server management to workload balancing, from storage management to network performance, Unicenter NSM delivers the widest range of robust management functions. These functions offer rich management capabilities that leverage each other through their integration within the open, object-oriented architecture. Unicenter NSM comprises these primary components: Unicenter Explorer and GUI ComponentsProvides Discovery, 2D and 3D advanced visualization, historical time-based management, Business Process Views, Association Browser, additional browsing tools, and extensive reporting for complete management of all resources from a web browser. Agent TechnologyProvides the Unicenter NSM manager/agent architecture used to manage the resources in your IT enterprise. Agent Technology includes agents, their runtime environment, and various browsing tools. Performance ManagementProvides the tools needed to monitor, measure, and report on the usage and performance of your valuable resources. The graphical applications that allow you to view, analyze, report on, and manage data include Performance Trend, Performance Configuration, Performance Scope, and Chargeback.
19
Enterprise ManagementProvides a collection of management solutions associated with Event Management, Workload Management, Security Management, Tape Management, Report Management, and other functions. Brightstor ARCserve 2000 Backup Unicenter Edition is the Automated Storage Management (ASM) component that provides backup and restore solutions for Windows and UNIX/Linux platforms. Unicenter ReportsProvides predefined, ready-to-view reports. Easily customizable, this reporting facility incorporates complex queries to build sophisticated reports against all objects in the repository. ManagedPCDelivers images to any BIS-compliant machine that supports PXE (Preboot execution Environment). BIS (Boot Integrity Services) is an Intel initiative that secures images transferred to client computers. PXE is an Intel technology that allows administrators to perform management functions in the absence of the operating system. Software Development Kit (SDK)Supplies the APIs and other tools needed to develop and integrate applications into Unicenter NSM. API libraries are supplied for WorldView, Agent Technology, and Enterprise Management.
WorldView
Using WorldView, you can do the following:
Discover all the devices in your network using the CA Discovery service and automatically add them to the Common Object Repository as managed objects. Define new classes using the Class Wizard, allowing for characterization and modeling of practically anything. See your entire network graphically represented on 2D and 3D maps, grouped into networks, subnetworks, and segments based on their logical relationships. Create customized Business Process Views of specific processes based on different business needs, resource features, roles, geographical locations, organizational structures, and applications. Trace all events reported by network devices on the Event Console Log, isolate faults, and display them on the WorldView maps so action may be taken for resolution.
WorldView provides an extensive set of tools to enable you to customize any view of your enterprise according to its logical structure, from 2D and 3D maps for iconic views, to a selection of browsers for textual views.
110
Administrator Guide
End-to-End Management
End-to-end management is the ability to identify resources throughout your IT infrastructure and organize, monitor, and manage them. Typically, these resources are widely dispersed throughout the enterprise. Unicenter NSM uses object technology to automatically identify and define many resources in your IT infrastructure. Object Technology The number of individual resources in an IT infrastructure may range from small (hundreds) to large (millions). Unicenter NSM uses an object-oriented approach to the management of these resources by automatically defining them as managed objects and storing them in the Unicenter Common Object Repository. The Common Object Repository is used by all management functions to store information about managed objects, their properties, relationships, and the methods by which they are managed. Examples of managed objects are hardware devices, software applications, databases, and processes. Common Object Repository All of the objects in your enterprise, including network devices, agents, and software applications, are defined according to their Unicenter NSM class names, and are stored in the Unicenter NSM Common Object Repository (see Objects and Classes following). The Common Object Repository contains managed objects derived from many different classes, such as router, host, application, database, agent, and link. It also contains policies, methods, associations, and objects derived from non-managed object classes. Building the Common Object Repository with information about the resources in your enterprisealso called populating the repositoryis accomplished using the CA Discovery service. Objects and Classes Unicenter NSM uses two basic tools to manipulate data: objects and classes. Understanding this concept makes creating or modifying a class with Unicenter NSM much easier. Note: For detailed information about and examples of each of the Unicenter NSM predefined classes and Application Programming Interfaces (APIs), see the CA SDK Developer Guide.
111
Objects
Unicenter NSM focuses on easily defined units, which together with their status, are referred to as objects. Examples of objects include SQL servers and CD-ROMs. Unicenter NSM lets you manage these objects. A class is a collection of objects with the same characteristics and behavior. There are many types of classes. A special type of class is the virtual class. A virtual class is not used to create objects, but rather used to help you organize other classes. For example, the ManagedObject class is a virtual class. In Unicenter NSM, you can use the Class Wizard to simplify the creation of classes. Unicenter NSM provides classes for a variety of the most common entities found in heterogeneous environments. Each predefined class has all the characteristics defined and is ready to use.
Classes
Advanced Visualization Capability To fully appreciate this feature, you must see firsthand the exciting next generation of 2D and 3D technology. Using any data source, you can transport your entire infrastructure to a virtual reality plane that simulates real world environments and is both easy to use and to understand. The innovation of the Association Browser shows the dynamic container relationship and enterprise configuration through a wide array of views. This advanced browser allows you to traverse objects in your enterprise. Time Dimension Time dimension is achieved through the Historian technology of Unicenter NSM. Presented in a multidimensional format, Historian gives you unprecedented insight for the entire enterprise. This added intelligence increases service and efficiency thresholds.
112
Administrator Guide
Agent Technology
Unicenter NSM uses multi-level, manager/agent architecture. Agent Technology is critical to the management of large environments. Agents perform remote monitoring to report to the manager when error conditions occur or certain threshold values are reached. Agents may also act when instructed to do so by the manager, or they may correlate information and act by themselves. Unicenter NSM provides agents to monitor operating systems and databases. Using the Software Development Kit (SDK), you can also create agents for any device or process, as desired. Unicenter NSM is an open architecture into which you may add agents created by other software vendors. Important! Remember, if you want to implement an agent that is being supplied by a third party, you must have that agent certified by Computer Associates. An important feature offered by agents is their ability to instrument a resource so that specific information about that resource can be gathered. Put another way, resources are instrumented with agents so that they can be managed. For example, suppose you are interested in just a few specific values in a large database maintained by a manufacturing application. You may write an agent that monitors those values and advises you when the values reach or exceed specific criteria. You can create agents to instrument file systems, database applications, and other software applications. These agents significantly increase your ability to monitor and control such software processes. Node View You can use Node View to monitor the status of managed objects discovered by the Auto Discovery process. Managed resources on a node may include such entities as the operating system and its subsystems, databases, and software applications. Node View relies on the following:
SNMP agents that provide information about the state of the managed resources on the node The Distributed State Machine (DSM) that correlates state information from an agent into a format that Node View can display
113
Because Node View displays the managed objects on a node in tree format, you can see both the overall status of the node, and the logical relationship and status of individual agents and objects at the same time. Represented in the display are:

The node itself Agents installed and running on the node Subsystems or groups of resource objects for which an agent is responsible Individual resource objects monitored by an agent
Each Node View display includes an icon for PING, which represents the nodes ability to respond to an ICMP echo request. DSM View DSM View is a companion to Node View and provides detailed information about each managed object in the Distributed State Machines domain. You can use DSM View to create new properties for a managed object as well as modify the values of existing properties. Using the DSM View windows, you can:

Display managed objects based on the class to which they belong. Query the Object Store for managed objects. Edit the properties of a managed object.
MIB Browser The MIB Browser is a graphical user interface that can be used to view the values of MIB attributes. Using the MIB Browser, you can browse MIBs supported by SNMP agents running on any node connected to your Unicenter NSM workstation over a TCP/IP network, set the values of MIB attributes, and print MIB data. Individual Agent Views You use the individual agent views to drill down to the specific set of resources monitored by each Unicenter NSM agent. You can also use the controls provided by the views to add new resources for monitoring and to set the threshold values that determine the status of each of the monitored objects. Each agent view is unique and provides a set of detail windows that reflect the different sets of monitored agent resources, such as database tables or file systems.
114
Administrator Guide
Performance Management
Performance Management provides the following graphical applications used for visualization of performance and resource consumption data:

Performance Configuration Performance Scope Performance Trend Performance Chargeback
The Performance Management agents collect data from standard system utilities appropriate to the environment being managed. Using the tools provided, you may view this performance data in a context-sensitive fashion by pointing and clicking the managed objects on the Unicenter NSM WorldView Map.
Enterprise Management
Enterprise Management is a collection of integrated system management functions available through Unicenter NSM. Using Enterprise Management, you can manage your system resources and add policy-based automation, security, reliability, and integrity to your environment. This management can be accomplished in a centralized fashion, distributed throughout the network, or hybridized by combining different approaches to best match the unique structure of your organization. Further, each Enterprise Management workstation can be customized to reflect the needs of a particular administrator. For example, one workstation can manage backup and archiving of storage, while security workstations can be placed throughout the network, bringing user administration closer to each business unit. The following are just a few of the tasks you can perform with Enterprise Management:
Using Event Management, direct important messages to a centralized location and process them automatically, a task that would otherwise require manual intervention. Using Problem Management, effectively record, access, and track problems related to the system and end-user requirements. Using Workload Management, automate repetitive or calendar-based processing. Using File Management and Tape Management, perform backup and restore operations, and provide integrity and reliability of the information stored on external media.
115
Using Security Management, effectively secure your computing environment without disrupting valuable work time.
Policy-Based Management
Most successful organizations operate according to established policies. As the organization becomes more complex, it becomes necessary to formalize and document these policies. Unicenter NSM allows these policies to be enforced by the systems management functions available in Enterprise Management. Some examples of these types of policies are:

When and how different types of data are backed up Who has access to sensitive data Who can change sensitive data How often certain processes shall run What to do if they fail
Policies typically grow and change to adapt to new situations. The advantage to policy-based management is ease of implementation. Usually, these policies are reflected in Enterprise Management rules on a one-to-one basis. Therefore, new policies may be easily implemented.
116
Administrator Guide
Enterprise Management Functions Event Management is a status/exception management facility. Using Event Management, you can define policies that instruct Unicenter NSM to intercept selected messages requiring additional attention. By defining Event Management policies, you can:

Respond to the message. Suppress the message. Issue Unicenter NSM commands. Start other programs or scripts. Send information to a network management application. Forward the message to other managed platforms. Issue commands to be executed on other platforms. Define or update objects in the Unicenter NSM Common Object Repository. Administer the Unicenter NSM environment remotely using email and pager messages.
The CA Event Console lets you monitor system events across the network as they occur. All running programs and user processes can direct inquiries and informative messages to this facility. You can process messages on individual servers and redirect them to a central server or other Unicenter NSM Event Management servers and, by extension, their consoles. You can collect related messages network-wide for display at a single location, or send them to multiple locations, as needed. Additionally, you can use Security Management options to restrict Console Log views to only authorized personnel. Event Management can be used to automate tasks that would otherwise require manual intervention. For example, Event Management can forward exceptions requiring intervention to the Help Desk function, which then opens a problem ticket and assigns it to the appropriate person for resolution. Event Managements Wireless Messaging component furnishes email and pager channels for operator input when the operator may be unable to access a Unicenter NSM console. Messages can be sent to and received from two-way pager devices. The Event Management suite of functions includes Unicenter Virus Scan. This utility automatically scans the local drive daily at midnight. Parameters can be set to customize the type of scan, the drive to be scanned, and the actions to be taken upon virus detection.
117
Workload Management provides an effective tool for planning, organizing, and controlling your entire production workload. Workload Management allows you to automate background processing for execution during non-peak hours or according to pre-set schedules, dependencies on other jobs, calendar definitions, or a combination of these. Using Workload Management, you can:

Define and maintain jobs. View a list of related jobs. Identify predecessor jobs, files, and manual tasks. Schedule jobs with calendars and triggers. Display job status. Cancel or demand jobs.
Additionally, Unicenter NSM Security Management can be integrated to provide authority for each job, and to prevent unauthorized access to these facilities. From its Jobflow component, Workload Management provides an online, graphical representation of your enterprises workload. You may view relationships among jobs defined in the scheduling database, and monitor the status of jobs in real time. Using the GUI, you can tailor your view of the workload. You can limit the number of jobs by job name, time span, and number of successor levels, and display the results as either a Gantt or a Pert chart. You can zoom in on a single jobs successors and triggers, or zoom out for a larger perspective. Tape Management provides comprehensive, yet easy to use tools to perform tasks associated with maintaining your tape library. These tasks include the following:
View lists of files, volumes, and storage vaults/areas so you can update or perform actions based on the information. Change the expiration date of a volume. Check a volume out to an out-of-area storage vault, or check a volume in that was previously out-of-area. Print an external label for a volume by selecting either the volume serial number or the data set name. Update the cleaning statistics. Display the status and service description of a volume (in service, deleted, expired, scratch). View lists of tape devices based on esoteric group or generic unit group name for which you want to receive detailed information.
118
Administrator Guide
Monitor tape device status to determine whether the device is online or offline. Monitor the movement of tape volumes through the Vault Management system. Place ANSI standard labels on tape volumes. Protect against tape data destruction by malicious or accidental overwrites. Maintain automatic tape file inventories. Facilitate swift retrieval of the appropriate tape volume when a file is needed. Provide for automatic recognition of mounted tape volumes and assignment of those devices to requesting applications.
Many installations require some type of facility for the storage of tape volumes containing critical files. Examples of such storage facilities include a fireproof vault or an off-site storage location. Working with Tape Management, Vault Management supports:

Vault creation Media selection Automated media movement Manual media movement Movement and inventory tracking Audit trails
Once implemented, Vault Management furnishes the means to automate the off-site storage and retrieval of your critical tape data sets. Storage Management comprises Brightstor ARCserve 2000 Backup Unicenter Edition. Brightstor ARCserve Backup is the backup and restore management solution for a local Windows or UNIX/Linux host server. Brightstor ARCserve Backup furnishes the following features:
The Job Status manager informs you of job activity and assists in controlling a specific Brightstor ARCserve Backup job. Various options let you optimize basic functions, such as backing up specific files or scheduling a jobs performance. The Device Manager manages the devices and media needed to run Brightstor ARCserve Backup efficiently. Brightstor ARCserve Backup enables you to optimize the use of your media, and designate a scheduled backup scheme to coordinate with specific requirements in your environment.
119
The server component monitors the Job, Tape, and Database engines of Brightstor ARCserve Backup, displaying the status of each. The Alert manager reports on the status, results, and activities of Brightstor ARCserve Backup. Brightstor ARCserve Backup recognizes ASM tapes and prevents the tapes from being overwritten.
Security Management protects valuable system resources. Using Security Management, you can identify authorized users and the conditions under which they may enter the system and access designated assets. By defining policies for Security Management, you can:
Prevent unauthorized individuals from gaining access (logging on) to your system. Ensure that only authorized personnel can access system data, resources, and other assets. Protect against access abuse by users with administrative privileges. Provide a way to audit the use of data and resources.
Securable assets may include physical resources, such as programs and files, and abstract resources, such as administrative privileges, and other user-definable assets, as well. An optional feature, User Profile Synchronization (UPS), permits Windows, UNIX/Linux, OS/390, and z/OS nodes to participate in the sharing of password and status updates to user accounts. For OS/390,and z/OS nodes, UPS interfaces with the Command Propagation Facility (CPF) for communication with eTrust CA-ACF2 Security for z/OS and OS/390, eTrust CA-Top Secret Security for z/OS amd OS/390, and IBMs RACF for user profile updates. Security Management also provides the ability to interface with Distributed Computing Environment (DCE) technologies for synchronizing user credentials. The support of UPS with other z/OS and OS/390 security products assumes that eTrust CA-ACF2, eTrust CA-Top Secret, or RACF is installed on the z/OS or OS/390 mainframe under separate license. If you want to use UPS to interface with DCE synchronization services, those services must be installed in the client environment under separate license, with necessary DCE client components installed on the Windows server where Unicenter NSM is operational. Problem Management automates the definition, tracking, and resolution of problems. It provides a framework for accurate management of day-to-day problems and questions.
120
Administrator Guide
You can continuously improve the reliability of your computing environment by accurately identifying the cause of a problem and relating it to a specific hardware, software, or procedural source. Additionally, you can significantly reduce the time needed to correct problems by assigning ownership and tracking the progress of the resolution, and by automatically escalating a problem until it is resolved. Further, as it is integrated with the other Unicenter NSM functions, Problem Management can identify problems and potential problems automatically. Report Management extends traditional report/print processes by enabling you to define rules under which selected pages of a report can be repackaged into bundles and redistributed to designated users using print or electronic mail facilities. Report Management also tracks report delivery so that the system administrator can monitor the service provided to users. Spool Management furnishes a simplified interface to the UNIX/Linux spooler lp (or AIX enq) to enable users to access and manage spooled files, and to provide the systems administrator with a graphical interface to spool functions. Print devices are usually defined once and updated only when a new printer is added to the system. When you need to add a new printer, you probably spend an excessive amount of time just looking up the commands and syntax you need to make the update. Spool Management simplifies this process and expedites the overall task. Using Spool Management, you can:

Define, add, and update print devices. Manipulate the printer queues.
ManagedPC
The ManagedPC feature of Unicenter NSM lets you effectively administer your PC workstations. ManagedPC provides the following solutions:
Automatically detects ManagedPC operating system installation requests, and provides facilities to customize those requests. Furnishes remote installation services for a Windows operating system. During the Discovery process, automatically inventories all ManagedPCs in the Common Object Repository. Secures images transferred to client computers using Intels Boot Integrity Services (BIS) for those clients that support it.
121
Through the Unicenter WorldView GUI, offers you methods needed to monitor the status of your ManagedPCs. Includes facilities in the Unicenter WorldView interface that can awaken a ManagedPC from a soft off or sleep mode. Furnishes reports that are specifically customized for your ManagedPC administrative personnel.
Appendix A of this guide describes how to incorporate Unicenter NSM with any original equipment manufacturers (OEMs) packaging to support your managed PCs.
The Software Development Kit

The CA Software Development Kit (CA SDK) lets you take advantage of the capabilities of Unicenter NSM in your own applications. The Application Programming Interfaces (APIs) provided allow access to the WorldView, Agent Technology, and Enterprise Management components of Unicenter NSM. The CA SDK includes three API sets representing the major components of Unicenter NSM. WorldView APIIncludes functions and exits that enable user-written programs to interact with Unicenter NSM, the WorldView maps, and the Common Object Repository. Agent Technology APILets you create multi-platform, scaleable manager/agent applications. The Agent Technology API library provides an environment in which you may develop agents that communicate with management applications using SNMP. Enterprise Management APIFurnishes access to all of the management functions and common services supplied in Unicenter NSM, and facilitates cross-application integration. The Enterprise Management API library includes functions and exits that enable user-written programs to interact directly with Enterprise Management.
122
Administrator Guide
Documentation Road Map
Getting Help
Each Unicenter NSM GUI window and error dialog has either a Help command button or Help menu bar selection. The following types of help are available to assist you:
Help Topics access the table of contents for the current Help system, including the Contents, Index, and Find tabs. On Window provides information about the active window or dialog. About Unicenter describes what version of Unicenter NSM you are running. Context-Sensitive (F1) displays helpful information about the currently active window, dialog, or field.

Types of Documentation
The Unicenter NSM documentation set consists of a printed Getting Started guide, PDF (Portable Document Format) files, JavaHelp files (.JAR), and Windows Help files (.HLP). The last CD in the Unicenter NSM CD set contains the guides in PDF format. Note: The PDF files are independent of platform and operating system, and are viewable in the Adobe Acrobat Reader in Windows and UNIX/Linux environments. To download the appropriate version of the Adobe Acrobat Reader from Adobes Web site, go to http://www.adobe.com. Printed Documentation
Getting Started
PDF Files

Administrator Guide Business Process View Management User Guide CA SDK Developer Guide Getting Started Management Data Integrator User Guide
123
Release Summary Remote Monitoring User Guide Using the DB2 Agent Using the DCE Agents Using the Informfix Database Agent Using the Ingres Agent Using the Log Agent Using the Oracle Agent Using the Performance Agent Using the SQL Server Agent Using the Sybase Agent Using the Unicenter NSM WMI Agent Using the UNIX Process Agent Using the UNIX System Agent Using the Windows 2000 System Agent Using the Windows NT4 System Agent Working with Agents
Unicenter Explorer Help (.JAR Files)

Unicenter Explorer Help Unicenter Explorer Procedures
Java Book Viewer (.JAR Files) Only the following books are available on UNIX/Linux:

CA Reference CA SDK Reference
To launch the Java Book Viewer, click the cabook shortcut, or enter cabook at a command prompt. The Java Book Viewer appears with the CA Reference displayed. To switch to the CA SDK Reference, choose File, CA SDK Reference from the menu bar.
124
Administrator Guide
Unicenter TND Books Online Program Group (.HLP Files)

CA Glossary CA Messages CA Procedures CA Reference CA SDK Reference
Notational Conventions The majority of the information provided in this guide applies generically to both the Windows and UNIX/Linux platforms. However, when information is specific to one of these, the appropriate platform identifier, as shown following, accompanies it. This image is associated with information that is specific only to the Microsoft Windows operating system. The term Windows refers to the Microsoft Windows operating system, including Windows NT and Windows 2000. Unless specifically designated, Windows refers to any Microsoft Windows operating system supported by Unicenter NSM. This image is associated with information that is specific only to UNIX/Linux platforms. The small shaded box ( ) designates the end of the platform-specific information.
125
Chapter
Advanced Visualization
Unicenter WorldView offers a highly visual and naturally intuitive approach to enterprise management with the 2D and 3D Maps available through the Unicenter Explorer and WorldView GUIs. The maps work as an infrastructure navigator, allowing you to view any part of your enterprise with the click of a button. For example, you can view all assets in your networkfrom the global network to the local subnets, hubs, bridges links, the servers and workstations connected to them, their processors and drives, right down to the databases, and applications. WorldView includes Auto Discovery and IPX Discovery to detect networked objects, resources, and agents in your IT infrastructure, as well as the relationships among these. The objects discovered are stored in the Common Object Repository and are used by Unicenter NSM to monitor and manage your enterprise. Unicenter NSM provides an extensive set of tools that can be used to customize the maps to represent any type of entity, whether network related or not, in an arrangement that best addresses your enterprise management needs. Moreover, the arrangement of objects, or view, that you create can be saved separately. For example, a customized Business Process View could be prepared for every major department in a large company located in several states. The manufacturing department may have a view showing the servers and segments in various factories and warehouses. Still another view may show the objects responsible for maintaining certain ledgers in the accounting department. Unicenter NSM provides built-in geographic maps you can use for backgrounds. Additionally, you can import images such as floor layouts to your views in order to see at a glance exactly where a device resides or a problem has occurred. WorldView provides support for the Desktop Management Interface (DMI) specification. This feature lets you manage the installed hardware and software on your PCs. This can be accomplished locally, as well as remotely across your network.
21
Discover the IT Infrastructure

Auto Discovery automatically detects and identifies workstations, including ManagedPCs, AS400, and OpenVMS machines, routers, systems, databases, applications, network devices, and the relationships among them. Then it populates the Common Object Repository with objects representing these devices. Auto Discovery also can determine if a device provides Web-Based Enterprise Management (WBEM) data, and if so, create a WBEM object in the devices Unispace. Once defined, these objects and their Management Information Base (MIB) can be viewed, monitored, and managed through the 2D and 3D Maps, ObjectView and the Topology Browser. The entities they represent can be managed by Event Management, by Manager/Agent Technology, and by third-party manager applications. The various methods of navigating and administering your enterprise network are discussed later in this chapter. Using Auto Discovery, you can do the following:

Specify the types of resources to be discovered. Discover all resources in the infrastructure or just those belonging to a subnet. Specify community names with a wildcarded IP address so that Discovery only attempts appropriate community names for each device. See Multiple SNMP Community Name Support for information. Locate multi-homed devices. Run multiple instances of Auto Discovery simultaneously. Start Auto Discovery automatically or manually. Automatically retain a history of Discovery activity using Discovery History.
Auto Discovery discovers IP and IPX devices and SAN fabric elements; therefore, Auto Discovery provides network configuration management by discovering the complete networking environment of your organization, not just isolated elements. Running Auto Discovery is the first step in implementing WorldView following installation.
22
Administrator Guide
The following two phases exist for the Discovery process:
Phase 1Auto Discovery locates network entities in your IT infrastructure, such as servers, workstations, and routers. In addition, it has the ability to initiate SAN Discovery, which locates SAN fabric devices (fibre-enabled switches, bridges, and hubs), hosts and SCSI devices connected to the SAN fabric. It also creates Business Process Views in the WorldView map of the SAN fabric and the links between the objects. IPX Discovery locates Novell NetWare servers and network segments that use the IPX protocol and populates the Common Object Repository with objects representing the NetWare servers and their associated segments.
Phase 2Agent Technology WorldView Gateway service locates Unicenter NSM agents running on the network objects discovered in Phase 1.
All of the objects discovered in Phase 1 and Phase 2 are used to populate the Common Object Repository. Once their descriptions and relationships are stored in the repository, objects can then be used for display on the 2D and 3D Maps and referenced by the components of Unicenter NSM.
Creating the Common Object Repository

You probably created the Common Object Repository during your installation of the WorldView component of Unicenter NSM. The Common Object Repository is a database of formalized information about managed entities, their properties and relationships. The Common Object Repository is populated with the object descriptions collected by the Auto Discovery processes. If you chose not to build the Common Object Repository during WorldView installation, use the Create Repository application (click Start, Programs, Unicenter TND, WorldView, Create Repository) when you are ready to build a repository on a Windows machine. (Currently, you cannot create a repository on a remote UNIX/Linux machine.) A repository must exist before you can proceed with discovering your network devices. You can also use the Create Repository application to rebuild an already existing repository. Note: You can also use the maketng command from a command line prompt to start the Create Repository application. See the online CA Reference for detailed information about the maketng command. See the instructions for creating and working with the Common Object Repository in the online CA Procedures under the following topics:

Building the Common Object Repository Rebuilding the Common Object Repository Removing the Common Object Repository
23
Establishing the Common Object Repository Size Setting Common Object Repository Troubleshooting
Repository Bridging The Unicenter Repository Bridge lets you replicate and maintain (or bridge) a subset of the managed objects in a source repository to a destination repository. The objects that are bridged are determined by a set of rules you define, known collectively as Bridging Policy. Once activated, a Bridge Instance bridges all objects in the source repository that comply with the Bridging Policy, and then continues to monitor the source repository for the following:
State changes in bridged objects, updating the destination repository with those changes or removing a bridged object if the state change means it no longer conforms to the Bridging Policy State changes in non-bridged objects, bridging an object if a state change means that it now conforms to the Bridging Policy
By using a number of Repository Bridges in parallel, a single source repository can be bridged to many destination repositories; or, more usefully, many source repositories can be bridged to a single central destination repository. A many-toone bridge configuration gives you central monitoring of significant objects within a distributed enterprise environment. For a complete discussion of bridging repositories including installation, bridge architectures, configuration and implementation, see the appendix Repository Bridging in this guide. Dynamic Repository Updates Dynamic Host Configuration Protocol (DHCP) Synchronization In addition to the Discovery process described in Phase 1 - Discovering and Classifying Network Devices, there is a service that monitors DHCP traffic on the network and dynamically updates the Common Object Repository. Upon discovery of a DHCP session, the DHCP Synchronization service will run Single IP Discovery, which discovers a given node (device) based on its IP address or hostname. The device is then added/updated to the repository in the proper subnet. By default, the DHCP Synchronization service is not installed and the service is not displayed in the Auto Discovery Distributed Services window. The service should be installed or activated only once per segment. Install the DHCP Synchronization service on each segment that is being configured by a DHCP server (this should not be the DHCP server itself) by running the following command:
syncdhcp.exe -install repository_name
24
Administrator Guide
Once installed, the service appears in the Auto Discovery Distributed Services window and can be started or stopped. The service is set to manual by default. By selecting the DHCP Synchronization service in the Distributed Services window and clicking Setup, you can set the service to start automatically or you can disable it. To adjust the repository name, remove the service and reinstall it with a new repository name. To remove the DHCP Synchronization service, run the following command:
syncdhcp.exe -remove
See the instructions for running a single IP discovery in the online CA Procedures under the topic, Discovering a Single Machine. Note: The WorldView base components must be installed prior to installing the DHCP Synchronization service.
Phase 1: Discovering and Classifying Network Devices

Auto Discovery locates network devices using the facilities provided by TCP/IP and SNMP and then populates the Common Object Repository with object descriptions and relationships based on the information in the devices SNMP Management Information Base (MIB). SNMP MIB agents typically are resident in network device firmware and are provided by each devices vendor. For more information about MIBs, see the section Whats a MIB? in the chapter Event Management of this guide. Note: This discussion assumes a basic familiarity with TCP/IP network and SNMP principles and the concept of router connectivity. Auto Discovery uses router connectivity information to establish a networks logical connectivity. A TCP/IP network is divided into subnets that are interconnected through routers. The discovery process automatically locates and identifies all the routers in the network.
Auto Discovery Methods
Auto Discovery provides the following operating methods for discovery:
Ping SweepThe Ping Sweep method pings all the devices on the network based on the subnet mask, finds IP devices, and then retrieves SNMP information. If no SNMP information is retrieved, just the IP address is retrieved and the object is created as an Unclassified_TCP device. ARP CacheThe ARP (Address Resolution Protocol) Cache method starts at the gateway address of the router nearest to the Unicenter NSM machine running Auto Discovery and uses the gateways ARP Cache to determine information about the devices.
25
Auto Discovery retrieves the gateway address from the machine on which it is running (the machine on which Unicenter NSM is installed) and gets the IP list from the ARP Cache on that router. It then discovers the subnets nearest that router and for each subnet it discovers, queries its gateway, doing the same thing over and over again. For each device found in the ARP Cache, an SNMP request is initiated. If the device does not respond, it is assumed to be a non-SNMP device, just the IP address is retrieved and the object is created as an Unclassified_TCP device.
Fast ARPThe Fast ARP method saves time by only checking the ARP Cache of routers. Fast ARP is the best method for updating the Common Object Repository when you do not want to use the more intensive searches provided by Ping Sweep and ARP Cache. DNS (Domain Name Server) SearchThe DNS Search method limits the discovery of devices to those that are defined in the Domain Name Server. The IP address of each of these devices is combined with the defined subnet mask to determine whether or not to discover the object. (In contrast, the Ping Sweep option would try to discover all active devices numerically, without regard to their definition in the DNS).
Each Auto Discovery method has advantages and disadvantages. The Ping Sweep method provides more comprehensive quantitative informationin the form of the number of devicesbecause every device on the network is pinged. Even devices not recognized by the router, which may not be discovered through the ARP Cache method, can be discovered using Ping Sweep. Ping Sweep, however, generates additional network traffic and is more time consuming than ARP Cache.
Tip: Discovering devices throughout the network can be time-consuming. To minimize the time required to perform discovery, we recommend using one of these techniques:

Use the Fast ARP method Use the DNS Search method Run Auto Discovery on only a few subnets at a time Start with the default community name, public Run multiple copies of Auto Discovery simultaneously
(Running multiple discovery engines only works if you are discovering many subnets, since only one discovery engine can work on a given subnet at a time.)
26
Administrator Guide
Starting Auto Discovery To run a discovery session, select Tools from the left pane dropdown menu, expand your machine name, and choose Discovery Wizard. The Discovery Wizard starts in the right pane. Click the forward arrow to proceed through the pages of the wizard. To start the discovery process, click the Start Discovery arrow. Note: The Discovery Wizard is self-documented and easy to use. We highly recommend that you use the wizard. If you are already familiar with network discovery concepts and want to interact with the Unicenter NSM discovery process at a detailed technical level, choose Advanced Discovery to view the detail pages where you can make specific entries that will determine limits for your discovery. See the instructions for running Auto Discovery in the online CA Procedures under the topic, Advanced Discovery. Multiple SNMP Community Name Support To speed up the discovery process, Unicenter NSM supports multiple SNMP community names. When adding a new community name, you are required to enter a filter definition that limits the number of devices tested with the new community name. Your filter definition consists of an IP address (if the new community name is to be limited to a single device), or a wildcard IP address. The wildcard IP address will limit the discovery process to a subnet, or group of subnets. For example, the wild card filter definition 172.224.111.* limits the discovery process to all devices that begin with 172.224.111. The Community Name field is found in the SNMP Page of the Discovery Wizard. Multi-Homed Device Support Unicenter NSM also provides proper management and discovery of multihomed devices. If a device has more than one physical interface to one or more networks, it is known as a multi-homed device. When a multi-homed device is discovered, only one instance of the object is created in the Common Object Repository. However, objects representing each of the device's IP addresses are displayed on the 2D and 3D Maps, and the Topology Browser.
27
Mobile Device Support Mobile devices are added to the repository automatically when they connect to the network, whether the connection is wireless or through a conventional LAN. The status of the device displays in the 2D and 3D Maps as ONLINE, OFFLINE, WARNING, or CRITICAL. Taking the device off the network puts the object in OFFLINE status, or optionally, removes the object from the repository. All mobile devices become objects in a Mobile Devices Business Process View. A lightweight agent on the mobile device measures mobile device metrics (such as battery life). The metrics can be viewed from the Unicenter Explorer. Configurable alerts are generated when metrics reach a critical status. See the instructions for discovering devices in your network in the online CA Procedures under the following topics:

Discovering a Single Machine Discovering a Single Network Discovering an Entire Intranet Discovering a Subnet Scheduling Auto Discovery Runs Note: You can integrate Auto Discovery with Workload Management to ensure that you have regularly scheduled discovery runs that will have minimal impact on your production environment.
28
Administrator Guide
Monitoring Auto Discovery The Discovery Monitor provides a visual display that tracks the progress of Auto Discovery. To view the Discovery Monitor, select Tools from the left pane drop-down menu, expand Tools Root, and choose Discovery Monitor. The monitor will also run automatically when you click the Start Discovery arrow in the Discovery Wizard.
The Discovery Monitor is updated every five seconds. Discovery History Information regarding the Discovery process and devices discovered is retained in the Discovery History Log. This log contains such information as each objects UUID, name, IP address, type, timestamp, and operation type. It also contains records for the start and stop times for each Discovery process that has taken place. View the Discovery History Log in the Object Browser (from Start Programs Unicenter TND, choose WorldView Object Browser). Simply click History under the TNGRoot class and the log will be displayed in the right pane. To view the log, click the plus sign to expand the TNGRoot class and highlight History. The log is displayed in the right pane.
29
Note: In WorldView Classic, the Discovery Wizard Advanced Setup Repository tab also displays Discovery History objects. Deleting Discovery History Records You can delete Discovery History records in the Discovery Wizard Advanced Setup dialog on the Repository tab. Simply highlight the record you want to delete and click Remove. Note: In WorldView Classic, the Remove button appears only when you highlight a History record. Classifying Devices
Class Characteristics
When a class is created, certain characteristics are defined that determine the state and behavior of its objects. The two major kinds of characteristics are methods and properties. Methods determine the behavior exhibited by an object. For example, a method for Unicenter NSM maps may specify that objects include a function that launches an executable file. Properties determine the state of the object created from a class. For example, a property for Unicenter NSM maps may specify that an object use red as the background color for the icon. Properties of an object are values determining the uniqueness of an object of a particular class. For instance, the IP address of an object is different for each object. Properties for a class are defined at the following two levels:
Class-leveldetermines the state and behavior of objects derived from the class. The value of a class-level property is the same for all objects derived from the class and may be modified (for example, the image of an object of this class). Instance-leveldefines the attributes and relationships for a particular object. Instance-level properties are unique for each object and may be modified (for example, the label of the object).
For additional information on objects and classes, see Object Oriented Programming Basics in the online Help for the Class Wizard (from Start Programs Unicenter TND, choose WorldView Class Wizard). Also see the CA SDK Developer Guide.
Class Relationships
Classes relate to each other using inheritance and hierarchy.
210
Administrator Guide
Class inheritance allows a subclass to inherit characteristics from the class above it in the hierarchical tree; that is, its superclass. For example, in superclass A, all objects have the properties of being a binary data type and having a red icon. You can create a subclass of A, called subclass B, that contains objects with the properties of being a binary data type, having a red icon, and identical creation dates. The subclass B inherited the characteristics of a binary data type and red icon from the superclass. Unicenter NSM enforces the following inheritance rules:
Class-levelThe definition of a subclass can overwrite the class-level property value inherited from its superclass, but not its data type and length. Instance-levelThe definition of a subclass can overwrite a superclass instance-level property default value but not its data type, length, required flag, and key flag.
Once an object is created, the type and value of its properties remain fixed even if the default values of the properties of the class from which it was derived are changed. If a property is added to the class, all of the objects will have that property with a NULL value. Class hierarchy is a relationship between classes. Classes can be structured to have a single root class that contains the most general characteristics common to all the subclasses below it. Class hierarchy dictates inheritance. Note: You can find specific information about the Unicenter NSM implementation of object-oriented programming principles, the class structure, and predefined classes in the CA SDK Developer Guide. Understanding these foundations will make creating or modifying classes much easier.
Classified, Unclassified, and Conflict Objects
As Auto Discovery locates each valid device, it compares information about the device to the list of subclasses that are defined as objects of the ManagedObject class in the Common Object Repository. If a matching class is found, an object of that class is created using the MIB information (sysobjid) that Auto Discovery found for the device. These objects are considered classified. If a matching class cannot be found, Auto Discovery is unable to categorize this device and an object representing this device is created under the generic class Unclassified. Objects of this type are considered unclassified.
Classified objects have an SNMP-compliant MIB agent and a matching Unicenter NSM class definition. By default, all classified objects are visible on the 2D and 3D Maps. An example of a classified object is a UNIX/Linux workstation. Unclassified objects can be non-SNMP devices, or can simply be a device model that has no corresponding Unicenter NSM class. Conflict objects can have IP, MAC address, or name conflicts.
211
Note: The instance-level property Hidden controls whether an object is visible on the 2D and 3D Maps. For more information on how to set instance-level properties for an object, see the online Help for the Property Notebook, which is accessed through the Topology view. To make a hidden object visible, you can go to the Class Specification navigational tree in the left hand pane, Instances in the right hand pane, and right click to choose Views/Property Notebook. Change the Hidden property from True to False.
Discovery Reclassification
You can define criteria by which discovered objects are reclassified during the discovery process. By adding reclassification definitions in the reclass.dat file located in the \NSM\script folder, you can assign newly discovered objects to other, more appropriate classes. During installation, this file is named reclass.dat_sample. Once you rename the file to reclass.dat, any reclassification entries are applied during subsequent Auto Discovery sessions. A reclassification definition uses the following format: Format [RECLASSIFY DEFINITION 1] Description Each entry must have a title, and this title must use the naming convention [RECLASSIFY DEFINITION X] where X = 1 for the first definition, and the next consecutive integer for subsequent definitions. This is the name of the class to which you want to apply this definition; for example, Windows2000_Server. This class must be defined in the repository This is the name of the class to which you want to reclassify the object; for example, OpenVMS. This class must be defined in the repository SNMP community name. Using a name provides a level of security during TCP/IP communication This is the port number that the SNMP service is running on. The standard SNMP port is 161.
OLDCLASSNAME=old_class
NEWCLASSNAME=new_class
COMMUNITYSTRING=public
PORTNUMBER=161
212
Administrator Guide
Format OID=1.3.6.1.2.1.1.5 VALUE=computer1
Description *SNMP Object Identifier for the value you would like to reclassify based on. *The value you would like to reclassify based on.
* You can choose any OID/Value pair to reclassify on. The following example will reclassify the windows2000_server machine named computer1 as an OpenVMS machine.
[RECLASSIFY DEFINITION 1] OLDCLASSNAME=Windows2000_Server NEWCLASSNAME=OpenVMS COMMUNITYSTRING=public PORTNUMBER=161 OID=1.3.6.1.2.1.1.5 VALUE=computer1
Reclassifying Unclassified Objects You can reclassify unclassified objects found during Auto Discovery by using the Reclassify Object dialog to assign objects to another, more appropriate class. The easiest way to access this dialog is through the Unicenter Explorer Topology view. Expand ManagedObjectRoot in the tree in the left pane, right-click the object you want to reclassify and choose Reclassify from the popup menu. Note: You can access the Reclassify Object dialog through an MS DOS command line prompt also. For information, see the UNCLASS command in the online CA Reference. See the instructions for reclassifying an unclassified object in the online CA Procedures under the topic, Reclassifying Unclassified Objects. Starting IPX Discovery IPX Discovery searches for Novell NetWare servers and network segments that use the IPX protocol. Objects representing the NetWare servers and their associated segments are stored in the Common Object Repository. The objects are displayed on the 2D and 3D Maps under the IPX Network icon.
213
For each server the discovery process finds, an IPX_Host object is created and stored in the Common Object Repository. The physical MAC address and its segment from the primary physical interface identify the server. In addition, the server has the following properties: a server name, an IPX/SPX version, a virtual MAC address, and a virtual segment address. The virtual information is retrieved from the first virtual IPX interface in the server. Each server object is included in a segment object. The segment object name refers to the segment of the first nonvirtual interface found in the server. Each server can then have one or more physical interfaces (IPX_Generic_Interface). Each physical interface entry in the IPX_Generic_Interface class has properties pertaining to the LAN card itself. The IPX_Generic_Interface properties are as follows:
MAC Address and segment; both of which are physical. LAN cards do not have virtual segments or MAC addresses. These are found only on the server. IRQ and DMA channels for the interface. A text description by the manufacturer.
If IPX Discovery finds a NetWare server already in the Common Object Repository, it ignores it and moves on to the next server with no interruption. If an existing server is found with new interfaces installed that were not previously discovered, the new interfaces are added to the Common Object Repository. IPX Discovery can run concurrently with Auto Discovery, which uses SNMP and TCP/IP protocols. When Auto Discovery and IPX Discovery find two or more objects with matching MAC addresses and different interface types, a Multi_Protocol_Host object can be created from them using the utility Multi_if. Use Multi_if after running Auto Discovery and IPX Discovery to create relationships between two servers with different protocols that share the same MAC address. Run IPX Discovery from Start, Programs, Unicenter TND, WorldView Auto Discovery. See the instructions for running IPX discoveries in the online CA Procedures under the topic, Starting IPX Discovery. Starting SAN Discovery SAN Discovery runs as a part of the Auto Discovery service and writes informational as well as error messages to the Windows Event Log. SAN Discovery launches automatically during the Unicenter NSM install, or you can launch it manually from the Distributed Services GUI as part of the Auto discovery Service.
214
Administrator Guide
You can change default run time parameters by clicking Advanced in the Discovery Wizard and reviewing the SAN page, or you can pass parameters to the service on the command line. (Command line arguments are not saved as defaults and only apply to the current execution of the service.) You can change default CA SAN Proxy timeout and retry values, as well as the discovery method. SAN Discovery requires prior discovery of SAN objects by Auto Discovery. It uses SNMP to gather additional information from those SAN objects. If no SAN objects exist on your network, the SAN Discovery ends quickly and logs a message stating that there were either no SAN fabric elements (SAN objects) found, or that no SAN fabric exists, and there is nothing more for SAN Discovery to do. SAN fabric elements are those in classes designated as SAN classes. SAN classes are defined as subclasses of Switch, Bridge, or Hub classes. New SAN classes can be added easily using the Unicenter Class Wizard. SAN classes require one additional class level property (CLP): SAN, Boolean datatype set to TRUE. SAN Discovery interrogates all discovered hosts and servers for the presence of the CA SAN Proxy (the CA SAN Proxy must be installed on every host attached to a SAN). CA SAN Proxy determines the WWN of the HBA card in the server and discovers SCSI devices attached to the SAN fabric. CA SAN Proxy then reports this information to the SAN Discovery service. SAN Discovery includes the server information and all connected devices in its view of the SAN fabric. If any SAN components are discovered, the SAN Discovery creates a SAN Business Process View (BPV). Under this Business Process View, there will be a set of folder objects containing SAN fabrics, SAN collections (containing one or more linked fabrics), SAN-enabled devices grouped by device type, SAN devices discovered by SAN discovery (as opposed to discovered by IP discovery), SAN devices which have no SAN links, and an Enterprise SAN object containing all linked SAN devices. The SAN fabric object's label name is based on the Fabric Id of the principal SAN switch. All objects in the Business Process Viewfabric elements, servers, and SCSI devices connected directly or indirectly to each othershare the same fabric id. See the instructions for setting SAN discovery options in the online CA Procedures under the topic, Running SAN Discovery.
215
Visualize Your Network Infrastructure
Phase 2: Discovering Agents and Agent Objects

Phase 2 of discovering your IT infrastructure occurs after you have installed Unicenter Agent Technology and started the Agent Technology services. The post-installation tasks for Agent Technology provide details for starting the Agent Technology services.
Tip: After you have installed Agent Technology and started the Gateway services, close and restart your WorldView session so that the Distributed State Machine Gateway can get information about the nodes that WorldView has discovered. When you restart one of the WorldView maps, you will see managed objects for all of the agents and agent objects that have been discovered.

WorldView provides maps, various utilities, browsing tools, and functionality that let you view and navigate your enterprise. The 2D and 3D Maps work as an infrastructure navigator to let you view any part of your enterprise from any point at any time with the click of a button. The advanced visualization features of Unicenter NSM introduce the Association Browser to let you identify eBusiness resources and the relationships between them. The 2D Map offers smooth navigation by letting you easily pan and zoom throughout your enterprise.
216
Administrator Guide
The Unicenter Explorer Window

The Unicenter Explorer is the primary interface for managing your entire enterprise. With its functionality implemented in Java, the Unicenter Explorer integrates and hosts all GUI components and plug-ins.
The type of information shown in the right pane depends on the category selected from the drop-down list in the left pane. Different left pane and right pane combinations let you completely customize the way you work in Unicenter NSM. Use the Topology view simultaneously with both the 2D and 3D Maps to view the dependencies between managed objects and the hierarchical relationships and links (parentchild) between them. The left pane of the Topology view displays a hierarchical tree of all the entities appearing in the Managed Objects folder in the 2D Map. As you expand the tree, both parent and child objects appear in the left pane. The right pane displays the instance-level property values for the children of the selected object.
Navigation View
The left pane of the Unicenter Explorer window is known as the Navigation View pane. It provides different views of Unicenter NSM functions and data. To select a view, use the drop-down list at the top of the left pane.
217
The left pane is the navigation pane because it lets you choose the type of information you see in the right pane, which is called the Data View pane. Double-click an item in the left pane to display details about it in the right pane.
Data View
The Data View pane is located on the right side of the Unicenter Explorer. It lets you view or modify a selected item. The right pane contains various plug-ins that display information about the object selected in the left pane. Plug-ins are available from the drop-down list and they include generic tools as well as 2D Map, Association Browser, and so on. The components that appear in this drop-down box depend on what is selected in the Navigation View pane. Note: If you want to disable the menu bar fade-in-and-fade-out feature at the top of the Unicenter Explorer, see the online help procedure Disabling Toolbar Fade.
Terminology
It is important to understand a few terms and tools related to how the 2D and 3D Maps display information.
Business Process View
A logical group of managed objects you create, based on any criteria you determine, such as geographic location, business process, security, and so on. A Business Process View acts as a filter that displays only objects relevant to the management of resources for a specific business requirement. For example, you can create a Business Process View that displays only objects related to your companys accounting processing, another for payroll, and so forth. A collection of objects with the same behavior. A rich set of class descriptions comes predefined with Unicenter NSM, and you can create additional classes of your own design with the WorldView Class Wizard. A general term referring to anything in your IT infrastructure, such as network devices and software applications. The visual representation of parent-child relationships existing between managed objects in the 2D Map. The initial 2D Map is a single folder, Managed Objects. The folder holds only managed objects that are not children of another object. Two concise views are provided to simplify the deployment and maintenance of your enterprise management systemiconic and textual. By default, the maps display your objects (represented as icons on the 2D Map and as models on the 3D Map), one level at a time. When you open, or expand, an icon or model, the objects that are included in this object are revealed.
Class
Entity
Folder
Iconic and Textual Views
218
Administrator Guide
Object
Any representation of an entity, stored in the Common Object Repository, such as a network device or software application. In the Unicenter NSM maps, these entities are considered to be objects and fall into one of the following categories:
Managed Objects represent entities that can be monitored and controlled using the Unicenter Enterprise Management applications or other software. A managed object has state, behavior, and identity that can be monitored and controlled by one or more management applications. Managed objects are stored in the Common Object Repository, and are derived from the ManagedObject class. WorldView Objects represent entities that are stored in the Common Object Repository, but are not managed objects. WorldView objects are derived from a Unicenter NSM class other than the ManagedObject class. Map-only Objects represent entities that do not need to be controlled or monitored, and therefore are not stored in the Common Object Repository.
For example, a parent object may be a Windows NT server with child objects such as the database agent and software application agents stored on the server. When you double-click the Windows NT server icon, a folder opens showing icons for the database and software application agents. Only the Windows NT server icon would appear in the initial Managed Objects folder of the 2D Map.
ObjectView
The ObjectView utility provides performance statistics about a network device. Depending on the device and its agent, this information may include the number of devices connected, which interfaces are down, and the number of packets coming in compared with the number going out. ObjectView also has pre-configured workspaces that let you selectively view certain MIBII values and WBEM data upon startup. This feature lets you create methods that enable the immediate viewing of specific SNMP data from a given host.
Map-Only File
A map-only file contains map-only objects, such as background maps, shapes, or text. For objects using the Unicenter Explorer, backgrounds and position are in the Common Object Repository. For WorldView Classic, the objects are created in the 2D Map and are not stored in the Common Object Repository, but rather in a separate map-only file that you create when you build tailored views of your infrastructure. The Topology Browser shows the dependencies between managed objects, such as a router and the workstations connected to it. It also illustrates the hierarchical relationships and links (parentchild) between your managed objects. The Topology Browser is a tree-like hierarchical structure view that lets you explore the objects by their textual label. When you open a branch, the objects that are included in the selected object are revealed.
Topology Browser
219
Unispace
Unispace refers to an area inside a host or a workstation, represented by an icon on the 2D Map or a model on the 3D Map. This particular area may contain representations of all the Unicenter NSM applications, other applications like Ingres, Performance, and SQL Server, and agents that are installed on a given object. Unispace is created by default when you install Enterprise Management components. However, agents are not represented in Unispace unless you elect to place them there at installation, or a particular agent happens to be installed on an Enterprise Management component. Note: For information about how to populate the repository with Unispace objects, see the cauwvini.exe command in the online CA Reference.
View
The visual representation of a folder on the 3D Map is called a view. Since the 3D Map uses a Single Document Interface (SDI), it is not possible to display multiple folders. Instead, when you double-click an icon, the entire display is updated to show only the children of the selected managed object.
Exploring the Network with the 2D Map

The 2D Map is a two-dimensional, geographical representation of the logical structure of your enterprise. The 2D Map simplifies managing your eBusiness resources by providing powerful tools to customize visual representations of your business enterprise. To access the 2D Map, select Topology from the drop-down list box of the left pane of the Unicenter Explorer, and then select 2D Map from the right panes drop-down list box. You select an object from the Managed Object Root tree. The 2D Map gives you direct access to the managed objects that are maintained in the repository. From the maps, you can list objects, delete them, change the values of their properties, enhance their definitions with comments and user-defined fields, and add objects to the repository, as well as search and query object information in the repository. The status of your managed objects is updated in real-time. The 2D Map uses real geographic maps to determine physical locations; for example, it has knowledge of longitudes and latitudes. Thus, objects or collections of objects can be positioned for realistic placement on the various maps, which feature full geographic detail, such as roads and bodies of water. The 2D Map also addresses additional management needs by allowing you to create customized Business Process Views. You can add images, such as floor layouts, to your views to see exactly where a device resides or a problem occurs.
220
Administrator Guide
As you launch the 2D Map, icons depicting these objects appear automatically and are arranged according to your network topology. The severity status of the objects is updated continuously in real-time. Using this interface, you can group map-only objects, such as background maps, lines, shapes, and text into a logical hierarchy of networks, subnetworks, and segments, based on your network topology.
Panning
Superior navigation of the 2D Map is possible through the advancement of the pan and zoom capability. The pan feature lets you move the 2D Map to see where you are in the map without getting lost. To pan the 2D Map, click the mouse and drag it in the direction you want to pan. The zoom feature lets you zoom in and out of the map using your keyboard and mouse. To zoom in the 2D Map, hold down the Ctrl key and the left mouse button. Then, drag the mouse upwards to zoom in or drag the mouse downwards to zoom out. Following is an example of how objects look in the 2D Map:
Zooming
221
2D Map Basics Click the right mouse button on the background area of an object to display a context-sensitive pop-up menu. Each menu is sensitive to the type of class the selected object is created from; therefore, the menu that appears may vary for each class of object. The class information decides what pop-up menu appears. The pop-up menu is associated with the objects class and is customizable. For example, from a WBEM objects pop-up menu, you can ping to learn if WBEM is active on that machine and you can browse the WBEM data of the object. You can customize the pop-up menu with the Unicenter NSM SDK or the Class Wizard. Positioning the cursor over any object displays a cross-hair cursor containing up to four instance-level property values for the object such as name, label, IP address, and severity status. Class defines the cross-hair cursor content; therefore, the information that appears may vary for each class of object. Double-clicking on any object executes the default pop-up menu option. This action usually opens a folder that displays the children of the selected object. That is, you begin to drill down through the levels of your IT infrastructure. Continue to open objects to drill down to the lowest level and check the status, identity, and so forth, of each object. Note: You can customize the cross-hair cursor data and the pop-up menu for any class at any time with the Class Wizard. For more information, see Adding or Modifying Classes later in the chapter or the online Help for the Class Wizard. See the instructions for customizing menus in the online CA Procedures under the following topics:

Creating a New Class Customizing Menus on the Menu Bar
222
Administrator Guide
Locating and Modifying Managed Objects

As part of the Auto Discovery process, network-centric entities and their connections are automatically arranged according to the logical structure of your network. Nevertheless, these objects can be moved, copied, and rearranged on the 2D Map to suit your enterprise management needs. See the instructions for how to modify managed objects in the online CA Procedures under the following topics:

Customize the 2D Map Manipulate WorldView Objects Use the 2D Map
Adding Objects You can easily add objects to the 2D Map using the drag-and-drop method. Dragging and dropping objects involves just a couple clicks of the mouse. To add an object, click once on the object from the Tool Palette tree and while holding down the left mouse button, drag the object into the 2D Map. Linking Objects To link objects that you added to the 2D Map, select Link from the Tool Palette tree. Select the type of link you want to create and drag it to the first object that you want to link. Then click and drag to the second object to create the link between the objects.
223
Arranging Object Layout You have control over how managed objects are arranged in the 2D Map. The Layout option from the context menu allows you to choose from a variety of layouts. The graphic following illustrates how the symmetrical layout appears in the 2D Map:
224
Administrator Guide
Adding Background Maps You can add background images to your 2D Map by choosing a background image or geomap from the Tool Palette tree list. Click and drag the image by holding down the left mouse button and dropping it into the 2D Map. The background map will appear underneath the objects in the 2D Map. Unicenter Explorer supports any BMP graphic you want to use as a background. Use the context menu to remove the background image.
You can create additional custom maps to use as background geomaps with Vector Globe, a product licensed by Computer Associates from Cartografx Corporation. You can create maps for anywhere in the world with a configurable level of detail, place these maps as backgrounds for your topology, and arrange devices by geographical latitude and longitude. Vector Globe is provided with the Unicenter NSM CD set for you to install after Unicenter NSM is installed. Start Vector Globe either from the Start Programs menu, choosing Vector Globe Unicenter, or from the Unicenter Explorer 2D Map by clicking the Tool Palette icon, right-click on the Tool Palette menu area, and choose Create New Geomap.
225
When Vector Globe starts, use the controls to create a map with the size and level of detail you require. When your map is ready, right-click on the map and choose Save Map to Unicenter. You can export multiple maps before closing the application. Close and restart Unicenter Explorer to make your new maps available for use as background geomaps. Creating Bookmarks Bookmarks are an easy way of quickly navigating to specific objects. To create a bookmark in the 2D Map, select an object in the Topology view and then click the bookmark icon from the toolbar. To view your bookmarks, choose Bookmarks from the left pane menu. To go to any of these bookmarks, just double-click on its image from the bookmark grid. To remove a bookmark, right click the bookmark and choose Delete from the popup menu.
226
Administrator Guide
Creating Billboards Creating a billboard lets you keep up-to-date information about critical (not propagated) objects in view at all times. To create a billboard, click the Tool Palette icon and choose Billboard from the Managed Object tree, then drag and drop it into the 2D Map. Once a billboard object is created, all of the critical children of the billboards siblings are shown in the billboard. If the critical status of an object is changed to normal, that object is removed from the billboard. A status that changes from normal to critical automatically appears in the billboard. Any of these changes are reflected automatically.
The status of any object that appears in the 2D Map can be seen at a glance, as devices with problems, along with their segments, subnetworks, and networks, appear in colors reflecting the severity of their problems. Alarmsets defined in the Common Object Repository and represented on the 2D and 3D Maps determine the relative importance of different classes of faults by assigning each one a severity status. Default alarmsets are provided, which you can assign to any object, customize, and extend. Note: Billboard objects should not be placed on the topmost parent. You should have multiple Billboard objects way down in your topology, perhaps at each segment level.
227
Exploring the Network with the 3D Map

The 3D Maps real-time, three-dimensional approach provides a highly visual representation of your enterprise. From a single point of control, problems can be resolved through the ability to travel throughout the enterprise, identifying and viewing the current status of the system, network, database, application resources, and even the physical environment. This three-dimensional representation of real-time status information provides system administrators with a truly intuitive tool that is easily mastered. The 3D Map employs virtual reality and three-dimensional graphics technology to provide a real world interface that is both intuitive and comprehensive. The 3D Maps real-time, three-dimensional approach affords you a highly visual representation of your enterprise. Using the advanced graphics capabilities of the 3D Map, you can fly to any site in your enterprise and view your applications, systems, networks, and more. The 3D Map has many powerful features. These include zoom, pan, and rotate features allowing easy maneuvering within your business. Fly into a city, to a building, and then into your network. Seeing a problem is easy since the border of the rooms reflects the severity. The tooltips also show the severity of the room or the object. The objects viewed using the 3D Map are fully open and easily customized. Hundreds of 3D models are already included with Unicenter NSM, and new models, such as buildings, floor plans, and unique systems, can be added without changing code. You can navigate the 3D Map easily with the pan and zoom feature of Unicenter NSM. To pan, hold down the F2 key and drag the mouse in the direction you want to pan the map. To zoom in the 3D Map, hold down the F3 key and drag the mouse downward. Drag the mouse upward while holding the F3 key to zoom out of the map. The 3D Map also rotates around an object. Just hold down the F4 key, then click toward the middle of the 3D Map and move the mouse in the direction you want to rotate. You move through the 3D Map by double-clicking on objects. The deeper you navigate the map, the closer you will be to finding out what is going on with your enterprise. In the illustration following, the red ball above the building indicates a critical object. Double-click on the critical object and use the pan and zoom feature to further investigate its status. After you have finished investigating an object, use the p key to navigate to the parent of the object you are currently viewing.
228
Administrator Guide
Unicenter NSM provides an extensive set of tools you can use to display objects on the maps easily and efficiently. Whether the object displays in the 2D or 3D Map depends on which map is active when you make a selection.
229
This screen illustrates where the critical objects are located as you move inside the 3D Map of your enterprise. Continue to double-click on the critical object to gather more information.
Viewing Billboards Billboard objects give you up-to-date information about critical (not propagated) objects in view at all times. Take a quick look at the billboard to see if any of the children of this room are critical. They are real objects so you can enter the billboard to solve the problem. Double-click on the object to get a closer look at a critical object. 3D Map Basics Positioning the cursor over any object displays a cross-hair cursor containing up to four instance-level property values for the object such as name, label, IP address, and severity status. Class defines the cross-hair cursor content; therefore, the information that displays may vary for each class of object. Clicking the right mouse button on any object displays the popup menu for the object. Class defines the popup menu content; therefore, the menu that displays may vary for each class of object.
230
Administrator Guide
Note: You can customize the cross-hair cursor data and the popup menu for any class at any time with the Class Editor. For more information, see Adding or Modifying Classes later in the chapter or see the online Help for the Class Editor. Double-clicking on any object executes the default popup menu option. The default popup menu option usually opens the object and allows you to fly into it so that you may view the children of the selected object. Continue to open objects in order to drill down to the lowest level and check the status and identity of each object.
Tip: You can back out to the previous view at any time by pressing the p key.
Using a Mouse
Navigating the 3D Map using a mouse is simple. Hold the z key and left click an object once to bring it closer, then double-click the object to open it. Advanced navigation tools are also available to you with pan, zoom and rotate features for navigating with the mouse.
PanHold the F2 key and drag the mouse in the direction you want to pan map. ZoomHold the F3 key and drag the mouse up to zoom out of the map or down to zoom deeper into an object on the map. RotateHold the F4 key, click toward the middle of the map, and move the mouse in the direction you want to rotate the map. An object will tilt if you hold the F4 key, click toward the edge of the map, and move in the direction you want to tilt.
Using a Spaceball
If you use a Spaceball pointing device to navigate the 3D Map, always keep in mind that the more pressure you apply to the Spaceball, the faster the 3D Map moves.
Tip: Increase your freedom of movement around the 3D Map by resetting your spaceball with the Options Re-zero spaceball menu command.
See the Spaceball users manual for complete instructions on using the Spaceball and adjusting its sensitivity.
231
Viewing Objects with the Association Browser

The Association Browser lets you navigate different types of relationships among objects. The hyperbolic tree helps you see what is happening in your enterprise as you traverse nodes through associations. To view the Association Browser, select Topology from the drop-down list box of the left pane, and then select Association Browser from the drop-down list box in the right pane. When the Association Browser displays, it shows the selected object and all the objects with which it is directly associated. Note: Not all classes of objects displayed in the Unicenter Explorer support the concept of associations. Many objects of classes that do support associations may not have any associations currently defined. When this is the case, only the selected object displays in the Association Browser. See the instructions for navigating in the Association Browser in the online CA Procedures under the topic, Viewing Objects with the Association Browser.
Viewing Current Status

Another important feature of the Unicenter NSM maps is their ability to display the current, real-time status of any managed object. If a managed object experiences a problem, its visual appearance on the maps changes. On the 2D Map, you can assign each severity level a separate icon. By default, the icons shape remains the same, but the color changes based on severity. A floating ball above a managed object on the 3D Map depicts the status of the object. The color of the ball indicates the severity level. Several Unicenter NSM facilities control how the status of managed objects appears on the maps. First, up to ten severity levels can be set for every class of managed object, and second, you can specify a separate 2D icon for each level of severity through the Class Wizard.
Determining Severity through Alarmsets
Every managed object can have an alarmset associated with it. Each Alarmset Entry identifies a possible status for the object and associates it to one of 10 predefined levels of severity. Whenever the status of a managed object changes, Unicenter NSM compares that status setting to alarmset policy settings. Alarmsets are defined using the Alarmset dialogs. Using the Alarmset dialog, you can create a new alarmset, change existing instance-level alarmset property values, or delete existing alarmset entries from this dialog. You also can associate the alarmset with any managed object. In the Unicenter Explorer, click the right mouse button on an object, choose Viewers and Alarmset View from the popup menu to access the AlarmSet dialog.
232
Administrator Guide
Each alarmset definition contains the following information:
Alarmset nameidentifies the alarmset. Use this name when associating an alarmset with a specific managed object class definition. The same alarmset can be used by multiple managed object classes. Propagate_statusdetermines whether the status of the object propagates up to the objects parents. Severityidentifies the state to which the object should be changed when the status_no text is encountered.
Note: You associate the alarmset at the object level, not the class level. This allows objects instantiated from the same class to be associated with different alarmsets. See the instructions for creating and assigning alarmsets in the online CA Procedures under the following topics:

Creating, Deleting, or Modifying Alarmsets How Alarmsets Work
Viewing Object Details and Properties

Every managed object is derived from the ManagedObject class, or a subclass of ManagedObject. You can view, and sometimes modify, the values of a managed objects class-level and instance-level properties with the Managed Object Notebook. Click the right mouse button on an object, choose Viewers and Property Notebook from the popup menu to access the Property Notebook. Each of the notebook tabs corresponds to a property group for the class. Each field represents a property, either class-level or instance-level. The number of tabs that appear depends on the objects class definition. For details about the Property Notebook, see the online Help. Note: Use the Class Wizard facility to modify the occurrence of a class or instance-level property. For more information about class definitions, see the section Adding or Modifying Classes later in this chapter and the topics Class-level properties and Instance-level properties in the online Help for the Class Wizard.
233
Viewing MIBs and WBEM Data with ObjectView

ObjectView lets you browse a devices MIB and WBEM data. The MIB consists of a collection of attributes that are retrieved using network management protocol. MIB information includes aspects of a device's performance including the number of devices connected, which interfaces are down, and the number of packets coming in compared with the number going out. WBEM information is a standardized collection of end-to-end management and diagnostic data in enterprise networks that can include hardware, protocols, operating systems, and distributed applications. Note: You must use WorldView Classics ObjectView to browse WBEM data. The left pane of the ObjectView container displays the groups of attributes belonging to a device. Expanding a category shows the particular attributes for which you can obtain values from the devices MIB or WBEM data to display in the right pane.
234
Administrator Guide
Tip: You can access ObjectView directly from Tools in the left pane dropdown of the Unicenter Explorer.
Using ObjectView, you can obtain attribute information such as Object ID, Value Type, or information for an attribute group such as an attribute count and, if applicable, table information. You may also set attribute values at the device level. For example, if an interface is having problems, you can change its adminStatus from up to down. For more information see the online Help for ObjectView. See the instructions for viewing MIBs in the online CA Procedures under the topic, Viewing a MIB. Dashboard Monitor The DashBoard Monitor lets you graph selected MIB attributes in real-time. It provides access to the Graph Wizarda tool for creating dynamic graphs of device performance for further analysis. WorldView Classics ObjectView supports Microsoft Excel and you can display the collected data in Excel spreadsheets. Using the DashBoard Monitor and Graph Wizard, you can create formulas for the attributes selected for graphing that include usage of polling interval information. See the instructions for using the Dashboard Monitor and graphing MIB attributes in the online CA Procedures under the following topics:

Creating a Dashboard Formula Creating a Graph from ObjectView
Creating and Viewing Business Process Views

The Unicenter Business Process View (BPV) is the means by which the constituent resources that together perform some business critical process within an enterprise can be grouped logically. Undeniably powerful, the Business Process View is an effective way to alert you to the fact that a key link in chain of resources is encountering some problem that may impact the business.
235
A Business Process View is a simple, concise view of a logical grouping of managed objects that are related to a specific process. The contents of a Business Process View can represent whatever you decide is important to your process execution. You can group these views by geographical locations, organizational structures and roles within the organization, applications, resource features, or any other requirements. The Business Process View presents all of the resources related to a business application or a specific business process. To monitor the condition and status of objects, you can set triggers and thresholds, and intercept messages generated by programs participating in the process. These views can assist you in the early detection and prevention of problems, and when a problem does occur, the Business Process View provides an immediate, graphical view of the source and severity of the problem. Dynamic Containment Service The Unicenter Dynamic Containment Service (DCS) is a yet further extension to the Business Process View concept. The DCS maintains the contents of any designated Dynamic Container object in the repository according to a fully configurable rule-based inclusion policy. The Dynamic Containment Service is made of three closely related components:
The DCS Service is a Windows Service that automatically starts and stops the Engine during a reboot. The service helps to ensure that the Engine is running whenever the repository is running and that your container objects are an accurate reflection of their associated inclusion policy. The service defaults to an Automatic startup type. It can also be started and stopped manually using the Window Service Control Manager or from the command line with the following commands:
Net Start CA-DCS Net Stop CA-DCS
The DCS Engine implements the policy defined for each Dynamic Container object in the repository. The Engine detects property changes and objects are added or removed as children of a Dynamic Container object as they conform to or no longer conform to the inclusion policy. The DCS Policy Wizard quickly configures the engine to maintain your designated Dynamic Container objects. Using the Policy Wizard, you can perform the following tasks: Select the repository you want the engine to run against and configure sign-on details so that it can run unassisted as a Windows service. Specify the location and granularity of the log file that the engine generates.
236
Administrator Guide
Specify Event Management node to which events are forwarded by the engine. Configure the inclusion policy for any number of Dynamic Container objects you want to have dynamically maintained by the engine.
You can access the DCS Policy Wizard from the Start Programs Unicenter WorldView group. Note: Configuration changes do not take effect until you stop and restart the service. Viewing a Business Process View Choose Business Process Views from the left pane of the Unicenter Explorer to open a previously created Business Process View window from either the 2D or 3D Map. To display a particular Business Process View, double-click the view in the list. If the 2D Map is active, the selected Business Process View folder is opened in the 2D Map. However, if the 3D Map is active, your display is automatically revised to display only the objects related to the selected business process. You can access the pop-up menu associated with objects of the BusinessView class by selecting the Business Process View and clicking the right mouse button. Note: WorldView Classic supports the All icon, which affects the 3D Map only. It resets the view in the 3D Map to display all objects in the Common Object Repository, not just those in a particular Business Process View. Creating a Dynamic Business Process View A Dynamic Business Process View uses the Dynamic BPV Manager to help you build a query, search for objects that meet your criteria and populate the Dynamic BPV with the results of the search. The process saves you the effort of manually searching for objects to populate a Business Process View. You can refresh the view at any time by rerunning the query to pick up new objects that meet the query criteria. Note: WorldView Classic supports WBEM and SNMP, while Unicenter Explorer supports the Common Object Repository only. The Dynamic BPV Manager is able to use both WBEM and SNMP protocols as well as Common Object Repository objects to populate the Dynamic BPV. To retrieve WBEM objects, you must have the WBEM core installed on the machine where the Dynamic BPV Manager is running, as well as on the machines being queried. Because WBEM protocol uses SNMP, you must also have SNMP installed. To retrieve SNMP objects, you must have the SNMP Service on any machine being queried.
237
To create a Dynamic BPV, first create a Dynamic BPV class object. The Dynamic BPV class object is placed in the Managed Objects folder. Access the Dynamic BPV Manager by right clicking the object and selecting DBPV. See the instructions for creating Business Process Views, saving a view, and creating Dynamic Business Process Views in the online CA Procedures under the following topics:

Creating a Business Process View Saving 2D Map-only Objects and Views Creating Managed Objects
Customizing the Maps

Unicenter Explorer
See the instructions and guidelines for customizing maps in the online CA Procedures under the following topics:

Customize the 2D Map Customize the 3D Map
Unicenter Classic
Using the various customization procedures for the 2D Map, you can add, modify, and delete objects and their relationships in the repository without writing code. Enhance your displays with your own customized images that reflect the unique aspects of your enterprise more precisely and in greater detail. The 2D and 3D Maps can accommodate map and model image files and texture files that are imported from third-party graphics software or from scanned photographs. You also can insert a scanned image of your floor layout and place the objects in their respective physical locations in order to see, at a glance, exactly where a device resides or a problem occurs. See the instructions and guidelines for customizing the 2D and 3D Maps in the online CA Procedures under the following topics:

Adding Menus and Menu Selections to the 2D or 3D Map Menu Bar Changing the Color of the 3D Map Status Ball Configuring the 3D Map Wireframe View Creating and Displaying 3D Models Customize the 2D Map Customizing the 3D Map Importing an Image
238
Administrator Guide
Modify the Class Hierarchy
Also see the online help for the 3D Map under Guidelines for Creating or Modifying Complex Models. Note: This discussion assumes that you are familiar with the 3D Map and basic object-oriented programming concepts. For more information, see the online help for the 3D Map, and Object-Oriented Programming Basics in the Class Wizard online help.

Unicenter NSM comes with an extensive set of predefined classes to manage your IT resources. To learn more about the predefined classes, see the Predefined System Classes section of the CA SDK Developer Guide. There will, on occasion, be times when you want to modify the properties of an existing class; for example, to change the popup menu associated with a class of objects or the icon that appears. In addition, there may be instances when an application or device contains unique qualities that warrant the creation of a new class, defined as a subclass of one of these predefined classes (primarily the ManagedObject class). Making updates of this nature is easily done using the WorldView APIs of the Unicenter NSM SDK or through use of the Class Wizard.
239
Reviewing Class Definitions

Before modifying the Unicenter NSM class hierarchy, you should first review the predefined classes by selecting the Class Specification category in the left pane of the Unicenter Explorer and the Class Editor from the right panes drop-down list. Class Specification and the Class Editor display the class definitions of the Common Object Repository in an organized hierarchical format. It is an effective tool that allows you to see what properties exist for each class.
The left pane displays the Unicenter NSM classes in a hierarchical structure. The right pane displays the class-level properties of the class highlighted in the tree, followed by instance-level properties when they exist for the class. Class properties define an objects state and behavior and can be of two types class or instance. Class-level properties may not be modified. Instance-level properties are unique for each object and may be modified. Note: For a complete list and description of all existing properties and their attributes, see the class- and instance-level properties tables in the online Help.
240
Administrator Guide
For more information about using the Class Editor to review the properties of defined classes, see the online Help.
Adding or Modifying Classes

The Class Wizard in WorldView Classic, or the Class Editor in Unicenter Explorer, is an easy-to-use facility that steps you through the process of modifying existing classes or adding new ones to the Common Object Repository. The simplest way to create a new class or modify an existing class is to let the Class Wizard or Editor guide you through the process.
Unicenter Classic
Use the Class Wizard to define properties, create pop-up menus for launching applications, or define the appearance of managed objects on the 2D and 3D Maps. Whether you are a programmer who uses the Unicenter Software Development Kit to define and modify classes, or an end-user who wants to modify the look of a managed object's icon on a map, you can use the Class Wizard to create or modify classes without writing any code. When you activate the Class Wizard from the 2D Map, the 3D Map, or the Object Browser, the series of dialogs presented by the Class Wizard appear as tabs at the top of the window. For detailed field and procedural information, see the online Help for the Class Wizard.
Unicenter Explorer
Use the Class Specification and the Class Editor categories in the Unicenter Explorer to modify existing classes or to create new classes of objects. See the instructions for modifying classes or adding new ones to the Common Object Repository in the online CA Procedures under the following topics:

Adding A Property Adding A Property Group Adding A SysObjID Creating A New Object (Unicenter Explorer only) Creating A New Class or Subclass Creating Custom Icons for Classes (Unicenter Explorer only) Deleting An Existing Class Deleting A Property Group Deleting A Property Deleting A SysObjID Modifying An Existing Class
241
Modifying An Objects 2D Icons Modifying An Objects 3D Models Modifying An Objects Cross-Hair Cursor Modifying An Objects Pop-up Menu
Alternatively, you can use the Unicenter NSM SDK and accomplish these tasks under program control. For information on using the SDK, see the CA SDK Developer Guide. Deleting Classes You can delete a class only if the following conditions are true:
The class is not a system class such as the ManagedObject or Network class. That is, you cannot delete a class for which the class level property system_class is set to TRUE. The class has no subclasses. The class has no objects derived from it. All objects of the class must be deleted before the class can be deleted.
242
Administrator Guide
Viewing Your Enterprise Across Time

Time dimension is a key technology of Unicenter NSM. It provides you with the tools to travel through time. The time travel feature let you navigate through time through the Unicenter Controller to view historical status and other information about the past.
Unicenter Controller
The Unicenter Controller enables time travel into the past of your enterprise using the Historian. The Unicenter Controller control panel works in conjunction with the Unicenter Explorer to help you manage and visualize data more effectively. You access the Unicenter Controller control panel from the Historian view of a specific object or from the Unicenter TND program group. The Unicenter Controller provides a number of controls to facilitate traveling back in time to view historical information. When you use these controls to set the clock to a time in the past, the Unicenter Explorer will be notified to access data from the Historian and present information for the specified point in time. The Unicenter Controller also provides features to assist managing the present time. It provides controls used in the Unicenter Explorer to navigate specific objects. The Unicenter Controller displays a list of objects identified as being in a critical state. The Unicenter Controller lets you navigate the Unicenter Explorer by displaying specific Business Process Views that you defined. You can also display views you previously saved as bookmarks. To connect to a server, click the Connect button located at the top of the screen. When pressed, a drawer will open from the right side of the control that presents a list of Unicenter NSM Servers that can be connected to. Selecting a server from the list will establish a connection to that server. When you select a Unicenter NSM Server, the WorldView repository managed by the server will be queried for a list of objects that are in a critical state. These objects will be displayed at the bottom of the Unicenter Controller in the Critical Objects list. You can navigate the Unicenter Explorer to one of these objects by clicking on an item in the list. For instance, if you click on the item labeled STHOMAS, the Unicenter Explorer will be set to the Topology view and expanded to show and select STHOMAS in the Navigation View pane.
243
Navigating to Business Process Views The Unicenter Controller also presents a list of Business Process Views you can use to navigate the Unicenter Explorer. The Business Process View Selector button is located toward the bottom of the Controller. When you select this button, a drawer appears to the right and presents a list of Business Process Views (BPVs). Selecting an item from the list navigates you to the selected Business Process View object in the Unicenter Explorer. The Business Process View will also be displayed following the BPV Selector button. The BPV button is initially disabled when the Control Panel is displayed. It is enabled when a connection has been made to a Unicenter NSM server. Restoring Bookmark Views The Unicenter Controller lets you restore the Unicenter Explorer to a previously bookmarked view. The Bookmark button is located at the top left of the Control Panel. When clicked, a drawer opens from the right side of the Control Panel with a list of the bookmarks. Selecting an item in the list navigates an open Unicenter Explorer to the view represented by that bookmark. Traveling Back in Time The Historian feature facilitates time travel by letting you view historical status and events in the Topology and Business Process Views. You instruct the Unicenter Explorer to access data from the Historian by using the time travel controls located on the Unicenter Controller. A sliding glass pane covers the Controller. This glass pane slides up as the mouse moves over it. Select the Lock Cover Open button to keep the glass pane open. You can close the glass pane to hide the time travel controls by clicking on the arrow that appears above the date and time display. The Controller provides controls similar to those found on a VCR. There are buttons for forward play and reverse play, and others for quickly moving to key points in time. A dial lets you manually turn the clock back to a desired time in the past.
244
Administrator Guide
Importing and Exporting Data with Trix
For example, you need to know what the state of a Printer 6B was during the weekend. Display the Historian for Printer 6B. The Unicenter Controller automatically opens. From the Unicenter Controller, rotate the dial counter clockwise to reach that date and time. When you release the mouse button, the historical data for the printer is updated in the Historian view for Printer 6B.

WorldView Repository Import Export (trix) is an effort and time-saving utility you can use to copy existing object definitions from the Common Object Repository into a separate trix file. This is a useful way to back up the Common Object Repository or to populate another Common Object Repository, such as a central corporate Common Object Repository. The trix facility is also a way to modify object definitions. This is useful when you are adding a few objects that are similar to existing objects, because it does not require you to run Discovery. For example, if you have two subnets with 10 machines on each that are the same except for their names, you can use trix to export the definitions of the existing machines into a trix file, modify the name property as necessary for each applicable object and import the objects with modified name properties into the Common Object Repository.
245
Before You Use Trix
Before using trix, make sure you have reviewed and are familiar with the topics discussed in the next few pages. Failure to do so may result in your actions corrupting your Common Object Repository and object definitions. Trix lets you do the following:
Populate a Common Object Repository with existing objects from another Common Object Repository. Populate a Common Object Repository with objects that are similar to existing objects already stored in that Common Object Repository or another one.
Note: It is always good practice to perform database backups regularly in case of errors in your trix script. Trix exports (copies) object definitions (properties) from a Common Object Repository into a script file. These exported object definitions can be modified and then imported back into the same Common Object Repository or another one. This technique for updating or adding information to the Common Object Repository is typically done when you have new objects on your network that are similar to existing objects. Using Trix There are two ways to export objects from the Common Object Repositoryby object or by class. When exporting by object, you can choose to export child objects, inclusions, and outgoing and internal links. When exporting by class, all objects that match the Unicenter NSM class definition are exported. To launch trix on Windows, choose Start, Programs, Unicenter TND, WorldView and open the Repository Import Export utility. Choose the Common Object Repository from which you want to export objects. The trix window is displayed. The trix window lets you create new script files, print script files, edit script files, and monitor messages pertaining to the export process. It also provides access to the export and import dialogs. For a more detailed explanation of the trix window including menu selections, see the online Help. To launch trix on UNIX/Linux, choose Tools from the Unicenter Browser. Right click on Repository Import/Export. The pop-up menu lets you create new script files, refresh the view of script files, and provides access to the export and import dialogs.
246
Administrator Guide
Export Objects
To access the export dialog on Windows, choose Actions Export Repository. To access the export dialog on UNIX/Linux, choose Export from the Repository Import/Export menu. The Export Repository dialog lets you export object definitions by class or object and determine the location of the trix script file and the prefix you will use for the trix script filename. The default trix script filename on Windows is trix.imp. The default trix script filename on UNIX/Linux is TRIX.TNG. You can assign a different name to the files. The name is limited to four characters. After the trix script file is created a number is assigned to it starting with zero (trix0.imp on Windows, TRIX0000.TNG on UNIX/Linux). There is a 1 MB size limit on trix files. When the trix file (trix0.imp on Windows, TRIX0000.TNG on UNIX/Linux) size approaches the limit, a second trix file (for example, trix1.imp on Windows, TRIX0001.TNG on UNIX/Linux) is created and so on until all the object definitions have been copied into the trix files. When multiple trix files are created, an Include file is created that lists all the created trix files. When starting trix from the command line, rather than listing each trix file individually, you can use this Include file to reference all the trix files.
Import Objects
To access the import dialog on Windows, choose Actions Import Repository. To access the import dialog on UNIX/Linux, choose Export from the Repository/Import Export menu. The Import Repository dialog lets you initiate and stop importing object definitions into a Common Object Repository, add and remove script files to be imported, and monitor the progress of the importing process. Select the trix files that contain the object definitions you want to import into your Common Object Repository. Use the Add Scripts button to add a trix file not listed in the Import Repository dialog. Important! The Unicenter Explorer must be closed before you import a trix script. See the instructions for importing and exporting objects in the online CA Procedures under the following topics:

Exporting Objects Importing Objects
247
Protecting the Repository with Data Scoping Rules

WorldView Data Scoping lets you protect repository object data from unauthorized access. Data Scoping rules let repository administrators control a specific user IDs access to a particular data object or group of data objects. Data Scoping is intended to provide protection against both malicious and nonmalicious access. Data Scoping lets you filter large amount of information contained in a repository into smaller, more pertinent subsets of data. It lets you view the same data differently depending on the current task. Data Scoping has minimal impact on repository performance. No data scoping solution can be completely free of impact on performance; however, the impact on repository performance varies on a site-by-site basis relative to how you use the Data Scoping feature. You are protected against unnecessary performance degradation by both flexible Data Scoping rule syntax and a Data Scoping evaluation cache that holds the most frequently read Data Scoping rules. You can define the following two levels of Data Scoping rules:
Class-level rules scope data objects by their data classification. Class-level rules let you restrict access to an entire class of objects, rather than individual objects. Because object-by-object evaluation is not required to support this type of Data Scoping rule, defining class-level rules is the most efficient means of scoping data objects. For example, you could define a Data Scoping rule to implement a statement like User ID JOE cannot access objects of the Payroll class. When a request for access to the Payroll class is evaluated, it determines whether the requesting user ID is JOE and the entire request is immediately allowed or denied.
Object-level rules allow data objects to be filtered explicitly on an object-byobject basis using the objects instance-level properties. Object-level rules target a specific object or group of objects within a class. For example, you could define a Data Scoping rule to implement a statement like User ID JOE cannot access Payroll objects that were created by user ID MARY. A rule like this requires an object-by-object analysis of each of the Payroll objects accessed by JOE to determine if the createuser instance-level property has a value of MARY.
248
Administrator Guide
Data Scoping rules are stored in the repository and evaluation requires additional I/O to retrieve them. To reduce the number of additional I/O requests and their impact on repository performance, a Data Scoping evaluation cache holds the most frequently used Data Scoping rules in memory. When an incoming repository request is evaluated for Data Scoping, the evaluator determines the requesting user ID. If the requesting user ID is not already in its cache memory, the evaluator loads the cache with all of the Data Scoping rules that correspond to the user ID. The mechanism described previously limits additional Data Scoping I/O to the first repository request by a user ID. Synchronization of the cache with Data Scoping rule updates is critical and verified on a request-by-request basis. If we assume that the user ID is the same user ID that is used to connect to the repository, the impact of Data Scoping rules on repository performance can be summarized as follows:
When Data Scoping rules are not used, there is no performance impact on repository functionality. When a user ID has no Data Scoping rules applied to it, there is no performance degradation for any repository requests after the first data access. When a user ID has Data Scoping rules that apply to it at a class level, there is no performance degradation for any repository requests to those classes with no rules applied. Any performance degradation of access is limited to those classes with rules applied and is negligible. When a user ID has Data Scoping rules that define object-level overrides (thus requiring property-by-property analysis), there is no performance degradation of repository requests to those classes for which there are no rules. The impact on performance is limited to those requests that target a class for which there is a rule.
Each set of Data Scoping rules governs data access only for the repository for which they are defined. If more than one data repository exists on a machine, each repository has its own set of autonomous rules. Further, if a user of a single machine connects to more than one repository, each repository has it own independent set of Data Scoping rules for that user. Data Scoping rules can control the type of access that is used. You can govern all access to a particular data type, or you can give a specific user ID read access without giving that same user update, create, or delete capabilities. By default, users connected to the repository have full access to objects until Data Scoping rules are generated to deny particular types of access. On UNIX/Linux, only local repositories are supported. All references to repository refer to the local database.
249
Note: Data Scoping rules do not affect the Discovery process. All discovered devices are added to the repository. If you do not want a particular user to see these discovered devices, create rules for those users that deny READ access.
User IDs and Data Scoping Evaluations

The user ID required for a Data Scoping evaluation depends on your database, the database configuration, and the type of application you are running. Win32 Applications To enforce Data Scoping properly, Win32 applications depend on the user ID that is connected to the repository. The user ID required for connecting to the repository varies as follows:
SQL Server 7.0
SQL Server and Windows Security Mode (default mode) uses IDs that vary with your logon circumstances, such as the following: If the Windows user currently logged on is defined to access SQL Server, or is part of a Windows Group defined to access SQL Server, the Windows user ID is used for Data Scoping rule evaluation. If the Windows user currently logged on is not defined to access SQL Server, or is not part of a Windows Group defined to access SQL Server, Data Scoping rule evaluation uses the SQL Server user ID used to log in to the repository. The SQL Server user ID is the user ID entered into the Repository SignOn dialog or the user ID saved in the registry.
Windows NT only Security Mode always uses the Windows logon user ID for Data Scoping rule evaluation.
Note: Data Scoping does not support SQL Server 6.5.

SQL Server 2000
Windows NT only Security Mode (default mode) always uses the Windows logon user ID for Data Scoping rule evaluation. SQL Server and Windows Security Mode uses IDs that vary with your logon circumstances, such as the following: If the Windows user currently logged on is defined to access SQL Server, or is part of a Windows Group defined to access SQL Server, the Windows user ID is used for Data Scoping rule evaluation.
250
Administrator Guide
If the Windows user currently logged on is not defined to access SQL Server, or is not part of a Windows Group defined to access SQL Server, Data Scoping rule evaluation uses the SQL Server user ID used to log in to the repository. The SQL Server user ID is the user ID entered into the Repository SignOn dialog or the user ID saved in the registry.
Local Group Authentication
On the local machine, if a user logs into a machine using a locally defined account that is Windows NT-authenticated to SQL Server, that is, the account is defined to SQL Server and has permission to use the TNGDB database, the local user account is used for Data Scoping rule evaluation. Note: Data Scoping rules are not supported for local groups, only local users. To authenticate a Windows user ID to SQL Server using the SQL Enterprise Manager, follow these steps: 1. 2. Create a new login in SQL Enterprise Manager and select Windows NT Authentication as the authentication method. On the Database Access Tab, check the Database TNGDB checkbox.
A local account can be authenticated in one of the following two ways:

Define the Local Account to SQL Server as described previously. Define a Local Group Account to SQL Server and add the local user account to the Local Group. Add the local user account to the TNDUsers Group. The TNDUsers Group is automatically authenticated to SQL Server when Data Scoping is installed.
On a remote machine, if a user is authenticated to a remote repository using a non-domain account, then the user can be authenticated in one of the following two ways:
When you map a drive to the remote machine using a user ID defined to SQL Server as described previously, the user ID used to map the drive is used for Data Scoping rule evaluation. The following must be true of the user logged into the local machine: The local user ID must be defined on the remote machine The password for the local user ID must be the same on the local machine and the remote machine The user ID must be Windows NT-authenticated to SQL Server
Data Scoping rule evaluation takes place as described for a local machine.
251
Accessing the Repository You access the repository through plug-ins in the Unicenter Explorer. On a local repository, the currently logged on Windows user ID is used for Data Scoping evaluation. For a remote repository, a Windows user ID defined on the remote machine is used for Data Scoping evaluation. You can enter the Windows NT user ID in the Login Security dialog that is accessible from the Unicenter Explorer. When the Unicenter SignOn dialog for remote connections appears, use the following user IDs:

SQL Server user ID (for example, sa). Windows user ID. Use the User Manager to add this user ID to the Windows Group TNDUser. TNDUser is created during Unicenter NSM installation and has all the necessary Windows privileges. You need only to add a Data Scoping user to this group before they can sign on to Unicenter NSM using the ID.
For a local repository, the currently logged on UNIX/Linux user is used for Data Scoping evaluation. For a remote repository, a UNIX/Linux user ID defined on the remote machine is used for Data Scoping evaluation. The UNIX/Linux user ID can be entered from a SignOn dialog from the Unicenter Explorer.
Data Scoping Classes

Data Scoping requires six new classes. The first class, DataScope, is the parent class. The DataScope class has the following five subclasses:
ScopeRule--Logically groups more than one class-level. A class-level rule targets a particular classification of data objects. ScopeClassRule--Stores objects that define class-level rules. ScopeObjectRule--Stores objects that define object-level rules. An object-level rule targets a specific data object or group of data objects. ScopeOptions--Holds any DataScope options in its class-level properties. ScopeInclusion--Functions comparably to the inclusion class in the WorldView repository and is the means for defining cross object relationships. It links users to class-level rules, and class-level rules with object-level rules.
252
Administrator Guide
Each of these subclasses initially has no instances. Instances are added as Data Scoping rules are added. On Windows, the Unicenter Class Wizard can be used to alter any of these values.
Using Data Scoping

You can activate and deactivate Data Scoping rules according to the current date at the time of access by defining a Data Scoping rule with an effective date or an expiration date. If Enterprise Management is installed, you also can set the applicability of a Data Scoping rule by specifying that it use a particular calendar. Before you can begin to use the DataScope Rule Generator, you must first activate the Data Scoping utility and create the DataScope classes by running the following command:
\NSM\bin\wvscpini.exe
Note: Only administrators can run this command. If you run this command after you have connected to the repository, applications already connected will not have DataScope rules enforced until the applications are restarted. To start the DataScope Rule Generator GUI and create new rules or update existing rules, run the command:
\NSM\bin\datargen.exe
Note: Only administrators can run this command. You can only create rules on classes inherited from the ManagedObject or Association class. If, after activating and using Data Scoping, you want to deactivate the data scoping, run the command:
\NSM\bin\wvscpdel.exe
Note: Only administrators can run this command. Data Scoping security is designed for non-administrator accounts; that is, for Windows user IDs that are not part of the Windows Administrators Group. While you can create DataScope rules for Administrator accounts, and those rules will be enforced, any administrator can delete those rules. Effectively, there is no real Data Scoping security for administrators.
253
You use the scputil utility from the UNIX/Linux command line to create new Data Scoping rules, update existing rules, and for defining cross object relationships. For syntax and usage information, see the online CA Reference. To activate Data Scoping and create the DataScope class, run the following command:
$CAIGLBL0000/wv/bin/wvscpini.exe -r repository
where repository is the name of the Common Object Repository on which you want to activate Data Scoping. Remote Common Object Repositories are not supported; therefore, the repository name should be that of the local repository. Note: Only the root user can run this command. If you run this command after you have connected to the repository, applications already connected will not have Data Scoping rules enforced until the applications are restarted. To deactivate Data Scoping, run the following command:
$CAIGLBL0000/wv/bin/wvscpdel.exe -r repository
where repository is the name of the Common Object Repository on which you want to deactivate Data Scoping. After running the wvscpdel.exe command, recycle WorldView to record changes made to the database tables. Note: Only the root user can run this command. Data Scoping security is designed for non-root accounts only.
254
Administrator Guide
Datargen Examples (Windows Only) The following object-based example creates a rule on the WindowsNT_Server class that denies Update and Delete access to the machine named nt1 when its severity is critical. The rule applies only to the Guest and sa user accounts.
255
The following class-based rule denies all access to WBEM objects for all users:
256
Administrator Guide
The following object-based rule allows all access to user sa to the BusinessView objects named bpv1 or bpv2. The rule takes effect only on the days set in the Enterprise Management calendar named cal1. For this rule to be implemented, the Enterprise Management component must be installed. For more information about defining calendars, see the topic Establish Date and Time Controls for Automated Event Processing in the chapter Event Management.
257
Data Scoping Inheritance Rules

Data Scoping rules are inherited in the following two ways:
Class inheritanceRules defined for a particular class are inherited by all its subclasses. Rules defined for a particular class override rules from any of its parent classes. If no rule is defined for a particular class, the immediate parent overrides any other rules in the class hierarchy. Thus, if you deny Delete access for the ManagedObject class, but allow Delete access for Host, Windows Server machines and Windows 2000 Server machines can be deleted but a Crossroads_Bridge cannot be deleted.
Inclusion inheritanceRules defined for a particular class are propagated to the child objects of that class. Also, because a Business Process View object has two parents, both of the parents rules are checked. If there is a rule for the child object, it will override the rule for the parent object. Thus, a rule defined for a particular subnet will have that rule take effect on all objects within that subnet. For example, if you cannot delete subnet a.b.c.0, you are also not able to delete machine a.b.c.14 or a.b.c.16.
If rules are defined for a parent object and a parent class, the class inheritance rules takes precedence over the inclusion inheritance rules. The inclusion inheritance rules are only evaluated if the class inheritance rules do not apply. Rule propagation is useful for administrating entire subnets or all objects related to a device. If you deny Delete access for Windows machine ABCD, then any agents, Enterprise Management components, or WBEM object for that device cannot be deleted. Separate rules do not need to be defined.
Data Scoping Order of Rule Precedence

Data Scoping rules can be applied to target a specific class or superclass (if subclasses are present). The order of precedence rules are applied only when there are multiple rules that conflict, that is, one rule denies access and another allows access for the same operation. The order of rule precedence is as follows:
Object-level rules take precedence over class-level rules. If object-level rules conflict, the Allow rule takes precedence. If class-level rules conflict, the Allow rule always takes precedence.
258
Administrator Guide
This same concept applies to class generation level. Class generation level 0 implies that the rule is tied to the current class and has precedence over all other class generation levels. Class generation level 1 implies that the rule is tied to a class that is a direct superclass of the current class. Rules for a class always take precedence over superclass rules. An Allow object-level rule takes precedence over any other object-level rule. An Allow class-level rule takes precedence over any other class-level rule. An Allow class-level rule never takes precedence over any object-level rule. If there is no specific class-level rule or object-level for a class or any of its superclasses, the inclusion hierarchy is used for Data Scoping evaluation. That is, the topology of the network is used for evaluation. Rules are evaluated for the parent folder of an object. If the rule applies to the parent, it applies to all children within the folder. If the parent folder has no rule that applies, its grandparent is searched, then its great grandparent, and so forth. Objects that are in multiple folders where one folder has a Deny rule, and the other an Allow, the Allow takes precedence.
Examples
Example 1
For the following two rules, Rule 1 takes precedence:
Rule1: Deny Delete on Windows where the label equals Machine1 for User1. Rule2: Allow Delete on Windows for User1.
Example 2
For the following two rules, Rule 1 takes precedence:

Rule1: Deny Delete on Windows for User1. Rule2: Allow Delete on ManagedObject for User1.
Example 3
For the following rule, Machine1 in subnet 192.168.255.0 is denied access for delete: Rule1: Deny Delete on IP_Subnet where Name=192.168.255.0.
Example 4
For the following rules, and if Machine1 is in subnet 192.168.255.0 and class Windows, Rule2 takes precedence.

Rule1: Allow Delete on IP_Subnet where name=192.168.255.0. Rule2: Deny Delete on Windows where Name=Machine1.
Example 5
For the following two rules, and if Machine1 is on subnet 192.168.255.0, Rule 2 takes precedence:
Rule1: Deny Delete on IP_Subnet where Name=192.168.255.0.
259
Rule2: Allow Delete on Business Process View BPV1 where Machine1 is in BPV1.
Example 6
For the following three rules, Rule1 takes precedence over Rule3 for Machine1 in BPV Atlas:

Rule1: Class = ManagedObject /Deny/create+update+delete/User=user1 Rule2: BPV/Deny/All/User=User1 Rule3 BPV/Allow/Read+Update/User=User1/Name=Atlas
Since Rule1 is a class inheritance rule, it takes precedence for objects within the BPV named Atlas over the inclusion inheritance rule Rule3. To allow update access for all objects within the BPV Atlas, Rule1 should be changed to the following: Rule1: Class=ManagedObjectRoot/Deny/Create+Update+Delete/ Name=ManagedObjectRoot/User=user1
Rule Performance Issues

Data Scoping rule evaluation can significantly degrade performance because of inclusion inheritance rules. For every object where access is evaluated, all ancestors of that object are also evaluated if no Data Scoping rules apply to that particular object. The performance degradation is caused by the object-based rules defined in the class hierarchy. This is due to the fact that an object must be constructed by issuing SQL queries as the topology is traversed. Limiting object-based rules at a lower level in the class hierarchy can reduce this database overhead. For example, if the following rule is defined on the class ManagedObject, and the managed objects are Windows 95 or Windows NT machines, then the rule should be defined on the Workstation class Rule1: Deny delete for address=172.168.34.45 or address=172.168.34.46
Data Scoping from Outside Unicenter NSM

Data Scoping is designed to be a complete solution. Since the repository can be accessed with tools that are not part of Unicenter NSM, the possibility of a security breach exists that Data Scoping cannot defend against on its own. However, you can take steps to ensure security no matter how the repository is accessed. The following topics describe how you, as repository administrator, can implement end-to-end Data Scoping in Unicenter NSM.
260
Administrator Guide
Create Database User ID A database user ID (either the Windows user ID or the SQL Server user ID) must be defined to the database server before you can access the repository. However, you should create the user ID with the following attributes:
No SELECT, UPDATE, INSERT, or DELETE privileges for any table in TNGDB. No privileges to run any stored procedure defined for TNGDB. No membership in any Windows Group or any SQL Server role that has complete access to TNGDB.
The user ID is then not able to write any embedded or dynamic SQL applications that access the TNGDB database and cannot access the repository through external tools such as the SQL Query Analyzer. The only way to write an application to access the repository can be through using the WorldView Application Programming Interface (API). Since all Unicenter NSM applications access the repository through the WorldView API, they are assured complete access to the repository. If Data Scoping is deactivated, this user ID should have full database privileges restored. To access the repository, the database user ID must be defined to the Advantage Ingres database server. However, you should create the user ID with the following attributes:
No SELECT, UPDATE, INSERT, or DELETE privileges for any table in TNGDB. No privileges to run any stored procedure defined for TNGDB. No membership in any UNIX/Linux group or any Ingres role that has complete access to TNGDB. The user ID must consist of all lowercase characters.
The user ID is then not able to write any embedded or dynamic Ingres applications that access the TNGDB database and cannot access the repository through external tools such as Ingres SQL. The only way to write an application to access the repository can be through using the WorldView API. Since all Unicenter NSM applications access the repository through the WorldView API, they are assured complete access to the repository. If Data Scoping is deactivated, this user ID should have full database privileges restored. Create Data Scoping Rules To restrict access to users who write applications using the WorldView API, or who use Unicenter NSM tools, you should create Data Scoping rules for those users whose access needs to be restricted.
261
When the rules are saved in the repository for which access needs to be restricted, Data Scoping enforcement is complete for all Unicenter NSM applications. Applications that are not using Unicenter NSM are denied complete access to the repository because of the precautions you set up when you created the database user ID. Maintain Data Scoping Security Data Scoping security is an ongoing process. You can update and delete rules. You can remove DataScope classes to completely deactivate Data Scoping. On Windows, when you update Data Scoping rules, they are enforced immediately (except for the conditions noted in the following topic, Data Scoping in the 2D Map). On UNIX/Linux, when you update Data Scoping rules using the scputil command, they are enforced immediately.
Data Scoping in the 2D Map (Windows Only)

Because of the unique design of the 2D Map, Data Scoping works differently from other Unicenter NSM applications. Data Scoping rules for all other Unicenter NSM applications are enforced immediately after they are created. Data Scoping in the 2D Map has the following unique features.
Delta Mode
Objects in the 2D Map are loaded when the folder containing the objects are opened. If Data Scoping rules for READ access are created before opening a folder containing objects where Data Scoping rules exist that affect these objects, the Data Scoping rules are enforced. The objects are visible or hidden on the map depending on the rules. If rules are created after opening the folder, the Data Scoping rules are not enforced because all the objects for the folder have been read into the map and are not re-read until the 2D Map is restarted. Rules controlling CREATE, UPDATE, and DELETE access are always enforced immediately after the rule is created. The 2D Map does not need to be restarted in these cases.
Non-Delta Mode
All objects in the 2D Map are loaded when the 2D Map is started. Therefore, any Data Scoping rules you create that affect READ access are not enforced until the 2D Map is restarted. Rules controlling CREATE, UPDATE, and DELETE access are always enforced immediately after the rule is created. The 2D Map does not need to be restarted in these cases.
262
Administrator Guide
Troubleshooting on UNIX/Linux
You may find the following topics helpful when using Data Scoping on UNIX/Linux. Changing the Inbound and Outbound Session Limits If you get an error stating that inbound or outbound connections have exceeded their limits, you may want to increase the limits for the inbound_limit and outbound_limit parameters. To view the current values for these parameters, use the following commands:
iigetres ii.hostname.gcc.*.inbound_limit iigetres ii.hostname.gcc.*.outbound_limit
To change the values for these parameters, use the following commands:
iisetres ii.hostname.gcc.*.inbound_limit nnn iisetres ii.hostname.gcc.*.outbound_limit nnn
Use the following formula to calculate the maximum number of connections that can be supported at any given time:
inbound_limit + outbound_limit <= (nofiles - 14)/2
where nofiles is the number of file descriptors allocated for each process. Note: To set the values for inbound_limit and outbound_limit each to 128, set the kernel parameter NOFILES to at least 526. If you change these settings after you start a communications server, you must stop and restart the Advantage Ingres server for the new limits to take effect. For more information about these parameters, see the Advantage Ingres System Administrator Guide.
263
Permissions for Jasmine Catalog By default, non-root users do not have access to the Jasmine Catalog. If you run Unicenter Explorer (uniexplorer) as a non-root user, you may experience problems with permissions on the Jasmine Catalog. The following error appears:
Transaction Commit Failed during Installation of Modifications. Reason: <date> E_GW0001_COULD_NOT_OPEN Could not open store file: $JI_SYSTEM/files/catalog.dat on host <hostname>. Reason: Permission denied.
To correct this error, run the following command:

chmod 666 $JI_SYSTEM/files/catalog.dat
You may also need to change the permissions on the $JI_SYSTEM/files directory. To correct this error, run the following command:
chmod 777 $JI_SYSTEM/files
264
Administrator Guide
Chapter
Agent Technology
To facilitate comprehensive and integrated network polling and administration, Unicenter NSM uses Agent Technology to automate manager tasks and responses to events. Agent Technology monitors and reports the state and status of machines and applications. Agent Technology lets you monitor resources (also called managed objects) as well as the applications. The status of these devices is displayed on the 2D and 3D Maps.
Understand Agent Technology

Agent Technology expands your ability to monitor and control your enterprise. Agent Technology uses numerous levels of implementation to enhance your monitoring capabilities.
Agents
An agent is an application that supports network management. An agent typically resides on a managed software node, such as a Windows NT server or workstation, and provides information to a management application. This information is interpreted according to a management protocol that is understood by both managers and agents. Unicenter NSM agents use the following management and communications protocols: Protocol Communications Protocol Network Management Protocol Definition User datagram protocol (UDP) of the transmission control protocol/Internet protocol (TCP/IP) suite. Simple network management protocol (SNMP) designed to run on top of TCP/IP.
Both agent and management applications can view the collection of data items for the managed resource. This collection is defined by the management information base (MIB). Each MIB describes attributes that represent aspects of the managed resource. The network management platform accesses MIB data using SNMP.
Agent Technology
31
Neugents Computer Associates leading technology Neugents are an optional add-on that provides advanced monitoring capabilities. Instead of using a fixed set of conditions you have explicitly defined, Neugents use pattern recognition to identify conditions that raise alarms or are unusual. The Neugent monitors combinations of events and issues alarms based on complex correlations. Note: Neugents may require agent installation. Agents, Neugents, and Unicenter NSM Agents use many of the components of Unicenter NSM to report and act on events. The agent is installed on a resource and reports events to the Distributed State Machine (DSM). The DSM processes this information and reports the results to WorldView, Event Manager, DSM View, and Node View. Similarly, the DSM receives instructions from Event Manager, processes this information, and passes instructions to the agent.
Distributed State Machine (DSM)

Every agent must be associated with at least one DSM. Through configuration, you can determine which machines in your enterprise report to a DSM. Each DSM can communicate with only one repository, but a single repository can accept information from multiple DSMs. The Distributed State Machine layer consists of several components that can be started and stopped independently. These components include the following: Component Distributed Services Bus SNMP Gateway Object Store DSM Definition Manages communications for all the other Agent Technology components. Manages communications to and from SNMP agents. Stores class data on managed objects. Controls the discovery of managed objects and converts data into current object states. Manages communications to and from the repository.
WorldView Distributed State Machine Gateway
32
Administrator Guide
For more information about DSM components, see the Working with Agents guide.
Managed Objects
Each resource that an agent monitors is called a managed object. A managed object can represent a physical device, such as a printer or a router, or it can represent an abstraction, such as the combination of hardware and software components that constitute a network connection between two nodes. A managed object can be monitored and, in some cases, controlled with the use of one or more management applications. Unicenter NSM groups managed objects into classes. A class is a group of managed objects that share a common definition, and therefore, share common structure and behavior. By changing the behavior of a class, you can change the behavior of the managed objects that belong to that class. The definitions for each Agent Technology agent class are in the individual agent policy files. For more information about policy files and their syntax, see the Working with Agents guide. For more information about a specific class of managed object, see the individual agent guide.
States
Every managed object has a state. A state is one of a set of predefined possibilities for the condition of the managed object (for example, up, down, or unknown). A change in state appears on the 2D and 3D maps of WorldView as a change in icon color. You can drill down through the network, to the machine, to Unispace, and to the agent that caused the state change. From the pop-up menu associated with the agent, you can view the state of the agent according to the DSM (Node View) or according to the agent (Agent View). Each layer of Unicenter interprets the state of a managed object differently, placing an emphasis on different aspects of the object. For example, a Windows NT server may be taken off-line for repairs. The Windows NT System agent stops sending information to the DSM. The state of the agent according to the DSM is Absent, emphasizing the fact that no information is being relayed. However, the state of the agent according to WorldView is Down, emphasizing the fact that the server is inaccessible.
Agent Technology
33
Agent States The agent collects data about its managed objects. The agent sends this data to the DSM and any associated Neugents. Based on the rules defined in the agent configuration set, the agent processes the data and determines the state of each managed object. This state is displayed in Agent View. For more information about the agent configuration sets, see Configuring Agent Technology, Agent Level. Neugent States The Neugent collects data and combines this data in hundreds of different ways. Neugents recognize patterns in the way certain resources are used. Patterns are recurring combinations of certain data values. Patterns represent various states that may exist in your system. Neugents group patterns together into common modes. Common modes represent groups of patterns of resource values that are similar. The Neugent sends this data to the DSM. This mode is displayed in Neugent View. DSM States The DSM collects data sent by an agent or Neugent and processes it to determine the state of its managed objects. Based on the evaluation rules defined by the agent/Neugent policy files, the DSM processes the data and determines the overall state of each agent/Neugent and its managed objects. The DSM sends the information about the overall state of the agent/Neugent to the repository. The states of the agent/Neugent and its managed objects are displayed in Node View. For more information about agent and Neugent policy files, see Configuring Agent Technology, DSM Level. WorldView States The repository collects data sent by the DSM and translates it into agent/Neugent states on the 2D and 3D maps of WorldView. For more information about using WorldView, see the chapter Advanced Visualization.
34
Administrator Guide
Configure Agent Technology

You can change the way agents and Neugents handle information on three levels:

Agent Level DSM Level WorldView Level
Agent Level
The agent layer of Agent Technology collects data about your enterprise. You can configure this layer to monitor as many resources as you require. For example, with the Windows NT System agent, you can specify both that file systems will be monitored, and the exact name of the file systems to be monitored for this machine. You can configure the following components of the agent layer: Component SNMP Administrator Agent Configuration Sets trap and community string values. Sets MIB threshold and alarm values.
For more information on configuring at the agent level, see the individual agent guide.
Agent Technology
35
DSM Level
The DSM layer of Agent Technology manages your agents. The DSM interprets data collected by agents then makes that information available to applications such as the WorldView Maps and Node View. You can configure this layer to report any combination of resources you require. For example, the Windows NT System agent monitors both Windows NT servers and Windows NT workstations. If you do not want to monitor the Windows NT workstations, you can remove the Windows NT workstations class from the DSM policy files. Therefore, even if a Windows NT System agent on a Windows NT workstation reports to the DSM, the DSM ignores the data. You can configure the DSM layer using the following techniques: Component Policy files Pollsets Dynamic configuration State change correlation Configuration Sets trap and community string values and defines object classes, state propagation, and event initiation. Sets MIB threshold and alarm values. Sets some policy aspects dynamically using awm_config or the CORRELATE message action Relates previously unrelated state changes.
WorldView Level
The WorldView layer of Agent Technology represents your entire Unicenter NSM enterprise. This layer contains the WorldView Maps through which you can view all of your monitored resources and their relationships, such as which agents appear on which nodes. You can configure the following components of the WorldView layer: Component WorldView policy WorldView DSM Gateway Configuration Defines status representation and severities. Filters the list of discovered nodes and determines which devices the DSM monitors.
36
Administrator Guide
View Agent Technology

When WorldView detects a problem in your network, you must locate the specific managed object causing the problem. Unicenter NSM provides a number of interfaces to view and modify agent and Neugent status. Agent Technology provides the following graphical interfaces to help you view and manipulate your data: GUI Agent Technology Services Manager Agent View Distributed State Machine (DSM) View Event Browser Global Configuration Utility (GCU) MIB Browser Node View Description Displays the status of the DSM components. Agent Technology Services Manager lets you start and stop individual agent technology components. Displays a customized view for an individual agent. Agent View lets you view the status of the agent and set configurable attributes. Displays the managed objects for an individual DSM. DSM View lets you find objects and manage properties associated with managed object classes in the domain. Displays detailed information about the events that have affected the status of an object. Event Browser also provides a record of warning messages being sent. Displays all the nodes and agents of a network. The GCU lets you distribute configuration files to remote agents, create new configuration files, and copy, rename, and edit existing configuration files. Displays an entire agent MIB. MIB Browser lets you set configurable attributes, such as threshold values. Displays the managed objects on a node in tree form. Node View provides both the overall status of the node and the status of individual agents and managed objects. Displays a list of pollsets currently defined in the WorldView Repository. Pollset Browser lets you view, add, change, and delete pollsets from the WorldView Repository. Displays the results of a ping. Remote Ping lets you ping any host from any other host on your network. If your network is spread over several physical locations, you can conveniently test all nodes from any host. Displays the subclasses under the specified agent class in the repository. Repository Monitor lets you easily monitor the agents in the repository. You can view and delete a complete list of objects for a specified agent class. Displays SNMP traffic handled by the SNMP Administrator component. Displays agent and Neugent status across the entire enterprise. For more information about WorldView, see the chapter Advanced Visualization.
Pollset Browser
Remote Ping
Repository Monitor
SNMP Administrator WorldView
Agent Technology
37
Agent Technology Services Manager

Agent Technology Services Manager shows the status of the DSM components. In addition, this GUI lets you start or stop the following DSM components.

Service Control Manager (awservices) Distributed Services Bus (aws_orb) SNMP Gateway (aws_snmp) Trap MUX (aws_listen) Object Store (aws_store) DSM (aws_dsm) WorldView Distributed State Machine Gateway (aws_wvgate)
You can access Service Control Manager from Start, Unicenter TND, Agent Technology, Service Control Manager.
38
Administrator Guide
Agent View
Agent View provides a user-friendly interface for configuring an agent. Agent View contains several windows that reflect the different sets of monitored agent resources. Within each window, you can set configurable attributes such as adding and deleting resources to monitor, setting warning and critical threshold values, and setting resource polling intervals. The following window shows a view of the Windows 2000 Agent View:
You can access Agent View for an agent by right-clicking an agent in Unicenter Explorer, WorldView Classic, or Node View, and selecting View Agent from the pop-up menu.
Agent Technology
39
DSM View
DSM View lets you find objects and manage properties associated with managed object classes in a management domain. You can create new properties for a managed object, as well as modify the values of existing properties. Note: You can also use the DSM Wizard to modify a selected subset of property values for all discovered instances of specific agent object classes.
You can access DSM View from Node View in either of the following ways:

From the menu bar, choose Edit, Find Object. Click the Find Object (microscope) button.
310
Administrator Guide
Event Browser
The Event Browser provides detailed information about the events that have affected the status of an object, including the following:

State changes Creation of an object Deletion of an object
With this information, you can determine patterns of activity. For example, the Event Browser shows that an object moves from a NORMAL to a CRITICAL state once every hour. You can use this pattern to determine the cause of the problem with the object. The Event Browser also provides a record of warning messages being sent.
You can access Event Browser by right-clicking an object in WorldView Classic or Node View, and selecting Event Browser from the pop-up menu.
Agent Technology
311
Global Configuration Utility

The Global Configuration Utility (GCU) lets you distribute configuration files to remote agents from a centralized location. This utility lets you create new configuration files as well as copy, rename, and edit existing configuration files. Files can be assigned to individual agents or groups of agents (by node). When a profile is assigned to a group of nodes, this profile applies to all agents of a type in all the nodes belonging to the group. In addition, the GCU can verify whether the agent is still using the assigned configuration file. During verification, any configurable parameters that have been changed outside of GCU are replaced by the values prescribed in the assigned configuration file. When the GCU updates or cannot update an agents configuration, a message is sent to the Event Console.
You can run the GCU GUI from any Internet browser. Start your Internet browser and go to htttp://GCU_server_machine_name /gcu/gcu.html. Note: You can use the IP address of the GCU server instead of the GCU server name.
312
Administrator Guide
Connect to the GCU server using the GCU servers Windows user ID and password. The GCU GUI opens in a separate window outside of the browser.
MIB Browser
MIB Browser lets you view the agent MIB in a tree-like hierarchy. If you are familiar with a particular agent, you may prefer to use MIB Browser to set configurable attributes, such as threshold values. MIB browser shows an agents entire MIB as it appears in the file whereas Agent View provides a graphical representation of the MIB.
You can access the MIB Browser by right-clicking an agent object in WorldView Classic or Node View, and selecting MIB Browser from the pop-up menu.
Agent Technology
313
Node View
Node View builds an object tree from the information provided by the DSM. Node View acknowledges status change from the DSM by changing icon colors. Status propagates up through the Node View treethat is, the most severe status reported by a child object propagates up to the parent object. Notes: 1. 2. You can change DSM policy to affect the way DSM states are displayed in Node View. The awsadmin icon represents the SNMP Administrator. If you expand this icon, you can view the MIB names of the agents currently running. If the MIB name for an agent is not present, that agent is not currently running.
You can access Node View by right-clicking an agent object in the WorldView Classic, and selecting View Node from the pop-up menu.
314
Administrator Guide
Pollset Browser
Agent policy uses pollsets to let you set the properties that are used by the Distributed State machine to discover and manage an agent. The Pollset Browser lets you view, add, change, and delete pollsets from the WorldView Repository. Note: This interface displays the pollsets that can be used by the DSM, but does not poll the agents.
You can access the Pollset Browser from Start, Unicenter TND, Agent Technology, Pollset Browser.
Agent Technology
315
Remote Ping
Remote Ping lets you indicate the IP addresses of the source and destination machines and to establish retries and timeouts for the poll. In addition, you can view the activity of the Distributed Services Bus where the poll originates.
You can access Remote Ping from Start, Unicenter TND, Agent Technology, Remote Ping.
316
Administrator Guide
Repository Monitor
Repository Monitor lets you easily monitor the agents in the repository. You can view and delete a complete list of objects for a specified agent class. Note: Advanced users can also delete the class name.
You can access the Repository Monitor from Start, Unicenter TND, Agent Technology, Repository Monitor.
Agent Technology
317
SNMP Administrator
The SNMP Administrator checks the community string and Internet Protocol (IP) address of get, get-next, and set requests to make sure these requests come from authenticated management applications. This component forwards trap messages to the appropriate destinations. The SNMP Administrator stores configuration sets and MIB definitions for each agent on the node in memory.
You can access the SNMP Administrator by right-clicking the AWsadmin object in Node View (if this object exists for the node) and selecting View Agent from the pop-up menu.
318
Administrator Guide
Verify Agent Status
Verify Agent Status

The status of some managed objects can fluctuate to reflect activity around threshold levels. For example, processor usage may be critical during one interval (represented by a red icon) and fine the next (the icon returns to bright green). To verify the status of an object, follow these steps: 1. 2. 3. Confirm the current status View the sequence of events Edit Managed Objects
Confirming the Current Status

To ensure that an icon color in Node View reflects the current status of the managed object, you can poll the DSM. To poll the DSM, choose Options Poll from Node View. When the status of a managed object on the node changes, the DSM automatically sends a message to Node View at predefined polling intervals. However, by polling the DSM you can update the status before the next polling interval.
Viewing the Sequence of Events

After verifying the current status, you can use Event Browser to display a log of events that affected the status. Event Browser displays all state changes and the reason for the change, recorded for the selected object and its children. It receives information about the causes of state changes in real-time, so its event log is updated whenever a new state change occurs. To start Event Browser, follow these steps: 1. 2. Right-click the managed object from the Node View main window. Choose Event Browser from the pop-up menu.
Since Event Browser lists events in real-time, the display window changes continuously. To freeze the display of the event log list temporarily so you can examine the details of a particular event, choose Edit Pause. This action affects the display of events onlynot the collection of events. When you finish, choose Edit Resume to return to real-time updating. You can sort and filter Event Browser information. See the instructions for sorting and filtering in the online CA Procedures under the following topics:

Sorting Event Browser Information Filtering Event Browser Information
Agent Technology
319
Correlate Events
Editing Managed Objects

After you have verified your status and discovered the problem, you may discover that the threshold for the problem object is too low. See the instructions for changing threshold values in the online CA Procedures under the following topics:

Changing Attribute Values in MIB Browser Windows Setting a Single Attribute Value Setting Multiple Attribute Values
Correlate Events
Correlation is the ability to relate two or more previously unrelated events. This ability significantly enhances the usability of Unicenter NSM by letting you customize alerts and actions for your installation. For example, if you have three mission-critical web servers, you need to be alerted if two of the servers reach critical status. With message correlation, you can alert technicians when this critical situation occurs, without having to monitor each server separately. Using state change correlation, you could add a state to individual agents to indicate your router is down, avoiding confusion about unknown agent states. Similarly, you could create a new Node View object that has states based on multiple agents, such as SQL and Windows NT, to produce information that relates specifically to your monitoring needs, and sends messages based on the new states. Unicenter NSM supports the following types of correlation: 1. Message Correlation Message correlation uses the CORRELATE option in the Event Console to take action on two or more messages. All processing for this type of correlation takes place at the Event Console and can take advantage of messages issued from all Unicenter components. 2. State Change Correlation State change correlation uses code within the Distributed State Machine policy files to relate event and response messages from agents to state changes. All processing for this type of correlation take place at the Distribute State Machine and can only use event and response messages from the agents. You can use these types of correlation separately or together, to distribute processing time and usage. For more information on using these types of correlation together or separately, see the Working with Agents guide.
320
Administrator Guide
Use Network Monitoring

The SNMP data collected by the DSM regarding the status of network components is also available through additional network monitoring facilities provided by Unicenter. These facilities provide additional information and updates that can be useful in diagnosing network problems.
Polling
Polling is a method of sending a message to a machine on your network to test the status of that machine. Unicenter NSM provides the following ways to use polling:

IP Demand Polling Remote Ping IPX Ping
You can also change the way Unicenter NSM polls network devices. You can set multiple system default values, and set defaults based on IP address, agent class, device class, and device name. If you can have more than one agent for a device, you may have different polls set for each agent and device. See the instructions for configuring polling in the online CA Procedures under the topic, Configuring Your Polling Interval.
Agent Technology
321
IP Demand Polling IP demand polling lets you immediately poll any device and update the status in the Common Object Repository. When you use the IP Demand Poll dialog, one of the following messages appears:
Message
Cause
No DSM for this node. The node is not assigned to a DSM. In the Managed Object Notebook, check the Check the properties of status of the node by viewing the Administrative Status check box. this node Failed Connecting to the DSM The connection to the DSM failed. This situation occurs for one of the following reasons:
The network connection between IP Demand Poll and the DSM is down. Check the network connection between these machines in WorldView. The DSM machine is down. Check the status of the DSM machine in WorldView. The Distributed Services Bus on the DSM is not running. Check the status of the Distributed Services Bus in the Service Manager dialog.
Ping failed
The node is connected to the DSM, but the ping failed. This situation occurs for one of the following reasons:

The node is down. Check the status of the node in WorldView. The network connection to the node is broken. Check the network connection between these machines in WorldView.
This Node is Alive
The ping was successful. The message displays the system OID and MIBII information, including description, and system up time. See the instructions for using IP demand polling in the online CA Procedures under the topic, Polling an IP Device On Demand.
Remote Ping Unicenter NSM lets you poll a remote host from another host. The Remote Ping interface lets you indicate the IP addresses of the source and destination machines and to establish retries and timeouts for the poll. In addition, you can view the activity of the Distributed Services Bus where the poll originates. You can request a Remote Ping from the Event Console, the 2D Map, or the command line. For more information on polling a remote host, see the Remote Ping online help.
322
Administrator Guide
IPX Ping Unicenter NSM lets you ping an IPX object at any time from within the 2D or 3D Maps or the Object Browser. See the instructions for using IPX Ping in the online CA Procedures under the topic, Ping an IPX Device.
Checking Interface Connectivity

Sometimes you may need to know whether a device is completely down or just unreachable on a single route. This information is particularly useful for routers and multi-homed devices that may be reachable through multiple connections or interfaces. Unicenter NSM provides a utility, routechk.exe, which can determine which device interfaces are connected to the network. The routechk.exe utility polls the specified device in the Common Object Repository using a ping. If the poll fails, the utility identifies all the interfaces included under the device and polls each of those interfaces. If an interface responds to the poll, the utility updates the device object with the address of the interface that was successfully polled. To determine how many interfaces of a device can be successfully polled, use the I ON parameters for routechk.exe. The utility returns the number of responsive interfaces. Note: The I ON parameter does not perform updates to the Common Object Repository if an object is initially unreachable by its default address, but can be contacted on one of its interface addresses. This utility is started at the command line and can be found in the following directory:
Install_Path\NSM\bin\routechk.exe
For more information on routechk.exe, see the online CA Reference.
Agent Technology
323
Chapter
Performance management is an important aspect of total systems management. You gain control over your computer systems through value-added information relating to their performance. To achieve an effective performance management strategy, it is important for the systems administrator and capacity planner to address two fundamental concerns:
The day-to-day management of unexpected performance problems across the enterprise The ability to perform long-term planning and trend analysis
These concerns present numerous challenges. On a daily basis, you need confirmation that your systems are performing according to expectations. Any systems problem in your enterprise must be brought to your attention immediately and automatically. Once you are aware of the problem, you need to be able to identify its nature and cause. The timely resolution of problems requires special tools to do the following:
Monitor the key parameters that influence performance of your systems and applications. Compare what is actually happening against a set of predefined operational parameters.
You must also consider performance management from a capacity planning perspective to determine the most efficient use of your computer resources. For example, capacity planning examines how busy each server is, which servers are overused or underused, when machines are being used, whether usage is increasing or decreasing, and where bottlenecks occur. Capacity planning addresses the collection, aggregation, and analysis of performance metrics such as response time, throughput, and concurrence. While not an exact science, capacity planning involves the use of mathematical and statistical techniques.
41
How Performance Management Works
Performance Management is available on Windows NT and Windows 2000. The Performance Agents provide monitoring capabilities for many different platforms, including Windows, all major UNIX platforms, all major Linux platforms, and NetWare. The Performance Management front-end components Performance Configuration, Performance Scope, Performance Trend, and Chargeback are available on Windows. Additionally, a cut-down Java version of Performance Scope is available through the Unicenter Explorer or Unicenter Browser on UNIX.

Performance Management provides the tools to extract performance data and present it in a spreadsheet format, making it possible to see trends that have occurred over long periods of time and to compare one machine with another. Performance Management comprises four components that present computer usage and performance data in an easy-to-comprehend, graphical form. These components are listed following:
Performance ConfigurationLets you configure Performance Agents and Performance data gathering policies (profiles) across your enterprise. Using the Performance Configuration main GUI, and other graphical configuration tools, you can implement and administer these policies from a central location in a multi-tiered architecture. This architecture may consist of nested configuration servers within each configuration domain. Other features of Performance Configuration include network topology views of machines and device classes, a centralized configuration database, concurrent client configuration support, a built-in security model, one click Associate MIB and Profile Creation wizards, tabbed notebook dialogs, and backward compatibility with earlier Performance Agents. Performance ScopeProvides a real-time view of performance for the components of managed systems. Systems administrators and support technicians can seamlessly join real-time and historical data to merge current and past performance information for any resource. The ability to go back in time allows you to pinpoint exactly when a problem first appeared. Each view may include the performance of several different resources, or you may have multiple views monitoring many machines. Performance TrendFacilitates capacity management by providing historical performance and usage information in a spreadsheet where it can be displayed and analyzed. A series of predefined charts is provided for load and go functionality. ChargebackAllocates resource accounting data obtained from heterogeneous platforms across the enterprise to real-world charge groups. The ability to identify and track the use of each distributed system by individual users allows you to allocate charges, maintain budgets, and generate billing invoices and reports.
42
Administrator Guide
Performance Management lets you view and configure performance and resource usage information collected by the Performance Agent and Resource Accounting Service. The following sections describe this agent and service and the type of information they collect.
Performance Agent
Performance Management employs the Performance Agent to collect performance-related data on the distributed systems. The agent collects information from a variety of systems and database resources for many platforms, including Windows 2000, UNIX/Linux, and NetWare. The performance information collected varies by environment. There is no limit to the number of devices that the Performance Agent can monitor. However, the number of monitored devices can be affected by the following:

Processor speed of the collection machine NIC card speed of the collection machine Available network bandwidth Number of metrics (OIDs) being monitored by each device
Listed following are some of the resources available for performance monitoring. For a complete list of resources, see the Performance Scope online Help.
UNIX/Linux Platforms
The Performance Agent collects the following information in a UNIX/Linux environment:

CPU Utilization Disk Information File Access Information Buffer Activity System Call Statistics Memory Freeing Activity Message and Semaphore Activity Paging Activity Queue Length Memory Usage Swapping Activity Terminal Activity
43
Total Logged in Users Filestore Usage Process Information
Windows NT Windows 2000
The Performance Agent collects the following information in a Windows NT and Windows 2000 environment:

System Processor Memory Cache Physical Disk Logical Disk Process Thread Objects SQL Server SQL Server-Log SQL Server-Users SQL Server-Locks SQL Server Replication-Published DB Redirector Server Server Work Queues Paging File Browser NetBEUI NetBEUI Resource NBT Connection
NetWare
The Performance Agent collects the following information in a NetWare environment:

Logged-In Users Connections In Use Total Number of Reads Total Number of Writes
44
Administrator Guide
Total KBytes Read Total KBytes Written Open Files Total Packets Received Total Packets Transmitted CPU Utilization Cache Buffers Dirty Cache Buffers Code and Data Memory Allocated Memory Free Space on the Volume Purgeable Volume Space Non-purgeable Volume Space File Cache Hits Free Redirection Area Bindery Queue Jobs Service Process Count Mirrored Status
Using a three-dimensional model for data management, the agent stores the collected performance information locally, reducing the load on the machine that monitors and manages resources across the enterprise. Additionally, the agent footprint is small, thereby placing minimal demands on the systems being managed.
Resource Accounting Service

A secondary task for the Performance Agent is to collect, format and deliver daily summaries of the resources used on a system to the Performance Management Chargeback accounting tool. For most supported platforms, the Performance Agent can collect this summarized resource usage data directly from the native operating system, through the facilities that it provides. For other platforms where these facilities are not available, such as Windows NT and Windows 2000, it is necessary to introduce the Resource Accounting Service to run continuously in the background, collecting and summarizing this data. The data is again collected and delivered by the Performance Agent.
45
The following table lists the resources measured by the Resource Accounting Service for Windows NT. Resource Measured Number of reads Description The number of times the system has issued a read instruction. The actual read may have caused either a physical disk read or a cached read. System paging that was caused by the user is not measured within this counter. As previous but the total bytes read. The number of times the system has issued a write instruction. The actual write may have been flushed straight to disk or cached in memory. System paging that was caused by the user is not measured within this counter. As previous but the total bytes written. Total number of processes that the user has created. Total number of processes that was terminated by the user. Total duration of all the users processes in 100nanosecond intervals (10,000,000/th of a second) Total kernel time taken up by the user in 100nanosecond intervals (10,000,000/th of a second). Total user time taken up by the user in 100nanosecond intervals (10,000,000/th of a second). Total jobs that have been printed. Total jobs that have been deleted due to system/printer failure. Total pages printed. Total bytes printed. The summation of the highest amount of virtual memory (in bytes) used by all the processes for that user. The summation of the total amount of virtual memory (in bytes) used by all the processes for that user. The summation of the largest size of the working set (in bytes) used by all the processes for that user.
Total bytes read Number of writes
Total bytes written Processes Created Processes Terminated TOTAL PROCESS DURATION Kernel Time User Time Printed Jobs SYSTEM FAILED PRINT JOBS Printed Pages Printed Bytes Peak Virtual Size
Total Virtual Size
Peak Working Set Size
46
Administrator Guide
Resource Measured Total Working Set Size Minimum Working Set Size Maximum Working Set Size Total Page Fault Count Peak Virtual Size by Process
Description The summation of the total size of the working sets (in bytes) used by all the processes for that user. The summation of the minimum size of the working sets (in bytes) used by all the processes for that user. The summation of the maximum size of the working sets (in bytes) used by all the processes for that user. The total number of page faults caused by all processes for that user. The largest virtual size of a single process (in bytes) for that user.
Peak Working Set Size by The largest working set of a single process (in bytes) Process for that user. Minimum Working Set Size by Process Maximum Working Set Size by Process The smallest working set for any single process (in bytes) for the user. The largest working set for any single process (in bytes) for the user.
Terminology
The section that follows includes Performance Management terminology and information on the Performance Agent that you should become familiar with before using Performance Management.
Associate MIB Wizard
A Performance Configuration wizard used to define the SNMP resources that you want to be made available for collection. One or more chart definitions. A chart definition is a named group of monitored resources and a selected style for chart presentation, such as bar style. Performance Trend provides chart definition sets based on operating system The agent technologies controlling entity in a Unicenter NSM domain. A Performance Configuration server that requests data from the Domain Server and delivers it to the performance agents. Since all data is centralized at the configuration domain server level, the configuration distribution server operates without the need for any local persistent information.
Chart Definition Set
Distributed State Machine (DSM) Distribution Server
47
Domain Server
A Performance Configuration server that holds all configuration data pertinent to the entire configuration domain. Centralizing configuration data simplifies backups and restores, and other data maintenance and disaster recovery procedures. The Unicenter NSM view of a resource that is being managed. A resource, such as a host operating system or swap space, that is being managed. A Microsoft Windows product with spreadsheet features that Performance Management uses to manage, manipulate and display performance data. Familiarity with Microsoft Excel is useful but not required. Performance Trend and Chargeback require Microsoft Excel (not supplied with Unicenter). A simple Performance Configuration GUI that enables you to view and, if necessary, change the configuration of the Performance Agent on a selected machine/device in your enterprise. A machine that is being monitored by the Performance Agent for performance or resource accounting purposes. Only the Performance Agent components are installed on this machine. Performance data is stored in the form of performance cubes. A time-banded data management model that allows data to be stored and manipulated in three planes. A Performance Configuration editor that configures the performance agent for data gathering and management. It simplifies the assignment and modification of configuration options, resource set handling, SNMP monitoring, and monitoring of named processes for existing profiles. The means for configuring the Performance Agent. The profile specifies complete criteria for data collection, including monitored resources, and duration and frequency of data collection. A particular component of a system. Hardware, software, applications, and data are examples of resources. Identifiers in time-banded data used to define the resource. The resource type indicates the general grouping of data, the resource subtype indicates subgroups, and the instance indicates the specific values. A resource is the combination of resource type, subtype, and instance. For example, Disk is a resource type, %busy is a resource subtype, and disc 3-0 is a resource instance. A program in Performance Management that gathers extra data (beyond operating system resource usage) through the Performance Agent. Computer Associates supplies a list of predefined sponsors in the Performance Configuration component.
Managed Object
Microsoft Excel
One Click Configuration
Performance Agent Station
Performance Cube
Profile Editor
Profiles
Resource
Resource Type/ Subtype/Instance
Sponsor
48
Administrator Guide
Accessing the Performance Components
Time-Banded Data
Data that is sampled at fixed, frequent intervals for processing by the Historical Performance Agent. The data collected during each time interval is called time-banded data. A typical example of time-banded data is the amount of time a CPU stands idle in a day.
Accessing the Performance Components

To initiate a Performance Management session, launch the WorldView 2D or 3D Map or the Unicenter Explorer, select a machine object, double-click the object to open its Unispace, then select and double-click a Performance Management object. Alternately, from the Windows NT or Windows 2000 Start menu, click on Programs, then Unicenter, then Performance Management, and choose the Performance Management component.
Performance Configuration
Performance Configuration is a client-server application that provides extensible configuration capabilities from a central point of control. It lets you create and apply configurations (called profiles) to Performance Agents. Once a Performance Agent has received a profile, it knows what performance data to collect, when to collect it, and where to send it. By using the Performance Configuration management GUIs and multi-tiered server components (multiple Configuration Domain Servers and nested Configuration Distribution Servers within each domain), Performance Configuration architecture provides scalability that enables you to create and manage configurations for many thousands of Performance Agents. The Performance Configuration management GUIs can be regarded as thin client interfaces that let you perform configuration operations from any workstation. The GUIs employ the latest design styles and techniques to ensure they are easy to use, engaging, and intuitive.
Understand the Architecture

Todays eBusiness environment is typically made up of a large and disparate collection of machines and devices distributed across a wide geographic area. The Performance Configuration architecture supports such a distributed environment effectively by providing high levels of scalability, and facilitating the configuration of Performance Agents across many thousands of nodes.
49
Furthermore, because it is often desirable to define logical groupings within the enterprise and manage each of these groups independently, the architecture implements the concept of multiple Configuration domains. Performance Configuration tiered architecture is constructed using three levels:

Configuration Domain Server (one for each Configuration domain) Configuration Distribution Servers (nested within each domain) Performance Agents
The following diagram illustrates this architecture.
410
Administrator Guide
Client/Server Relationship and Functionality The primary purpose of the Performance Configuration servers is to provide scalable, distributed configuration management. By using a tiered fan-out architecture, Performance Agents report to the Distribution Servers that, in turn, report to the Domain Servers. The Domain Server stores configuration polices where you can use the client GUIs to review and modify them. The Domain Server distributes any configuration changes to the various Distribution Servers for onward distribution to the agents. The Configuration servers execute as persistent services and daemons, which let them react immediately to registration requests from agents (those in which the agent requests the latest version of its configuration profile), and to service instructions from any active client GUIs.
Domain Server
The Domain Server is similar to a file server. It holds all configuration information pertinent to the entire domain. This centralized data simplifies backups, restores, and other data maintenance and disaster recovery procedures. The Domain Server also provides data element access locking and integrity checks, allowing multiple clients to be connected to the Domain Server at the same time, and be actively engaged in simultaneous configuration operations. The clients maintain no persistent information, but instead obtain all configuration and state information from the Domain Server. Therefore, you can perform configuration operations from any workstation that has the Performance Configuration application installed. Furthermore, a client can connect to multiple Domain Servers (not simultaneously), so that you can use a single client to administer multiple domains. The Distribution Server requests data from the Domain Server and delivers it to the Performance Agents. Since the configuration data is centralized at the Domain Server level, Distribution Servers operate without the need for any local persistent information whatsoever. Therefore, Distribution Servers can be regarded as plug and play, and you can install and re-install them without the need to backup and restore data. To ensure that the configuration state of any Performance Agent within the Configuration domain is always known, the architecture implements a handshaking mechanism between the Performance Agents, and the Distribution and Domain Servers. The configuration state of agents at any given time is therefore known to the Domain Server, and is clearly represented by displayed color keys in the client GUI. Within the GUI, the most severe state is propagated upwards, thus letting you drill down within the GUI to quickly determine any machines that are in an undesirable configuration state.
Distribution Server
Performance Agent
411
See the following help topics for detailed information on configuration states:

Color-coded Configuration State Table Performance Agent Extended Status Information
See the section Maintain Configuration Servers and the Performance Agent later in this chapter for more information on the Domain Server, Distribution Server, and Performance Agent. Performance Configuration GUIs Performance Configuration provides the following GUIs:
The Performance Configuration application GUI lets you perform domainlevel configuration from any workstation on which it is installed. The application is split into two sections. The main Performance Configuration Application provides a mechanism for viewing and organizing machines and devices in your enterprise. The Performance Configuration Profile Editor provides all the intelligence for editing the configuration policies (profiles) used on the machines and devices. See the section Configure Your Performance Domain later in this chapter for information on how to use this GUI. The One Click Configuration GUI provides a simple and fast interface to inquire about and, if necessary, change the configuration of the Performance Agent on a selected machine/device in your enterprise directly from the Unicenter Explorer or WorldView 2D/3D maps. See the section Configure a Selected Machine/Device later in this chapter for information on how to use this GUI.
Other Features Performance Configuration also offers a number of other notable features:
The ability to transfer configuration responsibilities for an agent from one Distribution Server to another. Full backward compatibility support for previous versions of Performance Agents An operating system independent approach to configuration, allowing you to use the same monitoring policy to configure machines and devices of mixed systems
412
Administrator Guide
Configure Your Performance Domain

Use the Performance Configuration application GUI to perform domain-level configuration operations from any workstation on which it is installed. It features color-coded representations of the configuration status of the Performance Agents and support for multiple concurrent clients. It uses advanced browser style GUIs to articulate:

Machines and devices that exist across the eBusiness enterprise Customizable configuration groups Performance Management policies
It provides wizards for creating new objects and property pages for updating existing objects. Using this GUI, you can select any of the objects available in your enterprise for configuration. You can navigate to the principal configurable objects (machines and devices, groups, and profiles) by using the treeview in the left pane or the browser-style hyperlinks in the right pane. Additionally, you can use the Address field at the top for navigation. You can change the style of the view in the right pane to an Iconic view, List view, Details view, or Graphical view. Within this GUI, you can select a machine/device and view, modify, or configure Performance data gathering criteria for it. You can invoke the Associate MIB Wizard to quickly include extra SNMP resources to collect for a particular machine/device class. You can also use this GUI to organize machines into multiple logical groups. For example, you can group machines by business process, function, geographical location, and cost center. You can then manage each group independently. Viewing and Maintaining Machine/Device Properties The Machines and Devices branch contains a network topology view of all machines that appear in the Common Object Repository. The Machines and Devices object provides, by default, a view of all the objects in your enterprise. The top level of the network topology view is Machines and Devices. A list of network segments is under the Machines and Devices level. A list of subnets is under each network segment. Each subnet can then optionally display a list of machine classes taken from the Common Object Repository or a list of machines/devices contained within the subnet. If displayed, each machine class contains a list of machines/devices within the subnet belonging to that particular WorldView class. Since the network topology view is derived from information in the Common Object Repository, the hierarchy has exactly the same structure as the hierarchy in the WorldView 2D map and the Unicenter Explorer.
413
Two ways to navigate to a particular machine/device are listed following:
If you know the address details, you can drill down through the network topology tree until you find the machine/device. If you only know the name, you can invoke the Find Machine dialog, which enables you to locate a machine/device simply by typing in the first part of its name. To invoke this dialog, right-click on Machines and Devices and choose Find.
Note: Since this network topology view and Find Machine dialog are replicated in the Performance Scope component, you have a standard interface for viewing machines in both components. Several ways to change the view of machines/devices are listed following:
You can limit the view to only those machines that the Performance Agent is monitoring. You can locate a particular machine/device. You can view machine classes. Note: WorldView classes are displayed for SNMP devices.
You can view certain machine and system properties, such as the machine name, IP address, and Performance Configuration status. You can apply profiles. If a profile has been applied, you can view the profile name, type, and properties. You can view or change the machine group to which a machine belongs.
See the instructions for viewing and editing machine/device properties in the online CA Procedures under the topic, Maintaining Machines and Devices.
DHCP Support
Performance Management supports DHCP name and address changes for version 3.0 and above Performance Agents. Address changes are handled automatically, so no user intervention is required. Name changes require user intervention. Ideally, the machine name used for performance cubes should be constant in order to provide continuity through the historical data. If an agents machine name has changed, the Change button on the Performance Agent tab of the machines Properties dialog is enabled. Press this button to instruct the agent to change its name to the current DNS name. When the change takes effect, the performance cubes are named differently. For example, period cubes are split. Data collected before the name change is in one cube, and data collected after the name change is in another. Performance Management does not support DHCP name and address changes for the following:
Domain Server or Distribution Server machines. These servers should be located on machines with constant names and addresses.
414
Administrator Guide
SNMP devices. If an SNMP device changes name or address, delete the old device and add the new one. Navigate to the devices proxy (the Performance Agent which is collecting the data) and choose Properties. Then click on the SNMP Proxies tab, select the device to be deleted, and press the Remove button. Add the new device in the usual manner. Performance Agents prior to 3.0.
Organizing Machines into Groups The Groups branch provides a different view of your enterprise by letting you group machines based on some meaningful criteria. To realize the maximum benefits available through Performance Configuration, we recommend that you organize computers into groups based on such criteria as business processes or functions, geographic locations, or cost centers. For example, you can create machine groups named Accounting, Human Resources, and Sales. Organizing machines into groups is the easiest way to apply a profile to many machines quickly. Once you have created your machine groups, you can drag machines from the Machines And Devices object and drop them onto the appropriate machine group. A machine can exist in only one group at a time. See the instructions for creating and managing machine groups in the online CA Procedures under the topic, Maintaining Groups. Viewing Profiles for Each Agent Type The Profiles branch contains a sub branch for each supported type of agent (the Performance Agent in this case). Each sub branch contains the profiles for that agent type. A profile provides detailed monitoring and data collection instructions to the Performance Agent, such as which resources to monitor, and the frequency and duration of data gathering. Every Performance Configuration installation provides a generic profile named Default Profile, which enables the Performance Agent to begin monitoring machine resources as soon as you install the agent. Important! Any change to the collection times and collection frequency of the profile used by an SNMP proxy machine also affects the devices being monitored by that machine. See the section Configure SNMP Data Gathering and Proxy Machines later in this chapter. See the instructions for creating and maintaining profiles in the online CA Procedures under the topic, Maintaining Profiles.
415
Discovering Agents If you rebuild the Common Object Repository, use the Discover Agent command to rediscover which machines have the Performance Agents installed.
Registering New Agent Stations
If the Common Object Repository is rebuilt, the Performance classes, methods, and icons will be added but there will be no Performance objects. You need to perform WorldView Auto Discovery and then use the Discover Agents command in the Performance Configuration application to add the Performance objects. Discover Agent queries each machine in the repository to determine if it has an agent and repopulates the repository with all of the Performance objects. Performance Configuration and Performance Scope use the Performance objects. You can also use the Discover Agent command to determine whether the Performance Agents are installed and active on a selected machine. The command queries the agent and waits for a response. When the agent receives a Discover Agent message, it responds with its normal registration message. The Distribution Server picks up the registration message and registers the machine. Once an agent has successfully registered, a Profile icon appears under the machine object. Use the Discover Agent command if the registration message from the agent is missing. Two indications that registration is missing from the agent are listed following:
Detecting Problems with the Agent
You are unable to apply a profile to a machine with a Performance Agent installed without the GUI prompting you to select an SNMP Proxy collector. You are unable to see a machine in the Resource View of the Performance Scope component.
See the instructions for discovering agents in the online CA Procedures under the topic, Discovering Agents and Resources. Discovering Resources Use the Discover Resources command to detect resources that have been added to a selected agent machine. These new resources may have been added by installing new versions of operating systems and new software applications (for example, eTrust Antivirus). The command adds new monitored resources and subtypes to the database used by Performance Configuration and Performance Scope. As a result, all resources available to you will be displayed when using the Full resource set in a profile or while creating a new custom resource set.
416
Administrator Guide
Examples of resources that can be discovered are protocols and other network components such as UDP, TCP, ICMP, IP, Network Interface, Client Service for NetWare, NWLink SPX, NWLink, NetBIOS, NWLink IPX, and FTP Server. See the instructions for discovering resources in the online CA Procedures under the topic, Discovering Agents and Resources.
Configure the Performance Agent

Use the Performance Configuration Profile Editor to configure the Performance Agent for data gathering and management. This editor simplifies the assignment of configuration options, resource set handling (system, database, and SNMP-based resources), and monitoring of named processes for existing profiles. Two ways to start the Performance Configuration Profile Editor are listed following:

Choose Properties on a profile in the Performance Configuration application. Complete the Performance Configuration Profile Creation Wizard.
The Performance Configuration Profile Editor provides wizards for creating new profiles and cube definitions, and property pages for updating existing ones. Note: The Performance Configuration Profile Editor contains all knowledge of the internals of the configuration policy. The main Performance Configuration application has no knowledge of the internals of the profile. This provides a layer of abstraction, simplifying the creation or delivery of the configuration policies. Creating and Maintaining Profiles If you need to create a new profile, use the Performance Configuration Profile Wizard to automate the process. For more information on profiles, see the section Work with Profiles later in this chapter. See the instructions for creating and maintaining profiles in the online CA Procedures under the topic, Maintaining Profiles. Defining Data Gathering Properties When you initially create a Performance profile, you are asked to execute the Performance Profile Creation Wizard to define the primary data gathering properties. You can modify them later if necessary.
417
Performance Agents can collect many thousands of different performance resources across many different platforms. To help in configuring which resources you wish to collect, the Performance Configuration Profile Editor provides the concept of resource sets, which are groupings of resources that you may wish to collect. By default, there are four sets (Full, Extended, Standard, and Minimal). Each set provides a different level of monitoring. If resources are included in a resource set, the Performance Agent automatically collects them. However, the Performance Configuration Profile Editor also provides some additional configuration options for certain types of resources:
Processes. Collecting process resources may result in many thousands of instances being gathered and included in the performance cube. To reduce this number, the Performance Agents provide the option of filtering which processes are collected. You can define this filtering either by a threshold (only include the instance if it is over (under) a given value), or by specifying a wildcard process name. The Process filtering option is available from the Advanced button on the Data Gathering notebook. Sponsors. Performance Agents collect sponsor resources by running special plug-in executables. Examples of sponsor resources are Users and FileSystem resources on Unix and the resources collected by the FrameRelay and SAP options to Performance Management. When the agent runs the special sponsor executables, it gives the executable a defined amount of time (in seconds) to collect the data before it assumes that the executable has failed. If the timeout is too short (for example, if a large number of instances are being collected), you can increase it from the Sponsors configuration dialog, accessed from the Advanced button on the Data Gathering notebook. Another feature of sponsor configuration is the ability to pass optional parameters through to the called sponsor executable. This provides an extra level of configuration that you can use, for example, to limit the filesystem sponsor to collecting information about local filesystems only.
Once you have defined the data gathering policy, you are required to configure the performance cubes that will be collected. The Performance Agent supports the configuration of different types of performance cubes, and the configuration of general management policies, such as end-of-day processing times. The types of cubes and general policies you can define in the Data Management section are listed following:

Daily Performance Cubes Period Performance Cubes Enterprise Performance Cubes
See the instructions for defining data gathering properties in the online CA Procedures under the topic, Configuring Data Management.
418
Administrator Guide
Daily Performance Cubes
The Performance Agent supports configuration of two types of daily cubes:
A Full Daily Cube contains performance data from one machine or device collected over a period of one day. When you create a new Full Daily Cube, you specify to which machine the cube will be delivered, and when the created cube is to be purged. Once you have created a Full Daily Cube, you can modify its properties at any time. Note: You can consider the Full Daily Cube as the master data cube from which all other cubes (Period and Enterprise) are derived.
A Subset Daily Cube is a compact version of the Full Daily Cube. When you create a new Subset Daily Cube, you define the collection frequency, resources, delivery, and deletion requirements. You can modify its properties later if necessary.
Period Performance Cubes
A Period Performance Cube consists of data from one or more Full Daily cubes from different days, joined together to present a picture of the performance of a single machine or device over a period of one or more days. The Performance Agent can create any number of Period Performance Cubes from the base performance data. You can create a Period Performance Cube definition and later modify its properties. When you create a Period Performance Cube, you define the period properties, frequency, resources, delivery, and deletion policy. An Enterprise Performance Cube consists of data from one or more Full Daily Cubes from any number of machines and devices, joined together to present a picture of the performance of those machines over the course of one day. When you create an Enterprise Performance Cube, you define the data sources, frequency, resources, delivery, and deletion policy. You also nominate a Performance Agent machine to act as a collector and one or more machines you would like to be included in the cube. The collector is the machine on which the Enterprise cube is built. You select the collector from a list of collection machines. Collection machines are registered in the Performance domain, have Performance Agents installed on them, and are being managed by the Domain Server to which the Configuration application is connected. You select the machines to be included in the Enterprise cube from a list of source machines. Source machines are those machines and devices discovered in the repository to which Performance Configuration is connected. These machines do not necessarily need to be in the same Performance domain. In order for the Enterprise cube to be created successfully, the machines contained within the cube should have the same data gathering properties (start and stop time, frequency, and collection days) as the Enterprise cube definition. To start Enterprise cube generation, the profile must be delivered to the named collector machine.
Enterprise Performance Cubes
419
At the end of the day, the Performance Agent checks to see if it needs to create any Enterprise cubes. For each Enterprise cube, it gathers source data by doing the following:
Determining if the data exists in its local cube store. (This occurs if the collection machine was specified as a recipient in the source machines profile.) Requesting data from a remote Performance machine.
Once all the data is available, the Performance Agent builds the cube and delivers it to the recipient machines.
General Management Policies
Use the General Management Policies section of the Performance cubes definition to address the end-of-day processing time and the general deletion policy. End-of-day processing indicates when the Performance Agent will perform such tasks as Period Cube and Enterprise Cube building. The general deletion policy indicates when the Performance Agent will delete any cubes that other agents have sent to it, that is, cubes that this particular agent has not built.
Performing Threshold Processing The Performance Agent can perform threshold processing on any performance data it gathers. Any threshold breach causes a trap to be raised, and the state of the object to be changed in the Unicenter Explorer. Use the Thresholds and Alarms section to define the various thresholds. Thresholds are divided into groups. Each group relates to a single operating system type. You can create a threshold group and later modify it by updating its properties. If you should define a threshold for a resource that is not listed for collection, an informational message is displayed. See the instructions for defining thresholds in the online CA Procedures under the topic, Configuring Thresholding and Alarms. Configuring and Deleting Exception Files Use the Performance Neugent section to configure and delete Exception files. You can also define Evaluation groups that specify which personality profiles are delivered to each system type or host. You can define an Evaluation group and later modify it by updating its properties.
420
Administrator Guide
See the instructions for implementing Exception files and defining Evaluation groups in the online CA Procedures under the topic, Configuring Performance Neugent. Note: The Performance Neugent is a supplemental product to Unicenter NSM. Defining and Modifying Summarized Data Properties You can define and later modify the properties of your Summarized Data by enabling the following selections:
Daily commands summary, daily usage summary, line usage summary, periodical commands summary, Performance Chargeback interface Summarized data processing time (end-of-day or next-day processing) The machines to which the summarized data will be delivered The deletion policy for the summarized data
See the instructions for defining and modifying summarized data properties in the online CA Procedures under the topic, Configuring Summarized Data.
Work with Profiles

When you create a new profile, you can base its data gathering properties on the properties of an existing profile or on a set of default values. An object representing each profile you create appears in the right pane of the Performance Configuration application under the Profiles object. When the Performance Agent is started, it checks that it has a valid configuration and if not, notifies its Distribution Server. The Distribution Server receives these notifications and sends a profile to generate a valid configuration for that machine. The profile sent is based on the following determinations:
If the machine has never been configured, the Distribution Server sends the Default profile. If you have created a new profile and defined it as the Default profile, the Distribution Server sends the new profile. If the machine was configured using a custom profile, the Distribution Server sends that profile.
Creating a New Profile Use the Performance Profile Creation Wizard to quickly create a new profile. To launch the wizard, right-click on the Profiles object in the Performance Configuration application and choose Create Profile.
421
Applying a New Profile To apply a newly created profile, use your mouse to drag the profile from the right pane, and then drop it on the target machine or machine group shown in the left pane. You can apply profiles in this way to machines with Performance Agents and to SNMP devices. Fine-Tuning or Modifying a Profile Use the Performance Configuration Profile Editor to fine-tune or modify any profiles data gathering and management properties. This editor simplifies the assignment of configuration options, resource set handling (System, Database and SNMP based resources), and monitoring of named processes for existing profiles. To launch the editor, right-click on the profile under the Profiles object in the Performance Configuration application, and then choose Properties. The Profile Editor presents a view of the profile from which you can select the properties you wish to change. Deleting a Profile You cannot delete a profile while a machine in your enterprise is using it. If you want to delete a profile, you must first drag-and-drop a different profile on any machines currently using the profile you want to delete. It is also not possible to delete the profile that has been marked as the default profile, or to delete the profile named Default Profile.
Configure SNMP Data Gathering and Proxy Machines

Performance Agents not only monitor system resources on the local machine where the agents reside; they can also monitor any SNMP-compliant resource on the local machine, and on one or more remote devices. With this functionality, you can treat an SNMP device like any other machine. You can view its properties, apply a profile to it, and include it in a group. For example, you can monitor the status of the routers in a network from a remote machine with a Performance Agent installed.
422
Administrator Guide
Configuring an SNMP Proxy Machine By default, SNMP resources are not collected for the local machine for agents prior to 3.0, but are collected for version 3.0 or above agents. To configure SNMP data gathering for a local machine, right-click on the machine and choose Properties. On the tabbed SNMP Proxies page, if you check Collect SNMP Resources for this machine, SNMP resources are automatically included in the performance cube. To stop collecting SNMP resources, drill down to the machine that has the Performance Agent on it, and choose Properties. Click on the SNMP Proxies page and uncheck Collect SNMP Resources for this machine. When configuring a remote machine or device that does not have a Performance Agent installed, you must identify a proxy machine that will gather performance data on behalf of the remote machine. The data collected is limited to SNMP-based resources. Because the same Performance Agent is performing standard resource data gathering, certain policies of SNMP resource gathering must be inherited from the agents standard configuration. These policies are listed following:

Data gathering start and stop times Collection frequency Collection days
Filtering the SNMP Proxy Machine Selection List Use the Filter Criteria drop-down box to filter the main list of potential SNMP proxy machines. Using this facility means that only machines using profiles meeting the filter criteria are displayed. Use the Advanced filter to filter by each unique collection policy. Configuring a Performance Agent to Monitor an SNMP Device Use the Performance Configuration application to configure a Performance Agent to monitor an SNMP device. When configuring the monitoring of an SNMP device, you must identify the following:

The SNMP device to be monitored The name of the Performance Agent machine that will serve as the proxy collector The profile to be applied
To supply this information, simply drag and drop the profile onto the SNMP device. You can later change the proxy machine for an SNMP device using the Properties dialog of the SNMP device.
423
When applying a profile to an SNMP device that is currently unavailable, the configuration status still registers as Configured provided the selected proxy collector is available. This occurs because the collector (not the SNMP device) is being configured to do the monitoring. Specifying Timeout and Retry Periods When you configure an SNMP device for data collection, you can specify monitoring timeout and retry periods. These definitions tell the Performance Agent how long to wait for an SNMP message to be returned by the device, and how many times to retry the SNMP ping. You can set these values on the SNMP Proxies tab of the Properties dialog for the SNMP device. Discovering SNMP Resources Use the Associate MIB wizard to discover SNMP resources. This wizard enables you to define the SNMP resources that you want to be made available for collection for a specific class. You can select a subset of resources. To invoke this wizard from the Performance Configuration application, right-click Machines and Devices and choose Associate MIB. For more information about MIBs, see the topic Whats a MIB? in the Event Management chapter of this guide. For more information on the Associate MIB wizard, see the online Help for the Performance Configuration application. Note: SNMP devices take their Performance system type from the WorldView class under which they were classified during discovery. This is in contrast to machines running the Performance Agent, where the Performance Agent itself determines an exact system type. Configuring MIBMux Agent Resources Several Unicenter NSM agents provide the ability to monitor multiple instances of an object. For example, you can configure the Unicenter NSM Oracle Agent to monitor multiple instances of the Oracle database. The technology employed to achieve this is called MIBMux. When monitoring the MIB of a MIBMux agent, you can precisely tailor the instances for which you wish to gather resources. To produce a machine configuration that includes resources for any MIBMux instances you want to specify, simply access the Properties notebook dialog for the device, and specify the related MIBMux instance names. Specify the instance name as listed following:
<CommunityString>@<InstanceName>
where CommunityString is the string you wish to use to access the MIB, and InstanceName is the database instance you wish to monitor.
424
Administrator Guide
Performance Configuration automatically creates a configuration containing the resources for each MIBMux instance you specified. Removing Monitoring of an SNMP Device If you wish to cease the monitoring of a particular SNMP device, simply open the Properties notebook of the SNMP Proxy (that is, the Performance Agent machine collecting data on behalf of the device) to view the devices that machine is monitoring. Select one of these devices and click the Remove button to stop the monitoring of that device. Note: Stopping monitoring of a device does not delete Performance Cubes that have already been generated.
Configure a Selected Machine/Device

To quickly and easily configure the primary data gathering policies for the Performance Agent on a single selected machine/device in your enterprise, use the One Click Configuration application. This application starts from Unicenter Explorer or the WorldView 2D Map in the context of the machine/device that you selected. Right-click on a machine/device, and then choose View Performance Gathering or Modify Performance Gathering to launch this application. If you choose View Performance Gathering, the Performance Data Gathering Properties window appears. If you choose Modify Performance Gathering, the Performance Data Gathering Configuration window appears. When editing profiles and resource sets using One Click Configuration, you are effectively configuring a machine-specific profile or resource set for that particular host or device. This means the changes you make using One Click Configuration will only affect the machine or device selected. It is important to understand the implications of modifying the currently active profile for a given machine/device using One Click Configuration. The Performance Configuration application enables you to create many different profiles. You can apply each of these profiles to many different machines or devices. For example, in the Performance Configuration application, you may create a profile named MyProfile, and apply this same profile to 100 different servers and devices. When you use One Click Configuration to modify the properties of MyProfile for just one of these 100 servers and devices, it is important that these changes are only applied to the selected machineand not to the other 99 machines and devices originally using MyProfile.
425
To accommodate this, One Click Configuration uses a delta concept by creating a specific profile that applies only to the selected machine/device. The specific profile that is created is post-fixed with the same name as the machine/device to which it applies, as in MyProfile@pollin.com. The following rules apply to the profiles created using the One Click Configuration:
If you selected Details view when viewing a Performance Agent on a given machine/device under the Machines and Devices or Groups trees in the Performance Configuration application, the term YES in the Specific ? column in the right hand pane indicates that a specific profile definition has been applied to this Performance Agent. The list of available Performance Configuration profiles under the Profiles/Performance Agent tree in the Performance Configuration application does not show specific profiles.
When modifying the data gathering policies with One Click Configuration, you can choose any of the available generic resource sets to define the resources that the Performance Agent collects. Many different profiles may use these resources. In turn, many different machines may use these profiles. As with profiles, when you use One Click Configuration to modify a resource set, it is important that the changes are only applied to the selected machine, and not to any of the other machines that are using profiles that are referencing the resource sets. Again, as with profiles, One Click Configuration uses a delta concept by creating a personalized resource set. The personalized resource set is available only to the selected machine/device when using One Click Configuration. One Click Configuration provides for simplistic and rapid configuration changes. Therefore, the data gathering and management properties that you can modify are restricted to the data gathering policies (collection times and frequency, collection days, and collected resources). In addition to these, you can configure where the base set of data collected (the Full Daily Performance Cube) is delivered. The profile you are modifying may contain other definitions, such as Period Cube definitions, Enterprise Cube definitions, and threshold rules. Since changes made to the data gathering policies in One Click Configuration may affect them, these definitions in the profile are automatically changed to accommodate any modifications. This also applies to creating a new profile based on an existing profile that includes Period and Enterprise cube definitions.
426
Administrator Guide
Creating and Applying a New Profile You can create and apply a new profile that defines the data gathering and management properties of a selected machine/device. When you create a new profile, you need to name it, specify collection details and a selection period, select a resource set for data collection, and identify the recipient machines. By default, SNMP resources are not collected for the local machine for agents prior to 3.0, but are collected for version 3.0 or above agents. To configure SNMP data gathering for a local machine, check the Collect SNMP Resources for This Machine checkbox on Step 5 of the wizard when creating a new profile using One Click Configuration. See the instructions for creating a performance data gathering profile in the online CA Procedures under the topic, Maintaining Data Gathering. Applying a Predefined Profile You can apply an alternate, predefined profile that defines the data gathering and management properties of a selected machine/device. See the instructions for selecting a profile for performance data gathering in the online CA Procedures under the topic, Maintaining Data Gathering. Modifying the Current Profile You can modify the currently active profile that defines the data gathering and management properties of a selected machine/device. See the instructions for modifying performance data gathering in the online CA Procedures under the topic, Maintaining Data Gathering. Changing the Resource Set You can change the resource set that the profile uses for data collection by selecting a different resource set when creating a new profile on the Resources step of the Performance Configuration Profile Wizard or when modifying the current profile in the Data Collection Properties notebook. See the instructions for modifying performance data gathering preferences in the online CA Procedures under the topic, Maintaining Data Gathering.
427
Viewing Performance Data Gathering You can view the current performance data gathering status information for a selected machine/device by right-clicking the machine/device in the Unicenter Explorer or the 2D Map and choosing View Performance. See the instructions for viewing performance data gathering status for a machine/device in the online CA Procedures under the topic, Maintaining Data Gathering. Disabling and Re-enabling Performance Data Gathering You can disable and re-enable data gathering and management for a selected machine/device. When you disable data gathering, you are sending a special No Collection profile to the agent. When you re-enable data gathering, you are resending to the agent the original profile that it was previously using. See the instructions for temporarily disabling and then re-enabling performance data gathering for a machine or device in the online CA Procedures under the topic, Maintaining Data Gathering. Configuring a Selected SNMP Device When configuring an SNMP device, one of the steps in the Performance Configuration Profile Wizard contains an SNMP Proxy Machine Selection form. This allows you to select a machine with the Performance Agent installed to act as a proxy to collect SNMP-based resources from the device. When selecting a predefined profile for a selected SNMP device, the same form appears, prompting for selection of an SNMP proxy machine. See Performance Configuration Profile Wizard help for more information on the SNMP Proxy Machine Selection form.
Maintain Configuration Servers and the Performance Agent

Listed following are tasks involved in maintaining the configuration servers and the Performance Agent. Many of these tasks involve the Performance Configuration Command Line Utility (cfgutil.exe). See the online CA Reference for descriptions of cfgutil.exe and other commands referenced following. Note: cfgutil.exe is available on Windows platforms only.
428
Administrator Guide
Starting and Stopping the Domain Server You can start and stop the Domain Server through the Services applet in Windows Control Panel/Microsoft Management Console or through the command line. By default, the service starts automatically. To start the Domain Server through the command line, enter:
cd %TNG_HOME%\Config\PmDmnSrvr profileserver start
To stop the Domain Server through the command line, enter:

cd %TNG_HOME%\Config\PmDmnSrvr profileserver stop
Starting and Stopping the Distribution Server You can start and stop the Distribution Server through the Services applet in Windows Control Panel/Microsoft Management Console or through the command line. By default, the service starts automatically. To start the Distribution Server through the command line, enter:
cd %TNG_HOME%\Config\PmDstrbSrvr configserver start
To stop the Distribution Server through the command line, enter:

cd %TNG_HOME%\Config\PmDstrbSrvr configserver stop
Viewing Configuration Server Service Status To view the status of the Domain Server, enter:
cd %TNG_HOME%\Config\PmDmnSrvr profileserver status
To view the status of the Distribution Server, enter:

cd %TNG_HOME%\Config\PmDstrbSrvr configserver status
Viewing Configuration Server Logs The Domain Server log is stored in the following directory:
%TNG_HOME%\Config\PmDmnSrvr\log
The Distribution Server log is stored in the following directory:

%TNG_HOME%\Config\PmDstrbSrvr\log
429
Changing the Domain Server of a Performance Agent To change the Domain Server of a Performance Agent, you simply need to point it to a Distribution Server in the new domain.
cd %TNG_HOME%\Config\PmDmnSrvr cfgutil c <Distribution Server> agent
Configuring the Performance Agent to Report to a Different Distribution Server To change the Distribution Server of a Performance Agent, enter:
cd %TNG_HOME%\Config\PmDmnSrvr cfgutil c <Distribution Server> agent
Note: For agents prior to 3.0, restart the agent using the m option. Then issue the Discover Agents command. Restricting Configuration Operations Given the many individuals that have access to computing resources with today's eBusiness environment, it is critical to restrict access to configuration policies and procedures. For this reason, the Domain Server implements a builtin security model that enables you to restrict configuration operations to certain users, domains, or machines. To change security options, modify the following file on the Domain Server machine:
<Installation Directory>\Config\PmDmnSrvr\data\users.dat
The format of each record is as follows:

<host name or Microsoft Windows domain name> | username | permissions
Note: If a user logs onto a Windows domain, the domain name is used for security checking. If a user is not using a Windows domain, the computer name is used for security checking. Separate each field with a | (vertical bar), and omit white space. Put an asterisk (*) in the first field to indicate that any host or Windows domain will match. Put an asterisk in the second field to indicate that any user name will match.
430
Administrator Guide
You can set the following permissions: read write deliver monitor setstatus The user can view the profiles within this domain. The user can update the profiles within this domain. The user can deliver profiles to agents and devices in this domain. The user can view the delivery status of profiles within this domain; for example, to see if an agent is configured. The Distribution Server uses this status to report status back to the Domain Server. Set this permission for the machine where the Distribution Server is located.
The default security record is as follows:

*|*|read,write,deliver,monitor,setstatus
which means that all users on all machines have full permissions. To give just read access to all users in the domain PUBLIC, but allow all other users in other domains full control, change users.dat to the following:
*|*|read,write,deliver,monitor,setstatus PUBLIC|*|read
When deciding which record applies to a particular request from a user, the most restrictive record is chosen. In the previous example, any user in a different domain still has full access. Only users in the PUBLIC domain are restricted. To allow only users PERFORMANCE1 and PERFORMANCE2 on any machine full control and to give everyone else just read and profile delivery permissions, change users.dat to the following:
*|*|read,deliver *|PERFORMANCE1|read,write,deliver,monitor,setstatus *|PERFORMANCE2|read,write,deliver,monitor,setstatus
You do not need to restart the Domain Server after updating the users.dat file. Note: For the Distribution Server to connect successfully to the Domain Server, the user account that the Distribution Server starts up as must have read and setstatus permissions. If the system account is used, SYSTEM must be specified. For example, change the users.dat to the following:
*|SYSTEM|read,write,deliver,monitor,setstatus
431
Performance Scope
Backing Up the Domain Server Use any backup tool to back up the Domain Server. Back up the following directory only:
<Installation Directory>\Config\PmDmnSrvr
Note: This directory also includes the Domain Server executable. You can successfully restore (overlay) the Domain Server on any machine with the same name and IP address of the original to achieve a working installation. To restore the data, first use the Service Control Manager to make sure the Domain Server is shutdown. The service name to stop is Unicenter Configuration Domain Server.
Performance Scope
Performance Scope provides a real-time view of the performance for the components of managed systems. Each view lets you seamlessly join real-time and historical data so that you can observe both current and previous resource performance. Performance Scope provides extensive graphical analysis and advanced thresholding capabilities, all of which may be used for monitoring data collected by the Performance Agents. Scope features an intuitive, easy-to-use graphical interface. Using this component, you can do the following:

Identify performance bottlenecks. Identify components that are consuming excessive resources. See how a change in system parameters affects performance. Apply thresholds to local machines in your enterprise to alert you when a particular threshold is violated while in a Scope monitoring session. Go back in time to detect when a problem first occurred. Save and retrieve views of machines when you need to analyze data.
When you start Performance Scope, the desktop contains the Resource View window. The Threshold Status window and the Errors and Notifications window are minimized. The windows contain menu and toolbar options. These commands are available from the main Performance Scope window as well. The commands enable you to perform real-time monitoring, create charts of monitored data, save data, apply thresholds, view errors, and access online Help.
432
Administrator Guide
Performance Scope
Configure Scope Options

Performance Management supplies default values for operating Performance Scope. After you become familiar with this application, you can change the initial settings at any time. Use the Performance Scope Options dialog (opened from the Scope menu item) to set the default sample period frequency to match the collection frequency as specified in the profile for the machine that you are monitoring. The frequency setting specified in the machines profile must equal the setting on the Historical View Default tab, or no historical data will appear when you create a machine view. However, Performance Scope can automatically search for historical data that most closely matches your specified criteria if an exact match is not available. See the instructions for enabling this feature in the online CA Procedures under the topic, Requesting Best Match Historical Data. The sample period frequency can also be changed for a specific machine by clicking the historical view toolbar button to open a historical view settings dialog for the selected machine view. For the Realtime Performance Data chart, Performance Scope supplies a default value of 2 seconds for polling the Realtime Performance Agent. If you decide to change this value, be sure to consider that a long period (for example, 1-minute) is less resource intensive than a short period (for example, 5 seconds). See the instructions for using the Performance Scope Options dialog in the online CA Procedures under the topic, Configuring for Performance Scope.
View Resources for a Specific Machine

Resource View makes it easy to identify all machines on which the Performance Agents have been installed. When you open Resource View, a list of networks appears in the left pane in a tree-like structure. You can expand each level until you reach the machine level. Each machine object expands to show a list of resources available for monitoring. The resources available are dependent on the operating system. Along with machines and system resources, any SNMP devices and resources that you discovered using the Performance Configuration component are shown in the Resource View. The resource object expands to list available subtypes for performance monitoring. When you select a subtype, the associated instances display on the right pane for the machine you selected. The Snapshot! command takes a picture of that instance in real time and returns its value in the right pane. See the topic Resource View Window in the online Help for Performance Scope for descriptions of each level in the resource tree.
433
Performance Scope
Right-click on a resource and, from the popup menu, choose Whats this? to display its definition. See the instructions for working with Resource View in the online CA Procedures under the following topics:

Viewing Machine Properties Locating a Machine Viewing Resource Definitions
Create Charts of Monitored Data

You can view performance data from the Resource View in chart form by creating a machine view. You create a machine view for one machine at a time. You can display up to forty resources concurrently in one chart. You can also have multiple views monitoring many machines. To create a machine view and plot values on the charts, drag a resource instance to the Performance Scope desktop or to an open chart for the selected machine. The machine view window opens (from the Resource View window) to show a historical view in the left pane and a real-time view in the right pane. See the instructions for creating a machine view in the online CA Procedures under the topic, Creating Charts and Adding Data. If the Performance Agent has collected data in a full Daily cube for the resources that you selected to monitor in real time, the values appear in the historical chart. You can also view historical data recorded from the previous day or on a specified date, using the Historical Defaults tab on the Options dialog. In order to use this feature, the historical data must be stored in the Full Daily cube type. Real-time monitoring continues until you stop it. Performance Scope can automatically search for historical data that most closely matches your specified criteria if an exact match is not available. See the instructions for enabling this feature in the online CA Procedures under the topic, Requesting Best Match Historical Data. You can examine machine view data in a variety of chart styles. In addition to the styles, you can view a chart in 2D or 3D. See the instructions for defining chart styles and the 2D and 3D option in the online CA Procedures under the following topics:

Setting Chart Style Properties Viewing Charts in 2D Viewing Charts in 3D
434
Administrator Guide
Performance Scope
The following options and commands are particularly useful:
Use the Remove from Chart command to remove monitored resources from a chart. Use the Send Mail option to send the active machine view via Microsoft Exchange to remote locations for additional analysis. Use the Save View With Data and Save View Without Data commands to save a machine view for retrieval later, when you need to analyze data. When you open the saved view, the real-time monitoring will commence for the resources that you selected when you created that view. These options save time, as you do not need to redefine viewing specifications.
See the instructions for saving and sending data in the online CA Procedures under the topic, Saving Machine View and Sending Mail.
Set Thresholds
In addition to Performance Scopes powerful performance monitoring capabilities, you can define thresholds for the resources provided in the Resource View. The Threshold Wizard creates templates that contain threshold values for resource subtypes and instances. Defining thresholds is extremely valuable, as you can be informed immediately of performance issues on any computer serving as a Performance Agent station. Alternately, you can specify that a threshold be exceeded for a defined number of real-time agent polling periods before notification occurs. For example, using an orientation of greater than, you may set a warning threshold of 50 and a critical threshold of 100 for all occurrences of system errors on a server. The format of the notification depends on the values you entered in the Performance Scope Options dialog and in the Threshold Action Definition dialog. For example, when the thresholds defined for the Server System Error template are met, you can specify that a message box appears, an alarm sounds, and an error is logged. You apply threshold templates in the Resource View to machines to which you wish to apply thresholding. Threshold templates are based on the operating system. The Threshold Status window allows you to view threshold status. The left pane displays the machines and resources that have threshold templates applied and are active. The color of a computer object indicates whether a threshold warning (yellow) or critical value (red) has been reached. If an objects color appears grayed, the resource selected for threshold monitoring has not yet been polled.
435
Performance Trend
See the instructions for creating and applying thresholds in the online CA Procedures under the following topics:

Creating Threshold Templates Defining Actions for Thresholds Applying Threshold Templates
View Errors
The Errors and Notifications window provides a central location for documenting system errors, notifications, warnings, and messages. This view is valuable for tracking problems that may have occurred during real-time monitoring. By tracking and documenting these issues, you can trace problems and issues for long-term analysis. You can also determine suitable threshold values for enterprise performance. You can filter the errors and display them in a list format. You can also define the level of errors that are sent to the Errors and Notifications window. See the instructions for working with Errors and Notifications in the online CA Procedures under the following topics:

Viewing Errors and Notifications Filtering Errors
Performance Trend
Performance Trend provides historical performance and resource usage data in a spreadsheet-based environment from which you can easily load, manipulate, and view the data provided by the Performance Agent. Performance Trend offers a comprehensive selection of default chart definitions that provide load and go functionality, allows for the immediate generation of 2D and 3D charts. The ability to present monitored resource data in various chart styles enables you to observe at a glance any trends that are occurring across your enterprise. Using Performance Trend, you can do the following:

Identify which servers and devices are heavily loaded. Observe patterns of activity and use of applications and servers. Identify problematical trends. Investigate the impact of moving applications and users to other servers. Determine the effect of running workload at different times. Provide automated graphical reports.
436
Administrator Guide
Performance Trend
When you open Performance Trend, the Performance Trend menu appears in the Microsoft Excel desktop. Using the Microsoft Excel spreadsheet application, Performance Trend holds performance data in worksheets. The worksheets provide full flexibility and extensibility for data manipulation. All functionality is available through the Performance Trend menu. Descriptions of the menu items appear in the online Help for Performance Trend under the topic, Menu Bar. Performance Trend translates resource data contained in the performance cubes into Comma-Separated Value (CSV) files. The CSV files created during cube format conversion are placed in the default directory specified on the General Configuration window. Typically, you can use the default directory without making any changes. Use the General Configuration window to set the original format, performance cube, or CSV file that you want to analyze for performance trends. See the instructions for general configuration in the online CA Procedures under the topic, Specifying Directories and Data Format.
Conduct Trend Analysis

The first step in trend analysis is to either create new or edit existing chart definitions. A chart definition is a named group of monitored resources and a selected style for chart presentation, such as bar style. A chart definition set contains one or more chart definitions. Performance Trend provides chart definition sets based on the operating system.
Chart Configuration
The Performance Trend Configuration Wizard provides an interface for maintaining chart definition sets. You can create, edit, or remove chart definition sets. The wizard presents the Configure Chart Definition dialog that enables you to add or edit the following properties for each chart definition within the chart definition set:

Name/title details. Resource types, subtypes, and instances the chart should attempt to plot. Threshold rules to apply to the chart. Any specialized plot options, such as instance selection and automated threshold generation. Chart settings and properties (3D, bar, line, and so forth). Macros to run against the data selected for the chart. See the topic Macros for Customizing Chart Definitions in the online Help for Performance Trend. This topic contains a template for writing a macro successfully, descriptions of the Out-of-the-Box macros that Performance Trend provides, and information on providing macro selection functions.
437
Performance Trend
Once you have used the wizard to create or update a chart definition set, the chart definitions are immediately available for use both interactively (through the Generate Predefined Charts feature) or in batch mode (through the Batch Reporting Feature). See the instructions for using the Performance Trend Configuration Wizard to configure chart definition sets in the online CA Procedures under the topic, Configuring Chart Definition Sets.
Predefined Chart Generation
The second step in trend analysis is to issue the Generate Predefined Charts command. This command invokes the Data Selector window where you select the performance cubes or CSV files that you want to analyze for performance trends.
Selecting a daily cube generates a daily chart, which shows the usage of a number of resources by a particular computer during the course of a day. Daily charts allow you to observe patterns of use within a day and to spot resource bottlenecks. Selecting a period cube generates a period chart, which shows the usage of one resource by a particular computer during the course of a day for a number of days. Selecting an enterprise cube generates an enterprise chart, which shows the usage of one resource by a number of computers during the course of a day.
After you select the performance cube or CSV file, the Select the Required Charts folder appears. This folder consists of tabs, each associated with a set of chart definitions. You can select the definitions that contain the specifications for the charts you want to generate. A timesaving feature is that you can load multiple chart definitions at one time. Analyzing computer performance trends enables you to observe which computers are heavily loaded and during what periods of the day. See the instructions for generating predefined charts and using data selectors in the online CA Procedures under the following topics:

Generating Predefined Charts Using Data Selectors
After data selection is complete, the command extracts the resources set in the chart definition and creates a workbook. The workbook follows a standard format, and contains all the performance data from the selected Performance Cube, and worksheets for each of the generated charts.
438
Administrator Guide
Performance Trend
The first tab of each generated workbook consists of a worksheet listing the entire contents of the performance cube or CSV file. Data is sorted alphabetically by machine name, resource type, resource subtype, and instances. This sheet includes the computers and resources monitored and the performance resource values. The second tab shows the extracted resources for the first chart definition in chart format. (You can use standard Microsoft Excel functionality for additional formatting and printing options, if desired.) The third tab lists only the data that was extracted for the chart. The chart is the graphical representation of the extracted data. The format of this workbook is the same for each chart that you generate. See the instructions for closing workbooks and for interpreting charts in the online CA Procedures under the following topics:

Closing Workbooks Interpreting Charts - CSV Interpreting Charts Performance Cubes
Ad hoc Chart Generation
For those circumstances when you only need a chart for one-time use, instead of the Generate Predefined Charts command, issue the Generate Ad hoc Charts command. This command invokes the Chart Data Selector window where you select the performance cube for which you want to generate a chart. After you select the performance cube, a tabbed dialog appears, enabling you to add properties for the one-time chart. When you finish adding properties, the ad hoc chart you generated is displayed. See the instructions for generating a chart for one-time use in the online CA Procedures under the topic, Generating an Ad hoc Chart.
On-Chart Thresholding
For both predefined and ad hoc charts, if warning or critical thresholds were defined during chart creation and if any data point exceeds a threshold, Performance Trend generates an additional thresholds report that is associated with each chart. You can view a summary of threshold breaches across all charts during the current session and select a chart for more detailed analysis. Then on the selected chart, when you select one or more subtype/instance combinations, Performance Trend generates a threshold chart for each. These threshold charts are stored within the same workbook as the original charts and can be saved in Excel or HTML format. You may automate the generation of threshold charts by using the Batch Reporting feature of Performance Trend. See the instructions for working with on-chart thresholding in the online CA Procedures under the topic, Viewing Threshold Breaches.
439
Performance Trend
Automate Chart Generation

The process of generating charts can be accomplished automatically through integration of Performance Trend with Enterprise Management Workload and Calendar. The Performance Trend Batch Reporting Wizard enables you to define a profile that Workload uses to submit generating Performance Trend charts as jobs. Using the Batch Reporting Wizard, you can do the following:
Automate chart generation of data collected from many machines in a heterogeneous environment. Generate charts in the background on a regular, daily schedule. Save formatted charts to a disk either within an Excel workbook or as user-customizable HTML pages. Spool to a default printer. Deliver charts via electronic mail. Store charts in spreadsheets for later analysis.
The Batch Reporting profile is a template for Workload to run the job and to define the Performance Cubes included in job processing. An important advantage of defining the chart generating job through the Batch Reporting Wizard is having several output options, including writing charts to disk, spooling to a default printer, and sending via electronic mail. Familiarity with generating charts is recommended before using Batch Reporting. See the instructions for using the Batch Reporting Wizard and for viewing batch reports in the online CA Procedures under the following topics:

Automating Chart Generation Viewing Batch Reports
Correlate Cube Data

Correlation provides a means to discover and alleviate bottlenecks in performance. For example, after analyzing all disks on a file-server, you would replace the disk with the highest incidence of severity conditions because this would do the most good in reducing bottlenecks. Correlation analysis provides an indication of mutual behavior tracking in statistical form. Correlation coefficient values range in magnitude from 0 (no behavior tracking) to 1.0 (complete behavior tracking). A high magnitude of the correlation coefficient indicates a high degree of behavior tracking.
440
Administrator Guide
Chargeback
The Performance Trend Correlation Wizard guides you through the process of correlating data. After the correlation calculations are complete, the Correlation Wizard places an affinity list and one or more heat sheets in a workbook for interactive analysis. See the instructions for performing correlation in the online CA Procedures under the topic, Correlating Data.
Chargeback
The Chargeback component of Performance Management is a powerful, yet uncomplicated resource allocation and chargeback application. Resource allocation is a method of determining who is using how much of what. Chargeback is a way of attributing monetary values to the quantities used. With Chargeback you can identify and report on end-user usage of system resources, and charge users for the computing resources and services they consume. Utilizing the Microsoft Excel spreadsheet application, Chargeback offers a high degree of customization and extensibility in a flexible environment. Chargeback offers the following features:
Uses the Performance Agents located across the heterogeneous systems distributed throughout your enterprise. Consists of three functional levels (Resource Allocation, Chargeback, and Budget) that build on each other to provide a comprehensive level of functionality to suit the needs of your organization. Allows Chargeback to accept data feeds from end-user and third party applications. Allows resource usage data to be attributed to logical groupings of related users or charge groups that reflect the organizational structure of your enterprise. Allows for the creation of high-definition, graphical reports and the ability to present data in many different forms. Provides for resetting, reopening, and restoring closed accounting periods. Compares billing information against preset budgets for each charge group. Supplies customizable billing reports and professional invoices. Generates summary billing information by charge group and provides a master totals report.
441
Chargeback
Provides powerful graphical business management reports. Interfaces to Enterprise Management functions such as Calendar, Event Management, and Security Management.
Chargeback Implementation
Chargeback can be implemented in three phases or levels that expand the application from its basic resource allocation level to the budget accounting level. You determine the extent of functionality that you want from the application. The primary functional levels are listed following:
Resource Allocationa method whereby detailed resource usage data across your enterprise is attributed to the charge groups that reflect your organizational structure. Chargeback Accountinga method of assigning a per-unit monetary value to quantified resources. Bills, invoices, and reports can also be generated. Budget Accountinga method of maintaining accounts for the charge groups that you are charging. Amounts used are compared to a preset budget to yield a balance. The ability to include balances enhances reports. Note: The Resource Allocation level is installed by default. Other levels have to be selectively enabled. The level of accounting can be set at any time after install. See the instructions in the online CA Procedures under the topic, Setting the Accounting Level.
Identify Your Organizational Structure

Chargeback enables you to map your companys organizational structure by allowing you to create a hierarchy with up to 255 nested levels. This concept is illustrated in the diagrams following. Note: In Chargeback, by default, Enterprise always represents the top level (also referred to as the root charge group) of your organizational structure.
Sample Enterprise Organizational Structure Enterprise Sales Accounting Research & Development Services
442
Administrator Guide
Chargeback
A portion of the structure has been expanded to illustrate a multileveled hierarchy.

Sales and Accounting Levels Expanded Enterprise Sales East Coast Leads Support Admin. West Coast Leads Support Admin. Marketing Advertising Direct Mail Accounting Accounts Receivable Billing Collection Admin. Accounts Payable Mail Payroll Admin.
The multileveled organizational structure depicted here can easily be replicated in Chargeback. See the instructions in the online CA Procedures under the topic, Creating Charge Groups.
Chargeback Concepts
This section includes an overview of the three functional levels. The Chargeback component opens to reveal the desktop and a default WBChargeback.xls workbook. Note: Launching the Chargeback component starts Microsoft Excel. When Excel opens, you are prompted to enable or disable macros. The option to disable macros was added into Office 97 by Microsoft to stop macro viruses. Chargeback contains macros that are vital to the component. Therefore, you must click the Enable Macros button in order for the component to run properly. All Chargeback activity is recorded on the spreadsheets contained in that workbook. The default WBChargeback.xls workbook opens to Accounting Information as the active spreadsheet. Two primary column headings, Charge Groups and Resource Allocation, appear on that spreadsheet. Under Resource Allocation are two columns, Per Group and Consolidated. Chargeback provides two default charge groups, Enterprise and Default, which are discussed later in this chapter. The Chargeback menu appears on the Microsoft Excel menu bar. This menu contains the commands for performing primary Chargeback functions. See descriptions of the menu commands in the online Help for Chargeback under the topic, Menu Bar.
443
Chargeback
Resource Allocation Data for Chargeback is acquired from a simple data file in comma-separated value (CSV) format. The Performance Agent creates one data file per day, per computer and sends it to specified computers with Chargeback installed. An open file format is employed to allow you to include data from custom-made systems or your own files into the Chargeback component. Windows NT and Windows 2000 do not currently provide comprehensive support for user resource accounting. Windows NT and Windows 2000 are able to measure the performance and usage of resources but are not able to portion these statistics to individual users. The Resource Accounting Service solves this problem by monitoring various resources and recording a summary of resource usage by user for a selected machine in a CSV file. These files are collected on a daily basis by the Performance Agent and passed to the Chargeback component. See the Resource Accounting Service section later in this chapter.
Weight Factors
The Chargeback component allows you to assign a weighting factor to each of the resource types in the raw data file. You may want to assign a weight factor, for example, to indicate by varying degrees the resources that are in general more costly to consume. For example, you may consider that in your enterprise, CPU usage is an inexpensive commodity, and therefore assign a 1:1 weighting relationship. However, you may also consider Disk Usage an expensive commodity, and therefore assign a 10:1 weighting for this resource. As well as weighting by resource type, weighting factors can be applied at an individual computer level. Chargeback supports that functionality, as you may wish to weight all resource usage values differently from one machine to another. For example, it would be appropriate to apply a premium to all the resources consumed on a $100,000 Sun Server, more than those consumed on a $2,000 Workstation. Furthermore, you may want to chargeback the cost of equipment purchases by charging users on a particular computer at a higher rate. When combined during reconciliation processing, resource and computer weighting factors act together to produce the total resource usage (RU) units. For data files, a resource-weighting factor is applied per column to the values in the column. Placing a weight value equal to 1 means that the values in the column are used in data processing as is. Placing a value equal to zero means that the values in the column for that resource are ignored when processing the data. Placing a weight value of 10, for example, means that the values in that column are multiplied by 10. By default the Chargeback application uses the values in the first column of the data file as is and ignores the remaining columns. (By default all computers are included in processing.) When you multiply the value found in each column with the weight factor assigned to that column, the result is the RU units. (See the Weight Factors and Charge Groups section in this chapter for an example.)
444
Administrator Guide
Chargeback
When Chargeback performs reconciliation processing for a given accounting period, it simply reads data files and attributes the RU units for each user in the file to that users charge group.
Users
In Chargeback a user or user entity consists of the following:

User name Name of computer where data originates Data format or operating system, for example, UNIX/Linux
Users are added to Chargeback either manually through the GUI, or automatically by reconciliation processing. Reconciliation dynamically discovers new users and adds them to the Default charge group.
Charge Groups
Charge groups are created within the Chargeback application, and they reflect various departments, teams, and so forth, that make up your organizations structure. When charge groups are defined you specify which users belong to which charge groups. You can make those assignments individually on a per user basis, or generically. The two options for assigning users to charge groups are listed following:

Drag-and-drop the users to a new group. Create user entity profiles.
User Entity Profiles
In Chargeback, a user entity profile consists of the same data as a user entity:

User name Name of computer where data originates Data format or operating system, for example, UNIX/Linux
Chargeback provides three options for creating user entity profiles:

Dynamic creation of absolute user entity profiles Manual creation of absolute user entity profiles Manual creation of generic user entity profiles
A discussion of each option follows.
445
Chargeback
Dynamic Absolute User Entity Profiles
Every time reconciliation processing occurs, Chargeback searches each record in the data files for the current accounting period and attempts to match the user name (first priority), computer name where data originated (second priority), and data format (third priority) with an existing user entity profile. If a valid match is found, then the resource usage data associated with that user is attributed to the charge group to which the matching user entity profile is assigned. If no valid match is found, then the Chargeback component dynamically creates an absolute user entity profile for that user, and automatically assigns it to the Default charge group. The resource usage data for that user is then attributed to the Default charge group. The purpose of this operation is two-fold. Firstly, it means that Chargeback automatically builds a record of all the users in your enterprise, which means that you avoid the costly set-up time of adding user definitions manually. Secondly, when new user names, computer names, or data format types are encountered during reconciliation processing, the resource usage data associated with them is automatically allocated to the Default charge group, rather than being ignored.
Manual Absolute User Entity Profiles
You can create absolute user entity profiles by selecting a target charge group for the new user and adding a new user entity profile definition within the charge group. An absolute user name, computer name, and data type are needed in order to create a profile. Chargeback automatically checks for identical user entity profiles. If an identical profile is found, you are prompted to either cancel the add operation, or delete the old profile in favor of the new one. When Chargeback next performs reconciliation processing, any resources associated with data records that exactly match that user entity profile (for example, same user name, computer name, and data type) are attributed to the charge group to which the user entity profile is assigned.
Manual Generic Entity Profiles
A generic user entity profile contains at least one generic definition for either user name, computer name, or data type. Using generic user entity profiles speeds up processing considerably. As an example, instead of using drag-and-drop to move all 500 users associated with the Machine Name SERVER00 to the Payroll charge group, you can select Payroll as the target charge group and create a generic user entity profile that contains user identification as follows:

User name = * Computer name = SERVER00 Data type = *
446
Administrator Guide
Chargeback
Note: Any or all of the fields can be specified absolute or with a generic mask, wildcard (asterisk). For example, enter a* in the user name field to search for all user names beginning with the letter a. A generic user entity profile is assigned to a charge group in the same way that an absolute user entity profile is, and the profile can represent many hundreds or thousands of users. To add a generic user entity profile, select the target charge group for the new generic definition, and add a new user entity profile definition within that charge group. When you add a new generic user entity profile, Chargeback checks for any existing absolute user entity profiles that are covered by the generic definition you are adding. If found, you are prompted with a complete list of those absolute user entity profiles. For any absolute profiles found in the Default charge group, the default action is to delete them (as it is probable that these definitions have been added dynamically by Chargeback, and you will probably wish to override them). Any absolute user entity profiles in other charge groups are, by default, left in place. At that time, you are able to selectively amend which absolute user entity profiles are deleted. Chargeback GUIs simplify the operation. When Chargeback next performs reconciliation processing, any resources associated with data records that have the closest match to an existing user entity profile are attributed to the charge group to which the user entity profile is assigned.
Assigning User Entity Profiles to Charge Groups
Two methods for assigning user entity profiles, absolute and generic, to a selected charge group are listed following:
Drag-and-drop existing user entity profiles from one charge group to another. Create a new user entity profile within a selected charge group.
Resource Usage Assignment Rules
When Chargeback performs reconciliation processing, it needs to determine which resource usage information is added to which charge group. It does this by examining the data recordsthe user name is the first priority, the name of the computer where the data originated is the second priority, and the data format (held in the data file header) is the third priority.
447
Chargeback
The following table illustrates the matching rules employed during the assignment process. Criteria Scale (Most Specific to Most Generic) Most Specific Criteria User Name (Priority 1) user001 user001 user001 user001 user0* user0* user0* user0* use* use* use* use* use* u* u* * * * * * Most Generic Criteria * Computer Name (Priority 2) system01 system* * * system01 system* system* * system01 system* syst* * * system01 system* system01 system* syst* syst* * * Data Format (Priority 3) UNIX/Linux UNIX/Linux UNIX/Linux * UNIX/Linux UNIX/Linux * * UNIX/Linux UNIX/Linux UNIX/Linux UNIX/Linux * UNIX/Linux UNIX/Linux UNIX/Linux UNIX/Linux UNIX/Linux * UNIX/Linux *
See the instructions for associating users to charge groups in the online CA Procedures under the topic, Assigning Users to Charge Groups.
448
Administrator Guide
Chargeback
Listing Users and Charge Groups
The Chargeback component maintains a list of user entity profiles that represent one or more users within your enterprise. It also contains a crossreference of which user entities are associated with what charge groups. After assigning users to charge groups, the User List command generates a User Association table, which can be saved as a WBMaintenance.xls file. See the instructions for using the User List command in the online CA Procedures under the topic, Creating a List of Users.
Weight Factors and Charge Groups
The example that follows illustrates how RU units are calculated and attributed to charge groups when reconciliation processing occurs. Data used is from the sample UNIX/Linux format data file generated by computer DBEngine and the User Association table (both appear previous). The following hold true for this example:

Charge groups Mail and Payroll were created and users were assigned. The resources shown are assigned weight factors that are greater than zero. Computer DBEngine is assigned a machine power weight value equal to 2. All users operate computer DBEngine. UNIX/Linux Resource CPU(MINS)_NPRIME Weight Factor = 1 5x1=5 23 x 1 = 23 0x1=0 5x1=5 0x1=0
Login Name user01 (Mail) user02 (Payroll) user03 (Payroll) user04 (Mail) user05 (Mail)
UNIX/Linux Resource CPU(MINS)_PRIME Weight Factor = 5 5 x 5 = 25 21 x 5 = 105 25 x 5 = 125 3 x 5 = 15 0x5=0
Machine Power Weight Factor = 2 30 x 2 = 60 128 x 2 = 256 125 x 2 = 250 20 x 2 = 40 0x2=0
Processing the data in the previous table attributes 100 RU units to charge group Mail and 506 RU units to charge group Payroll. The option to apply a monetary ($) cost per RU unit in order to charge a group for the resources consumed by its users is covered later in this chapter. By collecting data over a few days and defining your organizational structure within charge groups, you can immediately obtain an overall idea of who is using how much of what in your enterprise. That result is accomplished at the first, default level of the Chargeback component without having to assign monetary values to RU units or define budgets.
449
Chargeback
Chargeback Chargeback accounting handles how much each charge group should pay for the RU units attributed to them by applying a charge per resource usage unit. You can define additional charges to account for fixed or regular costs, typically overhead such as staffing, electricity, and paper/printing costs. Chargeback also allows you to split charges, taking charges from one group and splitting amongst others. For example, the cost for computer operations can be split equally across all charge groups in the enterprise. Once this level of the application has been enabled, you can generate customized bills and reports for business management. Budget In budget accounting each charge group is assigned its own budget. Those budgets can be allocated on a period-by-period or annual basis. The balance in each charge group budget is automatically calculated at each reconciliation. The state of any remaining budget is maintained and included in the bills and reports. If a budget becomes overdrawn, warnings can be sent to Event Management for further processing. A walk-through is provided for each functional level to illustrate the tasks involved. The walk-through sections should be reviewed in orderResource Allocation, Chargeback Accounting, and then Budget Accounting.
Resource Allocation Walk-Through

Chargebacks basic Resource Allocation level enables you to report consolidated resource usage across your enterprise using load and go. Chargeback provides the option to expand its basic Resource Allocation functionality to include reporting resource usage at a detailed levelbroken down by individual user, project, team, or business unit. The tasks for performing basic and advanced Resource Allocation are listed in this section. See the instructions for accomplishing each task in the online CA Procedures under the topic, Walking Through Resource Allocation.
450
Administrator Guide
Chargeback
Basic Steps
By performing the few simple steps following, you can report the total resource usage in number of units consumed by all users in your organization for a selected resource. 1. Obtain at least a days worth of raw resource usage data from the computers that you defined to interface with Chargeback. (For information on the Chargeback interface option, see the Defining and Modifying Summarized Data Properties section under Performance Configuration earlier in this chapter.) 2. 3. Open the Chargeback component. Create a New Period corresponding to when the resource usage data was collected. For example, if you have data files dated June 2001, enter 2001 as the year and 6 as the period number. After creating the period, notice that the year and period number are added to the workbook name as WBChargeback<yearperiod>.xls. (See the discussion of accounting periods under the Chargeback Period Concepts section later in this chapter.) 4. Perform Reconcile Period to process data.
The Chargeback component supplies default values for processing, so you do not need to be concerned about creating charge groups or assigning weighting algorithms. When processing is complete, values display to the right of the Enterprise and Default charge groups under the Resource Allocation column heading.
Advanced Steps
You can continue with the tasks following to report resource usage at a detailed level. 5. Perform Rollback Period to reset the period (undo data processing). Notice that the values are cleared from the Accounting Information spreadsheet. In addition to resetting the period, performing Rollback Period after processing enables the Chargeback menu commands that are used to map your companys organizational structure and assign optional properties to charge groups. 6. Create charge groups that map your organizational hierarchy using the Edit Charge Group Hierarchy Explorer. Chargeback automatically updates the Accounting Information spreadsheet with the charge groups that you created. The nested levels created using the Chargeback Hierarchy Explorer are translated into numbers that appear under the Level column.
451
Chargeback
7.
Assign users to the charge groups that you created in Step 6. A user on a specific computer can exist in one charge group at a time. (Remember, this task assigns users with the resource usage they consumed to the charge group that you specified.)
8.
Perform Reconcile Period. When processing is complete, the Accounting Information spreadsheet displays resource usage broken down by department.
9.
Perform Rollback Period (to reset the period for the next step).
10. Change the weight factors for fields in a Weighting Algorithm table to include additional resources in data processing. Thus far, Chargeback has been reporting on the resource usage units for the first resource listed in your data file tables. This step involves making the weight value greater than zero for the resources that you want to include in processing. Those resources are listed in the Weighting Algorithm table appropriate for their format type. There is a separate Weighting Algorithm table for each data format type that contains all of the resource types supported by that data format. 11. Perform Reconcile Period. During processing Chargeback performs the calculations and reports the total resource usage in units. 12. Perform Rollback Period (to reset the period for the next step). 13. Assign a weight factor to single computers. The concept here is similar to the one discussed in Step 10. By default, a power unit weight value equal to 1 is assigned to each computer, which means that Chargeback includes all computers in processing and with equal weighting. 14. Perform Reconcile Period to process data. You are now familiar with the concepts that the Chargeback application uses for performing basic and advanced Resource Allocation, and you possess a general knowledge of the tasks involved. The remainder of this section provides additional information to enhance your understanding of assigning users to charge groups. After performing Resource Allocation, you can choose to expand the Chargeback application. See the tasks for performing Chargeback Accounting under the following section, Chargeback Accounting Walk-Through.
452
Administrator Guide
Chargeback
Chargeback Accounting Walk-Through

After setting up charge groups and assigning users, only a few steps are necessary to apply charges to the resource units consumed per group. The tasks for performing Chargeback Accounting are listed following. See the instructions for accomplishing each in the online CA Procedures under the topic, Walking Through Chargeback Accounting. 1. 2. After completing Step 14 under Resource Allocation Walk-Through, perform Rollback Period to reset the period. Set the accounting level to Chargeback Accounting. Notice how the Total Consolidated, Resources Consolidated, Additional Consolidated, and Split Consolidated columns appear under the Chargeback column heading on the Account Information spreadsheet. 3. Assign properties to your charge groups. Chargeback provides optional properties that enable you to apply charges for additional items (for example, support), apply charges per resource usage unit, and split charges across groups. Edit Charge Group Properties is a tabbed dialog that serves as the focal point for configuring charge group properties. A description follows for each of the three optional property areas.
Additional Charges
The Additional Charges tab lists items and the amounts applied to them. For example, an amount of $200 has been applied to the item Electricity, and an amount of $100 has been applied to the item Support. To enter an amount of $50 for the item Printer Paper, use the New Additional Item dialog. The apply options on this dialog provide an easy way of distributing additional charges to a charge group and its associated groups or children. Closing the dialog prompts Chargeback to search the data files and update charge groups with any matching data that it finds. See the instructions in the online CA Procedures under the topic, Applying Charges for Additional Items. The consolidated total per charge group for additional item charges is reflected on the Accounting Information spreadsheet under the Chargeback heading, under the Additional Consolidated column.
Charge Per-Unit
The Charge per Unit tab lets you change the charge per resource unit consumed by the users assigned to a charge group. See the instructions in the online CA Procedures under the topic, Applying Charge per Unit Costs. The totals per charge group for charges per resource usage unit are reflected on the Accounting Information spreadsheet under the Chargeback heading, under the Resources Consolidated column.
453
Chargeback
Split Charges
The Split Charges tab lists charge groups, parents, and percentage of the amount to be distributed. Use the Split Properties dialog to divide costs among different charge groups. See the instructions in the online CA Procedures under the topic, Splitting Charges Among Charge Groups. The total per charge group for split charges is reflected on the Accounting Information spreadsheet under the Chargeback heading, under the Split Consolidated column. 4. Perform Reconcile Period to process data. Notice the values generated that appear across the Accounting Information spreadsheet. You are now familiar with the concepts the application uses for performing Chargeback Accounting, and you possess a general knowledge of the tasks involved. You are now ready to generate reports for bills and transactions. The remainder of this section provides information on generating bills, customizing invoices, reporting transactions, and creating graphical reports. After performing Chargeback Accounting, you can again choose to expand the application. See the tasks for performing Budget Accounting in the section, Budget Accounting Walk-Through.
Generating Bills and Customizing Invoices The WBChargeback.xls provides three templatesBill tmpl cons, Bill tmpl ncons, and Bill tmpl sumfor creating invoices. The cells on these sheets are locked; they cannot be edited. However, Chargeback enables you to create bill templates based on those provided in the application. The templates that you create are subject to Microsoft Excel format features. This ability enables you to customize bills to meet your company's specific needs. The Report Bills command generates the invoice. In order to perform this task, Chargeback must be in a closed period. When generated, the name of the bill file appears on the Chargeback header next to the period name. See the instructions in the online CA Procedures under the topic, Generating Bills.
454
Administrator Guide
Chargeback
Reporting Transactions The Transactions command generates a report that can be broken down by charge group, user, computer, resource usage units, and amount. By default, Chargeback generates transaction reports by charge group and uses the RU units from the resources that you specified for processing. You can configure Chargeback to report transactions at any or all of the following levels of detail:

Charge group Computer User Resource type
After selecting the level of detail, Chargeback generates the transaction report. Transaction data displays on the Report spreadsheet of the WBChargeback.xls workbook. You can then create graphical reports for presentation to management using the transaction report data, as discussed in the next section. See the instructions for generating transaction reports in the online CA Procedures under the topic, Generating Transactions. Creating Graphical Reports Chargeback, combined with Microsoft Excel, enables you to display data in a format that satisfies many presentation needs. For example, data can be interpreted into several chart styles, including bar, pi, line, scatter, and 3D. Microsoft Excel standard functionality is available for additional formatting and for printing options. See the instructions for presenting resource data in reports in the online CA Procedures under the topic, Creating Graphical Reports.
Budget Accounting Walk-Through

After performing Chargeback, you can choose to expand the application to offer its maximum accounting power. The Budget Accounting level provides the ability to do the following:

Set and maintain preset budgets per charge group. Advise when budget values are exceeded.
455
Chargeback
The tasks for performing Budget Accounting are listed following. See the instructions for accomplishing each in the online CA Procedures under the topic, Walking Through Budget Accounting. 1. 2. After completing Step 4 under Chargeback Accounting Walk-Through, perform Rollback Period to reset the period. Set the accounting level to Budget Accounting. Notice how the Budget column heading appears and the following columns are added to the Accounting Information spreadsheet: Period Consolidated, Used (Period) Consolidated, Year Consolidated, and Used (Year) Consolidated. 3. Assign a monetary ($) value to your charge groups. As stated earlier, properties for charge groups are configured using the Edit Charge Group Properties dialog. Setting the level to Budget Accounting adds a fourth tabbed section, Budget, to that dialog. You can define a budget amount per charge group by simply selecting a charge group and entering a ($) value in the Budget field. Closing the dialog prompts the application to automatically update the properties for the charge groups that you selected; the values appear in the columns under the Budget column heading. Also, Chargeback automatically adds the budget values defined to the charge groups that you created to your top level, Enterprise, charge group. 4. Perform Reconcile Period to process data. When processing is complete, Chargeback reports a balancededucts the amount for all charges from the preset budget amountper charge group. Notification is received when a budget has been exceeded. You are now ready to define the structure of your Chargeback application in detail and begin using the Chargeback component to perform your accounting (Resource, Chargeback, and Budget) requirements. The remainder of this chapter provides additional information on features that can enhance your understanding of the Chargeback application.
456
Administrator Guide
Chargeback
Chargeback Period Concepts

You can create up to 12 monthly accounting periods per year if you choose the period accounting option in the Configure folder. You can set a budget amount at the time you create a new period.
Closing a Period
When you close a period, the resource data and the Chargeback program structure used for that period are saved in a workbook file in the closed_periods directory. A backup copy of the WBChargeback.xls workbook is created. When you reopen a period for editing or viewing, the period restores to its condition at the time of closing. Two options for reopening an accounting period are listed following:

Reopening a Period
View Period Edit Period
The View Period command enables you to view an old, closed period. The old period is opened in Closed mode, which means that the processed data is protected from any changes. You can generate reports, create a user list, transfer summary files, and configure for Chargeback. The Edit Period command enables you to reopen an old accounting period. An old period is opened in Open mode, which means that the processed data is not protected from changes. You can view the period, generate reports, reconcile the period, and rollback the period. Edit Period restores the Chargeback data, including the overall Chargeback program structure for that period. See the instructions for creating and managing periods in the online CA Procedures under the following topics:

Creating a New Period Closing an Open Period Viewing a Closed Period Editing a Closed Period
Alternately, you can choose to create accounting periods using a previously defined Enterprise Management calendar. See the instructions for creating Enterprise Management calendars in the online CA Procedures under the topic, Defining Calendars.
457
Chargeback
Where Resource Files Are Stored

By default, raw resource files are received and stored under new_daily, under the directory C:\NSM\CHARGEBACK\accounting_data. Those files remain there until you reconcile the period. The Reconcile Period command processes raw data files and transfers them under the directory processed_daily. Performing the Rollback Period command resets the period (reverses processing) and moves the files back under new_daily. Therefore, where resource files reside depends on whether the data contained within them is raw or processed. When you close a period, the WBChargeback.xls and WBData.xls files are saved and stored under the directory closed_periods. Those files contain the structure you defined for your Chargeback application for that period, including charge groups, weight factors, and optional properties. A summary CSV file is generated for each closed period and stored under closed_periods\summary.
Security Management
Security in Chargeback is implemented at the menu item level. This means that a security call is made to the Unicenter Security Manager every time a Chargeback menu item is clicked. The security call is made with the current logged on user, the name of the machine, the asset type CHARGEBACK, and an asset name. The asset name used depends on which menu item is clicked. The user is notified with a message if he is not granted access to the operation or if Unicenter security is not started. The asset type is registered in the Common Object Repository the first time Chargeback is started. The name of this type is CHARGEBACK. The asset names used by Chargeback to check access permissions for the current logged on user are shown in the table following. Asset Name NEW CLOSE RECONCILE REPORTS REPORTS REPORTS ROLLBACK Menu Item New Period Close Period Reconcile Period Reports-Bills Reports-Transactions Reports-User List Rollback Period
458
Administrator Guide
Chargeback
Asset Name REOPENVIEW REOPENEDIT CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE CONFIGURE FILETRANSFER
Menu Item Reopen-View Reopen-Edit Options-Charge Group Hierarchy Options-Charge Group Properties Options-Locked Options-Machine Power Weight Options-Weighting Algorithm Options-Configure Options-New Bill Template Options-New Bill Template Options-Delete Bill Template File Transfer
See the instructions for implementing security in the online CA Procedures under the topic, Implementing Security for Chargeback.
Resource Accounting Service

The Resource Accounting component is executed as a Windows NT or Windows 2000 Service. Once installed this service runs as a background process requiring no user interaction. The configuration of the Resource Accounting Service is dependent on the Performance Agent. If no configuration is received from the agent, no data can be provided. When the agent receives a configuration from its manager, or is restarted, it passes this information onto the Resource Accounting service. The Resource Accounting service will then provide the data at a time and place as specified by the agent. The configuration from the Performance Agent determines how the Resource Accounting Service interacts with the other Performance Management tools; however, it does not alter how the service monitors resources used. Initially the service monitors from 00:00 to the <end of day> as specified by the agent. You can alter this setting at any time. See the instructions for setting the resource usage processing time in the online CA Procedures under the topic, Configuring the Resource Accounting Service.
459
Performance Utilities
Performance Management provides the following utilities:

Performance Cube to CSV File Conversion Utility Chart Definition File Conversion Utility Cubespider Utility
Performance Cube to CSV File Conversion Utility

Use this utility to convert performance cube data to a format that can be easily manipulated by standard tools in addition to those that the Performance Management components provide. For example, you may want to extract data from performance cubes and insert it into your own custom application. The Performance Cube to CSV utility (pcmtocsv) extracts data from multiple performance cubes and stores it into CSV files in a spreadsheet-like format. The utility runs as a console application with various switches and generates a CSV file for each performance cube. This utility provides:

Recursive processing through subdirectories Cube selection filtering Flexible and meaningful CSV file naming Output and error reporting
The pcmtocsv utility is installed into the CA_APPSW directory. See pcmtocsv in the online CA Reference for details on the Performance Cube to CSV utility.
Chart Definition File Conversion Utility

The installation process automatically converts any chart definitions in the /trend/Config directory from the Excel format to the version 3.0 chart definition set format. However, if you have stored any version 1.0 chart definitions in a different directory for any reason, such as for archiving purposes, you may need to convert them later. Performance Management provides a standalone DOS utility for that purpose. The updatechartdef utility is installed into the install-path\Trend directory.
460
Administrator Guide
See updatechartdef in the online CA Reference for details on the chart definition file conversion utility.
Cube Spider Utility

Use this utility to gather performance cubes from remote agent nodes that have previously failed to transfer successfully to the manager machine. The cube spider utility monitors its local cube store, gathers configuration information from the domain server, and determines which cubes it would expect to find in the local cube store. It then automatically gathers the missing cubes from the remote agent that created them. The cube spider utility resides on one or more manager/domain machines and pulls cubes to the center. It runs as a low-priority task and builds and maintains large centralized cube stores. The cube spider utility is installed into the CA_APPSW directory. To administer the cube spider utility:
Identify the machines with cube stores that need to be updated with missing cubes. Obtain the name of the domain server. The cube spider needs to fetch a list of agents and their configuration details to calculate which cubes are missing from the local cube store. Decide whether the cube spider should run perpetually (that is, scheduled to run every day and not used in a one-off fashion to repair the cube store). To achieve this, you can run the cube spider with the Windows service manager. Decide whether to implement the optional remote command execution capability. (See Remote Command Execution section following.)
To tailor your use of the cube spider, use the command line options to do the following:

Limit the number and type of cubes fetched Limit the number of concurrent cube transfers Filter the list of machines from which cubes are collected Control the type of report generated Fetch orphaned cubes (those that were generated before an agent was reconfigured with different cube collection properties) Connect to a domain server on a different machine Use the address instead of the name when communicating with the agent
461
See cubespider in the online CA Reference for details on these and other cube spider utility command line options. The cube spider generates two types of reports: normal and verbose. You can control the type of report generated with a command line option.
Normal Report
Following is an example of a normal report. It contains, for each cube type, the number of missing cubes, the number of cubes fetched, and the number of cubes that do not exist on the remote machine.
*************** Unicenter Performance Cube Spider Report ***************** == Session Options Summary =============================================== Collection Date : Thu Nov 07 17:15:35 2002 Session ID (-F) : <default> Domain Server (-f) : sorcerer.ga.com Operational Mode (-R) : Normal (cubes fetched) Execution Mode : Command line -- Cube Selection Criteria --------------------------------------------Fetch Cubes of Age (-d and -i) : 40d (As per local agent) Fetch Cubes of Type (-T) : All cubes Target Cube Store (-c) : D:\NSM\PERFDATA/performance_cubes Remote Agent Selection Criteria (-m) : staticName=sorcerer.ga.com Fetch cubes intended for recipients (-D) : sorcerer.ga.com Fetch 'Orphaned' Cubes (-o) : No Re-fetch existing cubes (-A) : No - just fetch cubes which do not exist locally -- Data Transport Options ---------------------------------------------Maximum Simultaneous Cube Transfers (-n) : 10 Time to Wait Between Cube Transfers (-l) : 0 secs Timeout For A Single Cube Transfer (-C) : 100 secs Retry Delay When Timeout Occurs (-t) : 15 mins Max Retries For A Remote Agent (-r) : 0 Use agent name or address (-I) : Address -- Reporting Options --------------------------------------------------Report Detail Level (-L) : Normal Report Directory Path (-a) : D:\NSM\PERFDATA\CubeSpiderReports Report Retention (-N) : 20 reports ========================================================================== == Summary Of Fetched Cubes By Remote Agent ============================== -- sorcerer.ga.com ----------------------------------------------Agent : sorcerer.ga.com Profile : Standard Sys Type : xpp501i RCL Status : Remote Cube List (RCL) feature enabled -- Full Daily Cube --------------------------------------------Description : FullDaily Start time : 00:00 Frequency : 5 Delete After : 40d Day Range : Sun, Mon, Tue, Wed, Thu, Fri, Sat -- Totals ---------------------------------------------------41 cubes expected in local Cube Store based on above deletion policy 7 cubes missing and targeted for fetching from sorcerer.ga.com 0 cubes fetched successfully
462
Administrator Guide
7 cubes not fetched as they did not exist 0 cubes not fetched due to communication problems 7 cubes still missing from this cube store -- SubsetDaily ------------------------------------------------Start time : 00:00 Frequency : 20 Delete After : 40d Day range : Mon, Tue, Wed, Thu, Fri ---------------------------------------------------------------No cubes of this type fetched, as they are not configured for delivery to any of the machines defined as recipients in the "Fetch cubes intended for recipients (-D)" list in the "Session Options Summary" section above. ====================================================================== == Session Totals Summary ============================================ 7 cubes missing and targeted for fetching 0 cubes fetched successfully 7 cubes not fetched as they did not exist 0 cubes not fetched due to communication and machine availability problems 7 cubes still missing from the local Cube Store
Verbose Report
Following is an example of part of the output from a verbose report. In addition to the information in the normal report, it lists each individual cube. The boxed area in the example indicates the difference between the normal and verbose report.
*************** Unicenter Performance Cube Spider Report ***************** == Session Options Summary =============================================== Collection Date : Thu Nov 07 17:31:01 2002 Session ID (-F) : <default> Domain Server (-f) : sorcerer.ga.com Operational Mode (-R) : Normal (cubes fetched) Execution Mode : Command line -- Cube Selection Criteria --------------------------------------------Fetch Cubes of Age (-d and -i) : 10d (User supplied) Fetch Cubes of Type (-T) : All cubes Target Cube Store (-c) : D:\NSM\PERFDATA/performance_cubes Remote Agent Selection Criteria (-m) : staticName=sorcerer.ga.com Fetch cubes intended for recipients (-D) : sorcerer.ga.com Fetch 'Orphaned' Cubes (-o) : No Re-fetch existing cubes (-A) : No - just fetch cubes which do not exist locally -- Data Transport Options ---------------------------------------------Maximum Simultaneous Cube Transfers (-n) : 10 Time to Wait Between Cube Transfers (-l) : 0 secs Timeout For A Single Cube Transfer (-C) : 100 secs Retry Delay When Timeout Occurs (-t) : 15 mins Max Retries For A Remote Agent (-r) : 0 Use agent name or address (-I) : Address
463
-- Reporting Options --------------------------------------------------Report Detail Level (-L) : Verbose Report Directory Path (-a) : D:\NSM\PERFDATA\CubeSpiderReports Report Retention (-N) : 20 reports ========================================================================== == Summary Of Fetched Cubes By Remote Agent ============================== -- sorcerer.ga.com ----------------------------------------------Agent : sorcerer.ga.com Profile : Standard Sys Type : xpp501i RCL Status : Remote Cube List (RCL) feature enabled -- Full Daily Cube --------------------------------------------Description : FullDaily Start time : 00:00 Frequency : 5 Delete After : 10d Day Range : Sun, Mon, Tue, Wed, Thu, Fri, Sat -- Cube Fetch Log ------------------------------------------06:11:2002 - already fetched 05:11:2002 - already fetched 04:11:2002 - OK 03:11:2002 - OK 02:11:2002 - OK 01:11:2002 - OK 31:10:2002 - OK 30:10:2002 - already fetched 29:10:2002 - already fetched 28:10:2002 - already fetched 27:10:2002 - already fetched -- Totals ---------------------------------------------------11 cubes expected in local Cube Store based on above deletion policy 5 cubes missing and targeted for fetching from sorcerer.ca.com 5 cubes fetched successfully 0 cubes not fetched as they did not exist 0 cubes not fetched due to communication problems 0 cubes still missing from this cube store -- SubsetDaily ------------------------------------------------Start time : 00:00 Frequency : 20 Delete After : 10d Day range : Mon, Tue, Wed, Thu, Fri ---------------------------------------------------------------No cubes of this type fetched, as they are not configured for delivery to any of the machines defined as recipients in the "Fetch cubes intended for recipients (-D)" list in the "Session Options Summary" section above. ====================================================================== == Session Totals Summary ============================================ 5 cubes missing and targeted for fetching 5 cubes fetched successfully 0 cubes not fetched as they did not exist 0 cubes not fetched due to communication and machine availability problems 0 cubes still missing from the local Cube Store
464
Administrator Guide
By default the report files are placed relative to the cube store used. For example: C:/NSM/PerfData/CubeSpiderReports. You can override this location with a command line option. Several dated versions of the report files are kept for reference. You can control the number of versions with a command line option.
Remote Command Execution
If a large number of cubes are missing from the remote agents cube stores, you can allow remote command execution from the cube spider host on the remote agent machine. Remote command execution increases the performance of the cube spider by enabling it not to attempt to fetch non-existent cubes. To allow remote command execution, the machine running the cube spider must be in the remote machines cafthost.cfg file:
On a Windows machine, start a DOS box. On a UNIX machine, start a root shell. Enter the following command on the remote machine:
cafthost -a [IP address of machine running cubespider]
For example: cafthost -a 101.202.111.222, where 101.202.111.222 is the IP address of the manager machine where the cube spider is running Since CAFT optionally allows remote command execution, the cube spider can obtain a listing of the available cubes on a remote machine. There are two reasons for enabling this feature: efficient cube transfers or fetching of orphaned cubes. Efficient cube transfer means not attempting to fetch cubes that do not exist. For example, if an agent keeps one year of cubes, but has only been running for a week, 51 weeks of cubes do not exist. If the cubespider cannot get a list of cubes on that agent through a remotely executed dir or ls command, it tries to copy 51 weeks of non-existent cubes. With remote command execution enabled on the remote host, the cubespider can get a list of existent cubes and thus only copy the week of data (the cubes that actually exist). During normal running of an agent, it is likely to be reconfigured from time to time. These new configurations may involve changes to the collection properties of the cubes; such as, different start and stop times. As a result, there may be cubes on an agent that do not correspond to the configuration the agent is currently using. With remote command execution the cube spider can find and copy these orphaned cubes. In summary, CAFT remote command execution is essential for fetching orphaned cubes and beneficial for efficient cube transfers.
465
Chapter
Event Management
Event Management facilities provide a focal point for integrated message management throughout your heterogeneous networked environment. It is capable of monitoring and consolidating message activity from a variety of sources. In addition to message consolidation and monitoring capabilities, the Event Management component lets you identify event messages that require special handling and initiate a list of actions specified for handling that event. You can channel event messages from any node in your network to one or more monitoring nodes through support of industry standard facilities. This makes it possible, in fact easy, to centralize management of many servers and ensure that important events are detected and routed to where they can be acted on most expeditiously. For example, you may want to route message traffic to three different Event servers by directing event and workload messages to the production control event manager, security messages to the security administrators event manager, and problem messages to the help desk administrators event manager. Further, by filtering the messages that appear on each console, you can retrieve specific information about a particular node, user, or workstation. Wireless Messaging provides alternate channels for operator input in situations where the operator may be unable to access a CA Event Console. Two types of messaging protocols are supported: email and pager. Using the SMTP/POP3 mail messaging protocol, pager messages may be sent to and received from two-way pager devices. An incoming message may trigger any series of actions you define to be performed by the Event Console in response to the message.
Event Management
51
Establish Date and Time Controls for Automated Event Processing
The successful implementation of Event Management involves the following activities:

Establishing date and time controls for automated event processing Trapping important event messages and assigning actions Putting Event Management policies into effect Monitoring message traffic Providing Wireless Message Delivery Customizing your Unicenter NSM consoles Using SNMP to monitor activity Implementing maintenance considerations
Establish Date and Time Controls for Automated Event Processing

Determining a course of action based on when an event occurs can be critical to the proper handling of the event. You define the when criterion using calendar profiles. Define calendars through the Enterprise Management GUI or the cautil command line interface. Note: The use of calendars with Event Management is optional. You can proceed to the Trap Important Event Messages topic if you are not setting date and time controls now. Unicenter NSM provides facilities to define as many calendars as you require to meet your needs, and to store them for easy reference. The GUI has a significant advantage over command line entry because it simplifies date and time specifications. You can use the mouse to click specific days, months, and times, or you can click on a specific day and drag the cursor to the last day, rubber-banding the range of days to be set.
Calendar Sharing
The Unicenter NSM calendar object is a common object and thus is available for use by any of the Enterprise Management functions. We recommend that you identify your calendars primary function in a naming scheme. Calendars can be created for use by any of the Enterprise Management functions. For example, use a single holidays calendar for your company whenever company holiday dates need to be considered.
52
Administrator Guide
Trap Important Event Messages and Assign Actions
First, create a calendar, such as your company holidays calendar, and save it. The next time you create a new calendar, associate your holidays calendar with this new calendar by selecting Options Configure commands. You then only need to click the appropriate command button when you want to combine the dates set in this calendar with the new calendar you are creating. See the instructions for setting date and time controls for automated event processing and calendar administration in the online CA Procedures under the topic, Defining Calendars.

Through Event Management message record and message action profiles, you can identify the messages that are important to your operation and define the special processing to be performed automatically whenever Unicenter NSM encounters these messages. Event messages are generated by Unicenter NSM components, system components, utilities (such as cawto), and user programs. All of these messages are sent to an Event daemon for processing. The default processing, in the absence of any policy, is to write the messages to the Event Console log file. To define a message processing policy to filter the messages received by the Event daemon and define specific actions to be taken, you begin by defining message records that describe which messages need processing. The message record defines matching criteria. Each field in the event message has a corresponding field in the message record. Message record fields may contain wildcards to match a wider range of event messages. A message record has associated message action records that describe what action to take when a message matches the message record.
Event Management
53
Message Sources Messages can be directed to Event Management from a variety of sources:

From the cawto command, which sends a message to the Event Console. From the cawtor command, which sends a message to the Event Console and waits for a reply. The message appears in the held messages pane and will not be deleted until the operator replies. From the oprcmd command, which sends a request to execute a command to the designated target machines. From the careply command, which lets you use any terminal to reply to a message being held by the Event Console. From Enterprise Management components such as Workload Management, Security Management, and File Management, which generate messages directly to the Event Console. From SNMP event messages and traps that are routed to the node identified by the CAIOPR daemon as the provider for the Event Management service through the Computer Associates trap daemon catrapd. From the Windows Event Log, which can send messages to the Event Console. From the syslog daemon on UNIX/Linux platforms, where messages are routed through the syslog daemon to the Event Console. Messages issued through the logger utility are included as they also use the syslog daemon. These messages may have originated on a platform not running Unicenter NSM. (Messages issued by Unicenter NSM components are sent directly to the Event Console, not through syslog, in order to take advantage of message matching fields.) Note: Unicenter Event Management requires access to the /etc/syslog.conf file. Ensure that the permissions are set correctly before you start Unicenter Event Management.
From Agent Technology policies, which issue messages to the Event Console. From inocmd32, the virus scan utility, which sends messages upon virus detection. From the Unicenter NSM SDK or API functions, such as EmEvt_wto, which issue messages to the Event Console.
See the online CA Reference for additional information on the cawto, cawtor, oprcmd, careply, inocmd32, and catrapd administrator commands.
54
Administrator Guide
Identifying Messages That Require Special Handling You identify messages that require special handling by creating message record objects. You then specify what those special handling requirements are by creating message action objects that are associated with a particular message record object. Once defined, message records and message actions become a message handling policy that identifies the events that have special handling requirements and the tasks that must be performed when they are detected.
Message Records
Event Management provides two categories of message records to identify important events: Message Type Message Command Description Represents the output text string received by Event Management and displayed on the Event Console. Represents the text string input by someone operating the Event Console. (You can enter commands at the command field of the console, use customized buttons to automatically issue commands, or enter these commands as command line arguments provided to the oprcmd utility.)
UNIX/Linux command output can be used as a source of text that you can substitute into the message text in database message records during the message matching process. For example, the string pwd in the database record message text field causes the current directory to be inserted into the message text.
Message Actions
Message actions specify what Event Management should do when it detects a match between an input event message and a message record. Possible actions range from simply highlighting messages on the console display to replying to messages, opening problems, or executing commands or other programs. For example, to ensure that a message catches the attention of the person responsible for monitoring the console, you can use either or both of these methods:
Route the message to a held area of the console GUI where it remains until acknowledged by the console operator. Assign an attribute, such as highlighting or blinking, to make a message more noticeable on the Event Console.
Event Management
55
Message Activity Distribution Unicenter NSM lets you distribute message and action activity across multiple servers and their clients. This capability enables you to do the following:

Create a central event log from which all servers can be monitored. Send selected messages to another server for processing. Manage special functions such as security or tape management on dedicated consoles.
Whenever the Event database is loaded, it checks the EVALNODE of every message record against its own node name. If its node name matches the EVALNODE of the message record, the record and all associated message actions are read into memory. If there is no match, the message record is ignored. The set of message and message action records read into memory constitute the Event policy for the current execution of the Event daemon until the policy is reloaded by a restart or the opreload command. Message Action Policy Definitions and Servers Through message record and action policies, you select a message based on content and then define the desired action. One of the message action capabilities available to you can be used to instruct Event Management to perform an action on a specific (and potentially remote) machine. Actions such as sending the message to a remote machine or initiating a command on the remote machine are accomplished easily. For example, you can identify a network security event or a tape mount event for routing to an alternate machine simply by defining Event Management policies to that effect. Actions that need to be performed on remote nodes can be done synchronously. Action processing waits for the remote action to complete and return a completion code before proceeding to the next action. This means that the completion code received from the remote action can be tested as part of a message action and used to control subsequent processing. Remote actions are not attempted if the target node is known to be unreachable.
56
Administrator Guide
Message Routing to Remote Hosts Routing messages to a remote machine through message/action policies is most easily achieved by creating a message record that traps those events and a message action that uses the FORWARD action keyword and specifies the remote node to which you want the messages sent. Since one message can have many message actions, it is easy to send messages to multiple machines if you wish. You can specify the name of any machine that is currently defined for CAICCI remote communication. The configuration is set up during the installation procedure. For more information, see the topics under Unicenter NSM Installation and Setup in the online CA Procedures. On UNIX/Linux platforms, one source of event messages is the Berkeley syslog daemon, which can route messages to a Unicenter NSM server for processing, even those originating from servers not running Unicenter NSM. Event Management takes advantage of the powerful messaging facilities provided by the syslog daemon to do the following:

Select from several priorities, levels, and facilities of messages. Route messages by level or priority to different devices. Route messages by level or priority to different hosts. Receive messages from other hosts for local display.
To instruct the syslog daemon to route all messages to a remote machine, edit the syslog daemons configuration file and insert the remote host name in the action part of the line, prefixing the host name with a single at sign (@). See the instructions for configuring the Berkeley syslog daemon in the online CA Procedures under the topic, Setting Up the Berkeley Syslog Daemon. Note: If you use both the Berkeley syslog daemon and specific message action policies to reroute the same messages to the same remote machines, those messages will display twice on those remote machines as they were sent there twice, once by the Berkeley syslog daemon and again by Event Management. See the instructions for defining message records and actions in the online CA Procedures under the following topics:

Defining a Message Record Defining a Message Action
Event Management
57
More About Defining Unicenter NSM Message Actions You can use several types of actions in any sequence or combination to thoroughly automate processing of an input or output message. For explanations of these action keywords, see the cautil DEFINE MSGACTION control statement in the online CA Reference. For information on the environment variables that are created as a result of the COMMAND action, see the topic, Environment Variables for Messages and Actions presented later in this chapter. Event Management Message Action Restriction Event Management allows you to restrict the nodes and RUNIDs that are authorized to send the message actions COMMAND, UNIXCMD and UNIXSH to your local host. During the installation process, if setup detects that Event Management was previously installed at that node, you will see a message box informing you of the new message action restriction feature and the default setting that disables message action restriction. You are given the opportunity to override the default and enable message action restriction.
If you accept the default response n to the prompt for message action restriction, setup creates the actnode.prf configuration file for you with a single entry of -n=*,*,E to allow all RUNIDs from all nodes to submit these message actions. If you instead respond y to the prompt for message action restriction, setup creates the actnode.prf configuration file with a single entry of -n=*,*,D to deny all RUNIDs from all nodes the ability to submit these message actions.
When setup detects that you are installing Event Management for the first time on the node, you will see a message box informing you of the new message action restriction feature and the default setting that disables message action restriction. You are given the opportunity to override the default and enable message action restriction at that time.
If you accept the default response n to the prompt for message action restriction, setup creates the actnode.prf configuration file for you with a single entry of -n=*,*,E to enable message action submission for all RUNIDs from all nodes. If you instead respond y to the prompt for message action restriction, setup creates the actnode.prf configuration file with a single entry of -n=*,*,D to disable all RUNIDs from all nodes from submitting these message actions.
58
Administrator Guide
You can change this rule at any time after installation by executing the caevtsec utility located in the $CAIGLBL0000\bin directory. The utility only allows the uid 0 user to maintain the file and preserve the file permissions. The file may also be maintained using a UNIX/Linux text editor. For more information about using the caevtsec utility, see the online CA Reference. The actnode.prf configuration file is located in the $CAIGLBL0000/opr/config/<hostname> directory. You can use this file to maintain policies that specify how message action restriction is to be enforced based on the submitting node and RUNID. The file must be owned by root and only a uid of 0 may have write access to it. An individual entry in the file has the following format: -n=nodename,runid,flag where: nodename Specifies the node from which the COMMAND, UNIXCMD or UNIXSH message action is initiated; it may contain a trailing generic mask character. runid Specifies the node from which the COMMAND, UNIXCMD or UNIXSH message action is initiated; it may contain a trailing generic mask character. flag Specifies D for disable (feature is active; disallow the message action submitted by RUNID from nodename), E for enable (allow the RUNID from nodename to submit the message action), or W for warn (check the rule but allow the message action submission to occur). Some examples are listed following:
-n=*,*,E
This is the default rule in effect if, during installation, you elected not to activate message action restriction. The rule states that for all nodes and all RUNIDs, COMMAND, UNIXCMD and UNIXSH message action submission is allowed. This is the default rule in effect if, during installation, you elected to activate message action restriction. The rule states that for all nodes and all RUNIDs, COMMAND, UNIXCMD and UNIXSH message action submission is disallowed. This combination of rules only enforces a message action restriction on RUNID root and allows all other RUNIDs to submit the message actions.
-n=*,*,D
-n=*,*,E -n=*,root,D
Event Management
59
-n=*,*,E -n=mars,*,D -n=*,root,W
This combination of rules allows all RUNIDs to bypass message action restriction unless the request comes from the node mars. In that case, message action restriction is enforced for all RUNIDs. The last entry sets a warning type restriction rule for RUNID root if it comes from a node other than mars.
Event Management scans the entire configuration file for a best match and uses that rule. It uses the node field as a high level qualifier when searching for a best match. For example, consider the following:
-n=mars,*,D -n=*,root,W
If these are the only two entries in the file, any request coming from the node mars uses the disallow rule. The user root only uses the warning rule if the request comes from a node other than mars.
Environment Variables for Messages and Actions When Event Management invokes a command or script as a result of a COMMAND or UNIXCMD action, the new process is created with a list of new environment variables that contains information about the event that you may find useful. Programs, Windows .bat files, or UNIX/Linux shell scripts can reference these variables, but they cannot be altered. Variable EVENT_CATEGORY EVENT_DATEGEN EVENT_DEVICE EVENT_JOBNAME EVENT_JOBNO EVENT_JOBQUAL EVENT_JOBSET EVENT_LOGRECID Description Category field from the event Date (yyyy/mm/dd) event was generated Device associated with the event Event jobname (if from a Workload job) Event job number (if from a Workload job) Event job qualifier (if from a Workload job) Event jobset (if from a Workload job) ID of the last record written to log when the command is invoked (possibly the current event if it is not suppressed) Message number field from the event Node origin associated with the event User name under which Enterprise Management is processing this message action ID (decimal) of the process that generated the event
EVENT_MSGNUM EVENT_NODEID EVENT_OPUSER EVENT_PID
510
Administrator Guide
Variable EVENT_PROGRAM EVENT_REPLID EVENT_SEQNO EVENT_SEVERITY EVENT_SOURCE EVENT_STATION EVENT_TAG EVENT_TEXT EVENT_TIMEGEN EVENT_TIME8 EVENT_TOKEN EVENT_TYPE EVENT_UDATA EVENT_USERID EVENT_YYYYMMDD
Description Program that generated the event (for example, cawto.exe) Reply ID returned if the event was WTOR Sequence number of the action that invoked this command Event severity Event source Event station Platform tag associated with the event (WNT, HPUNIX, and so forth.) Full text of the event Time (hh:mm:ss) event was generated Time (hh:mm:ss) command was invoked Token number of message record that matched this action Type of event: MSG/CMD/REPLY/WTOR User data (value of the CA_UDATA environment variable when the event was generated) User origin associated with the event Date the action was invoked
The sample CMD file listed following references settings in the following submitted job definition:
define smgrec msgid=* scantext=*error* define msgact name=(*,100) action=commandtext=logerr.cmd
The logerr.cmd file contains the following:

@echo off Rem: This command file is invoked from Event Management action to log some event data to a file. Rem: The %EVENT_..% variables contain values from the event that invoked the action. echo LOG,%EVENT_YYYYMMDD%,%EVENT_TIME8%,%EVENT_NODEID%, %EVENT_USERID%,%EVENT_TEXT% >>c:\temp\err.log
Event Management
511
Message Enhancement
Event Management enhances messages by automatically providing the source or origin of each message along with the message text. You can also simplify or customize the message text to meet the specific characteristics of your enterprise. The following action keywords let you control the message text that appears on the Event Console:

EVALUATE FORWARD SENDKEEP SENDOPER WAITOPER
For explanations of these action keywords, see the previous discussion or to the cautil DEFINE MSGACTION control statement in the online CA Reference.
Correlating Event Console Messages

It is often true that a single message coming across the Event Console is not important unless seen in context with other messages. By constructing a series of message records and actions, you can be notified and take action if two or more events occur that together have more significance to your enterprise than any one of the events may have when it occurs in isolation. For example, assume you have two PCs in your accounting department. If one of these PCs goes down, it is a problem and you probably have established Problem Management policies to deal with such an occurrence. However, should the second PC also go down, the problem suddenly becomes critical and the action you want to take in this situation may be quite different. A solution to the problem would be to define message records that will trap the event messages coming to the Event Console informing you that Accounting PC #1 and Accounting PC #2 are coming down. Then define message actions for each message record that test for the occurrence of the other event message. You will now be automatically notified of the critical situation that exists in the Accounting department. Sample procedures for two approaches to defining Event Management policy that correlates two incoming event messages are provided in the online CA Procedures under the following topics:

Correlating Two Messages in Event Management Using REXX to Assist Correlating Messages in Event Management
512
Administrator Guide
Put Event Management Policies into Effect
Tip: When you use the Event Console simultaneously with the 2D Map, the visual information regarding device status is interpreted by messages present in the Event Console.
Using Advanced Event Correlation You can also use the Advanced Event Correlation (AEC) feature of Unicenter NSM to correlate events. AEC is a powerful tool that interprets and correlates events in your dynamically changing environment. AEC determines the root cause and impact of failures reported to the Event Console by analyzing each failure message in relation to other failure messages. See the appendix Advanced Event Correlation for more information.

For performance reasons, the Event Management service reads all message records and message action policy definitions from the Event Management database tables during startup and maintains active lists of message records message actions in memory resident tables. Database updates are not immediately reflected in these memory resident tables. Subsequent changes to message records and message action policies will not take effect until the Event Management service refreshes the real-time versions of policy with which it is currently running. You accomplish this either by using the Unicenter NSM command opreload or by shutting down and restarting the Event Management component. The opreload command directs Event Management to refresh the active message record and message action lists immediately with the definitions stored in the Event Management database. Any requests for automated message processing remain in queue until the refresh of the active lists is complete. See the instructions for putting Event Management policies into effect in the online CA Procedures under the topic, Refreshing the Active Event Management Policies.
Event Management
513
Event Agent
The Event Agent is a lightweight Enterprise Management solution that provides Event Management functions on any Windows NT or Windows 2000 system that requires only Event Management. You can deploy the Event Agent on machines with limited resources and without database connectivity. Event Agents can retrieve policy either from a local DSB file, or from a remote Event Management installation on Windows. Event Agents can selectively process and forward events to other Event Management installations on Windows. This makes it easy to centralize management of many servers and ensure that important events are detected and routed to a location where they can be acted on most expeditiously. The Event Agent retrieves policy from the Event Management server automatically on startup. Once the policy information is transferred to each agent machine, all Message Records and Actions are evaluated as if they were defined locally. Thus, if certain message policy is valid for all remote machines, it needs to be defined only once on the server machine. All administration of event policy for the agent machine occurs at the server. To refresh event policy for the agent machine, shut down and restart the agent machines Event Management component. Policy Retrieval The Event Agent for Windows NT/2000 can be configured to retrieve policy from a DSB file or from a remote Unicenter Manager on Windows. After installation, default DSB files will be located as follows: File Name CAOPR.DSB (Event) CA_CAL.DSB (Calendar) Location NSM\LOGS\ NSM\CAL\
514
Administrator Guide
Generate a DSB file on a Unicenter Manager by following these steps: 1. Using the OPRDB utility to save the current Event Management policy database:
oprdb save dsb-file-name
or 2. Using the CAUTIL command to save selected policy records:

select msgrec msgid= .....other selection criteria... save: msgrec file=dsb-file-name
Remote Management On a machine with Unicenter NSM installed, use the EM Connection Manager program to add the remote server with the Agent to the list of known servers. You are then able to open the Console Log for the agent. To manage a remote NT Agent from an NT Server, enter the following command at the command line:
unicntrl start all server agent-name
or
unicntrl stop: all server agent-name
To manage a remote UNIX/Linux Agent, enter the following command at the command line:
rexec agent-name -l userid unistart all
or
rexec agent-name -l userid unishutdown all
To update a remote agent configuration, use the CAUTENV utility command as shown following:
oprcmd -n agent-name cautenv setlocal var-name value
or
oprcmd -n agent-name cautenv setopt:
opt-name value
Notes: 1. VAR-NAME or OPT-NAME and other values can be obtained from the Unicenter Configuration Settings notebook by pressing F1 on the selected setting. The user issuing the command must be included in the Users authorized to enter commands (CA_OPR_AUTH_LIST) on the Agent node. Authorized users can be found in the Unicenter Configurations Settings notebook.
2.
Event Management
515
3.
The Agent must be active for the commands to be executed.
Important Configuration Values Configuration Values CAUTENV SETLOCAL CA_OPR_PROXY NODENAME CAUTENV SETLOCAL CA_OPERA_NODE NODENAME Description Instructs the Event Agent to retrieve policy from NODENAME. Instructs the Event Agent to forward events to NODENAME. Execution of various Event Management commands (cawto, oprcmd, and so forth.) takes place on the CA_OPERA_NODE unless you use the -n parameter to specify a node on which to execute. To execute a local opreload, use the following command: oprcmd -n mynodename opreload. After the Event Agent is installed, you may want to set CA_OPERA_NODE to be your local machine. In this case, you will have to use standard Event policies to selectively forward various events to another manager for processing. CAUTENV SETLOCAL CA_OPR_PROXY "" CAUTENV SETLOCAL CA_OPR_DSB DSB_FILE_FULL_PATHNAME Instructs the Event Agent to use the specified DSB file only. The default is %CAIGLBL0000% \logs\caopr.dsb.
Note: You must stop and restart the Event Agent for any of the previous configuration changes to take effect.
516
Administrator Guide
Monitor Message Traffic

Event Management gives you a visual window into message activity that lets you view and immediately respond to events as they occur, providing an unprecedented level of control over your systems. The Event Console provides two window panes to view messages written to the Event Console Log.
Held Messages
The Held Messages pane displays messages that require a response. These messages are often critical and require immediate attention or require an operator reply. Held messages that require an operator reply are WTOR (Write To Operator with Reply) messages. When no held or WTOR messages exist, the windowpane reserved for messages of that type disappears. Note: If a reply pending message (WTOR) has been sent and either the Event Manager or the entire system goes down while the message is still pending, the message is queued and activated automatically (appears to be still active) when the Event Manager is brought back up.
Log Messages
The Log Messages pane displays all logged messages (including held messages). Note: Through message records and message actions, these messages can be further highlighted with a variety of user-specified colors and attributes to make them more noticeable on the console display.
Event Console Log
The Event Console Log provides both a real-time and an historical online interface into all Event Management message activity. Created daily, the console log is a file containing all messages written to the Event Console Log on a particular day. You can view the previous days log or the next days log (relative to the date of the log you are currently viewing), or select a log created on a specific date. On UNIX/Linux and Compaq NonStop Himalaya systems, you can choose to view all messages in the log file or you can download the last portion of the log file. For example, you can limit your view to the last two hours. By default, you are prompted for a choice when you start Console Log. After making an initial selection for a partial retrieval, you can request additional retrieval by choosing View Retrieve. You can also click the Retrieve Log button on the toolbar. Only Event Management can read these files. You can set the directory where these files are stored with the Console Files Directory (CAI_CONLOG) environment variable. See the online CA Reference for additional information about the CAI_CONLOG environment variable. You should consider a policy for archiving outdated Event Console Log files to tape for off-site storage. See the section Cleaning Up Log Files later in this chapter.
Event Management
517
Filtering Sensitive Console Messages

Security Management support for Event Management Console Log viewing lets you restrict Console Log message access to only authorized users and user groups. By defining Console View objects to the Unicenter NSM database, you can filter messages from the Event Management Console Logs, thereby limiting certain users access to sensitive messages that would otherwise be displayed. Security Management furnishes two asset types you can use to define Console Log message access:
CA-CONVIEWEach Console View database record is treated as a Security Management asset of this type. Rules can be defined to control user and user group permissions for creating, modifying, deleting, or listing these Console View database objects. CA-CONVIEW-ACCESSWhen users select the Console Log, views are determined by the access that has been granted or denied them by use of this asset type. You can define this asset type either through Event Management, or through Security Management user and user group profiles. By attaching a Unicenter NSM calendar profile to the definitions of this asset type, you can restrict Console Log access to specific times. For example, assume that USER1 is limited to VIEW1 Monday through Friday during regular business hours, but to only VIEW2 outside of normal business hours; you could enforce these restrictions using a Unicenter NSM calendar.
For detailed descriptions of these asset types, see the Asset Types Table in the online CA Reference. Important! Users must be defined in FAIL mode in order for your access rules to be enforced. The only Enforcement mode that results in access being denied is FAIL mode, whether explicitly set in the user profile, or implicitly set by referring in the user profile to a System Violation Mode of FAIL. After defining Console View access rules, execute the commit process to put them into effect. See the topic Initializing and Populating the Database in the Security Management chapter for information about the commit process. Each user accessing the Event Management Console Log is presented with a list of Console Views from which to choose. They can choose only those views that are associated with their user ID. Info Console View access rules exist for a user, the entire Console Log appears. Once a user is removed from the Console View definition, that view is no longer available to the user.
518
Administrator Guide
See the instructions for monitoring message traffic in the online CA Procedures under the following topics:

Viewing Console Messages Replying to Console Messages Acknowledging or Replying to Held Messages Capturing Acknowledgments and Replies to Held Messages Defining Console View Access Using Event Management Defining Event Management Console Views Using Security Management
Browsing Event Logs from Mobile Devices

Unicenter for Pocket PC contains a lightweight interface that provides access to Event Management logs on other servers. To better fit the form factor, the interface differs from the conventional console GUIs by emphasizing filtering of the event log records you want to receive and display. As an extension to the filtering functionality available with the Java and Win32 consoles, the Pocket PC menus display intuitive event filters that allow you to retrieve events without creating complex filters. For example, to retrieve all events related to Unicenter NSM Security, selecting Security from the Filter menu retrieves all security-related events. In addition to these convenient predefined filters, event filtering is fully customizable on the Pocket PC. Event Dispatch from Mobile Devices to Unicenter Event Managers Unicenter for Pocket PC allows for the dispatch of events to specified Event Managers with the conventional WTO (Write To Operator), WTOR (Write To Operator with Reply), and OPRCMD (see the online CA Reference for a description) commands.
Event Management
519
Provide Wireless Message Delivery

Unicenter Wireless Messaging operates as an extension to the Event Management system. Wireless Messaging provides a channel for operator input in situations where the operator may be unable to access an Event Console. Two types of messaging protocols are available: email and pager. Using the SMTP/POP3 mail messaging protocol, pages can be sent to and received from two-way pager devices. An incoming message may trigger any series of actions you specify to be performed by the Event Console. To define Event Management policies for sending and receiving pager and email messages, use the Wireless Messaging Policy Writer GUI to do the following:
Specify the text of the incoming message that triggers the pager or email response. Define up to three pager or Email messages to be sent during the Event Console action sequence. Define the text of the pager or email message and up to six possible replies to that message. Administer the Wireless Messaging address database and set the path used for storage and workspace.
See the section, Creating Message Policy: The Wireless Messaging Policy Writer, presented later in this chapter. To secure operations, warning messages initiated by the Event Console are assigned a unique identifier and must have a correctly formatted reply before any action is taken. Once a response is received or the page has timed out, the identifier is expired and cannot be reused.
Understanding Wireless Messaging Policy

The Wireless Messaging client executable, capagecl, uses two files to generate outbound messages and interpret replies. The message file lists the active responses that are sent with a notification message and gives directions to the Wireless Messaging client. The configuration file applies the numerical return code to each active response; this code will be returned to the Event Console. The following list describes how these policy files are used: 1. 2. A message is formed (from those defined in the message file) and sent to the remote pager using the Wireless Messaging server. The Wireless Messaging client waits for a response.
520
Administrator Guide
3. 4.
The pager operator chooses a response from the list and replies to the message. The Wireless Messaging client receives the response using the Wireless Messaging server and translates it to one of the return codes defined in the configuration file.
The following topics provide detailed information on the message files and configuration files. Using Message Files Wireless Messaging reads input information from the message file. This may include any fixed-text information to be sent as part of the message, and many of your applications command line text and parameters. Note that the message can send only fixed text, and Unicenter NSM environment variables, such as &NODEID, will not be resolved unless they are included in the text of the notification message on the command line. The primary importance of the message file is that it may include the list of preformatted replies expected from the message recipient. The processing of replies is, however, independent of the message file contents. Additional or alternative replies may be sent by the message recipient, and will be resolved into actions if these replies are included in the configuration file and if policy actions are in place to handle the additional return codes. Apart from directives to the Wireless Messaging client (set xxx=yyy), text written to the message file will be appended to the message specified on the command line and included in the dispatched message. The actual format of the reply text is dependent on the device to which the message is to be sent. The wireless messaging client recognizes replies delimited by three underscore characters, as in ___Reply___ though this formatting may be transparent on remote devices. For instructions on formatting the commands embedded in the text file, see the information on message files in the online CA Reference.
Event Management
521
Using Configuration Files Configuration files store the address information, the audience information, the message group information, and the list of replies with their associated return codes. When a message arrives at the Unicenter NSM mailbox, the message server opens it and searches for an ID code. If this code matches the code expected by an instance on the Wireless Messaging client application, the server passes the message on to that client. The client processes the text of the message and looks for a reply. If a reply is found, the client checks the appropriate configuration file for a match to find the code it should return to the calling application. The Reply Information Configuration file then maps responses to return codes. In the following sample configuration file, Acknowledge is mapped to return code 97.
# SendKeep Text= 30 Page Someone Else= 31 Banner Message= 37 Acknowledge= 97
The Reply Information Configuration file may include any or all of the responses sent out with the initial message, and can include additional responses that were not sent as suggestions but may be useful to the remote user. Valid return codes range from 6 through 95 and can be unique to each client instance. Note: Return codes 6 to 95 may be assigned to user replies. All 90 return codes may be defined in any configuration file, but configuration files and standard policy generated by the Wireless Messaging Policy Writer will recognize only those replies you list when defining the policy. Other replies can be interpreted if these are manually added to the configuration file, or a default file is used. Unless one of these methods is employed, return code definitions can be arbitrary (as long as they are unique) without affecting the behavior of the policy.
522
Administrator Guide
The reserved return codes (0-5 and 96-99) are used by the system. The following codes are significant. Code 03 96 97 98 99 Meaning Message not sent (rejected by calendar check) Abort code (triggered by server termination or capagecl I issueid X command) Acknowledge Reply not found in the given configuration file Wireless Messaging client timed out without receiving a reply
For the format of each of the configuration files, see the configuration file information in the online CA Reference.
Sending a Message
To send a message using Wireless Messaging, the host machine must have access to SMTP and POP3 servers, Wireless Messaging must have been selected during installation, and the Wireless Messaging server must be running. Starting the Server The Wireless Messaging server is started as part of Event Management. If it is not started, use the following command:
UNICNTRL START OPR
Verify that the server is running by viewing the output from UNIFSTAT. Once the server has started, it will attempt to make a connection to the mailing system and the database. Using the Wireless Messaging Client capagecl The Wireless Messaging client is used to format messages and pass them on to the server. When a reply is expected, the Wireless Messaging Client executable, capagecl.exe, waits for a reply, matching the ID number of the page it sent with the text of a reply that it is expecting to receive.
Event Management
523
This executable has four basic command line options, which specify the following:

The message address The text of the message The message file (.rep) containing the text of the replies (to be sent to the remote device) The configuration file (.cfg) used to interpret responses
The Wireless Messaging client performs a number of additional formatting and administrative tasks. These are set by entries on the command line or by directives in the message file. Detailed descriptions of the command line options are provided by the topic capagecl in the online CA Reference. Sending a One-Way Message from the Command Line See the instructions for sending one-way messages in the online CA Procedures under the topic, Sending a One-Way Message from the Command Line. Sending a Two-Way Message from the Command Line In order to send a two-way message, both the message and configuration files must be generated for use by the pager client. See the instructions for sending two-way messages in the online CA Procedures under the topic, Sending a Two-Way Message from the Command Line.
Responding to a Message
To respond to a simple email message, the following actions must be taken:
Open the original message and extract the ID# code, which is normally on the subject line. Create a new message addressed to the Unicenter NSM server and copy this ID to the new message. To set the reply, copy the text of the required reply from the original message and paste it to the new message.
To respond to a two-way message, data must be sent back to the server giving the ID# code of the initial notification message and the text of one of the listed replies.
524
Administrator Guide
Implementing Command Messaging

The Wireless Messaging tab of the Configuration/Settings notebook provides the environment variables for Wireless Messaging. You can set the Server security mode and Inbound command authorization code to enable the Wireless Messaging server to accept commands from remote devices. Specially formatted messages sent to the server will be processed and passed to the Event Console as oprcmds. You can set the Autoreply to unsolicited messages to YES if you want to acknowledge receipt of validated and rejected pages. This option also tells the server to produce a warning message when a reply arrives for which no client is waiting. For details on setting the environment variables, see the information on Event Management environment variables in the online CA Reference. For security reasons, the password is contained in an encrypted portion of the command message. Using the PageNet Pagewriter application, this process is transparent, although the password must be entered at the time the page is generated. The higher security default option for command paging uses the CAIWMSDB database for address authentication. You can use the Wireless Messaging Policy Writer to administer the list of authorized addresses. For more information, see the topic Creating Message Policy: The Wireless Messaging Policy Writer, following this discussion. To send a command page using unformatted email, the server must be started with the Server security mode environment variable set to L. Setting this option relaxes security. Additionally, a special format must be observed:
The first line of a command pager message specifies the layout of your message, and is used for the automatic answering process. The layout strings are the same as for the capagecl command. The second line contains only the unencrypted password. The third line contains the literal text of the oprcmd to be issued using the Event Console.
Event Management
525
Creating Message Policy: The Wireless Messaging Policy Writer

An Event Management policy is triggered by an inbound message. Using the Wireless Messaging Policy Writer, you can create a simple notification policy or two-way messaging policies. Using the return code from the capagecl executable, you may integrate calls to the Wireless Messaging client into a sequence of Event Management policy. You can define message actions to respond to the pager message, and make their execution conditional on the return code received in the pager message. The Wireless Messaging Policy Writer enables you to define policy for remote messaging by building policy templates. These template files are built using the information you supply in the Wireless Messaging Policy Writer GUI. See the topic, Using Template Files, presented later in this discussion. The following items describe some of the policy you may define using the Wireless Messaging Policy Writer:
The text of the inbound message, which can include all Unicenter NSM substitution variables (such as &1, &source, and &severity). A policy to trigger a remote messaging sequence Recipient data to specify message addressing Which message and set of replies is to be sent The return code that identifies a reply for a notification message
The Wireless Messaging Policy Writer also provides persistent storage, so that email addresses, message layouts, default timeouts, and standard groups of messages need not be redefined for each paging policy. For a detailed description of the fields in the Wireless Messaging Policy Writer GUI, see the topic Wireless Messaging Policy Writer in the online Help. See also the topic Troubleshooting the Wireless Messaging Policy Writer presented at the end of this discussion. Creating a Simple Notification Policy To create a simple notification policy, use the Wireless Messaging Policy Writer to specify the message record text by which your policy is to be triggered. You will also specify the pager or email account to which the message will be sent and the Single Notify policy template. See the instructions for creating a simple notification policy in the online CA Procedures under the topic, Creating a One-way Messaging Policy.
526
Administrator Guide
Creating a Two-Way Messaging Policy The process of creating a simple two-way messaging policy, where a message is sent and the policy sequence waits for a reply, is similar to that for a simple notification policy. See the instructions for creating a two-way messaging policy in the online CA Procedures under the topic, Creating a Two-Way Messaging Policy. Using Template Files The template files used by the Wireless Messaging Policy Writer are modified Event Management database script files. Template files provide the underlying frame upon which the final policy will be based. An example of a template file is one named Single Notify. These files contain command actions used to start the pager client and sequences of conditional GOTOs used to trap return codes. Many of the details, such as the capagecl command lines and condrc= numbers, are supplied to template files by your entries in the Wireless Messaging Policy Writer when generating the fixed script files. Entries in the file that are specific to each policy have been replaced with flag entries beginning with [DUMMY]. For a full list of these substitution flags, see the information on template files in the online CA Reference. A number of policy templates are supplied with the messaging software, and you may create new template files by copying blocks from the existing files and then pasting them into your new file. Defining Message Sets A Message Set consists of the text of a message that is to be sent to a remote recipient, the priority as it will appear in the formatted message, and the list of suggested replies (with return codes) the recipient may employ. A Message Set is identified by the Message Set Name you specify in the Wireless Messaging Policy Writer. The message text you supply as the Notification Message will be sent to the recipient, and valid Unicenter NSM substitution variables, such as &TEXT, will be resolved. The Wireless Messaging Policy Writer uses the replies you have specified when it generates the configuration and reply files for the Wireless Messaging client. The return codes are used in the configuration file and tell the Wireless Messaging client which code it should return for any of these text messages. If you use the Wireless Messaging Policy Writer to form the message action sequence, these return codes will also be trapped in the sequence of actions following a two-way page command.
Event Management
527
To define a new Message Set, specify a new Message Set Name using the Wireless Messaging Policy Writer, and edit the other data to set the message, priority, and reply information for the message. Once the new data has been supplied, you can store it. To edit an existing Message Set, make the required changes to the Message Set Name using the Wireless Messaging Policy Writer, and then store it to update the record. Defining Multiple Recipients: Group Addressing Some of the template files, unlike Single Notify, send a number of messages during the action sequence. Provision is made by the Wireless Messaging Policy Writer to send messages to three different addresses or recipients in some of your policies. You can gather recipients as a group according to their area of expertise, such as Unicenter NSM administrators, or by organizational structure, such as technician or supervisor, although the way in which these addresses are used is entirely dependent on the specifications of template policy. See the instructions for defining group addressing in the online CA Procedures under the topic, Defining a Policy for Paging Multiple Recipients. Administering the Address Database The Wireless Messaging Policy Writer can be used to administer the server address list. Using the Wireless Messaging Policy Writer, you can perform several administrative tasks affecting the address database:

Add a new address to the database. Edit a registered address. Alter the permissions for an address. Change the format or layout setting for an address. Delete an unwanted address.
You can maintain a number of databases in this way. The database chosen by the message server is the one that was last accessed using the Wireless Messaging Policy Writer. To select the desired database, simply enter its name and data set name (DSN) into the Database Name field of the Wireless Messaging Policy Writer GUI and define the new database by clicking the SET button. If the connection is successful, this becomes the active database. See the instructions for administering a database of authorized addresses in the online CA Procedures under the topic, Administering the Wireless Messaging Address List.
528
Administrator Guide
Troubleshooting the Wireless Messaging Policy Writer

Use the information supplied by this topic to assist you when the Wireless Messaging Policy Writer has not responded as you expected during the processes described. Loading the Wireless Messaging Policy Writer If the Wireless Messaging Policy Writer cannot find its configuration files on startup, it will ask for the location of these files. These are usually located in the \NSM\Wireless directory, but may be placed in a different directory by changing the Root directory option in the Wireless Messaging configuration. Generating Policy A number of points at which a problem can occur when creating a messaging policy exist. If the policy creation process appears to run smoothly after pressing the Create Policy button, but a subsequent test (after an opreload) does not send out any messages, perform the following checks:
Check the list of message records shown in the Event Management GUI. (You can call this from the command line caugui msgrecord, or by using the Start menu entry.) The new message should be listed there. If not, the policy generation has failed prior to the Wireless Messaging Policy Writers attempt to load the script into the Event Management database. See the topic, Script Files, presented later in this discussion. If the record is present, open it and check to see if any actions are associated with it. If both the message and the action (a capagecl command) are defined, check the console log. If not, there has been a problem with the Wireless Messaging Policy Writer itself. If the message has not appeared in the database, check that the script file was created properly. Open the Wireless folder (usually \NSM\Wireless) and then open the Script folder. If this is a new installation, there will be only one file in this folder. This file was created when you clicked the Create Policy button. If a number of script files exist, sort the files by date to find the most recent. To avoid naming conflicts, script and configuration files are named according to the time and date of their creation.
Event Management
529
Formatting Script Files Script files contain the information used to create message records and actions, and are stored in the plain text format used by the cautil f command to load data into the database. The [DUMMYxxx] substitution variables used in the template files will have been replaced. If any of these are still present, particularly in non-text areas of the script (like the condrc=), the script will be rejected by the Event Management database. Another common cause of failure is the length of the line, which must not exceed 255 characters. If you are familiar with this format, you may want to check the file for errors, and rerun the database load command cautil f. If this file is empty or has not been created, check the data entered in the Wireless Messaging Policy Writer and retry the Create Policy button. Note that quotation marks and some other control characters can cause the database load to fail, and these should not be present in any of the text fields in the Wireless Messaging Policy Writer. Note: The text entry containing the capagecl command can often become quite long. If you have specified information on the command line, it may be better to migrate this to the message file where possible. Rerunning the cautil f command on the file, such as cautil f 181912999, will provide some additional information about the point at which the database load fails. No Script File Was Generated An empty script file suggests that the policy template has been damaged. Check the template file for the failed policy. If this has been emptied or corrupted, reinstall the file from the distribution CD. If the script file is entirely absent, the Wireless Messaging Policy Writer has failed internally. If, after checking for valid entries in the Wireless Messaging Policy Writer and retrying the policy creation, no script file is generated, try reloading or even reinstalling the Wireless Messaging Policy Writer. Determining the Cause of an Error See the online CA Messages to determine the cause of a Wireless Messaging error and the proper corrective action to be taken.
530
Administrator Guide
Customize Your Unicenter Console

Event Management provides a number of features that make viewing messages easy. These features let you move through the Event Console Log and narrow the focus of the display so that you can concentrate on the messages that are pertinent to your immediate situation.
Button and Toolbar Display
View Buttons turns the display of the 16 customized buttons at the bottom of the window on or off. View Toolbar turns the display of the toolbar beneath the menu bar on or off.
Column Width
Options Reset to default Column widths resets the column widths in the Messages section to their default values (NT only). You can define each of the sixteen numbered command buttons to execute a command when you click the button.
Command Buttons
When you click an auto command button, the command is processed immediately and the corresponding text is written to the Event Console Log. When you click a manual command button, the command text appears on the command line. You can then edit the text before pressing Enter to issue the command. Once you issue the command, the corresponding text is also written to the Event Console Log.
Command History File
The command line of the Event Console stores the last 20 unique commands issued by the operator in a history file. To view the history file, click the drop-down list box arrow. You can select historical commands for processing by clicking the desired entry. The command you select appears on the command line where you can edit it, or press Enter to submit it for processing. You can save your console log settings so that columns and buttons appear the way you like them. For Windows platforms, Options Config file on the Event Console lets you save your console log settings. For UNIX/Linux platforms, View Save default settings on the Event Console lets you save your console log settings.
Configuration File
Fonts
Options Fonts displays the Font Customization dialog box. Here you can select the fonts you would like to use during the display of your Event Console. You can append comments to messages that come across the Unicenter NSM console. A appears in the Annotation column of the console window next to a message that is annotated.
Message Annotation
Event Management
531
Record Selection
You can filter messages from the Unicenter NSM console log by supplying criteria such as node name, user, source or workstation name, or text of a message to control which messages appear in the Event Console. Only those messages meeting all of the specified criteria appear on the console. For Windows platforms, the Options Settings Filters tab lets you specify criteria for filtering messages from the Event Console Log. For UNIX/Linux platforms, View Include lets you specify criteria for filtering messages from the Event Console Log.
Scroll Feature
The Scroll feature allows you to move backward and forward through the Event Console Log. For Windows platforms, the Options Settings Miscellaneous tab lets you specify your preference for message scrolling. Check or uncheck Autoscroll to specify. For UNIX/Linux platforms, Options Scrolling lets you specify your preference for message scrolling. Autoscroll is the default mode. The autoscroll position displays the most recently logged messages. You can scroll through the console log, but the window automatically resets to the auto position by default 30 seconds after a new message is logged. Manual mode lets you scroll through the console log and keep your selected window position, even if the console log receives new messages.
Store and Forward
Store and forward (SAF) is a facility that stores messages locally when the Event Manager on a remote node is not available. When you enable SAF for a remote node and Event Management sends a message that cannot be delivered to the Event Console on that node, the message is added to a list and forwarded when the node is again available. SAF is implemented by a daemon that periodically wakes up and tries to reconnect to all nodes for which there is an SAF list. The SAF list is maintained on a per node and per day basis in a directory specified by the CA_OPR_SAF_ROOT environment variable. Subdirectories are created for each node that is eligible for SAF and the stored messages are kept in them. When an SAF message is finally sent to its destination, its message text is prefixed with the following: QMSG date time The prefixes to these messages let message actions differentiate between timely messages and those delivered after some delay (were stored).
532
Administrator Guide
View Multiple Remote Console Logs
Once a message is successfully forwarded, it is deleted from the SAF list. See the topic Activating Store and Forward under Windows Post-Installation Tasks in the online CA Procedures for details about implementing SAF.
Timer Intervals
The Options Settings Timers tab lets you specify various timer intervals (NT only). You can change these settings:

Console log rescan interval Automatic scrolling update interval Timer interval during which a blinking message is on or off
See the instructions for customizing your Unicenter NSM console in the online CA Procedures under the following topics:

Activating Store and Forward (SAF) for Console Messages Annotating a Console Message Automating Frequently Used Commands Filtering Messages from the Console Log Setting Timer Intervals for Scrolling
View Multiple Remote Console Logs

By default, the Event Console is set up (on both servers and administrative clients) to view the Event Console Log of only one machine at a time. The Console Daemon Node setting of the Configuration Settings Console Management tab notebook page identifies this machine. You can, however, view multiple remote console logs from one machine using one of the following ways:

Adding the node name to the server map Adding the node name to the CONSOLE.TAB file if you are unable to use the default UNISHARE share name
See the Event Management Console Table (console.tab) File in the online CA Reference for more information about multiple log file support.
Event Management
533
Use SNMP to Monitor Activity

Simple Network Management Protocol (SNMP) is a widely used standard in network event management. SNMP provides a method to identify objects on a network so that information concerning their status and activities are monitored and reported on. The daemons, commands, and utilities provided with Event Management give you an unprecedented level of control for locating, analyzing, troubleshooting, and reporting on activity in your network. This section gives you an overview of the SNMP facilities provided with Unicenter NSM.
SNMP Traps
An SNMP trap is usually an unsolicited message that reports on one of two types of events:
Extraordinary events indicate that something is wrong, or an error has occurred Confirmed events provide information about status, such as a process ending normally or a printer coming online
A variety of SNMP agents are available today, including those provided through Unicenter Agent Technology. They vary greatly in purpose, complexity, and implementation. Despite their differences, all SNMP agents have the ability to do the following:

Respond to SNMP queries Issue an SNMP trap Accept instructions about where to route SNMP traps
Accepting instructions on where to route SNMP traps is typically referred to as accepting a setting for a trap destination. Setting the trap destination is important because traps should be directed to where they can be acted on. Recognizing this, many vendors provide facilities for setting a system-wide default trap destination through an SNMP configuration file. For example, some UNIX/Linux platforms set their trap destination in the file /etc/snmpd.conf. This path and filename may be different for your system.
534
Administrator Guide
Accepting a trap destination setting, however, is only half the job. There also must be something at that trap destination that can receive and process that trap. Enterprise Management provides an agent called the Computer Associates trap daemon, catrapd, which can automatically receive and process any traps directed to the destination (the machine) on which it is executing. Any SNMP trap that catrapd receives is unpacked (decoded) and sent to the other Event Management components for processing. As part of this decoding, character representations, or strings, can be assigned to substitute names for the Enterprise IDs that are part of the SNMP trap. Unicenter NSM provides translation files for that purpose. The translation file provided with Unicenter NSM is as follows:
%CAIGLBL0000%\DB\enterprise.dat on Windows platforms $CAIGLBL0000/snmp/dat/enterprise.dat on UNIX/Linux platforms
The file is self-documenting. You can add additional entries to this file easily by using a text editor of your choice. For more information on catrapd and other SNMP utilities provided with Unicenter NSM, see the online CA Reference.
Automatic Formatting of SNMP Traps

The CA SNMP Trap Daemon (CATRAPD) has an option to format SNMP traps automatically into more easily read text. The formatted text contains the most important information from the trap in a form that is easier to understand and use. Predefined formatting is provided for thousands of traps from many companies. To enable this feature, set the Format traps using provided tables option on the Configuration Settings notebook to YES. Also, make sure that the SNMP Trap Server Activated option is set to YES. After changing any of these options, CATRAPD has to be restarted. CATRAPD uses the TRAP and MIB tables in the CAITRPDB database to determine which traps are to be formatted. A TRAP record identified by a unique Eid (Enterprise ID), Generic, and Specific key contains information needed to format one trap. A MIB record identified by a unique Name key contains information about one MIB. All TRAP and MIB records have Enable columns that control which traps should be translated.
Event Management
535
Note: In this context, a MIB is a collection of related traps generated by one software program or hardware device. One company or organization usually compiles a MIB. See the topic What is a MIB? later in the chapter for a detailed discussion of MIBs. If an incoming trap matches the Eid (Enterprise ID), Generic, and Specific trap fields, and the corresponding TRAP and MIB records are enabled, the trap will be translated to the readable form. The Format, Args, and AlarmName columns of the matching TRAP record and the Variable Bindings (VarBinds) from the incoming trap are used to create the final text. The format of the text is as follows:
%CATD_I_066, AlarmName: unique variable-text
Where AlarmName is from the TRAP record and unique variable-text is created by substituting selected VarBinds into the Format column of the corresponding record. The formatted traps are then sent, as usual, to the Event Management daemon for further processing. Manipulating MIB and TRAP Tables The TRPCNTRL command lets you enable, disable, delete, save, or list all or selected records in the TRAP and MIB tables. To disable a single TRAP record, use the following syntax:
TRPCNTRL disable trap e=Eid g=Gen s=Spc
For example:
TRPCNTRL disable trap e=1.3.6.1.2.1.10.16 g=6 s=1
This command disables the automatic formatting of the Link Layer Operational trap. Note: After modifying TRAP or MIB records, you must notify CATRAPD of the changes by issuing the TRPCNTRL refresh command. To enable the TRAP record shown previously, enter the following command:
TRPCNTRL enable trap e=1.3.6.1.2.1.10.16 g=6 s=1
Enable or disable multiple TRAP records by using wildcards in the keywords.
536
Administrator Guide
For example:
TRPCNTRL disable trap e=1.3.6.1.4.1.199.1.*
This command disables all TRAP records that have an Eid column beginning with 1.3.6.1.4.1.199.1. To list TRAP or MIB records of a specific MIB or group of MIBs, use the following commands:
TRPCNTRL list mib: m=<mib-name/mib-mask> TRPCNTRL list trap m=<mib-name/mib-mask>
For example:
TRPCNTRL list mib: m=RFC1157 TRPCNTRL list trap m=RFC* TRPCNTRL list trap enabled=N
For more information, see the TRPCNTRL command in the online CA Reference.
Sending Traps with catrap

Send traps with the catrap command, which can issue SNMP traps to any destination in your network. The catrap command supports all the operands accepted as Open System standards for an SNMP trap command and can be used interactively, through UNIX/Linux shell scripts or in Windows .bat files, or as part of automated event handling policies defined to Event Management. The operands provided as destination and information data to the catrap command convert automatically into the appropriate Open Systems standard datagram and are sent to the designated trap destination. The catrap command makes it simple for user applications, shell scripts that are part of production jobs, or Event Management policies to issue SNMP traps of their own, simply by executing the command and passing it the appropriate arguments. Further, unlike some other SNMP trap commands, the catrap command does not restrict itself to any particular set of ISO or Enterprise MIBs (Management Information Base) and is totally open for use with any MIB or pseudo MIB with no dependencies on any third-party network management components. For more information on the catrap command, see the online CA Reference.
Event Management
537
What Is a MIB?
MIB is an acronym for Management Information Base. In simplest terms, a MIB is the numeric code that identifies an event and includes other data as necessary to describe the object affected by the event. Because the MIB number is such an important part of identifying an event, it is absolutely essential that no two vendors use the same MIB number to describe different events. To avoid use of the same numeric codes by multiple vendors, standards exist that result in MIBs being organized into one of three broad categories. The first category of MIB is the Industry Standard MIBs. These are sanctioned and published by the International Standards Organization (ISO). The second category of MIB is the Enterprise MIBs. Enterprise MIB numbers are assigned by the Internet Assigned Numbers Authority (IANA) to a given organization and are reserved for that organizations exclusive use from that point forward. The third broad category of MIB is the pseudo-MIBs. They are not sanctioned by or assigned by the IANA but can be just as meaningful and useful as an ISO or Enterprise MIB. Pseudo-MIBs often piggy-back on another organizations Enterprise MIB and take advantage of many of the defaults available on a given platform. The following sample pseudo-MIB describes an event tree. Each element on the tree represents information that could be sent when specified as a variable on the catrap command.
538
Administrator Guide
Sending a trap of 999.1.1.2 is equivalent to sending the message The Enterprise Database server that handles the General Ledger database has been started. A trap of 999.1.1.3 indicates that the General Ledger database has encountered a journal full condition. And a trap of 999.2.1.5 indicates that the General Ledger financial application has resumed processing after a temporary outage (warm start). Taking the example a step further, assume that Unicenter NSM is executing on several nodes in this network, but you have decided that all SNMP trap traffic should be directed to a single monitoring machine running on the server Earth. The server Earth receives the SNMP traps, which are recorded and acted on by the Event Management component. Another machine in the network, the server named Mars, is used for the production financial applications. For some unknown reason, an error occurs and the General Ledger production application running on Mars terminates with an error.
Event Management
539
Testing the return code issued by the General Ledger production executable, the shell script realizes that the exit code indicates a problem and issues an SNMP trap to alert the server Earth that something has gone wrong by simply executing the following command:
catrap earth 6 0 22 999.2.1.7 integer 128
Command/Operand Description catrap earth and 6 0 22 Sends the identified trap information to the server Earth Instructs catrap to take the default Enterprise code and the default agent address respectively for this node Indicates that this command is sending a specific trap Identifies the specific trap number for this example An arbitrary number we have selected as a timestamp indicator
The next operands identify the variable binding (varbind) information for the trap. Command/Operand Description 999.2.1.7 The ID of the object about which information is being sent. If you refer to the event tree illustrated earlier, you can see that this refers to an error in the Enterprise financial application, General Ledger. Provides additional information about the event. In this case, it could mean send an integer value of 128 to node earth, assuming 128 is an error code that has meaning to the General Ledger application; or perhaps it is the exit code that the shell script detected as indicating an error.
integer 128
When received at the trap target server Earth, the Event Management component (catrapd) then decodes the event and performs automatic actions in response. If you refer to the event tree, you can see what other types of events could be sent, such as 999.1.1.1, indicating that the Enterprise data servers database for the General Ledger system has shut down. When coupled with the other capabilities of Unicenter NSM, the possibilities expand.
540
Administrator Guide
For example, you can use the Event Management facilities to intercept the error messages from any application and automatically execute customized catrap commands in response. The Workload Management function can detect key events and send traps in response to files becoming available for processing or applications completing their processing. Security violation attempts detected by Security Management can result in other SNMP traps being sent, and so on. When on the receiving side of an SNMP trap, you can use Event Management message handling policies to do the following:

Open problem tickets automatically Send warning messages in human readable form to other consoles or terminals Start recovery jobs Post dependencies as having been met so that other production jobs can proceed Issue additional SNMP traps to one or more other nodes
As this simple example demonstrates, the possibilities for using SNMP trap information are virtually endless. For more information on the catrap command, including an example of how to issue an SNMP trap using the catrap command, see the online CA Reference.
Event Management
541
Maintenance Considerations
Cleaning Up Log Files
By default, Event Management console log files are kept online indefinitely. These files can, of course, be removed manually; however, we recommend that you establish an automatic cleanup of your console log files. See the instructions for establishing automatic cleanup of console log files in the online CA Procedures under the topic, Cleaning Up Log Files.
Using a Local Copy of the Event Management Policy

You can configure Event Management to use a static copy of message record and action policy tables from the Event Management database. This greatly enhances the resilience of Event Management since servers that do not have access to the database when they are started (for whatever reason) can run off of local copies of the policy that they last executed. See the instructions for putting a local copy of the Event Management database into use in the online CA Procedures under the topic, Using a Local Copy of the Database.
Exits for User-Defined Functions

Event Management provides certain well-defined exit points for adding userdefined functions that customize and enhance your implementation of Unicenter NSM. For complete information about using these exits, see the CA SDK Developer Guide.
Security Enhancements
Before a command is executed from the console GUI or through a message action via oprcmd, careply, or delkeep, Unicenter NSM performs an authorization check to verify that the userid has authority to perform the action. If Unicenter NSM security is not active, the userid issuing the command must be listed in the Users authorized to issue commands environment variable. This list is a Unicenter NSM setting you can edit in the Event Management Preferences page of the Configuration Settings notebook.
542
Administrator Guide
If Unicenter NSM security is active, the userid must have explicit permission from Unicenter NSM security to execute that command. To do this, a rule must be created for the asset type CA-CONSOLE-COMMAND. See the instructions for determining eligibility for command execution in the online CA Procedures under the topic, Defining the Environment for Command Execution.
Submit Commands on Behalf of Another User

Event Management allows you to submit commands on behalf of another user. In order to enable this policy, you must first supply new privileges for the Unicenter NSM user ID and for those users logged on by Unicenter NSM. See the instructions for submitting command on behalf of another user in the online CA Procedures under the topic, Submitting a Process as Another User.
Event Management
543
Chapter
Workload Management
Workload Management automates submission and tracking of batch processes. It facilitates the definition and enforcement of complex interrelationships among units of work (including predecessor controls, manual tasks, and cause-and-effect scheduling policies). This chapter explains how to implement your workload policy through the Workload Management function. Todays production control administrators need flexibility to control their view of the job flow. Sometimes they need to see the big picture; at other times they must focus on a specific job or group of jobs. Jobflow provides the tools to meet those needs. Jobflow is an enhancement to the Workload Management function that expands your view of the workload to include multiple job relationships. In this chapter you will learn the following:
How Workload Management schedules work and submits jobs to the operating system How to implement your workload policy by defining where, when, and how work is to be performed, as well as the actual work involved How Jobflow works to provide forecasts, status views, and operation modes How to navigate through the tracking displays How to customize the environment
Workload Management
61
How Workload Management Works

Workload Subsystems
Workload Management is made up of two major subsystemsthe Workload job server and the Workload agent. Typically, sites have one Workload job server and multiple Workload agents. The Workload agents run on all the machines where the Workload job server component will submit and track work. Workload Job Server The Workload job server is responsible for scheduling work, sending job submission requests to the Workload agent, processing user commands, and job tracking. It consists of two functional areas:
The Monitor, which identifies jobs that should run and determines when and where they should be submitted The job tracker, which collects job event data from all Workload agents where jobs have been submitted and uses that data to update job status and resource availability information
Workload Agent The Workload agent runs jobs on behalf of the Workload job server and sends workload-related information to the central job tracker. Workload agent processes should be running on every machine where Workload Management submits and tracks work (including the server where the Workload job server resides). The Workload agent consists of two functional areas:
The remote submission agent executes the submit file specified by the Workload Monitor. The remote tracking agent collects job event data and sends it to the Workload job tracker.
62
Administrator Guide
The following section describes how the Workload Management processes act together to automatically schedule, submit, and track a unit of work. The Monitor determines when it is time to submit a job and sends a submission request to the appropriate agent. The Workload server and Workload agent together accomplish the tasks of scheduling, submitting, and tracking your jobs as follows:
The remote submission agent receives the submission request which includes data items like submit file name, user ID information, and parameters required by the submit file. The remote submission agent performs the submission. When the job starts, the submission agent notifies the Workload Management checkpoint file. Shortly thereafter, the tracking agent reads and forwards the event data to the job tracker. The job tracker marks the job as started. The same flow of events occurs when the job terminates.
Workload Management
63
Workload Profiles
You define your Workload Management policy through profiles that specify where, when, what, and how work is to be performed. It is through these profiles (described following) that Unicenter NSM manages your workload. Icon Description The station profile identifies the location where work is to be performed. A station can be a CPU where jobs are processed or a physical location where manual tasks, such as distributing reports, are performed. A calendar profile defines the days on which jobs can run.
The station group profile defines a group of stations where work can be performed so that you can schedule work to multiple stations or the best available station in a group.
A job profile specifies what work is to be performed. There are various types of jobs; for example, a CPU job specifies a command or program that runs as a background process. A jobset profile generally shows how the work is to be performed. A jobset groups logically related jobs into a set and defines scheduling criteria for the group as a whole. It provides default values for all jobs grouped in the jobset. A resource profile specifies the hardware, software, or supporting resources that must be available before a job can be submitted.
A predecessor profile controls the sequence or order of work being processed. A jobset or job predecessor specifies a list of jobs or jobsets that must complete before a job can be run. A predecessor profile is accessed from a notebook page on the Job Detail and Jobset Detail windows.
64
Administrator Guide
In addition to predecessors, Workload Management lets you specify the following:
Early start time indicates the earliest time a jobset can be marked as started or a job can be submitted for processing. (Think of this as the dont start before time.) Must start time indicates the latest time that work can be started without being considered late. The work can start anytime prior to the indicated time, but not before the early start time. Must complete time indicates the time by which work must be completed, otherwise it is considered late. (Think of this as the must be finished by time.) Maximum time indicates the maximum length of time that work can run. Advanced calendar override criteria let you set conditions for holiday and non-workday processing.
Types of Job Scheduling

The use of calendars to schedule jobs is called predictive scheduling. Jobs are scheduled and automatically placed in the tracking file on the days you specify using calendars. The use of triggers and message actions to schedule jobs is called event-based scheduling. Event-based scheduling is event driven: a message action starts when a trigger is tripped. Both approaches have inherent strengths and weaknesses, and most enterprises use a combination of the two, using predictive scheduling for the bulk of their workload and event-based scheduling for exception event processing.
Workload Management
65
Specify Where to Perform Work
Specify Where to Perform Work

The first step in implementing a Workload Management policy is to identify the locations (the where) and operations (the what) used in running your current work. You can identify where work gets done through the definition of station profiles and station group profiles, which allow you to assign logical names to the locations where tasks are performed. Think of each station as the place where one or more steps in a procedure are performed. A typical production job involves more than just executing a program. Often, job setup and post-processing requirements must also be performed to ensure the correct processing of jobs. Recognizing this, Unicenter NSM provides three categories of Workload Management stations:
PRECPU
The location where a manual task, such as loading a printer with special forms, must be performed prior to running jobs on the CPU A machine where a job actually runs The location where a manual task, such as verifying or distributing printed reports, must be performed after the CPU completes its work
CPU POSTCPU
PRECPU and POSTCPU stations provide important aspects to the automation of workload processing. By providing the same level of attention to critical non-CPU tasks that you do to CPU-based processes, Unicenter NSM helps you ensure that jobs are set up correctly and have appropriate manual checks and balances. Getting it done fast is of no value unless its done right! See the instructions for specifying where to perform work in the online CA Procedures under the following topics:

Defining Station Profiles Defining Station Group Profiles
66
Administrator Guide
Identify Resource Requirements for Workload Balancing
Identify Resource Requirements for Workload Balancing

If you are not setting workload balancing capabilities for Unicenter NSM at this time, you can proceed to the next section in this chapter. Identifying resource requirements is only necessary if you will be using advanced workload balancing. Unicenter NSM maintains a list of available resources and the special resource requirements of any given job to automatically balance an active workload. This feature is typically referred to as workload balancing. Workload balancing enables Unicenter NSM to avoid bottlenecks and resource contention problems on a single machine or across a network of machines. Tape drives, for example, are serial-use devices. It would be inappropriate to simultaneously submit two jobs, each requiring a tape drive for processing, on a machine that has only one tape drive. Between these two unrelated jobs, a special resource requirement would exist that requires coordination (in this case, serial processing). To derive maximum benefit from workload balancing, you must identify those resources that have special usage or access coordination requirements and define them to Workload Management as resource profiles. Changes made to resource profiles affect all jobsets and jobs that reference the resources, including work currently scheduled for processing (entries in the tracking file.) Work currently scheduled for processing can be monitored or updated using Jobset Status and Job Status. See the instructions for identifying resource requirements in the online CA Procedures under the topic, Defining Resource Profiles.
Workload Management
67
Schedule Work by Dates

The next step in implementing a Workload Management policy is to define a default calendar and any other calendars necessary for scheduling jobs. The default calendar, typically named BASE (base on UNIX/Linux platforms), is associated with any jobset for which no calendar has been explicitly specified. Job profiles, however, are handled differently. If you do not specify a calendar name in the job profile, the value Def appears in the Calendar field to indicate that the jobs calendar setting, by default, inherits the jobsets calendar. Note: A job is eligible for processing only when the jobset to which it belongs is also eligible for processing. Jobs, however, can be excluded from running on certain days that the jobset is selected by using a different calendar for the job that has those days turned off when the job should not run. You can assign a name other than base to the default calendar on Windows platforms by opening the Configuration Settings window, turning to the Options Workload Management notebook page and specifying a new value for Default Calendar. On UNIX/Linux platforms, this is done by setting the Workload Management configuration option environment variable CAISCHD0009. See the section Important Configuration Environment Variables later in this chapter for information about setting this variable. By associating a jobset or job with a calendar, you define the days on which a jobset or job is eligible to run. Workload Management does not use any time settings defined in a calendar profile. The times that jobs run are determined by the settings in the jobset and job profiles you define.
Tip: We recommend that you establish a naming convention for your Workload calendars that clearly distinguishes them from the calendars used by other Unicenter NSM functions.
Expanded Calendar Processing
As an alternative to using a calendar to let jobsets or jobs run on specific days, you can use extended calendar processing to define conditions under which jobsets, jobs, or triggers run. Expanded calendar processing allows you to set conditions for holiday and nonworkday processing. By setting the holiday action and non-workday action switches, you can tell a job what to do on these days; you would not have to maintain special calendars to handle the situation. Using expanded calendar processing also can reduce the number of calendars you have to maintain. For example, when you want one job to run on Mondays and another job to run on Tuesdays, you have the choice of defining two calendars or setting extended calendar processing criteria for a single holidays calendar.
68
Administrator Guide
Use the Profile notebook page on the Jobset, Job, or Trigger Detail windows to extend your calendar processing criteria. The fields on the Profile notebook page are as follows:
Holiday calendarThe name of the holiday calendar to use when testing any of the criteria keywords. An entry in this field overrides any other calendar processing that may be set on the Jobset or Job Main Info notebook page. Holiday actionThe action to take if the selected day falls on a holiday. Non-workdayThe action to take if the selected day falls on a non-workday (Saturday or Sunday). AdjustmentThe adjustment in days (positive or negative) to make when the other criteria do not quite meet expectations. ConditionsThe selection criteria keywords to use when processing this calendar. This field allows Boolean logic to create compound conditions.
See the online Help topic Job/Jobset/Trigger Profile - Detail for a complete description of these fields and conditions keywords. See the instructions for scheduling work by dates in the online CA Procedures under the topic, Defining Calendars.
Workload Management
69
Form Groups of Related Tasks (Jobsets)

Having defined at least one calendar and a station profile, you can next define a jobset. A jobset is a collection of one or more logically related jobs that are typically part of the same production run. The jobset profile establishes the relationships, criteria, and default attributes of the jobs that you later define as members of this jobset. Note: Every job must belong to a jobset. Jobset Resources Use of jobset resources is optional. If you are not interested in using workload balancing with jobsets, you can skip ahead to the next jobset section. Jobset resource profiles specify the minimum resource requirements for each job in the jobset. Because jobsets do not allocate or require resources, a resource identified for the jobset does not have to be available for the jobset to be declared eligible for processing and selection to the tracking file. (Jobsets never have a status level of WRSRCWaiting for Resourcesand are never included in workload balancing.) Resource requirements specified at the jobset level define the minimum resource requirements that must be available before any individual jobs of the jobset will be considered eligible for submission.
Resource Amount, Weight, and Usage
The jobset resource profile references a previously defined Unicenter NSM resource profile that describes resources required by the jobs in the jobset. Amount describes how much of this resource is needed. Weight indicates the relative importance of a resource. Usage indicates how this resource will be used by the jobs in the jobset and can be specified as one of the following:

PRIVATEeach job needs exclusive access to a resource. SHAREDmultiple jobs share a resource. COREQjobs can access the resource only when another job has PRIVATE access. Note: COREQ control typically is used to direct jobs that have a particular service to the CPU where the system is active. Consider, for example, a job that has a CPU dependency of Any available CPU and requires a co-requisite resource named db. This job can only run on a CPU where another job, which has PRIVATE use of the resource db, is currently active.
610
Administrator Guide
An example of resource allocation follows. Assume that an existing resource profile named tapedevs specifies that four tape drives exist on station europa. The following Jobset - Detail Resources window indicates that each job in the jobset requires one of the four tape drives defined as available resources by the previously defined resource profile named tapedevs, and each job needs exclusive access to the tape drives.
Note: Workload does not verify the physical existence or actual availability of tape drives or any other device. These resource definitions are logical rather than physical. Jobset Predecessors Use of jobset predecessors is optional. If you are not interested in making use of predecessor relationships at the jobset level, you may skip ahead to the next jobset section. Jobset predecessors are used to specify the list of jobs, jobsets, or trigger profiles that must complete successfully before this jobset can be started. A predecessor requirement will be marked satisfied if any of the following conditions are true about the predecessor:

The predecessor completed successfully (COMPL). The predecessor aborted and shows a status code of ABORT but has an Abend action of CONTINUE in its profile. The predecessor is missing from (that is, does not exist in) the current workload tracking file.
Workload Management
611
Nonexistent Predecessor Evaluation
If a jobset has a predecessor requirement that specifies a job, jobset, or trigger that is not in the tracking file (not currently scheduled to run) at the time the predecessor requirement is evaluated, that predecessor requirement is automatically satisfied through an implicit posting. In effect, it is ignored. The reason Workload Management performs this implicit posting is simple. To have a dependency on a job that does not exist is illogical, because any job with such a predecessor dependency would never run. As such, if Workload Management detects such a conditiona predecessor requirement referencing a job not scheduled to run (that is, does not exist in the current workload)it ignores the illogical predecessor requirement and continues to evaluate eligibility.
Canceled Predecessors
The only predecessor requirements honored are those that represent predecessor jobs that are scheduled to run in the current workload (also referred to as being in the tracking file). Because of this rule, the cancellation of any predecessor job (which removes that job from the tracking file) will result in that predecessor requirement being ignored. In effect then, the cancellation of a predecessor job effectively satisfies the predecessor requirement, allowing any successor jobs to run. While many enterprises find this behavior intuitive and useful, many others do not. To support each enterprises preference, the Workload Management components provide an option that allows you to change the default effect of the cancel command so that successors (those jobs that define the canceled job as a predecessor) are not automatically posted. See Important Configuration Environment Variables later in this chapter for information on specifying this option using Post on Cancel? and CAISCHD0014. See the instructions for forming groups of related tasks in the online CA Procedures under the topic, Defining Jobsets.
612
Administrator Guide
Identify Work to Perform

A job is a unit of work performed. A job can be as follows:

An executable file used to process an application A manual task to be performed before or after processing an application
Before covering how to define jobs, we encourage you to review the following sections that describe how Workload Management evaluates the policies you define to determine when jobs are eligible to run. Jobset Membership Every job must belong to a jobset, and only after a jobset is marked as started will Workload Management evaluate the jobs in the jobset. (DYNAMIC jobs are a special exception to this rule and are discussed separately later in this chapter.) Early Start Time Early start time indicates the earliest time a job may start. For CPU jobs, this is the earliest time they would be submitted to the operating system. Once the jobs jobset has started, Workload checks the jobs early start time. If you specify an early start time for the job, the job remains in WSTART status (waiting for the jobs early start time) until that time arrives. When the time arrives, or if the job does not have an early start time specified, the job advances from WSTART to WPRED status (waiting for predecessor requirements to be satisfied). Job Predecessors Jobs, jobsets, and triggers can all be defined as predecessors for a job. All predecessors defined for the job must be satisfied before a job can become a candidate for submission. Important! The jobset starts only after all of the jobsets predecessor requirements have been met, and only after the jobset starts will Workload Management evaluate the predecessor requirements for the individual jobs that are members of that jobset. On UNIX/Linux platforms, you can also specify advanced system conditions that must be met before a job can run on a specific node. For example, if a job must not run when a particular user is logged on, you can define a system condition criterion that specifies this. Workload Management then holds the job until that user is no longer on the system and then releases it.
Workload Management
613
SYSCON objects for administering system condition requirements are available using cautil command syntax and are described in the online CA Reference under the topics JOBSYSCON, JOBSETSYSCON, and TJOBSYSCON. External Predecessors The EXTERNAL job type setting in a job profile makes it possible for you to define a job to Workload Management which will be submitted by an external Workload manager. The job is actually submitted by another job management system such as Unicenter CA-7 Job Management (Unicenter CA-7), Unicenter CA-Scheduler Job Management (Unicenter CA-Scheduler), Unicenter CA-Jobtrac Job Management (Unicenter CA-Jobtrac), and so forth. Unicenter NSM treats this job as a non-CPU job with a class of EXTERNAL (similar to PRECPU and POSTCPU). The jobs presence on the tracking file causes JOBINIT and JOBTERM triggers to be generated internally and the job is automatically tracked by the client where the job actually runs. The Workload Management server does not submit the job, only tracks it. Since this is a JOB base entry, predecessor definitions and calendar selection can reference it. You specify the job type at the Main - Info notebook page of the Job - Detail window. Job Resources Job resource requirements do not override jobset resource requirements. Rather, resource requirements defined at the job level are added to any resource requirements that may already be defined at the jobset level. Jobset and job resource requirements are therefore cumulative. Job Submission Workload Management submits CPU jobs based on user-defined processing requirements. You define what to submit and any special considerations through a submission profile that assigns these submission characteristics:

User ID (the user for whom the job is submitted) Name of the file or program to submit Optional parameter values to pass to the submitted file or program Password of the user for whom the job is submitted Domain of the user for whom the job is submitted
614
Administrator Guide
Password Validation for Job Submission
Workload job submission requires a password and a valid user ID in order for a job to be executed. During the installation process, if setup detects that Workload Management was previously installed at that node, you will see a message box informing you of the new password feature and the default setting that disables password validation to maintain upward compatibility. You are given the opportunity to override the default and enable password validation at that time.
If you accept the default response n to the prompt for password checking, setup creates the ExtNodeL.sch configuration file with a single entry of n=*,*,D to disable password validation for all users on all nodes. If you instead respond y to the prompt for password checking, setup creates the ExtNodeL.sch configuration file with a single entry of -n=*,*,E to enable password validation for all users on all nodes.
When setup detects that you are installing Workload Management for the first time on the node, you will see a message box informing you of the new password feature and the default setting that enables password validation. You are given the opportunity to override the default and disable password validation at that time.
If you accept the default response n to the prompt for password checking, setup creates the ExtNodeL.sch configuration file for you with a single entry of -n=*,*,E to enable password validation for all users on all nodes. If you instead respond y to the prompt for password checking, setup creates the ExtNodeL.sch configuration file with a single entry of -n=*,*,D to disable password validation for all users on all nodes.
You can change this rule at any time after installation by executing the cawrksec utility located in the $CAIGLBL0000\sche\bin directory. The utility only allows the uid 0 user to maintain the file and preserve the file permissions. The file can also be maintained using a UNIX/Linux text editor. For more information about using the cawrksec utility, see the online CA Reference. The ExtNodeL.sch configuration file is located in the $CAIGLBL0000\sche\config directory. You can use this file to maintain policies that specify how password validation is to be performed based on the submitting node and user ID. The file must be owned by root and only a uid of 0 may have write access to it. An individual entry in the file has the following format: -n=nodename,user-id,flag where: nodename Specifies the node from which the job is initiated; it can contain a trailing generic mask character.
Workload Management
615
user-id Specifies a user ID to whom the rule applies; it can contain a trailing generic mask character. flag Specifies D for disable (perform no password authorizations), E for enable (unless the proper password is supplied, the job will not run), or W for warn (check the password; if invalid, run the job but issue a warning message). Some examples follow:
-n=*,*,E
This is the default rule in effect if, during installation, you elected to enable password checking. The rule states that for all nodes and all users password validation is to occur. This is the default rule in effect if, during installation, you elected to disable password checking. The rule states that for all nodes and all users password validation is bypassed. This combination of rules only enforces a password validation on user root and allows all other users to bypass password validation. This combination of rules allows all users to bypass password validation unless the request comes from the node mars. In that case, password validation is enforced for all users. The last entry sets a warning type password validation for user root if it comes from a node other than mars.
-n=*,*,D
-n=*,*,D -n=*,root,E
-n=*,*,D -n=mars,*,E -n=*,root,W
Workload scans the entire configuration file for a best match and uses that rule. It uses the node field as a high level qualifier when searching for a best match. For example:
-n=mars,*,E -n=*,root,W
If these are the only two entries in the file, any request coming from the node mars uses the enforce rule. The user root only uses the warning rule if the request comes from a node other than mars.
616
Administrator Guide
Cyclic Job Submission Workload Management supports cyclic job submission, which allows a job to be submitted multiple times during a particular time period. For example, if you have a job that needs to run every hour between 8:00 a.m. and midnight, you can define the job as cyclic and specify the frequency (how often it should run) and the number of iterations (how many times it should run). Cyclic job submission is much easier than defining 17 jobs, one for every hour between 8:00 a.m. and midnight. It also simplifies maintenance because you only have to change a value once to alter the cycles, frequency, or number of iterations. Note: You should define cyclic jobs as ineligible for backlogging to ensure that the job is purged from the tracking file at the next new-day autoscan.
Cyclic Job Special Considerations
Processing cyclic jobs has special considerations of which you should be aware if you plan to take advantage of this powerful facility. The following discussion provides detailed explanations of these special considerations. When a cyclic job is demanded into the tracking file after its early start time has passed, Workload Management adjusts for this situation by doing the following:
Adding one instance of the job using the normal early start time job, so that the job starts immediately Submitting x instances of the job to start at the first eligible time interval after the current time
For example, if the job has an early start time of 1:00 p.m. and a frequency of 60 minutes, and the job is demanded at 3:15 p.m., Workload Management generates entry one to start at 1:00 p.m. When the job enters the current workload (by entering the tracking file), Workload Management recognizes that it is late (it should have started at 1:00 p.m.) and starts it immediately. The next submitted instance of this job has a start time of 4:00 p.m. with subsequent entries to start at 5:00 p.m., 6:00 p.m., and so forth. When a cyclic job is brought in late (demanded), Workload Management skips the jobs that are too late to run and only runs the number of iterations left, based on the calculation of when the jobs should have run. Consider, for example, a cyclic job that has a frequency of 30, a cycle count of 16, and an early start time that defaults to the new-day autoscan time of 1:00 a.m. The job is typically brought in at 1:00 a.m. and runs 16 times: at 1:00 a.m., 1:30 a.m., 2:00 a.m., and so forth until the last (sixteenth) run at 8:30 a.m. However, if the job is demanded in at 4:05 a.m., the occurrences up to that time are skipped and the job is run at 4:05 a.m., 4:30 a.m., 5:00 a.m., 5:30 a.m., and so forth. At 8:30 a.m., the job runs for the last time, for a total of 10 runs. The occurrences that would have run (at 1:00 a.m., 1:30 a.m., 2:00 a.m., 2:30 a.m., 3:00 a.m., 3:30 a.m.), are skipped. Workload Management does not attempt to catch up if it means running the jobs after the last calculated start time of 8:30 a.m.
Workload Management
617
If you elect to run with the autoscan process disabled, cyclic jobs are submitted only when you execute a manual autoscan. The jobs are not automatically submitted each day. See the section Autoscan later in this chapter for an explanation of the autoscan process. You cannot define a cyclic job as a predecessor to itself. In other words, when a cyclic job is submitted, the job begins execution when its early start time is reached. It does not wait for any preceding instances of itself to complete. You can define a cyclic job as a predecessor to another job or jobset. All occurrences of the cyclic job are treated as predecessors and must complete before the successor job or jobset is eligible to run. The predecessor criteria for cyclic jobs include a qualifier option that allows cyclic jobs to run in one of two ways. For example, assume you have two cyclic jobs, CycJobA and CycJobB, where both have an iteration number of 3, frequency is set to 60, and CycJobA is the predecessor of CycJobB. When both jobs are demanded into the tracking file, the file appears as follows:
CycJobA CycJobA CycJobA CycJobB CycJobB CycJobB QUAL=xx01 QUAL=xx02 QUAL=xx03 QUAL=xx01 QUAL=xx02 QUAL=xx03
If you set the qualifier Use Qualifier Predecessor Criteria for cyclic job? to N, CycJobB runs after all CycJobA iterations have run. If you set the qualifier to Y, CycJobB QUAL=xx01 runs after CycJobA QUAL=xx01 completes, CycJobB QUAL=xx02 runs after CycJobA QUAL=xx02 completes, and so forth. Note: If you plan to use cyclic job submission for Windows platforms, review the environment settings for Workload Management in the Configuration Settings window for Max active jobs, Max resources, Max predecessors, and Use Qualifier Predecessor Criteria for cyclic job? (Options tab) and set the appropriate values to accommodate the additional jobs in the daily workload. Note: If you plan to use cyclic job submission for UNIX/Linux platforms, review the values set for the environment variables CAISCHD0025, CAISCHD0026, CAISCHD0027, and CAISCHD0040 and set appropriate values to accommodate the additional jobs in the daily workload. See the instructions for identifying work to perform in the online CA Procedures under the topic, Defining Jobs.
618
Administrator Guide
Schedule Work by Special Events

Occasionally situations or events may arise that require a quick, consistent, and correct response to ensure that operations continue to run smoothly. Workload Management provides facilities to identify these events and specify responses to be taken automatically. A trigger profile specifies a special event for which Workload Management should be prepared. When an event occurs that matches a trigger profile, Workload automatically trips that trigger and sends a message to the Event Console where a message action is invoked. For example, assume you download an updated database to your system on a weekly basis and you want a number of reports to run as soon as the file transfer is complete. To automate the sequence, you can define a File Close (DCLOSEU) trigger profile and a message action profile. When the file closes, the trigger is detected, the appropriate message is issued, and the message action profile DEMANDs in a jobset containing all of the necessary report jobs. Workload lets you define triggers for the following events:

Job initiation Job termination The caevent command File close (when a file, opened for write or newly created, is closed, a File close event is created) File unlink IPL event
Once a trigger trips, its associated message action profile executes. See the section Trap Important Event Messages and Assign Actions in the Event Management chapter for a description of message action processing. Triggers can be defined to be associated with a calendar so that although a triggering event may occur at any time, the trigger is only tripped when its associated calendar determines it is appropriate. When a trigger profile has no associated calendar, it is always in effect; it is scheduled every day and never marked complete.
caevent
For most situations you can choose a trigger type of File close, Job termination, or Job initiation. However, there may be times when the triggering event you want to define is not a system-initiated event. Perhaps a logical event may be more suitable. The trigger type of CA Event lets you create these user-initiated logical events.
Workload Management
619
Using the executable caevent (provided with Unicenter NSM), you can generate a logical event by executing the caevent command and supplying two command line arguments: the first is the logical event name and the second optional parameter is an event status code. By placing the caevent executable in files or using it interactively, you can alert Workload Management to events as they take place. In addition, since the event name and status code are user-specified, they can describe any trigger event. For example, the following caevent command sends an event of type caevent, with an event name of bkupnow (a previously defined trigger profile) and a status code of 10 to Workload Management:
caevent bkupnow 10
If a defined trigger profile matches these criteria, the trigger trips and the associated message action profile is processed. The message action profile may demand a jobset into the workload automatically or execute a cautil backup command. Message action profiles are flexible enough to meet your needs. See the online CA Reference for additional information on the caevent command.
Triggers as Predecessors
Often, events not related to a job need to be tied directly to a job or jobset, such as creation or deletion of a file, completion of a job that ran on another server, or occurrence of an IPL event. These events can be detected by Workload by its trigger mechanism and can be used to satisfy a job dependency. For instance, you may not want a payroll job to start until the data file has transferred from another system. You can define a trigger to watch for the creation of the data file and define the payroll job with a predecessor to wait on the trigger. In another scenario, Workload server SERVA runs a job on system SYSA. Workload server SERVB cannot run a job until the job submitted by SERVA completes. Define a trigger on SERVB to watch for the completion (JOBTERMU) of the job submitted by SERVA and define this trigger as a predecessor to the job on SERVB. Note: See the Control Statements for JOBSETPRED and JOBPRED objects in the online CA Reference for additional information about keywords for using trigger profiles as predecessors. See the instructions for scheduling by triggers in the online CA Procedures under the topic, Defining Trigger Profiles.
620
Administrator Guide
Run a Job on Demand
Run a Job on Demand

Many installations jobs are not performed on a predictable schedule or in response to any particular event, but rather are run on demand. You can use the Jobset Demand choice on the Jobset list container window to instruct Workload Management to demand a jobset that is defined in the Workload database into the current workload. Demanding a jobset lets you bring jobsets and jobs into the current days workload (into the tracking file) that would not be automatically selected for processing. When you demand a jobset into the tracking file, the individual jobs in the jobset are also brought into the tracking file if both of the following conditions are true:

The job profile specifies Autoselect=YES. The calendar profile for the job indicates that today is a valid execution day.
Both of these conditions must be satisfied to bring jobs into the tracking file when you demand the jobset of which they are members. Otherwise, you must specifically demand the job into the tracking file using the Job Demand choice on the Jobs list container window.
Demand a DYNAMIC Job
You can demand a job into the current workload that is not defined in the Workload database by designating the job as DYNAMIC. This is an ad hoc job that, while not in the Workload database, can have Unicenter NSM capabilities:

Its messages go to the Event Console History information is written to the Workload history database The running process appears on the Jobflow status GUI The job can be tracked and canceled by Workload You can specify basic parameters such as start time and effective date
The next autoscan removes all references to the job. See the instructions for running a job on demand in the online CA Procedures under the topic, Demanding a Job into the Workload.
Workload Management
621
Test Your Workload Policy Definitions

After you have defined your workload policy to Workload Management, we recommend that you run the Simulation Report to see what happens before committing the policy to your daily production cycle. The Simulation Report invokes a simulated autoscan process, producing a set of detailed reports that identify:
Jobs that would be selected, executed late, or carried over to the next day (backlogged) Date and time that each job would be processed Location where each job would be processed Resources that would be required Amount of utilization for each resource
The information obtained from the Simulation Report will help you to evaluate your implementation and more readily identify any adjustments that may be required to the workload policies you have defined. Run the following command from a command line prompt to create a simulation report:
wmmodel
The wmmodel executable lets you play what if scenarios, override job dependencies, and change the duration of a job execution. To run a Workload Management report on UNIX/Linux platforms, you must be logged in as ca7mngr or as root. Issue a command at the command line similar to the following:
schdsimu BOTH
This command example also runs the Simulation report. See the online CA Reference for additional information on Workload Management reports. Report output goes to stdout, which can be directed to any printer or file, as you prefer, using standard redirection operators. See the following section, Workload Management Reports, for information about the location of the executables.
622
Administrator Guide
Workload Management Reports The Workload Management shell scripts and programs listed following generate the standard Workload Management reports. Windows schdchk.cmd schdfore.cmd schdhist.cmd UNIX/Linux schdcheck schdfore schdhist schdpxr Creates this report Workload Management Check Report Workload Management Forecast Report Workload Management History Report Workload Management Predecessor/ Successor CrossReference Report Workload Management Simulation Report Workload Management Simulation Report
schdsimu.cmd wmmodel.exe
schdsimu wmmodel.exe
On Windows platforms, the report generating programs are located in the %CAIGLBL0000%\bin directory. On UNIX/Linux platforms, the report generating shell scripts are located in the $CAIGLBL0000/sche/bin directory.
Workload Management
623
Autoscan
Autoscan
The selection, submission, tracking, and cleanup of jobs begin with the autoscan procedure. Workload Management treats a workday as a 24-hour time period that begins at new-day time. The default setting for the new-day autoscan is midnight for Windows platforms and 01:00 a.m. for UNIX/Linux platforms. At this time, all the jobsets and jobs that qualify are added to the new-days workload (added to the tracking file). A periodic autoscan also occurs at specific intervals to determine if any changes or additions should be made to the current days workload. New-day autoscan performs the following tasks:
Cleans up the tracking file by purging finished work from the previous days workload. Any unfinished work that is backlog eligible is carried over to the new days workload. Scans the Workload Management database to select the new days work. Autoscan first selects all jobsets that qualify for processing the current day (based on their calendar, expiration, and effective date criteria). From these jobsets, autoscan similarly selects the individual jobs that qualify. Once these jobsets and their jobs are in the current days workload (in the tracking file), they are ready for processing, review, and any last minute changes.
Qualifying for Selection During Autoscan

To determine if a jobset (and job) qualifies for automatic inclusion in todays workload, autoscan examines several operand values in the following sequence: 1. Auto selectionIs the jobset or job eligible for automatic selection? Typically jobs and jobsets that run on a regular schedule use calendars and have the auto selection operand set to YES. If the auto selection operand is set to NO, the jobset or job is ignored and no further evaluation is performed. Effective date and expiration dateHas the effective date in the jobset or job profile been reached? Is the expiration date in the jobset or job profile still in the future? Skip countHas the workload administrator indicated that this jobset or job should be skipped? The workload administrator would do this by specifying a positive integer for the Skip box of the jobset or job to be skipped. When the autoscan encounters a jobset or job with a non-zero skip count, it automatically ignores that jobset or job and decreases the skip count. When the skip count is again zero, either because the workload administrator explicitly set it to zero or because the jobset or job has been skipped the necessary number of times, the jobset or job again becomes eligible for automatic selection.
2.
3.
624
Administrator Guide
Autoscan
4.
CalendarsDoes the calendar named by the calendar operand in the jobset or job profile indicate that today is a workday? Jobsets and the jobs subordinate to them, whose calendars indicate that today is a workday, are automatically brought into the tracking file during autoscan. Workload uses only the date information provided by a calendar and ignores any time information. Workload gets the early start time from the job or jobset profile.
Cleanup and Backlogging

What happens to jobs that are not completed when the next new-day autoscan occurs? The answer to this question depends on whether the job is eligible for backlogging. Jobs that are unable to start on the day they are selected and have Backlog=YES in their profile (or default to Backlog=YES through their Jobset profile) are backlogged. When an unfinished job is backlogged, it is left in the tracking file as part of the workload for the following day and automatically rescheduled for processing. Jobs that are unable to run on the day they are selected and which have Backlog=NO in their profile (or default to Backlog=NO through their jobset profile) are automatically canceled and purged from the tracking file as part of the new-day autoscan. Jobs that are running when the new days autoscan occurs and have Backlog=RUNNING in their profile are backlogged. When a running job is backlogged, it is left in the tracking file as part of the workload for the following day and is automatically rescheduled for processing. If the job is not running during the autoscan, the job is removed from the tracking file.
Tip: The time of the new-day autoscan should occur after the expected completion of all scheduled jobs. This makes the Backlog option more meaningful. If the new-day autoscan runs before the days work is completed, all unfinished jobs will either be purged or backlogged.
Workload Management
625
Workload Processing
Workload Processing
The processing of the current days workload (work in the tracking file) is status driven. Workload constantly monitors and tracks jobs, moving jobs from one status level to the next only after specific conditions or requirements have been satisfied. The following figure shows the various status levels through which jobsets and jobs advance during workload processing. The autoscan process brings qualifying jobsets and jobs into the tracking file with an initial status of LOADNG. After all the new work loads, Workload marks it WSTART (Waiting to Start). Autoscan is then complete.
Jobset AUTOSCAN 1. LOADNG 2. WSTART
Being Loaded Into Tracking File Waiting for Jobsets Early Start Time
Job 1. LOADNG 2a. WSTART

Being Loaded Into Tracking File Waiting for Jobset to Start
2. WSTART 3. WPRED 4. START WORKLOAD PROCESSING
Waiting for Jobsets Early Start Time Waiting for Jobsets Predecessors Now Looks at Jobs
2a. WSTART
Waiting for Jobset to Start
WORKLOAD BALANCING
11. COMPL
When All Jobs Complete. . . Mark Jobset
2b. WSTART 5. WPRED 6. WRSRC 7. SUBPR 8. SUBMIT 9. START 10. COMPL
Waiting for Jobs Early Start Time Waiting for Jobs Predecessors Waiting on Resources Submit in Progress Submitted Started Successfully Completed
After bringing all new qualifying jobsets and jobs into the current days workload (into the tracking file), Workload processes the workload by reviewing:

Early start time Predecessors Priority Resource usage and availability
Jobsets are processed first. Jobset criteria are evaluated prior to any criteria for jobs in the jobset. First, Workload checks that a jobsets early start time has arrived; second, it checks to see if all predecessor requirements for the jobset have been satisfied.
626
Administrator Guide
Workload Processing
Once the jobset is in START status, Workload Management looks at similar criteria for jobs in the jobset. A jobset must be marked as started (START) before its jobs can be evaluated. For example, when a job is in WSTART (Waiting to Start) status, Workload Management evaluates its early start time. If the early start time has been reached, the job is placed in WPRED (Waiting for Predecessors) status. Otherwise, the job stays in WSTART until the specified early start time is reached. Workload Management prioritizes jobs based on resource requirements (if any), early start time, and priority. Although you can fine-tune the sequencing of your workload using early start time and priority, you typically use predecessors as the primary means to establish the sequence of workload jobset and job processing. Once all the jobs in the jobset are complete, the jobset is marked complete (COMPL). A jobset is also marked complete if none of its jobs meet the criteria for selection, or if there are no jobs in the jobset. To summarize, Workload first looks at the jobset to determine that early start time has arrived and predecessor requirements are satisfied. Workload then looks at the jobs in the jobset to determine that early start time has arrived, predecessor requirements are satisfied, and that resources, must complete time, and priority can be satisfied.
Workload Management
627
Workload Logs
This maintenance activity is applicable to UNIX/Linux platforms only. Whenever you start the Workload Management function, all but the last 10 versions of the audit trail log files are automatically purged by an implicit execution of the cleanlog shell script. The cleanlog script is located in the $CAIGLBL0000/sche/scripts directory. You can run the cleanlog script whenever you want to purge old audit trail log files by entering the following command:
$CAIGLBL0000/sche/scripts/cleanlog
The $CAIGLBL0000/sche/log/$host directory contains the Workload log files. Workload Log mtrsuf Description This four-byte file identifies the current suffix number of the schdxxx.nnnn files described following. The version number can be a maximum of 9999. These files represent the stdout and stderr for each of the Workload daemons. There is only one version of each of these files. ca7xxx.out provides an audit trail of all display command processing that flows through Workload. The files are rebuilt each time Workload is stopped and restarted. This file provides an audit trail of all update command processing that flows through Workload, including trigger commands. A new version of this file is created each time Workload is cycled and at midnight every day. nnnn is identified by the mtrsuf file. This file provides an audit trail of all tracking activity by Workload. A new version of this file is created each time Workload is cycled and at midnight every day. nnnn is identified by the mtrsuf file. This file provides an audit trail of all submission and selection activity by Workload. A new version of this file is created each time Workload is cycled and at midnight every day. nnnn is identified by the mtrsuf file.
ca7xxx.log ca7xxx.out
schdlcs.nnnn
schdtrk.nnnn
schdmtr.nnnn
628
Administrator Guide
Tracking File
As mentioned previously in this chapter, work remains in the tracking file until it is either cleaned out during the new days autoscan, or until you manually cancel and purge it from the current days workload. Because any failed jobs (and their jobsets) that are eligible to be backlogged would remain in the tracking file after the new-day autoscan, we recommend that you check the tracking file on a periodic basis and clean out (cancel and purge) any obsolete entries that were not automatically removed. These backlogged jobs were not eligible to be purged as part of the new days autoscan.
Undefined Calendars During Autoscan

To prevent potentially serious incorrect scheduling of jobs, Workload Management automatically suspends job submission (using an implicit cautil stop autosub command) when it detects calendar validation or reference errors. Typically, this is caused by a job or jobset reference to an undefined calendar profile. Upon issuing this implicit cautil stop autosub command, Workload Management issues a message to alert the Event Console, and in turn the workload administrator, that a calendar validation problem was detected during autoscan. The message provides an opportunity to identify and correct any error that may exist before any jobs are run in error. After completing the necessary maintenance tasks to correct the condition, you can instruct the Workload Management real-time components to rescan the Workload Management databases for eligible jobs and jobsets by running the command:
cautil start autoscan
To resume automatic job submission, run the following command:

cautil start autosub
Workload Management
629
Workload Database
Unload Workload Definitions to a Text File
You can use the cauexpr command to unload Workload definitions to a file called cauexpr.txt in cautil type format that can then be used by cautil. You can upload the file if necessary, take the definitions to another machine, or use cautil to input them. See the online CA Reference for a description of the syntax for the cauexpr command. The following maintenance tasks are applicable to UNIX/Linux platforms only.
Schedule Routine Backups with unidbbackup
We recommend that you schedule routine backups of the Workload Management database. A sample shell script provided with Unicenter NSM, unidbbackup, performs a combined database backup and archive for all or selected Unicenter NSM databases. We recommend that you define unidbbackup as a regular Workload Management job, thus automating the largest part of your Unicenter NSM database maintenance activities. The full path name of the unidbbackup script is $CAIGLBL0000/db/scripts/unidbbackup. Eight operands are available for use with unidbbackup to allow you to tailor the shell script to your own maintenance requirements. The usage of the operands is documented in the shell script.
Purge Old History Records
To delete old history records that are no longer associated with a job or jobset record in the Workload database, run the History Report using the CLEAN parameter:
$CAIGLBL0000/sche/scripts/schdhist CLEAN
Note: You must specify the CLEAN parameter in uppercase. The CLEAN parameter deletes the associated history entries for any job or jobset record that no longer exists in the Workload Management database (has been deleted). The History Report lists the history entries that have been deleted from the database.
Submit Jobs on Behalf of Another User

Workload Management allows you to submit jobs on behalf of another user. In order to enable this policy, you must first supply new privileges for the Unicenter NSM user ID and for those users logged on by Unicenter NSM. See the instructions for submitting jobs on behalf of another user in the online CA Procedures under the topic, Submitting a Process as Another User.
630
Administrator Guide
Agent/Server Configurations
Workload Management provides a flexible architecture that lets you distribute work to multiple machines where the necessary resources are available for a job to be processed. Workload Management has two primary components that are used in combination to provide both local and remote scheduling. These two components, which were mentioned earlier in the introduction, are as follows:
The server, which provides support for the database and has the capacity to build schedules for execution The agent, which processes and tracks the execution of work on behalf of the server
By combining these two elements, Unicenter NSM can provide many different combinations of local and remote scheduling. Distributed remote scheduling can be performed between a single full-function Workload server and a single agent or many agents or among multiple Workload servers installed in the same network. Each Workload server can have many clients and each Workload client can be designated as a client of many servers. Workload Management is not restricted to having an agent service just a single Workload server. A server (regardless of platform, UNIX/Linux, Windows, or z/OS and OS/390) can have its work tracked for it by an agent. The following sections describe how you can apply this architecture to defining Workload Management policies across the following:

A single server machine Multiple servers in an agent/server domain
Workload Management
631
Single Server Workload Management on a single server uses a local server and a local agent to define, service, and track all scheduling activity. The following diagram shows you this configuration for a single node called Mars:
Multiple Hosts in an Agent/Server Relationship Workload Management in agent/server mode uses a local server, a local agent, and a remote agent to define, service and track all scheduling activity across multiple hosts. The following diagram shows two host machines in an agent/server relationship. Mars, the server machine where the Workload database is located, has a local agent and a remote agent. The local agent processes work to be done on mars, and the remote agent processes work sent by mars to the remote node titan.
632
Administrator Guide
Cross-Platform Scheduling
Scheduling, as defined in the past, was the ability to schedule units of work (jobs) within a particular host (for example, z/OS and OS/390, Windows, UNIX/Linux, AS/400). This scheduling activity started out with simple definitions:

Time dependencies. (Start Job A at 10:00 AM.) Unit-of-work dependencies. (Only start Job A after Job B has completed successfully.)
Today many data centers are working with more complex production workloads that cover a wider variety of processing environmentsincluding OS/390, UNIX/Linux, Windows, VAX, and other platforms communicating with each other. Such an environment requires cross-platform scheduling.
Cross-platform scheduling provides integrated enterprise control. It defines and sets dependencies. It submits and tracks the status of units of work (jobs or events) not only on the traditional platforms (z/OS and OS/390, UNIX/Linux, Windows, AS/400) but on a variety of other platforms. Actions result in the immediate and automatic notification of status changes of the unit of work (EXECUTING, COMPLETED SUCCESSFULLY, ERROR) and the ability to perform additional automatic actions. These status changes can trigger event-dependent processing not only on the local platform but on other systems/resources throughout the environment to maximize enterprise processing efficiency. Computer Associates provides distributed scheduling capabilities that enable integration of its z/OS and OS/390 (formerly MVS) productsUnicenter CA-7, Unicenter CA-Jobtrac, and Unicenter CA-Schedulerwith Unicenter NSM.
Workload Management
633
Components of Cross-Platform Scheduling

Workload Managers and Agents Cross-platform scheduling is implemented using a manager/agent model.
In this architecture, the manager performs the following functions:

Maintains job definitions and relationships Evaluates job execution and job completion information Uses a database for workload definitions Interfaces with agents to initiate jobs and collect status information
The workload agent component is a small set of programs that execute on each target machine where jobs will be processed. The agent performs the following functions:
Receives job requests from one or more managers and initiates the requested program, script, JCL or other unit of work Collects status information about job execution and file creations Sends the status information to the requesting workload manager for evaluation
Many environments choose to use a centralized repository for defining jobs and monitoring their workload. The Workload Management component of Unicenter NSM provides a Workload agent so you can initiate and track jobs on a machine without maintaining a workload database on that machine. The Workload agents can process a request from a Workload manager (Unicenter NSM on another machine or one of our OS/390 scheduling products) by initiating the requested process and returning tracking information about that process to the requesting Workload manager. Any Workload manager can submit job requests to any Workload agent.
634
Administrator Guide
Configuring Workload Managers and Agents
All managers and agents that participate in cross-platform scheduling require a valid CAICCI connection.
Tip: Review the CAICCI considerations listed in the CA Common Communications Interface overview in the online CA Reference. Careful consideration of these issues will help to ensure that your Workload scheduling tasks work across a variety of platforms.
The Workload manager requires a station definition for the Workload agent node. The Workload agent does not require any additional configuration because it simply processes requests on behalf of the Workload manager.
Implementation
Cross-platform scheduling can include several different platforms and several different products, as indicated in the following examples:
Unicenter NSM Workload servers on Windows can submit work to Unicenter NSM agents on UNIX/Linux Unicenter NSM Workload servers on UNIX/Linux can submit work to Unicenter NSM agents on Windows Unicenter CA-7, Unicenter CA-Scheduler, and Unicenter CA-Jobtrac can submit work to Unicenter NSM agents on Windows and UNIX/Linux Unicenter NSM Workload servers on Windows and UNIX/Linux can submit work to Unicenter CA-7, Unicenter CA-Scheduler, and Unicenter CA-Jobtrac
Workload Management
635
Centralized or Decentralized? The implementation of cross-platform scheduling can be tailored to the needs of each site. Prior to installing the software components, decisions must be made that determine where managers and agents will be implemented.
Centralized
You can implement Workload Management in a centralized fashion so that there is a central repository on one server. You can use this central repository to schedule and monitor work on any other server. In the scenario following, Unicenter NSM Workload server is installed on one server, and the Workload agents are installed on the other systems.
Decentralized
You can implement Workload Management in a decentralized fashion so that there are multiple Workload managers. Each of these can manage jobs on their own server and request processing on other servers running Workload agent (and, optionally, Workload server).
636
Administrator Guide
Unicenter WorldView
Regardless of whether you use a centralized or decentralized method of implementation, an important element of any implementation is being able to access and monitor all of the enterprises workload from a single point. To accomplish this, use Unicenter WorldView and the scheduling WorkStations for the z/OS and OS/390 scheduling products:

Unicenter CA-Scheduler WorkStation Unicenter CA-Jobtrac WorkStation Unicenter CA-7 WorkStation
Recommended Approach See the instructions for implementing cross-platform scheduling in the online CA Procedures under the topic, Implementing Cross-Platform Scheduling. Scheduling Workstation Usage Scheduling WorkStations provide a graphical tool for defining jobs and monitoring current workload processing on the OS/390 scheduling products. The scheduling workstations, when used in conjunction with Unicenter NSM, provide the ability to administer and monitor all of your batch processing through WorldView from a Windows workstation.
Workload Management
637
Important Configuration Environment Variables

The environment variables listed following are referenced in various sections of this chapter. See the online CA Reference for a summary of all Workload Management environment variables.
Default Calendar
Windows Environment Variable: Default calendar UNIX/Linux Environment Variable: CAISCHD0009 The name of the default Workload Management calendar is BASE (base for UNIX/Linux platforms), but you can assign a different name to the default calendar through this environment variable. For Windows platforms, this value is set in the Configuration Settings dialog. Click the Options and Workload Management tabs to locate the variable. For UNIX/Linux platforms, this environment variable is set in the file $CAIGLBL0000/sche/scripts/envset. Note: For C shell users, this environment variable is set in the file $CAIGLBL0000/sche/scripts/envusrcsh.
Autoscan
Windows Environment Variable: Autoscan hour and Interval between Autoscans UNIX/Linux Environment Variable: CAISCHD0011 and CAISCHD0012 These Workload Management environment variables set the time of day for the new-day autoscan and the interval between autoscans for the current workday. You can set these environment variables to different values if you want to change the default time of the new-day autoscan (default is 0 for 00:00 on Windows and 1 for 01:00 on UNIX/Linux platforms) or the default autoscan interval (default is every 3 hours). For Windows platforms, this value is set in the Configuration Settings dialog. Click the Options and Workload Management tabs to locate the variable. For UNIX/Linux platforms, valid values for CAISCHD0012 are 0, 1, 2, 3, 4, 6, 8 and 12.
638
Administrator Guide
Post on Cancel?
Windows Environment Variable: Post on Cancel? UNIX/Linux Environment Variable: CAISCHD0014 This environment variable sets the option that controls the effect of the cancel command on successor jobs. The default setting is YES. With this setting, Workload Management posts on cancel, allowing successor jobs to run because the predecessor requirement is satisfied by the predecessor having been removed (by the cancel command) from the current days workload. If the variable is set to any other value, successor jobs dependent on the prior completion of a canceled job are not posted. Because the predecessor requirement is not satisfied, successor jobs will remain in a WPRED (waiting for predecessors) status. For Windows platforms, you can change the setting of the Post on Cancel? environment variable from the default of Y (post on cancel) to N (do not post on cancel), in the Configuration Settings dialog. Click the Options and Workload Management tabs to locate the variable. To place a change in the option setting into effect, shut down and restart Workload Management using these commands at a command line prompt:
unicntrl stop sch unicntrl start sch
For UNIX/Linux platforms, this environment variable is contained in the file $CAIGLBL0000/sche/scripts/envset. Change the CAISCHD0014 environment variable from the default YES (post on cancel) to NO (do not post on cancel), by adding the following statements to $CAIGLBL0000/sche/scripts/envset:
CAISCHD0014=No export CAISCHD0014
To place this option setting into effect, shut down and restart Workload Management using these commands:
unishutdown sche unistart sche
Note: Issuing the unicntrl stop sch (Windows), unicntrl stop sche (UNIX), or unishutdown sche command (UNIX) stops job submission and disables display of the status tracking information for jobsets and jobs. These processes resume when you issue the unicntrl start sch (Windows), unicntrl start sche (UNIX), or unistart sche (UNIX) command. There is no loss of tracking data for jobs that complete or abnormally terminate while Workload Management is stopped. The Workload Event Logger continues to run and track completion of scheduled processes, even while Workload Management is stopped.
Workload Management
639
Environment Variables for Jobs and Actions

When Workload Management submits a job for execution as a Windows process, several environmental variables are set with information you may find useful. The programs or .BAT files executed as part of a job's submission can reference these variables, but the variables cannot be altered. Variable JOBSET JOBNAME JOBJNO JOBSTATION JOBQUAL JOBNODE JOBNUMBER JOBSUBFILE JOBUSER Description Name of the Workload Management jobset Name of the job, within the identified jobset The job number associated with the identified jobset and job The Unicenter NSM station to which the job was submitted The Unicenter NSM job qualifier The machine name (node ID) associated with the job The unique job identifier assigned by Workload Management for internal use The command string Unicenter NSM submitted to start this job The user ID for which the job was submitted
The following sample BAT file references settings within the following submitted job definition:
define jobset define job id=Trees id=(Trees,Oak,01) station=AMERICA autosel=yes
define jobparm id=(Trees,Oak,01)subfile=Oak.bat
The OAK.BAT file contains the following:

@echo Off set ID=%JOBSTATION%: Job(%JOBSET%,%JOBNAME%,%JOBJNO%) Qual(%JOBQUAL%) cawto %ID% Phase 1 has ended cawto %ID% Phase 2 has ended
If job Oak is selected or demanded, the following messages are sent to the Event Console Log:
AMERICA: Job(Trees,Oak,01) Qual(3001) Phase 1 has ended AMERICA: Job(Trees,Oak,01) Qual(3001) Phase 2 has ended
640
Administrator Guide
Monitor Workload Status

At completion of the new-day autoscan, the entire days workload resides in the tracking file. (See the Autoscan section earlier in this chapter for a detailed explanation of the autoscan process.) For the remainder of the day, Workload Management schedules, submits, and tracks the progress of that workload. This is an important distinction, as Workload Management does much more than just submit jobs on time. It actually monitors or tracks the status of the workload and updates control information as jobsets and jobs progress from one status to another. Using the tracking facilities of Workload Management, you can monitor job status and, as necessary, modify the days workload (modify the contents of the tracking file). Any changes you make in the Job and Jobset Tracking windows are temporary and affect only the contents of the tracking file; they do not affect the Workload Management policy stored as job or jobset profiles in the Workload Management database. Note: Although job and jobset resource requirements appear in the Tracking windows, this information is read-only and cannot be modified through the tracking facilities. If you discover that you need to make changes that affect Workload Management policies, as opposed to minor changes in the current days workload, see the instructions in the online CA Procedures under the topic, Modifying Workload Management Policies. See the instructions for monitoring workload status in the online CA Procedures under the following topics:

Displaying Jobset Status Changing the Status of Non-CPU Jobs Tracking the Time Spent on Manual Tasks Changing the Current Workload
Workload Management
641
Jobflow Tracking on Windows

Note: The Jobflow GUI is available on Windows platforms only, but can be used to display Windows, UNIX, and z/OS and OS/390 Workload Management policy definitions and status. Opening either the Jobflow Forecast icon or the Jobflow Status icon from the Workload Management folder accesses the tracking facility of Workload Management. By reviewing the sections that follow, you will learn to do the following:

Start the forecast and status monitor components and select jobs to view. Interpret the jobflow displays. Customize the number of successor/triggered jobs to appear in the displays. View job dependencies. Print jobflow displays and save them as files.
Jobflow provides an online, graphical representation of an enterprises workload. You can view relationships between jobs that are defined in the scheduling database and monitor the status of jobs in real time. The graphical interface lets you tailor your view of the workload. You can limit the number of jobs to view by specifying job names, time span, and number of successor levels. You can display the results as either a Gantt or Pert chart. You can zoom in on a single jobs successors and triggers, or zoom out for a larger perspective. Jobflow provides two types of views:

Jobflow forecast views Jobflow status views
Jobflow forecast views display job relationships (that is, predecessor-successor or job-triggers) for selected jobs within a given time frame. You can view dependencies (requirements) for any job in the flowchart. Jobflow status views display real-time status information for selected jobs within a given time frame. Color coding lets you easily identify job status and pinpoint trouble spots. For example, abended jobs are red and late jobs are yellow. Status information is updated at regular intervals, so your view of the workload remains current. Once you display a jobflow view, you can expand the scope of the display to include additional levels of successors (or triggered jobs), and to include job dependencies.
642
Administrator Guide
See the instructions for viewing the jobflows in the online CA Procedures under the following topics:

Starting the Jobflow Forecast Function Starting the Jobflow Status Function
The following sections present an overview of the jobflow forecast view and jobflow status view. The Jobflow Forecast View The jobflow forecast view allows you to view relationships between jobs that are defined in the Workload Management database. The Jobflow window contains the Jobflow Forecast window, which presents the jobflow forecast view of a single job; this job, the starting job, is the one you specify in your selection criteria. The jobflow forecast presents each job as a bar extending across the appropriate number of time increments representing the jobs start and end times. Links (or arrows) connect jobs that are related to the starting job. The jobflow consists of the starting job and the jobs that are successors to the starting job. The jobflow forecast view can be either a Gantt chart or Pert chart. Gantt charts display the relationships between jobs across a time span; Pert charts display job relationships without regard to time. For information about Pert charts, see the topic, Changing the Chart Type: Gantt or Pert, presented in the online Help. Jobs with names followed by plus signs can be expanded to show additional trigger (or successor) levels. Dependency Views Workload Management jobflow allows you to display a dependency view of any job in the jobflow. A dependency is any job or jobset that this job relies on as a predecessor or a system resource needed by this job. The dependency view also shows jobs and jobsets that rely on the specified job as a predecessor. The Dependency View window lets you see two levels of dependency for a specific job:
The jobs predecessors and all of the jobs dependencies (such as resources and user requirements) All jobs that are successors of the specified job
Workload Management
643
The Jobflow application window displays two document windows, the Jobflow Forecast window and a Dependency View window. You can display multiple dependency windows in a single Jobflow window. Viewing Dependencies in the Jobflow Forecast Window The Forecast window displays job predecessor-successor connections, but does not show job dependencies. To see these relationships and the status of same, you use the Dependency View. The Dependency View window lets you see two levels of dependency for a specific job. You can see the following:

The jobs predecessor and all of the jobs dependencies (such as resources) All jobs that are successors of the specified job
In a single view you can see all of the jobs that affect the target jobs execution, as well as all of the jobs that depend on the target job for their execution. Further, you can display multiple dependency views. See the instructions for viewing dependencies in the online CA Procedures under the topic, Viewing Dependencies. The Jobflow Status View The jobflow status view displays the real-time status of jobs within a given time frame. The Jobflow window contains the Jobflow Status window, which presents several jobflows (a job and its successors). Unlike the jobflow forecast view, the jobflow status view can contain multiple jobflows, depending on your selection criteria. Jobs are represented by bars extending across the appropriate number of time lines reflecting the starting and ending times of the jobs; the bars are color coded to indicate their status. Jobs that are currently executing span the vertical line representing the current time. Jobs that appear in the Future area are jobs that have not yet executed. Jobs in the Past area are jobs that have completed execution.
644
Administrator Guide
Viewing the Jobflow Status The Jobflow Status window shows the real-time status of the jobs you selected. The window displays one or more jobflows. Jobs that are currently executing span the vertical line representing the current time. Jobs that appear in the Future area are jobs that have not yet executed. Job names appear inside or next to the job symbols. When you first display the Jobflow Status window, the active jobs become the starting point of the flow. As the status is updated, a job remains in the display until the following three conditions are met:

The job completes. All jobs associated with the job complete. The end time of the job precedes the start time of the display.
The default color codes for job status are as follows: Color Light blue Dark green Medium green Description Jobs that are supposed to be processed in the near future based on what is defined in the database Active jobs Ready queue jobs This status occurs so quickly that it rarely appears on the Jobflow Status Window. Light green Dark blue Yellow Red Pink Request queue jobs Completed jobs Late jobs Abnormal jobs Canceled jobs
Note: You can change the default color scheme using the methods described in the Customize the Environment section presented later in this chapter. In the jobflow status view, as in the jobflow forecast view, you can expand job displays to show additional or successor levels. You can also display dependency views.
Workload Management
645
Displaying Multiple Views You can display multiple jobflow forecast and jobflow status views simultaneously. See the instructions for displaying multiple views in the online CA Procedures under the topic, Displaying Multiple Views. Customize the Environment Facilities are provided that enable you to customize the jobflow display as well as the appearance of objects in the Jobflow Forecast and Jobflow Status windows.
Operational Modes
Jobflow has two operational modes:

Run mode Design mode
Run mode is the basic operating mode. When the system is in run mode, you can perform all of the Jobflow functions except changing the appearance of objects in the jobflow and saving jobflow forecast and status files. Design mode allows you to access the Tools window to change the appearance of the Jobflow environment and to save jobflow forecast and status files. The default mode at startup is run mode. See the instructions for customizing your Jobflow environment in the online CA Procedures under the following topics:

Adjusting Job Name Labels Changing the Appearance of Objects Changing the Chart Type: Gantt or Pert Changing the Display Color Changing the Display Fonts Changing the Display Size Choosing Run Mode or Design Mode Expanding and Collapsing Jobflow Levels
646
Administrator Guide
Scrolling Through the Forecast and Status Displays You can scroll left and right to change the time frame displayed, or scroll up and down to display multiple jobflows (a job and its successors/triggered jobs) by using the navigation buttons or commands described in the online CA Procedures under the topic, Navigating Through the Jobflow. You can tailor your view of the jobflow by expanding or collapsing the levels of successor jobs that appear. For example, you may want to see several levels of detail for a specific job but not for others. Job names that are followed by a plus sign designate jobs that can be expanded. Refreshing the Display The display is automatically refreshed at regular intervals to update the Jobflow Status window. (You specified a refresh rate for the Jobflow Status window in the Status Selection Criteria dialog when you selected the workload to monitor.) You can control the updating of status information by refreshing the display at any time, stopping the refresh process, or changing the refresh rate. Printing a Jobflow Forecast You can print the current view of the jobflow (that is, the contents of the active Jobflow Forecast window), or you can print the entire jobflow forecast. You can customize your output by specifying fonts, colors, titles, legends, and other elements. The typical jobflow forecast spans multiple pages, both horizontally and vertically, and the output must be assembled. Jobflow generates a two-part number on each page of the printed output indicating the location of a particular segment on the assembled, printed flowchart. The digits preceding the decimal indicate the horizontal position (the row) of the segment; the digits following the decimal indicate the vertical position (the column) of the segment. The following diagram illustrates the numbering convention:
Workload Management
647
The sections in the remainder of this chapter provide more detail on the following:
Customizing the output, specifying margins, titles, and reference information using the Page Setup dialog Previewing the output before printing it Adjusting the number of pages and the scale
Customizing Your Printed Output The Page Setup dialog allows you to customize the margins of the printed jobflow and to specify titles and reference information to appear on the printed output. Settings for page margins, network margins, and borders apply to every segment of the printed output. Titles and legends can appear either on every segment, or just on the segments that span the bottom of the printout, depending on the options you specify in the Chart Print Options dialog (see the section Adjusting the Number of Pages and the Scale presented later in this chapter). Previewing Your Printed Output Choose File Print Preview to view a segment of the jobflow as it will appear in the printed output. The Print Preview window shows all jobs that fall within the time frame specified in the Jobflow Forecast window, including jobs that do not appear on the screen (that is, more jobs may be active during a time period than can fit on a single screen). The view includes document titles, document reference information, page title, and legend, when specified. Adjusting the Number of Pages and the Scale Most likely, you will be using Jobflows automatic settings, which determine the number of horizontal and vertical pages required to most effectively accommodate the objects in the jobflow. You can, however, override the automatic settings with your own numbers for horizontal and vertical pages. The numbers you choose will affect the appearance of the printed output.
648
Administrator Guide
Before printing, adjust the scale by zooming in or out. The number of pages required to print the jobflow depends on the time span you specified (the longer the time span covered, the greater the number of pages) and the scale of the objects in the jobflow display (the larger the magnification, the greater the number of pages). Note: If you turned on the page title option in the Page Setup dialog, the page title (that is, the title bar text) appears at the bottom of every page segment, regardless of how you set the Title on bottom pages only option. Opening and Saving Jobflow Forecast Files Once you have tailored your view of a jobflow in the Jobflow Forecast window (by expanding and collapsing the levels that appear and by modifying the scheduling database), you can take a snapshot of the jobflow by saving it as a jobflow forecast file with an extension of .GBF. Note: This option is available only in Unicenter Classic. When you open a flowchart forecast, the displayed workload is not connected to the underlying scheduling database; thus, you cannot expand and contract trigger levels or display dependencies. The advantage of working with a jobflow forecast file is that you can open the file quickly, since Jobflow does not have to build a selection list of jobs in the database. Working with a file, rather than a dynamic flowchart is useful if your schedule does not change frequently. See the instructions for opening and saving a Jobflow Forecast file in the online CA Procedures under the following topics:

Opening a Jobflow Forecast or Status File Saving a Jobflow Forecast or Status
Workload Management
649
Chapter
Problem Management
Problem Management defines and tracks items and events. The items and events are the components and activities typically found in a data center or processing environment, items such as PCs, printers, and file servers, and events such as program and network activity. Typical problem management systems create problem records, track the progress of problems toward resolution, and eventually complete and archive the problems. Unicenter NSM provides additional Problem Management capabilities that let you:

Establish a configuration of components Define Problem Management policies Define problem escalation policies Set up Machine Generated Problem Tracking (MGPT) policies
Establish the Configuration

The first step in implementing Problem Management is to populate the database with definitions of the components of your configuration that are candidates for problem tracking. While not required, component definitions in the Problem Management database let you manage your Help Desk more easily and effectively. Some of the components you may want to define are as follows:

Displays/monitors Keyboards Telecommunications equipment PC equipment PC software Network equipment Printers Office automation equipment
Problem Management
71
Establish the Configuration
Note: If you have Microsoft SMS installed on Windows platforms, you can use the caimpsms command to create Unicenter NSM component definitions for your SMS inventoried items. See the online CA Reference for information on the caimpsms command. Establishing a configuration is a matter of defining components by serial number, category, type, parents, children, peers, warranty, maintenance, users, and so forth. There are two benefits to establishing the configuration in the Problem Management database. The first benefit is that you have a central repository of pertinent information about the components. This repository provides centralized access to all information about components, such as the warranty, where to place service calls or which engineer to ask for. The second major benefit is that when a component fails you can assess its total impact because the configuration information includes the relationships (parent, child, peer) of components to one another. When a parent component fails, you know its children may be affected. If a component fails, you can check its current group for peers that may be able to assume the work of the affected component until it is repaired. Similarly, if several children of a particular parent fail over and over again, you may have reason to suspect the parent is involved in the root cause of the problems. You are not required to define warranty, maintenance, and user information for a component. However, if you define as much component information as you can before a problem occurs, you create a thorough and effective repository of all the critical information your Help Desk will need to begin effectively solving a problem the moment it is reported. Note: Unicenter NSM includes discovery services that you can use to help initially define components. See the section Phase 1Discovering and Classifying Network Devices in the chapter Advanced Visualization, for a discussion of the discovery process. Also see the following online CA Reference topics: For Windows platforms, see the DSCVRBE (Start Auto Discovery Processing) command. For UNIX/Linux platforms, see the cadiscvr and cabldcomp commands. See the instructions for establishing your configuration in the online CA Procedures under the topic, Defining Components.
72
Administrator Guide
Establish Basic Problem Management Policies

An important part of Problem Management is setting up tables of values that control how and when to apply Problem Management policies. Defining these tables is part of implementing Problem Management. Updating and adjusting them is part of the ongoing maintenance of Problem Management.
Setting Up Categories
The category table describes the valid categories for organizing problems. You can use predefined categories and, if necessary, define additional codes to meet the needs of your enterprise.
Predefined Categories
The predefined categories are as follows:

CPU - CPU category PRT - printer category MON - monitor category DSK - storage disk category
User-Defined Categories
After you determine how specific you want your categories to be and how problems should be reported, you can add categories. Be sure to take into account the way that your enterprise already segments problem information. Defining categories enables you to sort and select information from the Problem Management database according to your criteria. You will eventually want to study problem trends and analyze problem causes. Narrowing and focusing your view to specific categories can make these studies more significant and revealing. See the instructions for setting up categories in the online CA Procedures under the topic, Setting Up Categories.
Setting Up Status Codes

The status code table associates a problem with a certain status. You can use the predefined status codes and, if necessary, define additional codes to meet the needs of your enterprise.
Predefined Status Codes
The predefined status codes are as follows:

ACT - active problems RES - resolved problems COM - completed problems
Problem Management
73
It is important to understand the difference between RES and COM. A resolved problem (RES) has an unconfirmed solution, so the problem is not solved. A completed (COM) problem has a confirmed solution and is ready for archival. A completed problem is no longer eligible for priority escalation. (For more information about priority escalation, see the section Establish Problem Escalation Policies later in this chapter.) For instance, the resolution (RES) to a printer problem may be that it needs a new toner cartridge. However, the problem is not complete (COM) until you install the toner cartridge and the printer is once again online.
User-Defined Status Codes
If your organization uses other terminology for identifying the status of a problem, you should define the status codes that suit your needs and ignore the predefined status codes, or you can change their definitions to match your usage. You may want to define additional status codes, such as the following:

IMP - problem solutions that are being implemented PLN - problem solutions in the planning phase CIR - problems that have been circumvented EMG - critical problems that must be addressed immediately
Defining status codes enables you to sort and select information from the Problem Management database on that basis. Status codes are useful when you are investigating and updating problems. See the section Viewing a List of Problems later in this chapter. See the instructions for setting up status codes in the online CA Procedures under the topic, Setting Up Status Codes.
Setting Up Responsibility Areas

The responsibility areas define codes that represent specific areas of responsibility. You can use predefined responsibility area codes and, if necessary, define additional codes to meet the needs of your enterprise.
Predefined Responsibility Areas
The predefined responsibility area codes are as follows:

SYS - system administrator USR - end user support team OPR - system operator
74
Administrator Guide
Establish Problem Escalation Policies
Responsibility areas can also work in conjunction with escalation policies. As a problem escalates in priority, its responsibility area can also be escalated. A problem initially defined with a priority of 99 and a responsibility area code of JAJ could, through an escalation policy, be elevated to a priority of 1 and a responsibility area code of PRS. An escalation policy can be associated with a problem definition when the problem definition is opened. By associating a problem definition with a specific escalation policy, you can automate escalation of the problem definitions priority and responsibility area. Note: You may define the numerical value associated with high and low priority. For example, your installation may consider a priority of 1 to be the lowest and 10 to be the highestyou may decide not to use numbers over 10 at all. See the instructions for setting up responsibility areas in the online CA Procedures under the topic, Setting Up Responsibility Areas.

An escalation policy can be associated with a problem when you (or MGPT) open the problem definition. By associating an escalation policy with a problem definition, you can automate escalation of the problems priority and responsibility area as time passes. You can define several escalation policies to cover the many different types of problems your Help Desk encounters. For example, you may want a different escalation policy for problems in the CPU category than for problems in the office supplies category. The reason for separate escalation policies in this example is that a CPU problem needs to be escalated more rapidly than a problem involving office supplies. All escalation polices work on the basis of an aging interval and a cycle time. You set the cycle time to the frequency with which you want Problem Management to review the status of problems. You set the aging interval to the number of minutes you want to pass before Problem Management escalates a problem definition. If you have not updated a problem definition since the last review, and if its aging interval has passed, Problem Management escalates it to the next level in the escalation table associated with the problem definition. In short, the cycle time is how often Problem Management reviews the problem definition. The aging interval is how much time you allow to pass before escalation occurs. Escalation policies, which include the aging interval, are set up during implementation of Problem Management. The default cycle time for problem review is set up during installation, but you can modify it.
Problem Management
75
Windows platform installations can modify the default cycle time for problem review by following this procedure: 1. 2. 3. Open Configuration from the Unicenter NSM main folder. Open Settings from the Configuration folder. Click the Problem Management tab of the Unicenter Settings notebook. Enter a new value in the Setting column of the ESCALATION SLEEP TIME parameter.
UNIX/Linux platform installations can modify the default cycle time for problem review by setting the Problem Management control option ESCALATION_CYCLE_TIME in the configuration file $CAIGLBL0000/prb/config/ca_prb.init. Modifying and adding escalation policies are routine maintenance activities in Problem Management.
Escalation Tables
Defining an escalation table is simple. The first thing to understand is that a priority level, 1 to 99, is either high or low depending on your companys declaration of what is high and what is low. For the rest of this discussion, let us assume 1 is high and 99 is low. The next thing to understand about an escalation table is that you can use the Priority and Range fields together to define an inclusive priority range. For instance, if Priority is 89 and Range is 99, then upon completion of the aging interval, any problem that has a priority between 89 and 99 (inclusive) and has not been completed will be escalated to the values in the New Priority field, the New Responsibility field, and the New Status field. At this point, the table rolls to the next line of escalation actions. Do not confuse the aging interval with the cycle time. The aging interval is the number of minutes the problem must remain unattended (in a status other than COMplete) before it is escalated. Cycle time is the frequency with which Problem Management reviews the status of active problem definitions. Note: Problem definitions with a status of COM are considered complete and are not eligible for escalation.
Escalation Cycle Time
The default escalation cycle time is 1 hour (01:00). Every hour the problem definitions in the Problem Management database are checked against their associated escalation policies. If a problem has not been updated within the period set by the Escalation Cycle Time, and if the aging interval in the policy associated with that problem definition has elapsed, the problem definition is escalated to the next priority and responsibility area according to its associated policy.
76
Administrator Guide
Open New Problems
Note: Do not set an aging interval lower than the escalation cycle time. For example, setting the aging interval to 60 minutes and the escalation cycle time to 3 hours defeats the purpose of the aging interval. Problem Management would not know that the aging interval had elapsed until it was already two hours past due. See the instructions for establishing Problem Management policies in the online CA Procedures under the topic, Setting Up Escalation Tables.
Open New Problems

When a user reports a problem to the Help Desk, you first create a problem definition in the Problem Management database to describe it. If your problem definition includes category, status, and responsibility codes, you must make sure the codes you use for those definitions are already defined. By default, no fields are required as part of a problem definition. However, you may want to develop guidelines for your Help Desk staff to follow when entering data on the Problem - Detail window. See the instructions for opening new problems in the online CA Procedures under the topic, Defining Problems.
Establish Policies for Automatically Opening Problems

You can think of MGPT (Machine Generated Problem Tracking) as a special technician on your Help Desk staff. When specific messages come across the Event Console, MGPT enlists the aid of Event Management to automatically define, update, or close problem definitions in the Problem Management database based on MGPT criteria. Any message that Event Management receives is eligible for processing as a problem by MGPT. The types of messages you may want MGPT to process are as follows:

Hardware failures Failures of scheduled batch processes Excessive CPU usage High paging rates Unusual file activity Unusual security conditions
Problem Management
77
Message Records and Message Actions

One of the most powerful features of Problem Management is that any message directed to the Event Console, whether sent by components of Unicenter NSM or other software running on your system, can result in the automatic creation of a Help Desk problem. Messages routed to the Windows Event Log or sent to the Unicenter Event Console through Unicenter NSM commands or an API (Application Program Interface) represent event messages that may be eligible for processing by MGPT. In addition, messages generated by Simple Network Management Protocol (SNMP) traps or by the UNIX/Linux logger may also be eligible for processing by MGPT. As discussed earlier, however, MGPT looks for messages in a particular format. Not all of these messages are in that predefined message format, so how is it possible for Unicenter NSM to automatically open problems for exceptional events identified by other programs running on your system? Its actually quite simple. By using Event Management facilities, you can easily reformat the messages sent to the Event Console so that MGPT can recognize them. Message Actions
MGPT Tables
The Source component, ID node (Windows only), Event, Argument, Relation, and Data boxes on the MGPT table - Detail window correspond to the data contained in the Text field of the Message Record Action - Detail window as follows: If the Message Action Text is: ID node (Windows only) is: Source is: Event is: Argument is: Data is: MGPT3 [earth] MGPT Password Violated by tim002 earth Password Violated 2 tim002 Data is the literal value of the element found at the position of the value of Argument. Relation is the relationship between the argument and the data in which you are interested. Then a message action that has the constant mgpt3 [CCInode] MGPT followed by tim002 as the second element after Source and Event in its Text field would meet the criteria for MGPT to open a problem definition.
78
Administrator Guide
MGPT Cycle Time The default MGPT cycle time is 30 seconds. Every 30 seconds MGPT checks the messages in the MGPT log against all MGPT policies. If a message matches a policy, MGPT evaluates the criteria specified by the Cycle Duration, Warn Threshold, and Log Threshold. If the message meets those criteria, MGPT opens a problem definition. Be careful not to set a cycle duration lower than the MGPT sleep time (minutes:seconds), the MGPT_CYCLE_TIME for UNIX/Linux platforms. Setting the cycle duration to 1 minute and the MGPT cycle time to 3 minutes defeats the purpose of the cycle duration. Problem Management wouldnt know the cycle duration had elapsed until it was already two minutes past due. To change the MGPT cycle time on Windows platforms, edit the MGPT sleep time, minutes:seconds entry in the Configuration Settings notebook. The MGPT sleep time entry is on the Problem Management tab for both Client Preferences and Server Preferences. To change the MGPT cycle time on UNIX/Linux platform installations, edit the $CAIGLBL0000/prb/config/ca_prb.init configuration file and alter the setting for MGPT_CYCLE_TIME. See the instructions for establishing policies to automatically open problems in the online CA Procedures under the following topics:

Setting Up MGPT Tables Defining a Message Record Defining a Message Action
Problem Management
79
Track Problems
Track Problems
Tracking problems consists of the following:

Viewing a list of problems Investigating and updating problem definitions Closing and archiving completed problems
Viewing a List of Problems
To determine if there are problems to update or close, you need to view the Problems container. You can view a list of all problems or a selected group of problems in the Problem Management database. You can update the Problem Management database with any pertinent information about a current problem definition. The way you enter and look up the information about a problem is through the Operations LogOpLog for short. To close a problem, you need to change its status to complete (COM). Once you resolve problems and complete any steps necessary to implement the resolution, you need to archive the problems to free space in the Problem Management database. (See the cautil problem command in the online CA Reference for information on archiving problem definitions.) See the instructions for tracking problems in the online CA Procedures under the following topics:

Investigating and Updating Problems
Closing and Archiving Problems
Viewing a List of Problems by Status Using the OpLog to Investigate and Update Problems Closing Problems
710
Administrator Guide
Chapter
Report Management
Report Management automates and optimizes the production, packaging, distribution, and tracking of reports. Through Report Management, you can do the following:

Define who receives a report (the recipient) Define the pages of a report that a recipient requires Define where to deliver a report Produce multiple copies of a report or report subset
The following four main features of Report Management optimize your report distribution:
Page selection profiles identify the specific pages of a report to extract and bundle for a recipient. Report profiles identify the reports that Report Management processes. Recipient profiles define who receives the bundles. Bundle status indicates the status of a bundle as it journeys from production to recipient.
The implementation of Report Management consists of four straightforward tasks. First, select the files to become your source reports that Unicenter NSM will manage. Second, define page selection profiles that tell Report Management which pages should be extracted from the original report to form the new bundle. Third, define report and recipient profiles for each of these reports. The report and recipient profiles tell Report Management:

The file name of the source report Who will receive the customized selections of the report Whether to print or discard the original report file after using it Where to print the new bundle and what options to use
Fourth, route reports to Report Management for processing and tracking.
Report Management
81
Decide Which Reports to Manage
Decide Which Reports to Manage

The first step in implementing Report Management is deciding which reports could become more useful if specific pages were selected and bundled for delivery to specific recipients. Good candidates for Report Management include reports that need to be divided among multiple recipients, those that need to have certain pages distributed to multiple recipients, or those in which only a segment of the reportsuch as a totals or summary pageis needed by a specific recipient. To help determine which reports may be good candidates for processing by Report Management, look for reports that meet any of the following criteria:

Reports printed regularly and distributed to a large audience Long reports (over 50 pages) Reports that require multiple copies Reports that recipients read in part Reports to track from production to delivery Reports that are only needed on certain days (uses Calendar)
Once you decide which reports to manage, youre ready to create page selection profiles for them.
Select the Required Pages

Report Management has the ability to extract segments of a report and deliver those segments as bundles to specific recipients. It is through the page selection and report recipient profiles that you identify the relevant pages of a report and the individuals who expect to receive them.
Page Format and Selection
Before you can define which pages of a report you want to select, you need to know what the pages of the report look likehow their information is arranged on the pageand what text to search for to determine whether you want to select that page for the bundle. Specifically, you need to know:

The text for which you are searching The line number on which to begin searching for the text The starting and ending columns between which to search for the text What action to take when the text is found: either select the page, begin selecting a range of pages, or end a range of selected pages
82
Administrator Guide
Identify a Report Profile and Recipient
On the UNIX/Linux platform, you can use the Boolean expressions AND, OR, and NOT as logical operators in your page selection criteria. The logical expression determines the pages to include. By using the logical expression, you can combine several scan text criteria into one operation. For example, to specify a page to include only when both scan text criteria match, you can use an AND expression for both scan text criteria. Report Management treats any unspecified scan text criteria as an OR expression. Once you have this information, you are ready to define a page selection profile. See the instructions for selecting report pages in the online CA Procedures under the topic, Defining a Page Selection Profile.
Identify a Report Profile and Recipient

The recipient profile ties the report profile to the page selection profile so that segments of a report can be bundled and delivered to their designated recipient locations (printers and, for UNIX/Linux platforms, email IDs). In addition, the recipient profile defines the delivery requirements for a particular recipient. The recipient profile treats each recipient individually, so no individual is constrained by another individuals delivery instructions. Also, no individual has to wait until copies are made or pertinent segments are separated from a report because Report Management can arrange all those steps for each recipient. Specifically, a recipient profile defines:

The report recipient name The report profile name The page selection profile name The delivery destination for the report or bundle (printer or, for UNIX/Linux platforms, email IDs) How many copies to print
See the instructions for defining report profiles and recipients in the online CA Procedures under the topic, Defining Report and Recipient Profiles.
Report Management
83
Route Reports to Report Management for Distribution
Route Reports to Report Management for Distribution

When you have completed the essential tasks that define the automatic production and delivery of a report, you are ready to route the individually customized print output file to Report Management for distribution. On Windows platforms, use the jobroute command to route print jobs to Report Management for processing:
jobroute sample.rpt TestRpt1
where sample.rpt is the name of the source report file you are using to generate the customized reports and TestRpt1 is the name of the report profile you want to be used. Note: Before executing the jobroute command, verify that the CAPrinter is set to the Local Port and is directing files to Install_Path\NSM\Reptdist\jobqueue\n.dat. See the instructions for setting up the CAPrinter in the online CA Procedures under the topic, Setting Up the CAPrinter. On the UNIX/Linux platform, use the lp command to submit a report to Report Management for processing:
lp -dbeehive /usr/tmp/samplerpt
where samplerpt is the name of the source report file you are using to generate the customized reports. Report Management will process the report and extract the necessary pages to meet your recipients needs. Each recipient receives the segment of the report he needs at his preferred destination. The next step is to track bundles as they travel from creation to delivery.
Track Report Bundles

Using Bundle Status, you can track each report bundles manual delivery through intermediate delivery checkpoints until it reaches its recipient. For reports with highly sensitive information, or those reports with critical delivery dates and times, tracking the progress of a report until it reaches its designated recipient could be important. At each checkpoint a bundle passes, the date, time, location and individual who monitored that checkpoint can be recorded in the Bundle Status record.
84
Administrator Guide
Track Report Bundles
If a recipient profile has an end disposition of print or eMail, a Bundle Status profile is automatically created for it as soon as Report Management generates a recipients bundle, but the checkpoints along the delivery path must be monitored and recorded manually in the Bundle Status profile. For UNIX/Linux platforms, if a recipient profile has an end disposition of email, the Bundle Status profile automatically records the delivery of that bundle. See the instructions for tracking report bundles in the online CA Procedures under the topic, Tracking Status. Report Management at Work The primary Report Management bundleb service (bundlbee on UNIX/Linux platforms) drives the entire report distribution process by performing the following functions:
bundleb determines the file name of the report and then searches the Report Management database to determine whether any report profiles reference this file name. bundleb assumes a report has been routed in error if the search indicates there are no report profiles referencing this report file and reroutes the report to another special destination, the default name of which is rejects. (The name of this destination is specified with the Report Management configuration variable CAIPRNT0010.) bundleb accepts those reports for which a profile was found and performs another database lookup, this time looking for any recipient profiles that reference this report profile. bundleb again routes the report file to the rejects queue if the database search indicates there are no recipients interested in this report. bundleb initiates the report bundle generation process when there are recipient profiles defined that reference the report profile. bundleb then distributes the generated report bundles to the appropriate destination and creates/updates the bundle status profiles to reflect the same.
For more information on bundlebee (UNIX/Linux), see the online CA Reference.
Report Management
85
Rejects Queue
If a report file goes to CAPrint (NT) or lp (UNIX/Linux), but there is not a corresponding Recipient profile and Report profile for the report, it is sent to the rejects queue. The administrators in charge of the reporting process should define a process for regularly monitoring the rejects queue and taking appropriate action for the report files that end up there. For example, some appropriate actions include changing the print destination and printing the report or correcting errors in a Recipient or Report profile and resending the report file to report distribution for processing by Report Management. Regardless of the action chosen as appropriate for your installation, the important thing is to regularly monitor rejects. The report files in that queue are reports that are not reaching their intended recipients. For Windows platforms, the rejects queue is located in the Install_Path\NSM\Reptdist\Reject directory. For UNIX/Linux platforms, the rejects queue is located in the directory defined for the environment variable $CAIPRNT0010.
86
Administrator Guide
Chapter
Spool Management
The information in this chapter applies only to UNIX/Linux platforms. Spool Management provides a simplified interface to the UNIX/Linux lpadmin command (or the AIX equivalents) to let you access and manage spooled files, and to provide the systems administrator with a graphical interface to spool functions. Print devices are usually defined once and updated only when a new printer is added to the system. When you need to add a new printer, you probably spend an irritating amount of time just looking up the commands and syntax you need to make the update. Spool Management simplifies this process and expedites the overall task by allowing you to do the following:

Define, add, and update print devices Manipulate the printer queues Start and stop the spooler (available for platforms other than SCO and SVR4 MP (AT&T))
Manipulating the printer queues using Spool Management lets you do the following:

View all the jobs in a print queue View all the jobs created by a specific login ID View a report online Change the priority or destination of a job in the queue Change the number of print copies (feature not available on AIX) Delete jobs from the print queue Check what class each printer belongs to and which printers are members of the same class Determine which printers are enabled or disabled Determine whether a printer is accepting or rejecting print requests View a user-defined description, which can help identify a printers location or other key information that you choose
Spool Management
91
Implement Spool Management
When considering how Spool Management can help you, you should determine how many printers are currently connected to the system, and whether you would rather manage them through UNIX/Linux commands or through the Unicenter NSM Spool Management facilities.

Essentially, implementation consists of the following:

Defining devices Determining and defining procedures for modifying print requests Modifying print requests Monitoring the system to verify that everything is working as intended
If you decided to activate Spool Management during installation, you were directed to run the caspload script, which automatically determines what print devices are defined on your system and defines them to the Spool Management function of Unicenter NSM. Note: If you have not yet run caspload, you should do so now. If you are operating a UNIX/Linux platform other than SCO, or SVR4 MP (AT&T), you must stop the spooler before running this script. Remember to start the spooler when the caspload script finishes. For more information on caspload, see the online CA Reference.
Stop and Start the Spooler

Spool Management components allow you to define print devices without stopping the spooler. However, until the spooler is stopped and restarted, the newly defined or redefined print devices are not available. When the spooler is shut down immediately prior to defining a print device, the changes are accepted and processed immediately. Messages returned by Unicenter NSM when defining new devices will differ depending on whether the spooler is running. If the spooler is running when you are defining print devices, the following informational messages appear: .CAPS_W_052 Warning! Spooler Running: Printer request queued until spooler is shut down .CAPR_E_022 Printer action cancelled due to error condition
92
Administrator Guide
Tip: Before shutting down the spooler, you should consider that when you stop the spooler, all printing stops as well. Review the jobs currently printing, because any printing when the spooler stops will be reprinted in its entirety when the spooler is restarted. This means that if page 9000 of a 9500-page report is interrupted, the report will start reprinting at page 1 when the spooler restarts.
These messages tell you that the new print device definition could not be added to the active list of lp devices at this time, but that it will be processed the next time the spooler is shut down and restarted. See the instructions for stopping and starting the print spooler in the online CA Procedures under the topic, Stopping and Starting the Spooler.
Define a Print Device

When you add a new printer to your system, you need to define and describe the device to Spool Management. You can also use the Print Device feature of Spool Management to update an existing device definition and to enable or disable the flow of data to the printer. See the instructions for defining print devices in the online CA Procedures under the following topics:

Defining a Print Device (All UNIX/Linux Platforms Except AIX) Defining a Print Device (AIX Platform)
Modify a Print Request

You can modify the parameters of a print job even though it has already been submitted to the print queue. For example, you may want to change the number of copies you want printed, or you may want to alter the priority of the job in the queue. See the instructions for modifying print requests in the online CA Procedures under the topic, Modifying a Print Request.
Spool Management
93
Verify Spool Management Implementation

To verify that print devices are correctly defined, do the following: 1. 2. 3. Send a job to each of the print devices you defined. Check the print queue to see that the print arrived in the correct queue. Verify that the job printed correctly.
If the first step results in an error, check to be sure that the spooler is started. If the second or third step fails, verify the following:

Unicenter NSM is running. Spool Management is started. The printer is online and able to receive print requests.
Control the Flow of Data to Printers

Sometimes, it may be necessary to stop the flow of data to one or two specific printers. Use the Status fields in the Print Device - Detail window to accomplish this. Note: The spooling system does not have to be shut down to change the Status fields. See the instructions to stop a printer from printing or accepting jobs into its print queue in the online CA Procedures under the topic, Controlling the Flow of Data to Printers.
94
Administrator Guide
Chapter
10
Unicenter Reports
Unicenter Reports is a Unicenter Explorer-enabled, web-capable analysis and reporting solution that delivers desktop- and server-based reporting. It can also generate a wide array of queries across multiple Unicenter NSM databases. You can create sophisticated reports easily and schedule them for automatic execution and delivery through the network. This chapter introduces the main components of Unicenter Reports:

Reports Builder Reports Administrator Reporter Server
Note: You can upgrade Unicenter Reports 3.0 to CleverPath Reporter 4.0.1 for Unicenter. CleverPath Reporter 4.0.1 is a superset of Unicenter Reports 3.0. Install CleverPath Reporter from the Product Explorer after you have installed Unicenter Reports 3.0. See the CleverPath Reporter documentation for complete information about using Clever Path Reporter. To access CleverPath Reporter documentation, choose Start, Programs, Computer Associates, CleverPath, Reporter Builder or Reporter Server.
What Is the Reports Builder?

This tool is an easy-to-use report designer or generator that keeps simple reports simple and makes complex reports easy. With its flexible formatting capabilities, you can use this tool for everything from on-demand reports to monthly production reports. One of its more powerful features lets you retrieve data easily from multiple databases and place that data in the same report. Other features include:

Selecting data from any available Unicenter NSM database or data file Filtering data to limit what is returned from the database Adding calculations anywhere on a page Creating n-dimensional reports with crosstab details
Unicenter Reports
101
Viewing the report design, layout, and results Outputting reports to a printer or to a file
Accessing Reports Builder
You can access the Reports Builder in either of the following ways:

Start, Programs, Unicenter TND, Utilities, Reports Builder Start, Programs, Computer Associates, CleverPath, Reporter Builder (Available only if you upgrade to CleverPath Reporter 4.0.1 for Unicenter)
Configuring the Reports Builder

The following components of Unicenter NSM have reporting options:

Enterprise Management Agent Technology WorldView
Each report category requires a specific source type and database: Component Enterprise Management Agent Technology WorldView Source Type ODBC ODBC MS_SQLSERVER Database CA_TNDReports_EM CA_TNDReports_AT TNGDB
Note: Before using ODBC as a source type for Enterprise Management and Agent Technology reports, you must reload the reports in Unicenter Explorer before data can be accessed. To reload a report, open Unicenter Explorer and choose Reports from the drop-down list. Choose a report and click Reload.
Printer Requirements
You must install a printer driver on Windows before running CleverPath Reporter Builder or CleverPath Reporter Server so that CleverPath Reporter knows what the font metrics are. Font metrics define the exact sizes of all the characters so that information can be correctly positioned on a report. If your system does not have a local printer or even a networked printer available, you can define a local printer using a FILE port. This creates a virtual printer that will write to a file.
102
Unicenter Network and Systems Management Administrator Guide
If you choose not to install a printer, you can define printer metrics using the following procedure: 1 2. 3. 4. 5. Choose Unicenter TND, Utilities, Reports Builder. Choose Preferences from the Options menu. Click Expert, and then OK to close the dialog box. Choose Font Metrics from the Options menu. In the Metrics Database File Name field, type \NSM\Reports\irengine\fdb\fontinfo.fdb. Click OK. To define the source type and database, complete the following steps for each report category: 1. 2. 3. 4. 5. In Reports Builder, choose File, New, New Report. Click OK to go to the next screen. In the login screen, enter the Source Type and Database as described in the table above. Enter your user ID and password. Continue to create your report specifics by selecting from the screen options. See the online help for field definitions.
Note: Perform this configuration only once per session if the Use current login when creating details option is selected under Options, Preferences.
Selecting Data
No matter how large a Unicenter NSM database is or where it is located, it is very easy to add data to reports. To do this, identify where on the page the data should appear by creating a container called a detail. Details can be created two waysmanually or with a wizard. Either way, the Reports Builder prompts for selecting the file or database it should use as the source, and for any necessary passwords. After logging in to the database, begin selecting the reports data. Note: To use data from more than one source, create multiple details.
Unicenter Reports
103
Filtering Data
To limit data returned from the database, create filtering conditions that return only the needed information. For instance, if you are creating a report showing only Houston employees, add the filtering condition city = Houston to eliminate all other rows.
Adding Calculations
Use the Expression Editor to add a variety of calculations to reports. These calculations usually take the form of computed fields or summaries. A computed field calculates a value using functions, variables, columns, lookup tables, and user-defined expressions. Summaries can be placed anywhere in reports and provide information such as totals, average values, and the number of items matching a certain value.
Accessing Report Information

Several methods are available for accessing report information. See the Reports Builder online help for more information about the methods described in the following topics. The Reports Builder provides the following methods for accessing information: Method Report Views Description Four report views are available in Reports Builder: Design View, Partial Results View, Page Layout View, and Print Preview. Several print options are available for printing the entire report, specified ranges, multiple copies, and so on. The Reports Builder permits converting reports to several industry standard formats such as Excel, HTML, RTF, and so on. In addition, the Reports Builders ERF conversion permits viewing reports in its ERF Viewer without having to load the Reports Builder. You can publish and then view the report file or converted ERF in Unicenter Reports using Unicenter Explorer.
Printing Conversions to Other Applications
Unicenter Explorer
104
Note: When the report file is selected for viewing, the report executes first and then appears. When you view the converted ERF or HTML file, the reports output appears immediately because the results were executed during the publishing stage.
Catalog Management Outside the Reports Builder

In the Reports Builder, the File, Publish, Report option is used to publish reports to the catalog. You can also use the catadmin utility to publish reports; this utility also lets you manage the catalog. See the online CA Reference for more information about the catadmin utility.
Saving Database Passwords

When publishing reports to the catalog, you must save the database passwords in the report. To do this, select the Save Database Passwords in the Reports option in the Reports Builder preferences (choose Options, Preferences) before publishing. Note: Set this option again even if you set it in a previous version of the Reports Builder. If you open a report published using a previous version of Reports Builder with passwords saved in the report and open it with the current version, the database passwords are deleted if you do not also set the option in the current version. Also select the Use Saved Values For Login (No Prompt) Reporter attribute (choose Attributes, Report Attributes).
Unicenter Reports
105
What Is the Reports Administrator?
What Is the Reports Administrator?

The Reports Administrator creates the workspaces used by the Reports Builder. Using the Reports Administrator, you can (among other things):
Define which sources of data are available to users and how the users can connect to those sources. Configure data sources, limiting the number of tables and columns available for easier navigation. Specify how the data is presented to the users. Data can be grouped and given alternate names to make it easier for users to find and understand. Define how joins should be made to provide maximum efficiency.
In summary, the Reports Administrator lets you customize your environment to make it easier for users to find the data they need in the most efficient way possible.
Accessing Reports Administrator
You can access the Reports Administrator in either of the following ways:

Start, Programs, Unicenter TND, Utilities, Reports Administrator Start, Programs, Computer Associates, CleverPath, Reporter Builder, Reporter Administrator (Available only if you upgrade to CleverPath Reporter 4.0.1 for Unicenter)
What Is the Reporter Server?

The Reporter Server provides web access to reports from the CleverPath Portal or directly through a web server using CGI. Web-enabling report access provides an enterprise solution for the distribution of report output without requiring client software on each system. CleverPath Portal provides a secure, organized view of the report information available. When a report is saved in the Reports Builder, all of the report specifications are saved in the .rep file. The specifications include the different report elements; their attributes, like font, color, borders, source information, and designated passwords; page layouts; run-time variables; named expressions; and lookup tables. The report can be executed in the Reports Builder or use the Reporter Server. The Reporter Server uses a server to generate reports designed in the Reports Builder. The output can be sent to a printer, written to a PostScript file, or converted to another file format. The Reporter Server can be used with the Reporter Scheduler to schedule report execution.
106
What Is the Reporter Server?
Note: The Reporter Server is an excellent tool for increasing the efficiency of the Reports Builder; however, it does not schedule other products. It is not an all-purpose client and server scheduling utility. Use the Reporter Server when:
The report contains so much data that the speed and computational power of a server system are needed. The PC may not be able to run critical reports. You need to execute production reports on a regularly scheduled basis. By using the Reporter Scheduler, the actual time the report is generated can be scheduled.
Accessing Reporter Server
You can access the report server after you upgrade to CleverPath Reporter 4.0.1 for Unicenter in several ways:

From CleverPath Portal. Directly from a web server using CGI. From the Reporter Scheduler (either from the Reports Builder menu File, Scheduler, Schedule Report or by choosing Start, Programs, Computer Associates, CleverPath, Reporter Server, Scheduler). By choosing Start, Programs, Computer Associates, CleverPath, Reporter Server, Server. From a DOS prompt using a command line to run prsserv.exe.
Unicenter Reports
107
Chapter
11
Tape Management
Tape Management is not available on Windows platforms. Tape Management provides the tools to protect, control, and manage your tape resources. Using Tape Management, you can define retention policies to ensure that your tapes are protected from premature overwrite, secure access to tape-resident files, and maintain a comprehensive inventory of your tape library resources. Many enterprises require that physical storage be spread across multiple physical locations, rather than a single, local tape library. Examples of such storage facilities include a fireproof vault at your site or an off-site storage location. Working in conjunction with Tape Management, the Vault Management component enables you to specify which tape files belong where, and when they should be moved through the following facilities:

Vault creation Media selection Automated media movement Manual media movement Movement and inventory tracking Audit trails
In short, Vault Management provides an easy and effective way to coordinate off-site storage and retrieval of your critical tape files.
Tape Management
111
Define Tape Volumes
Define Tape Volumes

Resident Tapes
For a volume to come under the control of Tape Management, you must first define the volume serial number (VOLSER) in the Tape Management database. When a volume is so defined, it becomes a resident volume. Defining volumes (establishing residency) is accomplished by doing the following:
Using the Tape Management GUI or the catape utility create volume command to create volume definitions in the Tape Management database. Once defined, these volumes are considered resident volumes and are protected by Unicenter NSM.
Tip: Using the GUI permits you to create one volume definition in the Tape Management database. By using the catape utility, you can create a range of volume definitions. Initializing those volumes using the cainit command (see the section, Initialize Tape Labels, presented later in this chapter).
Nonresident Tapes
Volumes, which have been initialized and have valid labels, but are not defined in the Tape Management database, are considered nonresident tapes. There are special processing considerations (discussed later in this chapter) for these types of tapes. While we recommend that you create volume definitions in the Tape Management database before you attempt to initialize volumes, you are not required to do so. Any volume that is initialized, but is not defined in the Tape Management database, is considered to be a nonresident volume.
112
Administrator Guide
Initialize Tape Volumes

Internal Labels
Initializing a resident tape volume causes an internal label to be written on the tape. The VOLSER to be assigned to the tape must have already been defined in the Tape Management database (see the previous section). Tape Management reads internal tape labels to accurately identify those volumes under its control. Internal labels consist of a series of label records written to the tape prior to, and following, your actual tape files. Tape Management supports labeling standards approved by the American National Standards Institute (ANSI), which determine the format and define the content of these tape labels. A subset of the labels is described following. Two of them, VOL1 and HDR1, are referred to throughout this topic. Label
VOL1
Description The VOL1 label is the first record written to the volume and identifies the six-character alphanumeric volume serial number (VOLSER). The HDR1 label follows the VOL1 label and identifies the first 17-characters of the file name of the first data file following the HDR2 record. The HDR2 label follows the HDR1 label and contains fields describing physical characteristics of the first data file.
HDR1
HDR2
Note: To initialize a volume, its definition in the database must indicate that the volume is in active service and scratch status.
What Is a Scratch Tape?
The term scratch refers to a resident tapes status. If a resident tape has data stored on it and that data has not expired (more on this later), it is in retain status and will be protected against an overwrite. Otherwise, it is in scratch status and is available for output. Tape Management provides the cainit command for use in initializing volumes. The cainit command initializes the volume by writing an ANSI standard VOL1 label to the tape, places it under Tape Management control, and updates the Tape Management database to reflect that this volume has been initialized. For more information on the cainit command, see the online CA Reference. For example, the following cainit command assigns a volume label using volume serial number JPK001 to the volume that is currently mounted on the device identified in the command. Note that device specifications vary among operating systems, but your command will be similar to one of the following:
cainit cainit cainit cainit cainit /dev/rmt0 JPK001 /dev/rmt0h JPK001 /dev/rmt/c0t0d0s0 JPK001 /dev/rmt/0m JPK001 /dev/rmt/0m JPK001 ovrid
Tape Management
113
Because writing labels to a volume is a potentially destructive process (any data that may already reside at the beginning of the tape will be overwritten by the label), Tape Management performs the following tests before initializing a tape:
If VOL1 and HDR1 labels are not found on the tape, Tape Management determines that this tape is a new tape that does not require overwrite protection, and VOL1 and HDR1 label files are written to the volume. If VOL1 and HDR1 labels are found on the tape, additional tests are performed to determine if an overwrite is permitted on the mounted tape. For a description of these tests, see the section Reinitializing Tape Volumes, presented later in this chapter.
If no volume definition exists in the Tape Management database that corresponds to the VOLSER you are attempting to write to the tape, Tape Management proceeds with the initialization. In addition to resident and nonresident labeled tapes, Tape Management supports unlabeled tapes. For information on unlabeled tape support, see the section, Process Unlabeled Tapes, presented later in this chapter.
Reinitializing Tape Volumes

When first working with Tape Management, most sites typically start with a small set of tapes that they use for testing. In preparation for production or implementation testing, it may be necessary to reinitialize these tapes. Reinitializing resident tapes is not a simple matter of re-executing the cainit command. Specific tests are performed by Tape Management to protect against the accidental overwrite of valid data and inappropriate labeling of a volume. All of the following tests must be passed before a resident tape can be reinitialized: 1. When the tape was examined, did Tape Management find it to contain an internal volume label (VOL1)? If no, allow initialization. If yes, continue with the following test. Has the user explicitly declared the intention to overwrite an existing volume label by providing the cainit command operand, ovrid? If no, reject the label attempt. If yes, continue with the following test. If Unicenter NSM security is active, is this user authorized to label this volume according to ALTER LABEL privileges assigned through Security Management? If no, reject the label attempt. If yes, continue with the following test. Regarding the new VOLSER the user wants to write on this tape, does a volume definition for the same VOLSER already exist in the Tape Management database? If not, permit labeling.
2.
3.
4.
114
Administrator Guide
If a volume definition of that name does exist in the Tape Management database, is the Use Count in that volume record zero? If not, reject the label attempt. If zero, permit the labeling.
Tip: If you find your attempts to label a volume are being rejected, use the Tape Management GUI or catape utility commands to examine the relevant volume definition in the Tape Management database. Then, based on your new understanding of the initialization/reinitialization process, make whatever updates are necessary and appropriate.
Displaying an Internal Label

External labels do occasionally fall off or get placed on the wrong volumes. Labeling errors can result in an operator unknowingly mounting the wrong tape. Because Tape Management determines a tapes identity by checking the internal volume label, it is capable of protecting volumes from the unfortunate effects of a missing or incorrect external label. Clearly, the external label should match the internal label. In the event of a discrepancy, you can display the current internal label of a volume using the asmdmp command. You can use the following command to display the internal label content of a volume on stdout. Note that device specifications vary among operating systems, but your command will be similar to one of the following:
asmdmp asmdmp asmdmp asmdmp /dev/rmt0 /dev/rmt0h /dev/rmt/c0t0d0s0 /dev/rmt/0m
Using the information this command provides, you can update the external label accordingly.
Tape Management
115
Managing Special Tape Marks

enfcontrol 610 10
The enfcontrol 610 10 command controls how Tape Management handles applications that use setmarks. A setmark is a tape hardware feature available in some advanced devices that may be used for high speed tape positioning. Setmarks can, however, represent a tape integrity exposure and, by default, Tape Management rejects all attempts by applications to issue setmark commands to a device. Using the enfcontrol 610 10 command, you can disable this intervention and permit setmarks. For tapes labeled by HP OmniBack II, add the following line to the end of the $CAIGLBL0000/tape/scripts/rc file:
enfcontrol 610 10
If you use the OmniBack GUI to run backups, the surrogate tape mounting facilities of Tape Management must be used as well. For information on surrogate tape mounting, see the section Implement Surrogate Tape Processing, presented later in this chapter.
Transparent End-Of-Volume (TEOV) Assistance

When a UNIX/Linux application, writing to a volume, encounters an end-of-volume (EOV) condition, that application will receive an out of space (ENOSPACE) error return code from its last attempted write operation to that tape. When writing to a disk file, applications that receive an ENOSPACE condition typically terminate (no room on file system...so issue an error message and stop). If an application has been instrumented to be able to tell the difference between writing to a tape file and writing to a disk file, and it is capable of handling the tape device CLOSE, remount, and subsequent OPEN with another volume, then the application can continue its output operations without assistance. Unfortunately, there are relatively few applications that can handle this condition. For those applications that cannot, Unicenter NSM can transparently intervene and automatically:

Close, rewind, and eject (if possible) the current tape. Prompt the operator to mount another scratch tape. Upon receipt of the operators reply, label the new tape as a part of a multivolume tape set and continue writing.
A similar set of tasks is performed during a restore operation involving a multivolume tape data set. Unicenter NSM again can transparently intervene and automatically:

Close, rewind, and eject (if possible) the current tape. Prompt the operator to mount the next tape in the set. Upon receipt of the operators reply, continue reading.
116
Administrator Guide
Note: If you use an application to create a multivolume tape data set on a machine running Unicenter NSM with TEOV processing enabled, you must restore the data on the tapes using a machine that is running Unicenter NSM with TEOV enabled as well. Use the following two enfcontrol commands to enable or disable TEOV processing system wide:
enfcontrol 524 {0|1}
where: 0 Specifies that TEOV processing is disabled for all tape devices physically attached to this system. This is the default. 1 Specifies that TEOV processing is enabled for all tape devices physically attached to this system. Note: Only the root ID can execute the enfcontrol 524 command, and the setting affects only tape mounts initiated after command execution. Use the following enfcontrol command to set TEOV processing modes for a specific device:
enfcontrol 525 device {0|1}
where: device Identifies the tape device where TEOV processing will be performed. 0 Disables TEOV processing for the specified device, thereby overriding the current global setting. 1 Enables TEOV processing for the specified device, thereby overriding the current global setting.
Tape Management
117
Handling Special External Labels

External labels are typically gummed labels that are applied to the exterior of tape reels and cartridges. They provide a quick visual reference for the physical identification and logical filing of tape media. External labels can be generated under Tape Management automatically by changing the default value of the GUMLABEL configuration option to Y in the tms_options shell script. When GUMLABEL=Y is in effect, a label record is created and stored in the label.dat file upon every volume CLOSE and EOV for output tapes, and this file is used to print external labels. For more information on setting this and other Tape Management options, see the section Change System Options, presented later in this chapter. When GUMLABEL=N is in effect, label records are not created for all CLOSE and EOV output tape events. However, you can override this option value by using the GUMLABEL=Y operand of the catape utility mount command to create a label record for a specific tape. Unicenter NSM provides the ca_prt_label shell script for printing a single gummed label. Using this shell script, you are free to change the format of the printed label as you see fit. Note: Tape Management also supports unlabeled tapes. For more information, see the section, Process Unlabeled Tapes, presented later in this chapter. All other examples presented in this chapter outside of that topic assume that tapes are labeled.
118
Administrator Guide
Access a Resident Tape

Because writing data to a tape is an inherently destructive process (any data already on the tape is overwritten), Tape Management must make certain that the volume about to be written on is a scratch tape, or that the volume is positioned past the last file on the tape. For obvious reasons, Unicenter NSM performs substantially different types of tape management processing, depending on whether you want to write to or read from a tape. You must declare your intention to either read or by using the catape utility mount command.
Declaring Intentions
The following example shows a typical tar command that writes a file named myfile to a tape currently mounted in the tape drive identified in the command.
tar -cvf /dev/rmt/0m myfile
There is no advanced declaration of intent here, and without Tape Management, any data that may have existed on that tape would be overwritten and lost. The following commands achieve the same objective, but protect against data overwrite by declaring a need for a volume in scratch status.
catape mount /dev/rmt/0m myfileontape \ retention=30 volser=SCRATCH tar -cvf /dev/rmt/0m myfile
The mount command in the preceding example does the following:
Declares the intention to write to the tape by requesting that a scratch tape be mounted on the specific drive identified in the command Causes a record to be created in the Tape Management database that automatically associates the file named myfileontape with this volume after the file is written to it Retains and protects the file from overwrite for 30 days
As the preceding example shows, successful access to volumes does require some implementation effort. Protecting a tape, however, requires no such cooperation. If, for example, the user had attempted to use the first example shown previously (the tar command without the mount command), and the tape mounted on the tape drive was a retained resident tape, the write attempts would have failed.
Tape Management
119
This distinction is extremely important, as only Tape Management is capable of providing this level of tape protection without dependence on application cooperation.
Calling for an Input Tape

Once you create a definition in the Tape Management database, operators or applications no longer need to know which volume a tape file (or the most current version of a file) resides on. Using the catape utility mount command, applications can call for a tape file by name and Tape Management automatically consults the Tape Management database in order to determine which volume that tape file resides on. Further, because Tape Management knows which volume should be mounted to satisfy the mount request, it is capable of making certain that the correct volume is mounted. Tape Management will automatically reject any incorrect volume that is mounted, in a way that is completely transparent to the application that is attempting the tape access. You declare your intention to use a tape for input (which in turn sends a mount request to the console when the first physical access to the tape is attempted) using a variation of the same command we used in the previous discussion, the catape utility mount command. For example, to declare your intention to read a file called myfileontape, use the following command:
catape mount /dev/rmt/0m myfileontape
When this command is processed, the Tape Management components automatically scan the Tape Management database looking for the most current version of the tape file named myfileontape and make note of the VOLSER of the tape on which this version of myfileontape resides. When an attempt is made to read from the tape device (in this example /dev/rmt/0m), the device access attempt is interrupted and the volume information on the mounted tape is read and verified against the volume information extracted from the Tape Management database, without the application ever being aware.
1110
Administrator Guide
Verifying Tape Access (Input and Output)

The following summarizes how Tape Management verifies that the correct volume is mounted:
Intercept the access attempt to the tape drive and determine whether it is an input or output operation. Extract label information from the tape mounted in the device and determine what type of tape this is (resident scratch, resident retained, and so forth). If the tape is a resident tape, determine whether a declaration of intent has been supplied by a preceding mount command. If not, reject the access. Check if the context of the I/O access attempt is consistent with the intent declared (for example, attempting to read from a scratch tape would not be appropriate, nor would attempting to write to an input tape). If the access is not consistent with the intent, reject the access. For output operations, confirm that the tape is in scratch status or positioned beyond the last file. If not, reject the request. For input operations, confirm that the tape mounted is the correct tape by verifying the following information, which is extracted from the environment of the user attempting the access request, the mount command, and the Tape Management database: Based on file name and the optional VOLSER and version number arguments of the mount command, extract from the Tape Management database the VOLSER of the volume that matches this request. Confirm that the correct volume is mounted (determined by reading the VOL1 label). Confirm that the file name in the HDR1 label (extracted from the volume) matches the information in the Tape Management database (to protect against the possibility that two or more volumes may have the same VOLSER written to their respective volume labels). Confirm that the login ID of the user attempting to access this tape file (extracted from the user environment) is the same as the login ID of the user who created the tape file (extracted from the Tape Management database). Note: This final check can be suppressed by specifying the ID of the user who created the tape file with the mount command operand, by_owner.
Tape Management
1111
Retain Tape Files
Retain Tape Files

How long a tape file is retained depends on the type of retention criteria you specify. Retention criteria can take several forms, as Unicenter NSM can be instructed to do the following:

Retain a tape file a specific number of days. Retain a specific number of versions of a tape file. Retain a tape file a specific number of years. Retain a tape file perpetually.
When the retention criteria are met, the tape file is said to have expired. When all the files in a given volume set have expired, that volume set becomes eligible for scratch status. Note: A Tape Management resident tape does not enter scratch status automatically. It is redesignated as a scratch tape when the tms_scratch shell script is executed. For more information on the tms_scratch shell script, see the section, Customize the Daily Processing Cycle, presented later in this chapter.
Assign Tape Drives

Using the catape utility mount command is quite straightforward, but some operations require more flexibility. One of the operands required in the mount command is the name of the tape drive the requester intends to use. At smaller sites that have only one tape drive, having to explicitly identify that drive in a mount command is not a problem. In larger shops that have many tape drives, having to explicitly identify the name of the tape drive a volume is mounted on presents a real challenge. To address this issue, many sites either develop customized shell scripts that request the name of the tape device from the operator through the Event Console Log, or use automatic volume recognition (AVR) to dynamically extract the name of the required device from the environment. The following sections discuss these techniques in more detail:

Defining Eligible Devices for Automatic Volume Recognition (AVR) Displaying Tape Device Status
1112
Administrator Guide
Assign Tape Drives
Defining Eligible Devices for Automatic Volume Recognition (AVR)

One shortcoming of the operator assigning tape devices is that it requires that the operator keep track of available drives and the volumes that are mounted on those devices, and coordinate operations accordingly. The automatic volume recognition (AVR) feature of Tape Management relieves operations personnel of this task. AVR automatically assigns tape drives to applications that request them through use of the catape utility mount command. The device table, also referred to as the devtab file, defines the storage devices used by AVR. The default devtab file contains only one tape drive entry. If you have multiple tape drives, you will need to edit this configuration file to add definitions for your other devices. We recommend that you make all of your tape drives available to Tape Management by editing and saving the file. Operator Assignment of Tape Devices The smplmntscratch shell script (included as file $CAIGLBL0000/tape/scripts/smplmntscratch) sends a console message to the operator, asking that a scratch tape be mounted on a tape drive. The process waits for the operator to respond to the request with the name of the device containing the mounted scratch tape, and then issues the mount command with the name of that device. One of the features of Unicenter NSM makes it possible for the operator to respond to the request with the reserved word, AVR, which causes Tape Management to automatically search for and assign the appropriate volume/device.
Tape Management
1113
Assign Tape Drives
Automatic Assignment of Tape Devices Using AVR An alternative to specifying a device name with the mount command is to specify the reserved word, AVR in place of the device name, which causes Tape Management to automatically assign the proper drive to the requesting process. Upon execution of any mount command specifying AVR as the device name, AVR automatically scans all locally attached tape drives that are AVR-eligible (as defined in the Unicenter NSM configuration file, $CAIGLBL0000/tape/config/devtab) and which are not already assigned to other processes, and evaluates those drives to determine:

The identity of the currently mounted volume The status of the currently mounted volume Whether any mounted volume meets the requirements specified in the mount command request
Using AVR for Output Processing In the following example, the catape utility mount command instructs Tape Management to find an available tape drive with a scratch tape mounted.
catape mount AVR myfile volser=SCRATCH
AVR scans all locally attached tape devices that are AVR-eligible (as defined in the Unicenter NSM configuration file $CAIGLBL0000/tape/config/devtab) and are not already assigned to other processes. When the mount locates an available device, it automatically determines if a scratch tape is mounted in that device and, if so, reserves that device for use by the requesting process. AVR returns the AVR070 message to indicate the identity of the drive used. When myfile (named in the previous example) is written to the assigned tape device, the Tape Management database is updated automatically to indicate that the volume on that drive is no longer in scratch status and now contains the latest version of myfile.
1114
Administrator Guide
Assign Tape Drives
Using AVR for Input Processing In the following example, the catape utility mount command instructs AVR to search the Tape Management database to determine the VOLSER of the volume containing the most current version of the file, myfile.
catape mount AVR myfile returnfile=/tmp/devname.$$
Once AVR knows the VOLSER, it scans all locally attached tape devices that are AVR-eligible (as defined in the Unicenter NSM configuration file $CAIGLBL0000/tape/config/devtab) and are not already assigned to other processes. If it finds that volume mounted, it automatically reserves that device for the requesting process and writes the name of the reserved tape device into the specified file, /tmp/devname.$$. If the AVR scan does not find the required volume already mounted, it automatically prompts the Unicenter Console, asking the operator to mount the required tape.
Displaying Tape Device Status

In response to requests from operations personnel using prior versions of Tape Management, the command, tapeavr_status is available which, when executed, displays to stdout a report on all tape devices that are available to AVR. The following is a sample of this report:
$tapeavr_status VOLSER SCR BOT ABC001 Y Y ABC002 Y Y $ WRP N N CLASS TYPE AVAIL MT 4MM Y MT 4MM Y END OF REPORT DEVICE (COMMENT) /dev/rmt/0mnb () /dev/rmt/1mnb ()
where: VOLSER Identifies the serial number of the volume mounted on this device. SCR Indicates whether the volume is a scratch (Y/N). BOT Indicates whether the volume is currently at beginning-of-tape, also referred to as load point or BOT (Y/N). WRP Indicates whether the volume is write-protected (Y/N).
Tape Management
1115
Reserve Tape Drives
TYPE Identifies the media type used. CLASS Identifies the class of this device (from the devtab file). AVAIL Indicates whether the device is currently available (Y/N). DEVICE Identifies the device name.
Reserve Tape Drives

Tape device reservation protects against conflicting device access and is accomplished using the catape utility mount command and the catapemnt command. These commands reserve a tape drive for explicit use by one process in a process family tree until that process family tree has finished using it. A process family tree is important because Tape Management must recognize the process parentage to determine whether an attempt to access a tape device is being made by the same user or job that reserved it. Tape Management uses two techniques to determine what constitutes a process family tree:
In those cases where the process family tree for a user is unique all the way back to init (the process from which all processes are created), Tape Management is able to recognize this and protect the tape properly. In other cases, however, several users may have a common ancestor in addition to init. For example, a Telnet user (coming in through Telnet) starts by running the inetd daemon (Internet manager), and then runs the Telnet daemon (Internets Telnet manager), which invokes the shell the user is actually running. This situation results in two users who both logged in through Telnet having a common ancestor of inetd, placing both of these processes (incorrectly) under the same process family tree.
To account for the second situation, Tape Management, through CAIENF, provides the enfcontrol 864 command, which groups inetd or any other direct descendants of the init process together, and avoids including them as the common ancestor of a process requesting tape device reservation or access.
1116
Administrator Guide
Implement Surrogate Tape Processing
The enfcontrol 864 command applies system-wide, affecting all tape devices on the system. The syntax is as follows:
where: 0 Includes all descendants of init in the tape process family tree. 1 Does not include the direct descendants of init in the tape process family tree.

Surrogate tape processing is a Tape Management feature that addresses the special device reservation requirements of jobs that process cooperatively, sharing device reservation and I/O access with long-running processes that require intermittent use of tape devices. Typically, the functions of Tape Management restrict access to a mounted tape device to those processes in the same process family tree as the process that mounted the volume (a process family tree is the list of ancestors of a process). The surrogate mount facility makes it possible to allow processes that are part of one process family tree to access tape devices that have been reserved (via a catapemnt command or catape utility mount command) by another process family tree. The following table describes the enfcontrol commands you can use to implement the surrogate mount facility: Command enfcontrol 378 device enfcontrol 379 device enfcontrol 862 {0|1} Description Enables surrogate tape processing for a specified tape device Disables surrogate tape processing for a specified tape device Defines whether to retain surrogate status or clear surrogate status after the completion of the tape process Requires system operator verification before a tape device can be acquired by a surrogate
Each enfcontrol command is explained in detail in the sections that follow.
Tape Management
1117
Enabling Surrogate Mounts

The following enfcontrol command declares a tape drive eligible for surrogate tape processing:
enfcontrol 378 device
This command informs Tape Management that the tape device named by device is eligible for acquisition by another process that is not part of the process family tree that initially reserved the tape drive. Note: The tape device represented by device must have been previously reserved by this process/process family tree through the catapemnt command or catape utility mount command. For example:
catape mount /dev/rmt/tx0 abcfile volser=SCRATCH disp=DISM enfcontrol 378 /dev/rmt/tx0
Disabling Surrogate Mounts

Disabling a surrogate mount assumes you have previously issued the catape utility mount and enfcontrol 378 commands. To revoke surrogate mount eligibility, enter the following enfcontrol command:
enfcontrol 379 device
This command informs Tape Management that the tape device identified by device is no longer eligible for acquisition by another process that is not part of the process family tree that reserved this tape drive. Note: The tape device identified by device must have been previously reserved by this process/process family tree through the catapemnt command or catape utility mount command. For example:
enfcontrol 379 /dev/rmt/tx0
Retaining Surrogate Status

The enfcontrol 862 command specifies whether tape devices declared as eligible for surrogate tape processing should retain this eligibility after they have been accessed and the tape device closed.
1118
Administrator Guide
To specify the duration of surrogate processing eligibility for all tape devices, enter the enfcontrol command as follows:
where: 0 Maintains surrogate eligibility after I/O to the tape device completes and the tape device is closed. 1 Revokes surrogate eligibility after I/O to the tape device completes and the tape device is closed. If the enfcontrol operand is set to 0, all surrogate tape devices remain eligible for surrogate processing even after the device is closed. If the enfcontrol operand is set to 1, the device is no longer considered eligible for surrogate processing after the tape device is closed.
Requiring Operator Verification

The enfcontrol 863 command validates the acquisition and use of a tape device that has been declared surrogate-eligible by the system operator. This setting is for all tape devices on the system. The syntax is as follows:
where: 0 Indicates that no prompts appear on the console during a surrogate mount access. 1 Sends a prompt to the console during a surrogate mount access to validate the device acquisition.
Tape Management
1119
Regulate Trusted Offenders
Example
enfcontrol 863 1
The message prompt that is sent to the console is as follows: CAIENF_I_SURROGATE: ALLOW (Y/N) dev device name PROGRAM program name where: device name Specifies the name of the tape device driver. program name Specifies the name of the program attempting to access the device.
Tip: For those sites that want to send these event messages to the Event Console Log as an audit trail but also want the message to be responded to automatically in the affirmative, we recommend automating the response. Use the Event Management component to define a Message Record profile and subordinate Message Action profiles to automate the response.
Regulate Trusted Offenders

By default, Tape Management (through CAIENF) blocks all inappropriate tape access. Determining what constitutes inappropriate access is done by Tape Management's evaluation by a strict set of rules. In many situations, you may need to make exceptions to these rules. Trusted offender support is provided to enable operations personnel to participate in the decision to block (deny) the access attempt. The following choices are available:
Operator DENY and ALLOW
Using the Event Management MSGRECORD and MSGACTION objects, you can delete the existing TMS035 Tape Violations message record and message action. The absence of the message forces the operator to respond to each violation by either denying or allowing the violation. Using the Event Management MSGRECORD and MSGACTION objects, you can define a more specific message by including in the TMS035 Tape Violations message text a user ID or program name. You can then define the message action to either DENY or ALLOW the violation, based on criteria specified in the message.
Selective DENY or ALLOW
1120
Administrator Guide
Process Unlabeled Tapes

Unlabeled resident volumes have volume records defined in the Tape Management database and typically have external labels, but they do not have the internal labels (the VOL1 and HDR1 files) that allow Tape Management to verify the identity of a volume. Since they are marked with external labels only, integrity checks performed by Tape Management are limited to verification prompts that require confirmation from the operator that the correct volume is mounted. Important! Tape Management provides unlabeled tape processing only to accommodate sites that require some measure of unlabeled tape support for previously created tapes. Since Unicenter NSM is completely dependent upon operator responses to identify unlabeled tapes, there is no way to confirm the identity of an unlabeled tape.
Enabling Unlabeled Tape Processing

Support for unlabeled tape processing is enabled during the installation process. Tape Management requires that only the Tape client be operational to process unlabeled tapes; the Tape server and database need not be operational. Your response to the following prompt during installation determines whether unlabeled tape processing is implemented: Do you want NON-Standard label support enabled? A response of NO causes Tape Management to treat unlabeled tapes as non-resident (unprotected). If you attempt to use an unlabeled tape, and the Tape server or database is not operational, you are allowed to proceed without interruption. A response of YES causes Tape Management to support unlabeled tapes and treat them as resident (protected). If you attempt to use an unlabeled tape, you are prompted for the VOLSER. If the Tape server or database is not operational, you are prompted with a message asking you whether you wish to terminate the process or continue.
Tape Management
1121
Accessing Unlabeled Resident Volumes

You declare your intent to use an unlabeled volume by specifying lbltype=nl as a catape utility mount command line operand. For example, the following mount command requests access to an unlabeled input tape on /dev/rmt/0m with an external volume label of nl0001. Enter the mount command as follows:
catape mount /dev/rmt/0m myfile volser=nl0001 \ lbltype=nl
Because a label type of NL (No Label) was specified (lbltype=nl), Tape Management determines that an unlabeled volume is required. When Tape Management recognizes a volume on the drive as unlabeled, it sends a message to the console asking the operator to verify and respond with the VOLSER of the mounted tape, based solely on the contents of the external tape label. If the VOLSER the operator responds with has a corresponding volume definition in the Tape Management database having a tape label type of NL, the volume is accepted and the rules for resident tape access apply. If the VOLSER the operator supplies does not have a corresponding volume record in the Tape Management database, or there is such a record but it does not have a label type of NL, the volume is rejected.
1122
Administrator Guide
Establish a Vault Storage System

Working in conjunction with Tape Management, Vault Management can coordinate the movement of critical volumes from one location to another and back into the data center. Typically, in a data center that utilizes off-site storage locations, critical volumes are cycled out of the central tape library to progressively more secure storage areas (vaults), and finally back into the central library. Under Vault Management, as volumes meet the vaulting criteria you have defined, they are automatically checked out of Tape Management with the proper vault code, and Vault Management generates reports indicating the current location and the destination to which the volumes must be moved. The Tape Management system maintains, in its catalog, information that describes the movement of volumes to and from such vaults or storage areas. Vault Management works with Tape Management to provide automatic control, rotation, slot number assignment, and reporting on vaulted volumes so that you can route these volumes to and from other storage locations and back to the data center, as necessary. Further, the criteria for holding tapes in vaults can be different for each file and for each vault. The following table describes important terms associated with Vault Management. Term Vault Slot Meaning A vault is any identifiable storage area or location that you define. Slots are created in a vault when a volume is vaulted. Each slot is used to store one volume. By default, there are unlimited slots in a vault, but a maximum can be designated when a vault is created. A schedule determines when a volume is placed in or removed from a vault. A rotation is used to move volumes, and is associated with a schedule. Each rotation you define points to a vault. A vault cycle is the actual movement of volumes. You must describe the vault, the volume, and the rules for volume movement under Tape Management by creating a Vault Criteria Descriptor (VCD) record. Vault Management uses this descriptive information to execute a vault cycle when movement is scheduled.
Schedule Rotation Vault cycle
Tape Management
1123
Term Reports
Meaning Each time a vault cycle is executed, two reports must be produced before another vault cycle can be initiated. These reports are the Shipping Report and Receiving Report, which provide a reliable record of the result of the cycle and the current location of your volumes. An Inventory Report is also available, which you can produce at any time.
Vault Creation
The first step in establishing a vaulting policy is to create a vault by describing it uniquely to Vault Management. You create a vault by defining the new vault using either the Unicenter GUI or the cautil command line interface. Each vault contains slots, and each slot in the vault stores one volume. A slot is created in a vault as part of moving a volume into the vault (also referred to as vaulting a volume). By default, a vault can contain an unlimited number of slots, but you can assign a maximum number of slots when you define the vault. See the instructions for creating vault definitions in the online CA Procedures under the topic, Creating a Vault.
Media Selection
You make assignments to vaults by specifying the vault rotation schedule that a tape-resident file will use. The name of the first file in a volume set becomes the controlling data set. When this data set is vaulted, the volume set on which it resides is placed in slots in that vault. Slot number assignment is based on the rotation records that belong to the rotation schedule selected, which are defined using either the Unicenter GUI or cautil. The number of rotations is limited to 9,999. When a volume comes under Vault Management control, Tape Management updates the volume's EDMID (External Data Manager ID) to VMS (Vault Management System), and records the old EDMID as the previous EDMID. To prevent a volume from being used while under Vault Management control, the volume is automatically checked out, and the location is updated to reflect this. In addition to the controlling data set name, Tape Management uses the creating program name and the FABORT flag to select volumes to be vaulted.
1124
Administrator Guide
Scheduled Media Movement

Generating reports that detail the volume movement requirements and update locality information is accomplished by executing the cycle vault command process. After the volume sets to be vaulted have been selected according to the VCD record information, and the required temporary slots generated, the vaulting rotation process begins. The slots that already contain volumes and the new slots to be vaulted are grouped together by their common schedule. They are sorted in the order of their creation dates, newest to oldest. Beginning with the first rotation in the schedule, volume sets are assigned to a vault and slots based on the expiration criteria. When the first rotation is satisfied, the next rotation in the schedule is processed, and so on through the entire schedule until all rotations have been exhausted. Any volume sets that remain unvaulted are returned to Tape Management.
Special Media Movement

Special movement between Vault Management and Tape Management is either temporary or permanent. As examples, you would use temporary movement when you wanted to restore a file from one of the vaulted volumes, but then return it to the vault when done. You would use permanent movement when you wanted to pull a volume from the vault and not return it; this volume would then not be available for vaulting until it assumes scratch status and is reused.
Temporary Movement
Since all volumes that are vaulted are in checked out status, those volumes will need to be checked in to Tape Management before they can be used. When you have finished using the volume, it will again be checked out and returned to the vault. Note: A temporary movement will be automatically escalated to a permanent movement if the volume remains checked in for one entire vault cycle. That is, its slot will be deleted, and the EDMID will be restored.
Permanent Movement
For permanent movement, the slots are unvaulted. The unvaulting process performs a checkin of the volume, removes the associated slot, and restores the EDMID. The volume will not be eligible for vaulting until it has reached scratch status and been reused, at which time it can be vaulted again if its new data meet the requirements for vaulting.
Tape Management
1125
Physical Movement and Inventory Tracking

Although updating the volume location information in the database is automated, the physical movement of volumes is done manually. In addition to the Tape Management inventory tracking reports generated as part of daily program execution (see the section Report on Tape Activity presented later in this chapter), Vault Management further provides the following reports:
The Shipping Report contains a list of volumes to be pulled from each of the vaults. The Receiving Report contains a list of volumes to be distributed to the vaults. The Inventory Report lists volumes grouped by vault and sorted by slot number within the vault where they reside.
Since the Inventory Report is built from information contained in the Slot table, you can produce an Inventory Report at any time. The Shipping and Receiving Reports are built from the movement records generated during a vaulting cycle, and must be produced using a cautil list vault command after each cycle vault command process has completed. The Vault Selection Listing is produced each time the cycle vault command is executed. For each VCD processed, this list identifies the first volume in the volume set and the controlling data set. This information is provided for all volume sets selected for the vaulting cycle. Special Handling During Volume Movement Vault Management provides the vault_exit facility, which you may use to perform special handling during the execution of a cycle vault command process to trigger an action. Using this facility, you can write a shell script or executable that will be called each time a volume is moved as part of a cycle vault command process. You can, for example, send a message to the Event Console Log that notifies the operator of a further consideration for a specific volume. To be called, your executable must be named vault_exit, and it must reside in any directory within the search path ($PATH). The exit is processed once for each volume moved into or out of a vault when the cycle vault command is executed.
1126
Administrator Guide
Vault_exit, when called, is passed the following command line arguments in the order shown:
vault_exit <currentvaultname> <currentslot> <fstvol> <volser> <mediaclass> <mediatype> <newvaultname> <newslot>
where:
currentvaultname
Identifies the current vault name, 1-20 alphanumeric characters.

currentslot
Identifies the current slot, 1-6 numeric characters.

fstvol
Identifies the volume set, 1-6 alphanumeric characters. This is the FSTVOL field used by Tape Management.
volser
Identifies the volume serial number, 1-6 alphanumeric characters.

mediaclass
Identifies the device type defined for Tape Management. The following media class is valid: MT Magnetic tape (9tk, 8mm, 4mm, CART, 3480)
mediatype
Identifies the media type used by Tape Management. Any of the following media types are valid: 9TK 9tk tape 8MM 8mm cartridge 4MM 4mm DAT tape CART 1/4 inch cartridge tape (QIC) 3480 3480 cartridge
newvaultname
Identifies the new vault, 1-20 alphanumeric characters.

newslot
Identifies the new slot, 1-6 numeric characters.
Tape Management
1127
Schedule Volume Movement
Audit Trails
Vault Management records the creation date, time, and user, as well as the last modified date, time, and user, for a file. The Movement file contains a history of the most recent slot movements for a vault cycle.
Schedule Volume Movement

Vault Management relies upon a user-defined rotation policy to determine when and where tape volumes are to be moved. You can define your rotation policies using the define rotation control statement through the cautil command line reference. See the instructions for creating rotation definitions in the online CA Procedures under the topic, Defining the Rotation.
Select the Media

To describe the rules for media selection, you must create a Vault Criteria Descriptor (VCD) record under Tape Management. You can define your VCD record using the define vcd control statement through the cautil command line interface. See the instructions for creating VCD records in the online CA Procedures under the topic, Creating VCD Records.
Move Volumes Into/Out of a Vault

The cycle vault command process updates the location information for a volume set, indicating movement into a vault or from a vault back to the Tape Management database. You can initiate the process by issuing the command, cycle vault, from the cautil command line. Slots are automatically created and volumes automatically vaulted during this process. The cycle vault command can be used with the optional SIMULATE operand to produce a Shipping Report. You can use the SIMULATE operand at any time to predict how many volumes will be moved without actually updating the location information. For instructions on how to execute the cycle vault command, see the online CA Reference.
1128
Administrator Guide
View Slot Storage for a Volume Set
View Slot Storage for a Volume Set

Vault Management provides the facility to display the slot contents for any vaulted volume set of your choosing. This view provides the following information:

Media type and class Rotation schedule and sequence Current vault Previous data manager Volume serial number and current slot number occupied Previous vault and slot
Because slots are automatically created when a volume is vaulted, you typically have no reason to update slot information. However, should you need to do so, use the cautil command, alter slot. See the online CA Reference for instructions on how to execute the alter slot command. See the instructions for viewing slot storage in the online CA Procedures under the topic, Viewing Slot Storage for a Volume Set.
Customize the Daily Processing Cycle

As you begin to use Tape Management in a production mode, you must perform certain tasks on a regular basis, preferably daily. These tasks include backing up the Tape Management database, scratching tapes, and generating reports. Unicenter NSM provides the following five sample shell scripts (found in the directory $CAIGLBL0000/tape/scripts) to assist you in accomplishing these maintenance tasks:

tms_daily (which calls the other four shell scripts) tms_db_backup tms_scratch tms_report report.vars
To ensure the continued reliable operation of Tape Management, we strongly recommend that you execute the tms_daily procedure daily.
Tape Management
1129
Report on Tape Activity
The most important task performed by the tms_daily script is the tms_db_backup procedure. The tms_db_backup procedure does the following:

Produces a current backup of the Tape Management database. Clears the Tape Management journal of all transactions logged since the last tms_db_backup.
The tms_db_backup procedure can also be executed outside of the tms_daily shell script, and should be executed whenever the Tape Management journal file reaches capacity to quickly clear that journal and resume processing. Whenever the Tape Management journal reaches capacity, the following error message displays on the Event Console Log:
CAI_F_DB_045 The Database Journal File is Full
You should run tms_db_backup as soon as possible after the message is issued, and we recommend you consider automating the execution of the tms_db_backup script in response to this message being issued, through definition of Event Management message records and message actions.

Tape Management reports provide information about error statistics, media usage, and scratch availability. You produce the following reports automatically when you execute the tms_daily shell script:
The Scratch and Clean Listing identifies scratch tapes that should be pulled from the tape library and placed in the scratch pool. The File Name Master provides an inventory of all tape files currently defined in the database. The Volume Serial Master provides an inventory of all volumes in the database. The Volume Set Master provides an inventory of all volume sets in the database.
Generating the Scratch and Clean Listing

You can also use the catape utility dbscratch command to generate the Scratch and Clean Listing and any of its optional auxiliary reports without running the entire tms_daily shell script. For more information on the dbscratch command, see the online CA Reference.
1130
Administrator Guide
Tip: You can project scratch availability by running the Scratch and Clean Listing with a date set several days, or even weeks, into the future. This gives you a reasonably accurate picture of future tape availability. While retention, such as cycle control, cannot be reflected in this report (this report works primarily from expiration dates), it provides a basis by which you can predict any needs for purchasing additional tapes, or perhaps adjust retention criteria to make additional tapes available earlier.
Generating the Auxiliary Reports You can produce optional auxiliary reports when you generate the Scratch and Clean Listing. The auxiliary reports provide consolidated listings of the scratch volumes that require special attention. These auxiliary reports include the following:
The Pull List identifies volumes in scratch status that you may pull from the tape library and place in the scratch pool. The Clean List identifies volumes in scratch status that must be pulled and cleaned before being placed in the scratch pool. The Erase List identifies volumes in scratch status that must be pulled and erased before being placed in the scratch pool. The Replace List identifies volumes in scratch status that must be pulled and replaced. Replace thresholds are based on age and error counts that you pre-define.
To produce these auxiliary reports as part of the daily batch processing cycle, customize the tms_scratch shell script to specify a dbscratch control statement containing the REPORT operand. For details, see the dbscratch command in the online CA Reference.
Tape Management
1131
Printing an Earlier Vault Report

Vault Management provides the prev_vreport shell script for your use in reprinting a vault report from a previous vault cycle process. The reports are stored as .rdw files in the directory named $CAIGLBL0000/tape/vault_repts. Each .rdw file is created during the initial generation of each report, that is, as the result of a LIST VAULT control statement that specifies a report operand. You may want to periodically remove or archive these files. To reprint a report, run the following command:
$CAIGLBL0000/tape/scripts/prev_vreport type_vault_pid.rdw
where:
type
Specifies the type of report: inventory, shipping, receiving.

vault
Specifies the vault name.

pid
Specifies the creating process ID (applied for uniqueness). The report will be directed to stdout, which can be redirected.
1132
Administrator Guide
Change System Options

You must set the Tape Management system options to customize your tape processing environment. These options identify the date format, the default retention and cycling criteria, the company name for reports, and the resolutions for label, density, and expiration conflicts. The initial values set during installation remain in effect until you supply new values. You can set new values at any time by executing the tms_options shell script located in the directory $CAIGLBL0000/tape/scripts. Use the following table to survey the system options and identify those that you should modify to meet your processing requirements: Option
ABE
Description Defines the abend retention period for all volume sets that go through tape dismount with an OPEN file and for any file that is closed due to a crash. Acceptable values are CYCLE/nnn, LDATE/nnn, PERM, RETPD/nnn, and RETPY/nnn. (See the section Retention Values for System Options following this table.) Determines whether versions of a file created the same day are to be treated as a single cycle or as separate cycles. Acceptable values are Y (treat all versions of a file created the same day as a single cycle) and N (treat every version of a file, regardless of the creation date, as a separate cycle). Determines whether cycles are to be qualified by file name, user, and creating job name or by file name and user. Acceptable values are Y (qualify each cycle by file name, user, and creating job name) and N (qualify each cycle by file name and user). Defines the company name to appear on all reports. Use single quotation marks (preferred) or double quotation marks as delimiters when the name contains blanks. Determines whether cycles are to be qualified by file name and creating login ID or by file name. Acceptable values are Y (qualify each cycle by file name and creating login ID) and N (qualify each cycle by file name). Determines how external dates are to be entered, printed, and displayed. Determines whether density changes are allowed on a volume. Acceptable values are Y (allow density changes) and N (disallow density changes).
CDAY
CJOB
COMPANY
CUSER
DATEFMT DCHG
Tape Management
1133
Option
GUMLABEL
Description Determines whether gummed labels are printed at CLOSE or EOV for output tapes. Acceptable values are Y (print gummed labels automatically) and N (suppress the automatic printing of gummed labels). Sets retention when a scratch tape controlled by the Tape Management function is used as input after being returned from an off-site location. Acceptable values are CYCLE/nnn, LDATE/nnn, PERM, RETPD/nnn, and RETPY/nnn. (See the section Retention Values for System Options following this table.) Determines whether an unlabeled tape can be mounted for a structured tape request and whether a structured tape can be mounted for an unstructured tape request. Acceptable values are Y (allow label changes) and N (do not allow label changes). Determines whether a volume set can have mixed (different) types of expiration dates when new files are added to the volume set. This option serves as a precaution against attempts to apply different types of retention to various files within the same volume set. Acceptable values are L (log the incident and process the request), W (send a warning message to the operator and process the request), and D (disallow this request). Specifies the number of days that a volume set under cycle control is kept after it expires. This additional number of days is the cycle extension. Defines the default retention period for all files and volume sets created without specific retention. Acceptable values are CYCLE/nnn, LDATE/nnn, PERM, RETPD/nnn, and RETPY/nnn. (See the section Retention Values for System Options following this table.) The initial value is five days.
KEYTAPE
LCHG
MIXEXP
RCYCDAYS
RPERIOD
1134
Administrator Guide
Retention Values for System Options The following table describes the acceptable parameters for the ABE, KEYTAPE, and RPERIOD options: Retention Value CYCLE/nnn LDATE/nnn Description nnn versions of this tape file are retained, where nnn is a positive integer in the range 001-099. This tape fileversion is retained for nnn days past the last date on which it is used, where nnn is a positive integer in the range 001-999. This tape fileversion never expires. It is permanently retained. This tape fileversion is retained for nnn days after the date on which it is created, where nnn is a positive integer in the range 001-999. This tape fileversion is retained for nnn years after the date on which it is created, where nnn is a positive integer in the range 001-999.
PERM RETPD/nnn
RETPY/nnn
Tape Management
1135
Chapter
12
Storage Management
Storage Management is made up of the following two components:
BrightStor ARCserve 2000 Backup for Windows--Unicenter Edition is the backup and restore management solution for the local Windows host server. BrightStor ARCserve Backup for UNIX/Linux--Unicenter Edition is the backup and restore management solution for the local UNIX/Linux host server. This component provides a BrightStor ARCserve Backup Java Manager to administer the UNIX/Linux-based BrightStor ARCserve Backup server through Netscape or Internet Explorer browsers.
This chapter describes the features and functions of BrightStor ARCserve Backup, and includes detailed information on the following:
What you need to know to perform a backup of your data, including descriptions of different backup methods All restore functions, from restoring a single file to recovering from a network failure
BrightStor ARCserve Backup is fully integrated with Windows through shell extensions:
Context Menu Handler: Perform instant backup of drives from context menu simply by right-clicking on drives. Submit pre-saved jobs from context menu item by right clicking on job scripts. Icon Handler: Display a different icon for each job type for BrightStor ARCserve Backup job scripts. Property Sheet Handler: Display BrightStor ARCserve Backup status on properties of drives. Display job information from properties of job scripts.
Storage Management
121
Features
Features
Web-Based Access to All BrightStor ARCserve Backup Manager Windows: On the UNIX/Linux platform, the BrightStor ARCserve Backup Manager consists of a Java Applet providing access to the local BrightStor ARCserve Backup server. Once connected to a BrightStor ARCserve Backup web server, the BrightStor ARCserve Backup Manager is displayed. The BrightStor ARCserve Backup Manager window can then be accessed to allow backup, restore, and other management tasks to be performed. Easy-to-Use GUI Interface: BrightStor ARCserve Backup administrators can use a graphical interface to perform administration and job management functions. Explorer-like tree view, property dialog, drag-and-drop, and right-mouse click integrate with Windows interface designs. You can configure and save column list display, and column list layout (width, position, ordering, display order). Windows Registry Backup: You can partially or fully back up your Windows registry entries to the key level as a separate media session. ODBC Database Support: BrightStor ARCserve Backup supports ODBC (SQL) database formats to use as its main database system. Event-Driven Notification System: The Alert notification system informs you of key events in your operations. Alert notifications can be used for specific non-job related events, such as the tape or database engine starting, error messages, or other events viewed through the Activity log. Virus Scanning: You can automatically scan for viruses during a backup, copy, or count operation. Cyclic Redundancy Check (CRC) Verification Support: When you back up your data, you can verify the individual data packets with CRC verification. This prevents data corruption by generating a numeric value for each packet, then checking that value against the data on the media. Bit-By-Bit Verification Support: BrightStor ARCserve Backup on UNIX/Linux utilizes bit-by-bit data verification. Intelligent Data Compression: You can use the intelligence of BrightStor ARCserve Backup to compress data if the tape drive does not support compression, or the hardware compression is disabled. Device Configuration: BrightStor ARCserve Backup supports various media, including 4mm, 8mm, and DLT.
122
Administrator Guide
Features
BrightStor ARCserve Backup for Windows also supports removable optical drives, Iomegas Zip or Jazz media, PDS, MO, and QIC formats. You can configure the following types of backup devices: tape, optical, or removable device. Encryption Support: You can encrypt all BrightStor ARCserve Backup jobs with a session/encryption password to enhance network security. Automatic Media Rotation Scheme: You can schedule repetitive backup jobs that are customized for your environment. BrightStor ARCserve Backup uses an automatic rotation scheme, which can be a simple rotation or a Grandfather-Father-Son (GFS) rotation. BrightStor ARCserve Backup Job Queue Security: You can restrict access to the BrightStor ARCserve Backup job queue by granting varying security permissions to different user/group identities for the job queue. Jobstatus Command Line Program: Using the jobstatus.exe command line program, you can monitor BrightStor ARCserve Backup job functions. Preferred Machine Configuration: You can configure all volumes of a specific machine as a share using the BrightStor ARCserve Backup browser. The share will be displayed under the Preferred Shares node of the BrightStor ARCserve Backup browser. Intelligent Restore: You can quickly locate and restore your archive data using the BrightStor ARCserve Backup database system. You can also restore data that was backed up under a previous version of Unicenter Automated Storage Management (ASM). Detailed Report Generator: The administrator can view and print BrightStor ARCserve Backup job histories and activities. User-Defined Scripts: You can configure reusable scripts to perform specific BrightStor ARCserve Backup tasks. Pre/Post Commands Based on Job Status: BrightStor ARCserve Backup contains conditional pre-execution, job execution, and post-execution based on previous results (exit codes). Pre- and post-execution is not only supported for before or after job execution, but also before or after execution on machines. You can elect to run or not run a command if a job fails, is completed, or is not completed. For instance, you can run a detailed report on a job if it fails.
Storage Management
123
Management Functions
ARCbatch Utility: With the BrightStor ARCserve Backup job utility you can submit, delete, or modify the execution time for jobs in local or remote BrightStor ARCserve Backup job queues from the command prompt (Console mode). You can use a job script created in the BrightStor ARCserve Backup Manager or in a text file using the ARCbatch Job Information Template in the arcbatch.wri file, which is located in the BrightStor ARCserve Backup home directory. Command Line Component: This component provides direct control over all operations that can be performed by a BrightStor ARCserve Backup server using the UNIX/Linux prompt. Using BrightStor ARCserve Backups command line utilities provides an alternative method of accessing almost all of the operations available from the BrightStor ARCserve Backup UNIX/Linux manager. Unicenter Tape Management Mode: BrightStor ARCserve Backup media is managed and protected by a centralized Unicenter NSM database. This database keeps track of media using the volume serial number. Device sharing is included. Built-in Tape Library Support: BrightStor ARCserve Backup is designed to support a tape library including a single changer with one device drive operating with 20 slots or less. Parallel Streaming: You can submit jobs concurrently when using multiple storage devices.
The following paragraphs describe the management functions of the BrightStor ARCserve Backup product: Backup Activates the Backup Manager so that you can schedule and submit jobs to back up your machines. Backup lets you perform a complete system backup of all machines. BrightStor ARCserve Backup can back up a servers system information, such as the Windows registry. You can submit a large backup job to automatically span multiple media until the job is complete. Lets you restore data previously backed up by BrightStor ARCserve Backup.
Restore
124
Administrator Guide
Backup
Activates the Backup Manager so that you can schedule and submit jobs to back up your machines. Backup lets you perform a complete system backup of all machines. BrightStor ARCserve Backup can back up a servers system information, such as the Windows registry. You can submit a large backup job to automatically span multiple media until the job is complete. Lets you create and maintain media pools for a logical grouping of media. This lets you efficiently schedule the maintenance and recycling of your media. The BrightStor ARCserve Backup administrator can design specific media rotation schemes to suit particular archive needs. BrightStor ARCserve Backup employs either the Simple Rotation or the Grandfather-Father-Son Rotation scheme to make scheduling easier. You can produce reports detailing media information for media pools used in your rotation schemes, including media status and session information. Lets you monitor all pending, completed, and active jobs from the Job Status Manager window. You can reschedule pending or completed jobs, submit new jobs, delete jobs, and stop active jobs. Log information is provided for each completed job. Lets you view information about your storage devices and media, change a drives compression mode, and perform media maintenance functions, such as formatting, erasing, and retensioning a cartridge tape. You can assign volume serial numbers to media to help manage your rotations. Lets you view information from the BrightStor ARCserve Backup database, such as the jobs processed by BrightStor ARCserve Backup, the media used by BrightStor ARCserve Backup, and the devices you are using with BrightStor ARCserve Backup. Reports are generated from the database. Lets you keep up-to-date on BrightStor ARCserve Backup activity. For example, the Activity Log gives you information about the jobs performed by BrightStor ARCserve Backup. Other reports help you keep track of media usage, and Rotation and GFS activity. Lets the BrightStor ARCserve Backup root user customize user access to BrightStor ARCserve Backup based on the privileges assigned to a specified group. Scans media for session information. You can scan a single session or the entire media. Results of the media scan can be viewed in the Report Manager under the Activity Log listing, or under the User Log listing if an additional log file is created.
Media Pool
Job Status
Device Manager
Database
Report
Profile Manager Scan
Storage Management
125
Wizards
Backup
Activates the Backup Manager so that you can schedule and submit jobs to back up your machines. Backup lets you perform a complete system backup of all machines. BrightStor ARCserve Backup can back up a servers system information, such as the Windows registry. You can submit a large backup job to automatically span multiple media until the job is complete. Merges information from media into the BrightStor ARCserve Backup database. The database information from the media will be appended to your existing database files. You can use the Merge utility if you need to restore files to a BrightStor ARCserve Backup host that you did not use to create the backup. Contains various utilities such as Database Recovery, Purge, Copy, Count, and Compare are available.
Merge
Utilities
Wizards
Similar to other wizard software, the BrightStor ARCserve Backup wizards take you step-by-step through the completion of a specific task. BrightStor ARCserve Backup provides the following wizards: Backup wizard--Takes you step-by-step from initial target selection to scheduling a job. Restore wizard--Restores data from media to a specified destination. You can restore by session or by querying for the specific data. Device wizard--Simplifies the task of formatting, erasing, re-tensioning, compressing, and ejecting the storage media. Disaster Recovery wizard--Lets you create local or remote boot disks and backup multiple databases using step-by-step procedures. This wizard is enabled only if you have purchased and are using the Unicenter NSM option, Advanced Storage Option (ASO).
126
Administrator Guide
Components
Components
BrightStor ARCserve Backup consists of two primary components that work together to back up, copy, and restore your data. The components are:

BrightStor ARCserve Backup Manager BrightStor ARCserve Backup Server
BrightStor ARCserve Backup Manager

The BrightStor ARCserve Backup Manager lets you control all operations of BrightStor ARCserve Backup from a single machine. Use the BrightStor ARCserve Backup Manager to submit your backup and restore jobs, manage your database, and produce reports, and so forth. You can use either the Backup or Restore wizard. Each offers you an automated service to perform your task. With either wizard, you are able to submit a job to the BrightStor ARCserve Backup job queue without running the BrightStor ARCserve Backup Manager. You can customize your job by specifying options, filters, and scheduling information. The BrightStor ARCserve Backup UNIX/Linux Manager includes Java classes, icons, images, and the httpd daemon and communicator program, which function as an information bridge between the browser and back-end services.
BrightStor ARCserve Backup Server

The BrightStor ARCserve Backup Server directly manages all data operations, such as backup and restore procedures, and controlling the Job, Tape, and Database Engines. BrightStor ARCserve Backup Server Admin for Windows The BrightStor ARCserve Backup Server Admin for Windows directly manages the backup procedure, controlling the Job, Tape, and Database Engines.
The Job Engine is responsible for processing your jobs at their designated date and time. It scans the job queue, and when it finds a job that is ready to be executed, the Job Engine sends it to the appropriate handler. The Tape Engine is responsible for communicating with and controlling your storage devices, such as tape and optical drives. When a storage device is needed for a BrightStor ARCserve Backup job, the Tape Engine selects the device.
Storage Management
127
Components
The Database Engine is responsible for maintaining a history of the following: Files, directories, drives, and machines that BrightStor ARCserve Backup has backed up or copied. Information about jobs that have been processed by BrightStor ARCserve Backup, such as the job type, logs, the final result, the start and end time, and so forth. Media used by BrightStor ARCserve Backup, such as its name, the date it was first formatted, the date it expires, the sessions on it, and so forth. By default, all operations within BrightStor ARCserve Backup are recorded by the Database Engine.
BrightStor ARCserve Backup Server for UNIX/Linux The BrightStor ARCserve Backup UNIX/Linux Server runs on a UNIX/Linux file server and consists of back-end daemons that process all jobs. BrightStor ARCserve Backup UNIX/Linux Server updates information about these jobs in the BrightStor ARCserve Backup activity logs and database. The BrightStor ARCserve Backup UNIX/Linux Server contains the following back-end services:
Discovery Service (asdiscovd)--Collects and maintains information on the availability of the BrightStor ARCserve Backup servers on the network, and supplies this information to clients that request access to BrightStor ARCserve Backup resources. In addition, it also maintains BrightStor ARCserve Backup user information obtained from the BrightStor ARCserve Backup servers on the network. BrightStor ARCserve Backup Loader (ARCserve Backupd--Loads and unloads all BrightStor ARCserve Backup services. Authentication Service (asauthd)--Provides a centralized point of control for security issues concerning the entire network of resources made available by BrightStor ARCserve Backup for UNIX/Linux. It verifies and controls the actions performed on BrightStor ARCserve Backup resources using a predefined set of privileges (permissions). Scheduler (asqd)--Manages the jobs that are scheduled through the BrightStor ARCserve Backup Manager or command line. Media Server (asmediad)--Handles the transfer of data, to and from media. Database Server (asdbd)--Keeps track of the jobs run, and all of the files backed up or restored by BrightStor ARCserve Backup. Event Logger (asloggerd--Handles message logging and message retrieving. Broadcasts messages to numerous destinations, such as a printer, fax machine, a beeper, a file, an SNMP console, or a Unicenter Console.
128
Administrator Guide
Components
The Client Agent for UNIX/Linux
The Client Agent for UNIX/Linux enables the directory structure of a UNIX/Linux machine to be browsed, in addition to handling the transfer of data. It is a required module on all target UNIX/Linux hosts.
Domains
To better manage the services running on each BrightStor ARCserve Backup server, one or more BrightStor ARCserve Backup servers can be configured to form a distinct group called a BrightStor ARCserve Backup domain. The BrightStor ARCserve Backup domain concept provides security and management of the entire BrightStor ARCserve Backup network. arcroot User Profile BrightStor ARCserve Backup includes the arcroot super user profile that is automatically assigned root privileges for all BrightStor ARCserve Backup functions. The password for the arcroot profile can be set during the setup of the program, or afterwards using the BrightStor ARCserve Backup Profile Manager. Additional BrightStor ARCserve Backup user profiles can be created (possessing their own set of rights) using the Profile Manager. Note: BrightStor ARCserve Backup user names control access only to BrightStor ARCserve Backup-related functions, and should not be confused with the operating system required login name and password. Identifying a Domain Each BrightStor ARCserve Backup domain is identified by the primary Discovery service. A single primary Discovery service is the common identifier for each machine selected to point to a particular domain. Therefore, all computers set to point to a particular primary Discovery Service should have the same domain name.
Storage Management
129
Perform Data Backup
Perform Data Backup

The backup tools provided in BrightStor ARCserve Backup have the following capabilities:

Backs up to various media or create a customized backup scheme. Uses filters to selectively exclude or include directories and files from backup jobs. Creates an automated backup scheme using the GFS rotation scheme. Applies backup options to local source objects (such as volumes and nodes), or globally to the entire backup job, or to both at the same time.
Selecting the Best Backup Scheme for Your Requirements

BrightStor ARCserve Backup provides the following backup schemes: Scheme Custom Rotation Description Runs a backup job once, or on a repeating basis. This scheme gives you the choice to use or not use media pools. Maintains a weekly rotation of media. A combination of three backup methods is used: full, differential, and incremental. This scheme requires media pool usage. Maintains a monthly rotation of media. A combination of three backup methods is used: full, differential, and incremental. This scheme requires media pool usage.
GFS Rotation
Determining Database Backup Sources

BrightStor ARCserve Backup on the Windows platform lets you back up your Windows computer using one of the following database sources:

The administrative shared drives The user-shared files, directories, and drives
In addition to creating default administrative shares, Windows lets you designate, as shareable, specific files and directories (user-shared drives and directories). These files and directories are displayed in the BrightStor ARCserve Backup Browser so that you can quickly select them for backup. You can back up (either fully or partially) the Windows registry for a Windows machine. Back up the registry as if it were any other directory. (You must enter security information for the computer to back up the registry information.)
1210
Administrator Guide
Perform Data Backup
You can use the Backup wizard to create and submit a backup job to the job queue without running the BrightStor ARCserve Backup Manager. See the instructions for using the Backup Wizard in the online CA Procedures.
Selecting the Backup Method

The backup method determines which files in a selected drive or directory are backed up. Before you decide which backup method to use, you should understand how BrightStor ARCserve Backup uses the archive bit for that specific backup process. A files archive bit is a marker that indicates whether the file has been modified. An archive bit that is set (turned on) indicates to BrightStor ARCserve Backup that the file has changed since it was last backed up. This table describes the various backup methods and indicates the archive bit setting for each one: Check Archive Bit? No Reset Archive Bit? No
Method Full (keep archive bit)
Files Included All source files
Description Backs up all the source files. This method does not change the archive bit. You can use this option if you want to perform an unscheduled full backup that will not affect your incremental or differential backups.
Full (clear archive bit) Incremental (clear archive bit)
All source files
Backs up all the source files. At the end of the No job, all files that have been backed up have their archive bits cleared. Backs up only files that have changed since the last full (clear archive bit) or incremental backup. BrightStor ARCserve Backup checks the files archive bit each time. If the archive bit is on, BrightStor ARCserve Backup backs up the file, then clears the archive bit. Backs up files that have been changed since the last full (clear archive bit) or incremental backup. BrightStor ARCserve Backup checks the files archive bit each time. If the archive bit is on, BrightStor ARCserve Backup backs up the file, but in this case, BrightStor ARCserve Backup does not clear the archive bit. Yes
Yes
Source files whose archive bit is turned on
Yes
Differential (keep archive bit)
Source files whose archive bit is turned on
Yes
No
Storage Management
1211
Perform Data Backup
Note: A files archive bit can also be turned on and off by other applications. See the instructions for selecting a backup method in the online CA Procedures. When running BrightStor ARCserve Backup on the UNIX/Linux platform, files are flagged for backup based on their modified date and time. The following backup methods are available: Method Full backup Incremental backup Description Performed each time the job is repeated. Backs up only those files that have changed (determined by date and time of last saved changes) since the last backup was done will be backed up. After each backup, the date and time are recorded so that they are not backed up during the next incremental backup job. The backup is performed daily after one weekly full backup and the following occurs: A full backup will be made of the job and all dates and times are recorded. The next day, the differential backup will back up files that have their dates and/or times changed. (The dates and times will not be recorded after the backup.) The following day, the differential backup will contain all files that have their dates and times changed from the previous two days.
Differential backup
Unicenter Tape Management Mode
When backing up to any blank media that does not have a valid six-character volume serial number, BrightStor ARCserve Backup will provide a volume serial number automatically. Alternately, you can prepare the media before hand by manually formatting it. See the section, Formatting Media, presented later in this chapter.
1212
Administrator Guide
Perform Data Backup
Specifying Rules for Media Overwrite/Append

You can specify the overwrite/append rules for the media used in your backup job while you are configuring the job. The following types of rules are available:
Rules for the First Backup Media determine the overwrite rules for the first media that is used for the backup job. The first backup media is the media you use when the backup job begins. Rules for Additional Backup Media determine the overwrite rules for additional media needed for the backup.
See the instructions for specifying overwrite/append rules for your backup job media in the online CA Procedures. Rules for the First Backup Media The available rules for the first media are as follows:
Rule Append to Media
Description Appends job sessions to the selected media.
Overwrite Same Media Name, or Blank Overwrites the media in the drive only Media if it is the one you specified for the job or if the media is blank. If neither of these conditions is met, BrightStor ARCserve Backup prompts you to supply the specific media name. First, then Any Media Reformats whatever media is found in the device and starts backing up files from the beginning of the media. This is the number of minutes BrightStor ARCserve Backup will wait for media to be inserted into a drive before it cancels the job.
Time out for First Media
Storage Management
1213
Perform Data Backup
By default, BrightStor ARCserve Backup appends any data to the media selected for the backup job. However, you can also overwrite media in the drive by selecting another Media Option. The available rules for the first media are as follows: Rule Description
Overwrite Same Media Name, or Blank Overwrites the media in the drive only Media if it is the one specified for the job (set in the Media Name field), or if the media is blank. If media with a different name is in the drive when the job begins, the job will fail. Overwrite Same Media Name, or Blank Overwrites any media that is in the Media drive. Selecting this option initiates BrightStor ARCserve Backup to check whether the media in the drive is the one specified for the job. If it is not, BrightStor ARCserve Backup checks to see if the media is blank. If it is not blank either, BrightStor ARCserve Backup reformats whatever media it finds in the device (with the name that is in the Media Name field) and starts backing up files at the beginning of the media. Only GFS rotation media will not be overwritten. If BrightStor ARCserve Backup finds that the media in the drive is a GFS rotation media, the job fails. Overwrite Same Media Name, or Any Media First, then Blank Media Overwrites any media that is in the drive, with the same name as in the Media Name field, or any media. If media with a different name is in the drive or if the media in the drive is a GFS rotation media, the job fails. This is the number of minutes BrightStor ARCserve Backup will wait before attempting to access media, before canceling a job.
Time-out for First Media
WARNING! Unlike appending to a media, overwriting a media formats the media and then starts writing to it at the beginning. Any data on the media is lost.
1214
Administrator Guide
Perform Data Backup
Rules for Additional Backup Media The additional backup media rules apply to jobs that require more than one media. You need to specify which media BrightStor ARCserve Backup can use when the job spans media. The available rules are: Rule Description
Overwrite Same Media Name, or Blank Write to the media in the device only if Media it has the same media name (but a different media ID) or if it is blank. BrightStor ARCserve Backup remembers the name and ID of the jobs first media. When the job requires additional media, BrightStor ARCserve Backup checks if the new media has the same name (but different media ID) or if it is blank media. As long as the ID is different, BrightStor ARCserve Backup reformats the media, giving it the same name and ID as the first media. The sequence number will be different. Overwrite Same Media Name or Blank Media First, then Any Media Overwrite any media found in the device (as long as it has a different ID from the first medias ID). All subsequent media are reformatted with the same name and ID as the first media. Only the sequence number will be different. Number of minutes BrightStor ARCserve Backup will wait for media to be inserted into a drive before it cancels the job.
Timeout for Additional Media
Storage Management
1215
Perform Data Backup
Span Media Options If the backup job you schedule requires more than one media to back up the selected targets, BrightStor ARCserve Backup needs some information on what to do. If you only have one device drive, BrightStor ARCserve Backup will have to wait the specified number of minutes in the Timeout for Span Media field for you to insert the new media. If you have grouped devices together, then BrightStor ARCserve Backup can automatically move to the next drive and use that media. However, you need to tell BrightStor ARCserve Backup to use only media with the same name, or blank media, or any media. Rule Description
Overwrite Same Media Name, or Blank Using this option overwrites any media Media with the same media name as the sequence one media (the first media used in the backup job). The next media (sequence two) is reformatted with the name that is in the Media Name field. Overwrite Same Media Name, or Blank Use this option if you want BrightStor Media First, then any Media ARCserve Backup to overwrite any media that is in the drive. The next media (sequence two) is reformatted with the name that is in the Media Name field. Be careful when using this option when you have grouped drives. Leaving media in a drive can cause it to be reformatted if you have told BrightStor ARCserve Backup to span to any media. Overwrite Same Media Name, or Any Media First, then Blank Media Using this option overwrites any media that is in the drive, with the same name as in the Media Name field, or any media. If media with a different name is in the drive or if the media in the drive is a GFS rotation media, the job will fail.
1216
Administrator Guide
Perform Data Backup
Compressing and Encrypting Your Backup Data

You can maximize the effectiveness of your media and increase data speed by setting the Compress Files Before Backup option for the backup job. With this option turned on, the data being transported and archived will be compressed. If the tape drive does not support compression, or if the hardware compression is disabled, BrightStor ARCserve Backup will compress the data. On a compressed NTFS volume, the data being archived will be stored compressed. See the instructions for setting compression in the online CA Procedures. Encryption encodes your data so that it is not intelligible. To enhance network security, you must first specify a Session/ Encryption password for a backup job or a selected drive. Once you have chosen a password, you will need it to subsequently restore the data from media. Select Encrypt Files Before Backup to enable this feature. See the instructions for specifying a session password for your backup job in the online CA Procedures. Important! Make sure that you remember your password so that it is available when you want to restore your data. If you do not know your password, you will not be able to access the data!
Verifying Your Backup Data

BrightStor ARCserve Backuplets you verify that your data was correctly backed up to media. You can verify data for the entire backup job or for a selected drive in your backup job. The global verification options (applied to the entire job) will be overridden by the options selected for a drive. The following verification options are available: Verification Option None Scan Backup Media Contents Description The backup is not verified. Check the proprietary BrightStor ARCserve Backup data area of each file on the backup media. If it is readable, BrightStor ARCserve Backup assumes the data is reliable. If it is not readable, the Activity Log is updated with this information. Of the four verification methods listed here, this one is fastest.
Storage Management
1217
Perform Data Backup
Verification Option Compare Backup Media to Disk
Description Data from the backup media is read and compared byte for byte against the source files. This option is takes time, but ensures that all data on the backup media are exactly as on the disk. If BrightStor ARCserve Backup finds a mismatch, the error is recorded in the Activity Log. If you have selected the Calculate and Store CRC Value on Media option on the Operation tab, BrightStor ARCserve Backup will perform CRC verification. This method assigns a value to the data that you copied to media and compares it to the value assigned to the data that you backed up. This enables you to identify the individual data packets that were backed up.
Cyclic Redundancy Check (CRC)
See the instructions for verifying your data on media in the online CA Procedures.
Specifying Pre/Post Commands

BrightStor ARCserve Backup lets you specify pre/post commands that perform various actions immediately before and/or after your data is backed up to media. You can specify pre/post commands for the following:
The entire backup job. These commands are executed at the beginning or end of the job. A selected computer. These commands are executed before and/or after the data from the selected computer is backed up.
You can run UNIX/Linux Commands, UNIX/Linux executable programs, and UNIX/Linux shell scripts. See the instructions for specifying a pre/post command for a selected machine or for the entire backup job in the online CA Procedures. For information on applying additional backup job options, see the section Customize Your Jobs, presented later in this chapter.
1218
Administrator Guide
Perform Data Restore

Each restore requires a source and a destination. The files you select as your source will always originate on backup media, and the place you select as your destination will always be a hard drive. You can use the BrightStor ARCserve Backup Restore Manager to perform your restore. For Windows, you can use the Restore Wizard, which offers you an automated service to restore your data. With the Restore Wizard, you are able to submit a restore job to BrightStor ARCserve Backups job queue without running the BrightStor ARCserve Backup Manager. If you have performed a full or partial backup of the Windows system directory (including the registry files), you can restore a selected object in the registry, if required. See the instructions for using the Restore Wizard in the online CA Procedures.
Storage Management
1219
Selecting Backup Media for a Restore

The method you choose to select your restore source depends on what you know about the files you want to restore and the media you need to use. The following table lists the methods by which you can choose your source files. Restore Method How It Works Using its database, BrightStor ARCserve Backup reconstructs a directory tree of all machines, directories, and files that were backed up. Explanation You can restore a specific directory or drive, or a directory of files if you know their original location (machine name/drive/ directory structure) before they were backed up. Use Restore by Tree when you dont know which tape contains the data you need, but you know which machine it came from. This source view provides you with the best overall picture of your network, including each machine, as it was when you backed it up.
Restore by Tree
1220
Administrator Guide
Restore Method
How It Works Using its database, BrightStor ARCserve Backup reconstructs a directory tree of all machines, directories, and files that were backed up.
Explanation You can restore a specific directory or drive, or a directory of files if you know their original location (machine name/drive/ directory structure) before they were backed up. Use Restore by File System when you do not know which tape contains the data you need, but you know which machine it came from. This source view provides you with the best overall picture of your network, including each machine, as it was when you backed it up.
Restore by File System
Restore by Session
Using its database, BrightStor ARCserve Backup displays all media used for backups and the source for each session on the tape.
Use this method if you know the tape name, but are not certain about the session you want to restore. Use this method when you know the names of the files or directories you want to restore, but are not sure of the tape name or location. The Restore by Query can be as general or as specific as you want. A search (using a wild card) will show you each backup occurrence, so that you can select the exact session you need.
You specify a search pattern and BrightStor Restore by Query (only if ARCserve Backup using the Restore Wizard) searches its database for the specified machine, directories, subdirectories, and files. You then select the files to be restored from this list.
Storage Management
1221
Restore Method
How It Works
Explanation This method should be used if a tape was created by a different version of BrightStor ARCserve Backup, or if the database does not recognize it.
Restore by Backup Media Use this method when you know only the name of the tape, but are not certain of its contents.
Selecting a Destination for Your Restored Data

If you select the default option, Restore files to their original location(s), your files are restored to their original machine and path. You can clear this option and select another destination using the Browser. In addition, with either type of destination, you can use the Options button to specify destination options. See the instructions for selecting a destination for your restore in the online CA Procedures. Specifying Destination Options The destination options determine how the directory structure will be created on the destination when files are restored. They also determine which files (if any) can be overwritten. The options that are available for restoring directories to a destination are as follows: Option Description
Do not create the base Selecting this option creates all subdirectories below the directories source base directory. (A base directory is the name of the last directory given in the source path.) This is the default. Create directories from the base Creating entire path from the root Selecting this option creates a destination path beginning from the base directory. Selecting this option creates on the destination only the directory path to the base directory. No files from any parent directories are restored.
See the instructions for specifying destination options in the online CA Procedures.
1222
Administrator Guide
Merging Media
The Merge Media utility appends database information to your existing database files. Use Merge Media when you need to restore data from a different server than the one on which your BrightStor ARCserve Backup database resides. For example, if a backup was created using BrightStor ARCserve Backup on a different machine, you can use Merge Media to get the media information into the database in BrightStor ARCserve Backups home directory. Merge Media lets you take media that contains one or more backup sessions and merge the information from that media into your BrightStor ARCserve Backup database.
File Conflict Resolution Options

The file conflict resolution options let you select the method BrightStor ARCserve Backup should use when there are files on the destination disk that have the same name as files being restored from the backup media. The default is Overwrite All Files.
The file conflict resolution options are described below: Option Overwrite All Files (Default) Description Restore all source files to the destination regardless of conflicts in file names. The files restored from the backup media will overwrite existing files on the destination.
Storage Management
1223
Recover from a Disaster
Option Rename Files
Description Restore the source file to the destination with the same filename, but a different extension if a conflict exists. The restored files extension will maintain the first two characters of the original, but the last character will be 1, 2, 3,..., depending on how many files BrightStor ARCserve Backup has encountered with the same name. Filenames without extensions will be renamed with extensions .___0, .___1, .___2, and so forth. Note: On the UNIX/Linux platform, the filename extensions will be renamed .AS1, .AS2, and so forth.
Skip Existing Files Overwrite with Newer Files Only
Do not restore a source file if a file with the same name already exists. Only restore source files whose modification dates are newer than the modification date of the file with the same name on the destination. A source file whose modification date is earlier will not be restored to the destination. Applies when submitting an immediate job (if Run Now is selected). Before BrightStor ARCserve Backup restores the source file, you are prompted to confirm that you want to overwrite the file on the destination.
Confirm Overwrites

This section describes how to use BrightStor ARCserve Backup to best protect and recover your data in case of a system failure. Note: BrightStor ARCserve Backup lets you back up a single computer. If you need to create backups for multiple databases, you may consider purchasing the Unicenter NSM option, Advanced Storage Option (ASO), which creates disaster recovery boot disks. Using this option, the server data can be recovered without reinstallation of the operating system and BrightStor ARCserve Backup.
1224
Administrator Guide
Maintaining Current Backups

The single most important thing you can do to ensure against data loss is to maintain current backups of your data. If you do not have these backups, then BrightStor ARCserve Backup is limited in its ability to recover data lost due to a system failure. You can choose to use the GFS rotation feature to help you maintain current backups. GFS rotation can assist you in designing a complete backup scheme so that a current backup is always an option. Maintain at least one full set of system backups, and at least one set of operating system installation tapes at a protected, offsite location. Rotate the set of tapes stored at this offsite location on a regular basis to ensure that these tapes represent as current a set of backups as possible.
Backing Up the BrightStor ARCserve Backup Database

When you back up your entire BrightStor ARCserve Backup host, the BrightStor ARCserve Backup database is backed up as well. If you use GFS rotation, the databases are backed up automatically, no matter which targets are included in the GFS rotation set. Always maintain a current backup of your BrightStor ARCserve Backup database files so that recovery from a failure will be easier. Assume, for example, that you create a full backup every Friday. Monday through Thursday, a differential backup is created, which contains any files that have changed since the last full backup. Should something happen to any node during the period between full backups, then you can recover using the last full backup (a backup job with the Clear Archive Bit method selected), and the most recent differential backup, which contains all the modifications to the data since the last full backup. See the instructions for restoring the BrightStor ARCserve Backup host and database for both Windows and UNIX/Linux in the following sections.
Restoring the BrightStor ARCserve Backup Host for Windows

Important! If you have purchased and are using the Unicenter NSM option, Advanced Storage Option (ASO), do not use this procedure. Instead, use the BrightStor ARCserve Backup Disaster Recovery Wizard. Use the following procedure to restore your BrightStor ARCserve Backup host. 1. 2. Reinstall the Windows operating system. (See your Windows documentation for instructions.) Reinstall BrightStor ARCserve Backup.
Storage Management
1225
3.
Restore the BrightStor ARCserve Backup database. The BrightStor ARCserve Backup database contains information about what has been previously backed up. You will need to recover the BrightStor ARCserve Backup database so that you can restore the rest of the information on the host. Perform the procedure furnished under the section Restore the BrightStor ARCserve Backup Database for Windows, and then return to Step 4 below.
4.
Open Restore Manager and choose Restore by Tree so you can see the BrightStor ARCserve Backup host. You can pick and choose what you want to recover or select the entire host. Select the destination. The destination path for the restore operation will typically be hostname:\ where hostname is the name of your local host. Click the Options button to specify destination options. If you are attempting to restore the client to the state it was in before it failed, then you should overwrite any conflicting files during the restore. If you are unsure, you can choose to rename any files that exist on the client.
5. 6.
7.
Click the Submit button to start the job. BrightStor ARCserve Backup will then tell you the media that you will need. BrightStor ARCserve Backup knows which media contain the latest version of all the files for the machine you want to recover.
Restoring the BrightStor ARCserve Backup Database for Windows

This procedure lets you restore database files from media to your BrightStor ARCserve Backup database. 1. 2. 3. 4. From the BrightStor ARCserve Backup Storage Management window, select BrightStor ARCserve Backup Manager. Choose the Classic Quick Access tab. Click the Recover DB button. Specify the media you want to use. If the media you want to use is not currently in a storage device, you must type the information into the Group and Media fields. 5. 6. 7. Specify any options for the job. Specify any filters for the job. Click the Run button to run the job.
1226
Administrator Guide
Restoring the BrightStor ARCserve Backup Host for UNIX/Linux

Use the following procedure to restore your BrightStor ARCserve Backup host. 1. 2. 3. 4. Reinstall the UNIX/Linux operating system. (See your UNIX/Linux documentation for instructions.) Reinstall BrightStor ARCserve Backup. Install and configure the Client Agent for UNIX/Linux. Restore the BrightStor ARCserve Backup database. The BrightStor ARCserve Backup database contains information about what has been previously backed up. You will need to recover the BrightStor ARCserve Backup database so that you can restore the rest of the information on the host. Perform the procedure under the section Restore the BrightStor ARCserve Backup Database for UNIX/Linux, and then return to Step 5 below. 5. Open Restore Manager and choose Restore by File System so you can see the BrightStor ARCserve Backup host. You can pick and choose what you want to recover or select the entire host. If you plan to restore the entire host, exclude the following directories from your restore job using Exclude Directory Filter: /bin /etc /usr/bin /usr/lib These directories contain system sensitive files that should not be overwritten. In the event of a system failure, these files will be restored through system reinstallation. Attempting to over-write these files could cause additional failures. Note: The ARC_HOME directory should also be excluded from your full host restore. Attempts to overwrite the restore process while a restore is in progress will cause the job to hang and fail. BrightStor ARCserve Backup user-defined directories, such as ./jobs and ./logs can be restored later through selective restore. 6. Select the destination. The destination path for the restore operation will typically be hostname:/ where hostname is the name of your local host. Selec the File System view to click the client you want to restore, without having to worry about which media and sequence numbers you need for the job. BrightStor ARCserve Backup will find the latest version of the host to restore. If you do not want the latest version, you can use the BrightStor ARCserve Backup Version History function to select the version to restore.
Storage Management
1227
7.
Click the Options button to specify destination options. If you are attempting to restore the client to the state it was in before it failed, then you should overwrite any conflicting files during the restore. If you are unsure, you can choose to rename any files that exist on the client.
8.
Click the Submit button to start the job. BrightStor ARCserve Backup will then tell you the media that you will need. BrightStor ARCserve Backup knows which media contain the latest version of all the files for the machine you want to recover.
Restoring the BrightStor ARCserve Backup Database for UNIX/Linux

If you have lost the database on your BrightStor ARCserve Backup host, you will need to recover the BrightStor ARCserve Backup database before restoring any other information. Use the following procedure to restore the database. 1. Insert the media containing the most recent backup of your entire BrightStor ARCserve Backup host. If you have a backup of your host, then the BrightStor ARCserve Backup database will be a separate session on that media. Place this media into the drive. 2. From the BrightStor ARCserve Backup servers home page, select Scan. The Scan Manager appears. Select the media you want to scan, then click to scan All Sessions on the media. 3. Click Source and scan all the sessions on that media. Remember to send this report to a file on disk so that you have a permanent record. You will need to look at this report to see which session contains the BrightStor ARCserve Backup database. 4. 5. Note the session that contains the BrightStor ARCserve Backup database. This is the session that will have to be restored. Choose the Restore by Backup Media view. Since there is no database information on the host, you will need to manually restore the database. 6. Select the media to use for the restore. Select the group and media that you just scanned. Specify the session number that contains the BrightStor ARCserve Backup database. 7. Select the Destination tab. The destination directory is the BrightStor ARCserve Backup database directory, $ARC_HOME/dbase.
1228
Administrator Guide
Manage Jobs Using the Job Status Manager
8.
Click the Submit button to execute the job. After the database is restored, you can use the Restore Manager Tree View to recover any client that was backed up.

Each time you run or schedule a job with the BrightStor ARCserve Backup Manager, you submit it to the BrightStor ARCserve Backup job queue. Information about all jobs (such as execution time, status, last result, and owner) is stored here. BrightStor ARCserve Backup continuously scans the job queue for jobs that are ready to be executed. The scanning frequency can be changed through the BrightStor ARCserve Backup Server component; see the section Administer the BrightStor ARCserve Backup Server, presented later in this chapter. At the given date and time, the job is executed. You can manage jobs that are in the queue with the Job Status Manager. Job management includes the following tasks:

Review information about the last time jobs were executed Add a previously saved script to the queue Change a jobs execution date, time, or status (this includes resubmitting a job) Display information about a job Modify information about a pending job Delete a job Monitor an active job Stop an active job
Accessing Job Status Information

You can open the Job Status Manager from the Quick Access screen when you click the Job Status button. Job Status Manager has the Explorer-like paradigm that is consistent with all the other managers. The left-panel Server Browser makes it easy to navigate through BrightStor ARCserve Backup servers and objects on those servers. At the top level, all servers are arranged into groups that you can configure.
Storage Management
1229
Displaying Job Detail and Job Log You can use the bottom panel of the Job Status Manager to display details about any job in the job queue. The Job Detail tab displays the details about a job, including the source and destination target(s) and the jobs schedule. If you have selected customization options, such as pre/post backup requirements, these will be displayed as well. After a backup job has started, you can view its sequence and session number. If the job has completed, you can also use this panel to view the Job Log. The Job Log displays information about jobs that have been executed. The level of detail in this log is determined when you create a job. You can elect to see all of the activity that occurred while the job was running or only the summary information, which includes source, destination, session number, totals, and any errors that may have occurred. See the instructions for displaying the Job Detail and Job Log in the online CA Procedures. Displaying the Job Queue Menu You can access the Job Queue menu from the Job Status Manager by clicking the right mouse button on a highlighted job. The Job Queue menu offers the following options: Option HOLD Action Changes the jobs status to HOLD or READY (if it is currently on hold). (HOLD signifies that the job is not scheduled to be launched. READY means that the job can be launched.) Selects a job script and adds it to the queue Modifies a job Changes the jobs execution time Stops an active job Deletes a job from the queue Changes the way jobs are listed in the queue Double-click to produce the Job Properties dialog box.
Add Job Modify Job Reschedule Job Stop Job Delete Job Sort By Properties
1230
Administrator Guide
Reviewing Information About Executed Jobs A job listed in the Job Queue with a status of Done is a job that has no repeat interval and has already been executed. Done jobs remain listed in the Job Queue for a specified number of hours. This is determined through BrightStor ARCserve Backups Server Admin feature. See the section Administer the BrightStor ARCserve Backup Server, presented later in this chapter. A repeating job (for example, a backup job that runs every Friday) will not have a Done status after it has been executed. Instead, it will have a Ready status (it is ready to be executed again next Friday). The Last Result field of the Job Status window tells you whether your job execution was successful. If it was not successful, the Last Result field helps you determine why the job may have failed so you can remedy the problem. You can then resubmit the job. For information about resubmitting a job, see the section Changing a Jobs Execution Date, Time, or Status, presented later in this chapter. The following table describes the type of information BrightStor ARCserve Backup provides about your job in the Last Result field. Last Result Explanation All of the nodes and drives/shares were processed. All of the nodes and drives/shares were processed. The job was partially unsuccessful. Possible Cause (This is a normal end.)
Completed
(This is a normal end.)
Finished Incomplete
Review the Activity Log information to check the exact nature of what occurred to prevent job completion.
Storage Management
1231
Last Result Canceled
Explanation The job was intentionally canceled.
Possible Cause One of the following events may have occurred:
A user canceled the job from the Job Queue. Someone answered NO or CANCEL to a prompt. The job required a confirmation of OK, or you needed to insert media before the timeout was reached. (Timeout is set in the Tape options in the Backup Manager window.)
Failed
The job failed to perform its designated task. If the job was started, but the Manager could not complete the job, you will receive Run Failed status (below). The job was started, but the program that runs the job (the Job Runner) failed. The job was started and a system error occurred which prevented BrightStor ARCserve Backup from completing its task.
Review the Activity Log information for the exact nature of what occurred that prevented job completion.
Run Failed Crashed
There was not enough memory to run the job or a DLL file was not found. A system error occurred in the job, such as a memory violation, that caused BrightStor ARCserve Backup or the operating system to be shut down. Complete information about the status of this job will not appear in the Activity Log.
Reviewing the Activity Log The Activity Log provides information about the status of your jobs. If, for example, a job failed, the Activity Log may contain the entry Job Engine is Stopped and provide the date and time of the occurrence.
1232
Administrator Guide
Adding a Job to the Job Queue

You can quickly submit a job to the queue by using a previously saved script. A script is a job that you saved to a file. It contains the original source, destination, option, and schedule information for the job. See the section Customize Your Jobs for more information about scripts. See the instructions for adding a job script to the Job queue in the online CA Procedures.
Changing a Jobs Execution Date, Time, or Status

The Job Status Manager makes it easy for you to quickly change a jobs execution date, time, or status. It also allows you to resubmit a previously executed job that is still in the Job Queue. You may want to do this if your job was not successful when it first ran. See the instructions for changing a jobs execution date, time, or status in the online CA Procedures.
Stopping an Active Job

You can use the Stop Job button or the Delete Job button to cancel an active job. If the job you are stopping is a job that repeats at regular intervals (you specify this when you create the job), you should read the following information to determine which button to use. You can delete jobs from the queue, whether they are active, done, or pending. Deleting jobs from the Job Status Manager window completely removes them from the job queue. This means that repeating jobs will not be rescheduled.
Stop Job--Cancels the active job and reschedules it for its next regular interval. Delete Job--Cancels the active job and deletes it completely.
Note: If you stop a job, the Last Result field of the Job Status window will display Canceled. Important! We recommend using the Stop Job option when you want to delete an active job that repeats at intervals (determined when you create the job). Selecting the Delete Job button will interrupt and remove the job completely from the queue, and it will not be rescheduled. You will have to recreate the job if you did not save it to a script file. See the instructions for stopping an active job in the online CA Procedures.
Storage Management
1233
Modifying a Job
You can modify a job already in the queue using Job Status Manager. This enables you to add options or additional sources to an existing job, without having to create a new job. See the instructions for modifying a job in the Job queue in the online CA Procedures.
Changing the Way Jobs Are Listed in the Job Queue

When you first open the Job Status Manager, the jobs in the queue are listed in order of execution time. You can change the way in which jobs are listed in the queue. Sorting the job queue is for informational purposes only. It does not affect the order in which jobs are processed. Jobs can be sorted by clicking any of the following fields:

Status Execution Time Job Type Server Last Result Owner Description Total Files
See the instructions for sorting the Job queue in the online CA Procedures. Tip: You can resize these columns by using the drag-and-drop method with the mouse. Place the cursor on the divider between columns, click and hold down the left mouse button, and then move the divider in either direction until the column is the size you want.
1234
Administrator Guide
Filtering the Information Displayed for a Selected Server Group BrightStor ARCserve Backup provides options when configuring the view associated with a server group. All view options are on a per-group basis and can be set in accordance with the following job queue characteristics: Option Job Status Job Type Time Range Description Allows job status related information to be selectively displayed for a given group. Lets you selectively display jobs based on their type or characteristic. Display is based on the how old the job is (in days).
Choosing Job Status Display Options BrightStor ARCserve Backup allows you to set which column headings will be shown within the Job Status Manager for a particular Server group. These headings are as follows:

Server Job Status Execution Time Job Type Comments Last Result Owner
Monitoring an Active Job

You can monitor the real-time status of a job while it is running. The Job Monitor displays the status of a job that is running.
Storage Management
1235
Customize Your Jobs
Monitoring Job Status for Central Databases You can monitor the job activity for all BrightStor ARCserve Backup members from the Central Database. Proceed from the Job Status Manager, at the root of the BrightStor ARCserve Backup tree, and select Global, and then the Central Database Server. You can use the following items to monitor job activity:

Job queue for all jobs being run by BrightStor ARCserve Backup members Activity Log for all BrightStor ARCserve Backup members activity Tape Log includes all BrightStor ARCserve Backup members tape session information. (You can configure the Detail Log in the Server Admin Tape Engine for Tape Log access.)
See the instructions for viewing centralized job information for BrightStor ARCserve Backup members in the online CA Procedures.
Customize Your Jobs

You can customize your jobs with the following:

Using filters Scheduling a job Using job scripts Specifying options
Customizing Your Jobs Using Filters

Filters let you include or exclude files and directories from your backup, restore, or copy jobs, as well as from the utilities, such as count and purge. You can choose to include or exclude files based on the following criteria:

Specific file names or patterns Specific directory names or patterns File attributes (hidden, system, and so forth) Files created, modified, or last accessed before, on, or after a specific date, or within a date range
Include vs. Exclude
Exclusions always take precedence over inclusions. For example, if you add a File Pattern filter to include only files that have an extension of .EXE, and you add a Directory filter to exclude your \WORK directory, then all .EXE files in the \WORK directory will be excluded.
1236
Administrator Guide
Customize Your Jobs
Specifying to include files will result in a backup or restore containing only those files that satisfy the filter specifications. For example, suppose in the source area you selected to back up your entire local hard drive, and you then define a Directory filter to include files in the \WORK directory. The result would be that BrightStor ARCserve Backup would only back up files from your \WORD directory. No other files would be backed up. Machine-Level or Job-Level Filters A backup or count job can have machine-level and job-level filters for the same job. Machine-level filters apply to one specific machine, not the entire job. If you want to add a filter that applies to the entire job, use a job-level filter. See the instructions for applying filters in the online CA Procedures. File Pattern Filter Use a file pattern filter to include or exclude certain files from a job. You can specify a particular file name, or you can use wildcards to specify a file pattern. An example of including a file is provided in the online CA Procedures Guide.
Windows/ NetWare File Pattern Syntax
The following table describes the recognized file patterns for Microsoft Network computers and NetWare servers:
Pattern
DRIVE:\PATH\FILE
What It Means An absolute path on your local hard drive An absolute path on the specified network machine An absolute path on any network drive The file can be in any directory on the specified drive. The file can be in any directory on any network drive.
Examples
C:\SYSTEM\*.FOT C:\BAT\AUTOEXEC.BAT \\ENG\DOS\SYSTEM.BAT
\\MACHINE\PATH\FILE
\PATH\FILE DRIVE:FILE
\WINNT\SYSTEM\*.FOT\BAT\AUTOEXEC.BAT C:*.FOT C:AUTOEXEC.BAT C:*.FOT AUTOEXEC.BAT
FILE
Storage Management
1237
Customize Your Jobs
UNIX/Linux File Pattern Syntax
The following table demonstrates how to specify paths and file names for UNIX/Linux servers. While reading the following table, keep in mind that:
PATH represents a series of directories following the long file name format for UNIX/Linux (maximum of 255 chars), separated by forward slashes (/). FILE is the name of the file to filter, following the UNIX/Linux long file name format (maximum of 255 chars). Examples
/tmp/memo memo
Pattern
/PATH/FILE FILE
What It Means This is an absolute path and file name. The file can be in any directory.
Directory Filter Use a directory filter to include or exclude specific directories from a job. You can enter an entire directory name or provide a pattern that the directory name follows. An example of how to exclude a specific directory is provided in the online CA Procedures.
Windows/ NetWare Directory Filter Syntax
The following table demonstrates how to specify paths for Microsoft Network computers and NetWare servers:
Pattern
DRIVE:\PATH \\MACHINE\PATH \PATH DRIVE:DIR_NAME
What It Means An absolute path on your local hard drive An absolute path on the specified network machine An absolute path on any network drive The directory can be in any other directory on the specified drive The directory can be in any other directory on any network drive.
Examples
C:\WINNT\MSAPPS\ C:\WIN* \\ENG\DOS \WINNT\MSAPPS\WIN* C:MSAPPS C:MS* MSAPPS *APPS
DIR_NAME
1238
Administrator Guide
Customize Your Jobs
UNIX/Linux Directory Filter Syntax
The following table demonstrates how to specify paths and file names for UNIX/Linux servers. While reading the following table, keep in mind that:
path refers to a series of directories following the long file name format for UNIX/Linux (maximum of 255 chars), separated by forward slashes (/). dir_name is the name of the directory to filter, following the UNIX/Linux file name format (maximum of 255 chars). Examples
/usr/pete pete
Pattern
/path/dir_name
What It Means This is an absolute path to the directory to filter. The directory to filter can be a subdirectory.
dir_name
File Attributes Filter Use the file attributes filter to include or exclude specific types of files from a job. You can choose one or more of the following types of file attributes, selecting as many file types as you need.
Hidden--Files not shown in a directory listing, for example, io.sys is a hidden file. System--Files that are unique to the machine you are using. Read Only--Files that cannot be modified. Archive--Files whose archive bits are set.
For an example of how to exclude specific file types, see the online CA Procedures. File Modified/Created/Accessed Filters Use one of the following filters to include or exclude files based on a specific date and time or a date range.

Modified--Includes or excludes files last modified (changed) on this date. Created--Includes or excludes files created on this date. Accessed--Includes or excludes files last accessed (used but not changed) on this date.
You can choose from the following filter criteria options:
Before--Files whose date matches, or whose date is earlier than this date will be included or excluded.
Storage Management
1239
Customize Your Jobs
After-- Files whose date matches, or whose date is later than this date will be included or excluded. Between--You must specify two dates for this selection. Files whose date falls between the two dates will be included or excluded from the job. Within--Selecting this option requires you to enter a number of days, months, or years to be used for the comparison (for example, within the past twelve months). Enter a number between 1 and 250, inclusive. BrightStor ARCserve Backup will use the current date as the basis from which to count back.
For an example of how to exclude files based on a specific date and time or a date range, see the online CA Procedures.
Customizing Your Jobs Using Schedule Options

This section discusses scheduling a job to run immediately or at a later date and time. You must specify the source and, if required, the destination for your job before you can specify scheduling information. All jobs can be scheduled in essentially the same way, using the schedule options available in each Manager. Backup jobs can also be configured to use Media Rotation schemes. See the section Define Media Pools and Rotation Schemes in this chapter. You should run your job immediately when:
The job you are submitting is a one-time job that you want executed immediately. You want to monitor the job as it runs.
Scheduling Considerations You should not run a job immediately if your storage device is currently busy and you want to run a backup job as soon as the device is free (do not select Run Now). Instead, you should schedule your backup job, keeping the current date and time. When BrightStor ARCserve Backup discovers that the device is busy, it will continuously retry the backup job and automatically execute the job when the device becomes available. If you select Run Now, BrightStor ARCserve Backup will report that the device is busy and the backup job will not be submitted to the job queue. Instead, you will be asked to wait until the device is available before you can resubmit the job. You can schedule your job to run on a specified date and time, or to repeat regularly (the job is automatically resubmitted to the job queue).
1240
Administrator Guide
Customize Your Jobs
Schedule your job when:
You are submitting a one-time job, but you do not want it to run now. You want it to run at a specific time. You are submitting a job that should run regularly. This is especially useful for setting up a media rotation scheme for your network. Your storage device is currently busy and you want to run a backup job as soon as the drive is available. To do this, schedule your backup job with the current date and time. BrightStor ARCserve Backup will retry the job until the device is available.
See the instructions for scheduling your jobs in the online CA Procedures.
Customizing Your Jobs Using Job Scripts

You can save any type of job as a script. The script will contain the source, destination, and options that you selected, as well as the schedule information. It will also contain any filters you created to include and exclude files and directories. Creating a script has the following advantages:

You can re-use the same settings for a subsequent job. You can copy your settings to a different machine running BrightStor ARCserve Backup on the same platform. You can quickly re-submit regularly executed jobs after a job has been accidentally deleted.
To use a script, go to the Job Queue window of the Job Status Manager and use the Add Job button. When you specify the job script name, all of the information that you set when you saved the job script will be used, including the files and directories and the scheduling information. Note: The list you create using Alert options is saved with the job script together with the configuration defined using the Configuration button. See the instructions for creating a script in the online CA Procedures.
Customizing Your Jobs Using Options

You can customize your jobs using the following options:

Destination options Log options Operation options
Storage Management
1241
Customize Your Jobs
Database options Retry options Media options Pre/Post job options Virus scanning options Alert options Event Notification options
Specifying Destination Options The destination options determine how the directory structure is created on the destination computer when files are copied or restored. They also determine which files (if any) can be overwritten. Note: When running BrightStor ARCserve Backup on the Windows platform, destination options are also available when copying files. See the instructions for specifying destination options for a restore or copy in the online CA Procedures. Specifying Log Options The log options determine the level of detail that is included in the log report for the operation. You can view the log report in the Job Status window or Database Manager window (Job View). The log options are described in the following table. Option Log All Activity Log Summary Only (the default) Description Record all of the activity in the Job Log that occurs while the job is running. Record summary information of the job (including source, destination, session number, and totals) and errors. Do not record any information about this job in the Job Log. Log Disabled
1242
Administrator Guide
Customize Your Jobs
Option
Description Sends all messages to the Unicenter NSM Console.
Unicenter Alert SNMP Alert Printer Name Internet E-mail
Note: Both the BrightStor ARCserve Backup server and the machine running Unicenter NSM are required to be configured in order for this option to work. Sends all messages to your SNMP messaging console. Sends all messages to the specified UNIX/Linux printer local to BrightStor ARCserve Backup server. Sends all messages to the specified email address.
The log options can be set in the following windows:

Backup Restore Scan Merge
Additionally, these log options can be set in the following windows:

Copy Count Compare Delete
Storage Management
1243
Customize Your Jobs
Specifying Operation Options The operation options for your job determine related actions that occur during or after the job, and the level of information that is recorded in the database: Option Delete Files After Backup Operation Backup Description Delete source files from the source machine after they have been backed up to media. Use this option to perform disk housekeeping. Set a filter to back up files that have not been accessed for a certain period of time (say, three months), and then select this option to delete these outdated files from the source disk. Before any file is backed up to media, BrightStor ARCserve Backup, by default, performs an estimate of how long the job will take. Set this option to ON if you want BrightStor ARCserve Backup to bypass this check. Eject the media from the drive after the job finishes. This prevents any other job from overwriting information on this media. You can back up the BrightStor ARCserve Backup database if the BrightStor ARCserve Backup home directory is selected. When media is backed up, a checksum of data is generated and stored on the media and in the database. These values are compared to ensure that the data is intact.
Disable File Estimate
Backup
Eject Media
Backup
Backup Back up BrightStor ARCserve Backup Database files Calculate and Store CRC Backup
1244
Administrator Guide
Customize Your Jobs
Option Mirror
Operation Copy
Description Create a mirror image of the source machine on the destination. Copy files and directories from source and delete all files and directories that do not appear on source. This feature is disabled. Copy empty directories from source machine to destination machine. Restore empty directories.
Create Empty Directories
Copy
Create Empty Directories
Restore, Compare, Scan, Count Copy
Copy File Security Information Delete Files Restore Registry Files
Copy the file-level security information for file access on NTFS volumes. Delete files from source machine after copying to destination. Restore registry files to the machine. This option is not available under the UNIX/Linux platform unless a Windows Agent is used. The default selection; will not create the base directory, but will create all subdirectories that can reside below the source base directory. Will create the destination path beginning from the base directories on the destination. A base directory is considered the directory selected in the source path. Will create the entire path of the source file, starting from the root (the destination path specified) on the destination.
Copy Restore, Compare, Scan, Count
Restore Do not create the base directories Create Directories from the base Restore
Create entire path from the root
Restore
Storage Management
1245
Customize Your Jobs
Option Overwrite All Files
Operation Restore
Description The default selection; will simply overwrite the existing file on the destination with the file from the source. Restore the source file to the destination with same file name, but with the extension .ASn (.AS1, .AS2, and so forth). Source files with the same name as a file on the destination will not be restored. Restore source files whose modification date is later than the modification date of the file with the same name on the destination. Source files whose modification date is earlier will not be restored to the destination.
Rename Files
Restore
Skip Existing Files
Restore
Overwrite with Newer Files Only
Restore
Specifying Database Options The database options determine what, if any, job-relevant information will be recorded in the BrightStor ARCserve Backup database. The following table describes the database options: Option Record Detail Information Operation Backup Description Log all the information pertaining to the source and destination in the BrightStor ARCserve Backup database. Log only job and session information in the BrightStor ARCserve Backup database.
Record Job and Session Information Only
Backup
1246
Administrator Guide
Customize Your Jobs
Option
Operation Backup
Description Do not log any information about this job in the BrightStor ARCserve Backup database. Select this option if you are backing up the BrightStor ARCserve Backup database, or have limited disk space. You must submit a Merge Media job before you can use any of the database views to restore this data, or you must restore data from this job using the Restore by Backup Media source view.
Disable Database Recording
Record Job Information Only Disable Database Recording
Restore, Copy Restore, Copy
Log only job information. Do not record job information.
Specifying Retry Options There are two types of retry options:
Open File Retry determines how frequently (if at all) BrightStor ARCserve Backup attempts to back up. File Sharing determines how BrightStor ARCserve Backup shares the files with other applications when backing up.
Note: When running BrightStor ARCserve Backup on the Windows platform, Retry options are also available when copying files. The following paragraphs discuss these retry options.
Open File Retry Options
Select one of the following Open File Retry options:
Option Retry Immediately
Description Back up or copy the file again immediately after the first attempt failed. If the file is still unavailable, this information is written to the Activity Log, and the job is labeled Incomplete.
Storage Management
1247
Customize Your Jobs
Option Retry After Job
Description Back up or copy the file again after all other source files have been backed up or copied. If the file is still unavailable after these attempts, this information is written to the Activity Log, and the job is labeled Incomplete. If you specify to retry the file after the session, BrightStor ARCserve Backup will try to backup the file(s) based on the number of times specified in Retry Count (by default 3 times), every specified number of seconds in Retry Interval (by default every 10 seconds). If the file is still unavailable after these attempts, this information is written to the Activity Log, and the job is labeled Incomplete. Number of times you want BrightStor ARCserve Backup to try to back up or copy the file. Period of time you want BrightStor ARCserve Backup to wait between attempts.
Retry After Session
Number of Retries Retry Interval (seconds)
File Sharing Options
Select one of the following file sharing options:
Option Use Deny None if Deny Write Fails
Description Attempt to place the file in Deny Write mode. If this is not possible (because the file is already open), then place the file into Deny None mode. This is the default. Attempt to place the file in Deny Write mode. If this is not possible (because the file is already open), then lock the file completely (prohibiting any user from opening or writing to the file). This option ensures the most recent version of the file is backed up or copied. Prevent another process from writing to the file while BrightStor ARCserve Backup has it open. If another process has the file open before BrightStor ARCserve Backup can open it, BrightStor ARCserve Backup will not back up the file (unless you specified an Open File Retry option).
Use Lock Mode if Deny Write Fails
Deny Write
1248
Administrator Guide
Customize Your Jobs
Option Deny None
Description Allow another process to read or write to the file, whether BrightStor ARCserve Backup opens it first or opens it after another process has it open. This option ensures that your files are up-to-date, although the file that was backed up or copied may not be the most recent version.
If you use applications (such as email) that are in operation 24 hours a day, you may want to choose one of the Deny None methods. As long as no other process is writing to these files during the job, the backup or copy will be consistent. If you want to ensure that only the most current version of every file is backed up or copied, you should select a Deny Write or Lock Mode option. Specifying Media Options The media options for Restore, Merge, and Scan allow you to specify a time out period in which to provide media before BrightStor ARCserve Backup restores your data. Note: When running BrightStor ARCserve Backup on the Windows platform, Media options are also available when comparing files. Available Media options are listed in the following table: Option Timeout for First Media Description Period of time that BrightStor ARCserve Backup waits for the first media required for your restore job. If the time expires and the first media has not been provided, the job will fail. By default, BrightStor ARCserve Backup will wait five minutes. Period of time that BrightStor ARCserve Backup waits for any additional media to become available. By default, there is no time out.
Timeout for Additional Media
Storage Management
1249
Customize Your Jobs
Specifying Pre/Post Job Options Pre/post options allow you to submit a command on your machine before or after the job is executed. For example, you may want to use this option on a Windows machine to load a virus scanning application before files are backed up, and then run a batch file you created that sends a detailed report to the printer. Pre/post options are available for Backup, Restore, Scan, and Merge operations. Note: When running BrightStor ARCserve Backup on Windows platforms, Pre/Post options are also available when copying files. The available pre/post options are listed in the following table: Option Run Command Before Job On Exit Code Description Enter the path to and name of the file to be executed on the machine before the job takes off. BrightStor ARCserve Backup detects exit codes of other programs. You can specify the following options for a particular exit code: Run Job Immediately--The job runs immediately if the appropriate code is detected. Skip Job--The job does not run if the appropriate exit code is detected. Skip Post Application--Skip any commands specified to run after the job if the appropriate exit code is detected. Specify the delay (in minutes) in which BrightStor ARCserve Backup waits before running a job when the appropriate exit code is detected. Enter the path and name of the file to be executed on the machine after the job has completed.
Delay Run Command After Job
1250
Administrator Guide
Customize Your Jobs
Option
Description Specify that a job will not run if BrightStor ARCserve Backup detects one the following conditions: Job Fails--BrightStor ARCserve Backup detects that a job fails. Job is Incomplete--BrightStor ARCserve Backup detects that a job is not completed. Job is Complete-- BrightStor ARCserve Backup detects that a job is completed.
Do not run Command if
The User Name and Password corresponds to the UNIX/Linux system of the host server selected, Run Before/After Command and is required in order to check the system privileges on that server. The user name and As password entered into these fields should not be confused with BrightStor ARCserve Backups User Name and Password.
Specifying Virus Scanning Options You can automatically scan for viruses during a backup, copy, or count operation using the virus scanning options. Available virus scanning options are: Option Enable Virus Scanning Description Select this option to enable virus scanning. Note: Virus scanning is not available for UNIX/Linux platforms. Do not back up the infected file. Rename the infected files with the extension AVB. If a file with the same name and the extension AVB exists, then extension AV1 is used, and so on. Delete the infected file.
Skip Rename
Delete
Storage Management
1251
Manage Devices and Media
Specifying Alert Options You can select alert options, which cause the alert notification system to send messages about events in your backup operation. For more information on the alert system, see the section Use the Alert Manager, presented later in this chapter. Specifying Event Notification Options Event notification options permit you to select one or more events for which you want to be notified. Choose one or more of the following events: Alert Event Job completed successfully Job incomplete Job canceled by user Job failed Virus detected Description All of the nodes and drives/shares were processed successfully. Some nodes or drives/shares were missed. The user canceled the job. The job was started but could not be completed. A virus was detected in one of the files to be backed up. See the section Specifying Virus Scanning Options (Backup, Copy, Count) for more information. A customized event occurred. To specify this type of event, enter an error, warning, or notification code in the space underneath the Event dropbox. You can enter multiple codes and use wild cards, for example, E1???; W*; N1?31.
Customized Event
Note: The list you create using alert options is saved with the job script and the configuration you defined using the Configuration button.

When you want information about storage devices that are connected to your system, the media in these devices, or the status of these devices, use the Device Manager. You can also use the Device Manager when you need to format, erase, re-tension media, or change the compression mode for your tape drives. See the instructions for using the Device Manager in the online CA Procedures.
1252
Administrator Guide
Defining Device Groups

BrightStor ARCserve Backup provides the concept of device groups, which allows you to separate your storage devices. If you want to include several devices in a group, each device in the group must be the same make and model. Grouping devices lets you take advantage of parallel streaming. Moreover, if you have several devices in a group, you can perform automated media spanning. When BrightStor ARCserve Backups Tape Engine is started, each storage device that you have is automatically placed in a device group. Identical drives are grouped together and differing drives are separated into different groups. For example, if you have five drives attached to your machine, three of which are identical, you will have three groups: GROUP0, GROUP1, and GROUP2. The three identical drives will be in one group and the remaining two, since they are different from all others, are each placed in their own individual group. BrightStor ARCserve Backup on the UNIX/Linux platform uses the names of the planets in our solar system (excluding Earth) to label device groups. (The planets are Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, and Pluto.) Depending on the type of SCSI card you have connected, you can have up to seven or fifteen storage devices per SCSI adapter card, connected to your host. Note: BrightStor ARCserve Backup will only configure the first seven devices found on the primary SCSI card using the planet names, one device per group. If your primary card has more than seven devices, additional devices will be configured into groups labeled using a prefix of Group, and a suffix numbered sequentially starting at zero. In the event that your system is configured with a second SCSI card, BrightStor ARCserve Backup will not recognize the devices on that card until the Media Server (asmediad) has been initiated. Once initiated, the Media Server will assign the devices on the second card (and subsequent cards) using the Group label. In addition, BrightStor ARCserve Backup assigns SCSI IDs to the devices within each device group. Since BrightStor ARCserve Backup automatically groups your storage devices, you can keep these device group names, or you can regroup and rename them. The device group operations available through the Device Manager are as follows:

Create a new device group. Assign a device to a device group.
Storage Management
1253
Remove a storage device from a device group. Rename or delete a device group.
See the instructions for defining new device groups in the online CA Procedures.
Using the Device Sharing Feature

Device sharing is a locking mechanism by which BrightStor ARCserve Backup can reserve devices for exclusive use by BrightStor ARCserve Backup. BrightStor ARCserve Backup locks (reserves) the device only when it is asked, or if a backup/restore/scan/merge job is being executed. At other times, BrightStor ARCserve Backup does not lock the device, and it can be used by any other application. Note: To use the device-sharing feature, Tape Management must be running (active). You must also activate Unicenter Tape Management mode. See the section Managing Devices and Media in Unicenter Tape Management Mode, presented later in this chapter. For Backup/Restore/Merge/Scan For backup/restore/merge/scan operations, you need not reserve the device for BrightStor ARCserve Backup. BrightStor ARCserve Backup interacts with Tape Management to automatically request use of the device that BrightStor ARCserve Backup has selected. If the device is available, BrightStor ARCserve Backup will use it to perform the specific operation. Once the operation is completed, Unicenter NSM is notified that the device is again available, and the device is automatically unreserved. If BrightStor ARCserve Backup cannot reserve the device because it is being used by another application, BrightStor ARCserve Backup will poll the device until it is available. Once reserved, the job is started, and upon completion, it is automatically unreserved. For Device Manager For Device Manager operations, you must explicitly reserve the device for BrightStor ARCserve Backup using either the Java GUI or the command line. You can reserve a device if, and only if, no other application has opened it (and conversely). Once the device is reserved, BrightStor ARCserve Backup can open the device.
1254
Administrator Guide
When performing Device Manager operations (format, erase, re-tension, and compression, as examples), BrightStor ARCserve Backup needs to perform an explicit Reserve of the device. When you open Device Manager, all options in the window are unavailable until you select Reserve. This selection claims the device exclusively for BrightStor ARCserve Backup tape operations. When Reserve is selected, you are able to perform all types of tape operations. When you have completed your tape operations, you must Unreserve the device to make it available to other users. If you fail to Unreserve the device, it can only be made available to other UNIX/Linux operations if a BrightStor ARCserve Backup/restore/merge/scan operation is executed. Once the operation is completed, BrightStor ARCserve Backup will release its claim on the device. How Device Sharing Works BrightStor ARCserve Backup uses Unicenter NSM to lock/unlock the device. If BrightStor ARCserve Backup needs the device for an operation, it asks Unicenter NSM to mount the device. If the mount is successful, the device is reserved for the exclusive use of BrightStor ARCserve Backup and no other application can access it until BrightStor ARCserve Backup unmounts that device. If Unicenter NSM cannot mount the device, it is because another application has it mounted, BrightStor ARCserve Backup cannot use it until that application unmounts it. Activating Device Sharing You can activate or deactivate device sharing in the asmediad.cfg file by specifying whether DEVICE_SHARING_ENABLED=1 (on) or 0 (off).
Using Parallel Streaming

If you have more than one device group configured on your computer, you can take advantage of parallel streaming. Parallel streaming means that you can have more than one job requiring a storage device running at a time. For example, suppose you have two device groups; GROUP1 and GROUP2. You could then have a backup job running with GROUP1, while a restore job runs with GROUP2.
Storage Management
1255
Spanning Media Automatically

Media spanning means that when one media becomes full, the session will automatically span to another media. If you have a device group that consists of two or more devices, media spanning will occur across devices. That means, when one media in a group drive becomes full, the job spans to another media in another device within the same device group. For example, suppose you have two device groups; GROUP1 and GROUP2. GROUP1 consists of one storage device and GROUP2 consists of two storage devices. If you submitted a backup job that will take up two media, you can insert blank media in each GROUP2 drive and let BrightStor ARCserve Backup automate the media spanning for you. If you used GROUP1 for the same backup job, you will need to manually eject the first media and then insert a second media. As you can see, automated media spanning allows BrightStor ARCserve Backup to do most of the work for you.
Tip: There is only one rule when assigning storage devices to the same group: the devices in the group must be of the same make and model.
Viewing Media Information

When you highlight a storage device, or the media contained in a storage device, you can view two types of information: summary and detail. BrightStor ARCserve Backup displays general information about the media, such as the media name, sequence number, ID, and whether it is write-protected. Media characteristics are also displayed.
Maintaining Media
You can perform the following maintenance tasks on your media:

Formatting media Erasing data from media Re-tensioning a cartridge tape Compressing data on media Copying media
Important! Before you use these options, especially the destructive ones (formatting and erasing), make sure you have the right media selected.
1256
Administrator Guide
Formatting Media
Although BrightStor ARCserve Backup automatically formats blank media, you can manually format your media using Device Management. Formatting writes a new label at the beginning of the media, effectively destroying all existing data on the media. You must format your media before using it. You can use the GUI or the command line, using the following commands, to do this:
as_devmgr, ca_init
As formatting is completed, the media is placed in the Scratch set. When a backup is made on this media, it is automatically placed in the Save set. WARNING! Use media formatting with care! Once you format media, the data it contained (if any), and any job sessions associated with this media, are gone permanently. Media life is generally based on passes. A pass is defined as the storage device head passing over a given point on the media. For example, a backup without verification constitutes one pass, whereas a backup with verification constitutes two passes. Choose an expiration date based on how you will use the media. If you plan to use the media often, say, a few times a week, you should set the expiration date to a year from now, or even sooner than that. On the other hand, if you plan to use the media only once or twice a month, you can set the expiration date further into the future. When its expiration date arrives, you will still be able to use the media, but when you make a backup, for example, a note is made in the Activity Log that this media is expired. The expiration date is a way of tracking how long media has been in service so you can stop using it before it reaches the end of its useful life. If you are formatting new, blank media, the default expiration date will be one year from the current date. If you are reformatting media, the expiration date that appears will be the date you specified the first time the media was formatted. Note: You also use formatting through Device Management to add media to a media pool. For more information about how this works, see the section Define Media Pools and Rotation Schemes, presented later in this chapter.
Storage Management
1257
For Unicenter Tape Management Mode You can manually format any media that does not have a volume serial number, or that has an invalid volume serial number, but you must supply a valid six-character volume serial number to that media in order to complete the formatting. You can also manually format any media that already has a valid six-character volume serial number if that media is in the scratch set or is blank; however, the existing, valid volume serial number must be reassigned. When Unicenter Tape Management mode is active, media without a volume serial number, or with an invalid volume serial number cannot be moved into media pools.
Erasing Data from Media

WARNING! Use this feature with care! Once you erase data on media, the data is gone. Use erase to delete all data from media. BrightStor ARCserve Backup also erases all references to the contents of this media (if any) from the database. If you reformat this media, its physical history (read and write passes, and so forth) will be carried over. You can choose from three erase options: Erase Option Quick Erase Description A Quick Erase takes less time than a Long Erase because it only overwrites the current media label. Although, technically, there is still data on the media, the data is effectively gone without the media label. Quick Erase is useful if you want to re-use BrightStor ARCserve Backup media, but do not have time to wait for a Long Erase. Like Quick Erase, Quick Erase Plus erases the current media label. In addition, Quick Erase Plus also erases the serial number, so that you can assign a new serial number to the media.
Quick Erase Plus
1258
Administrator Guide
Erase Option Long Erase
Description A Long Erase completely removes all data from the media. It takes much longer than a Quick Erase, but the media is considered blank, as if it were just formatted. For security reasons, if you want to make sure that the data on the media is gone completely, use Long Erase.
When Unicenter Tape Management Mode is active, you can only erase media if it is in the Scratch set, and then any existing, valid volume serial number will remain; the media becomes blank, but retains the original volume label with the valid volume serial number.
If you reformat removable storage media using the Long Erase with NTFS option, all existing data on the storage media will be erased.
Re-Tensioning a Cartridge Tape

This feature applies only to quarter inch cartridge tapes. Use the re-tensioning feature to make sure a tape is evenly wound and properly tensioned. You can try re-tensioning a tape if you are having trouble writing to it or reading from it. When a tape becomes unevenly wound, it is prone to errors, can jam, or worse, break.
Compressing Data on Media

BrightStor ARCserve Backup supports compression. If your tape drive supports compression, you can tell BrightStor ARCserve Backup to turn it on. Normally, you will want to leave compression on. The only time you should turn it off is if you plan to use a tape in another drive that does not support compression. In this case, the drive that does not support compression will not be able to read the compressed data on the tape.
Tip: You can only change compression when a blank tape is in the drive. This prevents mixing of uncompressed and compressed data between sessions on a tape.
Storage Management
1259
Using Media-to-Media Copy

To duplicate data residing on a given media, BrightStor ARCserve Backup provides a media-to-media function. To make a media copy, you must have two drives that use the same type media. Additionally, the two drives must belong to different groups. You can only copy to blank media. If you insert media into the destination drive that has not been formatted by BrightStor ARCserve Backup, then BrightStor ARCserve Backup will assume that media is blank, and any information on that media will be destroyed.
Managing Removable Drives

BrightStor ARCserve Backup supports SCSI removable devices allowing you to back up data, restore data, scan sessions, merge removable sessions, and manage removable media on your removable devices. The BrightStor ARCserve Backup Manager identifies and treats the removable media as tape media. Note: For the most up-to-date list of certified devices, see the Certified Device List on the Computer Associates website http://esupport.ca.com. Before you can back up to removable media, you must do the following:

Enable your removable device Format your removable storage media Configure removable device groups
Important! Always use the BrightStor ARCserve Backup Device Manager to eject removable media if your device supports this feature. Enabling Removable Drives Before you can back up to your removable media, you must enable the drive so BrightStor ARCserve Backup can recognize it. You can do this by clicking the Disk Configuration icon and configuring the removable drive using the Administrative Tools.
1260
Administrator Guide
Formatting Removable Media Before you can back up to your removable media, you must enable the drive so BrightStor ARCserve Backup can recognize it. You can do this by clicking the Disk Configuration icon and configuring the removable drive by using the Administrative Tools. Note: Before formatting removable media, you must partition the media using the Windows windisk.exe utility (through Administrative Tools). Configuring Device Groups for Removable Devices You configure removable device groups using the BrightStor ARCserve Backup Device Management feature. Creating or deleting new removable device groups, renaming removable device groups, and assigning or removing individual devices is done easily with BrightStor ARCserve Backup. You cannot assign a removable drive into a group of tape drives. You must create a new group for the removable devices.
Managing Devices and Media in Unicenter Tape Management Mode

When Unicenter Tape Management mode is active, BrightStor ARCserve Backup uses a central Unicenter NSM database to manage and protect media. This database tracks media using the six-character volume serial number. Therefore, any media that is to be protected by Tape Management must be formatted with a volume label containing a valid volume serial number. You can use existing media that does not have a valid volume serial number for append-only backup jobs, but Tape Management will not protect this media. Rules for Volume Serial Numbers Use the following rules when assigning volume serial numbers to your media:
A valid volume serial number is six characters in length, and can be composed of alphabetic or numeric characters. Letters are not case sensitive; that is, b is the same as B. Once assigned, the volume serial number cannot be modified or removed from the media. The volume serial number can only be modified if it is invalid.
Storage Management
1261
Define Media Pools and Rotation Schemes
Media Pools for Unicenter Tape Management Mode Media in the Unicenter NSM database can be in one of two sets: Save set--The media is protected by Tape Management. Scratch set--The media is not protected. Media in the save set cannot be formatted or erased. Media in the Scratch set can be formatted, but must reuse the same volume serial number. Media in the scratch set can also be erased, but must retain the same volume serial number. Once media has been assigned a valid volume serial number, it cannot be removed. Activating Unicenter Tape Management Mode During asetup execution, you are prompted to indicate whether you want to use Unicenter Tape Management. If you answer yes, BrightStor ARCserve Backup modifies the ARCserve Backup.cfg file and adds the switch useUnicenterTapeManagement. If you answer no during asetup, you can modify the configuration file at a later time to add the switch.

A media pool is a collection of media managed as a unit. Each media pool is assigned a name and the media are organized according to the range of volume serial numbers the pool contains. The volume serial numbers assigned are permanent, and if you are using a device with a bar code reader, the bar code labels will be used for the volume serial numbers of the media. Media pools are divided into two sets, the save set and the scratch set. Media are assigned to the save set after a backup job has been completed. They stay there until eligible to be assigned to a scratch set after the retention time expires. Save set media are protected, and cannot be erased or overwritten unless first moved to the scratch set. Media in the scratch set are recycled reusing the oldest media in a scratch set first. Thus, in a GFS rotation scheme, a set number of media in a media pool are used for your backup jobs. If there are no media in a scratch set, BrightStor ARCserve Backup prompts for blank media. Each time media in the scratch set are written to, they move from the scratch set to the save set. The media will move back to the scratch set once the specified retention criteria have been met.
1262
Administrator Guide
When Unicenter Tape Management mode is active, media without a volume serial number, or with an invalid volume serial number cannot be moved into media pools. Media pools apply to every media, regardless of which backup type and method were selected.
Describing a Save Set

The media pool save set is a set of media that cannot be overwritten. You can modify save set information for all custom backup jobs. You can move media from the save set to the scratch set, and you can move media from one media pool save set to another media pool save set. You define the minimum number of media contained within the save set and its retention period. When that retention period expires, the media will eventually be rotated to the proper pool in the scratch set. BrightStor ARCserve Backup performs media pool maintenance at the beginning of a job, and does not allow media in the save set to be moved to the scratch set until two criteria are met:
The oldest tape in the save set is compared to the retention time and exceeds it. The minimum required numbers of media are in the save set.
Otherwise, BrightStor ARCserve Backup prompts for a blank tape, or will accept media from the scratch set. Note: In the Media Pool Manager, you can view the media available in a save set or a scratch set by opening the icon for that set in a media pool.
Describing a Scratch Set

The media pool scratch set is a set of media that has been recycled from the save set after its retention period has passed. All media in the scratch set will be overwritten the next time they are used. Those media that have not been formatted in the longest period will be used first.
Storage Management
1263
Specifying the Retention Period

The retention period is the number of days in which a media has not been used before it is moved into the scratch set. For example, if you specify a retention period of 14 days, a media will remain in the save set as long as it has been used within that specified time. If the media has not been used for 14 days, it will be moved to the scratch set. You can specify the minimum number of save media to be retained in the media pool, that is, the number of media to be retained in the save set before the older media are recycled to the scratch set. Specifying this number is a safeguard for preventing data loss if backups are not done for extended periods.
Creating a Media Pool

All rotation backup jobs automatically create media pools. A rotation backup job defines its media pool name from what you supply in the Media Pool Name Prefix field on the Schedule notebook page in Backup Manager. When you enable GFS, the same convention is used to define the media pool name. For a simple (single media pool) rotation, you specify the complete name for the media pool using the Media Pool Manager.
Supplying Serial Numbers

The serial numbers of media are used in categorizing media pools. One of the following methods can be used to create a serial number: Method Bar Code Description A number is read from a bar code label, assigning the serial number. A changer with a bar code reader is required for this method. This will override any previously-defined media pool settings. BrightStor ARCserve Backup automatically assigns a serial number based on the Base and Range of serial numbers set when the pool was created.
Automatic
1264
Administrator Guide
Note: You cannot change the serial number of media. However, you can add and modify the following serial number information fields on the Pool Configuration screen. Field Base Description This is the base number that BrightStor ARCserve Backup will use when automatically assigning serial numbers. The first media formatted will have the same serial number as the Base number. Each medias serial number thereafter will be incremented by one. You can specify the range (up to 31 digits) from which the media pool serial numbers will be categorized. For example, if you specify 200000 as the range for all media in the MKTG media pool, all numbers that fall into the 200000 range will be categorized in the MKTG media pool.
Range
Assigning Media to a Media Pool

You can assign media to a media pool during the process of formatting. When you format media using Device Management, you define certain media pooling information that will be associated with the media. You can define the following media pool information: Field New Media Name Description If the media inserted in the storage device is named, that name will be displayed. If the media is blank, you can assign a name. If the media is blank, but has an assigned serial number, it can be assigned to any existing media pool. You can set an expiration date for the media to be formatted. When this date arrives, BrightStor ARCserve Backup will remind you that the media has reached expiration. You can select any existing media pool previously created using the Media Pool Manager. The serial number is the current serial number, bar code label, or the next available serial number (based on predefined rules). You can manually enter a different serial number only if that number is not already in use. BrightStor ARCserve Backup scans the database, and if the serial number already exists (in any of the media pools), produces an error message requesting you to enter a new serial number.
Expiration Date Media Pool Serial Number
Storage Management
1265
Using the Media Pool Manager

The Media menu for Media Pool Manager can be invoked as a pop-up menu by selecting a media pool in the left panel and then clicking the right mouse button. The Media Pool Manager helps you perform the following tasks:

Create a media pool. Delete an existing media pool. Move media in a pool from scratch set to save set and conversely. Perform location maintenance. View and reconfigure media pool properties such as: Media name, serial number and random ID number Name of media pool to which media belongs Expiration date of media Date first formatted Date last formatted Date media was sent Date media was last read
You can assign or reassign offsite locations to media using the Media Pool Manager. You can also enter new locations or modify the information about existing locations.
Defining a Simple Rotation Scheme

You can define a rotation scheme for a backup job using the BrightStor ARCserve Backup default scheme, or by specifying your own rotation parameters. Configuring a simple rotation scheme consists of specifying one of the following parameters for a backup on a given calendar day:

Full backup--Performed each time the job is repeated. Incremental backup--Backs up only those files that have changed since the last full or incremental backup was done. Differential backup--The backup is performed daily after one weekly full backup.
1266
Administrator Guide
The following events occur for Windows: A full backup will be made of the job and all archive bits will be cleared. The next day, the differential backup backs up files that have their archive bit set. (The archive bit will not be reset after the backup.) The following day, the differential backup contains all files that have their archive bit set from the previous two days.
The following events occur for UNIX/Linux: A full backup will be made of the job and all dates and times are recorded. The next day, the differential backup will back up files that have their dates and times changed. (The dates and times will not be recorded after the backup.) The following day, the differential backup will contain all files that have their dates and times changed from the previous two days.
Note: You can use the Calendar View to customize your rotation scheme according to the types of backups you want for particular days of the week or month. This feature enables you to specify exceptions to the standard rotation scheme you are using.
Using the GFS Rotation Scheme

The Grandfather-Father-Son (GFS) rotation scheme is a set of predefined backup jobs consisting of full backup jobs combined with incremental and differential jobs. BrightStor ARCserve Backup lets you select from these predefined backup jobs on the Schedule tab of the Backup Manager when you select Use Rotation Scheme. GFS backup jobs are based on a five or seven-day weekly schedule beginning any day. A full backup is performed at least once a week. On all other days, full, partial, or no backups are performed. The daily backups are the Son. The last full backup in the week (the weekly backup) is the Father. The last full backup of the month (the monthly backup) is the Grandfather. GFS rotation schemes allow you to back up your servers for an entire year using a minimum volume of media.
Storage Management
1267
Using GFS rotation, you can restore data reliably for any day of the week by using the weekly full backup in conjunction with the daily incremental or differential backup jobs. In incremental backup jobs, the archive bit is cleared after every incremental backup job. Thus, only files that have changed since the last incremental job are backed up. In GFS rotation schemes using differential daily backup jobs, only the files that have changed since the last full backup job are backed up. Since differential backup jobs do not clear a files archive bit, the files that were backed up in the last differential job are backed up. Using this scheme, the backup jobs require more time to process than incremental backup jobs. However, this strategy requires less effort to restore servers and workstations because you may need fewer tapes to restore your machines.
Exceptions
You can deviate from your standard rotation scheme (for instance, if a holiday falls on Wednesday, your usual backup day). An exception is handled from the Backup Manager by selecting Use Rotation Scheme, and then selecting Exceptions. (Similarly, exceptions can be removed.) To review each backup method, see the section Backup Methods.
GFS Media Names When media are assigned to a GFS rotation media pool, BrightStor ARCserve Backup automatically assigns a name to each and labels each with the backup type, date, and usage. This media naming convention allows administrators to easily identify backup media. Media for GFS rotation schemes are automatically named using the following syntax:
bt-pp-day-date
where: bt Specifies the backup type. Valid types are listed following: F Specifies a full backup. I Specifies an incremental backup. D Specifies a differential backup. W Specifies a weekly backup. M Specifies a monthly backup.
1268
Administrator Guide
pp Specifies the pool prefix, which is the name you assigned to the media pool for your GFS rotation scheme. day Specifies the abbreviation for the day of the week on which the job was performed. date Specifies the date on which the backup was performed in mm/dd/yy format. For example, the media used for the first backup in your rotation scheme will have the following name:
F-TP-MON-11/1/02
where: F Specifies a full backup. TP Specifies the name of the media pool assigned for the GFS rotation scheme MON Specifies Monday, the day on which the rotation scheme starts 11/1/02 Specifies the date on which the job runs. GFS Media Pools When you schedule a backup using the GFS rotation scheme, BrightStor ARCserve Backup automatically creates three media pools: daily, weekly, and monthly. BrightStor ARCserve Backup maintains individual media in the appropriate pool for each backup type. These pools are named according to the Media Pool Prefix you supply in the Schedule dialog. For example, if you were to supply BK as the Media Pool Prefix, the following media pools would be created in your GFS rotation schemes: Pool name BK_DLY BK_WLY BK_MLY Description Daily incremental, differential, or full backup media for the BK media pool Weekly full backup media for the BK media pool Monthly full backup media for the BK media pool
Storage Management
1269
Each media pool has its own Scratch set and Save set with a default retention period and minimum number of media to save. The retention period for media depends on the type of GFS rotation scheme you are using, that is, a five-day GFS rotation scheme or a seven-day rotation scheme, and the media pool to which the media is assigned, daily (_DLY), weekly (_WLY), or monthly (_MLY). Five-day GFS rotation schemes have the following retention times for each media pool:
Daily (_DLY): Six days (Daily media in seven-day rotation schemes has a retention time of eight days.) Weekly (_WLY): Five weeks Monthly (_MLY): 343 days
If, for example, you have a daily incremental backup job for a five-day GFS rotation scheme on the media I-SAMPLE-TUES-9/09/02, the media remains in the Save set for six days. The media will be overwritten when the same job runs again the following Tuesday. The new name for the media will be I-SAMPLE-TUES-9/14/02. The following are the formulas used for calculating the number of media in the Save sets and the retention times for the GFS media pools:
Daily Pool: This pool holds the media for daily backup jobs. The default retention period is six days and the number of Save set media is based on the number of daily media in the GFS rotation minus one [# of daily media -1]. For example, if you are using the five-day GFS rotation scheme, in which you preserve six daily media, the number of Save set media in the GFS Daily Media Pool would be five: six daily media minus one. It meets the criteria to be moved from the Save set to the Scratch set after six days have passed since the media was used (on the seventh day).
Weekly Pool: This pool holds the weekly media. The retention period equals the number of weekly media times seven, minus one [(# of weeklies * 7) - 1]. The number of save media is based on the number of weekly media in the GFS setup minus one [# of weekly media - 1]. For example, if you were using the seven-day GFS rotation scheme, in which you preserve five weekly media, 34 days would be the length of the retention period (5 times 7 minus 1). In the same example, four would be the number of save media in the GFS Media Pool (5 weekly media minus 1). After 34 days since the media was used (on the 35th day), it can be moved to the Scratch set, provided there are four other media in the Save set of the Weekly pool.
Monthly Pool: This pool holds the monthly media. The retention period equals the number of monthly media times 29 minus five [(# of monthlies * 29) - 5]. The number of save media is based on the number of monthly media in the GFS setup minus one [# of monthly media - 1].
1270
Administrator Guide
For example, if you were using the seven-day GFS rotation scheme, in which you preserve 12 monthly media, 343 days would be the length of the retention period (12 times 29 minus 5). In the same example, 11 would be the number of save media in the GFS Media Pool (12 monthly media minus 1). After 343 days since a media has been used, it can be moved to the Scratch set, provided there are 11 media in the Save set of the Monthly pool. Note: If you preserve one media each month (12 monthly media), the retention period is 343 days, using the (12 *29)-5 formula, which takes into account months with differing number of days. You can change retention times in the Media Pool Manager. Customizing GFS Rotation Schemes Although GFS rotation schemes are predefined, you can modify these schemes to suit your individual needs as an administrator. You can use the following tabs on the bottom of the Schedule tab of the Backup Manager to customize your GFS rotation jobs:
Exceptions: Defining particular days on which the back up type and the execution time or date differs from the pre-existing schemes. You can also select specific days off. You can define different backup criteria for days in your rotation on which you want to deviate from the standard scheme, such as a vacation day. Rotation Rules: Customizing rotation rules that differ from the predefined GFS rotation schemes. As an alternative to selecting Remove Exceptions from the Calendar View, you can remove exceptions using the Exceptions dialog. Calendar View: Customizing individual days in the Calendar view. With GFS rotation either enabled or disabled, you can use the Calendar View feature to customize your rotation scheme according to the types of backups you want for particular days of the week or month:
Storage Management
1271
Media: Appending the new sessions to existing media with data. At the beginning of the week or for a full backup, BrightStor ARCserve Backup formats an appropriate tape (from the Scratch set or a blank tape). For every Differential or Incremental backup after a full backup, BrightStor ARCserve Backup formats a blank tape or one from the Scratch set.
Sample GFS Rotation If you were using the five-day incremental GFS rotation scheme as your backup strategy, the media would be used in the following manner during the month of September:
1272
Administrator Guide
Manage and Report on the Database

The BrightStor ARCserve Backup database records job information for each job that is run, including media and media device information. The database information allows you to perform intelligent restores by keeping track of each file and directory that was backed up to media. When you want to restore a specific file, the database determines which media contains the file. The database information is also used to generate many types of reports that BrightStor ARCserve Backup provides. See the section Viewing and Printing Reports, presented later in this chapter.
Opening the Database Manager

The Database Manager lets you do the following:

Keep track of the location of your media. Determine the session number of your backup. Determine whether media should be retired. View log information about jobs that you have run. Delete old records from the database. Compare the size of your database to the total available disk space using graphics.
Note: The database size reported by the BrightStor ARCserve Backup Database Manager is the size of the data device (not including the log). You can obtain this information by entering the following command in the SQL Enterprise Manager:
sp spaceused
When you open the Database Manager from the Quick Access window, the Summary View is shown. This view shows how much space the database occupies on your hard disk. Selecting a Database View You can change the database view by selecting a new view from the drop-down menu. The following database views are available:

Summary View Job View Media View
Storage Management
1273
Client View Device View
Changing the Sort Order You can change the sort order of records displayed in the Job View, Media View, and Device View windows by clicking the field name by which you want to sort. Re-building the SQL Index We recommend that you re-build the index periodically to keep the index size manageable. The index should be updated after running an overnight job in order to keep the database size small.
Tip: You should update the index statistics from time to time (run asdbupdate_all_stats in asdb).
If you do not have enough time to update all the indexes, update the key index IX_astpdat_1. This index plays an important role and affects the browsing speed dramatically in the Restore Manager and Database Manager. Pruning Your Database You may want to set BrightStor ARCserve Backup to prune old records from the database. For more information, see the section Administer the BrightStor ARCserve Backup Server, presented later in this chapter. Jobs processed by BrightStor ARCserve Backup can be viewed in the following ways:
Job View--Displays information about jobs processed by BrightStor ARCserve Backup. Media View--Displays information about the media used with BrightStor ARCserve Backup. This includes information about formatting, how much the media has been used since it was put into service, and number of errors (if any) that have occurred while BrightStor ARCserve Backup was using the media.
1274
Administrator Guide
Device View--Displays information about the media devices used with BrightStor ARCserve Backup. You can display the Error Log to view information related to any device problem detected by BrightStor ARCserve Backup.
You can view additional details about media. This includes how many errors BrightStor ARCserve Backup encountered while reading from or writing to the media, how much data (total) was written to the media, and the number of read and write passes BrightStor ARCserve Backup made over the media. Additionally, you can see a list of the sessions that were created on the media and a list of files backed up for each session. The following table describes the statistical information that is available about the database. Statistics Media Errors Explanation Indicates that some sort of data corruption has occurred on the media and the read or write operation could not be successfully completed. An error has occurred while reading the media. BrightStor ARCserve Backup has attempted to correct the problem in real time. A higher number of soft read errors indicate possible defective media. Media should be replaced for any future backups. A write error has occurred during the backup. BrightStor ARCserve Backup is correcting the media problem in real time. A high number indicates the media should be replaced for future backups. Make sure the drive heads are cleaned after the current backup session has been completed.
Soft Read Errors
Soft Write Errors
Error Log Information
The following table describes the information provided by the Error Log:
Field Code Time Sense Info Media Soft Write
Description Type of error: hardware or media Time the error occurred SCSI error code Number of media errors that occurred during the job Number of soft write errors
Storage Management
1275
Microsoft SQL Server Support
Field Soft Read Media Usage KB Written Times Formatted
Description Number of soft read errors that occurred during the job Amount of time the media was used during the job Amount of data written to the media during the job Number of times media has been formatted
Microsoft SQL Server Support

You can choose one of two database options when you install BrightStor ARCserve Backup: the standard BrightStor ARCserve Backup database, or Microsoft SQL Server 6.5. Note: For the SQL database to function properly, you must start it in Microsofts SQL Service Manager.
Supplying SQL Connections

For each job that you run, you need two SQL connections. Be sure that you have set enough connections (or licenses) in your SQL server. To determine your default SQL connections, from the SQL Enterprise Manager select Server and SQL server. When you browse from the configuration tab, you will view the user connections. Set these values to the appropriate user setting. If either error message, Cannot update record, or Failed to login appears, you may have run out of the connections.
Running a Database Consistency Check

When your database activity is not high, we recommend that you run a Database Consistency Check if you have a large database. Although it takes some time, it is important to determine that your SQL database is functioning correctly. For more information, see your Microsoft SQL documentation.
Logs and Reports

BrightStor ARCserve Backup provides access to a number of logs and reports using the Report Manager.
1276
Administrator Guide
Logs and Reports
BrightStor ARCserve Backup Logs

BrightStor ARCserve Backup provides the following logs:

Activity Log--Logs all BrightStor ARCserve Backup activity. Job Log--Logs activity related to a specific job. Tape Log--Logs all tape activity (for debugging purposes only). Important! You must monitor the log size periodically to be sure that the log does not become full. If a log is full, the database cannot function. Although the default setting is truncate log on checkpoint, you should increase the log size to 50% of the database if you expect to prune a large number of records.
Media Server Log--Provides an audit trail of all BrightStor ARCserve Backup Media Server activity, including when the Media Server is loaded and unloaded. (This log is the equivalent to the Tape Log found on Windows platforms). Database Log--Contains information pertaining to all possible database activities including Backups, Media Pool operations, Media formatting, and GFS operations. (For debugging purposes only). Queue Scheduler Log--Provides basic information about all of the jobs in the BrightStor ARCserve Backup job queue including, sources destinations, execution dates and times, and pre/post execution commands. You can view this log to get an inventory of the jobs in the job queue. You can also use this log to see what jobs other BrightStor ARCserve Backup users have submitted.
Discovery Log--Provides all basic domain related information. It also includes all available servers within a domain. ARCserve Backupd Log--Contains comprehensive information about all BrightStor ARCserve Backup daemon activity. This log indicates what tasks that daemon is performing. Authentication Log--Contains comprehensive information about the security operations performed by BrightStor ARCserve Backup. It provides an audit trail of all BrightStor ARCserve Backup security activity, including the identity and validity of all authorized BrightStor ARCserve Backup users logged on and unsuccessful attempts to log into the program. GFS Rotation/Rotation Daily Log--Helps you manage your GFS backups. It gives you information about your previous backup and helps you prepare for your next backup. All GFS Daily Log files have a .DLY extension. The file name is the set name. If you are running GFS rotation jobs, you should look at this log each day so that you can physically label your media and retrieve the media that is needed next.
Storage Management
1277
Logs and Reports
GFS Rotation/Rotation Full Log--Contains all of the Daily Logs for a GFS set. It provides the history of a GFS rotation set, including the dates of each GFS rotation backup and the media used. Each GFS rotation set has its own Full Log. The Full Log does not contain the current Daily Log. All GFS Full Log files have a .FUL extension. The file name is the set name. You can view this log to get a get a general idea of what has been backed up. You may need to do this if you need to restore files from a GFS backup.
User Log--Contains a listing of any error messages that can arise during any backup jobs submitted by a particular user.
Activity Log
The Activity log contains comprehensive information about the operations performed by BrightStor ARCserve Backup. It provides an audit trail of all BrightStor ARCserve Backup activity, including every job that is run. For each job, the log includes the following:

Time the job started and ended Type of job Average throughput of the data Number of directories and files processed (backed up, copied, and so forth.) Job session number and Job ID Result of the job Errors and warnings that occurred
You can scan this log every day to see if any errors have occurred. You can also use it to find out a session number in case you need to restore a specific session.
Job Log
A Job Log is generated for each job that is executed by BrightStor ARCserve Backup. You can specify the level of detail in the log by choosing Job Log options before you submit the job.
1278
Administrator Guide
Logs and Reports
The Job Log options are listed following: Option Log All Activity Log Summary Only (default) Log Disabled Description Record all of the activity that occurs while the job is running. Record summary information of the job (including source, destination, session number, and totals) and errors. Do not record any information about this job.
See the instructions for configuring and viewing the Job Log in the online CA Procedures.
Tape Log
The Tape Log contains messages sent by the tape drives to BrightStor ARCserve Backup. This log is not generated during normal operation. It is designed for debugging purposes only.
Media Server Log

This log provides an audit trail of all BrightStor ARCserve Backup Media Server activity, including when the Media Server is loaded and unloaded. You should only need to view this log if you are having unexplainable errors when you try to run a backup. The log contains information about media jobs, including:

Backups Formatting Re-tensioning Erasing
For each job, the log includes the following:

Date and time the job started and ended ID number of the job Detailed activity of the media service (asmediad) Any errors that occur; errors are displayed in red.
Storage Management
1279
Logs and Reports
Viewing Reports Using the Reports Manager

The Reports Manager allows you to view and print a variety of reports based on information in the database. The Report Manager also provides a few functions to help manage both reports and logs: Cancel Delete Filter Clear Cancels the report currently being generated. Deletes the entire log. Allows the filtering of the contents of a log based on its date. Deletes all of the information from a log when clicked.
The following reports are available for viewing through the Reports Manager. Job Report This report provides a brief listing of all jobs that have been run by BrightStor ARCserve Backup. It contains the information that is found in the Database Manager on the Job View window. For each job, this report lists the following information: job ID, job type, job status, start time, submitter, and description. Note: On the UNIX/Linux platform, this report is titled, Job Records Report. Media Report This report provides information about your BrightStor ARCserve Backup media. It contains the information found in the Database Manager on the Media View window. You must select media before you can generate this report. This report includes the following: media name, ID, and sequence number; media type; usage time; creation, format, and expiration date; amount of data written to the media; number of errors; usage statistics. Note: On the UNIX/Linux platform, this report is titled Media Records Report.
1280
Administrator Guide
Logs and Reports
Media Session Report This report provides information about all of the backup sessions that are on media. (Each source you select to back up is saved on media as an individual session.) The report contains the session information found in the Database Manager on the Job View or Media View window when you highlight a record and click the Session tab. When you go to view this report you will be asked if you want the report to include all media or just one that you select. For each media session, this report includes the following: session number, status, source selected, start time, end time, session method, flags, total files/KB in the session. Note: On the UNIX/Linux platform, this report is titled, Media Sessions Report. Media Session Detail Report This report includes all of the information found in the Media Session Report and lists every file that was backed up in each session. The report contains the session information that is found in the Database Manager on the Job View or Media View window when you highlight a record and click the Files tab. When you attempt to view this report, you will be asked to select a media and a session from that media. Storage Device Report This report provides information about all of your BrightStor ARCserve Backup storage devices. It contains the information that is found in the Database Manager on the Device View window. This report gives you a convenient way of getting a hardcopy printout of your Device View information. When you attempt to view this report you will be asked to select a storage device. For each storage device, this report includes the following: vendor, firmware revision, SCSI ID, device type, last head cleaning date, head cleaning count, amount of usage, and errors. Enterprise Job Status This report provides Enterprise job statistics. The Enterprise Job Status Report contains information about the jobs that have been run by all the servers within a specific period. The information includes server name, job ID, start time, time elapsed, job status, and submitter, along with session numbers and file statistics for each job.
Storage Management
1281
Logs and Reports
Media Pool Report This report provides information about your media pools. This information includes pool name, date activated, serial number ranges, as well as the media properties of the tapes contained in the pool. GFS Rotation Profile Report This report displays GFS rotation information. The information in this report includes data on the media in the Scratch and Save sets, media pool name, number of media in each set, tape names, backup method for each media (Full, Incremental, or Differential), status, and location. This report also contains the source, session number, and file statistics for each media. GFS Media Prediction Report This report displays a forecast by name of the media you will need. You can specify a number of days into the future from the time at which you run the report. Rotation Job Report This report provides a brief historical record of all rotation backups performed on a target. The report lists the set the target belongs to and each of the backups that were performed. For each backup, the media name, date, session number, backup type, status, number of files backed up, and the amount of data backed up is listed. GFS Rotation Job Report This report provides a brief historical record of all GFS backups performed on a target. The report lists the set the target belongs to and each of the backups that were performed. For each backup, the media name, date, session number, backup type, status, number of files backed up, and the amount of data backed up is listed.
1282
Administrator Guide
Administer the BrightStor ARCserve Backup Server

The BrightStor ARCserve Backup Server consists of the following functional engines:
Job Engine--Controls the execution time of jobs in the job queue. It scans the job queue regularly and launches jobs as their execution dates and times are reached. Tape Engine--Identifies the storage devices that are connected to your system and activates each when a job requiring it is started. Database Engine--Stores all of the important information that BrightStor ARCserve Backup needs. Some of the information saved to the database is as follows: Files and directories that have been backed up, copied, and restored Jobs that BrightStor ARCserve Backup has processed Storage devices and media used for BrightStor ARCserve Backup operations
The BrightStor ARCserve Backup Server Admin lets you configure each engine to suit your needs. To configure the BrightStor ARCserve Backup engines, select Configuration from the Admin menu.
Configuring the BrightStor ARCserve Backup Job Engine

Your configuration options for the Job Engine include the following:
Job Queue Scanning Interval (seconds)--The Job Engine constantly scans the job queue for jobs that should execute. By default, the job queue is scanned every 10 seconds. To change the time interval, specify a number from 1 to 999. Retention Time for DONE Job (hours)--Jobs with a final status of Done remain in the job queue for the time specified in this field. By default, BrightStor ARCserve Backup keeps Done jobs for 24 hours before they are deleted from the queue. To change the time, specify a number between 0 and 999. Message Type in Activity Log--The Activity Log contains information about all BrightStor ARCserve Backup activities. By default, notes, warnings, and errors that occur when running BrightStor ARCserve Backup appear in its Activity Log.
Storage Management
1283
To change the types of messages, specify one of the following values: Value None Errors Warnings & Errors Notes, Warnings & Errors Debug Description No messages appear. Only errors that occur will appear. Warnings and errors that occur while running BrightStor ARCserve Backup will appear. The default selection; includes all notes, warnings, and errors. Only debugging information will appear. This should only be used for troubleshooting purposes.
Configuring the BrightStor ARCserve Backup Tape Engine

Important! We recommend that you do not change the configuration of the Tape Engine unless you are having problems with your storage devices. Keep the default configuration for the Tape Engine, except for troubleshooting purposes. The following Tape Engine configuration options are available:
Message Level--The value you specify for this field determines whether you need to specify values for the other fields in this dialog. If you keep the default (None), you do not need to specify anything else. If you specify a different Message Level, BrightStor ARCserve Backup will monitor the Tape Engine and log all information in a Tape Engine Log. To change the message level, specify one of the following: Value None Detail Description The default value; nothing is logged. Every message sent by the drives is logged.
Message Output--If you specified Detail in the Message Level field, you can specify where you want the messages sent. Specify one of the following: Value Both Screen and File Screen Only Description The messages are recorded in the Tape Engine Log as well as to a DOS box (the Tape Engine Message window). The messages are sent to the Tape Engine Message window only.
1284
Administrator Guide
Value File Only
Description The messages are recorded in the Tape Engine Log.
Device to Monitor--If you specified Detail in the Message Level field, you can specify which device(s) you want to monitor. To specify the device, select one of the following: Value All Devices The Device to be Monitored Description All the SCSI devices connected to your machine will be monitored. Select this option to monitor only one device. Use the drop-down list of devices to select one device.
Configuring the BrightStor ARCserve Backup Database Engine

The following Database Engine configuration options are available on Windows platforms: Option Database Buffer Size (Kbytes) Description By default, BrightStor ARCserve Backup uses a buffer that is 300 KB for recording information in the database. To change the size of the buffer, select an available size from the drop-down list. Specify the minimum amount of disk space (in MB) you want to reserve for the BrightStor ARCserve Backup database. By default, 5 MB of disk space is specified. To change the amount of disk space, specify a number between 1 and 10. Information regarding the files and directories that were backed up in a session is deleted when database pruning is done. By default, this option is selected. It is useful to maintain the detailed information for restoring purposes. However, not pruning your database can mean that it fills quickly. Set this option to On to free up space in the database. This field is active only if the Enable Database Pruning option is on. By default, the record will be pruned (if enabled) after it has been in the database for 30 days. To change the length of time, specify a number between 1 and 365. This option is operational only on the standard BrightStor ARCserve Backup database.
Minimum Free Disk Space Required (Mbytes)
Enable Database Pruning
Prune Database Records Older Than __ Day(s)
Storage Management
1285
Option Run Database Pruning at __
Description This field is active only if the Enable Database Pruning option is on. Specify when you want the pruning operation to run. By default, pruning (if enabled) will occur at 12:00 am. When you reformat or erase media, BrightStor ARCserve Backup will delete the records in the database that pertain to the media. Performing this extra step, however, can be a time-consuming process. When running an Overwrite Media job, select this option to postpone deleting these records until pruning is performed. This option submits a database pruning job to the BrightStor ARCserve Backup job queue with the specified parameters immediately.
Delete Media-Related Database Records ONLY when Pruning
Submit Database Pruning now
1286
Administrator Guide
The following Database Engine configuration options are available on the UNIX/Linux platform: Option Auto Prune Jobs Description Pruning preserves all job and session records, but removes all details about files that were included in the backup sessions. If you have old job records in the database, but you think you may someday need to restore data from those old jobs, you should enable pruning, not purging. Though all file details will be pruned from the database, you will still be able to restore entire sessions. By default, this option is not selected. Prune job records older than: This field is active only if the Auto Prune Jobs option is on. By default, the record will be pruned (if enabled) after it has been in the database for 6 months. Pruning of selected files begins at the time set in the Starting daily at field. Purging completely deletes all traces of a database record, including session and file information, with the exception of GFS rotation jobs. This field is active only if the Auto Purge Jobs option is on. By default, the record will be purged (if enabled) after it has been in the database for 12 months. Purging of selected files begins at the time set in the Starting daily at field. This field enables you to restrict the size of the BrightStor ARCserve Backup database. By default, there is no limitation enforced on the amount of data to be written to the database. A limit can be set by using the arrow keys associated with this field or by manually entering a value.
Auto Purge Jobs
Purge job records older than:
Maximum Database Size (MBytes)
Storage Management
1287
Viewing Information About the BrightStor ARCserve Backup Engines

Use the BrightStor ARCserve Backup Server Admin to view information related to the BrightStor ARCserve Backup engines. The Server Admin presents the following tabs: Tab Label Summary Job Engine Tape Engine Database Engine Description Shows you the current state of all BrightStor ARCserve Backup engines. Displays information about jobs, such as the number of active and pending jobs. Displays information about jobs using the tape engine, such as the type of job and who submitted it. Displays database statistics and database pruning status.
To view information about an individual engine, launch the BrightStor ARCserve Backup Server Admin program and select the specific engine menu tab.
Understanding Engine Status

What happens when an engine is stopped? A stopped engine is one that is completely offline. Errors, manual shutdown, or a new installation can cause this condition. Whatever the reason, it means that the services of that engine are not available. These engines are designed to run independently of each other. If you stop the Tape Engine, the Database Engine and the Job Engine are not affected. They continue to run, providing and performing their services as configured. The Database Engine continues to log pertinent BrightStor ARCserve Backup information in the database, and the Job Engine continues to scan the job queue and launch jobs as required. If a job requires a storage device, the Job Engine launches the job as usual, but the job will fail because the Tape Engine is not there to communicate with the storage device. The Database Engine then logs this information. Note: Although BrightStor ARCserve Backup still functions if one or two engines are not running, BrightStor ARCserve Backup needs all three engines running simultaneously to achieve complete functionality. On the UNIX/Linux platform, all BrightStor ARCserve Backup engines are daemon processes that are referred to as Services.
1288
Administrator Guide
Using the BrightStor ARCserve Backup Manager

You can control select BrightStor ARCserve Backup services from any of the BrightStor ARCserve Backup Managers. The back-end services accessible from each BrightStor ARCserve Backup Manager window include the following:

Queue service Media service Database service
In addition to controlling these services, you can start or stop all of the back-end services running on a host server by selecting Start All Services or Stop All Services. Methods for Accessing Back-end Services You can access the selected services of a BrightStor ARCserve Backup server from the BrightStor ARCserve Backup File Menu, or using the service icons found on the BrightStor ARCserve Backup Status Bar (located at the bottom of each Manager window). Depending on the state of the service, the service icons will be displayed using the following colors: Color Green Red Yellow Status Service is running. Service is down. The ARCserve Backupd daemon is either down, or the connection to it is broken. Since the ARCserve Backupd daemon supplies all daemon status for a selected host server, the status of each daemon is therefore unknown.
Once a service icon is selected, a dialog is presented where you can start or stop the selected service, start or stop all services associated with the host server, or see a detailed status listing of all the services on the server. When you select a detailed listing of the services running on a particular server, the information displayed includes the following:

Service name State Program number Version
Storage Management
1289
Host Protocol Registration
Selecting the Network Shares Browser Option

The Network Shares Browser option determines how the network is displayed in the Browser. The available options are listed following: Browser Option Use All Shares Use Default Shares Only Use Users Shares Only Description Displays administrative and user shares. This is the default. Displays only administrative shares. Displays only shares that users have specifically set.
Recording Hard Links for NTFS Volumes

If you back up files that have hard links, this information is included and preserved by default.
Confirming When Overwriting Media

When you need to overwrite media, you can have BrightStor ARCserve Backup prompt to confirm that you really want this to happen. By default, this option is not set. If you set this option, BrightStor ARCserve Backup produces a confirmation dialog and waits five minutes for your response. If you still have not confirmed after five minutes, the job is canceled.
Backing Up the Windows Registry

By default, when you select an entire machine to be backed up, BrightStor ARCserve Backup will back up the Windows machines vital system information and its registry. When the option is turned on, it will back up the Windows registry details (key-by-key) onto the storage media if an entire machine (remote or local) is selected. For more information on the Windows registry and registry keys, see your Windows documentation.
1290
Administrator Guide
Use the Alert Manager
Using Alert with the Logs

The Alert tab menu acts similar to a text search function. You can have the Alert program send an alert message if the BrightStor ARCserve Backup Server comes across a specified message from within the BrightStor ARCserve Backup logs. However, you must first install and set up the Alert option before this selection will work. For more information on how to install and configure Alert, see the section Use the Alert Manager, presented later in this chapter.
Changing the BrightStor ARCserve Backup System Account

The BrightStor ARCserve Backup Server requires a valid user account on the host Windows machine. You must enter a system account during the installation program. You can change the system account at any time through the BrightStor ARCserve Backup Server Admin program.
Setting the Database Access Mode

To set the particular database access mode, select Database Access Mode from the Operation menu. This option is only applicable when using the default BrightStor ARCserve Backup database.

Alert is a notification system that sends messages to personnel in your organization using various methods of communication. Alerts can be sent to the system administrator, a hardware technician, or anyone else, in or out of the office. An individual or groups of persons in different segments of the network can also be notified. In order for BrightStor ARCserve Backup to generate alerts, you must tell Alert what information is necessary to communicate. For example, if you are using the pager system, you must tell Alert what pager number to dial, and supply information about your modem. All of this information must be configured in the Alert program on your server.
Storage Management
1291
Alert does not generate its own messages. Alert routes messages, errors, or warnings it receives from different sources, including BrightStor ARCserve Backup, and distributes these alerts to specific destinations. For example, BrightStor ARCserve Backup generates warning messages whenever a virus is detected. These warning messages are passed to Alert, which sends the notification.
Tip: Microsoft Exchange Mail SetupYou can use either the Alert Setup program or the Exchange Mail Setup option in the Alert Manager File menu to configure Microsoft Exchange Mail for use with Alert.
The following table lists the methods by which alerts can be sent: Method Broadcasts Pager Trouble Tickets Simple Network Management Protocol (SNMP) Event Log Notification Unicenter Option Electronic Mail Description Alert broadcasts can be sent to specific computers. Numeric and alphanumeric are supported. An alert can be directed to any print queue on your network. Managers, such as NetWare Management System (NMS) and HP OpenView, can be used. Local and remote Windows Event Log Notification are provided. Send a message to the Event Console or World View repository when an alert is generated. Microsoft Mail, Microsoft Exchange, and Lotus Notes are supported.
Understanding Basic Components of Alert

The following table describes the basic components of Alert: Component Alert Service Description The service responsible for the reception, processing, and distribution of Alert messages.
1292
Administrator Guide
Component ALBUILD.DLL
Description The .DLL that acts as the channel between Alert and other applications. This should be located in the BrightStor ARCserve Backup home directory. The application profile file. This file is provided by an application (such as BrightStor ARCserve Backup, which creates an ARCSERVE BACKUP.ALT file). This .ALT file must be present in the Windows directory in order for Alert to handle messages generated by an application. You can use this component to configure how Alert sends its messages.
*.ALT
Alert Manager
Running the Alert Manager

You can run Alert from the BrightStor ARCserve Backup program group by selecting Alert Manager. You can use the Alert Manager to select a remote machine to manage Alert messages. Before you start Alert, you must establish a Service Account connection and select a remote machine.
Configuring Alert
Alert lets you configure default settings used by all applications that use the Alert Service. You can also enter configuration information specifically for an individual application, which will override the default Alert configuration. Each application that uses Alert is displayed as a leaf on the leftmost function tree. Creating and Editing Port Configurations The Ports object, located under the Configuration object, contains communication port profiles. The following Port specifications are used by the Pager and any other function that utilizes serial port access: Specification Port Baud rate Parity Description Name of the communications port you want the pager message to be broadcast from The baud rate being used by your modem The parity setting of your modem (none, odd, or even).
Storage Management
1293
Specification Data bits Stop bits
Description The number of data bits that your modem uses (7 or 8). The number of stop bits that your modem uses (1 or 2).
Using the Broadcast Option of Alert

You can send Alert broadcasts to specific network users or groups. See the instructions for adding broadcast recipients in the online CA Procedures.
Using the Pager

Use the Pager option to a send a numeric or alphanumeric pager message. When you highlight the Pager option, the current list of recipients appears. See the instructions for adding Pager recipients the online CA Procedures.
Tip: Before you can add pager recipients, you need to configure your communications ports.
Note: When sending an alphanumeric page, consult your pager manual for proper modem settings. Interpreting the Pager Message Several messages, similar to those listed following, can be sent to an alphanumeric pager. Words that appear in italics are substituted with specific information.

Boot Virus Detected - username at workstation_address Manager Detected a Virus virusname in path - username at workstation_address Infected File servername/path Detected Infected File path Accessed by username at workstation_address
Using the SNMP Option

You can use the SNMP option to send an SNMP trap (message) to an SNMP manager. Examples of SNMP managers include NetWare Management System (NMS), HP OpenView, and IBM NetView.
1294
Administrator Guide
See the instructions for using the SNMP option in the online CA Procedures. On the UNIX/Linux platform, you can send messages to your SNMP messaging console using the SNMP Alert option. This option is included in the Backup, Restore, Scan and Merge Managers.
Using the Trouble Ticket

You can use Trouble Tickets to alert users through a printed document.
Using Email
You can use the email option to send email messages to specific users. Important! Microsoft Mail or Microsoft Exchange Client must be installed on your computer in order to be able to send messages or to enter configuration data on this screen. Consult your Windows manual for instructions about how to set up your email account.
Using the Unicenter Option

The Unicenter option makes it possible to send a message to the Event Console Log or Common Object Repository when an alert is generated. Note: The Alert application must be running on both the Event Management machine, as well as the WorldView machine. See the instructions for using the Unicenter option in the online CA Procedures.
Determining the Application Event Priority

All applications calling Alert specify one of the following Event Priorities:

Critical Warning Informational
Storage Management
1295
Sample Unicenter Alert Scenarios If you want to send informational alerts to the Unicenter Console Log using blue text, for example, configure a recipient as follows: Event Priority Informational Blue Yes Yes Description Application Event Priority Color Send to Event Console Log Send to Common Object Repository
If you want to send error alerts to the Unicenter Console Log using red text, and have the object status in the Common Object Repository updated, configure another recipient as follows: Event Priority Critical Red Yes Yes Description Application Event Priority Color Send to Event Console Log Send to Common Object Repository
Testing the Recipients

You can use the Test toolbar button to test any of the Alert messaging functions without generating an actual alarm condition. See the instructions for testing Alert messaging functions in the online CA Procedures. Note: You should test any features after the configuration has been completed. Be sure to inform any Alert recipients that a test is taking place.
1296
Administrator Guide
Activity and Event Logs of Alert

While the status of Alert is shown when the Alert Summary is highlighted in the Activity group, an historical listing is stored in the Activity Log. Similarly, every message that is generated by Alert is stored in the Event Console Log. You can view, print, or clear these logs. You can configure the Event Console Log destination so that Alert will put an event for a selected server in that machines Event Console Log. See the instructions for viewing, printing, and clearing the logs in the online CA Procedures.
Storage Management
1297
Chapter
13
Security Management
Security Management provides a policy-based security system that protects against unauthorized access to the system, its programs, and data. With the explosion in the number of desktop computers and departmental servers, it has become increasingly harder to enforce security by restricting physical access to computers. Further, the recent advances in networking render many physical access restriction approaches to security ineffective. To protect your systems, you must augment physical security with a software solution that can do the following:
Prevent unauthorized individuals from gaining access (logging on) to your system. Ensure that only authorized personnel can access system data and resources. Protect against access abuse by users with administrative privileges. Provide a way to review and audit the use of data and resources.
Enhanced and simplified Security Management means reduced errors, greater responsiveness, and increased flexibility in meeting the needs of your organization. Most importantly, it means you can implement thorough and effective security policies without disrupting your work environment.
Security Management
131
How Security Management Works

Security Management provides a policy-based layer of security that works in combination with native operating system security to provide enhanced security, including the following:
Controlled resource access by users with administrator privileges; you can delegate support functions that require administrator authority, such as system tuning, without allowing the user complete access to your files Enforcement of file naming standards by limiting the names users can assign when creating new files Prevention of the accidental destruction of a file Limits on system and file access by date and time
What is wrong with access control lists (ACLs)? Actually, nothing is. However, one of the most important advantages of a policy-based security system over ACLs is that files are protected, not by their physical attributes and ACLs, but rather by security policies you define. These security policies are stored in the Security Management database. Newly created files are protected automatically, not at the discretion of the creator, and consistently with the needs you identify for the file based on your security policy. This set-and-forget nature of policy-based security is the key to managing hundreds of users on a system as easily as you can manage a dozen.
Managing Security Policies

All of the user logon and asset access controls provided in Security Management are maintained through policies you define in the Security Management database. Once these policies are set, they are enforced until the security administrator changes them. The policy-based security model of Security Management provides an additional layer of protection that does not eliminate native operating system security, but complements it with the following added benefits:

Users can reflect the permissions of multiple user groups simultaneously. Multiple files are protected by a single policy, which can use character masking and wildcard specifications. Time and date restrictions can be applied. Create and delete access modes are provided for files.
Additionally, all access violation attempts are routed to the Event Console Log, providing a real-time window into security activity.
132
Administrator Guide
The primary policy definitions used in managing security policies are as follows:
User
User profiles contain information about users who access (log onto) the system. Each user having an account in the native operating system should have a user profile in the Security Management database. This profile contains user logon validation information, as well as data specific to the operating system. User groups logically group users and access permissions together. Defining user groups is optional. An asset describes a specific occurrence of a protected entity, such as a particular file (for example, commit.exe), or an Enterprise Management object (such as a specific calendar). Users can be given access to an asset directly by granting permission to the user, or indirectly by granting permission to a user group of which the user is a member. An asset group describes multiple assets with similar attributes; for example, all the files to which a user group has READ access. As with assets, users may be given access to an asset group directly by granting permission to the user, or indirectly by granting permission to a user group of which the user is a member.
User Group
Asset
Asset Group
Understanding the Commit Process

The commit process puts that version of the policies you currently have defined into the database and into effect. It also generates the Decision Support Binary (DSB) files (see the following section). Security Management requires that you execute the commit process during various phases of implementation. Once Security Management is operational, the commit process is typically required anytime after you make a change to your policies, that is, a change to a user, user group, asset, or asset group rule. However, Unicenter offers specific Security Management options that you can set to cause your changes in these policies to be dynamically applied to the database, making the commit process unnecessary.
Security Management
133
Decision Support Binary (DSB) Files
The DSB file is an in-memory version of the Security Management database. The DSB file is the authority against which the Security Management daemons validate all asset access attempts. To maintain optimum system performance, all real-time Security Management validations refer to the DSB representation of a policy, rather than to the Security Management database. Using this DSB technique yields the following three major benefits:
It maintains optimum system response by performing real-time access validations against an in-memory DSB rather than against a disk-resident relational database. It lets security administrators make administrative changes and updatesat any timewithout impacting real-time processing. The updates can be put into effect at a more appropriate or convenient time by executing a subsequent commit process. If the database is unavailable, security evaluation continues to run, that is, a database outage does not disable security.
After populating the Security Management database, each subsequent commit process will update the DSB files and DSB memory, the Windows security database, the definitions in the UNIX/Linux /etc/passwd file and, optionally, other UNIX/Linux control files. Optionally, through the setting of the Dynamic Update for DSB/SAM option (UPDATE_EXTERNAL option for UNIX/Linux platforms), future administrative updates to user accounts can be reflected in the DSB representations of the user database as part of real-time processing. These updates may include defining new users, as well as deleting existing user profiles. After Security Management has been implemented, setting this option to YES will result in user administration changes, including status and password updates being placed into effect immediately without requiring the execution of the commit process.
134
Administrator Guide
Considerations and Requirements
The commit process, when executed, performs the following tasks:
Security Database Access--The first phase extracts the policies that you have defined in the Security Management database. As such, that database must be online and active. Security Evaluator Active--Another phase takes the policies extracted from the database and places them into effect on the designated server computer, where they are processed by the Security Management functions, which must already be running. If Security Management is not already running, the commit process will detect this and issue an appropriate error message indicating that an attempt to place the new security policies into effect has failed.
To perform a commit process, issue the secadmin command with option c from the cautil command line, or select File Commit from the menu bar in the Security Management GUI. See the secadmin command in the online CA Reference for command syntax, examples, and additional information about warnings and commit customization.
Security Management
135
Implement Security Management
Implement Security Management

The implementation of a security policy for a server is a result of planning, implementing, testing, evaluating, and adjusting. Understanding the implementation process, including why specific procedures are performed in a particular order, is critical to the success of your Security Management solution. Security Management is implemented in the following phases:
Phase 1--Review your Security Management Options, and Client and Server Preferences, to ensure that needed components are available and other options are set to the proper values. Phase 2--Initialize and populate the Security Management database using the secadmin command with option d, execute the commit process to create the Decision Support Binary (DSB) files, and start Security Management daemons (service providers) in QUIET mode. Phase 3--Create security rules for users, user groups, access permissions, and asset groups in WARN mode and verify user access, adjusting rules based on results, then re-execute the commit process. Consider any optional features you may need. These features are discussed under the topic, Optional Features, presented later in this chapter. Phase 4: Customize Security Management options for FAIL mode production operations.
This chapter provides detailed information and points you to procedures that allow you to accomplish each of the phases of implementation.
136
Administrator Guide
Phase 1: Review Security Management Options

Security Management options that affect logon, password, enforcement modes, violation rules, and other controls are set globally and are used systemwide. These options have default values that can be customized to your sites security requirements. Windows Security Management option settings can be modified through the Enterprise Management GUI. See the instructions for security option settings in the online CA Procedures under the topic, Customizing Your Security Management Options. UNIX/Linux platform Security Management options are located in the $CAIGLBL0000/secu/scripts/secopts file. You can use the editor of your choice to modify the option settings in this file. If you are upgrading to Unicenter NSM from an earlier version, you may consider refreshing the $CAIGLBL0000/secopts file with the new version, $CAIGLBL0000/secu/scripts/secopts, so that options can be located by Security Management. After you have reviewed your options, see the platform-specific requirements in the section, Customizing Your Options for Phase 2, presented later in this chapter.
Security Management
137
Options to Consider for Your Operations

This section describes some of the options you can customize to support Security Management. Other Security Management options are described later in this chapter under the following topics:

Other Options for the Windows Platform Other Options for UNIX/Linux Platforms Setting Computer Associates International Standard Security Facility (CAISSF) Scoping Options User Profile Synchronization (UPS), including the Command Propagation Facility (CPF) Interface to eTrust CA-ACF2, eTrust CA-Top Secret, and IBM RACF running on z/OS and OS/390, and Unicenter Security Management running on UNIX/Linux computers Distributed Computing Environment (DCE) Synchronization Data Base Synchronization (DBS) Windows Backup Domain Controller Support Native Operating System Database Update Password Change Notification Facility FTP Proxy for UNIX/Linux Rexec Proxy for UNIX/Linux
Default Permission Option The Default Permission option (DEFAULT_PERMISSION for UNIX/Linux platforms) controls the action of Security Management when a user attempts to access an asset. This option can be set to either DENY or ALLOW.
DENY--Directs Security Management to deny access to any asset not otherwise permitted for a given user. DENY results in every system asset being considered protected by default. You can think of DENY as a way of saying, no one gets access to anything unless specifically told otherwise. ALLOW--Directs Security Management to allow access to any asset not otherwise (explicitly) denied a given user. ALLOW protects only those assets you tell it to protect. You can think of ALLOW as giving access to everything except those assets that are specifically protected.
An explicitly set permission in the user profile will override this Default Permission option setting.
138
Administrator Guide
System Violation Mode The System Violation Mode option (SYSTEM_MODE for UNIX/Linux platforms) determines whether and how Security Management responds when a user attempts to access an asset. This option can be set to QUIET, WARN, FAIL, or MONITOR (for UNIX/Linux only). The default is QUIET. The following table describes each of these modes. Mode Setting QUIET WARN Effect Ignores user accesses to assets. No enforcement action is invoked by Security Management. Allows access to an asset for which the user has no permission, logs the event to the Event Console Log, and sends a warning message to the user whom originated the access violation. WARN logs the event but does not increment the violation counter or invoke an enforcement action. Denies access to an asset for which the user has no permission, logs the event, and increments the users violation counter. FAIL is the only mode that provides unconditional protection of assets and invokes the specified enforcement action. Allows access to an asset for which the user has no permission, and sends a warning message to the Event Console Log. The violation counters are not incremented, and no enforcement action is invoked. The user is unaware that a violation has occurred.
FAIL
MONITOR (UNIX/Linux only)
You can associate the Default Permission option with the System Violation Mode option to produce a specific level of asset protection. For example, a Default Permission of DENY combined with a System Violation Mode of WARN causes Security Management to log all unauthorized asset access, but not deny access. (Assets specifically permitted to a user will not generate an Event Console Log entry.) The combination of DENY and WARN is especially useful while you are in the process of implementing your security policies, because it produces an audit trail of all asset access through the Event Management component. Alternatively, a Default Permission option setting of ALLOW combined with a System Violation Mode of FAIL enables Security Management to protect only those assets specifically defined as protected, that is, everything except the protected assets will be accessible. Many security administrators prefer this approach because it quickly protects a set of defined assets without affecting the rest of the system.
Security Management
139
UNIX/Linux (only) Option USE_PAT
If you are implementing Security Management on a UNIX/Linux platform, you can effect security evaluation by use of the Protected Asset Table (PAT). The USE_PAT option affects security evaluation behavior, which is based on the Protected Asset Table, or PAT. The PAT contains asset type-asset ID combinations, which encompass the entire set of all security rules defined for your enterprise. At evaluation time, requests are evaluated to validate user access to a specific asset type-asset ID-access mode combination, otherwise known as a tuple. For example, user Joe has access to asset type UNIX-FILE, asset ID /uni/secopts, access mode READ. If no rule is found to match this tuple, the PAT is searched for the pair asset type-asset ID within the defined rules. If a match is found, then an access of DENY is returned by the evaluators for the request. If no match is found, the value of the Security Management option DEFAULT_PERMISSION (either ALLOW or DENY) is returned. This option can be set to YES or NO. Setting this option to YES maintains this level of security evaluation (search the PAT). A setting of NO will bypass PAT processing and will result in a more get what you define behavior. If a tuple is found for the user, the access associated with the tuple (ALLOW, LOG, or DENY) is returned; otherwise, the value of the DEFAULT_PERMISSION option is returned.
Access Violation and Enforcement Once an access violation is detected, the next decision Security Management must make is what to do about the violation. Should the access be allowed and the user warned? Should the access attempt be denied? Should the access attempt be allowed, but the violation logged? The action taken by Security Management when a violation occurs depends on the Enforcement mode and the Enforcement action that are currently defined in the user profile for the individual user who attempts the access. The Enforcement mode and Enforcement action that are in effect for a user interact with and rely on the settings of the following Security Management options: Windows Platform Option User Default Violation Mode User Default Violation Action UNIX/Linux Platform Option USER_VIOLMODE USER_VIOLACTION
Important! Understand that the options listed previously are the system-level rules; the Enforcement mode and Enforcement action are the user-level rules.
1310
Administrator Guide
The settings of the User Default Violation Mode and the User Default Violation Action options are assumed as the defaults when you add a new user profile definition to the database and have not specified the Enforcement mode and Enforcement action in the user profile definition. The defaults remain in effect for the user until you furnish an Enforcement mode and action in the definition. The interplay between the system-level Violation Mode/Action options and the user-level Enforcement Mode/Action is discussed in the following paragraphs. For more information, see the section Defining Users, presented later in this chapter.
User Default Violation Mode/Enforcement Mode
The values that can be specified for both the system-level User Default Violation Mode option and the user-level Enforcement mode are QUIET, WARN, and FAIL. The mode, MONITOR, is also available, but only for UNIX/Linux platforms. An additional user-level Enforcement mode, SYSTEM, indicates that the user will default to the setting of the system-level System Violation Mode option (see the section System Violation Mode, presented earlier in this chapter). The following table describes the User Default Violation Mode/Enforcement mode settings. Mode Setting QUIET WARN Effect Ignores user accesses to assets. No enforcement action is invoked by Security Management. Allows access to an asset for which the user has no permission, logs the event to the Event Console Log, and sends a warning message to the user whom originated the access violation. WARN logs the event but does not increment the violation counter or invoke an enforcement action. Denies access to an asset for which the user has no permission, logs the event, and increments the users violation counter. FAIL is the only mode that provides unconditional protection of assets and invokes the specified enforcement action. Allows access to an asset for which the user has no permission, and sends a warning message to the Event Console Log. The violation counters are not incremented, and no enforcement action is invoked. The user is unaware that a violation has occurred. Uses the enforcement mode currently defined by the System Violation Mode option (SYSTEM_MODE for UNIX/Linux platforms).
FAIL
MONITOR (UNIX/Linux only)
SYSTEM
Security Management
1311
User Default Violation Action/Enforcement Action
Important! This option setting takes effect only if the Enforcement mode in the user profile is FAIL. You can set the User Default Violation Action option value (USER_VIOLACTION for UNIX/Linux platforms) to one of the following values: Equivalent User Profile Enforcement Action Setting Cancel Cancel & Logout Cancel, Logout, & Suspend
Option Setting CANUSER CANU&LOG CANU&LOG&SUS
Effect Cancel the process under which the failed attempt was made. Cancel the process under which the failed attempt was made and log the user off of the computer. Cancel the process under which the failed attempt was made, log the user off of the computer, and suspend the users account. Once suspended, the user cannot log on to the system until an authorized security administrator removes the suspension. See Reactivate a Suspended User ID later in this chapter.
Note: Additionally, for UNIX/Linux platforms, a Cancel, Logout & Suspend action occurs when the number of access violations reaches the value specified by the SSF_MAXVIO option. Authorized User List (for QUIET Mode) The Authorized User List identifies the IDs that have authority to administer security policies. The default user IDs that are in effect for QUIET mode rely on the setting of the following Security Management option:
Windows Option: Authorized User List The default user IDs for the Authorized User List option are ADMINISTRATOR and CAUNINT. At a minimum, you must supply an administrator ID to continue with your implementation. If you add user IDs, separate each one from the other with a comma, as spaces are valid in user IDs.
1312
Administrator Guide
UNIX/Linux Option: SSF_AUTH The default user ID in the SSF_AUTH option is root. Edit the IDs in the list using the text editor of your choice. If you add user IDs, separate each one from the next with a space. Dynamic Update of Local User and User Group Profiles You can dynamically update a user or user group profile, and have the changes reflected immediately in the native operating system security control files and the Security Management DSB files, without any requirement for a Security policy commit. Administrative updates to user and user group accounts can be reflected in the DSB representations of the user base as part of real-time processing. This includes newly defined users and user group accounts, as well as deleted accounts. This means, for example, that if the Dynamic Update for DSB/SAM option is on and a user is suspended, this change in status is reflected immediately without any requirement for a commit process. If this feature is not active, updates are in effect only after a commit process has been executed. The option to dynamically update a user profile is supported by both Windows and UNIX/Linux. The option to dynamically update a user group profile is supported only by Windows. Whether Dynamic Update is in effect relies on the setting of the following Security Management options:
Windows Option: Dynamic Update for DSB/SAM The Windows option, Dynamic Update for DSB/SAM, determines whether dynamic update support is in effect for local user profiles. If this option is set to ON, dynamic updates to the Windows security database and Security Management DSB files occur. If set to OFF, updates are in effect only upon completion of a commit process (secadmin /c server_name command). UNIX/Linux Option: UPDATE_EXTERNAL The UNIX/Linux security option, UPDATE_EXTERNAL, controls real-time updates to user profile information. If this option is set to YES, changes to user profile information are automatically applied to the /etc/passwd file and the Security Management DSBs. For example, a password change is immediately reflected not only in the Security Management database, but also in the /etc/passwd file as well. If set to NO, updates are in effect only upon completion of a commit process (secadmin -c command).
Security Management
1313
Windows Option: Dynamic Group Update for DSB/SAM The Windows option, Dynamic Group Update for DSB/SAM, determines whether dynamic update support is in effect for local user group profiles. If this option is set to ON, dynamic updates to the Windows security database and Security Management DSB files occur. If set to OFF, user group updates affect only the Unicenter database, and are in effect only upon completion of a commit process (secadmin /c server_name command). Additionally, user group commands are performed implicitly when you add a user. For example, cautil define user id=wilma will implicitly add wilma to the default user group (USERS). This implicitly altered user group is subject to the Dynamic Group Update setting. When Dynamic Update is enabled, a commit process is needed only to place changes in access permissions (or access restrictions) into effect. Changes of this nature include explicit permit/deny administrative actions, and changes to user groups, asset groups, and assets directly associated with a user account. Important! When defining a new user profile, note that if that user is in FAIL mode, the user will not be able to log on until a commit process is executed. Since the Security Management evaluators get their information as a result of the commit process, the user is unknown. The evaluators will reject all requests by an unknown user, even if the Default Permission option (DEFAULT_PERMISSION for UNIX/Linux platforms) is set to ALLOW. Local/Remote Standard Security Facility (CAISSF) Support This feature allows Unicenter NSM systems that may or may not have Security Management installed to route requests to external (remote) Security Management evaluators. You can define any local or any remote servers to perform security evaluation should an evaluation request be returned with a Security not active return code. Use the following options to support this feature: Windows Option: Local Evaluation Server List UNIX/Linux Option: LOCAL_EVAL_SERVER_LIST This option controls the action of the local Enterprise Management Security APIs (EmSec_ssfCheck) when an evaluation request is returned with a Security not active return code. Use this option to specify a single node or a list of nodes (delimited by either space or comma). The first node that responds to the request controls the evaluation answer. Node contact is attempted in the order of the list. A null value for this option negates its use.
1314
Administrator Guide
Windows Option: Remote Evaluation Server List UNIX/Linux Option: REMOTE_EVAL_SERVER_LIST This option controls the action of the remote Enterprise Management Security APIs (EmSec_ssfCheck) when an evaluation request is returned with a Security not active return code. Use this option to specify a single node or a list of nodes (delimited by either space or comma). The first node that responds to the request controls the evaluation answer. Node contact is attempted in the order of the list. A null value for this option negates its use. Option: Remote Default Permission This option specifies the permission to be granted (ALLOW or DENY) for access to a remote asset ID when none of the servers in the Remote Evaluation Server List are responding. The default is ALLOW. Option: Support same-circular userid passwords Passwords cannot be circular shifts of the user ID. The setting of this option (YES or NO) determines whether a check will be made for circular characters in password/user ID combinations. The default is NO. Option: Ignore case for new password change validation When comparing for circular shifts in password/user ID combinations, the setting of this option (YES or NO) determines whether the case of the password/user ID will be ignored. YES instructs to ignore the case, NO checks for the same case. The default is NO. The following return codes are associated with Remote CAISSF: Return Code
EMSEC_API_REMOTE_NOT_SPECIFIED
Meaning The EmSecRemote_ssfCheck API does not identify the remote node, or no remote node value was specified for the option, Remote Evaluation Server Path. The request has failed to reach the servers in the path.
EMSEC_API_REMOTE_NOT_RESPONDING
Security Management
1315
Other Options for the Windows Platform

The options discussed under this topic are associated exclusively with Windows platforms, and are used to enable the following Security Management features:

Dynamic update of remote user profiles Trusted domain support Remote audit Guest ID support WINLOGON logon support Windows NT/SAM password maintenance
Dynamic Update of Remote User Profiles Security Management supports remote dynamic update for Unicenter and Windows security database users. Using remote dynamic update, you can administer one nodes users in a different nodes database, and immediately update the information in the first nodes Windows security database and Security Management DSB files. In effect, any administration change to a user is immediately available. If this feature is not active, updates are reflected only after commit processing. Unicenter NSM must be active on both nodes for this to occur. If the receiving node is inactive, the transaction will be retried through store-and-forward technology every 15 minutes (by default) for a week. Nodes do not have to have Security Management activated or active to participate in remote Windows security database updates.
How It Works
The security option, Accept Remote Dynamic Update for DSB/SAM, controls whether this support is available. If the setting of this option is YES, updates to the Windows security database and Security Management DSB files are accepted from any source. If the setting is UNIAPP, remote updates are accepted only from the node designated to perform your nodes administration. If the setting is NO, the feature is disabled. The default is YES. A node is the Security Management administration node for five other nodes. Using a cautil statement to change a password for a user can affect all six nodes and be effective immediately in the Windows security database and the Security Management DSB files.
Example
1316
Administrator Guide
Trusted Domain Support Security Management supports all Windows domain models. Master domains, multiple master domains, and multiple trust models are supported through the Security Management implementation of Trusted Domain Support. Workstation and server models are also supported through this implementation. Important! In a trusted relationship, administrator shares cannot be trusted, nor should they be allowed to be trusted. For example, administrator share users on domain A are denied access to asset type WNT-FILE on domain B. So that users on domain A can access WNT-FILE on domain B, you would need to create a new share for the root drive and allow users access to that share.
How It Works
The security option, DSB Search Order, determines from where a Unicenter NSM user profile is obtained. Since the user profile contains such information as violation mode, enforcement action, expiration date, and so forth, this information controls a users logon session. Therefore, the user profile for a user ID is obtained (or not) depending on the setting of this option. The setting can be one of those described in the following table. DSB Search Option Value REMOTE&LOCAL
Effect Unicenter NSM first contacts the remote node (where the user is actually logged on through Windows WINLOGON) to obtain the user profile. If the remote node responds with the profile, it is used and the search terminates. If the remote node cannot be contacted, the previously obtained user profiles will be extracted from the Security Management DSB User file for the remote node by the local node. If the user profile is found, it is used and the search terminates. If no entry is found in this DSB User file, this completes the REMOTE search. Since the &LOCAL value is present, the search continues with the local node value replacing the remote node. The local node DSB User file is searched for the user profile. If the user profile is found, it is used and the search terminates. If the user is not found in any of these locations, the user does not exist to Unicenter and is not allowed access. (See the section Guest ID Support, presented later in this chapter.)
Security Management
1317
DSB Search Option Value LOCAL&REMOTE
Effect The search starts with the local node value replacing the remote node. The local node Security Management DSB User file is searched for the user profile. If found, it is used and the search terminates. If not, this completes the LOCAL search. Since the &REMOTE value is present, Security Management will contact the remote node (where the user is actually logged on through Windows WINLOGON) to obtain the user profile. If the remote node responds with the user profile, it is used and the search terminates. If this remote node cannot be contacted, the previously obtained user profile will be extracted from the Security Management DSB User file for the remote node by the local node. If the user profile is found, it is used and the REMOTE search terminates. If the user is not found in any of these locations, the user does not exist to Security Management, and is not allowed access. (See the section Guest ID Support, presented later in this chapter.)
LOCAL
The search begins with the LOCAL node value replacing the remote node. The local node Security Management DSB User file is searched for the user profile. If the profile is found, it is used and the search terminates. If no entry is found in the local DSB User file, this completes the LOCAL search. If the user is not found, the user does not exist to Security Management and is not allowed access. (See the section Guest ID Support, presented later in this chapter.)
1318
Administrator Guide
DSB Search Option value REMOTE
Effect Security Management will contact the remote node (where the user is actually logged on through Windows WINLOGON) to obtain the user profile. If the remote node responds with the profile, it is used and the search terminates. If the remote node cannot be contacted, the previously obtained user profile will be extracted from the Security Management DSB User file for the remote node. If the user profile is found, it is used and the search terminates. If no entry is found in this DSB User file, this completes the REMOTE search. If the user is not found in any of these locations, the user does not exist to Security Management and is not allowed access.
Remote Audit Security Management supports remote auditing for trusted and trusting domains. Since users have the ability to use resources of domains they are not explicitly logged onto, Security Management rule violations may need to be audited more carefully. When remote auditing is active, administrators or auditors can see violations occurring on their own node, as well as violations by members of their domain when these occur on other nodes. Remote suspension is also supported. With this support, a user can be suspended on his domain node for violations occurring elsewhere. Remote domain support does not include the ability to dynamically update a remote Windows security database or the Security Management DSB files. The security option, Dynamic Update for DSB/SAM (UPDATE_EXTERNAL for UNIX/Linux platforms) determines whether this support is in effect.
How It Works
The security options, Remote Audit Send Setting and Remote Audit Receive Setting, control whether the local node can send or receive remote audit transactions. Important! Since each node can set these options independently, understand that although a remote node may send an audit transaction, the receiver does not necessarily accept it. Administrators must communicate and coordinate the setting of these two remote audit options.
Security Management
1319
Guest ID Support Security Management supports Guest IDs. Guest IDs are either permitted or denied according to the setting of the option, Guest Logon Options. Provided also is the option, Guest User ID, which is used to specify the user profile to use when the users logon session setup occurs. When a guest ID user profile is used, the Security Management LOGON message specifies that this user is using a guest ID. All rule violation messages specify the actual users ID, and not the guest ID. WINLOGON Logon Support Security Management supports password changes, expirations, and other options through Unicenter WINLOGON. To use these password features, the user must log onto the domain through the Unicenter NSM version of WINLOGON.
How It Works
The security option, Logon Intercept Setting, determines whether Unicenter WINLOGON support is active. If the setting is OFF, no support is in effect. If the setting is WINLOGON, users logging on to this domain are forced to use Unicenter NSM WINLOGON, going through the password control features during user session setup. Any user using Windows WINLOGON is not permitted to access resources when this option is set to WINLOGON.
1320
Administrator Guide
Windows NT/SAM Password Maintenance Security Management lets you maintain Windows NT/SAM passwords in the Security Management database.
How It Works
The security option, Maintain Passwords in Unicenter, determines whether this feature is available. If this option is set to YES (the default), Unicenter maintains the passwords in the Security Management database. This means that all password modifications must be done through Unicenter NSM using either the cautil command line or the Enterprise Management GUI, or through logon with Security Management running while logon intercepts are active. If a password is modified using the Windows User Manager, the password will be out of synchronization, and the user will not be able to log on through Unicenter NSM logon. If this option is set to NO, Unicenter does not maintain passwords. All password updates must take place using the Windows User Manager, or through logon. The logon intercepts may be active; the password will be modified only in the Windows NT/SAM database. Any attempts to change the password through cautil or the GUI will result in the following message: %CASD_I_038, Unicenter is not maintaining passwords. Password must be changed in Windows User Manager. All other changes made to the user (status, expiration date, and so forth) will take place. Additionally, the password may be specified when the user is defined through cautil or the GUI. The password will be placed in the Windows NT/SAM database.
Security Management
1321
Rule Server for Rule Processing Rule server support allows you to specify another server from which to obtain your rules used for evaluation by commit processing. This servers rules are obtained in conjunction with the local servers rules. This support enables you to define global rules shared by two or more servers, in addition to having your local rules enforced.
How It Works
Specify the name of your global rule server as the value for the Security Management option, Rule Server for Rule Processing.
User Group Server for Rule Processing User group server support allows you to specify another server from which to obtain user groups used for evaluation by commit processing. This feature is usually implemented on a server or current Backup Domain Controller (BDC) where users typically use domain user IDs to access assets. Rules defined for those nodes refer to the user groups defined on the domain controller.
How It Works
Specify the name of your user group rules server as the value for the Security Management option, User Group Server for Rule Processing.
Security Management Automatic Startup By default, Security Management is not started during the activation of the other Enterprise Management services. If you did not specify during the Unicenter installation process that you wish to have Security Management started automatically, you can do so at any time by performing the following steps. 1. 2. Open Windows Settings, Control Panel, Services icon, and select CA-Unicenter. Click the Startup button. The Service dialog is displayed. Click the Automatic radio button in the Startup Type box and click OK. The Services dialog is displayed. Note that the Startup column shows the type as automatic. Locate the file, caicfg.glo in Install_Path\BIN. Using the editor of your choice, edit the file and add SEC to the list of three-character component IDs. Close the file.
3.
Each time Unicenter NSM is started in the future, Security Management will be started automatically.
1322
Administrator Guide
Other Options for UNIX/Linux Platforms

The options discussed under this topic are associated exclusively with UNIX/Linux platforms, and are used to enable the following Security Management features:

Node support Network Information Service (NIS) integration support Password processing: Restriction bypass, validation exits, and time-out specification Security evaluation based on the target user of an su command Security evaluation on a setuid operation
Node Support Implementation Within Security Management, all user and asset definitions are typically global; that is, the definitions apply on all hosts that may share the Security Management database. Unicenter NSM provides node support for the UNIX/Linux platform under which a definition can be associated with a specific node in a group. Node support is useful for sites that share a Security Management database among multiple systems, and sites that would like to use Security Management evaluators in a distributed client/server environment. The implementation of node support requires an understanding of two aspects before you can determine how you want to set the options that control this support. These aspects are definition and evaluation. Definition Both user definitions and asset definitions may contain an associated node value. Similarly, within any definition that accepts an asset specification, there can be a node specification associated with that asset. Upon completion of the initial Security Management installation, all node values are blank, which means that all definitions are global.
User Definitions
When Security Management policies are committed to your system, Security Management looks for user definitions that are applicable to your system. It limits its selection criteria to those user definitions that are node specific, that is, those that contain a node value equal to the system identification on which the commit process is being executed; it then looks for user definitions that are global (having no associated node value). Since duplicate user definitions can exist, that is., specific and global, Security Management chooses the most specific definition.
Security Management
1323
Because of the selection process, you can define a global user definition that may be applicable to a number of systems that are supported by Security Management. You can then override this definition with a node-specific one in the event that your requirements vary on a particular node from the global definition.
Asset Definitions
Asset definitions can be qualified by node. Asset definitions are associated with user, user group, and asset group definitions. When a node value is included in an asset definition, Security Management applies the policy only to that specific node. In the absence of a node value, the policy is global and is applied to all nodes supported by the Security Management database. Again, as with user definitions, when Security Management policies are committed to your system, Security Management looks for rules that are applicable to your system. It retrieves all rules that have a node value equal to the system identification on which the commit process is being executed; it then retrieves rules that are global (have no associated node value). The Security Management evaluators will use this set of rules to enforce the Security policy.
Evaluation The Security evaluators work from extracted policy images stored as DSB files. The commit process generates these files. When a commit process is executed, the rules that are applicable to the node where the commit process is being executed are extracted from the Security Management database (secdb) and loaded internally to the Security evaluators. The rules take the form: Can userID at nodeID have access to assetID defined on this node? If a request is made without a node value associated with the user, the node where the evaluation is taking place is used. The evaluators then search through the set of rules associated with the specific user definition, as well as the global set of rules for this user definition. If only a node-specific user definition exists, or if only a global definition exists, that set of rules is used. Only when both definitions for the user exist will the evaluators search both sets of applicable rules. Again, because of this process, a Security administrator can define global policies for users, and then add any additional rules for a specific node to these policies.
1324
Administrator Guide
Two Security Management options are associated with node support: SEC_GLOBAL_AND_LOCAL and SEC_EVALORDER. Each is described in the following paragraphs.
SEC_GLOBAL_AND_ LOCAL
The SEC_GLOBAL_AND_LOCAL option determines whether the Security Management evaluators apply those rules of both the global and the node-specific user definition, or only the node-specific user definition. This option can be set to YES or NO. The default is YES. This option is applicable only when both the global and the specific user definitions exist for a given user ID. A global user definition is one that is not node-qualified, that is, does not have an associated node value. Global user definition rules are applicable to all nodes supported by the Security Management database. A specific user definition is one that is node-qualified, and the node value is equal to the node where the Security Management evaluators are running. If this option is set to YES, then rules that have been written against both the global and the node-specific user definitions are included for evaluation; setting this option to YES has the effect of adding specific rules to the already existing global rules for a user. If the SEC_GLOBAL_AND_LOCAL option is set to NO, then only the rules that have been written against the specific user definition are included for evaluation. Setting this option to NO has the effect of defining a new set of rules for a user, which applies only to the specific node.
How It Works
SEC_EVALORDER
The SEC_EVALORDER option determines how the Security Management evaluators look at multiple sets of rules that may be assigned to a user ID. This option can be set to GLOBAL_FIRST, LOCAL_FIRST, or MIXED. The default is MIXED. This option is only applicable when SEC_GLOBAL_AND_LOCAL is set to YES. Additionally, it applies only to the evaluation of users who have both a global and a specific user definition. (See the previous discussion of the SEC_GLOBAL_AND_LOCAL option for an explanation of global and specific definitions.) A setting of GLOBAL_FIRST instructs the Security Management evaluators to look first at all rules associated with the global user definition when evaluating a request for a user. If no applicable rule is found, then the rules for a specific user definition are evaluated. A setting of LOCAL_FIRST instructs the Security Management evaluators to look first at all rules associated with the specific user definition when evaluating a user request. If no applicable rule is found, then the rules associated with the global user definition are searched.
How It Works
Security Management
1325
A setting of MIXED is the combination of GLOBAL_FIRST and LOCAL_FIRST. This setting instructs the Security Management evaluators to treat both sets of rules (global and specific) as the same. The evaluators perform the default behavior, looking for exact match DENY rules first in both the global and specific user definitions. If no match is found, the evaluators look at exact match LOG rules, followed by exact match ALLOW rules. A similar searching algorithm allows for masked rules (DENY, LOG, then ALLOW). MIXED evaluation is the same as evaluation for a user who has only one set of applicable rules. Important! Because both a global and a node-specific definition may exist for a user in the Security Management database, you should be aware that updates to a user account (such as violation counts, password changes, and others) will be applied to the specific definition, if it exists. Otherwise, the global definition for the users account is updated. Network Information Service (NIS) Integration Support Unicenter NSM on UNIX/Linux supports integration with the Network Information Service, or NIS. This support lets Security Management coexist in an NIS environment without requiring that local password entries exist for all users. NIS provides a method for maintaining user definitions (among other items) in a single location. This location is termed an NIS server, which provides remote access to user definitions for NIS client access. Consequently, user definitions on NIS client computers are not maintained within local password files; user information is retrieved through NIS services. On an NIS client, user definitions can exist in the local password files, as well as on the NIS server. Which definition is used depends on the NIS configuration. If a user definition exists in the local password file, then that definition is used. Otherwise, a call to the NIS server is made to obtain the user information. When defining users under Security Management, the User origin field identifies where the user definition originated, either a local password file or NIS. This field tells Security Management which user definitions should be maintained within the local password files, as well as where to look for user definitions when that information is needed.
1326
Administrator Guide
Three Security Management options are associated with NIS integration support:

UPDATE_PASSWD_FOR_NIS DELETE_NIS_FROM_PASSWD CALL_PREPOST_FOR_NIS
The following paragraphs furnish general guidelines to follow when setting these options.
UPDATE_PASSWD_ FOR_NIS
The UPDATE_PASSWD_FOR_NIS option instructs Security Management to update local password file information for users who are defined with a USERORIGIN keyword value of NIS. This option can be set to YES or NO. The default is NO. This option can be set to YES on an NIS server running Security Management and using system password file information to maintain NIS user definitions. When an update to a user account is made on an NIS server through Security Management, that update is then propagated to the system password files, allowing NIS services running on that computer access to the update. Generally, the UPDATE_PASSWD_FOR_NIS option will be set to NO on a computer running as an NIS client.
How It Works
DELETE_NIS_FROM_ PASSWD
The DELETE_NIS_FROM_PASSWD option determines whether Security Management will remove local password file entries for users who are defined with a USERORIGIN keyword value of NIS during a security commit process (secadmin -c). This option can be set to YES or NO. The default is NO. The DELETE_NIS_FROM_PASSWD option should always be set to NO on an NIS server where local password file information is maintained for NIS users. If this information is not maintained on the NIS server (as with NIS+), then this option is set to YES on the NIS server. WARNING! Use this option with caution! Make certain that local password file information is not the primary source of information on an NIS server before setting this option to YES on an NIS server computer. When set to YES, all Security Management users who are defined with a USERORIGIN value of NIS will have their local password file entries removed during commit processing (secadmin -c). On an NIS client, DELETE_NIS_FROM_PASSWD should be set to YES when local password file entries are not maintained for NIS user definitions. If local password file entries are maintained on an NIS client, then this option should be set to NO.
How It Works
Security Management
1327
This option is useful on an NIS client when upgrading from a prior version of Unicenter that did not have NIS integration support. In prior versions, it was required to have all user definitions in the local password files. With NIS integration support, this is no longer a requirement. To remove these definitions from the local password files, all user definitions that represent NIS users can be updated with a USERORIGIN keyword value of NIS. Then, set the DELETE_NIS_FROM_PASSWD option to YES and execute a commit process (secadmin -c). Again, this will remove all NIS user definitions from the local password files.
CALL_PREPOST_ FOR_NIS
The CALL_PREPOST_FOR_NIS option tells Security Management if the pre-post scripts should be called when updates are made to users who are defined with a USERORIGIN keyword value of NIS. This option can be set to YES or NO. The default is NO. This option works in partnership with the UPDATE_PASSWD_FOR_NIS option. If the UPDATE_PASSWD_FOR_NIS option is set to NO (typically on NIS client computers), the calls to the pre-post scripts will also be bypassed. To have the pre-post scripts executed for updates to user accounts while omitting the corresponding updates to the local password files, the CALL_PREPOST_FOR_NIS option should be set to YES, and the UPDATE_PASSWD_FOR_NIS option should be set to NO. If the UPDATE_PASSWD_FOR_NIS option is set to YES, then the update is performed as any user update would be. This means that the setting of the CALL_PREPOST_FOR_NIS option has no effect when the UPDATE_PASSWD_FOR_NIS option is set to YES (the pre-post scripts will always be called).
How It Works
Example
This example illustrates how Security Management can be configured in an NIS environment. In this example, the two computers are named nisserv and niscli. The nisserv computer is configured as an NIS server, where NIS user information is stored within the local password files. It is running Security Management. The niscli computer is configured as an NIS client, where the majority of user account information is stored on the NIS server, nisserv. Some user account information is stored within the local password files on this computer, primarily for the system user IDs (for instance, the root ID). This computer is also running Security Management. Jack Jones is the Security Administrator for these two computers. He has recently upgraded to Unicenter on both computers, and he now would like to implement NIS integration with Security Management. Prior to upgrading Unicenter NSM, Jack had run the Security Management program ca_nis2uni, and had defined all of the NIS users to Security Management and the local password files on his NIS client computer, niscli.
1328
Administrator Guide
Jacks objective is to have all the users defined to Security Management, but only maintain the system IDs within the local password files on niscli. Jack begins by determining how to set the NIS-related Security Management options. He edits the secopts file on nisserv and sets the following options: Option DELETE_NIS_FROM_PASSWD UPDATE_PASSWD_FOR_NIS CALL_PREPOST_FOR_NIS Setting NO YES YES
Jack then edits the secopts file on niscli and sets the following options: Option DELETE_NIS_FROM_PASSWD UPDATE_PASSWD_FOR_NIS CALL_PREPOST_FOR_NIS Setting YES NO YES
Jack starts Unicenter NSM on both computers. His next task is to determine which set of users to define as NIS. He notices that all UIDs for the users he would like to define as NIS have values greater than 100. The only other user accounts have UID values less than 100. He alters the user definitions within the Security Management database as follows:
cautil select user uid>100 list user
After reviewing the output from the list command, Jack is confident that these are the users he wants to define as NIS. He then issues the following command.
cautil select user uid>100 alter user userorigin=NIS
Now that Jack has the user definitions updated within the Security Management database, he executes a commit process on niscli using the secadmin -c command. Once the commit process has completed, he views the local password file on niscli. He is pleased to see that all user definitions for his NIS users no longer exist within the local password files. To ensure the definitions will remain within the local password files on nisserv, Jack also executes a commit process on this computer. He views the local password file here, and notes that all user accounts are still maintained within the local password files on nisserv.
Security Management
1329
To test the implementation, Jack signs on to each computer to confirm that his user base will still have access to each computer. Jack is now ready to customize his pre-post scripts on each of these computers to specify his site-specific requirements related to the processing of users. Jacks next objective is the synchronization of user information between these two computers. See the section DBS Synchronization, presented later in this chapter. Password Processing: Restriction Bypass, Validation Exit, and Time-out Specification Security Management provides options that let you do the following:

Bypass password content restrictions (PSWDADMINBYPASS option) Call the Security password validation exit for password change validation (PSWDVALEXIT option) Specify a password validation time-out value (PSWDVALEXIT_TIMEOUT option)
PSWDADMINBYPASS
Using the PSWDADMINBYPASS option, an administrator (identified by the SSF_AUTH option) who changes an end-users password can bypass all password content restrictions, including any imposed by PSWDVALEXIT that are normally applied by Security Management. This option can be set to YES (bypass the restrictions) or NO (maintain restrictions). The default is NO. The PSWDVALEXIT option specifies whether Security Management calls the security password validation exit for additional password change validation. This option can be set to YES (call the exit) or NO (bypass the exit). The default is NO. The password validation exit function is named EmSec_PwExit(). It resides in $CAIGLBL0000/samples/causec_exit1.c. In order to implement EmSec_PwExit() functionality, you must modify causec_exit1.c to your site specifications, compile it into object format, and place it into a shared object library named libemsec2.so. (Shared library file extension conventions vary from system to system, so review your system documentation.) Once you have created the library containing the new EmSec_PwExit() functionality, follow these steps to install the new library: 1. 2. Deactivate Security Management by running the following command:
secadmin -s all
PSWDVALEXIT
How It Works
Back up $CAIGLBL0000/secu/lib/libemsec2.so.
1330
Administrator Guide
3. 4.
Copy the new libemsec2.so to $CAIGLBL0000/secu/lib/libemsec2.so. Restart Security Management by running the following command:
secadmin -i all
If PSWDVALEXIT=NO, Unicenter bypasses the password validation exit and performs normal validation of the password change attempt. If PSWDVALEXIT=YES, Security Management calls the password validation exit whenever a password change is attempted. The exit is called with one function argument: the clear text password that is being attempted. It then produces one of the following return codes: Return Code EMSEC_RTRN_PW_REJECT EMSEC_RTRN_PW_DEFER Description The exit rejects the password. The password change is denied. The exit allows the password, but Unicenter NSM continues with normal password validation.
EMSEC_RTRN_PW_ACCEPT The exit allows the password and Unicenter NSM bypasses all other password validation. If EmSec_PwExit() produces a return code other than one just listed, the exit is ignored and normal validation of the password change attempt is performed. The EmSec defines are located in the include file, $CAIGLBL0000/include/causec2.h.
PSWDVALEXIT_TIMEOUT
The PSWDVALEXIT_TIMEOUT option specifies the maximum number of seconds Security Management should wait for the completion of the password validation exit. Any number of seconds can be specified. The default is 30 seconds. Use this option only when the PSWDVALEXIT option is set to YES. If the password validation exit does not return within the number of seconds specified, a warning message is displayed on the operator console and the EMSEC_RTRN_PW_DEFER return code is returned. This indicates that the exit is allowing the password, but normal password validation is continuing.
How It Works
Security Management
1331
su Command: Secure Target User

SU_SWITCH_ID
The SU_SWITCH_ID option enables Security Management to perform its evaluation against the target user of an su command. If, for example, this option is set to YES and user joe executes the su command to become user sally, then all subsequent Security Management evaluation is performed against user sally. This option can be set to YES or NO. The default is YES.
How It Works
setuid Operation: Secure Target User

SETUID_SWITCH _ID
The SETUID_SWITCH_ID option enables Security Management to perform its evaluation against the target user of a setuid operation. If, for example, this option is set to YES and a daemon running as root performs a setuid() call to become user joe, then subsequent Security Management evaluation is performed against joe. This option is useful when you want to protect against remote file access, as occurs by ftp and rcp. These UNIX/Linux utilities typically perform a setuid operation to become the target user who is performing the command. Using the SETUID_SWITCH_ID option, security evaluation for remote access to files behaves the same as that for local access to files. This option can be set to YES or NO. The default is NO.
How It Works
1332
Administrator Guide
Customizing Your Options for Phase 2

Before you can continue to Phase 2 of Security Management implementation, you must customize the Security Management options so that they are consistent with your enterprises security requirements. Additionally, you must set several options to absolute values before continuing to Phase 2 so that you will be able to test your policies during implementation without locking out your user community. Set the following options to their respective values, as shown following: Windows Option UNIX/Linux Platform Option Value ACTIVE SYSTEM QUIET ALLOW
Overall Activation Setting N/A User Default Violation Mode System Violation Mode Default Permission USER_VIOLMODE SYSTEM_MODE DEFAULT_PERMISSION
Set the remaining User Default options (USER_... for UNIX/Linux platforms) to the values you want to be applied to those users who will populate the database during the next phase of implementation. Supply an Administrator ID for the option, Authorized User List (SSF_AUTH for UNIX/Linux platforms), the user ID of the person who is authorized to modify your Security Management policies. For Windows platforms, set the component activation flag, Security Management Activated, to YES. See the instructions for setting options in the online CA Procedures under the topic, Customizing Your Security Management Options.
Security Management
1333
Phase 2: Populate the Database, QUIET Mode

This phase of implementation requires that you perform the following tasks: 1. 2. 3. Initialize and populate the Security Management database by executing a secadmin command using option d. Execute the initial commit process to create the Decision Support Binary (DSB) files by executing the secadmin command using option c. Start the Security Management daemons in QUIET mode.
Initializing and Populating the Database

Recognizing that some systems may already have many users defined in the native operating system database, you can take advantage of these definitions during initialization of the Security Management database. Invoked by the Security Management secadmin command using option d, this facility defines user profiles in the Security Management database for each of the user entries found in the Windows security database or the UNIX/Linux /etc/passwd file on the indicated server computer. When executed with option d, the secadmin command process does the following:

Extracts information from the native operating system database Augments that data with default information supplied by Security Management options Builds a user profile for each user found Defines Unicenter user groups, replacing any entry of the same name that may already exist in the Security Management database, as appropriate
Important! On Windows, new users are added and existing users are not updated. The Windows security option, Database Populated Server List, contains the server names populated through secadmin option d command processing. If the server is not in this list, the rules, user passwords, and assets will be deleted for this node to facilitate reinstallation.
1334
Administrator Guide
Important! On UNIX/Linux platforms, all users will be defined in REPLACE mode. This causes new user definitions to be defined, and existing definitions to be altered. The secadmin command using option d will replace any users or user groups of the same name that may already exist in the Security Management database. Any customization that may have been made to such users or user groups would be overwritten (and lost) by a subsequently executed secadmin command using option d. Therefore, it is important to execute the secadmin command using option d before users are created in the Security Management database. Because this facility uses information provided by security options settings to define certain user profile data, you must review and tailor your options before invoking the secadmin option d process. Important! Note the setting of the option, Dynamic Update for DSB/SAM. If this option is set to YES when the secadmin option d command is executed, dynamic update is active and in effect, and all database updates will be applied to the operating system database, even when Security Management is stopped or inactive. See the instructions for executing a secadmin command with option d in the online CA Procedures under the topic, Initializing and Populating the Security Management Database.
Executing the Initial Commit Process

During Security Management implementation, the first commit process run after initializing and populating the Security Management database creates the Decision Support Binary (DSB). Any subsequent additions or modifications to user groups, assets, or asset groups require that a commit be run to update the DSB file and DSB memory, putting the new rules into effect. See the instructions for executing the initial commit process in the online CA Procedures under the topic, Initializing and Populating the Security Management Database.
Security Management
1335
Starting the Security Management Daemons

After populating the Security Management database and executing your initial commit, you must start the Security Management daemons. After starting the Security Management daemons in QUIET mode, you can test security policies without risk of adversely affecting your user community. However, although you are in QUIET mode, an administrator ID is still required; ensure that you have supplied an administrator ID for the Windows option, Authorized User List (SSF_AUTH option for UNIX/Linux platforms), before starting the daemons. Important! Before starting Security Management, we strongly recommend that you review all Security Management options you have customized to make certain that you do not have the following settings:
Default Permission (DEFAULT_PERMISSION): DENY
and
System Violation Mode (SYSTEM_MODE): FAIL
A Default Permission of DENY indicates that any asset access that has not been identified as authorized by a preceding permit should be denied. DENY has the net effect of protecting every asset on the system. The System Violation Mode of FAIL indicates that any unauthorized access attempt should be rejected. If the options were unknowingly set as shown previously, every user could be locked out of the system. The only way back in would be by rebooting in single-user mode and updating the Security Management options. For example, all users requiring access to your system will need to be able to log on and access their home directories. A Default Permission of DENY indicates that those users should not be allowed access to those files (even if they are in their own home directories), unless rules have been written to grant permission to do so. See the instructions for starting the Security Management daemons in the online CA Procedures under the topic, Initializing and Populating the Security Management Database.
1336
Administrator Guide
Phase 3: Create Rules for Production, WARN Mode

With the System Violation Mode set to WARN, you can test all of the rules you have defined, and refine and adjust those rules without risk of impacting your users ability to work. See the instructions for configuring your system to operate in WARN mode in the online CA Procedures under the topic, Setting Options for Production, WARN Mode. Complete the procedures referenced in the rest of this section to create security rules for the following:

Users User groups Asset groups Access permissions
Defining Users
The user profile defines the basic permissions, credentials, and properties with which Security Management will associate an individual user. The user profile furnishes, among other information, a users:

ID and password Node specification Enforcement mode Enforcement action Password controls Windows security database update
ID and Password
The user ID and password are the critical pieces of information that identify a user to the system. Whenever a user attempts to log on to the system, that attempt is challenged. If the person making that attempt provides a valid user ID and password, then the logon is accepted. The node specification for a user definition identifies the host or hosts to which the user definition is applicable. For UNIX/Linux platforms, Unicenter NSM lets you specify a value of blank (no value) to indicate that this is a global definition, and that the user definition should be applied to all nodes that extract their policies from a given Security Management database. Unicenter NSM supports global node specification for UNIX/Linux platforms only.
Node Specification
Security Management
1337
A value other than blank indicates a specific node to which the user definition should be applied. A nodal user definition is applicable to only one node, and overrides a global definition of a user, should one exist.
Enforcement Mode
The Enforcement mode, as previously described, can be set at the system level or the user level. The Enforcement mode can be FAIL, WARN, QUIET, or SYSTEM. In addition to these, you may also set the MONITOR mode for UNIX/Linux. The Enforcement action is the action taken when a user with an Enforcement mode of FAIL attempts to access an asset without the necessary permission after having reached the maximum violation count for his logon session. (An Enforcement mode of FAIL is set either explicitly at the user level, or implicitly through a user-level setting of SYSTEM and a System Violation Mode setting of FAIL.) The following table describes the Enforcement actions: Action Cancel Cancel & Logout Cancel, Logout, & Suspend Effect Cancel the process under which the failed attempt was made. Cancel the process under which the failed attempt was made and log the user off the computer. Cancel the process under which the failed attempt was made, log the user off the computer, and suspend the users account. Once suspended, the user cannot log on to the system until an authorized security administrator has removed the suspension. See the section Reactivate a Suspended User ID, presented later in this chapter.
Enforcement Action
Password Controls
Password controls are options you can use to further customize how passwords are to be managed in your environment. Several user profile configuration options are available at the system level. Some of the controls you can set include:
Historical password tracking, which can be used to maintain a history of up to 64 previously used passwords under Windows, and 32 previously used passwords under UNIX/Linux platforms The number of incorrect password entry attempts to permit before suspending a user The minimum acceptable length of a users password
1338
Administrator Guide
Note: The actions taken when a user attempts entry to the system with an incorrect password are not regulated by any Security Management user or system enforcement mode setting; these controls are always in effect. For example, if a user supplies the wrong password while attempting to log on, he will be denied access to the system regardless of his enforcement mode. In addition, if a user exceeds the number of incorrect password entry attempts allowed, that users account is suspended. See the instructions for defining a user in the online CA Procedures under the topic, Defining Users. Updating the Windows NT/SAM Database After you add users to the Security Management database, they can be automatically added to the Windows NT/SAM database as well. See the instructions for configuring Unicenter NSM to automatically update the Windows NT/SAM database in the online CA Procedures under the topic, Updating the Windows NT/SAM Database. You can also update the Windows NT/SAM database using Unicenter NSM exits. See the section Updating the Windows NT/SAM Database Using Unicenter NSM Exits, presented later in this chapter.
Security Management
1339
Defining User Groups

Using Security Management, you can group users to simplify administration. User groups logically connect permissions to many users in a single operation. For example, if you define 50 users to the user group PRJTX, and PRJTX has permission to access a file, then all 50 users are automatically granted access to that file. In addition, because Unicenter NSM recognizes that a user may belong to more than one user group, your organization can define security from a variety of perspectives. For example, you could define the user USER01 to the following user groups: User Group PRJTX LAB PLANNING HRSAPPL CLSIFIED Description Project X Development Team Laboratory Team Planning Analyst Human Resource Systems Clearance is Classified
USER01 has access to any file permitted to any of these user groups. This example illustrates that permissions can be logically assigned, based on USER01s department (PRJTX), the users area within the department (LAB), or specific title (PLANNING). You can also base access on the application on which the user works (HRSAPPL), or even the information clearance level assigned to the user (CLSIFIED). User groups exemplify the power of the Security Management architecture. If USER01 is promoted, changes jobs, or changes departments, permissions can be adjusted automatically by changing the user groups of which the user is a member.
1340
Administrator Guide
Nested User Groups
In addition to creating multiple groups per user, you can nest groups (have a group that contains other groups) for additional flexibility in mapping how your organization typically works. For example, a corporate division has a certain set of files and other assets associated with it, such as being able to read the corporate telephone directory. Additional departments (such as personnel, payroll, and mailroom) also have special authorities. You can use nested user groups to give the departments automatic access to the corporate assets. By making each of these departments a group within the corporate group, each department has access to their assets and any assets defined to corporate. They do not, however, have access to the assets permitted specifically to the other departments. Let us look at an example of how nested user groups work. The following example uses Windows syntax; however, this example is illustrative of how the process works on other platforms as well.
In the diagram there is a group called CorpUsers that has access to the c:\corp\directs\* files. Three other groups are members of (nested within) the CorpUsers group: PayDept, AdmDept, and MailDept. These groups have permissions to files c:\payroll\*, c:\admin\*, and c:\mailroom\* respectively. User FRED is a member of group CorpUsers, user ALAN is a member of the PayDept group, user SAM is a member of the AdmDept group, and user ANDREA is a member of the MailDept group. With this structure, the following actions occurs:

Fred can access only c:\corp\directs\* files. Alan can access c:\payroll\* and c:\corp\directs\* files. Sam can access c:\admin\* and c:\corp\directs\* files. Andrea can access c:\mailroom\* and c:\corp\directs\* files.
Security Management
1341
You can apply as many levels of nesting as you want. If, in addition to the corporate and department groups previously shown, you also have a company group, you can make the departments a member of corporate, and corporate a member of the company. Permissions apply in the same manner as in this simple structure:
All members of departments can access their departments assets, the corporate assets, and the company assets. All members at the corporate level can access the corporate assets and the company assets. All members at the company level can access only the company assets.
See the instructions for defining your users in the online CA Procedures under the topic, Defining User Groups.
Defining Asset Groups

Unicenter NSM refers to any resource (file, program, user ID, and so forth) as an asset, which is defined to Unicenter NSM as a member of one or more asset groups. An asset group may have a single member or many, and access to an asset group can be permitted to either a user group or an individual user. You can also define nested asset groups. An asset group is defined by assigning a name to the new asset group and specifying the assets that are to be members of the group. Asset groups can be nested within other asset groups and can be included as members of multiple asset groups. Assets that are members of an asset group are identified by the following:

Asset type Asset name, also referred to as asset ID
The asset type is the category into which the asset logically falls. You can define your own asset types; you also have available over 60 predefined asset types identified by the prefix, CA-. In practice, however, you will find that the majority of your protected assets will probably have an asset type of WNT-FILE (or UNIX-FILE for UNIX/Linux platforms). For a list of supported asset types, see the asset type tables in the online CA Reference under the Security Management cautil ASSETTYPE command. See the instructions for defining your own asset types in the online CA Procedures under the topic, Defining Dynamic Asset Types.
1342
Administrator Guide
The asset name, or asset ID, is used primarily to specifically and individually identify a particular instance of an asset type. For example, the asset name for an asset type of WNT-FILE is a file path.
Nested Asset Groups
In addition to creating nested user groups, you can nest asset groups within as many levels as you require. For example, imagine a corporate asset group that contains various files and other general-purpose assets, one of which is the telephone directory. You want to associate these general-purpose assets with the more specific assets in three other asset groups that comprise payroll, administrative, and mailroom assets. You can accomplish the appropriate sharing of assets and avoid a duplication of asset groups by nesting the three more specific asset groups within the general-purpose asset group. The following example uses Windows syntax; however, it is illustrative of how the process works on other platforms as well.
The Corp asset group contains the files c:\corp\directs\*. The Payroll, Admin, and Mailroom asset groups are members of (nested within) the Corp asset group. These asset groups contain the files c:\payroll\*, c:\admin\*, and c:\mailroom\*, respectively. Because of nesting, the Corp asset group now includes the following:

The c:\corp\directs\* files The Payroll asset group, which includes the c:\payroll\* files The Admin asset group, which includes the c:\admin\* files The Mailroom asset group, which includes the c:\mailroom\* files
Security Management
1343
Adding an Asset Group As mentioned earlier, asset groups are collections of one or more assets, and are a key part of administering Security Management policies. See the instructions for creating a new asset group in the online CA Procedures under the topic, Adding an Asset Group.
Asset Protection: Determining Access to Assets

Asset permissions govern which protected assets a user can access and how they can be used after being accessed. Permissions are created through the Security Management GUI or the cautil command line interface by specifying the name of the asset or asset group that you want permitted to a user or user group. You can, conversely, provide the name of the user or user group to be permitted access to an asset or asset group. With this level of flexibility, you can manage security in the manner that is most comfortable for you. Important! If a user is denied access based on asset permissions (or the lack of an asset permission to a protected asset), a violation results. It is important to remember that the presence of a violation does not necessarily mean that a user will be stopped from accessing the asset. The Enforcement mode controls whether the user will actually reach the asset. Access Types The access type specified in a user definition determines whether the user will be allowed to access an asset. When defining access permissions, you can use the following access types to meet your specific control or audit needs: PERMIT LOG Allows the access to take place. Allow this user to access this asset control is the standard. Allows the access to take place and logs the event. LOG is used in those cases where you want to maintain an audit trail of access to a critical asset. For example, you may want to record all updates to the payroll master file. Do this by using two access types: a PERMIT for READ and a LOG for WRITE. READ authority is allowed normally, while a WRITE request generates a record of the access to the Event Console Log. The end user will not be notified that this access has been logged. Denies access and logs the event. DENY is useful for creating exceptions to normal permission sets.
DENY
1344
Administrator Guide
Whenever an asset is referenced (either explicitly or generically) as the subject of a PERMIT or DENY rule, it becomes protected. This protection means that when you permit a user to access an asset, such as a file, any other users who have not been granted permission to access this file (those in FAIL mode) will be denied access. Such protection is referred to as implicit DENY. Important! Security Management considers the access mode when evaluating a rule. For example, if the access mode (READ, WRITE, and so on) of a permission does not match the requested access type, the permission is not used. (See the section Access Modes, presented later in this chapter.)
Windows Example
If, for example, you decide to grant a user permission to read all files in the c:\WINNT35 directory, you could permit that user read access to an asset type of WNT-FILE with an asset name of c:\WINNT35\* and an access mode of READ. However, because all files in the directory c:\WINNT35 have been referenced as the subject of a rule (c:\WINNT35\*), all of these files are now protected and all unauthorized users (users operating in FAIL mode) will be denied access to these files. This means, for example, that as a side effect of this rule, no one will be able to access c:\WINNT35\SYSTEM. DENY rules would have the same effect as well. If, for example, you decide to deny a user access to all the programs in c:\bin, you could accomplish this by writing a rule that denies access to an asset type of WNT-FILE with an asset name of c:\bin\*. Again, however, as all the files in the \bin\ directory have been referenced as the subject of a PERMIT or DENY rule (c:\bin\*), all of those files are now protected. Your intent may have been to deny a single user EXECUTE access to the programs in c:\bin, but the result would be to deny access to all users who have not been explicitly permitted access. Note: For Windows platforms, Unicenter NSM provides the security option, Implicit DENY Permission for Rules, which can be set to suppress the implicit deny feature either for all users, or only for the user to which a rule applies.
UNIX/Linux Platform Example
If, for example, you decide to grant a user permission to read all files in the /etc directory, you could permit that user read access to an asset type of UNIX-FILE with an asset name of /etc/* and an access mode of READ. However, because all files in the directory /etc have been referenced as the subject of a rule (/etc/*), all of these files are now protected and all unauthorized users (users operating in FAIL mode) will be denied access to these files. This means, for example, that as a side effect of this rule, no one will be able to access /etc/ profile.
Security Management
1345
DENY rules would have the same effect as well. For example, if you decide to deny a user access to all the programs in /bin, you could accomplish this by writing a rule that denies access to an asset type of UNIX-FILE with an asset name of /bin/*. Again, however, as all the files in the /bin directory have been referenced as the subject of a PERMIT or DENY rule (/bin/*), all of those files are now protected. Your intent may have been to deny a single user EXECUTE access to the programs in /bin, but the actual result would be to deny access to all users who have not been explicitly permitted access.
Date and Time Controls
The name of a Unicenter NSM calendar can be associated with any access rule. When a calendar is associated with a rule, that rule is then considered applicable only when the dates and times specified as ON in that Calendar definition are met. For example, calendars are often used in conjunction with DENY asset types to set special dates and times when access will be denied. Understanding how access modes and calendars affect security evaluation make it possible to construct some sophisticated security rules. For example, assume the staff in the Payroll department has read and write access to the payroll master file, and you want to deny write access to members of that group on weekends. You could create a weekdays-only calendar and associate it to Payroll as a PERMIT access type for access mode WRITE.
Access Modes The access policies of Security Management support several types of authority, or access modes. Think of access modes as ways a user may try to access an asset. An access policy can specify one, several, or all of the applicable access modes for an asset. At least one access mode must be specified. These access modes include the following: READ WRITE UPDATE Controls the ability of the user to have READ access to the asset, as in permission to open a file for READ. Controls the ability of the user to have WRITE access to the asset, as in permission to open a file for WRITE. Controls UPDATE access to an asset. UPDATE is only valid for Unicenter NSM asset types. UPDATE access implies READ and WRITE authority. Controls the ability to create a new asset (for example, the names of files users can create). CREATE is when enforcing file naming standards.
CREATE
1346
Administrator Guide
DELETE
Controls the ability to delete or remove the asset from the system. For example, this mode would prevent a file erase or file delete operation. DELETE is useful in preventing accidental deletion of files, as can occur when issuing a del *.* (Windows) or an rm -r *(UNIX/Linux platforms) from the wrong directory level. Controls the ability to search a directory. Controls the ability to execute a program (or setuid system call for UNIX/Linux platforms). Controls the ability to access Unicenter NSM administration objects, such as STATION, CALENDAR, and so forth.
SEARCH EXECUTE CONTROL
For example, you may want to deny a new member of the Payroll department the ability to update the payroll master file, even though this members group typically does have READ/WRITE access to it. You can simply write a specific DENY rule for that user to deny WRITE access to that file. Asset Name: Using Wildcard Masking Characters and Regular Expression Asset names must always be included when defining an asset as a member of an asset group or as the subject of a rule. When you define permissions for an asset, the permission can identify a specific single asset name, or you can use masking characters to create an asset name pattern that matches large groups of assets. Unicenter NSM supports two standard wildcard characters, asterisk (*) and question mark (?). The question mark masks any single character position. The asterisk masks none or more characters; it is equivalent to specifying a question mark for each character in the asset name. The expression *.exe, for example, specifies a match on every file name having an extension of .exe. A solitary asterisk specifies all names, with no regard to the presence of an extension. The following examples show valid masks:
/home/???????/myfile /*/payroll/* /??me/payroll/myfile
Regular Expression
Unicenter NSM supports regular expression to facilitate operations on large groups of assets, specifically WNT-FILE for Windows platforms, UNIX-FILE for UNIX/Linux platforms, and user-defined assets. Using regular expression, you can qualify and protect large groups of assets under one rule by including special control and masking characters as part of the asset name. Regular expression allows more than one asterisk in a single name expression. For example, the expression a*b*c* matches abc, abacus, and acrobatics, but does not match back or attic.
Security Management
1347
Exclusion Processing
Exclusion can be specified when groups of assets should not be matched. Exclusion is specified by prefixing individual name or names expressions with a tilde (~). If an exclusion specifies a drive or a directory path, such as ~A:\FILE or ~EMULATOR\FILE, it only applies to those files on the specified drive or in the specified path. If the exclusion is a simple file name pattern, it applies to all drives and directories.
Concatenating Names
Concatenation can be used to link names. You can specify concatenation by separating each name in the expression with a caret (^). For example, the expression, *.c^*.h^*.def defines a rule that permits access to all files having extensions of .c, .h, and .def. Note: The expression used here illustrates how you would specify concatenation when defining a rule through the Enterprise Management GUI. However, if you are defining a rule using the cautil command line, you must type the caret character twice to represent one caret, since a stand-alone caret is interpreted as an escape character.
Ambiguous Character Sets
Name expressions can contain ambiguous character sets. The characters in a set can be listed individually, as in abc1, or specified as a range of characters, as in a-z. Sets are enclosed in brackets and match any character belonging to the set. If the first character in the set is a tilde (~), then the set matches any single character not in the set. Following are some examples:
[abc] [a-m] *[234][0-9] *[~xyz] [...]*
Matches a or b or c Matches any name that starts with a through m Matches any name that ends with 20 through 49 Matches any name that does not end with an x, y, or z Matches zero or more occurrences of [...]
Unicenter NSM uses the backslash character (\) to indicate that the next character should be taken literally. Use this to prefix any character that would otherwise have a special meaning. For example, the expression, a*[\^\-0-9a-f] will match any name that starts with the letter a and ends with a caret, dash, or hexadecimal character.
Examples
The following expression specifies any .txt file in the root directory except the file named test.txt:
C:\*.txt^~C:\test.txt
The following expression specifies a match on AXYZ, BXYZ, and CXYZ, but not AAXYZ or DXYZ:
[BAC]XYZ
1348
Administrator Guide
Writing Rules When deciding how to assign permissions, you need to answer the following questions before implementing the rules:
What kind of access does the user need for a particular asset? For example, in addition to being able to read a file, should the user be able to write to it?
What permission does your user need so that the operating system can service the initial READ/WRITE access mode? For example, does the operating system need to have READ or WRITE access to one or more assets in order to perform those tasks implicit to servicing a users EXECUTE?
What permissions does the application itself need to be complete? For example, when executing one file, does the application need user access to another file?
The asset name is of critical and specific importance for all asset types, especially WNT-FILE for Windows and UNIX-FILE for UNIX/Linux platforms. See the Windows or UNIX/Linux platform-specific topic following for discussions and examples of handling the unique asset types WNT-FILE for Windows, and UNIX-FILE, UNIX-SETUID, and CA-JOBAUTHORITY for UNIX/Linux. WNT-FILE Asset Type
WNT-FILE
The WNT-FILE asset type describes a policy that governs access to a file or directory. This asset type requires an asset name that represents the full path of a file or directory to which the defined access type (PERMIT, DENY, or LOG) applies. For example, assume the rule you are writing is for a policy that says, Log each attempted open for READ of the payroll file by user ID USER01. To define this policy, the pertinent fields of the various windows would have the following values: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 WNT-FILE c:\default\users\acct\payroll READ LOG
Security Management
1349
If, however, you wanted to write a rule to define a policy that says, Deny all WRITE access to the payroll files by USER01, to define this policy, the pertinent fields of the various windows would have the following values: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 WNT-FILE c:\default\users\acct\payroll WRITE DENY
Note: If others have WRITE access to the payroll files and USER01 does not, then this DENY rule is not necessary. USER01 will be defined implicitly. This rule is only necessary if USER01 belongs to a group that has access and you want to deny USER01 access on an exception basis. DENY rules are usually written only to create exceptions to higher-level permissions. UNIX/Linux-Only Asset Types The asset name is of specific importance for the asset types UNIX-FILE, UNIX-SETUID, and CA-JOBAUTHORITY. The examples that follow explain how each of these asset types uses the asset name.
UNIX-FILE
The UNIX-FILE asset type describes a policy that governs access to a UNIX/Linux file or directory. This asset type requires an asset name that represents the full path of a UNIX/Linux file or directory to which the defined access type (either PERMIT or DENY) applies. For example, assume the rule you are writing is for a policy that says, Log each attempted open for READ of the payroll file by user ID USER01. To define this policy, specify the following values in the pertinent fields of the various windows: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-FILE /usr/acct/payroll READ LOG
1350
Administrator Guide
Assume that you now want to write a rule to define a policy that says, Deny all WRITE access to the payroll files by USER01. To define this policy, specify the following values in the pertinent fields of the various windows: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-FILE /usr/acct/payroll WRITE DENY
Note: If others have WRITE access to the payroll files and USER01 does not, then this DENY rule is not necessary. USER01 will be defined implicitly. This rule is only necessary if USER01 belongs to a group that has access and you want to deny USER01 access on an exception basis. DENY rules are usually written only to create exceptions to higher level permissions.
UNIX-SETUID
The UNIX-SETUID asset type describes a policy that governs access to the UNIX/Linux system call setuid(2). This asset type requires an asset name that represents the following two items:

The file or directory (subject path) to which the setuid policy applies The user to whom the caller is attempting to setuid (the set-to user)
These two items must be separated by a pound sign (#) in the asset name. For example, assume the rule you are writing is for a policy that says: There are setuid programs owned by root in the directory, /usr/hacker01. Deny user ID USER01 access to the implicit setuid to root that happens when this program is executed. To define this policy, specify the following values in the pertinent fields of the various windows: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-SETUID /usr/hacker01/*#root EXECUTE DENY
Security Management
1351
Assume that you now want to write a rule for a policy that says, Log each time that USER01 becomes (sus to) root. To define this policy, specify the following values in the pertinent fields of the various windows: User ID: Asset Type: Asset Name: Access Modes: Access Type:
CA-JOBAUTHORITY
USER01 UNIX-SETUID /*#root EXECUTE LOG
The CA-JOBAUTHORITY asset type can be used to secure the administration of Workload Management job submission parameters. The Workload Management components of Unicenter NSM on the UNIX/Linux platform are capable of submitting jobs for execution (programs or shell scripts) on behalf of any users logon ID defined on your system, without requiring knowledge of that users password. This powerful feature could potentially be abused. An unscrupulous individual could submit jobs under the guise of other users to do things that he would otherwise be prevented from doing. The CA-JOBAUTHORITY asset type can be used to restrict the names of the programs or shell scripts that a workload administrator can specify as the job to submit, as well as the logon ID on whose behalf that job is submitted. For example, if you want to make certain that the workload administrator whose logon ID is USER01 does not define or alter a Workload Management jobs submission parameters to submit the shell script /prod/payroll on behalf of the user ID root, define a rule as follows: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 CA-JOBAUTHORITY root#/prod/payroll CONTROL LOG
Take special note of the way that the asset name is specified in this example. The first part of the asset name specifies the logon ID, in this case, root. The second part of the asset name is the name of the file, in this case, /prod/payroll. A single pound sign (#) separates these two parts.
1352
Administrator Guide
Examples The following examples present some typical questions regarding access rules, and the answers. These questions assume the system is running in DENY mode. As they illustrate, when putting your system in DENY mode, the set of permissions you initially define may not be adequate to grant your user community access to all the tools it requires to execute and complete jobs.
How Do I Deny a User Access to a File?
Do nothing. When Security Management is in DENY mode, all users in FAIL mode are denied access to any assets that do not have an explicit PERMIT rule for the user or user group.
How Do I Grant a User Access to the Event Console Log?
You will need a PERMIT rule with the following information: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 CA-CONLOG * CONTROL PERMIT
How Do I Grant Users Execute Access to the File, C:/hello.exe?
You will need a PERMIT rule with the following information: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-FILE c:/hello.exe EXECUTE PERMIT
Initially, this may seem to be all that is required for EXECUTE access to this file. However, there is another rule required that may not be as obvious in this situation. For the user to successfully execute this file, they will also need to be able to READ from the root directory of the C:/ drive.
Security Management
1353
Therefore, you need the following additional PERMIT rule with the associated asset type, asset name, and access modes: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-FILE c:/ READ or SEARCH PERMIT
How Do I Grant Users Access to the File: D:/users/kevin/myprog.bat?
Based on the logic of our previous example, we know we need at least the following PERMIT rules: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 UNIX-FILE d:/ READ or SEARCH PERMIT
User ID: Asset Type: Asset Name: Access Modes: Access Type:
USER01 UNIX-FILE d:/users READ or SEARCH PERMIT
USER01 UNIX-FILE d:/users/kevin READ or SEARCH PERMIT
1354
Administrator Guide
USER01 UNIX-FILE d:/users/kevin/myprog.bat READ or SEARCH PERMIT
Important! Notice the READ access mode requirement in the last PERMIT rule. Because myprog.bat is a batch file, UNIX/Linux needs READ access in addition to EXECUTE so that the operating systems shell interpreter can read the instructions from the file to execute. A similar requirement exists for .cmd files and for UNIX/Linux shell scripts. When the system is in DENY mode, it is important that you think about what the operating system needs to be able to do for your permissions to be properly defined.
I Want My Users to Be Able to Use Microsoft Write for Windows. What Permissions Do I Need?
Assuming you have installed Windows onto the C: drive in its default directory, you will need to define the following PERMIT rules: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 WNT-FILE c:\ READ or SEARCH PERMIT
USER01 WNT-FILE c:\winnt35 READ or SEARCH PERMIT
Security Management
1355
USER01 WNT-FILE c:\winnt35\write.exe EXECUTE PERMIT
These rules let your users run Microsoft Write for Windows; however, they may be in for a surprise if they ever need to use the online Help. Microsoft Write uses a separate file named write.hlp to display online Help for write.exe. Since write.hlp is a separate file, and there is no explicit PERMIT rule for this file, your users will be denied the ability to use online Help until you define the following PERMIT rule: User ID: Asset Type: Asset Name: Access Modes: Access Type: USER01 WNT-FILE c:\winnt35\write.hlp READ PERMIT
Defining Access Permissions

When Security Management is called upon to make a real-time decision about whether to permit a user or user group access to an asset, it must identify two entities: the user and the asset. Once identified, Unicenter NSM must determine what policies (if any) have been defined that describe how this access attempt should be handled. Defining these policies is typically done using one of two approaches: user perspective or asset perspective. Defining an access permission from the user perspective can be thought of as, What asset does this user need to access, and where? Defining an access permission from the asset perspective can be thought of as, Who requires access to this asset, and where? Unicenter NSM is uniquely capable of supporting both perspectives in granting access permissions to assets. A common requirement of both perspectives is that the asset access rule has a specific access mode and a specific access type. See the section Access Modes, presented earlier in this chapter for lists of access modes and access types.
1356
Administrator Guide
Access Determination
When a user attempts to access an asset, Security Management looks at all rules associated with the user to find the ones that apply to the access in question. Security Management only considers rules that match the asset type, asset name, asset node, access mode, and any conditions determined by a calendar or criteria profile. If several permission rules match an asset name, the rule with the best fit (closest match to asset name) is used, and an access type DENY overrides LOG, which overrides PERMIT. Step-by-step procedures for defining your access permissions are provided in the online CA Procedures Guide under the following topics:

Permitting Users to Assets Permitting Assets to Users
Rule Evaluation Two decisions are made during the security evaluation process. The first decision is whether a specific access attempt is considered authorized. If the access is not authorized, a violation results and the second decisionwhat to do about the unauthorized access attemptdepends on the Enforcement mode in effect. The only Enforcement mode that results in access being denied is FAIL mode, whether explicitly set in the user profile, or implicitly set, by referring in the user profile, to a System Violation Mode of FAIL. For additional information about Enforcement modes, see the section Access Violations and Enforcements, presented earlier in this chapter.
Setting CAISSF Scoping Options

Using the CAISSF Scoping feature, you can assign the rights to administer Unicenter NSM securable objects in a granular fashion. Because CA asset types identify specific parts of Unicenter NSM, you can secure those parts by defining an access permission using CAISSF Scoping. Some examples of permissions using a scoping rule are as follows:

User can administer user profiles for this node, but not for that node. User can use DEFINE, but not ALTER. User can modify other parameters in a user profile, but not the password (see Examples).
Scoping rules can be written only for CA asset types (those having the prefix CA-), but not for user-defined asset types. Scoping can narrow an access permission to a keyword object, a data object, or a command object. Each of these has a specific CA asset type and an associated Security Management option (which must be set before scoping can be applied).
Security Management
1357
Each object, its related option, and its CA asset type (identified by the suffix) are shown following: Object to Be Secured Keyword
Security Management Option Windows: SSF Keyword Scope UNIX/Linux platforms: SSF_SCOPE_KEYWORD Windows: SSF Data Scope UNIX/Linux platforms: SSF_SCOPE_DATA Windows: SSF Command Scope UNIX/Linux platforms: no option
CA Asset Type Suffix KW KW DT DT CM (none)
Data
Command
CAISSF Keyword Scope Scoping of keyword asset types provides validation against Security Management policies based on the specified keywords. The use of keyword scoping provides finer granularity of access to CA asset types. For example, you can deny access to specify the UID of a user, but allow access to specify the user name. Keyword scoping rules are specified for asset types having a suffix of KW. For instance, use CA-USER-KW to apply a keyword scoping rule to the CA-USER asset type. CAISSF Data Scope Scoping of data asset types provides validation against Security Management policies based on the data specified for a keyword value. Using data scoping, access to CA asset types can be limited to the level of the value within a keyword. For example, access to update the CA-USER object can be restricted for ID=root, but allowed for other user accounts. Data scoping rules are specified for asset types having a suffix of DT. For instance, use CA-USER-DT to apply a data scoping rule to the CA-USER asset type.
1358
Administrator Guide
When specifying the asset ID (type) for a CA data object (suffix DT), you must supply a setup character immediately preceding the operand (as the underscore is used with the node= operand in the previous example). This character is used by the rule evaluator to edit the definition, and is required to indicate to the evaluator that the next specification is a new operand. You can use one of the following characters: ~ / | _ tilde slash pipe underscore
Note: Scoping on Data objects is not supported through the EmSec APIs. CAISSF Command Scope Scoping of command asset types provides validation against Security Management policies based on the specified command. Using command scoping, access to CA asset types can be limited to specific operations. For example, a user can create new user accounts, but cannot update existing accounts. Command scoping rules are specified for asset types having a suffix of CM. For instance, use CA-USER-CM to apply a command scoping rule to the CA-USER asset type. Command scoping is only valid for use on Windows platforms. Defining Scoping Rules A scoping rule can be defined using either the Security Management GUI or the cautil command line interface when defining access permissions. Examples of using the GUI and using the cautil command line are provided in the online CA Procedures under the topic Restricting Access Permission (Scoping).
Performing a Commit Process

Remember, when you finish defining or modifying any security rules for users, user groups, access permissions, and asset groups, you must execute a commit process to put the new rules into effect (see the section Understanding the Commit Process, presented earlier in this chapter). See the instructions for performing the commit process in the online CA Procedures under the topic, Committing Your New Rules in WARN Mode.
Security Management
1359
Phase 4: Set Options for Production, FAIL Mode
Phase 4: Set Options for Production, FAIL Mode

After you have defined your security policies and carefully reviewed them, proceed with this phase of implementation to place your security policies into an active enforcement, or FAIL mode. With System Violation mode set to FAIL, and after executing a commit process, violations will be logged to the Event Console Log, access will be denied, and violation actions will be enforced. See the instructions for setting options in the online CA Procedures under the topic, Setting Options for Production, FAIL Mode.
Enabling the Security Logon Intercept for Windows

After you have completed the FAIL mode cycle of Security Management implementation for Windows platforms, you should enable auditing and rule evaluation of Windows logons through the Unicenter NSM winlogon.exe file. Unicenter also uses this executable to intercept and control passwords. See the instructions for enabling the logon intercept in the online CA Procedures under the topic, Enabling Logon Intercept for the Windows Platform.
Activating Security Intercepts for UNIX/Linux Platforms

To activate Unicenter NSM control over user access to the system (login), ID switching (su), and password changing (passwd), execute the secadmin -a command. Note: If you have already activated these intercepts as part of the post-installation tasks, there is no need to activate them again. To activate security intercepts, log in as root and enter the following command:
secadmin -a
Note: Once activated, real-time security components govern access to these privileges (login, su, passwd, and so on). If the real-time security components are not active, only those users whose IDs are in the CAISSF authorization list (identified by the SSF_AUTH option of the Security Management configuration file, secopts) are permitted to access the system.
1360
Administrator Guide
Reactivate a Suspended User ID
Performing the Commit Process

Now that you have established your security policies for FAIL mode, you must execute the commit process to put those policies into effect. See the instructions for the commit process in the online CA Procedures under the topic, Performing a Commit Using the GUI. See the secadmin command in the online CA Reference for more information about using secadmin.
Reactivate a Suspended User ID

After you fully activate Security Management, you may find that some user IDs become suspended quite quickly, as users are unfamiliar with the new access rules and violation modes. These user IDs will need to be reset before the suspended accounts can be utilized. See the instructions for reactivating a user ID that is suspended in the online CA Procedures under the topic, Reactivating a Suspended User ID.
Deactivate Security Management

Under extremely serious circumstances, such as a hardware failure causing a loss of the Security Management database and DSBs, you may find it necessary to deactivate Security Management. Important! Understand that after Security Management has been deactivated, the only security in effect will be that inherent to the native operating system. Should it become necessary to deactivate Security Management, see the instructions in the online CA Procedures under the topic, Deactivating Security Management.
Security Management
1361
Optional Features
Optional Features
Security Management offers several optional features that your enterprise may find beneficial. These features are listed following and discussed in detail in this section.
User Profile Synchronization (UPS), which includes the UPS/Command Propagation Facility Interface to RACF, eTrust CA-ACF2, and eTrust CA-Top Secret running on z/OS and OS/390, and Unicenter NSM running on Windows and UNIX/Linux computers Distributed Computing Environment (DCE) Synchronization Database Synchronization (DBS) Windows Backup Domain Controller Support Native Operating System Database Update Password Change Notification Facility FTP Proxy for UNIX/Linux Rexec Proxy for UNIX/Linux
User Profile Synchronization (UPS)

User Profile Synchronization (UPS) permits Windows and UNIX/Linux nodes to participate in the sharing of password and status updates to user accounts. Additionally, UPS provides the Command Propagation Facility (CPF) Interface to communicate user profile updates to eTrust CA-ACF2, eTrust CA-Top Secret, and or RACF running on z/OS and OS/390, and Security Management running on Windows and UNIX/Linux computers. For more information on this interface, see the section UPS/Command Propagation Facility Interface, presented later in this chapter.
How It Works
The UPS feature has two associated daemons: the UPS daemon and the CPF daemon. The UPS daemon is required for automatic synchronization between Security Management databases. You will need to activate the CPF daemon only when synchronizing user profile updates with eTrust CA-ACF2, eTrust CA-Top Secret, and IBM RACF running on z/OS and OS/390, and Security Management running on Windows and UNIX/Linux computers. When the UPS daemon receives a UPS event, the Security Management evaluators authenticate the event prior to performing the UPS update. You can configure the UPS daemon to perform this validation on behalf of a designated user, or as the user whose account is being synchronized.
1362
Administrator Guide
Optional Features
In either case, UPS calls the evaluators with an asset type of CAUPS-NODE, and an access mode setting of CONTROL. The asset name (or asset ID) within this request is the name of the station that has sent the event to this station. You can then write access rules to specifically ALLOW, LOG, or DENY access to these UPS events. Once you have activated UPS, Unicenter NSM notifies the UPS daemon when a password or a status update occurs. (These password and status updates can be performed through Security Management administration, or can occur as the result of Security Management real-time processing, for example, account suspension due to a violation.) When the UPS daemon receives notification of a change, it contacts the participating nodes to receive and process the event. You identify the participating nodes by defining a Station Group, and then supplying the Station Group name in the user profile. (Define Station Groups through the Unicenter Station Group object.) Note: The UPS feature uses the Computer Associates International Common Communications Interface (CAICCI). You will need to configure CAICCI to communicate with each station you would like to include for UPS transactions.
Restrictions on UNIX/Linux Platforms
On UNIX/Linux platforms (only), UPS will only synchronize status and password information associated with a global user definition (node value of a blank, or unspecified). Any node specification within the UPS event is stripped prior to performing the UPS update. The UPS feature is not intended to synchronize status and password changes made within a UNIX/Linux environment where a common Security Management database is being shared among multiple hosts. In an environment where multiple hosts are sharing a Security Management database, the UPS feature should be configured on only one host (typically on the host where the Security Management database resides), and serve as a gateway between Security Management running on UNIX/Linux, and Security Management running on other platforms. The Database Synchronization (DBS) feature can then be configured to propagate changes in real time between the various UNIX/Linux nodes running Security Management.
Security Management
1363
Optional Features
UPS-Related Security Management Options As with all Security options, the UPS-related options are read at startup. To have option updates reflected by the Security Management daemons that use them, you must recycle the Security Management daemons. The following Security Management options are associated with the UPS feature. Windows Option: User Profile Sync - Logging Options This option specifies where the UPS log of transactions will be kept. You can specify one of three destinations by setting this option to one of the following values: Log file Unicenter NT Event Log Transactions will be kept in a file in %CAIGLBL0000%\logs\caups.log. This is the default. Transactions will be logged to the Event Console Log. Transactions will be logged in the Windows Event Application.
UNIX/Linux Option: UPS_LOGOPTION This option specifies where the UPS log of transactions will be kept. You can specify one of two destinations by setting this option to one of the following values: File Unicenter Transactions will be kept in a file in $CAIGLBL0000/caups.log. This is the default. Transactions will be logged to the Event Console Log.
1364
Administrator Guide
Optional Features
Windows Option: User Profile Sync - Logon As User UNIX/Linux Option: UPS_LOGONASUSER This option determines whether inbound transactions can be processed with the Master node user ID. When this option is set to YES, the user ID of the person who initiated the transaction on the Master node will be carried with the transaction to the remote node. If this option is set to NO, the value of the User Profile Sync - SSF User for UPS option (UPS_LOGONUSER option for UNIX/Linux platforms) is used. If this option is set to YES, it overrides the value of that option. The default is NO. To configure UPS to perform evaluation on behalf of a designated user, set this option to NO, and set the User Profile Sync - SSF User for UPS (UPS_LOGONUSER for UNIX/Linux platforms) option to the user ID against which you would like to have the UPS events evaluated. To configure UPS to perform evaluation on behalf of the user who originated the event, set this option to YES. In this case, the User Profile Sync - SSF User for UPS (UPS_LOGONUSER for UNIX/Linux platforms) option is ignored. Windows Option: User Profile Sync - SSF User for UPS UNIX/Linux Option: UPS_LOGONUSER This option identifies the user who will perform the user profile updates on this node. This user ID is used for CAISSF evaluation. Specify the user ID for this option value. The default for Windows is CAUNINT. The default for UNIX/Linux is root. If the User Profile Sync - Logon As User option (UPS_LOGONASUSER option for UNIX/Linux platforms) is set to YES, this option is ignored. Windows Option: User Profile Sync - Master Node Use this option to identify the name of the UPS Master node, that is, the node that will route UPS transactions. To have this node act as a Master node, enter the node name of the local computer. If this computer is not a Master node, changes made to users on this computer are not propagated through UPS transactions. The default is the current computer name. UNIX/Linux Option: UPS_MASTER Set this option to indicate whether UPS events should be generated from this computer. If set to YES, outgoing UPS events will be generated when updates to a user account are made (either directly on this computer, through UPS, or through DBS) which affect the status or password information for that user. This option can be set to YES or NO. The default is NO.
Security Management
1365
Optional Features
Windows Option: User Profile Sync UPS Station Group UNIX/Linux Option: USER_UPSSTAT As values for this option, supply a list of stations to which you wish UPS events sent. Windows Option: User Profile Sync - Check Old Passwords UNIX/Linux Option: UPS_CHECKOLDPASSWORDS This option is used only by eTrust CA-Top Secret running on z/OS and OS/390 (see the section UPS/Command Propagation Facility Interface, presented later in this chapter). Set this option to ensure that the old password is checked for a match before allowing a new password to be set. The default is NO. When a user is required to update his password as part of system entry validation, eTrust CA-Top Secret notifies all other UPS/CPF connected nodes of that change. If a matching user ID is found on a remote node, eTrust CA-Top Secret first compares the password of the remote user ID with the old password of the local user ID to verify that they are not two different user IDs. If the passwords match, the password on the remote node is updated. For example, USER01 signs on to TSO on nodeA. The users current password clear has expired, so the user changes it to always. Through UPS/CPF, that change is sent to nodeB, a remote Windows node. When UPS on Windows finds a USER01 in the Security database of nodeB, it asks, Is the current password clear? YES =The password of user01 on nodeB is also updated. NO = UPS/CPF assumes that user01 on nodeB is not the same person as user01 on nodeA, and leaves the nodeB password unchanged. UPS/CPF sends a message to the Event Management console to record this condition. Windows Option: User Profile Sync Days to Store and Forward UNIX/Linux Option: UPS_STOREINTERVAL Transactions are kept in the store-and-forward file if the target node cannot be reached. Use this option to specify the number of days those transactions that could not be routed will be retained in the store-and-forward file before they are dropped. The default is 3. UPS will retry failed events every 15 minutes.
1366
Administrator Guide
Optional Features
Windows Option: User Profile Sync Proxies Route Using User Profiles UPS Station Group UNIX/Linux Option: UPS_PROXYROUTE Proxy routing permits target nodes to rebroadcast transactions to new nodes. This option determines whether this node will route transactions it receives from other UPS daemons to the stations indicated within the users UPS station group. This option can be set to YES or NO. The default is NO. Windows Option: CPF Target Systems UNIX/Linux Option: CPF_TARGETS The setting of this option identifies the target z/OS or OS/390 systems for the UPS/CPF Interface. The setting can be one of the following: NONE ACF2 RACF TOP SECRET ACF2 & RACF ACF2 & TOP SECRET RACF & TOP SECRET ACF2 & RACF & TOP SECRET The default is NONE. Windows Option: User Profile Sync - Password Change Case This option lets you apply a consistent rule to password case, regardless of its form when received from the mainframe. The setting of this option can be one of the following: LOWER UPPER NOCHANGE Translate all passwords to lowercase. This is the default. Translate all passwords to uppercase. Update Windows with the password exactly as received.
Security Management
1367
Optional Features
Mapping User IDs for UPS Events UPS provides the facility that lets you map user IDs. Incoming UPS events can have the user ID mapped to another user ID within the UPS event before the event is executed on the target station. This enables synchronization between stations where a user ID may be different.
How It Works
The UPS user ID mapping file is named upsalias.cfg. For Windows, this file resides in the $CAIGLBL0000\db directory; for UNIX/Linux platforms, this file resides in the $CAIBLGL0000/secu/db directory. By default, this file does not exist. If you need to translate (or map) user IDs for UPS events, you will need to create this file. Each entry in the file must be on its own line, and has the following format: <incoming-userid>,<mapto-userid>, For example, to translate user JOHN to user ID jssmith, the entry would look like the following: JOHN,jssmith,
Translation
1.
If a user ID is found in the mapping file, then the mapto-userid is used. For UNIX/Linux platforms, further tests are performed on the mapping file:
2.
If the user ID is not found in the mapping file, then a system call is made to see if the user ID is defined to the system (getpwnam()). If the user ID exists, then it is used. If both tests 1 and 2 shown previously fail, then the user ID is translated to lowercase and it is used.
3.
1368
Administrator Guide
Optional Features
UPS/Command Propagation Facility Interface This section provides information on the User Profile Synchronization (UPS)/Command Propagation Facility (CPF) Interface to RACF, eTrust CA-ACF2, and eTrust CA-Top Secret running on z/OS and OS/390, and Security Management running on Windows and UNIX/Linux computers.
Minimum Requirements
If you want to implement this interface, you must first satisfy the following minimum requirements:
Unicenter NSM, including the following components: Calendar Event Management Security Management Stations
Initialized and populated Security Management databases (see the section Phase 2: Populate the Database, QUIET Mode, presented earlier in this chapter.) TCP/IP
When you have satisfied the minimum requirements and understand how you are going to configure your station groups, you are ready to configure the CPF Interface. See the section Configuring the UPS/CPF Interface, presented later in this chapter.
How It Works
Once the UPS and the CPF daemons are started, Security Management is ready to perform user profile synchronization of all user status or password updates for users who have a UPS station group identified in their user profiles. A UPS station group should contain a list of stations to which you would like the UPS daemon to send updates. The stations within the station group must be defined with a type of CPU, and the appropriate station node type should be specified (as UNIX/Linux, Windows, z/OS and OS/390, and so on). Once the Station and Station Group definitions have been created, and a UPS station group value assigned to the user, then any change to this users status or password will be communicated to the other computers within the specified UPS station group. If changes are made to the definition of a station group, such as adding a new station, then the UPS daemon must be recycled to recognize these changes.
Security Management
1369
Optional Features
If the UPS daemon is unable to deliver an update to a station, the UPS event is written to the store-and-forward file, caups.dat (located in the CAIGLBL0000 directory). An attempt to send these stored UPS transactions will be made every 15 minutes until they are successfully sent to a station, or until the value of the User Profile Sync Days to Store-and-Forward option (UPS_STOREINTERVAL option for UNIX/Linux platforms) has elapsed. If you would like to specify a default UPS station group to be used automatically for all newly defined users, you can set the User Profile Synch UPS Station Group option (USER_UPSSTAT for UNIX/Linux) to the name of a default UPS station group. Once set, all new user definitions that do not identify a Station Group name will be assigned to the Global Station Group. Note that this is for newly defined users only. Additionally, if you change the Global Station Group name for the USER_UPSSTAT option, this will not change the UPS station group names that have already been assigned to any user. Attention RACF Clients! z/OS and OS/390 RACF will uppercase any passwords entered by an administrator. This means that all password synchronization from RACF to Unicenter NSM UPS will be in uppercase. Assume, for example, that a RACF administrator enters ALU TESTID PASSWORD(newpsd); the Unicenter NSM password becomes NEWPWD. Configuring UPS UPS must be configured on each computer that is to be involved in synchronizing user password and status changes among the databases. This requirement consists of every Windows computer, UNIX/Linux computer, and z/OS or OS/390 computer that will be listed in your Station Group. You can configure these computers in any order, and even concurrently. See the instructions for configuring the CPF in the online CA Procedures under the topic, Configure the UPS/CPF Interface. If you want to configure UPS to forward (route) incoming UPS events to other stations, you will need to set the User Profile Sync Proxies route using User Profiles UPS Station Group option (UPS_PROXYROUTE option for UNIX/Linux platforms) to YES. This will cause incoming UPS events to be forwarded to the stations listed in the UPS station group defined for a user. Important! The UPS_PROXYROUTE option should be set to YES on only one host within a UPS configuration. If two stations are configured to route UPS events between them, an infinite loop of UPS synchronization events will occur when a third station sends a UPS event.
1370
Administrator Guide
Optional Features
Additionally, there is no protection against circular UPS configurations. You should not configure loops between stations that are routing. Assume, for example, that three stations are configured with the UPS_PROXYROUTE option set to YES, and stationA sends its events to stationB, then stationB sends events to stationC and stationC to stationA. An infinite loop of routed UPS events will occur. Take every precaution to avoid configuring a loop within the context of UPS stations. A recommended approach for setting up a UPS configuration is to model the stations that are participating in UPS synchronization after a star structure. In the star structure, all nodes send UPS events to all nodes, but no nodes route UPS events to other nodes (UPS_PROXYROUTE is set to NO). Once you set the UPS_PROXYROUTE option to YES, you must be careful to avoid recursion.
Distributed Computing Environment (DCE) Synchronization

DCE synchronization enables Unicenter NSM administrators on Windows and UNIX/Linux to ensure that administrative and end-user changes made through Unicenter NSM are automatically reflected in the DCE security registries. Unicenter NSM administrators can create, alter and delete DCE user accounts. Unicenter NSM synchronizes DCE with password and status updates to user accounts.
How It Works
The DCE Synchronization Option is built upon the Security Management base with the UPS (user profile synchronization) daemon. When the DCE Synchronization Option is activated, a DCE synchronization daemon is started. The daemon registers with the UPS daemon and is notified when there is any user account administration performed, including password or status updates. (These password and status updates can be performed through Security Management administration, or can occur as the result of Security Management real-time processing, for example, account suspension due to a violation.) The DCE synchronization daemon then interacts with the DCE security registry to keep the user account information synchronized. The DCE daemon registers with the DCE security registry (by logging into DCE) using an administrative principal name (user account) specified during installation. Once the initial handshake with DCE succeeds, the DCE synchronization daemon is able to create, alter and delete DCE accounts in the registry.
Security Management
1371
Optional Features
DCE-Related Security Management Options The following Security Management options are associated with the DCE synchronization feature. These options are discussed in detail in the paragraphs that follow this table.
Windows Option: UPS_DCEGATEWAY UNIX/Linux Option: UPS_DCEGATEWAY This option specifies where the DCE synchronization daemon will be started. The value of this option is the node name of the computer where the DCE synchronization daemon will run. Usually this node name will be the same as the computer where Unicenter is installed. Windows Option: UPS_DCEADMIN UNIX/Linux Option: UPS_DCEADMIN This option determines the DCE administrative principal name under which the DCE synchronization daemon will run to gain access to and update the DCE security registry. This option defaults to cell_admin. Windows Option: UPS_DCEKEY UNIX/Linux Option: UPS_DCEKEY This option specifies the file name of the DCE keytab file, which combined with the UPS_DCEADMIN principal name will allow the DCE synchronization daemon to authenticate itself to the DCE security registry. The value of this option is the fully qualified file name of the previously created keytab file.
Creating the keytab File
You can create the keytab file by going into dcecp and running the following command:
keytab create /.:/hosts/hostname/config/keytab/dceadmin -storage full_file_name -data {dceadmin plain 1 dceadmin_password}
where: hostname Specifies the host name for which you want the key file to be valid. dceadmin Specifies the principal name that the keytab will represent.
1372
Administrator Guide
Optional Features
full_file_name Specifies the fully qualified file specification that will be used to hold the keytab file. dceadmin_password Specifies the password for the principal name that the keytab will represent. A sample command to create a keytab file is listed following. The command is assumed to create a keytab file in the directory /private/keytab. The keytab filename will be keytab.cell_admin. The principal represented in the keytab file is cell_admin. The password for cell_admin is sec123. The node the keytab file will be on is named dcehost1.
keytab create /.:/hosts/dcehost1/config/keytab/cell_admin storage /private/keytab/keytab.cell_admin data {cell_admin plain 1 sec123}
Starting DCE for UNIX/Linux
As with all Security options, the DCE-related options are read at startup. To have option updates reflected by the Security Management daemons that use them, the Security Management daemons need to be recycled. To activate DCE on a UNIX/Linux platform, set the START_DCE_DAEMON activation flag to YES. The next time the Security Management component is started, the DCE synchronization daemon will also start. To start the DCE synchronization daemon manually, run the following secadmin command:
secadmin -i dce
You can manually stop the DCE synchronization daemon by running the following command:
secadmin -s dce
Starting DCE for Windows
To activate DCE on Windows, set the CAIACTDCE environment variable. Setting this variable to YES will cause the DCE Synchronization daemon to start when Security Management is started. Use the cautenv command to set this variable. The command syntax is as follows:
cautenv setglobal caiactdce yes
You must recycle Security Management to have the new configuration take effect. The next time the Security Management component is started, the DCE synchronization daemon will also start.
Security Management
1373
Optional Features
Database Synchronization (DBS)

The Database Synchronization (DBS) feature of Security Management performs synchronization of all attributes associated with a user account in the Decision Support Binary (DSB) User files and memory versions of the database. This synchronization includes the addition of user accounts, any alterations to existing user accounts, and the deletion of user accounts. Any changes made by Security Management through auditing, such as password and status changes, are also included. DBS can be used to synchronize changes across UNIX/Linux computers or across Windows computers, but not across both. The essential benefit of DBS is that you can administer user accounts on one host (or station), and have that administration take effect on a set of like hosts in an automated manner without requiring the Security Management commit process. An additional benefit, associated with the auditing events that occur within the realm of Security Management, is keeping password and status for user accounts consistent within this set of Unicenter hosts.
How It Works
DBS facilitates the configuration and subsequent automated synchronization of changes made to user definitions. The initial design objective was for DBS to support Unicenter configurations that share a Security Management database between multiple hosts, but this design has been extended to support an environment where the use of multiple Security Management databases has been implemented. DBS is activated at the computer level. Therefore, changes made to any user accounts on a DBS-enabled computer will generate DBS events. DBS cannot be configured on a user-by-user basis. Three individual Security Management options let you specify the types of DBS events that you would like to generate: DEFINE transactions, ALTER transactions, and DELETE transactions. DBS will also generate outgoing UPS events on stations that are configured with UPS. UPS events are only triggered when a change is made to a user account that affects either the password or status for that user, and that user has a UPSSTATGROUP keyword value specified within their user definition. This integration between UPS and DBS automates synchronization events to and from Security Management on UNIX/Linux, and Security Management running on other platforms.
Restrictions
As previously stated, this feature operates only in a UNIX/Linux-to-UNIX/Linux or a Windows-to-Windows environment. Additionally, to have DBS perform real-time updates to the DSB representations of user definitions within Security Management, the Dynamic Update for DSB/SAM option (see the UPDATE_EXTERNAL option for UNIX/Linux platforms) must be set to YES.
1374
Administrator Guide
Optional Features
DBS-Related Security Management Options The following Security Management options are associated with the DBS feature. These options are discussed in detail in the paragraphs that follow this table.
Windows Option: Dynamic Update for DSB/SAM UNIX/Linux Option: UPDATE_EXTERNAL This option indicates if real-time updates should be performed. This option must be set to YES to have DBS perform real-time updates to any/all Decision Support Binary (DSB) representations of user accounts within Security. This option does not affect updates made to the Security Management databases. Windows Option: Maximum Number of User Records Specifies the maximum number of users that can log on. When this number is reached, Unicenter purges the users who have been logged on the longest. Those users must log on again. The number you specify should always be greater than the total number of users defined in the Security Management database. Ensure that this database can accommodate the number of users you indicate before increasing this number. The range is 1 to 999999. The default is 500. UNIX/Linux Option: SSF_NUMUSRS Specifies the maximum number of logon IDs or User profiles maintained by CAISSF. You must define a substantial block of memory to manage this number. The number you specify should always be greater than the total number of users defined in the Security Management database. Ensure that this database can accommodate the number of users you indicate before increasing this number. The range is 1 to 999999. The default is 500. Windows Option: UPS Database Sync - Accept Alter Transactions This option specifies whether any alteration to a user account definition should generate a DBS event. This includes both administration and auditing updates to user accounts. This option can be set to either YES or NO. The default is YES. UNIX/Linux Option: SYNC_ALTER This option is used by both the UPS and DBS features. Set this option to YES to enable outgoing ALTER events. This includes both administration and auditing updates to user accounts. This option can be set to either YES or NO. The default is YES.
Security Management
1375
Optional Features
Windows Option: UPS Database Sync - Accept Define Transactions This option specifies whether the definition of a new user account should generate a DBS event. This option can be set to either YES or NO. The default is YES. UNIX/Linux Option: SYNC_DEFINE This option is used only by the DBS feature. Set this option to YES to enable outgoing DEFINE events. This includes only administration updates to user accounts. This option can be set to either YES or NO. The default is YES. Windows Option: UPS Database Sync - Accept Delete Transactions This option specifies whether the deletion of a user account should generate a DBS event. This option can be set to either YES or NO. The default is YES. UNIX/Linux Option: SYNC_DELETE This option is used only by the DBS feature. Set this option to YES to enable outgoing DELETE events. This includes only administration updates to user accounts. This option can be set to either YES or NO. The default is YES. Windows Option: UPS Database Sync - Global Station Group UNIX/Linux Option: DBS_STATGROUP This option identifies a station group containing a list of stations to which DBS events should be sent. This option (in conjunction with one or more Accept Alter Transactions/SYNC_ALTER, Accept Define Transactions/SYNC_DEFINE, or Accept Delete Transactions/SYNC_DELETE options) constitutes the activation of the DBS feature. Windows Option: UPS Database Sync - Auditing Data Level UNIX/Linux Option: DBS_AUDITDATALEVEL This option specifies the amount of data that should be sent within the DBS event during an audit of a user account. Either the changed data (CHANGED) or all data (ALL) can be specified. The default is CHANGED. When the value is set to CHANGED, only the attributes associated with the user definition that have changed as part of the update will be sent. When the value is set to ALL, then the entire user profile is sent within the DBS event whenever an update occurs to that profile. The DBS_AUDITDATALEVEL option is for auditing user account information.
1376
Administrator Guide
Optional Features
Windows Option: UPS Database Sync - Admin Data Level UNIX/Linux Option: DBS_ADMINDATALEVEL This option specifies the amount of user data that should be sent within a DBS event when an administration change is made to a user account. Either the changed data (CHANGED) or all data (ALL) can be specified. The default is CHANGED. When the value is set to CHANGED, only the attributes associated with the user definition that have changed as part of the update will be sent. When the value is set to ALL, then the entire user profile is sent within the DBS event whenever an update occurs to that profile. The DBS_ADMINDATALEVEL option is for administering user account information (either through the cautil command line interface or from the Security Management GUI). This option applies to ALTER only. A DEFINE will always send ALL information associated with a user definition. A DELETE operation will send the user ID and node values only. UNIX/Linux (only) Option: ACCEPT_DBS_STATGROUP This option identifies a defined station group containing a list of stations that are allowed to send DBS events to this computer. If no station is included within this station group definition, the DBS event will be rejected. If this option is left blank (unspecified), then any station can send DBS events to this station (all events will be processed). If a station group ID is specified as the value for this option, then only the stations defined within this station group are allowed to send synchronization events to this station. All others will be rejected.
Security Management
1377
Optional Features
Windows Option: User Profile Sync - Logging Options This option specifies where the UPS log of transactions will be kept. One of three destinations can be specified by setting this option to one of the following values: Log file Unicenter Transactions will be kept in a file in %CAIGLBL0000%\logs\caups.log. This is the default. Transactions will be logged to the Event Console Log.
NT Event Log Transactions will be logged in the Windows Event Application. UNIX/Linux Option: UPS_LOGOPTION This option specifies where the UPS log of transactions will be kept. One of two destinations can be specified by setting this option to one of the following values: File Unicenter Transactions will be kept in a file in $CAIGLBL0000/caups.log. This is the default. Transactions will be logged to the Event Console Log.
Windows Option: User Profile Sync - Master Node Set this option to identify the name of the UPS Master node, that is, the node that will route UPS transactions. To have this node act as a Master node, enter the node name of the local computer. The default is the current computer name. UNIX/Linux Option: UPS_MASTER Set this option to indicate whether UPS events should be generated from this computer. If set to YES, outgoing UPS events will be generated when updates to a user account are made (either directly on this computer, through UPS, or through DBS) which affect the status or password information for that user. This option can be set to YES or NO. The default is NO. Windows Option: User Profile Sync - Days to Store and Forward UNIX/Linux Option: UPS_STOREINTERVAL Transactions are kept in the user-defined store interval if the target node cannot be reached. Use this option to specify the number of days those transactions that could not be routed will be retained in the store-and-forward file before they are dropped. The default is 3.
1378
Administrator Guide
Optional Features
UNIX/Linux (only) Option: SYNC_DB_DSB_FROM_MON This option indicates that incoming events from ca_dsb_monitor should generate an outgoing DBS event. This option is used during transition to facilitate an incremental approach when upgrading to Unicenter where the use of ca_dsb_monitor is required. Windows (only) Option: UPS Database Sync - Proxies route via Global DBS Station Group The setting of this option determines whether DBS events will use the global station identified by the Global Station Group option to forward incoming events to other hosts. This option can be set to YES or NO. On UNIX/Linux platforms, routing occurs automatically using the station group identified by the DBS_STATGROUP option. Note: The remainder of this topic discusses options that perform the same operation on both Windows and UNIX/Linux, but differ between the two platforms in their appearance and syntax. For simplicity, the UNIX/Linux version of the option is used. See the table shown previously if you need to identify the corresponding Windows option.
Configuring DBS
The DBS feature uses the UPS daemon as a means for communicating synchronization events between stations. In turn, the UPS daemon uses the CAICCI component of Unicenter NSM to perform the data communication between stations. You will need to configure CAICCI to allow for the general communications required to perform DBS. Since this feature uses UPS as a means of communication, there are two Security options that can be specified to configure the UPS daemon. They are User Profile Sync - Logon As User (UPS_LOGOPTION for UNIX/Linux platforms) and User Profile Sync - Days to Store-and-Forward (UPS_STOREINTERVAL for UNIX/Linux platforms). UPS_LOGOPTION indicates where UPS log messages should be sent, either to a file ($CAIGLBL0000/caups.log), or to the Event Console Log. The UPS_STOREINTERVAL option specifies a time interval (in days) at which synchronization events should be retried when they are unable to be communicated to another station. The UPS daemon will retry failed events every 15 minutes until the events have been sent, or until the time interval specified by UPS_STOREINTERVAL has been reached. The User Profile Sync - Master Node option (UPS_MASTER for UNIX/Linux platforms) is used by DBS to determine if an incoming DBS event should in turn generate an outgoing UPS event. If the value of this option is blank, then UPS events are not broadcast. If this option is set to the node name, then incoming DBS events are candidates for causing the generation of an outgoing UPS event to all members of the station group.
Security Management
1379
Optional Features
To determine if a UPS event should be generated, the following criteria is used:

The received (or incoming) DBS event must be an ALTER. The user identified within the DBS event must have a UPSSTATGROUP keyword value specified within that users definition. A change in status or password for that user has been detected.
Two options that can be used to control the amount of user data that is passed in an ALTER DBS event are DBS_AUDITDATALEVEL and DBS_ADMINDATALEVEL. Each of these options can be set to a value of either CHANGED or ALL. When the value is set to CHANGED, only the attributes associated with the user definition that have changed as part of the update will be sent. When the value is set to ALL, then the entire user profile is sent within the DBS event whenever an update occurs to that profile. The DBS_AUDITDATALEVEL option is for auditing of user account information, and DBS_ADMINDATALEVEL is for administration of a user account (either through the cautil command line interface or from the Security Management GUI). The ACCEPT_DBS_STATGROUP option is provided to permit the explicit specification of the stations that are allowed to send DBS events to this station. If this option is left blank (unspecified), then any station can send DBS events to this station. If a station group ID is specified as the value for this option, then only the stations specified within this station group are allowed to send synchronization events to this station. All others will be rejected. The SYNC_DB_DSB_FROM_MON option allows events received by ca_dsb_monitor to generate DBS events. This option should only be used when ca_dsb_monitor is being used to communicate user account updates between earlier versions of Unicenter TNG and Unicenter NSM. This allows updates that occur within prior versions of Unicenter TNG to be sent using ca_dsb_monitor to Unicenter NSM. Once the event reaches Unicenter NSM, ca_dsb_monitor can be configured with this option to automatically generate a DBS event, allowing the update to be reflected within the set of stations that are running Unicenter NSM. Note: ca_dsb_monitor will only send user data that is compatible between Unicenter and prior versions of Unicenter. ca_dsb_monitor can also be used to send data from Unicenter NSM and prior versions of Unicenter TNG. This is restricted to alterations to user accounts only, and requires the use of ca_dsb_alert to initiate the event (perhaps through Event Management message records and message actions).
Starting DBS
As with all Security options, the DBS-related options are read at startup. To have option updates reflected by the Security Management daemons that use them, the Security Management daemons need to be recycled.
1380
Administrator Guide
Optional Features
Defining a Station Group
You will need to define a station group containing a list of stations to which you would like to have DBS events sent. Each station within the station group should be defined as type CPU. This station group should then be identified by the DBS_STATGROUP option. See the instructions for defining a station group in the online CA Procedures under the topic, Defining Station Group Profiles. You will need to set at least one of the SYNC_ALTER, SYNC_DEFINE, or SYNC_DELETE options to YES to activate outgoing synchronization events. If you would like to generate DBS events for all user operations, you should set each of these three options to YES. Once a station group name has been identified in the DBS_STATGROUP option, and at least one of the options listed in the previous paragraph has been set to YES, DBS has been activated. Once DBS has been configured, DBS events will be generated whenever Security Management detects a change to a user account definition. As mentioned, this includes DEFINE and DELETE operations. When a change to a user account is made, a DBS event is formulated, and is sent to the UPS daemon for distribution. Included in each DBS event is the current station where the event took place, and the station of the Security Management database that was updated. The UPS daemon determines which stations the event should be sent to by reading the stations specified in the station group identified by the DBS_STATGROUP option. The UPS daemon will not send the event to the current station, should this station be found in the station group. If the UPS daemon cannot communicate with any of the stations that it needs to send the DBS event to, it writes a record to a store-and-forward file ($CAIGLBL0000/caups.dat). These failed DBS events will be retried every 15 minutes until they are either successfully communicated, or until the limit specified by the UPS_STOREINTERVAL option has been reached for that event. Upon receiving a DBS event, the UPS daemon determines whether a database update is required for this event by comparing the station that it uses for a Security Management database, versus the station that is specified within the DBS event. If they are different, then the appropriate database operation is performed.
Security Management
1381
Optional Features
Independent of the database operation, a real-time update is then performed if the UPDATE_EXTERNAL option is set to YES on that station. If it is, then all DSB representations for that user are updated (defined, or deleted). This includes updates to system files (such as /etc/passwd), disk-resident DSB files, and CAISSF memory images of the defined user base. Also independent of the database operation and the DSB operation, the DBS event is then rebroadcast to all stations specified within the station group indicated by the DBS_STATGROUP option on that system. Regarding this operation, the event will never be sent back to the station that sent it here, even if that station is listed within the station group definition. Important! Although DBS events are not sent back to the station that was responsible for sending the event to a station, there are no checks for circular configurations. You should take precautions to prevent circular configurations from being defined within the station groups specified by the option, DBS_STATGROUP.
Windows Backup Domain Controller Support

Security Management provides support for Windows Backup Domain Controllers. Under Windows platforms, the BDC does not have its own database; it uses the Windows security database belonging to the Primary Domain Controller (PDC). In keeping with this design, Unicenter obtains user information for the BDC from the PDC. All users of the PDC are automatically defined to the BDC during the process of initializing the Security Management database and upon execution of the commit process (secadmin command using option c). Important! Security Management only supports a BDC if the PDC database has been populated using the secadmin command with option d. When the secadmin command is performed on a BDC, that BDC contacts the PDC to obtain its Decision Support Binary (DSB) files. Unicenter NSM must be running on the PDC in order for Security Management to be installed on the BDC. Although the BDC and PDC share user information (which is only stored in the Windows security database residing on the PDC), asset information is stored in the BDC version of the Windows security database. If the PDC disappears and the BDC is promoted to a PDC, the Security Management DSB User file has already been built by a previous secadmin command using option d, and is ready to use. Two Security Management options, User DB Backup Path and User DB Backup Flag, provide a way to back up the Security Management database on the domain controller. If necessary, this database can be imported to the new PDC database by running the following PDCADMIN utility command:
pdcadmin restore
1382
Administrator Guide
Optional Features
Native Operating System Database Update

Windows Security Database Unicenter NSM supports user exits for updates to the Windows security database. These exits are called whenever Unicenter NSM adds, changes, or deletes a user record from the SAM database. These exits are provided to enable you to modify information being given to SAM, abort the transaction, or report on the success of the transaction.
How It Works
You must create a DLL named CASFEXIT.DLL. This DLL must have the following entry points exported: EmSecAddPre EmSecAddPost EmSecChgPre EmSecChgPost EmSecDelPre EmSecDelPost For details, see the CASFEXIT.C and the CASFEXIT.H sample files within the NSM\SDK directory. See also the section Dynamic Update of Remote User Profiles, presented earlier in this chapter.
UNIX/Linux Control Files Unicenter NSM provides entry points which can be invoked as part of the real-time update procedure for the /etc/passwd file and the /etc/group file.
How It Works
Copy the following distributed scripts from the $CAIGLBL0000/secu/scripts directory to the $CAIGLBL0000/secu/bin directory: AddPre AddPost ChgPre ChgPost DelPre DelPost For a detailed description of each of the scripts listed previously, see Security Management Executables in the online CA Reference.
Security Management
1383
Optional Features
Password Change Notification (PCN) Facility

Note: This feature is functional only on Windows. Changes in passwords for Windows NT/SAM can originate from many sources: Windows Workstation clients, Windows 95 clients, and Windows administrators using the SAM User Manager or APIs. Unicenter Password Change Notification (PCN) is an optional feature that intercepts all SAM password updates, regardless of origin, and synchronizes them with the Security Management database. PCN interfaces to the Unicenter User Profile Synchronization and Database Synchronization features to provide enterprise-wide password synchronization. PCN reports transaction success/failure messages to the Event Management Console Log if Event Management is active, or to the Windows Event Log if Event Management is not active. CASAMAUD is the name of the PCN control program. You can execute the following to install (or uninstall) this facility, display the status of PCN, and apply updates for all outstanding transactions. For the operand syntax, see the CASAMAUD command in the online CA Reference. CASAMAUD -Install CASAMAUD -Status CASAMAUD -All Updates the necessary Windows registry keys with the PCN facility exit DLL name. Displays the Windows registry status and DLL status. Applies Password Change Notification to the Security Management database for all outstanding transactions. Applies Password Change Notification to the Security Management database for an individual outstanding transaction. Removes the Windows registry keys for the PCN facility exit DLL name added during the installation.
CASAMAUD -filename
CASAMAUD -Deinstall
If, for some reason, a transaction fails, the Stored-Transaction file is not deleted and can be reused by a manual execution of CASAMAUD -All once the cause of the failure is determined. (Possible causes of failure are an SQL Server access error, Router Services not active, and a CAICCI problem.)
1384
Administrator Guide
Optional Features
How It Works
When a Windows NT/SAM password is updated, Windows searches through its exit chain for Password Change Notification DLLs (found when the PCN facility is installed). Security Management writes the user ID and updated password to an SDS file and executes a batch program; this program uses the DLL interface to cautil for users and sends a password update transaction to Security Management. It generates messages appropriately to the Event Console or the Windows Event Log. Security Management does not have to be running to support this feature; however, the user must be defined in the Security Management database.
FTP Proxy
IBM AIX, HP-UX, and Sun Solaris Only How it Works
FTP Proxy controls access between the FTP client and the FTP server. The FTP Proxy server intercepts all FTP traffic to a computer and calls Security Management to verify the user ID and password, as in normal login processing.
An attempt to connect to the FTP server invokes FTP Proxy, which in turn invokes ftpd. Inetd monitors the FTP port (which is dynamically selected by ftpd). When FTP Proxy is enabled and it receives a user ID and password from the FTP client, Security Management determines whether the attempt is valid. If so, the command is forwarded to ftpd. If the attempt is invalid, FTP Proxy returns an error message to the FTP client, and the user may retry the login. Security Management suspends the user account after a third invalid login attempt. FTP Proxy checks all FTP control commands. Except on the IBM AIX platform, FTP Proxy also checks all FTP data transfers. The following Security Management options are associated with FTP Proxy server support:
ENABLE_FTP_PROXY The setting of the ENABLE_FTP_PROXY option determines whether the FTP Proxy will be started when the Security Management intercepts are installed. This option can be set to YES or NO. The default is YES.
Security Management
1385
Optional Features
ENABLE_ANONYMOUS_FTP The setting of the ENABLE_ANONYMOUS_FTP option determines whether the FTP Proxy will permit anonymous FTP access without checking for the anonymous or FTP user in the Security Management database. This option can be set to YES or NO. The default is NO. FTP_COUNTASLOGIN The setting of the FTP_COUNTASLOGIN option determines whether a user is counted as logged in. Assume a user is permitted only one login; if this option is set to YES and the user has a telnet session open, he is not permitted another FTP connection. Similarly, if this user has an FTP session active, all other login attempts on his part will be rejected. This option can be set to YES or NO. The default is NO. Enabling FTP Proxy For FTP Proxy to be active, /etc/inetd.conf file must be modified. This file initially contains the following line:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd
This line is modified as follows:

ftp stream tcp nowait root /usr/lbin/ftpd /s/secu/bin/ftp_proxy
The secadmin -a command will automatically modify the /etc/inetd.conf file as shown previously, and recycle inetd if the ENABLE_FTP_PROXY option is set to YES. A secadmin -z command will return the /etc/inetd.conf file to the original version and recycle inetd.
Rexec Proxy
IBM AIX, HP-UX, and Sun Solaris Only
Rexec Proxy executes commands one at a time on a remote host. The following options are associated with Rexec Proxy:
ENABLE_REXEC_PROXY The setting of the ENABLE_REXEC_PROXY option determines whether the Rexec Proxy will be started when the Security Management intercepts are installed. This option can be set to YES or NO. The default is YES.
1386
Administrator Guide
Security Management Reports
REXEC_COUNTASLOGIN The setting of the REXEC_COUNTASLOGIN option determines whether a user is counted as logged in. This option can be set to YES or NO. The default is NO.

This section provides information on how to interpret the reports that extract security audit data from the Event Console Log. Also included in this topic are instructions on how to use the UNIX/Linux platform whohas and whathas commands and interpret the reports they generate. Access Violations The Event Console Log may include violation errors that look similar to the following: CASF_E_465 Access violation by userid to asset ( mode ) assetname from source terminal_device at node source_node for access type access_mode. ( context ) When a user attempts to access an asset to which he does not have permission, an error message is written to the Event Console Log. The first key to identifying access violation errors is the message number. CASF_E_465 is the general message number used for all DENY violations. The remaining keys to this message are listed following: Field userid mode assetname Description ID of the user who caused the violation Users violation mode: W=Warn, M=Monitor, F=Fail Asset name of the asset involved in the violation For WNT-FILE, UNIX-FILE, and UNIX-SETID, the asset name will be a fully qualified path name. terminal_device source_node Device the user was logged into at the time of the violation Node from which the user logged into the system
Security Management
1387
Field access_type
Description Access mode, abbreviated as follows: Rd=read, Wr=write, Up=update, Sc=scratch, Fe=fetch, Cr=create, Co=control, Se=search, Ex=execute Context of the violation For Windows intercepted events, this will be the access type (read, write, and so on). For UNIX/Linux platforms, this will be the system call name. For CAISSF resources checks through components, it will be resource.
context
Logon/Logout Messages The Event Console Log will typically include logon and logoff messages that look similar to the following: CASF_I_019 Login successful by userid from source terminal_device at node source_node CASF_I_020 Logoff by userid from source terminal_device at node login_node The keys to these messages are as follows: Field userid terminal_device source_node Description ID of the user who logged in or out Device into which the user logged Node from which the user logged into the system
UNIX/Linux Platform Reports

Whohas Report
You can use the whohas report to look at the policies that have been set for a particular asset type and asset name. To create this report, run the following command from the command line prompt:
whohas [asset_type][asset_value]{user_name}{node_name}
The following command was used to generate the following sample report:
whohas UNIX-FILE "*"
1388
Administrator Guide
COMPUTER ASSOCIATES INTERNATIONAL, INC. 'WHOHAS' FOR UNICENTER USER: audit NODE: ASSETNODE: ---- ACCESS MODES --- -------------- RULE -------------------FILE SSF NAME - ORIGIN PERMISS TEXT ---- ---- ----------- ------ ------ ---------------------rwdxc --- allfcrit User PERMIT /users/audit rwdxc --- allfcrit User PERMIT /users/audit/* PAGE 1
NUM ---0001 0002
COMPUTER ASSOCIATES INTERNATIONAL, INC. 'WHOHAS' FOR UNICENTER USER: audit NODE: auditnode ASSETNODE: ---FILE ---r--r--ACCESS MODES --- -------------- RULE -------------------SSF NAME - ORIGIN PERMISS TEXT ---- ----------- ------ ------ ------------------------ rcrit User PERMIT /users/audit --- rcrit User PERMIT /users/audit/* PAGE 2
NUM ---0003 0004
Total rules: 4 Whohas run by root on Tue Jul 10, 2001 at 11:49:46 End of whohas
The USER, NODE, and ASSETNODE values identify the user, the node associated with the user, and the targeted asset node, respectively. The whohas report groups the assets by the USER, USERNODE, and ASSETNODE values. The ACCESS MODES indicate the CAISSF access modes. The access modes are abbreviated as follows: R=READ, W=WRITE, D=DELETE, X=EXECUTE, U=UPDATE, C=CREATE, S=SEARCH, N=CONTROL. In addition to the FILE and CAISSF access type flags, the NAME field lists the internal criteria name (for diagnostic purposes) or the name of a custom jll criteria profile. The RULE is a combination of the following: ORIGIN PERMISS TEXT User or user group source of this policy Permission granted by this policy Asset name for this policy
Security Management
1389
What-Has Report
You can use the what-has report to look at the policies that have been set for a particular user ID. To create this report, run the following command from the command line prompt:
whathas [userid][node]
The following command was used to generate the following sample report:
whathas audit 07/10/01 WHAT-HAS REPORT Userid: audit
Asset Type/ Access Criteria Asset Name/Asset Node Type Profile RWDXUCSC Expires Calendar Path Path --------------- ---- ------ -------- -------- ------- ------------- -----UNIX_FILE PERMIT allfcrit YYYYNYNN /users/audit DENY rwxcrit YYNYNNN
1390
Administrator Guide
Appendix
ManagedPC
This appendix describes how to incorporate Unicenter NSM with any original equipment manufacturers (OEM) packaging to support ManagedPCs. The ManagedPC component provides the following solutions:
Detects ManagedPC operating system installation requests automatically, and provides facilities to customize those requests. Furnishes remote installation services for a Windows operating system. Inventories all ManagedPCs in the Unicenter Common Object Repository automatically during the Discovery process. Offers methods you need to monitor the status of your ManagedPCs through the Unicenter WorldView GUI. Includes facilities in the Unicenter WorldView interface that can awaken a ManagedPC from a soft off or sleep mode. Furnishes reports that are specifically customized for your ManagedPC administrative personnel.
Note: Due to the intrinsic nature of a ManagedPC client in a basic DOS environment, double byte character sets cannot be supported. As a result, the ManagedPC components do not support international languages.
ManagedPC
A1
Prepare for ManagedPC Installation
Prepare for ManagedPC Installation

During your installation using the ManagedPC Wizard, you are prompted to insert a DOS-formatted, bootable diskette containing files to use in a download operation. Use the following requirements to prepare this diskette prior to launching the ManagedPC Wizard:

Format the diskette using the format a:/s command at the command prompt. Create the diskette using Windows 95/98 or DOS 6.2x. Windows ME cannot be used as a basis for creating the boot diskette. Label the diskette (optional). Copy the following three files to a DOS-formatted, bootable diskette: sys.com format.com choice.com
The three .com files are located in the DOS or Windows directory under the command subdirectory on the hard disk of the machine on which you formatted the diskette. Copy the files to the root of the diskette. For example, if the C: drive is your Windows installation, use the following:
copy c:\command\format.com a:\
Launch the ManagedPC Installation

To start the ManagedPC installation, follow these steps: 1. To launch the ManagedPC wizard, choose Start, Programs, Unicenter TND, WorldView, ManagedPC. The Welcome dialog appears. 2. 3. 3. Click Next to start the installation. The Repository Selection dialog appears. Select a the repository to which you want to connect. In most cases, you can use the defaults from the Repository Selection dialog. Select which of the Windows operating systems will be deployed by the ManagedPC server to the ManagedPC clients. You can select any or all of the operating systems listed. The number of operating systems you select determines how many times the Create ManagedPC ReadyInstall Image dialog is displayed.
A2
Administrator Guide
4.
Specify the path (typically to a CD) where the operating system installation files are located. The staging area is the location to which the installation procedure will copy the operating system installation files. Again, you may be able to use the default destination.
5.
When the copy operation ends, specify the location of the next operating system installation files (if you previously selected more than one operating system). Once all operating systems have been copied to the staging area, ManagedPC Setup creates the diskette image that you will download to the ManagedPC client.
6.
Insert the DOS-formatted, bootable diskette that you created prior to installation (see the section, Prepare for ManagedPC Installation, presented earlier in this appendix). The Customize Floppy dialog appears. Specify the location of the Windows CD-ROM. The ManagedPC wizard copies the appropriate files needed to create a boot image from the CD to the diskette, producing the installation image file.
7.
ManagedPC
A3
Notes for Client Installations

When installing a Windows client, consider the following items:
After installing a Windows 95 client, immediately install the correct driver for the NIC and remove the ndis network driver. You may experience lockups if this is not done. You must also manually install the correct NIC card drivers and set up the network configuration after Windows 98 and Windows NT client installations. The key code option for Windows 95 is not available. You must manually enter this code at the client machine during installation.
A4
Administrator Guide
Configure ManagedPC
Configure ManagedPC
Configuring a ManagedPC is accomplished by turning on the ManagedPC and having it boot from the network. This creates an Uninstalled ManagedPC object in the repository. Once the ManagedPC has been powered on and an object exists for it in the repository, you can configure the properties of that particular ManagedPC. To configure the ManagedPC, follow these steps: 1. Start the 2D Map by choosing Start, Programs, Unicenter TND, WorldView, 2D Map. Note: You can also start the configuration tool from the Unicenter Explorer by selecting a Managed PC client and clicking the Set ManagedPC Boot Option.
ManagedPC
A5
Configure ManagedPC
2.
Double-click the Uninstalled ManagedPC object to get the list of uninstalled ManagedPC clients.
3.
To configure each ManagedPC object, right-click the object and choose Set ManagedPC Boot Option.
A6
Administrator Guide
Configure ManagedPC
You can use the displayed dialog to identify the file to be transferred to the ManagedPC client by the ManagedPC server. The ManagedPC Boot Options on this dialog are Normal Boot and Special Boot.
Normal BootUnless the Special Boot option contains an entry other than DEFAULT (see following), this boot type is used first. It identifies the name of the file to be transferred to the ManagedPC client. Special BootIf set to anything other than DEFAULT, this boot type is used first. The ManagedPC will transfer this file to the client regardless of the setting of the Normal Boot option. Once this file is transferred to the ManagedPC client, it is reset to DEFAULT, so the Normal Boot entry takes precedence the next time the ManagedPC client boots. If Special Boot is set to BOOTHD, BIS radio buttons are presented on the ManagedPC Configuration screen. These permit you to install and remove BIS certificates. By selecting Install BIS Certificates, BIS will be activated, and only images generated by this ManagedPC server will qualify for download to the ManagedPC client. This function defaults to Install BIS Certificates for any client that supports BIS.
ManagedPC
A7
Configure ManagedPC
Downloading Files Using Boot Sequencing

Boot sequencing can change the way the ManagedPC boots. Boot sequencing permits you to download a series of files in sequential order. An example of the use of sequential booting would be to download an image to partition the hard drive, and then reboot and install the operating system. Assume that you have four files named filea.1 through filea.4. When the Special boot file name is set to filea.1, the first time the ManagedPC client boots, filea.1 is sent to the ManagedPC client. The next time the ManagedPC client boots, filea.2 will be sent. This process continues until all the files with the same name and sequential extension have been transferred to the ManagedPC client. After the last file (filea.4) is sent to the ManagedPC client, the Special boot value is reset to the default, and Normal boot takes precedence. If you were to choose osinstal.2 using the previous dialog, you would initiate boot sequencing. Then, once the ManagedPC client booted, file osinstal.2 would be sent to the ManagedPC client. Once the client rebooted, the client would receive the file osinstal.3.
A8
Administrator Guide
Configure ManagedPC
The Boot Parameters tab on the ManagedPC configuration dialog lets you configure which batch file is to be executed at the client. The batch file controls the type of operating system that is installed.
Assume, for example, that Windows 98 is one of the operating systems to be deployed. By choosing win98.bat for a particular ManagedPC, you will install Windows 98 for that ManagedPC. Once the configuration for the ManagedPC client is completed, reboot the ManagedPC client and observe the installation.
ManagedPC
A9
Configure ManagedPC
Creating Custom DOS Boot Images for Downloading

Unicenter NSM provides the copy144 utility, a program that lets you create your own customized DOS boot images on 1.44 MB diskettes. Customized DOS boot images may be required when the staged DOS boot images created from the OEM-supplied disks do not satisfy all of your requirements. The following list contains examples of why you would use the copy144 utility:
To load different DOS drivers than those available with the staged DOS boot images. To change the default settings in the config.sys file. To execute different DOS applications, so you must create a customized DOS boot image that contains the environment needed for the different applications.
Customizing a DOS Boot Image The following list provides a high-level summary of the tasks you must complete to customize a DOS boot image: 1. 2. Using the copy144 utility, restore the DOS boot image file osinstal.3 to a formatted 1.44MB diskette. Change the contents of the autoexec.bat file on the newly created 1.44 MB diskette to indicate the name of the Unicenter NSM server, and the name of the customized .bat file that should be executed. (See the next section, Changing the autoexec.bat File.) Save the changes made to the customized DOS boot image on your 1.44 MB diskette. Using the copy144 utility, copy the customized DOS boot image from the diskette to a new DOS boot image file hard drive of the Unicenter NSM server. (See the section, Copying the New Boot Image to the Unicenter NSM Server, presented later in this appendix.) Make the desired modifications to existing .bat files in the Install_Path\NSM\MANAGEDPC\CAMENU directory or create new .bat files for further customizations.
3. 4.
5.
The sections that follow provide details about these tasks. Changing the autoexec.bat File Note: In earlier versions of the ManagedPC, you were required to change the autoexec file to use the new server name and batch file. This was necessary to install a particular operating system. With ManagedPC Version 2.0, modification of the autoexec.bat file is no longer necessary.
A10
Administrator Guide
Configure ManagedPC
When the ManagedPC is powered on, it requests a parameter file from the ManagedPC server. This file contains the information necessary to configure the autoexec.bat file.
Example
In the sample ManagedPC autoexec.bat file following, substitutable variables, called sentinels, are dynamically modified by a program named setopdat. To use an example, setopdat will change $BatchFile$ to win98.bat if that is what you selected in the ManagedPC Configuration dialog. Following is an example of an autoexec.bat file that has been changed for the Unicenter NSM server SERVER03, and the file named monthend.bat:
@ECHO OFF PROMPT $p$g SET TEMP=A:\ PATH=A:\;A:\net echo goto start > a:\install.bat copy a:\install.bat + a:\autoexec.bat > NUL setopdat -f a:\install.bat a:\net\system.ini a:\net\netstart.bat a:\install.bat rem we will never get here :start CALL a:\net\NETSTART.BAT net use m: /d > nul net use m: $ShareName$ The value $ShareName$ is changed dynamically to the Actual Share Name. m: cd \ if not exist "$BatchFile$" goto menu This is substituted with the Actual batch file name. $BatchFile$ goto end rem we will never get here :menu menu.exe a: cd \ camenu.bat :end
Copying the New Boot Image to the Unicenter NSM Server You must use the copy144 utility to copy the customized DOS boot image on your 1.44 MB diskette to the Unicenter NSM server. To copy the contents of your diskette to the hard drive of the Unicenter NSM servers hard drive, specify the following command:
copy144 b <1.44 disk drive id> <osinstal.x>
The name of the customized DOS boot image must be osinstal.x, where x is a numeric extension (do not use extensions 2 or 3). The new boot image is placed in the installpath\NSM\MANAGEDPC\IMAGES\DOSBOOT\UNDI directory. If you need to copy from your local hard drive to a diskette, specify the following:
copy144 d <DOS boot image name> <1.44 disk drive id>
ManagedPC
A11
Configure ManagedPC
WARNING! Running the copy144 utility to copy the DOS boot image to your 1.44 MB diskette erases all files on that disk. For this copy process, use only a formatted diskette, or one containing unwanted data. Note: If changes to the DOS boot images result in the files not fitting onto a single 1.44 MB diskette, you may have to connect to the share directory of the Unicenter NSM server from another computer. To do so, boot your own computer using the DOS boot image 1.44 MB diskette, and then execute the DOS commands for those DOS boot image files that did not fit on the 1.44 MB diskette.
Associating Customized DOS Boot Images with ManagedPCs

The name of the customized DOS boot image can be associated with specific ManagedPCs. You can associate your customized DOS boot image with the following:
ManagedPCs that have already been defined as objects in the Unicenter Common Object Repository All ManagedPCs that will be discovered in the future
Associating ManagedPCs Already Defined as Objects in the Common Object Repository
You should use the Set ManagedPC Boot option of the Unicenter NSM Object Browser to associate the customized DOS boot image with specific ManagedPCs already defined as objects in the Common Object Repository. The next time these ManagedPCs reboot, they will do so with the customized DOS boot image. Detailed information about the use of the Set Managed PC Boot option can be found in the section, Using the Set ManagedPC Boot Option, presented later in this appendix.
Associating All ManagedPCs Discovered in the Future
Default behavior for all newly discovered ManagedPCs is defined by the values of the ManagedPC registry keys, BootFirst and RunFile, on the Unicenter NSM server. The default value of the BootFirst registry key is BootHD. BootHD is the name of the preboot image that is sent to the ManagedPC, instructing it to attempt to boot from its local hard drive.
A12
Administrator Guide
Configure ManagedPC
To use a customized DOS boot image, for example, logon.3, change the default values of the BootFirst and RunFile registry keys to the values shown in the following table: Registry Key BootFirst RunFile Default Value BootHD New Value BootDos LOGON
Note: Unicenter NSM applies the .3 extension to the name of the customized DOS boot image that is defined as a value for the RunFile property.
Using the Set ManagedPC Boot Option

When you locate a specific ManagedPC object with the Unicenter NSM Object Browser, you can select the Set ManagedPC Boot Option from the objects menu. The Setting ManagedPC Boot Option dialog that appears lets you configure the users ManagedPC to do the following:

Boot from the ManagedPCs local hard drive at all times. Boot in the same manner, according to how Unicenter NSM is set up (that is, according to the menu selection made by the ManagedPC user), every time. Boot to download an image, one time, then boot to the hard drive for subsequent boots.
After you have made the selection for the ManagedPC, the next time that the ManagedPC requests a download of a boot file, it receives instructions from Unicenter NSM to boot according to the new configuration.
ManagedPC
A13
Appendix
Virus Scan
The Event Management suite of functions includes Unicenter Virus Scan. This utility automatically scans the local drive daily at midnight. Parameters can be set to customize the type of scan, the drive to be scanned, and the actions to be taken upon virus detection. Unicenter NSM provides predefined message policies that automatically launch the Virus Scan utility at midnight. The installation procedure defines a Midnight* message record and associated action to run Virus Scan every day at midnight. Note: To prevent Virus Scan from running automatically, simply delete the Midnight Virus Scan message record (Message ID: Midnight*) from the Message Records container. You can also delete the message records only associated message action from the Message Action Summary container. Deleting either record prevents the automatic execution of Virus Scan. You can also run Virus Scan on demand by launching the inocmd32.exe command with your desired parameters. Parameters can be used to specify the type of scan performed and the action to be taken upon virus detection. Upon virus detection, Virus Scan sends messages to the Unicenter NSM Console Log and the Event Log. For more information on the inocmd32.exe command, including a list of valid parameters, see the online CA Reference.
Downloading Virus Signature Updates

See the instructions for updating your virus signature in the online CA Procedures under the topic, Downloading Virus Signature Updates. The procedure includes a link to the appropriate Computer Associates support web page.
Virus Scan
B1
Deleting Old Scan Logs
Deleting Old Scan Logs

Virus Scan maintains its Scan Logs indefinitely in the \NSM\db directory on the hard drive. If you need to reclaim hard disk space, you can manually delete the old logs.
B2
Administrator Guide
Appendix
Advanced Event Correlation

Advanced Event Correlation (AEC) integrates seamlessly with Event Management to provide a powerful event correlation, root cause, and impact analysis capability. When used with existing Unicenter NSM features, AEC can increase the quality and reduce the quantity of the information reported on the Event Console, which is used to automate certain operational tasks.
What Is Event Correlation?

In simple terms, event correlation is a way to group associated events together for the purpose of further processing. Grouping events in this way lets you do simple but powerful forms of processing, such as event suppression, reformatting, aggregation or consolidation. You could, for example:
Suppress events according to source, duplication, transient states (for example a flapping link), frequency, thresholds associated with field values, and so on. Combine (aggregate) information spanning multiple events into one event. Extract data from events that may be difficult to extract using existing tools, making it available for further processing through automation. Reformat events for easier processing or to be more readable for human operators. Detect the absence of scheduled events, such as a Backup complete. It can also facilitate more powerful contextual forms of processing such as root cause and impact analysis.
Root Cause Analysis lets you clearly differentiate the root cause event associated with an event stream from the non-root cause or symptomatic events that may not require a direct response. This helps drastically reduce the number and frequency of events seen by console operators, eliminates message flooding, and reduces false notifications.
C1
Why Use AEC?
Symptomatic events can provide valuable information about the impact of the root cause problem on the overall system, and thus, should not be discarded in all cases. The Impact Analysis function can help you proactively alert users of an impending problem (reducing the load on your help desk), initiate failover or recovery procedures for the dependent systems; or simply alert operations staff that they need not address a problem associated with one of the symptomatic elements.
Why Use AEC?

Unicenter NSM reports messages generated by the failure of managed components to the Event Console. Within the Event Console, message records trigger actions for the failure messages reported. However, some of the messages received by the Event Console can be misleading or unnecessary. These messages can trigger unnecessary actions to fix false or secondary failures. Reasons for misleading or unnecessary failure messages include the following:
An expected, but normally inappropriate, state, such as services taken offline for repairs Services failures cause dependent object failures System failures cause agent failures Repetition of a previously received message
These false failure messages cause problems because message records and actions erroneously generate notifications and tickets, and therefore, important messages may get lost in all of the erroneous, secondary, false messages. Using Advanced Event Correlation you can do the following:

Distinguish between primary and secondary failure messages Determine the root cause of a failure Provide an impact analysis of a failure Diagnose and filter unwanted messages Respond to dynamically changing environments
C2
Administrator Guide
How AEC Works
How AEC Works

AEC extends the functionality of Event Management. To use AEC, you must first identify a set of events that you want to monitor and correlate, and what actions should be performed if correlation exists or does not exist. The events to be monitored are reported to the Event Console as messages. These messages act as input to AEC, and are intercepted and analyzed. You configure AEC to act on the input messages it receives to produce the desired output, which are the messages that are actually sent to the Event Console. AEC uses correlation rules to analyze the input messages in relation to each other and identify the root cause messages from those incoming messages. A correlation rule performs the following functions:
Describes patterns so as to recognize those incoming messages that are related. Defines timings on when to report root cause messages to the Event Console. Captures the logic of cause and effect relationships of all related messages. Describes formatting of the root cause messages reported to the Event Console.
When AEC is running, it does the following:

Listens to all incoming messages. Uses patterns (tokens and regular expressions) in the rule to trap matching incoming messages. Triggers the correlation rule based on matched events. Continues to look at incoming messages to see if any more messages match the patterns in the rule.
The actions listed previously continue accordingly to the timings specified in the rule. Each correlation rule has timings on when to report a correlation message to the Event Console once the rule is triggered, and when to stop processing the rule once it is triggered. AEC knows the logic of cause and effect relationships of different messages since that logic is stored in the rule. AEC applies this logic to the messages it has matched against the rule. Using that logic, it identifies which of the incoming messages are root causes and which of these are not. Once AEC has the root cause message identified, it applies the formatting specified in the correlation rule and reports the resulting message to the Event Console.
C3
Installing AEC
Understanding Event Definitions

Understanding event definitions is critical to understanding AEC, configuring it, and using it correctly. You can define the following types of events in AEC:

Input events Output events
Input events are the events that define patterns used by AEC to match messages coming in to the Event Console. Output events are events generated by AEC and sent to the Event Console. You define these events in the correlation rules when you configure AEC. Each event that you define has a key field, called the message string, which describes the event. The message string can contain regular expressions and tokens.
Installing AEC
To install AEC, follow these steps: 1. From the root installation CD directory of the Unicenter Network and Systems Management CD, run setup.bat. This launches the Unicenter Product Explorer. Select Advanced Event Correlation from the Post Installation Utilities folder located under Unicenter for Windows (Intel) NT/2000/XP entry. Click the Install button and follow the instructions provided. Recycle Event Management by entering the following command at a command prompt:
unicntrl stop opr
2. 3. 4.
Then enter the following command:

unicntrl start opr
AEC is now installed.
C4
Administrator Guide
Configuring AEC
Configuring AEC
Configuring AEC consists of defining correlation rules and saving them in a rule file. You create correlation rules using the AEC Integrated Development Environment (IDE), which runs a single Windows application and provides an easy-to-use graphical user interface (GUI). Development using the IDE typically goes through the following phases before you can use AEC in a production environment: 1. 2. 3. Defines correlation rules. Tests the correlation rules. Saves the correlation rules in rule files. Rules files have an extension of .rca.
After you define your correlation rules, you can test them in the IDE. The IDE reads Event Console messages and applies the rules you have defined in the rule file. Note: You only need to use the IDE when you are defining and testing rules. After your rules are defined, you can use the AEC Configuration Wizard from the Start menu to load the rules into the production environment. See Implementing AEC later in this chapter. AEC processes events as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. Listens to all incoming messages. Uses patterns in the rule to identify the incoming messages that match. Triggers the correlation rule when a matched message is detected. Listens to incoming messages to see if any more messages match the patterns in the rule. Uses timing, specified in the rule, to determine continuation of monitoring. Stores the logic of cause and effect relationships of different messages. Identifies which incoming messages are root causes, based on the cause and effect logic. Applies the formatting specified in the correlation rule. Reports the resulting message to Event Console.
The IDE lets you see the following:

What rules were triggered. The messages with which the rules are triggered. How many instances are running, and the values of tokens in each instance. For more information, see Using Tokens.
C5
Configuring AEC
The times the rule processing started. How much time is left for maturity and reset of the rule. For more information, see Timing Parameters. The flow of logic in the rule processing.
Starting the IDE

To start the Advanced Event Correlation IDE, use the following path from the start menu:
Unicenter TND, Enterprise Management, Advanced Event Correlation, IDE
Components of a Correlation Rule

You can add two types of correlation rules to your policy:

An event pipeline rule A Boolean logic rule, which supports complex nested Boolean logic conditions that help you analyze and identify complex patterns of behavior. For more information, see Using Boolean Logic in AEC Rules.
Event Pipeline Rule Components The components of an event pipeline correlation rule are as follows:

Pipeline Root events
Pipeline
The pipeline is where most of the logic of cause and effect relationships of messages is defined. Each correlation rule has one pipeline. It is a list of pipeline items, each of which contains descriptions of similar messages. Each pipeline item deals with only one message type. Pipeline items are grouped together to form a pipeline that has a cause and effect relationship among the items. The order of pipeline items in a pipeline is important. Any pipeline item in a pipeline is considered to be the root cause of all pipeline items under it. When AEC receives many messages that are matched by different pipeline items, it chooses the highest item and determines that message to be the root cause. For example, a pipeline may have the following two pipeline items: Pipeline Item # 1: Ping Failure on Server Pipeline Item # 2: Service Critical on Server
C6
Administrator Guide
Configuring AEC
The Promote/Demote feature (available on the pop-up menu of any pipeline item) lets you modify the order. The main components of pipeline items are as follows: Match Event This component indicates conditions (message string and node name) under which the item will trigger the rule. Local Correlation Event and Local Reset Event The Local Correlation and Local Reset Events are similar to the Root Correlation and Root Reset Events in that they describe the message strings that are sent to the Event Console at maturity (reset) of the correlation rule. However, you can configure AEC to use either the Local or the Root Correlation (Reset) message, by setting one of two flags. The flags Use Root Correlation Event and Use Root Reset Event let the Root Correlation and Root Reset messages override the Local Event Messages. The advantage of setting the Root Correlation (Reset) message is that you, for example, must configure the correlation (Reset) message at only one place. However, the disadvantage may be that, regardless of the root cause, AEC generates the same formatted message (although, using tokens, it can be specialized to reflect the root cause event in each case). The disadvantage of setting the Local Correlation (Reset) message is that you must configure these messages at each of the individual pipeline items. This lets you configure different messages to be sent to the Event Console when you have different root causes. Exclusion Event You can use the Exclusion Event with the Match Event to help restrict the events that match the matching element. For example, you could define a Match Event to match any events containing the text ABC but exclude any events also containing the text DEF. If you defined the following events in a rule, all application failure events are matched except for those that refer to lab applications. Match Event: Exclusion Event: Âpplication .* has failed$ Âpplication LAB_APP1|LAB_APP2 has failed$
You can also use the Exclusion Event to restrict the matching of any element of an event. For example, you could use it with the Match Event to match a given event from all servers except those specified in the Node field of the Exclusion Event.
C7
Configuring AEC
Reset Request Event Lets you reset an individual pipeline item. Set the Enable Local Reset Request Event flag to reset an individual pipeline item. In addition, this lets you decrement the counter for the number of events that matched associated with a pipeline item when a Reset Request Event is received. When you set this flag, a pipeline item is reset only when the counter is decremented to zero. For example, assume you have five automated procedures that generate consecutive events to indicate that they have started and completed successfully. Using this flag, you can match the five start events and decrement the counter by assigning the Reset Request Event to the completion event. If, at the end of the maturity period, the matching element has not reset, one or more of the automated procedures must have failed to complete successfully and the rule can generate a Root Correlation Event to indicate that. Local Reformat Event Configured at the rule or matching element level, you can use the Reformat Event to change the format of a matched event. The reformatted event can consist of the following:
All, or any element of the original event (using &TEXT or &1 - &n, respectively) Any global or user-defined token value Static text
For example, assume you want to prefix any event that matches Pipeline Item # 1 with the string %AEC_HOLD. This prefix could then be identified by a standard Event Management message record/action, resulting in the event being placed in the Held Messages queue. Local Revised Correlation Event It is possible that a higher pipeline item can be matched after a correlation event has been generated (for example, where the rule matures before the highest pipeline item is matched). In that case, you may want to generate an event indicating that the previous correlation event has been superseded. A Revised Correlation Event can consist of the following:
All, or certain elements of the original root cause event (using &TEXT or &1 - &n, respectively) All, or certain elements of the new root cause event (using &RCTEXT or &RC1 - &RCn, respectively) Any global or user-defined token value Static text
C8
Administrator Guide
Configuring AEC
For example, if Event B was initially determined to be the root cause but was subsequently replaced by Event A, you could generate the Revised Correlation Event Event A has been replaced by Event B as the root cause for Problem X using the template &TEXT has been replaced by &RCTEXT as the root cause for Problem X. Reset Request Acknowledge Event This event can be generated whenever a rule or pipeline item resets in response to a Reset Request Event. Local Impact Event If the rule is configured to generate impact events, the pipeline item Use Root Impact Event flag is set to FALSE, and this is not the root cause item, this output event is generated to the Event Console after maturity to report the events impacted by the root cause.
Root Events
You can define root events to override pipeline events. Individual root events are as follows: Reset Request Event Configure this input event to match incoming events that trigger the rule to reset automatically, rather than waiting for the duration of the reset period. Root Reformat Event Configure this output event to reformat events that matched the item if the pipeline item Reformat Matched Event is set to TRUE, and the Use Root Reformat Event flag is set to TRUE. Root Correlation Event Describes the message that identifies the root cause event to be sent to the Event Console at maturity of the correlation rule. Root Revised Correlation Event If the rule level Enable Revised Root Cause Event flag is set to TRUE, and the new root cause pipeline item Use Root Revised Correlation Event flags is set to TRUE, this output event will be generated if the pipeline item is matched after maturity and is higher than the current root cause item to indicate that a new root cause has been identified. Root Impact Event Describes the message to be sent to the Event Console for each of the impacted messages. This message could contain components of the root cause message as well as the impacted messages. You can also use event-byevent impact messages, or aggregate impact messaging. For more information, see Impact Analysis. Root Reset Event Describes the message to be sent to the Event Console when the correlation rule is reset. For more information about resetting a rule, see Timing Parameters for more information.
C9
Configuring AEC
Root Request Acknowledge Event This output event is generated to acknowledge receipt of the request to the Console if the rule has been reset using a Reset Request Event. Components of a Boolean Logic Rule The components of a Boolean logic correlation rule are as follows:

Boolean operators Root events
Boolean Operators
Each Boolean rule can have one or more nested Boolean operators, each with one or more pipeline items. These Boolean operators let you establish complex relationships among messages. When AEC receives many messages that are matched by different pipeline items, it performs the logical Boolean operations to determine if all conditions have been met. For example, assume you define a rule that contains the following components: Boolean Operator AND has been selected. Pipeline Item # 1: Disk I/O Usage Critical Pipeline Item # 2: Database Backup Starting When AEC detects both events (Item # 1 AND Item # 2) occurring within the maturity period, it generates a correlation event. In this example, you may want to abort the database backup to save disk I/O. The following components of Boolean operator pipeline items are the same as a pipeline rule:

Match Event Exclusion Event Reset Request Event Local Reformat Event Reset Request Acknowledge Event
Note: The Local Correlation Event, Local Reset Event, Local Impact Event, and Local Revised Correlation Events are not available in a Boolean pipeline item, because all pipeline items must be considered together in a Boolean rule. Use the root versions to generate these output events.
C10
Administrator Guide
Using Boolean Logic in AEC Rules
Root Events
The following Boolean rule root events are the same as a pipeline rule:

Reset Request Event Root Reformat Event Root Correlation Event Root Reset Event Reset Request Acknowledge Event

AEC provides support for complex nested Boolean logic conditions, which lets you use Boolean logic on events. In addition to defining patterns and capturing matched events, AEC can also perform Boolean logic on whether matched events have occurred and make a corresponding determination on whether to send out correlated messages when the Boolean logic returns a TRUE condition. Boolean logic can be applied by defining Boolean logic rules. Boolean logic rules are different than event pipeline correlation rules. Boolean logic rules do not have pipelines but instead correlate events using Boolean operations.
Boolean Logic Rules

Boolean logic rules support complex nested Boolean logic conditions that help you analyze and identify complex patterns of behavior. The Boolean operators supported are as follows:

ANDAll conditions must be met OROne of the conditions must be met XOR(exclusive OR) Only one of the conditions must be met NOTThe condition must not be met
C11
These operators can be combined to form complex logical statements, for example:
As with event pipeline rules, the pipeline item object for a Boolean logic rule determines what events are matched, how they are processed, and what the output will be:
A Boolean condition is different from a root cause (input) event. You define the Root Correlation and Reset Events at the rule (rather than pipeline item) level and they are output when the rule matures, assuming all conditions have been met in the Boolean logic statement. Boolean Logic rules can be configured to mature as soon as all conditions of the Boolean statement are met.
C12
Administrator Guide
Auto-Trigger
An additional feature of a Boolean logic rule is Auto-Trigger (a configurable option), which is a trigger without receiving an event as input. To do this, at least one condition must be met (which will always be a NOT condition). Using Auto-Trigger, you can trap the absence of an anticipated event. For example, if you know that there should be a heartbeat event from a key application every hour, you can define a rule with one NOT condition to match that event. It will auto-trigger in the absence of the event. If the event is not received by the end of the maturity period, the condition will be TRUE and the rule can cut a Root Correlation event to indicate that the application has failed. If the event is received, the condition will not be TRUE and the rule will be reset at maturity without generating its Root Correlation event.
Example
You may have a situation where the correlation depends on the occurrence or nonoccurrence of a series of events. An example of this situation could be Ping Down from two nodes of a clustered server. If there is a Ping Down from Server A, it does not constitute a problem, as the Server B would handle its functions. However, a Ping Down of Server B in conjunction with Server A does constitute a serious problem. Similarly, if there is a Ping Down message from Server B alone, it does not constitute a problem. The previous situation can be further complicated with a third message that is Server Maintenance which indicates that Server A and Server B are brought down as a part of maintenance and the servers being down does not constitute a problem. The following table summarizes this situation: Messages Ping Down Server A [EVENT-A] Ping Down Server B [EVENT-B] Ping Down Server A [EVENT-B] Ping Down Server B [EVENT-B] Diagnosis Not a problem because Server B takes over. Not a problem because Server A takes over. No application availability. Correlated Message None None Cluster failure
C13
Messages Ping Down Server A [EVENT-A] Ping Down Server B [EVENT-B] Server Maintenance [EVENT-C]
Diagnosis Scheduled maintenance.
Correlated Message None
Timing Parameters
Each correlation rule has time settings that specify when to report a correlation message to the Event Console once the rule is triggered, and when to stop processing the rule after it is triggered.
Maturity Seconds and Override Maturity Flag
Maturity Seconds (or Maturity Period in the Configuration Wizard) is the period required to establish the root cause for a given event stream. AEC waits this many seconds after triggering a rule to report the root cause event to the Event Console. This maturity period must be long enough to ensure that AEC sees the root cause event for a given event stream. If defined too short, AEC will not have enough time to establish the root cause, and will not be able to correlate all messages associated with the current event stream. If specified too long, AEC will wait too long to establish the root cause, and unrelated events from a new event stream may be seen by AEC as being related to the previous stream. The value of this timing parameter depends heavily on the events that are being correlated. This value can be overridden by setting an Override Maturity flag on a pipeline item. In this case, the root cause event is established as soon as the matched event comes in, which is useful for analyzing operator-generated events.
Reset Seconds and Request Reset Event
Reset Seconds (or Reset Period in the Configuration Wizard) is set as the time estimated in which the flood of messages is to be blocked. AEC waits this many seconds after triggering a rule to identify subsequent matched messages as being repeated messages and pertaining to the same root cause.
C14
Administrator Guide
This reset period should correspond to the time it generally takes after the root cause of an event is established for that problem to be resolved. If defined too short, AEC will not have enough time to recognize repeated messages as being repeated, and will treat repeated messages as if they were separate failures. If specified too long, AEC will continue to ignore similar messages as repeated for longer than the correct time, and may not act upon some messages by mistaking them as being repeated. The value of this parameter also depends heavily on the events that are being correlated. This value can be overridden when a message comes in that matches the Request Reset Event. Then the rule is reset immediately. For example, if there is an interface failure on a server, we want to suppress the agent events for the time that it takes to replace the interface. The Request Reset event is important because if we replace the interface faster than normal, we want to be ready as soon as possible, in the event that the new interface may also fail (due to a manufacturing defect, for example). How AEC Uses Timing Parameters Typically, a correlated message is generated by the correlation rule at maturity. Until reset, the rule is triggered only once. All other messages that satisfy the rule are considered correlated to the current instance of the rule. Duplicate messages do not trigger another rule. That is how the reset period absorbs flooding. Upon reset, the current instance of the rule dies. No further messages are correlated with the same root cause. Any further messages satisfying the rule conditions can trigger another rule instance and report another root cause. This new instance is completely independent of the last one. Fine-tuning the maturity and reset periods is important for AEC to correlate correctly. Example When a system fails, an application makes four attempts to access its services every 60 seconds. Thus, the application will report four failures at 0, 60, 120, and 180 seconds. A reset period of 100 seconds is too short because two rules will be triggered and two root causes will be reported for a single failure.
C15
Configuration Wizards
A reset period of 500 seconds is too long. The system may go through a failure, come back up, and fail again. In this case, only one root cause would be reported for two failures. In this example, a good reset period would be 200 seconds.
Configuration Wizards
Every configurable AEC object has a Configuration Wizard associated with it, which guides you through the steps necessary to configure that object. The wizard can be launched from the IDE toolbar using the Configuration Wizard button ( ), or the right mouse button menu for that object. See the IDE online help for more information
Using Tokens
You can use tokens in correlation rules. A token is similar to a substitution parameter and can be recognized by the ampersand character (&) in front of it. For each Event field, any tokens are replaced by their actual correlation rule values (if they exist), otherwise they will be replaced by a word wildcard, that is, any value will match. Advanced Event Correlation supports the following types of tokens:

Internal tokens User-defined tokens
Internal Tokens
Internal tokens already exist in AEC and can be referenced without having to define them. Internal tokens are also referred to as built-in tokens. AEC internal tokens closely match the tokens available in Event Management message records and actions, and can be used to identify predefined event variables. In addition, there are tokens specific to AEC. See the IDE online help for descriptions of AEC internal tokens.
C16
Administrator Guide
Using Tokens
User-Defined Tokens
User-defined tokens can be included in any field of an incoming matching message. User-defined tokens are defined as &(..), with the name of the userdefined token in the parenthesis. User-defined tokens can be used to establish a relationship among messages that should be correlated. For example, if you want to relate a ping failure on one server to a service failure on that particular server, you can define a token such as &(NODENAME) in the matching string of the two messages. An assigned token, such as &(NODENAME), parsed from an incoming message, can be reused in an output message. For example, if you enter &(NODENAME) in the node field of a pipeline item match message, then it would get assigned to the first matching message. It then could be reused as part of an output message such as a local correlation message. User-defined tokens can facilitate template rules, that is, a new rule will be triggered for each unique user-defined token assignment. For more information, see Template Rules. The user-defined token value is assigned by the first matching message and it does not change until the rule has been reset. Use the IDE Token Configuration Wizard to define tokens. Local User-Defined Tokens User-defined tokens can have a scope within a rule, called a local token. A local token can be referenced only within the rule in which it is defined. Local user-defined tokens can be either static or dynamic. The value of static tokens can be determined using the fields of an event. A dynamic token can be configured to use a script or executable to return the token value. Periodically, the script is executed and the result is parsed into match and output components. In this way, tokens that reflect the current state of the dynamically changing enterprise can be assigned. To define a token for a rule, right-click the Tokens object on the rule, and select a token type. Valid token types are:

Case-sensitive--The token uses case-sensitive matching. Case-insensitive--The token uses case-insensitive matching. Host--The token matches the case-insensitive short or fully qualified name for a device. Dynamic--The token is dynamic.
C17
Using Tokens
The token is added to the token list with a red icon to indicate it is not yet active, that is, it has not yet been instantiated:
Once added, you can configure the token name and additional properties (which vary depending on the token type). Whenever you use the token in a rule, you can reference it just by name, for example, &(MYTOKEN). All configuration information is retrieved from the declaration when the token is instantiated.
Static User-Defined Tokens Dynamic UserDefined Tokens
You can predefine static user-defined tokens by adding token objects to the token list and then referencing them throughout a rule. A local dynamic token calls a script or executable when instantiated, and can pass the value that matched the token as a parameter (using an &TEXT token). The script or executable must return (to stdout) a string in the format: [input-string]\n[output-string] where input-string is the string substituted into input events, and output-string is the string substituted into output events. For example, the following event and token call the script MyScript with the command line:
C:\MyScript AValue ABC
The string returned by MyScript is then parsed and everything before the new line is the string for input events, and everything after is for output events.
Match String Input Event ^TEST: &(DYNAMIC:3600:C:\MyScript &TEXT ABC) TEST: AValue
Additionally, local dynamic tokens have a cache to aid performance. The data returned by a script or executable call is placed into the cache and remains there for the time (in seconds) indicated in the token definition. Any call to a script checks the cache first to see if a previous call with the same parameters has been made. If it has, and it is in-date, the return value is retrieved from the cache, saving significant time. If there is no entry, or the entry is too old, the entry is flushed and the script is invoked. The cache is shared across all rules so the benefits are significant.
C18
Administrator Guide
Using Tokens
Using the Matching Regular Expression You can configure the matching regular expression asterisk character (*) to include any valid regular expression. This gives you tight control over what token will match in incoming events. This expression is defined in the Expression field in the token object. For more information, see Using Regular Expressions.
Using Additional Token Evaluation Once a token has been assigned a value based on the matched element within an incoming event, you can apply additional evaluators to that value to determine if the token (and therefore the pipeline item) matches. Available evaluators are as follows: Greater Than The matched value must be greater than the value specified. Greater Than or Equal To The matched value must be greater than or equal to the value specified. Less Than The matched value must be less than the value specified. Less Than or Equal To The matched value must be less than or equal to the value specified.
C19
Using Tokens
Between The matched value must be within the range specified. Not Equal To The matched value must not match the value specified. When using additional evaluators, you can also specify that the token is never actually instantiated with a value. This lets you use tokens to extend the capabilities of POSIX regular expressions to include the evaluation capabilities listed previously. For example, assume you have defined a token &(IP_RANGE) that has a Between evaluator configured specifying the matched value must be between 75 and 100. You can then use the IP_RANGE token to restrict the Match Event to match events only relating to devices that have an IP address that falls within the range specified (for example, 192.168.51.&(IP_RANGE)). Because IP_RANGE is never instantiated with a value, it continues to act as a filter for the IP addresses being matched even after the first event has been matched.
C20
Administrator Guide
Using Tokens
Global Constants
A global constant is a constant that you define once--manually or by calling an external script, Dynamic Link Library (DLL), or executable--and then use throughout AEC policy. Global constants apply to all rules in a rule file. These constants can be used to implement a static text substring in multiple rules. The substring can be changed globally instead of manually modifying many rules. Global constants can be either static or dynamic. The value of static constants can be determined using the fields of an event. A dynamic constant can be configured to use an external script, Dynamic Link Library (DLL), or executable to return the constant value. Periodically, the DLL is loaded, and the specified DLL function is called to retrieve the constant value. In this way, constants that reflect the current state of the dynamically changing enterprise can be assigned. As with user-defined dynamic tokens, the script or executable invoked must return a string in the format: [input-string]\n[output-string] where input-string is the string substituted into input events, and output-string is the string substituted into output events. For example, say you have a series of rules that relate only to your payroll system and you want to keep a list of server names and then reuse this list for every rule. Instead of rewriting the list every time you use it, you could define a global constant such as &GLOBAL(PAYROLL) with the value SERVER1|SERVER2|SERVER3. If you add a new server to your payroll system, you would need to update the list in only one place, and the change is reflected in all rules that use it. Taking this example one step further, if you were maintaining a Business Process View in the Common Object Repository with all of your payroll servers, you could have AEC periodically retrieve the server names from that Business Process View and update the list dynamically. Using dynamic global constants in this way lets you maintain just the Business Process View and your AEC policy is updated automatically with any changes that you make. Use the IDE Global Constant Configuration Wizard to define dynamic global constants. Calendar Support As with correlation rules, dynamic global constants support the use of Unicenter NSM calendars. If configured, the value of the dynamic global constant is only refreshed when the calendar is active.
C21
Template Rules
Examples
You can use user-defined tokens in a correlation rule with two items, such as the following: Ping Failure on &(NODENAME) Service failure on &(NODENAME) The event Ping failure on A will only be correlated to Service Failure on A messages. Service Failure on B and Service Failure on C will not be correlated to the previous Ping Failure.
Template Rules
A template rule is a rule that acts as a generic template and lets multiple instances run. The rule should contain user-defined tokens that enable AEC to identify similar (but unrelated) events. Tokens are set when events are compared against the rule; the tokens take the values of the corresponding items in the event. When an event comes in that matches the match string in a rule, but does not agree with the user-defined tokens, the new event invokes another instance of the rule. This new instance will process with its own token values, and at the time of its maturity, create its own correlation message, and at the time of its reset, create its own reset message.
Example
Expanding upon the previous example of a correlation rule using Service Failure and Ping Failure as a template rule, a new instance will be created for each new NODENAME value that is encountered. Where NODENAME is a static user-defined token, assume that the following events occur: 1. 2. 3. 4. 5. Ping Failure on A Service Failure on A Service Failure on B Service Failure on C Service Failure on C
C22
Administrator Guide
Using Regular Expressions
Three different instances of the rule will be triggered and they are listed as follows:
Instance # 1--NODENAME=A correlates events # 1 and # 2. The root cause identified by this rule would be Ping Failure on A. Instance # 2--NODENAME=B correlates event # 3. The root cause identified by this rule would be Service Failure on B. Instance # 3--NODENAME=C correlates events # 4 and # 5. The root cause identified by this rule would be Service Failure on C.
As another example, assume that you have defined the following tokens in a correlation rule:
Router &(ROUTERNAME) is &(STATUS)
These tokens would match a Router A1 is down or Router A2 is up message. If the correlation rule is a template rule, then two instances of the correlation rule would be created. If the correlation rule is not a template rule, then the rule would match only the first event because, once set in a correlation rule, user-defined tokens cannot be reset. If you wanted to match both events, define the correlation rule as a template rule.
Using Regular Expressions

AEC allows the matching of events based on patterns instead of fixed strings. These text patterns are known as regular expressions, and are stored in the match event fields of AEC. Regular expressions evaluate text data and return an answer of TRUE or FALSE. That is, either the input string matches or it does not. Regular expressions consist of characters to be matched as well as a series of special characters that further describe the data. The description specified by special characters (also called meta characters) can be in the form of position, range, repetition, and placeholders. Within AEC, rules can be specified for the set of possible events that you want to match. Regular expressions can also be used to split the event apart in various ways. Regular expressions are also used to extract parts of strings and store it as a token.
C23
Advanced Template String Editor
The fields of the Match Event that accept regular expressions are as follows:

Match String Node User Station Severity Device Workload Process User Data Category Tag
AEC correlates only those messages whose node, user, station, and match string matches what is specified in the match event of a rule, and then triggers that rule. For a list of regular expressions and their meanings, see the IDE online help.
Advanced Template String Editor

The AEC IDE includes a powerful utility that lets you test matched messages against regular expressions and tokens defined in the message. The Advanced Template String Editor makes configuring AEC easy. To invoke the Advanced Template String Editor from the Configuration Wizard, click the icon Editor next to the field.
Advanced Configuration
You can use the following advanced features when configuring correlation rules in AEC.
C24
Administrator Guide
Overriding Maturity
By default, AEC waits for the maturity seconds before sending a root cause message. Sometimes you do not need to wait for the maturity period. For example, if an operator brings down a system, you know the root cause of failure. The Maturity Override flag can be used to override any wait time. As soon as the matched event is encountered, the system sends out correlated messages. To override maturity, set the Maturity Override flag for the desired rule. Once this flag set is to TRUE, the rule no longer waits for the maturity period to send a root cause message.
Suppressing Processed Messages

Sometimes you may want to hide the messages that Advanced Event Correlation has identified as being non-root cause. This process allows operators looking at the Event Console to see only genuine problem messages. The Suppress Matched Event flag can be used to suppress these messages, while still logging the messages for audit purposes. To suppress non-root cause messages, set the Suppress Matched Event flag for the desired rule. Once this flag is set to TRUE, the rule no longer reports non-root cause messages to the console.
Reformatting Processed Messages

You may not want to suppress messages that AEC identified as the non-root cause. Instead, you may want to make these processed messages look different on the Event Console by reformatting. This lets operators know the events are processed, even if they do not need to take action. For example, two messages come into the console Subnet 192.168.78.xx Down and Node 192.168.78.99 Down. The Subnet message is the root cause. However, instead of suppressing the node message, it can be reformatted to let an operator know that the node is down due to the subnet being down. To reformat messages, use the reformatted event string at the Engine level so that it applies to all rules and pipeline items. This field defaults to &TEXT, so you can either prefix or postfix the event text. For event reformatting specific to each matched event, refer to the Root and Local Reformat Events associated with each rule.
C25
Resetting Rules Dynamically

By default, setting the Reset Seconds in the correlation rule resets the rule in a static manner when the reset period ends. AEC lets you terminate a rule while it is processing. Two ways to reset a correlation rule while it is processing are listed following:

Right-click the correlation rule you want to reset, and click Reset. Define a Reset Request Event. When the Reset Request Event occurs, the correlation rule is reset.
Correlation Among Rules and RC Suppression Flag

By default, AEC generates a root cause message for each rule, regardless of whether another rule may have sent out a root cause message for the same event. This creates multiple messages whenever the same match event exists for more than one rule, and that event is matched. You can specify correlation among the root cause messages so that the common event is reported as the root cause only once. For example, consider the following two rules: Example Rule # SR: Pipeline Item # A: Operator performed Shutdown with Restart Pipeline Item # B: Example Rule # SO: Pipeline Item # C: Operator performed Shutdown with no Restart Pipeline Item # D: Ping failure They have a common event: ping failure (B or D). For example, if an operator brings down a system with a shutdown with restart option, a ping failure occurs. Since events A and B occur, rule # SR gets triggered. Because event B is the same as event D, rule # SO also gets triggered. By default, AEC generates two root cause messages: one associated with event A as the root cause in rule # SR, and the other associated with event D as the root cause in rule # SO. You can eliminate the generation of the second message. To suppress additional root cause (or non-root cause) messages for a rule, set the Suppress Matched Event RC flag to TRUE for all rules that you want to correlate. Ping failure
C26
Administrator Guide
Flexible Configuration of Certain Reported Fields

You can configure AEC to use the match and reported fields in a flexible manner to achieve different goals. Two examples are described following: Using Tokens to Report the Originating Node AEC reads messages from the Event Console, and then determines whether or not they are false. As a result, the output messages generated by the Engine contain the node name of the node on which the Engine is running, and not the name of the node from which the message originated. This may cause problems with those message records that are defined to trap messages that are generated on the original server. To keep the original node name in the node name field of the messages generated by the Engine, use the &NODEID internal token in the node field of the reporting event (correlation, reset, or impact event). This token retrieves the value of the node from the original message. By using the same token in the reporting event, AEC will report the messages with a node field containing the originating nodes name. Using Reset Request Event for Dynamic Resetting of Rules Using Event Messages By default, setting the Reset Seconds parameter in the correlation rule resets the rule in a static manner. AEC lets you terminate an instance dynamically, while it is running, by rightclicking the instance, or by sending a message to the Event Console. In a production environment, you may want to terminate an instance in the following types of situations:

A message from the Event Console A particular status on an object, since that is reflected by a message Adding or removing an object to or from a Business Process View by creating a message to be sent to the Event Console.
The Reset Request Event field lets you specify a match event, which upon receipt, forces the rule to reset. For example: Rule # 1 Pipeline # 1--Match Event=Ping Failure Pipeline # 2--Match Event=Service Failure
C27
Rule Reset Request Event=Ping OK In this case, a Ping Failure triggers the rule and causes service failures to be optionally suppressed. But, at some point during the activation of the rule, a Ping OK event is received. The rule is then immediately reset. If it is reset before maturity, the correlation event is not issued. After maturity, the reset interval is circumvented and the reset event is immediately issued.
Event Filtering
By checking the Filter Matched Events flag, any event that matches a pipeline item will not be considered by any subsequent pipeline item (in the same rule), or rules in the rule list. This functionality is provided to improve event throughput--where you know that an event will only match one of your rules, there is no need for that event to be processed by other lower-level rules in your policy.
AND Concept for Pipeline

A Match all Pipeline Items for RC flag can be set for a pipeline rule to indicate that all pipeline items must be matched for the rule to then generate a Root Correlation event. This introduces a simple AND concept for the pipeline (defaults to OR). You could also use a Boolean logic rule.
Calendar Support
AEC includes Calendar support for rules and dynamic tokens. A rule will only be enabled when the (optionally) assigned Calendar is active. If a rule is enabled while a Calendar goes inactive, the rule will continue to process events until reset, after which it will not process events again until the Calendar reactivates. This allows increased event throughput and reduced performance overhead by preventing certain rules from processing events if they are relevant only to certain times of the day, week or month. Similarly, the scheduling capabilities of the global constants are enhanced by Calendar support. If configured, the constant will only refresh its value when the Calendar is active.
C28
Administrator Guide
Event Counters and Thresholds

You can assign counters and thresholds to pipeline items to indicate how many events should match before that element is considered a root cause item (in a pipeline) or a TRUE condition in a Boolean logic statement. This lets you define rules that state that one instance of an event is not a problem, but two or more may indicate a problem, for example, a domain logon failure may be a user error the first time, but two or more errors could indicate an attempted security breach. All pipeline items have a threshold that defaults to one. This threshold must be exceeded for a pipeline item to be a valid root cause item. The threshold can be configured using the Configuration Wizard using the following built-in tokens:

&COUNT--Number of events that matched root cause pipeline item. &THRESHLD--Threshold on the root cause pipeline item.
For example, the correlated message can be defined this way:

Domain Logon Failure Message is generated &COUNT Times and the Threshold is &THRESHLD.
Event Sequencing
Every pipeline item has a configurable sequence number that can be used to determine the order in which events must arrive for that element to be matched. For example, the sequence number enables you to have a pipeline in which the second pipeline item must arrive before the first in order to match. Additionally, within a Boolean logic statement, the order in which the events arrive can affect which conditions are met, and therefore what the associated root cause is determined to be. All elements have a default sequence number of 0, which means they can be matched in any order. A sequence number higher than 0 means that the event must arrive at or later than the sequence number specified. Elements can have the same sequence number, so you could have a condition that says Event A (seq no 1) must arrive first, followed by Event B or C or D (all seq no 2).
C29
Generate Root Cause for Every Matched Event

In a pipeline where you may have multiple events matching the same pipeline item, you may want to output a correlation event for every matched event. For example, if you have a pipeline covering ping failure and agent failure events for a host, where the ping failure event is not seen but multiple agents have reported failures, you can configure AEC to generate a correlation event to indicate that several agents have failed of their own accord. You can do this by setting the Generate RC for every Matched Event flag at the pipeline item level.
Restart Timer on Match

This flag lets you configure a rule that says, If I see a problem reported multiple times within a five minute period, assume it is the same problem. If the problem is reported outside of that five minute window, assume it is a new problem. This can further reduce the number of tickets associated with the same problem. The flag works by resetting the maturity/reset counter every time a new event matches the pipeline item, so that the rule will only expire when no additional events are matched during the configured period.
Rule Chaining
In some cases, you may want to use the output from one AEC rule to form the input to another AEC rule. To support this, set the Reprocess AEC Events flag on the rule. Default functionality in AEC prevents the automatic reprocessing of its own events to avoid situations of infinite recursion and accidental matching.
Rolling Event Window

A standard AEC rule is triggered when the first matching event arrives, and matures in n seconds after that according to the maturity period you specified. Using counters, you can do some basic event frequency correlation, for example, generate a correlation event if five events are generated from the time of the first event to maturity. However, to support true event frequencies you can use a rolling event window, which means that a correlation event is generated if five events are generated at any time within the time window specified. Consider the following time line:
C30
Administrator Guide
Impact Analysis
The dashed lines represent the arrival of matching events, and the dotted lines represent the maturity period for the associated rule. In a standard rule configured to generate a correlation event, when five events are matched within a maturity period of five minutes, no correlation event is generated because five events were not matched between the time the rule was triggered and the time it reached maturity (it would have been triggered twice in the previous example with three matches on the first occasion and three matches on the second). In a rule configured to use the rolling event window, because five events were seen within a five-minute period (just not within five minutes of the rule first being triggered), a correlation event would be generated. A rolling event window means that, as new events are added to the list of matching events for the rule, old (expired events) are removed from that list and the maturity period is readjusted to start from the first matched event that still falls within the maturity period specified. This means that both the match counter and the maturity counter for a rule can go down as well as up. Using the Rolling Events window, you can configure rules that will trigger when an event reaches a significant frequency. For example, a few network alarms may be considered noise, but if 50 are seen within any hour period, that may indicate some as yet undiscovered problem, such as an error in an updated routing table. Note: The Rolling Event window only works with one pipeline item.
Impact Analysis
You can configure AEC rules to generate messages associated with the events impacted by the root causes in addition to root cause messages. AEC analyzes input messages to determine the impact a failure has on a component of a system. AEC responds by sending out impact analysis messages based on its rules. These messages can contain specified sub-strings from both the root cause and the impacted message. In addition, these impact messages can also be sent to the Event Console in the form of an aggregate report, one for each non-root cause. Since AEC recognizes a dependency of event A on event B (which is defined in the correlation rules), it can be used to report impact messages like the following:

A is impacted because B went down B has impacted A B has impacted [A1, A2, A3, A4]
C31
Impact Analysis
For example, an operator shutdown on US-NY-01 has caused a ping failure and an agent failure. You can use Impact Analysis to do the following:
Provide the operators complete and intelligent information to understand and notify the failures in the enterprise. Impact messages can be used to notify the repair personnel to fix the real failures, and also to notify the users of false failure components that their hardware or software has been impacted.
Make infrastructure changes that affect the impacted components, after receiving impact messages. For example, a router failure has caused a group of applications to fail because they have been disconnected from the database server as a result. After receiving the impact messages, you can provide an alternate route or a use a failover router from the applications to the database server that would bypass the failed router. The downtime of these applications would be drastically reduced.
Provide system administrators a way to measure the impact of failures of hardware and software throughout the enterprise. This can be done not only in terms of downtime of the failed component, but in terms of the impact, this failure had in causing downtime of all impacted components. For example, a failure on a router that is connected to two less critical workstations may not necessitate a repair until hours later. However, a failure on a router that supports hundreds of servers that house an Enterprises main applications that are accessed in a real-time manner by its clients should result in a fleet of support people to rush on site to immediately fix it. Repeated failures will prompt the administrators to use another failover router dedicated to this one, or to use an alternate network path in case of failure, or to altogether replace the router with a new one.
Impact Events
A root impact event is a type of reporting event that lets you specify the format of reported messages. You configure a root impact event similarly to the way you configure the other two types of reporting events, root correlation and root reset. A root impact event also has a similar local instance, called a local impact event, for each pipeline item, and also a flag for Use Root Impact Event.
C32
Administrator Guide
Impact Analysis
You can use tokens when configuring a root impact event, which lets you configure the impact message that is reported to the Event Console. However, the difference is in the way it generates messages.
A correlation message is generated at maturity. A reset message is generated at the end of the reset period (or when reset by a reset request event). Both these messages contain information about the root cause event. A local impact message is generated for each processed Event Console message. This message will contain information about non-root cause events that have been impacted by the root cause failure. The impact messages can be generated, one by one, after maturity, or can be done as a one-time aggregate report. If the aggregate impact mode is not chosen, the impact messages are generated once for each non-root cause event. However, there is no message generated until the root cause is determined, which is at maturity. In some cases, maturity may be before the end of the maturity period if the Override Maturity flag is set. So until the root cause is known, the impact messages cannot be generated. That is because until correlation occurs, it is not known if a message is root cause or non-root cause. At maturity, each distinct non-root cause message causes an impact message. After maturity, any non-root cause event that comes in will generate an impact message. This will continue until reset occurs. Since AEC reports only distinct messages, operators do not have to read many repeated failure messages generating many impact messages.
In addition to generating individual impact messages, AEC can be configured to generate an aggregate impact message, which is one message for all non-root cause events. For example, you could configure a message such as Ping Failure on Server A caused Agents (X Y Z) to fail.
Aggregate Impact Messages

Impact events can also be aggregated into a single, concise message. To use aggregate impact messages, the flags Generate Impact Events for Root Cause and Generate Aggregate Impact Event must be set to TRUE at the rule level. Aggregate impact events are defined within the root impact event because impacts from all pipeline items must be considered. Note: In the wizard, this means checking the Generate Impact Events check box and clicking the Aggregate button under Impact events at the bottom of the window. The key to specifying aggregate impact events is the special token &EVTLST(..), which outputs elements of each matched event that is non-root cause. Tokens inside the parenthesis are repeated for every non-root cause event that matched the pipeline. You can use any user-defined or built-in tokens inside &EVTLST.
C33
Implementing AEC
An example of an aggregate impact message is shown following: &RULEDESC Root Impact: &RCTEXT CAUSED { &EVTLST(&TEXT )} Thus, a rule with the following elements would generate the aggregate impact event shown following: Rule Description: Server Shutdown -Pipeline Item # 1: OPR Server Shutdown -Match Event: ÔPR_Server_Notify: Server: &(SERVERNAME) UID=caunint 12/4/00 10:18:18 AM Change#: Msg=shutdown restart -Local Correlation Event: Scheduled Shutdown of &(SERVERNAME) -Pipeline Item # 2: Server Ping Failure -Match Event: ^WindowsNT_Server Ping Poll Agent:Ping .* Broken Ping -Local Correlation Event: Ping Failure on &(SERVERNAME) -Pipeline Item # 3: Agent Failure -Match Event: ^WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT NA LINK-DOWN NT -Local Correlation Event: Agent Failure on &(SERVERNAME) The resulting impact message would be as follows: Server Shutdown Root Impact: Scheduled Shutdown of NODEA CAUSED { WindowsNT_Server Ping Poll Agent:Ping NODEA:Ping Broken Ping WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT NA LINK-DOWN NT} Thus, a single console message can display the root cause and all events impacting the root cause determination.
Implementing AEC
After rules are created and tested, they can be put into production. You can let the correlation process run unattended by using the AEC Engine. The Engine is installed when you install AEC. The AEC Engine runs in the background and processes the events received at the Event Console. Note: IDE processes events after they are sent to the console, while the Engine processes events before they are sent to the console. Thus when AEC is configured with reformatting or suppression features, these work only when using the Engine.
C34
Administrator Guide
Implementing AEC
Event Management passes all events to this Engine before doing any of its own processing (that is, message actions, writing to the log, and so forth).
Using the Configuration Wizard

The Configuration Wizard prompts for a rule file and sends the rules in the selected rule file to the AEC Engine. To start the Advanced Event Correlation Wizard, use the following path from the Start menu:
Unicenter TND, Enterprise Management, Advanced Event Correlation, Configuration
Note: Do not use the IDE and the AEC Engine at the same time to process rules. If both the IDE and the Engine are running at the same time, duplicate messages appear in the Event Console. However, you can add or modify rules using the IDE when the Engine is running. For more information, see the Engine Status utility.
DLL Utilities
AEC provides the following two utilities for use with the Engine. Engine Status The Engine Status GUI shows the status of Engine processing. It also permits the Engine processing to be suspended and resumed, which is useful when using the Engine in conjunction with the IDE. The Engine processing can be suspended while rules are being tested in the IDE. If both the Engine and IDE environments are active, duplicate messages appear on the console since both event correlation environments are processing messages. Note: If the Engine status shows: Could not determine Engine Status, Unicenter NSM Event Management must be recycled using unicntrl stop opr followed by unicntrl start opr. The Engine is only loaded during Event Management startup. To start the Engine status utility, use the following path from the Start menu:
Unicenter TND, Enterprise Management, Advanced Event Correlation, Engine Status
C35
Examples
Event Log Player This utility plays back prior Console Logs so that the IDE rule files can be tweaked for maximum function. The player resembles a VCR. The log directory and starting date/times must be entered as well as a target Event Management node. Clicking Play causes all prior log messages meeting the criteria to be resent to todays console on the designated node. In this way, historical events can be used to provide simulation for the Advanced Event Correlation rules. Other features allow for a real-time playback mode in which the messages are sent with their original frequency. To start the event log player, use the following path from the Start menu:
Unicenter TND, Enterprise Management, Advanced Event Correlation, Log Player
Examples
The following examples guide you step-by-step through different applications of AEC in an enterprise.
Ping Failure (Single Rule)

Whenever a system monitored by Unicenter NSM fails, many Event Console failure messages occur. These messages include ping failure messages as well as one service failure message for each service. The ping failure message is genuine and requires action. However, in this case, the service failure messages are not necessarily important. Whether an action is taken due to a service failure message depends on whether a ping failure message has been sent. Also, the Distributed State Machine may report multiple failure messages for both ping and service failure. When multiple failure events are reported, the message record component of Event Management may issue multiple notifications. In extreme cases, this failure can cause so many messages that the Event Console is flooded. This flooding can have a negative impact on Event Management processing times, as well as causing other Event Management messages to be overlooked by operators. This example shows you how to configure AEC to achieve the following results:

Identify the genuine failure messages. Reduce multiple notifications. Eliminate flooding.
C36
Administrator Guide
Examples
Identifying the Correlation Consider the following observations:

If a ping failure occurs, a ping failure is the root cause. If accompanied by a ping failure, a service failure is not the root cause. If not accompanied by a ping failure, a service failure is the root cause. Service failure and ping failure should be correlated only if they occur on the same server. A service failure message on one server should not be correlated with a ping failure message on another server. Service failure and ping failure messages should be correlated on the same server and any service.
Tip: AEC should be configured so that, after reading input messages of ping failure and service failure, it should output the root cause message.
Configure the following correlation rule and pipeline items for this scenario: 1. 2. 3.
Adding and Configuring the Ping FailureService Correlation Rule
Ping FailureService Correlation Rule. Ping FailureService Correlation Rule: Ping Failure Pipeline Item. Ping FailureService Correlation Rule: Service Failure Pipeline Item.
To add and configure the Ping FailureService Correlation Rule, follow these steps: 1. 2. 3. Open a new rule file, and expand Engine in the left pane of the IDE. Highlight Correlation Rules, right-click and select Add Event Pipeline Rule. Highlight and right-click the new rule and choose Wizard.
C37
Examples
The Rule Configuration Wizard window appears.
4.
Enter information in the following fields: Rule Name Enter Ping Failure--Service Correlation Rule. Maturity Period Enter 30. Reset Period Enter 45. Template Rule Check this check box so that a different rule is triggered for each originating node.
5.
Click OK.
C38
Administrator Guide
Examples
Adding and Configuring the Ping Failure--Service Correlation Rule: Ping Failure Pipeline Item
To add and configure the Ping Failure--Service Correlation Rule: Ping Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Ping Failure rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Ping Failure. Click Next.
C39
Examples
The event Configuration Wizard - Match Event pane appears.
6.
Enter information in the following fields: Message Template Enter WindowsNT_Server Ping Poll Agent:Ping UP Broken Ping. Node Enter &(NODENAME). This ensures that service failures from a particular node are only matched against ping failures on that node. This field is used with the Template Rule check box.
C40
Administrator Guide
Examples
7.
Click Next repeatedly until you get to the Local Correlation Event pane.
8.
Enter the following string in the Message Template field:

AEC Correlated Message: Ping Failure on &(NODENAME)
C41
Examples
9.
Click Next repeatedly until you get to the Local Reset Event pane.
10. Enter the following string in the Message Template field:

AEC Reset Message: Ping Failure on &(NODENAME)
11. Click OK.
C42
Administrator Guide
Examples
Adding and Configuring the Ping Failure--Service Correlation Rule: Service Failure Pipeline Item
To add and configure the Ping Failure--Service Correlation Rule: Service Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Ping Failure rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Service Failure. Click Next.
C43
Examples
The Event Configuration Wizard - Match Event pane appears.
6.
Enter information in the following fields: Message Template Enter WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT;ntServiceInst Repaired Critical &(SERVICENAME). Node Enter &(NODENAME). This ensures that service failures from a particular node are only matched against ping failures on that node.
C44
Administrator Guide
Examples
7.
8.

AEC Correlated Event: Service &(SERVICENAME) Failure on &(NODENAME)
C45
Examples
9.

AEC Reset Message: Service Failure on &(NODENAME)
11. Click OK. 12. The left pane of your IDE should now look like this:
C46
Administrator Guide
Examples
Resulting Messages By placing the pipeline item Ping Failure above Service Failure in the hierarchy, you ensure that a ping failure is viewed as the root cause of a service failure. Therefore, if a service failure message is the only message sent from the Event Console, AEC sends a correlated event indicating the root cause to be service failure. The reset message appears after the reset period ends. If a service failure and a ping failure message are sent from the Event Console, AEC sends a correlated event indicating the root cause to be a ping failure. The reset message appears after the reset period ends. If a flood of service failure and ping failure messages is sent from the Event Console, AEC sends a single correlated event indicating the root cause to be a ping failure. The reset message appears once. AEC does not report any other instances of these messages.
Ping Failure (Multiple Rules)

Whenever a Unicenter NSM monitored system fails, many Event Console failure messages occur. These messages include ping failure messages as well as one service failure message for each service and one process failure message for each process. The ping failure message is genuine and requires action. However, in this case, the service failure and process failure messages are not necessarily important. Whether an action is taken about a service failure or process failure message depends on whether a ping failure message has been sent. In addition, the Distributed State Machine may report multiple failure messages for ping, process failure, and service failure. When multiple failure events are reported, the message record component of Event Management may issue multiple notifications. In extreme cases, this failure can cause so many messages that the Event Console is flooded. This flooding can have a negative impact on Event Management processing times, as well as causing other Event Management messages to be overlooked by operators. This example shows you how to configure AEC to achieve the following results:

Identify the genuine failure messages. Reduce multiple notifications. Eliminate flooding.
C47
Examples

If a ping failure occurs, it is always the root cause. If accompanied by a ping failure, a service failure is not the root cause. If not accompanied by a ping failure, a service failure is the root cause. If accompanied by a ping failure, a process failure is not the root cause. If not accompanied by a ping failure, a process failure is the root cause. Service, process, and ping failures should be correlated only if they occur on the same server. A service or process failure message on one server should not be correlated with a ping failure message on another server. Service failure and ping failure messages should be correlated on the same server and any service. Process failure and ping failure messages should be correlated on the same server and any process.
Tip: AEC should be configured, so that after reading input messages of ping failure, process failure, and service failure, it should output the root cause message.
Configure the following correlation rules and pipeline items for this example: 1. 2. 3. Ping Failure--Service Correlation Rule. Ping Failure--Service: Ping Failure Pipeline Item. Ping Failure--Service: Service Failure Pipeline Item.
Note: Open a new rule file and use the procedures in the first example to create the Service Correlation Rule and pipeline items listed previously. The procedures are not duplicated in this example. 4. 5. 6. Ping Failure--Process Correlation Rule, which includes configuring the Multiple Event RC Flag. Ping Failure--Process Correlation Rule Ping Failure Pipeline Item. Ping Failure--Process Correlation Rule: Process Failure Pipeline Item.
For more information about performing these procedures, see the IDE online help.
C48
Administrator Guide
Examples
Adding and Configuring the Ping Failure--Process Correlation Rule
To add and configure the Ping Failure--Process Correlation Rule, follow these steps: 1. 2. 3. Open the rule file you already created, and expand Engine in the left pane of the IDE. Highlight Correlation Rules, right-click and select Add Event Pipeline Rule. Highlight and right-click the new rule and choose Wizard. The Rule Configuration Wizard window appears.
4.
Enter information in the following fields: Rule Name Enter Ping Failure--Process Correlation Rule. Template Rule Check this check box so that a different rule is triggered for each originating node. Suppress Multiple Event RCs Check this check box because ping failure is configured in both rules. If the root cause is a ping failure, both rules report this event to the Event Console, but checking this flag suppresses duplicate reporting of the root cause. Note: Use the default values for Maturity Period and Reset Period.
C49
Examples
5.
Adding and Configuring the Ping Failure--Process Correlation Rule: Ping Failure Pipeline Item
Click OK.
To add and configure the Ping Failure--Process Correlation Rule: Ping Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Ping Failure rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and select Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
C50
Administrator Guide
Examples
6.
Enter information in the following fields: Message Template Enter WindowsNT_Server Ping Poll Agent:Ping UP Broken Ping. Node Enter &(NODENAME). This ensures that service failures from a particular node are only matched against ping failures on that node.
C51
Examples
7.
8.

AEC Correlated Message: Ping Failure on &(NODENAME)
C52
Administrator Guide
Examples
9.

AEC Reset Message: Ping Failure on &(NODENAME)
11. Click OK.
C53
Examples
Adding and Configuring the Ping Failure--Process Correlation Rule: Process Failure Pipeline Item
To add and configure the Ping Failure--Process Correlation Rule: Process Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Ping Failure rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Process Failure. Click Next.
C54
Administrator Guide
Examples
6.
Enter information in the following fields: Message Template Enter WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT;ntProcessInst Up Critical &(PROCESSNAME). Node Enter &(NODENAME). This ensures that service failures from a particular node are only matched against ping failures on that node.
C55
Examples
7.
8.

AEC Correlated Event: Service &(PROCESSNAME) Failure on &(NODENAME)
C56
Administrator Guide
Examples
9.

AEC Reset Message: Service &(PROCESSMESSAGE) Failure on &(NODENAME)
11. The left pane of the IDE should now look like this:
C57
Examples
Resulting Messages By placing the pipeline item Ping Failure above Service Failure and above Process Failure in the hierarchy, you ensure that a ping failure is viewed as the root cause of a service failure or a process failure. Therefore, if a service failure message is the only message sent from the Event Console, AEC sends a correlated event indicating the root cause to be a service failure. The reset message appears after the reset period ends. If a process failure message is the only message sent from the Event Console, AEC sends a correlated event indicating the root cause to be a process failure. The reset message appears after the reset period ends. If either a service failure or a process failure message and a ping failure message are sent from the Event Console, AEC sends a correlated event indicating the root cause to be a ping failure. The reset message appears after the reset period ends. When a service failure, process failure, and ping failure message are sent from the Event Console, AEC sends a correlated event indicating the root cause to be a ping failure. For both rules, ping failure is indicated to be the root cause. However, since the Suppress Multiple RCs flag is TRUE, only one root cause message is returned. If a flood of service failure and ping failure messages are sent from the Event Console, AEC sends a single correlated event indicating the root cause to be ping failure. The reset message appears once. AEC does not report any other instances of these messages.
Operator Server Shutdown (Three Item Pipeline)

In an enterprise, operators routinely shut down servers. As a result, the Unicenter NSM Agents generate huge volumes of failure messages. But, the failures from the system the operator is shutting down are not actually problems, because the down state is a desired state. Event Management message records log these failure messages and, as a resulting action, send notifications. These messages cause message/action records to open unnecessary tickets. Then service people rush to fix problems only to find out that there really is no problem. Worse still, the messages are sometimes generated repeatedly causing the previous undesirable actions multiple times. The goal of this example is to show you how to use a desired state application, which can identify the desired state of a service/system, with AEC to identify only true failures and not the false failure messages.
C58
Administrator Guide
Examples
AEC rules are set up to correlate the messages of the desired state application with the system failure message by the agents. If the failure is desired, that is, caused by an operator, it shows the root cause as Server being taken down by Server Manager message. If the failure is not desired, that is, a genuine failure, it shows the root cause as system failure. Additionally, if there is a ping failure (regardless of whether it is caused by operator action or a genuine failure), there may be many agent failure messages. These agent failure messages are not real failures. However, if the agent failures are reported without any ping failure or operator message on the same system, then there is a genuine agent failure. Traps need to be sent to the Event Console as input if the operators bring down systems. These traps show up as messages on the Event Console, AEC reads the messages and knows that it is desired to have that system/service stopped. For information about traps, see the chapter Event Management.
Configure the following correlation rule and pipeline items for this example: 1. 2. 3. 4.
Adding and Configuring the Server Shutdown Correlation Rule
Server Shutdown Correlation Rule. Server Shutdown Correlation Rule: Operator Server Shutdown Pipeline Item. Server Shutdown Correlation Rule: Ping Failure Pipeline Item. Server Shutdown Correlation Rule: Agent Failure Pipeline Item
To add and configure the Server Shutdown Correlation Rule, follow these steps: 1. 2. 3. Open a new rule file, and expand Engine in the left pane of the IDE. Highlight Correlation Rules, right-click and select Add Event Pipeline Rule. Highlight and right-click the new rule and choose Wizard.
C59
Examples
The Rule Configuration Wizard window appears.
4.
Enter information in the following fields: Rule Name Enter Server Shutdown. Template Rule Check this check box so that a different rule is triggered for each originating node. Note: Use the default values for Maturity Period and Reset Period.
5.
Click OK.
C60
Administrator Guide
Examples
Adding and Configuring the Server Shutdown Correlation Rule: Operator Server Shutdown Pipeline Item
To add and configure the Server Shutdown Correlation Rule: Operator Server Shutdown Pipeline Item, follow these steps: 1. 2. 3. Expand the Server Shutdown rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Operator Server Shutdown. Click Next.
C61
Examples
6.
Enter information in the following fields: Message Template Enter ÔPR_Server_Notify: Server: &(NODENAME) UID=caunit ??/??/?? ??:??:?? ?? Change#: Msg=shutdown restart. Node Enter &(NODENAME). This ensures that agent failures and ping failures from a particular server will be matched against the operator server shutdown message on that server.
C62
Administrator Guide
Examples
7.
8.
Enter information in the following fields: Message Template Enter AEC Correlation Message: &PIPEDESC &(NODENAME). Colour Change this field to Red.
C63
Examples
9.
10. Enter information in the following fields: Message Template Enter AEC Reset Message: &PIPEDESC &(NODENAME). Colour Change this field to Green. 11. Click OK.
C64
Administrator Guide
Examples
Adding and Configuring the Server Shutdown Correlation Rule: Ping Failure Pipeline Item
To add and configure the Server Shutdown Correlation Rule: Ping Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Server Shutdown rule and highlight Pipeline. Right-click and select Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
C65
Examples
6.
Enter information in the following fields: Message Template Enter ^WindowsNT_Server Ping Poll Agent:Ping .* Broken Ping. Node Enter &(NODENAME). This ensures that agent failures and ping failures from a particular server are matched against the operator server shutdown message in that server.
C66
Administrator Guide
Examples
7.
8.
Enter information in the following fields: Message Template Enter AEC Correlation Message: &PIPEDESC on &(NODENAME). Colour Change this field to Red.
C67
Examples
9.
Click next repeatedly until you get to the Local Reset Event pane.
10. Enter information in the following fields: Message Template Enter AEC Reset Message: &PIPEDESC on &(NODENAME). Colour Change this field to Green. 11. Click OK.
C68
Administrator Guide
Examples
Adding and Configuring the Server Shutdown Correlation Rule: Agent Failure Pipeline Item
To add and configure the Server Shutdown Correlation Rule: Agent Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Server Shutdown rule and highlight Pipeline. Right-click and select Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Agent Failure. Click Next.
C69
Examples
The Event Configuration - Match Event pane appears.
6.
Enter information in the following fields: Message Template Enter ^WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT NA LINK-DOWN NT. Node Enter &(NODENAME). This ensures that agent failures and ping failures from a particular server are matched against the operator server shutdown message on that server.
C70
Administrator Guide
Examples
7.
8.
C71
Examples
9.
10. Enter information in the following fields: Message Template Enter AEC Reset Message: &PIPEDESC on &(NODENAME). Colour Change this field to Green. 11. Click OK. 12. The left pane in your IDE should now look like this:
C72
Administrator Guide
Examples
Resulting Messages AEC generates a correlated event indicating the root cause to be Operator Server Shutdown. The AEC reset message appears after the reset period as expected. By placing the Operator Server Shutdown at the higher pipeline level, you ensure that it is viewed as the root cause should it happen at the same time as a ping or agent failure. If the server shuts down on its own due to a power failure or some other electronic or software failure, the Ping Failure pipeline item would be determined as the root cause and its associated Local Correlation Event would be generated by AEC. The associated agent traps would be suppressed from the Event Console because they are caused by the ping failure. Finally, AEC would generate AEC Correlation Message: Agent failure on XYZ if the WindowsNT_Server SysAgtNT Trap Agent:SysAgtNT NA LINK-DOWN NT event message occurs by itself. A separate rule instance is triggered for each node where these events occur. A ping failure on node ABC does not correlate with an operator shutdown on node XYZ. These events would be treated by themselves if they occur.
Operator Service Shutdown (Multiple Tokens)

This example expands on the previous one. The last example showed how to configure AEC to ignore unwanted messages when operators shutdown servers. This example also deals with a desired down state, but a desired state as in which an operator brings down services rather than a server. This application must match two things: the service name and the server name. That is, if an operator brought down one service on a server, then this should be correlated with the service failure message on the same service and same server. Identifying the Correlation Configure the following correlation rule and pipeline items for this example: 1. 2. 3. Service Shutdown Correlation Rule. Service Shutdown Correlation Rule: Operator Service Shutdown Pipeline Item. Service Shutdown Correlation Rule: Service Failure Pipeline Item.
C73
Examples
Adding and Configuring the Service Shutdown Correlation Rule
To add and configure the Service Shutdown Correlation Rule, follow these steps: 1. 2. 3. Open a new rule file, and expand Engine in the left pane of the IDE. Highlight Correlation Rules, right-click and select Add Event Pipeline Rule. Highlight and right-click the new rule and choose Wizard. The Rule Configuration Wizard window appears.
4.
Enter information in the following fields: Rule Name Enter Service Shutdown Template Rule Check this checkbox so that a different rule is triggered for each originating node. Note: Use the default values for Maturity Period and Reset Period.
5.
Click OK.
C74
Administrator Guide
Examples
Adding and Configuring the Service Shutdown Correlation Rule: Operator Service Shutdown Pipeline Item
To add and configure the Service Shutdown Correlation Rule: Operator Service Shutdown Pipeline Item, follow these steps: 1. 2. 3. Expand the Service Shutdown rule and highlight Pipeline. Right-click and choose Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name filed, enter Operator Service Shutdown. Click Next.
C75
Examples
6.
Enter information in the following fields: Message Template Enter ÔPR_Service_Notify: Service: &(SERVICENAME) Server: .* has been Stopped. Node Enter &(NODENAME). This ensures that service failures from a particular server will be matched against the operator service shutdown message on that server.
C76
Administrator Guide
Examples
7.
8.
Enter information in the following fields: Message Template Enter AEC Correlation Message: &PIPEDESC &(NODENAME) service &(SERVICENAME) has been stopped. Colour Change this field to Red.
C77
Examples
9.
10. Enter information in the following fields: Message Template Enter AEC Reset Message: &PIPEDESC on &(NODENAME) service &(SERVICENAME) has been stopped. Colour Change this field to Blue. 11. Click OK.
C78
Administrator Guide
Examples
Adding and Configuring the Service Shutdown Correlation Rule: Service Failure Pipeline Item
To add and configure the Service Shutdown Correlation Rule: Service Failure Pipeline Item, follow these steps: 1. 2. 3. Expand the Service Shutdown rule and highlight Pipeline. Right-click and select Add New Pipeline Item. Highlight and right-click the pipeline item and choose Wizard. The Pipeline Item Configuration Wizard window appears.
4. 5.
In the Item Name field, enter Service Failure. Click Next.
C79
Examples
6.
Enter information in the following fields: Message Template Enter ^WindowsNT_Server SysAgtNT .* Agent:SysAgtNT:ntServiceInst .* Critical &(SERVICENAME). Node Enter &(NODENAME). This ensures that a service failure from a particular server is matched against the operator service shutdown message on that server.
C80
Administrator Guide
Examples
7.
8.
C81
Examples
9.
10. Enter information in the following fields: Message Template Enter AEC Reset Message: &PIPEDESC &3 &(NODENAME) service &(SERVICENAME) is down. Colour Change this field to Blue. 11. Click OK. 12. The left pane in your IDE should now look like this:
C82
Administrator Guide
Examples
Resulting Messages By placing the Operator Service Shutdown at the higher pipeline level, you ensure that it will be viewed as the root cause if it happens at the same time as a service failure event. If a service failure happens due to some unforeseen reason, the System Agent would generate a trap event for service failure, and AEC would generate the associated Local Correlation Event. Separate rule instances are triggered for each node where these events occur and for each service that fails. The Alerter service failure on node ABC would trigger a distinctly separate rule instance from the MSSQLSERVER service on the same node. Likewise, the MSSQLSERVER service on nodes ABC and XYZ are considered separately.
C83
Appendix
Migration Tools
This appendix details tools that you can use when migrating Unicenter NSM information from one platform to another.

Note: This wizard functions in a Windows-based environment only. The Data Transfer Wizard is a tool for transferring the Unicenter NSM-related repository data in an Ingres database to an SQL Server database. The tool supports the following databases:

Ingres II Enterprise Edition 2.0 and 2.5 Microsoft SQL Server 6.5, 7.0, and 2000
Migration Tools
D1
To start the Data Transfer Wizard, execute transferdb.exe in the \NSM\BIN directory. This wizard calls the dbmigrate executable, which is also in \NSM\BIN.
You can choose from three transfer modes for your data migration:
The Out transfer mode migrates the Ingres database data into template text files on a local workstation or network. The In transfer mode migrates the template text files from your local workstation or network to the SQL Server database. The transfer mode Both combines the In and Out transfer modes to migrate data from the Ingres database to the SQL Server database in one operation.
While using the wizard to perform a data migration in the In or Both transfer modes, you can choose to do either a clean install in to the SQL Server or to add data from the Ingres database into the existing SQL Server data. You determine the type of processing you want by setting the Process Type:
The Overwrite Data option removes existing data from the SQL Server tables and copies the data from the template text files into the SQL Server tables. The Do Not Overwrite Data option merges the data from the template text files with the existing data in the SQL Server tables.
D2
Administrator Guide
The wizard produces an error log when the process ends. The log is named dbmigrate.err and is written to the \NSM\BIN directory. The following table lists the most common messages that can show up in the file: Message SQL SERVER MESSAGE: Changed database context to master SQL SERVER MESSAGE: Changed database context to databasename. DB-LIBRARY error: General SQL Server error: Check messages from the SQLSERVER SQL Server. in tablename SQL SERVER MESSAGE: Cannot insert duplicate key row in object tablename with unique index indexname. in table SQL SERVER MESSAGE: The statement has been terminated. In browser_menu SQL SERVER MESSAGE: Violation of PRIMARY KEY constraint PK__key name. Cannot insert duplicate key in object tablename. in tablename Incomplete bulk copy FATAL ERROR! ,ERROR IN OPENING dbmigrate.out FILE bcp_colformat failed Bcp_init failed SQL SERVER MESSAGE: FAILED TO CONNECT TO SERVER INGRES MESSAGE: FAILED TO CONNECT User Action Informational only. Informational only. Check the message that follows this message. This row of data already exists in the SQL SERVER tables.
Check the message just prior to this message. This row of data already exists in the SQL SERVER tables and duplicate data is not permitted.
Part of data could not be copied from Ingres database. Check the data in the Ingres tables. Check that dbmigrate.out file exists in the same directory as the executable. Invalid data type. Contact Technical Support. Check that you have appropriate rights to perform BCP. Contact Technical Support. Check the password and server name. Check that the Ingres database server exists on the machine from which the user is trying to execute this program. Check the database to be sure that tables have valid column names or contact Technical Support.
One of the insert statements failed
Migration Tools
D3
Appendix
Repository Bridging
The Repository Bridge lets you replicate and maintain a subset of the managed objects in a source Common Object Repository to a destination Common Object Repository. This subset of objects is determined by a set of user-defined rules, known as bridging policy. Once activated, a bridge instance replicates objects in the source Common Object Repository that comply with the bridging policy, and then continues to monitor the source Common Object Repository for the following events:
State changes in bridged objects, updating the destination Common Object Repository with those changes or removing a bridged object if the state change means it no longer conforms to the bridging policy. State changes in non-bridged objects, bridging those objects if a state change means they now conform to bridging policy.
By using a number of bridges in parallel, a single source Common Object Repository can be bridged to many destination Common Object Repositories or many source Common Object Repositories can be bridged to a single destination Common Object Repository. A many-to-one bridge configuration enables central monitoring of significant objects in a distributed enterprise environment.
Repository Bridging
E1
Understand Repository Bridge
Understand Repository Bridge

The Repository Bridge implements the bridging policy defined in a bridge configuration file. Depending on the logging level set in the configuration, the status and activity of a bridge instance can be monitored by inspecting the log file generated locally. In addition, startup, shutdown, and critical error messages can be monitored remotely from a designated Event Manager Message Console.
During initialization, the Repository Bridge performs the following operations: 1. 2. 3. Scans the configuration--Parses the bridging policy. Initializes logging--Begins logging. The Repository Bridge provides complete logging facilities with a configurable level of detail. Establishes Common Object Repository connections--Establishes connections to both the source and destination Common Object Repository. The Repository Bridge must obtain a connection to both repositories to operate. Registers for notifications--Registers the Repository Bridge with the source Common Object Repository for the receipt of object state change notifications, which are used to drive the object replication process. Builds bridging decision binary--Builds an in-memory binary of the bridging policy. This process is analogous to the Event Manager or Security Manager building in-memory binaries of message records and actions. When notification is received, the Repository Bridge can rapidly analyze the notification to see if it should bridge any information to the destination Common Object Repository. Synchronizes--Scans the source Common Object Repository for all objects that satisfy the bridging policy criteria, then cross-checks the destination Common Object Repository to ensure the bridged objects exist with the same property values. Any previously bridged objects that no longer conform to policy are deleted from the destination Common Object Repository.
4.
5.
6.
Once these startup procedures complete, the Repository Bridge is driven by notifications from the source Common Object Repository. When a notification is received, the object to which it relates is analyzed to determine the following:
The object is bridged, so the notification is bridged.
E2
Administrator Guide
Bridge Architectures
The object should be bridged as a result of the notification, so the object is replicated in the destination Common Object Repository. The object is bridged, but no longer conforms to bridging policy as a result of the notification, so the replicated object is deleted.
The Repository Bridge permits two types of bridging architecture:

Fanout Aggregation
Fanout
This architecture consists of one source Common Object Repository and one or more destination Common Object Repositories. Bridge instances run between the source Common Object Repository and each of the destination Common Object Repositories.
Destination A
Destination B
Destination C
Bridge
Bridge
Bridge
Source A
DSM
Repository Bridging
E3
Aggregation
This architecture consists of several source Common Object Repositories and one destination Common Object Repository. Bridge instances run between each of the source Common Object Repositories and the destination Common Object Repository.
Destination A
Bridge Bridge Bridge
Source A
Source B
Source C
DSM
DSM
DSM
E4
Administrator Guide
Architectural Guidelines
The wrong architectural approach may have a significant impact on the performance of your bridged system, so you must consider several factors before making a decision. To aid your decision, use the following guidelines: A bridge instance should, if possible, be on the same machine as the source Common Object Repository. Significantly more communication occurs between the Repository Bridge and the source. If this communication occurs across a network you may encounter an increase in network loading and a delay in Bridge processing. The number of objects/activity in the source Common Object Repository affects the performance of the Repository Bridge. The more objects/activity in the source Common Object Repository, the more information the Repository Bridge must process. This situation may lead to delays in bridging objects or updates. Certain administrative activities, such as resetting the DSM, generate a large volume of activity in the Common Object Repository. You can temporarily stop the bridge instances associated with that Common Object Repository while such activities are performed, and then restart with Full Synchronization enabled to ensure that all updates are captured. The number of objects being bridged affects performance throughout the system. As the number of bridged objects increases, you may have an increase in processing by the bridge, an increase in network traffic between the Repository Bridge and the destination Common Object Repository, and an increase in the load on the destination database server.
Repository Bridging
E5
Fanout Guidelines The number of bridge instances running on a host affects CPU utilization on that host. Each bridge instance independently processes notifications from the source Common Object Repository. Thus, the more activity in the Common Object Repository, the more objects being bridged, and the greater the load on the host running the instances. The number of bridge instances associated with a source Common Object Repository increases the load on the source database server. Each destination aid your decision process in this architecture requires a separate bridge instance, which runs independently of the other instances associated with the source Common Object Repository. This situation causes an increased load on the source database server as the server processes requests and queries from those instances. Aggregation Guidelines The cumulative number of objects bridged from the source Common Object Repositories to the destination Common Object Repository should be carefully monitored. If several source Common Object Repositories exist, the number of objects in the destination Common Object Repository can quickly exceed the recommended limits. The same guidelines provided for a standard Common Object Repository should be followed for a bridged Common Object Repository. To avoid problems, estimates for the number of bridged objects from each source Common Object Repository should be obtained before implementation. Bridging duplicate objects to a Common Object Repository causes errors. If you have a duplication of objects across source Common Object Repositories (that is, objects have the same name), and those objects are bridged to the same destination Common Object Repository, errors can occur.
E6
Administrator Guide
Access Repository Bridge

Repository Bridge has the following interfaces: Component Repository Bridge Control Description Lets you monitor and control bridge instances available on the local host. Instances started automatically by the service can be stopped and restarted from here, if required. Lets you define bridging policy for a bridge instance through a graphical interface. This interface generates TBC files, which are stored in the Bridge Config. Directory specified during installation.
Repository Bridge Configuration GUI
Repository Bridge Instance Implements the bridging policy defined in a bridge configuration file.
Tip: The Repository Bridge has an optional Repository Bridge service that lets you manage configured bridges as an NT Service. Using this service, you can automatically stop and restart configured bridge instances during a system restart. For example, to stop the service from the command line, enter:
NET STOP Unicenter Repository Bridge
This command also stops all instances of the Repository Bridge currently running on the host that are under the control of the service.
Repository Bridging
E7
Bridge Control
The Bridge Control lets you write new bridge configurations, edit or delete existing configurations, or manually start and stop bridge instances on the local host. You can access the Bridge Control through the GUI or command line. The Bridge Control GUI displays information about the way the bridge was configured at installation, including the installation path and the path under which configurations are stored. To start the Bridge Control GUI, select Start, Unicenter TND, WorldView, Bridge, Bridge Control. The Bridge Control also has a command line interface through which you can start and stop any number of configured instances, letting you write scripts or batch files to control instances on a particular host without user intervention. The command line parameters are defined as follows:
bridgecntrl -i|-x configuration_name
where: -i Starts a bridge instance. -x Stops a bridge instance. configuration_name Identifies the configuration file name as displayed in the Repository Bridge Control GUI. For example, to start the configuration TestStart, and to stop the configuration TestStop, run the following command:
bridgecntrl iTestStart -xTestStop
Tip: You can specify any number of configurations to be started or stopped in one call. When controlling configurations using the command line, you do not need to specify the full path to the configuration file, or give the TBC extension.
E8
Administrator Guide
Bridge Configuration GUI

The Bridge Configuration GUI lets you develop and edit bridging policy, which is maintained in a TBC file. Although you can write or edit TBC files by hand, we recommend using the interface to ensure the accuracy and consistency of the policy.
To start the Bridge Configuration GUI, select Start, Unicenter TND, WorldView, Bridge, Bridge GUI.
Repository Bridging
E9
Write a Bridge Configuration
Bridge Instance
A bridge instance is a generic shell that derives its configuration from a TBC file. Only one instantiation of a given bridge configuration can be running at any time, although any number of instances can be running on a particular host. The command line parameters for a bridge instance are defined as follows:
bridge -i configuration_file [-b][-v]
where: -i configuration_file Specifies the full path and TBC extension to use. -b Specifies burst mode. This mode forces the bridge instance to start, synchronizes the two Common Object Repositories according to the policy defined, and then shuts down. This option reduces network traffic at the cost of loss of real-time update. -v Specifies bridges by propagated state. This option can only be used in combination with batch or burst mode.

To generate a bridge configuration from the Bridge Configuration GUI, follow these steps: 1. 2. 3. 4. 5. 6. 7. 8. Identify the source repository. Identify the destination repository. Configure Batch Mode Operation (if required). Configure the Logging Facility. Configure Event Management Integration. Configure Startup Options. Define the bridging policy. Save the configuration.
If the configuration definition is successful, the Bridge Configuration GUI closes and the Bridge Control interface updates its list of available configurations.
E10
Administrator Guide
Identify the Source Repository

1. To start the Bridge Configuration GUI, select Start, Unicenter TND, WorldView, Bridge, Bridge GUI. The Bridge Configuration GUI appears, as previously shown. 2. Click the button to the right of the Source Repository field. The Specify Source Repository Sign-On dialog appears.
2. 3. 4.
Specify a source Common Object Repository from those available in your system. To discover the available Common Object Repositories, click Browse. Provide signon details for the selected Common Object Repository. Click the Test Signon button to test your details. Click OK to accept the changes or Cancel to exit without changes.
Repository Bridging
E11
Identify the Destination Repository

1. On the first window in the Bridge Configuration GUI, click the button to the right of the Destination Repository field. The Specify Source Repository Sign-On dialog appears. 2. Specify a source Common Object Repository from those available within your system. To discover the available Common Object Repositories, select Browse. 3. 4.
Configure Targeting
Enter signon details for the selected Common Object Repository. Click the Test Signon button to test your details.
To aid the management of bridged objects in the destination Common Object Repository, the Repository Bridge lets you specify a target object under which all bridged objects will be placed. If targeting is not specified within a configuration, bridged objects are placed in the Managed Object folder of the destination Common Object Repository. To configure targeting, follow these steps: 1. Check the Destination Repository Targeting check box on the Specify Source Repository Sign-On window and click the Configure button. The Destination Target Object dialog appears:
2.
Specify whether the target object should be a Business Process View or a Folder, and provide the target with a name.
E12
Administrator Guide
3. 4.
Click Create Target Object Now! to create your object. Click OK to accept the changes or Cancel to exit without changes. Repeat this step for the Specify Source Repository Sign-On dialog.
Configure Batch Mode Operation

In batch mode, the Repository Bridge schedules updates at regular time intervals, ranging from 1 minute to 1 day (1440 minutes). Select the batch mode options you want to use. Batch mode lets you reduce the number of objects you need to bridge by removing the need to bridge the agent layer. In addition, in batch mode operation you can bridge objects based on their propagated state. For example, you could write rules to bridge all critical NT Server objects plus their children, rather than rules to bridge all critical NT System Agents plus their parents. Batch mode provides some additional features that are not available in a typical operation. However, the overhead associated with the additional calculations involved, particularly when applying summary state and bridging based on propagated state, may be prohibitive. Carefully consider the update period, ensuring that you permit enough time between updates for the Common Object Repository synchronization to be completed.
Repository Bridging
E13
Configure the Logging Facility

1. On the first window in the Bridge Configuration GUI, select the Logging & Events tab. The following page appears:
2.
Select the granularity of the log and specify the logging directory using the options available. For a typical operation, a logging level of Errors is likely to provide enough granularity. Note: You can view Repository Bridge log files through any standard text editor. Log file names use the following format:
<Configuration Name>_DDMMYYYY.LOG
E14
Administrator Guide
Configure Event Management Integration

1. 2. 3. Select the granularity of the messages to be sent to the Event Management node. Specify an Event Management node where start up, shut down, and other messages can be sent. Click Check Status to test the status of the node. Specify a message prefix to enable easy identification of the instance from which the event message was initiated.
Tip: Use caution when selecting the level of granularity for event forwarding to avoid flooding the Event Management node.
Configure Startup Options

1. On the first window in the Bridge Configuration GUI, select the Options tab. The following page appears:
Repository Bridging
E15
2.
Configure the available options as follows:
I would like this Configuration to be started by the Unicenter NSM Bridge Service Specifies that the Bridge Service automatically starts up a bridge instance for this configuration when the system starts up. This option ensures that the bridge instance is always running when the system is up. After initialization, bridge all updates rather than just state changes Specifies that the Repository Bridge continues to listen for all updates on objects in the source Common Object Repository. If this option is not checked, the Repository Bridge listens only for bridge state changes. In batch mode, if this option is checked all ILPs in the destination objects are updated where applicable. This action may lead to a high volume of unnecessary data transfer across the network. When an object is updated, bridge both status and severity Specifies that you are running a utility that bypasses the alarmset mechanism and directly update the severity of objects. Check for Class differences when updating objects Specifies that the Repository Bridge will tolerate the missing properties on 2.1 properties when bridging from a source 2.2/NetworkIT Common Object Repository to a destination 2.1 Common Object Repository. Maintain the physical links between Bridged Objects Specifies that link objects are bridged when their two end points are bridged. Link objects are those created outside of the auto-discovery process. My Source CORE is a TNG 2.2 installation and I want to Bridge by Propagated Severity Specifies that you want to use the propagate_sev property of objects in Bridging policy to bridge objects to their propagated severity if the source Common Object Repository is a 2.2 installation, and the CA-Unicenter TNG Severity Propagation service is running. Name Melding: Prefix the Name and Label of objects bridged to the Destination CORE Specifies that the name and label of bridged objects are prefixed with a user defined string. This facilitates easy identification of objects in the destination Common Object Repository bridged from multiple sources, and also helps to avoid duplicate object names resulting in a conflict in the Common Object Repository.
E16
Administrator Guide
Define the Bridging Policy

Bridging policy is defined as a set of rules. Bridge Rules consist of property/values pairs. The value may be specified in terms of an explicit alphanumeric value, a mix of alphanumeric and wildcard characters, a numeric range set, or a combination. Examples of each property/value format are contained in the table following: Format Explicit Wildcard Range Set Combined 1. 2. Example class_name: WindowsNT_Server, severity: 5 class_name: WindowsNT_Server, address: 172.24?.*.* class_name: WindowsNT_Server, severity: {0,2,4-6} class_name: WindowsNT_Server, address: 172.{2428,35}.*.*
Select the Bridging Rules tab. Add, edit, or delete the rules for your bridging policy. Rules are specific to a class of object. Identifying the class to which the rule relates determines the properties that can then be specified as rule criteria. a. To add a new rule, click the Add button. From this dialog, all available classes from the source Common Object Repository can be selected from the value list. The first criteria to be specified in any rule must be the class_name. b. Select the required class and click OK. c. To add criteria, click the Add button. The criteria for a rule have an inclusive AND relationship and must all be satisfied for an object to be bridged.
d. Once the list of criteria has been defined, specify the rule label and whether the rule is active. e. Specify the level of parent and child inclusions. This option determines the number of parent and child branches bridged when a compliant object is bridged. The bridging of child inclusions ensures that any status changes are correctly propagated for objects in the destination Common Object Repository. For example, if an NT Server object is bridged and has a child inclusion level of 2 set, Unispace and any managed applications running on the server (such as agents) are also bridged. f. Click OK to accept the changes or Cancel to exit without changes.
Repository Bridging
E17
Possible Implementations
Note: If batch mode is enabled and the Enable Bridging by Propagated State flag has been checked, the Repository Bridge dynamically determines the state of an object through propagation from its child objects. Thus, a rule specifying that all NT Servers with a severity of critical should be bridged, results in the bridging of NT Servers whose propagated state is critical.
Save the Configuration

Once the configuration has been defined, click the Save button to specify the configuration name. The generated TBC file is saved in the location specified for configuration files during the installation process, unless otherwise stated. Note: If this file is saved in a location other than that defined during installation, the Repository Bridge Control interface cannot detect the configuration.
The following scenarios represent possible implementations where Repository Bridge can be used.
Overview of a Distributed Organization

Your worldwide corporation wants to use Unicenter NSM to manage your enterprise. Your organization consists of a global headquarters plus a number of regional offices. Although you want to permit a degree of local autonomy in each of the regions, you also want to have a central summary of the key business processes throughout the organization to ensure that you are aware of any emerging problems that have potential impact on the global business. In this situation, you can deploy the Repository Bridge in an Aggregation architecture. Bridging the key resources from each regional Common Object Repository to the central Common Object Repository facilitates the representation of global business processes, providing the operators at that level with enough information to determine the current operation state of the organization without overloading them with low level regional detail. For example, the communications infrastructure in any organization is key to its capacity to function as a whole. The Repository Bridge could be configured to bridge the MS Exchange resources from each region into the central Common Object Repository so that a Global Communications Business Process View could be created and maintained.
E18
Administrator Guide
Problem Notification
Your large utilities company has a number of regional offices, each managed locally by Unicenter NSM. Your company also has a national Call Center where all problems are reported. If the problem cannot be resolved over the phone, a local contract services organization is notified which provides the necessary support at the local level. In this situation, you can deploy the Repository Bridge in an Aggregation architecture. By placing a Common Object Repository at the Call Center level, and bridging all objects with a status of critical from the regional level up, operators in the Call Center can monitor and track problems throughout the organization. Furthermore, by populating the Call Center Common Object Repository with only those resources showing a problem, the operators are not distracted by problem free resources, and can quickly focus their attention where required.
Restricted View of Resources

Your company has a central Common Object Repository populated with all your customers managed resources, from which you can do administrative tasks. A number of those customers have expressed an interest in passively monitoring the state of their own resources, to ensure your company is doing its job. For obvious reasons, your company could not simply provide a remote WorldView onto the central Common Object Repository for each customer, since you cannot restrict access to specific resources in that Common Object Repository. Any customer with access could browse the Common Object Repository and, potentially, the resources of their competitors. In this situation, you can deploy the Repository Bridge in a Fanout Architecture. By bridging the resources specific to each customer into a Common Object Repository to which that customer has exclusive access, you can ensure that their requirements are met without breaching any contractual obligations elsewhere.
Repository Bridging
E19
Troubleshooting
Troubleshooting
If a bridge instance fails to start, shuts down unexpectedly, or displays any unusual behavior, access the log file. Each instance has its own log file that can contain a large amount of information on the operational state of the Repository Bridge. If the log file does not contain any reported errors, the source of the problem may be in the way that the Repository Bridge has been configured. If errors are present, this may imply a problem with the source or destination Common Object Repository, or the Repository Bridge itself. The following sections help you quickly identify and overcome common problems associated with configuring and running the Repository Bridge.
Configuration File Not Displayed

When I save a configuration file, the Bridge Control does not display it in the list of Bridge Configurations. You may have saved the file into a different directory than that which you specified during installation. The directory under which the configuration files should be saved is displayed on the GUI, in the field labeled Config. File Path. To change the Config. File Path, use the Bridge Config. Directory option under Unicenter Repository Bridge on the NT Start menu.
Configuration Changes Not Used

The bridge instance does not pick up the changes I make to its configuration file. A bridge instance only reads its configuration file once, during initialization. For configuration changes to be recognized, the bridge instance must be shut down and restarted. Changing bridging policy after bridging has started may have undesirable effects, and can lead to further problems
E20
Administrator Guide
Troubleshooting
State Objects Not Bridged

I have specified that all critical NT Servers are bridged, but even though I have critical servers in the source Common Object Repository, they are not bridged to the destination Common Object Repository. The NT Servers may not be in a critical state. A child agent of that server may be critical, and its severity is being propagated to the parent server by the WorldView map. To bridge all critical NT server objects, you must bridge the associated agent objects with a parent inclusion level that embodies the server object. This rule should generalize to all host types. Alternatively, the Repository Bridge has a capability known as Virtual State Propagation, available when running in burst or batch mode, which simulates propagation to bridge objects.
Log Errors and Objects Not Bridged

When the Repository Bridge is running, errors are reported in the log file and some objects are not bridged. This problem may have one of the following causes:
Altering bridging policy dynamically-- If objects have been bridged to the destination Common Object Repository and subsequent changes are made to bridging policy, the following error may occur:
[Error]: Unable to add object <USER02:Ping> - Low level database error
This error indicates that an object to be bridged already exists in the destination Common Object Repository, with the same Uuid but a different name. This situation can occur if you alter the meld string that prefixes bridged objects.
The class of object being bridged is not defined in the destination Common Object Repository.-- If you attempt to bridge an object that has no associated class definition in the destination Common Object Repository, the following error may occur:
[Error]: Unable to get class level properties class <db2AgentNT> name <user02:DB2 Agent> - Invalid class
Errors are also reported if the class exists but differs in some way. Note: The Repository Bridge does not update class definitions in the destination Common Object Repository when bridging objects.
Repository Bridging
E21
Troubleshooting
Integrity Violation Error

An error with the term integrity violation is reported in the log file. The Repository Bridge maintains an internal representation of the objects it bridges. If, for some reason, bridged objects are deleted from the destination Common Object Repository while the Repository Bridge is running by something other than the Repository Bridge itself, an integrity violation error is reported. Avoid manually deleting of bridged objects when the associated bridge instance is running.
Bridge Service Does Not Start

The Repository Bridge service fails to start. The Repository Bridge service depends on the MS SQL Server service. If the Bridge Service is running on the same host as the source Common Object Repository, the Repository Bridge must wait for the Common Object Repository to start before starting the bridge instances that connect to the Common Object Repository. If your Bridge architecture has instances that are running on a machine that does not have SQL installed, you should remove the SQL dependency using the Services option on the Control Panel.
E22
Administrator Guide
Appendix
Desktop Management Interface (DMI)

Unicenter Support for DMI is a desktop management tool that conforms strictly to the Desktop Management Interface (DMI) specification. Unicenter Support for DMI extends the Desktop Management Interface (DMI) by providing the following:

Tracking for installed hardware and software Local machine management Remote management of desktop PCs across a network
DMI Overview
The rapid change and growth in the computer industry presents a myriad of hardware and software products that users and network administrators need to understand, manage, and inventory. In 1992, the Distributed Management Task Force, Incorporated (DMTF) began developing a standard framework for managing and tracking components installed on a PC. The DMTF established the Desktop Management Interface (DMI) specification. Unicenter Support for DMI incorporates the latest technology to implement the DMI specification on your PC and has features that do the following:

Displays current data from various resources. Provides inquiry capability for local or remote hardware and software. Allows modification of DMI data by the user (unless the data is designated read-only).
F1
Components
Components
Unicenter Support for DMI is made up of the following components:
Service Provider ExtensionA set of programs that provide DMI functionality to management applications and component instrumentation programs. MIF DatabaseContains information about hardware and software installed on a system. The Management Information Files (MIFs) contain the information stored in the database. Management InterfaceThe part of the Service Provider that allows a management application to query and edit the MIF database. Component InterfaceThe part of the Service Provider that allows a Component Instrumentation program that may come with a component to provide real-time component information.
Service Provider
The Service Provider is a set of programs that collect information from products, manage the MIF database, and pass information to management applications. The Management Interface (MI) handles communications between the Service Provider and management applications. The Component Interface (CI) handles communications between the Service Provider and manageable products. The Service Provider starts on system startup. Computer Associates DMI Service Provider consists of a group of program files referred to as the Unicenter Support for DMI Components.
MIF Database
The MIF Database contains information about the hardware and software installed on a system. Each product that adheres to the DMI specification is shipped with a MIF. Upon installation of the component, information in the MIF is stored in the MIF database. A MIFmay contain static information about a component, or it may describe how component data can be obtained through the component instrumentation.
F2
Administrator Guide
Management Interface (MI)
Management Interface (MI)

The MI lets a management application view and edit the MIF database.
Component Interface (CI)

The CI handles communications between components and the Service Provider. The CI communicates with components that supply Component Instrumentation programs that provides for real-time access to the values for component attributes in the MIF database.
Unicenter Support for DMI User Interface

The Unicenter Support for DMI user interface is a split pane, tree/list model.
Left Pane
The left pane displays a hierarchical tree.
Unicenter Support for DMI provides two operating modes: network browse and machine browse. In network browse mode, the root node is the Entire Network icon. In machine browse mode, the root node is a selected machine (as indicated by the PC icon).
F3
Unicenter Support for DMI User Interface
Right Pane
The right pane displays the same nodes in a list view.
You can drill down on a node by double-clicking it. As you do this, you will eventually get to the attribute. Attributes are displayed either in columns or in a table. You navigate within the columns or table using menu commands or toolbar buttons. In either view, you can click any column heading and the rows will be sorted, in ascending order, by the information in that column. If you select the View Sort Descending menu item, clicking a column header will sort the rows in descending order. Double-clicking on one of the attributes lets you edit that attribute.
F4
Administrator Guide
Appendix
Unicenter Management for Microsoft Operations Manager

Microsoft Operations Manager (MOM) is a Microsoft product that is similar to Unicenter NSM Event Management. The main purpose of MOM is to monitor the health of computers, devices, and services in a Microsoft network. MOM also has the capability to provide automated responses to alerts. Unicenter Management for MOM (MOM Management) integrates Unicenter NSM and MOM. This integration lets you manage MOM entities from within Unicenter NSM. The result is a central location from which you can perform management functions. The integration relies on identifying MOM-managed computers in the network. Identification is accomplished by querying both the Unicenter NSM and MOM databases. Once identified, information about those computers is gathered from the MOM database. That information is written to the Unicenter NSM Event Log and used to show status in the Unicenter NSM Common Object Repository.
Terminology
It is important to understand the following terms, which are used throughout this document. Web-Based Enterprise Management (WBEM) Web-Based Enterprise Management (WBEM) is a set of management and Internet standard technologies developed to unify the management of enterprise computing environments. WBEM provides the ability for the industry to deliver a well-integrated set of standard-based management tools leveraging the emerging Web technologies. The Distributed Management Task Force (DMTF) has developed a core set of standards that make up WBEM, which includes a data model, the Common Information Model (CIM) standard, an encoding specification, xmlCIM Encoding Specification, and a transport mechanism, CIM Operations over HTTP.
G1
Management Components
Windows Management Instrumentation (WMI) Windows Management Instrumentation (WMI) is a Microsoft infrastructure to support the CIM model and Microsoft-specific extensions of CIM. It offers query-based information retrieval and event notification. Microsoft Operations Manager (MOM) Microsoft Operations Manager (MOM) is a Microsoft product that delivers enterprise-class operations management by providing event management, proactive monitoring and alerting, reporting, and trend analysis. It helps administrators monitor and manage the events and performance of Windows 2000based server systems. MOM Entity A MOM entity can be a MOM Data Access Server, MOM Consolidator, or MOM Managed PC. MOM Data Access Server A MOM Data Access Server is a computer that has access to the MOM database. MOM Consolidator A MOM Consolidator is a computer that receives alerts from MOM Managed PCs. It consolidates those alerts and forwards them to the appropriate MOM Data Access Server. MOM Managed PC A MOM Managed PC is a computer with a MOM Agent running on it. The MOM Agents monitor the computer and report problems to a MOM Consolidator. MOM Administrator Console The MOM Administrator Console is the GUI where MOM is configured. It also provides the central monitoring point in MOM.
Management Components
MOM Management consists of MOM Discovery (Unicenter NSM WorldView) and MOM Alert Management (Unicenter NSM Event Management). MOM Discovery lets you see the status of MOM entities in WorldView. MOM Alert Management updates MOM object status and saves MOM alerts in the Unicenter NSM Event Log. MOM Management extends the functionality of WorldView and Event Management and relies on new technology that lets you identify and classify MOM-managed entities.
G2
Administrator Guide
Event Management
WorldView
Before you run a MOM Discovery, you must run a WorldView Auto Discovery on your MOM network to populate your Common Object Repository with WBEM-enabled computers. This list of WBEM-enabled computers is then used as the base for MOM Discovery. MOM Discovery communicates with MOM to identify the role each of these computers plays in your MOM network. Once that role is identified, the computer is classified as a MOM entity (MOM Server, MOM Consolidator, or MOM Managed PC.) A MOM object is created in Unispace for each role that the computer plays. After classification, MOM Management Views (Business Process Views) are created to organize the MOM entities. One MOM Management View is based on roles. In this MOM Management View, computers are grouped as MOM Servers, MOM Consolidators, and MOM Managed PCs. There are two other dynamic MOM Management Views that single out computers based on their status. These MOM Management Views let you see MOM entities created or removed based on the severity of their alert status. To keep MOM information current, you should run MOM Discovery at regular intervals. For more information about WorldView Auto Discovery, see the chapter Advanced Visualization.
Event Management
Open and unresolved MOM alerts are committed to the Unicenter NSM Event Log on the Unicenter Manager node. This lets you do the following:
View all open MOM alerts and Unicenter NSM events in one convenient location. Manage MOM alerts similarly to the ways that you manage Unicenter NSM events, such as defining event policy.
You can define policy for managing MOM alerts using Event Management. You can extend Event Management default policy to include actions specific to your implementation of Unicenter NSM. User-defined policy is executed according to current Unicenter NSM Event Management guidelines. For more information about Event Management, see the chapter Event Management.
G3
Management Using MOM Alerts

When activated, Unicenter Management for MOM interfaces with MOM and collects open and unresolved MOM alerts. Note: MOM alerts that are resolved are not collected in Unicenter NSM. You can view and resolve MOM alerts using the Unicenter Alert container, which can be opened from the context menu of a MOM Server in the MOM View. The Unicenter Alert container collects MOM alerts as they are raised in MOM. You can narrow the display of MOM alerts by setting filter criteria, such as show me alerts only for computer XYZ, and you can choose which fields you want to see displayed. To resolve a MOM alert, you assign a new MOM resolution state to the alert. See the Unicenter Alert container online help for more information.
Converting MOM Alerts to Unicenter NSM Events

Open MOM alerts are converted to Unicenter NSM events and written to the Event Log. MOM alerts are converted to Unicenter NSM messages in the following ways:
The Unicenter Event message text that is displayed in the Event Console is built using the MOM alert description field. The message always begins with the CAMM prefix followed by the description text. The MOM alert URL is appended to the message, if possible. The Unicenter Event node is the name of the MOM Server on which the MOM alert was raised. The Unicenter Event user is the user name of the process gathering the MOM alerts. The Unicenter Event workstation is the name of the MOM Managed PC that generated the MOM alert. The Unicenter Event user data value is the GUID value of the MOM alert.
G4
Administrator Guide
MOM alert severity converts to Unicenter NSM Event severity in the following ways: Mom Alert Severity Success Information Warning Critical Unavailable Unicenter NSM Event Severity S (Success) I (Information) W (Warning) F (Fatal) I (Information)
The severity conversion lets you define Unicenter NSM event policy. Through Event Management message record and message action profiles, you can identify the messages that are important to your operation. You can then define the special processing to be performed automatically whenever Unicenter NSM encounters these messages.
Determining Object Status

MOM alerts are also used to determine the status of MOM Managed PCs. Unicenter Management for MOM uses the MOM alert severity and resolution states to determine if the computer needs special attention. Objects are created for the MOM Managed PCs in the WorldView Common Object Repository during MOM Discovery. The color of those objects in Unicenter NSM changes to indicate health. The default resolution states for MOM alerts are as follows:

New Acknowledged Level 1: Assigned to helpdesk or local support Level 2: Assigned to subject matter expert Level 3: Requires scheduled maintenance Level 4: Assigned to external group or vendor Resolved
G5
The object receives the status of its most critical alert. The rules for how an object receives its status are as follows:
An alert with a resolution state of Resolved yields a Normal WorldView status. An alert with a resolution state of New receives a WorldView status depending on its MOM severity. For example: MOM Resolution State Success Information Warning Error Security Unavailable Level 1 through Level 4 Acknowledged WorldView Status Normal Normal Warning Critical Critical Down Warning Warning
When the status of an object turns to Critical or Warning, it appears in the Warning or Critical MOM Alert View. Once the alerts affecting the object are resolved, the status returns to Normal and the object is removed from the MOM Alert View.
G6
Administrator Guide
Viewing and Resolving MOM Alerts

By browsing the Enterprise MOM Topology, you can get an idea of the health of the various MOM entities in your network.
You can then use the Unicenter Alert container to learn why the status of a MOM Managed PC is Warning or Critical.
G7
To open the Unicenter Alert container for a MOM Server object, expand MOM Servers, right-click the MOM Server object, and choose Launch Alert Container from the context menu. The Unicenter Alert container lists all of the MOM Alerts for that MOM Server object. Use this window to view unresolved MOM alerts in Unicenter NSM. This container provides information about each MOM Alert raised for that MOM Server.
Some of the important information shown for each MOM alert (by scrolling to the right) is as follows: Web console Displays an icon that, when clicked, displays the alerts page in the MOM Web Console. Source Displays the name of the Windows service that was the source of the alert. Computer Displays the name of the computer on which these alerts were raised.
G8
Administrator Guide
You can click to select (highlight) one alert, or click and drag to select multiple alerts. Then right-click and select Resolve to open the Unicenter Resolve Alert Detail window to resolve the alert.
You can enter an owner name and update the resolution state for the alert. For specific procedures, see the online help for this window.
G9
Appendix
CAICCI
Computer Associates International Common Communications Interface (CAICCI) is a common service enabling cross-platform communication. CAICCI provides a platform-neutral high-performance interface that integrates CA products easily across the enterprise. In most circumstances, you need not be concerned with CAICCI. That is, CAICCI is maintained and configured transparently from various user interfaces provided by the products that rely on it. This communication facility provides a robust data transfer reliably across a variety of networks and protocols.
Data Security and CAICCI

Unicenter NSM and CCS components that use CAICCI perform proprietary data encryption for sensitive or private data, such as passwords, and so forth. Some installations may require an even higher level of protection than this. For this reason, some sites may want to implement a Virtual Private Network (VPN) or a similar facility for intensive and general security protection where needed. Other sites may want to implement the Proprietary Encryption Option (PEO) or the CAICCI Secure Sockets Facility (CCISSF) of CAICCI.
Proprietary Encryption Option (PEO)

The Proprietary Encryption Option (PEO) provides a level of security to CAICCI applications in addition to any existing encryption these applications may already provide. The PEO default algorithm and implementation is not based upon Secure Sockets Layer (SSL), nor does it use a standards-based mechanism such as DES. It is designed to balance enhancing data security and retaining the high-performance characteristics of CAICCI. When enabled, PEO calls a defined interface exposed by an exit program provided by you. In turn, outgoing CAICCI messages are encrypted using the designated algorithm. See Enabling PEO for more information.
CAICCI
H1
You may want to implement the PEO for one of two reasons:
When you have special use or internal security requirements that dictate the use of a proprietary encryption algorithm. As a general security enhancement for CAICCI applications.
Enabling PEO
By default, PEO is not enabled so it has no effect when first applied. To enable PEO, set the following environment variable and then restart your system:
CAI_CCI_ENCRYPT=1
Implementing PEO
When you want to use a proprietary encryption algorithm, you can provide a user-defined encryption library that is delivered as a dynamic link library (DLL). This library must be named cauemcc2.dll. PEO includes a default library of this name with the required encryption routines implemented so that no user-written encryption exits are required. Therefore, any user-written encryption library must replace these default binaries supplied with CAICCI.
Compatibility with Previous Versions of CAICCI

PEO functions compatibly with previous versions of CAICCI. Any CAICCI-based implementations that are not currently using the old CAICCI encryption exits do not need to be updated. PEO automatically determines the encryption capabilities of the communicating partner and makes the decision to encrypt appropriately based upon the capabilities of both.
H2
Administrator Guide
How PEO Works The following table describes how PEO works with different versions of CAICCI. The table uses the following class definitions:

Class 1--Pre Unicenter TNG 2.2 Class 2--Unicenter TNG 2.4 and Unicenter NSM 3.0 Class 3--Unicenter NSM 3.0 with PEO version of CAICCI applied. Encryption Provided No No User-defined encryption (old interface) No No No Not supported. Source must apply PEO version. Not supported. Target must apply PEO version. Default PEO encryption Default PEO encryption Default PEO encryption User-defined (new interface)
Source Target Class 1 Any Class 2 Class 2 Class 2 Class 3 Class 2 Class 3 Class 3 Class 3 Class 3 Class 3 Any Class 1 Class 2 Class 2 Class 3 Class 2 Class 3 Class 2 Class 3 Class 3 Class 3 Class 3
Source with User Exit Target with User Exit Not supported Does not matter Yes No No No Yes Does not matter No Yes No Yes Does not matter Not supported Must have same exits on both No No No Does not matter Yes No No Yes Yes
PEO APIs
Use this section only if you want to implement your own encryption algorithm. When PEO is enabled, CAICCI calls the following APIs during its normal operation. The library that you provide must contain these APIs; CAICCI uses them to encrypt and decrypt messages.
CAICCI
H3
EmCci_Init7
At startup, CAICCI calls this routine to initialize the user-supplied encryption library. CAICCI passes a character pointer to a component name (which allows the library to have different encryption routines for different components), the address of a void pointer, and the address of an integer. When the routine returns, the void pointer points at the memory segment allocated by the library, which contains the encryption key, and integer pointer points to the key length. It must return the version of the encryption library. In future versions of PEO, the API will be required to return an encryption key generated by the library and the length of that key. Syntax
uchar EmCci_Init7 (char * component_name, void ** key_p, int * key_l);
where: component_name Specifies a pointer to a null-terminated string that is the name of the application that is calling this initialization routine. Currently, CAICCI passes a pointer to a buffer that contains QUES or RMTD for this parameter. key_p Specifies the address of a pointer in which this initialization routine must store the pointer to an encryption key it has generated. The caller must allocate the storage for the pointer. Currently, CAICCI passes NULL for this parameter; it is reserved for future use. key_l Specifies the address of an integer in which this initialization routine must store the length of the encryption key pointed to by *key_p. The caller must allocate the storage for the integer. Currently, CAICCI passes 0 for this parameter; it is reserved for future use. Returns This function returns an unsigned character indicating the version of the encryption library. This function must return a value between 128 and 255. Other values are reserved for internal use only.
H4
Administrator Guide
EmCci_Encrypt7
CAICCI calls this routine to allow the user-defined library to encrypt the message in the buffer passed to this routine. This API encrypts the message, places the encrypted message into a buffer it allocates, and returns successfully or returns an error. Syntax
int EmCci_Encrypt7 (char * srcnode_p, char * srcapp_p, char * destnode_p, char * destapp_p, int convid, void * orig_p, int orig_l, void ** ret_p, int * ret_l, uchar version, void * key_p, int key_l);
where: srcnode_p Specifies a pointer to a null-terminated string that is the CAICCI system ID of the node from which the message was sent. This parameter is passed to this encryption routine to allow the implementation of node-specific encryption. srcapp_p Specifies the address of a null-terminated string that is the name of the application sending the message. This parameter is passed to this encryption routine to allow the implementation of application-specific encryption. destnode_p Specifies a pointer to a null-terminated string that is the CAICCI system ID of the node to which the message was sent. This parameter is passed to this encryption routine to allow the implementation of node-specific encryption. destapp_p Specifies the address of a null-terminated string that is the name of the application to receive the message. This parameter is passed to this encryption routine to allow the implementation of application-specific encryption. convid Specifies the CAICCI converse ID. orig_p Specifies the address of the buffer containing the clear text message to be encrypted. CAICCI supplies this pointer.
CAICCI
H5
orig_l Specifies the length of the buffer pointed to by orig_p. CAICCI supplies this length. ret_p Specifies the address of the buffer, allocated by this routine, containing the encrypted message. This routine returns the pointer to CAICCI. If the encryption was not successful, this pointer should be NULL but will not be used by CAICCI. CAICCI will not attempt to free a buffer upon return from this routine if this routine returns a failure. ret_l Specifies the length of the buffer containing the encrypted message, pointed to by ret_p. This routine returns this integer to CAICCI. If the encryption was not successful, this integer should be zero but will not be used by CAICCI. version Specifies the version of encryption supported by the other node in this communication. This parameter is passed to the encryption routine by CAICCI. key_p Specifies the address of a buffer in which this routine stores the encryption key used to encrypt the message. key_l Specifies the length of the encryption key at key_p used to encrypt the message. Returns This function returns 0 if the buffer was encrypted; -1 if the buffer was not encrypted.
H6
Administrator Guide
EmCci_Decrypt7
CAICCI calls this routine to allow the user-defined library to decrypt the message in the buffer passed to this routine. This API decrypts the message, places the decrypted message into a buffer it allocates, and returns successfully or returns an error. Syntax
int EmCci_Decrypt7 (char * srcnode_p, char * srcapp_p, char * destnode_p, char * destapp_p, int convid, void * orig_p, int orig_l, void ** ret_p, int * ret_l, uchar version, void * key_p, int key_l);
where: srcnode_p Specifies a pointer to a null-terminated string that is the CAICCI system ID of the node from which the message was sent. This parameter is passed to this decryption routine to allow the implementation of node-specific decryption. srcapp_p Specifies the address of a null-terminated string that is the name of the application sending the message. This parameter is passed to this decryption routine to allow the implementation of application-specific decryption. destnode_p Specifies a pointer to a null-terminated string that is the CAICCI system ID of the node to which the message was sent. This parameter is passed to this decryption routine to allow the implementation of node-specific decryption. destapp_p Specifies the address of a null-terminated string that is the name of the application to receive the message. This parameter is passed to this decryption routine to allow the implementation of application-specific decryption. convid Specifies the CAICCI converse ID. orig_p Specifies the address of the buffer containing the encrypted message to be decrypted. CAICCI supplies this pointer.
CAICCI
H7
orig_l Specifies the length of the buffer pointed to by orig_p. CAICCI supplies this length. ret_p Specifies the address of the buffer, allocated by this routine, containing the decrypted clear- text message. This routine returns the pointer to CAICCI. If the decryption was not successful, this pointer should be NULL but will not be used by CAICCI. CAICCI will not attempt to free a buffer upon return from this routine if this routine returns a failure. ret_l Specifies the length of the buffer containing the decrypted message, pointed to by ret_p. This routine returns this integer to CAICCI. If the decryption was not successful, this integer should be zero but will not be used by CAICCI. version Specifies the version of encryption supported by the other node in this communication. This parameter is passed to the decryption routine by CAICCI. key_p Specifies the address of a buffer in which this routine stores the encryption key used to decrypt the message. key_l Specifies the length of the encryption key at key_p used to decrypt the message. Returns This function returns 0 if the buffer was decrypted; -1 if the buffer was not decrypted.
EmCci_Free7
CAICCI calls this routine to free a buffer that was allocated within the library and returned to CAICCI by one of the three routines listed previously. Syntax
int EmCci_Free7 (void *buffer);
where: buffer Specifies a pointer to a buffer that was allocated by a library routine (EmCci_Init, EmCci_Encrypt7, or EmCciDecrypt7) to contain data to be returned to CAICCI.
H8
Administrator Guide
CAICCI Secure Sockets Facility (CCISSF)
Returns This function returns 0 if the buffer was freed; -1 if the buffer was not freed.

For CAICCI users who have the highest-level security requirements or must be compliant with certain governmental security certifications, CCISSF provides a solution. CCISSF transmits any data from components or products using CAICCI (such as Unicenter NSM) over a Secure Sockets Layer (SSL) connection, which is a highly secure encryption mechanism. As installed, CAICCI transmits data from point to point using traditional TCP/IP services, which means the application defines the format and encryption level of the data exchanged. Therefore, products that use CAICCI secure data areas that are sensitive to a product. CCISSF effectively wraps all data in an encrypted envelope. The resultant transmission is significantly more resistant to attacks, reverse engineering, and accidental or malicious intrusion.
Learning About OpenSSL

CCISSF uses OpenSSL, which is a consortium open source facility. See http://www.openssl.org for more information. Use of OpenSSL provides standards-based encryption and authentication for the sender and receiver. In OpenSSL, authentication is achieved through certificates. Certificates contain data about the local host that the remote host can use to determine whether the local host is authentic. This mechanism ensures that the communicating partner is who the partner claims to be. Secure Sockets Layer functionality is provided by dynamically loading available OpenSSL libraries. These libraries must be available on all installed machines. The minimum version requirement of OpenSSL to be used with CCISSF is OpenSSL Version 0.9.7. It is your responsibility to obtain a version of OpenSSL that is consistent with your needs and planned deployment. For your convenience, a version of OpenSSL will be installed with CAICCI.
Enabling CCISSF
CCISSF is disabled by default to provide out of the box compatibility with previous versions of CAICCI. Also, not all users will require this enhanced level of security, which comes with some performance costs.
CAICCI
H9
To enable CCISSF, set an environment variable or override the environment variable using the remote daemon configuration file. Note: Regardless of the environment variable setting, communications to a remote CAICCI will not use CCISSF unless an entry for that remote node is present in the remote daemon configuration file on the local system. Environment Variable To control CCISSF, set an environment variable in the system environment:
CAI_CCI_SECURE=[YES|NO]
where: YES Specifies that all connections, unless otherwise specified in the remote daemon configuration file (see Remote Daemon Configuration File), will have CCISSF enabled. NO Specifies that the remote daemon will not request SSL for any connections unless they are overridden in the configuration file. However, all incoming secure connections will be accepted using a secure connection. The default is NO. Remote Daemon Configuration File The configuration file is ccirmtd.rc. The SECURE verb lets you override the default behavior:
SECURE=[YES|NO]
where: YES Specifies a connection attempt to the corresponding remote CAICCI will be required to be made in a secure manner. NO Specifies that an outgoing connection attempt will be made in a non-secure manner unless the corresponding remote CAICCI requires it.
H10
Administrator Guide
Determining the Effective Security Value

The effective security value is determined by applying rules in this order: 1. 2. 3. The connection security as determined by a product configuration if it exists. The value of the host-specific SECURE value in a configuration if it exists. The value of the CAI_CCI_SECURE environment variable.
CCISSF will always connect with the highest possible level of security when communicating with another CCISSF-capable CAICCI. The following table describes the behavior: Source CAICCI Effective SECURE Value Yes Yes No No Target CAICCI Effective SECURE Value Connection Status Yes No Yes No Secure Secure Secure Not Secure
Compatibility with Previous Versions of CAICCI

When two remote daemons (one supports CCISSF and the other does not) connect to each other, the connection will never use the Secure Sockets Layer; therefore, the connection will be non-secure or denied completely. The following table defines the behavior: Effective SECURE Value of the CCISSF-Capable Version Yes No
Connection Status Denied Accepted, but not secure
CAICCI
H11
Configuring CCISSF
CCISSF depends on OpenSSL for effective communication. To use CCISSF, you must configure it to use OpenSSL. If OpenSSL is available on the system when CAICCI initializes, CAICCI uses the OpenSSL libraries to provide service for any secure connections. If OpenSSL is not available, CAICCI follows the behavior defined in the following table: Effective SECURE Values of All Connections NoDefault is No and no remote configuration file entries with SECURE=YES CAICCI Behavior if OpenSSL Is Not Available Warning message to the Event Log or syslog indicating that OpenSSL is not present at the time of initialization. All inbound connections will be denied if a secure connection request is made. All outbound connections will be made as a non-secure request. YesDefault is Yes or at least one remote configuration file with SECURE=YES An error message will be issued to the Event Log or syslog indicating the required OpenSSL component is not present and that only non-secure connections will be made. CAICCI will initialize but only connections that are requested to be non-secure will be made. Any connection for which the effective value of Secure is Yes will be disabled. Note: SSL connections are currently supported only between CAICCI remote daemons. Communication between hosts that use the QUES layer (transport daemon) cannot use SSL. The QUES implementation is typically used in Windows environments. For those users that want to use CCISSF, you must migrate to the remote daemon implementation. Default Certificate To facilitate installation, CCISSF supplies a default certificate to allow out of the box operation. However, use of the default certificate cannot ensure any significant level of authentication since all certificates are identical. For true authentication, we strongly recommend you use customized PEM format certificates in accordance with site standards, and replace the default certificate in the location discussed in this topic.
H12
Administrator Guide
The default certificate has the following properties:

Common Name is Default CCI Certificate. Issuer Common Name is Default Root Certificate. Serial number is 0xC. The certificate will become invalid after Jan 2, 2033.
The default certificates private key is encrypted with the passphrase CACCI. When CCISSF is installed a default certificate called cert.pem is installed on the system. Unless the default configuration is altered (see The ccisslcfg Utility) CCISSF will use this default certificate. This default certificate can be replaced with a user-provided certificate of the same name, or the ccisslcfg utility can be used to configure CCISSF to use a user-provided certificate with a different name.
Location of Certificate
This certificate must be placed in $CAILOCL0000. The default root certificate chain must be placed in one of the following locations:
OpenSSLs default certs directory (specified during compilation of OpenSSL) Appended or renamed to the OpenSSL default cert.pem file (specified during compilation of OpenSSL) Placed in the same directory as the default CAICCI certificate (as previously described) and be named root.pem.
Certificate Revocation Lists (CRLs) Certificate revocation lists (CRLs) are a common method to track probable rogue certificates. These are certificates that can no longer be trusted because the private key has become public knowledge, when using a public key infrastructure. CCISSF allows for the use of CRLs. To use this feature, place a generated CRL in the default CRL location of $CAILOCL0000\crl.pem. Using CRLs is not useful when using the CCISSF default certificate, since this certificate is the same across all nodes. You can use this feature only when generating your own certificates.
Tip: The ccisslcfg utility can override these default file locations.
CAICCI
H13
The ccisslcfg Utility CCISSF looks in a predetermined location for items such as a hosts certificate or root certificate (see Default Certificate). However, users may want to keep them in other locations and tell CCISSF of the change. The ccisslcfg utility lets you do this. When executed, ccisslcfg prompts for the following:

Hosts certificate and private key file. How to get the corresponding passphrase of the private key file, which can be one of the following options: By typing in the passphrase and ccisslcfg will store it in an encrypted form for you. By specifying the absolute path of a file that contains the passphrase in unencrypted form. By specifying that you will provide the passphrase in the password_cb() callback in the cauccissl/libccissl library. By stating that the private key is not protected with a passphrase.
Whether to use OpenSSLs default root certificate authority locations. CCISSF will use these locations in addition to any locations you specify in the following items below: Any number of root certificates Any number of directories containing root certificates (when specifying a directory, it is assumed that the files inside are all named with the convention of using the hash value of the issuers subject name. OpenSSL will not be able to correctly look up these files if they are not named with this convention. Read the OpenSSL documentation for more information.)
The location of any certificate revocation lists (CRLs), which can be any number of files or directories (As stated before, when specifying a directory, we assume the files inside are all named with the convention of using the hash value of the issuers subject name.)
After ccisslcfg prompts you for all these settings, it will write them in encrypted form to the file %CAILOCL0000%\ccissl.cfg. ccisslcfg will overwrite any previous settings you may have set in the past. Because this configuration file is encrypted, only the ccisslcfg utility can change these settings. Note that although the contents of this file are encrypted, we recommend that the permissions are set so that only administrators and CCISSF have access to this file.
H14
Administrator Guide
The presence of this file will override CCISSFs default behavior with respect to where it looks for certificates. This configuration utility does not need to be used if you plan to use the default CCISSF certificate locations along with providing the password_cb() callback in the cauccissl\libccissl library. The ccicrypt Utility CCISSF also includes ccicrypt, a general purpose encryption utility. The syntax for ccicrypt is as follows:
Ccicrypt [-help] [-in infile] [-out outfile] [-p password] [-cipher cipher] [-dv dataVector] encrypt|-decrypt
where: -in Specifies a file to read input from. If it is left out, ccicrypt uses standard input. -out Specifies a file to direct output to. If it is left out, ccicrypt uses standard output. -p Specifies a password for ccicrypt to use. If it is left out, ccicrypt uses a default internal password. -cipher Tells ccicrypt what type of encryption algorithm to use. Type ccicrypt -help for a list of choices and refer to http://www.openssl.org for descriptions. If an algorithm is not specified, DES in cipher feedback mode (des-cfb) is used. -dv Specifies a data vector to ccicrypt. In addition to a password, some encryption algorithm modes (life cipher feedback mode) require additional random data to further randomize the output. The data vector is any string of characters. -encrypt or decrypt Specify whether ccicrypt should encrypt or decrypt data. There is no default for this. One option should always be specified. -help Lists the available types of encryption algorithms. Using a Passphrase A passphrase is used to protect elements of the certificate while it resides on the local file system. CAICCI requires access to your system passphrase to properly function. By default, CCISSF will provide SSL with the passphrase used to encrypt the default certificate.
CAICCI
H15
To use a different passphrase, several options exist. First, the password_cb function can be provided in a shared library (see Programming a Customized SSL Environment). Additionally, you can use the ccisslcfg utility to provide the passphrase itself or the absolute path of a file that contains the desired passphrase.
Programming a Customized SSL Environment

We encourage you to create a customized SSL environment. Customization involves creating new certificates using OpenSSL tools. CCISSF has no special restrictions on the data within certificates. Any validly formatted SSL certificate will work. CAICCI lets you retrieve data in the following fields from a certificate:

Serial Number Common Name Locality State or Province Country Organization Organizational Unit Email Address Not Valid Before Date Not Valid After Date Issuer Common Name Issuer Locality Issuer State or Province Issuer Country Issuer Organization Issuer Organizational Name Issuer Email Address
Additionally, the following popular certificate extensions can be retrieved:

Basic Constraints Key Usage Subject Alternate Name Issuer Alternate Name
H16
Administrator Guide
Additional fields can be defined in the provided CAICCI header file but are not supported by CAICCI at this time.
Default Functions
Along with the default certificates, CCISSF also provides two default functions, password_cb and verifyCert, to provide the private keys password and authenticate the remote host respectively.
password_cb is called whenever the user certificates private key must be used. The default functionality is to provide the default passphrase used to encrypt the default private key. verifyCert is called whenever SSL makes a connection to ensure that the remote host is providing a valid certificate. The default behavior of this function is to allow any host presenting a certificate signed by a trusted Certificate Authority to connect.
To facilitate the customized environment, we provide an API. This interface acts as a convenient way to access the underlying Open SSL environment.
password_cb
Syntax
int password_cb(char *buf, int num, int rwflag, void *userdata);
where: buf Specifies the SSL-provided buffer of length num that points to the nullterminated password string upon exit of the function. num Specifies the length of buffer pointed to by buf (includes space for terminating character). rwflag Specifies the flag that indicates whether the function was called for encryption (rwflag is nonzero) or decryption (rwflag = 0). userdata Reserved for future use (will always be NULL).
CAICCI
H17
Returns This function returns the length of the password string pointed to by buf.
verifyCert
If you write a customized authentication function, place the functionality in verifyCert. When it starts up, the CAICCI remote daemon will attempt to load this function. Each time a secure connection is made, the CAICCI remote daemon gathers all information in certificates from the remote and local hosts. This information is placed in a structure (CCISSL_CLIENT_Auth_Callback_Env). The CAICCI remote daemon then calls verifyCert and passes it a pointer to this structure. If verifyCert returns a non-successful return code, the CAICCI remote daemon will terminate the connection. Syntax
int verifyCert(psCACE env);
where: env Specifies the CAICCI struct passed to function allowing access to certificate info (see header information at the end of this document). Returns This function returns 1 upon successful authentication; any other value upon unsuccessful authentication.
Custom Libraries
To provide custom functionality, supply a DLL. This library should export at least one of the symbols password_cb and verifyCert, and be named cauccissl.dll. If this library is present, CAICCI checks for the exported symbols password_cb and verifyCert. For each one that is exported in the library, CAICCI loads and calls that function. If either symbol is not exported, CAICCI uses the corresponding CCISSF default function (see Default Functions).
H18
Administrator Guide
User-Exported Symbols password_cb Function to supply private key passphrase. verifyCert Function to check the authenticity of a remote certificate.
User Available Functions

You have access to the following functions when writing customized authentication. Function pointers to the functions are supplied inside the data structure supplied to verifyCert.
get_cert_info
When writing a customized authentication function, you can use get_cert_info to retrieve information from a certificate on the local computer or the foreign computer. The programmer must supply only the ID of the data requested. Syntax
int get_cert_info(psCACE,
CCISSL_CERT_ID, CCISSL_CERT_DATA_ID, char** cert_data, int* cert_data_len);
where: psCACE Specifies a pointer to user struct (see CCISSL_CLIENT_Auth_Callback_Env following). CCISSL_CERT_ID Specifies an enumerated type indicating which certificate (local or remote) to look at (see header file at end). CCISSL_CERT_DATA_ID Specifies an enumerated type indicating which field of the certificate to return (see header file at end). cert_data Specifies a pointer to a char**. This will hold the data requested upon successful return. The user need not malloc or free this space. CAICCI will handle all memory management. cert_data_len Specifies a pointer to an int*. This will contain the length of cert_data upon successful return.
CAICCI
H19
Returns This function returns -1 on error, or if the data requested does not exist. On success it returns the index into the array of data where the requested information exists.
enum_cert_info
Upon first call to this function, certificate data held in the first element of the local_cert or remote_cert array is returned. Each successive call returns certificate data held in the next element of the array. When all data has been returned, the next call will return data in the first element of the array and the process repeats. Syntax
int enum_cert_info(psCACE,
CCISSL_CERT_ID, CCISSL_CERT_DATA_ID*, char** cert_data, int* cert_data_len);
where: psCACE Pointer to user structure (see CCISSL_CLIENT_Auth_Callback_Env following). CCISSL_CERT_ID Enumerated type indicating which certificate (local or remote) to look at (see header file at end). CCISSL_CERT_DATA_ID* Pointer to CCISSL_CERT_DATA_ID that contains the data ID of the data pointed to by cert_data upon return of the function. cert_data Pointer to a char**. This will hold the next piece of data in the array. The user need not malloc or free this space. CAICCI will handle all memory management. cert_data_len Pointer to an int*. This will contain the length of cert_data upon successful return. Returns This function returns -1 on error; 0 if data returned is the last in the array. If not, the index of the next piece of data is returned.
H20
Administrator Guide
output_cert_info
This function outputs a string to the destination indicated by CCISSL_OUTPUT_CERT_INFO_TYPE. All output will have the string, CCI_1024: pre-pended to it. Syntax
void output_cert_info(psCACE, char* format, );
CCISSL_OUTPUT_CERT_INFO_TYPE,
where: psCACE Specifies a pointer to user structure (see CCISSL_CLIENT_Auth_Callback_Env). CCISSL_OUTPUT_CERT_INFO_TYPE Specifies an enumerated type indicating the destination of the output (see header file described in next section). CCISSL_OUTPUT_TO_LOG specifies the event log. format Specifies a string to be output. Specifies variables to be substituted into format.
CCISSL_CLIENT_Auth_Callback_Env
The CAICCI struct (CCISSL_CLIENT_Auth_Callback_Env) is specified at the end of this document. This struct stores values that are taken from the certificates. The fields of the struct are as follows: client_callback_handle Specifies a value reserved for future use and always set to zero. local_hostname Specifies a pointer to string representing local host name. local_ipaddr Specifies an integer representation of local hosts IP address associated with remote daemon. local_portno Specifies the port number of the local side of the SSL connection. local_CCI_sysid Specifies a pointer to string representing the system ID CAICCI has assigned to the local host.
CAICCI
H21
remote_hostname Specifies a pointer to string representing the remote host name. remote_ipaddr Specifies an integer representation of remote hosts IP address associated with its remote daemon. remote_portno Specifies the port number of the remote side of the SSL connection. remote_CCI_sysid Specifies a pointer to string representing the system ID CAICCI has assigned to the remote host. remote_appname Specifies a pointer reserved for future use and set to NULL. remote_taskid Specifies a pointer reserved for future use and set to NULL. remote_userid Specifies a pointer reserved for future use and set to NULL. local_cert Specifies a pointer to an array holding information from the local machines certificate. local_cert_elem_ct Specifies the count of how many elements are in the array pointed to by local_cert. remote_cert Specifies a pointer to an array holding information from the remote machines certificate. remote_cert_elem_ct Specifies the count of how many elements are in the array pointed to by remote_cert. local_cert_elem_loc Specifies the current index into array pointed to by local_cert. remote_cert_elem_loc Specifies the current index into array pointed to by remote_cert. get_cert_info Specifies the pointer to the function that returns data from a certificate based on ID (see Header Information for User Customization). enum_cert_info Specifies the pointer to the function that sequentially returns data from a certificate (see Header Information for User Customization). output_cert_info Specifies the pointer to the function that allows the user to output a data string (see Header Information for User Customization).
H22
Administrator Guide
Header Information for User Customization

Use the following structures if you want to write customized authentication. Copy these structures and user-supplied code into a header file.
typedef enum CCISSL_CERT_ID_T { CCISSL_REMOTE_CERT_INFO, CCISSL_LOCAL_CERT_INFO } CCISSL_CERT_ID; typedef enum CCISSL_CERT_DATA_ID_T { CCISSL_CERT_BODY_DER, CCISSL_CERT_BODY_BASE64, CCISSL_CERT_SERIAL_NUMBER, CCISSL_CERT_COMMON_NAME, CCISSL_CERT_LOCALITY, CCISSL_CERT_STATE_OR_PROVINCE, CCISSL_CERT_COUNTRY, CCISSL_CERT_ORG, CCISSL_CERT_ORG_UNIT, CCISSL_CERT_DN_PRINTABLE, CCISSL_CERT_DN_DER, CCISSL_CERT_POSTAL_CODE, CCISSL_CERT_EMAIL, CCISSL_CERT_NOT_BEFORE, CCISSL_CERT_NOT_AFTER, CCISSL_CERT_EXTENSION_BASIC_CONSTRAINTS, CCISSL_CERT_EXTENSION_KEY_USAGE, CCISSL_CERT_EXTENSION_SUBJECT_ALT_NAME, CCISSL_CERT_EXTENSION_ISSUER_ALT_NAME, CCISSL_CERT_ISSUER_COMMON_NAME, CCISSL_CERT_ISSUER_LOCALITY, CCISSL_CERT_ISSUER_STATE_OR_PROVINCE, CCISSL_CERT_ISSUER_COUNTRY, CCISSL_CERT_ISSUER_ORG, CCISSL_CERT_ISSUER_ORG_UNIT, CCISSL_CERT_ISSUER_DN_PRINTABLE, CCISSL_CERT_ISSUER_DN_DER, CCISSL_CERT_ISSUER_POSTAL_CODE, CCISSL_CERT_ISSUER_EMAIL } CCISSL_CERT_DATA_ID; typedef enum CCISSL_OUTPUT_CERT_INFO_TYPE_T { CCISSL_OUTPUT_TO_STDOUT, CCISSL_OUTPUT_TO_LOG } CCISSL_OUTPUT_CERT_INFO_TYPE; typedef struct Certificate_Element { char *data; int length; CCISSL_CERT_DATA_ID id; } certElem; typedef struct CCISSL_Client_Auth_Callback_Env sCACE; typedef sCACE* psCACE; struct CCISSL_Client_Auth_Callback_Env { int client_callback_handle; char *local_hostname; int local_ipaddr; int local_portno; char *local_CCI_sysid; char *remote_hostname;
CAICCI
H23
int int char char char char
remote_ipaddr; remote_portno; *remote_CCI_sysid; *remote_appname; *remote_taskid; *remote_userid;
certElem *local_cert; int local_cert_elem_ct; certElem *remote_cert; int remote_cert_elem_ct; int int int local_cert_elem_loc; remote_cert_elem_loc; (*get_cert_info)(psCACE, CCISSL_CERT_ID, CCISSL_CERT_DATA_ID, char** cert_data, int* cert_data_len); (*enum_cert_info)(psCACE, CCISSL_CERT_ID, CCISSL_CERT_DATA_ID*, char** cert_data, int* cert_data_len); (*output_cert_info)(psCACE, CCISSL_OUTPUT_CERT_INFO_TYPE, char* format, ...);
int
void };
H24
Administrator Guide
Index
creating rules, C-5 event definitions, C-4 global constants, C-21 impact analysis, C-31 implementing, C-34 install, C-4 Maturity Seconds parameter, C-14 overview, 5-13 pipeline items, C-7 regular expressions, C-23 Reset Seconds parameter, C-14 starting the Integrated Development Environment(IDE), C-6 template rules, C-22 user-defined tokens, C-17 using tokens, C-16 utilities, C-35 Agent configuration, 3-5 discovering, 2-16 Distributed State Machine, 3-2 managed objects, 3-3 overview, 3-1 states, 3-4 Unicenter, 3-2 viewing, 3-9 Agent Technology configuration, 3-5 description, 1-13 DSM services, 3-8 overview, 3-1 starting services, 2-16 states, 3-3 viewing, 3-7 WorldView Gateway, 2-3 Agent Technology Service Manager, 3-8 Agent View, 3-9. see Node View Agent/server architecture, 6-31 Aging interval, escalation policies, 7-5
2
2D Map Business Process View, 2-35 customizing, 2-38 Dynamic Business Process View, 2-37 editing objects, 2-22 icons, objects as, 2-18 modifying managed objects, 2-23 objects as icons, 2-18
3
3D Map models, objects as, 2-18 mouse navigation, 2-31 navigating, 2-28 objects as models, 2-18 spaceball navigation, 2-31
A
Activating store and forward, 5-32 Activity Log, 12-32, 12-78 Adding backgrounds, 2-38 Address Resolution Protocol (ARP), 2-6 Administrative shares, 12-10 Advanced Event Correlation advanced configurations, C-24 Boolean logic rules, C-11 Boolean rule pipeline items, C-10 correlation rules, C-3 correlation timing parameters, C-14
Index1
Alarmsets, 2-32 Alert Logs, 12-91 Alert Manager activity and console logs, 12-97 Broadcast option, 12-94 components, 12-92 configuring, 12-93 eail option, 12-95 event priority, 12-95 overview, 12-91 pager message, 12-94 Pager option, 12-94 port configurations, 12-93 running, 12-93 sending methods, 12-92 SNMP option, 12-94 testing recipients, 12-96 Trouble Ticket option, 12-95 Unicenter option, 12-95 Alert options, 12-52 Alerts MOM Management, G-2 ALTER LABEL privilege, 11-4 Archiving problems, 7-10 arcroot User Profile, 12-9 ARP Cache method, 2-6 asset types CA-CONVIEW, 5-18 CA-CONVIEW-ACCESS, 5-18 Association Browser, 2-32 Attributes, messages, 5-5 Auto Discovery ARP Cache method, 2-6 classified objects and, 2-11 definition of, 2-1 DHCP synchronization, 2-4 discovery reclassification, 2-12 DNS Search method, 2-6 Fast ARP method, 2-6 features, 2-2 intranet, 2-8 IPX discovery, 2-13 methods, 2-5 monitoring, 2-9 overview, 2-2 Ping Sweep method, 2-5 reclassifying objects during, 2-12
SAN discovery, 2-14 single network, 2-8 starting a session, 2-7 TCP/IP and SNMP, 2-5 unclassified objects and, 2-11 with Workload Management, 2-8 Automated message processing, 5-1 Automatic volume recognition (AVR) defining devices for, 11-13 description, 11-13 using for input, 11-15 using for output, 11-14, 11-15 Autoscan cleanup and backlogging, 6-25 definition of, 6-24 new-day, 6-29, 6-38 qualifications for, 6-24 undefined calendars during, 6-29
B
Background image, 2D Map, 2-38 Background maps, 2-25 Backlog scheduling, 6-25 Backup additional media rules, 12-15 append, 12-13 BrightStor ARCserve Backup database, 12-25 compressing data, 12-17 Differential, 12-11, 12-12 encrypting data, 12-17 Full, 12-11, 12-12 Incremental, 12-11, 12-12 media rules, 12-13 media spanning, 12-16 methods, 12-11 of databases, 6-30 overview, 12-10 overwrite, 12-13 pre/post commands, 12-18 scheme, 12-10 verifying data, 12-17 Windows registry, 12-90 Backup domain controller support, description, 13-82 Backup Wizard, BrightStor ARCserve Backup, 12-6 Base calendar, 6-8, 6-38
Index2
Administrator Guide
Billboards, 2-27, 2-30 Bookmarks, 2-26, 2-44 Boolean logic using in AEC rules, C-11 Bridging accessing Repository Bridge, E-7 architecture, E-3 configuring, E-10 examples, E-18 troubleshooting, E-20 Brightstor ARCserve Backup description, 1-19 BrightStor ARCserve Backup backup, 12-10, 12-25 Device Management, 12-52 disaster recovery, 12-24 features, 12-2 functions, 12-4 introduction, 12-1 logs, 12-77 media management, 12-56 reports, 12-76 restore, 12-19 database (UNIX/Linux), 12-28 database (Windows), 12-26 host (UNIX/Linux), 12-27 host (Windows), 12-25 tasks administer BrightStor ARCserve Backup server, 12-83 customize your jobs, 12-36 define media pools, 12-62 define rotation schemes, 12-62 manage and report on database, 12-73 manage devices and media, 12-52 manage jobs, 12-29 perform data backup, 12-10 perform data restore, 12-19 recover from a disaster, 12-24 use Alert Manager, 12-91 use Media Pool Manager, 12-66 Windows integration, 12-1 wizards, 12-6 BrightStor ARCserve Backup features, 12-4 BrightStor ARCserve Backup domain, 12-9 BrightStor ARCserve Backup Manager, 12-7, 12-89 BrightStor ARCserve Backup Server, 12-7, 12-83
configuring engines, 12-83 Database Engine, configuring for Windows, 12-85, 12-87 engines, status, 12-88 engines, viewing information, 12-88 Job Engine, configuring, 12-83 Tape Engine, configuring, 12-84 BrightStor ARCserve Backup Server (UNIX/Linux), 12-8, 12-9 BrightStor ARCserve Backup Authentication Service (asauthd), 12-8 BrightStor ARCserve Backup Database Server (asdbd), 12-8 BrightStor ARCserve Backup Event Logger (asloggerd), 12-8 BrightStor ARCserve Backup Loader (arcserved), 12-8 BrightStor ARCserve Backup Media Service (asmediad), 12-8 BrightStor ARCserve Backup Scheduler (asqd), 12-8 Client Agent for UNIX/Linux, 12-9 Discovery Service (asdiscovd), 12-8 BrightStor ARCserve Backup Server Admin (Windows), 12-7 Database Engine, 12-8 Job Engine, 12-7 Tape Engine, 12-7 BrightStor ARCserve Backup wizards Backup wizard, 12-6 Device wizard, 12-6 Disaster Recovery--Boot Disk wizard, 12-6 Restore wizard, 12-6 Browser option, 12-90 bundlb command, 8-5 Bundle status, 8-1, 8-4 Business Process Views creating, 2-35 definition of, 2-18 dynamic, 2-37 dynamic containment service, 2-36 Unicenter Controller, 2-44 viewing objects with, 2-37 by_owner operand, 11-11
Index3
C
Ca7xxx log, 6-28 cabldcomp command, 7-2 CA-CONVIEW asset type, 5-18 CA-CONVIEW-ACCESS asset type, 5-18 cadiscvr command, 7-2 caevent command, 6-19, 6-20 CAI_CCI_Secure environment variable, H-10 CAICCI overview, H-1 CAIPRNT0010 environment variable, 8-5 CAISCHD0009 environment variable, 6-8, 6-38 CAISCHD0011 environment variable, 6-38 CAISCHD0012 environment variable, 6-38 CAISCHD0014 environment variable, 6-12 Calendars default, 6-8, 6-38 expanded processing, 6-8 profiles, 6-4 scheduling by, 6-5 sharing, 5-2 undefined, 6-29 cancel command, 6-39 capagecl command, 5-23, 5-26 careply command, 5-4 CASFEXIT.DLL, 13-83 catadmin utility, 10-5 Categories of problems predefined, 7-3 user-defined, 7-3 catrap command, 5-37 catrapd daemon, 5-35 cauexpr command, 6-30 cawto command, 5-4 cawtor command, 5-4 CCI. See CAICCI ccicrypt utility, H-15
Chargeback accounting period concepts, 4-57 allocating weight factors to charge groups, 4-49 assigning user entity profiles to charge groups, 4-47 assigning weight factors, 4-44 Budget accounting walk-through, 4-55 Budget concept, 4-50 charge group description, 4-45 Chargeback accounting walk-through, 4-53 Chargeback concept, 4-50 creating graphical reports, 4-55 generating bills and customizing invoices, 4-54 identifying your organizational structure, 4-42 implementing Chargeback, 4-42 listing users and charge groups, 4-49 overview, 4-41 reporting transactions, 4-55 Resource Accounting Service, 4-59 Resource Allocation concept, 4-44 Resource Allocation walk-through, 4-50 rules for assigning resource usage, 4-47 security management, 4-58 storing resource files, 4-58 understanding main concepts, 4-43 user description, 4-45 user entity profile description, 4-45 Child components, 7-2 Class adding, 2-41 characteristics of, 2-10 defining, 2-40 deleting, 2-42 hierarchy definition of, 2-11 modifying, 2-39, 2-40 inheritance, 2-11 modifying, 2-41 Class Editor, 2-40, 2-41 Class Specification, 2-41 Class Wizard, 2-18, 2-41 Classes, description, 1-12 Classified objects, 2-11 Classifying devices, 2-10 Class-level inheritance, 2-11 properties, 2-10 CLEAN parameter, 6-30
Index4
Administrator Guide
cleanlog shell script, 6-28 Closing problems, 7-10 COM problem status code, 7-6 Command Messaging, implementing, 5-25 Commands asmdmp, 11-5 bundleb, 8-5 cabldcomp, 7-2 cadiscvr, 7-2 caevent, 6-19, 6-20 cainit, 11-2 cancel, 6-39 careply, 5-4 catape create volume, 11-2 catape dbscratch, 11-30 catape mount, 11-9 catrap, 5-37 cauexpr, 6-30 cawto, 5-4 cawtor, 5-4 CYCLE VAULT, 11-28 datargen, 2-53 enfcontrol 378, 11-17, 11-18 enfcontrol 379, 11-17, 11-18 enfcontrol 524, 11-7 enfcontrol 525, 11-7 enfcontrol 862, 11-17, 11-18 enfcontrol 863, 11-17, 11-19 enfcontrol 864, 11-17 lpadmin, 9-2 maketng, 2-3 opreload, 5-13 schdchk, 6-23 schdfore, 6-23 schdhist, 6-23 schdsimu, 6-23 syncdhcp, 2-4 tapeavr_status, 11-15 unicntrl, 6-39 unishutdown, 6-39 unistart, 6-39 wmmodel, 6-23 Common Object Repository architecture, E-3 Class Wizard, 1-12 creating, 2-3 Data Scoping, 2-48 description, 1-11 Components configuration, 7-1
current group, 7-2 relationships, 7-2 tracking, 7-1 Configuration Agent Technology, 3-5 agents, 3-5 DSM, 3-6 WorldView, 3-6 configuration file, console.tab, 5-33 Configuration, agent/server multiple node, 6-32 single node, 6-32 Configuring components, 7-1 Conflict objects, 2-11 Console. See Event Console console.tab file, 5-33 Correlate event messages, 5-12 Correlation agent, 3-20 creating rules, C-5 correlation rules, Advanced Event Correlation, C-3 CPU station, 6-6 Create Repository application, 2-3 Cross-Platform Scheduling, 6-33 Customizing 2D Map, 2-38 Customizing jobs, BrightStor ARCserve Backup, 12-36 directory filters, 12-38 file attributes filters, 12-39 file pattern filters, 12-37 file update filters, 12-39 job scripts, 12-41 machine-level filters, 12-37 schedule, 12-40 using options, 12-41 Cycle duration, MGPT, 7-9 time, 7-5, 7-9 Cyclic job submission, 6-17
Index5
D
Daemons Berkeley syslog, 5-7 catrapd, 5-35 Dashboard Monitor, 2-35 Data flow to printers, 9-4 Data Scoping 2D Map, 2-62 accessing the repository, 2-52 classes, 2-52 datargen examples, 2-55 from outside of Unicenter NSM, 2-60 inheritance rules, 2-58 order of rule precedence rules, 2-58 required user IDs, 2-50 rule performance issues, 2-60 rules, 2-48 scputil utility, 2-54 troubleshooting on UNIX/Linux, 2-63 using, 2-53 Data Scoping the repository, 2-48 Database access mode, 12-91 Database Manager, 12-73 database, pruning, 12-74 opening, 12-73 sort order, changing, 12-74 SQL index, rebuilding, 12-74 view, selecting, 12-73 Database options, 12-46 Database Synchronization (DBS) configuring, 13-79 options, 13-75 overview, 13-74 restrictions, 13-74 starting, 13-80 station group, defining, 13-81 datargen (Data Scoping) examples, 2-55 datargen command, 2-53 DataScope class, 2-52 Date controls, calendar, 5-2 scheduling, 6-8 Decision Support Binary (DSB), 13-35 Deleting classes, 2-42
Delivery of reports, 8-3 Demand scheduling, 6-21 Desktop Management Interface (DMI), 2-1, F-1 MIF database, F-2 Service Provider, F-2 user interface, F-3 Destination options, 12-42 Device management, 12-52 device group, 12-53, 12-55 device sharing, 12-54, 12-55 media spanning, 12-56 Device View, 12-75 Device Wizard, BrightStor ARCserve Backup, 12-6 Devices, classifying, 2-10 devtab file, Tape Management, 11-13 Disaster recovery, BrightStor ARCserve Backup, 12-24 Disaster Recovery--Boot Disk wizard, BrightStor ARCserve Backup, 12-6 Discovering agents, 2-16 intranet, 2-8 single network, 2-8 Discovery process, 2-3 Discovery Setup window, 2-7 Discovery Wizard, 2-7 Distributed Computing Environment (DCE) keytab file, creating, 13-72 options, 13-72 overview, 13-71 starting for UNIX/Linux, 13-73 Starting for Windows, 13-73 Distributed State Machine, 3-2 configuration, 3-6 polling to verify status, 3-19 states, 3-4 viewing services, 3-8 Distributing message activity, 5-6 DNS Search method, 2-6 Documentation notational conventions, 1-25 Domain, BrightStor ARCserve Backup, 12-9 DSB. See Decision Support Binary
Index6
Administrator Guide
DSM View, 3-10 description, 1-14 Dynamic Business Process Views, 2-37 Dynamic Containment Service, 2-36 Dynamic Host Configuration Protocol (DHCP), 2-4
E
Early start time, 6-5, 6-13, 6-26 encryption. See also CAICCI encryption utility for use with CCISSF, H-15 End-to-end management, 1-11 Enterprise Job Status Report, BrightStor ARCserve Backup, 12-81 Enterprise Management, 1-15 enum_cert_info function, H-20 Environment variables Event Management, 5-10 Report Management, 8-5 Workload Management Autoscan hour, 6-38 CAISCHD0009, 6-8, 6-38 CAISCHD0011, 6-38 CAISCHD0012, 6-38 CAISCHD0014, 6-39 Default calendar, 6-38 Interval between Autoscans, 6-38 Post on Cancel?, 6-39 Escalation policies aging interval, 7-5 cycle time, 7-5, 7-6 description, 7-5 new priority field, 7-6 new responsibility field, 7-6 priority levels, 7-6 range field, 7-6 relation box, 7-8 table, 7-6 eTrust CA-Top Secret UPS/CPF interface, minimum requirements, 13-69 Event Browser, 3-11
Event Console column width, 5-31 command history, 5-31 configuration buttons, 5-31 configuration file, 5-31 customization, 5-31 fonts, 5-31 log file description, 5-17 securing, 5-18 viewing multiple, 5-33 message traffic, 5-17 record selection, 5-32 scroll modes, 5-32 timer interval, 5-33 viewing multiple log files, 5-33 window held messages, 5-17 log messages, 5-17 Event Management activating store and forward, 5-32 caiopr command, 5-13 calendars, sharing, 5-2 capagecl command, 5-23, 5-26 careply command, 5-4 cawto command, 5-4 cawtor command, 5-4 commands caiopr, 5-13 capagecl, 5-23, 5-26 careply, 5-4 cawto, 5-4 cawtor, 5-4 opreload, 5-13 configuration file, console.tab, 5-33 correlating messages, 5-12 description, 1-17 environment variables, 5-10 Event Console, customizing, 5-31 exits for user-defined functions, 5-42 held messages, 5-17 log file cleanup, 5-42 log messages, 5-17 maintenance considerations, B-1 message action restriction, 5-8 messages assign actions, 5-5 distributing activity, 5-6 held, 5-17 log, 5-17 node, 5-6 remote hosts, 5-7
Index7
trapping, 5-3 WTOR, 5-17 monitoring message traffic, 5-17 multiple console log support, 5-33 opreload command, 5-13 policies, 5-13 security enhancements, 5-42 submitting process as another user, 5-43 tasks assign actions to be performed, 5-5 customize your Event Console, 5-31 establish date and time controls, 5-2 make use of SNMP, 5-34 monitor message traffic, 5-17 promote Wireless Message delivery, 5-20 put policies into effect, 5-13 trap important messages, 5-3 view multiple remote console logs, 5-33 virus scan utility, B-1 Wireless Messaging policy defining, 5-20 triggering, 5-26 write to operator with reply, 5-17 WTOR, 5-17 Event Notification options, 12-52 Event-based scheduling, 6-5, 6-19 Events correlating, 3-20 viewing sequence, 3-19 Exits for user-defined functions, 5-42 Export Repository dialog, 2-47 Exporting objects, 2-46
G
Geomaps, 2-25 GFS Media Prediction Report, BrightStor ARCserve Backup, 12-82 GFS Rotation Job Report, BrightStor ARCserve Backup, 12-82 GFS Rotation Profile Report, BrightStor ARCserve Backup, 12-82 Global Catalog, 1-4 Global Configuration Utility, 3-12 Graph Wizard, 2-35
H
HDR1 tape label, 11-11 Help, how to access, 1-23 Historian, 2-44
I
Import Repository dialog, 2-47 Importing objects, 2-47 Inheritance class-level, 2-11 instance-level, 2-11 Instance-level inheritance, 2-11 properties, 2-10 Interface connectivity, 3-23 Interfaces UPS/Command Propagation Facility (CPF), 13-69 International Standards Organization (ISO), 5-38 Internet Assigned Numbers Authority (IANA), 5-38 IP demand polling, 3-22 IP discovery, 2-7 IPX discovery, 2-13
F
Fast ARP method, 2-6 File close event, 6-19 Filter messages, 5-1 Folder, WorldView, 2-18 FTP Proxy enabling, 13-86 options, 13-85 overview, 13-85
Index8
Administrator Guide
J
Job Log, BrightStor ARCserve Backup, 12-78 Job Queue Menu, BrightStor ARCserve Backup, 12-30 Job Queue, BrightStor ARCserve Backup adding a job, 12-33 changing execution date, 12-33 changing execution status, 12-33 changing execution time, 12-33 changing job list order, 12-34 display options, 12-35 filtering view for selected server group, 12-35 modifying a job, 12-34 stopping a job, 12-33 Job Report, BrightStor ARCserve Backup, 12-80 Job Status Manager, BrightStor ARCserve Backup, 12-29 Job Status, BrightStor ARCserve Backup display options, 12-35 executed jobs, 12-31 information, 12-29 monitoring active, 12-35, 12-36 Job tracker, 6-2 Job View, 12-74 Jobflow .GBF files, 6-49. See also Jobflow Forecast files colors for job status, 6-45 dependencies definition, 6-43 viewing, 6-44 dependency views, 6-43, 6-44 description, 1-18 design mode, definition, 6-46 displays customizing, 6-46 refreshing, 6-47 forecast files, 6-49 forecast views definition, 6-42 example, 6-43 expanding/collapsing, 6-47 mutliple views, 6-46 opening, 6-49 printing, 6-47 saving, 6-49 jobs as predecessors, 6-43, 6-44 as successors, 6-43, 6-44
completed, 6-45 levels, expanding/collapsing, 6-47 modes, changing, 6-46 predecessors, 6-44 printing adjusting pages/scale, 6-48 Forecast Views, 6-47 page setup for, 6-48 run mode, definition, 6-46 scrolling, 6-47 status conditions, colors of, 6-45 viewing job, 6-44 views,definition of, 6-42 Status Views Future area, 6-44 mutliple views, 6-46 overview, 6-44 Past area, 6-44 tasks learn the basics, 6-42 view the jobflows, 6-42 Jobs cyclic submission, 6-17 demanding, 6-21 early start time, 6-13 expanded calendar processing, 6-8 in jobset, 6-13 initiation, 6-19 not running, 6-8 predecessors, 6-13 profiles, 6-4, 6-13 resource requirements, 6-14 running on demand, 6-21 scheduling, 6-8 submitting, 6-14 termination, 6-19 Jobsets demanding, 6-21 expanded calendar processing, 6-8 predecessors, 6-11 profiles, 6-4 resource requirements, 6-10 scheduling, 6-8 usage, 6-10
Index9
L
Log files, 6-28 Log options, 12-42 Log threshold, MGPT, 7-9 lpadmin command, 9-2
Maximum time, 6-5 Media management compressing data on, 12-59 erasing media, 12-58 formatting media, 12-57 media-to-media copy, 12-60 re-tensioning media, 12-59 viewing information, 12-56 Media options, 12-49
M
Maintenance Event Management, B-1 Workload Management, 6-28, 6-29 maketng command, 2-3 Managed objects agents, 3-3 editing, 3-20 modifying objects, 2-23 WorldView, 2-19 ManagedPC autoexec.bat file, example, A-11 Boot Integrity Services (BIS) support, A-7 boot parameters, A-9 BOOTHD, A-7 configuring, A-5 boot options, A-7 objects, A-5 customized boot images associating with ManagedPC, A-12 creating, A-10 description, 1-21 DOS boot images autoexec.bat file, A-11 copying to server, A-11 customizing, A-10 downloading files with boot sequencing, A-8 with custom DOS boot images, A-10 installation launching, A-2 preparing for, A-2 introduction, A-1 Normal Boot, A-7 set ManagedPC boot option, A-13 Special Boot, A-7 Management Information Base (MIB), 5-38 Map-only file, 2-19
Media overwrite, confirming, 12-90 Media Pool Manager, 12-66 media location, 12-66 rotation scheme, GFS, 12-67 rotation scheme, simple, 12-66 Media Pool Report, BrightStor ARCserve Backup, 12-82 Media pools assigning media, 12-65 defining, 12-62 Media Pool Manager, 12-66 names, 12-64 retention period, 12-64 rotation backup jobs, 12-64 Save set, 12-63 Scratch set, 12-63 serial numbers for, 12-64 Media Report, BrightStor ARCserve Backup, 12-80 Media Session Detail Report, BrightStor ARCserve Backup, 12-81 Media Session Report, BrightStor ARCserve Backup, 12-81 Media View, 12-74 Message actions, 5-5 distributing activity, 5-6 for MGPT, 7-8 restricting, 5-8 scheduling by, 6-5, 6-19 Message correlation, 3-20 Message records assigning actions, 5-5 attributes, 5-5 node, 5-6 routing to remote hosts, 5-7
Index10
Administrator Guide
Messages eligibility for processing, 5-2 Event Console customizing, 5-31 WTOR, 5-17 Methods of discovery, 2-5 MGPT cycle time, 7-9 definition of, 7-7 table, 7-8 MIB Browser, 3-13 description, 1-14 MIB data in ObjectView, 2-34 Microsoft Operations Manager (MOM), G-1, G-2 MOM Administrator Console, G-2 MOM Consolidator, G-2 MOM Data Access Server, G-2 MOM Entity, G-2 MOM Managed PC, G-2 Modifying objects on 2D Map, 2-22 MOM Administrator Console, G-2 MOM Alert Management, G-2 MOM alerts resolution states, G-5 severity, G-5 viewing and resolving, G-7 MOM Consolidator, G-2 MOM Data Access Server, G-2 MOM Discovery, G-2 MOM Entity, G-2 MOM Managed PC, G-2 MOM Management, G-2 alert resolution states, G-5 alert severities, G-5 Unicenter Alert container, G-4 Using Event Management, G-3 MOM Management Views, G-3 Monitor in Workload server, 6-2 mtrsuf log, 6-28 Multiple console logs, viewing, 5-33 node configuration, 6-32 Must complete time, 6-5
Must start time, 6-5
N
Network additional monitoring, 3-21 discovering single, 2-8 Network Information Service (NIS) support, 13-26 Neugents, 1-6 overview, 3-2 states, 3-4 Unicenter, 3-2 New-day autoscan, 6-41 NIS. See Network Information Service (NIS) Node View, 3-14 description, 1-13 Nodes defining message action policies, 5-6 guest ID support, 13-20 multiple, 6-32 remote audit support, 13-19 restricting message actions, 5-8 single, 6-32 UNIX/Linux node support, 13-23 UNIX/Linux, global vs. nodal, 13-37 user database updates, 13-16, 13-62 viewing, 3-14 Non-CPU tasks, 6-6 NTFS volumes, recording hard links for, 12-90
O
Object Browser, 2-41 Object details, viewing, 2-33 Object Store, 2-3, 2-16 Object technology, 1-11 ObjectView, 2-19 dashboard monitor, 2-35 viewing MIB and WBEM data, 2-34 On demand scheduling, 6-21 Opening problems, 7-7
Index11
Operation options, 12-44 OpLog, 7-10 opreload command, 5-13 Options, Security Management Accept Remote Dynamic Update for DSB/SAM, 13-16 ACCEPT_DBS_STATGROUP, 13-77 Authorized User List, 13-12, 13-36 automatic startup option, 13-22 CALL_PREPOST_FOR_NIS, 13-28 CPF Target Systems, 13-67 CPF_TARGETS, 13-67 customizing, 13-7 DBS_ADMINDATALEVEL, 13-77 DBS_AUDITDATALEVEL, 13-76 DBS_STATGROUP, 13-76 Default Permission, 13-8 DEFAULT_PERMISSION, 13-8 DELETE_NIS_FROM_PASSWD, 13-27 DSB Search Order, 13-17 Dynamic Group Update for DSB/SAM, 13-14 Dynamic Update for DSB/SAM, 13-13, 13-75 ENABLE_ANONYMOUS_FTP, 13-86 ENABLE_FTP_PROXY, 13-85 FTP_SERVER_PORT, 13-86 Guest Logon Options option, 13-20 Guest User ID option, 13-20 Implicit DENY Permission for Rules, 13-45 Local Evaluation Server List, 13-14 LOCAL_EVAL_SERVER_LIST, 13-14 Logon Intercept Setting option, 13-20 Maintain passwords in Unicenter option, 13-21 PSWDADMINBYPASS, 13-30 PSWDVALEXIT, 13-30 PSWDVALEXIT_TIMEOUT, 13-31 Remote Audit Receive Setting option, 13-19 Remote Audit Send Setting option, 13-19 reviewing, 13-7 Rule Server for Rule Processing option, 13-22 SEC_EVALORDER, 13-25 SEC_GLOBAL_AND_LOCAL, 13-25 SETUID_SWITCH_ID, 13-32 SSF Command Scope Option, 13-58 SSF Data Scope Option, 13-58 SSF Keyword Scope Option, 13-58 SSF_AUTH, 13-13, 13-36 SU_SWITCH_ID, 13-32 SYNC_ALTER, 13-75 SYNC_DB_DSB_FROM_MON, 13-79 SYNC_DEFINE, 13-76 SYNC_DELETE, 13-76 System Violation Mode, 13-9
SYSTEM_MODE, 13-9 UPDATE_EXTERNAL, 13-13, 13-75 UPDATE_PASSWD_FOR_NIS, 13-27 UPS Database Sync - Accept Alter Transactions, 13-75 UPS Database Sync - Accept Define Transactions, 13-76 UPS Database Sync - Accept Delete Transactions, 13-76 UPS Database Sync - Admin Data Level, 13-77 UPS Database Sync - Auditing Data Level, 13-76 UPS Database Sync - Global Station Group, 13-76 UPS Database Sync - Proxies route via Global DBS Station Group, 13-79 UPS_CHECKOLDPASSWORDS, 13-66 UPS_DCEADMIN, 13-72 UPS_DCEGATEWAY, 13-72 UPS_DCEKEY, 13-72 UPS_LOGONASUSER, 13-65 UPS_LOGONUSER, 13-65 UPS_LOGOPTION, 13-64, 13-78 UPS_MASTER, 13-65, 13-78 UPS_PROXYROUTE, 13-67 UPS_STOREINTERVAL, 13-66, 13-78 USE_PAT, 13-10 User Default Violation Action, 13-10 User Default Violation Mode, 13-10 User Group Server for Rule Processing option, 13-22 User Profile Sync - Check Old Passwords, 13-66 User Profile Sync Days to Store and Forward, 13-66, 13-78 User Profile Sync - Logging Options, 13-64, 13-78 User Profile Sync - Logon As User, 13-65 User Profile Sync - Password Change Case, 13-67 User Profile Sync Proxies Route via User Profile's UPS Station Group, 13-67 User Profile Sync UPS Station Group, 13-66 User Profile Synch - Master Node, 13-65, 13-78 User Profile Synch - SSF User for UPS, 13-65 USER_UPSSTAT, 13-66 USER_VIOLACTION, 13-10 USER_VIOLMODE, 13-10 Options, Tape Management ABE, 11-33 CDAY, 11-33 CJOB, 11-33 COMPANY, 11-33 CUSER, 11-33 customizing, 11-33 DATEFMT, 11-33 DCHG, 11-33 GUMLABEL, 11-8, 11-34
Index12
Administrator Guide
KEYTAPE, 11-34 LCHG, 11-34 MIXEXP, 11-34 RCYCDAYS, 11-34 retention values for, 11-35 RPERIOD, 11-34 ovrid operand, 11-4
P
Page format, 8-2 selection, 8-1, 8-2 Page Writer, 5-25 PageNet, 5-25 Parent components, 7-2 Password Change Notification (PCN), 13-84 passwords encrypting, H-1 Peer components, 7-2 Performance Configuration architecture, 4-9 Associate MIB, 4-24 command line utility (cfgutil), 4-28 configuration server logs, 4-29 configuration states, 4-12 configuring Performance Agent, 4-17 performance domain, 4-13 selected machine, 4-25 selected SNMP device, 4-28 daily performance cubes, 4-19 data gathering properties, 4-17 default profile, 4-21 DHCP support, 4-14 disabling data gathering, 4-28 discovering agents, 4-16 resources, 4-16 Distribution Server, 4-11, 4-29, 4-30 Domain Server, 4-11, 4-29, 4-30, 4-32 enterprise cubes, 4-19 exception files, 4-20 full daily cubes, 4-19 general management policies, 4-20 Groups branch, 4-15 GUIs, 4-12
Machines And Devices branch, 4-13 MIBMux resources, 4-24 network topology view, 4-13 One Click Configuration, 4-25 overview, 4-9 Performance Neugent, 4-20 period cubes, 4-19 process resources, 4-18 Profile Editor, 4-17 profiles, 4-21 Profiles branch, 4-15 re-enabling data gathering, 4-28 restricting configuration operations, 4-30 SNMP data gathering, 4-22 proxy machines, 4-23 resources, 4-24 sponsor resources, 4-18 subset daily cubes, 4-19 summarized data properties, 4-21 threshold processing, 4-20 Performance Management accessing components, 4-9 Chargeback, 4-41 Configuration, 4-9 description, 1-15 overview, 4-1 Resource Accounting Service, 4-5 Scope, 4-32 terminology, 4-7 Trend, 4-36 UNIX/Linux Platform, 4-3 utilities, 4-60 Windows Platforms, 4-4, 4-5 Performance Scope configuring options, 4-33 creating charts, 4-34 overview, 4-32 real-time view, 4-32 setting thresholds, 4-35 viewing errors, 4-36 viewing historical data, 4-34 viewing machine resources, 4-33 Performance Trend ad hoc charts, 4-39 automating chart generation, 4-40 chart configuration, 4-37 chart definition sets, 4-37 chart definitions, 4-37 conducting trend analysis, 4-37 correlating cube data, 4-40 overview, 4-36
Index13
predefined charts, 4-38 translating resource data, 4-37 viewing batch reports, 4-40 Ping Sweep method, 2-5 Polling changing interval, 3-21 IP demand, 3-22 IPX, 3-23 remote, 3-22 Pollset Browser, 3-15 POSTCPU station, 6-6 Pre/post job options, 12-50 PRECPU station, 6-6 Predecessors for jobs, 6-13 for jobsets, 6-11 profiles, 6-4 triggers as, 6-20 Predictive scheduling, 6-5 Printer definitions, 9-4 Priority levels in escalation policies, 7-6 of jobs, 6-26 Problem Management archiving problems, 7-10 categories predefined, 7-3 setting up, 7-3 types, 7-3 user-defined, 7-3 closing problems, 7-10 configuration, 7-1 defining message action, 7-8 message record, 7-8 description, 1-20 escalation policies aging interval, 7-5 cycle time, 7-5, 7-6 priority levels, 7-6 setting up, 7-5 tables, 7-6 machine generated problems, 7-7 MGPT cycle time, 7-9 overview, 7-7 tables, 7-8
new problems, 7-7 overview, 7-1 policies overview, 7-3 predefined categories, 7-3 user-defined categories, 7-3 problems, oplog, 7-10 responsibility areas predefined, 7-4 setting up, 7-4 status codes predefined, 7-3 setting up, 7-3 user-defined, 7-4 tasks automatically open problems, 7-7 establish basic policies, 7-3 establish escalation policies, 7-5 establish the configuration, 7-1 open new problems, 7-7 track problems, 7-10 tracking problems, 7-10 Profiles, 6-19 Properties class-level, 2-10 inheritance rules, 2-11 instance-level, 2-10 Purging history records, 6-30
R
RACF UPS/CPF interface, minimum requirements, 13-69 Range field in escalation tables, 7-6 Recipient profiles, 8-1 Reclassifying objects during discovery, 2-12 Relation box in escalation tables, 7-8 Remote hosts, routing messages to, 5-7 Remote PING, 3-16 Removable drive support, 12-60 configuring device groups, 12-61 enabling, 12-60 formatting media, 12-61
Index14
Administrator Guide
Report Management bundle status, 8-1, 8-4 bundleb command, 8-5 description, 1-21 profiles page selection, 8-1 recipient, 8-1, 8-3 report, 8-1 tasks decide which reports to manage, 8-2 identify report profile/recipient, 8-3 select the right pages, 8-2 track report bundles, 8-4 report.vars shell script, 11-29 Reporter Server, 10-6 Reports accessing report information, 10-4 BrightStor ARCserve Backup, 12-76 File Management, 12-76 Security Management, 13-87 Simulation, 6-22 Tape Management, 11-30 Workload Management, 6-23 Reports Administrator, 10-6 Reports Builder accessing report information, 10-4 adding calculations, 10-4 data selection, 10-3 filtering data, 10-4 overview, 10-1 Reports Manager, 12-80 Repository Bridge architecture, E-3 configuration, E-10 control, E-8 examples, E-18 overview, E-2 troubleshooting, E-20 using, E-7 Repository Import/Export. See trix Repository Monitor, 3-17 Repository, Common Object. See Common Object Repository Resolution states MOM alerts, G-5 Resources evaluated, 6-26
for jobs, 6-14 for jobsets, 6-10 profiles, 6-4, 6-7 requirements, 6-7 Responsibility area codes predefined, 7-4 Restore BrightStor ARCserve Backup database (UNIX/Linux), 12-28 BrightStor ARCserve Backup database (Windows), 12-26 BrightStor ARCserve Backup host (UNIX/Linux), 12-27 BrightStor ARCserve Backup host (Windows), 12-25 destination options, 12-22 file conflict resolution, 12-23 merge media, 12-23 methods, 12-20 specifying destination, 12-22 Restore Wizard, BrightStor ARCserve Backup, 12-6 Restricting message actions, 5-8 Retention period, 12-70 Retry options, 12-47 File Sharing, 12-48 Open File retry, 12-47 Return codes in Wireless Messaging policy, 5-26 Rexec Proxy, options, 13-86 Rotation Job Report, BrightStor ARCserve Backup, 12-82 Rotation scheme, GFS, 12-67 customizing, 12-71 media names, 12-68 pool names, 12-69 Rotation scheme, simple, 12-66 example, 12-72 Routing messages to remote hosts, 5-7
S
SAN discovery, 2-14 schdcheck shell script, 6-23 schdchk command, 6-23
Index15
schdfore command, 6-23 schdfore shell script, 6-23 schdhist command, 6-23 schdhist shell script, 6-23, 6-30 schdlcs log, 6-28 schdmtr log, 6-28 schdpxr shell script, 6-23 schdsimu command, 6-23 schdsimu shell script, 6-23 schdtrk log, 6-28 Scheduling work across platforms, 6-33 scputil utility, Data Scoping, 2-54 Scroll modes, Event Console, 5-32 Secure Sockets Facility ccicrypt utility, H-15 compability with previous CAICCI versions, H-11 encryption utility, H-15 user functions enum_cert_info function, H-20 security. See also CAICCI Security command messaging, 5-25 enhancements for Event Management, 5-42 Security Management /etc/group file, updating, 13-83 /etc/passwd file, updating, 13-83 access date and time controls, 13-46 DENY type, 13-44 LOG type, 13-44 modes, 13-46 permissions, defining, 13-56 PERMIT type, 13-44 types, definition, 13-44 violations, 13-87 asset access permissions, defining, 13-44 description, 13-3 group, adding new, 13-44 groups, defining, 13-42 groups, nested, 13-43 name, ambiguous, 13-48 name, concatenating, 13-48 name, defining, 13-43, 13-47
name, exclusion processing, 13-48 name, writing rules, 13-49 type, CA-JOBAUTHORITY, 13-52 type, defining, 13-42 type, UNIX-FILE, 13-50 type, UNIX-SETUID, 13-51 type, WNT-FILE, 13-49 asset name ambiguous, 13-48 concatenating, 13-48 defining, 13-43, 13-47 exclusion processing, 13-48 regular expression, 13-47 rules, writing, 13-49 wildcard masking, 13-47 asset type CA-JOBAUTHORITY, 13-52 defining, 13-42 UNIX-FILE, 13-50 UNIX-SETUID, 13-51 WNT-FILE, 13-49 assets access modes, 13-46 access types, definition, 13-44 CONTROL access mode, 13-47 CREATE access mode, 13-46 DELETE access mode, 13-47 EXECUTE access mode, 13-47 protecting, 13-45 READ access mode, 13-46 SEARCH access mode, 13-47 UPDATE access mode, 13-46 WRITE access mode, 13-46 audit support, remote, 13-19 Authorized User List, 13-12 backup domain controller support options, 13-82 restoring to new PDC, 13-82 backup domain controller support, description, 13-82 CA-JOBAUTHORITY asset type, 13-52 Cancel & Logout Enforcement action, 13-38 Cancel Enforcement action, 13-38 Cancel, Logout, & Suspend Enforcement action, 13-38 CANU&LOG user default violation action, 13-12 CANU&LOG&SUS user default violation action, 13-12 CANUSER user default violation action, 13-12 CASFEXIT.DLL, 13-83 cautenv command, 13-73 Command Propagation Facility (CPF), 13-62
Index16
Administrator Guide
commit process considerations, 13-5 description, 13-3 executing for production, FAIL mode, 13-61 executing the initial, QUIET mode, 13-35 requirements, 13-5 using the GUI, 13-61 Common Communication Interface (CAICCI), 13-63 daemons, starting, 13-36 Database Synchronization (DBS) configuring, 13-79 options, 13-75 overview, 13-74 restrictions, 13-74 starting, 13-80 station group, defining, 13-81 database, populating, 13-34 Decision Support Binary (DSB), 13-35 description, 13-4 dynamic update, 13-13 defining asset groups, 13-42 asset name, 13-43, 13-47 asset type, 13-42 user, 13-37 user groups, 13-40 DENY access type, 13-44 description, 1-20 Distributed Computing Environment (DCE) keytab file, creating, 13-72 options, 13-72 overview, 13-71 starting for UNIX/Linux, 13-73 starting for Windows, 13-73 EmSec_PwExit() password validation exit, 13-30 Enforcement action Cancel, 13-38 Cancel & Logout, 13-38 Cancel, Logout, & Suspend, 13-38 overview, 13-10 user, 13-38 Enforcement mode overview, 13-10 user, 13-38 eTrust CA-ACF2, synchronizing database with, 13-62 eTrust CA-Top Secret, synchronizing database with, 13-62 FAIL mode, definition, 13-9, 13-11 FTP Proxy, 13-85 guest ID support, 13-20 implementation, overview, 13-6
intercepts, activating UNIX/Linux platform, 13-60 Windows, 13-60 Local/remote SSF support, 13-14 LOG access type, 13-44 logon intercept, Windows, 13-60 messages access violations, 13-87 login/logout, 13-88 MONITOR mode, definition, 13-9, 13-11 Network Information Service (NIS) support, 13-26 NIS. See Network Information Service node specification, user, 13-37 node support, UNIX/Linux, 13-23 objects, description, 13-3 optional features, 13-62 options Accept Remote Dynamic Update for DSB/SAM, 13-16 ACCEPT_DBS_STATGROUP, 13-77 Authorized User List, 13-12, 13-36 automatic startup, 13-22 CALL_PREPOST_FOR_NIS, 13-28 CPF Target Systems, 13-67 CPF_TARGETS, 13-67 customizing, 13-7 DBS_ADMINDATALEVEL, 13-77 DBS_AUDITDATALEVEL, 13-76 DBS_STATGROUP, 13-76 Default Permission, 13-8 DEFAULT_PERMISSION, 13-8 DELETE_NIS_FROM_PASSWD, 13-27 DSB Search Order, 13-17 Dynamic Group Update for DSB/SAM, 13-14 Dynamic Update for DSB/SAM, 13-13, 13-75 ENABLE_ANONYMOUS_FTP, 13-86 ENABLE_FTP_PROXY, 13-85 ENABLE_REXEC_PROXY, 13-86 FTP_SERVER_PORT, 13-86 Guest Logon Options, 13-20 Guest User ID, 13-20 Implicit DENY Permission for Rules, 13-45 Local Evaluation Server List, 13-14 LOCAL_EVAL_SERVER_LIST, 13-14 Logon Intercept Setting, 13-20 Maintain passwords in Unicenter, 13-21 PSWDADMINBYPASS, 13-30 PSWDVALEXIT, 13-30 PSWDVALEXIT_TIMEOUT, 13-31 Remote Audit Receive Setting, 13-19 Remote Audit Send Setting, 13-19
Index17
REXEC_COUNTASLOGIN, 13-87 Rule Server for Rule Processing, 13-22 SEC_EVALORDER, 13-25 SEC_GLOBAL_AND_LOCAL, 13-25 SETUID_SWITCH_ID, 13-32 SSF Command Scope Option, 13-58 SSF Data Scope Option, 13-58 SSF Keyword Scope Option, 13-58 SSF Scoping, 13-57 SSF_AUTH, 13-13, 13-36 SU_SWITCH_ID, 13-32 SYNC_ALTER, 13-75 SYNC_DB_DSB_FROM_MON, 13-79 SYNC_DEFINE, 13-76 SYNC_DELETE, 13-76 System Violation Mode, 13-9, 13-11 SYSTEM_MODE, 13-9 UPDATE_EXTERNAL, 13-13, 13-75 UPDATE_PASSWD_FOR_NIS, 13-27 UPS Database Sync - Accept Alter Transactions, 13-75 UPS Database Sync - Accept Define Transactions, 13-76 UPS Database Sync - Accept Delete Transactions, 13-76 UPS Database Sync - Admin Data Level, 13-77 UPS Database Sync - Auditing Data Level, 13-76 UPS Database Sync - Global Station Group, 13-76 UPS Database Sync - Proxies route via Global DBS Station Group, 13-79 UPS_CHECKOLDPASSWORDS, 13-66 UPS_DCEADMIN, 13-72 UPS_DCEGATEWAY, 13-72 UPS_DCEKEY, 13-72 UPS_LOGONASUSER, 13-65 UPS_LOGONUSER, 13-65 UPS_LOGOPTION, 13-64, 13-78 UPS_MASTER, 13-65, 13-78 UPS_PROXYROUTE, 13-67 UPS_STOREINTERVAL, 13-66, 13-78 USE_PAT, 13-10 User Default Violation Action, 13-10 User Default Violation Mode, 13-10 User Group Server for Rule Processing, 13-22 User Profile Sync - Check Old Passwords, 13-66 User Profile Sync Days to Store and Forward, 13-66, 13-78 User Profile Sync - Logging Options, 13-64, 13-78
User Profile Sync - Logon As User, 13-65 User Profile Sync - Master Node, 13-65, 13-78 User Profile Sync - Password Change Case, 13-67 User Profile Sync Proxies Route via User Profile's UPS Station Group, 13-67 User Profile Sync - SSF User for UPS, 13-65 User Profile Sync UPS Station Group, 13-66 USER_UPSSTAT, 13-66 USER_VIOLACTION, 13-10 USER_VIOLMODE, 13-10 password bypassing restrictions, 13-30 controls, 13-38 processing, description, 13-30 timeout specification, 13-31 user, 13-37 validation exit, 13-30 violation, 13-39 Password Change Notification CASAMAUD -All, 13-84 CASAMAUD -Deinstall, 13-84 CASAMAUD -filename, 13-84 CASAMAUD -Install, 13-84 CASAMAUD -Status, 13-84 Password Change Notification (PCN), 13-84 PDSADMIN command, 13-82 PERMIT access type, 13-44 policies, defining for production, 13-37 production rules, defining, 13-37 QUIET mode, definition, 13-9, 13-11 RACF, synchronizing database with, 13-62 regular expression, asset name, 13-47 reports access violations, 13-87 overview, 13-87 what-has, 13-90 whohas, 13-88 Rexec Proxy, overview, 13-86 rule server, 13-22 secadmin command option i, 13-73 option s, 13-73 setuid, secure operation, 13-32 SSF Scoping, 13-57 defining rules, 13-59 startup, automatic, 13-22 su command, secure target user, 13-32 support for Windows NT/SAM, 13-21 suspended user, 13-61 SYSTEM mode, definition, 13-11
Index18
Administrator Guide
tasks create rules for production, WARN mode, 13-37 customize options, 13-7 deactivate Security Management, 13-61 define access permissions, 13-56 execute initial commit, QUIET mode, 13-35 populate the database, QUIET mode, 13-34 reactivate a suspended user ID, 13-61 review Security Management options, 13-7 set options for production, FAIL mode, 13-60 start daemons, 13-36 trusted domain support, 13-17 UNIX-FILE asset type, 13-50 UNIX-SETUID asset type, 13-51 user access permissions, defining, 13-56 asset access permissions, defining, 13-44 defining, 13-37 Enforcement action, 13-38 Enforcement mode, 13-38 groups, defining, 13-40 groups, nested, 13-41 ID, 13-37 node specification, 13-37 password, 13-37 permitting to assets, 13-57 user groups server, 13-22 user ID, 13-37 User Profile Synchronization (UPS) configuring, 13-63 mapping user IDs for events, 13-68 options, 13-64 overview, 13-62 restrictions, 13-63 USERORIGIN keyword, 13-27 WARN mode, definition, 13-9, 13-11 wildcard masking, asset name, 13-47 Windows dynamic update, 13-13, 13-14 dynamic update, remote, 13-16 user exits, 13-83 Windows NT/SAM updating, 13-39 WINLOGON logon support, 13-20 WINLOGON.EXE, 13-60 WNT-FILE asset type, 13-49 Servers, 6-2 Shares administrative, 12-10 user specified, 12-10 Sharing calendars, 5-2
Shell scripts cadb unidbbackup, 6-30 Tape Management ca_prt_label, 11-8 report.vars, 11-29 smplmntscratch, 11-13 tms_daily, 11-29 tms_db_backup, 11-29 tms_options, 11-8, 11-33 tms_report, 11-29 tms_scratch, 11-29 Vault Management prev_vreport, 11-32 Workload Management cleanlog, 6-28 schdcheck, 6-23 schdfore, 6-23 schdhist, 6-23, 6-30 schdpxr, 6-23 schdsimu, 6-23 wmmodel, 6-23 Simple Network Management Protocol. See SNMP Simulation reports, 6-22 Single Document Interface, 2-20 Single node configuration, 6-32 SNMP cabldcomp, 7-2 cadiscvr, 7-2 catrapd, 5-4 trap messages, MGPT, 7-8 traps, 5-34 SNMP Administrator, 3-18 Software Development Kit (SDK), 1-22 Special event scheduling, 6-19 Spool Management controlling data flow, 9-4 description, 1-21 implementation, 9-2 stopping and starting spooler, 9-2 verifying implementation, 9-4 SQL server support, BrightStor ARCserve Backup, 12-76 SSF support, 13-14 options, 13-14 return codes, 13-15 State change, correlating, 3-20
Index19
States agents, 3-4 DSM, 3-4 Neugents, 3-4 overview, 3-3 WorldView, 3-4 Station groups profile, 6-4 Stations profiles, 6-4 types, 6-6 Status codes of problems predefined, 7-3 user-defined, 7-4 network, 3-21 verifying connectivity, 3-22 verifying for agents, 3-19 viewing 2D Map, 2-32 3D Map, 2-32 Storage Device Report, BrightStor ARCserve Backup, 12-81 Submit process as another user, 5-43, 6-30 Submitting jobs, 6-14 Summary page, 8-2 syncdhcp command, 2-4 syslog daemon, 5-7 System account, changing, 12-91
T
Tape Log, viewing, 12-79 Tape Management ABE option, 11-33 ANSI labels, 11-3 asmdmp command, 11-5 automatic volume recognition (AVR) defining devices for, 11-13 description, 11-13 using for input, 11-15 using for output, 11-14, 11-15 AVR \t, 11-13 ca_prt_label shell script, 11-8 cainit command, 11-3 catape mount command, 11-9
CDAY option, 11-33 CJOB option, 11-33 commands asmdmp, 11-5 cainit, 11-2 catape create volume, 11-2 catape dbscratch, 11-30 catape mount, 11-9 enfcontrol 378, 11-17, 11-18 enfcontrol 379, 11-17, 11-18 enfcontrol 524, 11-7 enfcontrol 525, 11-7 enfcontrol 862, 11-17, 11-18 enfcontrol 863, 11-17, 11-19 enfcontrol 864, 11-17 tapeavr_status, 11-15 COMPANY option, 11-33 CUSER option, 11-33 CYCLE/nn retention value, 11-35 DATEFMT option, 11-33 DCHG option, 11-33 description, 1-18, 1-19 device status, displaying, 11-15 device table (devtab file), 11-13, 11-14, 11-15 devices assigning, 11-12 automatic assignment of, 11-14 defining for AVR, 11-13 operator assignment of, 11-13 reserving, 11-16 end-of-volume assistance (TEOV), 11-6 enfcontrol 610 command, 11-6 examples enfcontrol 863 command, 11-20 input processing, 11-10 output processing, 11-9 reading from tapes, 11-10 file retention, 11-12 GUMLABEL option, 11-8, 11-34 HDR1 tape label, 11-3 HDR2 tape label, 11-3 internal tape labels, 11-3 KEYTAPE option, 11-34 labels external, 11-8 internal, 11-5 LCHG option, 11-34 LDATE/nnn retention value, 11-35 MIXEXP option, 11-34 options ABE, 11-33 CDAY, 11-33 CJOB, 11-33
Index20
Administrator Guide
COMPANY, 11-33 CUSER, 11-33 customizing options, 11-33 DATEFMT, 11-33 DCHG, 11-33 GUMLABEL, 11-8, 11-34 KEYTAPE, 11-34 LCHG, 11-34 MIXEXP, 11-34 RCYCDAYS, 11-34 retention values for, 11-35 RPERIOD, 11-34 overview, 11-1 PERM retention value, 11-35 RCYCDAYS option, 11-34 report.vars shell script, 11-29 reports Clean List, 11-31 description, 11-30 Erase List, 11-31 generating auxiliary, 11-31 Pull List, 11-31 Replace List, 11-31 resident tape, defining, 11-2 restore multivolume, 11-6 retention values, 11-35 RETPD/nnn retention value, 11-35 RETPY/nnn retention value, 11-35 RPERIOD option, 11-34 smplmntscratch shell script, 11-13 surrogate tapes, 11-17 disabling mounts, 11-18 enabling mounts, 11-18 operator verification, 11-19 retaining status, 11-18 tapeavr_status command, 11-15 tasks access a resident tape, 11-9 assign tape devices, 11-12 change system options, 11-33 define devices for AVR, 11-13 define tape volumes, 11-2 establish vault storage system, 11-23 implement surrogate tape processing, 11-17 initialize tape volumes, 11-3 process unlabeled tapes, 11-21 regulate trusted offenders, 11-20 report on tape activity, 11-30 TEOV (Transparent End-of-Volume), 11-6 tms_daily shell script, 11-29 tms_db_backup shell script, 11-29 tms_options shell script, 11-8, 11-33 tms_report shell script, 11-29
tms_scratch shell script, 11-29 trusted offenders, 11-20 unlabeled tapes, 11-8, 11-21 accessing, 11-22 enabling, 11-21 use count field, 11-5 Vault Management, overview, 11-1 vault, creating, 11-24 VOL1 tape label, 11-3 volume reinitialization, 11-4 scratch, 11-3 volume initialization, 11-3 Tape Management mode activating, 12-62 volume serial number, 12-61 Time controls calendar, 5-2 user access, 13-46 workload, 6-8, 6-13, 6-17 tms_daily shell script, 11-29 tms_db_backup shell script, 11-29 tms_options shell script, 11-8 tms_report shell script, 11-29 tms_scratch shell script, 11-29 TNDUser group, 2-52 Topology Browser, definition of, 2-19 Totals page, 8-2 Tracking components, 7-1 file, 6-24, 6-29 problems, 7-1, 7-10 Trap daemon, 5-35 Trap important messages, 5-3 Trigger profiles as predecessors, 6-20 scheduling by, 6-5, 6-19 types of, 6-19 trix definition of, 2-45 Export Repository dialog, 2-47 exporting objects, 2-46 Import Repository dialog, 2-47 importing objects, 2-47
Index21
trix window for exporting, 2-46 for importing, 2-47
User-defined functions, exits for, 5-42
V U
Uncienter Classic, 1-9 Unclassified objects, 2-11 Unicenter agents, 3-2 Controller, 2-43 Neugents, 3-2 Tape Management mode, 12-61, 12-62 Unicenter Alert container, G-4, G-8 Unicenter Browser, 1-8 Unicenter Explorer Association Browser, 2-32 billboards, 2-27, 2-30 bookmarks, 2-26, 2-44 class hierarchy, 2-40 description, 2-17 geomaps, 2-25 historian, 2-44 Unicenter Management for Microsoft Operations Manager (MOM), G-1 Unicenter Reports, 10-1 Unicenter Resolver Alert - Detail window, G-9 unicntrl command, 6-39 unidbbackup shell script, 6-30 unishutdown command, 6-39 Unispace, 2-20 unistart command, 6-39 UPS/Command Propagation Facility (CPF) configuring, 13-70 minimum requirements, 13-69 overview, 13-69 user interfaces, 1-8 User Profile Synchronization (UPS) mapping user IDs for events, 13-68 options, 13-64 overview, 13-62 restrictions, 13-63 Vault Management .rdw files, 11-32 audit trail, 11-28 CYCLE VAULT command, 11-28 daily processing, customize, 11-29 Inventory report, 11-26 inventory tracking, 11-26 media scheduled movement, 11-25 selection, 11-24, 11-28 special movement, 11-25 overview, 11-23 prev_vreport shell script, 11-32 Receiving report, 11-26 report.vars shell script, 11-29 reports Inventory, 11-26 Receiving, 11-26 Shipping, 11-26 shell scripts, 11-29, 11-32 Shipping report, 11-26 slot maintenance, description, 11-29 tasks customize daily processing, 11-29 maintain slot integrity, 11-29 move volumes, 11-28 schedule volume movement, 11-28 select the media, 11-28 terminology, 11-23 tms_daily shell script, 11-29 tms_db_backup shell script, 11-29 tms_report shell script, 11-29 tms_scratch shell script, 11-29 Vault Criteria Descriptor (VCD), 11-28 vault, creating, 11-24 VCD. See Vault Criteria Descriptor volumes permanent movement, 11-25 physical movement, 11-26 scheduled movement, 11-28 temporary movement, 11-25 verifyCert function, H-18 Viewing Agent Technology, 3-7 agents, 3-9 DSM properties, 3-10
Index22
Administrator Guide
events, 3-11 multiple console logs, 5-33 nodes, 3-14 objects with Business Process View, 2-37 sequence of events, 3-19 Virus scanning options, BrightStor ARCserve Backup, 12-51 utility, B-1 VOL1 tape label, 11-11
W
Warn threshold, MGPT, 7-9 WBEM data in ObjectView, 2-34 Web-Based Enterprise Management (WBEM), G-1 what-has report, 13-90 whohas report, 13-88 Windows , updating, 13-83 Windows Management Instrumentation (WMI), G-2 WINLOGON.EXE, 13-60 Wireless Messaging address database, administering, 5-28 capagecl, 5-23 configuration file format, 5-23 supplying information, 5-27 Configuration files, 5-22 databases, maintaining, 5-28 environment variables, 5-25 error messages, 5-30 implementing, 5-20 message files, 5-21 Message set creating, 5-28 editing, 5-28 messages command messaging, 5-25 command messaging security, 5-25 responding to, 5-24 sending, 5-23 sending a one-way, 5-24 sending a two-way, 5-24 policy descriptions, 5-26 generating, 5-29 triggering, 5-26
policy overview, 5-20 recepients, defining multiple, 5-28 Reply Information Configuration file, 5-22 reply text format, 5-21 return codes abort (96), 5-23 assignment, 5-22 calendar reject (03), 5-23 client timeout (99), 5-23 reply unrecognized (98), 5-23 reserved, 5-23 trapping, 5-27 script files, troubleshooting, 5-30 server, 5-23 simple notification, 5-26 template files building, 5-26 damaged, 5-30 description, 5-27 supplied, 5-27 troubleshooting, 5-29 two-way messaging, 5-27 Wireless Messaging Policy Writer, 5-29 wmmodel command, 6-23 wmmodel shell script, 6-23 Workload balancing, 6-7 database, 6-30 logs, 6-28 objects, 6-4 processing, 6-26 testing, 6-22 Workload Management agent/server, 6-2 autoscan, 6-24 caevent command, 6-19, 6-20 calendars default, 6-8 event-based scheduling, 6-5 expanded processing, 6-8 job scheduling, 6-5 profile, 6-4 CPU station, 6-6 cross-platform scheduling, 6-33 database, 6-30 description, 1-18 dump database to text file, 6-30 early start time, 6-5 environment variables Default calendar, 6-8 for jobs and actions, 6-40
Index23
event-based scheduling, 6-5 job tracker, 6-2 jobs calendars, 6-5 cyclic, 6-17 early start time, 6-13 expanded calendar processing, 6-8 in jobset, 6-13 introduction, 6-13 on demand, 6-21 predecessors, 6-13 profile, 6-4 resources, 6-14 running on demand, 6-21 scheduling, 6-5 submission, 6-14 jobsets amount, 6-10 COREQ, 6-10 expanded calendar processing, 6-8 introduction, 6-10 predecessors, 6-11 PRIVATE, 6-10 profile, 6-4 resource requirements, 6-10 SHARED, 6-10 usage, 6-10 weight, 6-10 maintenance, 6-28 maximum time, 6-5 monitor, 6-2 must complete time, 6-5 must start time, 6-5 non-CPU tasks, 6-6 objects, 6-4 POSTCPU station, 6-6 PRECPU station, 6-6 predecessors profile, 6-4 processes, 6-2 profiles calendar, 6-4 job, 6-4 jobset, 6-4 predecessor, 6-4 resource, 6-4 station, 6-4 station groups, 6-4 remote submission/tracking agents, 6-2 reports, 6-23 resource profile, 6-4 resource requirements, 6-7 single node configuration, 6-32 station groups profile, 6-4
stations profile, 6-4 types, 6-6 submitting process as another user, 6-30 tasks clear undefined calendars, 6-29 form groups of related tasks (jobsets), 6-10 identify resource requirements, 6-7 identify work to perform, 6-13 maintenance, 6-29 monitor workload status, 6-41 perform maintenance, 6-28 run a job on demand, 6-21 run simulation reports, 6-22 schedule work by dates, 6-8 schedule work by special events, 6-19 specify where to perform work, 6-6 tracking file, 6-24 trigger as predecessors, 6-20 caevent, 6-20 profile, 6-19 types, 6-19 WorldView 2D Map, 2-20 3D Map, 2-28 Agent Technology configuration, 3-6 Auto Discovery, 2-1 concepts, 2-18 description, 1-10 Desktop Management Interface (DMI), F-1 Dynamic Containment Service, 2-36 entity, 2-18 folder, 2-18 managed objects, 2-19 map-only objects, 2-19 repository Data Scoping, 2-48 states, 3-4 tasks discover IT infrastructure, 2-3 maintain Common Object Repository, 2-46 modify class hierarchy, 2-39 view managed objects, 2-20 terminology, 2-18 Topology Browser, 2-19 unispace, 2-20 WorldView objects, 2-19 WorldView Classic, 1-9 WTOR messages, 5-17
Index24
Administrator Guide

NSMADMG

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NSMADMG

Загружено:

Авторское право:

Доступные форматы

Unicenter Network and Systems Management

2003 Computer Associates International, Inc.

Chapter 1: Managing Your eBusiness Infrastructure

Chapter 2: Advanced Visualization

Chapter 3: Agent Technology

Chapter 4: Performance Management

Chapter 5: Event Management

Chapter 6: Workload Management

Chapter 7: Problem Management

Chapter 8: Report Management

Chapter 9: Spool Management

Chapter 10: Unicenter Reports

Chapter 11: Tape Management

Chapter 12: Storage Management

Chapter 13: Security Management

Appendix B: Virus Scan

Appendix C: Advanced Event Correlation

Appendix D: Migration Tools

Appendix E: Repository Bridging

Appendix F: Desktop Management Interface (DMI)

Appendix G: Unicenter Management for Microsoft Operations Manager

Managing Your eBusiness Infrastructure

Managing Your eBusiness Infrastructure

The Unicenter NSM SolutionIntegration and Innovation

The Unicenter NSM SolutionIntegration and Innovation

The Unicenter NSM SolutionIntegration and Innovation

Welcome to Unicenter Network and Systems Management

Managing Your eBusiness Infrastructure

The Unicenter NSM SolutionIntegration and Innovation

Managing the Extended Enterprise

The Unicenter NSM SolutionIntegration and Innovation

Managing Your eBusiness Infrastructure

The Unicenter NSM SolutionIntegration and Innovation

The Unicenter NSM SolutionIntegration and Innovation

Managing Your eBusiness Infrastructure

The Unicenter NSM SolutionIntegration and Innovation

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Performance Configuration Performance Scope Performance Trend Performance Chargeback

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

Unicenter NSM Infrastructure Solutions

Managing Your eBusiness Infrastructure

Unicenter NSM Infrastructure Solutions

The Software Development Kit

Documentation Road Map

Documentation Road Map

Managing Your eBusiness Infrastructure