Unicenter Network and Systems Management ® Implementation Guide r11.2 This documentation and any related computer software help programs (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and 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 the Documentation for their own internal use, and may make one copy of the related software as reasonably required for back-up and disaster recovery purposes, 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 provisions of the license for the Product are permitted to have access to such copies. The right to print copies of the Documentation and to make a copy of the related software is limited to the period during which the applicable license for the Product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, 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 the Documentation is governed by the end user’s applicable license agreement. The manufacturer of this Documentation is CA. Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.2277014(b)(3), as applicable, or their successors. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies. Copyright © 2008 CA. All rights reserved. CA Product References This document references the following CA components and products: ■ BrightStor® Backup for Unicenter ■ BrightStor® SAN Manager ■ Business Process View™ Management ■ CA Cohesion® Server ■ CA SPECTRUM® Network Fault Manager ■ CA SPECTRUM® OneClick ■ Distributed Intelligence Architecture (DIA) ■ Distributed State Machine Wizard (Unicenter DSM Wizard) ■ eHealth® Suite ■ eTrust® Access Control (eTrust AC) ■ eTrust® Security Command Center (eTrust SCC) ■ Job Management Option ■ Smart Business Process View (SmartBPV) ■ Unicenter® Adaptive Dashboard Services™ (ADS) ■ Unicenter® Advanced Systems Management (Unicenter ASM) ■ Unicenter® CA-7® Job Management (Unicenter CA-7) ■ Unicenter® CA-Jobtrac® Job Management (Unicenter CA-Jobtrac) ■ Unicenter® CA-Scheduler® Job Management (Unicenter CA-Scheduler) ■ Unicenter® Cisco Integration ■ Unicenter® Management Command Center (Unicenter MCC) ■ Unicenter® Management Portal (Unicenter MP) ■ Unicenter® Network and Systems Management (Unicenter NSM) ■ Unicenter Remote Control ■ Unicenter Remote Monitoring ■ Unicenter® Service Desk ■ Unicenter® Systems Command Center (Unicenter SCC) ■ Unicenter® Service Desk Knowledge Tools (Unicenter SDKT) ■ Unicenter Software Delivery ■ Unicenter® Trap Manager ■ Unicenter® Web Reporting Server™ (WRS) ■ WorldView Contact CA Contact Technical Support For online technical assistance and a complete list of locations, primary service hours, and telephone numbers, contact Technical Support at http://ca.com/support. Provide Feedback If you have comments or questions about CA product documentation, you can send a message to [email protected] If you would like to provide feedback about CA product documentation, please complete our short customer survey, which is also available on the CA Support website. Contents Chapter 1: Overview 15 Introduction .................................................................................. 15 Unicenter NSM ............................................................................... 15 Product Components .......................................................................... 17 Management Command Center Overview ................................................... 17 Agent Technology ......................................................................... 17 Event Management ....................................................................... 18 Unicenter Systems Performance ........................................................... 18 Active Directory Monitoring (Windows) ..................................................... 18 Discovery ................................................................................ 18 Notification Services ...................................................................... 19 Alert Management System................................................................. 19 Advanced Event Correlation ............................................................... 20 Adaptive Configuration .................................................................... 20 TrapManager ............................................................................. 20 Unicenter Browser Interface ............................................................... 21 Unicenter Configuration Manager .......................................................... 21 Unicenter Management Portal .............................................................. 21 Unicenter Software Development Kit (SDK) ................................................. 21 Web Reports and Dashboards .............................................................. 21 Online Books ............................................................................. 22 Management Database .................................................................... 22 Unicenter for Pocket PC ................................................................... 22 Unicenter Management for Microsoft Operations Manager.................................... 23 Integration with System Center Operations Manager ........................................ 23 Unicenter Cisco Integration ................................................................ 24 Unicenter Remote Monitoring .............................................................. 24 Business Process View Management (Windows) ............................................. 25 Data Scoping ............................................................................. 26 Unicenter Windows Management Instrumentation Agent ..................................... 26 Documentation ............................................................................... 26 Unicenter NSM Databases ................................................................. 27 Readme Files ............................................................................. 27 Release Notes ............................................................................ 27 Related Publications ....................................................................... 28 Contents 5 Chapter 2: System Requirements 33 Hardware Requirements ...................................................................... 33 Enterprise Manager Configuration .......................................................... 34 Infrastructure Server Configuration (Windows only) ......................................... 34 Management Command Center Configuration ............................................... 34 Managed Node Configuration .............................................................. 35 GUI Configurations ........................................................................ 35 Database Requirements ....................................................................... 36 Windows ................................................................................. 36 Web Environment Support .................................................................... 37 Supported Web Browsers .................................................................. 37 Supported Web Servers and Servlet Environments .......................................... 37 Java Browser Support ......................................................................... 37 Adobe Acrobat Reader Support ................................................................ 38 Unicenter NSM Agent Requirements ........................................................... 38 Unicenter Remote Monitoring Requirements .................................................... 38 Unicenter Management for Microsoft Operations Manager Requirements .......................... 39 CA System Center Operations Manager Integration ............................................. 39 CA High Availability Service (HAS) Requirements ............................................... 40 Windows: ................................................................................ 40 UNIX ..................................................................................... 40 Unicenter Cisco Integration Requirements ...................................................... 40 Unicenter for Pocket PC Requirements ......................................................... 41 Systems Performance Requirements ........................................................... 41 Chapter 3: Product Architecture 43 Implementation Layers ....................................................................... 43 Visualization .............................................................................. 43 MDB ..................................................................................... 44 Managers ................................................................................ 45 Monitoring Technology .................................................................... 51 Unicenter Systems Performance ............................................................... 59 Distributed Intelligence Architecture ........................................................... 60 Classic Versus Continuous Discovery ........................................................... 60 Deployment of Discovery Managers ........................................................ 61 Deployment of Discovery Agents ........................................................... 61 Chapter 4: Architecture Considerations 63 Introduction .................................................................................. 63 Current Environment ......................................................................... 63 6 Implementation Guide Hardware and Software ................................................................... 63 Network Considerations ................................................................... 64 Operational Standards and Restrictions ..................................................... 65 Evolution of the Environment .................................................................. 66 Business Needs ............................................................................... 67 Unicenter NSM Requirements .................................................................. 68 Chapter 5: Installation Preparation 69 Installation Methods .......................................................................... 69 Unicenter NSM Product Explorer - Windows ................................................. 69 setupNSM - Linux/UNIX ................................................................... 70 Unattended Installation ................................................................... 70 Unicenter Software Delivery ............................................................... 71 Start Menu and Installations ............................................................... 71 Common Unicenter NSM Server Categories ..................................................... 72 Managed Server .......................................................................... 72 Unicenter NSM Monitoring Manager ........................................................ 73 Unicenter NSM Reporting and Configuration Manager........................................ 76 MDB Server .............................................................................. 76 Visualization Server ....................................................................... 77 Pre-Installation Tasks ......................................................................... 78 Windows ................................................................................. 78 Linux and UNIX ........................................................................... 79 DIA Configuration ......................................................................... 79 Distributed State Machine (DSM) .......................................................... 80 Monitoring for z/OS ....................................................................... 82 Unicenter Systems Performance ........................................................... 87 Unicenter for Pocket PC ................................................................... 87 Unicenter Management for MOM ........................................................... 88 CA System Center Operations Manager Integration ......................................... 90 Unicenter Remote Monitoring .............................................................. 92 Highly Available Installations .............................................................. 93 Other Software Considerations ............................................................. 93 Chapter 6: Installation 95 Installation Overview ......................................................................... 95 Operating System Dependencies ........................................................... 96 Maximum Operating System PATH Lengths ................................................. 96 Special Character Support ................................................................. 97 Other Installed Software .................................................................. 98 Microsoft SQL Server Considerations ....................................................... 99 Contents 7 Microsoft SQL Server Browser Service ..................................................... 101 IPv6 Support Over MDAC ................................................................. 102 Reserved Database User Names .......................................................... 102 Database Configuration Considerations .................................................... 103 Security Considerations .................................................................. 105 Warning Messages During Installation ..................................................... 106 System Restarts During Installation (Windows Only) ....................................... 106 Installation Using Unicenter Remote Control ............................................... 107 Migration of Component Data From a Prior Release ........................................ 107 Network Port Conflicts.................................................................... 108 Windows Terminal Services Support ....................................................... 108 High Availability Considerations ........................................................... 110 Response File Must Not Be Read-Only ..................................................... 110 Install Unicenter NSM on Windows ............................................................ 111 Install Unicenter NSM on Linux or UNIX ....................................................... 119 Install CA Common Discovery ................................................................ 133 Platform Support ........................................................................ 134 Tomcat Authentication ................................................................... 134 Install CA Common Discovery............................................................. 135 NSM--Configure CA Common Discovery (CACD) With SSL .................................. 136 Register Unicenter NSM with Unicenter Software Delivery ...................................... 141 Prepare for Registration .................................................................. 142 Run Registration ......................................................................... 144 Deploy Unicenter NSM to Hosts ........................................................... 145 Install Unicenter Systems Performance........................................................ 145 Install Unicenter NSM Systems Performance on Windows ....................................... 146 Install Active Directory Management .......................................................... 147 Platform Support ........................................................................ 147 Software Requirements .................................................................. 147 Install Active Directory Management ...................................................... 149 Active Directory Agent Installation ........................................................ 151 Install Monitoring for z/OS Interface .......................................................... 156 FTP and Load JCL to the Mainframe ....................................................... 156 Install on the Mainframe ................................................................. 157 Download the Installation Library ......................................................... 159 SETVARS Member Modification............................................................ 159 Run the Installation Job .................................................................. 160 Copy the MIB to Agent Technology ........................................................ 160 Load the MIB into the Object Store........................................................ 160 Update the awservices Configuration ...................................................... 161 Update Agent PROCs and Add to System Procedure Library ................................. 161 Agent Load Library APF-Authorization ..................................................... 161 8 Implementation Guide Give the ZOSAGTS and CICAGTS PROCs the Proper Security ................................ 162 Migration of Previous z/OS Agent Installations ............................................. 162 Install Unicenter Management Portal .......................................................... 163 Install Unicenter for Pocket PC................................................................ 164 Installation of Unicenter Management for MOM ................................................ 165 Prerequisites for MOM Management Installation ............................................ 165 Install Unicenter Management for MOM .................................................... 166 Installation of the CA System Center Operations Manager Integration ........................... 167 Prerequisites for the SCOM Integration Installation ......................................... 167 Install the SCOM Integration.............................................................. 168 Install Unicenter Cisco Integration ............................................................ 169 Install TrapManager ......................................................................... 170 Install Unicenter Remote Monitoring .......................................................... 172 Install the Remote Monitoring Agent ...................................................... 172 Install the Administrative Interface Only ................................................... 173 Install the SPECTRUM Integration Kit ......................................................... 174 Discovery of SPECTRUM Server ........................................................... 175 How to Use the Event Agent to Forward SPECTRUM Alarms ................................. 175 Install the SPECTRUM Integration Kit ...................................................... 177 Uninstall Individual Components .............................................................. 187 Uninstall Unicenter NSM .................................................................. 187 Uninstall CA Common Discovery .......................................................... 189 Uninstall Unicenter for Pocket PC ......................................................... 189 Uninstall Unicenter Management for MOM ................................................. 189 Uninstall the Integration with System Center Operations Manager ........................... 190 Uninstall Unicenter Cisco Integration ...................................................... 190 Chapter 7: Post-Installation and Configuration 191 Reghost, Reinstall, Unplug Unicenter NSM Components ........................................ 191 Configure Active Directory Enterprise Manager ................................................ 191 Configure Data Scoping ...................................................................... 192 Configure Data Scoping for Linux and UNIX ................................................ 193 Configure Data Scoping for Windows ...................................................... 194 Create Data Scoping Rules Using the MCC ................................................. 194 Configure and Maintain CAICCI ............................................................... 195 CAICCI Overview ........................................................................ 195 Configure CAICCI on Windows ............................................................ 200 Configure CAICCI on Linux or UNIX ....................................................... 202 Configure CAICCI on HP NonStop ......................................................... 204 Configure CAICCI on OpenVMS ........................................................... 206 Configure CAICCI on OS/400 ............................................................. 210 Configure CAICCI on the Mainframe ....................................................... 214 Contents 9 Troubleshooting CAICCI .................................................................. 217 CCIRMTD Behavior at Startup ............................................................ 218 Configure Remote Monitoring ................................................................. 219 Configure Unicenter Management Portal ....................................................... 220 Configure Unicenter for Pocket PC ............................................................ 220 Configure the Unicenter WMI Agent ........................................................... 221 Configure Monitoring for z/OS Interface ....................................................... 221 Unicenter CA-SYSVIEW Server ............................................................ 222 Start and Stop the Agents ................................................................ 222 Run Unicenter Management for MOM Discovery ................................................ 223 Run CA System Center Operations Manager Discovery ......................................... 224 Access Unicenter NSM Web Applications ....................................................... 225 Access AEC Web UI ...................................................................... 227 Unicenter Configuration Manager Setup ................................................... 227 Access the Knowledge Base .............................................................. 228 Configure Unicenter NSM Web Reporting Server ........................................... 228 CA Web Server Configuration with SSL .................................................... 229 CA Web Server Security .................................................................. 240 Enable Unicenter NSM Integration with eHealth Reports ........................................ 242 Enable the DSM Policy for eHealth ........................................................ 243 Enable Alert Management Policy .......................................................... 244 Enable eHealth Links in the Unicenter MCC ................................................ 244 Configure eHealth Links in the Classical Interfaces ......................................... 245 Discover eHealth Objects in Unicenter NSM Using the Discovery Gateway Command-Line Utility245 Chapter 8: Creating the Reduced-Size Installation Image 249 Remote Agent Installation Using RSII ......................................................... 249 Prerequisites ................................................................................ 250 Best Practices ............................................................................... 250 How RSII Works ............................................................................. 250 Create an Installation Image for Windows ..................................................... 251 Create Custom Response Files ................................................................ 252 Plan Your Response Files ................................................................. 252 Create Custom Response Files for Windows ................................................ 252 Create Custom Response Files for Systems Performance Agents on Windows ................ 253 About Response Files ........................................................................ 254 Deploy the Agent-Only Installation Image ..................................................... 254 Interactive Installation ................................................................... 254 Registration with Unicenter Software Delivery ............................................. 254 Unattended (Silent) Installation on a Delivery Application................................... 255 Deploy the Image to Unicenter Software Delivery .......................................... 256 Troubleshooting ......................................................................... 257 10 Implementation Guide Chapter 9: Getting Started 261 Discover Your Network Infrastructure ......................................................... 261 Network Visualization ........................................................................ 262 Unicenter MCC ........................................................................... 262 2D Map ................................................................................. 264 Managed Object Status................................................................... 266 Value of Objects in Your Network ......................................................... 266 Network Views ........................................................................... 267 Association Browser ...................................................................... 268 Object Statistics ......................................................................... 268 Historical Information About Your Network ................................................ 268 Chapter 10: Implementation Scenarios 271 Introduction ................................................................................. 271 Scenario 1: Agentless Monitoring and Portal-Based Visualization ................................ 271 Installation .............................................................................. 272 Configuration ............................................................................ 273 Scenario 2: Focused Visualization Using Weighted Severity ..................................... 279 Assign Severity Weights .................................................................. 280 Scenario 3: Automated Business Views Using Dynamic BPV .................................... 281 Define Business Process Views to Show Location ........................................... 281 Scenario 4: Event Management and Advanced Event Correlation ................................ 283 Configure AEC to Receive Events at the Console ........................................... 284 Appendix A: DIA Reference 291 DIA Introduction............................................................................. 291 DIA Architecture ............................................................................. 292 Unicenter Knowledge Base ............................................................... 293 Dynamic Node Administrator ............................................................. 294 Gene .................................................................................... 295 Cells .................................................................................... 296 DIA Grid ................................................................................ 297 Consumer Applications ....................................................................... 297 Adaptive Dashboards Server .............................................................. 298 Management Command Center ........................................................... 298 Unicenter Management Portal & Web Reporting Services ................................... 299 Unicenter Remote Monitoring ............................................................. 299 WVObject Cell ........................................................................... 300 How DIA Works ............................................................................. 301 Utilities.................................................................................. 302 Contents 11 DIA Diagnostic Tool ...................................................................... 302 Advantages and Primary Functions............................................................ 304 Centralized Component Management ...................................................... 304 Data Collection and Abstraction ........................................................... 306 Transparent and Secure Communications.................................................. 306 Availability .............................................................................. 309 Zoning .................................................................................. 310 DIA Configuration ........................................................................... 312 DIA Deployment Recommendations ....................................................... 313 Configure Unicenter Domain Name Services ............................................... 314 Configure the MasterKB Without an SRV Record or Domain ................................. 316 Commands to Start and Stop DIA Daemons on Linux or UNIX............................... 317 Cell Configuration ........................................................................ 318 DIA Rules File ........................................................................... 318 Configure Communications for Encryption ................................................. 319 DIA Configuration in Special Environments ................................................ 321 Troubleshooting and Diagnostics .............................................................. 327 Backup for Master Knowledge Base ....................................................... 327 C-Gene Utilities Fail on HP-UX ............................................................ 328 Configure Memory Usage for a Cell ........................................................ 328 DIA Communications ..................................................................... 328 DIA Configuration in a Firewall or NAT Environment ........................................ 329 DIA Logs ................................................................................ 329 DIA Maintenance Tasks .................................................................. 333 Dynamic Node Administrator and UKB Installation Process Stops Responding ................ 340 Dynamic Node Administrator Floated to a Different Knowledge Base......................... 340 Dynamic Node Administrator Unable to Communicate with Unicenter Knowledge Base ........ 341 Float Dynamic Node Administrator to Another UKB Temporarily ............................. 342 Impact of Master Knowledge Base Crash on DIA ........................................... 342 Install DIA Without DNS Available......................................................... 343 Install DIA Without an SRV Record Set .................................................... 344 Multiple Entries in a Unicenter Knowledge Base in Grid ..................................... 345 Number of Cells Supported by Dynamic Node Administrator or Knowledge Base .............. 345 Potential Problems with DIA Consumer Applications ........................................ 346 Primary Master Knowledge Base is Down .................................................. 349 Primary and Secondary Master Knowledge Base Communication ............................ 350 Reconfigure Unicenter Knowledge Base Into Master Knowledge Base ........................ 350 Remove Server from the Network and the Grid in DIA ...................................... 350 Security Concerns with DIA ............................................................... 351 Specific OS Configuration Requirements for DIA Installation ................................ 351 Troubleshooting DIA Components ......................................................... 351 Two Zones in DIA ........................................................................ 355 12 Implementation Guide Unable to Autoactivate the Dynamic Node Administrator.................................... 356 Unable to Deploy Packages Using Package Deployment Infrastructure (PDI) ................. 356 Unable to Do an SRV Record Lookup ...................................................... 357 Unable to Open DIA Tool ................................................................. 358 Unicenter Knowledge Base Failure in Firewall Scenario ..................................... 358 Utilities to Assist Troubleshooting DIA ..................................................... 359 Appendix B: Making Components Cluster Aware and Highly Available 369 Cluster Aware and High Availability Introduction ............................................... 369 CA High Availability Service .................................................................. 369 Failover and Failback ........................................................................ 370 Resource Groups ............................................................................ 371 Resource Groups on Linux Platforms ...................................................... 371 Cluster Configuration..................................................................... 371 Shared Disk Support ..................................................................... 372 HAS Architecture ........................................................................ 373 Unicenter NSM Highly Available Components .................................................. 374 How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) ...................... 375 How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) ......... 377 How You Install, Reinstall, or Uninstall Unicenter NSM Components ............................. 379 How WorldView Becomes Cluster Aware ....................................................... 380 WorldView Resource Group ............................................................... 380 How Event Management Becomes Cluster Aware .............................................. 380 Event Management Resource Groups ...................................................... 381 How Event Daemon Resumes Processing from Point of Failure .............................. 381 Environment Variables Event Management Uses When Highly Available ...................... 382 How You Configure Event Management in a Cluster Environment ............................ 382 How You Test Event Management in a Cluster Environment ................................. 383 How AEC Becomes Cluster Aware ............................................................. 383 AEC Resource Groups .................................................................... 384 How Alert Management Becomes Cluster Aware ............................................... 384 Alert Management Resource Group........................................................ 385 How You Test Alert Management in a Cluster Environment .................................. 385 Cluster-Aware Agent Technology ............................................................. 386 How Agent Technology Becomes Cluster Aware ............................................ 387 Windows System Agent Highly Available Resource Groups .................................. 388 UNIX/Linux System Agent Highly Available Resource Groups................................ 390 UNIX/Linux and Windows Log Agent Highly Available Resource Groups ...................... 390 Microsoft SQL Server Agent Highly Available Resource Groups .............................. 393 Contents 13 Appendix C: CCS Linux/UNIX Reference 395 CCS Linux/UNIX Reference Introduction ....................................................... 395 PIF Response Files ........................................................................... 395 Parameter Usage in PIF ...................................................................... 396 PIF Response Files and Parameters ........................................................... 396 PIF Response Files Creation .................................................................. 396 Response File Considerations ................................................................. 397 Appendix D: Database Maintenance Quick Reference 399 Database Maintenance Quick Reference Introduction ........................................... 399 Database Backup ............................................................................ 400 Query Optimization (Ingres Only) ............................................................. 401 System Catalog Optimization (Ingres Only).................................................... 401 User-Defined Tables Optimization (Ingres Only) ............................................... 402 Database Recovery .......................................................................... 402 Index 14 Implementation Guide 405 Chapter 1: Overview This section contains the following topics: Introduction (see page 15) Unicenter NSM (see page 15) Product Components (see page 17) Documentation (see page 26) Introduction This chapter contains an overview of Unicenter Network and Systems Management (Unicenter NSM), a brief introduction of the available components, system requirements, and resources you can use for additional information. Note: In Unicenter NSM r11, the database used for the MDB is Ingres for both Windows and UNIX/Linux. In Unicenter NSM r11.1 and r11.2, however, the database used for the MDB is Microsoft SQL Server. Additionally, the Unicenter NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It has its own local PostgreSQL database to store relevant event management data. This PostgreSQL database is installed with the product. Therefore, the documentation for Unicenter NSM r11.2 has to provide various database information, so be aware that some information may not apply, depending on the Unicenter NSM version you are running. Unicenter NSM Unicenter NSM is a comprehensive management solution that lets you discover, monitor, and analyze infrastructure elements, gather reports on system and network status to help avoid potential bottlenecks, and set up automated actions to improve performance. Unicenter NSM lets you analyze the health, status, and performance of your infrastructure elements, improving management and facilitating optimization. Unicenter NSM displays and reports system status, problems, and history in a number of secure and personalized facilities including the Management Command Center (Unicenter MCC), Unicenter Management Portal (Unicenter MP), Event Console, and visual maps (such as Association browser and 2D Map). Unicenter NSM displays overview and detailed views of infrastructure elements with a single GUI, the Unicenter MCC. These visualizations let you identify and understand information relevant to particular operational roles. Chapter 1: Overview 15 Unicenter NSM Enterprise management requires tracking many elements to provide a valid view of infrastructure health. Unicenter NSM includes agents that provide monitoring and visualization of resources across many different platforms in the enterprise, that network together to perform a business service, and that complete a unified view of the enterprise. Efficient information sharing is accomplished through a centralized database known as the MDB. This comprehensive knowledge base of CA-gathered intelligence is shared among CA products such as Unicenter NSM and Unicenter MP to provide more accurate and significant information about infrastructure problems and resolutions. This technology allows multiple CA solutions to work together to perform a business service. In addition, Unicenter NSM can provide information from system platforms such as Windows, Linux, UNIX, AS400, z/OS, and HP NonStop, and network platforms such as Cisco and 3Com switches and routers to a single management station. For the most up-to-date listing of supported platforms, see the Release Notes. Unicenter NSM provides a unified approach encompassing all disciplines and elements needed to proactively manage business initiatives. Unicenter NSM offers specialized support to manage key technologies, like high availability clustering, available on many operating systems. Because Unicenter is a family of integrated business infrastructure management solutions, each member of the product family can use common facilities, making the whole solution more powerful. Unicenter uses advanced intelligence and visualization technology to simplify business administration. Through innovative use of intelligence, visualization, and personalization, Unicenter improves problem resolution time—reducing downtime and slow performance while improving overall service delivery. Unicenter products offer the following: ■ Sophisticated monitoring capabilities that gather information for display, managing, and reporting. ■ Advanced root-cause analysis and event management to identify the source of problems. ■ Industry-leading visualization and reporting that simplifies the complexity of the IT infrastructure, including Java-based graphical user interfaces (GUIs), 2D Maps, portal views, and association browsers. ■ Personalized views of information specific to the role and interests of the end user through the use of portal technology. 16 Implementation Guide Product Components The following product add-ons are available for Unicenter NSM: ■ Unicenter Advanced Systems Management This product leverages the intelligence in Unicenter NSM and Agent Technology to create a centralized, uniform infrastructure that lets you discover and manage clusters, dynamically reconfigure resources, and discover and manage virtual machines. ■ Unicenter Job Management Option This product enhances the efficiency of the enterprise by coordinating the execution of application processes. Business process dependencies are enforced to maximize utilization of resources and minimize manual interaction. Product Components Unicenter NSM offers out-of-the-box integration with other CA management products and consists of the components described in the following topics. Management Command Center Overview The Management Command Center (Unicenter MCC) provides a graphical tree structure, both familiar and intuitive, for productive navigation of role-based administrative tasks. The Unicenter MCC is the center for visualization, configuration, and monitoring in Unicenter NSM. You use it to navigate the WorldView 2D Map and topology tree view, monitor Event messages, look into details of Agent Technology, start network and system discovery, create reports, and much more. Integration with WorldView (through icons and Business Process Views) is also crucial for interaction between Unicenter NSM and other applications. Agent Technology Agent Technology monitors and manages your enterprise. Agent Technology can extend and manage customer and third-party programs and applications. Individual agents can collect information on a wide range of data across numerous operating systems and applications. Unicenter NSM Agent Technology also includes an integrated Distributed State Machine (DSM). This vital component provides the intelligent correlation of received events and translation of data into meaningful information for visualization and monitoring. Chapter 1: Overview 17 Product Components Event Management Event Management provides a rich collection of facilities to meet your information technology needs with flexible correlation, intelligence and automation capabilities at all levels of the management infrastructure. The Event Manager, Event agents, and the Event Console comprise Event Management. Unicenter Systems Performance Unicenter Systems Performance monitors the performance of the server platforms in your enterprise, letting you apply consistent management policies to disparate operating systems. Systems Performance provides historic and real-time information to assist with problem analysis and capacity planning. Also, simplified reports provide immediate value upon installation. Active Directory Monitoring (Windows) Active Directory Monitoring on Windows platforms monitors the health of critical aspects of the Windows Active Directory environment. Unicenter NSM provides comprehensive monitoring of the Active Directory Service (ADS), the File Replication Service (FRS), and the Domain Name Service (DNS). Discovery Discovery discovers and classifies devices on IP and IPX networks. It provides both an ad hoc (on demand) and continuous (real-time) mode. It provides discovery services to other CA Common Services components and updates the MDB with newly discovered and classified network objects. When you install your product, you can use any of the following types of Discovery: Classic Discovery Provides on demand discovery that lets you decide which subnets you want to discover and when. You can also configure Classic Discovery to run at regular intervals, which can be used as an alternative to Continuous Discovery and ensures that your discovered environment in the MDB is always current. You can start a Classic Discovery from the Discovery Classic GUI, the Management Command Center, the Unicenter Browser Interface, or the command line. 18 Implementation Guide Product Components Continuous Discovery Provides event-driven and ongoing discovery. Continuous Discovery employs a manager and agents that continuously scan your network in real-time mode for new devices or changes in IP addressing of existing IP devices. You can configure Continuous Discovery for optimal load balancing between the Discovery Agents and the Discovery Manager. If you choose this method of discovery, you must install the Discovery Agents and the Discovery Manager. Common Discovery Discovers IPv6 networks. The Common Discovery Import utility discovers IPv6 networks using Common Discovery technology and imports IPv6 addresses into WorldView, where they are integrated with existing networks. Notification Services Notification Services provide the messaging infrastructure for Unicenter NSM and leverage your existing investments in application, network, and telecommunications infrastructures to deliver business information to remote personnel in a timely manner through wireless and advanced protocols such as WCTP, SMTP, POP3, and so forth. Notification Services consist of two parts: Notification Services Client Provides the necessary libraries and utilities to connect to the Notification Services Server in order to send notifications and retrieve responses. You must select this component in addition to the Enterprise Management Administrative Client to manage remote installations through that GUI. Notification Services Server A Windows Service that provides the necessary facilities to process client notification requests, resolve recipient information, and send requests to recipients using various protocols and providers. If requested, the Server can retrieve responses and send them back to the requesters. Alert Management System The Alert Management System (AMS) organizes and tracks the most important events in an enterprise or a logical segment of an enterprise so that you can focus on and manage the highest severity IT events. AMS provides tools for defining alert policies and multiple panes in the Unicenter MCC for viewing alerts. AMS lets you link to Unicenter Service Desk, the customer support application that manages calls and IT assets, resolves problems, and shares corporate knowledge. You can also view the Alert Management console through Unicenter MP. Chapter 1: Overview 19 Product Components 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. Event correlation is a way to group associated events together for further processing. Grouping events lets you do simple but powerful forms of processing, such as event suppression, reformatting, aggregation or consolidation. Adaptive Configuration The Adaptive Configuration service supports the challenging agent areas of initial configuration, the ongoing configuration adjustment, and the tuning with the following functions: ■ Detection of resources that should be monitored ■ Providing suitable thresholds for these resources ■ Automatic configuration of the agent with an optimum monitoring policy After startup, the Adaptive Configuration service provides a predefined configuration. If the predefined configuration does not match your specific applications, you can customize the service to meet your needs. As an example, you can influence the Adaptive Configuration service by specifying threshold policies or including and excluding specific resources. TrapManager TrapManager is a component of Unicenter NSM that lets you perform sophisticated trap database and trap filter file management. You can use TrapManager to manage trap information and translation messages stored in the Trap Database and trap filters stored in the trap filter file. SNMP traps contain critical information about the latest status of your network environment, including the network itself and devices on that network. Since this information is received in the form of Management Information Base (MIB) variables and their numeric values, it is difficult to understand offhand. The Trap Daemon reads the Trap Database, which contains all trap information and translation messages, and translates SNMP traps into meaningful, easy to understand messages. These translated traps appear on the Unicenter NSM Event Console. 20 Implementation Guide Product Components For every incoming trap, the Trap Daemon also searches the trap filters file for any filters that apply. If the specified filter criteria are satisfied, the trap is dropped from further processing and does not appear on the Event Console. This can be helpful if you are only interested in certain traps. Unicenter Browser Interface The Unicenter Browser Interface provides a lightweight web-based Java user interface through which you can administer Unicenter NSM. Unicenter Configuration Manager The Unicenter Configuration Manager allows for web-based configuration and remote distribution of agent profiles. It is able to deliver configuration data at scheduled times and to audit existing configurations for Unicenter NSM components such as agents, Advanced Event Correlation, and opr (operator) settings in Event Management. Unicenter Configuration Manager also delivers file packages to remote machines, which is useful when you have callbacks defined on agent configurations. Audit, delivery forecast, and delivery status reports are also available. Unicenter Management Portal Unicenter Management Portal provides a role-based, dynamic, personalized, and consolidated view of the enterprise management information provided by Unicenter products using the web portal. Unicenter Software Development Kit (SDK) The Unicenter Software Development Kit (SDK) provides the means to programmatically interface with the major components of Unicenter NSM. It lets you extend and tailor the WorldView, Event, and Agent Technology functionality to your specific needs by letting you create personalized visualizations and policies, and integrating with your site-specific data, applications, and configurations. Web Reports and Dashboards Web reports let you create inventory, status, and performance reports for your managed resources. Dashboards present the detailed state of your managed resources in a graphic and intuitive manner. Web reports and Dashboards are accessible through the Unicenter MCC, Unicenter MP, and the CA web server. Chapter 1: Overview 21 Product Components Online Books Selecting Online Books from the installation Product Explorer installs Unicenter NSM documentation. Selecting Unicenter Online Books from the setupNSM menu on Linux or UNIX installations installs the Java-based book reader (cabook) on the system. Running cabook directly from the Linux/UNIX DVD lets you view the books without installing them. Management Database Unicenter NSM components are integrated using a management database (the CA MDB). The MDB provides a single integrated database schema (tables, columns, views) for the management data stored by all CA products. The schema includes the database objects used by Unicenter NSM, its components, and options. Use of the MDB in Unicenter NSM enables integration of Unicenter NSM and other CA products for managing your IT infrastructure. Unicenter NSM r11.2 supports MDBs running on Microsoft SQL Server. The Unicenter NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It installs its own local PostgreSQL database to store relevant event management data. Unicenter for Pocket PC Unicenter for Pocket PC works with Unicenter NSM to provide access to Event Management functionality from your Personal Digital Assistant. With Unicenter for Pocket PC, you can do the following: ■ Send events and commands to specific servers to request administrator response, trigger automated Event Management policy, or execute commands. ■ View console logs and update them in real time using convenient predefined or custom filters. ■ Subscribe to critical events delivered directly to the Pocket PC as Unicenter NSM notifications. 22 Implementation Guide Product Components Unicenter Management for Microsoft Operations Manager Unicenter Management for MOM integrates Unicenter NSM and the Microsoft Operations Manager (MOM). The integration between MOM and Unicenter NSM provides a central location for performing management functions. You can see the status of MOM servers and managed PCs using WorldView, and you can change the status from there. You can also view open MOM alerts and Unicenter NSM events in one convenient location on the Event Console. Alerts generated by Microsoft-managed nodes are forwarded to the Event Console, where the updates are processed. After an event is generated, it can be filtered for action, such as saving it into the MOM database or correlating it with similar events. Other automated responses, such as sending email messages, or issuing SNMP traps or pages are also possible. You can execute low-level functions such as command lines or scripts. Note: If you are upgrading Unicenter NSM from an earlier version and were using Unicenter Management for MOM, you must also upgrade Unicenter Management for MOM to its current version. Earlier versions of the component are not compatible with this release of Unicenter NSM. Integration with System Center Operations Manager Unicenter NSM integrates with Microsoft's System Center Operations Manager 2007 (SCOM). The integration between SCOM and Unicenter NSM provides a central location for performing management functions. You can see the status of SCOM servers and managed PCs using WorldView, and you can change the status from there. You can also view open SCOM alerts and Unicenter NSM events in one convenient location on the Event Console. Alerts generated by Microsoft-managed nodes are forwarded to the Event Console, where the updates are processed. After an event is generated, it can be filtered for action, such as saving it into the SCOM database or correlating it with similar events. Other automated responses, such as sending email messages, or issuing SNMP traps or pages are also possible. You can execute low-level functions such as command lines or scripts. Chapter 1: Overview 23 Product Components Unicenter Cisco Integration Unicenter NSM integration for Cisco provides enhancements to the generic Cisco class that is supplied with Unicenter NSM. It updates the Cisco classes for both Cisco routers and switches. This integration provides the object identifiers for each Cisco device, which automatically lets Unicenter NSM discover Cisco devices and classify them into a specific Cisco model. After Discovery, Unicenter NSM can display and monitor these Cisco devices. In addition, you can add support for new Cisco devices from the Cisco Integration Control by just providing the device type (router or switch) and Sys ObjID. Integration with the Unicenter Systems Performance tools Performance Configuration and Trend Analysis provides a set of predefined configuration files for all supported Cisco routers. The Performance Manager gathers information for these Cisco routers and lets you graphically visualize the historical performance of all these devices. Using the Cisco integration, you can perform many tasks such as the following: ■ See the Cisco devices from the Unicenter MCC ■ Launch Cisco Works from the Unicenter MCC Topology Map to view and manage any Cisco device in greater detail ■ Launch Cisco Works from WorldView 2D Map ■ Monitor device interfaces from Node View ■ Launch DSM View of your devices from Node View ■ Review the performance of your devices through Unicenter Performance Trend Unicenter Remote Monitoring Unicenter Remote Monitoring remotely monitors your Windows servers, Windows workstations, UNIX, Linux, and Mac OS X resources, and IP resources without installing any software on the monitored resources. From a single instance of the Unicenter Remote Monitoring agent, you can remotely monitor your distributed servers and workstations. If scalability or load balancing is a concern, simply add another instance of the agent. 24 Implementation Guide Product Components Unicenter Remote Monitoring uses protocols native to each operating system to gather its data. For IP resources, it uses the network protocol, ICMP. For Windows resources, it uses the native RPC commands to pass into a remote Windows resource and gather data. It accomplishes its monitoring using a domain administrative account that you can validate against the remote Windows resource. For UNIX, Linux, and Mac OS X resources, monitoring is accomplished using remote shell (rsh) or secure shell (ssh). Using Unicenter Remote Monitoring, you can deploy a management server with a Unicenter Remote Monitoring agent to monitor the resources at the remote location and perform its responsibilities without having to load dedicated agents on each resource. A Unicenter NSM Manager upstream knows about the Unicenter Remote Monitoring manager and processes all alerts and exceptions with less traffic through the wide area network (WAN) infrastructure. The deployment produces less traffic through the WAN and a simpler, faster product deployment. Unicenter Remote Monitoring provides you with a deployment solution that lets you monitor the computers in your environment. It is adaptive, quick to install, and easy to configure. It manages your resources by exception notification, is scalable, and provides reporting functionality. Business Process View Management (Windows) Business Process View Management (BPVM) for Windows adds intelligence to the Business Process Views you use to monitor and control your network. A Unicenter Business Process View is a logical group of managed objects you create based on any criteria you determine, such as geographic location, business process, security, and so on. The Business Process View acts as a filter that displays only objects relevant to the management of resources for a specific business requirement. Using Business Process Views, you can apply new rules to your system to determine how the state condition is propagated from existing WorldView objects using methods ranging from simple counters to complex correlation rules. BPVM lets you implement policies to make automated high-level decisions about key resources and set warning and critical events when problems are detected. Chapter 1: Overview 25 Documentation Data Scoping Data Scoping is one of the security mechanisms available for securing Unicenter NSM. Data Scoping works in addition to eTrust Access Control or Security Management if you do not use eTrust Access Control. Data Scoping protects the WorldView components from unauthorized access and is automatically installed with WorldView WorldView Data Scoping lets you protect the MDB object data from unauthorized access. Data Scoping rules let the MDB administrators control a specific user ID’s 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 also lets you filter large amounts of information contained in the MDB into smaller, more pertinent subsets of data. It lets you view the same data differently depending on the current task. For information about configuring Data Scoping, see the “Post-Installation and Configuration” chapter. For additional information about Data Scoping, see the Administrator Guide. Unicenter Windows Management Instrumentation Agent The Unicenter Windows Management Instrumentation agent exposes the monitored resources of Windows Management Instrumentation (WMI) to Unicenter NSM management services so that you can monitor the content of your system. The agent sets thresholds for these monitored resources to alert the manager of critical events. The Unicenter WMI agent enables the efficient monitoring and proactive management of Windows systems and applications. Documentation This guide is intended for users who are implementing Unicenter NSM on a new system; it documents architecture considerations, pre-installation tasks, installation instructions, and configuration information and implementation scenarios. Upgrade and migration instructions are presented in the Migration Guide. The Unicenter NSM documentation set consists of Portable Document Format (PDF) files, JavaHelp files (.JAR), and Windows Help files (.HLP). The Unicenter NSM Installation DVD contains the guides in PDF format. See the Documentation Roadmap topic in the Unicenter NSM Release Notes for a listing of the documentation provided with the product. 26 Implementation Guide Documentation Note: The PDF files are independent of platform and operating system, and are viewable in the Adobe Acrobat Reader in Windows, Linux, and UNIX environments. To download the appropriate version of the Adobe Acrobat Reader, go to http://www.adobe.com. Unicenter NSM Databases In Unicenter NSM r11, the database used for the MDB is Ingres for both Windows and UNIX/Linux. In Unicenter NSM r11.1 and r11.2, however, the database used for the MDB is Microsoft SQL Server. Additionally, the Unicenter NSM r11.2 Enterprise Manager also runs on UNIX/Linux systems. It has its own local PostgreSQL database to store relevant event management data. This PostgreSQL database is installed with the product. Therefore, the documentation for Unicenter NSM r11.2 has to provide various database information, so be aware that some information may not apply, depending on the Unicenter NSM version you are running. Readme Files The Unicenter NSM readme file contains important information not included in the product documentation (such as installation requirements and dependencies). Review the file before working with the product. You can access the readme file from the product explorer. Microsoft SQL Server Databases For information about installing Microsoft SQL Server, see the product readme and online books. Ingres Databases For information about restrictions of computer name, user name, and directory path when you are installing Ingres or components that require Ingres, see the Ingres readme file. Release Notes For a description of Unicenter NSM features and enhancements specific to this release, operating system support, system requirements, installation requirements, published fixes, as well as a documentation roadmap, see the Release Notes. Chapter 1: Overview 27 Documentation Related Publications The following guides provide information that you will find useful. Most are available on the Unicenter NSM installation media. Administration Guide Is intended for use by system administrators and contains general information and procedures about how to secure, customize, configure, and maintain Unicenter NSM after installation and implementation. Individual chapters describe the components that are included with or that can be integrated with your Unicenter NSM installation. Agent Technology Support for SNMPv3 Provides information about how Agent Technology can take advantage of the SNMPv3 protocol. Documents how the security information is handled on the manager and agent side as well as how it is applied to the managed systems. SNMPv3 configuration and usage details are provided in this guide. CA Procedures Contains procedures and processes for all components of Unicenter NSM, including WorldView, Agent Technology, Enterprise Management, Event Management, CAICCI, Data Scoping, Discovery, Notification Services, Wireless Messaging, Security Management, and Unicenter NSM Job Management Option. CA Reference Contains commands, parameters, and environment variables for all components of Unicenter NSM, including Advanced Event Correlation, Agent Technology, Enterprise Management, Event Management, CAICCI, Data Scoping, Discovery, Notification Services, Wireless Messaging, Security Management, Unicenter NSM Job Management Option, and WorldView. Implementation Guide Documents architecture considerations, pre-installation tasks, installation instructions, post-installation configuration information, and implementation scenarios. Appendixes include in-depth information about Distributed Intelligence Architecture (DIA), the MDB, and the CA High Availability Service (HAS) for cluster aware environments. This guide is intended for users who are implementing Unicenter NSM on a new system. Inside Active Directory Management Provides general information, installation scenarios, and configuration procedures for Active Directory Management. 28 Implementation Guide Documentation Inside Event Management and Alert Management Provides detailed information about Event Management (message records and actions), Advanced Event Correlation, and Alert Management. Inside the Performance Agent Contains detailed information about the configuration and use of the Performance Agent. Inside Systems Management Documents systems management from the Unicenter NSM architecture perspective. The guide describes the different layers (WorldView, Management Layer, Monitoring Layer) and associated components, for example: Distributed State Machine (DSM), Unicenter Configuration Manager, Dashboards and so on. Inside Systems Monitoring Explores how to use and configure the system agents of Unicenter NSM to monitor the system resources in your environment. The chapters guide you through the process of configuring and optimizing the agent for your special requirements. Inside Systems Performance Contains detailed information about the three architectural layers of Systems Performance, and provides guidance in the deployment, configuration, use, and best practice of the Systems Performance components. MDB Overview Provides a generic overview of the Management Database (MDB), a common enterprise data repository that integrates CA product suites. The MDB provides a unified database schema for the management data stored by all CA products (mainframe and distributed). The MDB integrates management data from all IT disciplines and CA products. The guide includes implementation considerations for the database systems that support the MDB and information specific to Unicenter NSM's implementation of the MDB. MIB Reference Guide Provides detailed information about each MIB attribute of the Unicenter NSM system agents. Migration Guide Provides detailed upgrade and migration instructions. This guide is available on http://SupportConnect.ca.com only. Chapter 1: Overview 29 Documentation Programming Guide Provides details for constructing applications by CA development teams and by third parties and their clients. The guide is intended for developers who use one or more of the application programming interfaces (APIs) in the SDK to develop applications for use with Unicenter NSM. Key among these APIs are the WorldView API, the Agent Technology API, and the Enterprise Management API. Readme Files Provides information about known issues and information discovered after Unicenter NSM publication. The following readme files are available: ■ The Unicenter NSM r11.2 for UNIX and Linux readme ■ The Unicenter NSM r11.2 Windows readme ■ The Unicenter Management Portal readme Release Notes Provides information about operating system support, system requirements, new and changed features, published fixes, international support, and the documentation roadmap. The following release notes are available: ■ The Unicenter NSM r11.2 for UNIX and Linux release notes ■ The Unicenter NSM r11.2 release notes. ■ The Unicenter Management Portal release notes Unicenter Management Portal Implementation Guide Provides installation, deployment, and basic administrative instructions for Unicenter Management Portal. CA Green Book, Systems Management Identifies CA's solution for managing challenges involved in maintaining the performance and availability of complex server infrastructures. The CA solution provides proactive management of servers as part of an overall effort to improve service levels, and minimize the costs of managing the computing infrastructure through increased automation. It provides a view of the requirements for systems management and best practices for deployment. This guide is available online at: http://supportconnectw.ca.com/public/ca_common_docs/greenbooks/gree nbooks-index.asp. 30 Implementation Guide Documentation CA Green Book, Service Availability Management Describes how to deliver integrated end-to-end performance and event management that is centered on services. The CA Service Availability Management solution leverages the Manager of Managers integration capabilities of Unicenter NSM and eHealth and explains how to take advantage of those capabilities. It includes details on how to install and configure a variety of management solutions to provide simpler and more comprehensive management and monitoring of IT services. This guide is available online at: http://supportconnectw.ca.com/public/ca_common_docs/greenbooks/gree nbooks-index.asp. Chapter 1: Overview 31 Chapter 2: System Requirements This chapter describes system requirements that your systems must meet before installing Unicenter NSM. This ensures that someone has prepared your systems with the proper database, adequate memory, CPU, and disk space. When necessary, certain information is flagged if it is specific only to the Windows platform or only the UNIX platforms. This section contains the following topics: Hardware Requirements (see page 33) Database Requirements (see page 36) Web Environment Support (see page 37) Java Browser Support (see page 37) Adobe Acrobat Reader Support (see page 38) Unicenter NSM Agent Requirements (see page 38) Unicenter Remote Monitoring Requirements (see page 38) Unicenter Management for Microsoft Operations Manager Requirements (see page 39) CA System Center Operations Manager Integration (see page 39) CA High Availability Service (HAS) Requirements (see page 40) Unicenter Cisco Integration Requirements (see page 40) Unicenter for Pocket PC Requirements (see page 41) Systems Performance Requirements (see page 41) Hardware Requirements If the computer does not have the minimum resources necessary to support the installed components, you will see messages stating that one or more CA services have failed to start. In some cases, even computers that meet or exceed the necessary hardware requirements may experience this behavior if the combination of software products installed cause a temporary shortage of resources during startup. The services may in fact be operational shortly after the errors appear. If this occurs, it is necessary to delay the startup of CA services to allow other critical services time to completely initialize. In cases where there are simply insufficient resources available, CA services and other services may fail causing other cascading failures. The overall stability of your system is affected if you install this product on systems with insufficient resources. Chapter 2: System Requirements 33 Hardware Requirements We recommend letting the Windows operating system manage virtual memory, instead of specifying an absolute value. If you decide to specify an absolute value, we recommend that value is at least 1.5 times the physical amount of real memory (RAM) on the computer. (Windows only) A pointing device, (for example, a mouse) is required to install and use this product. Enterprise Manager Configuration An Enterprise Manager Configuration consists of all management components including a local MDB. Hardware Minimum Recommended CPU Intel Pentium 4 - 2 GHz, or AMD Athlon XP 2000+ Latest model available RAM 2 GB 4 GB or more Hard drive 6 GB 20 GB Infrastructure Server Configuration (Windows only) An Infrastructure Server consists of all management components with a remote MDB. Hardware Minimum Recommended CPU Intel Pentium 4 - 2 GHz, or AMD Athlon XP 2000+ Latest model available RAM 1 GB 2 GB or more Hard drive 4 GB 8 GB Management Command Center Configuration A Management Command Center consists of the main GUI client interface to an Infrastructure Server or an Enterprise Server. Hardware Minimum Recommended CPU Intel Pentium 4 - 2 GHz, or AMD Athlon XP 2000+ Latest model available 34 Implementation Guide Hardware Requirements Hardware Minimum Recommended RAM 512 MB 1 GB or more Hard drive 1 GB 2 GB Managed Node Configuration A Managed Node consists of the System, Performance and Event Agents. Hardware Minimum Recommended CPU Intel Pentium III - 550 MHz, or AMD Athlon 600 Latest model available RAM 512 MB 1 GB or more Hard drive 500 MB 1 GB GUI Configurations Local GUI configurations require the following hardware: Hardware Minimum Recommended Video 32 MB DirectX-True Color 64 MB DirectX-True Color Monitor 17" @ 1024 x 768 21" @ 1600 x 1200 Chapter 2: System Requirements 35 Database Requirements Database Requirements Windows Unicenter NSM for Windows supports the following databases: ■ Microsoft SQL Server 2005 (64-bit) ■ Microsoft SQL Server 2005 (32-bit) with (optionally) SP1 or any later maintenance ■ Microsoft SQL Server 2000 (32-bit) with a minimum of SP4 or any later maintenance Note: MDB creation uses Windows Authentication and must be run by an operating system user that is a member of the System Administrators server role. This release of Unicenter NSM has the following other database requirements: ■ Mixed-mode authentication is required. ■ A dictionary sort order of case-sensitive or case-insensitive is required. ■ You can use the English version of Microsoft SQL Server with a code page/character set of 1252 on any of the Windows language versions that CA has certified for use with Unicenter NSM. ■ You can use localized versions of Microsoft SQL Server other than English on any of their respective and matching Windows language versions that CA has certified for use with Unicenter NSM, with the default code page/character set, or with a code page/character set of 1252 if you are not using specific localized character data for that region, even though you are installing on a localized system of that region. You must use the default code page/character set if you plan to use specific localized characters. ■ You cannot use a Microsoft SQL Server alias that matches the local computer name, but which really points to a remote Microsoft SQL Server (whether in another resource group on the same physical node of a cluster or actually on a different computer). Note: In Unicenter NSM r11, the database tool used for the MDB is Ingres for Windows, UNIX, and Linux. In Unicenter NSM r11.1 and r11.2, however, the database tool used for the MDB is Microsoft SQL Server. The documentation for Unicenter NSM r11.2 contains information for both Ingres databases and Microsoft SQL Server databases, so be aware that some of it may not apply to your installation, depending on the Unicenter NSM version you are running. 36 Implementation Guide Web Environment Support Web Environment Support This release supports specific web browsers, web servers, and servlet environments. Supported Web Browsers The release of Unicenter NSM supports the following web browsers: ■ Microsoft Internet Explorer, Version 6 SP1 and later ■ Mozilla Version 1.6, Firefox and later Supported Web Servers and Servlet Environments Unicenter NSM web applications run as Java Servlets and conform to the Java Servlet 2.3 and JSP 1.2 specifications. Unicenter NSM is shipped with Apache Tomcat, so a web server is not required to install or run Unicenter NSM web applications. JavaScript must be enabled on all supported web browsers for Unicenter NSM applications to function correctly. The Management Command Center Java Browser interface supports the following web servers: ■ Apache Server Version 2.0 and later ■ Microsoft Internet Information Services (IIS), version installed with the operating system Java Browser Support The Unicenter Browser Interface, Web Reporting Server (WRS), Unicenter NSM dashboards, and Systems Performance reports use Java applications in their web pages and require the following browser support for Java: ■ Unicenter NSM dashboards work with built-in Java support in a web browser, if present. If the built-in support for Java is not present, the dashboards require that you install the Java Runtime Environment (JRE) from Sun Microsystems. ■ WRS and Systems Performance reports require that you install the Java Runtime Environment (JRE) from Sun Microsystems for the web browser. Chapter 2: System Requirements 37 Adobe Acrobat Reader Support If JRE is not detected on the system when you try to use WRS, Unicenter NSM dashboards, or Systems Performance reports, a link appears so you can download JRE from the Sun Microsystems website. When you install JRE for Windows, make sure that you select the "Offline Installation" option instead of the "Install from the Web" option. Unicenter NSM web applications support JRE 1.5.10 or later. The graphical displays on dashboards and reports do not appear unless built-in support or the JRE is present. Adobe Acrobat Reader Support WRS and Systems Performance reports let you export reports in PDF format. To view reports in PDF format, the computer running the web browser or the Management Command Center must have Adobe Reader version 7.0 or later (for Windows) or Adobe Reader version 5.0.9 or later (for Linux) installed. To download the appropriate version of Adobe Acrobat Reader, go to http://www.adobe.com. A copy of the Adobe Acrobat Reader installation image is also available on the Unicenter NSM installation media. Note: To help ensure that you can correctly open reports using Acrobat Reader, open Acrobat Reader and clear the Internet category option "Display PDF in browser" under Edit, Preferences. Unicenter NSM Agent Requirements For information about systems requirements for Unicenter NSM agents, see Inside Systems Monitoring. Unicenter NSM agents are supported on the same operating systems as those supported by Unicenter NSM. Unicenter Remote Monitoring Requirements Unicenter Remote Monitoring requires .NET Framework 1.1 SP1 on all supported Windows platforms. Install the .NET Framework service pack before you install Unicenter Remote Monitoring. 38 Implementation Guide Unicenter Management for Microsoft Operations Manager Requirements Unicenter Management for Microsoft Operations Manager Requirements Unicenter Management for Microsoft Operations Manager has the following requirements: ■ Microsoft Operations Manager 2000 SP1 or later ■ WorldView repository ■ Installation on a Unicenter NSM Event Manager ■ The same hardware requirements as Unicenter NSM r11.2 Manager ■ Unicenter NSM Manager running on Windows 2003 CA System Center Operations Manager Integration Before installing the Unicenter NSM SCOM Integration, your system must meet minimum software requirements. Computer where the Integration Is Installed The computer where the SCOM Integration is installed must have, at minimum, the following software: ■ The Microsoft System Center Operations Manager Console Client, which provides the files necessary to integrate with SCOM ■ A Unicenter NSM Event Agent ■ A Unicenter NSM WorldView Client Elsewhere in the Domain The domain where the SCOM Integration is installed must meet the following minimum requirements: ■ An instance of System Center Operations Manager must be installed and running. ■ A Unicenter NSM Event Manager must be present because the SCOM Integration creates Unicenter NSM events from SCOM alerts. The Event Manager may be on the same computer as the SCOM Integration. Chapter 2: System Requirements 39 CA High Availability Service (HAS) Requirements ■ A Unicenter NSM WorldView Manager must be present because the SCOM Integration creates objects in the WorldView Repository. The Integration reflects the status of those objects, and SCOM alerts are created based on that status. The WorldView Manager may be on the same computer as the SCOM Integration. ■ An instance of the Management Command Center must be present because it is the user interface that shows SCOM objects in the WorldView Topology, and alerts in the SCOM Alert Viewer. The Unicenter MCC may be on the same computer as the SCOM Integration. CA High Availability Service (HAS) Requirements CA High Availability Service (HAS) has the following requirements: Windows: ■ The same hardware requirements as Unicenter NSM r11.2 Manager ■ The Unicenter NSM Manager must be running a version of Windows suitable for HAS. ■ On computers running Microsoft Clustering Services (MSCS), HAS must run under a cluster domain account to operate across the cluster nodes. ■ The Unicenter NSM r11.2 Supplement includes High Availability services. These services enable HA-ready components in clustered configurations. HA-ready components provided by this deliverable are consistent with those enabled in the CCS / NSM r11.2 parent project. Any components or configurations that have not been certified as HA-ready in Unicenter NSM r11.2 will not be considered HA-ready in the Unicenter NSM r11.2 Supplement. ■ HA readiness will be limited to Linux platforms only. Additionally, Unicenter NSM r11 Event and calendar on Linux were not certified on a cluster and are not planned to be HA-ready in Unicenter NSM 11.2 UNIX or Linux. UNIX Unicenter Cisco Integration Requirements To use Unicenter Cisco Integration, you must have access to the Cisco nmidb file that contains device model information. The file is accessible through your cisco.com login privileges, or from your CiscoWorks product media. You can obtain a valid Cisco user account and password from your channel partner or you can log a request at http://cisco.com. (Windows only) 40 Implementation Guide Unicenter for Pocket PC Requirements Unicenter for Pocket PC Requirements Unicenter for Pocket PC has the following requirements (Windows only): ■ Any certified Pocket PC 2002 device with a minimum of 32 MB RAM and a wireless LAN card ■ Microsoft ActiveSync 3.5 or later (for installation only) ■ Windows server running the Unicenter NSM Enterprise Manager Systems Performance Requirements The Performance Trend and Chargeback components of Systems Performance require the existence of Excel from Microsoft Office 2000, Office 2003 or Office 2007. (Windows only) Chapter 2: System Requirements 41 Chapter 3: Product Architecture This section contains the following topics: Implementation Layers (see page 43) Unicenter Systems Performance (see page 59) Distributed Intelligence Architecture (see page 60) Classic Versus Continuous Discovery (see page 60) Implementation Layers For implementation purposes, Unicenter NSM is implemented in a distributed manner and is arranged into four layers: ■ Visualization ■ MDB/Enterprise - Database Level ■ Managers ■ Monitoring Technology Visualization The visualization layer represents user access to the various GUIs and management points. This includes: ■ Management Command Center ■ WorldView (Maps, Class and Object Browsers, Viewers, Wizards) ■ Unicenter Browser Interface (Remote and Web-based Viewer) ■ Unicenter Management Portal ■ Unicenter Remote Monitoring (Administrative Interface) ■ Web Reports and Dashboards ■ Unicenter Configuration Manager ■ Classic Enterprise Management For the architecture of the GUI layer, ensure that adequate response and access is provided among the WorldView clients and both the MDB enterprise level and the associated management points. If there is a heavy concentration of GUI users in one location, place the related repository computers in close proximity. Chapter 3: Product Architecture 43 Implementation Layers Which GUIs you decide to employ and at what level is determined by the role and responsibility of the targeted viewer. For example: ■ Administration and Operations staff may use the Management Command Center, Unicenter Browser Interface, WorldView, or Configuration Manager. ■ Management may use the Management Command Center or Unicenter MP. ■ End users or clients may use Unicenter MP or Web Reports and Dashboards. These GUIs will vary depending on your organization’s requirements, the roles each individual needs to support, and the platform and supporting features of each of the individual interfaces. MDB The MDB is a single database containing common tables and multiple productspecific tables that were previously contained in separate product databases (for example, the Unicenter NSM WorldView Common Object Repository). Based on a central management database, the MDB serves as the enterprise database integrating all CA products. As the primary reference point, the MDB lets you collect asset resource information from a centralized entity, or database, eliminating costly access on the network. From a Unicenter NSM perspective, all WorldView data is now stored in the MDB (formerly known as the Common Object Repository) and is referenced as the MDB. Typically, there is one MDB, but there may be times when for physical reasons (many managed objects), organizational reasons (departmental segregation), or network considerations (international office locations) you may need multiple MDBs. If this is the case, use the Repository Bridge to synchronize WorldView data between the MDBs. The Repository Bridge lets you roll up the higher level monitored objects to an enterprise MDB, or you can use the Repository Bridge to segregate a single MDB into multiple MDBs, thereby separating departmental reference points from the enterprise-wide view. You can also install a distributed MDB where the component databases are on different computers. In this way, you can have a remote MDB (part of a distributed MDB) for TrapManager and a separate one for DSM, WorldView, Alert Management System, Continuous Discovery, and so forth. Although the number of MDBs deployed in an environment may differ, you should always have one enterprise MDB serving as the central database. The enterprise MDB provides a complete view of the environment status that other product installations can use. 44 Implementation Guide Implementation Layers Use the following guidelines for MDB planning: ■ Any files that are accessed by the DBMS Server must be configured on the Linux file system EXT3 (Third Extended File system), or another nonjournal file system. Note: CA does not recommend use of the Reiser file system for the MDB. This file system is not suitable for use by a large database. ■ When a central MDB is not feasible, create an enterprise MDB to consolidate the data from the multiple MDBs in the environment. ■ Increase the computer requirements as necessary for the enterprise MDB, when the MDB is integrating information for multiple CA products. Consider the information provided in the readme for each product and plan accordingly. ■ Treat the enterprise MDB as a business critical service, which may benefit from installation on a highly available server system (a cluster, for example). The cluster system may then be monitored using the CA High Availability Service (HAS). See the appendix Making Unicenter NSM Components Cluster Aware and Highly Available for additional information. ■ Locate a server with an installed MDB close to the majority of users who will require access. ■ Use the Repository Bridge for MDB large-scale roll-ups for WorldView objects. ■ Use the Repository Bridge when you require departmental MDBs for WorldView objects. For additional details about working with the MDB, see the Management Database Overview. Managers The manager layer requires planning. It is possible to have multiple layers of managers to scale to your network and requirements. The most common managers in Unicenter NSM follow: ■ WorldView ■ DSM ■ Continuous Discovery ■ Event ■ Alert ■ Job Status Chapter 3: Product Architecture 45 Implementation Layers WorldView Manager WorldView Manager monitors the MDB for changes to WorldView objects, propagates severity, and populates Dynamic BPVs. The WorldView Manager also exposes WorldView data to the Unicenter MCC and provides data to reports, dashboards, and Unicenter MP. As a best practice, the WorldView Manager must reside on the MDB server. This component contains the Severity Propagation engine and the Dynamic BPV engine. Note: The WorldView Manager component cannot be installed on a Windows Domain Controller. DSM Manager The Distributed State Machine (DSM) is the manager of agents and provides the first level of fault correlation in Unicenter NSM. An agent traps, or the manager polls, to ascertain whether there is a fault (or the possibility of one). Typically, you will want to use more than one DSM, not because of enterprise size, but because the DSM functionality is able to failover. The DSM is mission critical; treat the loss of enterprise monitoring the same as a critical server failure. Use a second DSM to handle the failover, when necessary, or a remote DSM that is responsible for dedicated locations (reporting to a central MDB). Continuous Discovery Manager The Continuous Discovery Manager consolidates discovery information gathered by its data collectors, the Continuous Discovery agents, with the MDB. When a new device is discovered on the network by an agent, it updates the MDB with this information. The manager monitors when it has last seen traffic for a device through various mechanisms that include DHCP and network traffic monitoring, scanning the ARP caches of routers, and scanning monitored subnets through various protocols such as ICMP (ping), SNMP, HTTP, and so forth. Discovery information is submitted to the MDB to be shared among Unicenter NSM components as well as other CA products. When new devices are discovered, these products can use the MDB Distributed Intelligent Architecture (DIA) cell to receive event notification to define business policy. 46 Implementation Guide Implementation Layers Event Manager The Event Management System is the focal point for managing enterprise events from a variety of sources throughout your network. Through the console log, you can monitor event activity and immediately respond to events as they occur. By filtering messages that appear on each console, you can retrieve specific information about a particular node, user, or workstation. Event Management processes messages and their related actions through the following components: ■ Console log views let you restrict message access to authorized users and user groups. ■ Calendars let you establish date and time controls for automated event processing. ■ Message record and action profiles let you identify events that are important to your operation and define the special processing that Unicenter NSM performs when encountering these events. ■ Advanced Event Correlation (AEC) enhances your message record and action policy by identifying 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 following schema is typical for Event Managementt implementation: ■ Collect and centralize ■ Notify and escalate ■ Automate and report In a distributed environment, you can link many levels of Event Management to process cooperatively. A small implementation may have just one Event Manager; large implementations may have more Event Managers in a layered approach. Use the following guidelines for Event Manager planning: ■ Use escalation hierarchies if possible (filter and forward). ■ Ensure you have enough resources on the machine for the volume. ■ Be as generic as possible with your messages and actions. ■ Take advantage of console color-coding. ■ Remember the 80/20 rule; some are vital and many are trivial. ■ Use Text matching rather than Scan wherever possible in message record definitions. ■ Consider deploying non-root event agents on Linux or UNIX wherever possible for increased security. Chapter 3: Product Architecture 47 Implementation Layers In general, as with DSMs, it is best to place Event Managers as close as possible to the objects with which they communicate. Avoid having lower level Event Managers simply forward all of their messages to higher level ones. Think of Event layers as escalation points. Each Event manager handles what it can, and escalates what it cannot to the next higher level (as configured on each Event Manager using message records to identify events that require special handling and message actions to specify what Event Management should do when it detects a match between an input event message and a message record). This keeps traffic levels to a minimum, and does not flood higher level Event Managers with trivial messages. Placing Event agents on the same level as DSMs is a good approach. In situations where a message gets to the highest level Event Manager and still requires escalation, you can create a message record and action that creates a trouble ticket. Note: Event agents do not require the message and action database to reside locally; only the committed Decision Support Binary (DSB) is required. In a situation where the Event Manager computer fails, locally generated messages would not be created; in an escalation-based setup, however, several critical messages would arrive from lower level Event Managers. A good approach is to have a DSM control the activation of failover policy and to plan multiple escalation points in case of failure. Event Managers are scalable and can handle large volumes of messages without problems. Place Event Managers where localized action processing is most effective (usually leading to a hierarchical placement at various levels in the environment). Depending on your requirements, it is sometimes reasonable to have multiple Event Manager hierarchies based on computer type, not only locale. Alert Manager The Alert Management System (AMS) is a tool for organizing and tracking the most important events in an enterprise or a logical segment of an enterprise. It lets you focus on and manage the highest severity IT events. With AMS you can do the following: ■ Specify the situations that create alerts, and define alert policies. ■ View and manage alerts in multiple panes of the MCC. ■ Link to Unicenter Service Desk, which is a customer support application that manages calls and IT assets, tracks problem resolution, and shares corporate knowledge. 48 Implementation Guide Implementation Layers Alerts are important (or critical) events generated by one or more source events in the Event Management System (EMS). You can organize, view, and manipulate alerts in complex ways with the Unicenter MCC. Alert Management maintains specialized events processed through message records and actions or AEC policies. An approach based on class makes extending and tailoring policies to any environment easy. We recommend that an Alert Manager be as close as possible to its corresponding Event Managers. You can install multiple Alert Managers on a functional or geographic basis for large enterprises. When determining your management requirements, consider how you want your Event and Alert configuration divided or consolidated, and where you would like the important and critical events processed to create alerts. Unlike Event Managers, you cannot configure Alert Managers to be organized in a hierarchy or to forward alerts. You can accomplish forwarding and reduction with Event Managers (where an Alert Manager is at the highest level of the hierarchy). At the appropriate level, you should implement message record and action event policy (forwarding any alert created to the Alert Manager). Note: Alerts should be a small subset of the events that occur. They should represent only events that require human intervention or provide information critical to continued normal operations. There are two reasons for this. First, if few alerts are generated, the operations staff can focus more easily on what is important. Second, AMS is a complex system and each alert consumes more computing resources than other events. By carefully designing your AMS configuration and policy, you can help ensure that you get the most benefit from AMS. Job Manager Another commonly implemented enterprise management function is Unicenter Job Management. Job managers control job scheduling. Job agents process commands at the direction of job managers. Installing a job agent enables the computer to be part of job process execution. Configure one or more job managers to direct job scheduling; configure one or more job agents across different machines and platforms to execute jobs. Job management can span multiple platforms; job managers are supported on the following platforms: ■ MVS ■ UNIX/Linux ■ Windows Chapter 3: Product Architecture 49 Implementation Layers Job agent support is provided through the Unicenter Universal Job Management Agent. It supports the following platforms: ■ OpenVMS ■ OS/400 ■ UNIX/Linux ■ Windows The job agent’s function is to execute and track the status of jobs on the local system; the job manager’s function is to instruct and manage the job agent. Use the ability to schedule and track jobs across multiple platforms to allow flexibility in the architecture. For example, a UNIX job MANAGER can control not only UNIX job agents but also Windows job agents. Remote CAICCI, the CA Common Communication Interface, is required if you are going to use cross-platform scheduling and must be installed and configured to connect to any computer that is part of cross-platform scheduling. Multiple job managers can schedule to each job agent. In a centralized job management environment, a single server schedules and monitors all job related activity (for all agents on all systems). In a decentralized environment, multiple job managers coordinate the jobs on multiple systems and may even perform tasks for other job managers. Place job managers on any host that runs scheduled production work. You can distribute job managers throughout the environment and coordinate them from a central location. This usually fits in well with the Event Manager and DSM Manager locations. Setting up a single locale and then replicating it to other locales is an efficient way to proceed with your implementation. Also, mission-critical processing on a single host is a good reason for placing an additional job manager on that host. The CA mainframe solutions such as Unicenter CA-7 Job Management (Unicenter CA-7) function as both job manager and job agent in the distributed architecture. Use the following guidelines for job manager planning: ■ Install job managers on mission-critical computers; install job agents on other computers. ■ Designate an enterprise job manager for top-level processing. ■ Do not forget the mainframe. 50 Implementation Guide Implementation Layers Monitoring Technology CA provides two methods for monitoring your network resources: Agent Technology and remote monitoring (RM). The topics that follow describe and compare the two methods. Agent Technology Unicenter NSM employs many types of agents, including System, Event, and Job. For Agent Technology to perform its function, all of the following components must work together: Agents Monitors the resources (operating system, log files, MS-Exchange Server, and so on) and, based on policy, forwards trap information to the DSM. DSM Converts the trap information to object state information and forwards it to the MDB. MDB Records the object information for use and displays it in the various Unicenter NSM interfaces. Interface Displays the object state information. Although you can install all of these components on the same computer, you will most likely install two or more on different computers. A simple configuration includes the three Agent Technology layers--a number of Agents communicating with a single DSM that in turn communicates with a single WorldView. This configuration is simplified, but it introduces basic pieces of each Agent Technology layer before you evaluate more complex implementation strategies. Determine exactly what computers need a performance agent. Implementing performance agents on a standalone server or a workstation may not be necessary. Only implement those components that serve a stated business requirement. Remember, you want to start with the business requirement, not the technology. Chapter 3: Product Architecture 51 Implementation Layers You can configure agents to monitor specific resources or metrics they should examine, and what level should be considered a problem for that metric (commonly known as a threshold). When a threshold is met, the agent sends a trap to its managers. Note: Agents can have multiple trap destinations, which is useful for failover situations. Ideally, traps are used when an agent detects an exception. When a manager polls an agent, it creates more traffic than a trap. A good practice is to set the poll level according to the type of network connection and the importance of the machine you are managing. Traps may not occur frequently because agents respond to polls from a manager. This is normal behavior. Use polls to ensure that the managed device is still responding to requests. A good practice is to have a larger poll interval (greater than 10 minutes) in a reliable network environment. Unicenter NSM supports agents on a wide range of platforms; however, there are platforms where agents cannot be installed. These platforms may be critical to your environment, in which case you can monitor them using proxies. Proxies bring the information from the unsupported platform into the Unicenter NSM domain. For example, you can view console logs from an HP 3000 machine piped to a managed Solaris (or serial) port fed into a Windows machine. You can also use Remote Monitoring to support platforms where agents cannot be installed. See the topic, Unicenter Remote Monitoring Architecture and also the scenario, Agentless Monitoring and Portal-Based Visualization in the chapter “Implementation Scenarios” for information about this method of monitoring your environment. Agents are instrumental in the environment, reporting conditions and status to their manager (a DSM), while providing the capability to drive the environment. Like any other software, agents have resource requirements. Agents are scalable and monitoring by an agent is designed to warn of impending problems. If the computer hard drive on which you intend to install the agent is full, consider a system upgrade before implementing the agent. In general, agents should reside near the managed resource. 52 Implementation Guide Implementation Layers Use the following guidelines for agent planning: ■ Determine which computers require monitoring. ■ Consider scheduling only a ping to a computer; it may be all you need. ■ Ensure that you have enough resources to run the agent. ■ Consider dual trap destinations (to more than one DSM) for failover purposes. ■ Use system agents for basic application monitoring (processes, services, files, and so on). ■ Ensure that you manage configurations centrally and automatically through Unicenter Configuration Manager. ■ Consider using Unicenter Remote Monitoring (agentless monitoring) if you cannot install an agent (because of dedicated systems or for liability reasons). Unicenter Remote Monitoring Architecture The Unicenter Remote Monitoring architecture consists of three tiers. The first tier contains a Unicenter NSM Windows manager with the Administrative Interface (AI) installed. The AI lets you configure the attributes of monitored resources, view the current state of monitored resources, and through WorldView, the AI presents a centralized view of your enterprise. The second tier contains the Unicenter Remote Monitoring agents, which are deployed throughout your enterprise running as a Windows service, usually on dedicated monitoring computers. Although Unicenter Remote Monitoring can remotely monitor UNIX, Linux, and Mac OS X servers, the Unicenter Remote Monitoring agent is currently supported only on Windows platforms. The third tier contains the resources being monitored by each Unicenter Remote Monitoring agent, which are the workstations and servers running in your corporate environment. Unicenter Remote Monitoring itself has three major components: ■ The Administrative Interface (AI) lets you discover resources, configure selected resources, and receive updates on the status of monitored resources. ■ The agent is the main processing module, which polls each monitored resource continuously and determines whether an error has occurred. ■ The local XML data store records the configuration data for each Unicenter Remote Monitoring agent. Chapter 3: Product Architecture 53 Implementation Layers Comparison of System Monitoring Products Determining which method you want to deploy for a system in your enterprise depends on several factors, including the information you must monitor to ensure the health and availability of your network resources. Consider using Unicenter Remote Monitoring (agentless monitoring) when you cannot install a remote agent for dedicated systems, or for liability reasons. Scalability compared to ease of deployment is also a consideration. The size and growth potential of your IT environment is an important factor. Agent Technology monitoring uses an approach that requires you to deploy agents and then scales in larger environments because the monitoring load is decentralized and network bandwidth is not consumed to do monitoring. The following table compares the general attributes of each monitoring method. Feature Unicenter NSM Agent Technology Unicenter Remote Monitoring Managing Component Distributed State Machine (DSM) Agent Managing Platforms Windows, UNIX, Linux Windows only Management method Monitoring sensor, or agent, installed on each remote host Agent queries each monitored host for its current status Communication protocol Host sends SNMP traps to DSM only if status changes, and DSM polls host to detect health Native operating system queries from agent to remote hosts Overall Footprint DSM manager piece and browsers installed on dedicated servers, and appropriate sensors installed on each host Agent and GUI interface manager piece installed on dedicated servers. Nothing installed on hosts Configuration Method Configset models applied as profiles centrally by Unicenter Configuration Manager Centrally configured through Administrative Interface 54 Implementation Guide Implementation Layers Feature Unicenter NSM Agent Technology Unicenter Remote Monitoring Benefits Manager runs on multiple platforms; in-depth monitoring of diverse data; manager can monitor itself; manager retains history of events, limited network traffic Lightweight, speedy implementation and discovery, easy configuration, user can choose exception only reporting, reduced support and management costs Integration With Event Management, WorldView, and Management Command Center With Event Management, WorldView, Management Command Center Security Support of SNMPv3, and community strings Agent utility defines privileged users. Monitored Information The following tables compare the type of data you can monitor using each of the two monitoring methods. General Agent Information AT RM Remote monitoring configuration (resources on remote machine) * Y Discovery ** Y Y Scalable in larger environments Y N Easy deployment N Y IP devices (any machines on the network), ICMP (ping) only N Y Novell Netware Y N Windows NT / 2000 / XP / 2003 Y Y Tier 1 UNIX (AIX, HP-UX, Linux, Solaris). For RM, Tru64 Y Y Programmable Watchers--monitor result of any user defined metric combination Y N Hardware monitoring (for example, CPU temperature, fan speed, UPS State and so on) Y Y * Only certain resources such as files, directories, and printers can be monitored remotely. ** Automatic discovery of objects can be monitored by using Adaptive Configuration or “AutoWatchers.” Chapter 3: Product Architecture 55 Implementation Layers Windows System Monitoring Features AT RM Processors--load or loss Y Y Memory--physical, virtual, paging file Y Y Logical volumes--throughput, fragmentation, free space, used Y space Y Mounts--change, loss Y N Distributed files systems (Win 2000)--loss, available replicas Y N Quotas--space per user Y N Directories--number, size, timestamp Y N Files--number, size, delta, timestamp Y N Processes--number, threads, children, memory, CPU usage Y Y Services--activity, existence, optional restart Y Y Jobs--existence, number of processes, CPU usage Y Y Sessions--number, memory, CPU usage, activity Y Y Printers--events, queue length, loss Y Y Network interfaces--send/receive packets+bytes, error rates, total values Y Y Registry entries--existence, value, change in subtree Y Y ASCII file content monitoring--user-defined, created files Y N Event log content monitoring--native system logs Y Y Linux and UNIX Monitoring Features AT RM: AIX/HP/Linux/Sun/T64 System--release, version, details, node name, system name, boot time Y N/N/N/N/N CPU--total, user, system, wait, idle CPU usage, context switches (for AT, includes overall and per CPU; for RM, includes overall only) Y Y/Y/Y/Y/Y Load--average load over 1, 5, 15 minutes Y Y/Y/Y/Y/Y Real memory--used, total Y N/N/N/N/N 56 Implementation Guide Implementation Layers Linux and UNIX Monitoring Features AT RM: AIX/HP/Linux/Sun/T64 Physical memory: Y Y - Scan Rate Y N/N/N/N/N - Free memory (KB) Y Y/Y/Y/Y/Y - Pages paged in/out N Y / Y / N/ N / N - Total amount changed Y N/N/N/N/N - Size free list N Y/Y/N/N/N - Active free pages N Y/Y/N/N/N Swap space--used, total, per swap file used, per swap total Y N/N/Y/Y/Y File systems--KBytes used, total, free (no inodes for RM) Y Y/Y/Y/Y/Y Mounts--loss, total, free, KBytes Y N / N / N / N/ N Physical disk throughput--blocks in/out Y Y/Y/N/Y/Y Files--existence, file size (KB), file size delta, modified date Y N/N/N/N/N Processes--number of instances, children, CPU, size Y Y/Y/Y/Y/Y Printer queues--number of jobs, status of queue Y N/N/N/N/N Network--in packets, out packets, collisions, interface name Y Y/Y/Y/Y/Y IPC--total resources, message queues, shared memory, semaphores Y N/N/N/N/N IP Monitoring Features AT RM IP response times/availability N Y Port availability (IP services) Y Y Agent Monitoring Features AT RM Multiple poll methods--disable, poll only, poll and query, query only Y Y* Configurable thresholds for severity level Y Y Chapter 3: Product Architecture 57 Implementation Layers Agent Monitoring Features AT RM Delta warning and critical statuses for monitoring changes in analog values Y Y Overloaded thresholds Y N Call backs to rectify problems automatically on the monitored Y machine N Detailed event information sent to Unicenter Event Management Console Y Y Ability to monitor the removal of a resource (Loss Monitoring) Y Y Ability to avoid state change in data that spikes by using lags/breaches Y Y Available resource lists to aid with configuration of the agent Y Y Monitoring of cluster resources ** Y N Automatic Adaptation of Monitoring Thresholds *** Y N Policy based creation of Monitoring Objects **** Y Y * Disable and poll are valid for Remote Monitoring ** Allows you to discern between a failover and a loss of shared resource *** By means of Adaptive Configuration **** By means of Auto Watchers or Adaptive Configuration Collection of Historic Data AT RM Data collected by agent stored into Performance Cubes for historical analysis Y N Data collected by agent passed to Performance Scope for real-time analysis Y N Event history (history of state changes) stored in agent Y Y Event Message Handling AT RM Status events sent to Unicenter Event Management Console Y Y Integration with Unicenter Service Desk Y Y Place agent into maintenance mode to stop event propagation Y Y* Provisioning of NSM Event Definitions Y Y 58 Implementation Guide Unicenter Systems Performance * Even if the monitoring of a single resource is stopped, agent continues to monitor all other resources. Visualization AT RM Visualized in 2D Map Y Y Visualized in MCC Y Y Visualized in Unicenter Management Portal Y Y Unicenter Systems Performance The computing facilities in many companies typically comprise a large and diverse collection of machines spread over a wide geographic area. The Systems Performance architecture supports such a distributed environment by providing high levels of scalability and enabling easy configuration across many thousands of machines. 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. Applications like Performance Scope and Performance Reporting retrieve performance data from the Performance Data Grid (PDG). This grid has multiple levels: the Enterprise Server Node, the Distribution Server Nodes, and the Managed Nodes. In essence, the grid creates a single image of the performance data for the entire enterprise and grants you seamless access to this data. The grid contains performance data for the following machines, resources, and times: ■ All the machines in your enterprise that have ever been monitored ■ All the resources capable of being monitored ■ All times from when you first collected performance data through to the present time Performance Agents (running on the managed nodes) report to the Performance Distribution Servers, which in turn report to a Performance Domain Server. Both the Domain and Distribution Servers run as persistent services or daemons, so they can react immediately to registration requests from agents and service instructions from the Performance Configuration application. For a complete discussion of Unicenter Systems Performance, see the Inside Systems Performance guide. Chapter 3: Product Architecture 59 Distributed Intelligence Architecture Distributed Intelligence Architecture Distributed Intelligence Architecture (DIA) allows a central location to manage all components and aspects of a network. DIA makes data requests and retrievals standard across different Unicenter components by providing a generic mechanism that permits the dynamic deployment of necessary files to facilitate the correct monitoring of any given system. Deployment is generic and open to growth. DIA allows for high speed, secure communications to transport data while providing remote node management and inherent failover capabilities. For a detailed discussion of DIA, see the appendix "DIA Reference." Classic Versus Continuous Discovery Discovery is the process by which network devices are found and classified and then placed in the MDB as managed objects. The Agent Technology WorldView Gateway service locates agents running on the network objects. A common set of classification rules lets you tailor your discovery to your environment. Note: An MDB must exist before you can run Discovery to discover your network devices and populate the MDB. Once objects are defined to the database, you can view, monitor, and manage these objects and their Management Information Base (MIB) through the 2D Map, ObjectView, and the Topology Browser. You can manage the entities they represent using Event Management, Manager/Agent Technology, and thirdparty manager applications. When you install your product, decide which type of discovery you want to use: Classic Discovery An on-demand process that lets you decide which subnets you want to discover and when. You can also configure Classic Discovery to run in regular intervals, which can be used as an alternative to Continuous Discovery and ensures that your discovered environment in the MDB is always current. You can start a Classic Discovery from the Discovery GUI, the Unicenter MCC, the Unicenter Browser Interface, or the command line. 60 Implementation Guide Classic Versus Continuous Discovery Continuous Discovery An event-driven and ongoing process. It employs a manager and agents that continuously scan your network in real-time mode for new devices or changes in IP addressing of existing IP devices. You can configure Continuous Discovery for optimal load balancing between the Discovery agents and the Discovery Manager. If you choose this method of discovery, you must install the Discovery Agents and the Discovery Manager. Note: We recommend that you do not use both discovery methods. After a device is under Continuous Discovery control, it should not be discovered with Classic Discovery. Deployment of Discovery Managers Due to its distributed nature, the deployment of managers and agents is very important. Manager granularity primarily depends on the hosting server's capability, which includes memory and processing bandwidths. Since a manager aggregates the agents' subnets, the bandwidth required is directly proportional to the number of subnets and their constituent devices. Discovery Manager granularity may also depend on other factors, such as administrative issues. For example, an enterprise's network may be geographically dispersed and internal domains may exist, such as NA, EMEA, AP, and so forth. It may be appropriate for your enterprise to deploy managers and agents based on these geographical regions. Deployment of Discovery Agents Agent granularity also depends on the agent's hosting server capability. However, additional considerations apply. Discovery employs various nonintrusive methods, such as sniffing and DHCP listening, which enable real-time discovery. These methods require proximity to the events generated; that is, they require close proximity to the hosts making DHCP and ARP requests. To capture these events, an agent must be deployed in that subnet. Therefore, the finest agent deployment granularity that you can achieve is to deploy one agent per subnet. In practice, you may need to compromise to get sufficient coverage. Due to the plausible constraint of deploying an agent in each subnet, you could enable DHCP-based discovery on the Discovery Manager to get wider coverage. In this case, the Discovery Manager must be deployed on the same subnet as the DHCP server. Since a corporate network may have multiple DHCP servers, a plausible scenario may be deployment on the backup DHCP server subnet. However this type of deployment requires changing router configuration regarding helper addresses. Chapter 3: Product Architecture 61 Chapter 4: Architecture Considerations This section contains the following topics: Introduction (see page 63) Current Environment (see page 63) Evolution of the Environment (see page 66) Business Needs (see page 67) Unicenter NSM Requirements (see page 68) Introduction This chapter contains architecture information that you should consider before beginning your Unicenter NSM implementation. Review this chapter carefully to ensure optimal results for your particular environment. A well thought-out architecture is important to a successful production rollout of Unicenter NSM. Current Environment Before designing your Unicenter NSM architecture, you must understand your current technology environment. Start your Unicenter NSM implementation planning by identifying the following aspects of the existing architecture: ■ Hardware and software ■ Network considerations ■ Operating standards and restrictions (security, firewalls, and naming conventions) Hardware and Software To understand the physical architecture of your deployment environment, identify the following information for your current hardware and software: ■ Number, type, and location of computers that will be impacted by this implementation (as user interface clients, managers, managed devices, or installed with the enterprise MDB) ■ The operating system of those computers (including release and maintenance level) Chapter 4: Architecture Considerations 63 Current Environment ■ Major software applications installed on those computers and their corresponding roles (for example, mail server) ■ Available disk space and processor load on those computers ■ Open issues regarding functionality of computers or software You need to understand how the Unicenter NSM deployment will impact the current software applications and how those applications could impact Unicenter NSM. Start by identifying mission-critical applications and computers (the computers, applications, or functions that must be minimally impacted). Your size requirements and various hardware platform capabilities will help determine the placement of the required Unicenter NSM management points. Depending on the components or options you deploy, you can have fewer more powerful computers (database servers) or more less powerful computers (software delivery). Unicenter NSM has the flexibility to allow the housing of multiple components on a single powerful machine or distribution across multiple servers and platforms. In planning your implementation, we highly recommend that you test your proposed configuration in a lab environment before deploying it in your production environment. The lab equipment should mirror, as much as possible, the hardware and software specifications of your production environment. This will help you identify potential problems while the impact is minimal. Know the number of computers, their location, and the bandwidth available between the central and remote locations (especially where other software will use the enterprise MDB)--this is crucial in determining scalability. Keep in mind that low-level functions can run on existing hardware, but it is better to have dedicated hardware for enterprise-level functions. Typically, users connect through administrative GUIs to the higher-level management points; this facilitates better response times (where fewer independent functions are executing concurrently). Network Considerations Your Unicenter NSM implementation will rely on the underlying network infrastructure to function. Ensure that your implementation makes the most efficient and effective use of network resources by understanding the following: Physical and logical layout Learning the physical layout of the network lets you realistically and correctly place Unicenter NSM management functionality. You should also learn the logical aspects (such as LAN segments) and what devices (servers, printers, workstations, and so on) reside on the network so you can plan what you want to manage with Unicenter NSM. 64 Implementation Guide Current Environment Line speed Know the line speed and the backbone (in place and planned) of the network. It may be better to purchase another management server than to upgrade the network, or to overload a WAN connection. Load information Measure the average and peak loads for the network to ensure that the network can support your planned implementation. You must know the underlying technology to determine whether a connection is busy; Ethernet and ATM have widely different capabilities for throughput in a stressed setting. If a connection is stressed, investigate any plans to upgrade or add connections and consider waiting to implement that segment. The distributed nature of Unicenter NSM lets you customize the architecture to provide the right solution. However, you need all the available information to plan the architecture correctly. Operational Standards and Restrictions Understanding the current environment requires knowing the following operating standards: Scheduled downtimes Knowing when a system will be down helps you minimize or eliminate the false alarms that generate when Unicenter NSM cannot detect that system (and the objects it is monitoring on that system). Existing firewalls and which ports are available to open Unicenter NSM and its many options provide tools to both monitor and manage enterprise resources that sometimes span very complex and extensive networks. To perform these tasks, Unicenter can communicate using multiple protocols (TCP/IP, SNMP, and UDP) and multiple communication ports. In cases where agents or other components will be installed outside of a firewall, additional configuration steps are required to minimize the number of ports that must be opened through the firewall. Security restrictions Obtain the necessary passwords and the appropriate authorizations. Failover requirements Determine whether failover or fallback is the operational standard. Failover (the switch from a primary system to a backup system) is configured to perform automatically, while fallback is designated as a manual task. Chapter 4: Architecture Considerations 65 Evolution of the Environment Naming conventions Know the naming conventions for users, computers, directories, jobs, and so on. If no naming conventions are in place, now is a good time to establish them. Evolution of the Environment Besides examining the existing environment, you should also research the evolution of your environment. The addition of new computers, a change in network structure, operating system changes, and the implementation of other software solutions (especially where remote access to the enterprise MDB is required) should all influence your architecture design. For example, if you plan to add many new workstations, plan for an additional management point (provided those workstations require monitoring). If a server you are targeting for MDB installation will also be the target of several processor-intensive software installations, consider selecting a different server. When considering the possibilities, remember to take growth into account. Be aware that your environment is not static and, in most cases, will evolve and grow. An enterprise-scale Unicenter NSM implementation can take over a year to roll out, so you should understand what environmental changes could take place during that time. By using a tiered architecture, you can easily handle change and growth because the environment is split into smaller groups. For example, think of the architecture as having the following levels of responsibility: ■ Enterprise ■ Regional ■ Office If you add a new office, you can replicate (sized appropriately) the office level architecture to the new office. The same is true for the regional offices. Unicenter NSM allows for as many tiers, or levels, as you require, allowing greater flexibility in the implemented solution. 66 Implementation Guide Business Needs Business Needs Determine the business needs you expect to address using Unicenter NSM. For example, you can install Unicenter Software Delivery to manage software installations across multiple computers and multiple sites in a standardized manner. Understanding the need that is driving the Unicenter NSM implementation will help you decide which components to implement and which customizations to make. Once you have implemented Unicenter NSM, this information will provide insight into how to customize the components to optimally monitor and manage your infrastructure. Identify the following: ■ What devices will you monitor or manage? ■ What type of reporting will you require? (Who will need those reports, when will they be needed, and through what medium?) ■ What type of response do you require if a monitored object is unreachable or if you receive specific error messages? ■ What are your security requirements? ■ What are your job processing requirements? ■ Where will administration occur? (If multiple locations are involved, will each location be administered locally or remotely from a central site?) ■ Who will need administrative capabilities? ■ How much of the infrastructure will each administrator handle? Although Unicenter NSM can handle the entire environment, can one administrator handle all alerts, messages, events, and so forth? ■ Who will need informational-only capabilities? ■ How will you provide those capabilities (GUI access)? If you plan to use Unicenter MP technology to give executives high-level access to the environment’s state, what type of activity should they be able to monitor? ■ Who needs automatic notification of the status and state of specific objects? ■ How will notifications occur (email, pager)? ■ Who will be responsible for administering the databases? Note: Unicenter NSM spans multiple disciplines and you may find that there are some subtle, yet critical differences in how different departments approach IT requirements. Chapter 4: Architecture Considerations 67 Unicenter NSM Requirements Deliverables should always be business-related. Create a measurement mechanism for each deliverable, so you can measure the effectiveness of the solution. For example, in a Unicenter Remote Control implementation, the business requirement may be to decrease by 40 percent the time it takes to ascertain why a user cannot print. The business requirement is not to put a Unicenter Remote Control agent on every desktop. That may be the solution, but it is not the business requirement. Without a metric to use as a measure, it will be difficult to pinpoint exactly how the new implementation has improved operations and what areas need improvement. Before deployment begins, verify the project timeline and ascertain if it is realistic without compromising the implementation. Reach an agreement for the implementation plan with all involved parties. We recommend a phased implementation (preceded by technical engineering and policy development in a lab environment) if time allows. Unicenter NSM Requirements The Unicenter NSM readme includes the latest Unicenter NSM requirements. Ensure that you meet these hardware and software requirements before beginning your implementation. 68 Implementation Guide Chapter 5: Installation Preparation This section contains the following topics: Installation Methods (see page 69) Common Unicenter NSM Server Categories (see page 72) Pre-Installation Tasks (see page 78) Installation Methods You can install Unicenter NSM using any of the following methods: ■ Unicenter Product Explorer--Windows ■ setupNSM--Linux/UNIX only ■ Unattended Installation ■ Unicenter Software Delivery ■ Upgrade and Migration Unicenter NSM Product Explorer - Windows The Unicenter NSM Product Explorer starts automatically when you use the Unicenter Network and Systems Management Installation DVD. Using the Unicenter Product Explorer provides the following benefits: ■ The automated process determines your Windows platform and displays the appropriate options. ■ The search feature (or F3) lets you find specific components for installation by title or keyword. ■ The Product Information button lets you reference this guide and the readme during installation. ■ The System Requirements button for each component displays the hardware and software requirements specific to that component. Chapter 5: Installation Preparation 69 Installation Methods setupNSM - Linux/UNIX Unicenter NSM for Linux and UNIX uses the installer setupNSM, which leverages available technology from within the Unicenter brand of products. This installer provides the following capabilities: ■ A Java-based graphical user interface for easy point-and-click selection of Unicenter NSM components ■ Tighter integration with Unicenter Software Delivery for remote deployment of Unicenter NSM components ■ Unattended installation of Unicenter NSM components Unattended Installation Unattended installation is available for Windows, Linux, and UNIX platforms, and lets you use a response file to answer installation questions. You can create the response file by selecting the “Build Unicenter NSM response file for unattended install” option in the Windows setup or by running the Linux or UNIX setupNSM installer with the -a option. Working from the initial Product Explorer dialog (Windows) or the initial setupNSM dialog (Linux/UNIX), you can choose to register response files to define custom installation procedures for Unicenter NSM deployment. To register custom installation procedures of Unicenter NSM, the setup walks you through creating a response file that lets you request the installation of one or more individually selected components, common agent configurations, or all Unicenter NSM components. The response file is a text file that you can edit or customize; it configures all of the options during your installation. This file is ideal for use with Unicenter Software Delivery because no prompts appear during the installation; the answers reside in the response file. See the topic Register Unicenter NSM with Unicenter Software Delivery in the “Installation” chapter and the appendix “CCS UNIX/Linux Reference” for detailed information about response files. 70 Implementation Guide Installation Methods Unicenter Software Delivery Unicenter NSM lets you register Unicenter Software Delivery packages, so that you can automate the delivery, installation, and configuration of Unicenter NSM components across your network. Working from the initial Product Explorer dialog (Windows) or the initial setupNSM dialog (Linux/UNIX), you can choose to register response files to define custom installation procedures for Unicenter NSM deployment. To register custom installation procedures of Unicenter NSM, the setup walks you through creating a response file that lets you request the installation of one, any, or all Unicenter NSM components. Once you create the response file, the complete Unicenter NSM installation image and response file is registered to Unicenter Software Delivery as a single package. You can create multiple response files for embedding in Unicenter Software Delivery to support different types of installations using the same Unicenter Software Delivery package. Unicenter Software Delivery supports a multi-tiered architecture that lets you stage product installation images across the enterprise and invoke the installation from a local software store. Note: You must install Unicenter Software Delivery Enterprise, Local, or Workgroup Server, or an Admin Console to use this installation method. See Register Unicenter NSM with Unicenter Software Delivery in the “Installation” chapter for detailed instructions about this installation method. Start Menu and Installations When upgrading or reinstalling, log on as the same operating system user that performed the first installation. Some aspects of the product, such as the Start Menu folder, are intentionally tailored just to the user that installed the product. In some cases, users may have created the Start Menu items for more users using utilities such as CAUTCFG.EXE. Thus, if you install a prior release as User A and upgrade to a newer release as User B, only the Start Menu icons that User B originally had (if any) will be upgraded for the new product. This is especially important when performing installations through Unicenter Software Delivery, which can run either as SYSTEM or as a particular user. Upgrading a product that was installed under User A through Unicenter Software Delivery that is running under User B (which may be SYSTEM) will cause this condition. Chapter 5: Installation Preparation 71 Common Unicenter NSM Server Categories For information about upgrading and migrating an existing version of this product, see the Migration Guide. For the latest version of the guide, visit http://ca.com/support. After you have logged in, in the left panel under the Downloads topic, select "Documentation." You are directed to an area where you can search for the guide. Common Unicenter NSM Server Categories The categories presented here provide recommended component selection for servers that are typically found in a Unicenter NSM environment. These server descriptions are not intended to be comprehensive or restrictive and some level of adjustment will often be needed to make them specific to your Unicenter NSM infrastructure. Managed Server A Unicenter NSM Managed Server represents a server that is to be monitored by a corresponding Unicenter Monitoring Manager. A server can be monitored either through the deployment of Unicenter Agent Technologies or through Unicenter Remote Monitoring technology. Unicenter Remote Monitoring can perform basic monitoring without requiring any software deployment to the managed server. Unicenter NSM Managed Servers are enabled for monitoring from Unicenter NSM Visualization Servers. Unicenter NSM Agents Unicenter NSM Components Comments Agent Common Services Includes Adaptive Configuration System Agent Log Agent Performance Agents For Windows platforms, these agents are installed through the separate Unicenter Systems Performance installation. Active Directory Agent Windows only WMI Agent Windows only Event Agent Universal Job Management Agent 72 Implementation Guide Install only if you are using the Job Management Option Common Unicenter NSM Server Categories Unicenter NSM Monitoring Manager Unicenter NSM Monitoring Managers represent the core pieces of Unicenter NSM technology. Through interaction with Unicenter NSM Managed Servers, you can manage the entire enterprise with technology such as Advanced Event Correlation, Alert Management, WorldView, Systems Performance, and Remote Monitoring, all tied together by the MDB. You can then monitor the entire enterprise from a central point of control using the Unicenter MCC and Unicenter Reporting technology. Event and Alert Manager Unicenter NSM Components Comments MDB Client/Server The CA Management Database can be local or remote. Unicenter knowledge base Required with the MDB Server Event Manager Alert Management Advanced Event Correlation (AEC) Web Policy Editor Event Management Wireless Messaging Notification Services Server Enterprise Management Provider Job Management Server Unicenter NSM Components Comments MDB Client/Server The CA Management Database can be local or remote, but a local MDB is strongly recommended for the Job Management Server. Unicenter knowledge base Required with the MDB Server Event Manager Event Management Wireless Messaging Job Management Option Enterprise Management Provider Chapter 5: Installation Preparation 73 Common Unicenter NSM Server Categories WorldView Manager Unicenter NSM Components Comments MDB Server The CA Management Database must be local. Unicenter knowledge base Required with the MDB Server. WorldView Manager Must be installed on the MDB Server before any remote WorldView clients can connect to it. WorldView Provider Bridge Repository Service If desired. Continuous Discovery Manager If desired. Notes: Migration of WorldView data from a Unicenter NSM 3.x MSSQL repository during an installation can only be performed when you are installing the WorldView Manager on the MDB Server. A WorldView Admin Client upgrade installation does not allow for migration of WorldView data. See the Migration Guide for more information. Distributed State Machine (DSM) Unicenter NSM Components Comments MDB Client/Server The CA Management Database can be local or remote. The DSM and WorldView on the same machine must share an MDB. This is enforced at install time. Distributed State Machine Unicenter knowledge base Agent Views OS Agent Gateway Agent Technologies DSM Provider 74 Implementation Guide Required with the MDB Server or DSM Common Unicenter NSM Server Categories Unicenter Systems Performance Domain Server For Windows platforms, the Unicenter Systems Performance components are installed through the separate Unicenter Systems Performance installation. For Linux and UNIX platforms, the Unicenter Systems Performance installation is integrated with the Unicenter NSM installer and is a component selection in the Installation Wizard. Unicenter NSM Components Comments Performance Domain Server Typically, there is only one Domain Server machine for an enterprise. Performance Distribution Server Performance Scope Win32s Performance Trend Win 32s Performance Reporting Browser Performance Configuration Win32s Chargeback If desired, Win 32s Performance Tools and Utilities Unicenter Systems Performance Distribution Server For Windows platforms, the Unicenter Systems Performance components are installed through the separate Unicenter Systems Performance installation. For Linux and UNIX platforms, the Unicenter Systems Performance installation is integrated with the Unicenter NSM installer and is a component selection in the Installation Wizard. Unicenter NSM Components Comments Performance Distribution Server Install multiple Distribution Server machines to load-share. Performance Tools and Utilities Chapter 5: Installation Preparation 75 Common Unicenter NSM Server Categories Unicenter Remote Monitoring Manager Unicenter Remote Monitoring provides remote monitoring of Windows, Linux, and UNIX servers without the need for agents. Unicenter NSM Components Comments Unicenter Remote Monitoring The manager must be a Windows server. Unicenter NSM Reporting and Configuration Manager A Unicenter NSM Reporting and Configuration Manager enables reporting on the state of the entire enterprise through Unicenter MP and Dashboard technology. The Unicenter Configuration Manager allows for configuration of Unicenter NSM Managed Servers from a central location and maintains a comprehensive Unicenter knowledge base for configuration data. Reporting/Configuration Manager Unicenter NSM Components Comments Configuration Manager Unicenter knowledge base Required with Configuration Manager System Performance Reporting Web Reports and Dashboards Unicenter Management Portal MDB Server The MDB provides a single, integrated database schema (tables, columns, views, and so forth) for the management data stored by all CA products. The MDB schema ties together data from all IT management disciplines and enables integration between CA products. Management Database Server Unicenter NSM Components Comments MDB Server Local Management Database Unicenter knowledge base Required with MDB Server 76 Implementation Guide Common Unicenter NSM Server Categories Unicenter NSM Components Comments WorldView Manager Required with MDB Server. Must be installed on the MDB Server before any remote WorldView clients can connect to it. Visualization Server The Unicenter NSM Visualization Server represents Unicenter NSM interface technology. The MCC provides a single point of control for visualization and monitoring of events and network topology throughout the entire enterprise. Other less powerful interfaces are also available, as in previous releases of Unicenter NSM, to specifically target WorldView and Agent Technology visualization and monitoring. You can also deploy Unicenter MP and Systems Performance technology for comprehensive reporting. Management Command Center Unicenter NSM Components Comments WorldView Administrative Client Win32s Agent Views Enterprise Management Administrative Client Win32s Notifications Services Client Install if Enterprise Management Administrative Client is to manage remote Unicenter Notification Services installations Advanced Event Correlation Policy Editor Install if Enterprise Management Administrative Client is to manage remote AEC installations Unicenter Browser Interface Browser; install as desired Management Command Center Java; install as desired Unicenter Management Portal Chapter 5: Installation Preparation 77 Pre-Installation Tasks Systems Performance Desktop Applications For Windows platforms, the Unicenter Systems Performance components are installed through the separate Unicenter Systems Performance installation. For Linux and UNIX platforms, the Unicenter Systems Performance installation is integrated with the Unicenter NSM installer and is a component selection in the Installation Wizard. Unicenter NSM Components Comments Performance Scope Win32s Performance Trend Win32s Performance Reporting Browser Performance Configuration Win32s Chargeback If desired; Win32s Pre-Installation Tasks This section includes any pre-installation tasks specific to supported platforms and components. You must perform the pre-installation tasks to ensure a successful implementation. The following supported platforms and components require pre-installation tasks. Windows eTrust Access Control, or any other software that performs similar protections, must be shut down prior to a clean installation or an upgrade of Unicenter NSM. eTrust Access Control protects against unauthorized adds, deletes, or updates to users and usergroups. Unicenter NSM creates users during the installation, such as the nsmadmin and cautil users. Any of these operations can either fail or result in a disabled user. When the installation or upgrade is complete, restart the security software. See the eTrust Access Control documentation for the commands and instructions to stop and start the software. The user or system TEMP environment variable must exist and point to a valid directory with a path name that contains 125 or fewer characters. The TEMP path must be writable and have at least 500 MB of free space. 78 Implementation Guide Pre-Installation Tasks Linux and UNIX You must update certain parameters in the kernel configuration for Unicenter NSM to acquire the required IPC (Inter-process Communication) resources on Linux and UNIX platforms. These values, if not already at required levels, are automatically updated and built into the kernel during installation. Parameter Name Minimum Setting maxfile 8192 msgmax 32768 msgmnb 65535 msgmni 128 semmni 256 semmns 512 semmsl 100 shmmax 536870912 shmmni 512 threads-max 65262 Hostname Limitations If you intend to install CCS or CCS consumers on HP-UX, the hostname should not consist of more than 8 characters. This is a prerequisite for this installation, because HP-UX is unable to recognize hostnames with more than 8 characters. The name of the host on which the Event Agent is running should not consist of more than 15 characters including its domain name, for example, mynsm.mydom.com. Otherwise the CA-opr service does not start. DIA Configuration Before installing Unicenter NSM r11.2, there are several tasks you need to perform to ensure that the Distributed Intelligence Architecture (DIA) is configured to monitor your infrastructure. You must complete these configuration tasks before you begin the installation. For a detailed description of the tasks required to configure DIA, see the section DIA Configuration in the appendix "DIA Reference." Chapter 5: Installation Preparation 79 Pre-Installation Tasks Distributed State Machine (DSM) We recommend that you plan to install each DSM physically close to the resources it will manage. DSMs have a capacity based on polling cycles; if the DSM has to poll across multiple routers, the round-trip time to complete each poll increases. If the round-trip time is excessive, consider decreasing the DSM capacity. The number of objects that a DSM can monitor varies with your hardware specifications. The primary rule used in sizing a DSM for a Windows-based server is based on an Intel architecture using Pentium III (700 MHz) with 512 MB of RAM and 4 GB or more of disk space. We suggest an upper limit of 20,000 managed objects for each Windows-based DSM. Linux or UNIX DSMs may scale to a smaller number of objects. Further tuning, by adjusting polling intervals at the object and class levels, can allow DSMs to run up to 50,000 objects for polling over a local area. DSMs handling this many objects should have more than 1GHz CPU with 1GB RAM or more. If you are polling objects at remote locations over slow connections, we suggest a maximum of 10,000 managed objects; the effective maximum may be less. If you are monitoring more than 100,000 objects with a single DSM, that DSM should be installed on a dedicated server. Note: The number of objects a DSM can monitor depends on the poll interval, the amount of memory on the machine, the number of processes running, the hard drive speed, the connection speeds, the efficiency of the pollsets, and the type of policy running (ATP or DAT/CNF). Use the following guidelines for DSM planning: ■ Always monitor the DSM as a critical device (use dsmMonitor to monitor remote DSMs from a central DSM). ■ Provide sufficient resources for DSMs (50 MB main memory minimum plus more for additional objects). ■ Consider multiple DSMs when monitoring more than 200 hosts. ■ Ensure that polling frequency is reasonable. ■ Ensure that all DSMs report to a specific MDB. ■ Locate DSMs as close as possible to their monitored devices to avoid unnecessary network load. 80 Implementation Guide Pre-Installation Tasks Installation Considerations Consider the following items when you are preparing to install your DSM: ID and Password During the installation procedure, you may be required to provide a user ID and password for the agent. For example, if the agent requires a database administrator ID, use that administrator ID and password. This practice prevents other users from disabling the agent or changing the ID and password. The ID remains available for use by the related agent so that the information can be accessed from the database server. The information you provide is stored in a secure manner specific to the subject agent. DSM Installation Consideration The file Install_Path/SC/CCS/AT/services/bin/awservices is a script that starts and stops Agent Technology services. In that script, the Agent Technology SNMP Gateway is started using the following command: aws_snmp -t <port_number> If you encounter a port conflict (where the SNMP Gateway and some other code both require access to the default port of 162), start aws_snmp on another port using the -t operand as previously shown. Verify Trap Socket Number Definitions Traps may be sent to as many machines (ports) as appropriate for your installation. When agents send traps intended to be received by the SNMP Gateway, the target port number designated should be the same number to which the aws_snmp daemon has been instructed to bind. Previous Method: Editing the following configuration file configures the destination of traps: Install_Path/SC/CCS/AT/services/config/aws_sadmin/aws_sadmin.cfg New Method: If there are any DSM entries in the file aws_sadmin.cfg, those entries are used to configure traps to be sent to those DSMs. Otherwise, an entry in the atmanager.ini file (AutoConfig Trap Destination=yes) automatically configures a DSM to notify the system administrator of each host machine that it is listening to. This setting resides on the DSM side, so nothing on a monitored host would need to be modified. Chapter 5: Installation Preparation 81 Pre-Installation Tasks Monitoring for z/OS Use the sections that follow to help you perform all necessary pre-installation tasks for the Monitoring for z/OS feature of Unicenter NSM. CAIRIM for License Authorization Each z/OS agent uses CAIRIM, the Resource Initialization Manager, for product license authorization. Many CA z/OS products share CAIRIM features and functions, which prepares your z/OS operating system environment for your CA products and components and executes them. CAIRIM routines are grouped under CA MVS Dynamic Service Code S910. Review the CA Common Services for z/OS and OS/390 Administrator Guide for more information about the features and associated utilities of CAIRIM. The CA License Management Program To initialize correctly, the agents require the CA License Management Program (LMP). CA LMP also provides a standardized and automated approach to the tracking of licensed software. CA LMP is provided as an integral part of CAIRIM. Once CAIRIM has been installed, assistance is available to you for all CA LMP-supported products. To authorize the agents through the LMP facility, you must install CAIRIM, activate LMP, and then code LMP statements. For details, see the CA Common Services for z/OS and OS/390 Administrator Guide. LMP Key Certificate Information Examine the CA LMP Key Certificates you received with the installation and maintenance tape for the Monitoring for z/OS feature. Your certificate contains the following information: Product Name Specifies the trademarked or registered name of the product as licensed for the designated site and CPUs. Product Code Specifies a two-character code that corresponds to the agent. 82 Implementation Guide Pre-Installation Tasks Supplement Specifies the reference number of your license for the product in the format nnnnnn - nnn. This format differs slightly inside and outside North America, and in some cases may not be provided. CPU ID Specifies the code that identifies the specific CPU for which installation of the product is valid. Execution Key Specifies an encrypted code required by CA LMP for the installation of the product. During installation, it is referred to as the LMP Code. Expiration Date Specifies the date your license for the product expires. It is in the format ddmmmyy, as in 15JAN04. Technical Contact Specifies the name of the designated technical contact at your site responsible for installation and maintenance of the product. This is the person to whom CA addresses all CA LMP correspondence. MIS Director Specifies the name of the Director of MIS or the person who performs such a function at your site. If the title but not the individual’s name is indicated on the certificate, you should supply the actual name when correcting and verifying the certificate. CPU Location Specifies the address of the building where the CPU is installed. Chapter 5: Installation Preparation 83 Pre-Installation Tasks LMP Code Specification You must add the CA LMP Execution Key provided on the Key Certificate to the CAIRIM parameters to ensure proper initialization of the agents. To define a CA LMP Execution Key to the CAIRIM parameters, modify the KEYS member in CAI.PPOPTION. The parameter structure for the KEYS member is as follows: PROD(pp) DATE(ddmmmyy) CPU(tttt-mmmm/ssssss) LMPCODE(kkkkkkkkkkkkkkkk) pp (Required) Specifies the two-character product code. This code agrees with the product code already in use by the CAIRIM initialization parameters for any earlier versions of the product (if applicable). Values for pp are as follows: IU Represents the z/OS System agent. IY Represents the CICS agent. ddmmmyy Specifies the CA LMP licensing agreement Expiration Date. tttt-mmmm (Required) Specifies the CPU type and model on which CA LMP is to run (for example, 3090-600). If the CPU type and or model require less than four characters, blank spaces are inserted for the unused characters. ssssss (Required) Specifies the serial number of the CPU on which CA LMP is to run. kkkkkkkkkkkkkkkk Specifies the execution key needed to run CA LMP. This CA LMP execution key is provided on the key certificate shipped with each CA LMP software solution. For a full description of the procedure for defining the CA LMP Execution Key to the CAIRIM parameters, see the CA Common Services for z/OS and OS/390 Administrator Guide. 84 Implementation Guide Pre-Installation Tasks Unicenter CA-SYSVIEW Server Installation If you are installing the Monitoring for z/OS feature for the first time, install the Unicenter CA-SYSVIEW Server before installing Unicenter NSM. See the Unicenter CA-SYSVIEW Realtime Performance Management Server Getting Started guide for instructions on installing the Unicenter CA-SYSVIEW Server. If you are installing the Monitoring for z/OS feature in an environment that contains an existing Unicenter CA-SYSVIEW installation (operating at a minimum release level of 7.7 SP1), or you are installing on top of an existing copy of the System, CICS, or MQ Series agents (operating at a minimum release level of 3.3), you do not need to install the Unicenter CA-SYSVIEW Server. Use the procedures that follow to prepare an existing Unicenter CA-SYSVIEW or z/OS agent installation for proper operation. Note: If you are running a version of Unicenter CA-SYSVIEW older than 7.7 SP1, you must upgrade before installing the Monitoring for z/OS feature. Reassemble and Link the Unicenter CA-SYSVIEW GEN Module For the Monitoring for z/OS agents to operate with an existing Unicenter CASYSVIEW or z/OS agent installation, you must reassemble and relink the Unicenter CA-SYSVIEW GEN module. To reassemble and link the Unicenter CA-SYSVIEW GEN module 1. Update the INST0005 member, which is in the sysview.INSTLIB data, so that the GEN parameter FEATURE= includes the SERVER option. If you use the Unicenter CA-SYSVIEW installation with the Monitoring for z/OS feature across multiple systems, you must update the GEN module for each system. 2. Submit the INST0005 job. 3. Ensure that all job steps complete with a condition code of 0. Chapter 5: Installation Preparation 85 Pre-Installation Tasks Disable the Previous Release The following applies only if you are currently running a previous release of the z/OS system or CICS agents. To disable the previous release 1. Set the UNICENTER-CICS-AGENT parameter of the sysview.PARMLIB (CICSOPTS) member to NONE to disable the previous release of the CICS agent. 2. Set the UNICENTER-MVS-AGENT parameter of the sysview.PARMLIB(MVSAGENT) member to NONE to disable the previous release of the z/OS System agent. Important! The changes do not take effect until the Unicenter CA-SYSVIEW CICS XPFS transaction and the MVSDATA tasks have been recycled. Enable the MVSDATA Task For the Monitoring for z/OS feature to collect data from Unicenter CA-SYSVIEW or CA-SYSVIEW Server, the MVSDATA task must be enabled and running. If you have a previous release of the z/OS and CICS agents, this task will already be enabled. ■ For CA-SYSVIEW, add the following line to the sysview.PARMLIB (SYSVIEW) member to enable the MVSDATA task: START MVSDATA ■ For CA-SYSVIEW Server, add the following line to the sysvserv.PARMLIB (SYSVSERV) member to enable the MVSDATA task: START MVSDATA Enable the CICS Logger Task To collect data from Unicenter CA-SYSVIEW or CA-SYSVIEW Server using the Monitoring for z/OS CICS agent, the CICSLOGR task must be enabled and running. If you have a previous release of the CICS agent or the Unicenter CASYSVIEW CICS option is turned on, this task will already be enabled. ■ For CA-SYSVIEW, add the following line to the sysview.PARMLIB (SYSVIEW) member to enable the CICSLOGR task: START CICSLOGR.CICSLOGR ■ For CA-SYSVIEW Server, add the following line to the sysvserv.PARMLIB (SYSVSERV) member to enable the CICSLOGR task: START CICSLOGR.CICSLOGR 86 Implementation Guide Pre-Installation Tasks Unicenter Systems Performance Both of the following components run on Windows, Linux, and UNIX: Performance Domain Server Defines and manages a Systems Performance Domain. This service provides Systems Performance applications with accessibility to the performance data gathered by the Performance Agents registered in the domain and also manages all of the configuration information pertinent to the operation of those Performance Agents. Each Systems Performance Domain contains only one Systems Performance Domain Server. Performance Distribution Server Allows the Systems Performance Domain Server to scale effectively. Multiple instances of this service can be installed across the servers in your network (one instance per server) to provide rapid access to performance data and high levels of scalability for Performance Agent configuration operations. Each one of these services forms a node in the Performance Data Grid. These nodes communicate with each other to share the performance data stored in their local Performance Cube Store and collaborate to fulfill requests for performance data made by Systems Performance applications. Before installing Unicenter Systems Performance, you must check the following: ■ ■ For connections to a Performance Domain Server, ensure that: – The Performance Domain Server is running. – The computer running the Performance Domain Server is in the repository. The remote admin client must be at or above the level of the server to which it attaches. Unicenter for Pocket PC Before installing Pocket PC, complete the following pre-installation tasks: ■ Ensure that the Pocket PC device is configured to communicate over the wireless LAN. The most widely used connectivity option is a wireless LAN card using 802.11b. See your Pocket PC vendor for compatible wireless solutions. ■ Identify an existing Unicenter NSM Windows server that hosts Unicenter NSM Enterprise Management. Any Windows server running any combination of Unicenter NSM Enterprise Management can manage Pocket PC devices. Chapter 5: Installation Preparation 87 Pre-Installation Tasks ■ Name your device. Each Pocket PC managed by Unicenter NSM must have a unique device ID. To name your device, follow these steps: 1. Select the System menu. 2. Select Settings, System, About. 3. Select the Device ID tab. Unicenter Management for MOM Unicenter Management for MOM (MOM Management) requires the following pre-installation tasks: ■ Install a patch that enables MOM Management to recognize MOM agent computers. ■ Set up an account for installation and discovery. ■ Set up the Unicenter Management for MOM runtime account. Note: Both the WorldView and Event Managers must be installed before installing Unicenter Management for MOM. Install Patch for Recognizing MOM Agent Computers If you are running Microsoft Management for MOM 2005, you need to install a patch that enables MOM Management to recognize MOM agent computers. The patch updates the MSFT_Computer class of Microsoft SQL Server. For step-by-step instructions, see the Knowledge Base article 888197 on support.microsoft.com. Set Up an Account for Installation and Discovery The user account for installing Unicenter Management for MOM and for running Unicenter Management for MOM Discovery must have the following privileges: ■ Membership in the Administrators group on the Unicenter Manager node ■ User right to “Act as part of the operating system” Note: The domain administrator or domain user account for collecting MOM information, installing Unicenter Management for MOM, and discovery must be same account used for installing Unicenter NSM. 88 Implementation Guide Pre-Installation Tasks To apply the privilege “Act as part of the operating system" 1. On the Unicenter NSM Manager node, choose Start, Settings, Control Panel, Administrative Tools, Local Security Policy. The Local Security Settings window opens. Note: You can also give domain administrators this privilege on the primary domain controller. Choose Start, Settings, Control Panel, Administrative Tools, Domain Security Policy. 2. Expand Local Policies, and click User Rights Assignment. The user rights appear in the right pane. 3. Double-click Act as part of the operating system. Add the user name to the list, and click OK. The user account now has the “Act as part of the operating system” privilege. Set Up the MOM Management Runtime Account Unicenter Management for MOM requires a user account for collecting MOM information. Use a domain administrator or domain user account that can access MOM information throughout the domain. The installation prompts you for this user name and password. The account needs the privilege “Log on as a service” on the Unicenter Manager. If you use a domain user account, it also needs to be a member of the Administrators group on the MOM server. Note: The account for collecting MOM information can be the same account used for installing MOM Management and running MOM Discovery. To apply the privilege “Log on as a service” to a domain administrator or domain user account 1. On the Unicenter NSM Manager node, choose Start, Settings, Control Panel, Administrative Tools, Local Security Policy. The Local Security Settings window opens. Note: You can also give domain administrators and users this privilege on the primary domain controller. Choose Start, Settings, Control Panel, Administrative Tools, Domain Security Policy. 2. Expand Local Policies, and click User Rights Assignment. The user rights appear in the right pane. 3. Double-click Log on as a service. Add the user name to the list, and click OK. The account now has the “Log on as a service” privilege. Chapter 5: Installation Preparation 89 Pre-Installation Tasks To apply administrative privilege to a domain user account 1. On the MOM server, open Control Panel, Administrative Tools, Computer Management. The Computer Management window opens. 2. Expand Local Users and Groups, and click Groups. The groups appear in the right pane. 3. Double-click Administrators, add the domain user name to the list, and click OK. The domain user account becomes an administrator. CA System Center Operations Manager Integration CA System Center Operations Manager Integration (SCOM Integration) requires the following pre-installation tasks: ■ Set up an account for installation and discovery. ■ Set up the SCOM Integration runtime account. ■ Install the Microsoft System Center Operations Manager Console Client Note: Both the WorldView and Event Managers must be installed before installing SCOM Integration. Set Up an Account for SCOM Installation and Discovery The user account for installing the SCOM Integration and for running SCOM Discovery must have the following privileges: ■ Membership in the Administrators group on the Unicenter NSM Manager node ■ Permission to "Act as part of the operating system" Note: The domain administrator or domain user account for collecting SCOM information, installing SCOM Integration, and discovery must be same account used for installing Unicenter NSM. To apply the privilege "Act as part of the operating system" 1. Choose Start, Settings, Control Panel, Administrative Tools, Local Security Policy on the Manager node. The Local Security Settings window opens. Note: You can also give domain administrators this privilege on the primary domain controller. Choose Start, Settings, Control Panel, Administrative Tools, Domain Security Policy. 90 Implementation Guide Pre-Installation Tasks 2. Expand Local Policies, and click User Rights Assignment. The user rights appear in the right pane. 3. Double-click Act as part of the operating system. Add the user name to the list, and click OK. The user account now has the "Act as part of the operating system" privilege. Set Up the SCOM Integration Runtime Account SCOM Integration requires a user account for collecting SCOM information. Use a domain administrator or domain user account that can access SCOM information throughout the domain. The installation prompts you for this user name and password. The account needs the privilege "Log on as a service" on the Unicenter Manager. If you use a domain user account, it also needs to be a member of the Administrators group on the SCOM server. Note: The account for collecting SCOM information can be the same account used for installing SCOM Integration and running SCOM Discovery. To apply the privilege "Log on as a service" to a domain administrator or domain user account 1. On the Unicenter NSM Manager node, choose Start, Settings, Control Panel, Administrative Tools, Local Security Policy. The Local Security Settings window opens. Note: You can also give domain administrators and users this privilege on the primary domain controller. Choose Start, Settings, Control Panel, Administrative Tools, Domain Security Policy. 2. Expand Local Policies, and click User Rights Assignment. The user rights appear in the right pane. 3. Double-click Log on as a service. Add the user name to the list, and click OK. The account now has the "Log on as a service" privilege. Chapter 5: Installation Preparation 91 Pre-Installation Tasks To apply administrative privilege to a domain user account 1. On the SCOM server, open Control Panel, Administrative Tools, Computer Management. The Computer Management window opens. 2. Expand Local Users and Groups, and click Groups. The groups appear in the right pane. 3. Double-click Administrators, add the domain user name to the list, and click OK. The domain user account becomes an administrator. Unicenter Remote Monitoring The processor on the Unicenter Remote Monitoring agent computer needs to be powerful because it analyzes the data for each monitored resource to determine whether an error has occurred. The advantage to this method is minimal CPU and memory impact on your production environment. Before installing the component, review the following tasks to ensure that your system is ready. In the Agent checklist, verify the following: ■ The WorldView Manager or Client is installed. If Client, the WorldView Manager must be installed on another machine in the environment. ■ The Remote Administrative Client is installed. In the Administrative Interface checklist verify that a DIA client (DNA) is present. Security Considerations You must install the Unicenter Remote Monitoring agent using an administrator account and password. When configuring a Windows resource for monitoring, you can use the service administrator account or you can provide the agent with specific credentials to use instead. Linux, UNIX, and Mac OS X resources are monitored using remote shell (rsh) or secure shell (ssh). The Unicenter Remote Monitoring agent includes a secure shell client for accessing your remote Linux, UNIX, and Mac OS X computers, but you must provide the secure shell daemon on each of the target computers. The Unicenter Remote Monitoring agent connects to remote Linux, UNIX, and Mac OS X systems using a non-privileged user account that must have write access to its home directory. 92 Implementation Guide Pre-Installation Tasks Highly Available Installations Pay particular attention when configuring Microsoft SQL Server and this product in a cluster environment. The installation of Microsoft SQL Server creates a network name inside the resource group that you selected for installation. If there is already a network name in that resource group, the result is two or more network names. Resource groups with more than one network name or more than one IP address are not supported by this product. Ensure that the target resource group has only one network name and one IP address. Other Software Considerations We strongly recommend that you update all other installed software products to their latest maintenance levels. It is particularly important to update all virus scanning products so they can properly detect the newest viruses and prevent known false alarms. Furthermore, be aware that some virus scanners may cause problems during product installation, runtime operation, and/or uninstallation. For example, an installation wizard, when finished installing, may be unable to clean up its files in the %TEMP% directory tree if a virus scanner has one or more of those files locked. Other more severe problems may occur if this happens during product installation or operation. Chapter 5: Installation Preparation 93 Chapter 6: Installation Note: If you have not reviewed the information in the previous chapters, do so before proceeding. This section contains the following topics: Installation Overview (see page 95) Install Unicenter NSM on Windows (see page 111) Install Unicenter NSM on Linux or UNIX (see page 119) Install CA Common Discovery (see page 133) Register Unicenter NSM with Unicenter Software Delivery (see page 141) Install Unicenter Systems Performance (see page 145) Install Unicenter NSM Systems Performance on Windows (see page 146) Install Active Directory Management (see page 147) Install Monitoring for z/OS Interface (see page 156) Install Unicenter Management Portal (see page 163) Install Unicenter for Pocket PC (see page 164) Installation of Unicenter Management for MOM (see page 165) Installation of the CA System Center Operations Manager Integration (see page 167) Install Unicenter Cisco Integration (see page 169) Install TrapManager (see page 170) Install Unicenter Remote Monitoring (see page 172) Install the SPECTRUM Integration Kit (see page 174) Uninstall Individual Components (see page 187) Installation Overview Before starting a Unicenter NSM installation, we strongly recommend that you shut down all application software, most specifically other CA software, to prevent files from being in use, thus requiring the new software installation to schedule a restart of the system to replace those files that are in use. It is critically important that you use all proper mechanisms provided by other software or the operating system to shut down these applications and services. Killing processes and applications in Task Manager may cause breakage to those other applications and possibly leave them in an unstable state. Additionally, some applications may detect that services they use are unexpectedly gone and try to restart them again, perhaps causing still further problems. When you install a Unicenter NSM component on a computer, the Welcome and End User License Agreement (EULA) screens appear. You must respond to the EULA before continuing with an installation. Use the Unicenter component selection menus to select one or more components for installation. Chapter 6: Installation 95 Installation Overview Installing Unicenter NSM on any individual machine is normally done either from CA-supplied media, such as a DVD, or from a Unicenter Software Delivery process. You can also copy the CA-supplied media to your hard drive and install from there, whether locally or from a remote network share. In this case, be careful that you do not alter the image in any way. Changes such as resetting or altering file attributes such as the read only, hidden, or other attributes using attrib, attrib /S, or Windows Explorer and changing the case of file names and directories are all unsupported actions and can cause installation or runtime failures in the product. You must also carefully control write access to any hard drive copy of the installation files to avoid inadvertent changes by individuals and to protect the files from viruses or other malware infections that could then further propagate during future installations from the affected image. Placing the image on a read only share is supported so long as the attributes of the files and directories remain as originally copied from the CA-supplied media. Operating System Dependencies This product cannot be installed properly if either of the following conditions are true: ■ Windows Installer is not correctly installed or not fully operational, or the service is disabled. ■ The Windows Service Control Manager database is locked. Maximum Operating System PATH Lengths The different versions of Microsoft Windows Operating Systems have different maximum system PATH lengths. ■ ■ 96 Implementation Guide The following Windows versions support a maximum of only 1024 characters: ■ Windows 2000 unless hotfix Q180410 is applied ■ Windows XP unless Service Pack 2 or higher is applied ■ Windows 2003 unless Service Pack 1 or higher is applied Newer versions and service packs of Windows provide support for a maximum of 2048 characters Installation Overview This product uses a portion of the available system PATH space depending on which components and how many components you select to install. If the components and destination install paths that you select exceed the available system PATH space, the installation warns you of this and will not proceed. In this case, you must do one of the following: ■ Upgrade the operating system to achieve 2048 character support ■ Select shorter destination install paths ■ Select fewer components for installation Special Character Support Note: In this section, "ASCII alphanumeric" refers to the following characters: A-Z, a-z, and 0-9. Unicenter NSM does not support localized characters in the computer name, Microsoft SQL Server instance name, installation source media/response file or destination paths, user names, or password fields. It does support the following set of characters with any frequency, pattern, or ordering of those characters for those fields as specified here: ■ Computer name: ASCII alphanumeric and hyphen (-). Underscores and other special characters are commonly used by Microsoft Windows operating environments but are not allowed in RFC-952 even with the looser restrictions of RFC-1123. Their use can cause problems in systems that communicate over the network, or even locally when an application uses network related functions. This is true even if your network is using the Microsoft DNS Server or no DNS server at all. Some versions of Microsoft Windows block the use of non-standard characters into the computer name in their administrative GUIs, or they present warnings about the ramifications of their use. Still, the Win32 SetComputerName API lets you get around some of those blocks. Although adding IP address/computer name aliases into the \etc\hosts file of each computer may correct some problems you may encounter while using non-standard characters or names not allowed by the DNS standard, the deployment of Unicenter NSM in such an environment is not supported. For more information, review Microsoft Article 909264 and the documentation for the SetComputerName Win32 API. ■ Microsoft SQL Server Instance Name: ASCII alphanumeric ■ Installation source media/response file path: ASCII alphanumeric, hyphen (-), underscore (_), period (.), open bracket ([), close bracket (]), space ( ), and dollar sign ($). Chapter 6: Installation 97 Installation Overview ■ Installation destination path: ASCII alphanumeric, hyphen (-), underscore (_), period (.), tilde (~), and space ( ). ■ System %TMP% and %TEMP% path: ASCII alphanumeric, hyphen (-), underscore (_), period (.), open bracket ([), close bracket (]), tilde (~), space ( ), and dollar sign ($). Unsupported characters can exist in these variables if your logged on user name contains such characters or because you have otherwise manually defined them this way. In this case, change these system environment variables to contain characters meeting these restrictions. Note: The installation source media/response file path, installation destination path, and system %TMP% and %TEMP% paths cannot start with a space ( ), end with a space, or contain the string "$$". The colon (:) character is supported only when it immediately follows the name of an existing disk drive as part of a path specification such as "C:\". The backslash (\) character is supported only as a path separator of directory levels. In addition, the installation source media path cannot have a directory that ends with a space or contain any of the following characters: /*?<>|"%,=&@^!~()#;> ■ User name: ASCII alphanumeric, hyphen (-), underscore (_), pound or hash sign (#), and dollar sign ($). ■ Passwords: No character restrictions except that passwords cannot contain localized characters. Note: Also review the section called Using Semicolons in Microsoft SQL Server Login Passwords under Known Issues in the Readme file. Other Installed Software We strongly recommend that all other installed software products be updated to their latest maintenance levels. Some Microsoft and other third-party issues are documented in the Known Issues section of the Readme file. ■ It is of particular importance to update all virus scanning products so that they can properly detect the newest viruses and prevent known false alarms. ■ For optimal integration with CA eTrust Antivirus, use the version shipped with this media to upgrade any existing installation if you select Event Management or the Event Agent for installation. If this upgrade is not performed, when Event Management launches the default Midnight message record action for virus scanning, thousands of "File filename has been skipped from Antivirus scanning" messages may appear in your console log, which is different behavior than previous releases of this product. 98 Implementation Guide Installation Overview ■ For correct integration with Unicenter Service Desk 6.0, the following Service Desk patches must be applied: QO43395 and QO57381. ■ If you want to install Unicenter NSM r3 or r3.1 for NetWare from a system with this product's r11 or r11.1 versions installed, you must preapply QO79868 or a similarly appropriate fix to your Unicenter for NetWare product install media. ■ This release contains DIA performance enhancements and better integration with Agent Technology. In a mixed environment where r11 and r11.1 installations both exist, the r11 systems must be patched with the corresponding performance enhancements. Not patching those systems could cause performance degradation on the r11.1 systems. As of the publishing of this document, the patches are QO81842 and QO81837 (Windows), QO81843 and QO81838 (Linux), QO81844 and QO81840 (Solaris), QO81846 and QO81841 (HP-UX), and lastly QO81845 and QO81839 (AIX). For the latest versions, go to SupportConnect at http://supportconnect.ca.com. Microsoft SQL Server Considerations Unicenter NSM requires that Microsoft SQL Server installations have the TCP/IP network protocol enabled and operational. See the Microsoft SQL Server documentation for information on how to choose and configure network protocols. When establishing connections between a local Microsoft SQL Server (DBMS or Client) and a remote Microsoft SQL Server DBMS, the default network library settings of the local and remote installations must be compatible. For example, you can use "TCP/IP" on both sides. If the Microsoft SQL Client configurations are not compatible, you may receive connection errors during the installation process. There are many reasons why you may not be able to connect to a remote Microsoft SQL Server. One solution you can try using to establish connections to remote named instances follows. When connectivity problems exist, command line Microsoft SQL Server tools may also fail to connect and perhaps generate the following error message: SQL Server does not exist or access denied. ConnectionOpen (Connect ()). Chapter 6: Installation 99 Installation Overview One solution you can try using to establish connections to remote named instances when receiving this error message is as follows. To connect to a remote Microsoft SQL Server 1. On the Start menu, select Programs, Microsoft SQL Server, then click Client Network Utility. The Client Network Utility dialog appears. 2. If TCP/IP is not already present under Enabled protocols, follow Steps 3, 4, and 5. If TCP/IP is present, go to the Alias tab, Step 6. 3. Configure a client to use TCP/IP. 4. Click the General tab, then click Add. The Add Network Library Configuration dialog box appears. 5. Click TCP/IP. 6. Click the Alias tab, then click Add. The Add Network Library Configuration dialog box appears. 7. Under Network libraries, select TCP/IP network library. 8. In the Server alias box, enter the alias of the instance of Microsoft SQL Server listening on the Windows Sockets Net-Library to which you want to connect. 9. Specify exactly the full instance name of the Microsoft SQL Server to which you want to connect (for example, Servername\Instancename) and which listens for TCP/IP Sockets clients. With TCP/IP, you also can specify the server with its IP address instead of its name. 10. Clear the Dynamically determine port check box to set the port manually. 11. Type the port number of the Microsoft SQL Server instance from the remote machine in the Port number box. To get the port number from the remote server 1. On the Start menu, select Programs, Microsoft SQL Server, then click Server Network Utility. The Server Network Utility dialog appears. 2. Under Enabled protocols, select TCP/IP, then click Properties. 3. Note the value of the default port. Use this number to configure the clients also. 100 Implementation Guide Installation Overview In general, if you experience difficulty with Unicenter NSM connecting to a Microsoft SQL Server instance, always try the native Microsoft SQL Server tools themselves to ensure that they can connect. If the Microsoft SQL Server client software is unable to connect to the remote instance, it is very likely that CA software will not be able to connect either. See Microsoft article 328306 and other articles for some of the common causes of connectivity problems. When receiving this error message from the Microsoft SQL Server command line tools, the Unicenter NSM Installation Wizard may also report "connect failed" on the Database Selection dialog, though it may report this for other failures also. CA MDB and Raw Partitions You cannot install the MDB into a Mircosoft SQL Server instance where the default data files are created on a raw partition. Microsoft SQL Server Browser Service When using the Installation Wizard, you may not be able to select configuration of an MDB that already exists in a Microsoft SQL Server installed image on your system. The following message indicates the reason: "There is no MDB that is both installed and active that can be configured" If you receive this message, confirm that the Microsoft SQL Server Browser Service is running on that system. The service enables this product to find the existing MDB. In addition, various interfaces of this product may offer a Browse button so that all existing Microsoft SQL Server installed images are found and listed. The accuracy and completeness of the data in resulting dialogs may be affected by a number of conditions, including at least the following: ■ The Master Browser is updated only periodically, and may not know about all of the active Microsoft SQL Servers at the time the browse request is issued. ■ This product may indicate that a given Microsoft SQL Server exists, but when you try to list available instances for it, a message may appear indicating no instances exist. If this occurs, confirm that the Microsoft SQL Server Browser Service is running on that server. Chapter 6: Installation 101 Installation Overview IPv6 Support Over MDAC Communication between the Systems Performance and WorldView database layers and the MDB occurs through SQLOLEDB, which uses the Microsoft Data Access Components (MDAC) for the underlying communication with Microsoft SQL Server. As MDAC does not support IPv6 on Windows Server 2003 or Windows XP, the database application layer cannot support IPv6 addresses to connect to the database. We recommend that you use the host name or an IPv4 address to connect to the database on these platforms. This applies to the MDB hostname field in the Systems Performance installer. Reserved Database User Names When defining database user names for the MDB, there are a number of reserved names that cannot be used for the nsmadmin ID. This is because either the database you install, Microsoft SQL Server or Ingres, or the CA MDB has reserved them. The list of reserved names is as follows: MDB Users, Roles, or Groups aiadmin emadmin uapmadmin_group aionadmin_group emuser uapmbatch_group aipublic harvest_group uapmreporting_group amsgroup harvest_rep ucmadmin apmadmin icanbill_group ucmuser apmuser icancommon_group udmadmin_group apnm_admin infopump_admin ujoadmin apnm_user infopump_user umpadmin apwmv_admin jmoadmin umpuser apwmv_user jmouser uniadmin asmoadmin pdadmin uniuser asmouser pduser upmadmin_group backup_admin_group portaldba_group upmuser_group ca_itrm_group regadmin usmgroup cmew_admin sccadmingroup workflow_admin_group cmew_rdr sccusergroup workflow_ro_group dms_backup_group service_desk_admin_group wsm_admin_group 102 Implementation Guide Installation Overview dsaadmin service_desk_d_painter_ group wsm_ro_group dscadmin service_ro_group wvadmin dscuser siadmins wvuser MS SQL System Users dbo guest MS SQL Server (Reserved System) Roles bulkadmin processadmin setupadmin dbcreator securityadmin sysadmin diskadmin serveradmin MS SQL Database (Reserved) Users or Roles db_accessadmin db_ddladmin db_securityadmin db_backupoperator db_denydatareader public db_datareader db_denydatawriter db_datawriter db_owner MS SQL 2000 MSDB-Specific Roles RepositoryUser TargetServerRole PostgreSQL Users postgres nsmadmin mdbadmin Database Configuration Considerations If you choose to install one or more components (such as Event Management and WorldView) that require a database management system (DBMS) and an MDB, the Installation Wizard interview asks you to specify on the Database Selection and Configuration dialog which database the components should use. You can choose to have the components use the same DBMS instance or you can specify that they use different instances. If you have installed other CA products on your system, you may already have an MDB. Although it may be installed, the MDB does not appear in bold in the Component Selection dialog of the Unicenter NSM Installation Wizard. The MDB component appears bold in the dialog only if you installed it by using Unicenter NSM or if you configured an existing instance that was installed by some other product for use by Unicenter NSM. Chapter 6: Installation 103 Installation Overview The reasons to configure an existing instance prior to Unicenter NSM physically using it are as follows: ■ Unicenter NSM must ensure that settings for memory, connection limits, and other parameters necessary to support it are large enough. ■ Unicenter NSM installation must create a nsmadmin ID in the database that has the proper access permissions to the MDB table space that the product requires. ■ The supporting infrastructure that Unicenter NSM requires must be installed on the MDB server. In situations where an existing MDB is present, you can choose to configure that MDB for use by Unicenter NSM or you can install a new one. We recommend that you configure the existing MDB to preserve system resources and enable better integration of data across products. Once you have configured an instance of the MDB for use by Unicenter NSM, or installed a new one, you do not need to configure any others on this system. Therefore, the configuration option is disabled for future installations. MDB installations are one-time selections. This means that once an instance is either configured or newly installed for use with Unicenter NSM, this product's installation is tied to that instance and can be changed only by uninstalling the product. You can, however, adjust runtime settings on particular components, such as Event Management and WorldView, to point them to different instances on remote machines that Unicenter NSM has similarly configured. If you have an existing instance of the MDB that is of a newer version than what is shipped on the Unicenter NSM media, you are only able to configure the MDB instance for use by Unicenter NSM. Never install the MDB from the Unicenter NSM media on top of the existing newer version. If you require a reinstall or repair operation of the newer version, use the media that shipped it. Of course, you could simply install a new instance of the version shipped with Unicenter NSM rather than configure the newer, pre-existing instance. The configuration option has the following restrictions: ■ The option does not install an MDB into an existing database instance. It solely configures a locally existing MDB for the needs of this particular product. ■ The option applies only to local installations. It cannot configure an existing remote database with an existing MDB. 104 Implementation Guide Installation Overview To use an existing MDB of the same database type that this product supports, whether local or remote, you must use the configure operation provided in the Installation Wizard to configure that MDB for use by this product. As stated in this topic, and shown in the Installation Wizard's Component Selection dialog, the configure operation can be performed only on a local MDB. Therefore, if you want to use an existing remote MDB, you must first run this product physically on that remote machine to configure it. Once this is done, you can have any number of other machines point to that existing remote MDB. Security Considerations Unicenter NSM security provides approximately 100 rules, nine roles or user groups, and about 100 asset types out-of-the-box. Unicenter NSM provides embedded security, which is a DENY mode security engine that, by default, is turned on. The following components use Unicenter NSM embedded security, if it is enabled: ■ Calendar Management ■ Embedded Security (can protect itself) ■ Job Management Option ■ Alert Management ■ Notification Services ■ Agent dashboards ■ Web Reporting Service ■ Unicenter Configuration Manager ■ Management interfaces, which include Management Command Center, Event Management, Unicenter Management Portal, Unicenter Browser Interface, and Unicenter for Pocket PC (logon only) While selecting components in the Installation Wizard for Unicenter NSM, consider clearing the Express check box if you want to customize the installation for tighter security. By clearing this installation option, you are able to explicitly specify more user names and passwords than if you choose this option, where the installation chooses default values for you. For Windows installations only, you can enable security for these components by selecting the check box "Install security for components that support it" during the installation. This check box appears only when you are installing in non-Express mode. Chapter 6: Installation 105 Installation Overview CA Web Server The CA Web Server is configured, by default, to use standard MemoryRealm, but Unicenter NSM secures the directory containing the tomcat-users.xml file by restricting it to Administrators only. You may want to upgrade this product to a version of Unicenter NSM with Security Management so that you can use the NSM Security Realm, or you may want to use digested passwords as mentioned previously. Note: For more information about the NSM Security Realm, see the topic CA Web Server Security in the "Post-Installation and Configuration" chapter. Warning Messages During Installation During the installation of Unicenter NSM, the following warning message may appear one or more times: Process "<some process and parameters>" is taking longer than expected to complete. Do you want to wait longer? <YES|NO> This message generally occurs because the components you selected for installation on the system are consuming more resources than the computer may have in total, or may have available at a given moment in time. You should choose Yes to wait longer unless directed otherwise by Customer Support, or unless a process seems to take an unreasonable amount of time, which might indicate the computer is hung or looping. Although you may be using a computer that meets the minimum requirements, your particular deployment or network topology may increase the resources required by this product. If you receive this message, consider using a machine with greater processing power for the components you have selected, or a machine with fewer other processes and applications that are competing for available resources. If you are installing management components on a computer with insufficient resources, some processes may take five to ten or even more minutes to complete because of operating system swapping and processor thrashing. System Restarts During Installation (Windows Only) There are a number of circumstances under which installing Unicenter NSM can require a system restart. One reason depends on the components you select to install. For example, if you install Unicenter NSM on a computer that does not have an existing installation and you choose to install the Unicenter Browser Interface component and have it use an Apache Web Server, a restart will be required. 106 Implementation Guide Installation Overview Installations, reinstallations, and upgrades can require a restart for other reasons. These usually include being unable to delete, rename, or alter files that are in use by other processes, or being unable to update or alter Unicenter NSM Windows services that do not stop within a reasonable time when asked to do so. It is not possible to predict whether a specific installation, reinstallation, or upgrade is going to require a restart because of these conditions; it depends on the state of the computer at the time. Processes outside of the Unicenter NSM installation (whether local or remote) such as virus scanners and other applications not under Unicenter NSM control can lock a file to which the installation needs control. To minimize the possibility of being required to restart for an upgrade or reinstallation, we recommend that you stop all processes relating to Unicenter NSM, that use Unicenter NSM, or that share components in common with Unicenter NSM. For example, numerous CA products use the CA Messaging (CAM) component. If one of those products is actively using CAM during a Unicenter NSM installation and Unicenter NSM needs to upgrade it, a restart will be required. Installation Using Unicenter Remote Control You cannot install Unicenter NSM from a Unicenter Remote Control session if the host on which you are installing is a Unicenter Remote Control "managed host." This is because Unicenter Remote Controll managed hosts use the CA Message Queuing Service (CAM), which is a component of the Unicenter NSM installation, and CAM cannot be used and upgraded at the same time. Migration of Component Data From a Prior Release During the upgrade of a prior release of Unicenter NSM, the Installation Wizard lets you migrate component data (such as message records and actions from Event Management) from the original database server the component uses now to a new database server of your choice, which the upgraded installation will then use. For upgrades from Unicenter NSM 3.x to Unicenter NSM r11.2 for example, you can move data from an SQL Server database (CAIOPRDB) on node A to a new database (MDB) on node B. In some cases, A and B might be the same node. You cannot migrate data from the Ingres-based Unicenter NSM r11 to the Microsoft SQL Server-based Unicenter NSM r11.2 during the r11.2 installation. Chapter 6: Installation 107 Installation Overview If you do not choose to migrate your existing records for a component, the new database is loaded with fresh default data, or it is left alone if records already exist. If you choose to migrate existing data, any and all data belonging to that specific component that already exists in the new database will be deleted and replaced with the migrated data. Data belonging to other components will be left alone. It is not possible to automatically merge component data on an upgrade or migration. If you want to merge message records and actions, or other component-specific data, you must do so manually after the upgrade. If you choose to build a response file, or run an interactive installation, and you ask for data migration, the Installation Wizard prompts you with a warning about this condition. You must either choose Yes to proceed or go back and elect no data migration. Network Port Conflicts Unicenter NSM requires numerous network ports during installation and later during normal runtime operation. Examine your system for any potential conflicts between the port requirements of this software and any existing software on your system, or of future software that you may install. For example, Unicenter NSM may install Apache Tomcat under certain circumstances, with default port selections of 9090 for primary functionality and 9005 for shutdown functionality. While the Installation Wizard prompts you to specify different ports if it finds these are in use during the installation interview, the wizard cannot know if you have another instance of Apache Tomcat, or any other application, that might not be running at installation time. In such cases, runtime operation of the other product, or of Unicenter NSM, may fail, depending on which product started later and was unable to establish ownership of the port. For more information about the ports that Unicenter NSM uses, see the appendix "Utilizing and Configuring Ports" in the Administrator Guide. Windows Terminal Services Support Windows Terminal Services (WTS) is a server-based component that supports the Terminal Services Client. Unicenter NSM support of WTS allows at least one instance of any given application, excluding daemons or services, to run under each unique WTS session. 108 Implementation Guide Installation Overview For example, you can run a Remote Administrative client application at least once in each unique WTS session without regard to whether the effective user ID is the same or different in the various WTS sessions. Therefore, each of five WTS sessions, three using the same user ID and two using different user IDs, may all run the same application at the same time. Installing, uninstalling, and configuring Unicenter NSM do not support multiple instances of WTS. The processes prevent concurrent instances across other sessions by failing and providing an informative message that only one instance of the installation can run across the entire system at any one time. However, the processes do support being executed in a WTS session. Unlike Unicenter NSM r11.1 GA, this release supports installations through Windows Terminal Services even when configured in Application Server Mode. However, the following settings are required: ■ CONSOLE mode must be used when performing installation from remote access. Example: mstsc /v:HostName /console ■ Terminal server USER settings should be changed to INSTALL prior to the installation. Example: change user /install To verify the user settings, execute the following command: change user /query For more information about the Windows Terminal Server CHANGE USER utility, see http://support.microsoft.com/kb/186504. For additional information about the WTS/Citrix support Statement for Unicenter NSM, see Technical document TEC411264 on SupportConnect. Chapter 6: Installation 109 Installation Overview High Availability Considerations You must change all Unicenter resources to be offline on the current node before installing, reinstalling, or upgrading Unicenter NSM or any CCS consumer product on that same node. If you perform a highly available installation and select any components that use a Microsoft SQL Server database, be sure to choose the same cluster resource group for this product installation as the Microsoft SQL Server instance. For example, the WorldView Manager requires a local MDB. If you select a different resource group at the beginning of our install than the one that Microsoft SQL Server is actually using, Microsoft SQL Server will appear to be remote, and the WorldView Manager cannot be installed on that server. Similarly, this product supports installing an MDB to an existing local Microsoft SQL Server. If you select a different resource group at the beginning of your installation than the one your target Microsoft SQL Server is actually using, the Microsoft SQL Server will appear to be remote, and the MDB itself cannot be installed on that server. Response File Must Not Be Read-Only You cannot use a response file for an unattended installation when the response file is located on a read-only file system or if the response file has the read-only attribute set. The file must be writable because certain values may be altered during installation based on the configuration of the target system. For example, if the CA_APPSW directory already exists on the target system, that current location is used instead of what is specified in the response file. 110 Implementation Guide Install Unicenter NSM on Windows Install Unicenter NSM on Windows Use the following procedure to ensure a successful installation of Unicenter NSM on a Windows platform. Note: You must be logged in as a member of the Administrators group of the local system to initiate the Unicenter NSM installation. To install Unicenter NSM on Windows platforms 1. Verify that Microsoft SQL Server for the desired instance is running. 2. Insert the Installation DVD into the DVD drive. The Unicenter Product Explorer window appears. The option for Installation Wizard for Unicenter NSM is preselected. Note: When you click a selection, prerequisite information appears at the bottom of the window. The Prerequisites section lists the following information: None No prerequisites are required. Satisfied Additional prerequisites beyond the standard are required, but you have met those requirements. Should already be installed Additional prerequisites are required and they have not been installed. You must meet these additional requirements before you can install the component. 3. Click Install. The Unicenter NSM Installation Wizard window appears with the following setup options: Install any or all Unicenter NSM components When you choose to install any or all Unicenter NSM components, the installation wizard prompts you for the components you want to install, where the components should be installed, relevant user IDs and passwords, and other information important for installing the product in your enterprise. Chapter 6: Installation 111 Install Unicenter NSM on Windows Build Unicenter NSM response file for unattended install When you choose to build a Unicenter NSM response file for unattended installations, the installation wizard prompts you for the same information as in the interactive installation as well as the name and location for the response file. Saving setup information in a response file is an effective way to perform identical installations on a number of different physical computers. As the installation wizard records your answers, no attempt is made to validate the data because the machine and environment you are using to create the response file may be different than the target machine where the installation eventually occurs. Note: You cannot reuse a response file created for an earlier version of the product. Use the installation wizard to build a new response file, and then manually merge in any changes that you want to retain from the earlier version. Enter the following command at a command prompt to run the Unicenter NSM installer and pass the name of the response file to it as follows: SETUP.EXE -NT="full path to response file" -CDPATH="full path of directory containing this setup.exe on the product media" For example: SETUP.EXE -NT="C:\MY.RSP" -CDPATH="C:\Images\NSMr11\DVD\Windows" For additional information about deploying installations using the response files you create, see the topic Register Unicenter NSM with Unicenter Software Delivery in this chapter. Create Reduced-Size Install Image (RSII) When you choose to create a Reduced Size Install Image (RSII), see the chapter "Install the Reduced-Size Installation Image" and the topic Create an Installation Image for Windows for information about this feature. 4. Select “Install any or all Unicenter NSM components” and click Next. The License Agreement Window appears. 5. Read the license agreement carefully. When you have scrolled to the end of the agreement, the “I accept the terms in the license agreement” button becomes enabled. 6. Click “I accept the terms in the license agreement” and then click Next. The Company Information window appears. 112 Implementation Guide Install Unicenter NSM on Windows 7. Enter the information requested and click Next. The Component Selection window appears. Notes: Under Configuration choices, the default setting is Management Station. If you select anything outside one of the standard installations, by adding or deselecting components, the Configuration choices setting changes to Custom. A red X next to a component selection signifies that the component cannot be installed on the system. For example, the system does not meet the requirements for the component. You can select an item with a red X and read the description text under the tree to see the reason why the item cannot be installed. Management Station Installs the most frequently used Unicenter managers on a large server for centralized administration of the enterprise. Managed Node Installs the most frequently used Unicenter agents on a workstation that will be administered by the Management Station. Administrative Client Installs the graphical user interfaces, utilities, and supporting infrastructure required to manage remote installations. Custom Installs only the components that you select for installation. Note: Selecting the Express Install option limits the number of installation questions by supplying default responses. One response sets up an operating system user account with the name caunint and automatically supplies a long, random password. If you ever want to use this account or need to change the password, either uncheck the Express Install option so that you can supply a password of your choice, or use some other Administrator account after installation is complete to reset the password. Chapter 6: Installation 113 Install Unicenter NSM on Windows 8. Select components by clicking empty check boxes to add components and clicking check boxes until the box clears to deselect components not desired. Components that do not have checkmarks beside them are not part of the default installation. You must select those components you want for your installation scenario. See the topic Common Unicenter NSM Server Categories in the “Installation Preparation” chapter for examples of recommended component selections for servers typically found in a Unicenter NSM environment. Note: Click Help for an explanation of the color-coded checkmarks. 114 Implementation Guide Install Unicenter NSM on Windows 9. Click Next. If DNS is not available, the installation wizard asks you for the Master Knowledge Base node name. Chapter 6: Installation 115 Install Unicenter NSM on Windows 10. Click Next. The Management Database (MDB) Setup dialog appears. 11. Use the MDB Setup dialog to define the database administrative user you want to create and use. Note: Unicenter NSM can only configure or install an MDB to a local database instance, so the Database Server Name field is dimmed. To use an MDB, WorldView requires that the server name of the Microsoft SQL Server system housing the MDB and the Microsoft SQL Server's instance name together do not exceed 29 bytes total. You can use a combination of single- and double-byte characters. Whichever combination you use, it cannot exceed 29 bytes. Note: See the Installation Overview topic Special Character Support for additional information about supported and restricted characters. You can enter the following information: Database Instance Name Specifies in a drop-down list all the database server instance names the system detects. Select an instance from the list. Use the Refresh button to update the list. If you leave the field blank, the default (unnamed) instance is used. Administrator Name Specifies the user name this product should use to access the MDB. The default user name is nsmadmin, but you can change it to a name of your choice. If you specify a user name that already exists in the database, the password you supply must be the actual password for that user and that user name must already have all appropriate permissions, roles, groups, and so forth that the product requires. A prompt appears if the name does not have these permissions. For Microsoft SQL Server, an existing user must be an authorized user of the master and MDB databases, and must be assigned the roles of db_owner, uniadmin, and regadmin. Note: The MDB creation uses Windows Authentication and must be run by an operating system user that is a member of the System Administrators server role. If you specify a user name that does not already exist, the name is created with the password you supply. A number of names are reserved by the database or the MDB and will be rejected. Review the list of reserved database user names in the earlier topic Reserved Database User Names before selecting a name. 116 Implementation Guide Install Unicenter NSM on Windows Administrator Password Specifies the password to use with the administrator name. The password must be at least six characters in length. Note: Remember the user name and password you specify. During installation, you must specify the user name and password. You will also use the name and password to connect to this MDB from this local or any remote machine in the future. Confirm Password Confirms the password you entered previously. 12. Click Next. The Database Selection and Configuration window appears. Note: This window does not appear during an Express Install unless the default values assumed by the installation wizard are invalid on the current system. Use this window to specify the database server type, location, and authorization credentials for the Unicenter management components that store data in a Database Management System (DBMS). You can use the same DBMS on the same machine for all components, or designate different DBMSs on different machines. The list box identifies components that require a DBMS to store data for the components you have selected. Note: If you are creating a response file for unattended installations, the Database Selection and Configuration dialog does not attempt to determine the location of an MDB. Therefore, you must specifically designate the Database Server and Instance Name that you want to use. When you later install the product using the response file, there is no attempt to search for an MDB other than on the server and instance name you have specified. 13. Select a component such as WorldView Repository, enter the requested information in the Logon Information and other tabs, and click Next. The Apache Tomcat Configuration Information window appears. Chapter 6: Installation 117 Install Unicenter NSM on Windows 14. Enter the following information: User Name Specifies the user name required for authentication to Apache Tomcat. The name is admin and cannot be changed. Password Specifies the password for the Tomcat administrative user. The password cannot be blank and must contain at least six characters. Port Specifies the port the Tomcat service must use. The default port is 9090. If the default port is not available at the time the dialog appears, the system tries to locate an available port by incrementing the number to up to 9095. If none of these ports are available, the port number is set back to 9090. You cannot proceed with the installation without entering a valid (that is, available) port number. 15. Click Next. The Install Directories window appears. Use this window to verify the directories where Unicenter NSM components are to be installed. To install a component in a different directory, click the directory name and press F2 to change the directory. If you select a different directory for installation, Unicenter NSM may require directory name changes for other components as well, based on product prerequisites. Note: If you install Unicenter NSM r11.2 on a 64-bit Windows Server, a message appears and informs you that all NSM 11.2 applications will be installed in "%ProgramFiles(x86)%", if "%ProgramFiles%" is specified as the input directory. 16. Click Next. The Selection Summary window appears showing the components you are installing and their install locations. If you want to change any of the values in the summary, click Back to return to the appropriate window and make your changes. 17. When the values are correct, click Next. The Interview Complete window appears. 18. Click Install to begin the installation process. The Installation Progress window appears. 19. When the Installation Progress bar shows 100% Complete, click Close. Note: Remember to restart your security software. See Pre-Installation Tasks in the “Installation Preparation” chapter. 118 Implementation Guide Install Unicenter NSM on Linux or UNIX Install Unicenter NSM on Linux or UNIX Use the following procedure to install Unicenter NSM for Linux or UNIX on a system that has a local DVD drive and supports a Java GUI installation. The DVD drive can be network mounted. Note: During the installation of Unicenter NSM, some kernel parameters are verified and updated to meet Interprocess Communications (IPC) requirements. See the chapter “Installation Preparation” for more information. You will be notified if updates are required. To install Unicenter NSM on a Linux or UNIX system 1. If you want to perform an unattended installation, set the SHLIB_PATH variable to the path where the GTK libraries are located. This is a prerequisite for creating a response file. 2. The DVD provides directories for each supported platform (AIX, HP-UX, Linux, Solaris-Intel, Solaris-Sparc). Change to the appropriate directory on the DVD (for example: Linux) and run the setupNSM installation program. Use one of the following commands: ./setupNSM Installs the Unicenter NSM components interactively. This launches the interface by default when running in a graphically enabled Linux or UNIX environment (for example, KDE). Otherwise, VT100 mode will be used. ./setupNSM [-V|-vt100] Installs the Unicenter NSM components interactively using VT100 style GUIs. Use this to bypass GUI mode if desired. ./setupNSM -a /directory/responsefile Generates a response file for future use with unattended installation of the requested component. ./setupNSM -r /directory/responsefile Installs the component using a previously generated response file. ./setupNSM -s Reinstalls or upgrades existing Unicenter NSM components silently. To complete a silent mode install for a machine that does not have Unicenter NSM installed, you must use the -r option to initiate a response file install. Chapter 6: Installation 119 Install Unicenter NSM on Linux or UNIX Note: You must be logged in as userid root to initiate the Unicenter NSM installation. The Installation window appears. The installer supports interactive installation of one or more Unicenter NSM components and uninstallation of Unicenter NSM components. The initial startup includes valid options based on the state of your computer. The Product Information button provides a brief description of available choices. When you install Unicenter NSM on a Linux or UNIX computer where a remote MDB is used, proper network and port authority is required. If the machine is not in a network state, or the ports are secured, the installation will not succeed. The installation wizard prompts you for the components you want to install, where the components should be installed, relevant user ids and passwords, validates system requirements, and other information important for installing the product in your enterprise. 120 Implementation Guide Install Unicenter NSM on Linux or UNIX For additional information about system requirements, such as kernel parameters, see the "Installation Preparation" chapter, the Release Notes and the Readme. 3. Click Install. The License Agreement window appears (initial installation only). 4. Read the license agreement carefully. When you have scrolled to the end of the agreement, the "I agree" button becomes enabled. Chapter 6: Installation 121 Install Unicenter NSM on Linux or UNIX 5. Click "I agree". The Unicenter NSM Configuration window appears (new installation only). 6. Select your configuration type and click Next. The Component Selection window appears. Note: Choosing the Express Install option limits the number of installation questions by supplying default responses. 122 Implementation Guide Install Unicenter NSM on Linux or UNIX 7. Select those components you want for your installation scenario. See the topic Common Unicenter NSM Server Categories in the “Installation Preparation” chapter for examples of recommended component selections. Notes: ■ You can only select components that are supported on your UNIX or Linux system. ■ Depending on your component selection, the following windows in this procedure may or may not appear. The following steps in this procedure describe typical installations. Chapter 6: Installation 123 Install Unicenter NSM on Linux or UNIX 8. Click Next. Depending on your system configuration and on the selected components to be installed, it can be necessary that kernel parameters need to be modified. In this case the following window appears: 124 Implementation Guide Install Unicenter NSM on Linux or UNIX 9. Select Yes if you want to continue the installation and then click Next. The Select Installation Locations window appears. Accept the default directories or change the installation locations if necessary. Unicenter NSM cannot be installed into directories with names containing white spaces or special characters such as (, ), *, [, ], :, $, or #. Chapter 6: Installation 125 Install Unicenter NSM on Linux or UNIX 10. Click Next. If you are installing the Event Agent for a Managed Node configuration, the Select Event Agent Policy window appears. Enter the required name and click Next. 126 Implementation Guide Install Unicenter NSM on Linux or UNIX If you are installing components that require DIA, the Distributed Intelligence Architecture window appears. Chapter 6: Installation 127 Install Unicenter NSM on Linux or UNIX 11. Enter the name of the Master Knowledge Base Node or leave this field blank. Click Next. The Enable Security window appears. 128 Implementation Guide Install Unicenter NSM on Linux or UNIX 12. Select Yes or No and click Next. The Management Database Configuration window appears since you install Enterprise Management. It uses a local PostgreSQL database for its data. Chapter 6: Installation 129 Install Unicenter NSM on Linux or UNIX 13. Enter the required passwords and click Next. The Remote DSM Configuration window appears if you have selected the DSM component to be installed. 130 Implementation Guide Install Unicenter NSM on Linux or UNIX 14. Enter the credentials for the remote MDB and click Next. The Selection Summary window appears. Chapter 6: Installation 131 Install Unicenter NSM on Linux or UNIX 15. Check your component selection and click Next if it is complete. The Installation Wizard is now ready to install Unicenter NSM. 16. Click Install to start the installation process. The Installation Progress window appears. When the installation completes, the Installation Complete window appears. 17. Click View Readme to review the latest product updates. The readme appears. 18. Click Details to review the installation log. You can review the log at a later time using an editor of your choice. The log is maintained on your computer as /opt/CA/installer/log/Unicenter NSM.install_type.log, where install_type is install, reinstall, upgrade, or deinstall. If the install fails for any reason, the log will be located at /tmp/CAInstaller.Unicenter NSM.install_type.log. 19. Click OK to close the installation dialog. 132 Implementation Guide Install CA Common Discovery Install CA Common Discovery CA Common Discovery is a subsystem that provides the discovery and classification of all entities in your Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) network. It discovers the relationships between these entities and effectively records the network's topology. CA Common Discovery includes the following components: Discovery User Interface Provides the services to support an administration user interface thin client. The Apache Tomcat web service must be previously installed on the computer. The installation prompts for the Tomcat installation path, discovery server name, and port number. You can install multiple Discovery UI components that point to a single Common Discovery server component. Discovery Server Provides a central point for storing and querying Discovery data, options, policies, and log data. The server includes a single instance of the discovery agent. You must install at least one discovery server in a CA Common Discovery installation. Large environments can install multiple discovery servers as they are needed, but it is not necessary to have multiple discovery servers. Several CA products can share the same discovery server. The installation prompts for the discovery server port number. Installation includes the following discovery server subcomponents: ■ Request Manager ■ Database (DB) Manager ■ Log Manager ■ Enterprise Common Services Installation Note: It is not necessary to have multiple Discovery Servers. You can share a single Discovery Server across multiple CA products. Chapter 6: Installation 133 Install CA Common Discovery Discovery Agent Provides discovery data gathering. CA Common Discovery installs at least one discovery agent with a discovery server in a CA Common Discovery installation. Multiple agents can be installed at strategic locations on the network to gather data and communicate it back to the discovery server. After installation, the agent service starts automatically. It also registers itself with the discovery server. The agent registration process adds the agent to the discovery server's agent list. The server returns a set of default agent options. The installation prompts you for the discovery server name. Installation includes the following discovery agent subcomponents: ■ Request Agent ■ Discovery Engines ■ Enterprise Common Services Installation Platform Support The following platforms support installation of CA Common Discovery: ■ Windows 2003 ■ Windows XP ■ Windows Vista ■ Longhorn Tomcat Authentication You can select Tomcat authentication by choosing the custom CA Common Discovery installation. The installation defines an admin role for a Tomcat user with a user name of admin. If the admin user is already present, the installation aligns it to the admin role created, but if not present, the installation creates a user by that name with a password of tomcat. The admin user is given access to CA Common Discovery on successful authentication. 134 Implementation Guide Install CA Common Discovery Install CA Common Discovery You must install Tomcat 5.5 or greater as a prerequisite to performing the CA Common Discovery UI installation. To install CA Common Discovery on Windows 1. Insert the installation media into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Select Installation Wizard for CA Common Discovery, and click Install. A welcome screen appears. 3. Click Next. The Setup Type page appears. 4. Select one of the following: Complete Installs all the Common Discovery components. Custom Lets you select the Common Discovery components you want to install. The Custom Setup page appears when you select the Custom option. The Destination Folder page appears when you select the Complete option. 5. Select the program features you want to install in the Custom Setup page. The Destination Folder page appears. 6. Click Change. The Change Current Destination Folder page appears. 7. Select the Apache Tomcat folder, and click Install. Note: You must manually locate the Apache Tomcat folder or else an error message appears. The installation starts. 8. Click Finish. CA Common Discovery is installed. Chapter 6: Installation 135 Install CA Common Discovery NSM--Configure CA Common Discovery (CACD) With SSL When installing and configuring SSL-enabled CACD or CA Web Server, keytool commands and installation or configuration dialogs prompt you for the hostname of the system. Provide that hostname consistently using either Fully Qualified Domain Name or the short hostname. There is potential for two SSL mechanisms to be in place: ■ The Common Discovery UI is accessible by the Tomcat SSL port. Complete the procedure below to configure this mechanism. ■ Clients of CACD (for example, classic discovery using dscvrbe) connect to an SSL enabled CACD server using the Common Discovery Server Port specified during CACD installation. For more information about configuring this mechanism, see Configure Your Client Applications to Communicate With an SSL-enabled CACD Server. To configure CA Common Discovery (CACD) with SSL 1. Choose a custom CACD installation to support SSL encryption and authentication. 2. When performing the installation, select the "Use SSL/TLS encryption and authentication" check box, which is not selected by default. See the Common Discovery Server Configuration window of the CACD Installation Wizard. 136 Implementation Guide Install CA Common Discovery 3. Continue the installation and follow the instructions on the screen. 4. On the Certificate Password dialog, when prompted for the CACD Certificate password, it must also match that of the CA Web Server's .keystore file. Chapter 6: Installation 137 Install CA Common Discovery 5. 138 Implementation Guide During the CACD installation, the Java Keystore dialog prompts you for the Java Keystore filename. If the Tomcat service was installed with SSL enablement, you must enter the full path of the same .keystore file that was installed with CA WebServer. The Keystore Password must also match the password of the CA Web Server's .keystore file. Install CA Common Discovery 6. If the same certificate was already imported into Java Trust Store as described in step 3 in the "Configure Tomcat with SSL" section in this guide, enter the full path and credentials of the same Java Trust Store that was already installed. 7. When the CACD Installation completes successfully, it writes the setjavaopts.bat file into the root directory of the CA-Web Server. This file contains two entries similar to the following: VM_OPTION = -Djavax.net.ssl.keyStore=C:\keystore VM_OPTION = -Djavax.net.ssl.keyStorePassword=changeit 8. Copy these entries manually into the ws.cfg file that is located in the conf folder of the CA Web Server installation directory. 9. Restart the CA Web Server service. Note: The Server.xml file inside the Tomcat must be changed manually to enable the SSL for Tomcat as explained in steps 5 and 6 in the "Configure Tomcat with SSL" section in this guide. Chapter 6: Installation 139 Install CA Common Discovery Configure Your Client Applications to Communicate With an SSL-enabled CACD Server The following steps detail how to create an SSL client key to enable client applications to communicate with an SSL-enabled CACD server. To create an SSL client key 1. From the command prompt change to the folder CA_APPSW\WVCmnDscv_SSL 2. Copy the cacert.pem file from the discovery server located under the Common Discovery Installation Folder\SSL to the CA_APPSW\WVCmnDscv_SSL folder. 3. Run the following command: newclientcert.cmd client 4. When prompted, enter your details like country name and so on or you can just press the enter key to use the default values. Note: When prompted for Common Name, enter the client system's name. Remember to consistently use either the FQDN or hostname as appropriate. 5. Verify that you have a certs folder under SSL folder. In the SSL folder the files client.pem and clientkey.pem should exist. Reinstall CACD in an SSL Enabled Environment If presented with a "Certificate already exists." error while attempting to reinstall an SSL enabled CACD on a system, you need to confirm that the certificate with alias "cacd" is not being used by any other applications. Once confirmed, you may use the following commands to list and delete the certificate from the Java Trust Store. To list and delete a certificate from the Java Trust Store 1. From the command prompt, enter the following command: cd JRE_HOME\lib\security JRE_HOME is the install path of the corresponding JRE. Make sure that the JRE_HOME\bin is in the path. 2. List all of the certificates that are stored in the trust store file by entering the following command: keytool -list -keystore cacerts 140 Implementation Guide Register Unicenter NSM with Unicenter Software Delivery 3. Delete a certificate with the "cacd" alias using the following command: keytool -delete -alias cacdSYSTEMNAMEca -keystore cacerts SYSTEMNAME is the name of the corresponding host machine. The cacdSYSTEMNAMEca must match the cacd prefixed entry as output of the keytool -list command. 4. Once the certificate has been deleted, a restart of all the applications using JRE and tomcat authentication is recommended. You should now be able to reinstall CACD successfully again using SSL. Register Unicenter NSM with Unicenter Software Delivery Registering Unicenter NSM with Unicenter Software Delivery lets you register once and deploy many times. When you register Unicenter NSM, the entire contents of the Unicenter NSM product media are copied to the Unicenter Software Delivery database. Because of the large amount of data, you do not want to register Unicenter NSM multiple times, and it is not necessary. The many computers to which you want to deploy Unicenter NSM may have different uses for or requirements of Unicenter NSM. You may want to install different agents and management components on different computers. Further, you may want to specify different installation or configuration parameters. The solution is to register Unicenter NSM as one Unicenter Software Delivery package with many procedures, where each procedure installs a different selection of components and specifies a different set of installation or configuration values. Chapter 6: Installation 141 Register Unicenter NSM with Unicenter Software Delivery Prepare for Registration The first thing you must do is plan. Make a list of all the varieties of installations you want to support. Each item on the list will specify a selection of components to install, as well as installation parameters such as installation drive and path, database server name, and so on. You can create response files for Windows, Linux, and UNIX installations. You can also create response files for Systems Performance on these platforms. Note: When registering packages to Unicenter Software Delivery, you must define 32-bit response files to be deployed to 32-bit operating systems and 64-bit response files to be deployed to 64-bit operating systems. The job output will contain an error message indicating that you deployed the response file to the wrong operating system. If you are running DSM 11.x, this restriction is enforced by DSM and the deployment will not take place. Host names and other machine-specific information needs to be edited in the response file. For information about response files in PIF and enabling dynamic settings that are evaluated on the target system, see the “CCS UNIX/Linux Reference” appendix. After making your plan, create a separate response file to correspond to each item on your list. A response file is a text file that the Unicenter NSM Installation Wizard creates for you. When you run the wizard, select the option to “Build Unicenter NSM response file for unattended install.” The response file records all of your choices and specifications. You can tell the wizard what name to give the response file and where to store it. Later, when you perform Unicenter Software Delivery registration, the name of the response file becomes the name of the Unicenter Software Delivery procedure that installs Unicenter NSM with that response file. If you are making more than one response file, make each name descriptive of the kind of installation it will perform. 142 Implementation Guide Register Unicenter NSM with Unicenter Software Delivery Note: You must run the registration tool using the steps provided here. You cannot run the executable SDRegister.exe directly from the product media. To prepare for registering a Unicenter NSM install package with Unicenter Software Delivery for Linux or UNIX 1. Create a directory to contain your custom response files. This directory may be given any name; for example, ResponseFiles. 2. Run setupNSM with the -a parameter to create custom response files. 3. Select Installation Wizard for Unicenter NSM. Note: Give the response file a meaningful name, as this name will become the name of the Unicenter Software Delivery procedure that runs the unattended install. The name appears in the Unicenter Software Delivery catalog and you will want to be able to recognize it. 4. Click Next and select the components you want to install, answering the install questions with appropriate values. For Linux and UNIX registrations, you have the option of registering Unicenter NSM agents only. Registering Unicenter NSM agents reduces only network load while deploying agents to a large number of machines. You will be prompted for any required information. You can create as many custom response files as you want with this procedure. To prepare for registering a Unicenter NSM install package with Unicenter Software Delivery for Windows 1. Create a directory to contain your custom response files. This directory may be given any name, for example, ResponseFiles. 2. Run the install wizard for the appropriate Windows, Linux or UNIX platform to create custom response files. The first page of the install wizard appears. 3. Select “Build a Windows response file for unattended install” and enter the full path name for the response file, specifying the directory you created in Step 1. Note: Give the response file a meaningful name, as this name will become the name of the Unicenter Software Delivery procedure that runs the unattended install. The name appears in the Unicenter Software Delivery catalog and you will want to be able to recognize it. 4. Click Next and select the components you want to install, answering the install questions with appropriate values. You can create as many custom response files as you want with this procedure. Chapter 6: Installation 143 Register Unicenter NSM with Unicenter Software Delivery To prepare for registering a Unicenter NSM Systems Performance install package with Unicenter Software Delivery (Windows only) 1. Create a directory to contain your custom response files. This directory may be given any name, for example, ResponseFiles. 2. Run the install wizard for Unicenter NSM Systems Performance to create custom response files. The first page of the install wizard appears. 3. Select “Generate a response file for unattended (and remote) installations” and enter the full path name for the response file, specifying the directory you created in Step 1. Note: Give the response file a meaningful name, as this name will become the name of the Unicenter Software Delivery procedure that runs the unattended install. The name appears in the Unicenter Software Delivery catalog and you will want to be able to recognize it. 4. Click Next and select the components you want to install, answering the install questions with appropriate values. You can create as many custom Systems Performance response files as you want with this procedure. Note: You can copy and rename response files if necessary, as long as the end result is the same. The files should have meaningful names and be placed in the directory you created in Step 1. Run Registration After you have created all required response files and placed them in a single directory, run the Unicenter Software Delivery registration tool. On Windows platforms, to run the Unicenter Software Delivery registration tool 1. From the Unicenter NSM Product Explorer, locate “Unicenter Products/Unicenter for Windows,” select “Register packages to Unicenter SD for Windows,” and click Install. The registration tool dialog appears. Specify the directory that contains your response files and the location of Unicenter NSM product media. Note: You may not specify UNC drives for either the Root directory or the Response Files fields. If these files are located on remote servers, map them to a local drive and use that drive letter. 2. Click Register. The task is complete. 144 Implementation Guide Install Unicenter Systems Performance On Linux or UNIX platforms, to run the Unicenter Software Delivery registration tool 1. Run setupNSM, select “Register Unicenter NSM r11.2 Linux/UNIX packages to Unicenter SD,” and click Install. The registration tool dialog appears. 2. Specify the directory that contains your response files and the location of Unicenter NSM product media. 3. Click Register. The task is complete. Deploy Unicenter NSM to Hosts To deploy Unicenter NSM to a host on your network, specify to Unicenter Software Delivery both the host and the procedure. Unicenter NSM installation runs in unattended mode on the designated host. The installation is configured by the response file you associated with the procedure. Note: On Linux or UNIX systems proper locale settings are required before Unicenter Software Delivery deployment (for example: en_US). Install Unicenter Systems Performance You must use the Systems Performance Component Selection screen to install the Unicenter Systems Performance feature. In addition, you can use Unicenter Software Delivery to install and configure Systems Performance agents across the enterprise. Note: Systems Performance creates default settings in the All Users area of Documents and Settings. The package for the Unicenter NSM agents provides procedures for installing the following agents: ■ System (OS and log) agents ■ Performance agents Chapter 6: Installation 145 Install Unicenter NSM Systems Performance on Windows Install Unicenter NSM Systems Performance on Windows Use the following procedure to ensure a successful installation of Unicenter NSM Systems Performance on Windows platforms. To install Unicenter NSM Systems Performance on Windows platforms 1. Insert the installation DVD into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Expand the Unicenter for Windows view. 3. Click Installation Wizard for Unicenter NSM Systems Performance, and then click Install. The Unicenter NSM Systems Performance Setup wizard appears. 4. Click Next. The license agreement appears. 5. Accept the license agreement, and click Next. The Customer Information page appears. 6. Enter your user name and organization, select Install on this machine, and click Next. The Setup Type page appears. 7. Select the required setup type, and follow the on-screen instructions to complete the installation. Note: If you select a folder under %ProgramFiles% on a 64-bit version of Windows, the installer automatically corrects the folder to be under %ProgramFiles(x86)% because it is installing 32-bit applications. Note: If you choose the option Generate a Response File in the Customer Information page of the wizard, you can make a file containing setup and configuration information for future use with unattended installations of Systems Performance. Enter the following command at a command prompt to run the Systems Performance installer and pass the name of the response file to it (the argument is case-sensitive): setup.exe USE_THIS_RESPONSE_FILE="full path to response file" The setup.exe file for this command is located on your installation media at x:\Windows\NT\SystemsPerformance\setup.exe. 146 Implementation Guide Install Active Directory Management Install Active Directory Management Active Directory Management (ADM) for Unicenter NSM is integrated into the Unicenter NSM r11.2 installation and consists of the following components: ■ Active Directory Enterprise Manager ■ Active Directory Explorer ■ Active Directory Reporting ■ Active Directory Knowledge Base Content ■ Active Directory Agent (caiAdsA3) You can select Active Directory Management and the Active Directory Agent to install from the Unicenter NSM Installation Wizard. Each entry contains subnodes that define what ADM components are installed and how the Active Directory Agent interacts with Active Directory Management. This section contains ADM platform support, software requirements, installation procedures for ADM and the Active Directory Agent, and both agent installation scenarios: integrated with ADM or standalone. Platform Support ADM fully supports the following platform: ■ Windows Server 2003 The caiAdsA3 agent also supports Windows Server 2008, but not on an Active Directory functional level. Read-only DCs are also not supported on this platform. Software Requirements Ensure that the following software requirements are met for ADM and the Active Directory Agent: ■ Active Directory Management requires the Performance Distribution Server component to be present on the same server to import created performance cubes from the Active Directory EM Service on the manager server into the Performance Data Grid. On startup, ADM checks for the availability of Systems Performance libraries and whether a Distribution Server is installed. If either of the checks fails, the service terminates and writes a message to the Windows Event Log. Chapter 6: Installation 147 Install Active Directory Management ■ Active Directory Reporting requires the Performance Reporting component to be present on the same server. Active Directory Reporting tightly integrates with Performance Management to provide performance statistics related to Active Directory domains. When running reports, the Active Directory data displays within Performance Reporting using customized reports and a customized report tree. If Performance Reporting is not installed, Active Directory Reporting cannot register itself with Web Reporting Server. ■ When integrated with Active Directory Management, the Active Directory Agent requires the Historical Performance Agent to be present on every monitored node to poll the Active Directory Agent for performance data and transfer it to an associated performance cube. You should install both agents on at least every domain controller to ensure that all relevant performance data is captured. None of these operations are performed by default when you install the Active Directory components. You must ensure that these components are on the appropriate servers and install them manually if they are not. You can perform the required installations in any order (either before or after the Active Directory installations), although it is recommended to install the Active Directory Agent before the Performance Agent. 148 Implementation Guide Install Active Directory Management Install Active Directory Management Starting with Unicenter NSM r11.2, Active Directory Management appears as a new component in the Unicenter NSM Installation Wizard. Active Directory Management appears as several manager components that you must install to take full advantage of its Active Directory monitoring capabilities. Installation of the Active Directory manager components is managed as part of the new Active Directory Management (ADM) setup plug-in, which is loaded by the Unicenter NSM installer and interfaces with the installation framework to drive the correct setup of the components. Important! Keep in mind that you must have the Performance Distribution Server and Systems Performance Reporting components installed on the same server for ADM to work correctly. You can install these components before or after the ADM installation. For more information, see Software Requirements. For the integration with the Active Directory Agent to work correctly, all Active Directory Agents must be at the caiAdsA3 level (either r11.1 or r11.2). Install Active Directory Management on a Unicenter NSM manager server somewhere in the Active Directory; installation on a domain controller is not recommended. ADM installs to the following location: Install_Path\SC\CCS\ADEM Note: The following procedure reflects an ADM-only installation. If you select additional Unicenter NSM components to install at the same time, other screens and options may appear during the installation. To install Active Directory Management 1. Open the Unicenter Product Explorer, select Installation Wizard for Unicenter NSM, and click Install. The installation wizard initializes, and the Setup Options screen appears. 2. Select Install any or all Unicenter NSM components and click Next. The License Agreement screen appears. 3. Scroll to the bottom of the agreement, select I agree, and click Next. The Company Information screen appears. 4. Enter your information in the Details pane and click Next. The Component Selection screen appears. 5. Select the Active Directory Management check box to install the main ADM manager component, which provides a hierarchy view of the Active Directory infrastructure and stores a Business Process View representation of Active Directory components and services in the MDB. Chapter 6: Installation 149 Install Active Directory Management The following sub-nodes are automatically selected and are necessary to implement the complete functionality of ADM: Active Directory Enterprise Manager Provides an enterprise-wide view of your Active Directory resources. Active Directory Enterprise Manager analyzes all enterprise Active Directory resources and displays the information it gathers in the Active Directory Explorer. Selecting this check box automatically installs the following two components: ■ Active Directory EM Service Queries the Active Directory for information about Active Directory resources and polls the Active Directory Agents on all monitored domain controllers in all forests for domain controller specific metrics and states. ■ Active Directory Explorer Displays Active Directory data in a web-based application. The Active Directory Explorer gets its data from the Active Directory EM Service. It lets you manage your Active Directory on an enterprise level based on forests, sites, and domains from domainoriented or site-oriented perspectives. Active Directory Reporting Transfers important Active Directory metric and event information to Unicenter NSM performance cubes. Active Directory Reporting lets you run various out-of-the box reports from the Active Directory Explorer that are generated from this performance cube data. These reports are processed by Web Reporting Server (WRS), which provides the ability to select from preconfigured reports, configure your own custom reports, and schedule reports to run at set times. Note: Active Directory Reporting requires the Systems Performance Reporting component to be installed on the same server to enable the reporting functionality. For more information, see Software Requirements. 6. (Optional) Expand CA Knowledge Base and select ADM Knowledge Base Content if you want to install the Knowledge Base content for Active Directory Management. This component causes traps from the Active Directory Agent and messages from the Active Directory Enterprise Manager that appear as event messages in the Unicenter NSM Event Console to contain a specific hyperlink in their message text. Clicking that link redirects you to associated articles in the Knowledge Base that you can use to troubleshoot the cause of the event and possible solutions. This option is not selected by default when you select Active Directory Management. 150 Implementation Guide Install Active Directory Management 7. Click Next when finished selecting components to install. The Distributed Intelligence Architecture screen appears. 8. Enter the Master KB Node in the provided field and click Next. The Database Selection and Configuration screen appears. 9. Confirm the logon information for the MDB containing WorldView information and click Next. The Apache Tomcat Configuration screen appears. 10. Enter the Tomcat configuration credentials in the provided fields and click Next. The Install Directories screen appears. 11. Specify the installation directory or accept the default, and click Next. The Installation Summary screen appears. 12. Click Next. Active Directory Management installs. Active Directory Agent Installation You install the new Active Directory Agent used with ADM (caiAdsA3) into the same place you installed the old agent (caiAdsA2). Installation of the caiAdsA3 agent is managed as part of the existing Agent Technology Agents (ATA) setup plug-in that is loaded by the Unicenter NSM installer and interfaces with the installation framework to drive the correct setup of all agents shipped with Unicenter NSM. Note: The Unicenter NSM r11.1 ADM patch suite also included several PTFs related to the Active Directory Agent policy files, such as DSM, abrowser, and dashboards. These files are now included with Unicenter NSM and automatically installed as part of the Common Resource Packages and Agent Technologies components. The Active Directory Agent is an entry in the Unicenter NSM Installation Wizard located under Agent Technologies, Agent Technology Agents. The agent installs to the following location: Install_Path\SC\CCS\AT\AGENTS During an initial installation the agent is selected by default on domain controllers, and it is not selected by default for non-domain controllers. If you are reinstalling or upgrading, your previous settings are preserved. Chapter 6: Installation 151 Install Active Directory Management The selections you make for the Active Directory Agent and the agent's implementation requirements depend on how you want to use the agent. The following are the two most common implementation scenarios: ■ Full integration with Active Directory Management ■ Standalone operation (similar to caiAdsA2 agent implementation, without ADM integration) Important! You must select one or the other implementation option. You can either have an environment with standalone caiAdsA3 agents without ADM installed, or you can implement a fully-functional ADM environment, including caiAdsA3 agents installed on all domain controllers. 152 Implementation Guide Install Active Directory Management Install the Active Directory Agent for Full Integration with Active Directory Management The most common and recommended implementation scenario for the Active Directory Agent on domain controllers is to enable full integration with Active Directory Management. In this scenario, Active Directory Management relies on the agent's enhanced and sophisticated monitoring capabilities to be able to fully provide the enterprise-wide monitoring functionality. Important! Keep in mind that you must have the Performance Agent installed on every monitored node to collect the performance data of the Active Directory Agent. We recommend installing the Active Directory Agent first. For more information, see Software Requirements. In this scenario, you must install the Active Directory Agent on all domain controllers (DCs) in the forests you want to monitor and select Full Integration on these DCs. If during a roll-out phase the Active Directory Agent is not installed on all DCs, the agent and Active Directory Management still function; however, for a full picture of proper Active Directory operation, such as proper replication to all DCs, the agent must be installed on all DCs. Note: The following procedure reflects an agent-only installation. If you select additional Unicenter NSM components to install at the same time, other screens and options may appear during the installation. To install the Active Directory Agent fully integrated with Active Directory Management 1. Open the Unicenter Product Explorer, select Installation Wizard for Unicenter NSM, and click Install. The installation wizard initializes, and the Setup Options screen appears. 2. Select Install any or all Unicenter NSM components and click Next. The License Agreement screen appears. 3. Scroll to the bottom of the agreement, select I agree, and click Next. The Company Information screen appears. 4. Enter your information in the Details pane and click Next. The Component Selection screen appears. Chapter 6: Installation 153 Install Active Directory Management 5. Select Active Directory Agent under Agent Technologies, Agent Technology Agents, and clear the Express Install check box. Note: You must clear the Express Install check box, or you cannot specify the implementation of the agent that you want to use. Click Next. The Component Functionality screen appears. 6. Select the Full Integration of Active Directory Agent with Active Directory Management check box. Also, you should select the Adaptive Configuration Support for Active Directory Agent check box if you want Adaptive Configuration to automatically configure the agent. Click Next. The Distributed Intelligence Architecture screen appears. 7. Enter the Master KB Node in the provided field and click Next. The Install Directories screen appears. 8. Specify the installation directory or accept the default, and click Next. The Installation Summary screen appears. 9. Click Next. The Active Directory Agent installs. Install the Active Directory Agent as a Standalone Agent If you do not make use of Active Directory Management, or if you want to monitor critical member servers, such as Microsoft Exchange, you should install the agent as standalone without Active Directory Management integration. The caiAdsA2 agent is not supported in Unicenter NSM r11.2, but you can operate the standalone Active Directory Agent in the same manner you did the caiAdsA2 agent. However, the agent will only support a subset of its monitoring capabilities in this configuration. You may even want to preserve the configuration of the old caiAdsA2 agent. For more information, see the Inside Active Directory Management guide. When the Active Directory Agent is not integrated with Active Directory Management, the Historical Performance Agent is no longer a required component. Note: The following procedure reflects an agent-only installation. If you select additional Unicenter NSM components to install at the same time, other screens and options may appear during the installation. 154 Implementation Guide Install Active Directory Management To install the Active Directory Agent to operate in a standalone manner 1. Open the Unicenter Product Explorer, select Installation Wizard for Unicenter NSM, and click Install. The installation wizard initializes, and the Setup Options screen appears. 2. Select Install any or all Unicenter NSM components and click Next. The License Agreement screen appears. 3. Scroll to the bottom of the agreement, select I agree, and click Next. The Company Information screen appears. 4. Enter your information in the Details pane and click Next. The Component Selection screen appears. 5. Select Active Directory Agent under Agent Technologies, Agent Technology Agents, and clear the Express Install check box. Note: You must clear the Express Install check box, or you cannot Also, you should select the Adaptive Configuration Support for Active Directory Agent check box if you want Adaptive Configuration to automatically configure the agent. Note: You must clear the Express Install check box, or you cannot specify the implementation of the agent that you want to use. Click Next. The Component Functionality screen appears. 6. Clear the Full Integration of Active Directory Agent with Active Directory Management check box. Also, you should select the Adaptive Configuration Support for Active Directory Agent check box if you want Adaptive Configuration to automatically configure the agent. Click Next. The Distributed Intelligence Architecture screen appears. 7. Enter the Master KB Node in the provided field and click Next. The Install Directories screen appears. 8. Specify the installation directory or accept the default, and click Next. The Installation Summary screen appears. 9. Click Next. The Active Directory Agent installs. Chapter 6: Installation 155 Install Monitoring for z/OS Interface Install Monitoring for z/OS Interface The Monitoring for z/OS interface is installed automatically as part of Unicenter NSM (with no component selection screen). The following instructions provide the information you need to install the interface on the mainframe. You have the choice of using the files provided on the Unicenter NSM Installation DVD or installing using the mainframe tape provided. FTP and Load JCL to the Mainframe This topic provides instructions for you to FTP the necessary files from the Unicenter NSM Installation DVD to the mainframe and load the necessary JCL for the installation. FTP the Sequential Files to the Mainframe To upload the sequential files to the mainframe 1. From a command prompt, change to the SMO file directory on the DVD. For example: cd dvd_drive:\zOS 2. Connect to the mainframe using the ftp client: ftp mf_hostname 3. Sign on to the FTP server. 4. At the FTP prompt, enter the following: ftp> bin ftp> quote site recfm=fb ftp> quote site lrecl=80 ftp> put smo110.seq.instlib 'hlq.SMO110.SEQ.INSTLIB' ftp> put smo110.seq.loadlib 'hlq.SMO110.SEQ.LOADLIB' ftp> put smo110.seq.miblib 'hlq.SMO110.SEQ.MIBLIB' 5. To transfer the conversion JCL to the mainframe, enter the following: ftp> cd 'hlq.site.JCL' ftp> ascii ftp> put smo110_receive.jcl RECSMO1 156 Implementation Guide Install Monitoring for z/OS Interface Convert the Sequential Files Back to PDS Format To convert the sequential files back to PDS format 1. Edit the RECSMO1 file and follow the instructions listed at the top of the file. 2. Submit the RECSMO1 job. The job should complete with a return code of zero for all steps. Complete the Installation To complete the installation, see the topic Install on the Mainframe and follow these steps: For a non-SMP/E installation: 1. Skip Steps 1 and 3 in the Procedure checklist. Detailed instructions for each step follow the checklist. 2. Complete Step 2 and Steps 4 through 10 as listed. For an SMP/E installation: 1. Skip Step 1. 2. Complete Step 2 by filling in the required values. 3. For Step 3, use the JCL INSTDVD1 instead of the INSTSMP1. This completes the SMP/E installation while bypassing the tape copy steps. 4. Complete Steps 4 through 10 as listed. Install on the Mainframe Use the following procedure if you want to install the Monitoring for z/OS feature using the mainframe tape (included with the Unicenter NSM package) instead of the files on the Installation DVD. The installation tape, which is a standard label tape, contains these data sets and formats: File Data Set Name Data Set Contains Format 1 SMO.INSTLIB.TAPE The installation JCL IEBCOPY 2 SMO.MIBLIB.TAPE MIB library IEBCOPY 3 SMO.LOADLIB.TAPE Agent load library IEBCOPY Chapter 6: Installation 157 Install Monitoring for z/OS Interface The Monitoring for z/OS installation requires several procedures; use the following checklist as you install the agent. √ Procedure 1. Download the installation library. 2. Modify member SETVARS. 3. Run the installation job. 4. Copy the MIB to Agent Technology. 5. Load the MIB into the object store. 6. Update the awservices configuration. 7. Update the agent PROCs and add them to a system procedure library. 8. Give APF authorization to the agent load library. 9. Give the ZOSAGTS and CICSAGTS PROCs the proper security. 10. Migrate previous z/OS installations (if applicable). 158 Implementation Guide Install Monitoring for z/OS Interface Download the Installation Library To download the installation library 1. Run the following job stream to download the installation library from the installation tape. //COPYINST JOB (0000) //COPY EXEC PGM=IEBCOPY //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(5,1)) //SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(5,1)) //SYSPRINT DD SYSOUT=* //TAPEIN DSN=SMO.INSTLIB.TAPE,DISP=OLD, DD // UNIT=TAPE,VOL=SER=SMO110, // LABEL=(1,SL) //INSTLIB DD DSN=smo.INSTLIB,DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,VOL=SER=volume, // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160), // SPACE=(CYL,(1,1,5)) //SYSIN DD * COPY INDD=((TAPEIN,R)),OUTDD=INSTLIB /* // 2. Modify the job stream to fit your site’s specifications by replacing the italicized items in the sample JCL with the following information: smo Specifies the high-level index qualifier for the installation library. You can change this index to meet your site’s needs or naming conventions. The default index qualifier for all the libraries is smo. volume Specifies the volume serial number where the installation library is to reside. SETVARS Member Modification The SETVARS member contains JCL SET statements used to assign symbolic parameters used in the remainder of the installation. Review and modify these statements as needed. The meaning of each symbolic parameter is explained in the member. Note: The install supports both SMP/E and non-SMP/E; the SETVARS member contains settings for both installation types. Chapter 6: Installation 159 Install Monitoring for z/OS Interface Run the Installation Job Run the installation job to create the agent libraries. The SMP/E installation and non-SMP/E installation have separate jobs. INSTSMP1 is for the SMP/E installation and INSTSTD1 is for the non-SMP/E installation. Instructions for the installation are included in the members. To run the installation job for an SMP/E installation 1. Review the INSTSMP1 member in the smo.INSTLIB data set. 2. Submit the INSTSMP1 member. 3. Ensure the INSTSMP1 job ends with a condition code of 4 or less. To run the installation job for a non-SMP/E installation 1. Review the INSTSTD1 member in the smo.INSTLIB data set. 2. Submit the INSTSTD1 member. 3. Ensure the INSTSTD1 job ends with a condition code of 0. Copy the MIB to Agent Technology To copy the agent MIB to the Agent Technology MIB directory 1. Review the INSTMIB2 member in the smo.INSTLIB data set. 2. Submit the member INSTMIB2. 3. Ensure the job INSTMIB2 ends with a condition code of 0. Note: To load the monitoring for z/OS MIBs automatically whenever the clean_sadmin script runs, update the install_mibs script. Add the following lines to the $AGENTWORKS/services/tools/install_mibs file: ldmib -n caiSysAgtzOS -m “//’$AWORKS_MVS_PREFIX.MIBLIB(ZOSAGENT)’” ldmib -n caiSysAgtCics2 -m “//’$AWORKS_MVS_PREFIX.MIBLIB(CICSAGT2)’” Load the MIB into the Object Store To load the agent MIB into the Agent Technology Object Store Note: Agent Technology must be active to run this job. 1. Review the INSTLDM3 member in the smo.INSTLIB data set. 2. Submit the member INSTLDM3. 3. Ensure the job INSTLDM3 ends with a condition code of 0. 160 Implementation Guide Install Monitoring for z/OS Interface Update the awservices Configuration The Monitoring for z/OS feature must be defined so it can register itself with Agent Technology. To define the z/OS and CICS agents Note: Agent Technology must be active for this job to run. 1. Review the INSTAWS4 member in the smo.INSTLIB data set. 2. Submit the member INSTAWS4. 3. Ensure the job INSTAWS4 ends with a condition code of 0. Update Agent PROCs and Add to System Procedure Library The CICSAGTS, CICSAGTE, ZOSAGTS, and ZOSAGTE members contain the JCL procedures needed to start and stop the CICS and System agent address spaces. To update the agent PROCs 1. Copy the agent PROCs into one of your system procedure libraries. 2. Modify the SET statements at the beginning of each PROC. 3. Remove the following load libraries from the STEPLIB if they are in the system LINKLIST: ■ Agent Technology ■ IBM LE ■ Unicenter CA-SYSVIEW Server Agent Load Library APF-Authorization The smo.LOADLIB data set must be APF-authorized for the agents to operate. Chapter 6: Installation 161 Install Monitoring for z/OS Interface Give the ZOSAGTS and CICAGTS PROCs the Proper Security To give the ZOSAGTS and CICSAGTS PROCs the necessary security 1. Ensure an OMVS segment is defined to the user ID assigned to the ZOSAGTS and CICSAGTS started tasks. The segment allows the agents to access USS. 2. Assign a user identifier (UID) to the user ID assigned to the started task ZOSAGTS. This allows the agent to collect complete information on USS processes and IPC resources. Note: A UID of 0 (super-user authority) allows the agent to collect all USS process and IPC resource information. A UID of any other value allows the agent to collect information only on USS processes and IPC resources owned by the specified UID. Migration of Previous z/OS Agent Installations You use the CFGCONV utility to migrate an existing agent configuration from the previous release of CICS, OS/390, and USS agents into this release of Unicenter NSM. Configuration sets for the system and CICS agents from previous releases are not compatible with this release. In addition, the functionality of the USS agent has been integrated into the z/OS system agent. Use the CFGCONV utility to migrate existing threshold and watcher settings from an existing agent installation. The JCL for using the CFGCONV utility is located in smo.INSTLIB(CFGCONV). CFGCONV generates the configuration set in a format that Unicenter NSM can use. By default, the newly generated configuration set is CfgZOSAGENT for the system agent and CfgCICSAGENT for the CICS agent, where ZOSAGENT and CICSAGENT represent the default agent instance names. Note: You must run CFGCONV once for each agent instance you are migrating. Run the utility additional times to append USS agent settings to the z/OS system agent or to append multiple CICS regions to a CICS configuration set. How You Can Use the CFGCONV Utility Perform the following steps before using CFGCONV: 1. Start Agent Technology. 2. Stop the agent instance. If you are migrating data from the OS/390 and USS agents, shut down both agents while running CFGCONV. 3. 162 Implementation Guide Update the PARM field in the CFGCONV job to specify the migration options. Sample PARMS are provided in the job. Install Unicenter Management Portal The following flags control CFGCONV: -i Identifies the instance name of the previous agent. The default instance name for the OS/390 agent is Mvs.CAIAGENT or Mvs.SYSVIEW, depending on your installation. The default instance name for the CICS agent is Cics.RegionName. Note: This flag is required for the CICS and OS/390 agent migration. -c Specifies the file name for the newly generated configuration set. By default, the configuration set file is stored in the Agent Technology HFS file system. The full path is $AGENTWORKS_DIR/agents/config/CfgZOSAGENT.cfg for the z/OS system agent and $AGENTWORKS_DIR/agents/config/CfgCICSAGENT.cfg for the CICS agent. -f Specifies the full path name for the log file. By default, the log file is stored in the Agent Technology HFS file system, with the file name of $AGENTWORKS_DIR/agents/log/CfgConver_instance.log. -a Appends configuration data to an existing configuration set. Note: This flag is required if you are generating a configuration set for multiple CICS regions or converting a USS agent configuration to the z/OS system agent. -u Converts the USS agent configuration to a z/OS system agent configuration set. Install Unicenter Management Portal On Windows platforms, you can install Unicenter MP using the Product Explorer of the Unicenter NSM Installation DVD. On Linux and UNIX platforms, you can install Unicenter MP using the Unicenter NSM Installation Wizard. See the Unicenter Management Portal Implementation Guide for complete installation information. Chapter 6: Installation 163 Install Unicenter for Pocket PC Install Unicenter for Pocket PC Perform the Unicenter for Pocket PC installation from a host PC using the Microsoft ActiveSync Add/Remove Programs utility. You must establish a working partnership between the Pocket PC and a Windows workstation before installing Pocket PC. To install Pocket PC 1. Ensure that Microsoft ActiveSync is installed on the local Windows workstation and that a partnership is established with the Pocket PC device where you want to install Unicenter NSM. Ensure that the device is connected to ActiveSync before proceeding. 2. Launch the Unicenter Product Explorer, select the Unicenter for Pocket PC option, and click Install. The Unicenter Product Explorer appears. If Microsoft ActiveSync is installed and a device is connected, the following dialog may appear. Note: If a device is not currently connected, Unicenter for Pocket PC automatically installs the next time a device connects to ActiveSync. 3. Click Yes and follow the prompts on both the Windows workstation and the target Pocket PC device. 4. Set the Timeout value in seconds. The default is 60. 5. Click OK in the upper-right corner to save these settings. 164 Implementation Guide Installation of Unicenter Management for MOM Installation of Unicenter Management for MOM The installation of Unicenter Management for MOM (MOM Management) involves the following sequence of tasks: 1. Make sure your network conforms to prerequisites. 2. Set up user accounts for installation, MOM Discovery, and collecting information from MOM. 3. Install MOM Management. 4. (Optional) Run MOM Discovery. Note: Unicenter NSM provides integration kits to both of Microsoft's management applications, Microsoft Operations Manager (MOM) and System Center Operations Manager 2007 (SCOM). Although the integrations to MOM and SCOM can coexist on the same management server, each one integrates only with its Microsoft counterpart. Prerequisites for MOM Management Installation The Unicenter NSM Manager where you install MOM Management must meet the following requirements: ■ The operating system must be Windows 2003 Server. ■ WorldView, Event Management, and Unicenter MCC must be installed. ■ Microsoft Operations Manager (MOM) and the servers it monitors must be in the same Windows domain. ■ The MOM database must be on a different server because of SQL configuration differences. ■ The node running the Unicenter NSM integration with MOM must be in the local Administrators group on the node where MOM is running. Note: See the Unicenter Management for MOM readme on the installation DVD for any other system requirements. Chapter 6: Installation 165 Installation of Unicenter Management for MOM Install Unicenter Management for MOM Unicenter Management for MOM (MOM Management) lets you manage Microsoft Operations Manager (MOM) alerts from Unicenter NSM. Install MOM Management after you install Unicenter NSM. Note: After the installation, you are prompted to perform MOM Discovery. Do this only if you have recently run Discovery on the MOM network. Otherwise, the discovery will not find any MOM servers or managed PCs. You can always run MOM Discovery later. To install MOM Management 1. Log on to the Unicenter Manager, and insert the Unicenter NSM installation DVD. The Unicenter Product Explorer appears. Note: The user must be an administrator with the privilege “Act as part of the operating system.” See Set Up an Account for Installation and Discovery in the chapter “Pre-Installation Tasks.” 2. Expand Unicenter for Windows, Post Installation Utilities. A list of utilities appears. 3. Double-click Management for Microsoft Operations Manager and answer the prompts. A window asks for the account that will collect information from MOM. 4. Enter a domain, user name, and password, and click Next. Note: The user must be an administrator with the privilege “Log on as a service.” See Set Up the MOM Management Runtime Account in the chapter “Pre-Installation Tasks.” Unicenter Management for MOM is installed. 5. (Optional) Run MOM Discovery by verifying the domain, user name, and password, and clicking Next. See Run MOM Discovery in the chapter “PostInstallation and Configuration.” MOM entities are classified as MOM servers or MOM managed PCs in the MDB. 166 Implementation Guide Installation of the CA System Center Operations Manager Integration Installation of the CA System Center Operations Manager Integration The installation of the CA System Center Operations Manager Integration (SCOM Integration) involves the following sequence of tasks: 1. Make sure your network conforms to prerequisites. 2. Set up user accounts for installation, SCOM Discovery, and collecting information from SCOM. 3. Install Microsoft System Center Operations Manager Console Client from the SCOM media. 4. Install the SCOM Integration. 5. (Optional) Run SCOM Discovery. Note: Unicenter NSM provides integration kits to both of Microsoft's management applications, Microsoft Operations Manager (MOM) and System Center Operations Manager 2007 (SCOM). Although the integrations to MOM and SCOM can coexist on the same management server, each one integrates only with its Microsoft counterpart. Prerequisites for the SCOM Integration Installation The Unicenter NSM Manager where you install the SCOM Integration must meet the following requirements: ■ The operating system must be Windows 2003 Server. ■ WorldView, Event Management, and Unicenter MCC must be installed, either on the same server or in the same Windows domain. ■ The Microsoft System Center Operations Manager Console Client must be installed where you install SCOM Integration. ■ If SCOM Integration is not on the same server as the Unicenter NSM Manager, a Worldview Client and Event Agent must be installed where you install SCOM Integration. ■ Microsoft System Center Operations Manager (SCOM) and the servers it monitors must be in the same Windows domain. ■ The SCOM database must be on a different server because of SQL configuration differences. Note: See the SCOM Integration readme on the installation DVD for any other system requirements. Chapter 6: Installation 167 Installation of the CA System Center Operations Manager Integration Install the SCOM Integration The CA System Center Operations Manager Integration (SCOM Integration) lets you manage Microsoft System Center Operations Manager (SCOM) alerts from Unicenter NSM. Install the SCOM Integration after you install Unicenter NSM. Note: After the installation, you are prompted to perform SCOM Discovery. You may do so at that time or run SCOM Discovery later. It is not required to first run Discovery on the SCOM network. To install SCOM Integration 1. Log on to the Unicenter Manager, and insert the Unicenter NSM installation DVD. The Unicenter Product Explorer appears. Note: The user must be an administrator with the privilege "Act as part of the operating system." See Set Up an Account for SCOM Installation and Discovery in the chapter "Pre-Installation Tasks." 2. Expand Unicenter for Windows, Post Installation Utilities. A list of utilities appears. 3. Double-click CA System Center Operations Manager Integration and answer the prompts. A window asks for the account that will collect information from SCOM. 4. Enter a domain, user name, and password, and click Next. Note: The user must be an administrator with the privilege "Log on as a service." See Set Up the SCOM Integration Runtime Account in the chapter "Pre-Installation Tasks." 5. (Optional) Run SCOM Discovery by verifying the domain, user name, and password, and clicking Next. See Run CA System Center Operations Manager Discovery in the chapter "Post-Installation and Configuration." SCOM entities are classified as SCOM servers or SCOM managed PCs in the MDB. 168 Implementation Guide Install Unicenter Cisco Integration Install Unicenter Cisco Integration Unicenter NSM integration for Cisco provides enhancements to the generic Cisco class that is supplied with Unicenter NSM. It updates the Cisco classes for both Cisco routers and switches. This integration provides the object identifiers for each Cisco device, which automatically lets Unicenter NSM discover Cisco devices and classify them into a specific Cisco model. After Discovery, Unicenter NSM can display and monitor these Cisco devices. In addition, you can create policy for each Cisco device to customize how Unicenter NSM manages the device in WorldView. To use Unicenter Cisco Integration, you must have access to Cisco's nmidb file that contains device model information. The file is accessible through your cisco.com login privileges, or from your CiscoWorks product CD. You can obtain a valid Cisco user account and password from your channel partner or you can log a request on cisco.com. Note: On Linux and UNIX platforms, Cisco Integration installation is part of the installation interview and is located on the Post Installation Utilities Component Selection window. To install the Unicenter Cisco Device Integration on Windows 1. Insert the installation DVD into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Expand the Post Installation Utilities folder. 3. Click Cisco Integration, and then click Install. A welcome screen appears. 4. Click Next. The installation wizard starts. 5. Follow the installation wizard prompts, and click Finish to complete your installation. Chapter 6: Installation 169 Install TrapManager To run a silent installation of the Unicenter Cisco Device Integration on Windows, enter the following command: msiexec.exe /qn /i “CA Unicenter NSM Cisco Integration.msi” [/lv* <log file>] [PROPERTY=VALUE …] For example: msiexec.exe /qn /i “CA Unicenter NSM Cisco Integration.msi” /lv* “C:\ci.log” INSTALLDIR=”C:\Program Files\CA\Unicenter NSM Cisco Integration” where INSTALLDIR is the installation location for Cisco Integration. To run a silent uninstall of the Unicenter Cisco Device Integration on Windows, enter the following command: msiexec.exe /qn /x “CA Unicenter NSM Cisco Integration.msi” [/lv* <log file>] For example: msiexec.exe /qn /x “CA Unicenter NSM Cisco Integration.msi” /lv* “C:\ci.log” Install TrapManager The TrapManager is a component of Unicenter NSM that lets you perform sophisticated trap database and trap filter file management. You can use the TrapManager to manage trap information and translation messages stored in the Trap Database and trap filters stored in the trap filter file. Note: On UNIX and Linux platforms, TrapManager installation is part of the installation interview and is located on the Post Installation Utilities Component Selection window. To install the Unicenter NSM TrapManager on Windows 1. Insert the installation DVD into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Expand the Post-Installation Utilities folder. Click TrapManager and then click Install. A welcome screen appears. 3. Click Next. The license agreement appears. 170 Implementation Guide Install TrapManager 4. Scroll to the end of the license agreement, accept the license agreement, and click Next. 5. Follow the installation wizard prompts. 6. Click Finish to complete your installation. To run a silent installation of the Unicenter NSM TrapManager on Windows, enter the following command: msiexec.exe /qn /i “CA Unicenter NSM TrapManager.msi” [/lv* <log file>] [PROPERTY=VALUE …] For example: msiexec.exe /qn /i “CA Unicenter NSM TrapManager.msi” /lv* “C:\tm.log” INSTALLDIR=”C:\Program Files\CA\Unicenter NSM TrapManager” XLATE=1 LOADDB=1 INSTALLDIR Specifies the installation for TrapManager. REMOTE Specifies 0 for a local database or 1 for a remote database. The default is 0. REPSERVERID Specifies the server name for the remote database when REMOTE is set to 1. REPSERVERID Specifies the user name for the remote database when REMOTE is set to 1. XLATE When REMOTE is set to 0, specifies 0 to disable message translation for traps and 1 to enable message translation for traps. The default is 1. LOADDB When REMOTE is set to 0, specifies 0 not to lead the default trap database and 1 to load the default trap database. The default is 1. To run a silent uninstall of the Unicenter NSM TrapManager on Windows, enter the following command: msiexec.exe /qn /x “CA Unicenter NSM TrapManager.msi” [/lv* <log file>] For example: msiexec.exe /qn /x “CA Unicenter NSM TrapManager.msi” /lv* “C:\tm.log” Chapter 6: Installation 171 Install Unicenter Remote Monitoring Install Unicenter Remote Monitoring The installation for Unicenter Remote Monitoring lets you select which components of Unicenter Remote Monitoring you want to install on a single computer. We recommend installing the Administrative Interface (AI) on the Unicenter Remote Monitoring agent computer. Additional Administrative Interface-only installs can be performed on as many non-agent computers as necessary. The AI can connect to any Unicenter Remote Monitoring agent in your environment. Important! We recommend that you install the Unicenter Remote Monitoring agent on a dedicated computer for optimum performance. In addition, you may be required to restart your computer during the installation procedure. Therefore, you should exit all programs before beginning the Unicenter Remote Monitoring installation procedure. Install the Remote Monitoring Agent Install Unicenter Remote Monitoring from the Unicenter Product Explorer on your installation DVD. To install the Remote Monitoring agent 1. Expand the folder Unicenter for Windows. The list of subheadings appears. 2. Expand the entry for Post Installation Utilities. A list of utilities appears. 3. Select Remote Monitoring and click Install. The Install Welcome dialog appears. 4. Click Next. The Install Type dialog appears. 5. Select the Complete option to install the agent, the AI, tools, and icons. 6. Click Next and follow the wizard prompts until finished. 7. On the Congratulations dialog, select the “Yes, I want to launch the URM Agent now” check box to immediately start the agent, and then click Finish. The agent starts as soon as the installation completes. 172 Implementation Guide Install Unicenter Remote Monitoring Install the Administrative Interface Only You can install the AI alone on any Unicenter NSM computer. The steps to install only the AI differ from the install of the agent. Begin from the Unicenter Product Explorer on your installation DVD and complete the following procedure. To install the AI only 1. Expand the folder Unicenter for Windows. The list of subheadings appears. 2. Expand the entry for Post Installation Utilities. A list of utilities appears. 3. Select Remote Monitoring and click Install. The Install Welcome dialog appears. 4. Click Next. The Install Type dialog appears. 5. Select the Custom option and click Next. The “Choose the features Setup will install” dialog appears. 6. Select the Administrative Interface and Icons check boxes. The icons install to the same location as the Unicenter MCC icons, allowing the Unicenter Remote Monitoring icons to display correctly with these Unicenter NSM tools. 7. Click Next and follow the wizard prompts until finished. The first time you launch the newly installed AI, it will prompt you for the name of the Unicenter Remote Monitoring agent to which you want to connect. Successive launches automatically connect to the last viewed agent. You can customize the command line of the AI to include the name of the Unicenter Remote Monitoring agent to which you want to connect. If you have installed multiple agents, this will let you launch the AI specifically for the targeted agent. Use the following command: install drive:\installdir\sagui.exe /A agentname Note: If the AI and the Unicenter Remote Monitoring agent are installed on the Unicenter NSM server, skip the following information regarding remote installations. Chapter 6: Installation 173 Install the SPECTRUM Integration Kit After you have installed the AI, you can start discovering resources. Note: For information about discovering your resources through Unicenter Remote Monitoring, see the Unicenter Remote Monitoring online help or the chapter "Monitoring Your Enterprise" in the Administration Guide. Install the SPECTRUM Integration Kit Unicenter NSM integration with SPECTRUM is achieved using the SPECTRUM Integration Kit. After installing the SPECTRUM Integration Kit, you can do the following from Unicenter NSM administrative interfaces: ■ Monitor states of SPECTRUM objects ■ View and manage SPECTRUM device model alarms ■ View SPECTRUM device model alarms as events in the Event Console ■ Access the SPECTRUM OneClick Console from the MCC or 2D Map The SPECTRUM Integration Kit version 3.5 is included with Unicenter NSM r11.2, and you can install it using the Unicenter Product Explorer. Use version 3.5 if you want to integrate Unicenter NSM r11.2 with versions 7.1 or 8.x of SPECTRUM. To integrate with SPECTRUM 9.0, you must use the SPECTRUMNSM Integration Kit version 4.0, which is located on the SPECTRUM 9.0 installation DVD. For more information about using version 4.0 of the kit, see the CA Unicenter NSM SPECTRUM Integration Guide shipped with SPECTRUM. The SPECTRUM Integration Kit uses existing Unicenter NSM and SPECTRUM architectures to establish a communication channel between the two products. After installation, SPECTRUM forwards alarms to Unicenter NSM using the SPECTRUM UnicenterNotifier. The SPECTRUM UnicenterNotifier forwards the alarms to Unicenter NSM using either SNMP traps or the Event Agent. Before you install the SPECTRUM Integration Kit, you must discover the SPECTRUM server that you want to integrate with and decide what method you want to use to forward SPECTRUM alarms to Unicenter NSM. The topics that follow provide information about these pre-installation tasks and the installation procedure. Note: For detailed information about how the SPECTRUM integration works, the complete installation and deployment process, and post-installation configuration, see the Administration Guide. 174 Implementation Guide Install the SPECTRUM Integration Kit Discovery of SPECTRUM Server Before you install the SPECTRUM Integration Kit, you must ensure that the SpectroSERVER has been discovered by Unicenter NSM. This server must have a representative object in WorldView for the integration to work. For the integration to function correctly, the SpectroSERVER server object must be classified as one of the following classes after Unicenter NSM discovers it: ■ Windows2000_Server ■ Windows_NetServer ■ WindowsXP ■ Windows2000 How to Use the Event Agent to Forward SPECTRUM Alarms By default, the SPECTRUM UnicenterNotifier uses SNMP traps to forward alerts to Unicenter NSM. However, you can use the Event Agent to forward alerts to Unicenter NSM as events using message policy if you want a more reliable method of delivery. The coldstart.bat, SetScript, and ClearScript files make use of the cawto command to send the alarms. When the Event Manager receives the alarms from UnicenterNotifier, it forwards them to the DSM, where they are classified and available to view using Unicenter NSM interfaces. To use the Event Agent to forward alerts to Unicenter NSM, complete the following process before installing the SPECTRUM Integration Kit: 1. Install the Event Agent on the SPECTRUM host server. 2. Configure the NSM Event Manager to allow command execution by the Administrator user from the SPECTRUM server. (see page 176) This gives the process running UnicenterNotifier on the SPECTRUM server permission to run commands using Event Management. 3. Recycle opr. 4. Ensure that the Unicenter NSM Event Manager server has the Agent Technology common service installed and is configured to enable Event Management to forward alarm messages to the local DSM. Note: For more details about the Event Agent method of communication, including the format of event messages and examples of different types of event messages, see the Administration Guide. Chapter 6: Installation 175 Install the SPECTRUM Integration Kit Configure the Unicenter NSM Event Manager to Receive Event Agent Alarms If you want to use the Event Agent to forward alarms from the SPECTRUM server to Unicenter NSM, you must configure the Event Manager to allow command execution initiated by the user on the SPECTRUM server running the UnicenterNotifier process. To configure the Event Manager to receive Event Agent alarms from the SPECTRUM server 1. Enter the following command from a command prompt: caugui settings The EM Settings dialog appears. 2. Click the Event Management tab, scroll down to the 'Users authorized to issue commands' entry, double-click the Setting field for this entry, and append the field with the following: , <SpectrumServerName>\Administrator This gives the SPECTRUM Administrator user on the SPECTRUM server running the UnicenterNotifier authorization to issue the Event Management commands necessary to forward SPECTRUM alarms. 3. Close the EM Settings dialog, and run the following commands from a command prompt: unicntrl stop opr unicntrl start opr The Event Management process is reloaded, and the authorization change takes effect. 176 Implementation Guide Install the SPECTRUM Integration Kit Install the SPECTRUM Integration Kit Install the SPECTRUM Integration Kit from the Unicenter Product Explorer on the Unicenter Manager that you want to integrate with SPECTRUM. Complete installation of the kit requires a DSM, WorldView Manager, and Event Manager to be present on the Unicenter NSM server. If one of these components is not present, you can complete a distributed installation by also installing the kit on the server that contains the component that is missing from the original server. Note: The following procedure describes how to install the Unicenter NSM portion of the SPECTRUM Integration Kit. You also must install the "SPECTRUM UnicenterNotifier Installation" piece of the kit on the primary SPECTRUM server to complete the integration. For more information about the complete installation process, configuring the SPECTRUM integration, and different deployment options, see the Administration Guide. To install the SPECTRUM Integration Kit on a Unicenter NSM server 1. Insert the installation DVD into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Expand the Post-Installation Utilities folder. Click Spectrum Integration Kit and then click Install. A welcome screen appears. Chapter 6: Installation 177 Install the SPECTRUM Integration Kit 3. Click Next. The Setup Type screen appears. 178 Implementation Guide Install the SPECTRUM Integration Kit 4. Select Unicenter NSM Integration with Spectrum and click Next. The integration begins to install. A dialog appears asking whether you want to enable the ability to clear SPECTRUM alarms in Unicenter NSM. Chapter 6: Installation 179 Install the SPECTRUM Integration Kit 5. Click Yes or No, depending on if you want to be able to clear SPECTRUM alarms in Unicenter NSM. The SPECTRUM Main Location Server screen appears. 180 Implementation Guide Install the SPECTRUM Integration Kit 6. Enter the name of the SPECTRUM Main Location server in the Server field, and click Next. The Event Trap Daemon Setup screen appears. Chapter 6: Installation 181 Install the SPECTRUM Integration Kit 7. Enter the name of the SpectroSERVER you want to use for the SPECTRUM integration in the Server field, and click Next. The OneClick Launch Setup screen appears. 8. Enter the name of the OneClick webserver you want to use when launching SPECTRUM OneClick. Also, enter the port number (separated from the server name by a colon) if the port you are using for OneClick is different than 80 (For example: OneClickServer:port). Click Next. A dialog appears asking if it is safe to reset the DSM to enable the DSM policy installed by the SPECTRUM Integration Kit. 9. Click Yes. The DSM resets, and a dialog appears asking for permission to issue the awservices start command to restart the DSM. 182 Implementation Guide Install the SPECTRUM Integration Kit 10. Click Yes. The DSM restarts, and a dialog appears stating one of the following: ■ If all required components are present on the Unicenter NSM server, the message informs you that all necessary files for the Unicenter NSM side of the integration have been installed. ■ If all required components are not present on the Unicenter NSM server, the message informs you of the component that did not install. You must install the SPECTRUM Integration Kit again on a server that contains the missing component to complete a distributed installation. Click OK. The Installation Complete screen appears. 11. Click Finish. The installation is complete. The SPECTRUM integration kit files are installed in the following location on the Unicenter NSM server: C:\Program Files\CA\SPECTRUM Integration v3.5 with Unicenter NSM To complete the SPECTRUM integration, you must also install the SPECTRUM UnicenterNotifier Installation component on the appropriate SPECTRUM server. Chapter 6: Installation 183 Install the SPECTRUM Integration Kit To install the SPECTRUM Integration Kit on a SPECTRUM server 1. Insert the installation DVD into the drive. The installation program starts automatically. The Unicenter Product Explorer appears. 2. Expand the Post-Installation Utilities folder. Click Spectrum Integration Kit and then click Install. A welcome screen appears. 184 Implementation Guide Install the SPECTRUM Integration Kit 3. Click Next. The Setup Type screen appears. 4. Select SPECTRUM UnicenterNotifier Installation and click Next. The integration begins to install. If CA Event Management Agent is installed on this system, a dialog appears asking whether you like to forward SPECTRUM events through the Event Agent. Chapter 6: Installation 185 Install the SPECTRUM Integration Kit If Yes, the installation is complete. If No, the DSM Server Setup dialog appears. 5. Enter the Server Name and click Next. The Installation Complete screen appears. 186 Implementation Guide Uninstall Individual Components 6. Click Finish. The installation is complete. The SPECTRUM Integration Kit is installed on the SPECTRUM server. For more information about configuring and deploying the SPECTRUM integration, see the Administration Guide. Uninstall Individual Components The following topics provide instructions for uninstalling individual components from your system. Uninstall Unicenter NSM You can uninstall Unicenter NSM from Windows, Linux, or UNIX platforms using the following procedures. Take great care in deciding whether to uninstall the MDB, as it may be shared by other local products and by other applications across the network that might not be active at any particular moment. You should uninstall the MDB only after making sure you have no other products installed that are dependent on this MDB on this particular server. If you decide to uninstall Unicenter NSM on a Linux or UNIX platform, you may uninstall Ingres along with other selected components. To uninstall Unicenter NSM on a Windows platform 1. Select Start, Settings, Control Panel, Add or Remove Programs. The Add or Remove Programs window opens. 2. Select Unicenter NSM and click Remove. Unicenter NSM is removed from the server. 3. Restart the computer. The uninstallation completes. Notes: The caunint ID is removed during an uninstall only if the ID was created during the installation of Unicenter NSM. The caunint ID is the administrator level ID under which Unicenter Enterprise Management services run. If the installation of Unicenter NSM you are removing was an upgrade to a previous release, the caunint ID is not removed. Chapter 6: Installation 187 Uninstall Individual Components If you decide to uninstall Unicenter NSM, you will need to uninstall the MDB, the MDB users such as the nsmadmin ID, and the entire DBMS manually afterwards. Although these may listed as components for uninstall by the product, selecting them for uninstall only results in their deregistration from the product. The physical items will remain on the machine for use by any other products, whether local or remote. The DBMS itself can be removed by going to the Windows Add or Remove Control Panel applet or by any other mechanism supported by the underlying DBMS. For additional information about removing Microsoft SQL Server on Windows platforms, see the Microsoft SQL Server online books. For additional information about removing Ingres on Windows platforms, see the Ingres for Windows Getting Started. To uninstall Unicenter NSM on a Linux or UNIX platform 1. Run setupNSM from the Unicenter NSM Installation DVD. The Installer window appears. 2. Choose Uninstall Unicenter NSM and click Update. An Update Options screen appears. 3. Select Remove All to uninstall all of Unicenter NSM or Remove Components to uninstall individual components. Notes: The uninstall process creates a log to record the progress of the uninstall. One of two logs is created depending whether you choose Remove All or Remove Components. The log created when removing all of Unicenter NSM is /tmp/CAInstaller.UnicenterNSM.deinstall.log. The log created when removing individual components is /opt/CA/installer/log/UnicenterNSM.update.log. For additional information about removing Ingres on Linux or UNIX platforms, see the Ingres for Linux Getting Started. Microsoft SQL Server is not supported on Linux or UNIX platforms. 188 Implementation Guide Uninstall Individual Components Uninstall CA Common Discovery If you do not want to use the CA Common Discovery program, you can uninstall it. To uninstall CA Common Discovery 1. Select Start, Settings, Control Panel, Add or Remove Programs. The Add or Remove Programs window opens. 2. Select CA Common Discovery, and click Remove. CA Common Discovery is uninstalled. Uninstall Unicenter for Pocket PC If you no longer need to manage your Pocket PC from Unicenter NSM, you can uninstall Unicenter for Pocket PC. To remove Unicenter for Pocket PC from your Pocket PC 1. From the Pocket PC Start menu, select Settings. The Settings dialog appears. 2. Select the System tab, and launch Remove Programs. The Remove Programs dialog appears. 3. Select Computer Associates Unicenter NSM, and click Remove. Unicenter NSM is removed from the Pocket PC. Uninstall Unicenter Management for MOM If you no longer need to manage Microsoft Operations Manager (MOM) alerts from Unicenter NSM, you can uninstall MOM Management. To uninstall Unicenter Management for MOM using the Control Panel 1. Log on to the Unicenter Manager, and choose Start, Settings, Control Panel, Add or Remove Programs. The Add or Remove Programs window opens. 2. Select Unicenter Management for MOM, and click the Remove button. MOM Management is deleted from the server. 3. Restart the computer. Chapter 6: Installation 189 Uninstall Individual Components Uninstall the Integration with System Center Operations Manager If you no longer need to manage Microsoft System Center Operations Manager (SCOM) alerts from Unicenter NSM, you can uninstall the SCOM Integration. To uninstall SCOM Integration using the Control Panel 1. Log on to the Unicenter Manager, and choose Start, Settings, Control Panel, Add or Remove Programs. The Add or Remove Programs window opens. 2. Select CA Unicenter NSM Integration for System Center Operations Manager, and click the Remove button. The SCOM Integration is deleted from the server. 3. Restart the computer. Uninstall Unicenter Cisco Integration When you uninstall Cisco Integration, Cisco device information is not removed. You must manually remove any devices you no longer want to support before you uninstall. See the Cisco Integration online help for more information. To uninstall Cisco Integration 1. Log on to the Unicenter Manager, and select Start, Settings, Control Panel, Add or Remove Programs. The Add or Remove Programs window opens. 2. Select Unicenter Cisco Integration, and click the Remove button. Unicenter Cisco Integration is deleted from the server. 190 Implementation Guide Chapter 7: Post-Installation and Configuration This section contains the following topics: Reghost, Reinstall, Unplug Unicenter NSM Components (see page 191) Configure Active Directory Enterprise Manager (see page 191) Configure Data Scoping (see page 192) Configure and Maintain CAICCI (see page 195) Configure Remote Monitoring (see page 219) Configure Unicenter Management Portal (see page 220) Configure Unicenter for Pocket PC (see page 220) Configure the Unicenter WMI Agent (see page 221) Configure Monitoring for z/OS Interface (see page 221) Run Unicenter Management for MOM Discovery (see page 223) Run CA System Center Operations Manager Discovery (see page 224) Access Unicenter NSM Web Applications (see page 225) Enable Unicenter NSM Integration with eHealth Reports (see page 242) Reghost, Reinstall, Unplug Unicenter NSM Components If you need to reghost, reinstall, unplug, or in any way shut down or make inaccessible a particular computer in your deployment, make certain to implement appropriate precautions for any other computers that depend on the computer. One such precaution can be to temporarily pause their services. For example, if you need to make the MDB or other management components inaccessible, remote computers may fail when they try to perform their function of connecting to the MDB or component. Product reinstallations and upgrades are particularly vulnerable. If remote applications attempt to connect to any one or more components on the node you are reinstalling, both the remote application as well as the local installation can fail. Configure Active Directory Enterprise Manager The Active Directory Enterprise Manager (ADEM) only automatically finds the forest of which the ADEM server is a member. If you have more than one forest you must use the Active Directory Enterprise Manager Connection Settings Utility utility in order for the ADEM to monitor it. See the Inside Active Directory Management guide and the utility help for further information. Chapter 7: Post-Installation and Configuration 191 Configure Data Scoping Configure Data Scoping Data Scoping is a security mechanism that Unicenter NSM uses to protect the WorldView components from unauthorized access. Data Scoping is automatically installed with WorldView To configure or implement Data Scoping involves writing Data Scoping rules that filter or protect the data. To implement Data Scoping, you must define a set of Data Scoping rules. Each set of Data Scoping rules governs data access only for the MDB for which they are defined. If more than one MDB exists on a computer, each MDB has its own set of autonomous rules. Further, if a user of a single computer connects to more than one MDB, each MDB has its 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. 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 can also activate and deactivate a Data Scoping rule by specifying that it use a particular calendar. By default, users connected to the MDB have full access to objects until Data Scoping rules are generated to deny particular types of access. You can define class-level rules or object-level rules. Class-level rules scope data objects using their data classification. Object-level rules let you explicitly filter data objects on an object-by object basis using the object's instance-level properties. 192 Implementation Guide Configure Data Scoping Configure Data Scoping for Linux and UNIX Configure data scoping for Linux and UNIX to define users and give or remove their access to the MDB. To configure Data Scoping for Linux and UNIX 1. To initialize Data Scoping, run: $CAIGLBL0000/wv/bin/wvscpini.exe -r database where database is the name of the MDB on which you want to activate Data Scoping. Remote MDBs are not supported; therefore, the database name should be that of the local MDB. Note: Only root can execute this command and the commands that follow. When you execute this command after connecting to the repository, applications already connected do not have Data Scoping rules enforced until you restart the applications. 2. Recycle WorldView. 3. To define users, run the following command: $CAIGLBL0000/bin/cautil Note: To use the cautil utility to define users, Security Management must be installed. See the CA Reference for more information about the cautil utility. 4. To give users access to the MDB, run the following command: $CAIGLBL0000/wv/scripts/add_ingres_user 5. To remove a user's access to the Ingres database, run the following command: $CAIGLBL0000/wv/scripts/delete_user_ingres 6. To define Data Scoping rules and associate rules with users, run the following command: $CAIGLBL0000/wv/bin/scputil.exe See the Data Scoping topics in the MCC help for additional information. See the CA Reference for more information about the scputil executable. If, after activating and using Data Scoping, you want to deactivate it, run the following command: $CAIGLBL0000/wv/bin/wvscpdel.exe Chapter 7: Post-Installation and Configuration 193 Configure Data Scoping Configure Data Scoping for Windows Before you can begin to use the Data Scoping Rule Generator in Windows, you must complete the following configuration procedure. To configure Data Scoping for Windows 1. Activate the Data Scoping utility and create the Data Scoping classes by executing the following command: wvscpini.exe Note: Only administrators can execute this command and the commands that follow on Data Scoping functions. When you execute this command after connecting to the MDB, applications already connected do not have Data Scoping rules enforced until you restart the applications. 2. Execute the following command to start the Data Scoping Rule Generator GUI and create new rules or update existing rules: datargen.exe 3. If, after activating and using Data Scoping, you want to deactivate it, execute the following command: wvscpdel.exe For additional information, see the Data Scoping topics in the MCC help and in the Administrator Guide. Create Data Scoping Rules Using the MCC You use the Data Scope Rule Editor to create Data Scoping rules to protect the MDB object data from unauthorized access, or to filter large amounts of data into smaller subsets of data for a group or user. Note: The administrator must be authorized to create or update rules for the specific class. To create Data Scoping rules 1. Open the Management Command Center, click the left pane menu and select Class Specification. The Class Specification view appears. 2. Select the ManagedObject class or Association class for which you want to create a rule. You can create Data Scoping rules only for these two classes and subclasses of these classes. The class is highlighted. 194 Implementation Guide Configure and Maintain CAICCI 3. Right-click New, Rule from the context menu. The Data Scope Rule Editor appears. A default Data Scoping rule for the class is created that allows full access to class objects for all users. You can modify the rule and make it more specific. For more information, see the MCC help. Configure and Maintain CAICCI The acronym CAICCI stands for CA Common Communications Interface. This topic explains briefly how to configure, manage, and test an important communication component that runs on Unicenter NSM and Unicenter Job Management. The topic describes how to test CAICCI communication between Windows, UNIX/Linux, HP NonStop, OpenVMS, and a job management manager. CAICCI Overview CAICCI is the Common Communications Interface for Unicenter NSM and Unicenter Job Management, and is essentially the glue among the various Enterprise Management components across a heterogeneous environment. CAICCI uses and runs on top of TCP/IP. CAICCI is implemented as three processes or daemons: ■ CAICCID is referred to as the main CAICCI daemon because it starts first and builds the necessary CAICCI resources. It is responsible for starting and stopping the other two processes. ■ CCICLND is referred to as the clean daemon because its responsibility includes the maintenance of the CAICCI IPC resources. ■ CCIRMTD is the remote daemon process that is responsible for transmission of data across the network. For a Unicenter job manager to communicate with the Unicenter Universal Job Management Agent on a target machine, you need to configure CAICCI on each platform. This topic provides step-by-step instructions for configuring CAICCI on the following platforms: ■ Windows ■ UNIX ■ HP NonStop ■ OpenVMS ■ OS/400 ■ the mainframe Chapter 7: Post-Installation and Configuration 195 Configure and Maintain CAICCI LOCAL and REMOTE Statements The format is the same for the LOCAL and REMOTE statements. The brackets are applied in the syntax example to separate the parameter names. Otherwise, the parameters are delimited by a space. LOCAL and REMOTE statements have the following format: LOCAL = <TCP/IP name><CCI name><buffersize><startup options><alias options><port options><retry interval> REMOTE = <TCP/IP name><CCI name><buffersize><startup options><alias options><port options><heartbeat options><retry interval> TCP/IP name Specifies either an IP address or a name that is used as input to a name service to retrieve an IP address. You may use the TCP/IP name with the PING command to determine whether a remote connection is live. The default is the TCP/IP host name. It does not require a logical connection to the CCI name. CCI name Specifies the logical name CAICCI uses to identify this host. This is the system name, which may or may not be the same as the IP hostname. This name may be as long as 64 characters, but an alias must be used for names greater than eight characters. For the REMOTE statement that defines the mainframe, the CAICCI name is the value specified by SYSID (xxxx) in the //ENFPARMS DD statement. This value is also on the PROTOCOL statement in //ENFPARMS. buffersize Specifies the maximum buffer CAICCI will receive or send over the socket, a value used for segmenting the data transfer. Each side of the connection may have this set to a different value, between 1024 and 32768. The lesser of the two values will be used. It is generally not necessary to alter this field. Important! Contact CA Customer Support before changing the buffer size. startup options Tells ccirmtd (the CAICCI remote daemon) whether to initiate a connection-sometimes you may want only one side to initiate the connection. Not having the server start connections eliminates a succession of messages when CAICCI is recycled. STARTUP tells CAICCI to attempt a remote connection when activated, whereas NOSTART implies that the remote system will be initiating the connection to the node. 196 Implementation Guide Configure and Maintain CAICCI alias options Specifies an optional alias name used to differentiate multiple remote computers having exactly the same first eight characters (when their host names exceed eight characters).It specifies that, for hosts with a hostname greater than eight characters, this name is used for internal CAICCI structures. This alias need not appear in DNS or IP host file. It must be unique and consistent across nodes. When an alias is used on the LOCAL line for a host with a name greater than eight characters, all hosts to which it will be connected must have a REMOTE line for this host with this same alias defined. The format is <ALIAS=aliasname>. port options Allows you to specify an alternate port for this specific connection only. Sometimes you may have two groups of hosts. One may still use the old 7000 port and the new ones may use the new 1721 port. Any host from the first group wishing to communicate with the second group must be made aware that the connection should be made to a different port. The format is PORT=1721. Do not change this value. heartbeat options Specifies whether the CAICCI remote heartbeat feature is enabled. The heartbeat feature detects connection loss with the remote node if the remote node terminates the connection without notification. The format to enable the heartbeat feature is HEARTBEAT=YES. The format to disable the heartbeat feature is HEARTBEAT=NO. You can also define the heartbeat functionality by using environment variables as follows. On Linux or UNIX: CAI_CCI_RMTHEARTBEAT When this variable is set to 1, the heartbeat option is enabled to all the nodes listed in the ccirmtd.prf file. However, explicitly setting the option in the ccirmtd.prf file takes precedence over the global flag. The variable needs to be unset to turn it off after being set. CAI_CCI_HBTIMEOUT By default, the wait time for an acknowledgement to ping from the remote node is 30 seconds. You can alter this value by setting the variable to a desired number of seconds. The minimum and maximum values allowed are 15 and 45 seconds. The value defaults to 30 seconds if any other value is set. Chapter 7: Post-Installation and Configuration 197 Configure and Maintain CAICCI On Windows: CAI_CCIRMT_HEARTBEAT When this variable is set to YES, the heartbeat option is enabled to all the nodes listed in the ccirmtd.rc file. However, explicitly setting the option in the ccirmtd.rc files takes precedence over the global flag. CCIRMTPINGTIMEOUT By default, the wait time for an acknowledgement to the ping from the remote node is 30 seconds. You can alter this value by setting the variable to a desired number of seconds. The minimum and maximum values allowed are 15 and 45 seconds. The value defaults to 30 seconds if any other value is set. You can set the variables using the Configuration Settings GUI (Options, CCI Options tab) or from the command prompt by running the following commands: cautenv setopt CAI_CCIRMT_HEARTBEAT value cautenv setopt CCIRMTPINGTIMEOUT value retry interval Determines how ccirmtd behaves if the connection is dropped and specifies the number of seconds between retry connect attempts. The format is as follows: – If x=0, ccirmtd will not retry the connection. – If x=-1, ccirmtd will start with a two second retry interval and double after each unsuccessful retry attempt. – If x > 0, ccirmtd will wait n seconds between retry attempts. Note: Retry interval is mainly used in conjunction with the nostart option to allow the server to sit passively and wait for incoming connection requests. If a client host goes down, the server will not attempt to reconnect. 198 Implementation Guide Configure and Maintain CAICCI Basic Sample Configuration Assume you have four systems, all with node names of eight characters or less: NTSYS1, VMSSYS2, UNXSYS3, and HPNSTP4. The configuration file for each system follows: UNIX: CCIRMTD.PRF LOCAL = UNXSYS3 UNXSYS3 32768 startup REMOTE = NTSYS1 NTSYS1 32768 startup REMOTE = VMSSYS2 VMSSYS2 32768 startup REMOTE = HPNSTP4 HPNSTP4 32768 startup Windows Manager: CCIRMTD.RC LOCAL = NTSYS1 NTSYS1 32768 startup REMOTE = UNXSYS3 UNXSYS3 32768 startup REMOTE = VMSSYS2 VMSSYS2 32768 startup REMOTE = HPNSTP4 HPNSTP4 32768 startup OpenVMS: CCIRMTD.PRF LOCAL = VMSSYS2 VMSSYS2 32768 startup REMOTE = UNXSYS3 UNXSYS3 32768 startup REMOTE = NTSYS1 NTSYS1 32768 startup REMOTE = HPNSTP4 HPNSTP4 32768 startup HP NonStop: CACCICFG.RMTPRF LOCAL = HPNSTP4 HPNSTP4 32768 startup REMOTE = UNXSYS3 UNXSYS3 32768 startup REMOTE = NTSYS1 NTSYS1 32768 startup REMOTE = VMSSYS2 VMSSYS2 32768 startup Advanced Sample Configuration In this configuration, assume that all of the host or system names are longer than eight characters (OPENVMSSYS1, for example). The configuration files would be as follows: UNIX: CCIRMTD.PRF LOCAL = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3 REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1 REMOTE = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2 REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4 Windows Manager: CCIRMTD.RC LOCAL = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1 REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3 REMOTE = VMSSYS2 32768 OPENVMSSYS2 startup ALIAS=VMSNOD2 REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4 Chapter 7: Post-Installation and Configuration 199 Configure and Maintain CAICCI OpenVMS: CCIRMTD.PRF LOCAL = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2 REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3 REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1 REMOTE = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4 HP NonStop: CACCICFG.RMTPRF LOCAL = HPNSTP4 HPNONSTOP4 32768 startup ALIAS=HPNS4 REMOTE = UNXSYS3 UNIXSERVER3 32768 startup ALIAS=UNX3 REMOTE = NTSYS1 WINNTSYS1 32768 startup ALIAS=NT1 REMOTE = VMSSYS2 OPENVMSSYS2 32768 startup ALIAS=VMSNOD2 Configure CAICCI on Windows During post-installation, you must configure CAICCI on every Windows machine on which you have installed the Unicenter Universal Job Management Agent (UJMA). To configure CAICCI on Windows 1. Attempt to ping the job manager node. If you cannot, modify the TCP/IP setup on the Windows machine as well as on the job manager machine. This may require a DNS entry or an entry in the Windows machine's %SystemRoot%\system32\drivers\etc\hosts file for the job manager or mainframe ENF node name. 2. Issue the following command to verify that the Remote Server is installed: ccicntrl A series of messages appears indicating status. If the Remote Server is installed and running, the following message appears: Service "CA-Unicenter (Remote)", STATUS is "Running" 3. Define a connection between job manager nodes and the UJMA machine. To define it on the UJMA machine, use LOCAL and REMOTE statements in the CAICCI configuration file, located at InstallPath\CAIUSER\ccirmtd.rc. The LOCAL statement applies to the local computer, while any REMOTE statements apply to the remote nodes that exchange information through CAICCI. For an explanation of the syntax and parameters in the LOCAL and REMOTE statements, see the section LOCAL and REMOTE Statements. The definitions apply to both LOCAL and REMOTE statements. 200 Implementation Guide Configure and Maintain CAICCI LOCAL Statement Example The following LOCAL statement example tells CAICCI that the TCP/IP name of the local machine is NTSYS1 and that any remote system wishing to communicate with this system can do so by referencing NTSYS1 as the name. Any UJMA within the network can send and receive messages to this system independent of hardware or protocols, if it uses the name NTSYS1. LOCAL = NTSYS1 NTSYS1 32768 STARTUP REMOTE Statement Examples The following REMOTE statement example tells CAICCI to attempt a connection to 172.22.111.121 and to internally register MF01 as the CCI name. Any Job Management Agent within the network can send and receive messages to this system independent of hardware or protocols, if it uses the name MF01. REMOTE = 172.22.111.121 MF01 32768 STARTUP PORT=1721 The following REMOTE statement example tells CAICCI to attempt a connection to the computer whose TCP/IP name is UNXSYS3 and whose CCI name (machine name) is UNIXSERVER3, but also to allow UJMA to send and receive messages using the alias UNX3. REMOTE = UNXSYS3 UNIXSERVER3 32768 STARTUP ALIAS=UNX3 4. If the Remote Server is not installed, issue the following command: ccicntrl install rmt <path> where path represents the location of the drive:\NSM\bin (installation path\bin). 5. Start the Remote Server if necessary. The Remote Server must be running. To determine whether it is running, issue the following command: ccicntrl A series of messages appears indicating the status. If the Remote Server is running, the following message is included: Service "CA-Unicenter (Remote)", STATUS is "Running". If the Remote Server is not running, issue the following command to start it: ccicntrl start rmt If you modified the ccirmtd.rc file as described in Step 3, and the Remote Server is still active, recycle the Remote Server by issuing the following commands: ccicntrl stop rmt ccicntrl start rmt Chapter 7: Post-Installation and Configuration 201 Configure and Maintain CAICCI If the Unicenter service (or any other service that depends on CAICCI) is running, stop it manually prior to stopping CAICCI with this command. If you use the Windows Services Control Panel applet to stop the Remote Server instead of using the ccicntrl stop command, you will see the list of any dependent services. 6. Issue the following command to verify that CAICCI has established communications: ccii The following is an example of the output of this command: Oid(SCHLAP2,CAI_OPR_SAFD ) Did( , ) type(L) Oid(SCHLAP2,CAU9SET SetUp Mgr Oid(SCHLAP2,SUBMITC Server Oid(A44SENF,W410_SPAWN_SERVER Oid(A44SENF,MVS_START_SERVER Oid(A44SENF,CA7XE44 Server ) Did( , ) type(L) ) Did( , ) type(L) ) Did( , ) type(R) ) Did( , ) type(R) ) Did( , ) type(R) Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R) Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R) In this example, the lines with the A44SENF entries indicate that the CAICCI connection has been made to a mainframe. SCHLAP2 is the Windows machine where UJMA is installed. The ccii command displays the CAICCI applications that are available. If UJMA has not been started, no entries are displayed for the local machine. Configure CAICCI on Linux or UNIX During post-installation, you must configure CAICCI on every UNIX or Linux machine where the Unicenter Universal Job Management Agent (UJMA) is installed. To configure CAICCI on Linux or UNIX 1. Attempt to ping the job manager node. If you cannot, modify the TCP/IP setup on the Linux or UNIX machine as well as on the job manager node. This may require a DNS entry or an entry in the /etc/hosts file of the Linux or UNIX machine for the job manager or mainframe ENF node name. (Note the MVS host name.) 2. Define a connection between job manager nodes and the UJMA machine. To define it on the UJMA machine, use LOCAL and REMOTE statements in the CAICCI configuration file, located at $CAIGLBL0000/cci/config/local host/ccirmtd.prf. 202 Implementation Guide Configure and Maintain CAICCI LOCAL and REMOTE Statement Format The LOCAL statement applies to the local Linux or UNIX computer, while REMOTE statements apply to the remote nodes that exchange information with CAICCI. For an explanation of the syntax and parameters in the local and remote statements, see the section LOCAL and REMOTE Statements. The definitions apply to both LOCAL and REMOTE statements. LOCAL Statement Example The following example tells CAICCI that the TCP/IP name of the local machine is UNXSYS3 and that any remote system that wants to communicate with this system should reference UNXSYS3 as the name. Any Job Management Agent within the network can send and receive messages to this system independent of hardware or protocols if it uses the name UNXSYS3. LOCAL=UNXSYS3 UNXSYS3 32768 STARTUP REMOTE Statement Examples The following REMOTE statement example tells CAICCI to attempt a connection to 172.22.111.123 and to internally register MF01 as the CCI name. Any Job Management Agent within the network can send and receive messages to this system, independent of hardware or protocols, if it uses the name MF01. REMOTE=172.22.111.123 MF01 32768 STARTUP PORT=1721 The following REMOTE statement example tells CAICCI to attempt a connection to the computer whose TCP/IP name is NTSYS1 and whose CCI name is WINNTSYS1, but also to allow any Job Management Agent to send and receive messages using the alias NT1. REMOTE=NTSYS1 WINNTSYS1 32768 STARTUP ALIAS=NT1 3. Issue the following command to determine the status of the Remote Server: unifstat A series of messages appears indicating the status of servers. If the Remote Server is running, the following message is included: CA-CCI Remote Server nnn running where nnn is the process ID of the Remote Server process. 4. Start the Remote Server if necessary. If the Remote Server is not running, issue the following command to start all processes including CAICCI: unistart all Chapter 7: Post-Installation and Configuration 203 Configure and Maintain CAICCI If you modified the ccirmtd.prf file (Step 2), and the Remote Server is active, issue the following command: unicycle all This command stops and starts all Unicenter processes. 5. Issue the following command to verify that CAICCI has established communications: $CAIGLBL0000/cci/bin/ccii The ccii command displays the CAICCI applications that are available. If Unicenter services have not been started, no entries are displayed for the local machine. Following is an example of the output of this command: Oid(SCHLAP2,CAI_OPR_SAFD ) Did( , ) type(L)Oid(SCHLAP2,CAU9SET SetUp Mgr ) Did( , ) type(L) Oid(SCHLAP2,SUBMITC Server ) Did( , ) type(L) Oid(A44SENF,W410_SPAWN_SERVER Oid(A44SENF,MVS_START_SERVER Oid(A44SENF,CA7XE44 Server ) Did( , ) type(R) ) Did( , ) type(R) ) Did( , ) type(R) Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R) Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R) In this example, the lines with the A44SENF entries indicate that the CAICCI connection has been made to a mainframe. SCHLAP2 is the UNIX machine where UJMA is installed. Configure CAICCI on HP NonStop During post-installation, you must configure CAICCI on every HP NonStop machine on which you have installed Unicenter Universal Job Management Agent (UJMA). To configure CAICCI on HP NonStop 1. Attempt to ping the job manager node. If you cannot, modify the TCP/IP setup on the HP NonStop machine and on the job manager machine. This may require a DNS entry or an entry in the HP NonStop machine's $SYSTEM.ZTCPIP.HOSTS file for the job manager or mainframe ENF node name. (Note the MVS host name.) 2. Define a connection between job manager nodes and the UJMA machine. To define it on the UJMA machine, use LOCAL and REMOTE statements in CACCICFG.RMTPRF, the CAICCI configuration file. 204 Implementation Guide Configure and Maintain CAICCI LOCAL and REMOTE Statement Format The LOCAL statement applies to the local computer. REMOTE statements apply to the remote nodes that exchange information with CAICCI. The LOCAL statement is automatically configured in the NSK installation. The REMOTE event node can be optionally configured in the NSK installation. For an explanation of the syntax and each parameter in the LOCAL and REMOTE statements, see the section LOCAL and REMOTE Statements. The definitions apply to both LOCAL and REMOTE statement formats. LOCAL Statement Example The following LOCAL statement example tells CAICCI that the TCP/IP name of the local machine is HPNSTP4 and that any remote system that wants to communicate with this system can do so by referencing HPNSTP4 as the name. Any Job Management Agent within the network can send and receive messages to this system, independent of hardware or protocols if it uses the name HPNSTP4. LOCAL=NSK01 NSK01 31998 STARTUP REMOTE Statement Examples The following REMOTE statement example tells CAICCI to attempt a connection to 172.22.111.125 and to internally register MF01 as the CCI name. Any UJMA within the network can send and receive messages to this system, independent of hardware or protocols if it uses the name MF01. REMOTE=172.22.111.125 MF01 31998 STARTUP PORT=1721 The following example tells CAICCI to attempt a connection to the computer whose TCP/IP name is UNXSYS3 and whose CCI name is UNIXSERVER3, but also to allow UJMA to send and receive messages using the alias UNX3. REMOTE=UNXSYS3 UNIXSERVER3 31998 STARTUP ALIAS=UNX3 3. Determine the status of the Remote Server. The Remote Server must be running. To determine whether it is running, issue the following command: unifstat A series of messages appears indicating the status of servers. If the Remote Server is running, the following message is included: CCI Remote Server nnn running where nnn is the process ID of the Remote Server process. 4. Start the Remote Server if necessary. If the Remote Server is not running, issue the following command to start all processes including CAICCI: unistart all Chapter 7: Post-Installation and Configuration 205 Configure and Maintain CAICCI If you modified the ccirmtd.prf file (Step 2), and the Remote Server is active, issue the following commands: unishutdown all unistart all These commands stop and start all processes. Configure CAICCI on OpenVMS During post-installation, you must configure CAICCI on every OpenVMS machine on which you have installed the Unicenter Universal Job Management Agent (UJMA). To configure CAICCI on OpenVMS 1. Attempt to ping the job manager node. If you cannot, modify the TCP/IP setup for the particular TCP/IP stack on the OpenVMS machine as well as the job manager node. This may require a DNS entry or configuration of the TCP/IP stack. Refer to the documentation for your particular TCP/IP stack. 2. Define a connection between job manager nodes and the UJMA machine. To define it on the UJMA machine, use LOCAL and REMOTE statements in the CAICCI configuration file, located at CAI_CCI_nodename:ccirmtd.prf. LOCAL and REMOTE Statement Format The LOCAL statement applies to the local computer, where the REMOTE statements apply to the remote nodes that exchange information with CAICCI. The syntax is the same for the LOCAL and REMOTE statements: LOCAL = <TCP/IP name><CCI name><buffersize><startup options><alias options><port options><retry interval> REMOTE = <TCP/IP name><CCI name><buffersize><startup options><alias options><port options><retry interval> For an explanation of the syntax and each parameter in the local and remote statements, see the section LOCAL and REMOTE Statements. The definitions apply to both LOCAL and REMOTE statement formats. 206 Implementation Guide Configure and Maintain CAICCI 3. Determine the status of the Remote Server. The general-purpose utility RMTCNTRL is available to help manage the remote daemon. The following syntax is supported: rmtcntrl show Outputs data concerning the hosts to which the remote daemon is or should be connected. It will also output information about the receivers available on those remote platforms similar to the RVT (Receiver Vector Table) information displayed by cci show. The information will be provided in sys$manager:syslog.log. rmtcntrl debugon/rmtcntrl debugof Enables or disables remote traces without recycling the remote daemon. Trace data is written to the log directory defined by the logical CAI_CCI_LOG. rmtcntrl status Displays information concerning the remote hosts to which the remote daemon is connected or to which it should be connected. This data appears in tabular form on stdout. If you receive a “no receiver online” error, check this output; it may show that you are not connected to the host in question. rmtcntrl release Displays the release of the ccirmtd to stdout. The command gives the release as follows: xxxyyzzzz xxx Specifies the source code version (for example, 1.137) yy Specifies the genlevel of Unicenter NSM (for example, 31 for NSM 3.1) zzzz Specifies the release of Unicenter NSM (for example, 9708) rmtcntrl disconnect <sysid> Causes the local remote to issue a disconnect command to the sysid specified and then close down the connection. This has the effect of severing the connection between these hosts. Neither side attempts to reestablish the connection. rmtcntrl reconnect <sysid> Disconnects hosts that are connected and then reconnects them. If hosts are not connected, the local remote daemon attempts to connect to the remote host. Chapter 7: Post-Installation and Configuration 207 Configure and Maintain CAICCI rmtcntrl ping <sysid> Requests the local remote daemon to send a special CAICCI packet to a remote daemon. This command lets you determine if the CAICCI connection is useful at the most basic level. Upon successful completion, the roundtrip time is displayed. rmtcntrl echo <sysid><message> Displays message on the target systems console if successful. Another useful tool for determining how well the CAICCI connection between two hosts is functioning. rmtcntrl retry <sysid>N Affects the retry time interval as follows: If N >0 Set the retry time interval to N If N = -1 Set the retry time interval to 2, then double on each successive failure If N = 0 Prevents the local host from attempting to reconnect 4. Issue the following command to verify that CAICCI has established communications. ccii The ccii command displays the CAICCI applications that are available. If Unicenter services have not been started, no entries are displayed for the local machine. Following is an example of the output of this command: Oid(vmsys1,Cci.Remote.SERVER ) Did( , ) type(L)Oid(vmsys1,CAU9SET SetUp Mgr ) Did( , ) type(L) Oid(vmsys1, SUBMITC Server ) Did( , ) type(L) Oid(A44SENF,W410_SPAWN_SERVER ) Did( , ) type(R) Oid(A44SENF,MVS_START_SERVER ) Did( , ) type(R) Oid(A44SENF,CA7XE44 Server ) Did( , ) type(R) Oid(A44SENF,BARRYNT2.A44SENFUL2 ) Did( , ) type(R) Oid(A44SENF,CA7XE44 Job track ) Did( , ) type(R) 208 Implementation Guide Configure and Maintain CAICCI In this example, the lines with the A44SENF entries indicate that the CAICCI connection has been made to a mainframe: vmsys1 is the OpenVMS machine where UJMA is installed. 5. Monitor CAICCI. Certain syntax is supported to help you understand CAICCI activities. cci show Lets you view the shared memory segment in which CAICCI stores the RVT list. This command is useful to determine general CAICCI information such as the number of free and active RVTs, the key used to create the CAICCI resources, the identifiers for the CAICCI resources, the process IDs of the CAICCI daemons, and the time the shared memory was created. You can also use this command to display the following information about a specific receiver: 6. ■ The existence of a specific receiver ■ The number of pending messages for a specific receiver ■ The PID of the process that created the receiver ■ The PID of the process that holds the semaphore for this receiver ■ The last send and receive time ■ The number of sends and receives Manage CAICCI. Certain syntax is supported to help you manage CAICCI: cci shutdown Tells the main daemon to shut down. The use of this command is not advised if Unicenter NSM is still running. cci debugon/cci debugoff Turns main daemon tracing on and off. 7. Check CAICCI logicals. The following table describes the logicals that are available on the OpenVMS platform. The logicals are defined in the file sys$startup:cci$environment.com. Do not modify this file unless directed to do so by CA Customer Support. If any of the values in this file are modified, CAICCI and any dependent applications will need to be restarted. Variable Definition and Use Components Affected CAI_CCI _DEBUG All CAICCI processes Use for tracing purposes. Use and applications set to enable CAICCI traces, unset to disable CAICCI traces. using CAICCI Chapter 7: Post-Installation and Configuration 209 Configure and Maintain CAICCI Variable Definition and Use Components Affected CAI_CCI_LOG The directory to which CAICCI trace file will be written. Use if a larger volume is required for trace output. Example: CAI_CCI_LOG=path, where path is a directory. All CAICCI processes and applications using CAICCI CAI_CCI _CONFIG Sets the path to the CAICCI configuration directory. Example: CAI_CCI_CONFIG=path All CAICCI processes CAI_CCI _PORT1 Use for firewalls or certain Remote daemon multi NIC situations: ccirmtd process will bind to specified port prior to connect calls. Example: CAI_CCI_PORT1=n, where 250 < n < 65k CCI_SELECT _TIME Sometimes network conditions will cause the TCP/IP handshake to take a long time to complete. Determines the timeout for select after connect. Example: CCI_SELECT_TIME=n, where n > 1. Remote daemon process Configure CAICCI on OS/400 During post-installation, you must configure CAICCI on every OS/400 machine on which you have installed the Unicenter Universal Job Management Agent (UJMA). To configure CAICCI on OS/400 1. Define CAICCI server node. You must select a Windows system in your network to function as the CAICCI Server Node for your OS/400 systems. This Windows system should run CAICCI services, either as part of Unicenter NSM or as part of Unicenter Universal Job Management. Configuration on the OS/400 system involves running the CAICCI configuration command, CACFGCCI, on the OS/400 system and specifying the name of the Windows node that will function as the CAICCI Server Node. (For more information about CACFGCCI see the Unicenter Universal Job Management Agent User Guide chapter “Job Management Agent Commands.”) 210 Implementation Guide Configure and Maintain CAICCI The CAICCI Server Node provides directory services to the Event Management component of UJMA on OS/400. The CAICCI Server Node can be the same machine as the Event Database Server Node, although it is not necessary that these nodes be the same. Note: The Event Database Server Node is configured with command CACFGEVT. 2. Configure remote bridge node. If UJMA on OS/400 will receive job submission requests from non-Windows platforms such as UNIX and OS/390, CAICCI, or the Remote Bridge Node, must be configured on OS/400. There are two parts to this configuration. These steps should be completed prior to starting UJMA on OS/400. If you change the configuration while UJMA is running on OS/400, you must stop and restart the CAICCI Remote services on your OS/400 system. From a command prompt on the OS/400 system, enter the following commands in order: cajmastop *cci *rmtd cajmastart *cci *rmtd The messages returned should indicate that CAICCI was stopped and restarted. Part 1-Specify OS/400 Node Name From a command prompt on the OS/400 system, enter the command CACFGCCI, and specify the name of the OS/400 node as the value of the option Remote Bridge Node Name. An example follows: CACFGCCI OS/400_nodename Part 2-Define a Remote Connection You must define a remote connection between the OS/400 system and each remote UNIX or mainframe system that will be submitting jobs to your OS/400 system. These connections may be defined on the remote hosts or on the local OS/400 system. If they are defined on the remote hosts, it is not necessary to define them on the OS/400 system. Similarly, if you define them on the OS/400 system, it is not necessary to define them on the remote hosts. To define connections on remote hosts, see the documentation for those remote platforms. To define connections on the OS/400 system, add REMOTE entries to the CAICCI configuration file, as shown: /UJMA/cci/ccirmtd.rc Chapter 7: Post-Installation and Configuration 211 Configure and Maintain CAICCI The syntax and interpretation of the REMOTE entries in this file is identical to that described previously for the Windows, UNIX, or Linux platforms. The following illustration is an example of the ccirmtd.rc file: You can edit this file by entering the following OS/400 command at the command prompt: WRKLNK '/UJMA/cci/ccirmtd.rc' Select option 2 to invoke the OS/400 editor. 3. Establish CAICCI connections. For a CAICCI connection to be established, the following conditions must be met: ■ You must be able to PING the remote TCP/IP name from the OS/400 system. ■ You must be able to PING the OS/400 system name from the remote host. ■ CAICCI must be started on the remote host. ■ CAICCI must be started on the OS/400 system. To start CAICCI on the OS/400 system, first configure CAICCI (as described previously), specifying the OS/400 system name as the value for the Remote Bridge Node Name option in CACFGCCI. For example: CACFGCCI BRGNODNAME(local-os400-system) Then any of the following commands would cause the remote bridge node (CAICCI) to start on OS/400: cajmastart *all cajmastart *cci cajmastart *cci *rmtd 4. Enter the following command at the command prompt to check the status of CAICCI connections with remote systems (whether configured locally or remotely): caccirmt status This displays the status of all connections on the terminal. 212 Implementation Guide Configure and Maintain CAICCI 5. Verify remote job servers. To verify that remote job servers can be reached by CAICCI, you can run the CAUNICTRL command, which displays the same information that is available from CCII on Windows and UNIX platforms. At an OS/400 command line, run command caunictrl: Caunictrl At the prompt, type the subcommand 'i', which stands for 'inquiry': ===> i A list of all known remote server applications appears, as shown in the following sample: You should find entries for the job management products in the list. To quit the CAUNICTRL utility, type the subcommand 'qq': ===> qq 6. Verify CAICCI communications. On OS/400, the commands CACCIR and CACCIS are the counterparts of the commands “ccir” and “ccis” that are available on Windows and UNIX or Linux. To test a CAICCI receiver on OS/400, run the command: caccir To test a CAICCI sender on OS/400, run the command: caccis node('remote-host-name') count(nnn) Chapter 7: Post-Installation and Configuration 213 Configure and Maintain CAICCI To stop the CAICCI receiver test on OS/400, run the command: casetevt 'test.cci.receiver' Read the output messages that are sent to the terminal by the caccir and caccis commands which indicate either a successful or failed attempt to communicate. Configure CAICCI on the Mainframe You can configure CAICCI on the mainframe before or after installing the Unicenter Universal Job Management Agent (UJMA). To configure CAICCI on the mainframe 1. Ensure required FMIDs are installed for TCP/IP support. The following CA Common Services for z/OS and OS/390 FMIDs (functional sysmods) are required for TCP/IP support: FMID Service CS91000 CAIRIM - CA Resource Initialization Manager CW11000 CW21000 CAIENF - CA Event Notification Facility CW41100 CAICCI - CA Common Communications Interface CF33100 CA-C Runtime 3.1 - CA C Language Runtime Facility, Version 3.1 Ensure that all of these FMIDs are installed. If any are missing, install them before continuing. See the CA Common Services for z/OS and OS/390 Getting Started for instructions. If the CAS9DCM3 database is not installed, perform task 11d in the CA Common Services for z/OS and OS/390 Getting Started. 2. 214 Implementation Guide Link edit CAICCI with TCP/IP. Requirements for link editing CAICCI with TCP/IP differ based on the combination of TCP/IP and runtime libraries you are using. See either of the following for a description of the link-edit process: ■ CA Common Services for z/OS and OS/390 Getting Started ■ CA Common Services for z/OS and OS/390 Administrator Guide Configure and Maintain CAICCI 3. Configure TCP/IP Gateway server started task. The started task procedure name differs based on the combination of TCP/IP and runtime libraries you are using. ■ CAI.CAIPROC member CCITCPGW contains the JCL needed to run the CAICCI TCP/IP Gateway server using IBM TCP/IP with LE/370. ■ CAI.CAIPROC member CCIGWS contains the JCL needed to run the CAICCI TCP/IP Gateway server using IBM TCP/IP with SAS C Runtime (instead of LE/370). ■ CAI.CAIPROC member CCIGWI3 contains the JCL needed to run the CAICCI TCP/IP Gateway server using Interlink TCP/IP 3.1 and 4.1. IBM TCP/IP users—If you do not have the IBM LE/370 or SAS C Runtime modules in a LNKLST data set, concatenate your runtime library to the appropriate CAICCI TCP/IP load library. Interlink TCP/IP users--If you do not have the SAS C Runtime modules in a LNKLST data set, concatenate your runtime library to the appropriate CAICCI TCP/IP load library. (Interlink provides the SAS C Runtime library.) The Interlink TCP/IP load library should be ahead of the SAS C library in the CCIGWI3 STEPLIB concatenation. 4. Define parameters for TCP/IP Gateway Server Started Task. Define the following PROTOCOL statement and port number parameters for the TCP/IP Gateway Server Started Task. An example follows the parameter descriptions. PROTOCOL Statement To start the desired TCP address space for host-to-host connectivity, you must include the appropriate PROTOCOL statement in the data set pointed to by the //ENFPARMS DD statement with your ENF started task JCL: ■ PROTOCOL(TCPIPGW,...) starts procedure CCITCPGW to use IBM TCP/IP (with the IBM C Runtime) for host-to-host connectivity. ■ PROTOCOL(TCPIPSGW,...) starts procedure CCIGWS to use IBM TCP/IP with the SAS C Runtime (instead of IBM C Runtime) for host-to-host connectivity. ■ PROTOCOL(TCPIP3GW,...) starts procedure CCIGWI3 to use Interlink TCP/IP Version 3.1 or 4.1 for host-to-host connectivity. TCP/IP can be started before or after any of the CAICCI address spaces. If TCP/IP services are not available, the gateway server started task periodically retries the connection until TCP/IP starts. If TCP/IP is shut down for any reason, the gateway server started task terminates. If originally brought up by CAICCI, the gateway server started task is automatically restarted and again repolls for TCP/IP restart. Otherwise, you must restart the address space manually. Chapter 7: Post-Installation and Configuration 215 Configure and Maintain CAICCI To manually restart the CAICCI Gateway server, issue the console command: ENF,PROTOCOL(TCPIPGW,...) Port Number TCP/IP connections are based on network addresses plus a port number. The combination of address and port uniquely identifies each application on the network. CAICCI, like all other TCP/IP applications, requires that you specify a port number for its use. This port number must be available to both the mainframe CAICCI software and PC client systems. By default, CAICCI uses port number 7000 for host-to-host connectivity. Change this value to 1721. Examples IBM TCP/IP users-If CAICCI is starting the TCP address space, override the port number using the associated PROTOCOL statement within the //ENFPARMS DD statement of the ENF started task JCL. For example: SYSID(SYSA) PROTOCOL(TCPIPGW,1721,,SYSA) Interlink TCP/IP users-If CAICCI is starting the TCP address space, override the port number using the associated PROTOCOL statement within the //ENFPARMS DD statement of the ENF started task JCL: SYSID(SYSA) PROTOCOL(TCPIP3GW,SSID=ACSS:1721,,SYSA) Note: ACSS is the default name for the Interlink TCP/IP subsystem. 5. Define a connection between the mainframe and the UJMA machine. We recommend that you define the connection from the agent machine instead of OS/390. Instructions for this syntax are included in the section Configure CAICCI on Windows in the step to define a connection between nodes. If you do wish to define the connection on the OS/390 mainframe, use NODE and CONNECT statements in ENFPARMS. NODE Statement The NODE statement identifies the machine to which you are defining a connection. For example: NODE(TCPIPGW,172.16.197.114:1721,1,TRITON) TCPIPGW is the protocol, 172.16.197.114 is the IP address, 1721 is the port number, 1 is the repoll time in minutes, and TRITON is the sysid (CAICCI machine name). 216 Implementation Guide Configure and Maintain CAICCI Note: You may use a node name instead of an IP address if the CA Common Services for z/OS and OS/390 genlevel is 9807 or higher (formerly known as TNG Framework for OS/390). If the node name is greater than eight characters, use the alias name specified in the LOCAL statement in the CAICCI configuration file (ccirmtd.rc in Windows, ccirmtd.prf in UNIX, or CACCICFG.RMTPRF in HP NonStop). CONNECT Statement The CONNECT statement initiates the connection. For example, the following statement initiates the connection to the machine identified in the previous NODE statement example: CONNECT(TRITON) For more information about the NODE and CONNECT statements, see the CA Common Services for z/OS and OS/390 Administrator Guide. 6. Restart CAIENF for these changes to take effect. Note: To dynamically define a connection between nodes, you may use console commands instead of NODE and CONNECT statements. However, if you do this, the changes are in effect for this session of CAIENF only. For the changes to be in effect permanently, you need to define NODE and CONNECT statements and restart CAIENF. The following example shows how to use commands to define a connection between nodes: ENF NODE(TCPIPGW,172.16.197.114:1721,1,TRITON) ENF CONNECT(TRITON) Troubleshooting CAICCI When communication between two remote systems does not take place, it is often because the queues are not available. CCII Utility The simplest method to determine whether the queues are registered on a remote system is by running CCII on both the local and remote machine. The output of CCII is the list of registered local and remote message queues. CCIS/CCIR Utilities CCIS and CCIR are provided on OpenVMS, UNIX, and Windows Manager. These test programs can be used to test communication between two remote daemons. CCIR-Connects to CCIRMTD and creates a message queue. It will listen on the queue for messages sent from another system that supports CCIS. Chapter 7: Post-Installation and Configuration 217 Configure and Maintain CAICCI Note: Before running CCIS, make sure that the test queue is registered on the remote system (system where CCIS will run), by executing CCII on the remote machine. CCIS-Sends a test message to the designated host. The format of the CCIS command is: CCIS SYSID COUNT count Specifies the number of times the message should be sent A summary of the location of the CAICCI configuration file follows: Operating System File Location + File Name Windows unicenter installdir \caiuser\ccirmtd.rc UNIX $CAIGLBL0000/cci/config/hostname/ccirmtd.prf OpenVMS CAI_CCI_nodename:ccirmtd.prf CCIRMTD Behavior at Startup At startup, the remote daemon must be able to resolve both the CAICCI service as well as the node name specified in the LOCAL line of the configuration file. If the remote daemon fails to start, check that these names can be resolved by whatever means are used to resolve names in the client's environment. This information is then used to passively open a socket. The remote daemon operates in a peer-to-peer manner, that is, all remote daemons listen for connection requests from all other remote daemons. Next, the remote daemon runs down the list of hosts to connect to, as specified in the configuration file. For each host you must be able to resolve the node name to the correct IP address. The remote daemon issues a connect request. If the target host is listening, the connection established at this point is at the TCP/IP level. Should a connection between two hosts drop, by default both hosts attempt to reestablish the connection. 218 Implementation Guide Configure Remote Monitoring Configure Remote Monitoring The best configuration for your Remote Monitoring deployment is determined by many factors, including network traffic, machine speed, and other variables. After you install and configure, you can monitor various reports and metrics to assess the performance of your deployment. After reviewing reports you may find that altering your configuration will produce better performance results. You can make the following changes to your Remote Monitoring deployment: ■ Change which Agent opens in the Administrative Interface Each Remote Monitoring Agent is configured to monitor a select set of resources. The resources you can view and configure in the Administrative Interface is determined by which Remote Monitoring Agent you connect to. By changing the Remote Monitoring Agent connection, you can view and configure a different set of resources. Note: If your organization is using the Remote Monitoring security, you must log in with the administrator access defined by Remote Monitoring to configure the agent (this is different from a Windows administrative user account). ■ Send status data to a different MDB Remote Monitoring sends resource data to an MDB. Both the Unicenter WorldView and Event Management Console are connected to this MDB and they are responsible for displaying the resource status and the event message information gathered by Remote Monitoring. In an environment where there is more than one MDB deployed, you may decide that an agent should instead start sending its information to one of the other MDBs. ■ Run multiple instances of the Administrative Interface Although you can change which Remote Monitoring Agent you connect to with the Administrative Interface, you may choose instead to create several shortcuts to the interface and configure each shortcut to connect to a different agent. By connecting each shortcut to a unique agent, you can run several instances of the Administrative Interface at the same time, monitoring several agents at once without having to manually switch from agent to agent within one interface. ■ Alter the list of resources monitored by a single Agent The amount of network traffic generated by monitoring a single resource is unpredictable. After you set up a list of resources to monitor with a single agent, you may need to revise that list; you can either add resources or remove resources from monitoring. If you remove resources from one agent, you can rediscover and add them to the list of another agent. Chapter 7: Post-Installation and Configuration 219 Configure Unicenter Management Portal Configure Unicenter Management Portal Unicenter MP leverages Unicenter DIA to get managed data from Unicenter NSM managers. The Unicenter NSM knowledge base in the designated zone must be set as the first step for Unicenter MP configuration. Furthermore, to get data from Unicenter NSM managers, the managers must be registered with Unicenter MP. Set the Unicenter knowledge base and register managers using the tool provided in the Unicenter MP Administration wizard under Task 1: Manage component. The Administration wizard is available when you log in to the portal using administrator credentials. For configuration information, see the chapter "Unicenter MP Administration" in the Administrator Help in the portal knowledge library under the Enterprise Management\Documentation folder. Configure Unicenter for Pocket PC Once you have installed Unicenter for Pocket PC, you are ready to configure the device. To configure Unicenter for Pocket PC 1. Start Unicenter NSM on the device by selecting Unicenter NSM from the Start menu. When you start Unicenter NSM for the first time on a device, a Configuration dialog appears. 2. Enter the name of the Windows server that acts as the device manager for this device. This can be the name or IP address of any Windows server running Unicenter NSM Enterprise Management. You can change this information later by selecting Options from the Unicenter Tools menu. 3. Select the TCP/IP Port number used for communications. The default is 8888. 4. 220 Implementation Guide Click OK. Configure the Unicenter WMI Agent Configure the Unicenter WMI Agent To configure the Unicenter WMI agent 1. Use the cawmicnf.exe utility to provide authentication for additional namespaces. It prompts for a namespace and associated credentials. Only authenticated namespaces can be monitored. 2. Configure thresholds and poll times through the Agent View user interface. You can launch this interface by right-clicking one of the following areas: ■ The context menu from WorldView ■ Directly on the command line by entering the following command: abrowser -c browser.caWmiAgent Configure Monitoring for z/OS Interface Use the information in this section to configure and control the Monitoring for z/OS feature (z/OS and CICS agents). To configure the Monitoring for z/OS Interface, edit the configuration sets to provide settings specific to your installation. A sample configuration set for each agent is located in the smo.INSTLIB data set in the following members: ■ CFGSETOS (z/OS system agent) ■ CFGSETCI (CICS agent) Note: You must reload the configuration set after running the clean_sadmin command. Chapter 7: Post-Installation and Configuration 221 Configure Monitoring for z/OS Interface Unicenter CA-SYSVIEW Server The Unicenter CA-SYSVIEW Server address space must be active before the agent can collect data. For instructions on starting and stopping the Unicenter CA-SYSVIEW Server address space, see the Unicenter CA-SYSVIEW Realtime Performance Management Server Getting Started. If you are an existing Unicenter CA-SYSVIEW or agent's user, start your SYSVIEW or CAIAGENT address space using the START command. If the MVSDATA collector has not been started in your SYSVIEW address space, issue the following command from the system console to start the MVSDATA collector dynamically: MODIFY SYSVIEW,START MVSDATA If the CICSLOGR task has not been started in your SYSVIEW address space, issue the following command to start the CICS logger dynamically: MODIFY SYSVIEW,START CICSLOGR The Unicenter CA-SYSVIEW CICS XPFI transaction must also be active in each CICS region that is to be monitored by the CICS agent. Start and Stop the Agents To start the agents 1. Ensure that Agent Technology is running before starting the agent address spaces. 2. Initiate the PROC that starts the agent address spaces by issuing the z/OS START command from a system console: START ZOSAGTS START CICSAGTS To initiate the PROC that stops the agent address spaces, issue the z/OS START command from a system console: START ZOSAGTE START CICSAGTE Do not use the CANCEL or FORCE commands to terminate the agent address spaces unless the agents refuse to terminate using the procedures provided. Doing so may prevent the agents from restarting properly until you recycle Agent Technology. For more information on controlling the z/OS and CICS agents, see the Inside Systems Monitoring Guide. 222 Implementation Guide Run Unicenter Management for MOM Discovery Run Unicenter Management for MOM Discovery Unicenter NSM MOM Discovery communicates with Micosoft Operations Manager to classify WEBM computers in your network as MOM servers or managed PCs. After discovery, you can view and update the status of these devices in WorldView and view MOM alerts on the Event Console. Note: The first MOM discovery can be done during the installation of Unicenter Management for MOM. To keep MOM information current, perform MOM Discovery at regular intervals. To run MOM Discovery 1. Run WorldView Auto Discovery on your MOM network. The MDB is populated with WBEM machines. 2. Choose Start, Programs, CA, Unicenter, Management for MOM, MOM Discovery. The MOM Discovery Wizard opens. 3. Click Next, and enter or verify the domain, user ID, and password for the account that accesses and updates MOM information. You defined this user when you installed Unicenter Management for MOM. The account that handles MOM is identified. 4. Click Next, and follow the prompts. MOM Discovery classifies WBEM devices as MOM servers or managed PCs. 5. Restart the RMI server (rmi_server). The icons are displayed correctly in WorldView. Chapter 7: Post-Installation and Configuration 223 Run CA System Center Operations Manager Discovery Run CA System Center Operations Manager Discovery Unicenter NSM SCOM Discovery communicates with Micosoft System Center Operations Manager to classify computers in your network as SCOM servers or managed PCs. After discovery, you can view and update the status of these devices in WorldView and view SCOM alerts on the Event Console. Note: The first discovery can be done during installation of the Integration with Operations Manager. To keep the information current, perform SCOM Discovery at regular intervals. To run SCOM Discovery 1. Run WorldView Auto Discovery on your SCOM network. The MDB is populated with servers and managed PCs. 2. Choose Start, Programs, CA, Unicenter, SCOM Integration, SCOM Discovery. The SCOM Discovery Wizard opens. 3. Click Next, and enter or verify the domain, user ID, and password for the account that accesses and updates SCOM information. You defined this user when you installed the Unicenter NSM Integration for System Center Operations Manager. The account that handles SCOM is identified. 4. Click Next, and follow the prompts. SCOM Discovery classifies the devices as SCOM servers or managed PCs. 5. Restart the RMI server (rmi_server). The icons are displayed correctly in WorldView. 224 Implementation Guide Access Unicenter NSM Web Applications Access Unicenter NSM Web Applications Unicenter NSM web applications such as the Active Directory Explorer, Adaptive Dashboard Services, Advanced Event Correlation Web User Interface, Knowledge Base, Unicenter Configuration Manager and Web Reporting Server run on the CA Web Server using Tomcat technology. You access the web applications through the welcome page that is available as part of the CA Web Server or directly by specifying the complete URL to the application. On Windows or Linux platforms, you launch the welcome page by opening your web browser and entering the following URL: http://host_name:port_number host_name Specifies the name of the server where the CA Web Server is running. port_number Specifies the port number where the CA Web Server is running. The default if 9090 unless it was changed during installation. On a Windows server that has CA Web Server installed, you can launch the welcome page by selecting Start, Programs, CA, Unicenter, NSM, CA Web Server. Chapter 7: Post-Installation and Configuration 225 Access Unicenter NSM Web Applications The welcome page lists the names of the applications installed by CA. You can access the application by clicking the application name. The welcome page also provides links to the standard Tomcat applications Tomcat Administration and Tomcat Manager. Tomcat Manager provides the capability to manage your web applications without having to shut down and restart Tomcat. Tomcat Administration lets you manage users, groups, and roles and perform advanced administration tasks. For more information about Tomcat applications, see http://jakarta.apache.org/tomcat/index. As an alternative to the welcome page, you can access the Unicenter NSM web applications directly by specifying the complete URL to the application as follows: Application URL Active Directory Explorer http://host:port/ade Adaptive Dashboard Services http://host:port/ads Advanced Event Correlation Web User http://host:port/aecwebUI Interface Knowledge Base http://host:port/KnowledgeBaseUI Unicenter Configuration Manager http://host:port/wiser Web Reporting Server http://host:port/wrs host Specifies the name of the server that is running the application. port Specifies the port that was specified for Apache Tomcat during the installation of Unicenter NSM. The default port is 9090. When you access a Unicenter NSM web application, you are prompted for a user ID and password. The default user ID for the Tomcat user defined by Unicenter NSM is admin. The password for the admin user is specified during the Unicenter NSM installation as the password for the Apache Tomcat administrator. 226 Implementation Guide Access Unicenter NSM Web Applications Access AEC Web UI You can launch the AEC Web Policy Editor a few different ways: ■ Launch through the CA Web Server menu, which displays a list of all CA web applications, including the AEC web policy editor. ■ Locate the AEC Policies tree item in the Management Command Center. The Web Policy Editor opens in the right pane of the Management Command Center. ■ Open the Web Policy Editor from Alert Management using the Alert Class Detail window, AEC tab in the Unicenter MCC. Launching the Web Policy Editor independently, outside of Management Command Center, requires some basic configuration. The Web Editor automatically displays a Configuration tab that prompts for the name of the Distributed Intelligence Architecture (DIA) Knowledge Base and the Event Manager host. Note: Launching from within Management Command Center does not require this configuration because Management Command Center already understands these values and passes them automatically to the web policy editor within the right pane of Management Command Center. Unicenter Configuration Manager Setup Post-installation steps for Unicenter Configuration Manager involve updating a configuration file in a cluster environment and entering information to access the MDB. ■ Cluster environment—If UCM is installed in a cluster environment, you need to update three properties in the configuration file ucm.properties. Add the Universal Naming Convention (UNC) address of the shared storage area that all UCM servers in the cluster use for retrieval and storage of all UCM profiles and file packages. An example is \\ServerName\SharedDirectoryName. The properties are: – ui.profile.defaultDirectory – ui.filepkg.defaultDirectory – ui.adaptive.defaultDirectory Chapter 7: Post-Installation and Configuration 227 Access Unicenter NSM Web Applications ■ Access to MDB—The first time you start Unicenter Configuration Manager, you must enter the following information to access the MDB: – The hostname where the MDB resides – A valid local user ID and password that has the appropriate MDB access levels in Microsoft SQL Server or Ingres – JDBC Port (The default value is provided when you select the DBMS Type.) Note: See the Unicenter Configuration Manager help for more information. Access the Knowledge Base You can access Knowledge Base articles in different ways: ■ Open the Knowledge Base User Interface and use the table of contents or perform a search from the Knowledge Base User Interface. ■ Specify a direct URL that performs a search in the Knowledge Base and that displays the search results. See the Knowledge Base help system for details. ■ Use the Knowledge Base links in the Active Directory Explorer and in the Active Directory Agent Dashboards. These links redirect you automatically to the associated articles. ■ Use the Knowledge Base links in Active Directory messages that appear in the Event Console. These links redirect you automatically to the associated articles. See the Inside Active Directory Management guide for further details. Configure Unicenter NSM Web Reporting Server The first time you start Unicenter NSM Web Reporting Server, you need to establish connections to the Unicenter NSM managers using the Manage Components page. To access the Manage Components page 1. Expand the Administration tree node in the left pane to view the Manage Components tree node. 2. Select Manage Components. 3. Click Discover to discover the Unicenter NSM managers available in your environment. 4. Select the components that you want to be accessible for reporting, choose the default connection for each component type, provide user ID and passwords as required, and save the connections. 228 Implementation Guide Access Unicenter NSM Web Applications CA Web Server Configuration with SSL SSL, or Secure Socket Layer, is a technology that lets web browsers and web servers communicate over a secured connection. This means that the data being sent is encrypted by the sending side, transmitted, and then decrypted by the receiving side before processing. This is a two-way process, both the server and the browser encrypt all traffic before sending out data. Another important aspect of the SSL protocol is authentication. During your initial attempt to communicate with a web server over a secure connection, the server will present your web browser with a set of credentials in the form of a certificate as proof the site is who and what it claims to be. To implement SSL, a web server must have an associated certificate for each external interface (IP address) that accepts secure connections. The theory behind this design is that a server should provide reasonable assurance that its owner is who you think it is, particularly before receiving any sensitive information. This certificate is cryptologically signed by its owner and is extremely difficult for anyone else to forge. For sites involved in e-commerce, or any other business transaction in which authentication of identity is important, a certificate is typically purchased from a well-known Certificate Authority such as VeriSign or Thawte. Such certificates can be electronically verified. In effect, the Certificate Authority vouches for the authenticity of the certificates that it grants, so you can believe that the certificate is valid if you trust the Certificate Authority that granted it. In many cases, authentication is not a concern. An administrator may simply want to ensure that the data being transmitted and received by the server is private and cannot be snooped by anyone who may be eavesdropping on the connection. Java provides a relatively simple command-line tool, called keytool, which can create a self-signed certificate. CA Web Server which is based on Tomcat 5.5 technology hosts several Unicenter NSM web applications including Active Directory Explorer, Knowledge Base, Unicenter NSM Web Reports and Dashboards, Unicenter Configuration Manager, and the AEC Web Interface. Chapter 7: Post-Installation and Configuration 229 Access Unicenter NSM Web Applications Therefore, the SSL configuration of the CA Web Server can be divided into two parts: Part 1 describes how to configure Tomcat that is distributed as part of CA Web Server to work with SSL. This topic provides step-by-step instructions on configuring CA Web Server and shared Tomcat. The procedures provided are specific to the Tomcat installed as part of Unicenter NSM r11.2. Part 2 describes additional configuration steps that are specific to web applications (Web Reporting Server) which are running under the CA Web Server. For additional information regarding Tomcat or SSL for Tomcat, visit the following websites: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html http://tomcat.apache.org/index.html 230 Implementation Guide Access Unicenter NSM Web Applications Part 1: Configure Tomcat with SSL To configure Tomcat with SSL, you need to know the install locations of the Tomcat and Java Runtime Environment (JRE) that is installed by Unicenter NSM. Linux default locations: Tomcat /opt/CA/SC/tomcat/5.5.23 JRE /opt/CA/SC/JRE/1.5.0_11 Windows default locations: Tomcat InstallPath\CA\SC\TomCat.ccs\5.5.23 JRE InstallPath\CA\SC\JRE.ccs\1.5.0_11 In the steps that follow, the install locations are referred to as jre_install_path or tomcat_install_path. To configure Tomcat with SSL 1. Change to the WRS directory InstallPath\SC\CCS\WRS. 2. To generate a self-signed certificate, run the keytool utility as follows: jre_install_path\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore \tomcat_keystore_path\tomcat_keystore_name tomcat_keystore_path Defines the path to the location of the keystore file you are creating. If you do not explicitly specify the path, the keystore file is created in your HOME directory. If you use a directory that has spaces in the path, you must enclose the value of the keystore parameter in double quotes; for example, "\my path\tomcat_keystore_name". tomcat_keystore_name Defines the name you assign for this specific certificate. The keytool utility prompts you for the following parameters: Keystore password Provide a password. The default password used by Tomcat is changeit (case-sensitive), although you can specify a custom password. Remember the password you use. You will provide the password in steps 3 and 4. Chapter 7: Post-Installation and Configuration 231 Access Unicenter NSM Web Applications First and last name Specify your host name. You must use the fully qualified host name when responding to this prompt; for example, myhost.mydomain.com. Information parameters Respond to several information parameters as they apply to your organization: the name of your organizational unit, the name of your organization, your city or locality, your state or province, and your two-letter country code. Key password for tomcat Specify the key password in the server.xml configuration file using "keystorePass" (see step 4). You must use the same password here as you use for the keystore password itself. The keytool prompt tells you that pressing the Enter key does this for you automatically. The following screen illustrates the output from the keytool command: 232 Implementation Guide Access Unicenter NSM Web Applications 3. To export the generated certificate into JRE's cacerts, run the following two commands: jre_install_path\bin\keytool -keystore \tomcat_keystore_path\tomcat_keystore_name -export -alias tomcat -file temp.cer tomcat_keystore_path Specifies the path to the keystore file you set in step 2. tomcat_keystore_name Specifies the name you assigned for this specific certificate in step 2. When prompted, provide the password you used to create the keystore in step 2. and jre_install_path\bin\keytool -keystore jre_install_path\lib\security\cacerts -import -alias tomcat -file temp.cer By default, the password for jre_install_path\lib\security\cacerts is changeit. Use this password even if you used a different password in step 2 while creating your own keystore file for Tomcat. If the jre_install_path has spaces in it, enclose the jre_install_path\lib\security\cacerts entry in double quotes. For example: "C:\Program Files\CA\SC\JRE\1.5.0_11\lib\security\cacerts" 4. Take a backup of the server.xml file that is located in tomcat_install_path\conf and modify the server.xml file with a text editor according to the following steps. 5. Open the server.xml file, remove the comment delimiters (<!-- and -->) before and after the SSL connector statement and add the keystoreFile and keystorePass attributes. The statement then appears similar to the following: <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="\tomcat_keystore_path\tomcat_keystore_name" keystorePass="your_custom_password" /> \tomcat_keystore_path\tomcat_keystore_name Points to the keystore file you created in step 2. your_custom_password Specifies the password you defined for the keystore in step 2. The default password is changeit. Chapter 7: Post-Installation and Configuration 233 Access Unicenter NSM Web Applications Note: If you change the default SSL port to something other than 8443, you must change the redirect ports for other connectors to that new SSL port number. 6. The WRS server uses the HTTP port (Non-SSL) for local connections. To stop listening for remote requests, add the address attribute to the 9090 Connector statement. The statement then appears similar to the following: <Connector port="9090" maxHttpHeaderSize="8192" maxThreads="50" minSpareThreads="2" maxSpareThreads="10" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" address='localhost' /> 7. Save server.xml. 8. Restart CA Web Server service. 9. Change the URL of the start menu entry: Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right click Properties, and change the URL to https://hostname:8443/index.jsp. Part 2: Application-Specific Instructions Once you configure the CA Web Server to run with SSL, the web applications running under it may require additional configuration steps. This topic describes the steps that are specific to the Web Reporting (WRS) and Adaptive Dashboard Services (ADS). Note: Unicenter Configuration Manager reports are published in WRS. To load them properly from Unicenter Configuration Manager and WRS, use the WRSspecific instructions that follow to get all the reports republished for use with the SSL port. The following procedure describes how to enable SSL for ADS and WRS: To enable SSL for ADS and WRS 1. Change to the ADS directory InstallPath\SC\CCS\ADS and run the wrscfg utility in that directory to republish the links: wrscfg republish from=http://hostname:9090/ads to=https://hostname:8443/ads save=true hostname Use the fully qualified host name that you have specified for your selfsigned certificate in part 1, step 2. from Specifies the non-SSL port and protocol (for example, http://myhost.mydomain.com:9090/ads) 234 Implementation Guide Access Unicenter NSM Web Applications to Specifies the SSL port and protocol (for example, https://myhost.mydomain.com:8443/ads) save true (default) saves the new port and protocol in local properties. For example: wrscfg republish from=http://myhost.mydomain.com:9090/ads to=https://myhost.mydomain.com:8443/ads save=true Note: The configuration capability (add, edit, delete watchers) is only available to users belonging to the administrator role. 2. Change to the WRS directory InstallPath\SC\CCS\WRS and run the wrscfg utility in that directory to republish the links: wrscfg republish from=http://hostname:9090/wrs to=https://hostname:8443/wrs save=true hostname Use the fully qualified host name that you have specified for your selfsigned certificate in part1, step 2. from Specifies the non-SSL port and protocol (for example, http://myhost.mydomain.com:9090/wrs) to Specifies the SSL port and protocol (for example, https://myhost.mydomain.com:8443/wrs) save true (default) saves the new port and protocol in local properties. For example: wrscfg republish from=http://myhost.mydomain.com:9090/wrs to=https://myhost.mydomain.com:8443/wrs save=true Note: The host name remains the same during republishing. 3. Restart CA Web Server service. Chapter 7: Post-Installation and Configuration 235 Access Unicenter NSM Web Applications 4. Stop RMI_SERVER process using the following command: RMI_MONITOR -k 5. Run the wrs_modcat command: wrs_modcat -s ServerName -p PortNumber -l ListenPort -c Protocol ServerName Specifies the server name on which WRS is running. Specify localhost. PortNumber (optional) Specifies the port number on which WRS operates. Specify the http port (for example, 9090). ListenPort (optional) Specifies the port number on which the wrapper listens for notifications. You can specify any available port (for example, 5182). Protocol (optional) Specifies the protocol to use. Specify http. In this case the following command is sufficient: wrs_modcat -s localhost 6. Make sure that Java and JavaScript is enabled for the Internet Explorer and that the host name used in step 1 and 2 does not block web sites. Otherwise, the reports cannot be displayed properly in MCC. To avoid blocking, you can, for example, modify the Security Zones of the Internet Explorer settings accordingly if necessary. Revert to a Non-SSL Configuration If you want to return to a non-SSL configuration, you need, in principle, only reverse some of the previously made configuration steps. To revert to a non-SSL configuration 1. Change to the WRS directory InstallPath\SC\CCS\WRS and run the wrscfg utility to republish the links: wrscfg republish from=https://hostname:8443/wrs to=http://hostname:9090/wrs save=true 2. Change to the ADS directory InstallPath\SC\CCS\ADS and run the wrscfg utility to republish the links: wrscfg republish from=https://hostname:8443/ads to=http://hostname:9090/ads save=true 236 Implementation Guide Access Unicenter NSM Web Applications 3. Change to the tomcat_install_path\conf directory and rename the backup file of server.xml to server.xml. The backup file was taken in step 4 of the Part 1 procedure. 4. Restart the CA Web Server service. 5. Change the URL of the start menu entry: Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right click Properties, and change the URL to http://hostname:9090/index.jsp. Example Procedure The following sequence of commands is an example for configuring the CA Web Server in SSL-mode. The commands may slightly differ depending on the respective installation. Part 1: Configure Tomcat with SSL 1. Change to the WRS directory C:\Program Files\CA\SC\CCS\WRS. 2. Generate a self-signed certificate. C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -genkey -alias tomcat -keyalg RSA keystore "C:\Program Files\CA\SC\CCS\WRS\WRSkeystore" Enter keystore password: changeit What is your first and last name? [Unknown]: myhost.mydomain.com What is the name of your organizational unit? [Unknown]: R&D What is the name of your organization? [Unknown]: myorg What is the name of your City or Locality? [Unknown]: mycity What is the name of your State or Province? [Unknown]: mystate What is the two-letter country code for this unit? [Unknown]: DE Is CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=US correct? [no]: yes Enter key password for <tomcat> (RETURN if same as keystore password): 3. Export the certificate to a temporary file. C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -keystore "C:\Program Files\CA\SC\CCS\WRS\WRSkeystore" -export -alias tomcat -file temp.cer Enter keystore password: changeit Certificate stored in file <temp.cer> Chapter 7: Post-Installation and Configuration 237 Access Unicenter NSM Web Applications 4. Import the certificate into cacerts. C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\JRE.ccs\1.5.0_11\bin\keytool" -keystore "C:\Program Files\CA\SC\JRE.ccs\1.5.0_11\lib\security\cacerts" -import -alias tomcat file temp.cer Enter keystore password: changeit Owner: CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=DE Issuer: CN=myhost.mydomain.com, OU=R&D, O=myorg, L=mycity, ST=mystate, C=DE Serial number: 48594891 Valid from: Wed Jun 18 19:40:33 CEST 2008 until: Tue Sep 16 19:40:33 CEST 2008 Certificate fingerprints: MD5: 2F:AA:84:D7:8C:67:72:21:9B:A6:0D:A3:0D:20:37:C2 SHA1: FE:EE:09:EC:95:47:79:F5:54:75:05:C5:77:91:20:A9:C3:45:F4:69 Trust this certificate? [no]: yes Certificate was added to keystore 5. Change to C:\Program Files\CA\SC\Tomcat.ccs\5.5.23\conf, open server.xml, add the parts formatted in bold characters to the server.xml file, and remove the comment delimiters (<!-- and -->) from the SSL connector statement (port 8443). ... <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector port="9090" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" address='localhost' /> ... <!-- Define a SSL HTTP/1.1 Connector on port 8443 --> <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\Program Files\CA\SC\CCS\WRS\WRSkeystore" keystorePass="changeit" /> ... 6. Save server.xml. 7. Restart CA Web Server service. 8. Change the URL of the start menu entry: Select "Start->Programs->CA->Unicenter->NSM->CA Web Server", right click Properties, and change the URL to https://hostname:8443/index.jsp. 238 Implementation Guide Access Unicenter NSM Web Applications Part 2: Application-Specific Instructions 1. Change to the ADS directory C:\Program Files\CA\SC\CCS\ADS. 2. Run the wrscfg utility to republish the ADS links. C:\Program Files\CA\SC\CCS\ADS>wrscfg republish from=http://myhost.mydomain.com:9090/ads to=https://myhost.mydomain.com:8443/ads save=true 3. Change to the WRS directory C:\Program Files\CA\SC\CCS\WRS. 4. Run the wrscfg utility to republish the WRS links. C:\Program Files\CA\SC\CCS\WRS>wrscfg republish from=http://myhost.mydomain.com:9090/wrs to=https://myhost.mydomain.com:8443/wrs save=true 5. Stop RMI_SERVER. C:\Program Files\CA\SC\CCS\WRS>RMI_MONITOR -k RMI_MONITOR RMI_Server is not running 6. Run the wrs_modcat command. C:\Program Files\CA\SC\CCS\WRS>WRS_MODCAT -s localhost Using Default Values for WRS Port Number and Listen Port Number ......Adding Local NameSpace: WRS on computer C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\CCS\AIS\framework\bin\addprov.exe" WRS WRSWrp key=WRSPrv WebServer="localhost" Webport="9090" ListenerPort="5182" Protocol="http" Modified provider - name: WRS wrapper: WRSWrp C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\CCS\AIS\framework\bin\addnsp.exe" WRS Root WRSPrvkey=WRSNsp description="NLS_WEBREPORTS" label="myhost" icon="reports_icon" Modified namespace - name: WRS owner: Root Delete existing WRS(WRS Namespace on Global Machine ...... C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\CCS\AIS\framework\bin\DelNspByName.exe" Root/WRS(myhost) Root/MasterCat Namespace deleted UnPublish Namespace : WRS on Global Machine ...... C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\CCS\AIS\framework\bin\UnPublishCat.exe" Root/WRS Root/MasterCat Namespace unpublished Publish Namespace : WRS(WRS Namespace on Global Machine ...... Chapter 7: Post-Installation and Configuration 239 Access Unicenter NSM Web Applications C:\Program Files\CA\SC\CCS\WRS>"C:\Program Files\CA\SC\CCS\AIS\framework\bin\publishcat.exe" Root/WRS Root WRS(myhost) Root/MasterCat description="NLS_WEBREPORTS" label="myhost" icon="reports_icon" Namespace published The new provider and namespace was successfully added. The relevant batch files have been modified. C:\Program Files\CA\SC\CCS\WRS> CA Web Server Security CA Web Server security is based on the Tomcat 5.5 security mechanism and is primarily concerned with authentication and access control. Tomcat security uses role-based authorization to manage access control. With this model, access permissions are granted to a security role and access is allowed only to the users or groups of users who are assigned this role. You can think of roles as similar to groups in Unix-like operating systems because access to specific web application resources is granted to all users possessing a particular role (rather than enumerating the list of associated user names). An individual user can have any number of roles associated with their user name. When a user accesses Unicenter NSM Web Applications, Tomcat security enforces user authentication. The user ID and password the user provides is sent to the Tomcat server for authentication. Important! When using HTTP to communicate with Tomcat, the user ID and password are not encrypted when they are sent from the web browser to the Tomcat server. In a production environment, we strongly recommend that you configure CA Web Server with SSL and use HTTPS as a secure transport mechanism to ensure encryption of the user ID and password. If authentication succeeds, Tomcat checks whether the user is assigned to a role authorized to access the application. For example, Tomcat Administration and Tomcat Manager applications only grant access to the users with the manager role. The following table provides a list of roles authorized by different web applications. Application Authorized Roles Unicenter Configuration Manager tomcat, admin, user Web Reporting Server tomcat, admin, user 240 Implementation Guide Access Unicenter NSM Web Applications Application Authorized Roles Adaptive Dashboard Services tomcat, admin, user Advanced Event Correlation Web User Interface tomcat, admin, user Tomcat Administration manager Tomcat Manager manager Tomcat security needs access to a database of user names and passwords that identify valid users of a web application (or set of web applications), plus an enumeration of the list of roles associated with each valid user. In Tomcat security implementation, this database is called a Realm. Unicenter NSM Web Applications support two implementations of Tomcat Realm, enabling connections to two different sources of authentication information as follows: MemoryRealm Accesses authentication information stored in an in-memory object collection, which is initialized from an XML document (conf/tomcatusers.xml). MemoryRealm is part of standard Tomcat functionality. For more information on MemoryRealm implementation, see the Apache website: http://tomcat.apache.org/tomcat-5.5-doc/index.html At startup time, MemoryRealm loads information about all users and their corresponding roles from an XML document loaded from CA_SHARED_COMPONENT_DIR/tomcat/5.5.23/conf/tomcat-users.xml. Changes to the data in this file are not recognized until Tomcat is restarted. You can use the Tomcat Administration application to manage users, groups, and roles used by the standard MemoryRealm implementation. If for security reasons you want to limit access to the Tomcat Administration application, it is possible to limit access to the web users on the local host only, or a list of specified hosts. See the Apache website for detailed instructions. Important! For the standard MemoryRealm implementation, the user's password is stored in tomcat-users.xml in clear text. In many environments, this is undesirable because of security concerns. To avoid the problem, the standard MemoryRealm implementations support the concept of digesting user passwords. This allows the stored version of the passwords to be encoded in a form that is not easily reversible. For more information on digesting user passwords and MemoryRealm implementation, see the Apache website. Out-of-the-box, the CA Web Server is configured to use MemoryRealm. MemoryRealm is not designed for production use. In the production environment, we recommend running NSM Web Applications with the NSM Security Realm. Chapter 7: Post-Installation and Configuration 241 Enable Unicenter NSM Integration with eHealth Reports NSM Security Realm Accesses authentication information provided by Unicenter NSM security. Unicenter NSM security authenticates the user using OS native authentication. Access control is implemented based on Unicenter NSM assets. You can configure the choice of Realm used by Unicenter NSM Web Applications using a web interface specific to the application. For more information, see the online help for the particular application. Access to Unicenter NSM Web Applications Granting access to Unicenter NSM web applications when Unicenter NSM security is enabled has the following requirements: ■ To access the Unicenter NSM web applications WRS, ADS, and UCM, the user ID must be assigned to one of the default groups in the Unicenter NSM security database. All security groups except PUBLIC have user access by default. ■ To access Unicenter NSM applications as an admin user with administrator authority, the user ID must belong to the SYSADMIN group Enable Unicenter NSM Integration with eHealth Reports eHealth and LiveHealth servers are configured to monitor the performance of various nodes on a network. Similarly, Unicenter NSM is deployed and configured to monitor various network devices and systems. Unicenter NSM and eHealth integration is an Agent Technology (DSM) policy-based integration that receives and processes the SNMP traps from your eHealth and LiveHealth servers. Real-Time Integration The LiveHealth server is specifically for real-time network performance monitoring and you can configure this server to send SNMP traps to the DSM server. Once configured, the LiveHealth server sends nhLiveAlarm SNMP traps to the DSM server when a performance threshold is violated. When an alarm expires (that is, when performance returns to acceptable levels), the LiveHealth server sends an nhClearLiveAlarm SNMP trap. As the nhLiveAlarm/nhClearLiveAlarm traps are received by the DSM server, the logic in the DSM policy processes these traps and updates or creates managed objects with the appropriate status in the DSM and appropriate corresponding managed objects in the WorldView database tables of the MDB. 242 Implementation Guide Enable Unicenter NSM Integration with eHealth Reports Performance Trend Integration You can also schedule Health reports from the eHealth server. If you configure the eHealth server to forward SNMP traps to the DSM server when a scheduled Health report runs, netHealthException SNMP traps are generated and sent to the DSM server. The DSM policy processes these netHealthException traps in a manner parallel to the nhLiveAlarm and nhClearLiveAlarm traps with one major difference: netHealthException traps are only generated when a scheduled Health Report is run. These traps are indicating negative network performance trends over time that may be currently affecting the performance of some element that is being managed. The nature of these traps and the fact that there is no corresponding “clear” trap, causes the DSM policy to create netHealthException managed objects in Agent Technology and WorldView with a status automatically set at a low-level WARNING. Once these particular netHealthException objects are created, the DSM policy does nothing more with them and you must acknowledge and remove them when appropriate. Your Unicenter NSM installation includes all of the integration policies necessary for integration with eHealth reports. To enable these policies, complete the procedures that follow. See the Unicenter MCC online help for additional information about Unicenter NSM integration with eHealth reports. Enable the DSM Policy for eHealth The DSM policy for eHealth lets Unicenter NSM create eHealth managed objects, process eHealth alarms, and maintain the status of eHealth managed objects. To enable the DSM policy for eHealth, start the DSM Wizard and mark the eHealthSpace class as enabled. To enable the DSM policy for eHealth 1. Click Start, Programs, CA, Unicenter, NSM, Agent Technology, DSM Wizard. The DSM Wizard appears. 2. Navigate to the Agent Selection page of the DSM Wizard and click the check box next to the eHealthSpace agent name. 3. Click Save. The change is committed. 4. Click Next until the Congratulations window appears. Chapter 7: Post-Installation and Configuration 243 Enable Unicenter NSM Integration with eHealth Reports 5. Click the Enable New Configuration check box. 6. Click Finish. Enable Alert Management Policy Alert Management policy translates eHealth alarms into Unicenter alerts. The following steps enable AMS policy. To enable Alert Management policy 1. Open a Command Prompt window on your AMS server. 2. Enter the following command: enableehealthAMS The output from the command script appears as follows: Install eHealth/AMS policy adding event policy... activating event policy... adding alert policy... The alert policy will not be activated until the CA-Unicenter Alert Management service is restarted. eHealth/AMS policy has been installed. 3. Go to the Services dialog of the Microsoft Management Console and restart the CA-Unicenter Alert Management Service. Enable eHealth Links in the Unicenter MCC After enabling the eHealth DSM and ASM policies, the Unicenter MCC automatically displays eHealth managed objects and any corresponding alerts. You can also enable the display of the Links menu in the main Unicenter MCC menu that contains actions to start the Business Service Console and the eHealth Report Server. To enable eHealth links in the Unicenter MCC 1. On the MCC client machine, set your working directory to the SC\CCS\WVEM\bin directory. 2. Issue the following command: cazipxp -u mcc_ehealth.caz The Links menu is available the next time you start the Unicenter MCC. 244 Implementation Guide Enable Unicenter NSM Integration with eHealth Reports Configure eHealth Links in the Classical Interfaces To launch eHealth reports from the Unicenter NSM classical interfaces such as the 2D Map and NodeView, configure Unicenter NSM to specify the location of the eHealth Web Server. On your Unicenter NSM client machine, run the SeteHealthServer.exe command. The syntax for the command is as follows: SeteHealthServer -h eHealthServerName -p ehServerPort -c ehServerProtocol The eHealth server name is the only required parameter. The defaults for the port and protocol are used if you omit them. Example: SeteHealthServer -h ehealthweb.company001.com -p 80 -c http Discover eHealth Objects in Unicenter NSM Using the Discovery Gateway Command-Line Utility Before Unicenter NSM can start monitoring eHealth objects, the eHealth objects must first be discovered and added to the WorldView repository. The eHealth Discovery Gateway is a command-line utility that synchronizes the objects discovered in eHealth with the objects that have been discovered by Unicenter NSM. The command has the following format: dscvrehealth -h eHealthServerHostname -s ehealthServerPort -l -u ehealthUserId -p ehealthPassword -wr WorldviewRepository -wu WorldviewUserid -wp WorldviewPassword -t ElementType -a ElementAddress -f LogFileName -d -? -h eHealthServerHostname Specifies the eHealth web server hostname or address. This parameter is required. -s ehealthServerPort Specifies the eHealth web server port. The default value is 80 if you use HTTP for the protocol. The default value is 443 if you specify the SSL option. -l Enables SSL support. Chapter 7: Post-Installation and Configuration 245 Enable Unicenter NSM Integration with eHealth Reports -u ehealthUserId Specifies the eHealth web server userid. The default value is admin. -p ehealthPassword Specifies the eHealth web server password. The default value is ehealth. -wr WorldviewRepository Specifies the name of the WorldView repository. This parameter is required. -wu WorldviewUserid Specifies the WorldView repository userid. This parameter is required. -wp WorldviewPassword Specifies the WorldView repository password. This parameter is required. -t ElementType Specifies the element base type to discover. Valid values are ROUTER,SYSTEM, or INTERFACE. The default is to discover all types. Note: When using the -t flag, you must discover routers and switches using the ROUTER option before using the INTERFACE option; otherwise, any discovered child interface objects are discarded if the parent device is not yet discovered. -a ElementAddress Specifies the IP subnet or address to discover. The default is to discover all objects of the specified type. Use '*' as a wildcard to discover all devices in a subnet range. For example, 192.168.* discovers all devices in the 192.168 subnet. -f LogFileName Directs output to a log file. -d Enables debugging information. -? Display command usage information. Whenever new objects are added to eHealth, you must rerun the dscvrehealth utility to resynchronize the two databases. Any objects that already exist in both databases are skipped. Any objects that are defined in the eHealth database but not in the WorldView repository are ignored. 246 Implementation Guide Enable Unicenter NSM Integration with eHealth Reports Note: Using an IP address correlates objects in the eHealth and Unicenter NSM databases; therefore, the IP address assigned to a device in eHealth and Unicenter NSM must match. If a device has multiple IP addresses assigned to it, eHealth and Unicenter NSM must have discovered the device using the same primary address; otherwise, the eHealth object is not added to the WorldView repository. Also, since the correlation relies on static address for devices, DHCP addresses are not supported. Chapter 7: Post-Installation and Configuration 247 Chapter 8: Creating the Reduced-Size Installation Image This section contains the following topics: Remote Agent Installation Using RSII (see page 249) Prerequisites (see page 250) Best Practices (see page 250) How RSII Works (see page 250) Create an Installation Image for Windows (see page 251) Create Custom Response Files (see page 252) About Response Files (see page 254) Deploy the Agent-Only Installation Image (see page 254) Remote Agent Installation Using RSII The Reduced-Size Install Image (RSII) produces an agent-only subset of the Unicenter NSM installation image. The agent-only image is considerably smaller than the full Unicenter NSM image. The RSII image makes it easier for you to send specific agents to remote computers using Unicenter Software Delivery or another distribution application. The Adaptive Configuration service is supported where applicable. The agent-only installation image supports remote deployment using either the Response file created with the RSII Image or one that you customize for it. You can install or upgrade agents for the following Unicenter NSM versions with RSII: ■ r11.2 Windows ■ r11.1 Windows ■ r3.1 Windows Chapter 8: Creating the Reduced-Size Installation Image 249 Prerequisites Prerequisites Make sure that your system is ready to run the RSII: ■ Verify that you have at least 200 MB of free space per operating environment. ■ RSII can upgrade Unicenter NSM r3.1 agents and r11.1 agents to Unicenter NSM r11.2. Note the following, however: – If you already upgraded computers using the full Unicenter NSM r11 or r11.1 DVD, you must continue to use the full DVD for later agent installations and reinstallations. – If you are running only the Unicenter NSM r3.1 Systems Performance agent on a Unicenter NSM r3.1 computer, upgrade the common agent services by deploying the Log or System agent package before the Systems Performance agent package. Best Practices To ensure that you create the agent-only installation image as efficiently and accurately as possible, consider the following best practices. ■ Check CA Support for any updates to Unicenter NSM r11.2. Apply the fixes before you create the installation image. ■ Use Windows as the operating system on your Unicenter Software Delivery server. How RSII Works RSII makes it easier for you to send agents to client computers in your enterprise. A few steps let you create the image and send the agents: ■ Create the installation image. ■ Create response files if you want to do a custom installation (see page 254). Response files make unattended installations possible because they contain answers to installation questions. ■ Register with Unicenter Software Delivery. This product supports a multitiered architecture that lets you stage product installation images across the enterprise and invoke the installation from a local software store. ■ Deploy the installation image (see page 256). This indicates the systems where you want to install the agents. 250 Implementation Guide Create an Installation Image for Windows Create an Installation Image for Windows This procedure shows how to create an image that will install agents on remote Windows servers. Note: Use a Windows computer when you create an installation image for Windows. To create an installation image for Windows 1. Make sure that you have the Unicenter NSM r11.2 GA DVD. 2. Start the Unicenter NSM Product Explorer by double-clicking on SETUP.EXE. The Unicenter NSM Product Explorer appears. 3. Select the item Installation Wizard for Unicenter NSM. After a few moments the first page of the wizard appears. 4. Select the option Create Reduced Size Install Image (RSII). The edit control labeled "Enter full path and name of the response file" and the Browse button are enabled. 5. Enter the location and a response file name to use to create the RSII image. Use the Browse button to find a location to place the response file. 6. Click Next and continue through the wizard changing options as needed. You are not given the option of selecting any components during this process. The components are preselected for you. They consist of the following agents: 7. ■ System Agent ■ ADS Agent ■ Log Agent ■ WMI Agent ■ Script Agent ■ Event Agent ■ Performance Agent Click Create on the Summary dialog to create the RSII image. The response file you specified on the first wizard dialog is loaded with your choices. The wizard creates the new image. Chapter 8: Creating the Reduced-Size Installation Image 251 Create Custom Response Files A status window appears indicating the progress of the image creation. Completing the image takes approximately five minutes. Upon completion, a message box displays the location of the new image. This location is usually at %TEMP%\NSMRSII. You can use the new image in exactly the same way as you use the GA Unicenter NSM DVD. You can start the Product Explorer from this image and then launch the Unicenter NSM wizard. The only thing you cannot do is create an RSII image from an RSII image. Create Custom Response Files Plan Your Response Files Make a list of all the types of agent installations you want to perform. For example, some remote clients may require only system agents, others may need only log agents, and so on. Create a separate response file for each item on your list. Note: You can use a combination of default response files and custom response files. Use a meaningful, descriptive file name for your response file because it becomes the name of the Unicenter Software Delivery procedure that installs the agents. Note: Besides using the installation wizards to create response files, you can also copy and rename response files. Create Custom Response Files for Windows You can create a response file that Unicenter Software Delivery can use to install Agent Technology and Event agents on remote Windows servers. Response files make unattended installations possible because the files contain answers to installation prompts. To create custom response files for Windows 1. Create a directory to contain your custom response files using the Command Prompt. 2. Switch to the directory that contains the agent-only image. 3. Enter the following command: setup The Unicenter Product Explorer opens. 252 Implementation Guide Create Custom Response Files 4. Expand Unicenter Agents for Windows. Selections for available agents to install appear. 5. For Agent Technology agents, select Installation Wizard for Unicenter NSM Agents, and click Install. The Welcome to the Unicenter NSM Install page of the Installation Wizard opens. 6. Alternatively, for the Event Agent, select Installation Wizard for Unicenter NSM Event Agent, and click Install. The Welcome to the Unicenter NSM Install page of the Installation Wizard opens. 7. Select Build Unicenter NSM response file for unattended install, and enter or browse for the name of the directory you created in Step 1, then click Next. Note: Use a meaningful, descriptive file name for your response file, because it becomes the name of the Unicenter Software Delivery procedure that runs the unattended installation. The name appears in the Unicenter Software Delivery catalog and you must be able to recognize it. 8. Select the agents to install. The wizard creates the response file. Note: Repeat this step for every response file you need to create. Create Custom Response Files for Systems Performance Agents on Windows This procedure shows how to create a response file that Unicenter Software Delivery can use to install Systems Performance agents on remote Windows servers. Response files make unattended installations possible because the files contain answers to installation prompts. To create a custom response file for Systems Performance agents 1. Create a directory to contain your custom response files using the Command Prompt. Use the same directory where any other Windows response files are located. 2. Switch to the directory that contains the agent-only image. 3. Enter the following command: setup The Unicenter Product Explorer opens. 4. Expand Unicenter Agents for Windows, select Installation Wizard for Unicenter NSM Systems Performance Agents, and click Install. The CA Unicenter NSM Systems Performance wizard opens. Chapter 8: Creating the Reduced-Size Installation Image 253 About Response Files 5. Click Next. Enter a user name and company, select Generate a response file, and click Next. The Setup Type page appears. 6. Follow the on-screen instructions. Note: Use a meaningful, descriptive file name for your response file, because it becomes the name of the Unicenter Software Delivery procedure that runs the unattended installation. The name appears in the Unicenter Software Delivery catalog and you must be able to recognize it. The wizard creates the response file. Note: Repeat this step for every response file you need to create. About Response Files Response files are text files that contain configuration information for an installation. They are useful for unattended installations because no prompts appear; all answers are in the response files. These files also provide an effective way to perform multiple identical installations. Note: Do not use response files created from a full-size Unicenter NSM r11, r11.1, or r11.2 image. They may produce unexpected and incorrect results and their use is not supported. Note: You do not need to create response files if you will use only the default response file created with the Image or will install the agents interactively. You can skip this section. Deploy the Agent-Only Installation Image Interactive Installation If you plan to install the agents interactively, you need not perform the actions described in this chapter. Instead, run setup.exe and follow the on-screen prompts. Registration with Unicenter Software Delivery Registration is the process of copying the agent-only image to the Unicenter Software Delivery database. 254 Implementation Guide Deploy the Agent-Only Installation Image Register the Windows Image This procedure shows how to register the agent-only image so that Unicenter Software Delivery can install Windows, Systems Performance, and Event agents on remote Windows servers. To register the image for Windows 1. Verify that all response files you are going to use are in the same directory. 2. Access the directory that contains the agent-only image. 3. Enter the following command: setup The Unicenter Product Explorer opens. 4. Expand Unicenter Products and Unicenter Agents for Windows. Selections for available agents to install appear. 5. Select Register Packages to Unicenter Software Delivery for Windows Agents, and click Install. The USD Registration dialog opens. 6. Enter or browse to the directories that contain the agent-only image (Root directory) and the response files, and click Register. Note: We recommend that you use the Browse buttons to select the directories. The Choose Products to Register dialog opens. 7. Select both packages, click Next, and follow the on-screen prompts. The wizard registers the agent-only image. Unattended (Silent) Installation on a Delivery Application If you are using a software delivery application other than Unicenter Software Delivery, check its exit code and use that application to transfer the agent image and response files to the remote computer. Use the following commands for the unattended installation in the different operating environments. The commands install the agents using a previously generated response file. Windows Installs all agents on Windows except the Systems Performance agent. setup.exe -nt="full path and response file name" -cdpath="full path to this setup.exe" Chapter 8: Creating the Reduced-Size Installation Image 255 Deploy the Agent-Only Installation Image Systems Performance on Windows Installs Systems Performance agents on Windows. This command must be in the directory \Windows\NT\SystemsPerformance. setup.exe USE_THIS_RESPONSE_FILE="full path and response file name" Deploy the Image to Unicenter Software Delivery Deployment is the process of indicating to Unicenter Software Delivery where you want to install the agents. The response file names become the names of the Unicenter Software Delivery procedures that run the unattended installations. These names appear in the Software Delivery catalog. To deploy the agent-only install image, open Unicenter Software Delivery, and drag and drop the agent package onto the systems or group of systems where you want to deploy the image. 256 Implementation Guide Deploy the Agent-Only Installation Image The response file names appear when you open the procedures of the registered agent package: Note: For more information about Unicenter Software Delivery, see the Unicenter Software Delivery Administrator Guide. You can view and download this guide from CA Support Online. Troubleshooting This section contains information that may help you if you have any questions or problems when creating or deploying the agent-only installation image. More information: Cannot Install the Agents (see page 258) Start Menu Has an Empty Folder (see page 259) Chapter 8: Creating the Reduced-Size Installation Image 257 Deploy the Agent-Only Installation Image Cannot Install the Agents Symptom: When I try to install RSII agents over older agents, I get an error message and the installation terminates. Solution: Try the following solutions: ■ Check the computer for a manager, and verify which agents are installed. RSII upgrades agents only if the target computer has the following configuration: – No manager component – The same agents or a subset of the agents in the RSII image If the target computer has a manager or different agents, you must use the full installation image copied from the DVD to install the agents. ■ ■ 258 Implementation Guide If you are using RSII to upgrade Systems Performance r3.1 agents to r11.2, you need to upgrade base Unicenter NSM first in one of the following ways: – Run the r11.2 installation interactively on the remote computer. Select nothing in the wizard and click Next repeatedly until you get to the end of the installation. – Install another agent first, like the system agent, and then install the Systems Performance agents. Recreate the agent-only installation image if you applied a CA Support patch to Unicenter NSM. If you applied any patches to the master image, verify that the RSII image was recreated from the updated master image. Deploy the Agent-Only Installation Image Start Menu Has an Empty Folder Symptom: After I install RSII agents on a Windows computer, the Start menu has a Books Online folder that is empty. Solution: You used a response file from Unicenter NSM r11.2 instead of RSII. Do not use response files created from a full-size Unicenter NSM image even though they may work in some cases. They may cause inconsistent results such as empty folders on the Windows Start menu. If a blank Books Online folder bothers you, you can remove it from the Start menu. For more information, see the Unicenter NSM online help for Windows. If you are going to use this agent-only installation image to install more agents, you may want to recreate a response file using RSII, reregister with Unicenter Software Delivery, and redeploy the image. Chapter 8: Creating the Reduced-Size Installation Image 259 Chapter 9: Getting Started This section contains the following topics: Discover Your Network Infrastructure (see page 261) Network Visualization (see page 262) Discover Your Network Infrastructure After you install Unicenter NSM, you need to discover the devices and objects in your enterprise and begin to monitor them. To discover the resources on your local machine 1. Open the Unicenter MCC. 2. Select Tools from the left pane drop-down menu. 3. From the tools tree view, select Discovery Wizard. The Discovery Wizard appears in the right pane. 4. Click Next and proceed through the Wizard windows, indicating what is appropriate for your environment. If you choose to discover a subnet of your network, you have to supply your subnet address, gateway and subnet mask in a subsequent dialog. On the Discovery Mode window, select Faster Discovery. Chapter 9: Getting Started 261 Network Visualization 5. When you click Discover on the final Wizard window, Discovery runs. Ultimately, the results window appears: Network Visualization Unicenter NSM WorldView offers a highly visual and naturally intuitive approach to enterprise management with the 2D Map and WorldView GUIs. The 2D Map works as an infrastructure navigator, letting you view any part of your enterprise with the click of a button. For example, you can view all assets in your network--from 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. Unicenter MCC The Unicenter Management Command Center is the primary interface for managing your entire enterprise. The Unicenter MCC integrates all Unicenter enterprise and network monitoring functionality into a single console. The Unicenter MCC provides dynamic multi-viewer content relevant to any asset in the MDB. 262 Implementation Guide Network Visualization The Unicenter MCC window has a left pane and a right pane. The views shown in those panes structure data into usable, meaningful relationships. Views not only show relationships within data and metadata, but also let you locate a specific entity in the MDB. These different left pane and right pane combinations let you completely customize the way you work in Unicenter NSM. You select a view from the drop-down list in the left pane, which displays information in a tree format. After you select a subject in the left pane, multiple standard viewers for that subject display content in the right pane. You can also select from the right pane drop-down list to display details about or modify the subject selected in the tree. The left pane Topology view displays a hierarchical tree of all the entities appearing in the Managed Objects folder in the 2D Map. Web Reports Unicenter NSM Web Reports are accessible from the Reports navigation tree in the Unicenter MCC. These reports are obtained from the Web Reports server. A valid user ID and password for the Tomcat server on which the Web Reports option is installed must be sent to the server before accessing reports. When requesting the first report each session, you are prompted to enter the user ID and password. Instead of being prompted once each session, you can check "Remember these settings" when entering the user ID and password on the Connection Settings dialog. Chapter 9: Getting Started 263 Network Visualization 2D Map The 2D Map is a two-dimensional, geographical representation of the logical structure of your enterprise. It simplifies managing your eBusiness resources by providing tools to customize visual representations of your business enterprise. To access the 2D Map, select the Topology view from the left pane drop-down list box of the Unicenter MCC, then select 2D Map from the right pane’s drop-down list box. As the 2D Map starts, icons depicting these objects appear arranged according to your network topology. Use the Topology view simultaneously with the 2D Map to view the dependencies between managed objects, their hierarchical relationships and links (parent-child) between them. The 2D Map gives you direct access to the managed objects maintained in the MDB. You can list objects, delete them, change the values of their properties, enhance their definitions with comments and user-defined fields, add objects to the MDB, and search and query object information in the MDB. 264 Implementation Guide Network Visualization Business Process Views The 2D Map also addresses additional management needs by letting you create customized Business Process Views. A Business Process View is 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 company’s accounting processing, another for payroll, and so forth. Adaptive Dashboards Unicenter NSM Adaptive Dashboards are accessible as right-pane data viewers in the Unicenter MCC if you install the Web Reports and Dashboards option. When requesting the first dashboard each session, you must enter the user ID and password for the Tomcat server on which the Web Reports and Dashboards option is installed. Instead of being prompted once each session, you can check "Remember these settings" when entering the user ID and password on the Connection Settings dialog. Chapter 9: Getting Started 265 Network Visualization Managed Object Status Another important feature of Unicenter NSM is the ability to display the current, real-time status of any managed object. If a managed object experiences a problem, its visual appearance in Unicenter NSM changes. Using the Class Editor, you can assign the icon used to represent a class of objects. The icon’s shape always remains the same, but the color changes based on severity. Several Unicenter NSM facilities control how the status of managed objects appears on the 2D Map. First, up to ten severity levels can be set for every class of managed object. To customize WorldView for your own environment, you can set the color scheme for the icons that appear for each severity level. Value of Objects in Your Network You can define the value of an object in your network infrastructure by assigning a numeric value from 1-100 that defines the degree of value of an object in your network. The higher the weight, the more value an object has in your network. Each class of ManagedObject has a default weight assigned to it, and when your network is discovered, each object that is derived from that class inherits the default weight for each class. For example, the default weight of a router is higher than the default weight of a workstation because, typically, a router has more significance in a network than an individual workstation. 266 Implementation Guide Network Visualization You can change this weight value for each object to reflect the value of the object in your network using the Status page of the Property Notebook. You may want to assign a higher weight to a particular router because the router affects more critical processes. For example, you may want to increase the weight of the router that is connected to the computers that process your company's payroll. Assigning a weight to an object helps give you a better indicator of the overall health of your network infrastructure. Object Importance Using a sophisticated algorithm, WorldView determines the importance of each managed object in your network. Letting you view the importance of each managed object in your network helps you better analyze your network by giving you a much better view of the health of your IT infrastructure. For example, importance lets you quickly and easily distinguish between a printer that has a critical severity because it is out of toner and a critical payroll server that processes your payroll. Importance is calculated using the weight and severity levels of child and parent objects in your network. The importance of an object increases when the propagated weighted severity of one of its child objects increases. You can set the weight of each object in your network, or you can use the default weight that is preset for each ManagedObject class. Network Views You can select the criteria (or property) you want to use to determine the status of objects to view in the Unicenter MCC. The view of your network may be entirely different depending upon the criteria you choose. Only the icon colors associated with the object's severity change. You have the following three property choices: Maximum Severity Specifies that you want to view the status of your network by the highest severity of objects. The icon colors change to reflect the greater of the true severity and the propagated severity of each object. Maximum Weighted Severity Specifies that you want to view the status of your network by the highest weighted severity of objects. The icon colors change to reflect the greater of the true weighted severity and propagated weighted severity of each object. Maximum Importance Specifies that you want to view the status of your network by the highest importance of objects. The icon colors change to reflect the greater of the true calculated importance and propagated importance of each object. Chapter 9: Getting Started 267 Network Visualization 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 appears, it shows the selected object and all the objects with which it is directly associated. Object Statistics You can view statistics data, such as variance, number of children, and average weighted severity (variance, mean, and nodal sum), for most WorldView objects in the Topology or Business Process Views view in the left pane. Historical Information About Your Network You can travel back in time to view historical information about your network using the Unicenter Controller and Unicenter MCC Historian view. The Unicenter Controller lets you set the clock to a time in the past, and the Historian displays information for the specified point in time on timelines. The Unicenter Controller opens automatically when you choose Historian view from the right pane of the Unicenter MCC when historical information is available for an object. 268 Implementation Guide Network Visualization The Unicenter 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. For example, if 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. The Unicenter Controller also allows you to display a list of objects that are identified as being in a “critical” state. You select these objects from the Unicenter MCC to be updated to present information. You can display specific Business Process Views that you define. Chapter 9: Getting Started 269 Chapter 10: Implementation Scenarios This section contains the following topics: Introduction (see page 271) Scenario 1: Agentless Monitoring and Portal-Based Visualization (see page 271) Scenario 2: Focused Visualization Using Weighted Severity (see page 279) Scenario 3: Automated Business Views Using Dynamic BPV (see page 281) Scenario 4: Event Management and Advanced Event Correlation (see page 283) Introduction This chapter describes ways you can implement Unicenter NSM to solve typical requirements in today’s businesses. Illustrative scenarios explain the situation, the Unicenter components you can use, and how to configure the components to meet the business need. Scenario 1: Agentless Monitoring and Portal-Based Visualization In this scenario, a system administrator needs to provide an internal service to a department that includes monitoring IT devices and providing a dedicated portal view on critical issues. Unfortunately, because of corporate policies several machines cannot have any monitoring software installed on them. The system administrator decides to use the Unicenter Remote Monitoring feature to collect availability and performance information from the servers. Whenever threshold values are breached, event messages are generated and sent to Unicenter Management Portal for display in user-specific views. The benefits provided by this solution follow: ■ Minimal effort to collect the data is required. ■ Collected data is turned into information for target groups: ■ – For an administrator, the data is presented through the Unicenter Remote Monitoring Administrative Interface. – For the system administrator, the data is presented through the Unicenter MP user workplace. The implementation is easy to maintain and extend. Chapter 10: Implementation Scenarios 271 Scenario 1: Agentless Monitoring and Portal-Based Visualization The products and components Unicenter NSM provides that the system administrator uses to implement the solution are as follows: ■ Unicenter NSM--provides the basic management infrastructure, including the MDB ■ Unicenter Remote Monitoring--provides its agentless monitoring feature, including an engine and an administrative interface ■ Unicenter MP--provides a portal server that exposes Unicenter and other content to users through a web browser Installation The implementation of the scenario for agentless monitoring and portal-based visualization is a two-part process requiring installation of the components followed by configuration of the components to present the visualization solution. This section covers the installation part of that process. Installation of the Management Machine on a Windows Server The Unicenter NSM setup starts the Product Explorer with an installation menu. Select the following options from the menu: ■ Unicenter NSM Installation Wizard--leads you through the main installation process. You need to make at least the following selections: – MDB – WorldView Manager and Client – Event Manager If you already have a Unicenter Manager with the MDB in your environment, you can select the Administrative Client installation option. ■ Post-Installation Utilities – Unicenter Remote Monitoring For additional information about the installations, see the Installation chapter in this guide. Installation of the Portal Server on a Windows or Linux/UNIX Server We recommend that you use a dedicated computer for the portal server. Unicenter MP installs separately from the base Unicenter NSM installation. Select Unicenter Management Portal from the Product Explorer of the Unicenter NSM Installation DVD. No specific selections are required. For detailed information about the installation, see the Unicenter Management Portal Installation Guide. 272 Implementation Guide Scenario 1: Agentless Monitoring and Portal-Based Visualization Configuration The implementation of the scenario for agentless monitoring and portal-based visualization is a two-part process requiring installation of the components followed by configuration of the components to present the visualization solution. This section covers the configuration part of that process. Configure Unicenter Remote Monitoring The configuration monitors a set of services and a few system parameters for all Windows servers. To set up monitoring using the Unicenter Remote Monitoring AI 1. Connect to a Unicenter Remote Monitoring agent. 2. Select Windows, Template to define a Windows template. The Windows Template dialog appears. 3. Enter the server name in the Node field to base the template on one of the servers, and then click Discover. Some system metrics such as Available Memory and Processor Load are already enabled by default. 4. In the Services tab, select the Windows services you want to monitor and the expected state. 5. Click OK. Chapter 10: Implementation Scenarios 273 Scenario 1: Agentless Monitoring and Portal-Based Visualization 6. Select Windows, New to define servers based on this template. The New Windows resource dialog appears. This is a web server, so the Expected State for the WWW service should be changed to running. 7. Click OK. The server is discovered and its settings are saved. Repeat this step for all servers you need to monitor. For detailed information about Unicenter Remote Monitoring, see the Administration Guide and the online Unicenter Remote Monitoring help. 274 Implementation Guide Scenario 1: Agentless Monitoring and Portal-Based Visualization Configure a Unicenter MP Workplace After you configure and publish an event view portlet to Unicenter MP, a portal user who belongs to the Windows Systems Administrator group can select the published Unicenter Remote Monitoring portlet for the workplace definition. To add a portlet to the workplace 1. Select or create a Workplace and click Add Content. The Add Content to Workplace screen appears. 2. Select the portlet you want to display and click Add To Column. The selected portlet appears in the column on the right pane of the screen. 3. Click OK. The portlet is added to the workplace. The Workplace appears with data. Chapter 10: Implementation Scenarios 275 Scenario 1: Agentless Monitoring and Portal-Based Visualization Configure and Publish a Unicenter MP Event View Portlet The configuration task for Unicenter MP is to define an event view portlet that the Windows system administrator can use in a portal workspace. This configuration requires Unicenter MP administrative privileges. To define an event view portlet 1. Start Unicenter MP and navigate to Knowledge, Library, Enterprise Management, and expand Unicenter Event Management. 2. Select Configure Event Filters to define an event filter. 3. Create a new filter group, name it URM, and save this setting. 4. Add a new filter and name it URM All to reflect all event messages related to Unicenter Remote Monitoring. Assign permissions for the workgroup Windows System Administrator and save the settings. Then add the filter criteria as follows: ■ Property: Message ■ Condition: startsWith ■ Value: URM Click Back to view the filter definition. You can define additional filters for specific Unicenter Remote Monitoring metrics in the same way. 5. Select Event Console from Knowledge, Library, Enterprise Management, Unicenter Event Management to define an event portlet named URM All. 6. In the content view, select the Configuration tab. 276 Implementation Guide Scenario 1: Agentless Monitoring and Portal-Based Visualization 7. Select the newly-created URM All filter in the Available column and click the forward arrow to move the filter to the Selected column. Chapter 10: Implementation Scenarios 277 Scenario 1: Agentless Monitoring and Portal-Based Visualization 8. 9. Publish the portlet by specifying the following parameters: ■ View Name: URM All events ■ Permission: View: Workgroup / Windows System Administrator ■ Channel: MyViews Publish Business Process Views by selecting Knowledge, Library, Enterprise Management, Business Processes, and then select _Configure BPV Summary View. 10. Select New for the WV-Business Process Views scoreboard and then select the Remote Monitoring Business View. 278 Implementation Guide Scenario 2: Focused Visualization Using Weighted Severity 11. Check the option boxes Include Summary and Portal Explorer and publish the new view as URM Objects view. Scenario 2: Focused Visualization Using Weighted Severity In this scenario, an operator is confronted with dozens of critical objects that need intervention. The administrator’s concern is to attend to the most critical problems first. The administrator decides that the Unicenter Management Command Center can provide the solution. The administrator can take the following steps: ■ Assign higher severity weights to objects of specific interest. ■ Specify sort and display rules based on importance. The benefits provided by this solution follow: ■ Abnormalities on important systems are addressed first. ■ Visualization of the critical objects is easy to understand because the display is laid out clearly. ■ Problems are solved faster. The products and components provided by Unicenter NSM that the system administrator uses to implement the solution is as follows: ■ Unicenter NSM--to provide the Unicenter MCC component. Chapter 10: Implementation Scenarios 279 Scenario 2: Focused Visualization Using Weighted Severity Assign Severity Weights The implementation of the scenario requires the system administrator to assign severity weights to server objects and set sort and display rules for the critical objects in the Unicenter MCC. To assign new severity weights to server objects 1. Select a server object from the Unicenter MCC Topology View or Business Process View, right-click and select Add Viewer, Properties from the context menu. The Property Notebook for the server object appears. 2. Modify the weighted severity for all servers that require extra attention. You can use the importance in Unicenter MCC as sort and object color criteria. By default, the object color is determined by the propagated severity and the sort order is by object name ascending. 3. Right-click in the viewer’s white space to open the Sort context menu and change the sort criteria to Importance / Descending. 4. Select View, Status Display Rule in the Unicenter MCC menu bar to change the object color criteria to Maximum Importance. The most important server appears in the upper left followed by your other servers in descending order of importance. 280 Implementation Guide Scenario 3: Automated Business Views Using Dynamic BPV Scenario 3: Automated Business Views Using Dynamic BPV In this scenario, a company rule requires the presence of location information in the system SNMP MIB. The server objects in the topology map need to be displayed in folders that represent this information. The system administrator decides that Business Views and Dynamic BPV are tools that provide a solution. Rules allow for dynamic objects. The benefits provided by this solution follow: ■ Automatic assignment of objects to business-centric views ■ Resource-specific status aggregation and display ■ Improved operator focus on abnormal situations The products and components provided by Unicenter NSM that the system administrator uses to implement the solution follow: ■ Unicenter NSM--to provide the WorldView component Dynamic BPV. Configuration and visualization employ the Unicenter MCC component. Define Business Process Views to Show Location The implementation of the scenario to provide automated business views requires defining Business Process Views in the Unicenter MCC that show location information. This information is part of the server object properties that are collected during the IT discovery. Chapter 10: Implementation Scenarios 281 Scenario 3: Automated Business Views Using Dynamic BPV To define Business Process Views to show location 1. In the Unicenter MCC Business Process Views navigation pane, right-click the BPV parent object and select New, Business Process View to create a new BPV. In the Properties view for this new BPV, specify FirstFloor as the name and the label. 2. Reclassify the FirstFloor object to the DynamicBPV class by right-clicking on the object to open the context menu and selecting Reclassify, Business View, DynamicBPV. 3. Right-click the FirstFloor object to open the context menu again and select Viewers, Dynamic BPV Editor. 4. Define the rules that define membership to the FirstFloor folder. This rule selects Windows 2003 servers and workstations that have “L1” as part of their location string. 5. 282 Implementation Guide Click Save to save the view and populate the folder. Scenario 4: Event Management and Advanced Event Correlation You can repeat these steps for additional views like GroundFloor, SecondFloor, and so forth. Then, you can arrange all these business views in a hierarchy reflecting your real-world environment. Scenario 4: Event Management and Advanced Event Correlation In this scenario, a system administrator wants to receive events for Windows servers at the console whenever there are both physical and virtual memory shortages. The system administrator determines that the Advanced Event Correlation (AEC) component will provide the solution. AEC provides not only root cause analysis but also Boolean logic on events. AEC generates aggregated events that can be forwarded to the Alert Management System (AMS). Chapter 10: Implementation Scenarios 283 Scenario 4: Event Management and Advanced Event Correlation The benefits provided by this solution follow: ■ Consolidated event messages ■ Improved operator focus on abnormal situations The products and components provided by Unicenter NSM that the system administrator uses to implement the solution follow: ■ Unicenter NSM--AEC is part of Event Management Configure AEC to Receive Events at the Console To implement the solution of configuring AEC to receive events at the console when there are physical and virtual memory shortages, the system administrator begins by creating a rule using the AEC Interactive Development Environment (IDE). To create a rule using IDE 1. Open the Windows EM Classic GUI, Event, and AEC Policies. The AEC Policies Summary dialog appears. 284 Implementation Guide Scenario 4: Event Management and Advanced Event Correlation 2. Select AEC Policies New. The Select Rule Type dialog appears. 3. Select General Boolean and click OK. The Advanced Event Correlation IDE window appears. The left pane provides basic instructions for policy authoring. Review the instructions for additional background information. Chapter 10: Implementation Scenarios 285 Scenario 4: Event Management and Advanced Event Correlation 4. In the tree view, select the rule node [BOOL, TEMPLATE] and enter the following values in the right pane: ■ Name WindowsMemEx ■ Override Maturity TRUE ■ Maturity Seconds 3600 ■ Reset Seconds 0 The maturity is the lifetime of the rule instance that starts as soon as the first event matches. The rule instance expires when the second event arrives by not later than after 3600 seconds. 5. Expand the rule note [BOOL, TEMPLATE] and then expand the AND operator node. The AND operator node shows two children, Event A and Event B. 6. Right-click on Event A and select the wizard to define the first event. The Logical Operator Configuration Wizard dialog appears. 7. 286 Implementation Guide Enter the following settings: ■ Item Name WindowsPhysMem ■ Enable local reset request event checked Scenario 4: Event Management and Advanced Event Correlation 8. Click Next. The Event Configuration Wizard Match Event dialog appears. 9. Specify event attributes that match any event console message that reports the status change to Warning or Critical for the physical memory metric on any host machine: ■ Message template Host:.*caiWinA3 Trap WinA3_MemPhys .* (Warning | Critical) Physical ■ Node &(NODE) 10. Click Next twice. You do not need to make any entries in the dialog you skip. Chapter 10: Implementation Scenarios 287 Scenario 4: Event Management and Advanced Event Correlation The Event Configuration Wizard Reset Request Event dialog appears. 11. Specify the event attributes to request that if the status changes back to Normal during the lifetime of the rule, the AND condition does not apply and the rule should be reset. ■ Message template Host:.* caiWinA3 Trap WinA3_MemPhys (Warning | Critical) Repaired Physical ■ Node &(NODE) 12. Click OK to finish the definition and terminate the wizard. The configuration in the second item (Event B) is similar. 1. Right-click on Event B in the Logical Operator Configuration Wizard dialog and select the wizard to define the second event. Use the following settings: 2. 288 Implementation Guide ■ Item name WindowsVirtMem ■ Enable local reset request event checked In the Match Event dialog, use the following settings: ■ Message template Host:.* caiWinA3 Trap WinA3_MemVirt .* (Warning | Critical) Repaired Virtual ■ Node &(NODE) Scenario 4: Event Management and Advanced Event Correlation 3. In the Reset Request Event dialog, use the following settings: ■ Message template Host:.* caiWinA3 Trap WinA3_MemVirt (Warning | Critical) Repaired Virtual ■ Node &(NODE) Finally, define the message that is generated when both events arrive and the AND rule evaluates to true. 1. Start the wizard from the [BOOL, TEMPLATE] rule node and move forward to the root correlation event definition screen to modify the default message template with the following: ■ RCA: &(NODE) high memory utilization (virtual and physical) 2. Save the new AEC policy by choosing File, Save As) and give the new policy a name (for example, WindowsMemEx). 3. For test purposes, you can perform rule processing inside the IDE by choosing Options, Start Test Engine. 4. Otherwise, deploy the rule to any Event Management node by choosing File, Deploy policy. In any case, when the related events arrive the console messages appear similar to the following: Chapter 10: Implementation Scenarios 289 Appendix A: DIA Reference This section contains the following topics: DIA Introduction (see page 291) DIA Architecture (see page 292) Consumer Applications (see page 297) How DIA Works (see page 301) Advantages and Primary Functions (see page 304) DIA Configuration (see page 312) Troubleshooting and Diagnostics (see page 327) DIA Introduction Distributed Intelligence Architecture (DIA) allows a central location to manage all components and aspects of a network. DIA makes data requests and retrievals standard across different Unicenter NSM components by providing a generic mechanism that permits the dynamic deployment of necessary files to facilitate the correct monitoring of any given system. Deployment is generic and open to growth. DIA allows for high-speed, secure communications to transport data while providing remote node management and inherent failover capabilities. DIA is the underlying architecture upon which to build your system. It serves as the common communication and data collection interface that monitors your entire system. DIA is IPv6 compliant. You can deploy DIA on pure IPv6 systems and across IPv4 and IPv6 systems. DIA supports all the clustering services and platforms which are supported by HAS. Note: For more detailed information on the major functions of DIA, see the Advantages and Primary Functions section. For configuration information, see the DIA Configuration section. Appendix A: DIA Reference 291 DIA Architecture DIA Architecture DIA is composed of the following components that execute its functions: ■ Knowledge Base ■ Dynamic Node Administrator ■ Genes ■ Cells ■ Grid 292 Implementation Guide DIA Architecture Unicenter Knowledge Base The Unicenter Knowledge Base is the central communication and management point for DIA, serving as the interface for the outside world in the DIA system. A Knowledge Base consists of a core, a Dynamic Node Administrator interface, a consumer interface, and a plug-in interface. It is a logical grouping of Dynamic Node Administrator hosts that collects data from several sources and abstracts the original location of the information. The Knowledge Base performs all of the following functions: ■ Detects and locates the Dynamic Node Administrator ■ Seeds the Dynamic Node Administrator ■ Manages and deploys DNS nodes based on configuration parameters to make them management enabled ■ Collects and manipulates data from various data sources and shares them across DIA components ■ Routes consumer requests to the correct locations ■ Performs proxy and port brokering for nodes located behind firewalls ■ Distributes work to the Dynamic Node Administrator ■ Creates an abstracted view of data Note: The Knowledge Base uses Java Remote Method Invocation (RMI) as the communication mechanism to the consumers. All the Unicenter Knowledge Bases in the DIA environment communicate with each other and synchronize their information through the MasterKB. Through this environment, a Knowledge Base can get information about any host without knowing its location or other details. To request host information, query the nearest Knowledge Base and submit the request. The Knowledge Base routes the request to the appropriate location, abstracts the information, and returns the result of the request in a generic format. The MasterKB in a Unicenter NSM installation is indicated by the presence of an SRV entry in DNS. This entry points all of DIA to one or more Knowledge Bases and allows for automatic configuration of the grid and managed hosts based on policy. The primary Master Knowledge Base is assigned by virtue of having the lowest priority number in the SRV record listing. The other higher priority number is considered secondary Knowledge Base. For example, the primary has a priority of 1 and the secondary Knowledge Bases have priorities of 2. Once any Knowledge Base starts, it looks for the presence of the SRV record and then contacts that Knowledge Base to perform several tasks. First, it is processed in policy to determine zone information; next, it is synchronized in the grid; and finally, it sends to the grid any information about itself to update the grid for its managed objects. Appendix A: DIA Reference 293 DIA Architecture On startup of any DIA object, Knowledge Base or Dynamic Node Administrator, the SRV record is queried and the information is used to connect to the Master Knowledge Base to have the host processed in the policy engine. This determines which zone to use for each of the Knowledge Bases and which Knowledge Base will manage which Dynamic Node Administrator; that is, where each Dynamic Node Administrator should activate. The existing zone policy file performs two functions: to determine and control the zone information and to determine and control the activation information. The only interaction with DNS from a DIA perspective is to query the DNS information to determine where the network service for DIA is running (occurs only once during startup). The DNS information indicates where the primary and secondary Knowledge Bases are running. Normal host resolution is also performed as new targets come online or as IP addresses change. There is very little impact to DNS with this technology. Note: Because all Knowledge Bases are in full communication with each other, you only need to connect to one Knowledge Base at a time to access all systems. Upon connecting, you can dynamically switch to another Knowledge Base at any time. Consumer Interface The consumer interface is a collection of methods used to submit requests to the Knowledge Base. The consumer interface is the entry point for applications external to DIA to submit requests for data, enable cells, and enable a host on the network. Examples of applications through which you can interface include Unicenter Management Portal and Unicenter Web Services. The SDK provides clean, easy to use APIs that allow secure connections to the Knowledge Base. Requests are sent in to the consumer interface and responses are sent back out. The response is then passed into the DIA decoder to supply the data in the format requested. Dynamic Node Administrator The Dynamic Node Administrator, the smallest subcomponent needed to hook into the DIA system, cultures the growth of knowledge for Unicenter components by seeding the system. It gives the host system all the necessary components for users to make intelligent system management decisions based on the available information. The two main tasks of a Dynamic Node Administrator are: ■ Recognition ■ Gene Management 294 Implementation Guide DIA Architecture A Dynamic Node Administrator is also responsible for the following: ■ Making the system Management Aware ■ Monitoring the system ■ Providing a central location to acquire information from the system Each Dynamic Node Administrator reports to a single Unicenter Knowledge Base (usually the nearest one, but configurable based on policy). A Knowledge Base in turn has many Dynamic Node Administrators reporting to it. The Knowledge Base distributes incoming work requests to the Dynamic Node Administrator. The Dynamic Node Administrator uses a domain lookup to determine the location of the Knowledge Base and which systems it can activate to. This process allows DIA to automatically locate Knowledge Bases and get Dynamic Node Administrator systems inserted into the Dynamic Node Administrator grid. You can configure the Dynamic Node Administrator to have a specific Knowledge Base as the owner using the autoactivatedna.bat or autoactivatedna.sh file. Simply provide the name of the Knowledge Base to which you want to assign the Dynamic Node Administrator as a parameter in the file. If you do not specify this information, the product performs an SRV lookup to determine the best Knowledge Base to use based on network and domain information. Notes: ■ Once a Dynamic Node Administrator is autoactivated to a Knowledge Base, it cannot be reactivated by rerunning autoactivatedna.bat or autoactivatedna.sh. You must use the DIA Diagnostic Tool. For more information on the autoactivatedna.bat file, see the Troubleshooting and Diagnostics section in this appendix. ■ When you install the Dynamic Node Administrator with the DIA Diagnostic Tool on a remote system, run autoactivatedna.bat manually on this remote system after the installation is completed successfully. Gene The gene is an interface between the cells and the Dynamic Node Administrator. The gene is responsible for the following: ■ Cell inventory ■ Encryption and decryption ■ Work order acceptance Appendix A: DIA Reference 295 DIA Architecture Cells Cells are the primary mechanisms for acting on existing data. They are dataor command-specific modules that collect any type of information from any given type of data source and therefore are responsible for the knowledge of the abstracted entities on which they are instructed to operate. Cells plug directly into the gene interface to collect data and are responsible for any type of communication needed for the data manipulation they support. Each cell isolates itself from all other entities and starts in its own environment, independent of the Dynamic Node Administrator and other cells, so that it remains abstracted from the Dynamic Node Administrator environment. This results in enhanced security and stability. All consumers can request data from any given cell by using a specific framework. Cells are either in Java or C/C++ format (which uses a Java/JNI interface). Every cell is lightweight with a Java component; however, when a cell needs native C/C++ code to make calls to the legacy code, it has a C/C++ component as well. In general, you manually enable cells only when they are required. This conserves the resources they consume. The cells installed with Unicenter NSM are an exception. Unicenter NSM installs, registers, enables, and starts the following cells by default as part of the Unicenter NSM installation process because they are required for Unicenter NSM to function: ■ Agent Control cell ■ DSM Control cell ■ WVObject cell ■ MDB cell ■ CAEM cell ■ CAAMS cell Note: These cells can be registered even if the Dynamic Node Administrator is not yet activated to a Knowledge Base, but starts running only after the Dynamic Node Administrator is activated. The PDI (Package Deployment Infrastructure) cell is also installed with Unicenter NSM. The PDI cell is a DIA internal cell, but to conserve resources it is not enabled by default. Enable the PDI cell when you want to use DIA's package deployment feature. You can deploy and start a DIA internal cell using the DIA Diagnostic Tool. However, support is not available for the PDI cell, even though it is shipped with Unicenter NSM. 296 Implementation Guide Consumer Applications DIA Grid The DIA grid determines the network location of particular DIA system elements. The grid allows users to route requests to any machines in the current DIA architecture. In other words, all DIA aware components can talk to any other DIA aware components without knowing specifics about each other. Users can make requests to any Unicenter Knowledge Base in the system and the grid will route it correctly for data retrieval. Once you submit a request to the system, DIA formats the request, moves and issues it, and finally returns it to the requester, all based on information contained in the grid. The grid seeks out the following information between all Knowledge Bases: ■ What is available ■ Version information ■ How each message should be passed around the DIA system Consumer Applications Consumer applications interact with DIA through the consumer interface to submit requests, enable cells, and enable hosts. Each application interfaces with DIA for a specific purpose, and each application has potential problems that may occur between DIA and the component. The main DIA consumer applications are as follows: ■ Adaptive Dashboards Server (ADS) ■ Management Command Center (MCC) ■ Unicenter Management Portal (UMP) and Web Reporting Services (WRS) ■ Unicenter Remote Monitoring (URM) ■ WVObject Cell See the topics that follow for an explanation of what each of these main consumers uses DIA for and ways to solve problems that may occur when interfacing. Appendix A: DIA Reference 297 Consumer Applications Adaptive Dashboards Server Adaptive Dashboards Server (ADS) uses DIA for registration and updates. It uses the Unicenter Knowledge Base as the interface to get information from the cells regarding the different enterprise resources that need to be displayed in the dashboards. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition to that, the dsmcell and the agctrlcell must be registered and active to collect the information. Potential Problems: Being a web-based application using Tomcat, the dashboards may not be visible. The first thing to check is whether the Tomcat server is up and running. From the DIA perspective, if the dashboards application is not able to connect to the Knowledge Base, it will not be able to show the latest information. In this case, check the ukb0.log file to determine the exact reason. If Tomcat and the Knowledge Base are both working properly, open the diatool to verify that both the dsmcell and agctrlcell are working properly. If there is a problem you can de-register and then reregister them. The cell-specific logs can also provide a precise cause of the failure. Management Command Center The Unicenter Management Command Center (Unicenter MCC) uses DIA for the correct and timely updates of status and other information that needs to be used and displayed. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition, the amscell, mdbcell and the event cell must be registered and active to collect the information from and send it to the Unicenter MCC. Potential Problems: The Unicenter MCC has various views. The views that are dependent on DIA could have trouble displaying the correct information when the Dynamic Node Administrator or the Knowledge Base services are not running properly.You must ensure that all the required cells are functioning properly. 298 Implementation Guide Consumer Applications Unicenter Management Portal & Web Reporting Services Unicenter MP and Web Reporting Services (WRS) are DIA clients and use it for registration and updates. They use the Unicenter Knowledge Base (local or remote) as the interface to get information from the cells (local or remote) regarding the different enterprise resources that need to be displayed in the dashboards. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition, the following cells are required for gathering the information: ■ wvobjectcell ■ caamscell ■ dsmcell ■ evtcell Potential Problems: Most functionality is unavailable when DIA or the cells are down. No reporting data is displayed. You will see the "unable to retrieve data" messages and other messages that only a System Administrator will be able to understand. Restarting the Unicenter Knowledge Base is probably not possible since it is unlikely the Knowledge Base is local to the Tomcat server. See the ukb0.log file for more details If Tomcat and the Unicenter Knowledge Base are both working properly, open the DIA Diagnostic Tool to verify that both the dsmcell and agctrlcell are working properly. If there is a problem, try deregistering and then reregistering them. The cell-specific logs could also provide precise cause of the failure. Unicenter Remote Monitoring Unicenter Remote Monitoring uses the DIA C-Gene – the communication component of DIA – to communicate between the Administrative Interface and Unicenter Remote Monitoring Agents. Pre-requisites: DIA Dynamic Node Administrator must be installed and running on both the Unicenter Remote Monitoring Agents and the Administrative Interface nodes. Potential Problems: Unicenter Remote Monitoring uses DIA for its communications. If the Dynamic Node Administrator service fails or is stopped on either the agent or the admin node, then this communication fails and you get an error message “Communication with the agent failed” Appendix A: DIA Reference 299 Consumer Applications You can also get this error message if the Dynamic Node Administrator is running, but it is not activated properly to the Unicenter Knowledge Base. That is, the libraries required for communication have not been pushed to the Dynamic Node Administrator by the owner Knowledge Base. To confirm this, check for the cgeneclient.dll library in the dna/lib directory. If this file is not present, it means that the Dynamic Node Administrator was not activated properly. WVObject Cell The WVObject cell depends on the Dynamic Node Administrator and the Unicenter Knowledge Base. It uses both the native and non-native API. The location of the registration and deregistration batch files are: InstallPath\CA\SC\CCS\WVEM\Bin The registration batch file is regwvcell.bat The deregistration batch file is unregwvcell.bat Potential Problems: Following are problems that a user might face with regards to the WVObject cell: ■ Cannot connect to cell ■ No data from cell To debug the problems related to the WVObject cell, do the following: ■ Check whether the WVObjectcell.exe, Dynamic Node Administrator and Unicenter Knowledge Base are running. Start them if they are not running. ■ Check whether the Severity Propagation Service and the database are running. Start them if they are not running. 300 Implementation Guide How DIA Works How DIA Works An understanding of how the DIA process works is necessary to know how your network is managed by one central location. The DIA process entails the initial configuration and subsequent processing of information across the IT infrastructure as follows: Configuration ■ The Knowledge Base detects a Dynamic Node Administrator and creates the required genes to support the current local installation; Dynamic Node Administrator recognition is automatic and configurable. ■ The Dynamic Node Administrator recognizes software components and operating system attributes that Unicenter may be interested in monitoring. The following inventories are created: ■ Knowledge interfaces in a Knowledge Base ■ Software and services in each Dynamic Node Administrator environment Information Processing ■ As requests come into the Unicenter Knowledge Base from consumers, they are sent to the appropriate nodes for data collection. The Unicenter Knowledge Base collects information from multiple sources like Event Management, WorldView, Agent Management, and Unicenter NSM agents. ■ The Unicenter Knowledge Base takes all information obtained during detection and deployment and populates the grid. If a Knowledge Base goes down, all managed nodes are adopted by another Knowledge Base. Information is instantly replicated across all Knowledge Bases. ■ Consumers like Unicenter MP or Web Services issue requests to the Unicenter Knowledge Base and the Knowledge Base submits those requests to the systems that it knows about based on information gathered when the system was enabled. Appendix A: DIA Reference 301 How DIA Works Utilities The following utilities, used to configure and test the product during the development phase, evolve frequently and have a limited availability: Detection and Deployment The detection and deployment utility locates all of the Dynamic Node Administrator in a given IP address range and, if a Dynamic Node Administrator is present, describes its state. This utility also deploys cells to all systems with a Dynamic Node Administrator. Console The console utility gets console data, displays attributes of console records, and filters console messages. This utility is currently in the form of the console log GUI (a way to test the console log knowledge module). It lets you collect the contents of the log file to any system running the utility without having to map a network drive or install other components. WorldView Registration Service The WorldView Registration Service is a DIA service that lets one machine in the DIA grid act as a server for registering and processing status changes of Unicenter components. There is one WV Registration Server for each DIA zone. The switchwvregsrvr command line utility lets you switch the WV Registration Server that is registered with DIA. The utility usage is described in the online CA Reference under WorldView Executables. DIA Diagnostic Tool The DIA Diagnostic Tool is a component of Unicenter NSM that lets you troubleshoot and manage all aspects of your DIA infrastructure from any Knowledge Base. The DIA Diagnostic Tool is designed for administrative and support personnel rather than end users. The DIA Diagnostic Tool is installed as part of the Knowledge Base installation and is located in the InstallPath\DIA\dia\ukb\bin directory. You can run the tool from this directory. Note: To run the DIA Diagnostic Tool to a non-english Knowledge Base, modify the diatool.bat file by adding the following case-sensitive option: -DAuth="false" The option must follow the line: -DCA_DIA_HOME="%CA_DIA_HOME%" 302 Implementation Guide How DIA Works Run the DIA Diagnostic Tool Run the DIA Diagnostic tool to monitor all aspects of your DIA infrastructure. To run the DIA Diagnostic Tool 1. Do one of the following: ■ On Windows, run the following command in the InstallPath\DIA\dia\ukb\bin directory: diatool.bat kb host ■ On Linux or UNIX, run the following command in the $CA_DIA_HOME/dia/ukb/bin directory: ./diatool.sh kb host kb host Specifies the name or IP address of the knowledge base to which you want to connect. The Knowledge Base Login screen appears. 2. Enter a valid Administrator or root user name and password that has access to the knowledge base you specified and click Connect. An admin group or root equivalent is also acceptable. The following message appears when the login is successful: Disclaimer: Caution!!! Improper usage of this tool might cause irreversible damage on your Knowledge Base grid, especially making a change like moving (floating) a DNA node to a different Knowledge Base node. Note that a corrupted grid will get propagated to all the known Knowledge Bases, so make sure you know exactly what you are doing before making changes to the grid. Click "Yes" to proceed or "No" to exit the tool. 3. Click Yes on the disclaimer to proceed with the tool. The DIA Diagnostic Tool main window appears. Note: See the DIA Diagnostic Tool help for more information. Appendix A: DIA Reference 303 Advantages and Primary Functions Advantages and Primary Functions DIA provides a central location that abstracts the data coming from any data source so that the front-end display does not need to know how to format it. These and other primary functions give you the many advantages of centralized system management. DIA comes with the following functions and abilities: ■ Centralized component management ■ Abstract data collection ■ Transparent and secure communications ■ Constant availability ■ Zoning See the topics that follow for more detailed descriptions of each primary function. Centralized Component Management DIA provides one central location to manage the Unicenter infrastructure that is installed. This allows for a much more robust environment that is selfmaintaining and easy to manage. The Dynamic Node Administrator lets you manage the system and perform tasks such as data collections and communications. The Knowledge Base is the entry point for collecting information from the Dynamic Node Administrator hosts. 304 Implementation Guide Advantages and Primary Functions Detection and Deployment DIA can locate itself on the network, in the form of a Knowledge Base or Dynamic Node Administrator host, and configure automatically and dynamically. Knowledge Bases locate all Dynamic Node Administrators and other Knowledge Bases on the network. They create a grid of machine information that allows you to determine where requests should be moved to and how to access all of the systems on the network. The grid is essentially a map of the entire management environment, allowing for communication to any of the systems. After a Knowledge Base locates a Dynamic Node Administrator, it can perform tasks such as the following: Software Recognition The process of locating installed software on the target system to allow for management of that software (such as SQL, Oracle, Unicenter Event Management, etc.). Management Aware/Enabled Activates components for cultivating knowledge from the target system for display in a GUI. Note: See the topic L Gene Technology for more information. Communications Enablement Provides secure and encrypted transmissions without changes to existing interfaces if so desired. Note: See the topic Transparent and Secure Communications for more information. Remote Node Management When a system becomes Management Aware, a Dynamic Node Administrator is placed on the system and the recognition process starts. The Dynamic Node Administrator detects operating system information, software and hardware information, and network information pertaining to the given target host. This information is then transmitted back to the Knowledge Base to determine the best way to manage the system and what components the system needs. Using Dynamic Node Administrator, you can dynamically and automatically adjust settings such as IP address changes, network firewall locations, future software installations, and others. Appendix A: DIA Reference 305 Advantages and Primary Functions Data Collection and Abstraction DIA creates a common interface to all available Unicenter components. Because each component uses different technology to recognize and use backend data, DIA abstracts the data format from the display and moves all backend components into one centralized common look. This method of data collection separates the data from the source from which it came, allowing multiple users to handle the data in their own ways, all without having specific knowledge of the source. L Gene Technology DIA uses L Gene technology to convert back-end data into an abstract format that can be distributed across the system for the purpose of displaying and/or correlating the data. L Genes provide a clean and easy to use interface for data suppliers to connect to DIA and feed knowledge into the system. DIA uses the L Gene to start up and configure a collection of cells that are used to cultivate or obtain knowledge from any given system. L Cells serve as the hook into DIA, and L Genes determine if a given L Cell should be created on a system based on information found on the given system. Transparent and Secure Communications DIA facilitates transparent and secure communications across different communications packages. Using the communications gene (or C Gene), DIA provides a layer to each communications mechanism on a network to allow their existing interfaces to remain the same while at the same time giving them the use of firewall detection, port consolidation and secure/encrypted transmissions with little or no modification to existing code. 306 Implementation Guide Advantages and Primary Functions C Gene Technology C Gene technology is responsible for moving data between hosts. It can perform tasks such as changing network IP addresses, detecting firewalls, and issuing proxy requests to the Knowledge Base for systems that are unreachable through normal communications. As with all DIA technology, C Gene technology performs independent of user interaction, on demand, and dynamically enough to be self-maintaining. The C Gene is a simple mechanism that moves data from point to point. C Cells support data such as publish/subscribe operations and message-based communications. To enhance the guaranteed delivery of messages, all communications can be confirmed with the receiving applications. Dynamic Network Detection The C Gene can detect the presence of a firewall and multi-tiered "Demilitarized Zones" (DMZ), allowing DIA to establish connections without making changes to the firewall. In addition, firewall detection allows for wellknown ports to access information located outside of the firewall. A DMZ is a firewall configuration for securing local area networks (LANs). DIA uses the same port for all communications so that there is no need to configure ports other than the ports required for DIA (a maximum of three). DIA can automatically proxy connections for target Dynamic Node Administrator hosts that are located behind the firewall without any interaction or configuration changes by the systems administrators. Since information can change on the network and more often on machines outside the firewall, DIA provides the ability to relearn the network topology with regards to the firewalls and network connections not only on the private network but in the DMZs as well. Appendix A: DIA Reference 307 Advantages and Primary Functions Security For security purposes, the Knowledge Base includes a proxy which detects firewalls and dynamically connects to machines that need monitoring in this environment. Note: DIA does not currently support Unicenter Knowledge Bases located outside a firewall unless in-bound ports are open for connects. However, the Dynamic Node Administrators can be outside of a firewall as long as they are communicating to a Unicenter Knowledge Base inside of the firewall. To further heighten security, all information in the DIA subsystem is encrypted and secure. It can only be removed within the DIA subsystem, which removes the ability to "spoof" requests and responses. All out-bound data communications from all DIA components (from the Knowledge Base to the Dynamic Node Administrator host) use secure sockets with public/private key encryption up to 128 bit for all transmissions to provide the highest possible level of security. Security Scenarios For a network with one DMZ or multiple DMZs that allow the private network full access on the way out, a single Knowledge Base is set up to proxy for all nodes in the DMZs outside the private network. The Knowledge Base learns about the nodes as they start up, and this information determines where the system needs help communicating to private network nodes. For a network with multi-tiered DMZs representing different levels of security before reaching the internet, multiple proxies are used to establish a wellknown path out of the private network. Each proxy manages the DMZ it is located in and passes information out by the established path. 308 Implementation Guide Advantages and Primary Functions Availability DIA is available at all times; there cannot be a single point of failure in the system. Knowledge transfers and communications are guaranteed, and in the event of a problem with a system area, they will reroute dynamically to ensure guaranteed delivery. Failover of Knowledge Bases ensures DIA's constant availability. DIA is selfreplicating, fully distributed, and backed up to a physical disk. Therefore, if a problem arises with one Knowledge Base, all other Knowledge Bases adopt the workload from the failed system. All users are then updated and rerouted accordingly. Appendix A: DIA Reference 309 Advantages and Primary Functions Grid Technology The Knowledge Base takes all of the information that was obtained during detection and deployment and populates the grid. The grid tracks the status and location of any system in the DIA management system. In the grid, all DIA aware components can interact without knowing specifics about each other. The grid replicates information from the master connection (the Knowledge Base on the MDB system). Knowledge Bases then retrieve this information from the grid and use it to interact with all other Knowledge Bases (such as notifying other bases of changes and requesting information). This replication allows for one common grid for all nodes in a given domain. After the grid is populated, the information is passed on to all other Knowledge Bases and replicates across these Knowledge Bases. As a result of this replication, if a Knowledge Base goes down, all of the managed nodes from that Knowledge Base are adopted by another Knowledge Base. The grid updates to reflect this change, and communications are re-established. All users connected to the failed Knowledge Base are then updated and rerouted accordingly. Once a Knowledge Base is part of the grid, its system will connect to the grid automatically without having to supply a host name for a Knowledge Base. DIA can then determine all potential connections to the grid without requiring information from the end user. Zoning Zones are logical entities or groupings of managed hosts on the network. Zone information is based on policy on the Master Knowledge Bases and is used to segregate groupings of machines so that there is no communication between logical groupings. For example, a typical use of zones is to break up production and test environments. The advantage is that a machine can be moved from test into production or vice versa by requesting DIA to move the machine, rather than having to physically change the location of the box or the subnet to which it belongs. There is no communication between zones at all. Zones should be carefully configured with this in mind. Submitting requests from one zone to another to retrieve data from any of the Dynamic Node Administrator hosts results in a zone violation and is unsuccessful. 310 Implementation Guide Advantages and Primary Functions In DIA, zones separate different working environments for you. If you want to keep the QA, development, and production environments separate, you can assign a specific zone for each Knowledge Base. This causes the Dynamic Node Administrator activated by you to belong to the designated zone. DIA separates the environments by allowing zones to exchange information with other zones but forbidding communication between zones. Knowledge Base Zone and Grid Rules Keep the following rules in mind while working with Knowledge Base zones and grids: ■ If a Knowledge Base is not defined to a particular zone, it is placed in the DEFAULT zone by default. ■ For security reasons, there is no communication or routing of requests across zones. Knowledge Bases in one zone cannot communicate to Knowledge Bases in another zone. ■ You only modify the policy file for the Master Knowledge Base. The Master Knowledge Base is the keeper of the grid information. Other Knowledge Base zones do not - they have slots from the grid. ■ Every Knowledge Base is only responsible for its own slot in the grid and only makes changes to that slot. ■ The Master Knowledge Base coordinates and updates changes to all Knowledge Bases in the zones. For example, if a Knowledge Base gets a new managed node, the Master Knowledge Base tells other Knowledge Bases in that zone about it. How the Grid and Knowledge Base Zones Work Knowledge Base zones and the grid work together to create different zones for different purposes. The following process indicates the interaction between the Knowledge Base zones and the grid: ■ The first Knowledge Base starts up and obtains all the SRV records for your service name (_grid._tcp) to determine to which zone the Knowledge Base belongs. The DNS server runs the IP address through the policy file and indicates to which zone it belongs. The Knowledge Base realizes it is first and becomes the Master Zone. ■ The second Knowledge Base starts (not the Master Zone) and pings the DNS server looking for the SRV record. The DNS server runs the IP address through the policy file and indicates to which zone it belongs. For example, the Development zone. ■ A managed node may start up after that. Managed nodes also do a look up in the SRV record - runs through the Activation Point section of the code. The target is told to which Knowledge Base it belongs. By default, they belong to a particular zone. Appendix A: DIA Reference 311 DIA Configuration Zone Setup To set up zones in an environment without a Master Knowledge Base, edit the Knowledge Base configuration file (ukb.cfg) by assigning the appropriate zone for the Knowledge Base in the field named Zone. All Dynamic Node Administrator machines are subsequently moved to the correct zone, where they cannot send requests across zones. DIA Configuration The topics that follow will give you an understanding of the DIA configuration and implementation process. We recommend reading the preceding portions of this appendix before continuing. You need to perform the following procedures so that the DIA is configured to monitor your infrastructure: ■ Configure Knowledge Base policy file ■ Create DIA rules file Important! Install and configure the Master Knowledge Base before installing any other machines. The Master KB's policy file is used to automatically configure subsequent Dynamic Node Administrator and Knowledge Base installations. If you do not do this, you must manually configure each machine. 312 Implementation Guide DIA Configuration DIA Deployment Recommendations Consider the following recommendations when you deploy DIA in your environment. RFC1033 implies that it is a good practice to use reverse DNS lookup to identify IP addressed hosts when they are added to the network. Therefore, an important requirement for DIA installation includes reverse DNS lookup using PTR records (pointer to canonical names) for the nodes involved. DNAs should be activated to the geographically and physically closest Unicenter Knowledge Base for better performance. DNA is always activated to a Unicenter Knowledge Base on the local machine if one is available. If possible, design Unicenter NSM deployment as follows: ■ The Master Knowledge Base has approximately an equal number of network hops from each Unicenter Knowledge Base ■ The number of DNAs registered with a Unicenter Knowledge Base does not exceed 500. For larger number of DNA registrations, divide them among the closest Unicenter Knowledge Bases. For large deployments, product installations, or product upgrades, adhere to the following best practices: 1. Decide on install locations for all NSM managers. Based on this information, decide on the overall most central location for the Master Knowledge Base. 2. Install and setup the Master Knowledge Base (NSM Manager install). 3. Set the activation and registration rules. For example, all machines running on the 141.202.*.* subnet should activate to the DSM manager Unicenter Knowledge Base and others to the MDB Unicenter Knowledge Base. 4. Ensure that the Master Knowledge Base is running 5. Install the agents. The agents are activated automatically based on the rules. Appendix A: DIA Reference 313 DIA Configuration Configure Unicenter Domain Name Services You need to set up and configure the auto detection mechanism that uses Domain Name Services (DNS) SRV records to locate the Knowledge Bases that activate and use DIA. You do this by adding an SRV record. Notes: ■ If DNS is not available, or if it is available but the DNS SRV record cannot be set, see the topics Install DIA Without DNS Available and Install DIA Without an SRV Record Set. ■ If you are installing Unicenter NSM r11.2 on a system that uses a static IP address, you may get an error because DIA fails to find and connect to the DNS server with the SRV record. To enable DIA to find the SRV record during installation, you must set the connection-specific DNS suffix in your network settings. To add an SRV record 1. Refer to the documentation provided by your operating system vendor or the DNS provider for information regarding how to invoke the configuration mechanism. If you are using a third party to host DNS services and do not have access directly to the DNS server, a forward lookup DNS server can be used. The following dialog provides an example: 314 Implementation Guide DIA Configuration 2. Configure the fields as follows: Service Specifies the actual name of the service that is used to perform the lookup. Enter _grid into this field. Once specified, you cannot change this value. Protocol Specifies the type of protocol to use. Enter _tcp into this field. Once specified, you cannot change this value. Priority Sets the order of priority for Knowledge Base systems to be pinged for the service record. Set this to 1 to designate the first Knowledge Base as the Master Zone, and if additional Knowledge Bases are installed, the number should be incremented to allow DIA to determine which Knowledge Base to use and in what order. Weight Algorithms to affect priority; this cuts down on traffic. Set this field to 0. Port number Specifies the port that the service is listening on. Set this port to the number used by the Knowledge Base located on the host that has the MDB installed. The default is 11503. Host offering this service Specifies the host (DNS server) where the installed service (Knowledge Base) and the MDB is physically running. Enter the name of the Knowledge Base into this field. Note: See the New Resource Record dialog for an example of what the dialog will look like with the information entered. 3. Click OK. The new SRV record is created. After the SRV record is created, the DNS hosts should all become members of the domain to which the SRV record is added. This is done in the network card configuration for the client system. For example, if your primary domain is company.com and you have made the changes to the DNS server hosting company.com, set the primary DNS to point to that domain server. If you have made the changes to subdns.company.com, which is configured as a forward lookup domain, set your primary DNS server on your client system to allow it to perform lookup requests to the system hosting subdns.company.com. Then you can get the correct DNS records from the server. Appendix A: DIA Reference 315 DIA Configuration In most cases, you would add the SRV records to the primary DNS server, as in the first example. Note: Once the MasterKB is set up, you may need to reset the location where the WorldView Registration Server is configured. From the WorldView Manager/MDB Server, run the switchwvregsrvr.bat utility. If you install the WorldView Manager and MDB after configuring the MasterKB, you do not need to run the utility. See the online CA Reference under WorldView Executables for information about the switchwvregsrvr.bat utility. You are now ready to begin installing DIA. DIA comes as part of the Unicenter NSM or CA CCS package; therefore, there are no additional hardware or software requirements than those for Unicenter NSM or CA CCS. Simply run the DIA installation to install. DIA comes fully ready for installation with all needed dependencies. Note: DIA does not require that a JRE be installed or running on the system. DIA does lay down a JRE, but it is not installed or registered with the system. DIA is fully encapsulated and starts executables and JREs as needed during the course of normal operations. Configure the MasterKB Without an SRV Record or Domain If DIA is installed in an environment where there is no domain set up or no access to a DNS server, you can specify the MasterKB host name in the dna.cfg file. Note: The dna.cfg file for each Dynamic Node Administrator host that you have installed must be changed. To configure the MasterKB without an SRV record or domain 1. Open the dna.cfg file in the folder InstallPath\CA\SC\CCS\DIA\dia\dna\config using a text editor of your choice. 2. Set overrideSRV to yes and MasterKB to the host name of the MasterKB that is to be your Master Knowledge Base server. For example, overrideSRV=yes MasterKB=mymasterkbhostname.domain.com 3. Optional: Set a secondary MasterKB host name to take over responsibility if the MasterKB is down. For example, SecondaryMasterKB=secondarymasterkbhostname.domain.com Note: Set the secondary MasterKB only when there is no domain or DIA SRV record set up. 316 Implementation Guide DIA Configuration 4. Save the dna.cfg file. 5. Stop the CA DIA 1.3 DNA service. 6. Stop the CA DIA 1.3 Knowledge Base service. 7. Start the CA DIA 1.3 Knowledge Base service. 8. Start the CA DIA 1.3 DNA service. Important! Always consider the sequence that is described in the steps 5 - 8 when you restart the two services (CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base). Stop the Dynamic Node Administrator first and then the Knowledge Base. Then start the Knowledge Base, and lastly, start the Dynamic Node Administrator. Also consider the following guidelines: ■ Override the MasterKB name on all these systems by running the updateConfigFile utility under Install_Path\SC\CCS\DIA\dia\dna\bin. Use fully-qualified domain names in dna.cfg. ■ If both SRV record/domain and dna.cfg are configured with the MasterKB, you can set an attribute in dna.cfg to specify which configuration has a higher priority. If overrideSRV is set to yes in dna.cfg, the MasterKB specified in this location takes effect regardless of the settings in the SRV record. If overrideSRV is set to no in dna.cfg, the MasterKB in the SRV record of the DNS takes effect. The default setting for overrideSRV is no. ■ Once the MasterKB is set up, you may need to reset the location where the WorldView Registration Server is configured. From the WorldView Manager/MDB Server, run the switchwvregsrvr.bat utility. If you install the WorldView Manager and MDB after configuring the MasterKB, you do not need to run the utility. See the online CA Reference under WorldView Executables for information about the switchwvregsrvr.bat utility. Commands to Start and Stop DIA Daemons on Linux or UNIX You can start and stop the DIA daemons running in Linux or UNIX environments with the following commands. To start CA DIA 1.3 Dynamic Node Administrator, run this command in the $CA_DIA_HOME/dia/dna/bin directory: ./dnacntl start To stop CA DIA 1.3 Dynamic Node Administrator, run this command in the $CA_DIA_HOME/dia/dna/bin directory: ./dnacntl stop Appendix A: DIA Reference 317 DIA Configuration To start CA 1.3 Knowledge Base, run this command in the $CA_DIA_HOME/dia/ukb/bin directory: ./ukbcntl start To stop CA 1.3 Knowledge Base, run this command in the $CA_DIA_HOME/dia/ukb/bin directory: ./ukbcntl stop Cell Configuration DIA comes with the following cells pre-installed: ■ Agent Control Cell ■ DSM Control Cell ■ WV Cell ■ MDB Cell ■ CAEM Cell ■ CAAMS Cell These cells are registered and activated automatically with a Dynamic Node Administrator. If you need to manipulate the cell settings, see the DIA Diagnostic Tool Help, Manage Resources for more information. DIA also installs the PDI cell, a DIA internal cell that is not enabled or started by default. You must enable and start the PDI cell manually when you want to deploy packages using the DIA Package Deployment Infrastructure feature. DIA Rules File The DIA Rule execution module writes rules for DIA in XML (eXtensible Markup Language). The module writes rules for hostnames of machines, IP addresses of machines, or complete subnets. The rules reside on the Master Knowledge Base, which is defined by an entry in the DNS. DIA defines its rules using the RDL (Rule Definition Language) and interprets its rules using the AION JSR-94 engine. A working knowledge of the RDL rule helps in understanding the DIA rules. Rules can be written for two reasons: ■ Setting the zone information of Knowledge Bases (the zone rule) ■ Setting the Dynamic Node Administrator ownership (the activation rule) 318 Implementation Guide DIA Configuration The DIA Diagnostic Tool provides the Knowledge Base Rule Editor utility to set the rules. See DIA Diagnostic Tool Help for more information on how to set the entries. Important! Do not edit the ukbrule.xml file manually. Always use the rule editor for any rule modifications. To apply the changes of the rule file, stop and restart the CA DIA 1.3 Knowledge Base service on the Master Knowledge Base where the rule file resides. Note: Once a new rule is inserted by using the DIA Diagnostic Tool, then the DIA services on all the affected DIA systems need to be restarted. Configure Communications for Encryption All host level outbound data communications that include those from DIA components (Dynamic Node Administator or Knowledge Base) are able to use secure sockets. Additionally, all of these communications can be configured to use public and private key encryption to further enhance data transfer security. Note: When a system with DIA is configured to work in an encrypted mode, all other DIA-enabled nodes, including the MasterKB, must be encrypted also before they can communicate with each other. A mixed environment where some nodes are configured to use encryption and some are not is not supported. Appendix A: DIA Reference 319 DIA Configuration All DIA communications, such as grid synchronization, activations, and so forth, are based on Java RMI and by default this information is not encrypted. You can, however, configure DIA communications for encryption with the following procedure. To configure DIA communications for encryption 1. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and stop the Dynamic Node Administrator and Knowledge Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base. Note: It is important to stop the services in this order, Dynamic Node Administrator first and the knowledge base second. The Dynamic Node Administrator and knowledge base services are disabled. 2. Open the Dynamic Node Administrator configuration file (InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set RMI_ENCRYPTION to 1, then save and close the file. The Dynamic Node Administrator is now configured for encryption. All of your Dynamic Node Administrator hosts must be configured in this way. 3. Open the Knowledge Base configuration file (InstallPath\CA\SC\CCS\DIA\dia\ukb\config\ukb.cfg) and set RMI_ENCRYPTION to 1, then save and close the file. Knowledge Bases are now configured for encryption. All Knowledge Bases must be configured in this way. By default, a non-expired encryption key is located at InstallPath\CA\SC\CCS\DIA\dia\config\mykey. You are not required to create a new encryption key. 4. (Optional) If you have an explicit need to create a new encryption key, replace the mykey file with your user key. Use the java utility keytool that comes with the java SDK to generate a new key. The password for the keystore must be "unicenter". The following is an example invocation of the tool to generate the mykey file for a validity period of 360 days: On Windows InstallPath\CA\SC\JRE.ccs\1.5.0_11\bin\keytool -genkey -keypass "unicenter" keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN" On Linux or UNIX /opt/CA/SharedComponents/JRE/1.5.0_11/bin/keytool -genkey -keypass "unicenter" -keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN" The expired default encryption key is now replaced. 320 Implementation Guide DIA Configuration 5. 6. Ensure that the ukb cleanup is done properly. The following files in the ukb/config folder need to be deleted: ■ lgenetable ■ masterqueue (on MKB) ■ masterukbzonelist (on MKB) ■ ukbgridtable ■ ukbinfo.dat ■ gridtable.txt Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and start the Knowledge Base and Dynamic Node Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA. Note: It is important to start the services in this order, the Knowledge Base first and Dynamic Node Administrator second. Start the Dynamic Node Administrator when the Knowledge Base is up and running. Encryption is now enabled. 7. Restart any applications that use DIA such as the Unicenter MCC, Unicenter MP, Unicenter Configuration Manager, Web Reporting Server, Dashboards, Agent Technology, and so forth. The applications establish an encrypted connection to DIA. DIA Configuration in Special Environments DIA supports several different environments, some requiring special configuration and some requiring no additional configuration. The following topics give configuration specifications for special environments in which DIA runs. Configure DIA for Firewalls DIA transparently supports the firewall environment. No special inbound ports need to be opened through the firewall. To configure DIA for this transparent support, you must set up a proxy Unicenter Knowledge Base inside the firewall. The proxy Knowledge Base then manages all outside Dynamic Node Administrator hosts trying to communicate to machines inside the firewall. Appendix A: DIA Reference 321 DIA Configuration To set up a proxy Unicenter Knowledge Base inside the firewall 1. Open the ukb.cfg file in the InstallPath\CA\SC\CCS\DIA\dia\ukb\config folder. 2. Set the PROXY_UKB to "YES" and save the file. A proxy Knowledge Base is now set up inside the firewall. 3. Restart the Knowledge Base and Dynamic Node Administrator services on the system. The changes take effect and a proxy Unicenter Knowledge Base appears inside the firewall. Firewall Environment Configuration Scenarios In the firewall environment, port usage depends on the firewall setup as well as the Knowledge Base position relative to the firewall. The following scenarios show how DIA behaves in specific firewall environments and how you must configure the ports. Agents Reside Outside the Firewall With UKB Proxy Configured If a Unicenter NSM manager resides inside the firewall and the managed nodes (agents, DNA hosts) reside outside the firewall, the managed nodes have to establish DIA connections to the manager inside the firewall. In this case a managed node has no way to register with the manager because all incoming ports are closed on the firewall. Therefore, there is no DIA communication toward the manager. To make this work, the Unicenter NSM manager needs to be set as a Unicenter Knowledge Base Proxy (UKB Proxy). This allows the manager to talk to any DNA hosts outside the firewall. If the Unicenter NSM manager (DNA manager) is a UKB Proxy, the managed nodes (DNA hosts) outside the firewall are able to communicate with the Knowledge Base inside the firewall. With this configuration, for every polling interval that is set in the ukb.cfg file, the UKB Proxy polls the DNA hosts outside the firewall through port 11501. The UKB Proxy knows which hosts are outside the firewall by looking at the list of hosts it manages. Since the communication session is initiated from inside the firewall and is bidirectional, the DNA host outside the firewall is able to respond to the UKB Proxy's requests on the same port, 11501. 322 Implementation Guide DIA Configuration In this scenario of a strict firewall where no inbound ports are open, activation needs to be done from the Unicenter NSM Manager server by using the DIA Tool. To activate agent DNA 1. Launch the DIA Tool by executing Install_Path\CA\SC\CCS\DIA\dia\ukb\bin\diatool.bat in the secured zone which is designated as the UKB proxy. 2. From the menu bar click Deloyment, Activate and follow the instructions on the screen. See also DIA Diagnostic Tool help: Activate Dynamic Node Administrator. The following ports must be outbound enabled: ■ 11501 - Unicenter Knowledge Base Registry Port ■ 11502 - Unicenter Knowledge Base Data Port Appendix A: DIA Reference 323 DIA Configuration Agents Reside Outside the Firewall Without UKB Proxy Configured If you have the previous scenario without a UKB Proxy configured, the following ports must be bidirectional enabled: ■ 11501 - Unicenter Knowledge Base Registry Port ■ 11502 - Unicenter Knowledge Base Data Port UKB Communicates With Another UKB Inside the Firewall If a UKB resides outside the firewall and has to communicate with a UKB inside the firewall, the following ports must be bidirectional enabled: ■ 11501 - Unicenter Knowledge Base Registry Port ■ 11502 - Unicenter Knowledge Base Data Port ■ 11503 - Dynamic Node Administrator Registry Port ■ 11504 - Dynamic Node Administrator Data Port NAT Settings DIA supports the scenario where the Unicenter NSM manager (the DIA Unicenter Knowledge Base) is inside and the the Unicenter NSM agent (the DIA Dynamic Node Administrator component) is outside the NAT environment, as in the following diagram: 324 Implementation Guide DIA Configuration As the diagram illustrates, the Unicenter NSM agents communicate with the manager using the NAT IP address, while the manager communicates with agents directly using their physical, or natural, IP addresses. To apply NAT settings 1. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and stop the Dynamic Node Administrator and Knowledge Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base. Note: It is important to stop the services in this order, Dynamic Node Administrator first and the knowledge base second. The Dynamic Node Administrator and knowledge base services are disabled. 2. Open Dynamic Node Administrator configuration file (InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set ISNAT=YES and NAT_PUBLIC_IP to a NAT public IP, then save and close the file. For example, the NAT public IP in the diagram is 10.20.170.22. 3. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and start the Knowledge Base and Dynamic Node Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA. Note: It is important to start the services in this order, the Knowledge Base first and Dynamic Node Administrator second. Start the Dynamic Node Administrator when the Knowledge Base is up and running. Unicenter NSM agents and the manager server now communicate through a NAT IP address. Appendix A: DIA Reference 325 DIA Configuration HACMP Clusters DIA supports overriding the default local IP address for RMI server binding. You can explicitly specify an address based on your requirements. When you enable an overriding RMI binding, the RMI server binds to the specified IP address only and does not query the local interfaces for possible IP addresses and then bind to them. The overriding RMI binding feature is specific to HACMP clusters where you have a requirement to bind to a specific IP address. This feature should strictly be used for that purpose only. To enable override RMI binding 1. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and stop the Dynamic Node Administrator and Knowledge Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base. Note: It is important to stop the services in this order, Dynamic Node Administrator first and the knowledge base second. The Dynamic Node Administrator and knowledge base services are disabled. 2. Open the Dynamic Node Administrator configuration file (InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg), set overrideRMIBind to yes and RMIBindHost to an explicit IP address (for example, RMIBindHost=192.166.1.226), then save and close the file. 3. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and start the Knowledge Base and Dynamic Node Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA. Note: It is important to start the services in this order, the Knowledge Base first and Dynamic Node Administrator second. Start the Dynamic Node Administrator when the Knowledge Base is up and running. Your HACMP cluster is now set to bind to a specific IP address. OverrideRMIBind cannot be used for multiple network interface controller environments where DIA traffic for one card is enabled and blocked for all others. DIA does not support this function as the intention of OverrideRMIBind is entirely different from this. DMZ Environments When running DIA in a DMZ environment, DIA does not require any special configuration for a normal DMZ. However, DIA does not support cascaded DMZ as of r11.2. 326 Implementation Guide Troubleshooting and Diagnostics Multiple Network Interface Controller Environments When running DIA in a multiple NIC environment, consider the following: ■ DNA should not float from one zone to another. ■ The primary Master Knowledge Base and secondary Master Knowledge Base should be in the same zone. ■ The secondary Master Knowledge Base shows all zones in its DIA Diagnostic Tool. ■ The rule_backup folder should not be part of the Unicenter Knowledge Base or Master Knowledge Base cleanup. ■ If a local Unicenter Knowledge Base is running, the DNA cannot be activated to a different Unicenter Knowledge Base. Troubleshooting and Diagnostics This section discusses common configuration and maintenance problems that can occur in a DIA environment and offers recommended configurations for optimal performance of the DIA components. It also provides troubleshooting techniques related to DIA and its components. Backup for Master Knowledge Base Symptom: Not able to backup the Master Knowledge Base. Solution: DIA supports two Master Knowledge Bases: ■ One primary Master Knowledge Base ■ One secondary Master Knowledge Base The second Master Knowledge Base automatically creates a mirror of the primary Master Knowledge Base in a real time environment. However, if your environment has only one Master Knowledge Base, copy all the files in the ukb\config folder to a backup folder. To solve a problem with the Master Knowledge Base 1. Shutdown the Master Knowledge Base by stopping the Unicenter Knowledge Base service. 2. Replace all the files in the ukb\config folder with the backed up files. 3. Restart Unicenter Knowledge Base service. Appendix A: DIA Reference 327 Troubleshooting and Diagnostics C-Gene Utilities Fail on HP-UX Symptom: The C-Gene utilities fail on HP-UX. Solution: Set the LD_PRELOAD path for the libjvm.sl library. Search for libjvm.sl and use the correct path in the following command: export LD_PRELOAD="/<path>/libjvm.sl" for example: export LD_PRELOAD="/nsmr11.2/CA2/SC/JRE/1.5.0_07/lib/PA_RISC2.0/server/libjvm.sl" Configure Memory Usage for a Cell Symptom: Not able to configure the amount of memory that is used by a cell. Solution: A cell process uses about 8 to 10M memory. Use the <cellname>_InitHeapSize property in the cell.cfg file to configure the memory usage for a cell. DIA Communications Symptom: Not able to route DIA communications through the Unicenter Knowledge Base. Solution: You cannot route all the DIA communications through the Unicenter Knowledge Base. The communication between the DSM and agents use DIA CGene communication and are not routed through the Knowledge Base. 328 Implementation Guide Troubleshooting and Diagnostics DIA Configuration in a Firewall or NAT Environment Symptom: Not able to configure DIA in a firewall or /NAT environment. Solution: To configure DIA in a firewall environment, set up a proxy Knowledge Base inside the firewall. All the Dynamic Node Administrator hosts that communicate with the machines located inside the firewall, must be managed by the proxy Knowledge Base. Note: A Knowledge Base is defined as a proxy, if the PROXY_UKB option is set to "YES" in the ukb.cfg file. You need not open an inbound port through the firewall. To configure DIA in a NAT environment, ensure that NAT is configured to forward packets from one network to another network using the same name. DIA Logs This section explains the logging details provided by DIA for its components, which can be used for troubleshooting. DIA logs are located in the following directory: Windows InstallPath\CA\SC\CCS\DIA\dia\logs Linux or UNIX /opt/CA/SharedComponents/ccs/dia/logs Note: Directory path is valid only if you have used the default location for installation. Appendix A: DIA Reference 329 Troubleshooting and Diagnostics The configuration files you can use to specify the parameters of the different DIA components, include the following. Unicenter Knowledge Base: ukb.cfg that is located at: Windows C:\Program Files\CA\SC\CCS\DIA\dia\ukb\config Linux or UNIX: /opt/CA/SharedComponents/ccs/dia/ukb/config Dynamic Node Administrator: dna.cfg file Cells: cell.cfg file. C-Gene: cgene.cfg file. The Dynamic Node Administrator, cell and cgene configuration files are located at: Windows: C:\Program Files\CA\SC\CCS\DIA\dia\dna\config Linux or UNIX: /opt/CA/SharedComponents/ccs/dia/dna/config The structure of all the configuration files is similar and all the parameters are configurable. Note: We highly recommend that an expert modify these parameters. The parameters related to the logs can be modified by anyone. Based on your requirement, you can configure the logs for the amount and level of information. The level of logging can be changed in the configuration file by modifying the LOG_LEVEL parameter. By default, this is set to SEVERE – which means that only the most important messages would be added to the log files (implying that the amount of information would be minimal). Note: For troubleshooting purpose set the LOG_LEVEL parameter in the configuration file to INFO. This provides sufficient information in the logs to make an intelligent interpretation. 330 Implementation Guide Troubleshooting and Diagnostics For the changes to the configuration file to be effective, do the following: ■ Stop the relevant service ■ Make changes to the configuration file ■ Start the relevant service again. Note: Stop and start the service when the problem is the Dynamic Node Administrator or Knowledge Base. Restart the cell in the case of a specific cell. Clean, delete or backup the existing log files to understand the flow of events (as the log files are appended to the existing ones, it might be difficult to understand the data for troubleshooting). The size of the log file is determined by the LOGFILE_LIMITSIZE parameter in the <component>.cfg file and the default value is 4 MB. After reaching this limit, the file is backed up and a new log file is automatically created. For Example: Assume that ukb0.log is the default log file for the Knowledge Base. If the size of the ukb0.log reaches more than 4MB, the log is saved as ukb1.log and then an empty ukb0.log is used for logging the new data. Subsequently, if the new ukb0.log reaches the 4MB limit, the file is saved as ukb2.log and so on. The number of such saved log files depend on the LOGFILE_COUNT parameter and the default value is 4. Note: You must modify only the LOG_LEVEL parameter. Appendix A: DIA Reference 331 Troubleshooting and Diagnostics Important Log Files This section provides a list of the important log files that you can use for troubleshooting: ukb0.log Contains all the information related to the interactions and requests to the Knowledge Base. The list of informational items contained in the log include the following: ■ Connection Requests to the Unicenter Knowledge Base. ■ Informational transfer with the Dynamic Node Administrators ■ Autoactivate requests from the Dynamic Node Administrator For DIA errors related to the Unicenter MCC, you can see the cause in the javashell.log file created for Unicenter MCC. Then once the main reason is known, you can scan the ukb0.log for the mapped sequence of events. dna0.log Contains the information related to the interactions of the Dynamic Node Administrator with the cells and the owner Knowledge Bases. The list of events for which you might refer to the dna0.log file include the following: ■ Autoactivate requests sent to the Knowledge Base ■ Cell information sent to the Knowledge Base ■ Request for information from the cells ■ Cell registration and deregistration requests cgene0.log Determines where the C-Gene communication information is stored. It provides the information related to the sequence of sends and receives done over different identifiers. dna_launcher0.log Contains the information related to the Dynamic Node Administrator service startup. ukb_launcher0.log Contains the information related to the Knowledge Base. 332 Implementation Guide Troubleshooting and Diagnostics Cell Logs Contains the information related to the cells. The cell name is added to the logs. For example, the AMS cell can contain the following files in the DIA logs directory: ■ caamscell_java0.log ■ caamscell_launcher0.log ■ caamscell_native0.log DIA Maintenance Tasks This section explains the maintenance tasks you can perform related to the following: ■ How to Encrypt the DIA Communication Messages (see page 335) ■ How to Set up WV Registration Server (see page 339) ■ How to Cleanup and Restart DIA (see page 333) ■ How to Activate a New or Modified Policy (see page 333) How to Activate a New or Modified Policy To activate a new or modified policy, restart the Unicenter Knowledge Base service on the Master Knowledge Base. How to Clean Up and Configure DIA Use this process to completely cleanup and configure DIA on a system. To clean up and configure a DIA system 1. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and stop the Dynamic Node Administrator and Knowledge Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base. Note: It is important to stop the services in this order, Dynamic Node Administrator first and the knowledge base second. The Dynamic Node Administrator and knowledge base services are disabled. Appendix A: DIA Reference 333 Troubleshooting and Diagnostics 2. 3. Change to the InstallPath\CA\SC\CCS\DIA\dia\dna\config directory and delete the following files: ■ act.dat ■ recognizerRscTable.dat ■ ukb.dat ■ MDBPushTechEntries.pt If there is no _srv record in your DNS environment, you may want to setup a Master Knowledge Base manually. Open the dna.cfg file in this directory and change the following settings: overrideSRV=yes MasterKB=Master_KB_System_Name Optional: Set a secondary Master Knowledge Base host name to take over responsibility if the Master Knowledge Base is down. SecondaryMasterKB=secondarymasterkbhostname.domain.com Note: Set the secondary Master Knowledge Base only, if there is no domain or DIA SRV record set up. 4. If this system has NSM manager components (WorldView, DSM, EM) installed, then change to the following directory: InstallPath\CA\SC\CCS\DIA\dia\ukb\config 5. Delete all files in this directory except the following: 6. ■ remins.cfg ■ ukb.cfg ■ ukbrule.xml Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and start the Knowledge Base and Dynamic Node Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA. Note: It is important to start the services in this order, the Knowledge Base first and Dynamic Node Administrator second. Start the Dynamic Node Administrator when the Knowledge Base is up and running. 7. Open a command prompt and change to the following directory: InstallPath\CA\SC\CCS\DIA\dia\dna\bin 8. If this is an Agent-Only system, enter the following command: autoactivatedna UKB_host_name 9. If this system has its own local UKB then enter: autoactivatedna 334 Implementation Guide Troubleshooting and Diagnostics 10. Change to the InstallPath\CA\SC\CCS\DIA\dia\dna\config directory and open the ukb.dat file to check if your DNA is owned by the correct Knowledge Base. You should see the name of the Knowledge Base that now owns this DNA. 11. If this system runs World View and the MDB, set up your WV Registration Server. From the command prompt, change to the InstallPath\CA\SC\CCS\WVEM\BIN and run the following command: switchwvregsrvr The DIA cleanup is now complete. How to Encrypt the DIA Communication Messages All host level outbound data communications that include those from DIA components (Dynamic Node Administator or Knowledge Base) are able to use secure sockets. Additionally, all of these communications can be configured to use public and private key encryption to further enhance data transfer security. Note: When a system with DIA is configured to work in an encrypted mode, all other DIA-enabled nodes, including the MasterKB, must be encrypted also before they can communicate with each other. A mixed environment where some nodes are configured to use encryption and some are not is not supported. All DIA communications, such as grid synchronization, activations, and so forth, are based on Java RMI and by default this information is not encrypted. You can, however, configure DIA communications for encryption with the following procedure. To configure DIA communications for encryption 1. Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and stop the Dynamic Node Administrator and Knowledge Base services, CA DIA 1.3 DNA and CA DIA 1.3 Knowledge Base. Note: It is important to stop the services in this order, Dynamic Node Administrator first and the knowledge base second. The Dynamic Node Administrator and knowledge base services are disabled. 2. Open the Dynamic Node Administrator configuration file (InstallPath\CA\SC\CCS\DIA\dia\dna\config\dna.cfg) and set RMI_ENCRYPTION to 1, then save and close the file. The Dynamic Node Administrator is now configured for encryption. All of your Dynamic Node Administrator hosts must be configured in this way. Appendix A: DIA Reference 335 Troubleshooting and Diagnostics 3. Open the Knowledge Base configuration file (InstallPath\CA\SC\CCS\DIA\dia\ukb\config\ukb.cfg) and set RMI_ENCRYPTION to 1, then save and close the file. Knowledge Bases are now configured for encryption. All Knowledge Bases must be configured in this way. By default, a non-expired encryption key is located at InstallPath\CA\SC\CCS\DIA\dia\config\mykey. You are not required to create a new encryption key. 4. (Optional) If you have an explicit need to create a new encryption key, replace the mykey file with your user key. Use the java utility keytool that comes with the java SDK to generate a new key. The password for the keystore must be "unicenter". The following is an example invocation of the tool to generate the mykey file for a validity period of 360 days: On Windows InstallPath\CA\SC\JRE.ccs\1.5.0_11\bin\keytool -genkey -keypass "unicenter" keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN" On Linux or UNIX /opt/CA/SharedComponents/JRE/1.5.0_11/bin/keytool -genkey -keypass "unicenter" -keystore mykey -storepass "unicenter" -validity 360 -dname "CN=Server, OU=BAR, O=Foo, L=Some, ST=Where, C=UN" The expired default encryption key is now replaced. 5. 6. Ensure that the ukb cleanup is done properly. The following files in the ukb/config folder need to be deleted: ■ lgenetable ■ masterqueue (on MKB) ■ masterukbzonelist (on MKB) ■ ukbgridtable ■ ukbinfo.dat ■ gridtable.txt Open the Windows Services user interface (Control Panel, Administrative Tools, Services) and start the Knowledge Base and Dynamic Node Administrator services, CA DIA 1.3 Knowledge Base and CA DIA 1.3 DNA. Note: It is important to start the services in this order, the Knowledge Base first and Dynamic Node Administrator second. Start the Dynamic Node Administrator when the Knowledge Base is up and running. Encryption is now enabled. 336 Implementation Guide Troubleshooting and Diagnostics Restart any applications that use DIA such as the Unicenter MCC, Unicenter MP, Unicenter Configuration Manager, Web Reporting Server, Dashboards, Agent Technology, and so forth. The applications establish an encrypted connection to DIA. How to Move DIA Systems From One Master Knowledge Base to Another The following procedures describe how to move DIA systems from one Master Knowledge Base to another Master Knowledge Base. It depends on the type of the DIA system which of the two procedures is used. Note: If any of these systems being moved is a WRS registration server, then the registration server should be switched first to another system in that zone. To move a DNA system from one Master Knowledge Base to another Master Knowledge Base on Windows 1. Open DIA Diagnostic Tool, right click the DNA system you want to move, and click Remove DNA from Grid. The selected DNA is de-activated and removed from the grid. 2. Stop the DNA service on the system, all Agent Technology services and other CA related agent services that use DIA. 3. Change to Install_Path\SC\CCS\DIA\dia\dna\classes and delete everything except dna.jar. 4. Change to Install_Path\SC\CCS\DIA\dia\dna\lib. Delete everything except dna.dll and nativeConsumer.dll. 5. Change to Install_Path\SC\CCS\DIA\dia\dna\config. Delete ukb.dat, act.dat and recognizerRscTable.dat. 6. Start the DNA service on the system. 7. Change to Install_Path\SC\CCS\DIA\dia\dna\bin and run autoactivatedna.bat with the name of the Unicenter Knowledge Base that is under the new Master Knowledge Base you want to activate to: autoactivatedna.bat kb-name The DNA system is activated again and has been moved to a new Master Knowledge Base. Note: If rules are set appropriately at the Master Knowledge Base for it to be activated to a new Unicenter Knowledge Base, run autoactivatedna.bat without a Unicenter Knowledge Base name. If no rules are set, the system gets activated to a random Unicenter Knowledge Base depending on its availability. Zones are not checked. Appendix A: DIA Reference 337 Troubleshooting and Diagnostics To move a UKB system from one Master Knowledge Base to another Master Knowledge Base on Windows 1. Stop the Unicenter Knowledge Base service on the system. 2. Stop the DNA service on the system. 3. Change the Master Knowledge Base by either updating it in the DNS SRV record for this machine’s domain or in dna.cfg, if it has to be overridden. 4. Change to Install_Path\SC\CCS\DIA\dia\ukb\config and delete all files except ukb.cfg, remins.cfg and ukbrule.xml. 5. Start the Unicenter Knowledge Base service on the system. 6. Start the DNA service on the system. 7. Open DIA Diagnostic Tool for the old Master Knowledge Base. Select this Knowledge Base and right click Remove KB from Grid. The UKB system has been moved to a new Master Knowledge Base. It loses its DNA information related to the old Knowledge Base. Note: It may be necessary to setup the same rules on the new Master Knowledge Base as on the old one. To move a DNA or UKB system from one Master Knowledge Base to another Master Knowledge Base on UNIX or Linux Follow the same procedures on Linux or UNIX platforms from the similar locations. How to Reactivate a DNA System From the DNA system that you want to reactivate perform the following steps: To reactivate a DNA system with a newer or the same version of Unicenter Knowledge Base on Windows 1. Open DIA Diagnostic Tool, right click the DNA system you want to reactivate, and click Remove DNA from Grid. The selected DNA is de-activated and removed from the grid. 2. Stop the DNA service on the system, all Agent Technology services and other CA related agent services that use DIA. 3. Change to Install_Path\SC\CCS\DIA\dia\dna\classes and delete everything except dna.jar. 338 Implementation Guide Troubleshooting and Diagnostics 4. Change to Install_Path\SC\CCS\DIA\dia\dna\lib. Delete everything except dna.dll and nativeConsumer.dll. 5. Change to Install_Path\SC\CCS\DIA\dia\dna\config. Delete ukb.dat, act.dat and recognizerRscTable.dat. 6. Start the DNA service on the system. 7. Change to Install_Path\SC\CCS\DIA\dia\dna\bin and run autoactivatedna.bat with the UKB name you want to activate to: autoactivatedna.bat kb-name The Dynamic Node Administrator is activated. Note: If rules are set appropriately at the Master Knowledge Base for it to be activated to a new Unicenter Knowledge Base, run autoactivatedna.bat without a Unicenter Knowledge Base name. If no rules are set, the system gets activated to a random Unicenter Knowledge Base depending on its availability. Zones are not checked. To reactivate a DNA system with a newer or the same version of Unicenter Knowledge Base on UNIX or Linux Follow the same procedure on Linux or UNIX platforms from the similar locations. How to Set Up WV Registration Server Use this process to set up a WV registration server on a system that has the WV MDB. To set up a WV Registration Server 1. Go to the InstallPath\CA\SC\CCS\WVEM\BIN directory. 2. Run the switchwvregsrvr.bat utility to set up the registration server. 3. Recycle the following services to register them with the new registration server: ■ CA Unicenter ■ CA Remote Monitoring (if installed) ■ CA Unicenter Alert Management System ■ CA Unicenter Network and Systems Management Auxiliary Services ■ CA Web Server 1.0 Appendix A: DIA Reference 339 Troubleshooting and Diagnostics Dynamic Node Administrator and UKB Installation Process Stops Responding Symptom: The Dynamic Node Administrator or Unicenter Knowledge Base installation process stops responding. Solution: Do the following: ■ On a Windows machine, check the following logs: – casetup.log – diasetup.log located in the CCS/NSM install history (for example, InstallPath\CA\CA_APPSW\InstallHistory ) ■ On a Linux machine, check the DIA install logs located in the system tmp folder (e.g.: /tmp) ■ On a Linux machine, you can also check the mount points. The DIA installation process can hang if there are too many mount points, especially when the automount/autofs option is enabled and Unicenter NSM is on an automounted share. To overcome this problem, – Do not have a Unicenter NSM image on a share where other file systems can be automounted. – Disable autofs by using the /etc/init.d/autofsstop command. Dynamic Node Administrator Floated to a Different Knowledge Base Symptom: The Dynamic Node Administrator has floated to a different Knowledge Base and even after the Knowledge Base is autoactivated, it does not show up in DIA Diagnostic Tool. Solution: Use the DIA tool to float the Dynamic Node Administrator back to the Knowledge Base. If this does not resolve the problem, remove the ukb.dat and act.dat files from the dna/config directory and reactivate the node by using the autoactivatedna.bat file. 340 Implementation Guide Troubleshooting and Diagnostics Dynamic Node Administrator Unable to Communicate with Unicenter Knowledge Base Symptom: A Dynamic Node Administrator fails to communicate with the local or the remote Unicenter Knowledge Base when the Knowledge Base is moved to a different subnet. Solution: A Dynamic Node Administrator fails to communicate with the local or remote Knowledge Base due to one of the following probable reasons: ■ The Knowledge Base host name cannot be resolved in the original subnet after it is moved to a new subnet. This might cause communication failure between the Knowledge Base and the Dynamic Node Administrator. To resolve the Knowledge Base host name in the original subnet, do the following: ■ Run the following command from the console from the dna/bin folder. autoactivatedna <knowledgebase IP Address> ■ ■ Specify the new Knowledge Base host IP address during activation DNS does not reflect the new IP address for the Knowledge Base. To ensure that DNS reflects the new IP address for the Knowledge Base, flush the local DNS cache on the DNS system. To flush the local DNS cache, use the following command from the Windows command prompt: ipconfig /flushdns ■ The Knowledge Base owner's IP address is stored in the Dynamic Node Administrator’s ukb.dat file, instead of the host name. In this case, the Dynamic Node Administrator cannot connect to the Knowledge Base, if there is any change in the IP address of the Knowledge Base. ■ If the Dynamic Node Administrator fails to connect to the Knowledge Base, do the following: ■ Remove the act.dat and ukb.dat files from the dna/config folder. ■ Reactivate the Dynamic Node Administrator by running the following command from the console from the dna/bin directory: autoactivatedna <knowledgebase name> Appendix A: DIA Reference 341 Troubleshooting and Diagnostics Float Dynamic Node Administrator to Another UKB Temporarily Symptom: Not able to disable Dynamic Node Administrator floating during Unicenter Knowledge Base shutdown. Solution: To disable Dynamic Node Administrator floating during the Knowledge Base shutdown, add a new entry "preferredukb=null" to ukb.cfg file. This setting ensures that all the managed Dynamic Node Administrators of that Knowledge Base do not float to any other Knowledge Base when the owner Knowledge Base is shut down. To specify a Knowledge Base to which the Dynamic Node Administrators managed by the Knowledge Base server must float when there is a problem add a new entry "preferredukb = <failover UKB-host name>" in the ukb.cfg file. For Example: If you add an entry in the ukb.cfg of host machine1 as: preferredukb = machine2.xx.com, then, if the Knowledge Base service on machine1 either fails or is stopped, the Knowledge Base on machine2 takes over all the Dynamic Node Administrators that are being managed by the Knowledge Base on machine1. The current Knowledge Base stores a list of all the Dynamic Node Administrators that were floated to the preferred Knowledge Base and when the Knowledge Base is restores, it will take back all of those Dynamic Node Administrators. Impact of Master Knowledge Base Crash on DIA Symptom: The Master Knowledge Base has crashed. You do not understand its impact on DIA. Solution: If the Master Knowledge Base crashes, some of the functions like Dynamic Node Administrator activation, zone lookup and grid synchronization fail. Restart the services as soon as possible. 342 Implementation Guide Troubleshooting and Diagnostics Install DIA Without DNS Available Symptom: Working with DIA when DNS is not available. Note: If DNS is available but the DNS SRV record cannot be set, see the topic Install DIA Without an SRV Record Set. Solution: If there is no DNS available in a network, SRV records cannot be configured and system or network names are not resolved to IP addresses. Host names must be mapped to IP addresses in the etc/hosts file on every system in the network. Because DIA requires Fully Qualified Domain Names (FQDN, or host name with domain appendices) to address a system, the FQDN of a system must be the first name in the list in etc/hosts to which an IP address is mapped. 1. Edit the etc/hosts file to make sure the first host name reference for an IP address is the FQDN of the system. For example, entries in etc.hosts should be similar to the following: 172.16.197.114 server.ca.com server serveralias1 serveralias2 2. Follow the instructions in the topic Install DIA Without an SRV Record Set (see page 344). Note: You must configure etc/hosts accordingly on all the systems where DIA is installed. Appendix A: DIA Reference 343 Troubleshooting and Diagnostics There is a new dialog box added in the installer for entering the MKB hostname. This will override the Master Knowledge Base in the DNS SRV records. Install DIA Without an SRV Record Set Symptom: Working with DIA without setting the SRV record. Solution: In the dna.cfg file, specify the Master KB and set the parameter 'overrideSRV' to 'Yes'. 344 Implementation Guide Troubleshooting and Diagnostics Note: You must modify the configuration file in all the systems where DIA is installed. Override the MasterKB name on all these systems by running the updateConfigFile utility under Install_Path\SC\CCS\DIA\dia\dna\bin. If possible, use fully-qualified domain names in dna.cfg. There is a new dialog box added in the installer for entering the MKB hostname. This will override the Master Knowledge Base in the DNS SRV records. Multiple Entries in a Unicenter Knowledge Base in Grid Symptom: Grid displays multiple entries for the same Knowledge Base. While one entry is with the original host name the other entry displays new IP address. Solution: In a DHCP environment, when you restart the system on which Unicenter Knowledge Base is installed, it is possible that the DHCP server assigns a different IP address to the system. It is further possible that the original IP address is still available in the cache and record is not yet updated in the Domain Name Service (DNS). Since the Knowledge Base is not able to resolve the IP address to the host name, the Master Knowledge Base adds the details to the grid, as a new record with the new IP address assuming that it is a new record. To remove the duplicate entries, do one of the following: 1. Refresh the grid to update the local cache. 2. Connect the DIA tool to the Master Knowledge Base or the local Knowledge Base and remove the duplicated IP entry from the grid. Recycle the Knowledge Base after you remove the Knowledge Base. Note: Multiple entries in the grid do not have any impact on the functioning of the DIA tool. Number of Cells Supported by Dynamic Node Administrator or Knowledge Base Symptom: Not able to determine the limit on the number of cells that the Dynamic Node Administrator or Knowledge Base can support. Solution: There is no limit to the number of cells that the Dynamic Node Administrator or Knowledge Base can support. As the cells run in a separate process space, the number of cells that can be supported depends on the system memory. Appendix A: DIA Reference 345 Troubleshooting and Diagnostics Potential Problems with DIA Consumer Applications This section explains the potential problems with the main DIA consumers in the Unicenter Network and Systems Management environment, which include the following: ■ Adaptive Dashboards Server (ADS) ■ Event Cell ■ Management Command Center (Unicenter MCC) ■ Unicenter Management Portal (Unicenter MP) & Web Reporting Services (WRS) ■ Unicenter Remote Monitoring ■ WVObject Cell Adaptive Dashboards Server Adaptive Dashboards Server (ADS) uses DIA for registration and updates. It uses the Unicenter Knowledge Base as the interface to get information from the cells regarding the different enterprise resources that need to be displayed in the dashboards. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition to that, the dsmcell and the agctrlcell must be registered and active to collect the information. Potential Problems: Being a web-based application using Tomcat, the dashboards may not be visible. The first thing to check is whether the Tomcat server is up and running. From the DIA perspective, if the dashboards application is not able to connect to the Knowledge Base, it will not be able to show the latest information. In this case, check the ukb0.log file to determine the exact reason. If Tomcat and the Knowledge Base are both working properly, open the diatool to verify that both the dsmcell and agctrlcell are working properly. If there is a problem you can de-register and then reregister them. The cell-specific logs can also provide a precise cause of the failure. 346 Implementation Guide Troubleshooting and Diagnostics Event Cell The event cell depends on the DNA and the Unicenter Knowledge Base services. It uses both the native and non-native API. The important binary for the Event Cell is the cell registration binary, located at: InstallPath\CA\SC/CCS/WVEM/bin/caamscellreg.exe Potential Problems: The problems you might face with regards to the event cell include the following: ■ Cannot connect to cell ■ No data from cell Verify that the DNA and the owner Unicenter Knowledge Base services are running and ensure that the event cell is enabled. Management Command Center The Unicenter Management Command Center (Unicenter MCC) uses DIA for the correct and timely updates of status and other information that needs to be used and displayed. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition, the amscell, mdbcell and the event cell must be registered and active to collect the information from and send it to the Unicenter MCC. Potential Problems: The Unicenter MCC has various views. The views that are dependent on DIA could have trouble displaying the correct information when the Dynamic Node Administrator or the Knowledge Base services are not running properly.You must ensure that all the required cells are functioning properly. Appendix A: DIA Reference 347 Troubleshooting and Diagnostics Unicenter Management Portal & Web Reporting Services Unicenter MP and Web Reporting Services (WRS) are DIA clients and use it for registration and updates. They use the Unicenter Knowledge Base (local or remote) as the interface to get information from the cells (local or remote) regarding the different enterprise resources that need to be displayed in the dashboards. Pre-requisites: DIA and the Unicenter Knowledge Base must be installed and running locally or on a remote system that can be queried for information. In addition, the following cells are required for gathering the information: ■ wvobjectcell ■ caamscell ■ dsmcell ■ evtcell Potential Problems: Most functionality is unavailable when DIA or the cells are down. No reporting data is displayed. You will see the "unable to retrieve data" messages and other messages that only a System Administrator will be able to understand. Restarting the Unicenter Knowledge Base is probably not possible since it is unlikely the Knowledge Base is local to the Tomcat server. See the ukb0.log file for more details If Tomcat and the Unicenter Knowledge Base are both working properly, open the DIA Diagnostic Tool to verify that both the dsmcell and agctrlcell are working properly. If there is a problem, try deregistering and then reregistering them. The cell-specific logs could also provide precise cause of the failure. Unicenter Remote Monitoring Unicenter Remote Monitoring uses the DIA C-Gene – the communication component of DIA – to communicate between the Administrative Interface and Unicenter Remote Monitoring Agents. Pre-requisites: DIA Dynamic Node Administrator must be installed and running on both the Unicenter Remote Monitoring Agents and the Administrative Interface nodes. Potential Problems: Unicenter Remote Monitoring uses DIA for its communications. If the Dynamic Node Administrator service fails or is stopped on either the agent or the admin node, this communication fails and you get an error message “Communication with the agent failed” 348 Implementation Guide Troubleshooting and Diagnostics You can also get this error message if the Dynamic Node Administrator is running, but it is not activated properly to the Unicenter Knowledge Base. That is, the libraries required for communication have not been pushed to the Dynamic Node Administrator by the owner Knowledge Base. To confirm this, check for the cgeneclient.dll library in the dna/lib directory. If this file is not present, it means that the Dynamic Node Administrator was not activated properly. WVObject Cell The WVObject cell depends on the Dynamic Node Administrator and the Unicenter Knowledge Base. It uses both the native and non-native API. The location of the registration and deregistration batch files are: InstallPath\CA\SC\CCS\WVEM\Bin The registration batch file is regwvcell.bat The deregistration batch file is unregwvcell.bat Potential Problems: Following are problems that a user might face with regards to the WVObject cell: ■ Cannot connect to cell ■ No data from cell To debug the problems related to the WVObject cell, do the following: ■ Check whether the WVObjectcell.exe, Dynamic Node Administrator, and Unicenter Knowledge Base are running. Start them if they are not running. ■ Check whether the Severity Propagation Service and the database are running. Start them if they are not running. Primary Master Knowledge Base is Down Symptom: Primary Master Knowledge Base set for the network is down. Solution: It is mandatory to set a primary and secondary Master Knowledge Base for the network. The secondary Master Knowledge Base automatically takes over if the primary Master Knowledge Base fails. Appendix A: DIA Reference 349 Troubleshooting and Diagnostics Primary and Secondary Master Knowledge Base Communication Symptom: Unable to understand the communication between primary and secondary Master Knowledge Bases. Solution: The secondary Master Knowledge Base periodically interacts with the primary Master Knowledge Base to get the information related to the grid, xml policy and zone table. If the primary Master Knowledge Base is down, the secondary Master Knowledge Base detects it and automatically takes over as the primary Master Knowledge Base. Reconfigure Unicenter Knowledge Base Into Master Knowledge Base Symptom: Unable to reconfigure the Knowledge Base into a Master Knowledge Base. Solution: You can reconfigure the Knowledge Base to act as a Master Knowledge Base by modifying the dna.cfg file. To reconfigure Unicenter Knowledge Base into the Master Knowledge Base, do the following: 1. Connect DIA tool to the local Knowledge Base and remove the Knowledge Base entry from the grid. 2. Stop the Dynamic Node Administrator and Knowledge Base services. 3. Set overrideSRV=yes and MasterKB=<Local Host Fully Qualified Name> in the dna.cfg file. 4. Delete the 'ukbgridtable' table from the \dia\ukb\config folder. 5. Restart the Dynamic Node Administrator and Knowledge Base services. Remove Server from the Network and the Grid in DIA Symptom: A server is removed from the network but you cannot remove it from the grid. Solution: To remove an entry from the grid do one of the following: ■ Uninstall DIA from the server. ■ Use the Remove a Host from the Grid option in DIA tool. 350 Implementation Guide Troubleshooting and Diagnostics Security Concerns with DIA Symptom: Unable to encrypt DIA communications. Solution: All the DIA communications related to grid synchronization, activations and so on are based on Java RMI and by default this information is not encrypted. To encrypt these communications do the following: ■ In the dna.cfg and ukb.cfg configuration files, specify the value for the RMI_ENCRYPTION parameter as 1. That is, RMI_ENCRYPTION = 1 Note: Enable the encryption option for all the Dynamic Node Administrators and Knowledge Bases so that they can communicate with each other. Specific OS Configuration Requirements for DIA Installation Symptom: Not able to configure the system for installing DIA. Solution: DIA is installed as a part of Unicenter NSM and it has the same operating system (OS) or hardware requirements that are required for Unicenter NSM. Ensure that you have the required OS or hardware capability to install DIA. Troubleshooting DIA Components This following topics explain troubleshooting techniques for the following components: ■ Unicenter Knowledge Base (see page 354) ■ Dynamic Node Administrator (see page 352) ■ Cells (see page 352) Appendix A: DIA Reference 351 Troubleshooting and Diagnostics Component Cell Binaries’ Location This section explains the list of cells currently implemented in the Unicenter environment and the location of their registration and de-registration binaries’ (assuming that the installation is under the default path). Agent Control Cell: InstallPath\CA\SC\CCS\AT\CELLS\InstallAgctrlCell.bat DSM Control Cell: InstallPath\CA\SC\CCS\AT\CELLS\InstallDsmCell.bat WV Cell: Registration: InstallPath\CA\SC\CCS\WVEM\BIN\regwvcell.bat Deregistration: InstallPath\CA\SC\CCS\WVEM\BIN\Unregwvcell.bat MDB Cell Registration: InstallPath\CA\SC\CCS\MDBCell\bin\mdbreg.bat Deregistration: InstallPath\CA\SCmponents\CCS\MDBCell\bin\mdbdereg.bat Dynamic Node Administrator The Dynamic Node Administrator runs as a service on all the DIA supported platforms. A Dynamic Node Administrator is the minimum requirement for a system that is DIA enabled. It is not mandatory that a Knowledge Base be local on all the systems. A Dynamic Node Administrator can report to a remote Knowledge Base. On Windows, the service manager has an entry for Dynamic Node Administrator as CA DIA 1.3 DNA. You can manipulate the Dynamic Node Administrator service using the service manager functions. The service spawns two processes internally and they show up as dna.exe and dnasvc.exe in the Windows Task Manager utility. In addition to the service manager, you can handle the Dynamic Node Administrator service from the console with the command line utilities that DIA provides. In an install on the default location, the DNA service utility is located at: InstallPath\CA\SC\CCS\DIA\dia\dna\bin\dnacntl.exe 352 Implementation Guide Troubleshooting and Diagnostics You can start, stop, install, remove and check the status of the service using this command line utility. Use the /? option to get the list of supported options for the utility. On Linux and UNIX platforms, the service structure is similar to that on Windows. If you list the processes, two processes appear that correspond to the Dynamic Node Administrator – dnasvcd and dna. In an install on the default location, the Dynamic Node Administrator service utility is located at: /opt/CA/SharedComponents/ccs/dia/dna/bin/dnacntl You can start, stop, install, remove or check the status of the service using this command line utility. In addition, you can use the Unicenter service controller to manipulate the Dynamic Node Administrator service on Linux or UNIX. The following is an example of the command: unicntrl <option> CA-diadna option can be: start | stop | install | remove | status Activating Dynamic Node Administrator In addition to the service binaries, Dynamic Node Administrator has another important command line utility – autoactivatedna. This command line utility activates the Dynamic Node Administrator to a specified Unicenter Knowledge Base. Use this utility to change or set the current Dynamic Node Administrator’s owner Knowledge Base. On Windows, this binary is located in the following directory (assuming installation in the default location): IntallPath\CA\SC\CCS\DIA\dia\dna\bin\autoactivatedna.bat The following is an example of the command: autoactivatedna.bat kb-name If you do not specify the name of the Knowledge Base in the argument, the system tries to activate the Dynamic Node Administrator to the local Unicenter Knowledge Base. If there is no local Knowledge Base, it will locate the Master Knowledge Base on the network and asks for an activation point. Use this command if you have just setup your Master Knowledge Base system and need to point to it. You can determine what your machines current Dynamic Node Administrator’s owner is by reading the contents of the ukb.dat file (located in CCS\DIA\dia\dna\config). Creation of the ukb.dat file in the mentioned directory can be inferred as successful completion of the autoactivatedna process. A problem with activation results in error “ConnectionRefusedException” Appendix A: DIA Reference 353 Troubleshooting and Diagnostics The most probable reason for this error is that the Knowledge Base that you are trying to activate your Dynamic Node Administrator to, is either down or unreachable. We recommend that you verify these configurations before invoking this utility. Use the DIA tool to verify whether a Knowledge Base is up or down. For Linux and UNIX platforms, the utility invocation and behavior is exactly the same. The utility is located in the directory (assuming default install location): /opt/CA/SharedComponents/ccs/dia/dna/bin The file is autoactivatedna.sh The following is an example of the command: ./autoactivatedna.sh kb-name Following are some of the problems that might occur during installation: ■ After install, the Agent-Only (Dynamic Node Administrator-only) systems are not activated. The main reason for this is that the Master KB is not set. See the DIA Reference Appendix in the Unicenter NSM Implementation Guide for the procedure to set the Master Knowledge Base. ■ In rare cases, on some UNIX systems, you can have situations where the Dynamic Node Administrator or Knowledge Base cannot be stopped and the error message “Error stopping the Service” appears. To recover from this situation, you must manually kill the service daemon (dnasvcd or ukbsvcd) and the associated process (dna or ukb). Unicenter Knowledge Base The Unicenter Knowledge Base runs as a service on all DIA-supported platforms. On Windows, the service manager has an entry for the Knowledge Base as CA DIA 1.3 Knowledge Base. You can manipulate Knowledge Base service using the service manager functions. The service spawns two processes internally and they show up as ukb.exe and ukbsvc.exe in the Windows Task Manager utility. In addition to the service manager, the Knowledge Base service can also be handled from the console with the command line utilities that we provide. In an install on the default location, the Knowledge Base service utility is located at: InstallPath\CA\SC\CCS\DIA\dia\ukb\bin\ukbcntl.exe You can start, stop, install, remove and check the status of the service using this command line utility. Use the /? option to see the list of supported options for the utility. 354 Implementation Guide Troubleshooting and Diagnostics For Linux and UNIX platforms, the service structure is similar to that of Windows. Upon listing the processes, there are two processes that correspond to the Knowledge Base – ukbsvcd and ukb. In an install on the default location, the Knowledge Base service utility is located at: /opt/CA/SharedComponents/ccs/dia/ukb/bin/ukbcntl You can start, stop, install, remove or check the status of the service using this command line utility. In addition, you can use the Unicenter service controller to manipulate the Knowledge Base service on Linux or UNIX. Example: Start, Stop, Install, Remove, or Check Status of the Unicenter Knowledge Base This example lets your start, stop, install, remove, or check status of the CAdiaukb: unicntrl option CA-diaukb option start | stop | install | remove | status Two Zones in DIA Symptom: A machine is shown under two zones in the DIA Diagnostic Tool. Not able to rectify it. Solution: Recycle the Knowledge Base on the machine to refresh the zone name. The problem is rectified automatically. Appendix A: DIA Reference 355 Troubleshooting and Diagnostics Unable to Autoactivate the Dynamic Node Administrator Symptom: Unable to autoactivate the Dynamic Node Administrator. Solution: Do any one of the following: ■ Check the network settings and ensure that you are able to resolve all the host machines by nslookup or pinging. ■ If this is an activation issue related to an agent-only installation, check the SRV record, xml rule file, network settings. ■ Ensure that the target Knowledge Base is up and the Knowledge Base service is running on it. Notes: ■ You can also recycle the Dynamic Node Administrator service to automatically activate the Dynamic Node Administrator. ■ The Dynamic Node Administrator cannot change ownership if it is being managed by a local running UKB. Unable to Deploy Packages Using Package Deployment Infrastructure (PDI) Symptom: Unable to deploy packages using Package Deployment Infrastructure. Solution: The PDI (Package Deployment Infrastructure) cell is not enabled by default. Enable and start the PDI cell when you want to use DIA's package deployment feature. Note: PDI is no longer a supported feature, but still gets packaged with DIA for users who might be using it with earlier releases. 356 Implementation Guide Troubleshooting and Diagnostics Unable to Do an SRV Record Lookup Symptom: Unable to do an SRV record lookup. Solution: Check if SRV records are setup in DNS by using the following command. c:\>nslookup >set type=SRV >_grid._tcp.ca.com <=== their domain where SRV records are setup If SRV records are setup in DNS, you will get the following output: Server: usilsg01.xx.com Address: 141.xxx.x.x DNS request timed out. timeout was 2 seconds. _grid._tcp.xx.com SRV service location: priority = 2 weight = 0 port = 11503 svr hostname _grid._xxx.xx.com = usildiaxxxxxx.xx.com SRV service location: priority = 1 weight = 0 port = 11503 svr hostname = usildxxx.xx.com xx.com nameserver = USILSxxx.xx.com xx.com nameserver = USLISxxx.xx.com xx.com nameserver = USILSxxx.xx.com xx.com nameserver = ASSYSxxx.xx.com xx.com nameserver = UKSLSxxx.xx.com xx.com nameserver = USILSxxx.xx.com xx.com nameserver = INHYSxxx.xx.com usildiaxxxxxx.xx.com internet address = 141.202.xxx.xxx usildxxx.xx.com internet address = 141.202.xxx.xxx USILSxxx.xx.com internet address = 141.202.xx.xxx USLISxxx.xx.com internet address = 130.200.xx.xxx USILSxxx.xx.com internet address = 141.202.x.xxx ASSYSxxx.xx.com internet address = 155.35.xx.xxx UKSLSxxx.xx.com internet address = 130.119.xx.xxx USILSxxx.xx.com internet address = 141.202.x.xx INHYSxxx.xx.com internet address = 155.35.xx.xxx If you do not get the above response, then it implies that the SRV record setting is not correct. See the section DIA Configuration for details about setting up the SRV records. Appendix A: DIA Reference 357 Troubleshooting and Diagnostics Note: If the machine is setup using static IP make sure domain is defined in "DNS suffix for this connection: This is defined under the DNS tab in "Advance TCP/IP Settings". If you don't do this, you will get something like "unable to find domain or failed to lookup SRV record ..." in the ukb0.log file. When executing the ipconfig command, "Connection-specific DNS Suffix" field should not be empty. If the machine is setup using DHCP, you don't need to set this because the domain of the machine info is already stored somewhere on the system. Unable to Open DIA Tool Symptom: The correct user name and password is given but the DIA tool is unable to open successfully. Solution: Do one of the following: ■ Verify whether the system to which you are trying to connect has DIA, and more importantly that a Unicenter Knowledge Base is installed. ■ If the first point is yes, verify whether the Unicenter Knowledge Base service is running on that system. If either of these scenarios is true, you will not be able to open the DIA tool successfully and would get the message “Unable to Connect to system-name” appears. Also, the console window that opens up with the DIA tool shows the entire error trace. This indicates you should verify these two solution points. Unicenter Knowledge Base Failure in Firewall Scenario Symptom In a firewall scenario, Unicenter Knowledge Base does not automatically take over another Knowledge Base. You do not understand its impact on consumer applications. Solution: You need extra configuration for one Knowledge Base to automatically take over another Knowledge Base in a firewall scenario. If the Knowledge Base that is located either inside or outside the firewall belongs to same zone, then you can route the request from a consumer application that is running inside the firewall to an external Knowledge Base. If the proxy Unicenter Knowledge Base fails, the C-Gene communications and the request and response mechanisms of the Knowledge Base do not work. 358 Implementation Guide Troubleshooting and Diagnostics Utilities to Assist Troubleshooting DIA The topics that follow list utilities that will help you troubleshoot DIA and collect additional information to aid your troubleshooting. Diacontrol Utility The diacontrol utility located in the dia\ukb\bin folder is intended to find, and in some cases fix, inconsistencies in the DIA grid. The DIA grid consists of a number of Unicenter Knowledge Bases (UKBs) installed on Unicenter NSM manager nodes and a large number of Dynamic Node Administrators (DNAs), installed on NSM agent nodes. Each DNA is activated and managed by one of the UKBs, its owner UKB. A designated Master Knowledge Base, which is also a fully functional UKB, maintains information about all DIA installations in the grid and provides this information to all other UKBs. The DIA grid can be divided into different zones with only the Master Knowledge Base having knowledge about all zones, but all other DIA installations having knowledge only about other DIA nodes that are in the zone assigned to them. DNA Ownership and Floating Ideally each DNA node is managed by one UKB node, the node by which it was activated. The initial activation of a DNA node by a UKB causes the UKB to add the DNA node to a list of original DNAs. DIA communication between DNA nodes, or between a DNA and a UKB, typically runs through the owner UKB, which forwards the data or request to the target UKB, or the owner of the target DNA. To avoid loss of communication with all managed nodes, a UKB on shutdown floats the DNAs it manages to another UKB node, which can either be specified with the preferredukb parameter in the ukb.cfg file or which is chosen from a list of other UKB nodes in the same zone. The remote UKB that takes over the DNAs adds them to a list of floating DNAs. On startup, the UKB attempts to take back ownership of its original DNAs. It also goes through the list of floating DNAs it had managed prior to shutdown and resume managing those that are not currently managed by another UKB. Appendix A: DIA Reference 359 Troubleshooting and Diagnostics DIA Grid Problems Targeted by This Utility DIA does not have an expiration date on grid membership. A node is removed from the grid on DIA uninstall, but this requires the node to be connected to the DIA grid during uninstall. Removing a host without uninstalling DIA while connected to the DIA grid may cause stale entries in the grid. The Diatool User Interface provides an option to float DNAs from one UKB to another, permanently changing original ownership. Sometimes there are problems with selected DNA installations that require manual reactivations, often involving a cleanup of local activation files. In such cases the DNA node is added to the original DNA list of the new owner UKB without being removed from the list on the previous owner. This may or may not be visible in the DIA grid as displayed by the Diatool. This utility cannot distinguish between original DNAs and floating DNAs. DIA nodes may be moved into another zone, or moved into another grid managed by a different Master Knowledge Base. If this is done without going through an uninstall while connected to the old grid, the node may remain in the old grid, and a node with the UKB service installed may continue to be chosen by the Master Knowledge Base as owner of a new DNA installation in the old grid. 360 Implementation Guide Troubleshooting and Diagnostics Diacontrol Usage Diacontrol implements the following commands to find or correct problems: Syntax: diacontrol UKB-host testconnect Attempts a connection to the specified UKB host and reports success or failure. In case of a failure, errors or exceptions can be found in the file diacontrol.err in the current directory. diacontrol UKB-host list alldnas Lists original, first all and then those currently managed, and all floated DNAs for the specified UKB host. A DNA node that is down and not managed by another UKB may be included in the currently managed list. This would not be regarded as a problem. However, a node should not be listed as currently managed in two different UKBs though. diacontrol UKB-host list origdnas [all] Lists all original DNAs for the specified UKB host. These DNAs should be managed by this UKB, which is possibly not the case. diacontrol UKB-host list origdnas owned Lists all original DNAs that are currently owned (managed) by the specified UKB host. diacontrol UKB-host list origdnas other Lists all original DNAs that are currently not owned (managed) by the specified UKB host. diacontrol UKB-host list floatdnas Lists all DNAs currently owned by the specified UKB host, but that are not registered in the original DNA list. These DNAs were floated over from other UKBs. This list should only contain nodes that are in the original DNA list of UKBs and that are currently down. diacontrol UKB-host list dnaowner DNA-host Lists the owner UKB information for the specified DNA host as found by the specified UKB host. This command is intended to check on grid consistencies. It should return the same information for any UKB host in the grid. diacontrol UKB-host list zonelist Appendix A: DIA Reference 361 Troubleshooting and Diagnostics Lists the ukbzonelist on the specified UKB host. For a regular UKB this command lists all UKBs in the same DIA zone. If the UKB host is the active Master Knowledge Base, it lists all UKBs in the DIA grid, and the zone each UKB belongs to. diacontrol MasterKB-host list ukbs zone Lists all UKB hosts in the specified zone. The specified MasterKB host needs to be the active Master Knowledge Base. The zone parameter is case sensitive and the default DIA zone is "Default". Important! Use the following commands with caution. diacontrol UKB-host remove origdna DNA-host Removes a stale DNA host entry from the original DNA list of the UKB host. This command may be used to remove an incorrect entry, such as duplicate entries or entries of installations that are known to no longer exist, as identified by one of the list commands described above. Use with caution. diacontrol UKB-host remove floatdna DNA-host Removes a stale DNA host entry from the floated DNA list of the specified UKB host (similar to the previous command). Use with caution. diacontrol UKB-host remove ukb UKB-host-to-remove Removes a UKB host entry from the zone table on the specified UKB host. This command can be used to remove a stale entry from the local ukbzonelist, or the masterukbzonelist on the Master Knowledge Base. It will not remove this UKB from the DIA grid. Use the diatool to remove UKBs that are currently found in the grid. Use with caution. DIA Environment Checks The following commands can be used to check if DIA works as expected: ■ Send a ping from a manager system to an agent system and conversely. ■ Perform nslookup from manager to agent and conversely ■ Run telnet on a manager system and connect to an agent system by using port 11501. ■ Run telnet on an agent system and connect to a manager system by using port 11503. ■ Send a ping from an agent system and from a manager system to the master. ■ Run telnet on an agent system and on a manager system and connect to the master by using port 11503. 362 Implementation Guide Troubleshooting and Diagnostics Dynamic Node Administrator-Related Utilities The following utilities are available with the Dynamic Node Administrator: GetRegisteredCells Use the GetRegisteredCells utility to get a list of registered cells on a particular Dynamic Node Administrator. Syntax: GetRegisteredCells.bat DNA_Host_Name|IP_Address DNA_Host_Name|IP_Address Specifies the name of the Dynamic Node Administrator host or its IP address for which you want to see the list of cells. Note: The utility returns only the external cell list; for example, the Unicenter NSM cells are all external cells and cells such as pdicell are DIA internal cells. The files used to run the utility are GetRegisteredCells.bat (Windows) or GetRegisteredCells.sh (Linux/UNIX). GetCellInfo Use the GetCellInfo utility to get cell information from a particular Dynamic Node Administrator. Syntax: GetCellInfo.bat DNA_Host_Name|IP_Address Cell_Name DNA_Host_Name|IP_Address Specifies the name of the Dynamic Node Administrator host or its IP address for which you want to see the cell information. Cell_Name Specifies the name of the cell about which you want to get information. Note: The utility returns information about external cells only; for example, the Unicenter NSM cells are all external cells and cells such as pdicell are DIA internal cells. The files used to run the utility are GetCellInfo.bat (Windows) or GetCellInfo.sh (Linux/UNIX). Appendix A: DIA Reference 363 Troubleshooting and Diagnostics setLogLevel Use the setLogLevel utility to set the logging level of a particular Dynamic Node Administrator or UKB. Syntax: setLogLevel dna|ukb|cgene hostname loglevel dna|ukb|cgene Specifies whether the logging level is to be set for a Dynamic Node Administrator, a Knowledge Base, or a cgene. hostname Specifies the host name of the Dynamic Node Administrator or Knowledge Base host for which you want to change the logging level. loglevel Specifies the logging level you want to set. Valid values are OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, or ALL. Note: The utility changes the logging level in process. It is not necessary to restart the Dynamic Node Administrator or Knowledge Base to make the change effective. The log level set by the setLogLevel utility is applied at runtime. The log level in configuration files is applied at the time of startup only. updateConfigFile This utility is used for changing the configuration files of UKB, DNA, cell, or cgene on DIA systems. Syntax: updateConfigFile.bat hosts_file_name config_file_name property_name property_value hosts_file_name Specifies the file name that stores the host names or IP addresses of the UKBs and DNAs on which the configuration information is going to be changed. 364 Implementation Guide Troubleshooting and Diagnostics config_file_name Specifies the name of the configuration file in which the configuration information is going to be changed; for example, UKB, DNA, cell, or cgene. property_name Specifies the name of the property that needs to be changed. property_value Specifies the new value of the property. Note: The LOG property is updated during runtime but not in the configuration files. For all other properties a restart of the service is required. Knowledge Base-Related Utilities The following utilities are available with the Unicenter Knowledge Base: getMasterKB Use the getMasterKB utility to get the Master KB of the specified doc. Syntax: getMasterKB.bat KB Host Name/IP KB Host Name/IP Specifies the Knowledge Base host for which you want to get the Master KB. The files used to run the utility are getMasterKB.bat (Windows) or getMasterKB.sh (Linux/UNIX). getOwnerKB Use the getOwnerKB utility to get the Knowledge Base owner of a given Dynamic Node Administrator host. Syntax: getOwnerKB.bat DNA Host Name/IP DNA Host Name/IP Specifies the Dynamic Node Administrator host for which you want to get the Knowledge Base owner. The files used to run the utility are getOwnerUKB.bat (Windows) or getOwnerUKB.sh (lLinux/UNIX). Appendix A: DIA Reference 365 Troubleshooting and Diagnostics getSRVInfo Use the getSRVInfo utility to get the SRV records of the domain. Syntax: getSRVInfo.bat domain name domain name Specifies the current domain name. Specifying the domain name is optional for Linux or UNIX if the domain name entry is present in the /etc/resolve.conf file. The files used to run the utility are getSRVInfo.bat (Windows) or getSRVInfo.sh (Linux/UNIX). refreshZone Use the refreshZone utility to reload the Master Knowledge Base rule file, refresh the zone or grid, or reset the zone. Syntax: refreshzone.bat kb|zone|reset mode_value kb|zone|reset Specifies the mode the utility is to use. The kb mode reloads the rule file of the Master Knowledge Base or synchronizes grid and zone information of a Knowledge Base with the Master Knowledge Base. The zone mode contacts all Knowledge Bases in the zone to synchronize zone and grid information with the Master Knowledge Base. The reset mode is used primarily when the zone of a Knowledge Base changes and there is still a stale entry in the old zone. The reset mode takes time to run if there are many Knowledge Bases in the old and new zones. The process notifies every Knowledge Base in the old zone to remove the stale Knowledge Base entry. 366 Implementation Guide Troubleshooting and Diagnostics mode_value Specifies the Knowledge Base name or zone name on which to take action. If you specify the kb mode, the mode_value should be the name or IP Address of the Knowledge Base. If you specify the Master Knowledge Base name, the utility reloads the rule file. If you specify the regular Knowledge Base name, the grid and zone information of the Knowledge Base is synchronized with the Master Knowledge Base. If you specify the zone mode, the mode_value should be the zone name you want to reset and the utility contacts every Knowledge Base in the zone you specify to synchronize the zone and grid of each Knowledge Base with the Master Knowledge Base. If you specify the reset mode, the mode_value should be the name of the Knowledge Base that still has an entry in the old zone. The files used to run the utility are refreshZone.bat (Windows) or refreshZone.sh (Linux/UNIX). getZone Use the getZone utility to get the Knowledge Base zone name from the Master Knowledge Base according to the rules set for it. Syntax: getzone.bat MasterKB Host_Name|IP MasterKB Specifies the name of the Master Knowledge Base. Host Name/IP Specifies the Knowledge Base host for which you want to get the zoning information. The files used to run the utility are getZone.bat (Windows) or getZone.sh (Linux/UNIX). Appendix A: DIA Reference 367 Troubleshooting and Diagnostics Examples: Synchronize Zone and Grid Information for Knowledge Bases ■ This example for Linux/UNIX synchronizes the zone and grid information of knowledgebase1 with the Master Knowledge Base: refreshZone.sh kb knowledgebase1 ■ This example for Windows synchronizes the zone and grid information of all Knowledge Bases in zone1 with the MasterKB. refreshZone.bat zone zone1 ■ This example for Linux/UNIX notifies all Knowledge Bases in a zone when the zone of a Knowledge Base changes. refreshZone.sh reset knowledgebase2 368 Implementation Guide Appendix B: Making Components Cluster Aware and Highly Available This section contains the following topics: Cluster Aware and High Availability Introduction (see page 369) CA High Availability Service (see page 369) Failover and Failback (see page 370) Resource Groups (see page 371) Unicenter NSM Highly Available Components (see page 374) How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) (see page 375) How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) (see page 377) How You Install, Reinstall, or Uninstall Unicenter NSM Components (see page 379) How WorldView Becomes Cluster Aware (see page 380) How Event Management Becomes Cluster Aware (see page 380) How AEC Becomes Cluster Aware (see page 383) How Alert Management Becomes Cluster Aware (see page 384) Cluster-Aware Agent Technology (see page 386) Cluster Aware and High Availability Introduction As organizations continue to conduct business in a global economy, it has become increasingly important to meet the exacting computing capabilities such an environment demands. More and more organizations are employing clustering technology and demand the high availability of resources in the wake of component failures in the system. To meet these demands, the CA High Availability Service (HAS) is provided as part of CA Common Services and Unicenter NSM to support fault tolerant functionality when Unicenter NSM is running in a cluster environment. CA High Availability Service HAS makes Unicenter NSM components highly available, promoting minimal down time and using resources optimally to ensure that your enterprise is continuously monitored and managed. Using cluster technology, HAS makes Unicenter NSM components cluster aware, providing high availability of service and maximizing the performance and value of your enterprise. Appendix B: Making Components Cluster Aware and Highly Available 369 Failover and Failback Using HAS, applications are automatically registered, which lets them receive status and notifications. Once registered, an application can be failed over (migrated) to another node on the cluster, ensuring continuous service. HAS supports the following vendor clusters: ■ Microsoft Cluster Service (MSCS) ■ Linux Red Hat Cluster Manager Note: The MDB does not support cluster failover using Red Hat Cluster. ■ Sun Cluster (Solaris) ■ VERITAS Cluster Server (Sun Solaris) ■ Hewlett Packard Multi-Computer/Service Guard (MC/SG) ■ IBM High Availability Cluster Multiprocessing for AIX (HACMP) Important! If you are installing UNIX agents into a cluster environment and want to enable HAS, go to http://supportconnect.ca.com/sc/support/Index for details. Note: Unicenter NSM r11 and r11.1 do not support an upgrade of the CA High Availability Service if you have an existing HAS 3.1 product installed on the computer. See the Migration Guide at http://ca.com/support for additional information. Failover and Failback Cluster technology enables failover and failback operations. Failover is an important fault-tolerant function of mission-critical systems that demand constant availability. Failover is a backup operation in which the functions of a system component (such as a processor, server, network, or database) automatically and transparently switch to secondary system components when the primary component becomes unavailable through either failure or scheduled down time. Failback is the process of migrating a failed application back to its original node to rebalance workloads when a previously failed component is available again. Typically, failover—the switch from a primary system to a backup system—is configured to perform automatically, while failback is a manual task. The manual task ensures that the problem is properly identified and corrected before functionality is returned to the original component. 370 Implementation Guide Resource Groups Resource Groups A common characteristic of a clustering solution is the concept of resource groups. A resource group is the logical entity that combines all of the resources required to make a service or application highly available. Resources can include physical hardware devices, such as disk drives and network cards, or logical entities, such as logical disk volumes, TCP/IP addresses, entire applications, and databases. Note: An HP-UX package corresponds to a HAS resource group. An HP-UX service corresponds to a HAS resource. Resource Groups on Linux Platforms In most cluster implementations, resources are distinct from resource groups. On Linux platforms, no explicit definition for resources exists. In other words, in Red Hat Cluster Manager, a one-to-one mapping between resources and resource groups exists. You can distinguish resources from resource groups by correctly using the service control script. If a service has five distinct applications, each can be viewed as a resource. You can use the control script to start, stop, and get the status of these applications separately, but report the results to the cluster as one return code. For example, if a Unicenter NSM resource group contained CAICCI, Event Management, and an agent, you could use the control script to start, stop, and get the status of these resources as a whole. These resources would then migrate together as a resource group when a failover occurs. Cluster Configuration Clusters are groups of computers that function together as a single entity for the purpose of parallel processing, load balancing, and fault tolerance. Using cluster technology increases the reliability and availability of a computer system. It keeps applications highly available by providing failover capabilities. The system is no longer dependant on a single server. The cluster software attempts to make the environment on each of the different computers appear uniform for the applications that run on them. Appendix B: Making Components Cluster Aware and Highly Available 371 Resource Groups The combination of shared resources and uniform runtime environments enables an application to migrate efficiently from one computer to another. The application can save its information to shared storage, shut down, and then start up on a different computer in the cluster. When clusters are used, an enterprise is protected from the costly effects of downtime. A system that is clustered promotes the availability of all shared resources should a system outage occur. In addition, clustering technology lets you add small, standard systems incrementally, instead of having to commit to high-end servers. The two types of cluster configurations supported by HAS are as follows: Active/Passive Cluster Configuration An active/passive configuration allows you to have a single instance of a fault tolerant component running on one of the physical servers in the cluster. The other nodes in the cluster are in standby mode until a failure on the active node or a manual failover during maintenance occurs. Active/Active Cluster Configuration An active/active configuration allows you to have multiple instances of a fault tolerant component running on both nodes of a two-way cluster. If one of the instances in the cluster fails, the failed instance automatically fails over to the other server. Shared Disk Support During the installation of Unicenter NSM in a cluster environment, several components that install in HA mode store their data files on the Shared Disk configured in the cluster. CA-HAS supports the following Disk and Storage resource types available on a MSCS cluster: The cluster software attempts to make the environment on each of the different computers appear uniform for the applications that run on them. Physical Disk The default Resource Type available on MSCS. Volume Manager Disk Group The Disk Group Resource available with the Veritas HA Software Foundation option installed on MSCS. IBM ServeRAID Logical Disk The Disk Resource Type available when the IBM ServeRAID NT Cluster Solution utility is installed on MSCS. Note: the Quorum Disk is not considered a valid shared disk for this purpose. 372 Implementation Guide Resource Groups HAS Architecture HAS includes a set of extensions to Unicenter NSM that provide fault-tolerant functionality when running Unicenter NSM in a cluster environment. When a Unicenter NSM component is installed, the installation checks for the existence of the HAS service on Windows, or the HAS daemon on UNIX/Linux. If this service or daemon exists, the Unicenter NSM component registers with HAS and installs what it needs to be highly available. The HAS service or daemon, which runs on all cluster nodes, acts as the middleman between the cluster and the Unicenter NSM components. The HAS service or daemon monitors the cluster, and provides notifications when resource groups change state. The Cluster Service Layer (CSL) insulates Unicenter NSM from cluster complexities and thus, makes Unicenter NSM components independent of any specific vendor clusters. Unicenter NSM components communicate to HAS using the CSL. Appendix B: Making Components Cluster Aware and Highly Available 373 Unicenter NSM Highly Available Components Unicenter NSM Highly Available Components The following Unicenter NSM components can be made cluster-aware and highly available: Event Management Event Management records, correlates, processes, and presents the events that occur within the enterprise. Event Management is typically the backbone of any enterprise management system and, therefore, it is essential that it be both cluster-aware and highly available within a clustered environment. Note: Event Management is not highly available on Linux platforms. Advanced Event Correlation Advanced Event Correlation (AEC) acts as a front end filter to the Event Management system, providing correlation, root cause, and impact analysis for the events being received. Event Management is fully cluster aware, and, therefore, it is essential that AEC is also fault tolerant to the same degree to ensure event processing continuity and quality is maintained from the point of failure. Note: Since Event Management is not highly available on Linux platforms, AEC is not highly available on Linux platforms. Agent Technology Agent Technology lets you closely monitor the critical computing resources in your enterprise by configuring individual agents to instrument these resources. Agent Technology uses agents throughout the enterprise to collect data, such as information on file systems, databases, and memory usage. This data is distributed to one or more management nodes or DSMs that interpret the data and take action based on custom configurations. Cluster-aware agents use HAS to operate within a cluster environment and to continue monitoring critical resources even in failover situations. Alert Management Alert Management is atool for organizing and tracking the most important events in an enterprise or logical segment of an enterprise. It lets you focus on and manage the hisghest severity IT events. Alert Management is fully cluster aware and highly available in a clustered environment. Note: Alert Management isnot highly available on Linux or UNIX platforms. WorldView WorldView offers a highly visual and intuitive approach to enterprise management with the 2D Map available through the Management Command Center, the Unicenter Browser Interface, and the WorldView Classic GUI. 374 Implementation Guide How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) HAS makes Unicenter NSM components highly available, promoting minimal down time and using resources optimally to ensure that your enterprise is continuously monitored and managed. To set up Unicenter NSM to be highly available, do the following: 1. Install cluster software on each computer in the cluster. 2. Set up a Unicenter NSM resource group on the cluster that contains, at a minimum, the following resources: ■ Virtual IP ■ Virtual network name ■ A shared disk Important! The Quorum Disk cannot be listed as a valid shared disk. Also, there must be only ONE virtual IP and virtual network name in the resource group. 3. On the first node in the cluster, install Unicenter NSM and all the components you want to use. HAS is installed automatically as part of CA Common Services or Unicenter NSM on a clustered computer where cluster software is present. For example, on Windows, HAS is installed on a computer where Microsoft Cluster Service is running, and on Linux, HAS is installed on a computer where Red Hat Cluster Manager is running. Note: Before installing Unicenter NSM cluster-aware agents, check the following on each cluster node: ■ Verify that the native cluster service/daemon is running. ■ Verify that the servers and cluster are set up properly by forcing the resource groups to fail over and by connecting a client. ■ Verify that SNMP is running correctly. Important! To ensure that HAS works across the nodes of your cluster, you must run HAS under a cluster domain account on Windows and as the root user on UNIX/Linux. HAS detects that the computer is in a cluster and a dialog box appears that lists all of the resource groups in the cluster. 4. Select the Unicenter NSM resource group. Depending on the components you installed, one or more of the following Unicenter NSM resources are added to the resource group: ■ Ingres Service Appendix B: Making Components Cluster Aware and Highly Available 375 How You Set Up Unicenter NSM to be Highly Available (Ingres Databases) ■ CA-Unicenter Service ■ WorldView Severity Propagation Service ■ "UNISHARE$" file share Since all of Unicenter NSM resources belong to one resource group, all of Unicenter NSM fails over at the same time. Note: Since these Unicenter NSM resources are to be managed by the cluster administrator, during the install you may notice that the option to autostart these services is disabled. In addition, Security Management is unavailable in a highly available install. 5. After the installation completes on the first node, perform the following tasks: a. Take the Unicenter NSM resources offline. b. Move the Unicenter NSM resource group over to a subsequent node in the cluster that does not yet have Unicenter NSM installed on it. 6. Be sure the cluster resources (virtual IP, network name, and shared disk) are still online. 7. On all subsequent nodes in the cluster, install Unicenter NSM and the same components you installed on the first node. HAS is installed automatically. 8. After the installation completes on each subsequent node, perform the following tasks: a. Take the Unicenter NSM resources offline. b. Move the Unicenter NSM resource group over to a subsequent node in the cluster that does not yet have Unicenter NSM installed on it. The resource group must be present on the node before you can install Unicenter NSM. Note: If this is the last node in the cluster, you do not need to move the resource group. 9. After Unicenter NSM has been installed on all nodes in the cluster, bring the Unicenter NSM resources online. Unicenter NSM is now running in a highly available mode. Note: If you install CA Common Service on a standalone computer and then add the computer to a cluster, the HAS service or daemon does not start automatically. You must manually start the HAS service/daemon or restart the computer. 376 Implementation Guide How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) HAS makes Unicenter NSM components highly available, promoting minimal down time and using resources optimally to ensure that your enterprise is continuously monitored and managed. To set up Unicenter NSM to be highly available, do the following: 1. Install cluster software on each computer in the cluster. 2. Select one instance of a Microsoft SQL Server cluster resource group to use for Unicenter NSM. HAS will use the related network name and IP address as set up from the Microsoft SQL Server installation. Note: In the steps that follow, "Unicenter NSM resource group" refers to the Microsoft SQL Server cluster resource group that you are using for Unicenter NSM. Important! In the Microsoft SQL Server cluster resource group, there must be only ONE virtual IP and virtual network name. Unicenter NSM will not install in HA mode if more than one virtual IP or network name is defined in the same resource group. 3. On the first node in the cluster, install Unicenter NSM and all the components you want to use. HAS is installed automatically as part of CA Common Services or Unicenter NSM on a clustered computer where cluster software is present. For example, on Windows, HAS is installed on a computer where Microsoft Cluster Service is running. Note: Before installing Unicenter NSM cluster-aware agents, check the following on each cluster node: ■ Verify that the native cluster service/daemon is running. ■ Verify that the servers and cluster are set up properly by forcing the resource groups to fail over and by connecting a client. ■ Verify that SNMP is running correctly. Important! To ensure that HAS works across the nodes of your cluster, you must run HAS under a cluster domain account on Windows. HAS detects that the computer is in a cluster and a dialog box appears that lists all of the resource groups in the cluster. 4. Select the Unicenter NSM resource group. Depending on the components you installed, one or more of the following Unicenter NSM resources are added to the resource group: ■ CA-Unicenter Service Appendix B: Making Components Cluster Aware and Highly Available 377 How You Set Up Unicenter NSM to be Highly Available (Microsoft SQL Server Databases) ■ WorldView Severity Propagation Service ■ "UNISHARE$" file share Since all of Unicenter NSM resources belong to one resource group, all of Unicenter NSM fails over at the same time. Note: Since these Unicenter NSM resources are to be managed by the cluster administrator, during the install you may notice that the option to autostart these services is disabled. In addition, Security Management is unavailable in a highly available install. 5. After installation of a WorldView Manager on a node in the HAS cluster environment, if the WorldView Manager installation requires a shutdown and restart, after shutdown and restart, you must run the following command to ensure the WorldView Object Cell (wvobjectcell.exe) is not running before you can install the WorldView Manager on other cluster nodes: wvcellservice.exe 2 Note: If the WorldView Manager installation does not require a reboot then no other action is required. 6. After the installation completes on the first node, perform the following tasks: a. Take the Unicenter NSM resources offline. b. Move the Unicenter NSM resource group over to a subsequent node in the cluster that does not yet have Unicenter NSM installed on it. 7. Be sure the cluster resources (virtual IP, network name, and shared disk) are still online. 8. On all subsequent nodes in the cluster, install Unicenter NSM and the same components you installed on the first node. Important! If a WorldView Manager installation requires a shutdown and restart, perform Step 5 on each node in the cluster. HAS is installed automatically. 9. After the installation completes on each subsequent node, perform the following tasks: a. Take the Unicenter NSM resources offline. b. Move the Unicenter NSM resource group over to a subsequent node in the cluster that does not yet have Unicenter NSM installed on it. The resource group must be present on the node before you can install Unicenter NSM. Note: If this is the last node in the cluster, you do not need to move the resource group. 10. After Unicenter NSM has been installed on all nodes in the cluster, bring the Unicenter NSM resources online. 378 Implementation Guide How You Install, Reinstall, or Uninstall Unicenter NSM Components Unicenter NSM is now running in a highly available mode. Important! If you need to recreate the WorldView class hierarchy using the Create Repository (maketng.exe) utility, you must ensure that the WorldView Object Cell (wvobjectcell.exe) is not running on any of the other nodes except the active node. If it is running on any node other than the active node, stop it using the “wvcellservice.exe 2” command. After all of the WorldView Object Cells (wvobjectcell.exe) are stopped on all the non-active nodes, you can run the Create Repository (maketng.exe) utility to recreate the WorldView class hierarchy. Note: If you install CA Common Service on a standalone computer and then add the computer to a cluster, the HAS service or daemon does not start automatically. You must manually start the HAS service/daemon or restart the computer. How You Install, Reinstall, or Uninstall Unicenter NSM Components You must take all Unicenter resources (CA WorldView Severity Propagation Service, CA-Unicenter) offline before taking any of the following actions: ■ Reinstalling Unicenter NSM ■ Installing any Unicenter NSM option or component after Unicenter NSM is installed ■ Installing any product that integrates with Unicenter NSM (for example Systems Performance Option) ■ Uninstalling Unicenter NSM Use the Cluster Administrator tool that is available in Windows to take the Unicenter resources offline. Do not use the Service Control Manager to take any of the Unicenter resources offline. Only use the Service Control Manager to shut down services that are not registered cluster resources, such as Agent Technology. Appendix B: Making Components Cluster Aware and Highly Available 379 How WorldView Becomes Cluster Aware How WorldView Becomes Cluster Aware In a clustered environment, the WorldView Manager and the WorldView Admin Client components are closely integrated with HAS and are compliant with the highly available directives of the HAS service. ■ When the WorldView Manager component is installed in a clustered environment, the installation process determines the location and setup of the installation environment, which includes information about local and shared drives, failover and failback events, and so on. ■ Only one instance of the WorldView Manager runs against the MDB at any one time. The WorldView Manager must be installed on the MDB server. ■ The Severity Propagation Service is added to the Unicenter NSM resource group, and when the Severity Propagation Service is failed over by HAS, it automatically fails over with the MDB. ■ The WorldView Admin Client is highly available only as a convenience. ■ Part of the WorldView Manager component is the WorldView Provider. ■ A Global Catalog can be placed on a cluster and is highly available. A Global Catalog file, the AIS catalog, is stored on the shared cluster drive. WorldView Resource Group Within the cluster, the Severity Propagation Service is added to the <nsm,> resource group and shared. How Event Management Becomes Cluster Aware In a clustered environment, the Event Manager components are closely integrated with HAS and are compliant with the highly available directives of the HAS service. ■ When Event Management is installed in a clustered environment, the installation process determines the location and setup of the installation environment, which includes information about local and shared drives, failover and failback events, and so on. ■ All Unicenter NSM Event manager configurations are added to the Unicenter NSM resource group. ■ Only one instance of Event Management will be running at any time within the cluster, which is controlled by HAS. 380 Implementation Guide How Event Management Becomes Cluster Aware ■ When failover occurs, the Event daemon resumes processing from the point of failure, even if this is within a sequence of Message Actions associated with a Message Record, for multiple action threads. This action is controlled by the CA_OPR_MONITOR_STATE environment variable. ■ SAF processing resumes from the point of failure. Event Management Resource Groups Within the cluster, the following Event Management resources are placed on the shared disk and shared among cluster nodes: ■ Console logs, which are the set of log files to which the events are written and recorded. After the failover, incoming events continue to be written to the same log, which ensures continuity for any external applications running against that log such as the Event Console. ■ Caopr.dsb file, which is a binary representation of the MSGRECORD\ MSGACTION policies. That ensures the implemented policy remains consistent when the failed over Event daemon is started by HAS, or when failback occurs. ■ SAF configuration file and SAF logs. This resource group ensures that a failed over SAF daemon can resume processing the SAF log from the point of failure. How Event Daemon Resumes Processing from Point of Failure The Event Management daemon keeps track of actions that are in the middle of processing when the CA_OPR_MONITOR_STATE environment variable is set to Yes, which is the default. ■ When an incoming event matches a MSGRECORD policy, the list of MSGACTIONs assigned to that policy is executed. If during this time a failover occurs during this time or the power is turned off, the Event Management daemon, during a start up, continues executing the rest of the MSGACTION list for the MSGRECORD and the event it was processing from when the failover occurred. ■ Only those events that were already retrieved by the Event Management daemon from the CAICCI queue, and that match any of the MSGRECORD\MSGACTION policies defined on the system are tracked. ■ These tracked events are stored in a state table in the CAOPRDMN.EXE cache. ■ The frequency with which the state table is saved into a flat file is determined by the value of the CA_OPR_MONITOR_INTERVAL environmental variable. The state table contains information about the event being processed, the matching MSGRECORD policy, and the last MSGACTION executed. Appendix B: Making Components Cluster Aware and Highly Available 381 How Event Management Becomes Cluster Aware Environment Variables Event Management Uses When Highly Available On each computer in the cluster, the following environment variables are automatically set in the Configuration\Settings\Event Management folder so that Event Management is highly available: CAI_CONLOG Specifies the shared location for the console logs files, for example g:\logs. CA_OPR_DSB Specifies the name of the .dsb file and the path to the shared location for the console logs files, for example g:\logs\caopr.dsb. CA_OPR_SAF_CONFIG Specifies the value of the SAF Config file on the shared location where the console logs files are, for example g:\logs\saf\saf.cfg. CA_OPR_SAF_ROOT Specifies the value of SAF directory on the shared location where the console logs files are to be kept, for example, g:\logs\saf. CA_OPR_MONITOR_STATE Specifies whether the Event Management Daemon will keep track of actions that it is in the middle of processing. The default is Yes. CA_OPR_MONITOR_INTERVAL Specifies the interval in seconds for saving the Event Management state table into a flat file. The default is 30 seconds. How You Configure Event Management in a Cluster Environment In general, when a node name is required, use the Unicenter NSM cluster virtual node (VNODE) rather than the physical node name of any of the constituent computers. Using VNODE makes sure that Unicenter NSM services are available. In particular, use the VNODE when you are performing the following tasks: ■ Configuring Remote Administration Clients (RAC) to manage Unicenter NSM on that cluster. ■ Forwarding events to a cluster node. Events sent to Event Manager from applications that are not registered with the cluster, or that are generated from the Windows Event Log by the Event Management Log Reader, carry the physical node name rather than the cluster VNODE. If those events are of interest, you should adjust any policy records that filter on the incoming node name to include both the physical and virtual node names. 382 Implementation Guide How AEC Becomes Cluster Aware How You Test Event Management in a Cluster Environment After you install and configure Event Management in a clustered environment, you may want to test that it is working correctly. Follow these steps: 1. Start Event Management on your primary server and verify that the Console Log is updated. 2. Issue a command similar to the following command from a command prompt on the primary server: cawto Test from primary server Verify that this message appears in the Console Log and has the name of the cluster in the Node Name field. 3. Force a failover, so that the backup server takes over the cluster environment. Verify that the same Console Log file is updated by the Event Management daemon running on the secondary server. 4. Issue a command similar to the following command from a command prompt on the backup server: cawto Test from backup server Verify that this message appears in the Console Log and has the name of the cluster in the Node Name field. How AEC Becomes Cluster Aware In a clustered environment, the AEC components are closely integrated with HAS and are compliant with the highly available directives of the HAS service. ■ When AEC is installed in a clustered environment, the installation process determines the location and setup of the installation environment, which includes information about local and shared drives, failover and failback events, and so on. ■ The Advanced Event Correlation configuration is added to the Unicenter NSM resource group. ■ Only one instance of AEC will be running at any time within the cluster, and will reside within the context of the Event Management daemon, which may itself failover under the control of HAS. AEC cannot failover independently of the Event Management daemon. ■ When the Event daemon (caoprdmn) is failed over by HAS, the AEC engine automatically fails over because it runs within the context of that daemon as a dll plugin. Appendix B: Making Components Cluster Aware and Highly Available 383 How Alert Management Becomes Cluster Aware ■ AEC cached policy, preconfigured rules, configuration information, and customizable tutor pane files are stored on the cluster's shared disk to ensure the correlation engine and associated user interfaces can resume seamlessly after failover. ■ At the point of failure, the state of any currently active AEC rules is lost because it is maintained within memory. AEC Resource Groups Within the cluster, the following AEC resources are added to the Unicenter NSM resource group and shared: ■ wvem\ace\ca-events.xml, which is a list of CA events that can be expanded and modified to include user-defined events. ■ wvem\ace\temp\, which is a directory that contains all cached policy from the MDB. The AEC engine is driven directly from this policy, therefore, it must be shared so that the failover engine can to access it without running ace_reload. ■ wvem\ace\html, which is a directory that contains html tutor-pane help that can be customized by the user. ■ wvem\ace\config, which is a directory that contains preconfigured rules that can be expanded or customized by the user. ■ Registry entries (shared directory/file structure on Linux), from which the AEC engine accesses the list of deployed policy, diagnostic log settings, and so on. Unlike the Event Management DSB concept, each policy is in a separate cache file. The registry tracks which of these policies is to be loaded into the engine. These registry settings are created and set using the AEC user interfaces. How Alert Management Becomes Cluster Aware In a clustered environment, the Alert Management components are closely integrated with HAS and are compliant with the highly available directives of the HAS service. ■ When AEC is installed in a clustered environment, the installation process determines the location and setup of the installation environment, which includes information about local and shared drives, failover and failback events, and so on. ■ All Unicenter NSM Alert Management configurations are added to the Unicenter NSM resource group. ■ Only one instance of the CA-Unicenter Alert Management Service will be running at any time within the cluster, which is controlled by HAS. 384 Implementation Guide How Alert Management Becomes Cluster Aware ■ When failover occurs, the Alert Management Service resumes processing from the point of failure. all alerts requested to be created by MRA and AEC policy during failover are processed and added to the MDB when AMS resumes on the failover system. Alert Management Resource Group In the cluster, the CA-Unicenter Alert Management Service is added to the Unicenter NSM resource group and shared. How You Test Alert Management in a Cluster Environment After you install and configure Alert Management in a clustered environment, you may want to test that it is working correctly. Follow these steps: 1. Bring the CA-Unicenter Alert Management Service online on your primary server. 2. Use a command such as cawto to create one or more event records that will trigger MRA or AEC policy to create alerts. 3. Verify in the Unicenter MCC that the message alerts are created and the alert queues are updated as expected. 4. Force a failover to the backup server of the resource group under which the CA-Unicenter Alert Management Service is installed. 5. After failover, verify that the CA-Unicenter Alert Management Service is online on the backup server. 6. Create alerts using the same technique you used in step 2. 7. Verify in the Unicenter MCC that the alerts are created and the alert queues are updated as expected. Appendix B: Making Components Cluster Aware and Highly Available 385 Cluster-Aware Agent Technology Cluster-Aware Agent Technology According to the underlying HAS clustering architecture, Unicenter NSM r11.x cluster-aware agents are categorized as follows: ■ Agents monitoring individual resources from one or more resource groups. For Unicenter NSM, these agents include: – Unicenter Windows System Agent (caiWinA3) – Unicenter UNIX/Linux System Agent (caiUxsA2) – Unicenter Linux/UNIX and Windows Log Agent (caiLogA2) These agents are continuously running on all cluster nodes. However, only one of these agents is actively monitoring a particular clustered resource, which is the agent on the cluster node currently having ownership of the shared resource, such as a file system or disk. Managed objects are dynamically rebuilt in the Management Command Center or 2D Map to visualize which agent is effectively monitoring a clustered resource. ■ Agents monitoring an entire service or application exposed by a particular cluster resource group. For Unicenter NSM, these agents include: – Unicenter Microsoft SQL Server Agent (caiSqlA2) – Unicenter Microsoft Exchange Agent These agents need access to all resources used by the service/application. Therefore, these agents fail over with the monitored service/application and run only on the cluster node where the corresponding resource group is active. After a failover, this agent will no longer automatically be started with the awservices start command. Instead, HAS will determine if the current node is the active node and tell Agent Common Services to start the agent. This also works in reverse, for example, if the current node becomes passive, HAS tells Agent Common Services to stop the agent. Managed objects are dynamically rebuilt in the WorldView repository in the MDB to avoid false status propagation. Important! Since Agent Technology does not support the automatic replication of an agent's configuration between cluster nodes, you must apply configuration changes on all cluster nodes, not just to the agent on the cluster node currently servicing the monitored resource or resource group. This is especially true for database agents to ensure that the agent that fails over to the secondary other node continues with exactly the same configuration as its predecessor. 386 Implementation Guide Cluster-Aware Agent Technology How Agent Technology Becomes Cluster Aware In a clustered environment, the Agent Technology manager components are closely integrated with HAS and are designed to be compliant with high availability directives and requirements of the service. ■ The Agent Technology manager installation (DSM, and associated manager-specific Agent Common Services) checks for a HAS configuration then determines the appropriate "SharedPath." The Unicenter NSM store and object store are configured on the "SharedPath" and the DSM runs in the warm start mode. ■ The following registry key is updated to point to the shared drive: KEY_LOCAL_MACHINE\\Software\\ComputerAssociates\\CA-Unicenter/TNG\\Agent Technologies\\Distributed State Machine\\SharedPath ■ The Distributed State Machine (DSM) and resource groups for each Agent Technology manager component (WV Gateway, DSM Monitor, SNMP, and so on) are added to the Unicenter NSM resource group. ■ Only one instance of the DSM can be running at any time within the cluster. The DSM requires that the manager components' directory structure reside on the shared drive to support continued management services regardless of the management node within the cluster. ■ Cluster-aware agents, when configured to monitor clustered resources, are not part of the resource groups containing those resources. This is enforced by the underlying HAS service and Agent Common Services components, which require their directory structures to reside on a local drive on each cluster node. ■ HAS does not require Unicenter NSM components to define cluster resources for resource groups. Instead, when a component (such as an agent) registers with HAS, HAS makes a mapping between the component name and the resource group and notifies the component of events occurring for the particular resource group (for example, the resource group stopped and started). This approach simplifies the deployment of agents in a cluster environment and supports the simultaneous use of both cluster-aware and non-cluster-aware agents. Also, there is no need to enhance policy or pollsets, or to make changes to the Agent Technology infrastructure. Appendix B: Making Components Cluster Aware and Highly Available 387 Cluster-Aware Agent Technology Windows System Agent Highly Available Resource Groups The Windows System Agent (caiWinA3) provides for the monitoring of the health and critical performance parameters of the Windows operating system. The caiWinA3 agent is packaged and distributed with Unicenter NSM. The following resource groups monitored by caiWinA3 can be failed over and continuously monitored: ■ Logical Volumes ■ Mounts ■ Processes ■ Services How System Agents Work in a Cluster Environment The use of HAS enables the system agent to adopt a platform independent, common approach for operation within cluster solutions provided by major Windows, UNIX, and Linux vendors. When a system agent is installed in a cluster environment, the following events occur: ■ The cluster name is reported in the System Summary Window of AgentView. ■ The cluster type is reported for all monitored instances of a resource eligible to be shared among the cluster nodes. ■ A dedicated passive aggregate status is used for failed-over resources while preserving watcher settings. ■ A dedicated status icon is used to visualize a passive resource in AgentView. The agent interfaces closely with HAS to obtain information about the cluster and any shared resources exposed. HAS supports and recognizes the agent's resource as clustered resources. For these resource groups, the agent maintains a cluster type attribute with each resource instance monitored. This attribute is set to one of the below values to indicate the actual state of the shared resource on the local cluster node: ■ Not-clustered—Resource is not clustered, that is, the node is not part of a cluster or the resource is not shared with other nodes in the cluster; the agent on this node actively monitors the resource. ■ Clustered-active—Local cluster node has resource ownership; the agent on this node actively monitors the resource. 388 Implementation Guide Cluster-Aware Agent Technology ■ Clustered-passive—Another node in the cluster owns the resource; the agent on the local node does not actively monitor the resource until ownership is transferred back (through failover or failback). Note: To enable the agent to get the cluster type information for processes, the name of the cluster resource group to which the monitored process belongs must be specified when adding a watcher. If during status evaluation a clustered-active resource is detected as passive, the agent does the following: ■ The watcher's sub-states (individual metric states) are set to OK and info traps are sent. ■ The watcher's aggregate status is set to passive and a passive status trap is sent to the DSM to indicate that a failover/failback from the local cluster node occurred for the resource. ■ Upon receipt of the passive status trap, the agent's DSM policy deletes the corresponding managed object representing the watcher from both NodeView and WorldView. ■ As long as the resource remains in the passive state (that is, not owned by the local cluster node), no more status traps are sent. During status evaluation, if a clustered-passive resource is detected as active, the agent performs the following tasks: ■ An active status trap is sent to DSM to indicate that a failover/failback to the local cluster node occurred for the resource. ■ Upon receipt of the active status trap, the agent's DSM policy recreates the corresponding managed object representing the watcher in NodeView and WorldView. ■ The watcher's sub-states (individual metric states) are evaluated as usual and info traps are sent. ■ The watcher's aggregate status is evaluated as usual and a normal status trap is sent. ■ As long as the resource remains in the active state (that is, owned by the local cluster node), status and info traps are sent. Appendix B: Making Components Cluster Aware and Highly Available 389 Cluster-Aware Agent Technology UNIX/Linux System Agent Highly Available Resource Groups The UNIX/Linux System Agent (caiUxsA2) monitors the health and critical performance parameters of UNIX and Linux operating systems. The caiUxsA2 agent is packaged and distributed with Unicenter NSM. The following resource groups monitored by caiUxsA2 can be failed over and continuously monitored: ■ File Systems ■ Disks ■ Processes UNIX/Linux and Windows Log Agent Highly Available Resource Groups The Windows and UNIX/Linux Log Agent (caiLogA2) checks for the existence or non-existence of user-specified files and monitors ASCII log files to detect faults in applications running under the operating system. The caiLogA2 agent is packaged and distributed with Unicenter NSM. The Windows and UNIX/Linux Log Agent (caiLogA2) can be configured to monitor the following resources: ■ Single log files ■ All files in a subdirectory, where the subdirectory name can contain wildcards. ■ Windows Event Log ■ UNIX console ■ Files with ASCII control characters. ■ Single-line log files—Some applications write only one entry into a log file, and a subsequent entry overwrites the existing one. The agent is able to monitor these single-line log files. 390 Implementation Guide Cluster-Aware Agent Technology How the Log Agent Works in a Cluster Environment HAS enables the log agent to adopt a platform independent, common approach for operation within cluster solutions provided by major Windows, UNIX, and Linux vendors. When a log agent is installed in a cluster environment, the following events occur: ■ A dedicated passive status is used for log file watchers monitoring log files located on failed-over storage devices. ■ A dedicated status icon is used to visualize a passive log file watcher in AgentView. The agent interfaces closely with HAS to obtain information about the cluster and any shared resources exposed. HAS supports and recognizes logical volumes on Windows, disks on UNIX/Linux, and file systems on UNIX/Linux (except IBM AIX) as clustered resources capable of hosting log files monitored by the agent. From a local cluster node's perspective, these storage devices can assume one the following states: ■ Not-clustered—Resource is not clustered, that is, the node is not part of a cluster or the resource is not shared with other nodes in the cluster; the agent on this node actively monitors log files located on the storage device. ■ Clustered-active—Local cluster node has resource ownership; the agent on this node actively monitors log files located on the storage device. ■ Clustered-passive—Another node in the cluster owns the resource; the agent on the local node does not actively monitor log files located on the storage device until ownership is transferred back (through failover or failback). If during log file evaluation a clustered-active storage device is detected as passive, the agent performs the following tasks: ■ The status of every log watcher concerned is set to passive and a passive status trap is sent to DSM to indicate that a failover/failback from the local cluster node occurred for the storage device hosting the monitored log files. ■ Upon receipt of the passive status trap, the agent's DSM policy deletes the corresponding managed object representing the log file watcher from both NodeView and WorldView. ■ As long as the storage device remains in the passive state (that is, not owned by the local cluster node), no more status traps are sent for the log watchers concerned. Appendix B: Making Components Cluster Aware and Highly Available 391 Cluster-Aware Agent Technology If during log file evaluation a clustered-passive storage device is detected as active, the agent performs the following tasks: ■ For every log watcher concerned, an active status trap is sent to DSM to indicate that a failover/failback to the local cluster node occurred for the storage device hosting the monitored log files. ■ Upon receipt of the active status trap, the agent's DSM policy recreates the corresponding managed object representing the log file watcher in NodeView and WorldView. ■ The status of every log watcher concerned is evaluated as usual and a normal status trap is sent. ■ As long as the storage device remains in the active state (that is, owned by the local cluster node), status traps are sent for the log watchers affected. How to Set Up and Configure a System or Log Agent in a Cluster Environment To provide full monitoring of the cluster, you must install the agent on each cluster node. We recommend that you enable Adaptive Configuration, which is supported only by the Windows and UNIX/Linux System agents, to provide automatic monitoring of critical cluster resources. Otherwise, manual user interaction is required, which starts with the identification of salient resources and the determination of their monitoring frequency, followed by the transformation of those considerations into agent configurations and their deployment and maintenance. Depending on what is already installed on a cluster node, the setup automatically installs or upgrades required CA Common Services components, specifically Agent Technology and High Availability Service. If you enabled Adaptive Configuration support, start the agent and the Adaptive Configuration service with one of the following commands: ■ awservices start ■ aws_baseline start If you did not enable Adaptive Configuration support, use one of the following commands to start the agent: ■ awservices start ■ caiUxsA2 start (UNIX/Linux System agent) ■ caiWinA3 start (Windows System agent) ■ caiLogA2 start (Log agent) 392 Implementation Guide Cluster-Aware Agent Technology Microsoft SQL Server Agent Highly Available Resource Groups The Unicenter Microsoft SQL Server Agent (caiSqlA2) provides status monitoring and health-checks for fundamental areas of the Microsoft SQL Server database environment. The Unicenter Microsoft SQL Server Agent (caiSqlA2) is included with the Unicenter NSM Database Performance Monitor Option (DPMO) 3.0 product suite. DPMO requires a working installation of Agent Technology Common Services and is certified to run with Unicenter NSM 3.0 or later. The Microsoft SQL Server Agent (caiSqlA2) can be configured to monitor the following resources: ■ Database Server Configuration ■ System Resources ■ Server Resources ■ Locks ■ Services ■ File Systems ■ File Groups ■ Databases ■ Tables ■ Processes ■ Jobs ■ Publications ■ Subscriptions ■ Programmable Watchers Due to its MibMUX enabled design, the caiSqlA2 agent also supports active/active Microsoft SQL Server cluster environments. How the Microsoft SQL Server Agent Works in a Cluster Environment HAS enables the Microsoft SQL Server agent to effectively operate within a Microsoft cluster environment. When a Microsoft SQL Server agent is installed in a cluster environment, the following events occur: ■ During configuration of the agent, the instance of the agent monitoring a clustered instance of SQL Server is registered with HAS. Appendix B: Making Components Cluster Aware and Highly Available 393 Cluster-Aware Agent Technology ■ If a failover or failback of the SQL Server instance occurs, the agent instance is restarted by the Agent Technology Common Services component on the cluster node that has assumed the workload for the SQL Server instance. The Agent Technology Common Services component also registers with HAS to receive notifications for caiSqlA2 start and stop requests. ■ If HAS detects a failover or failback of an SQL Server instance, the Agent Technology Common Services sends failover traps to the DSM computer to report the start or stop of the affected agent instances. – Upon receipt of these traps, the standard DSM policy removes the managed object representing the agent instance on the passive node in NodeView and WorldView. – The managed object representing the agent instance on the active node is recreated by initiating a rediscovery of the agent. How to Set Up and Configure the Microsoft SQL Server Agent in a Cluster Environment When the Microsoft SQL Server Agent is installed in an MSCS (Microsoft Cluster Service) environment that exposes one or more clustered instances of Microsoft SQL Server, you must install and configure agent instance on each node in the cluster. ■ The Microsoft SQL Server instances to be monitored by the agent must be running (online). Since the setup (and the caiSqlA2Cnf.exe configuration program) uses a server's virtual network name, the respective SQL Server resource group does not need to be moved between the cluster nodes during installation or configuration of the agent instance. ■ When configuring an agent instance to use Windows Authentication with a clustered instance of Microsoft SQL Server, the setup (or the caiSqlA2Cnf.exe configuration program) must be running under the cluster domain account. ■ The Agent Technology service must be running under the same account to enable the agent instance to connect to SQL Server using Windows Authentication. Important! Unless you experience problems with Agent Technology or HAS automatically starting the agent on the active node, do not explicitly start or stop the agent on any cluster node. 394 Implementation Guide Appendix C: CCS Linux/UNIX Reference This section contains the following topics: CCS Linux/UNIX Reference Introduction (see page 395) PIF Response Files (see page 395) Parameter Usage in PIF (see page 396) PIF Response Files and Parameters (see page 396) PIF Response Files Creation (see page 396) Response File Considerations (see page 397) CCS Linux/UNIX Reference Introduction This appendix is a reference for all CCS r11 components that are selectable and configurable by the product using them. It also lists those parameters that are configurable along with their default values. You can use these parameters to populate the PIF Response files for unattended installation. Response files are a feature of the PIF installer to enable unattended installations. Response files are used to customize the product or CCS installation if the default values do not fit into a specific installation environment. PIF Response Files PIF response files are plain text files that contain “parameter= value” pairs that define settings used during the installation, for example: CCSINST_EVTAGT=1 Appendix C: CCS Linux/UNIX Reference 395 Parameter Usage in PIF Parameter Usage in PIF To better understand the usage of response files, you need to know how parameters are defined and handled in PIF. All PIF parameters are defined in the default section of the PIF packages and they are always created with default values. These default values can be defined as either static or dynamic values, for example: #parameter: $CASHCOMP , /opt/CA/SC is a static default value, and #parameter: $EMSERVER , ’uname -n’ is a dynamic default value. Using dynamic default values for parameters makes it easy to deploy packages to multiple systems since the values are evaluated on the target system. This happens automatically for the parameters that are defined as dynamic parameters. You do not need to provide parameters using a response file if they are defined as dynamic parameters. PIF Response Files and Parameters Sometimes it is necessary to define certain parameters for the installation that cannot be handled through dynamic defaults, for example, the customer’s Unicenter MDB server name. In this case, you can use a response file to pass these parameters to the PIF package. PIF Response Files Creation You can create a response file with a text editor. An example of a response file follows: CASHCOMP=/opt/CA/mynsm csutils=1 CCSINST_EVTAGT=1 You can use this response file with your installation. CCS install results in a default Event Agent installation (CCSINST_EVTAGT), indicating that the EULA has been agreed to (csutils=1), that CCS will be installed into /opt/CA/mynsm/ccs (CASHCOMP is set to /opt/CA/mynsm, and the ccs directory will be created below that). Use the parameters described in Response File Considerations to set the specifics for each CCS component. 396 Implementation Guide Response File Considerations Response File Considerations Consider the following in relation to the response file in PIF: ■ You do not have to provide all the parameters in the response file. It is intended as an overlay to the defaults from the packages, so specify only the parameters you want to overwrite. ■ Generate a response file using the command setupNSM -a, then save it and modify it for future deployments. Do not attempt to use “lsm -a” to create a response file. ■ You can use environment variables in the response file, such as (my_host=`hostname -i`) to enable dynamic settings that are evaluated on the target system. Appendix C: CCS Linux/UNIX Reference 397 Appendix D: Database Maintenance Quick Reference This section contains the following topics: Database Maintenance Quick Reference Introduction (see page 399) Database Backup (see page 400) Query Optimization (Ingres Only) (see page 401) System Catalog Optimization (Ingres Only) (see page 401) User-Defined Tables Optimization (Ingres Only) (see page 402) Database Recovery (see page 402) Database Maintenance Quick Reference Introduction The maintenance tasks and administration efforts for the MDB may be unfamiliar to users accustomed to working with other databases used with previous releases. This quick reference section introduces the routine maintenance tasks needed to keep your MDB performing consistently and provide the necessary protection for your data investments. What follows are the commands we recommend using to keep your MDB running smoothly, as well as a brief description of when and how often to use each command. The following guidelines, although not comprehensive, are our recommended best practices and will ensure a smooth and effective experience. Note: If you need to handle more complex issues such as special purpose commands and customization, or if you need more detailed information on any of the tasks that follow, see the full Ingres or Microsoft SQL Server documentation. Additional guidelines for planning, configuring, maintaining and tuning your Unicenter NSM MDB can be found on the Implementation CD (go to Technical Support at http://ca.com/support). Information about PostgreSQL databases which are used for Event Management on UNIX/Linux are available at http://www.postgresql.org/docs. Appendix D: Database Maintenance Quick Reference 399 Database Backup Database Backup The following commands will back up your database. Microsoft SQL Server Databases All processes accessing the MDB must be shut down. You can enter all queries using the Microsoft SQL Server Query Analyzer. To determine which processes are running, execute the following query: USE master SELECT distinct hostname, program_name, hostprocess FROM sysprocesses WHERE dbid = (SELECT dbid FROM sysdatabases WHERE name = 'mdb') To back up without a logical backup device, execute the following query: USE master BACKUP DATABASE mdb TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\mdb_1.dat' To back up with a logical backup device, execute the following queries: 1. Create a logical device, if one does not already exist, using the following query: USE master EXEC sp_addumpdevice 'disk', 'mdb_1', 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\mdb_1.dat' 2. Back up to the logical device using the following query: USE master BACKUP DATABASE mdb TO mdb_1 To remove a logical device (optional), execute the following query: USE master EXEC sp_dropdevice 'mdb_1' Note: Update the backup path according to your environment. 400 Implementation Guide Query Optimization (Ingres Only) Ingres Databases ckpdb -d -umdbadmin mdb This command runs a checkpoint on your database to back up the data. We recommend you run this command once a day. This command saves only a single generation of the MDB. For your convenience, a script is provided to handle multiple generation in the r11 Implementation CD on SupportConnect. You must be an Ingres Administrator to perform this command. Note: For more information about checkpoints, database backup, or the ckpdb command, see the Ingres Command Reference Guide. Query Optimization (Ingres Only) Use the optimizedb command to generate statistics that optimize query processing strategies. To optimize query processing, enter the command in the following format: optimizedb -zk -zw -umdbadmin mdb We recommend that you run this command once a day to keep the database operating at peak efficiency. You must be an Ingres Administrator to perform this command. Note: For more detailed information on query optimization or the optimizedb command, see the Ingres Command Reference Guide. System Catalog Optimization (Ingres Only) To modify system catalogs of a database to predetermined storage structures, enter the following command: sysmod +w mdb The sysmod command reorganizes the system areas within the Ingres MDB itself to conform system catalogs to specific storage structures. Because it reorganizes system areas within the MDB, you must run this command with no other tasks connected to the database as it requires exclusive control. We recommend running this command only very infrequently (perhaps once every three months), and only when there is evidence that the system catalogs require reorganization. Appendix D: Database Maintenance Quick Reference 401 User-Defined Tables Optimization (Ingres Only) You must be an Ingres Administrator to perform this command Note: For more detailed information on system catalog optimization or the sysmod command, see the Ingres Command Reference Guide. User-Defined Tables Optimization (Ingres Only) To consolidate and optimize user-defined tables within the MDB, enter the following command: usermod -online -umdbadmin mdb The usermod command modifies the user-defined tables of a database to their currently defined storage structures. Because of its time-consuming nature, run this command infrequently, preferably during off-peak periods. We recommend running this command once every three months. You must be an Ingres Administrator to perform this command. Note: For more detailed information on user-defined tables and a more complete description of the usermod command, see the Ingres Command Reference Guide. Database Recovery You should back up your database regularly so that you can recover your data if necessary. Databases or tables can be damaged accidentally by hardware failure or human error. Microsoft SQL Server Databases All processes accessing the MDB must be shutdown. You can enter all queries using the Microsoft SQL Server Query Analyzer. To determine which processes are running, execute the following query: USE master SELECT distinct hostname, program_name, hostprocess FROM sysprocesses WHERE dbid = (SELECT dbid FROM sysdatabases WHERE name = 'mdb') 402 Implementation Guide Database Recovery To restore without a logical backup device, execute the following query: USE master RESTORE DATABASE mdb FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\mdb_1.dat' To restore with a logical backup device, execute the following queries: 1. Create a logical device, if one does not already exist, using the following query: USE master EXEC sp_addumpdevice 'disk', 'mdb_1', 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\mdb_1.dat' 2. Restore from the logical device using the following query: USE master RESTORE DATABASE mdb FROM mdb_1 To remove a logical device (optional), execute the following query: USE master EXEC sp_dropdevice 'mdb_1' Note: Update the backup path according to your environment. Ingres Databases rollforwarddb -v -umdbadmin mdb Run this command only as absolutely required. You must be an Ingres Administrator to perform this command. This command requires exclusive use of the database to succeed, meaning you must terminate all connections to the database before running. If this command should fail because the database cannot obtain the lock, the situation can usually be resolved by terminating Ingres by issuing the following: ingstop -force followed by: ingstart Notes: For more detailed information on database recovery and the rollforwarddb command, see the Ingres Command Reference Guide. Once a database is recovered successfully, we recommend that you take a checkpoint (see the Database Backup topic) to preserve the recovered state. Appendix D: Database Maintenance Quick Reference 403 Index 2 2D maps • 262, 264 A about • 252, 254 access Unicenter NSM web applications • 226 Active Directory Monitoring • 18 active/active configuration • 371 active/passive configuration • 371 Adaptive Configuration • 20, 392 Administrative Interface (AI) • 53 installation • 173 Advanced Event Correlation • 20, 47, 283 Interactive Development Environment (IDE) • 284 agent PROC's • 161 Agent Technology • 17, 18, 51, 283 controlling the agents • 222 copying the MIB to • 160 loading the MIB • 160 update awservices • 161 update PROCs • 161 agentless monitoring • 271 agents and Agent Technology • 51 configuration sets • 222 controlling • 222 initializing • 83 migrating configuration sets • 162 Unicenter NSM agents • 72 Alert Management System • 19 Alert manager • 48, 73 all agents • 386 and Advanced Event Correlation • 383 and Agent Technology • 386 and Event Management • 380 architecture • 373 architecture design hardware and software • 63 network considerations • 64 operational standards • 65 Association Browser • 268 authentication and access control • 241 automated business views • 281 aws_baseline • 392 aws_baseline command • 392 awservices • 392 awservices command • 392 B best practices, RSII • 250 business needs, determining • 67 Business Process View Management (BPVM) • 25 C CA High Availability Service See also HAS • 369 CA LMP • 83 CA SYSVIEW Server • 85 CICS Logger task • 87 MVSDATA task • 86, 222 reassemble and link • 86 starting • 222 CA Web Server • 226 configure with SSL • 230 security • 241 CAICCI • 195 daemons • 195 remote daemons at startup • 218 remote statement • 199 troubleshooting • 217 CAICCI configuration HP NonStop • 204 mainframe • 214 OpenVMS • 206 UNIX • 202 Windows • 200 caiLogA2 • 392 caiLogA2 command • 392 CAIRIM • 82 caiUsxA2 command • 392 caiUxsA2 • 392 caiWinA3 • 392 caiWinA3 command • 392 CCI CAICCI • 195 ccii utility • 217 ccir utility • 218 Index 405 ccis utility • 218 CCS UNIX/Linux Reference • 395 CFGCONV utility • 162 Cisco • 24 cluster service layer • 373 cluster service layer (CSL) • 373 cluster type attributes • 388 cluster-aware • 374 cluster-awareness • 388 clustered resource states • 391 Common Discovery • 60 configuration • 371 configuration choices • 111 configuration set file default location • 162 configuration sets location for each agent • 222 migrating • 162 configuring thresholds and poll times • 221 contacting technical support • iv Continuous Discovery manager • 46, 60 converting to PDS format • 157 critical state • 268 cross platform scheduling • 49 CSL (cluster service layer) • 373 customer support, contacting • iv D dashboards • 262 Data Scoping • 26 access to the MDB • 193 for Linux and UNIX • 193 for Windows • 194 rules that protect the data • 192 Data Scoping Rule Generator • 194 create Data Scoping rules • 194 database selection for Windows • 111 date and time controls • 47 demilitarized zone (DMZ) • 307, 326 deploy the install image • 256 description • 369 DIA Grid • 297 discovery • 60, 175 Discovery Wizard • 261 Distributed Intelligence Architecture • 291 configure • 319 configure for firewalls • 321 encryption mechanism • 319, 335 HACMP Clusters • 326 NAT settings • 324 406 Implementation Guide troubleshooting • 302 Distributed State Machine (DSM) • 17, 74 DSM manager • 46 pre-installation • 80, 81 role, Agent Technology • 51 DNA remote install • 294 documentation • 26 Dynamic Node Administrator (DNA) • 294 E environment variables • 382 Event Console • 20 event daemon, resuming processing • 381 Event Manager • 47, 73 F failback operation • 370 failover operation • 370 FTP files to the mainframe • 156 G GUIs • 43 H HAS cluster-aware components • 374 HAS daemon • 373 historical information • 268 how the reduced-size install image works • 250 I importance • 267 Ingres Ingres configuration dialog • 111 install image deploy • 256 register with Unicenter Software Delivery • 254 response files for • 252 installation AI installation • 173 CA Common Discovery • 135 Linux/UNIX considerations • 81 Pocket PC • 88, 164, 221 SPECTRUM integration kit • 174 installation methods • 69 unattended • 70 UNIX/Linux • 70 Windows • 69 installing Monitoring for z/OS • 156 installation library, download • 159 on the mainframe • 157 installing security • 105 installing Unicenter NSM • 111 deploying to hosts • 145 on Linux or UNIX • 119 installing Unicenter NSM Systems Performance • 146 introduction • 369 J Java Runtime Environment (JRE) • 232 JCL • 156 start and stop agent address spaces • 161 JDBC • 228 job agent • 49 Job manager • 49, 73 K in Agent Technology • 51 managers • 45 MemoryRealm • 241 Microsoft SQL Server agent • 393 Microsoft SQL Server agent cluster-awareness • 393 Microsoft SQL Server agent configuration • 394 Microsoft SQL Server agent resource groups • 393 migrating component data • 108 migration instructions • 26 migration, configuration sets • 162 MOM • 23 Monitoring for z/OS • 82 disabling previous release • 86 install on the mainframe • 157 monitoring technology • 54 comparison of products • 54 information monitored • 55 multiple NICs • 327 keytool utility • 232 knowledge base Master Knowledge Base • 311 zone and grid rules • 311 N L O licensing information • 82 Linux/UNIX pre-installation • 79 LMP (License Management Program)See CA LMP • 83 LOCAL statement format • 196 sample configurations • 199 log agent • 391 log agent cluster-awareness • 391 log agent setup • 392 log file default location • 162 OMVS segment • 162 online books • 22 OpenVMS basic CAICCI configuration • 199 overview • 369, 380, 383, 387 M Mainframe CAICCI configuration • 214 Managed Object • 266 Managed Server • 72 Management Command Center • 17, 77 Business Process Views • 281 Data Scoping rules • 194 focused visualization • 279 Management Database (MDB) • 22, 44, 77 accessing the MDB • 228 Notification Services • 19 NSM Security Realm • 241 P Performance Data Grid (PDG) • 59 PIF response files • 395 Pocket PC configuring • 221 implementing Unicenter • 88 installing • 164 uninstalling • 189 polling intervals • 80 portal-based visualization • 271 PostgreSQL • 15, 102, 119, 399 prerequisites • 250 PROCs security • 162 updating • 161 product licensing authorization • 82 protection against unauthorized access • 26 Index 407 proxies • 51 R readme file • 27 register with Unicenter Software Delivery about • 254 REMOTE statement • 196, 199 advanced sample • 199 basic sample • 199 Repository Bridge, uses • 44 resource groups • 371, 381, 384 response files create for Systems Performance • 253 default files • 252 plan for • 252 response files and registration • 142 restricting message access • 47 S setupNSM • 70, 119 SETVARS member • 159 smo • 159 SMP/E installation • 160 SPECTRUM integration kit installation • 174 SSL for Tomcat • 232 starting the agent address space • 223 statistics data • 268 status • 267 support, contacting • iv supported vendor clusters • 369 T TCP/IP communications port number • 221 technical support, contacting • iv testing • 383 Tomcat Administration • 226 Tomcat Manager • 226 Tomcat security • 241 Tomcat server • 263 Topology • 262, 265 Trap Daemon • 20 TrapManager • 20 install TrapManager • 170 troubleshooting • 257 U Unicenter Advanced Network Management • 15 408 Implementation Guide Unicenter Advanced Systems Management • 15 Unicenter Browser Interface (UBI) • 21 Unicenter CA-SYSVIEW Server • 222 Unicenter Cisco Integration • 24 install Unicenter Cisco Integration • 169 uninstall • 190 Unicenter Configuration Management • 21 Unicenter Controller • 268 Unicenter for Pocket PC • 22, 88, 164, 221 Unicenter Job Management Option • 15 Unicenter Management Command Center (Unicenter MCC) • 262 Unicenter Management for Microsoft Operations Manager • 23 install MOM Management • 166 MOM Discovery • 166, 224 set-up • 89 Unicenter Management Portal • 21, 271 configure a workplace • 275 event view portlet • 276 install Management Portal • 163 Unicenter NSM Monitoring Manager • 73 overview • 15 Product Explorer • 69 Reporting and Configuring Manager • 76 security • 105 Visualization Server • 77 Web Reporting Server • 229 Unicenter Remote Monitoring • 24, 53, 76, 92, 271 configure • 273 install • 172 Unicenter Software Delivery • 71, 141 registration • 144 Unicenter Software Delivery, register with • 254 Unicenter Software Development Kit (SDK) • 21 Unicenter Systems Performance • 18, 59, 75 pre-install tasks • 87 Unicenter WMI agent • 26 configuration • 221 uninstall Unicenter NSM • 187 UNIX CAICCI configuration • 202 UNIX/Linux and Windows log agent resource groups • 390 UNIX/Linux system agent resource groups • 390 update agent PROCs • 161 upgrade instructions • 26 upgrade Systems Performance agents • 250 user identifier • 162 V visualization • 43 W wait warning message • 106 Web Reports and Dashboards • 21 weight value • 266 weighted severity, using • 279 Windows CAICCI configuration • 200 pre-installation • 79 Windows system agent • 388 Windows system agent cluster-awareness • 388 WorldView manager • 46, 74 Index 409
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021