System Automation Application Manager Version 4.1. Installation and Configuration Guide IBM SC

Transcription

1 System Automation Application Manager Version 4.1 Installation and Configuration Guide IBM SC

2

3 System Automation Application Manager Version 4.1 Installation and Configuration Guide IBM SC

4 Edition Notices Before using this information and the product it supports, read the information in Notices on page 315 This edition of IBM Tivoli System Automation Application Manager, Installation and Configuration Guide applies to Version 4 Release 1, Modification 0 of IBM Tivoli System Automation Application Manager, program number 5724 S92, and to all subsequent releases and modifications of this product until otherwise indicated in new editions. IBM Tivoli System Automation Application Manager is the successor to the end-to-end automation management component of IBM Tivoli System Automation for Multiplatforms V2.3. This edition replaces SC IBM welcomes your comments. A form for readers' comments may be provided at the back of this publication, or you may address your comments to the following address: IBM Deutschland Research and Development GmbH Department 3248 Schoenaicher Str. 220 D Boeblingen Federal Republic of Germany FAX (Germany): FAX (Other Countries): (+49) Internet eservdoc@de.ibm.com If you would like a reply, be sure to include your name, address, telephone number, or FAX number. Make sure to include the following in your comment or note: v Title and order number of this book v Page number or topic related to your comment When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright IBM Corporation 2006, US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Figures vii Tables ix About this book xi Who should read this guide xi Where to find more information xi Conventions used in this guide xii ISO xii Related information xii How to obtain publications xiii How to reach us by xiii What's new in this release xv Chapter 1. Planning Planning for System Automation Application Manager Packaging Prerequisites Preparing for installation Planning for an LDAP user registry Planning for the agentless adapter Packaging Prerequisites Planning for high availability Planning for Distributed Disaster Recovery Packaging Prerequisites Preparing for installation Planning for the PowerHA adapter Packaging Prerequisites Automating the PowerHA adapter Behavior of the PowerHA adapter Planning for the FOC adapter Roadmap Packaging Prerequisites Planning and preparing for an highly available FOC adapter Behavior of the FOC adapter Planning for the VCS adapter Packaging Prerequisites Automating the VCS adapter Behavior of the VCS adapter for Solaris/SPARC 40 Planning for an end-to-end automation policy The scope of end-to-end automation policies.. 41 Identifying cluster-spanning dependencies Default directories Disaster recovery policy definition worksheets Chapter 2. Installing Installing the middleware software Contents of the middleware software DVDs.. 51 Installing a DB2 server Installing Jazz for Service Management Installing System Automation Application Manager 59 Using the installation wizard Installing in silent mode Upgrading to release Verifying the installation Post-installation tasks Upgrading from a Try and Buy version to a full product version Uninstalling Installing on new operating systems Installing fix packs Obtaining fix packs Archive naming conventions Naming conventions of the update installer location Usage instructions for the platform-specific archives Installing a product fix pack Installing fix packs in a high availability setup. 80 Uninstalling fix packs Installing for high availability Installing for Distributed Disaster Recovery Installing the prerequisite software on both sites 82 Installing and configuring System Automation for Multiplatforms Installing System Automation Application Manager on the first site Configuring System Automation Application Manager on the first site Setting up DB2 HADR Installing System Automation Application Manager on the second site Configuring System Automation Application Manager on the second site Creating tools for the replication of policy and credential files Configuring all end-to-end automation adapters with two System Automation Application Manager hosts Configuring high availability and contact retry interval of all end-to-end automation adapters.. 87 Installing the remote agentless adapter Using the installation wizard to install the remote agentless adapter Installing the remote agentless adapter in silent mode Uninstalling the remote agentless adapter Installing and uninstalling service for the remote agentless adapter Installing the IBM PowerHA adapter Using SMIT to install the adapter Copyright IBM Corp. 2006, 2015 iii

6 Verifying the PowerHA adapter installation Uninstalling the PowerHA adapter Installing the Failover Cluster (FOC) adapter Installing the Failover Cluster Command Interface optional feature Using the installation wizard to install the FOC adapter Installing the FOC adapter in silent mode Upgrading the FOC adapter Verifying the FOC adapter installation Uninstalling the FOC adapter Installing the Veritas Cluster Server (VCS) adapter 96 HACMP Using the installation wizard to install the VCS adapter Installing the VCS adapter in silent mode Verifying the VCS adapter installation Uninstalling the VCS adapter Chapter 3. Configuring Configuring the Application Manager Starting the Application Manager configuration dialog Configuring the Application Manager settings 100 Configuring the Application Manager common settings Domain tab Command Shell tab Discovery Library Adapter tab OSLC tab Event Publishing tab User Credentials tab Security tab Logger tab Save the common configuration Refreshing the Application Manager common configuration Configuring System Automation Application Manager in silent mode Configuring an alternative end-to-end automation host Configuring an LDAP user registry Adding the LDAP user registry as a federated repository Configuring supported entity types Porting from a file-based repository to an LDAP repository in a post-defined setup Configuring access to non-clustered nodes Configuring the local agentless adapter Configuring remote agentless adapters Controlling Agentless Adapters Configuring agentless adapters in silent mode 138 Tuning the number of domains and resources of agentless adapters Configuring virtual server & hardware management Configuring the hardware adapter Refreshing the active hardware adapter configuration Testing the active hardware adapter Configuring the hardware adapter in silent mode Configuring storage replication Configuring the TPC-R domain Refreshing the TPC-R domain settings Testing the TPC-R domain configuration Configuring the TPC-R domain in silent mode 150 Configuring high availability High availability for System Automation Application Manager High availability for a disaster recovery setup on two sites Configuring Distributed Disaster Recovery Configuring the destination for GDPS events 176 Configuring the GDPS agent Configuring synchronous communication with GDPS Configuring the PowerHA adapter Starting the PowerHA adapter configuration dialog Configuring the PowerHA adapter settings Replicating the configuration files to other nodes in the domain Defining the PowerHA adapter automation policy Removing the PowerHA adapter automation policy Configuring the PowerHA adapter in silent mode Controlling the PowerHA adapter Configuring the FOC adapter Starting the FOC adapter configuration dialog 186 Configuring the FOC adapter settings Replicating the configuration files to other nodes in the domain Configuring the FOC adapter in silent mode 192 Providing high availability for the FOC adapter 192 Configuring the VCS adapter Starting the VCS adapter configuration dialog 194 Configuring the VCS adapter settings Replicating the configuration files to other nodes in the domain Defining the VCS adapter automation policy 202 Removing the VCS adapter automation policy 202 Configuring the VCS adapter in silent mode Controlling the VCS adapter Configuring in silent mode Working in silent mode Processing tasks manually Starting silent configuration Silent mode input properties file Editing the input properties file Output in silent mode Configuration properties files Configuration properties files of the System Automation Application Manager Configuration properties files of the PowerHA adapter Configuration properties files for the VCS adapter iv Tivoli System Automation Application Manager V : Installation and Configuration Guide

7 Configuration properties files of the FOC adapter Chapter 4. Integrating Event consoles IBM Tivoli Netcool/OMNIbus Tivoli Enterprise Console Enabling event generation in System Automation Application Manager Enabling event filtering Tivoli Business Service Manager (TBSM) Integrating with System Automation Application Manager Prerequisites Configuring TBSM Configuring the Discovery Library Toolkit Integrating System Automation resources in TBSM Customizing TBSM views to add information from System Automation Configuring Tivoli Business Service Manager launch-in-context support Integration scenarios with Business Service Manager Tivoli Monitoring and Tivoli Composite Application Manager Prerequisites Tivoli Monitoring overview Integrating with System Automation Application Manager Creating a Tivoli Monitoring situation to trigger an automated restart Integrating with Tivoli Monitoring and Tivoli Composite Application Manager (ITCAM) Integration Scenarios with Tivoli Monitoring and IBM Tivoli Composite Application Manager (ITCAM) zenterprise Hardware Management Console Setting up the Hardware Management Console 283 Obtaining the Hardware Management Console certificate Firewall considerations Working with the discovery library adapter eezdla options quick reference eezdla options JazzSM Administration Services JazzSM integration scenario Configuring JazzSM Administration Services integration Administering registered JazzSM Administration Services resources Chapter 5. Securing Security concepts Security tab Securing the connection to end-to-end adapters using SSL Generating Keystore and Truststore with SSL public and private keys Enabling SSL security in the Application Manager configuration Enabling SSL security in FLA adapter configurations Optional: Enforcing usage of SSL for all FLA domains Securing communication with the zenterprise Hardware Management Console Managing the security setup for Agentless Adapters Managing user credentials to access single nodes with Agentless Adapters Managing SSH public keys Chapter 6. Tuning Tuning the number of domains and resources of agentless adapters Using IBM Support Assistant Installing IBM Support Assistant and the Tivoli System Automation for Multiplatforms plug-in Notices Trademarks Index Contents v

8 vi Tivoli System Automation Application Manager V : Installation and Configuration Guide

9 Figures 1. Overview of System Automation product family 2 2. Installation wizard: Required RAM information dialog Examples for resource references to resources and resource groups Example for end-to-end automation groups that are distributed over different platforms Application Manager tab of the Automation Manager Configuration dialog Non-clustered Nodes tab of the Automation Manager configuration dialog Virtual Server / HW Management tab of the Application Manager Configuration dialog Storage Replication tab of the Application Manager Configuration dialog High Availability tab of the Application Manager Configuration dialog Change Passwords tab of the Application Manager Configuration dialog Maintaining configurations for multiple Agentless Adapters End-to-end high availability scenario with a shared database file system End-to-end high availability scenario with a remote database file system Resource groups, resources, and their relationships Resource groups, resources, and their relationships Configuration of the PowerHA adapter Application Manager Adapter Configuration - Task Launcher for PowerHA Main window of the FOC Automation Adapter Configuration dialog Configuration of the VCS adapter VCS Automation Adapter Configuration dialog Sample configuration of launch entry Modifying menu entries that are displayed in the Tools menu TBSM basic architecture Identification Fields tab Tree template editor Integration of System Automation with Business Service Manager TBSM Service Availability Page TBSM Service Tree TBSM Service Tree TBSM Service Viewer Tivoli System Automation operations console Tivoli System Automation Operations Console Overview of the IBM Tivoli Monitoring infrastructure Application Manager Local Agentless Adapter Configuration Agent attributes which can be added as additional attributes Perform an System Automation Application Manager command shell command as action for an Tivoli Monitoring situation Example of System Automation Application Manager managing Tivoli Monitoring Endpoints and HA clusters JazzSM Administration Services integration scenario Registering resources for OSLC Using OSLC web services interfaces Keystore and Truststore generation using SSL Authentication with the Agentless Adapter on a remote node SSH key exchange overview Copyright IBM Corp. 2006, 2015 vii

10 viii Tivoli System Automation Application Manager V : Installation and Configuration Guide

11 Tables 1. System Automation Application Manager product DVDs Archive files of the electronic deliverable 3 3. Supported operating systems for System Automation Application Manager Disk space requirements Installation directory and Tivoli Common Directory DB2 data for local and remote DB2 setup WebSphere Application Server installation parameters Installation parameters End-to-end automation domain name WebSphere Application Server user ID System Automation Administrator user ID Directories on the product DVD Remote Agentless Adapter product DVD Archive files of the electronic deliverable Supported operating systems for remote agentless adapters Supported operating systems for non-clustered nodes managed by the agentless adapter Supported operating systems for Distributed Disaster Recovery Supported operating systems of managed clusters using GDPS for storage replication Supported operating systems of managed clusters using TPC-R for storage replication Supported environments Distributed Disaster Recovery with GDPS Supported environments Distributed Disaster Recovery with TPC-R Supported operating systems for the PowerHA adapter Supported operating systems for the FOC adapter Supported operating systems for the VCS adapter Default directories Worksheet to define disaster recovery topology Worksheet to define disaster recovery hardware Worksheet to define disaster recovery workload Archives for AIX platforms Archives for Linux on System x Archives for Linux on System z Recommended end-to-end adapter and JEE framework settings in a DR setup Archives for applying service to remote Agentless Adapter Default user IDs and groups of the System Automation Application Manager Role to group assignments: Role to user ID assignment Resources in the automation policy for the end-to-end automation manager Resources in the high availability policy for a disaster recovery setup Resources in the PowerHA adapter automation policy Resources in the VCS adapter automation policy Generated input properties files System Automation Application Manager event class types Common System Automation status attributes used in resource status change events (alerts.status) alerts.status: Resource, domain, event identification alerts.status: Other attributes used in resource status change events alerts.status: Domain status change events Existing rules file fields for System Automation events Compound state to OMNIbus severity mapping EIF severity to OMNIbus severity mapping Event Severity to TBSM State Mapping Text-based incoming status rules for TBSM Launch-in-context action parameters eezdla return codes Command line options for the discovery library adapter OSLC tab of the configuration utility 291 Copyright IBM Corp. 2006, 2015 ix

12 x Tivoli System Automation Application Manager V : Installation and Configuration Guide

13 About this book Who should read this guide This guide provides information needed to plan, install, configure, and upgrade System Automation Application Manager (from here on referred to as System Automation Application Manager) and the automation adapters for the following clustering products: v High Availability Cluster Multi-Processing / PowerHa (from here on referred to as HACMP ) v Microsoft Cluster Server / Failover Cluster (from here on referred to as MSCS) v VERITAS Cluster Server (from here on referred to as VCS. This guide is for planners, installers, and administrators who plan to install and configure System Automation Application Manager. Where to find more information The System Automation library contains the following books, including this one, describing System Automation Application Manager: v System Automation Application Manager Administrator's and User's Guide, SC v System Automation Application Manager Installation and Configuration Guide, SC v System Automation Application Manager Reference and Problem Determination Guide, SC You can download the books at: More information about System Automation for Multiplatforms can be found in the following books: v System Automation for Multiplatforms Administrator's and User's Guide, SC v System Automation for Multiplatforms Installation and Configuration Guide, SC v System Automation for Multiplatforms Reference, SC v System Automation for Multiplatforms High Availability Policies Guide, SC You can download the books at: The System Automation home page contains useful up-to-date information, including support links and downloads for maintenance packages. The System Automation Application Manager home page is: The System Automation for Multiplatforms home page is: Copyright IBM Corp. 2006, 2015 xi

14 The System Automation for z/os home page is: Conventions used in this guide ISO 9000 Related information This guide uses several conventions for special terms and actions and operating system commands and paths. Typeface conventions This guide uses the following conventions: v Typically, file names, directories, and commands appear in a different font. For example: File name: setup.jar Directory: /etc/hosts Command: eezdmn -start v Variables are either italicized, enclosed in brackets, or both. For example: v Frequently, variables are used to indicate a root installation directory: Root installation directory of System Automation Application Manager: <EEZ_INSTALL_ROOT> or EEZ_INSTALL_ROOT WebSphere Application Server root installation directory: <was_root> or was_root Runtime root directory of Integrated Solutions Console: <isc_runtime_root> or isc_runtime_root v Directories are shown with forward slashes (/), unless operating-system specific information is provided. On Windows systems, you should use backward slashes (\) when typing at a command line, unless otherwise noted. v Operating-system specific information is provided. For example: AIX, Linux: /opt/ibm/tsamp/eez Windows: C:\Program Files\IBM\tsamp\eez ISO 9000 registered quality systems were used in the development and manufacturing of this product. Find out where to find more information about products related to System Automation Application Manager. Knowledge Centers: WebSphere Application Server publications: The latest versions of all WebSphere Application Server publications can be found in the WebSphere Application Server Knowledge Center. xii Tivoli System Automation Application Manager V : Installation and Configuration Guide

15 How to obtain publications How to reach us by IBM DB2 publications: The latest versions of all DB2 publications can be found in the DB2 for Linux UNIX and Windows Knowledge Center. IBM GDPS publications: The latest versions of all GDPS publications can be found in the Tivoli NetView Monitoring for GDPS Knowledge Center. IBM Redbooks publications: The following publications are available at: v GDPS Family: An Introduction to Concepts and Capabilities IBM Tivoli Common Reporting (TCR) publications: The latest versions of all publications can be found in the Tivoli Common Reporting Knowledge Center. IBM Tivoli Storage Productivity Center for Replication (TPC-R) publications: The latest versions of all publications can be found in the Tivoli Storage Productivity Center for Replication Knowledge Center. IBM Support Assistant (ISA): ISA Publications are available on the IBM Support Assistant web site at: The System Automation publications are also available (valid at the time of release) at these Web sites: If you would like to contact us by , send your comments to eservdoc@de.ibm.com About this book xiii

16 xiv Tivoli System Automation Application Manager V : Installation and Configuration Guide

17 What's new in this release Get a quick overview about the new features of System Automation Application Manager version 4.1. New DASH user interface for the operations console The System Automation operations console is completely redesigned, based on Jazz for Service Management and Dashboard Application Services Hub. Key enhancements are: v More flexible and dynamic views v Create your own dashboards based on Dashboard Application Services Hub capabilities. Customize predefined dashboards, for example change widget layout or configure displayed columns. The predefined dashboard Domain and Automation Health provides a graphical status overview and drill down capabilities for more details. v Use the predefined dashboard Explore Automation Nodes to explore all domains and nodes that are connected to System Automation Application Manager and drill down to the hosted resources. v The predefined dashboard Operate End-to-End Resources displays automated resources and a graphical view of resource relationships. v You can now allow user requests against multiple resources at a time v You can allow priorities on requests. v The visualization of different group types is improved. v Performance of System Automation operations console is improved. Server group The server group is a new policy element, designed to group resources together, which have to react to dynamic load requirements by adding members if needed. The server group introduces automatic failover capabilities for its members and allows to dynamically start and stop spare member by modifying the availability target of the server group. Policy editor provided in the DASH operations console (V ) The policy editor, which is available in System Automation Application Manager, is now integrated into the DASH operations console. New versions of the middleware software (V ) Starting with fix pack , System Automation Application Manager exploits new features of the middleware software. Therefore, upgrade the middleware software, in particular the version of Jazz for Service Management, if you upgrade System Automation Application Manager to service level or higher. Copyright IBM Corp. 2006, 2015 xv

18 xvi Tivoli System Automation Application Manager V : Installation and Configuration Guide

19 Chapter 1. Planning Planning for System Automation Application Manager before introducing its software into your enterprise system helps ensure that the system you implement meets your needs and adapts to your existing infrastructure. This topic describes how to plan for System Automation Application Manager, including assessing your current infrastructure. Planning for System Automation Application Manager Prepare the installation of System Automation Application Manager on AIX and Linux systems. Check out first if you meet all required prerequisites, before you start your installation. System Automation Application Manager manages the system as a whole through connections to these other products. The products are linked together by automation adapters. The adapters for System Automation for Multiplatforms and IBM Tivoli System Automation for z/os are packaged with those products. All other automation adapters are packaged with System Automation Application Manager. Copyright IBM Corp. 2006,

20 SA User Web browser 1 SA Application Manager highly available installed Systems 3 SA Application Manager component or bundled Adapter Other product component (with SA Application Manager Adapter) MS Failover Cluster with SA Application Manager MSCS Adapter HACMP/ PowerHA Cluster with SA Application Manager HAC Adapter Veritas CS Cluster with SA Application Manager VCS Adapter Single Node Systems attached as Remote Endpoints to Agentless Adapter SA Application Manager remotely installed Agentless Adapter Systems SA for Multiplatforms Cluster with SA Application Manager SAM Adapter SA z/os Sysplex with SA Application Manager ING Adapter High Availability / Automation Clusters Systems with ITM / ITCAM agents attached to TEMS ITM / ITCAM TEMS Figure 1. Overview of System Automation product family Packaging You can order System Automation Application Manager as a media pack or download the electronic deliverable from an IBM software distribution download site. The URL for the electronic distribution is sent after purchasing the product. Media shipment There is a separate DVD for each supported operating system. The following table lists the versions of the product DVDs that are available for System Automation Application Manager. To install the product, use the installation wizard file listed in the right column of the table. Table 1. System Automation Application Manager product DVDs. Operating system Product DVD label Installation wizard file AIX Tivoli System Automation Application Manager V4.1 for AIX EEZ4100AIX/AIX/ setup.bin 2 Tivoli System Automation Application Manager V : Installation and Configuration Guide

21 Table 1. System Automation Application Manager product DVDs (continued). Operating system Product DVD label Installation wizard file Linux on System x Linux on System z Tivoli System Automation Application Manager V4.1 for Linux on System x Tivoli System Automation Application Manager V4.1 for Linux on System z EEZ4100I386/i386/ setup.bin EEZ4100S390/s390/ setup.bin For information about the middleware software DVDs that are shipped with System Automation Application Manager, see Contents of the middleware software DVDs on page 51. Electronic distribution Each supported operating system has a separate electronic deliverable. The following tables list the archives that you need to install System Automation Application Manager. Table 2. Archive files of the electronic deliverable Operating system Archive name Description AIX SA_AM_4.1_AIX.bin The archive is self-extracting. Linux on System x SA_AM_4.1_LinSysX.tar To extract the archive GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. Linux on System z SA_AM_4.1_LinSysZ.tar To extract the archive GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. After extracting the archive, the directory structure is identical to the directory structure on the corresponding DVD. Prerequisites Make sure you fulfill the software and hardware requirements for System Automation Application Manager. Supported operating systems System Automation Application Manager supports various versions of AIX and Linux operating systems. The following table lists the operating systems that are supported for System Automation Application Manager, including the local Agentless Adapter. If you want to exploit the Distributed Disaster Recovery functionality, refer to the following tables: v Table 17 on page 28, Supported operating systems for Distributed Disaster Recovery v Table 18 on page 28, Supported operating systems of managed clusters using GDPS for storage replication Chapter 1. Planning 3

22 v Table 19 on page 29, Supported operating systems of managed clusters using TPC-R for storage replication Table 3. Supported operating systems for System Automation Application Manager Operating system IBM System x 1 Power Systems IBM System z SUSE Linux Enterprise Server 10 (64 bit) SUSE Linux Enterprise Server 11 (64 bit) X X X X Red Hat Enterprise Linux 5 (64 bit) 3 X X Red Hat RHEL Linux 6 (64 bit) X X Red Hat RHEL Linux 7 (64 bit) 4 X X AIX AIX X X The following Service Pack or technology levels are supported, unless one of the notes below indicates a more specific minimum requirement. v Service Pack levels of the listed supported SUSE versions or higher. v Service Pack levels of the listed Red Hat version or higher. v Technology levels of the listed AIX versions or higher. Note: 1. IBM System x with IA32, EM64T, or AMD64 architecture. Any other systems with IA32, EM64T, or AMD64 architecture are also supported. Systems with IA64 architecture are not supported. All supported operating systems are also supported when running under VMware. All listed Linux operating systems running under the Red Hat Enterprise Virtualization Hypervisor (RHEV-H) KVM version 5.4 or higher are also supported. However, the live migration functionality provided by this hypervisor is not supported. 2. System Automation Application Manager does not support AIX Workload Partitions (WPAR) mobility or relocation. 3. The supported minimum level is Red Hat Enterprise Linux Platform support is introduced with fix pack For more information, see Installing on new operating systems on page 76. Installing prerequisites Before you start to install System Automation Application Manager, check if all prerequisites are installed or configured. The following prerequisites must be satisfied before you can start the installation wizard for System Automation Application Manager: v Jazz for Service Management including the 32-bit version of WebSphere Application Server and the Dashboard Application Services Hub must be 4 Tivoli System Automation Application Manager V : Installation and Configuration Guide

23 installed as described in Installing Jazz for Service Management on page 55. No other WebSphere Application Server product installation must exist on the system. v Global security must be enabled. v Java 2 security must be disabled, otherwise the installation fails. Java 2 security is not supported. v A DB2 server must be installed as described in Installing a DB2 server on page 51. The DB2 server instance must be running and accepting client connections. For more information about setting up the DB2 environment, see IBM DB2 Administration Guide: Implementation. v A Korn shell must be installed and accessible using /usr/bin/ksh. A Korn shell is required for the system where the Application Manager server is installed as well as for each system where a remote agentless adapter is installed. v The local agentless adapter that is installed as part of System Automation Application Manager requires the 32-bit version of the pluggable authentication module (PAM). v In the current RHEL 5 distributions, the Security-Enhanced Linux ((SELinux) environment is switched on by default. It must be switched off for System Automation Application Manager to work properly. v The user ID that is used to run the installer for System Automation Application Manager must have administrator authority. This user ID is typically "root". v Several 32-bit libraries must be installed on each SLES 10.3 and SLES 11 system, even if a 64-bit kernel is running, before System Automation Application Manager or a remote agentless adapter can be installed. These libraries are contained in the following RPM Package Manager packages: xorg-x11-libs-32bit glibc-32bit libstdc bit (SLES 10.3) libstdc bit (SLES11) v Several 32-bit libraries must be installed on each RHEL 6 or RHEL 7 system, even if a 64-bit kernel is running, before System Automation Application Manager or a remote agentless adapter can be installed. The required libraries are provided by the 32-bit versions of the following RPM Package Manager (RPM): libgcc glibc libstdc++ compat-libstdc++-33 motif libxext.i686 libxrender.i686 libxft.i686 libxtst.i686 Supported versions of IBM Tivoli Monitoring (ITM) You can use the agentless adapter to integrate resources which are monitored by IBM Tivoli Monitoring or by Composite Application Manager. These Tivoli Monitoring managed resources are integrated by using existing Tivoli Monitoring agents. The agentless adapter retrieves monitoring information from Tivoli Monitoring Agents and performs start and stop operations via these agents. Chapter 1. Planning 5

24 The supported IBM Tivoli Monitoring versions for this feature are: v 6.2 v v v The following types of Tivoli Monitoring agents can be integrated: v Application agents (also referred to as non-os agents) and custom agents v OS agents System Automation Application Manager provides predefined templates for the integration of the following agents: v Apache Web Server v WebSphere Application Server v DB2 v Custom agents built with the Tivoli Monitoring Agent Builder v Linux OS Agent v UNIX OS Agent Middleware software requirements Install all required middleware software before you start to install System Automation Application Manager. The following middleware software must be installed on the system on which System Automation Application Manager runs before the component itself can be installed: v DB2: A DB2 server for a local setup or a DB2 JDBC driver for a remote setup. v WebSphere Application Server (32-bit version, Java 7 enabled) v Jazz for Service Management including Dashboard Application Services Hub DB2 setup options The database that is required for System Automation Application Manager is DB2. There are different options how to set up DB2. When you plan to install System Automation Application Manager, decide which option you want to choose. You have the following options: Local DB2 setup The DB2 server is installed and runs on the same node on which System Automation Application Manager is installed. Remote DB2 setup The DB2 server is installed and runs on a node other than the node on which System Automation Application Manager is installed. In this case, you need to install a DB2 JDBC driver on the System Automation Application Manager node. DB2 software prerequisites Before you can install System Automation Application Manager, IBM DB2 must be installed on the system where the database of System Automation Application Manager is hosted. For a new DB2 installation, install IBM DB2 Version 10.1 for Linux, UNIX, and Windows, Limited Use edition, which is bundled with System Automation Application Manager Version 4.1. If you order System 6 Tivoli System Automation Application Manager V : Installation and Configuration Guide

25 Automation Application Manager Version 4.1 after fix pack is available, IBM DB2 Version 10.5 for Linux, UNIX, and Windows, Limited Use edition is bundled with System Automation Application Manager. In this case, you can also install this DB2 version. Alternatively, you can use the following database versions as well: v IBM DB2 for Linux, UNIX, and Window, Workgroup Server Edition, Version 10.1 (64-bit) or higher v IBM DB2 10 for z/os or higher Note: You are not entitled to use the DB2 Enterprise Server Edition that is bundled with Jazz for Service Management for System Automation Application Manager purposes. Local DB2 setup No additional prerequisites are required for a local DB2 setup. If you are using a local DB2 setup, the DB2 definitions are processed by the installation program. It creates the end-to-end automation management database and the database tables during the installation of System Automation Application Manager. Remote DB2 setup Manual installation steps are required for a remote DB2 setup. Before you can install System Automation Application Manager, the following software prerequisites must be manually installed: v A DB2 JDBC driver must be installed on the System Automation Application Manager node. WebSphere Application Server IBM Tivoli System Automation Application Manager supports the 32-bit version of WebSphere Application Server only. Make sure that WebSphere Application Server is configured to run with Java 7. The following application servers are supported: v WebSphere Application Server version and future releases, modifications, and fix packs. WebSphere Application Server version 8.5 Network Deployment is not supported. Check the following publication to find out which requirements need to be met for installing and running WebSphere Application Server Base: v The ReadMe file, which is available on the product DVD "IBM WebSphere Application Server Base Version 8.5". v The "Getting started" topics in the IBM Knowledge Center for IBM WebSphere Application Server, Version 8.5. v An IBM WebSphere Application Server Getting started document is also available on the product DVD for your operating system, where it is also referred to as Installation Guide. Make sure that all requirements for installing and running WebSphere Application Server are met. Otherwise, System Automation Application Manager might not work properly. All versions of WebSphere Application Server publications can be found at: Jazz for Service Management The versions of the Jazz for Service Management components listed below Chapter 1. Planning 7

26 are those contained on the product DVDs and in the corresponding electronic deliverables that you receive when you order System Automation Application Manager 4.1. Starting with fix pack the minimum versions of the Jazz for Service Management components have changed to: v Jazz for Service Management, Version v IBM Dashboard Application Services Hub, Version v IBM WebSphere Application Server, Version If you are planning to upgrade to System Automation Application Manager fix pack or higher, you must also upgrade Jazz for Service Management to the new minimum version. For more information, see Installing a new Jazz for Service Management version on page 58. v The following Jazz for Service Management components are at least required for the System Automation Application Manager server: Jazz for Service Management extension for IBM WebSphere 8.5, Version IBM Dashboard Application Services Hub, Version v IBM WebSphere Application Server Version or higher is supported. You can choose to install WebSphere Application Server when you install Jazz for Service Management, or you can use an existing supported WebSphere Application Server instance. Note: Only the 32-bit version of the IBM WebSphere SDK for Java is supported. v Ensure that enough disk space is available for the installation. At least 3 GBs are required. You can run the prerequisite scanner from the Jazz for Service Management installation package to list the precise requirements that depend on your operating system. To run the prerequisite scanner, enter the following commands: export JazzSM_FreshInstall=True <JazzSM_Image_Home>/PrereqScanner/prereq_checker.sh "ODP,DSH" detail The prerequisite scanner prints the expected disk space and other prerequisites. v You can find the requirements report for IBM Dashboard Application Services Hub on the following web page: System requirements report for IBM Dashboard Application Services Hub v Jazz for Service Management Version documentation v Some extra features of Jazz for Service Management require a database (for example, the registry services). If you plan to use one of those features, you can use one of the following DB2 versions: Version 10.1 Limited Use edition that is bundled with System Automation Application Manager Enterprise Server Edition Version 10.1 (64-bit) that is bundled with Jazz for Service Management Version Supported web browsers System Automation Application Manager has a web-based user interface. It is displayed in a web browser that connects to the Dashboard Application Services Hub on which the System Automation Application Manager dashboards are running. The web browser can run on any system. The following versions of web browsers are supported: 8 Tivoli System Automation Application Manager V : Installation and Configuration Guide

27 v Microsoft Internet Explorer V9 v Microsoft Internet Explorer V10 v Firefox Extended Support Release (ESR) 17 v Firefox Extended Support Release (ESR) 24 For updated information about the support of later browser versions, check the Software Product Compatibility Report for System Automation Application Manager. Hardware requirements Make sure your systems provide the required hardware requirements to install DB2. The hardware requirements listed below refer to the installation of DB2. For more information on hardware requirements for the required middleware software, see Installing the middleware software on page 51. Memory: Make sure you have enough memory available on the server to install System Automation Application Manager. The minimum required memory (RAM) is 4 GB or more to install WebSphere Application Server and System Automation Application Manager on the same server. For large environments, it is recommended to have a system with 8 GB RAM. If you start to install System Automation Application Manager, a memory check is automatically processed. In case the server provides less than 4 GB operational memory, a warning is displayed. In silent installation mode, the warning is written into the log and the installer is stopped. You can start the installation with the command line option -Dskipmemtest=true but you may consider to use the installation wizard instead. Chapter 1. Planning 9

28 Figure 2. Installation wizard: Required RAM information dialog Note: Check if it is required to increase the heap size. For more information, see Modifying available heap size on page 74. TCP/IP connectivity: It is required to install several products to run System Automation Application Manager. Some of these products require TCP/IP connections. You can install DB2, WebSphere Application Server and System Automation Application Manager on one server or on different servers, depending on your architecture. For example: Local DB2 setup: WebSphere Application Server, System Automation Application Manager, and the DB2 server run on the same system. Remote DB2 setup: WebSphere Application Server and System Automation Application Manager run on the same system, while the DB2 server runs on another system. 1. Local DB2 setup: WebSphere Application Server, System Automation Application Manager, and the DB2 server run on the same system. 2. Remote DB2 setup: the WebSphere Application Server and System Automation Application Manager run on the same system, while the DB2 server runs on another system. Provide TCP/IP connections between the following products and System Automation Application Manager components: v WebSphere Application Server and the resource adapters v WebSphere Application Server and the operations console v System Automation Application Manager and the DB2 server Disk space requirements: Check if you have all the required disk, file, directory, and registry space to install System Automation Application Manager. 10 Tivoli System Automation Application Manager V : Installation and Configuration Guide

29 Table 4. Disk space requirements The following disk space requirements must be met to install System Automation Application Manager. Note: The table does not include the space required to install the middleware software. Description Default directory Disk space Installation directory of System Automation Application Manager WebSphere Application Server (where automation manager and operations console are deployed) /opt/ibm/tsamp/eez/ AIX: /usr/ibm/websphere/appserver/ Linux: /opt/ibm/websphere/appserver/ 700 MB 100 MB DB2 database ~db2inst1 120 MB Temporary disk space needed for installation and installation log and response files Configuration file directory and policy pool directory of System Automation Application Manager /tmp/ Note: Make sure your /tmp directory has five times the size of the installation file setup.bin. /etc/opt/ibm/tsamp/eez/cfg/ /etc/opt/ibm/tsamp/eez/policypool/ Tivoli Common Directory /var/ibm/tivoli/common/ 40 MB Installer registry /var/ 1 MB 1 GB 1 MB Preparing for installation Collect all the required information like configuration parameters and user IDs, before you start your installation. Collecting the information The graphical installation of System Automation Application Manager is wizard-driven. Make sure that you specify all required parameters on the installation wizard panels and that your entries are correct. The wizard guides you through the installation and prompts you for installation and configuration parameters. The following tables list the parameters you need to specify on the installation wizard panels, in the order in which they must be specified. Installation directory and Tivoli Common Directory: If you want to use different directory names other than the default names, make sure you are a aware of restrictions. The parameters listed in the following table must always be specified. Chapter 1. Planning 11

30 Table 5. Installation directory and Tivoli Common Directory Parameter Description Default Installation directory name The directory to which the installable features are installed. In this guide, this directory is referred to as EEZ_INSTALL_ROOT. When specifying a directory other than the default, observe the following restrictions: /opt/ibm/tsamp/eez Tivoli Common Directory v v v The directory name has to consist of the platform-specific path separator character and alphanumeric characters (A..Z, a..z, 0..9). The underscore character (_) is allowed. The space and colon characters are not allowed. The Tivoli directory for storing serviceability information. During installation, you are only prompted for input when no Tivoli Common Directory is found on the system. In the Tivoli Common Directory, the subdirectory eez is created for storing product-specific data. In this guide, this directory is referred to as Tivoli_Common_Directory. When specifying a directory other than the default (only possible if no Tivoli Common Directory already exists on the system), observe the following restrictions: /var/ibm/tivoli/common v v v The directory name has to consist of the platform-specific path separator character and alphanumeric characters (A..Z, a..z, 0..9). The underscore character (_) is allowed. The space and colon characters are not allowed. Installation parameters for DB2: Make sure you have all required parameters available that are required to install DB2 on a local or remote server. The parameters listed in the following table must be specified. 12 Tivoli System Automation Application Manager V : Installation and Configuration Guide

31 Table 6. DB2 data for local and remote DB2 setup Parameter Description Default DB2 directory Local DB2 setup: The installation location of the DB2 Database Manager. The location is detected on your system and displayed as the default directory. DB2 JDBC driver path on local system DB2 instance host name DB2 instance port number Database instance owner name If you are using a local DB2 setup, you use the DB2 client that is part of the DB2 server installation. In this case, you need to specify the DB2 server directory. For remote DB2 setup only: Path to the directory where the files DB2 JDBC are located. Remote DB2 setup: The host name of the DB2 instance in which the automation manager and operations console databases are located. The port number of the DB2 instance in which the automation manager and operations console databases are located. Note: The installation wizard can retrieve the valid DB2 instance port number automatically. If you choose not to use this function, the port number will be displayed in the entry field on the corresponding installation wizard window. This is the default port number that is assigned to DB2 during the installation of DB2. However, if this port is not free, a different port number is assigned automatically, which is why you need to check if the default port number is correct. How you determine the correct port number is described in Tivoli System Automation Application Manager, Reference and Problem Determination Guide. The instance owner user ID of the DB2 instance in which the automation manager and operations console databases are located. In a local DB2 setup, this user ID will be used for creating the databases and tables. In a remote DB2 setup, the database and the tables must have already been created. The installation program does no change to DB2 and neither creates a DB nor tables. The user ID will be used by WebSphere Application Server to connect to the automation manager and operations console databases and to select, insert, delete, and update rows in tables db2inst1 Chapter 1. Planning 13

32 Table 6. DB2 data for local and remote DB2 setup (continued) Parameter Description Default Database instance owner password Automation manager database The password for the instance owner user ID of the DB2 instance in which the automation manager and operations console databases are located. Automation manager database for use by WebSphere Application Server. In a local DB2 setup, a database with this name will be created in the DB2 instance related to the specified instance owner. No default value is provided EAUTODB Backend version In a remote DB2 setup, a database with this name must already exist in the remote DB2 instance. Version of the back end DB2: v v v ZOSUDB81: DB2 UDB V8.1 - running on z/os ZOSUDB91: DB2 V9.1 - running on z/os DIST: DB2 LUW- running on distributed system DB2_OPTN_UDB WebSphere Application Server installation parameters: The parameters listed in the following table are detected during the installation of System Automation Application Manager. Note: WebSphere Application Server administrative security must be enabled before you install System Automation Application Manager. Table 7. WebSphere Application Server installation parameters Parameter Description Default WebSphere Application Server directory WebSphere Application Server (WAS) profile name WebSphere Application Server (WAS) server name WAS Admin User ID WAS Admin User Password The installation location of WebSphere Application Server. There must be exactly one installation of WebSphere Application Server on your system. The WebSphere Application Server profile to be used for the automation manager and the operations console. The server to be used for the automation manager. The user ID of the WebSphere Application Server administrator. The password of WebSphere Application Server administrator user ID. The location is detected on your system and displayed as the default directory. All existing profiles are detected on your system and displayed in a single-choice list. The server name is detected on your system and displayed as default value. No default value is provided. No default value is provided. 14 Tivoli System Automation Application Manager V : Installation and Configuration Guide

33 Table 8. Installation parameters Event console connection configuration data: Make sure you have the required installation parameters available, if you want to utilize OMNIbus for end-to-end automation management events. System Automation Application Manager can send EIF events about state changes of automated resources to IBM Tivoli Netcool/OMNIbus (OMNIbus). Parameter Description Default Host Name The name of the host where the OMNIbus Probe for Tivoli EIF is installed. Port Number The port number for the OMNIbus Probe for Tivoli EIF localhost Table 9. End-to-end automation domain name For more information about utilizing OMNIbus for end-to-end automation management, see IBM Tivoli Netcool/OMNIbus on page 216. Name of the end-to-end automation domain: Be aware of the naming rules for the end-to-end automation domain name. Parameter Description Default Automation domain name The domain name must be unique and may not be used for any other automation domain. The domain name must contain a maximum of 64 characters. The characters used for the domain name are limited to the following ASCII characters: A Z, a z, 0 9,. (period), and _ (underscore). FriendlyE2E Obtaining the WebSphere Application Server user ID The end-to-end automation engine requires a WebSphere Application Server user ID to access the JEE framework. The user ID is created during the installation of System Automation Application Manager. Table 10. WebSphere Application Server user ID In the installation wizard you need to specify the user ID and the password. Parameter Description Default User ID WebSphere Application Server user ID for the end-to-end automation engine. eezdmn Password Password of the user ID <none> Obtaining the System Automation Administrator user ID During the installation of System Automation Application Manager, the initial Tivoli System Automation administrator user is created in WebSphere Application Server and authorized for all tasks and actions that can be performed from the System Automation operations console. Chapter 1. Planning 15

34 In the installation wizard you need to specify the data listed in the following table: Table 11. System Automation Administrator user ID Parameter Description Default User ID User ID of the System Automation operations console administrator eezadmin Password Password of the user ID <none> Installation media System Automation Application Manager can be ordered from IBM as a media pack or downloaded as an Electronic Software Distribution (ESD) image from an IBM software distribution download site. There are multiple DVDs for each supported platform. This is what the DVD labeled System Automation Application Manager V4.1 for <operating_system_name> contains: v The files for launching the installation wizard v The readme file Table 12. Directories on the product DVD v Directories containing the files required to install components that are embedded into the System Automation Application Manager installation. These are: Directory README license DDL ECExtension <PLATFORM>¹ DOCS INTEGRATION Content For example, copyright notices and license agreements License key Scripts for creating DB2 databases and tables when remote DB2 setup is used setup.jar Product installer and files needed for installing the product Documentation Assets that integrate System Automation Application Manager and other IBM products. Note: AIX <PLATFORM> is one of the following: i386 (Linux on System x) s390 (Linux on System z) Supported languages System Automation Application Manager supports English and a set of other languages. In addition to English, System Automation Application Manager supports the following languages: v German v Spanish v French 16 Tivoli System Automation Application Manager V : Installation and Configuration Guide

35 v Italian v Japanese v Korean v Brazilian Portuguese v Simplified Chinese v Traditional Chinese Planning for an LDAP user registry Information about users and groups is stored in a user registry. By default, the WebSphere Application Server that is installed with Jazz for Service Management and is used by System Automation Application Manager is configured to use a local file-based user repository. Companies often use a central user registry that is based on the Lightweight Directory Access Protocol (LDAP) to manage users and groups company-wide and provide single sign-on to every service. Examples for LDAP servers: v IBM Tivoli Directory Server v Resource Access Control Facility (RACF ) v Windows Server Active Directory v OpenLDAP You can set up an LDAP server and create an LDAP user registry to use with System Automation Application Manager. The WebSphere Application Server uses this registry for user authentication and the retrieval of information about users and groups to run security-related functions. There are two different setup types: Pre-defined The LDAP user repository is configured in the WebSphere Application Server before the installation of System Automation Application Manager. Post-defined Planning for the agentless adapter The installer of System Automation Application Manager can already use the configured LDAP repository for user creation and role assignments. The LDAP user repository is configured in the WebSphere Application Server after the installation of the System Automation Application Manager. If you reconfigure the user repository after you installed System Automation Application Manager, you must complete extra steps to port from a file-based repository to an LDAP user repository. Decide if you want to install the agentless adapter local or remote. Installation for the local agentless adapter and remote Agentless Adapters is performed in different ways. The local agentless adapter is automatically installed together with the System Automation Application Manager product as described in Installing System Automation Application Manager on page 59. You can install remote agentless adapters on systems other than the system where the Application Manager is installed. Only one instance of the agentless adapter can be installed on a remote node. Chapter 1. Planning 17

36 For more information, refer to System Automation Application Manager Administrator's and User's Guide. Packaging The remote agentless adapter is shipped with System Automation Application Manager. You can order System Automation Application Manager as a media pack or download the electronic deliverable from an IBM software distribution download site. The URL for the electronic distribution is sent after purchasing the product. Media shipment Install the remote agentless adapter from the DVD Tivoli System Automation Application Manager V4.1 - Remote Clients all platforms. This DVD contains the installation wizards for all supported platforms. To install the adapter, use the installation wizard file listed in the right column of the following table. Table 13. Remote Agentless Adapter product DVD Operating system Windows AIX Linux on System x Linux on POWER Linux on System z Installation wizard file EEZ4100Remote\Windows\ALAdapt\setup.exe EEZ4100Remote/AIX/ALAdapt/setup.bin EEZ4100Remote/I386/ALAdapt/setup.bin EEZ4100Remote/PPC/ALAdapt/setup.bin EEZ4100Remote/S390/ALAdapt/setup.bin Electronic distribution There is a separate electronic deliverable for each supported operating system. The following tables list the archives that you need to install the remote agentless adapter. Table 14. Archive files of the electronic deliverable Operating system Archive name Description Windows AIX Linux on System x Linux on POWER Linux on System z SA AM 4.1 RemoteClient Windows.exe SA AM 4.1 RemoteClient AIX.bin SA AM 4.1 RemoteClient LinSysX.tar SA AM 4.1 RemoteClient LinPower.tar SA AM 4.1 RemoteClient LinSysZ.tar The archive is self-extracting. The archive is self-extracting. To extract the archive GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. To extract the archive GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. To extract the archive GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. After extracting the archive, the directory structure is identical to the directory structure on the corresponding DVD. 18 Tivoli System Automation Application Manager V : Installation and Configuration Guide

37 Prerequisites You can install the remote agentless adapter on various versions of Windows, AIX, and Linux operating systems. The following table lists the operating systems that are supported by remote agentless adapters. For a list of operation systems where remote applications that are managed by an agentless adapter may run, see Supported operating systems for non-clustered nodes managed by the agentless adapter on page 20. The operating system versions that are supported by the local agentless adapter are identical to the operating systems versions that are supported by System Automation Application Manager in general. Refer to Supported operating systems on page 3 for the corresponding list. Table 15. Supported operating systems for remote agentless adapters Operating system IBM System x 1 Power Systems IBM System z SUSE Linux Enterprise Server 10 (64 bit) SUSE Linux Enterprise Server 11 (64 bit) X X X X X X Red Hat Enterprise Linux 5 (64 bit) 2 X X X Red Hat RHEL Linux 6 (64 bit) X X X Red Hat RHEL Linux 7 (64 bit) 3 X X X AIX 6.1 AIX 7.1 Windows Server 2012 R1 Windows Server 2012 R2 X X X X Note: 1. IBM System x with IA32, EM64T, or AMD64 architecture. Any other systems with IA32, EM64T, or AMD64 architecture are also supported. Systems with IA64 architecture are not supported. All supported operating systems are also supported when running under VMware. All listed Linux operating systems running under the Red Hat Enterprise Virtualization Hypervisor (RHEV-H) KVM version 5.4 or higher are also supported. 2. The supported minimum level is Red Hat Enterprise Linux Platform support is introduced with fix pack Note: 1. The agentless adapter requires the 32-bit version of the pluggable authentication module (PAM) on all operating systems other than Windows. 2. On AIX systems, a 32-bit version of Java 6, Java 7 or Java 7.1 is required with the following minimum Service Refresh levels: v Java 6 SR9 FP1: AIX package Java6.sdk v Java 7.0 SR8: AIX package Java7.jre/Java7.sdk v Java 7.1 SR2: AIX package Java71.jre/Java71.sdk Chapter 1. Planning 19

38 Supported operating systems for non-clustered nodes managed by the agentless adapter The agentless adapter manages non-clustered nodes on various versions of Windows, AIX, Linux, Solaris, z/os, and HP-UX operating systems. Remote applications managed by the agentless adapter via remote protocols such as SSH can be located on one of the following supported operating systems: Table 16. Supported operating systems for non-clustered nodes managed by the agentless adapter Operating system Windows Server 2000 IBM System x 1, 2 32 bit 64 bit x Power Systems 2 IBM System z 2 Other platforms 2 Windows Server 2003 x x IA64 Windows XP x Windows Vista x x IA64 Windows Server 2008 R1 x x IA64 Windows Server 2008 R2 x IA64 Windows 7 x x Windows 8 Windows Server 2012 Windows Embedded POSReady x x Windows Embedded Standard x x Windows Embedded Enterprise x x AIX 5.2 AIX 5.3 (AIX 5L Version 5.3) ML 4 AIX 6.1 AIX 7.1 SUSE Linux Enterprise Server 8 x x x x SUSE Linux Enterprise Server 9 x x x x IA64 SUSE Linux Enterprise Server 10 x x x x IA64 SUSE Linux Enterprise Server 11 x x x x IA64 SUSE Linux Enterprise Server 12 x x x x IA64 SLED 10 x x SLED 11 x x Red Hat RHEL Linux 3 AS x x x x Red Hat RHEL Linux 4 AS x x x x IA64 Red Hat RHEL Linux 5 x x x x IA64 Red Hat RHEL Linux 6 x x x x IA64 Red Hat RHEL Linux 7 x x x x IA64 Red Hat Desktop 5.0 x x Red Hat Desktop 6.0 x x SOLARIS 8 x x SPARC SOLARIS 9 x x SPARC x x x x x x 20 Tivoli System Automation Application Manager V : Installation and Configuration Guide

39 Table 16. Supported operating systems for non-clustered nodes managed by the agentless adapter (continued) Operating system IBM System x 1, 2 32 bit 64 bit Power Systems 2 IBM System z 2 Other platforms 2 SOLARIS 10 x x SPARC z/os V1.6, V1.7, V1.8, V1.9, V1.10, V1.11, V1.12, V HP-UX 11i (32 bit) x PA-RISC, IA64 Note: 1. IBM System x with IA32, EM64T, or AMD64 architecture. Any other systems with IA32, EM64T, or AMD64 architecture are also supported. All supported operating systems are also supported when running under VMware. 2. Secure communications with targets, using SSH Protocol (SSH version 2), requires the use of v OpenSSH or higher v AIX targets: OpenSSH 4.7 v Sun targets: SSH 1.1 v v z/os targets: OpenSSH package provided by IBM Ported Tools for z/os SSH packages from other vendors, or earlier versions, are not supported. 3. z/os targets require z/os UNIX System Services (USS) and IBM Ported Tools for z/os (OpenSSH) to be installed. v v v v Documentation for OpenSSH can be found here: z/os UNIX System Services The IBM Ported Tools document is the authoritative source for information describing how to set up OpenSSH on z/os. OpenSSH is supported on z/os 1.4 and higher. Perform the following steps to set up the SSH server: Run COMMON.JCL(OPENSSH). Add SSHD JOBNAME SSHD5 ; SSH Server to the AUTOLOG section of USER.PARMLIB(TCPPROF2) Add 22 TCP SSHD5 ; SSH Server to the PORT section of USER.PARMLIB(TCPPROF2) Edit /etc/ssh/sshd_config, uncomment the UsePrivilegeSeparation parameter and change it to no. Re-IPL, the server should be started by TCP/IP. Browse /tmp/syslogd/ auth.log and check for a message stating sshd : Server listening on port 22. to verify if the server is started. Required settings for target machines that host IBM.RemoteResource resources The agentless adapter uses the IBM Remote Execution and Access (RXA) technology to start, stop, and monitor resources on remote nodes. This topic describes the RXA requirements that must be fulfilled by remote nodes that host the resources defined for an agentless adapter domain. These nodes are referred to as target-nodes. Chapter 1. Planning 21

40 Note: Many RXA operations require access to resources that are not generally accessible by ordinary user accounts. Therefore, for all target platforms, the account names that you use to log onto remote machines must have administrative privileges on each target machine. Windows targets: Some IBM Remote Execution and Access (RXA) operations rely on VBScript and Windows Management Instrumentation (WMI) calls to execute scripts on Windows targets. Windows protocol methods do not work if: v Windows Scripting Host (WSH) or the WMI service is disabled on the target. v VBScript is otherwise disabled. If you intend to access Windows targets using SMB protocol over NetBIOS, which is determined by setsmbtransporttype() : v Port 139 or the port specified by setnetbiosport(), must not be blocked by firewalls or IP security policies. v Enable NetBIOS over TCP/IP must be selected in the Control Panel settings for the machine's network connections properties. To enable NetBIOS over TCP/IP, select: Control Panel > Network and Dial-Up Connections > <some connection> --> Properties > Internet Protocol (TCP/IP) > Advanced > WINS > Enable NetBIOS over TCP/IP. Consult the documentation for your firewall to ensure that these ports are not blocked for inbound requests. To determine if security policies are blocking these ports, select: Start >Settings > Control Panel > Administrative Tools. Depending on whether your policies are stored locally or in Active Directory, the next steps are as follows: v Locally stored policies: Select Administrative Tools > Local Security Policy > IP Security Policies on Local Computer. v Policies stored in Active Directory: Select Administrative Tools > Default Domain Security Settings > IP Security Policies on Active Directory Administrative Tools > Default Domain Controller Security Settings > IP Security Policies on Active Directory Examine the IP security policies, and edit or remove filters that block the ports listed above. The following list contains the ports reserved for NetBIOS. Ensure that all ports currently used by RXA are not blocked. Port Number Use 135 NetBIOS Remote procedure call. At this time, RXA does not use this port. 137 NetBIOS Name service 138 NetBIOS Datagram. At this time, RXA does not use this port. 139 NetBIOS Session (file/print sharing) 445 CIFS (On XP and Win2K) Before you access Inter Process Communications share (IPC$), make sure the server service has been started: Select Control Panel > Administrative Tools > Services > Server. RXA requires that Simple File Sharing is disabled. 22 Tivoli System Automation Application Manager V : Installation and Configuration Guide

41 For an example of a batch file to manage agentless adapter resources on a Windows target node, see System Automation Application ManagerAdministrator's and User's Guide. Windows XP For Remote Execution and Access to work, Windows XP systems must have Simple File Sharing disabled. v Simple Networking forces all logins to authenticate as guest. v A guest login does not have the authorizations necessary for Remote Execution and Access to function. To disable Simple File Sharing, you must: v Step 1: Start the Windows Explorer and select Tools > Folder Options. v Step 2: Select the View tab, scroll through the list of settings until you find Use Simple File Sharing. v Step 3: Remove the check mark next to Use Simple File Sharing. v Step 4: Click Apply and OK. Windows XP includes a built-in firewall called the Internet Connection Firewall (ICF). By default, ICF is disabled on Windows XP systems. Windows XP Service Pack 2 comes with the Windows Firewall on by default. v If the firewall is enabled on a Windows XP or Vista target, it will block attempted accesses by Remote Execution and Access. v On XP Service Pack 2, you can select the File and Printer Sharing box in the Exceptions tab of the Windows Firewall configuration to allow access. Windows Server 2008 On Windows Server 2008 you might need to disable User Account Control if your account is not a domain user account. For details of how to disable User Account Control, refer to the relevant information provided in section Windows Vista. Windows Vista The new User Account Control feature of Windows Vista requires to run several steps before RXA applications can communicate with Vista targets. If you have a domain user account, ensure that the local and the target machine are both members of a Windows domain. If you are a member of a local administrators group and you use a local user account, complete the three steps to be able to run administrative tasks on the target machine. Step 1. Enable the built-in Administrator account and use it to connect. To enable the built-in Administrator account, open the Windows Control Panel and select Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options. Then double-click Accounts: Administrator account status and select Enable. Chapter 1. Planning 23

42 Step 2. Step 3. Disable User Account Control if a different Administrator user account is used to connect to the Vista target. To disable User Account Control, open the Windows Control Panel and select Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options. Then double-click User Account Control: Run all administrators in Admin Approval Mode and select Disable. Reboot your system. Disable User Account Control when you administer a workstation with a local user account (Security Account Manager user account). Otherwise, you don't connect as a full administrator and are not able to perform administrative tasks. To disable User Account Control, run the following tasks: 1. Select Start > Run, type regedit and then press ENTER. 2. Locate and then select the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 3. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps: v On the Edit menu, point to New, and click DWORD Value. v Type LocalAccountTokenFilterPolicy and press ENTER. v Right-click LocalAccountTokenFilterPolicy and then select Modify. v In the Value data box, type 1 and click OK. v Restart your computer. Alternatively, you can manually modify the registry entry by typing the following command line: cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f Windows 7 On Windows 7, the default start-up type for the Remote Registry service is manual. The Remote Registry service must be running to enable RXA. To check whether the Remote Registry service is enabled and started: Step 1 Go to Start. Step 2 Type services.msc and press ENTER. Step 3 When the Microsoft Management Console starts, ensure that the service status is started. If not, right-click Remote Registry and click Start. To avoid problems with the manual start up, set the Remote Registry service start-up type to automatic. If you want to automatically start the service after the server boot: 1. Right-click Remote Registry and select Properties. 2. In the Start-up type option, choose Automatic. 3. Click Apply and OK. When the system starts, Remote Registry starts automatically. 24 Tivoli System Automation Application Manager V : Installation and Configuration Guide

43 Windows Vista FDCC (Federal Desktop Core Configuration) With Windows Vista FDCC custom security settings, it is impossible to connect to this operating system using RXA. Perform the following steps on Windows Vista FDCC to enable RXA to connect to this operating system: 1. Allow File and Printer Sharing with the firewall. Enable the inbound file and printer exception using the Local Group Policy Editor: a. Go to Start. b. Type gpedit.msc and press ENTER. c. Go to: Local Computer Policy > Computer Configuration > Administrative Templates > Network > Network Connections > Windows Firewall > Standard Profile and enable Windows Firewall. Then allow inbound file and printer sharing exception. 2. Turn off the User Account Control. 3. Start the Remote Registry service. Windows Vista FDCC requires authentication using NTLMv2 protocol. Support for this protocol is implemented in RXA and is enabled by default. Note: 1. Changing Windows Vista FDCC settings makes them non-compliant with FDCC. 2. RXA is tested with Windows Vista FDCC image that can be found on the website of National Institute of Standards and Technology. Unix and Linux targets: IBM Remote Execution and Access (RXA) does not supply SSH code for UNIX machines. Ensure SSH is installed and enabled on any target you want to access using SSH protocol. OpenSSH 3.71 or higher contains security enhancements not available in earlier releases. Remote Execution and Access cannot establish connections with any UNIX target that has all remote access protocols (rsh, rexec, or ssh) disabled. In all UNIX environments except Solaris, the Bourne shell (sh) is used as the target shell. On Solaris targets, the Korn shell (ksh) is used instead due to problems encountered with sh. In order for RXA to communicate with Linux and other SSH targets using password authentication, you must 1. Edit the file /etc/ssh/sshd_config on target machines and set: PasswordAuthentication yes (the default is 'no') 2. Now stop and restart the SSH daemon using the following commands: /etc/init.d/sshd stop /etc/init.d/sshd start In order to use SFTP for file transfers, in addition to calling SSHProtocol.setUSESFTP(true), make sure that the SFTP server is enabled on the target machine. Note that the location of the sftp-server is OS dependent. It is typically found in the following locations: v Solaris: /usr/lib/ssh/sftp-server Chapter 1. Planning 25

44 v Linux: /usr/libexec/openssh/sftp-server v HP-UX: /opt/ssh/libexec/sftp-server v AIX: /usr/sbin/sftp-server The sshd_config file contains a line similar to the one below. Make sure the line that enables the sftp-server subsystem is not commented out, and that it points to the OS-specific location of the sftp-server subsystem. For example: Subsystem sftp /one_of/the_paths/shown_above z/os targets: z/os targets must have z/os UNIX System Services (USS) and IBM Ported Tools for z/os (OpenSSH) installed. You can order IBM Ported Tools (OpenSSH) and download the documentation from IBM Ported Tools for z/os. The IBM Ported Tools document describes how to set up OpenSSH on z/os. OpenSSH is supported on z/os 1.4, and newer releases. The following steps are used during IBM Remote Execution and Access (RXA) testing to set up the SSH server. Refer to IBM Ported Tools for z/os: OpenSSHUser's Guide if these steps do not work for you. Step 1 Run COMMON.JCL(OPENSSH). Planning for high availability Step 2 Add "SSHD JOBNAME SSHD5 ; SSH Server" to the AUTOLOG section of USER.PARMLIB(TCPPROF2). Step 3 Add "22 TCP SSHD5 ; SSH Server" to the PORT section of USER.PARMLIB(TCPPROF2). Step 4 Edit /etc/ssh/sshd_config, uncomment the "UsePrivilegeSeparation" parameter and change it to no. Step 5 Re-IPL, the server should be started by TCPIP. You can verify it is up by browsing /tmp/syslogd/auth.log and looking for a message stating "sshd : Server listening on port 22." Provide and configure the necessary prerequisites before you start to install the high availability setup. The following prerequisites must be met, if you want your system to be highly available: v Either 2 or 3 nodes must be part of the System Automation for Multiplatforms domain. v System Automation for Multiplatforms must be installed on all nodes with a minimum level of 3.1 or 2.3. If you use V2.3, the Distributed Disaster Recovery feature components are not part of the policy. v Make sure all prerequisites of the respective System Automation for Multiplatforms version that you are using are met. Check the System Automation for Multiplatforms documentation for further details. v IBM.StorageRM must be installed on all nodes. On Linux, the default installation includes IBM.StorageRM. If you use System Automation for Multiplatforms V2.3 on AIX, IBM.StorageRM is optionally. 26 Tivoli System Automation Application Manager V : Installation and Configuration Guide

45 v A virtual IP address must be available for the WebSphere Application Server. See the Host name or IP address field on the Domain tab of the Automation Manager Common Configuration dialog. To start the dialog, enter cfgeezdmn on the command prompt. For more information, see Domain tab on page 106. v A shared volume must be available for the System Automation Application Manager policy pool. See the Policy pool location field on the Domain tab of the Automation Manager Common Configuration dialog. To start the dialog, enter cfgeezdmn on the command prompt. For more information, see Domain tab on page 106. v If you want to include DB2 in your high availability policy, a shared volume must be available for the DB2 database. See the DB2 tab in configuration dialog cfgeezdmn. v If you want to include the System Automation Application Manager Agentless Adapter in your high availability policy, provide a shared volume for its policy pool. See the Policy pool location field in Adapter tab on page 128. v Enable the following ports in the firewall software for the communication between agentless adapter and target non-clustered nodes: UNIX SSH protocol ssh 22/TCP Windows WIN protocol Direct hosted "NetBIOS-less" SMB traffic uses ports microsoft-ds microsoft-ds 445/TCP 445/UDP For NetBIOS over TCP (NBT) enable the following ports nbname nbname nbdatagram nbsession 137/UDP 137/TCP 138/UDP 139/TCP v System Automation Application Manager must be installed on all nodes including the middleware (DB2, WebSphere Application Server). v Installation parameters for DB2 and the WebSphere Application Server must be the same on all nodes to allow these applications to move to another node seamlessly. These parameters are: 1. WAS - Application server name 2. WAS - Application server port 3. WAS - Profile directory 4. DB2 installation directory 5. DB2 instance owner user ID 6. DB2 instance owner mount point Planning for Distributed Disaster Recovery Distributed Disaster Recovery is shipped with System Automation Application Manager. Packaging The Distributed Disaster Recovery functionality is installed as part of the System Automation Application Manager installation. If you wish to exploit the Distributed Disaster Recovery functionality, it is not required to install additional programs. Chapter 1. Planning 27

46 Prerequisites The supported operating systems depend on the storage replication technology, which you are planning to use. The functionality provided by the Distributed Disaster Recovery feature is available on the operating systems listed in Supported hardware and operating systems. Supported hardware and operating systems Hardware and operating system prerequisites vary depending on the storage replication technology, that is used: Distributed Disaster Recovery with GDPS, or Distributed Disaster Recovery with TPC-R. The following tables show the operating system platforms that are supported by the Distributed Disaster Recovery feature. Distributed Disaster Recovery The supported operating systems for Distributed Disaster Recovery are listed in Table 17 Distributed Disaster Recovery with GDPS If you use Geographically Dispersed Parallel Sysplex (GDPS) for storage replication, the supported operating systems for clusters that are managed by the Distributed Disaster Recovery feature are listed in Table 18. Distributed Disaster Recovery with TPC-R If you use Tivoli Storage Productivity Center for Replication (TPC-R) for storage replication, the supported operating systems for clusters that are managed by the Distributed Disaster Recovery feature are listed in Table 19 on page 29. Table 17. Supported operating systems for Distributed Disaster Recovery Operating system: System x Power Systems System z SUSE Linux Enterprise Server 10 (64 bit) SUSE Linux Enterprise Server 11 (64 bit) Red Hat RHEL 5.0 AS (64 bit) Red Hat RHEL 6.0 AS (64 bit) TPC-R TPC-R TPC-R TPC-R GDPS GDPS GDPS GDPS AIX 6.1 TPC-R GDPS AIX 7.1 TPC-R GDPS Table 18. Supported operating systems of managed clusters using GDPS for storage replication Operating system: System x Power Systems System z SUSE Linux Enterprise Server 10 (64 bit) SUSE Linux Enterprise Server 11 (64 bit) Red Hat RHEL 5.0 AS (64 bit) SAMP, agentless adapter 2 SAMP, agentless adapter 2 SAMP, agentless adapter 2 SAMP, agentless adapter 2 SAMP, agentless adapter 2 SAMP, agentless adapter 2 SA MP, agentless dapter 2 SA MP, agentless adapter 2 SA MP, agentless adapter 2 28 Tivoli System Automation Application Manager V : Installation and Configuration Guide

47 Table 18. Supported operating systems of managed clusters using GDPS for storage replication (continued) Operating system: System x Power Systems System z Red Hat RHEL 6.0 AS (64 bit) SAMP, agentless adapter 2 SAMP, agentless adapter 2 SA MP, agentless adapter 2 AIX 6.1 SAMP, agentless adapter 2, PowerHA 1 AIX 7.1 SAMP, agentless adapter 2, PowerHA 1 Note: 1. Non-stretched clusters: System Automation for Multiplatforms Stretched clusters: PowerHA 2. Agentless adapter represents the non-clustered nodes managed by the agentless adapter that is part of the System Automation Application Manager product. The operating systems listed in Supported operating systems for non-clustered nodes managed by the agentless adapter on page 20 are supported. However, GDPS storage replication is not generally supported for these additional operating systems (but this is dependent upon your own testing activities). Table 19. Supported operating systems of managed clusters using TPC-R for storage replication Operating system: System x Power Systems System z SUSE Linux Enterprise Server 10 (64 bit) SUSE Linux Enterprise Server 11 (64 bit) Red Hat RHEL 5.0 AS (64 bit) Red Hat RHEL 6.0 AS (64 bit) AIX 6.1 AIX 7.1 SA MP SA MP SA MP SA MP SA MP SA MP SA MP SA MP SA MP, PowerHA SA MP, PowerHA The operating systems of managed clusters correlate with the operating systems that are supported by the end-to-end automation adapters. Automation adapters are used to integrate the corresponding first level automation domains into the end-to-end automation environment. In Table 18 on page 28 and Table 19, SA MP represents the end-to-end automation adapter that is part of the System Automation for Multiplatforms product. For more specific information, see the operating system support table in Table 3 on page 4. PowerHA represents the High Availability Cluster Multi-Processing (PowerHA) end-to-end automation adapter that is part of System Automation Application Manager. For more specific information about the operating system details, see Prerequisites on page 32. Chapter 1. Planning 29

48 Supported GDPS environments You can use only specific versions of the Distributed Disaster Recovery feature in combination with GDPS. The following versions for Distributed Disaster Recovery with GDPS are supported. Table 20. Supported environments Distributed Disaster Recovery with GDPS Characteristic Mirroring technique Supported environment PPRC controlled by GDPS (for non-stretched clusters) AIX LVM (for stretched clusters) Hardware Blade Center for System p and System x with Management Module (MM) service processors. Other hardware is supported by a script exit. GDPS/PPRC is a software prerequisite for Distributed Disaster Recovery. For more information about the prerequisites of GDPS/PPRC, see GDPS. If you are planning to implement a setup with a System Automation Application Manager on both sites, additional prerequisites apply. To support this setup, a special type of System Automation Application Manager high availability policy is required. Refer to Planning for high availability on page 26 for detailed planning information regarding the Application Manager high availability policy, with the following exceptions: v Only a single node in the high availability cluster is required v A virtual IP address is not required v A shared volume for the policy pool is not required v You must include DB2 as local EAUTODB. A shared volume for the database is not required, and the database must be on a local disk using DB2 HADR for replication. v You must configure and activate the high availability policy on both sites. Supported TotalStorage Productivity Center for Replication (TPC-R) environments You can use only specific versions of the Distributed Disaster Recovery feature in combination with TPC-R. The following environments for Distributed Disaster Recovery with TotalStorage Productivity Center (TPC-R) for Replication are supported. Table 21. Supported environments Distributed Disaster Recovery with TPC-R Characteristic Mirroring technique Supported environment Metro Mirror Failover or Failback sessions controlled by TPC-R System Automation Application Manager V3.2.2 supports the following TotalStorage Productivity Center for Replication versions: v TotalStorage Productivity Center for Replication V and higher PTFs v TPC-R V or later (for example 4.1.2) and PTFs 30 Tivoli System Automation Application Manager V : Installation and Configuration Guide

49 Note: 1. TotalStorage Productivity Center for Replication is no longer maintained, and is therefore not supported. 2. If you receive an error message that contains the message number of System Automation Application Manager EEZI0063E, refer to the latest release notes to determine which service level is required. Preparing for installation Provide and configure the necessary prerequisites before you start to install your Distributed Disaster Recovery setup. Before you can use Distributed Disaster Recovery, check the following: v For a setup with System Automation Application Manager on both sites, you can configure a specific single-node Application Manager high availability policy that requires DB2 HADR. For this setup you must have a corresponding DB2 HADR license. v Secure Shell (ssh) is set up correctly: In the USS of the GDPS K System, an ssh client must be set up. For more information on how to set up OpenSSH in USS, refer to IBM Ported Tools for z/os User's Guide, SA , which is available at servers/eserver/zseries/zos/unix/port_tools.html). Public key authentication must be used in order to avoid the specification of a password in GDPS v The disaster recovery policy is available and activated, see System Automation Application Manager Administrator's and User's Guide. v The GDPS agent must be configured, see Configuring the GDPS agent on page 176. v The GDPS agent must be started, see System Automation Application ManagerReference and Problem Determination Guide. v The hardware adapter and credentials must be configured, see Configuring the hardware adapter on page 139. v The hardware adapter must be started, see System Automation Application ManagerReference and Problem Determination Guide. v GDPS DCM must be set up. v In particular, verify that: The NetView Event/Automation Service (E/AS) is configured: the default name for the address space is IHSAEVNT The TCP/IP definition contains the port used by the NetView Event/Automation Service DCM is enabled in the System Automation z/os policy The GDPS K System and System Automation Application Manager have exchanged the ssh keys for ssh communication v For general GDPS information, see GDPS Family An Introduction to Concepts and Facilities (SG ) and the GDPS web site at z/advantages/gdps/. Chapter 1. Planning 31

50 Planning for the PowerHA adapter If you are already using IBM High Availability Cluster Multiprocessing for an existing high availability cluster, System Automation Application Manager provides the HACMP adapter to integrate resources that are managed by HACMP into an end-to-end automation environment. Packaging The PowerHA adapter is shipped with System Automation Application Manager. You can order System Automation Application Manager as a media pack or download the electronic deliverable from an IBM software distribution download site. The URL for the electronic distribution is sent after purchasing the product. Media shipment You install the PowerHA adapter from the DVD Tivoli System Automation Application Manager V4.1 - Automation Adapters all platforms. On the DVD, you can find the installation package hac.adapter in the installation source directory EEZ4100Adapters/EEZ4100HACMP/AIX Electronic distribution The name of the archive file of the electronic deliverable for the PowerHA adapter is SA AM 4.1 Adapter AIX.bin To extract the archive, run the executable. After extracting the archive, you can find the installation package hac.adapter in the same directory as on the PowerHA adapter DVD. Prerequisites Make sure you provide the required prerequisites, before you install the PowerHA adapter. The system on which you are installing the adapter must meet the following installation prerequisites: v The PowerHA adapter must not run on a node in the RSCT peer domain. If the node on which the adapter is to run previously was an RSCT peer domain node, the following actions must be taken prior to installing the adapter: 1. The environment variable CT_MANAGEMENT_SCOPE, which may be set to 2 for the RSCT peer domain, must be unset. 2. The RSCT peer domain must be stopped using the command: stoprpdomain <domain-name>. v The 32-bit version of Java 1.4 or Java 5 Service Release 5 or higher must be installed. v SSL or SSH packages must be installed and the sshd subsystem must be running to be able to complete the Replication task of the adapter configuration. v To install and operate the automation adapter on a PowerHA V7.1 system, install the following service levels: 32 Tivoli System Automation Application Manager V : Installation and Configuration Guide

51 For PowerHA V7.1.0: install the PowerHA V7.1 SP6 or higher. Refer to APAR IV For PowerHA V7.1.1: install the PowerHA V7.1.1 SP3 or higher. Refer to APAR IV For more details, see technote TSAAM's HACMP Automation Adapter does not start. Supported operating systems: Table 22. Supported operating systems for the PowerHA adapter Operating System Power Systems AIX 6.1 AIX 7.1 x x Note: Make sure that the version of your adapter is not higher than the version of System Automation Application Manager. Automating the PowerHA adapter It is required to automate the PowerHA adapter, if your PowerHA cluster has more than one node. v The host using the adapter must be able to reach the adapter always through the same service IP without reconfiguration. v If the node on which the adapter runs goes down or the PowerHA cluster services on that node are stopped, the adapter must move to another available node in the cluster to resume the connection with the host using the adapter. For more information about automating PowerHA adapters using the adapter configuration dialog, see Automation tab on page 180. Behavior of the PowerHA adapter Make sure you are familiar with the PowerHA adapter behavior to be able exploit the features and advantages. Before you install and use the PowerHA adapter, make sure you are familiar with the behavior of the PowerHA adapter: v PowerHA clusters are not request- but command-driven. Commands for bringing resources and groups online or offline are performed but not retained as persistent goals. No list of previously issued commands is available, and commands previously issued against a group or resource cannot be canceled. The latest command issued against a group or resource determines whether it should be online or offline. Commands issued by operators have the same priority as commands issued by the end-to-end automation manager. v PowerHA resources and groups cannot be suspended from automation by an end-to-end automation operator. v PowerHA groups have no "real" desired state. PowerHA performs online and offline commands on PowerHA groups by propagating them to member resources. PowerHA groups only act as containers and reflect the state of the contained PowerHA resources. If some of the PowerHA resources in a group were brought online and others offline, the group is in a mixed state - it is not clear whether the desired state of the group is online or offline. Chapter 1. Planning 33

52 Planning for the FOC adapter v PowerHA clusters do not have a policy concept as known by end-to-end automation. For this reason, the Policy Information page for PowerHA domains does not show reasonable information. v If PowerHA groups are referenced in a System Automation Application Manager start dependency then the PowerHA application monitoring mode "startup" or "both" is required to ensure the correct System Automation Application Manager automation behavior. v If you configure dependencies between PowerHA resource groups in the PowerHA cluster, the applications in these PowerHA resource groups are started sequentially. If the monitoring mode "startup" or "both" is used the sequential start sequence does not get affected. To ensure a smooth execution, you can configure several PowerHA application monitors. One of these PowerHA application monitors is configured to check the application startup for the application that is included in the PowerHA resource group with a reference from System Automation Application Manager. This ensures that the application in the PowerHA resource group starts successfully before other dependent System Automation Application Manager resources are started. If you are already using Microsoft Failover Cluster (FOC) for an existing high availability cluster, System Automation Application Manager provides the FOC adapter to integrate resources that are managed by FOC into an end-to-end automation environment. Roadmap Before you install the FOC adapter, you must decide whether you want to make the adapter highly available. The roadmap provides an overview of the steps you need to perform to install and configure the adapter depending on your high availability decision. Roadmap to install a highly available FOC adapter Check the roadmap to install and configure FOC adapters that are highly available. If you want your FOC adapter to be highly available, perform the following steps: 1. Plan and prepare for the installation and configuration of the FOC adapter. For more information, see Planning and preparing for an highly available FOC adapter on page Use the installation wizard to install the adapter on one node in the cluster and generate a response file. For more information, see Using the installation wizard to install the FOC adapter on page To ensure that uniform installation parameters are used, use the response file to install the adapters on the remaining nodes. Response-file driven installation can be performed in silent mode. For more information, see Installing the FOC adapter in silent mode on page 95 or in interactive mode using the installation wizard, see Using the installation wizard to install the FOC adapter on page 94). 4. Configure the adapter on one of the cluster nodes using the adapter configuration dialog (see Configuring the FOC adapter on page 186). 5. To ensure that uniform configuration parameters are used, replicate the adapter configuration files to the remaining nodes. For more information, see Replicating the configuration files to other nodes in the domain on page 192). 34 Tivoli System Automation Application Manager V : Installation and Configuration Guide

53 6. Create the WSFC resources needed for making the adapter highly available. 7. Verify the installation and configuration. For more information, see Verifying the FOC adapter installation on page 95). Roadmap to install a FOC adapter Check the roadmap to install and configure FOC adapters that are not highly available. To install and configure your FOC adapter without high availability, perform the following steps: 1. Plan and prepare for the installation and configuration of the FOC adapter (see Planning and preparing for an highly available FOC adapter on page 37). 2. Use the installation wizard to install the adapter on a cluster node (see Using the installation wizard to install the FOC adapter on page 94). 3. Configure the adapter using the adapter configuration dialog (see Configuring the FOC adapter on page 186). 4. Verify the installation and configuration (see Verifying the FOC adapter installation on page 95). Packaging The FOC adapter is shipped with System Automation Application Manager. You can order System Automation Application Manager as a media pack or download the electronic deliverable from an IBM software distribution download site. The URL for the electronic distribution is sent after purchasing the product. Media shipment You install the FOC adapter from the DVD Tivoli System Automation Application Manager V4.1 - Automation Adapters all platforms. On the DVD, you can find the installation wizard setup.exe in the installation source directory EEZ4100Adapters/EEZ4100MSCS/Windows Electronic distribution The name of the archive file of the electronic deliverable for the FOC adapter is SA AM 4.1 Adapter Windows.exe To extract the archive, run the executable. After extracting the archive, you can find the installation wizard setup.exe in the same directory as on the FOC adapter DVD. Prerequisites Make sure you provide the required prerequisites, before you install the FOC adapter. The Failover Cluster Command Interface feature is required to configure the FOC adapter. Starting with Windows Server 2012 system, this feature is not installed anymore per default as part of the Failover Cluster installation. Chapter 1. Planning 35

54 The system on which you are installing the adapter must meet the following installation prerequisites: v Any of the Windows Server versions listed in Table 23. v System must be a Microsoft Failover Cluster node. v 64 MB RAM is required for running the FOC adapter service. v 40 MB RAM is required for running the adapter configuration dialog. v Disk space requirements: 140 MB for FOC adapter installation. Typically, 6 MB is sufficient during normal operation, however, up to 250 MB may be required for service-related files in the Tivoli Common Directory (log files, FFDC files). Supported operating systems for the FOC adapter FOC adapter run on Windows Server 2012 only. Table 23. Supported operating systems for the FOC adapter Operating System Windows Server 2012 R1 Enterprise Edition (64 bit) Windows Server 2012 R2 Enterprise Edition (64 bit) System x x x Note: Make sure that the version of your adapter is not higher than the version of System Automation Application Manager. Installation directories for the FOC adapter Make sure you install the FOC adapter into the right directory using the right wording. For the FOC adapter installation directory and the Tivoli Common Directory, the following restrictions apply: v The FOC adapter installation directory name must not include the DBCS space character. The SBCS space character is supported. v Tivoli Common Directory: When specifying a directory other than the default, observe the following restrictions: The directory name has to consist of the platform-specific path separator character and alphanumeric characters (A..Z, a..z, 0..9). The colon character is allowed only once, immediately following the drive letter. For example, C:\<directory_name> is allowed, but C:\ <directory_name>:<directory_name> is not allowed. The space character and the underscore character (_) are allowed. Preparing the user account For the installation and operation of the FOC adapter, a domain user account with local administrative rights must be defined in the domain. The domain user account must be a member of the local administrators group on all nodes of the cluster the adapter will manage. Use this user account for the FOC adapter only. 36 Tivoli System Automation Application Manager V : Installation and Configuration Guide

55 Before you install the FOC adapter you must perform the following steps: v Create a domain user account which will run the FOC adapter service later on. This user is referred to as SAAMAdapter hereon. v Grant SAAMAdapter full control permission over the Microsoft Failover Cluster to be managed with the FOC adapter: Open Failover Cluster Management and navigate to this failover cluster. Right-click this failover cluster and select the Properties context menu entry. Select the Cluster Permissions tab and click the Add... button. In the Select Users, Computer, or Groups window specify the SAAMAdapter user account and select the OK button. On the Cluster Permissions tab select the added domain user account in the Group or user names list. Specify Allow on the Full Control entry in the Permissions for... list and click OK. v Log into each system where you want to install the FOC adapter, using an account with administrative rights on the system. Use the local group policy editor to grant the SAAMAdapter user account the right Log on as a service: Open the Start menu and select menu entry Run.... Specify gpedit.msc in the Open input field and click OK. In the Local Group Policy Editor window, select the entry in the tree view: Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. In the list view a list of user rights is shown. Double-click on the right Log on as a service and select the Add User or Group... button. Specify the SAAMAdapter user account and click OK. In the Log on as a service Properties window click the OK. Close the Local Group Policy Editor window. v Log into each system where you want to install the FOC adapter using an account with administrative rights on the system. Use the local users and groups editor to make the SAAMAdapter user account a member of the local Administrators group: Open the Start menu and select menu entry Run.... Specify lusrmgr.msc in the Open input field and click OK. In the Local Users and Groups window select the Groups entry in the tree view. Right-click the Administrators group in the list view and select the Add to Group... context menu entry. In the Administrators Properties window select the Add... button. In the Select Users, Computer, or Groups window specify the SAAMAdapter user account and click OK. In the Administrators Properties window click OK. Close the Local Users and Groups window. Planning and preparing for an highly available FOC adapter You need a virtual IP address to provide an highly available FOC adapter. If you want your FOC adapter to be highly available, perform the following steps: v Obtain a virtual IP address: The FOC adapter will use this IP address for incoming connections Chapter 1. Planning 37

56 Microsoft FOC will make the virtual IP address available on the appropriate Microsoft FOC node v If desired, obtain a network name: If you specify the network name in the FOC adapter configuration, the name will be published to the System Automation Application Manager server. The System Automation Application Manager server will use this network name for connecting to the FOC adapter Microsoft FOC will associate this network name with the virtual IP address on the DNS server that is configured in the Microsoft Windows domain Behavior of the FOC adapter To make sure your system runs well using an FOC adapter, more information is provided to better understand the behavior of the FOC adapter in combination with System Automation Application Manager. Before you install and use the FOC adapter, consider the following aspects: v The FOC adapter runs as a Windows service. This service logs on with the user account you specify during installation. All interactions with Microsoft FOC are performed on behalf of this user account. v If authentication is enforced in the FOC adapter configuration you must specify an arbitrary valid user account with credentials in order to establish a session with the adapter. The user account and password combination is checked on the system where the FOC adapter you are trying to contact is currently running. For this reason you can define and use a Windows domain user account for this purpose. When being prompted for the user account name you must specify the user account in a way which uniquely describes its scope, for example to show which domain the user account belongs to. For domain user accounts you can specify the user account as domain\user or user@domain. Nevertheless, the FOC adapter performs all operations on the Microsoft FOC cluster on behalf of the user account used by the System Automation Application Manager FOC adapter service to log on. v Microsoft FOC clusters are not request- but command-driven. Commands for bringing resources and groups online or offline are performed but not retained as persistent goals. No list of previously issued commands is available, and commands previously issued against a group or resource cannot be canceled. The latest command issued against a group or resource determines whether it should be online or offline. Commands issued by operators have the same priority as commands issued by the end-to-end automation manager. v Microsoft FOC resources and groups cannot be suspended from automation by an end-to-end automation operator. v Microsoft FOC groups have no "real" desired state. Microsoft FOC performs online and offline commands on Microsoft FOC groups by propagating them to member resources. Microsoft FOC groups only act as containers and reflect the state of the contained Microsoft FOC resources. If some of the Microsoft FOC resources in a group were brought online and others offline, the group is in a mixed state - it is not clear whether the desired state of the group is online or offline. v Microsoft FOC clusters do not have a policy concept as known by end-to-end automation. For this reason, the Policy Information page for Microsoft FOC domains does not show reasonable information. v Microsoft FOC does not monitor resources which are not expected to be online. 38 Tivoli System Automation Application Manager V : Installation and Configuration Guide

57 Example: Planning for the VCS adapter A file share resource has two different cluster nodes as possible owners. If the file share is currently defined and working (that is, online) on the first node, Microsoft FOC does not monitor the state of the file share on the second cluster node. Microsoft FOC will not notice a manual definition of the file share on the second node. The FOC adapter does not work around this monitoring approach and is thus not able to reliably report resources offline states. v Microsoft FOC groups reject offline commands in the following cases: The group contains the quorum resource. The group contains the FOC adapter service resource (if the adapter is made highly available). v Microsoft FOC resources reject offline commands in the following cases: The resource is the quorum resource and the quorum resource directly or indirectly depends on the resource to be taken offline. The resource is the FOC adapter service resource (if the adapter is made highly available). If the FOC adapter service resource directly or indirectly depends on the resource to be taken offline (if the adapter is made highly available). v Microsoft FOC nodes reject exclude commands if the adapter is made highly available and the group that contains the FOC adapter service resource is located on the node. In this case, message EEZZ0012E appears indicating that the group in question cannot be taken offline without impacting the FOC adapter. If you are already using Veritas Cluster Server (VCS) for an existing high availability cluster, System Automation Application Manager provides the VCS adapter to integrate resources that are managed by VCS into an end-to-end automation environment. Packaging The VCS adapter is shipped with System Automation Application Manager. You can order System Automation Application Manager as a media pack or download the electronic deliverable from an IBM software distribution download site. The URL for the electronic distribution is sent after purchasing the product. Media shipment You install the VCS adapter from the DVD Tivoli System Automation Application Manager V4.1 - Automation Adapters all platforms. On the DVD, you can find the installation package install.bin in the installation source directory EEZ4100Adapters/EEZEEZ4100VCS/Solaris Electronic distribution The name of the archive file of the electronic deliverable for the VCS adapter is SA AM 4.1 Adapter Solaris.zip Chapter 1. Planning 39

58 To extract the archive, run the executable. After extracting the archive, you can find the installation package install.bin in the same directory as on the VCS adapter DVD. Prerequisites Make sure you that you provide the required prerequisites and operating system, before you install the VCS adapter. The system on which you are installing the adapter must meet the following installation prerequisites: v Solaris 10 on SPARC processors running VCS 4.1 or 5.0 v 64 MB of free RAM Supported operating systems: Table 24. Supported operating systems for the VCS adapter Operating System Solaris 10 (64 bit) Sun SPARC x Note: Make sure that the version of your adapter is not higher than the version of System Automation Application Manager. Automating the VCS adapter If the VCS cluster consists of more than one node, the VCS adapter must be automated. It is required to automate the VCS adapter, if the VCS cluster consists of more than one node, for the following reasons: v The host using the adapter must be able to reach the adapter always through the same service IP without reconfiguration. v If the node on which the adapter runs goes down or the VCS cluster services on that node are stopped, the adapter must move to another available node in the cluster to resume the connection with the host using the adapter. For more information about automating VCS adapters using the adapter configuration dialog, see Automation tab on page 198. Behavior of the VCS adapter for Solaris/SPARC To make sure your system runs well using an VCS adapter, more information is provided to better understand the behavior of the VCS adapter in combination with System Automation Application Manager. Before you install and use the VCS adapter, make sure to be familiar with the behavior of the VCS adapter for Solaris/SPARC: v VCS Global (Remote) clusters are not supported. v VCS Global Service Groups are not supported. v VCS clusters are not request-driven but command-driven. Commands for bringing resources and groups online or offline are performed but not retained 40 Tivoli System Automation Application Manager V : Installation and Configuration Guide

59 as persistent goals. No list of previously issued commands is available, and commands that were previously issued against a group or resource cannot be canceled. The latest command that was issued against a group or resource determines whether it should be online or offline. Commands issued by operators have the same priority as commands issued by the end-to-end automation manager. v VCS resources and groups can be suspended from automation by an end-to-end automation operator. v VCS groups have no "real" desired state. VCS performs online and offline commands on VCS groups by propagating them to member resources. VCS groups only act as containers and reflect the state of the contained VCS resources. If some of the VCS resources in a group were brought online and others offline, the group is in a mixed state - it is not clear whether the desired state of the group is online or offline. v VCS clusters do not have a policy concept as known by end-to-end automation. This is why the Policy Information page for VCS domains does not show reasonable information. Planning for an end-to-end automation policy Before you define your own end-to-end automation policy, check the examples and identify cluster-spanning dependencies. The scope of end-to-end automation policies End-to-end automation management versus first-level automation. Find out, when to use which concept. As described in Tivoli System Automation Application Manager, Administrator s and User s Guide, end-to-end automation management is not intended to take over the role of first-level automation products. The main focus of first-level automation products is to ensure high availability of applications within a cluster of systems. This task must remain as close as possible to the resources for which high availability is to be ensured. The scope of end-to-end automation policies starts where local first-level automation capabilities end - on the border of a first-level automation cluster. Consequently, end-to-end automation policies should only define cluster-spanning relationships and groups. The following examples provide some information on what you must consider when defining resource references for first-level automation resources. Chapter 1. Planning 41

60 Example 1 Example 2 Example 3 Ref 1 Ref 2 Ref 3 Grp A Grp B Res X Grp A Grp B Res X Grp A Grp B Res X Figure 3. Examples for resource references to resources and resource groups. The examples show three resource references that were created for resources or resource groups that are hosted by a first-level-automation domain. These examples are described in the following topics. Example 1 This example illustrates why it is not desirable to create resource references pointing to resources that are members of first-level automation groups if the integrity of first-level automation is to be ensured. For this scenario, assume that: v Resource reference "Ref 1" references an actual resource which is a member of the first-level automation domain group "Grp A". v In the end-to-end automation policy, the desired state Online is defined for resource reference "Ref 1". v In the first-level automation policy, the desired state Offline is defined for both "Grp A" and "Grp B". When the end-to-end automation policy is activated, the end-to-end automation manager issues an Online request against the first-level automation resource that is referenced by "Ref 1". The first-level automation manager receives the request. If the referenced resource is offline, it will try to start the application. If the referenced resource is started due to the request from the end-to-end automation manager, the observed state of "Grp A" changes accordingly. "Grp A" has been defined to be offline. This goal cannot be accomplished by the first-level automation manager because the request on the group member has a higher priority and will be fulfilled. As a result, the compound state of "Grp A" changes, indicating that a problem has occurred. The same is true for "Grp B". An additional problem occurs because of the dependency between "Grp A" and the first-level automation resource "Res X". The administrator who created the first-level automation policy may have assumed that the relationship to "Res X" would always be evaluated before a member of "Grp A" is started. In such a scenario, however, this is not the case and the dependency will not be honored. Example 2 In example 2, resource reference "Ref 2" refers to "Grp A" which is hosted by the same first-level automation domain. This has the following two advantages for the constructs in Example 1: 42 Tivoli System Automation Application Manager V : Installation and Configuration Guide

61 1. All members of "Grp A" will be started or stopped in accordance with the desired group behavior. After the completion of the request from the end-to-end automation manager, "Grp A" changes to a normal end state and no problem will be indicated on the operations console. 2. The relationship to "Res X" will be evaluated when the request is send to "Grp A". This ensures that all required actions will be performed by the first-level automation manager as defined by the administrator of the policy. Only one problem remains: First-level automation cannot reach the desired state defined in the policy for "Grp B". However, in certain circumstances, referencing "Grp A" may reflect the desired behavior within in the scope of end-to-end automation. In such a case, the operator must understand that "Grp B" is in a problem state because end-to-end automation needed to start a member of this group in order to accomplish an end-to-end business goal. Example 3 The two examples above cause undesired behavior. This is not the case in this scenario, where "Ref 3" references the outermost (or top-level) resource group defined in the first-level automation policy. In this scenario, "Ref 3" references the outermost (or top-level) resource group defined in the first-level automation policy. No matter what desired state has been defined for "Ref 3", the first-level automation manager will act according to the request it receives from the end-to-end automation manager and all of the constructs defined in the first-level automation policy will remain in a satisfactory state. Identifying cluster-spanning dependencies Identify first-level automation resources that have cluster-spanning relationships. Such resources are candidates for being referenced in the end-to-end automation policy. Two kinds of dependencies can be expressed in the constructs of an end-to-end automation policy: 1. Grouping concept: defines the general structure of resources and resource groups. 2. Relationship concept: represents run-time dependencies between resources and resource groups. The following topics describe how you can find groups and relationships among automated resources that are hosted by different first-level automation domains. Grouping of resources An enterprise application consists of multiple resources (for example applications and IP addresses) that can belong to different business tiers and areas of responsibility. In order to automate resources effectively, the grouping concept is introduced in end-to-end and first-level automation. Resources need to be restructured from a technical and organizational point of view. Decisions to make: v Which of the resources that are automated by different first-level automation domains need to be available at the same time? Consider these resources to be grouped in collection groups. v Which of the resources that are automated by different first-level automation domains can act as alternatives for other resources in case these fail? Chapter 1. Planning 43

62 Consider these resources to become members of choice groups. v Which resources should be grouped together to ensure that their state can be easily monitored? For example, a group could comprise all resources that will be monitored by the same operator even if the resources are hosted by different first-level automation domains. These resources can also be grouped in collection groups, however this also implies that these resources are started and stopped together and have the same desired state. Organizing resources in groups has the following benefits: v Groups are logical containers that can be controlled as one logical instance. v Groups organize the automated resources in a hierarchical structure. v A group can be composed of resource references and other end-to-end automation groups. The possibility of nesting groups allows you to structure complex environments into several layers. v By encapsulating resources and nested groups within groups, you can organize your automated resources in a hierarchical structure that serves as the logical basis for an end-to-end automation policy. Resources can be gathered in groups according to logical, technical, security, or responsibility criteria. For example: v A resource group can be made up of resource references that reference all resources in an SAP environment. v A group can include all resources that have the same owner. Figure 4. Example for end-to-end automation groups that are distributed over different platforms End-to-end automation groups can be platform-spanning. This means that resource references for resources that are hosted by different first-level domains can be gathered in one group. The resource references that refer to a DB2 group on a first-level z/os sysplex can be gathered in a group together with the application "App", which is physically hosted on an AIX cluster. 44 Tivoli System Automation Application Manager V : Installation and Configuration Guide

63 Relationships Relationships represent dependencies between resources or groups. A relationship exists between a source and a target. Source and target can be either resource references or groups. For example, a relationship A StartAfter B ensures that resource A can only start when resource B is online. Decisions to make: v Which automated resource on a specific first-level automation domain needs which other resource on another automation domain in order to run? v What are typical tasks for an operator to start or stop applications in order to start or stop some solution? Are workflow documents available which describe the sequence in which applications need to be started or stopped? v How does an operator apply maintenance to specific applications? Are documents available that describe in which sequence an operator must shut down applications? v In case of an unexpected failure of some critical applications on a first-level automation domain, do other applications on other automation domains need to be stopped as well? Before you define a policy, you need to identify the relationships between the resources. When you identify the relationships that need to be defined in the policy, you should list the relationship information in the following sequence: v Source resource v First-level automation domain name v Target resource v First-level automation domain name v Relationship type The following example describes when a ForcedDownBy relationship between two resources is required. Resource A and Resource B have the following states: v Resource A has the default desired state Online. v Resource B has the default desired state Offline. You need to define a ForcedDownBy relationship between source resource Resource A and target resource Resource B (Resource A ForcedDownBy Resource B) if you want to achieve the following behavior: v Whenever Resource B is started, for example, due to an operator request, this should not have any effect on Resource A. v Whenever Resource B was online and is stopping, for example, after it was started due to an operator's Online request and the request is canceled, or when Resource B fails while it is offline, Resource A must be bounced, that is, it has to be stopped and restarted again, for example, to allow Resource A to synchronize with Resource B. Chapter 1. Planning 45

64 Default directories During the installation, default directories are used to install System Automation Application Manager. Default directories are defined in variables. Check out all used variables and their related default directory. The following table lists the default directory paths for which variables are used in this guide. The paths in your environment may differ, for example, if you changed the default path during the installation of the application or component. Table 25. Default directories Variable used in this guide <EEZ_CONFIG_ROOT> <EEZ_INSTALL_ROOT> <hacmp_adapter_install_root> <hacmp_adapter_conf_root> <mscs_adapter_install_root> <mscs_adapter_conf_root> <Tivoli_Common_Directory> <was_root> <vcs_adapter_install_root> <vcs_adapter_conf_root> Default path /etc/opt/ibm/tsamp/eez/cfg /opt/ibm/tsamp/eez The configuration properties files are located in the directory <EEZ_CONFIG_ROOT>. AIX: /opt/ibm/tsamp/eez/hac AIX: /etc/opt/ibm/tsamp/eez/hac/cfg Windows: C:\Program Files\IBM\tsamp\eez\mscs Windows: C:\Program Files\IBM\tsamp\eez\mscs\cfg /var/ibm/tivoli/common The path to the Tivoli Common Directory is specified in the properties file log.properties. The file log.properties is located in the following directory /etc/ibm/tivoli/common/cfg. AIX: /usr/ibm/websphere/appserver Linux: /opt/ibm/websphere/appserver Solaris: /opt/ibm/tsamp/eez/vcs Solaris: /etc/opt/ibm/tsamp/eez/vcs/cfg Disaster recovery policy definition worksheets Print out and use these worksheets to collect the information required for creating a disaster recovery policy. If you need to define more cluster sets, hardware boxes, slots, or nodes print out more copies of the appropriate worksheet. Table 26. Worksheet to define disaster recovery topology Site 1 Index 1 Name Site 2 Index 2 Name 46 Tivoli System Automation Application Manager V : Installation and Configuration Guide

65 Table 26. Worksheet to define disaster recovery topology (continued) Cluster set Cluster set Cluster set Cluster set Cluster set Cluster set Cluster set Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Table 27. Worksheet to define disaster recovery hardware. Reuse this table for each site. Name of Site1 / Site2: Hardware Box Name Chapter 1. Planning 47

66 Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table for each site. Name of Site1 / Site2: Hardware Box Node Node Node Slot 1 Slot 2 Slot 3 Slot 4 SNMPAgent (If mechanism="snmp") Name Slot 1 Slot 2 Slot 3 Slot 4 SNMPAgent (If mechanism="snmp") Name Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Host Port AuthProtocol PrivProtocol ServiceProcessorType Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Name PowerOff mechanism PowerOn mechanism Host Port Site index 1 / 2 Domain name Class HardwareDevice Name AuthProtocol PrivProtocol ServiceProcessorType Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP MD5 / SHA / None DES / AES / None MM Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP Script / SNMP MD5 / SHA / None DES / AES / None SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot Site index 1 / 2 Domain name Class HardwareDevice Name SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot MM 48 Tivoli System Automation Application Manager V : Installation and Configuration Guide

67 Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table for each site. Name of Site1 / Site2: Node Node Node Site index 1 / 2 Domain name Class HardwareDevice Name SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot Site index 1 / 2 Domain name Class HardwareDevice Name SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot Site index 1 / 2 Domain name Class HardwareDevice Name SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot Site index 1 / 2 Domain name Class HardwareDevice SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node Box Slot Table 28. Worksheet to define disaster recovery workload Business-critical workload: Resource name Cluster set name Discretionary workload: Resource name Cluster set name Site index Chapter 1. Planning 49

68 Table 28. Worksheet to define disaster recovery workload (continued) Business-critical workload must be able to run on either site in a cluster set, so you do not need to collect an associated domain name with this worksheet. 50 Tivoli System Automation Application Manager V : Installation and Configuration Guide

69 Chapter 2. Installing Installing System Automation Application Manager involves preparation to ensure that your system meets the prerequisite requirements, then installing the required software. Installing the middleware software Depending on the setup type you choose, install the middleware software on one or more systems before System Automation Application Manager can be installed. For information on the required middleware software for each system, see Middleware software requirements on page 6. Contents of the middleware software DVDs The middleware software DVDs that are shipped with the System Automation Application Manager product DVDs contain the following software products: v IBM DB2 Limited Use Version 10.1 v IBM DB2 Limited Use Version 10.5 v IBM WebSphere Application Server Base Version Note: 1. IBM Tivoli System Automation Application Manager only supports the 32-bit Version of WebSphere Application Server. 2. WebSphere Application Server Version 8.5 Network Deployment is not supported. 3. Note that the IBM Tivoli Directory Server is not contained on the middleware software DVDs. v IBM Jazz for Service Management Version Note: Starting with fix pack the minimum versions of middleware products have changed to: v Jazz for Service Management, Version v IBM WebSphere Application Server, Version If you are planning to upgrade to System Automation Application Manager fix pack or higher, you must also upgrade Jazz for Service Management to the new minimum version. For more information, see Installing a new Jazz for Service Management version on page 58. Installing a DB2 server DB2 server requirements Use the following publications to find out which requirements need to be met for installing and running a DB2 server: v IBM DB2 - Quick Beginnings for DB2 Servers (GC ) v IBM DB2 - Release Notes - Version 10 The latest versions of these publications are available on the IBM DB2 web site: Copyright IBM Corp. 2006,

70 DB2 for Linux, UNIX and Windows You will find the link to the PDF manuals in the Other resources section on the Web page. In addition, check for the latest system requirements: System requirements for IBM DB2 for Linux, UNIX, and Windows. The DB2 release notes can also be found on the DVDs labeled IBM DB2 Database for Linux, UNIX, and Windows Version 10.1 or IBM DB2 Database for Linux, UNIX, and Windows Version 10.5 for your platform. Make sure that all requirements for installing and running a DB2 server are met. Otherwise, System Automation Application Manager may not install or work properly. DB2 server installation You can use the DB2 Setup wizard to install the DB2 server. The DB2 Setup wizard is on the DVD labeled IBM DB2 Database for Linux, UNIX, and Windows Version 10.1 or IBM DB2 Database for Linux, UNIX, and Windows Version 10.5 for your platform. You can use the typical installation of a single-partition database environment. On Windows, you may consider to set the startup type of the DB2 service to Automatic. On a Windows system, the following users must be local users: v DB2 administration server user v Fenced user v Instance owner user Create a DB2 instance before you install System Automation Application Manager. Make sure that the DB2 server has the required version level (see Middleware software requirements on page 6). On a 64-bit operating system, the following link must exist in the home directory of the DB2 instance owner: /home/<db2 instance name>/sqllib/lib64/libdb2tsa.so If this link does not exist, use the following command to create the link: ln -s /home/<db2 instance name>/sqllib/lib64/libdb2tsa.so.1 /home/<db2 instance name>/sqllib/lib64/libdb2tsa.so Make a note of the following information for future reference: v Host name of the system where the DB2 server is installed. v Port number of the DB2 instance. The port number is displayed on the summary window of the DB2 Setup wizard. The summary window appears immediately before the wizard copies the program files. v Name of the directory to which the DB2 server is installed if a local DB2 setup is used. v Name and password of the instance owner user or of a different user who is authorized to drop and create databases and database tables, and to select, insert, delete, and update table rows. 52 Tivoli System Automation Application Manager V : Installation and Configuration Guide

71 Note: For information about DB2 Version 10 server security concepts and on how to authorize users to perform certain tasks, go to IBM DB for Linux, UNIX, and Windows documentation or IBM DB for Linux, UNIX, and Windows documentation. JDBC driver installation for a remote DB2 setup Depending on which operating system the remote DB2 is installed, you need the following files: v DB2 for Linux, AIX, and Windows: db2jcc.jar db2jcc_license_cu.jar: License file for DB2 for Linux, AIX, and Windows You can find these files in the <DB2_install_home>/sqllib/java directory. v DB2 for z/os db2jcc.jar db2jcc_license_cisuz.jar: License file for DB2 for z/os You can find these files in the subdirectory classes or jcc/classes of the DB2 JDBC installation directory in the HFS. Note: The IBM DB2 driver for JDBC and SQLJ needs to be installed separately, after you have installed DB2 for z/os. You have the following options to install the JDBC driver: v Create a new folder. Copy the files listed above into this folder. Point the installer to the directory as described in Using the installation wizard on page 59. v Use the WebSphere JDBC driver: Copy the appropriate.jar files into the directory <was_home>/universaldriver/lib, if not already available. Point the installer to the directory as described in Using the installation wizard on page 59. v Use the DB2 runtime client JDBC driver: Point the installer to the directory with the appropriate.jar files as described in Using the installation wizard on page 59. Preinstallation tasks for a remote DB2 setup The following tasks must be completed on the DB2 server system: v Create the automation manager database (for information on how to do this, see below). v Create the automation manager tables in the database (for information on how to do this, see below). Note: If the database has already been created and tables already exist, you must drop the existing tables before creating the tables. v To use a remote database setup, install a JDBC driver. The DVD System Automation Application Manager version 4.1 for your platform contains scripts for creating the required databases and tables. Creating the automation manager database and the database tables: Windows Perform the following steps if your DB2 server runs on a Windows system: Chapter 2. Installing 53

72 1. Log in with a user ID that has SYSADM privileges on the DB2 instance. 2. On the DVD labeled System Automation Application Manager Version 4.1, change the directory to DDL\Script 3. From this directory, run the following batch files: db2_create_automgr_db.bat <db_name> <instance_owner> <instance_pw> db2_create_reporting_tables.bat <db_name> <instance_owner> <instance_pw> <script_directory> where v v AIX or Linux <db_name> is the desired name of the automation manager database (Example: EAUTODB) <instance_owner> is the instance owner user ID of the DB2 instance (Example: db2admin) v <instance_pw> is the password of the instance owner user ID v <script_directory> is the directory where the DB2 scripts for Tivoli System Automation are located on the DVD, which you changed to in step 2 (DDL\Script) Perform the following steps if your DB2 server runs under Linux or AIX: 1. Log in as root. 2. On the DVD labeled System Automation Application Manager Version 4.1 for your operating system, change the directory to DDL/Script. 3. From this directory, run the following shell scripts: db2_create_automgr_db.sh <db_name> <instance_owner> <instance_pwd> <script_directory> db2_create_reporting_tables.sh <db_name> <instance_owner> <instance_pwd> <script_directory> z/os where v v <db_name> is the desired name of the automation manager database. Example: EAUTODB <instance_owner> is the instance owner user ID of the DB2 instance. Example: db2inst1 v <instance_pwd> is the password of the instance owner user ID. v <script_directory> is the directory where the DB2 scripts for Tivoli System Automation are located on the DVD, which you changed to in step 2 (DDL/Script). If you have a DB2 server system that runs on z/os, adjust and run the following jobs. They are provided on the DVD labeled System Automation Application Manager Version 4.1 for your operating system, in directory DDL/DB2. ATVED100 This job creates a DB2 table space, tables, and index entries. ATVED10C This job deletes the objects created by job ATVED Tivoli System Automation Application Manager V : Installation and Configuration Guide

73 Follow the instructions within the jobs to adjust them to your environment. Note: 1. Make sure that DB2 is active before submitting the jobs. 2. Before rerunning job ATVED100 run job ATVED10C to cleanup the table space and tables defined by the previous run. 3. The user ID under which these jobs are submitted must have DB2 SYSADM (system administrator) authority. Verifying the creation of the remote database: After running the scripts as described in Creating the automation manager database and the database tables on page 53, issue the following commands to verify that the remote database was created correctly: 1. Log on as DB2 instance owner. 2. db2 connect to <db_name> 3. db2 list tables for schema eautousr 4. db2 disconnect <db_name> The output of the list tables command displays the following table names: EEZAUTOMATIONACCESS EEZCOMMONEVENTS EEZDOMAINSUBSCRIPTION EEZOPERATORDOMAINFILTER EEZOPERATORDOMAINPREFERENCES EEZOPERATORHIDDENDOMAIN EEZPERSISTENTREQUEST EEZRESOURCESUBSCRIPTION EEZSAFOSEVENTS EEZNODE Installing Jazz for Service Management Before you install or update Jazz for Service Management, refer to the technotes for Jazz for Service Management. Technotes provide information about late-breaking issues, limitations, and workarounds. Check technotes referring to issues in Jazz for Service Management Version : Jazz for Service Management technotes. Section Jazz for Service Management installation describes how to install the version of Jazz for Service Management that you receive when you order System Automation Application Manager 4.1. Starting with fix pack the minimum versions of the Jazz for Service Management components have changed. Use the new Jazz for Service Management version rather than the version described in that section. For more information, see Installing a new Jazz for Service Management version on page 58. Jazz for Service Management installation Follow the steps described in this topic to install Jazz for Service Management. The following installation steps describe how to install the version of Jazz for Service Management that you receive when you order System Automation Application Manager 4.1. Starting with fix pack the minimum versions of Chapter 2. Installing 55

74 the Jazz for Service Management components have changed. Use the new Jazz for Service Management version rather than the version described below. For more information, see Installing a new Jazz for Service Management version on page 58. To install Jazz for Service Management Version and WebSphere Application Server Version , proceed as follows: 1. Create a common directory to store the extracted Jazz for Service Management installation media, referred to as the JazzSM_Image_Home/directory. Restriction: Ensure that the path to the common root directory does not contain any spaces or special characters. 2. Extract the contents of the following deliverable into this directory: Jazz for Service Management Version including Installation Manager: v AIX: JAZZ_FOR_SM_ _FOR_AIX_ML.zip (CISZ2ML.zip) v Linux: JAZZ_FOR_SM_ _FOR_LINUX_ML.zip (CISZ3ML.zip) v Linux on System z: JAZZ_FOR_SM_ _LINUX_SYS_Z.zip (CISZ4ML.zip) WebSphere Application Server Version : v AIX: WAS_V _FOR_JAZZSM_AIX_ML.zip (CIES5ML.zip) v Linux: WAS_V _FOR_JAZZSM_LINUX_ML.zip (CIES6ML.zip) v Linux on System z: WAS_V _FOR_JAZZSM_LINUX_Z_ML.zip (CIES7ML.zip) 3. Install Jazz SM Services by using Installation Manager: a. Browse to the JazzSM_Image_Home/im.platform_name/ directory and run the installation command, for example:./install If the installation does not start due to missing prerequisites, check whether all required libraries are installed as documented in Middleware software requirements on page 6. For more information about JAZZ for Service Management prerequisites, see Hardware and software requirements. b. The Installation Manager window opens. Select the following packages to be installed: 1) IBM Installation Manager Version ) IBM WebSphere Application Server Version ) IBM WebSphere SDK Java Technology Edition Version ) Jazz for Service Management extension for IBM WebSphere 8.5 Version ) IBM Dashboard Application Services Hub Version c. Click Next. The Installation Manager > Licenses window opens. Review and accept the License Agreements. d. Click Next and specify the directories that are used by the Installation Manager. e. Click Next and specify the installation directories for WebSphere Application Server and Jazz for Service Management. f. Click Next. The Installation Manager > Features languages window opens. 56 Tivoli System Automation Application Manager V : Installation and Configuration Guide

75 g. Accept the default translated languages that are selected in the Translations Supported by All Packages window. Click Next. The Installation Manager > Features window opens. h. Important: On the Features window, expand IBM WebSphere Application Server > IBM WebSphere SDK for Java Technology Edition 6 and select IBM 32-bit WebSphere SDK for Java. i. Click Next and specify the configuration for your WebSphere Application Server installation. Define the WebSphere administrative user ID. Click Validate. j. Click Next. The Installation Manager > Summary window opens. k. Review the software packages to be installed and their installation directories. Click Install to start the installation. l. When the installation successfully completed, a success window is displayed. You can now click Finish to close the Installation Manager. 4. Important: Activate the 32-bit version of Java 7 for the WebSphere Application Server profile: <was_root>/bin/managesdk.sh -enableprofile -sdkname 1.7_32 -profilename JazzSMProfile -enableservers JazzSMProfile is the profile name that is used for Jazz for Service Management. Default name: JazzSMProfile. Note: links: v v v More information about configuring Java 7 is provided at the following Find out how to install and configure Java 7 at the IBM Education Assistant -WebSphere software. Check the Java SDK Upgrade Policy for the IBM WebSphere Application Server before you apply the fixes to WebSphere Application Server, to ensure that the fix matches to the installed Java version. The page Verify Java SDK version shipped with IBM WebSphere Application Server fix packs describes which version of WebSphere Application Server corresponds to which Java SDK level. You are now ready to install System Automation Application Manager using its own installer. Post-installation tasks for Jazz for Service Management Jazz for Service Management defines default values for the time intervals within the browser polls for new content. These default values are higher than the values that are required by System Automation to ensure timely visualization when an automation resource changes its state. During initial installation of System Automation Application Manager, the timeout values are adjusted automatically. But when service for Jazz for Service Management is installed afterwards, the original default values are restored. Perform the following steps after installing service for Jazz for Service Management: 1. Open file /opt/ibm/jazzsm/ui/properties/activemqbroker.properties. 2. Ensure that each of the following properties are set to 5 seconds: ActiveMQBroker.timeout=5 ActiveMQBroker.pollDelay=5 ActiveMQBroker.pollErrorDelay=5 3. Save the file and restart WebSphere Application Server. Chapter 2. Installing 57

76 Installing a new Jazz for Service Management version Starting with fix pack the minimum version of Jazz for Service Management changed. The version of Jazz for Service Management that you receive when you order System Automation Application Manager 4.1 is not sufficient. Before you begin The required minimum version is Jazz for Service Management , including the following versions of Jazz for Service Management components: v IBM Installation Manager v IBM WebSphere Application Server Version v IBM WebSphere SDK for Java Technology Edition Version v Jazz for Service Management extension for IBM WebSphere 8.5 Version v IBM Dashboard Application Services Hub Version There are two scenarios to be considered: 1. You already installed System Automation Application Manager 4.1 and want to install a fix pack. As a prerequisite of the version 4.1 installation you installed the version of Jazz for Service Management that you received as part of System Automation Application Manager You ordered System Automation Application Manager 4.1 before fix pack is available and you want to run a new installation. This includes the case where you received version 4.1 already, but you want to install on an operating system version that was not yet supported by System Automation Application Manager version 4.1. This case is described in Installing on new operating systems on page You ordered System Automation Application Manager 4.1 after fix pack is available. You already installed System Automation Application Manager 4.1 In this case, you installed also the middleware components as described in Middleware software requirements on page 6. Upgrade the middleware components to the versions listed in this section. You can download the corresponding archives from the IBM Installation Manager, IBM WebSphere, and Jazz for Service Management support sites and upgrade each component separately. Alternatively, you can download Jazz for Service Management for your operating system platform from Passport Advantage (PA / XL). In this case, the corresponding Jazz for Service Management and WebSphere archives contain the required components that you can install in one step as describe below. You ordered System Automation Application Manager 4.1 before fix pack is available and want to run a new installation Install the middleware components by using the versions listed above. Download Jazz for Service Management for your operating system platform from Passport Advantage (PA / XL). For more information, see The corresponding Jazz for Service Management and WebSphere archives contain the required components that you can install in one step. For the download from Passport Advantage, use part numbers to locate the required packages. You need the following packages: 58 Tivoli System Automation Application Manager V : Installation and Configuration Guide

77 v CN54UML: Jazz for Service Management for AIX, 64-bit, Multilingual v CN552ML: IBM WebSphere Application Server for Jazz for Service Management for AIX, 64-bit, Multilingual v CN54VML: Jazz for Service Management for Linux, 64-bit, Multilingual v CN553ML: IBM WebSphere Application Server for Jazz for Service Management for Linux, 64-bit, Multilingual v CN54WML: Jazz for Service Management for Linux on System z, 64-bit, Multilingual v CN554ML: IBM WebSphere Application Server for Jazz for Service Management for Linux on System z, 64-bit, Multilingual The Jazz for Service Management packages contain IBM Installation Manager Version and IBM Dashboard Application Services Hub Version The IBM WebSphere Application Server packages contain IBM WebSphere SDK for Java Technology Edition Version You can use the packages that are downloaded from Passport Advantage for an initial installation and for an update installation. In case of an initial installation, proceed as described in Jazz for Service Management installation on page 55. Use the new versions instead of the ones that are documented in that section. In case of an update installation, specify the JazzSMRepository and the WASRepository as new repositories in your installation manager configuration and select to update the corresponding components. You ordered System Automation Application Manager 4.1 after fix pack is available If you order System Automation Application Manager 4.1 after fix pack is available, you receive already the new versions of the middleware software in addition to the versions that are delivered with System Automation Application Manager Proceed as described in Jazz for Service Management installation on page 55. Use the new versions instead of the ones that are documented in that section. Installing System Automation Application Manager If you finalized your planning steps to install System Automation Application Manager, start with the installation. You have two options to install. You can either use the wizard or install in silent mode. One instance of the agentless adapter is installed as part of the System Automation Application Manager installation. For more information about how to install more instances of the agentless adapter on other systems, see Installing the remote agentless adapter on page 87. Using the installation wizard This topic describes how to install System Automation Application Manager. For the installation, you use a graphical installation program, the installation wizard. The required steps are described in the following paragraphs. Chapter 2. Installing 59

78 When installing System Automation Application Manager to an AIX or Linux system, you must ensure that an X Window session is available for displaying the graphical installation wizard panels. If the graphical installation program cannot be started, the installer automatically switches to console mode. The console mode is not supported, and can't be used for the installation of the product. If the console mode is started, please check whether all required libraries are installed on the machine, as documented in Installing prerequisites on page 4. On the panels of the installation wizard, enter the data you collected using the lists provided in Collecting the information on page 11. Make sure that you specify all required parameters on the installation wizard panels and that your entries are correct. Note: 1. The wizard panels that are displayed during the installation are similar on different operating systems. Make sure to enter platform-specific information when specifying directory locations and file names. 2. In this topic, only those panels are depicted on which user actions are required. 3. The installation comprises these phases: a. In the preinstallation phase, you specify the installation parameters. b. The installation phase begins when you click the Install button on the last preinstallation window. In this phase, all files are installed to the disk. c. The configuration step, in which the necessary WebSphere Application Server and DB2 configuration is performed. The configuration step can be canceled at any time. The installation can be resumed by simply calling the installer again. To install System Automation Application Manager, perform these steps: 1. Make sure that all installation prerequisites are met (refer to Installing prerequisites on page 4). 2. Insert the following DVD into the DVD drive: System Automation Application Manager v4.1 - <platform> There are multiple DVDs. Be sure to use the one for your platform. If you are using electronic distribution switch to the appropriate archive. 3. Change to the directory that contains the installation program. For the location of the directory, refer to Packaging on page Start the installation by launching the installation wizard using setup.bin. For more information about how to install in silent mode, see Installing in silent mode on page 64 When the installer unpacks its contents, the initial wizard window opens. 5. Select the language in which the text on the wizard panels is to appear and click OK. The language in which System Automation Application Manager is installed is derived from the system locale setting. 6. The next window displayed is the "Introduction" window. On this window, you can see the available installation options: perform an initial installation, resume a canceled or failed installation, or perform an update installation. Read the information on this window and click Next to proceed. 60 Tivoli System Automation Application Manager V : Installation and Configuration Guide

79 7. The Software License Agreement window is displayed. Carefully read the terms of the license agreement. To accept the terms of the license agreement, select I accept the terms in the license agreement and click Next. 8. On the Installation Directory window, specify the directory where you want to install System Automation Application Manager or accept the default location. Click Next. 9. If the installation program detects a Tivoli Common Directory on your system, for example, because a Tivoli product is already installed, the directory must also be used for System Automation Application Manager. In this case, the Tivoli Common Directory window is not displayed. If the installation program does not detect a Tivoli Common Directory on your system, accept the default location or specify the directory to which the Tivoli log files are to be written. Click Next. 10. On the High Availability window, select the high availability setup that you require. v Click I want to install on a single server (not highly available) if you do not want a high availability scenario. The steps that follow determine the changes that are made to the end-to-end automation manager. The option Yes is automatically selected. v Click I want to create a highly available SAAM setup with two or more servers if you want a high availability scenario. No changes are made to the end-to-end automation manager database and the WebSphere Application Server is not started after the installation. Choose Yes if you have no database already installed on the cluster that is used by another system. Choose No if you have a database installed on the cluster that is used by another system. Click Next. 11. On the Database Server window, select the DB2 setup type you are using and click Next. Which window is displayed next, depends on the type of DB2 setup you selected: v Local DB2 setup: Proceed with step 12. v Remote DB2 setup: Proceed with step 13 on page 62. v Remote DB2 on z/os setup: Proceed with step 14 on page The "IBM DB2 on local system" window is displayed only if you are using a local DB2 setup. a. Specify the database name or accept the default name and click Next. Note that any existing database with the name you specify is dropped automatically without warning b. Specify the installation directory of your local DB2 installation and the name and password of the DB2 Instance owner, and then click Next. c. In the field DB2 instance port number, the valid port number must be specified: v If the DB2 port number was retrieved automatically, the valid port number is displayed in the field. v If the DB2 port number was not retrieved automatically, the default port number is displayed. DB2 port numbers often differ from the default, Chapter 2. Installing 61

80 depending on the DB2 setup that you configured. Ensure that your setting is correct before you proceed. Click Next and proceed with step 15. Note: After you click Next the installation program checks whether the database can be accessed with the values you specified on the window. If you want to skip the check, select the check box on the window. Continue with The "IBM DB2 Database on remote system" window is displayed only if you are using a remote DB2 setup. a. Specify the database name (see Preinstallation tasks for a remote DB2 setup on page 53) and click Next b. Specify the path to the DB2 JDBC driver or click Choose to select the directory (see JDBC driver installation for a remote DB2 setup on page 53 and Preinstallation tasks for a remote DB2 setup on page 53), and specify the name and password of the database instance owner. Click Next. Note: The installation wizard checks the contents of the defined directory and displays an error message if it does not contain a JDBC driver with a valid license c. In the field DB2 server host name, type the fully qualified host name of the system where the DB2 server is installed. In the field DB2 server port, the port number of the DB2 server must be specified. Enter port number of your DB2 on z/os database. To skip the access test, select the Skip DB2 access check box. Click Next. 14. The "IBM DB2 Database on remote system on z/os" window is displayed only if you are using a remote DB2 on z/os setup. a. Enter the location information of the database that runs on z/os and the schema name of the database. Click Next b. Specify the path to the DB2 JDBC driver or click Choose to select the directory, and specify the name and password of the database instance owner. Click Next c. In the DB2 server host name field, type the fully qualified host name of the system where the DB2 server is installed. In the DB2 server port field, specify the port number of the DB2 server. Enter port number On the User and Group Administration window, specify whether your WebSphere has administrative access to users and groups. Typically, this is the case in setups with federated user repositories where you can manage users and groups via the administrative console. If you click Yes, the installer creates users and groups in that repository to use with System Automation Application Manager. If you click No, the installer does not make any changes to users and groups. Click No, if you use a central LDAP user repository and the users and groups exist in this repository. This is the case if you created them manually in the LDAP repository or if a previous System Automation Application Manager installation created them in the same LDAP repository. 16. The installation directory of WebSphere Application Server is detected on your system and displayed on the WebSphere Application Server window. a. Click Next. 62 Tivoli System Automation Application Manager V : Installation and Configuration Guide

81 b. Specify a WebSphere Application Server administrative account and password. You can also choose another server. Select the profile you want to use and click Next. 17. On the Automation Domain Name window, specify the end-to-end automation domain name you want to use or accept the default name and click Next. Note: Accept the default domain name FriendlyE2E if you want to use the sample System Automation Application Manager environment to familiarize yourself with end-to-end automation management and the operations console. You can change the settings once your are done with the installation. For more information, see Domain tab on page If you want to use Tivoli Netcool/OMNIbus to display end-to-end automation management events: v Select Enable EIF event forwarding to OMNIbus. v In the Host Name field, specify the host name of the OMNIbus Probe for Tivoli EIF. v In the Port Number field, specify the port number of the OMNIbus Probe for Tivoli EIF. The default port number is Click Next. Note: You can also enable the connection from the WebSphere Application Server administrative console after the installation of System Automation Application Manager is complete. 19. On the System Automation Functional user ID window, specify the functional user ID and password for the end-to-end automation manager. Do not use cut and paste to enter the password and the password confirmation. Type in directly the password and the password confirmation. This functional user ID is needed for several purposes: v The end-to-end automation engine uses the credentials to access the JEE framework that runs on the WebSphere Application Server. v The JEE framework uses the credentials to access JMS, as defined in the WebSphere Application Server JAAS authentication alias EEZJMSAuthAlias. v The JEE framework uses the credentials for all asynchronous internal work that is associated with the EEZAsync role, as defined in the EEZEAR application's User RunAs role mapping. Note: Do not choose the same name for both the System Automation functional user ID and the WebSphere Application Server administrator user ID, as this may lead to problems if you later uninstall System Automation Application Manager. For example, do not specify wasadmin for both users. 20. If System Automation Application Manager Distributed Disaster Recovery with GDPS is supported on this platform, the GDPS window is displayed. If you want to connect the Automation Manager to GDPS: v Select Enable GDPS server connection. v In the field GDPS server host name, specify the TCP/IP host name of the GDPS controlling system (also known as the K system). v In the field GDPS server port number, specify the TCP port number configured for the NetView Event/Automation Service (E/AS) address space that is running on the GDPS controlling system. If you want to enable a connection to a backup GDPS controlling system: v Select Enable GDPS backup server connection. Chapter 2. Installing 63

82 v In the field GDPS server host name, specify the TCP/IP host name of your backup GDPS controlling system. v In the field GDPS server port number, specify the TCP port number configured for the NetView Event/Automation Service (E/AS) address space that is running on the backup GDPS controlling system. Click Next. Note: You can modify the GDPS connection after the installation of System Automation Application Manager is completed. For more information, refer to Configuring the destination for GDPS events on page On the "System Automation Administration user ID " window, specify the user ID and password of the System Automation administrator. Click Next. 22. When you specified all the required information on the wizard panels, the Pre-Install Summary window is displayed. The installer checks for disk availability. If the disk space requirements are not met, installation is not possible. Click Install to start the installation. The installation can take up to two hours to complete. 23. While the component is being installed and configured, information panels display the progress. 24. When the installation of System Automation Application Manager is complete, the Installation Complete window is displayed. Click Done to close the installation wizard. For information about verifying the installation, refer to Verifying the installation on page 71. Installing in silent mode You can install System Automation Application Manager Version by using a graphical interface (Installation Shield wizard) or in silent mode. The silent installation is run by using a previously created silent input properties file. You can generate the install.properties input file in two ways: Run a wizard-based graphical installation using setup.bin or setup.exe with the -Dpreparesilent=true option. When the installation procedure completes, the install.properties file is created in the <EEZ_INSTALL_ROOT>/install sub-directory of the product installation path. When an update installation is performed, the file is read to obtain the parameters and values needed for the update process. If this file is not found, the update installation fails. If you want to perform a silent installation of System Automation Application Manager on more than one system, you can take the install.properties file which was generated during a graphical installation, and use it on other systems of the same type. You might need to replace system-specific parameters in the file to customize it for the target system. You can prepare an install.properties file without performing a complete installation on the target system. The first part of the installation procedure gathers all the necessary parameters needed to generate the install.properties file. You do this by starting the graphical installer on the target system with the options -Dpreparesilent=true and -Dpropertiesfileonly=true. With these options, the installation procedure 64 Tivoli System Automation Application Manager V : Installation and Configuration Guide

83 stops before the product files are copied to the product directory. The install.properties file is created and stored in directory /tmp. If you want the file to be created in a specific path, you can optionally specify -Dpropertiesfilepath=<fully_qualified_path>. If the specified path is incorrect, the file is saved in the default temporary directory on the system. For example, if you want the file to be saved to /var/mydir, use the following command: setup.exe -Dpreparesilent=true -Dpropertiesfileonly=true -Dpropertiesfilepath=/var/mydir Note: The option -Dpropertiesfilepath=<fully_qualified_path> can be used only if -Dpreparesilent=true and -Dpropertiesfileonly=true are also specified. You can use the install.properties file for a silent installation only if the -Dpreparesilent=true option is specified. To run a silent installation, perform these steps: 1. Copy the input properties file install.properties to the system on which you want to perform the silent installation. 2. Edit the install.properties file and make sure that it contains all your system-specific parameters, such as host names, directories, and so on. Password parameters in the install.properties file do not contain any values. You must add the passwords manually to the file, or else the installation fails. 3. To start the installation, enter the following command depending on the platform you use: setup.bin -f <fully_qualified_properties_file_name> If the input file install.properties is found, silent installation starts. If the file is not found, the wizard-driven installation starts. Upgrading to release 4.1 To upgrade from any previous version to version 4.1, proceed as follows: 1. Export your data. For more information, see Exporting the content of the automation database on page Store the customized user role mappings. For more information, refer to Storing the user role mappings for WebSphere application EEZEAR on page On AIX only: Run the slibclean command. For more information, refer to Upgrading on AIX on page If you are upgrading from release or 3.2.1, review the additional information in Upgrading from release or on page Uninstall any previous version of System Automation Application Manager. 6. If you are not using a local DB2 installation, upgrade the automation database: v If you are upgrading from release or 3.2.1, review the additional information in Upgrading the automation database from version or on page Install the middleware software required by System Automation Application Manager Version 4.1. Chapter 2. Installing 65

84 8. If high availability is configured for System Automation Application Manager, perform the additional preinstallation steps described in Upgrading the high availability policy on page Install System Automation Application Manager Version If high availability is configured for System Automation Application Manager, perform the additional postinstallation steps described in Upgrading the high availability policy on page Import your data. For more information, see Exporting the content of the automation database. Once the previous version of System Automation Application Manager is uninstalled, all configuration files are preserved in directory <EEZ_CONFIG_ROOT>, for example /etc/opt/ibm/tsamp/eez/cfg. After version 4.1 is installed, System Automation Application Manager Version 4.1 uses the configuration files saved in <EEZ_CONFIG_ROOT>. If you are using the cfgeezdmn configuration utility in silent mode to configure the Application Manager common settings, make sure that you generate a new silent input properties file on the new release level. The Application Manager common settings are configured in silent mode by launching the cfgeezdmn utility using the options -s -e. Before performing any silent configuration, generate a new input properties file by launching the cfgeezdmn utility using the options -s -e [ -g -gr ]. Exporting the content of the automation database If you decide to drop and recreate the automation database, use the scripts described in this topic. These scripts export the data from the automation database before you drop the database, and import them back into the automation database once it is recreated. In addition, future upgrades of System Automation Application Manager can require changes of the layout of tables contained in the automation database. In this scenario, export the data contained in the automation database prior to the upgrade, and import the data back into the automation database after the upgrade to prevent data loss. System Automation Application Manager provides scripts that assist you to export and import data. These scripts are designed for local databases managed by DB2 for distributed platforms. If you have a remote DB2 setup you must directly run these scripts on the system where the automation database resides. If you use DB2 for z/os, the scripts cannot be used directly, but they can serve as a blueprint for your database administrators in order to create export and import procedures that are appropriate for your environment. To export the data, perform the following steps: 1. Stop the WebSphere Application Server to ensure that the automation manager does not lock any data in the database. 2. Change to the DDL/Script directory on the product DVD and run the following script to export the data:./db2_export_automation_db.sh <db_name> <instance_owner> <instance_pwd> <export_to_dir> If you use a remote DB2 located on a Windows system, run the corresponding.bat file from the DDL/Script directory on that remote system: db2_export_automation_db.bat <db_name> <instance_owner> <instance_pwd> <export_to_dir> 66 Tivoli System Automation Application Manager V : Installation and Configuration Guide

85 These are the required parameters: <db_name> - Name of the System Automation Application Manager database. Typically, this is EAUTODB. <instance_owner> - Database instance owner userid. <instance_pwd> <export_to_dir> - Database instance owner password. - Absolute path name of the directory where the exported tables should be stored. Ensure that the <instance_owner> user ID has write access to this directory. 3. Review the messages created by the script, including the messages contained in the export log file located in the logs sub-directory of the <export_to_dir> directory. For more information about how to import the content of the automation database, refer to Importing the content of the automation database on page 70. Note: 1. The export and import scripts are needed if an upgrade requires a change of the database layout. In this case, do not use the backup and restore functionality provided by DB2 to back up and restore the automation database, as this preserves the complete database layout. It is not generally required to export and import the data when the System Automation Application Manager is upgraded. In most cases, changes of the automation database layout are performed without the need to drop and recreate the database tables. For more information, see Upgrading to release 4.1 on page The DB2 export utility that is used by the automation data export script creates several warning messages with message ID SQL3100W. This warning message can be ignored. For further information about this message, refer to the DB2 documentation. 3. For general information about the EXPORT and IMPORT commands provided by IBM DB2, refer to the DB2 documentation. Storing the user role mappings for WebSphere application EEZEAR Store the role mappings before you uninstall a previous version as part of the upgrade process to release 4.1, if the default role mappings for the user roles defined within the EEZEAR application are changed. You can retrieve the role mappings using one of the following tools: v WebSphere administrative console 1. Log on to the WebSphere administrative console as a WebSphere administrator. 2. Navigate to Applications > Enterprise Applications > EEZEAR > Security role to user/group mapping. 3. Take notes for all existing mappings. v wsadmin scripting 1. Change to the /bin sub-directory of the WAS profile, e.g., /opt/ibm/websphere/appserver/profiles/appsrv01/bin 2. Enter./setupCmdLine.sh 3. Enter the wsadmin command./wsadmin.sh -username <wasadmin_id> -password <wasadmin_pwd> -lang jython -c Chapter 2. Installing 67

86 "java.lang.system.out.println(adminapp.view( EEZEAR, [ -MapRolesToUsers ]))" 4. Take notes for all existing mappings, or redirect the output into a file. After installing release 4.1, log on to the WebSphere administrative console. 1. Navigate to the Security role to user/group mapping for EEZEAR. 2. Adjust the mappings to the values that you noted in the wsadmin scripting list above. 3. Save the changes. 4. Restart the WebSphere Application Server. Upgrading on AIX On AIX, execute the following command after the automation engine (eezdmn) has been stopped and before the installation is started: # /usr/sbin/slibclean Upgrading from release or This section describes what you must observe when migrating from release or to release 4.1. To upgrade from release or to release 4.1 of System Automation Application Manager, uninstall release or and install release 4.1 as described in Upgrading to release 4.1 on page 65. Additional installation steps Before you uninstall release or as part of the upgrade process, consider the following questions: 1. Are you using the agentless adapter? Open the configuration utility using the cfgeezdmn command. If the Enable agentless adapter configuration check box on the configuration utility launchpad window is selected, you are using the agentless adapter. 2. Did you configure to use SSL for the communication with all first-level automation domains? Click Configure for the Application Manager common configuration on the configuration utility launchpad window and select the Security tab. Check if the Enforce use of SSL for all first-level automation domains check box is selected. Some modifications are introduced with release that have to be considered when migrating from release or directly to release 4.1. If the answer to both questions is 'yes', perform the following migration steps after installing System Automation Application Manager Version 4.1: Prior to release 4.1 of System Automation Application Manager, Agentless Adapter domains were not included when SSL was enforced for communication between the end-to-end automation manager and first-level automation domains. Starting with release 4.1, this applies also for agentless adapter domains. In release 4.1, the configuration of the agentless adapter has been extended to configure also SSL for data transport between the automation manager and the adapter. You can either configure SSL or deselect the Enforce use of SSL for all first-level automation domains check box in the Application Manager common configuration. 68 Tivoli System Automation Application Manager V : Installation and Configuration Guide

87 Refer to Configuring the Application Manager common settings on page 105 for a description of the configuration utility. If you decide to configure SSL for data transport between the automation manager and the agentless adapter, see also Securing the connection to end-to-end adapters using SSL on page 300. Using remote Agentless Adapters Prior to System Automation Application Manager release there was only one agentless adapter that was installed on the Application Manager server host. Fix pack , and specifically release 3.2.2, introduces the remote Agentless Adapters. The agentless adapter included with releases prior to System Automation Application Manager Version is now referred to as the local agentless adapter. The SSL enforcement option mentioned in the preceding paragraphs applies to both the local agentless adapter and the new remote Agentless Adapters, but the migration action described in the previous topics applies only to the local agentless adapter. If you configure remote agentless adapters on a system with System Automation Application Manager Version 4.1, you cannot distribute this configuration to a system where a remote agentless adapter of version is installed. You must upgrade the remote agentless adapter system to version 4.1 before you distribute the configuration. Upgrading the automation database from version or Create a new database table EEZNODE in the automation database. Existing database tables are not affected. To create the new table, run the appropriate script for your environment as described below: In a Windows environment: v In the <EEZ_INSTALL_ROOT>\install directory or in the DDL/Script directory on the product DVD, run: db2_run_sql.bat <db_name> <instance_owner> <instance_pwd> createnodetable.sql In a UNIX environment: v In the <EEZ_INSTALL_ROOT>/install directory or in the DDL/Script directory on the product DVD, run: db2_run_sql.sh <db_name> <instance_owner> <instance_pwd> createnodetable.sql Note: The db2_run_sql script searches for the SQL file in the../db2 directory. If the automation database is located on a z/os server, review ATVEM200 on how to create the EEZNODE table. Upgrading the high availability policy If high availability is configured for System Automation Application Manager, upgrade the automation policy. Perform the following steps: Preinstallation steps 1. Perform the update of the automation database as described in Upgrading the automation database from version or Exclude the node: samctrl -u a <node>. Chapter 2. Installing 69

88 3. Stop the first node in the cluster: stoprpnode <node>. Use the installation wizard to install System Automation Application Manager on this node. Specify that your are installing a high availability scenario. Select No, all database installation steps have been performed prior to this installation in order to prevent any database access during the upgrade process. Postinstallation steps 1. Restart the node: startrpnode <node>. 2. Include the node: samctrl -u d <node>. 3. Run the configuration dialog cfgeezdmn on the upgraded node. 4. Verify the values for configuring high availability are correct. Save your changes in case you had any. Click Define policy in order to upgrade the policy. Note: This does not affect any other resources defined in the end-to-end high availability policy. Repeat this procedure for all other nodes. Importing the content of the automation database If you decide to drop and recreate the automation database, use the scripts described in this topic. These scripts export the data from the automation database before you drop the database, and import them back into the automation database once it is recreated. In addition, future upgrades of System Automation Application Manager can require changes of the layout of tables contained in the automation database. In this scenario, export the data contained in the automation database prior to the upgrade, and import the data back into the automation database after the upgrade to prevent data loss. System Automation Application Manager provides scripts that assist you to export and import data. These scripts are designed for local databases managed by DB2 for distributed platforms. If you have a remote DB2 setup you must directly run these scripts on the system where the automation database resides. If you use DB2 for z/os, the scripts can not be used directly, but they can serve as a blueprint for your database administrators in order to create export and import procedures that are appropriate for your environment. For more information about how to export the content of the automation database, refer to Exporting the content of the automation database on page 66. Import data To import the data, perform the following steps: 1. Stop the WebSphere Application Server to ensure that the automation manager does not lock any data in the database. 2. Change to the DDL/Script directory on the product DVD and run the following script to import the data:./db2_import_automation_db.sh <db_name> <instance_owner> <instance_pwd> <import_from_dir> If you use a remote DB2 located on a Windows system, run the corresponding.bat file from the DDL/Script directory on that remote system: db2_import_automation_db.bat <db_name> <instance_owner> <instance_pwd> <import_from_dir> 70 Tivoli System Automation Application Manager V : Installation and Configuration Guide

89 These are the required parameters: <db_name> - Name of the System Automation Application Manager database. Typically, this is EAUTODB. <instance_owner> - Database instance owner userid. <instance_pwd> - Database instance owner password. <import_from_dir>- Absolute path name of the directory where the tables to be imported are stored. 3. Review the messages created by the script, including the messages in that are contained in the import log file that is contained in the "logs" sub-directory of the <import_from_dir> directory. Note: 1. The export and import scripts are needed if an upgrade requires a change of the database layout. In this case, do not use the backup and restore functionality provided by DB2 to back up and restore the automation database, as this preserves the complete database layout. It is not generally required to export and import the data when the System Automation Application Manager is upgraded. In most cases, changes of the automation database layout are performed without the need to drop and recreate the database tables. For more information, see Upgrading to release 4.1 on page The DB2 export utility that is used by the automation data export script creates several warning messages with message ID SQL3100W. This warning message can be ignored. For further information about this message, refer to the DB2 documentation. 3. For general information about the EXPORT and IMPORT commands provided by IBM DB2, refer to the DB2 documentation. Verifying the installation This topic describes the tasks you should complete in order to verify that the automation manager, automation engine, and operations console have been installed successfully. Verifying the automation manager To verify that the automation manager was installed successfully, complete the tasks described in the following topics. Verifying the end-to-end automation database: Perform these steps to verify that the end-to-end automation database and the database tables were created successfully on AIX, Linux or Windows: Procedure 1. Ensure that DB2 is running. 2. db2 connect to <db_name> 3. db2 list tables for schema eautousr 4. db2 disconnect <db_name> 5. Click Tables. The table names, that are listed in Verifying the creation of the remote database on page 55 should be shown. Chapter 2. Installing 71

90 What to do next Perform these steps to verify that the end-to-end automation database and the database tables were created successfully on z/os: 1. Ensure that DB2 is running. 2. Invoke the DB2 Administration Tool from within TSO. 3. Select the DB2 that is hosting the System Automation Application Manager tables. 4. Invoke the DB2 System Catalog function (option 1) 5. Navigate to Databases (option D). 6. Select EAUTODB (or whatever name you have chosen) and specify option T. 7. The tables listed in Verifying the creation of the remote database on page 55 are displayed. Verifying the automation JEE Framework: To verify that the automation JEE framework was installed successfully on AIX or Linux: 1. In a web browser window, specify the following address to display the Login window of the WebSphere Application Server administrative console: The default WebSphere Application Server administrative console port is On the Login window, enter the user ID and password of the WebSphere Application Server administrator user. 3. Navigate to Applications > Application Types > WebSphere enterprise applications. The list of installed applications must contain the entry EEZEAR. Verifying that DB2 accepts WebSphere Application Server requests: Perform the following task to verify that DB2 accepts WebSphere Application Server requests: 1. In a web browser window, specify the following address to display the Login window of the WebSphere Application Server administrative console: The default WebSphere Application Server administrative console port is On the Login window, enter the user ID and password of the WebSphere Application Server administrator user. 3. Navigate to Resources > JDBC > Data sources > EAUTODBDS. Click Test connection to verify that DB2 accepts WebSphere Application Server requests. If the test is successful, the following message comes up: Test connection for data source EAUTODBDS was successful. If the test fails, check if the DB2 port number specified for EAUTODB is correct. For more information, refer to Tivoli System Automation Application Manager, Reference and Problem Determination Guide. 72 Tivoli System Automation Application Manager V : Installation and Configuration Guide

91 Verifying the automation engine To verify that the automation engine was installed successfully, proceed as follows: Issue the command eezdmn -help. If the installation of the automation engine has been successful the list of available command options is displayed. Note: You can also use any of the other eezdmn command options to verify the installation of the automation engine. As long as you do not receive an exception, any message you receive verifies that the automation engine is installed correctly. For a complete list of the eezdmn command options, refer to Tivoli System Automation Application Manager, Reference and Problem Determination Guide. Verifying the operations console Perform the following steps to verify that the operations console was installed successfully: 1. In a web browser window, specify the following address to display the Login window of the Dashboard Application Services Hub: The default IBM Dashboard Application Services Hub port is On this window enter the System Automation administrator user ID. The default user ID is eezadmin. Click Log in. 3. On the Welcome page of the IBM Dashboard Application Services Hub, click the entry for Tivoli System Automation Application Manager. 4. When the Welcome page is displayed, click on System Automation Application Manager. 5. Select one of the Tivoli System Automation dashboards. The installation is successful if the selected dashboard opens. Post-installation tasks When you have verified the installation of System Automation Application Manager, you need to perform a number of post-installation tasks: v You should create and authorize additional users as described in Tivoli System Automation Application Manager, Administrator s and User s Guide. v To get System Automation Application Manager operational, you must create and activate an automation policy as described in Tivoli System Automation Application Manager, Administrator s and User s Guide. Enable the end-to-end automation manager to access the first-level automation domains referenced in the automation policy. Specify the user credentials for the first-level domains on the User Credentials tab of the configuration dialog. Starting the Application Manager configuration dialog on page 99 describes how to start the configuration dialog. For detailed information about the User Credentials tab, see User Credentials tab on page 111. Chapter 2. Installing 73

92 Modifying the Lightweight Third Party Authentication (LTPA) settings After the installation of System Automation Application Manager, you should check whether the LTPA settings are appropriate for your environment. During installation, the following LTPA parameters are automatically set in WebSphere Application Server: v LTPA Password is set to the password of the IBM Dashboard Application Services Hub administrator user ID v LTPA Timeout for forwarded credentials between servers is set to 1440 minutes LTPA Timeout is a security-related timeout. Because this timeout is absolute, a user will be logged out and forced to log in to the IBM Dashboard Application Services Hub again when the LTPA timeout is reached even if the user is working with the operations console at the time. To change the LTPA settings (for example, password and timeout) you use the WebSphere Application Server administrative console. In the administrative console, select Security > Global security. In the Authentication box, click on the link associated to the LTPA radio button. Configuring the number of users During the installation of System Automation Application Manager, a default value (30) is set that defines how many users can simultaneously connect to the automation manager using the System Automation operations console. You can change the current setting by changing the Maximum connections value for the EEZTopicConnectionFactory in the WebSphere administrative console: Resources >JMS > Topic connection factories > EEZTopicConnectionFactory > Connection pool properties. If Maximum connections is set to 0, the number of concurrent connections that can be established is allowed to grow infinitely. If the specified number of maximum connections is reached, the next connection attempt using the operations console will display the following error message: EEZU0011E: Unable to set up the event path between the operations console and the management server: CWSIAD005E: The JCA runtime failed to allocate a connection. Modifying available heap size After the installation of System Automation Application Manager, modify the heap size settings of the WebSphere Application Server to the following recommended values: v Minimum heap size: 768 MB v Maximum heap size: 2048 MB Perform the following steps to increase the JVM heap size: 1. Log on to the WebSphere administrative console. 74 Tivoli System Automation Application Manager V : Installation and Configuration Guide

93 2. Go to Servers > Server Types > WebSphere application servers > server1 > Server Infrastructure > Java and Process Management > Process Definition > Additional Properties > Java Virtual Machine. 3. Enter 2048 for the Maximum Heap Size and 768 for the Minimum Heap Size to avoid OutOfMemoryErrors. Refer to the WebSphere Application Server online documentation for more information about how to determine the optimum value for the maximum heap size, depending on the available physical memory. 4. Save your changes. Restart WebSphere Application Server for the changes to take effect. Upgrading from a Try and Buy version to a full product version If you have installed the Try and Buy version of System Automation Application Manager and decided to purchase the full product version, then you will receive another copy of the installation media. The installation media contains the license file for the full license. The license file is located in the license sub-directory. Extract the license file from the installation medium and perform the license upgrade by issuing the following command: eezdmn -instcert <fully qualified license_file_name> After upgrading the license, check if any updates are already available and install the latest service level. Uninstalling Use the uninstallation program to uninstall System Automation Application Manager. This topic describes how to uninstall System Automation Application Manager. An uninstallation program is provided that removes the components that are installed by the installation wizard. Note: Uninstall System Automation Application Manager before uninstalling WebSphere Application Server. Using the graphical uninstallation program Before you begin: v During uninstallation, a number of panels are displayed, prompting you to confirm that specific files are to be deleted. Check the files carefully before confirming the deletion. v If you changed the user repository settings of WebSphere Application Server to an external user repository after the installation of System Automation Application Manager, the following change is required: Change the variable EXTERNAL_USER_REP_ACTIVATE in file <EEZ_INSTALL_ROOT>/ uninstall/installvariables.properties to false: EXTERNAL_USER_REP_ACTIVATE=false. This prevents users and groups from being deleted in the WebSphere Application Manager in a subsequent uninstallation process. Chapter 2. Installing 75

94 Perform the following steps to uninstall System Automation Application Manager: 1. Launch the uninstallation program by entering the following command in a shell: <EEZ_INSTALL_ROOT>/uninstall/uninstall This starts the uninstallation wizard. 2. Read the information on the first wizard window and click Next. 3. Provide the requested information for the WebSphere Application Server: v v v WebSphere Application Server Admin user ID and password WebSphere Application Server - server name WebSphere Application Server profile name Click Next. 4. The Start Uninstallation window is displayed. The preparations to uninstall System Automation Application Manager are complete. Click Uninstall to start the uninstallation. 5. Some information panels are displayed while the uninstallation program checks your system for the information needed for the uninstall. 6. When the uninstallation is complete, a summary window is displayed. To exit the installation program, click Done. Note: If problems were encountered during the unconfiguration step, an error window appears before the actual uninstallation step, in which the files are removed from the disk. In such a case, perform the following steps: a. On the error window, click Save installation log files. b. Click Next if you want to remove all installed files. Otherwise, click Cancel to perform corrective actions and then rerun the uninstallation. Uninstallation in silent mode If you installed System Automation Application Manager in silent mode, the uninstallation must be silent too. The password parameter in the generated installvariables.properties file in the uninstall subdirectory does not have a corresponding value. Before starting the uninstallation in silent mode, you must enter this password manually, otherwise the silent uninstallation fails. Perform the following steps: Procedure 1. Edit the installvariables.properties file in the uninstall subdirectory. 2. Locate the password parameter by searching for WAS_ADMIN_PWD=, and specify the password. 3. To start the uninstallation, go to the uninstall subdirectory and issue the uninstall command. Installing on new operating systems New operating system support can be introduced with a fix pack <f>, where <f> is the respective fix pack number. 76 Tivoli System Automation Application Manager V : Installation and Configuration Guide

95 Installing the middleware software The middleware versions that are bundled as part of System Automation Application Manager version 4.1 might not be sufficient for newly supported operating systems. Before you install System Automation Application Manager, check the DB2 service level that is required to support the new operating system versions. If a service level higher than the one that you receive when you order System Automation Application Manager 4.1 is required, download that version from the respective download site. Install DB2 as described in Installing a DB2 server on page 51 by using the new DB2 version. Starting with fix pack the minimum version of Jazz for Service Management has changed. Therefore, the version of Jazz for Service Management that you receive when you order System Automation Application Manager 4.1 is not sufficient for any fix pack installation. For more information, see Installing a new Jazz for Service Management version on page 58. Installing System Automation Application Manager An installation of System Automation Application Manager version as described in Installing System Automation Application Manager on page 59 is only possible on the set of operating system versions that are initially supported for version Support for other operating system versions can be added with fix packs at a later point in time. Newly added operating system versions are referred as "new operating system support". If you want to install a fix pack on an already supported operating system, upgrade you installation as described in Installing fix packs on page 78. To check which new operating system support is introduced with which fix pack, see Supported operating systems on page 3. If new operating system support is introduced with a fix pack, this fix pack must be installed as an initial installation rather than an upgrade installation. Therefore, it is required to copy the 4.1 license file into the EEZ410<f><platform>/license directory before you start the fix pack installation: 1. Obtain a System Automation Application Manager license file that is contained in one of the 4.1 release deliverables: Product DVD Use one of the DVDs listed in Packaging on page 2 to obtain the license. You can find the license file that is named eez41.lic in directory EEZ4100<platform>/license. Electronic distribution Use one of the archive files that are listed in Packaging on page 2 to obtain the license. Extract the archive file. In the expanded directory tree, you can find the license file that is named eez41.lic in directory EEZ4100<platform>/license. 2. Extract the <f> fix pack archive file that contains the new operating systems support as described in Packaging on page 2. In the expanded directory tree, directory EEZ410<f><platform>/license is empty. 3. Copy the license file into the EEZ410<f><platform>/license directory of the expanded fix pack directory tree. 4. Start the System Automation Application Manager installation as described in Using the installation wizard on page 59. The installation program runs an initial installation of the product on the new operating system. Chapter 2. Installing 77

96 Installing fix packs Installing service means applying corrective service fix packs to release 4.1 of IBM Tivoli System Automation Application Manager or upgrading the software release level from release 4.1. In this documentation, the service fix packs that you use for updating System Automation Application Manager are referred to as product fix packs. Product fix packs and interim fixes are delivered as: v Self-extracting archives for AIX v Archives in TAR-format for Linux Note: Starting with fix pack the minimum version of Jazz for Service Management has changed. Before installing any fix pack, upgrade Jazz for Service Management to the required level. For more information, see Installing a new Jazz for Service Management version on page 58. Obtaining fix packs Read the release notes to find out which fix packs are required for a release update. The fix packs are available on the Tivoli System Automation Application Manager support page. Archive naming conventions Use the DVDs and archives listed in Packaging on page 2 to upgrade System Automation Application Manager from version 3.2 to version Naming convention for product fix pack archives: TIV-SAAM-<platform>-FP<fix_pack_number>.<archive_type> Where v <platform> represents the platform on which System Automation Application Manager is installed. v <fix_pack_number> represents the fix pack number. v <archive_type> represents the platform-specific file extension of the archive. Example: This is the tar archive that is used to install product fix pack 1 for System Automation Application Manager on Linux on System x platforms: TIV-SAAM-LinuxI386-FP0001.tar Naming conventions of the update installer location The location at which you find the update wizard program for installing the product fix pack after unpacking an archive has the following syntax: EEZ41<mf><platform>/<platform>/<update_wizard_file> where v <mf> represents modification level and fix level. For example, for fix pack , the directory is named EEZ4101. v <platform> represents the platform on which System Automation Application Manager is installed. 78 Tivoli System Automation Application Manager V : Installation and Configuration Guide

97 v <update_wizard_file> represents the update wizard program you use to install the product fix pack. Example: This is where you find the update wizard after the Linux on System x archive for fix pack 1 for System Automation Application Manager 4.1 is unpacked: EEZ4101I386/i386/ Usage instructions for the platform-specific archives These are the archives for applying service to System Automation Application Manager. AIX Table 29. Archives for AIX platforms Archive name TIV-SAAM-AIX-FP<fix_pack_number>.bin Description The archive is self-extracting. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>AIX/AIX/setup.bin Linux on System x Table 30. Archives for Linux on System x Archive name TIV-SAAM-LinuxI386-FP<fix_pack_number>.tar Description For extracting the archive, GNU tar 1.13 or later is required. Use the tar -xf command to extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>I386/i386/setup.bin Linux on System z Table 31. Archives for Linux on System z Archive name TIV-SAAM-LinuxS390-FP<fix_pack_number>.tar Description For extracting the archive, GNU tar 1.13 or later is required. Use the tar -xf command to extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>S390/s390/setup.bin Installing a product fix pack Before you begin: v Product fix packs are always cumulative. Chapter 2. Installing 79

98 v Release must be installed before any product fix pack can be installed. v You must have root authority. To install a product fix pack, perform the following steps: 1. Check the release notes to find out which archives are required. 2. Download the archives from the System Automation Application Manager support site. One archive is provided for each platform. Download the archive to a temporary directory. 3. Unpack the product fix pack archive to a temporary directory. For information about how to unpack the archive for your platform, refer to Usage instructions for the platform-specific archives on page Before performing the subsequent steps, check the release notes for additional or deviating installation instructions. 5. Change to the directory in which the update wizard program is located. For information on where to find the update wizard program, refer to Usage instructions for the platform-specific archives on page Start the update wizard. When the wizard is launched successfully, the Welcome window opens. 7. Follow the instructions on the wizard panels to install the product fix pack. Installing fix packs in a high availability setup If you made your installation of System Automation Application Manager highly available by using System Automation for Multiplatforms as described in High availability for System Automation Application Manager on page 150, perform the following steps to install service for System Automation Application Manager. The instructions assume that System Automation Application Manager is currently running on node 1 but not on node 2. Procedure 1. Exclude node 2, then stop node 2 within the System Automation for Multiplatforms domain using the command stoprpnode. It is important to stop the node and not just to exclude it. If you exclude node 2, the resources are still monitored. If the resources on node 2 become online due to the maintenance on node 2, they will be stopped automatically on both nodes. 2. Run the update installer on node 2. a. In case of remote DB2 setup, and if no other application uses the JDBC driver on this node, perform the following step: Temporarily rename the JDBC driver directory on node 2 in the file system, so that the WebSphere Application Server cannot find it. This ensures that there is no way for System Automation Application Manager on node 2 to connect to the remote database manager during update installation. You can determine the JDBC driver directory in the WebSphere administrative console. Open Environment > WebSphere Variables and inspect the variable DB2_JDBC_DRIVER_PATH. b. On the window High Availability, select I want to create or update a highly available System Automation Application Manager setup with two or more servers and No, all database installation steps have been performed prior to this installation in order to skip all steps related to the automation database. 80 Tivoli System Automation Application Manager V : Installation and Configuration Guide

99 3. In case of remote DB2 setup, perform the following step: Rename the JDBC driver directory back to its original name. 4. Then start node 2 using startrpnode and include node 2 again. 5. Move the end-to-end automation manager to node 2 (either by moving the application, or by excluding node 1). 6. Verify that System Automation Application Manager is properly installed (for example by inspecting the System Automation Application Manager operations console, and in particular the version number on the Welcome page). 7. To stop node 1 type stoprpnode. 8. Run the System Automation Application Manager update installer on node 1, observing the instructions described in step In case of remote DB2 setup perform the following step: Rename the JDBC driver directory back to its original name. 10. To start node 1 type startrpnode. 11. In case node 1 was excluded during step 5, include it again. Uninstalling fix packs Installing for high availability Uninstalling service is only supported by uninstalling the complete System Automation Application Manager as described in Uninstalling on page 75, and reinstalling to the level required. If you want to make System Automation Application Manager highly available using System Automation for Multiplatforms, you need to install System Automation Application Manager on an additional node. The following steps make sure that you keep your existing configuration and data, if you install System Automation Application Manager on an additional node. There are two scenarios: 1. You have one existing node and you want to install System Automation Application Manager on the second additional node. Both nodes are located in a high availability cluster with System Automation for Multiplatforms. 2. You have two existing nodes in a high availability System Automation for Multiplatforms cluster. You want to install System Automation Application Manager on one additional node. All three nodes are located in a high availability cluster. To install System Automation Application Manager on an additional node, perform the following steps: 1. Install System Automation Application Manager V3.2.2 on the additional node. Make sure to select I want to create a highly available SAAM setup with two or more servers on the high availability window in the installation wizard. 2. Potentially, do an update installation to System Automation Application Manager V4.1.x in order to match the fix pack level of the System Automation Application Manager installation on node Configure high availability for the end-to-end automation manager as described in Setting up the high availability policy on page 152. Chapter 2. Installing 81

100 Installing for Distributed Disaster Recovery Find out what to do, if you plan to implement a setup with a System Automation Application Manager on two GDPS sites. In this configuration, System Automation Application Manager is moved automatically by GDPS if the K-System master moves. Installing the prerequisite software on both sites Install all necessary System Automation Application Manager prerequisites on the nodes of both sites. The order in which you install them is not important, but you must ensure that the software versions, fix pack levels, and installation paths on both sites are the same. All configuration settings such as administrator ID and password, ports, DB2 instance, must be identical on both sites. See also Installing the middleware software on page 51. Installing and configuring System Automation for Multiplatforms Install System Automation for Multiplatforms on both sites. When the installation completes, create a single-node domain which is used to automate System Automation Application Manager, the WebSphere Application Server, and DB2 HADR: 1. Prepare the cluster node by using the preprpnode command. 2. Create the one-node peer domain by using the mkrpdomain command. 3. Start the domain by using the startrpdomain command. 4. Set up trace file spooling and adjust the ulimits to suit your needs. For details on the installation and configuration, see System Automation for Multiplatforms Knowledge Center. Installing System Automation Application Manager on the first site You can select either of the two sites for your first System Automation Application Manager installation. The first site must be installed as an initial installation in a high availability setup with local EAUTODB created during installation. Run your installation of System Automation Application Manager with the following options: v Install in a high availability setup, by selecting I want to create a highly available System Automation Application Manager setup with two or more servers, and Yes for the installation on the first node. v Select IBM DB2 on same system (local) and complete the required fields for this setup. v In the GDPS configuration section of the installation wizard, select Enable GDPS server connection and Enable GDPS backup server connection and specify the host name and port number of the GDPS K-Systems of both sites. For more information, refer to Installing System Automation Application Manager on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

101 Configuring System Automation Application Manager on the first site Use the following settings to associate the System Automation Application Manager with the GDPS site and to set up the high availability policy: v Start the cfgeezdmn configuration utility. v On the Application Manager tab of the launchpad window, click Configure. The configuration dialog is displayed. v In the Domain tab, click Alternate host. v In the Define Alternate End-to-end Automation Host dialog box, specify the alternate site host name of your other site, select Use GDPS to control the end-to-end automation manager site and select the correct GDPS site of the alternate host. v On the High Availability tab of the launchpad window, select Enable the high availability configuration tasks, and click Configure. v In the Select Application Manager High Availability Setup window, click Configure the Applications Manager single node high availability policy for a disaster recovery setup, and click OK. v In the Command shell tab, select Use specified user credentials and provide the user credentials. v Specify all the required information for this type of high availability policy and save your settings. Refer to Configuring the Application Manager common settings on page 105 and High availability for System Automation Application Manager on page 150. Setting up DB2 HADR Set up DB2 HADR for the Application Manager EAUTODB which was created during the installation of the first System Automation Application Manager. Stop the System Automation Application Manager. Make the database available as Primary at the site where the second System Automation Application Manager is going to be installed. For more information about how to install the setup, see DB2 for Linux UNIX and Windows Knowledge Center. Perform the following sequence of steps. The user ID performing these commands must be the DB2 instance owner. 1. Stop the System Automation Application Manager on the first site. Ensure that the DB2 instance is started on both sites. 2. Configure log shipping on the EAUTODB using the following commands, and substituting the values of the tags between < >: db2 update database configuration for <DB name> using LOGRETAIN recovery db2 update database configuration for <DB name> using LOGINDEXBUILD ON Where <DB name> is the name of the EAUTODB. 3. Set up HADR using the following commands: db2 update db cfg for <DB name> using HADR_LOCAL_HOST <Hostname 1> HADR_REMOTE_HOST <Hostname 2> HADR_LOCAL_SVC <Port 1> HADR_REMOTE_SVC <Port 2> HADR_REMOTE_INST <DB instance name> HADR_TIMEOUT 120 HADR_SYNCMODE <Sync mode> HADR_PEER_WINDOW 0 Chapter 2. Installing 83

102 Where: <DB name> is the name of the EAUTODB. <Hostname 1> is the host name of the node where the EAUTODB was created. <Hostname 2> is the host name of the node at the other site where System Automation Application Manager is going to be installed. <Port 1> the port that is used for transaction log shipping on the node where the EAUTODB was created. The transmission protocol is HTTP and the default port number is 5005 <Port 2> is the port that is used for transaction log shipping on the node at the other site (Site 2). The default is <DB instance name> is the instance name of EAUTODB on both sites. <Sync mode> choose between SYNC, NEARSYNC, and SUPERASYNC. Note: The following steps are required during the initial installation of the DR setup. They are also required if the EAUTODB cannot be automatically reintegrated after a disaster. This problem occurs after a System Automation Application Manager toggle in which the EAUTODBs on both sites were modified without replicating the changes to the other site. 4. Transfer the database to the other site. Create a directory on both nodes owned by the DB2 instance owner that belongs to the DB2 administrators group. This directory is for your backup. 5. Back up the database using the following command on the first site, replacing the values of the tags as indicated: db2 backup <DB name> to <Backup folder> Where: <DB name> is the name of the EAUTODB. <Backup folder> is the directory you created to store the backup. 6. Transfer the generated backup file to the DB2 host at the other site. On that site restore the backup by using the following command: db2 restore db <DB name> from <Backup folder> replace history file Where: <DB name> is the name of the EAUTODB. <Backup folder> is the directory you created to store the backup. 7. On the second site, you must adjust the HADR settings accordingly. The local host name must be exchanged with the remote host name. Use the following command, replacing the tags as indicated: db2 update db cfg for <DB name> using HADR_LOCAL_HOST <Hostname 1> HADR_REMOTE_HOST <Hostname 2> Where: <DB name> is the name of the EAUTODB. <Hostname 1> is the DB2 host name on the second site where System Automation Application Manager is going to be installed. <Hostname 2> is the DB2 host name on the first site. 8. Start HADR at the standby database first. This is the site where the System Automation Application Manager remains offline. If you set up HADR the first time during System Automation Application Manager installation, the standby site is the site where System Automation Application Manager is already installed. Use the following command: 84 Tivoli System Automation Application Manager V : Installation and Configuration Guide

103 db2 start hadr on database <DB name> as standby Where: <DB name> is the name of the EAUTODB. 9. Start HADR at the primary database. This is the site where System Automation Application Manager is going to be installed: db2 start hadr on database <DB name> as primary Where: <DB name> is the name of the EAUTODB. 10. Verify that the DB2 HADR is set up correctly on both sites. Use the following command on each site: db2pd -hadr -db <DB name> Where: <DB name> is the name of the EAUTODB. Check the output and verify that the HADR role is Standby at the site where System Automation Application Manager is already installed and Primary at the site where it is going to be installed. The HADR state on both sides must be Peer. Installing System Automation Application Manager on the second site Install System Automation Application Manager on the second site with the following options: v Install in a high availability setup, by selecting I want to create a highly available System Automation Application Manager setup with two or more servers and No as this is not the installation on the first node. v Select IBM DB2 on same system (local) and complete the required fields for this setup. v In the GDPS configuration section of the installation wizard, select Enable GDPS server connection and Enable GDPS backup server connection and specify the host name and port number of the GDPS K-Systems of both sites. For more information, see Installing System Automation Application Manager on page 59. Configuring System Automation Application Manager on the second site Configure the second System Automation Application Manager in the same way as described for the first site. All settings must be identical for both System Automation Application Manager installations, except for the GDPS site of the alternate System Automation Application Manager host. You can configure either using the graphical mode or the silent configuration utility. Refer to Configuring the Application Manager common settings on page 105 for the graphical configuration. If you want to use the silent configuration utility, perform the following steps: 1. On the site where System Automation Application Manager is already configured, create the silent properties input file for the Application Manager common configuration using the following command: Chapter 2. Installing 85

104 cfgeezdmn -s -e -gr 2. Transfer the silent properties input file from the first site to the host of the second site where you are now configuring System Automation Application Manager. 3. Adjust the settings for host name, alternate host name, and GDPS site location of the alternate host name. 4. Perform a silent configuration on the second site: cfgeezdmn -s -e Creating tools for the replication of policy and credential files The System Automation Application Manager policies and stored credentials must always be synchronized. Replication of configuration changes to the other site is not performed automatically by System Automation Application Manager, but has to be done manually by the operator each time the configuration on one site is updated. To simplify this task, you can install or develop a tool that copies the System Automation Application Manager policy pool and the dif properties files with the FLA domain credentials to the other site. You can customize the following example script with your site-specific information: #!/bin/sh scp r /etc/opt/ibm/tsamp/eez/policypool/ root@<hostname_at_other_site>: /etc/opt/ibm/tsamp/eez/policypool/ scp /etc/opt/ibm/tsamp/eez/cfg/eez.automation.engine.dif.properties root@<hostname_at_other_site>:/etc/opt/ibm/tsamp/eez/cfg Configuring all end-to-end automation adapters with two System Automation Application Manager hosts Every first-level automation adapter or remote agentless adapter connected to System Automation Application Manager must have the capability of switching its event target if the active System Automation Application Manager moves to the other site. For this to be possible, you must ensure that the version of the adapters you install supports the System Automation Application Manager site switch. Furthermore, both System Automation Application Manager host names should be defined as alternate targets on each system. The required adapter versions are: v Version or higher for all adapters that are part of the System Automation Application Manager product. v System Automation for Multiplatforms version or higher for the System Automation for Multiplatforms adapter. v System Automation for z/os 3.4 or higher for the z/os adapter. To configure the alternate System Automation Application Manager host name, start the configuration utility for the corresponding adapter, click Configure, and specify the alternate end-to-end automation management host name on the Host Using Adapter tab of the configuration dialog. For more information, refer to the specific sections on the adapter configurations in Chapter 3, Configuring, on page 99. The configuration for the System Automation for Multiplatforms adapter is described in System Automation for Multiplatforms Installation and Configuration Guide, SC Tivoli System Automation Application Manager V : Installation and Configuration Guide

105 For the system Automation for z/os adapter, there is no configuration utility. Refer to the System Automation for z/os documentation for information about how to apply this configuration in this environment. Configuring high availability and contact retry interval of all end-to-end automation adapters If a disaster occurs, end-to-end adapters might fail and the two sites might experience protracted communication problems. In such a situation, the System Automation Application Manager and the end-to-end adapters of the other site cannot communicate. All adapters and the JEE framework must be configured so that the adapters can try repeatedly to establish the connection to the JEE framework. The JEE framework must not remove previously connected domains before they can be reached again. It is recommended to set up the adapters as highly available resources. The following table lists the recommended settings of the end-to-end adapters and the JEE framework. See also System Automation Application Manager Reference and Problem Determination Guide, Chapter 4, "Modifying the environment variables for the automation Java EE Framework. For details about configuring adapters, refer to Chapter 3, Configuring, on page 99. Table 32. Recommended end-to-end adapter and JEE framework settings in a DR setup Configuration option JEE framework environment variable "com.ibm.eez.aab.domainremoval-hour" In the Advanced dialog in the Adapter configuration tabs: "Remote contact activity interval" In the Advanced dialog in the Adapter configuration tabs: "initial contact retry interval" End-to-end adapter is highly available End-to-end adapter is not highly available 48 (default) a value (default) 0 (retry forever) 0 (default) 0 (retry forever) Installing the remote agentless adapter You can install the remote agentless adapter using the wizard or in silent mode. Using the installation wizard to install the remote agentless adapter Use an installation wizard to install the remote agentless adapter on AIX, Linux, or Windows systems. The installation wizard files are located either on the product DVD or in the directory that is created as a result of extracting the electronic deliverable archive file for the respective operating system as listed in Packaging on page 18. Chapter 2. Installing 87

106 Run the following steps: Procedure 1. Log on to the system where you want to install the remote agentless adapter with a user ID that has administrator authority. This user ID is typically root. On Windows, this is the built-in local administrator user account of the system. If User Account Control (UAC) is active on the system, which is the default, make sure that the following default settings are active: User Account Control: Admin Approval Mode for the Built-in Administrator account is disabled and Usser Account Control: Detect application installations and prompt for elevation is enabled. 2. Change to the directory that contains the installation program. For the location of the directory, see Packaging on page 18. Start the installation by launching the installation wizard using setup.bin. On the first window, click OK to display the Welcome window. The language is detected automatically on your computer or you can select it on the Welcome window. To launch the installation wizard to generate a response file, use the following command: <installation_wizard> -Dpreparesilent=true. The following response file is generated: <install_root>\install\install.properties. When you launched the wizard, click Next on the Welcome window. Note: On a Windows system, you may get a Project Load Warning message indicating inconsistent installer versions. Ignore this message and press Enter to proceed with the installation process. 3. On Linux you can not change the default installation directory. On Windows you can specify a directory or leave the default value. Click Next to display the Tivoli Common Directory window. 4. If the installation program did not detect a Tivoli Common Directory on your system, accept the default location or specify a different directory. On Linux, the default directory can not be changed. If a Tivoli Common Directory was detected on your system, the directory is displayed and can not be changed. Click Next to display the preinstall summary. 5. After reviewing the displayed information, click Install to start the installation process. While the adapter is being installed, a progress window is displayed. When the installation is complete, an installation summary window is displayed, on which you can verify the success of the installation. If problems occur, check the applicable installation log files for more information. Click Done to close the installation wizard. Related information: Configuring remote agentless adapters on page 134 Configure remote System Automation Application Manager settings. Installing the remote agentless adapter in silent mode Use a response file which is generated during the wizard-driven installation to install the remote agentless adapter in silent mode. For information on how to generate a response file, refer to Using the installation wizard to install the remote agentless adapter on page 87. Copy the generated response file to the system where you want to install the remote agentless adapter in silent mode. If you want to perform a silent installation, you need the same authorization as described for using the installation wizard in graphical mode. If 88 Tivoli System Automation Application Manager V : Installation and Configuration Guide

107 you want to perform the remote agentless adapter installation on multiple systems with identical installation settings, copy the response file to each system and run the installation wizard in silent mode. Note: Response files contain password information. Delete the response files when they are no longer required. Procedure To install the remote agentless adapter in silent mode, use the following command: <installation_wizard> -i silent -f <response_file_name> Uninstalling the remote agentless adapter An uninstallation program is provided to remove the adapter that was installed by the installation wizard. If you want to uninstall the remote agentless adapter, you need the same authorization as described in Using the installation wizard to install the remote agentless adapter on page 87 for an initial installation. During uninstallation, you may be prompted to confirm that specific files are to be deleted. Make sure the right files are listed before you confirm the deletion. To determine the current status of the adapter, use the following command: eezaladapter status If the adapter is still running, stop the adapter before starting the uninstallation: eezaladapter stop For more information about the eezaladapter command, refer to Tivoli System Automation Application Manager, Reference and Problem Determination Guide. Procedure 1. To launch the uninstallation program, enter the following command in a shell: <EEZ_INSTALL_ROOT>/uninstall/uninstall. This opens the initial window of the uninstallation program. 2. The uninstallation program is launched in the same language as used for the installation. After the uninstallation program is launched, the uninstallation wizard starts. Perform the following steps: a. On the Welcome window, click Next to display the pre-uninstallation summary. b. After reviewing the displayed information click Uninstall to start the uninstallation process. c. The wizard removes the remote agentless adapter from your system. No configuration files will be removed. When the uninstallation is completed, the uninstallation summary is displayed. If problems occur, check the applicable installation log files for more information. Click Done to close the uninstallation wizard. 3. To perform a silent uninstallation, no response file is necessary. To launch the silent uninstallation, use the following command: <installation_wizard> -i silent. Chapter 2. Installing 89

108 Installing and uninstalling service for the remote agentless adapter Installing service means applying corrective service fix packs to release 4.1 of the System Automation Application Manager remote agentless adapter. The service fix packs that you use for updating a remote agentless adapter are referred to as product fix packs. Product fix packs and interim fixes are delivered as: v Self-extracting archives for AIX and Windows v Archives in TAR-format for Linux Where to obtain fixes The fix packs are available at Tivoli System Automation Application Manager Support page. The fix packs provides the links to the product related archives. Archive naming conventions The archives to upgrade a remote agentless adapter from version 4.1 have the following syntax: TIV-SAAMR-<platform>-FP<fix_pack_number>.<archive_type> v <platform>: Represents the platform on which the remote agentless adapter is installed. v <fix_pack_number>: Represents the fix pack number. v <archive_type>: Represents the platform-specific file extension of the archive. This is the tar archive that is used to install product fix pack 1 for the remote agentless adapter on Linux on POWER platforms: TIV-SAAMR-PPC-FP0001.tar Naming conventions of the update installer location Naming conventions of the update installer location After the Linux on POWER archive for fix pack 1 for the remote agentless adapter 4.1 is unpacked, you can find the update wizard in the following directory: EEZ4101Remote/PPC/ALAdapt/ Usage instructions for the platform-specific archives These are the archives for applying service to the remote Agentless Adapter. Table 33. Archives for applying service to remote Agentless Adapter Operating system Archive name Description Windows TIV-SAAMR-Windows- <fix_pack_number>.exe The archive is self-extracting. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>Remote\Windows\ALAdapt\setup.exe 90 Tivoli System Automation Application Manager V : Installation and Configuration Guide

109 Table 33. Archives for applying service to remote Agentless Adapter (continued) Operating system Archive name Description AIX Linux on System x Linux on POWER Linux on System z TIV-SAAMR-AIX- FP<fix_pack_number>.bin TIV-SAAMR- LinuxI386- FP<fix_pack_number>.tar TIV-SAAMR-LinuxPPC- FP<fix_pack_number>.tar TIV-SAAMR- LinuxS390- FP<fix_pack_number>.tar The archive is self-extracting. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>Remote/AIX/ALAdapt/setup.bin For extracting the archive, GNU tar 1.13 or later is required. Use the tar -xf command to extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>Remote/I386/ALAdapt/setup.bin For extracting the archive, GNU tar 1.13 or later is required. Use the tar -xf command to extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>Remote/PPC/ALAdapt/setup.bin For extracting the archive, GNU tar 1.13 or later is required. Use the tar -xf command to extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41<mf>Remote/S390/ALAdapt/setup.bin Installing a product fix pack Before you begin, be aware of the following: v Product fix packs are always cumulative. v Release 4.1 must be installed before any product fix pack can be installed. v To install a product fix pack, you must have root authority. To install a product fix pack, perform the following steps: 1. Check the release notes to find out which archives are required. 2. Download the archives for product fix packs from the System Automation Application Manager support site to a temporary directory. 3. Unpack the product fix pack archive to a temporary directory. For information about how to unpack the archive for your platform, see Usage instructions for the platform-specific archives on page Before performing the subsequent steps, check the release notes for additional or deviating installation instructions. 5. Change to the directory in which the update wizard program is located. For information on where to find the update wizard program, see Usage instructions for the platform-specific archives on page Launch the update wizard. The same authorization is required as described in Using the installation wizard to install the remote agentless adapter on page Follow the instructions on the wizard panels to install the product fix pack. The steps that you have to perform are the same as described for the initial installation. Chapter 2. Installing 91

110 Uninstalling service If you want to uninstall service you need to uninstall the complete remote agentless adapter as described in Uninstalling the remote agentless adapter on page 89. Then you can reinstall to the level required. Installing the IBM PowerHA adapter Find out how to install the PowerHA adapter using SMIT and how you can verify your installation. Using SMIT to install the adapter You will find the package in the directory on the DVD or in the electronic deliverable as described in Packaging on page 32. Package name: hac.adapter. Use the SMIT interface to install the adapter. The PowerHA adapter installation directory is /opt/ibm/tsamp/eez/hac. Note: Do not change the installation directory or the configuration directory (/etc/opt/ibm/tsamp/eez/hac/cfg). Otherwise, the PowerHA adapter cannot be run because it relies on fixed paths. After installing the adapter it must be configured as described in Configuring the PowerHA adapter on page 177. Verifying the PowerHA adapter installation You can use the clstat command to verify that the PowerHA adapter is running: 1. Open a terminal session on the nodes on which the PowerHA adapter may run. 2. In each session, type /usr/es/sbin/cluster/clstat. 3. The status screen depicted below should be displayed: v v Resource Group: hacadapter_rg (if the prefix is hacadapter ) in State: On line Interface: p57067ha (in the example configuration) associated with the service IP label of the same name in State: UP 92 Tivoli System Automation Application Manager V : Installation and Configuration Guide

111 clstat - HACMP Cluster Status Monitor Cluster: hacp57067 ( ) Mon Feb 20 14:15:16 MET 2011 State: UP Nodes: 2 SubState: STABLE Node: p570sa06 State: UP Interface: p570sa06 (0) Address: State: UP Interface: p57067ha (0) Address: State: UP Resource Group: hacadapter_rg State: On line Node: p570sa07 State: UP Interface: p570sa07 (0) Address: State: UP ************************ f/forward, b/back, r/refresh, q/quit ********* Uninstalling the PowerHA adapter To uninstall the PowerHA adapter, perform the following steps: 1. Stop the PowerHA adapter by using the hacadapter -stop command. 2. Use the SMIT interface to uninstall the adapter. The package name is hac.adapter. Installing the Failover Cluster (FOC) adapter You can install the FOC adapter either using the wizard or in silent mode. Make sure you verify your installation. Generate a response file when you use the installation wizard on a node. Install the adapter in silent mode on the remaining nodes of the cluster if you are making the adapter highly available, in which case the values in the response file apply to all nodes. Installing the Failover Cluster Command Interface optional feature The Failover Cluster Command Interface feature is required to configure the FOC adapter. Starting with Windows Server 2012 system, this feature is not installed anymore per default as part of the Failover Cluster (FOC) installation. The cluster.exe executable which is part of the feature is required by the cfgmscsadapter utility. If you are planning to use the FOC adapter, make sure that the Failover Cluster Command interface feature is installed on all nodes of the failover cluster. The feature is located in the hierarchy of installable features as follows: > Remote Server Administration Tools > Feature Administration Tools > Failover Clustering Tools Chapter 2. Installing 93

112 > Failover Cluster Command Interface Using the installation wizard to install the FOC adapter This topic describes how you install the FOC adapter using the installation wizard. For information on silent mode, see Installing the FOC adapter in silent mode on page 95. The installation wizard files are located either on the product DVD or in the directory that is created by extracting the archive file. You can find the archive file names for the respective operating system in the topic Packaging on page 35. Perform the following steps to install the adapter: 1. Log in with the domain user account prepared in Preparing the user account on page Launch the installation wizard. You have the following options: v v To launch the installation wizard without generating a response file, use the file: setup.exe When you launch the wizard in this way, the values that are displayed on the wizard panels are either default values or values that were detected on your system. Launch the installation wizard to generate a response file. Enter the command: setup.exe -Dpreparesilent=true You can find the response file in the following directory: <install_root>\install\install.properties When you launched the wizard, click Next on the Welcome window. 3. Specify the directory where you want to install the adapter or accept the default location. Click Next to display the Tivoli Common Directory window. 4. If the installation program did not detect a Tivoli Common Directory on your system, accept the default location or specify a different directory. If a Tivoli Common Directory was detected on your system, the directory is displayed and cannot be changed. Click Next to display the Microsoft Failover Cluster adapter service user window. 5. Specify the domain user account prepared in Preparing the user account on page 36 and the password. Click Next to display the summary window. 6. Check the values on the summary window and click Install to start the installation. 7. While the adapter is being installed, a progress window is displayed. When the installation is complete, an installation summary window is displayed, on which you can verify the success of the installation. If problems occur, check the applicable installation log files for more information. Click Finish to close the installation wizard. 94 Tivoli System Automation Application Manager V : Installation and Configuration Guide

113 Installing the FOC adapter in silent mode This topic describes how you install the adapter in silent mode, using a response file you generated during wizard-driven installation. For information on how to generate a response file and how to use it as input for a wizard-driven installation, see Using the installation wizard to install the FOC adapter on page 94. To install the FOC adapter in silent mode, use the following command: setup.exe -i silent -f <response_file_name> Note: 1. Response files contain password information and should be deleted when they are no longer needed. 2. The silent installation will only be successful if the wizard-driven installation where the response file was generated completed successfully without errors. Upgrading the FOC adapter You can upgrade an already installed FOC adapter to the current version by running the installation as described in Installing the Failover Cluster (FOC) adapter on page 93. Verifying the FOC adapter installation Perform the following steps to verify that the adapter is installed and configured correctly: The adapter is highly available: 1. Start the FOC adapter using Microsoft FOC and check if the domain joins. 2. Fail the adapter over to all Microsoft FOC nodes and check if the domain joins. The adapter is not highly available: Start the FOC adapter using the Services plug-in from the Microsoft Management Console and check if the domain joins. Uninstalling the FOC adapter Perform the following steps: 1. Make sure that the FOC adapter service is stopped before starting the uninstallation. Note that Microsoft FOC may try to restart or fail the FOC adapter service over to another Microsoft FOC node if you stop the service manually. If the FOC adapter service is highly available, you must take the FOC adapter group offline. 2. Open the Windows Control Panel and use Add or Remove Programs to uninstall the adapter. Chapter 2. Installing 95

114 Installing the Veritas Cluster Server (VCS) adapter HACMP You can install the VCS adapter using the wizard or in silent mode. Make sure you verify your installation. Using the installation wizard to install the VCS adapter You use an installation wizard to install the VCS adapter on Solaris/SPARC systems. Perform the following steps: 1. Log in as root on the system where you want to install the VCS adapter. 2. Launch the installation wizard using the file install.bin. On the window that appears, click OK to display the license agreement. The language is detected automatically or you can select it on the first window. To launch the installation wizard, generating a response file, use the following command: install.bin -Dpreparesilent=true This is the response file that is generated: <install_root>\install\install.properties After installing the adapter it must be configured as described in Configuring the VCS adapter on page 193. Installing the VCS adapter in silent mode This topic describes how to install the adapter in silent mode, using a response file generated during wizard-driven installation. For information on how to generate a response file and how to use it as input for a wizard-driven installation, refer to Using the installation wizard to install the VCS adapter. To install the VCS adapter in silent mode, use the following command: install.bin -i silent -f <response_file_name> Note: 1. Response files contain password information. Delete the response files when they are no longer required. 2. The silent installation is successful if the wizard-driven installation completed successfully without errors on the system where the response file was generated. Verifying the VCS adapter installation You can use the hastatus command to verify that the VCS adapter is running: 1. Open a terminal session on the nodes on which the VCS adapter may run. 2. In each session, type /opt/vrts/bin/hastatus. 96 Tivoli System Automation Application Manager V : Installation and Configuration Guide

115 3. A status screen similar to the following is displayed, showing the status of the member resources of the resource group vcsadapter-rg: sasun01:~ # hastatus attempting to connect... connectedgroup resource system message vcsadapter-rg sasun01 OFFLINE vcsadapter-rg sasun02 ONLINE vcsadapter-rs sasun01 OFFLINE vcsadapter-rs sasun02 ONLINE vcsadapter-ip sasun01 OFFLINE vcsadapter-ip sasun02 ONLINE Uninstalling the VCS adapter To uninstall the VCS adapter, perform the following steps: 1. Stop the VCS adapter by using the vcscadapter -stop command. 2. Open a shell and navigate to /opt/ibm/tsamp/eez/vcs/uninstall_vcs_adapter. 3. Invoke the script Uninstall VCS Adapter to uninstall the adapter. Chapter 2. Installing 97

116 98 Tivoli System Automation Application Manager V : Installation and Configuration Guide

117 Chapter 3. Configuring After you installed System Automation Application Manager and the components that you require, complete the configuration tasks to fully prepare your infrastructure environment. This topic describes the following configuration scenarios: v How to use the configuration utility to change the common configuration of System Automation Application Manager. v How to configure distributed disaster recovery. v How to configure agentless adapters. v How to configure high availability of System Automation Application Manager. Furthermore, it describes the configuration utilities to configure the first-level automation adapters that are part of System Automation Application Manager. Note: You need an X11 server to use the dialogs of the configuration utilities. You need the 32-bit version of the X11 installation packages to run the configuration dialog. On some Linux operating system platforms, those packages are contained on the distribution media, but are not part of the standard installation. Make sure that the 32-bit version of the X11 installation packages is installed. You can also configure the application manager in silent mode by using an input properties file. If an X11 server is not available, silent configuration is the only supported method on this system. For more information, see Starting silent configuration on page 205. Configuring the Application Manager Configure the Application Manager by starting the Application Manager Configuration - Task Launcher dialog. Starting the Application Manager configuration dialog The cfgeezdmn command configures the settings of different System Automation Application Manager components that run on the Application Manager server and the remote Agentless Adapters. The command offers a graphical user interface to specify parameters, which are stored in various property files that are required by the System Automation Application Manager components. Most parameters that are configured with this command control the behavior of the System Automation Application Manager components and do not need to be changed frequently. In addition, the cfgeezdmn command is used to add or change user IDs and passwords that are used to communicate with other automation domains and remote nodes. The user ID you use to start the dialog must meet the following requirements: Copyright IBM Corp. 2006,

118 v The user ID must be in same group as the user ID you used for installing System Automation Application Manager. The group permissions for the cfgeezdmn script must be set to EXECUTE. v The user ID must have write access to the following directory: /etc/opt/ibm/tsamp/eez/cfg Perform the following step to start the configuration dialog: 1. Log in on the system where System Automation Application Manager is installed. 2. Run the command: cfgeezdmn The configuration dialog task launcher is displayed. For more information, see Configuring the Application Manager settings. Configuring the Application Manager settings The initial window of the configuration dialog is called task launcher and provides all configuration tasks. The task launcher opens when you start the configuration dialog. For more information, see Starting the Application Manager configuration dialog on page 99. More detailed information about all configuration tasks is available in the online help. To start the online help, click Help in the menu bar of the configuration dialog. Application Manager tab Use the Application Manager tab for common configurations for the System Automation Application Manager. Figure 5. Application Manager tab of the Automation Manager Configuration dialog The Application Manager tab contains the following controls and fields: Application Manager common configuration: Configure Click Configure to open the Application Manager common settings dialog. 100 Tivoli System Automation Application Manager V : Installation and Configuration Guide

119 You can specify configuration settings that are common for different components of System Automation Application Manager. For more information, see Configuring the Application Manager common settings on page 105. Refresh Click Refresh to update configuration settings of the active, running Application Manager application. For more information, see Refreshing the Application Manager common configuration on page 114. Non-clustered Nodes tab Use the Non-clustered Nodes tab to configure agentless adapters. Figure 6. Non-clustered Nodes tab of the Automation Manager configuration dialog Controls and fields on the Non-clustered Nodes tab: Local agentless adapter configuration: Enable local agentless adapter configuration Select this check box to enable the Local agentless adapter configuration with the following effects: v The Configure button of the Local Agentless Adapter configuration is enabled. v Configuration files of the local agentless adapter are updated if they are affected by changes that you apply to the Application Manager common configuration. v If you configure Application Manager high availability, the corresponding resources are included into the Application Manager automation policy. For more information about configuring high availability of the Application Manager, see High availability for System Automation Application Manager on page 150. The configuration dialog remembers the enable/disable status of the local agentless adapter configuration across multiple invocations. Note: This check box applies only to the local agentless adapter, but not to any remote agentless adapter. Chapter 3. Configuring 101

120 Configure Click Configure in the Local Agentless Adapter configuration section of this tab to open the Application Manager agentless adapter configuration dialog. For more information, see Configuring the local agentless adapter on page 128. Remote agentless adapter configuration: Configure Click Configure in the Remote Agentless Adapter configuration section of this tab to open the Application Manager remote agentless adapter configuration dialog. For more information, see Configuring remote agentless adapters on page 134. Virtual Server / HW Management tab Use the Virtual Server / HW Management tab to configure the hardware adapter. The following two functions of the hardware adapter can be configured: v Access the zenterprise Hardware Management Console (HMC) for virtual server management. v Manage hardware for distributed disaster recovery with Geographically Dispersed Parallel Sysplex (GDPS). Note: The tasks on this tab are only enabled on a limited set of operating systems. For more information, see Supported hardware and operating systems on page 28. Figure 7. Virtual Server / HW Management tab of the Application Manager Configuration dialog Controls and fields on the Virtual Server / HW Management tab: Configure Click Configure to open the hardware adapter configuration dialog. Use this dialog to configure the hardware adapter host or the hardware access credentials that the hardware adapter uses or both. For more information, see Configuring the hardware adapter on page 139. Refresh Click Refresh to trigger a reload of changed hardware access credentials 102 Tivoli System Automation Application Manager V : Installation and Configuration Guide

121 Test into an active, running hardware adapter. For more information, see Refreshing the active hardware adapter configuration on page 145. Click Test to test the hardware adapter functionality without powering on or off the remote hardware systems and to test connectivity to the zenterprise HMC. For more information, see Testing the active hardware adapter on page 145. Storage Replication tab Use the Storage Replication tab to configure the Tivoli Storage Productivity Center for Replication domain to manage storage replication. Note: The tasks on this tab are only enabled on a limited set of operating systems. For more information, see Supported hardware and operating systems on page 28. Figure 8. Storage Replication tab of the Application Manager Configuration dialog The Storage Replication tab contains the following controls and fields: Configure Click Configure to open the TPC-R domain configuration dialog. Use this dialog to configure the settings of the TPC-R domain and the user credentials to access the corresponding TPC-R servers. For more information, see Configuring the TPC-R domain on page 146. Refresh Click Refresh to trigger a reload of the TPC-R domain settings by the active, running Application Manager application. Refresh recycles any active session with a TPC-R server in order to pick up changed user credentials. For more information, see Refreshing the TPC-R domain settings on page 149. Test Click Test to test the currently configured TPC-R domain properties. For more information, see Testing the TPC-R domain configuration on page 149. High Availability tab Use the High Availability tab to configure the System Automation Application Manager high availability policy. Chapter 3. Configuring 103

122 Figure 9. High Availability tab of the Application Manager Configuration dialog Click a task button by enabling the Enable the high availability configuration tasks check box. The configuration dialog remembers the enable / disable status of the high availability configuration across multiple invocations. The High Availability tab contains the following controls and fields: Configure Click Configure on the High Availability tab of the task launcher window to open the high availability policy configuration dialog. If you are running on a Linux for System z operating system platform, the Select Application Manager High-Availability Setup dialog opens. Select which type high availability policy you want to configure. The dialog offers two options: 1. Configuring the high availability policy on page High availability for a disaster recovery setup on two sites on page 168 Replicate For more information, see Replicating the configuration files on page 160. Set up domain For more information, see Setting up the domain on page 161. Remove domain For more information, see Removing the domain on page 162. Validate&Store policy For more information, see Validating and storing the automation policy on page 162. Define policy For more information, see Defining the automation policy on page 163. Remove policy For more information, see Removing the automation policy on page 163. Passwords Management tab Use the Passwords Management tab to change the passwords for any of the user credentials that are defined in the System Automation Application Manager configuration. 104 Tivoli System Automation Application Manager V : Installation and Configuration Guide

123 Use this tab as a shortcut to manage passwords rather than starting various configuration tasks. Especially if you must change multiple or even all credentials at the same time. Figure 10. Change Passwords tab of the Application Manager Configuration dialog The table on this tab contains entries for all credentials that can be configured for System Automation Application Manager. The Change Passwords tab contains the following controls and fields: Component This column shows all components that contain user credentials as part of their configuration. If multiple credentials can be configured for a component, one list entry shows the same component for each user ID. User ID This column shows the user IDs that are currently configured for the respective credentials. If <not configured> is shown, either the complete component is not configured or the corresponding credentials are currently not configured, because they are optional. Description This column explains the purpose of the corresponding credentials. Change password Use the Change password button to display a dialog that prompts you to specify and confirm the new password for the selected user ID. A password change does not change any password on the affected system, but only in one of the configuration files. After you successfully changed a password, the resulting message will indicate the updated configuration file. Configuring the Application Manager common settings The initial configuration of System Automation Application Manager is processed during the installation of the product. To browse or change the properties, use the System Automation Application Manager configuration dialog or silent configuration. Do not manually edit the configuration properties files in which the configuration parameters are stored. Chapter 3. Configuring 105

124 The following topics describe the common configuration tabs of the System Automation Application Manager configuration dialog. To open the configuration dialog, process the following steps: 1. Start the configuration dialog (see Starting the Application Manager configuration dialog on page 99). 2. Click Configure on the Application Manager tab of the task launcher window. The common configuration dialog opens. Refer to Domain tab. Post-configuration tasks: After the configuration properties are edited, run the following tasks: v Some configuration settings can be dynamically activated by clicking the Refresh task on the Application Manager tab of the task launcher. v If System Automation Application Manager is configured for high availability, replicate the configuration files to the other nodes of the System Automation for Multiplatforms cluster that provide high availability. For more information, see Replicating the configuration files on page 160. Changes in the domain name, host name, port numbers, or policy pool location on the Domain tab become effective, if the automation engine was restarted. Enter the commands eezdmn -stop and eezdmn -start. If you are using the hardware adapter of the Distributed Disaster Recovery feature, it must also be restarted by using the commands eezhwadapter -stop and eezhwadapter -start. Domain tab Use the Domain tab to configure the end-to-end automation domain and the host where the end-to-end automation manager is running. Controls and fields on the Domain tab: Domain name The name of the end-to-end automation domain. The name in this field must be the same as the XML element <AutomationDomainName> in each of the domain's automation policy files. Only the following ASCII characters can be used for the domain name: A Z, a-z, 0 9,. (period), and _ (underscore). The maximum number of characters for a valid automation domain name is 64. Host name or IP address Name or IP address of the system that hosts the end-to-end automation manager. Alternate Host Click to configure an alternate end-to-end automation host, and follow the procedure that is described in Configuring an alternative end-to-end automation host on page 114. WAS bootstrap port number The bootstrap port of the WebSphere Application Server instance that hosts the end-to-end automation manager. Command line request port number The port on which the automation engine receives command line interface requests. 106 Tivoli System Automation Application Manager V : Installation and Configuration Guide

125 Event port number The port on which the EIF message converter listens for events from the first-level automation domains. This port number must match the port number for the end-to-end automation manager host in all adapter configurations. You can configure the event port number for the end-to-end automation manager host during the configuration of the automation adapters on first-level automation domains. For the System Automation for z/os adapter, the event port number is the event port that is specified in the adapter configuration parameter eif-send-to-port in the adapter plug-in properties file. Policy pool The fully qualified name of the directory that contains the XML automation policy files for the end-to-end automation domain. Only automation policy files that are available in this directory can be activated. Command Shell tab Use the Command Shell tab to configure authentication settings for using the Application Manager command shell. Controls and fields on the Command Shell tab: User authentication for invoking the command shell: The end-to-end automation manager requires authentication when a user starts the end-to-end automation manager command shell by entering the eezcs command. By default, users are always prompted for their user credentials. You have the choice between these authentication modes: Read user credentials from stdin Users must always specify their user credentials in the shell window by using the -u and -p options. Prompt for user authentication Users are always prompted for their credentials by an X11 dialog unless they specify them when they use the command shell. Use specified user credentials A shared user ID is used for authentication, which prevents users from being prompted for their credentials when they use the command shell. Specify the shared user ID and the corresponding password in the fields User ID and Password. Only the following ASCII characters can be used for the user ID: A Z, a-z, 0 9, and _ (underscore). To change the password, click Change. Note: If the hardware adapter is configured to manage hardware for distributed disaster recovery with GDPS, specify the user credentials independent from the selected authentication mode. Correct authentication is ensured when the hardware adapter internally uses the command shell in this setup. User authentication for invoking commands against first-level automation (FLA) domains: If the command shell is used to run FLA domain commands, more authentication is required to access FLA domains. Choose between the following authentication modes: Chapter 3. Configuring 107

126 Read FLA domain access credentials from stdin Specify the FLA domain access credentials in the command shell window by using the -du and -dp options. Use FLA domain credentials as specified under "User credentials" Omit FLA domain access credentials in the command shell window if credentials are defined for the respective domain on the "User credentials" tab (see User Credentials tab on page 111). Discovery Library Adapter tab Use the Discovery Library Adapter tab to configure the location where the Discovery Library Adapter (DLA) stores IdML books. System Automation Application Manager provides a DLA to export the currently active System Automation Application Manager resource topology to an Identity Markup Language (IdML) discovery book. Controls and fields on the Discovery Library Adapter tab: IdML book directory The fully qualified path to the directory where the DLA stores IdML books. The Browse button that you can use to select a directory is only enabled if you select the local IdML book directory radio button. Local/remote directory Select whether the IdML book directory is on the computer where the DLA is running or on a remote system. Local IdML book directory The IdML book directory is on the computer where the DLA is running. Remote IdML book directory The IdML book directory is on a remote system. Hostname The host name of the remote system where the IdML book directory is located. This field is only enabled if you select the Remote IdML book directory radio button. User ID The logon user ID that is used by the DLA to store IdML books on the remote system. This field is only enabled if you select the Remote IdML book directory radio button. Password The logon password that is used by the DLA to store IdML books on the remote system. This field and the Change button are only enabled if you select the remote IdML book directory radio button. Click Change to change the password. OSLC tab Use the OSLC tab to configure the settings to use the Open Services for Lifecycle Collaboration (OSLC) services provided by System Automation Application Manager. Controls and fields on the Event Publishing tab: 108 Tivoli System Automation Application Manager V : Installation and Configuration Guide

127 Enable resource registration using OSLC services Select this check box if you want to use the Application Manager OSLC services. If the check box is not selected, the other fields on this tab are disabled. Host name or IP address The host where the OSLC administration and registry server that is used by the Application Manager is located. Port number The port number used to communicate between the end-to-end automation management server and the OSLC administration and registry server. User ID The user ID that is used to logon to the OSLC administration and registry server. Password The password that is used to logon to the OSLC administration and registry server. Click Change to change the password. Truststore The name of the truststore file used for Secure Sockets Layer (SSL) communication with the OSLC server. Click Browse to select a file. Truststore password The password of the truststore file. Click Change to change the password. Event Publishing tab Use the Event Publishing tab to configure settings to publish EIF events to Tivoli Netcool/OMNIbus or to Geographically Dispersed Parallel Sysplex (GDPS). Controls and fields on the Event Publishing tab: OMNIbus event publishing Enable OMNIbus EIF event publishing Select this check box if you want EIF events to be sent to the host where the OMNIbus Probe for Tivoli EIF is running. If the check box is not selected, all fields for OMNIbus event publishing on this tab are disabled. Event server Note: For compatibility reasons, alternatively a Tivoli Enterprise Console server and port can still be configured. Host name or IP address The host name or IP address of the host where the OMNIbus Probe for Tivoli EIF is running. You can specify up to eight values, which are separated by commas. The first location is the primary event server. All other locations are secondary servers that are used in the order that is specified and when the primary server is down. Port number The port number on which the OMNIbus Probe for Tivoli EIF is listening to EIF events. Event filter Publish EIF events caused by: Chapter 3. Configuring 109

128 Automation domain events Select this check box if you want EIF events for Application Manager automation domain events to be sent to the event server. Otherwise, domain events are filtered out. Adding and removing requests Select this check box if you want EIF events for adding and removing requests to be sent to the event server. Otherwise, events for adding and removing requests are filtered out. Resource status changes Select this check box if you want EIF events that are related to resource status changes to be sent to the event server. Otherwise, all resource status change events are filtered out. If you choose resource status change events to be published, select the status change severity for which events are published. Defining more filters: The event filters that you can enable or disable on this tab are the predefined filters that are included with System Automation Application Manager. If you want to define more filters, modify manually the corresponding configuration properties file: /opt/ibm/tsamp/eez/cfg/eez.publisher.omnibus.properties Do not edit predefined filters in this file, add new filters only. If you want to edit a predefined filter, add a new filter and disable the predefined filter. If configuration changes are applied by the cfgeezdmn configuration utility, any filters that you added are preserved. GDPS event publishing Hardware management with GDPS is enabled Note: If you have not enabled configuration of the hardware adapter for distributed disaster recovery with GDPS, all fields to configure GDPS event settings are disabled. Host name or IP address If you use the System Automation Application Manager hardware adapter to manage hardware for distributed disaster recovery with GDPS, define the GDPS event server. Provide the host name or IP address of the GDPS event server. Port number The port number on which the GDPS event server is listening to EIF events. Enable a backup GDPS event server Optionally, you can also configure a backup event server (Host name or IP address) and port. Select this check box if you want to configure a backup GDPS event server. Specify the backup server host name or IP address and port number in the entry fields that get enabled when you select the check box. For more information about configuration of the hardware adapter for distributed disaster recovery with GDPS, see Configuring the hardware adapter on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

129 User Credentials tab Use the User Credentials tab to configure the user credentials of the end-to-end automation manager. The automation manager uses these credentials to authenticate itself. The characters that are used for all user IDs entered on this tab are limited to the following ASCII characters: A Z, a-z, 0 9, and _ (underscore). Controls and fields on the User Credentials tab: Functional user ID The end-to-end automation engine uses the functional user ID to access the automation JEE framework that is running in WebSphere Application Server. The automation JEE framework uses the same user ID to access JMS and to run asynchronous tasks. Functional password The password for the functional user ID. Click Change to change the password. Generic user ID The user ID the automation manager uses to authenticate itself to a first-level automation domain when no credentials are specified for the domain in the Credentials for accessing specific FLA domains table. Generic password The password for the generic user ID. Click Change to change the password. Credentials for accessing specific first-level automation domains Click Add to specify a user ID that is valid for a specific domain. The user ID is not required to be root, but to be authorized to run operations on resources in the first-level automation domain that are supported by the end-to-end automation manager. For example, bringing an automated resource online. v Click Remove or Change to remove or modify the credentials for the selected domain. v Click Validate to validate the user ID and password that you specified for the selected domain. The domain is contacted, and the validation is performed on the system where the end-to-end automation adapter that manages the domain is running. For more information, see Tivoli System Automation Application Manager, Administrator s and User s Guide. Security tab Use the Security tab to configure the properties for the Secure Sockets Layer (SSL) connection to the first-level automation domains. Controls and fields on the Security tab: Truststore The fully qualified file name of the truststore file that is used for SSL. Click Browse to select a file. Keystore The fully qualified file name of the keystore file that is used for SSL. Click Browse to select a file. Chapter 3. Configuring 111

130 Keystore password The password of the keystore file. The password is required if a keystore file was specified. Click Change to change the password. Note: If the truststore is in a different file than the keystore, the passwords for the files must be identical. Certificate alias The alias name of the certificate to be used by the server. The characters that are used for the certificate alias are limited to the following ASCII characters: A Z, a-z, 0 9, and _ (underscore). Enforce use of SSL for all first-level automation domains Select this check box if you want to enforce that all first-level automation domains are properly configured to use SSL at the transport layer. Then, all first-level automation domains can successfully connect to the end-to-end automation manager. If not selected, first-level automation domains are configured to use SSL on an individual basis. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. Logger tab Use the Logger tab to configure message logging, tracing, and FFDC options for different components of System Automation Application Manager. The settings apply to the following components: v End-to-end automation engine v End-to-end automation manager command shell v Discovery library adapter v agentless adapter, if its configuration is enabled v Hardware adapter, if it is configured On the Logger tab, you can modify the following settings: 1. Change the settings temporarily. Perform these steps after you made sure that the automation engine is running: a. Make the required changes on the tab. b. Click Apply. Result: The new settings take effect immediately. They are not stored in the properties file. If the automation engine is not running on the system where this dialog is running, an error message occurs. 2. Change the settings permanently. Perform these steps: a. Make the required changes on the tab. b. Click Save. Result: The settings in the properties file are updated. To change the settings immediately, click Apply and then Save. 3. Revert to the permanent settings. If you changed the settings temporarily, you can revert to the permanent settings defined in the properties file as follows: a. Start the configuration dialog and open the Logger tab. The Logger tab displays the values that are currently set in the properties file. b. Click Apply to activate the settings. 112 Tivoli System Automation Application Manager V : Installation and Configuration Guide

131 Result: The settings take effect immediately. Controls and fields on the Logger tab: Maximum log/trace file size The maximum disk usage in KB that a log file can reach. If the limit is reached, another log file is created. The maximum number of log files is two, which means that the least recent file gets overwritten after both files are filled up. The default maximum file size is 1024 KB. Message logging level Select the Message logging level, depending on the severity of messages that you want to be logged. Trace logging level Select the Trace logging level, depending on the severity of the incidents that you want to be logged. First failure data capture (FFDC) recording level Select the FFDC recording level, depending on the severity of the incidents for which you want FFDC data to be collected. First failure data capture (FFDC) maximum disk space Specify the maximum disk space in bytes used by FFDC traces, which are written to the FFDC trace directory. The default space is bytes (10 MB). First failure data capture (FFDC) space exceeded policy Select one of the options: Ignore Issue a warning, but do not enforce the FFDC disk space limitation. Auto-delete Automatically delete FFDC files to enforce the FFDC disk space limitation. This is the default value of the space exceeded policy. Suspend Halt further FFDC actions until disk space is freed manually. First failure data capture (FFDC) message ID filter mode Select one of the options: Passthru All log events with messages that are specified in the message ID list will pass the filter and FFDC data is written. This is the default filter mode. Block All log events with messages that are specified in the message ID list are blocked. First failure data capture (FFDC) message ID list The message IDs that control for which log events FFDC data is written, depending on the filter mode. The comparison of message IDs is case-sensitive. Each message ID must occur in a new line. Wildcard characters, for example, *E for all error messages, are allowed. Save the common configuration To save your changes to the System Automation Application Manager common configuration properties files, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which Chapter 3. Configuring 113

132 configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. If you configured high availability for System Automation Application Manager, replicate the properties files to the other nodes in the System Automation for Multiplatforms cluster. For more information, see Replicating the configuration files on page 160). Refreshing the Application Manager common configuration Click Refresh on the Application Manager tab of the configuration dialog task launcher to trigger configuration settings. The settings are reloaded by the end-to-end automation engine. Use this task in the following cases: v Click Refresh after you changed the credentials for accessing specific first-level automation domains on the User Credentials tab of the System Automation Application Manager common configuration. v To clear the list of first-level automation domains that cannot be accessed anymore due to unrecoverable access errors. For more information, see Tivoli System Automation Application Manager, Administrator s and User s Guide. After you edited the System Automation Application Manager common configuration, restart the automation engine by entering the commands eezdmn -stop and eezdmn -start. Configuring System Automation Application Manager in silent mode You can configure System Automation Application Manager in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to perform the following configuration tasks: v Configuring Application Manager common settings v Refreshing the Application Manager common configuration. Refer to Configuring in silent mode on page 203 for a detailed description of the silent mode configuration tasks. Configuring an alternative end-to-end automation host The definition of an alternative end-to-end automation host is optional. If you want to configure a disaster recovery setup by using two different sites for System Automation Application Manager, the end-to-end automation manager can run on either site. To enable such a setup, you must define the host of System Automation Application Manager on the alternative site. Click Alternate Host on the Domain tab on page 106. In the dialog that opens, specify the host name or IP address of the WebSphere Application Server hosting the automation manager application on the alternative site. If you are running on a Linux for System z operating system, you can select to use Geographically Dispersed Parallel Sysplex (GDPS) to control on which site the end-to-end automation host is located. In this case, you must also select the GDPS site where the local and the alternative end-to-end automation hosts are located. 114 Tivoli System Automation Application Manager V : Installation and Configuration Guide

133 When you are configuring an alternative end-to-end automation host, proceed as follows: 1. Specify the host names that you use in this configuration in a reciprocal way for the Application Manager common configuration on the alternative site: v v Specify the local end-to-end automation host name of this configuration as alternative host name for the configuration on the alternative site. Specify the alternative host name of this configuration as local end-to-end automation host name for the configuration on the alternative site. 2. If you are using GDPS to control on which site the active end-to-end automation host is located, select which host is on which GDPS site. If you selected the alternative host to be on GDPS Site1, the local host is on GDPS site 2 and vice versa. 3. Specify both the local and the alternative end-to-end automation host name on the Host Using Adapter tab in the configuration of all end-to-end automation adapters. When an Application Manager site is switched, this setting ensures that the adapters smoothly switch to the new active end-to-end automation manager instance as the target for sending events. 4. If there is an Application Manager site switch, there might be a relatively long period where end-to-end automation adapters cannot communicate with either end-to-end automation host. To ensure that adapters continue to contact the System Automation Application Manager, configure appropriate values for Remote contact activity interval and Initial contact retry interval. Specify these values in the advanced settings in the configuration of all end-to-end automation adapters, including all Agentless Adapters. Modify the advanced settings by clicking Advanced on the Adapter tab in the adapter configurations. For information on these settings, see Configuring high availability and contact retry interval of all end-to-end automation adapters on page 87. Configuring an LDAP user registry Configure a central user registry, such as a Lightweight Directory Access Protocol (LDAP) registry, for user management and authentication. Configure WebSphere Application Server to use the LDAP user registry as a federated repository. The WebSphere Application Server uses this registry for user authentication and the retrieval of information about users and groups to run security-related functions. For more information about how to configure a federated user repository in WebSphere Application Server, see Managing the realm in a federated repository configuration. Procedure for pre-defined LDAP setup 1. Install Jazz for Service Management including WebSphere Application Server and Dashboard Application Services Hub (DASH). 2. LDAP configuration a. Add the LDAP user registry as a federated repository to the WebSphere Application Server. b. Configure the supported entity types so that new users and groups are created in the LDAP user repository. 3. Install System Automation Application Manager. Chapter 3. Configuring 115

134 4. Optional: Configure the connection to the LDAP server for secure communications. For more information, see Configuring an SSL connection to an LDAP server. Procedure for post-defined LDAP setup 1. Install Jazz for Service Management including WebSphere Application Server and Dashboard Application Services Hub (DASH). 2. Install System Automation Application Manager. 3. LDAP configuration a. Add the LDAP user registry as a federated repository to the WebSphere Application Server. b. Configure the supported entity types so that new users and groups are created in the LDAP user repository. 4. Port from a file-based repository to an LDAP repository a. Create users and groups to use with System Automation Application Manager in the LDAP repository if they do not exist. b. Authorize the LDAP groups within the Dashboard Application Services Hub. c. Remove duplicate users from the file-based user repository. 5. Optional: Configure the connection to the LDAP server for secure communications. For more information, see Configuring an SSL connection to an LDAP server. The core LDAP configuration is done in the same way for both pre-defined and post-defined setup. This LDAP configuration is described in the next sections. Adding the LDAP user registry as a federated repository Federated repositories can access and maintain user data in multiple repositories, and federate that data into a single federated repository. For example, use the default file-based repository and an LDAP repository that is combined under a single realm. Pre-requisites for this task: Set up an LDAP server and create an LDAP user registry. Ensure that WebSphere Application Server supports the LDAP user registry as a federated repository, for example, IBM Tivoli Directory Server or Microsoft Active Directory Server. Before you configure a central user registry, make sure that the user registry or registries that you plan to identify are started. The user registry must be accessible from the computer where you set up the Jazz for Service Management application server. Configuring an LDAP user repository Configure the LDAP user repository by running the following steps: Procedure 1. Open your web browser and connect to the WebSphere administrative console. 2. Enter the WebSphere administrator user ID and password, and click Log in. 116 Tivoli System Automation Application Manager V : Installation and Configuration Guide

135 3. Select Security > Global security. 4. From the Available realm definitions list, select Federated repositories and click Configure. 5. In the Related Items area, click the Manage repositories link and then click Add > LDAP repository to configure a new LDAP user repository. 6. In the Repository identifier field, provide a unique identifier for the repository. The identifier uniquely identifies the repository within the cell. For example, LDAP1. 7. From the Directory type list, select the type of LDAP server. The type of LDAP server determines the default filters that are used by WebSphere Application Server. If you choose one of the predefined LDAP servers, you get default definitions for the mapping of entity types to corresponding object classes and for the attribute name that is used to determine group membership. If you choose Custom as directory type, you must specify these definitions as Additional Properties depending on your specific LDAP server. For more information, see Configuring custom LDAP servers. 8. In the Primary host name field, enter the fully qualified host name of the primary LDAP server. The primary host name and the distinguished name must contain no spaces. You can enter either the IP address or the domain name system (DNS) name. 9. In the Port field, enter the server port of the LDAP user registry. The default port value is 389, which is not a Secure Sockets Layer (SSL) connection port. Use port 636 for a Secure Sockets Layer (SSL) connection. For some LDAP servers, you can specify a different port. If you do not know the port to use, contact your LDAP server administrator. 10. Optional: In the Bind distinguished name and Bind password fields,enter the bind distinguished name (DN) (for example, cn=root) and password. The bind DN is required for write operations or to obtain user and group information if anonymous binds are not possible on the LDAP server. In most cases, a bind DN and bind password are needed, except when an anonymous bind can satisfy all of the functions. Therefore, if the LDAP server is set up to use anonymous binds, leave these fields blank. 11. Optional: In the Login properties field, enter the property names used to log in to the WebSphere Application Server. This field takes multiple login properties, delimited by a semicolon (;). For example, uid. 12. Optional: From the Certificate mapping list, select your preferred certificate map mode. You can use the X.590 certificates for user authentication when LDAP is selected as the repository. The Certificate mapping field is used to indicate whether to map the X.509 certificates to an LDAP directory user by EXACT_DN or CERTIFICATE_FILTER. If you select EXACT_DN, the DN in the certificate must match the user entry in the LDAP server, including case and spaces. 13. Click Apply and then Save. Configuring custom LDAP servers If you chose Custom as directory type and not one of the predefined LDAP servers, define manually the mapping of entity types to corresponding object classes and the attribute name that is used to determine group membership. Set the object class for an entity type. If you chose Custom as directory type and not one of the predefined LDAP Chapter 3. Configuring 117

136 servers, you must manually specify the object classes that are used in your LDAP server for the entity types PersonAccount and Group. A PersonAccount represents a user, whereas a Group represents a group of users. 1. On the configuration page of your LDAP repository in the Additional Properties area, click Federated repositories entity types to LDAP object classes mapping. 2. Click New to define a new entity type to class mapping. 3. Specify a mapping for the PersonAccount entity type. As object classes, specify the object classes that are mapped to this entity type. Multiple object classes are delimited by a semicolon (;). For example, enter PersonAccount in the Entity type field, and enter inetorgperson in the Object classes field to define that LDAP entries that have the object class inetorgperson are mapped to the PersonAccount entity type. 4. Click Apply and then Save. 5. Specify a mapping for the Group entity type. As object classes, specify the object classes that are mapped to this entity type. Multiple object classes are delimited by a semicolon (;). For example, enter Group in the Entity type field, and enter groupofnames in the Object classes field to define that LDAP entries that have the object class groupofnames are mapped to the Group entity type. 6. Click Apply and then Save. Define group membership attribute If you chose Custom as directory type and not one of the predefined LDAP servers, you must manually configure how group membership is modeled in your LDAP server. Model the group membership in the Group attribute definition properties of the repository. There are two main ways of specifying group membership: Static group membership that is defined in Group entity. The Group entity has an attribute, for example member, which points to its members. The member attribute in this example is called the group member attribute. All LDAP server implementations support static group membership. Group membership attribute in PersonAccount entity. The PersonAccount entity has an attribute, for example, memberof, which points to the groups that this person belongs. The memberof attribute in this example is called the group membership attribute. Some LDAP servers support this kind of linking user objects to the groups to which they belong, for example Microsoft Active Directory Server. Use direct group membership if it is supported by the LDAP server. Configure the group membership depending on which group membership definition is supported by your LDAP server: Static group membership. If the group member attribute of the group is used, specify the name of the object class, and the attribute name that is used to indicate the group membership in Group attribute definition -> Member attributes. If the group objectclass for the user is 118 Tivoli System Automation Application Manager V : Installation and Configuration Guide

137 groupofuniquepersons, and within that objectclass members are listed as persons, then the static group Member attributes property is set as follows: 1. On the configuration page of your LDAP repository in the Additional Properties area, click Group attribute definition. 2. Under Additional properties, click Member attributes. 3. Click New to specify a new member attribute. Set the Name of member attribute field to persons. Set the Object class field to groupofuniquepersons. 4. Click Apply and then Save. Direct group membership. If the group membership attribute in the PersonAccount entity is used, specify the group membership attribute in Group attribute definition -> Name of group membership attribute. For example, if a PersonAccount entity (that is, a user) contains attributes called ingroup that contain each group membership, then you specify the direct group membership as follows: 1. On the configuration page of your LDAP repository in the Additional Properties area, click Group attribute definition. 2. Set the Name of group membership attribute field to ingroup. 3. Click Apply and then Save. Adding configured LDAP repository as federated repository to the security realm To add an already configured LDAP user repository as federated repository to the security realm, run the following steps: 1. On the Global security > Federated repositories page, click Add repositories (LDAP, custom, etc) To add an entry to the base realm: a. Ensure that the LDAP federated repository is selected from the Repository list. b. In the field, enter the distinguished name (DN) of a base entry that uniquely identifies this set of entries in the realm. This base entry must uniquely identify the external repository in the realm. Note: If multiple repositories are included in the realm, use the DN field to define an extra distinguished name that uniquely identifies this set of entries within the realm. For example, repositories LDAP1 and LDAP2 might both use o=ibm,c=us as the base entry in the repository. So o=ibm,c=us is used for LDAP1 and o=ibm2,c=us for LDAP2. The specified DN in this field maps to the LDAP DN of the base entry within the repository, such as o=ibm,c=us b. The base entry indicates the starting point for searches in this LDAP server, such as o=ibm,c=us c). c. Click Apply and then Save. 3. In the administrative console, select Security > Global security. 4. From the Available realm definitions list, select Federated repositories and click Set as current to mark the federated repository as the current realm. 5. Restart the WebSphere Application Server. 6. Verify that the federated repository is correctly configured: Chapter 3. Configuring 119

138 a. In the administrative console, click Users and Groups > Manage Users. b. Confirm that the list of displayed users includes users from both the LDAP federated repository and the local file registry. c. Click Users and Groups > Manage Groups. d. Confirm that the list of displayed groups includes groups from both the LDAP federated repository and the local file registry. Note: Verify that the default administrative user (for example, wasadmin) that is created during installation of Jazz for Service Management is in the local file registry. If System Automation Application Manager is installed before the LDAP repository is configured, also the users and groups that are generated during the installation are in the local file registry. Configuring supported entity types Configure the supported entity types before you can create users and groups in your LDAP repository in the administrative console. This configuration specifies which RDN property is used for the default entity types, for example users and groups, and where in the repository name space these entities are created. This configuration is also required if you install System Automation Application Manager after you configured an LDAP repository. The installer creates the default users and user groups for you in the LDAP repository. The supported entity types are Group, OrgContainer, and PersonAccount. A Group entity represents a simple collection of entities that might not have any relational context. An OrgContainer entity represents an organization, such as a company or a division. A PersonAccount entity represents a user that logs in. You cannot add or delete the supported entity types, because these types are predefined. 1. In the administrative console, click Security > Global security. 2. From the Available realm definitions list, select Federated repositories and click Configure. 3. Click Supported entity types to view a list of predefined entity types. 4. Click the name of a predefined entity type to change its configuration. 5. In the Base entry for the default parent field, provide the distinguished name of a base entry in the repository. This entry determines the default location in the repository where entities of this type are placed on write operations by user and group management. 6. Supply the relative distinguished name (RDN) properties for the specified entity type in the Relative Distinguished Name properties field. Possible values are cn for Group, uid or cn for PersonAccount, and o, ou, dc, and cn for OrgContainer. Delimit multiple properties for the OrgContainer entity with a semicolon (;). 7. Click Apply and then Save. 8. Repeat all steps for all predefined entity types. 9. Restart the WebSphere Application Server. You can now manage your LDAP repository users in the console through the Users and Groups > Manage Users menu item. 120 Tivoli System Automation Application Manager V : Installation and Configuration Guide

139 Note: When you add a user, check that the user ID you specify does not exist in any of the user repositories. You can avoid difficulties when the new user attempts to log in. What to do next: Pre-defined setup: The LDAP repository is configured and connected to the WebSphere Application Server. Next, install System Automation Application Manager. On the User and Group Administration page of the installer click Yes. The default users and groups for System Automation Application Manager are created in your configured LDAP user repository. If you already created the default user groups and users for System Automation Application Manager in the LDAP repository through a previous installation or by adding them manually, click No. In this case, the installer does not make changes to users and groups. Post-defined setup: If you already installed System Automation Application Manager and you did not define the default users and groups for System Automation Application Manager in the LDAP repository, create these users and groups in your LDAP repository as the next step. Assign roles to the new LDAP groups and remove the old groups that are no longer used from the file-based repository. These steps are explained in Porting from a file-based repository to an LDAP repository in a post-defined setup. Porting from a file-based repository to an LDAP repository in a post-defined setup If you configured WebSphere Application Server to use an LDAP repository after you installed System Automation Application Manager, complete extra steps to port from a file-based repository to an LDAP user repository. Run the following steps to port the users, groups, and roles that are created during the installation of System Automation Application Manager to an LDAP-based configuration: 1. Create users and groups to use with System Automation Application Manager in the LDAP repository if they do not exist. For more information, see Creating default users and groups. 2. Authorize the LDAP groups within the Dashboard Application Services Hub. For more information, see Authorizing LDAP groups within the Dashboard Application Services Hub on page Remove duplicate users from the file-based user repository. For more information, see Removing duplicate users from the file-based user repository on page 126. Creating default users and groups System Automation Application Manager requires a set of default users and groups. These users and groups are created during the installation of System Automation Application Manager. Chapter 3. Configuring 121

140 If you configured a new LDAP user repository after System Automation Application Manager is installed, the default users and groups are created in the local file-based user repository by the installer. In this case, manually create the default users and groups also in the LDAP repository and later delete the old definitions from the file-based repository. During installation, users and groups are created and mapped to a group role automatically. Table 1 lists these user IDs and user groups and shows to which group role they are assigned to. Table 34. Default user IDs and groups of the System Automation Application Manager Default user IDs Default groups Group roles eezadmin, eezdmn EEZAdministratorGroup EEZAdministrator EEZOperatorGroup EEZConfiguratorGroup EEZMonitorGroup EEZOperator EEZConfigurator EEZMonitor eezadmin EEZEndToEndAccessGroup EEZEndToEndAccess For more information, see System Automation Application Manager Administrator's and User's Guide. The following steps describe how to set up the default users (for example eezadmin), and groups (for example EEZAdministratorGroup) in the LDAP repository. If you choose to use different names for users and groups, adjust the described steps. Procedure 1. Log in to the administrative console. 2. Click Users and Groups > Manage Users to create users. 3. Click Create... to create a new user. Enter the user ID for eezadmin and eezdmn. 4. Click Create to create both users. 5. Click Users and Groups > Manage Groups to create groups. 6. Click Create... to create a new group. Enter the group name of the following groups: a. EEZAdministratorGroup b. EEZConfiguratorGroup c. EEZEndToEndAccessGroup d. EEZMonitorGroup e. EEZOperatorGroup 7. Click Create to create all groups. 8. To add eezadmin to the following groups, click the Group name of the following groups and proceed as follows: a. EEZAdministratorGroup b. EEZEndToEndAccessGroup 9. Select the Members tab on the selected group page. 10. Click Add Users Enter the user name eezadmin into the Search field or enter * to see all users. 122 Tivoli System Automation Application Manager V : Installation and Configuration Guide

141 12. Click Search. 13. Select eezadmin and click Add. 14. Repeat step 8 to 13 to add eezadmin to both groups. 15. To add eezdmn to the EEZAdministratorGroup, click the Group name. 16. Select the Members tab on the selected group page. 17. Click Add Users Enter the user name eezdmn into the search field or enter * to see all users. 19. Click Search. 20. Select eezdmn and click Add. Results You created the default users and groups. Since an LDAP repository is shared across multiple System Automation Application Manager installations, the users and groups must only be created once and can then be used by all System Automation Application Manager installations that are configured for this LDAP repository. What to do next v If you chose non-default group names, the role mapping for the EEZEAR application must be updated, see Updating the user and role mapping for the EEZEAR application. v Next, assign roles to these groups, so that users that belong to a group have the expected access rights to work with System Automation dashboards in the Dashboard Application Services Hub, see Authorizing LDAP groups within the Dashboard Application Services Hub on page 124. Updating the user and role mapping for the EEZEAR application If your LDAP user repository uses non-default group names, roles that are used by the System Automation Application Manager must be adjusted to the group names. If your LDAP user repository uses the default group names, no further action is required. Procedure 1. Log in to the administrative console as a WebSphere administrative user. 2. Click Applications > Application Types > WebSphere enterprise application in the navigation tree on the left side. 3. Click EEZEAR. 4. Click Security role to user/group mapping. 5. To change the mapping according to your settings, select a role and click Map Groups Enter in the Search field the name of the group you are looking for, or use * to see all available groups. 7. Select the appropriate group and move it to the Selected list by using the arrow button >>. 8. Remove the groups that you don't use. Otherwise, errors can occur in the WebSphere logs. Chapter 3. Configuring 123

142 9. Save the settings to the master configuration and restart the WebSphere Application Server. Adapting installation variables If you ported from a file-based user repository to a central LDAP user repository that is shared by multiple System Automation Application Manager installations, adapt an installation variable that defines whether a local or an external user repository is used. Otherwise, a later uninstallation of this System Automation Application Manager installation deletes the default users and groups from the LDAP repository. To adapt the installation variables, apply the following change: Procedure Change the variable EXTERNAL_USER_REP_ACTIVATE in file <EEZ_INSTALL_ROOT>/ uninstall/installvariables.properties to false: EXTERNAL_USER_REP_ACTIVATE=false. Results Prevents that in a later uninstallation process the default users, and groups are deleted from the LDAP user repository. Authorizing LDAP groups within the Dashboard Application Services Hub Users must have specific roles to work with dashboards that are available in the Dashboard Application Services Hub (DASH). This role assignment is configured in the DASH. Assign the required roles on the user group level, so that all users that belong to a group inherit the same roles. Roles are assigned to user groups and users during the installation of System Automation Application Manager. If you configured a new LDAP user repository after System Automation Application Manager is installed (see post-defined setup), assign the expected roles to the groups and users that are available in the LDAP repository. At the time of the installation of System Automation Application Manager, the roles are assigned to the groups, and users are created in the local file-based user repository. Table 35. Role to group assignments: Role EEZMonitor EEZOperator EEZConfigurator EEZAdministrator EEZEndToEndAccess Group name EEZMonitorGroup EEZOperatorGroup EEZConfiguratorGroup EEZAdministratorGroup EEZEndToEndAccessGroup 124 Tivoli System Automation Application Manager V : Installation and Configuration Guide

143 The iscadmins role is assigned to the default System Automation administrator (for example eezadmin) and to the default WebSphere administrative user (for example wasadmin): Table 36. Role to user ID assignment Role iscadmins User ID eezadmin, wasadmin You must have at least one user that has the iscadmins role. For a list of the available user roles for System Automation and their meaning, see System Automation Application ManagerReference and Problem Determination Guide. Procedure 1. Log in to the Dashboard Application Services Hub by using the WebSphere administrative user that you specified during installation of Jazz for Service Management (for example wasadmin). This user is in the file-based repository and has the iscadmins role that allows this user to change role assignments. 2. Click Console Settings > Roles in the navigation bar. 3. Click the EEZAdministrator role and then expand the Users and Groups section. The Users and Groups tables display the current list of users and groups to which the EEZAdministrator role is assigned. If you configured LDAP after System Automation Application Manager is installed (post-defined setup), the Groups table displays the following entry: cn=eezadministratorgroup,o=defaultwimfilebasedrealm This default configuration is made by the installer that assigns the EEZAdministrator role to the EEZAdministratorGroup that is created in the file-based user repository. 4. Click + (Add Group) in the toolbar of the Groups table to add the corresponding EEZAdministratorGroup that exists in the LDAP repository. The Available Groups window opens. 5. Enter EEZ* in the Group ID field and click Search to list all groups that begin with EEZ from the configured federated repositories. The results table lists all EEZ* groups from both the file-based repository and the LDAP repository. 6. Select the EEZAdministratorGroup that is defined in LDAP and click Add and then Save. Note: Ensure that you select the group that is defined in LDAP and not the one with the same name that still exists in the file-based repository by examining the distinguished name. If you use other group names in LDAP than you previously used in the file-based repository, you can also assign the EEZ-roles to groups named differently. In this case also adjust the group configuration for the EEZEAR application. 7. Repeat steps 3 6 for all EEZ* roles (EEZAdministrator, EEZConfigurator, EEZEndToEndAccess, EEZMonitor, EEZOperator). Adjust the mappings so that they match the expected role assignments as listed in the table. 8. Finally, assign the iscadmins role to either one of your LDAP groups or to individual LDAP users. For example, if you want all your EEZAdministrator users to modify existing dashboards or define new dashboards in the DASH, assign the iscadmins role to the LDAP-based EEZAdministratorGroup. Chapter 3. Configuring 125

144 Removing duplicate users from the file-based user repository During the porting from a file-based user repository to an LDAP-based user repository, you might have users and groups that have the same name in both repositories. This setting leads to problems when you try to log on with one of the users that exists in both user repositories. For example, if the functional user id used by the System Automation Application Manager (default: eezdmn) is in the file-based and in the LDAP repository, the EEZEAR application does not start. This prevents the EEZEAR application from being started. Therefore, you must remove the old System Automation users and groups from the file-based repository. Procedure 1. Log in to the WebSphere administrative console. 2. Click Users and Groups > Manage Users. The users from both the file-based and the LDAP repository are listed. 3. Select the following users: a. eezadmin with the unique name: uid=eezadmin,o=defaultwimfilebasedrealm b. eezdmn with the unique name: uid=eezdmn,o=defaultwimfilebasedrealm 4. Click Delete. Click Delete again in the confirmation dialog to delete both users. 5. Click Users and Groups > Manage Groups. The groups from both the file-based and the LDAP repository are listed. 6. Select the following groups: a. EEZAdministratorGroup with the unique name: cn=eezadministratorgroup,o=defaultwimfilebasedrealm b. EEZConfiguratorGroup with the unique name: cn=eezadministratorgroup,o=defaultwimfilebasedrealm c. EEZEndToEndAccessGroup with the unique name: cn=eezendtoendaccessgroup,o=defaultwimfilebasedrealm d. EEZMonitorGroup with the unique name: cn=eezmonitorgroup,o=defaultwimfilebasedrealm e. EEZOperatorGroup with the unique name: cn=eezoperatorgroup,o=defaultwimfilebasedrealm 7. Click Delete. Click Delete again in the confirmation dialog to delete the selected groups from the file-based repository. 8. Restart WebSphere Application Server and verify that you can log on with your LDAP users into the DASH. See the dashboards for which they are enabled according to their role and group assignments. Also, verify that you can still log in to the WebSphere Application Server administrative console by using your administrative user. The administrative user (for example wasadmin by default) is still in the file-based repository. 126 Tivoli System Automation Application Manager V : Installation and Configuration Guide

145 Results You now ported the default groups and users that are used by System Automation Application Manager to an LDAP user repository. You can continue to create further users in your newly configured LDAP repository. What to do next Optionally, you can define a different user who is in your LDAP repository as an WebSphere administrative user. Assign the following administrative roles to any of your LDAP users by using the WebSphere Application Server administrative console: 1. Admin Security Manager 2. Administrator 3. ISC Admins Go to Users and Groups > Administrative user roles to assign these roles to a new user. Configuring access to non-clustered nodes Use the agentless adapter to access and integrate non-clustered nodes into an end-to-end automation environment. Configure and use either the local agentless adapter or one or multiple remote Agentless Adapters or a combination of both. Configure the local and remote Agentless Adapters on the system where the System Automation Application Manager server is installed. Enter the cfgeezdmn command to open the configuration utility. After the configuration for one instance of the remote agentless adapter is completed, this configuration must be distributed to the corresponding adapter host. The topic Figure 11 on page 128 displays how configurations for Agentless Adapters are maintained. Enter the cfgeezdmn command to open the configuration utility. Chapter 3. Configuring 127

146 System Automation Application Manager cfgeezdmn configuration utility Configuration files - Agentless Adapter - Remote clients - remote.client1 - remote.client2 read Local Agentless Adapter distribute distribute remote.client2 remote.client1 Configuration files - Agentless Adapter Configuration files - Agentless Adapter read read ALA Domain1 ALA Domain2 Remote Agentless Adapter Remote Agentless Adapter ALA Domain3 ALA Domain4 ALA Domain5 ALA Domain6 ALA Domain7 Figure 11. Maintaining configurations for multiple Agentless Adapters Configuring the local agentless adapter The System Automation Application Manager local agentless adapter configuration dialog helps you to configure the local agentless adapter settings. To open the configuration dialog, click Configure in the Local Agentless Adapter configuration section on the Non-Clustered Nodes tab of the task launcher window Adapter tab Use the Adapter tab to configure the parameters of the host system on which the adapter is running and the parameters that are required for the agentless adapter policy. Controls and fields on the Adapter tab: Request port number Specify the number of the port on which the agentless adapter listens for requests from the end-to-end management host. The default port is If you configured the hardware adapter, make sure that the port numbers of the agentless adapter and the hardware adapter are different. Policy pool location Specify the qualified path name of the directory that contains the agentless 128 Tivoli System Automation Application Manager V : Installation and Configuration Guide

147 adapter policies. These policies define resources on non-clustered nodes. The resources are managed by the agentless adapter. Click Browse to select a directory. Automation domain list The table lists automation domain names. Each domain represents a set of resources on nodes that are not clustered and managed by the agentless adapter. A domain name must match the domain name value that is defined in the policy file. This policy file defines the corresponding set of resources. Add, Remove or Rename domains To change the list of domains, click the corresponding tasks: Add Click Add to open a dialog. Specify the domain name that you want to add to the list. Remove Select a domain from the list and click Remove. Rename Select the domain name that you want to rename and click Rename. A dialog opens. Enter the new name. Click Advanced. A dialog opens to specify the adapter runtime behavior: Adapter stop delay Defines the time that is measured in seconds within which the adapter stop is delayed to allow the adapter to properly deliver the domain leave event. The default value is 5. You can increase the value on slow systems. The value ranges between 3 through 60 seconds. Remote contact activity interval Defines the time after which the automation adapter stops if there is no communication with the end-to-end automation management host. Setting this parameter to 0 means that the adapter continues to run and never stops. The default value is 360 seconds. If you configured Application Manager high availability, you might specify a value greater than 0. In this case, the adapter is part of the high availability policy and it is restarted automatically. The adapter contacts the end-to-end automation management host again, with the value that is specified in the Initial contact retry interval parameter. If your adapter is not configured for high availability, specify 0 so that the adapter waits until it is contacted again by the end-to-end automation management host. Initial contact retry interval Defines the time that is measured in minutes, within which the adapter attempts to contact the end-to-end automation management host until it succeeds or the specified time elapses. The default value is 0, where 0 means the adapter attempts to contact the end-to-end automation management host indefinitely. The value range is minutes. Enable EIF event caching Select this check box to activate event caching. EIF reconnect attempt interval Defines the time that the adapter waits before it attempts to reestablish the Chapter 3. Configuring 129

148 connection to the end-to-end automation management host after the connection is interrupted. The default value is 30 seconds. The value ranges seconds. User Credentials tab Use the User Credentials tab to configure credentials of the agentless adapter. These credentials are used to access remote nodes, which host remote resources that are managed by the agentless adapter. These credentials are not required for IBM Tivoli Monitoring resources that are managed by the agentless adapter. Credentials for IBM Tivoli Monitoring resources are configured on the Tivoli Monitoring tab. For details about how to configure these credentials, see Tivoli Monitoring tab on page 131. Controls and fields on the User Credentials tab: Configure the user IDs and passwords that the agentless adapter uses to access remote nodes, which host resources that are managed by the agentless adapter. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. Generic user ID Enter a generic user ID to access all non-clustered nodes for which no specific credentials are defined in the list Credentials for accessing specific non-clustered nodes. Generic credentials are optional. If you want to remove already configured generic credentials, leave the user ID field empty. Generic password Enter your password for the generic user ID. Click Change to change the password. Credentials for accessing specific non-clustered nodes Define user credentials for each non-clustered node for which the generic credentials do not apply. The list shows all currently defined user credentials and their related node names. Add Click Add to define a new user ID and password to access remote nodes. More than one user credential per node is allowed. Remove To remove an entry from the list, select a user ID and click Remove. Modify To edit the node name, user ID, or password, select an entry from the list and click Modify. Note: 1. If an IPv6 host name is specified as node name, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address as node name instead of the host name. Use the tools that are provided by the operating system to check the DNS lockup records. For example, on Linux use the command host -a <ipv6_hostname> to check the DNS lookup records. 130 Tivoli System Automation Application Manager V : Installation and Configuration Guide

149 You can decide to use SSH public and private keys for user authentication between the agentless adapter and remote non-clustered nodes on the Security tab. In this case do not define specific credentials for any pair of node name and user ID for which you want to use the SSH key authentication approach. Tivoli Monitoring tab Use the Tivoli Monitoring tab to configure the integration of Tivoli Monitoring and IBM Tivoli Composite Application Manager (ITCAM) resources by defining settings and credentials to access the Tivoli Monitoring SOAP Server. Controls and fields on the Monitoring tab: Enable integration of ITM/ITCAM resources Select this check box if you want to integrate ITM/ITCAM resources in a policy for a domain that is managed by the local agentless adapter. Selecting this option enables all controls on this tab pane. Configure settings to access the Tivoli Monitoring SOAP server: Host name or IP address Specify the name or the IP address of the host where the hub monitoring server that hosts the SOAP service is running. SOAP server port number Specify service point port number of the SOAP server hosted by the hub monitoring server. The default number for a non-ssl port is The default number for an SSL port is You must specify the number of an SSL port if you selected the check box to use Secure Socket Layer (SSL) for communication with the SOAP server. SOAP alias of hub Specify the alias name of the hub monitoring server to which a SOAP request is routed. The request is routed to the hub monitoring server, which is on the same system as the SOAP server. In this configuration, you must specify SOAP as the alias. If you want to route the SOAP request to a remote hub, specify the alias name of this remote hub. This alias must be previously defined to the SOAP server in the ITM/ITCAM SOAP server configuration. Use SSL for communication with the SOAP server Select this check box if the agentless adapter must use Secure Socket Layer (SSL) for communication with the SOAP server. If you select this option, you must specify the number of an SSL port in the SOAP server port number field. The https protocol is used for communication. Configure credentials for accessing the Tivoli Monitoring SOAP server: Define for each user ID that is specified for an ITM/ITCAM resource in an agentless adapter policy the user credentials. You can define the user credentials in the list of specific credentials for accessing the SOAP server. When no user ID for the ITM/ITCAM resources is specified in the policy, the generic user credentials are used. Generic user ID Specify the generic user ID that is used to access the ITM/ITCAM resources for which a user ID was omitted in the agentless adapter policy. If you specified a user ID for all ITM/ITCAM resources in the agentless adapter policies, this field is not used. Chapter 3. Configuring 131

150 Generic Password Specify the password of the generic user ID. This field is mandatory only if you supplied a generic user ID. Click Change to change the password. Specific credentials for accessing the Tivoli Monitoring SOAP server Define each user ID that you specified for an ITM/ITCAM resource in an agentless adapter policy. Use the following tasks: Add Click Add to define a new user ID and password to access the SOAP Server. Remove To remove an entry from the list, select a user ID and click Remove. Modify To edit the user ID or password, select an entry from the list and click Modify. Note: You can define the SOAP server security setup to accept a user ID with an empty password. For example, if you want to use the agentless adapter in a test environment, you can specify the user ID for the corresponding ITM/ITCAM resource in the agentless adapter policy. It is not required to define the user ID in the list of specific credentials to access the SOAP server. In this case, the agentless adapter attempts to access the ITM/ITCAM resource with the user ID defined in the policy and an empty password. Security tab Use the Security tab to configure the settings for user authentication and secure data transport. You can configure the following settings: Secure Sockets Layer (SSL) for data transport Configure SSL for data transport between the agentless adapter and the automation manager host. If you configured Application Manager high availability, the end-to-end automation manager and the agentless adapter run on different systems. In this case, you might want to configure the corresponding SSL settings to secure the data transport between those systems. Usage of the Pluggable Access Module (PAM) for user authentication Configure user authentication between the automation manager and the agentless adapter with the Pluggable Access Module (PAM). User authentication with SSH public and private keys Configure user authentication between the agentless adapter and remote non-clustered nodes with SSH public and private keys. This authentication method applies only to remote resources, which are accessed by using a remote execution protocol. It does not apply to IBM Tivoli Monitoring resources defined in the agentless adapter policy because for IBM Tivoli Monitoring resources an existing IBM Tivoli Monitoring security infrastructure is reused. The user ID that you specify for a remote resource in an agentless adapter policy is used to authenticate on the remote node where the resource is located. The agentless adapter separately authenticates each user ID that is specified for a remote resource in the agentless adapter policy. The adapter authenticates those users on remote nodes in the following sequence: 132 Tivoli System Automation Application Manager V : Installation and Configuration Guide

151 1. The user ID that is specified for a remote resource in the agentless adapter automation policy is defined in the Credentials for accessing specific non-clustered nodes list on the User Credentials tab: The agentless adapter uses the password that is associated with that specific user ID. 2. The user ID that is specified for a remote resource in the agentless adapter automation policy is defined as Generic user ID for non-clustered nodes on the User Credentials tab: The agentless adapter uses the password that is associated with that generic user ID. 3. For the user ID that is specified for a remote resource in the agentless adapter policy, user authentication is processed by using SSH public and private keys. In this case, check Enable user authentication with SSH public and private keys and specify the SSH private key file and passphrase. Controls and fields on the Security tab: Configure Secure Sockets Layer for transport: Enable SSL for data transport between the automation manager and the agentless adapter Check this check box to enable the Secure Sockets Layer (SSL) protocol. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. The following fields are enabled: Truststore Enter the fully qualified name of the truststore file that is used for SSL. Click Browse to select a file. Keystore Enter the fully qualified name of the keystore file that is used for SSL. Click Browse to select a file. Keystore password Enter the password for the keystore file. The password is required if a keystore file was specified. Click Change to change the password. Note: Passwords must be identical if truststore and keystore are in two different files. Certificate alias Enter the alias name of the certificate that is used by the server. If not specified, the keystore file must contain only one entry, which is the one to be used. Configure user authentication between the Automation Manager and the agentless adapter with the Pluggable Access Module (PAM). Enforce user authentication between the automation manager and the agentless adapter Click the check box to enable user authentication with Pluggable Access Module (PAM). If not checked, user authentication is bypassed. PAM service The value of the PAM service depends on the operating system on which the agentless adapter runs: v For SUSE Linux distributions, specify a file in the directory /etc/pam Chapter 3. Configuring 133

152 v For Red Hat Enterprise Linux distributions, specify an entry in the file pam.d v For AIX, specify an entry in the file /etc/pam.conf The PAM service determines which checks are made to process user authentication. Examples for PAM service names are sshd for Linux, or login for AIX. You might also use any other value that is defined as a PAM service. Configure security for the communication between the agentless adapter and remote non-clustered nodes. Enable user authentication with SSH public and private keys Check this check box to use SSH keys for authentication. Use SSH keys for user IDs that have no generic or specific access credentials that are defined on the User Credentials tab. SSH private key file Enter the fully qualified name of the SSH private key file that is generated by the ssh-keygen utility. The default names of files that are generated by ssh-keygen are id_dsa or id_rsa. Ensure that the user ID under which the agentless adapter is running has read access for this file. Click Browse to select a file. SSH private key file Enter the fully qualified name of the SSH private key file that is generated by the ssh-keygen utility. The default names of files that are generated by ssh-keygen are id_dsa or id_rsa. Ensure that the user ID under which the agentless adapter is running has read access for this file. Click Browse to select a file. Private key passphrase Enter the passphrase that you used to generate the SSH private key file with the ssh-keygen utility. Click Change to change the passphrase. The passphrase is optional because you can omit the passphrase when you use the ssh-keygen utility. Click Change to remove a passphrase. Leave all entry fields in the dialog empty and select OK. Saving the local agentless adapter configuration To save your changes to the System Automation Application Manager agentless adapter configuration properties files, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files are updated. If errors occurred during the update, the corresponding error messages are also displayed. If high availability is configured for System Automation Application Manager, replicate the properties files to the other nodes in the System Automation for Multiplatforms cluster. For more information, see Replicating the configuration files on page 160. Configuring remote agentless adapters Configure remote System Automation Application Manager settings. To open the configuration dialog, click Configure in the Remote agentless adapter configuration section on the Non-clustered Nodes tab of the task launcher window. 134 Tivoli System Automation Application Manager V : Installation and Configuration Guide

153 Use the remote System Automation Application Manager configuration window to maintain the configurations for one or multiple remote System Automation Application Manager instances. The list of remote System Automation Application Manager configurations shows one entry for each currently configured remote System Automation Application Manager instance: Remote agentless adapter Host The host name of the node where the remote System Automation Application Manager is installed. Configuration Directory v UNIX: If the remote System Automation Application Manager is installed on a UNIX system, the configuration directory is /etc/opt/ibm/tsamp/eez/rala/cfg. v Windows: If the remote System Automation Application Manager is installed on a Windows system, the configuration directory is <INSTALL_ROOT>\cfg. <INSTALL_ROOT> is the directory that you specified during the installation of the System Automation Application Manager on the Windows system. Configuration complete The configuration complete value indicates whether the configuration for the corresponding remote System Automation Application Manager instance is completed or not. v No: Initial value after you added a configuration. v Yes: After you successfully completed the Configure task for the adapter instance. Note: You can distribute only completed configurations to the remote host. Click Add to add a configuration for another remote System Automation Application Manager instance. A dialog opens to specify the remote node name of the host and select whether the remote host is a Windows system or not. For a Windows system, specify also the configuration directory. After you completed the dialog, the new configuration is added to the list with the configuration complete value "No". Click Remove to remove the selected configuration from the list. All configuration files related to that configuration are deleted on the system where the configuration utility runs. If you distributed the configuration already, the configuration files on the remote host will not be deleted. Click Configure to open the configuration dialog for the selected configuration. For more information, see Configuring a remote agentless adapter instance. Click Distribute to distribute the selected configuration. For more information, see Distributing a remote agentless adapter configuration on page 138. Configuring a remote agentless adapter instance The content of the configuration dialog tabs and the semantics of the fields are mostly the same as described in Configuring the local agentless adapter on page 128. Below you can find the description of tabs or fields that are unique for a Chapter 3. Configuring 135

154 remote agentless adapter configuration. To open the configuration dialog, select the entry that you want to configure and click Configure in the remote agentless adapter configuration window. Post-configuration tasks Distribute the remote agentless adapter configuration to the corresponding remote agentless adapter host. For more information, see Distributing a remote agentless adapter configuration on page 138. If System Automation Application Manager is configured for high availability, replicate the configuration files to the high availability nodes of the IBM Tivoli System Automation for Multiplatforms cluster. For more information, see Replicating the configuration files on page 160. Adapter tab Refer to Adapter tab on page 128 for a description of this tab content and the semantics of the fields on the tab. Two controls are different than the Adapter tab for the local agentless adapter: Host name or IP address Host name or IP address of the node where the adapter runs. The default value is the remote agentless adapter host name that you specified for this adapter instance in the remote agentless adapter configuration window. If you want to change this value, for example to an IP address, make sure that the new value refers to the host where this adapter instance is installed. Request port number The disclaimer regarding the hardware adapter does not apply to remote Agentless Adapterss. User Credentials tab Refer to User Credentials tab on page 130 for a description of this tab content and the semantics of the fields on the tab. Tivoli Monitoring tab Refer to Tivoli Monitoring tab on page 131 or a description of this tab content and the semantics of the fields on the tab. Security tab Refer to Security tab on page 132 for a description of this tab content and the semantics of the fields on the tab. The only difference between the Security tab for the local and remote agentless adapter is the motivation to configure SSL for data transport between the automation manager and the agentless adapter. The end-to-end automation manager and the local agentless adapter run on different systems only if you configured Application Manager high availability. Remote agentless adapters always run on different systems. Logger tab The Logger tab is only available for remote agentless adapters. The local agentless adapter uses the logger settings that are defined in the Application Manager common configuration. 136 Tivoli System Automation Application Manager V : Installation and Configuration Guide

155 Use the Logger tab to specify the settings for logging, tracing, and First Failure Data Capture. You can change the settings permanently or temporarily. Note: The Logger tab always displays the values that are currently set in the configuration file. Controls and fields on the Logger tab: Maximum log/trace file size The maximum disk usage in KB that a log file can reach. If the limit is reached, another log file is created. The maximum number of log files is two, which means that the least recent file gets overwritten after both files are filled up. The default maximum file size is 1024 KB. Message logging level Select the Message logging level, depending on the severity of messages that you want to be logged. Trace logging level Select the Trace logging level, depending on the severity of the incidents that you want to be logged. First failure data capture (FFDC) recording level Select the FFDC recording level, depending on the severity of the incidents for which you want FFDC data to be collected. First failure data capture (FFDC) maximum disk space Specify the maximum disk space in bytes used by FFDC traces, which are written to the FFDC trace directory. The default space is bytes (10 MB). First failure data capture (FFDC) space exceeded policy Select one of the options: Ignore Issue a warning, but do not enforce the FFDC disk space limitation. Auto-delete Automatically delete FFDC files to enforce the FFDC disk space limitation. This is the default space exceeded policy. Suspend Halt further FFDC actions until disk space is freed manually. First failure data capture (FFDC) message ID filter mode Select one of the options: Passthru All log events with messages that are specified in the message ID list will pass the filter and FFDC data is written. This is the default filter mode. Block All log events with messages that are specified in the message ID list are blocked. First failure data capture (FFDC) message ID list The message IDs that control for which log events FFDC data is written, depending on the filter mode. The comparison of message IDs is case-sensitive. Each message ID must occur in a new line. Wildcard characters, for example, *E (for all error messages), are allowed. Chapter 3. Configuring 137

156 Saving the remote agentless adapter configuration To save your changes to the System Automation Application Manager remote agentless adapter configuration properties files, click Save in the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. Note: The configuration files are in a subdirectory of the standard configuration directory. The name of the subdirectory is the remote agentless adapter host name that you specified for this adapter instance in the remote agentless adapter configuration window. Distributing a remote agentless adapter configuration Use the remote agentless adapter configuration distribution dialog to distribute the configuration files for a remote instance to the remote host where that adapter instance is installed. To open the configuration distribution dialog, select the entry that you want to distribute and click Distribute in the remote agentless adapter configuration window. Provide the following input in the Remote agentless adapter configuration distribution dialog Remote host login user ID and password The credentials that are used to access the remote agentless adapter host. The specified user ID must have write access to the configuration directory on the remote host that you defined for this configuration. Recycle remote agentless adapter after configuration distribution Check whether you want the agentless adapter to be stopped and restarted on the remote host after the configuration distribution ran. Then, the remote agentless adapter runs with the changed configuration values. The remote agentless adapter is recycled only if the distribution of all configuration files is completed successfully and if the adapter is running. Click OK to distribute the configuration. Upon completion, the Configuration distribution status window opens to show the list of configuration files that are distributed. If you selected Recycle the remote agentless adapter after configuration distribution, you are informed about the result of the recycle attempt and the status of the adapter on the remote host. Controlling Agentless Adapters Use the eezaladapter command to start, stop, and monitor Agentless Adapters. To control the local agentless adapter, run the command on the Application Manager server system. To control the remote Agentless Adapters, run the command on the respective remote host. For more information about the eezaladapter command, see Tivoli System Automation Application Manager, Reference and Problem Determination Guide. Configuring agentless adapters in silent mode You can configure agentless adapters in silent mode as an alternative to using the configuration dialogs. 138 Tivoli System Automation Application Manager V : Installation and Configuration Guide

157 Use the silent mode to configure the agentless adapter: v Configuring the local agentless adapter. v Configuring remote Agentless Adapters. v Adding, removing, and distributing remote agentless adapter configurations. Refer to Configuring in silent mode on page 203 for a detailed description of the silent mode configuration tasks. Tuning the number of domains and resources of agentless adapters The amount of resources that can be managed by agentless adapters without performance degradation depends on the hardware. Your performance depends especially on processor power and CPU cycles, that are available on the system where agentless adapters run. Make sure that CPU and memory utilization is not higher than 80% after policy activation. Depending on your hardware capabilities, the numbers that are given in the following recommendations may vary slightly. Adhering to those recommendations provides a good performance using agentless adapters. Recommendations for the local agentless adapter: 1. Do not define more than 20 domains. 2. Do not include more than 50 resources in each domain. 3. Do not define more than 150 remote resources in total. Recommendations for one remote agentless adapter instance: 1. Do not define more than 40 domains. 2. Do not include more than 250 resources in each domain. 3. Do not define more than 450 remote resources in total. For each agentless adapter instance (local and remote), balance the number of resources per domain by including a similar number of resources in each domain. Configuring virtual server & hardware management Configuring the hardware adapter Configure the hardware adapter to access the zenterprise Hardware Management Console (HMC) or to manage hardware for distributed disaster recovery with Geographically Dispersed Parallel Sysplex (GDPS ). To open the configuration dialog, click Configure on the Virtual Server/HW Management tab of the task launcher window. Configure the System Automation Application Manager hardware adapter: 1. Configuring the hardware adapter host by using the Adapter tab. 2. Configuring the hardware adapter to access the zenterprise HMC for virtual server management by using the zenterprise HMC Access tab. Chapter 3. Configuring 139

158 3. Configuring the hardware adapter to manage hardware for distributed disaster recovery with GDPS by using the DR Hardware Credentials tab. Note: This configuration is supported only on Linux on System z. To open the configuration dialog, click Configure in the hardware adapter configuration section on the High Availability tab of the task launcher window. Post-configuration tasks: After you changed any of the configuration properties, continue as follows: v If you configured the hardware adapter to manage hardware for distributed disaster recovery with GDPS, activate any new or changed hardware access credentials. Start the Refresh task in the hardware adapter section of the Virtual Server / HW Management tab of the task launcher. For more information, see Refreshing the active hardware adapter configuration on page 145. If you configured the hardware adapter to access the zenterprise HMC for virtual server management, reconnect to the HMC by starting the Refresh task. In both cases, you can alternatively restart the hardware adapter by using the following commands: eezhwadapter -stop Stop the adapter, and eezhwadapter -start activate the changed configuration settings. v For a change in the request port number on the Adapter tab to become effective, the hardware adapter must be restarted with commands eezhwadapter -stop and eezhwadapter -start. v Test the hardware adapter by starting the Test task in the hardware adapter section on the Virtual Server / HW Management tab of the task launcher (see Testing the active hardware adapter on page 145). v If System Automation Application Manager is configured for high availability, replicate the configuration files to the other nodes of the System Automation for Multiplatforms cluster that provides the high availability. For more information, see Replicating the configuration files on page 160. Adapter tab Use the Adapter tab to configure the settings of the host where the hardware adapter is running. This is the same host system on which the WebSphere Application Server that hosts the end-to-end automation manager is located. Thus you do not need to explicitly specify a host name or IP address on this tab. Field on the Adapter tab: Request port number Specify the number of the port to which the hardware adapter listens for requests from the end-to-end management host. The default port is zenterprise HMC Access tab Use the zenterprise HMC Access tab to configure the hardware adapter to access the zenterprise Hardware Management Console (HMC) for virtual server management. Controls and fields on the zenterprise HMC Access tab: 140 Tivoli System Automation Application Manager V : Installation and Configuration Guide

159 Manage virtual servers using the zenterprise HMC Select this check box if you want to use the hardware adapter to manage virtual servers by using the zenterprise HMC. If you select this check box, the actions that are related to connecting to the zenterprise HMC will be performed when you start the Test tasks in the hardware adapter section on the Virtual Server / HW Management tab of the task launcher. If this check box is not selected, the refresh and test actions that establish the connection to the zenterprise HMC are not performed and all dialog elements on this pane are disabled. Configure settings of the zenterprise HMC: Domain name The name of the zenterprise HMC domain. The name that you specify in this field must be unique in the set of all automation domains you are working with. HMC host name or IP address The host name (short name or fully qualified name) or the IP address (IP version 4 or IP version 6) of the host where the zenterprise HMC server is installed. Configure functional user credentials to access the zenterprise HMC: The functional user credentials are used by the automation JEE framework to access the zenterprise HMC server through the hardware adapter. If you select one of the Use functional user credentials for authentication buttons, these credentials are also used for each user request to access the zenterprise HMC through the hardware adapter. Functional user ID Specify the functional user ID for the automation JEE framework. Functional password Specify the password of the functional user ID for the automation JEE framework. Click Change to change the current password. Configure the mode of authentication for accessing the zenterprise HMC: Enforce user authentication for all user interfaces If you select this button, credentials must be available or explicitly defined for each user who wants access to the zenterprise HMC through the hardware adapter. This applies for all user interfaces that support access to the zenterprise HMC through the hardware adapter. Use functional user credentials for authentication in command shell, enforce user authentication for all user interfaces If you select this button, credentials of the functional user ID described above are used by the JEE automation framework and for each user request to access the zenterprise HMC through the hardware adapter using the eezcs command. Credentials must be available or explicitly defined for each user who wants to access the zenterprise HMC through any other user interface, for example, the operations console. Use functional user credentials for authentication for all other user interfaces If you select this button, credentials of the functional user ID described above are used by the JEE automation framework and for each user Chapter 3. Configuring 141

160 request to access the zenterprise HMC through the hardware adapter. This applies for all user interfaces that support access to the zenterprise HMC through the hardware adapter. Configure Secure Sockets Layer (SSL) for communication with the zenterprise HMC: Truststore Specify the name of the truststore file that is used for SSL. Click Browse to select the truststore file. Truststore password Specify the password of the truststore file. Click Change to change the current password. Note: The steps for creating a truststore and importing the zhmc certificate are described in zenterprise Hardware Management Console on page 283. DR Hardware Credentials tab Use the DR Hardware Credentials tab to configure the hardware access credentials that are used by the System Automation Application Manager hardware adapter. Controls and fields on the DR Hardware Credentials tab Manage hardware for distributed disaster recovery with GDPS Select this check box if you want to use the adapter to manage hardware for distributed disaster recovery with GDPS. The actions that are related to the configured hardware access credentials are processed when you start the Refresh or Test tasks. These tasks are in the hardware adapter section on the Virtual Server / HW Management tab of the task launcher. If you do not select this check box, therefresh or Test actions are not processed and all controls to modifying the contents of the hardware lists on this pane are disabled. Note: The configuration of hardware access credentials is available only on a subset of the supported operating systems for the hardware adapter. If you run the configuration on an operating system that is not supported by this configuration task, the check box is disabled. Configured hardware access credentials This list shows all the hardware entities for which you currently defined credentials that are used by the hardware adapter to access those hardware units. A dash (" - ") in the Slot column indicates the hardware box itself. Each hardware unit that is defined in a disaster recovery policy must also be specified in the credentials list. However, you can decide to explicitly omit the actual credentials for selected hardware units. In this case, the user ID column remains empty. Use the Add missing button to update the hardware access credentials list. Add entries for all hardware units that are defined in disaster recovery policies, but do not yet have credentials that are defined. Use the Add button to display the Add Hardware Access Credentials dialog. Add a hardware unit with its credentials to the list of hardware access credentials. For more information, see Adding credentials on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

161 Use the Remove button to remove the selected hardware unit from the list of hardware access credentials. Remove only hardware units that are not defined in any disaster recovery policy. Use the Change button to display the Change Hardware Access Credentials dialog that to change the user ID and password for the selected hardware unit. For more information, see Changing credentials on page 144. Adding credentials: Use this dialog to define access credentials for hardware units that have not yet been defined in a disaster recovery policy. Fields on the Add Hardware Access Credentials dialog: Box Slot The name of the hardware box for which you want to define credentials. The name of the hardware box is mandatory. The name of the slot in the hardware box for which you want to define credentials. If the hardware box does not contain any slots or you want to define credentials just to access the box itself, leave this field empty. User ID The user ID that is used by the end-to-end hardware adapter to access the specified hardware unit. Password The password that is used by the end-to-end hardware adapter to access the specified hardware unit. Password confirmation Identical to the value specified in the Password field. Used to confirm password correctness. SNMP Privacy password If the hardware adapter uses SNMP to communicate to a hardware box, you need to add a privacy password to the credentials for that hardware box if SNMP is set up with encrypted communication. Do not specify an SNMP privacy password if you are defining credentials for a slot in a hardware box. Privacy password confirmation Identical to the value specified in the SNMP Privacy password field. Used to confirm password correctness. Because the definition of access credentials for hardware units is optional, you can leave the user ID and password fields empty. Even if you define access credentials for a hardware box that is accessed by the hardware adapter via SNMP, you can still choose to omit the SNMP privacy password. Clicking the OK button adds the hardware unit and the credentials that you have specified to the hardware access credentials list on the Hardware Adapter Configuration tab and closes this dialog. Clicking the Cancel button closes this dialog without adding the specified hardware unit and credentials. Chapter 3. Configuring 143

162 Changing credentials: Use this dialog to change the user ID and password for a selected hardware unit. The entry fields in this dialog are primed with the values of the selected hardware unit. The name of the box and slot of the selected hardware unit are displayed in the corresponding output fields. Fields on the Change Hardware Access Credentials dialog that you can update: User ID The user ID that is used by the end-to-end hardware adapter to access the selected hardware unit. Password The password that is used by the end-to-end hardware adapter to access the selected hardware unit. Password confirmation Identical to the value specified in the Password field. Used to confirm password correctness. SNMP Privacy password If the hardware adapter uses SNMP to communicate to a hardware box, you need to add a privacy password to the credentials for that hardware box if SNMP is set up with encrypted communication. Privacy password confirmation Identical to the value specified in the SNMP Privacy password field. Used to confirm password correctness. Note: SNMP privacy passwords can only be specified for hardware boxes. Therefore the privacy password fields are not shown on this dialog if you are changing credentials for a slot in a hardware box. Because the definition of access credentials for hardware units is optional, you can leave the user ID and password fields empty. Even if you define access credentials for a hardware box that is accessed by the hardware adapter via SNMP, you can still choose to omit the SNMP privacy password. Use the Clear credentials button to easily remove all specified credentials for the selected hardware unit. Clicking the OK button changes the credentials for the hardware unit that you selected in the hardware access credentials list on the Credentials tab and closes this dialog. Clicking the Cancel button closes this dialog without changing the selected hardware unit credentials. Saving the hardware adapter configuration To save your changes to the hardware adapter configuration files, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. If you have configured high availability for System Automation Application Manager, you must replicate the properties files to the other nodes in the System Automation for Multiplatforms cluster (see Replicating the configuration files on page 160). 144 Tivoli System Automation Application Manager V : Installation and Configuration Guide

163 Refreshing the active hardware adapter configuration Click Refresh on the Virtual Server / HW Management tab of the configuration dialog task launcher. The actions that are performed depend on the functionality you configured for the hardware adapter. If you configured the adapter to manage hardware for distributed disaster recovery with GDPS, new or changed hardware access credentials are automatically reloaded by the hardware adapter. It is not required to restart the hardware adapter. If you apply any changes to the configuration of the hardware access credentials, you must always request a refresh. If you configured the hardware adapter to manage virtual servers by using the zenterprise HMC, no refresh function is available. Note: If you changed any other settings of the System Automation Application Manager configuration, restart the hardware adapter by using the commands eezhwadapter -stop and eezhwadapter -start to activate the changes. Testing the active hardware adapter Click Test on the Virtual Server / HW Management tab of the configuration dialog task launcher. The actions that are processed depend on the functionality you configured for the hardware adapter. If you configured the adapter to manage hardware for distributed disaster recovery with GDPS, the hardware access credentials are tested without powering on or off the target hardware systems. Use this task after you configure the hardware access credentials. The hardware adapter must be running and a disaster recovery policy must be loaded. The test task runs the following actions: v Check whether credentials are specified for boxes and slots. Issue warnings if credentials are missing. v Check whether hardware management tasks for powering on and off are present for each slot. Issue warnings if tasks are missing. v Check whether the working directories for script execution exist and can be read. Raise exceptions if not. v Run each script that is defined in the disaster recovery policy with the test option. Raise exceptions if errors are found. v Run each SNMP task as a GET operation to read the power status of the node from SNMP. Raise exceptions if errors are found. If any warnings or exceptions occur, the corresponding messages are collected and presented in a dialog. Note: Some aspects of the disaster recovery setup cannot be tested without powering on and off systems. For example, for SNMP, the user ID might be authorized to read the power status of the node, but not to change it. The test option of the scripts can succeed while normal operation might fail. For this reason, real fire-drill tests are required for the hardware adapter. Chapter 3. Configuring 145

164 If you configured the hardware adapter to manage virtual servers by using the zenterprise HMC, the connectivity to the zenterprise server is tested. The following actions are processed: v The configured host name or IP address that is used by the interface to connect to the zenterprise HMC are verified. v The versions of the zmanager communication interface that is used by the Application Manager and the zenterprise HMC check for compatibility. v Log on to zmanager by using the configured functional credentials. v Log off from zmanager. The zenterprise HMC test function can be processed even if the hardware adapter is not up and running. You must always use the test function after you change the functional credentials that are used to access the zenterprise HMC, or its host name or IP address. If you configured the hardware adapter to be used for both tasks, both test functions are processed in the sequence described. Configuring the hardware adapter in silent mode You can configure the hardware adapter in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to configure the following tasks: v Configuring the hardware adapter v Refreshing the active hardware adapter configuration v Testing the hardware adapter Refer to Configuring in silent mode on page 203 for a detailed description of the silent mode configuration tasks. Configuring storage replication Configure storage replication by configuring TPC-R. Configuring the TPC-R domain Configure a Tivoli Storage Productivity Center for Replication (TPC-R) domain that is used by the System Automation Application Manager to integrate storage replication sessions into end-to-end automation policies. To open the configuration dialog, click Configure on the Storage Replication tab of the task launcher window. After you modified any of the configuration properties, you must activate new or modified TPC-R domain settings. Start the Refresh task on the Storage Replication tab of the task launcher. TPC-R Domain configuration window Use this window to configure the settings for the TPC-R domain and the user credentials to access the corresponding TPC-R servers. 146 Tivoli System Automation Application Manager V : Installation and Configuration Guide

165 List of TPC-R domain settings This list shows the currently defined TPC-R domain and its properties. v Use the Add button to display the Add TPC-R Domain dialog. Add a TPC-R domain with the settings of the corresponding TPC-R servers and the user credentials to access those servers. For more information, see Adding a TPC-R domain. Note: With the current release of System Automation Application Manager, the configuration of only one TPC-R domain is supported. v Use the Modify button to display the Change TPC-R Domain Settings dialog. Change the settings of the TPC-R servers that are associated with the domain and the user credentials to access those servers. For more information, see Changing TPC-R domain settings on page 148. Adding a TPC-R domain: Use this dialog to add a Tivoli Storage Productivity Center for Replication (TPC-R) domain with the settings of the corresponding TPC-R servers and the user credentials to access those servers. Fields on the Add TPC-R Domain dialog: Domain name Name of the TPC-R domain. The name that you specify in this field must be unique in the set of all automation domains with which you are working. TPC-R server one settings Hostname or IP address The name or IP address of the TPC-R server one that is used for this domain. Communication port number The port number that is used by System Automation Application Manager to communicate with the TPC-R server one. The default port number is Web-GUI port number The secure port number that is used to access the TPC-R web-gui on server one. It is used by System Automation Application Manager to provide launch-in-context capabilities from the System Automation operations console to the TPC-R GUI. The default port is Use the following URL to verify the port number: If the TPC-R server one is up and running, the welcome screen of TPC-R opens. TPC-R server two settings Hostname or IP address The host name or IP address of the TPC-R server two that is used for this domain. The server two host name or IP address is optional. Chapter 3. Configuring 147

166 Communication port number The port number that is used by System Automation Application Manager to communicate with TPC-R server two. The default port number is The server two port number is optional. Web-GUI port number The secure port number that is used to access the TPC-R web-gui on server two. It is used by System Automation Application Manager to provide launch-in-context capabilities from the System Automation operations console to the TPC-R GUI. The default port is The server two GUI port number is optional. Use the following URL to verify the port number: If the TPC-R server two is up and running, the welcome screen of TPC-R opens. Credentials for accessing TPC-R servers User ID The user ID that is used by System Automation Application Manager to access the specified TPC-R server one. If you specified also a server two, the same user ID is used to access both servers. This user ID is required for TPC-R. Make sure to configure the TPC-R user ID role Operator for all replication sessions that are managed with System Automation Application Manager by using replication references. You can assign this role in the Tivoli Storage Productivity Center for Replication. Password The password that is used by System Automation Application Manager to access the specified TPC-R server. If you specified also a server two, the same password is used to access both servers. Password confirmation Identical value as specified in the password field to confirm password correctness. Port numbers must match what you defined for the TPC-R configuration in: <TPC_R_INSTALL_DIR>/eWAS/profiles/CSM/properties/rmserver.properties Parameters on the respective TPC-R server. communications.port = <PORT_NUMBER> WC_defaulthost_secure = <GUI_PORT_NUMBER> Because definition of a server two is optional, you can leave the corresponding server host name and port fields empty. If you specify a server two host name or IP address, you must also specify the port numbers. Click OK to add the domain and the settings that you specified to the domain list in the TPC-R Domain Configuration window and closes this dialog. Click Cancel to close this dialog without adding the specified TPC-R domain. Changing TPC-R domain settings: Use the Modify TPC-R Domain Settings dialog to change the settings for a selected TPC-R domain. 148 Tivoli System Automation Application Manager V : Installation and Configuration Guide

167 The entry fields in this dialog are primed with the values of the selected domain. For a description of the fields, except for the domain name, which cannot be changed and is displayed as an output field, see Adding a TPC-R domain on page 147. Saving the TPC-R domain configuration To save your changes to the TPC-R configuration files, click Save in the TPC-R domain configuration window. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. If you configured high availability for System Automation Application Manager, you must replicate the properties files to the other nodes in the System Automation for Multiplatforms cluster. For more information, see Replicating the configuration files on page 160. Refreshing the TPC-R domain settings Click Refresh on the Storage Replication tab of the configuration dialog task launcher to trigger that the TPC-R domain configuration settings are reloaded into the running system. Repeat this procedure after changing any of the TPC-R domain properties or credentials. Domain properties are used to define the TPC-R server one and server two host and ports that are currently stored in the end-to-end automation database. The domain properties are refreshed with the values that are stored in the corresponding TPC-R configuration file. The currently active sessions with any TPC-R server are recycled to pick up a fresh copy of the access credentials from the configuration file. Testing the TPC-R domain configuration Click Test on the Storage Replication tab of the configuration dialog task launcher to trigger that the currently defined TPC-R domain configuration settings are validated. You can walk through the following steps, if you change any of the TPC-R domain configuration properties: v Test the configuration settings that are currently stored in the configuration files. This test requires that the TPC-R server is set up according to the configuration settings in those configuration files. You can have more than one TPC-R server. v If the test was successful, refresh the currently active configuration with the changed configuration values. The test task processes the following actions for the defined TPC-R domain: v Establish a connection to the TPC-R server one host. v Establish a connection to the TPC-R server two if a server two is configured. v Validate the defined user credentials for accessing TPC-R server one. v Validate the defined user credentials for accessing TPC-R server two if a server two is configured. Chapter 3. Configuring 149

168 Configuring the TPC-R domain in silent mode You can configure the TPC-R domain in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to configure the following tasks: v Configuring the TPC-R domain Configuring high availability v Refreshing the active TPC-R domain configuration v Testing the TPC-R domain configuration For a detailed description of the silent mode configuration tasks, see Configuring in silent mode on page 203. If you configured System Automation Application Manager for a disaster recovery setup on two sites, the high availability configuration is different. For more information, see High availability for a disaster recovery setup on two sites on page 168. High availability for System Automation Application Manager Make System Automation Application Manager highly available by using System Automation for Multiplatforms. The high availability policy makes all components that are required to run System Automation Application Manager highly available. System Automation for Multiplatforms resources and corresponding relationships are defined for each component: v DB2, optional. For more information, see High availability options with DB2 on page 151. v WebSphere Application Server v System Automation Application Manager end-to-end automation manager v System Automation Application Manager hardware adapter for the Distributed Disaster Recovery feature, if used v System Automation Application Manager GPDS agent for the Distributed Disaster Recovery feature, if used v System Automation Application Manager local agentless adapter, if used For a detailed description of all involved resources and relationships, see High availability policy of System Automation for Multiplatforms on page 164. There are different IP addresses involved: v One individual IP address for each node in the System Automation for Multiplatforms cluster. v One service IP address for the complete cluster. Use the service IP address as the target address to open the web-based operations console after the cluster is started and the policy is active. Use the service IP address as target address to configure end-to-end automation adapters as well. 150 Tivoli System Automation Application Manager V : Installation and Configuration Guide

169 The System Automation for Multiplatforms cluster might have one, two, or three nodes. The number of nodes that you configure has the following impact on the capabilities of the high availability policy: One node There is no redundancy and failover capability if the node becomes offline. System Automation for Multiplatforms provides the correct start/stop sequence of all components and a restart only in case of an application failure. Two nodes In addition to the capabilities available for the one-node setup, a complete failover of the Application Manager workload is processed in case of a node failure. If the local agentless adapterr is configured, the adapter and the rest of the Application Manager workload initially run on different nodes for workload balancing reasons. Only in case of a node failure, the complete workload moves to the remaining node. Three nodes In addition to the capabilities available for the two-node setup, the local agentless adapter is kept running on a different node in case of a node failure. The topic Configuring the high availability policy on page 153 describes the high availability configuration tabs of the System Automation Application Manager configuration dialog. To open the configuration dialog, click Configure on the High Availability tab f the task launcher. Post-configuration tasks: Ensure that the high availability configuration properties are identical on all nodes of the System Automation for Multiplatforms domain. Replicate the configuration files to the other nodes in the cluster. For more information, see Replicating the configuration files on page 160. High availability options with DB2 Learn more about two scenarios that show how DB2 can be used and the impact on the System Automation Application Manager high availability policy. Scenario with a shared DB2 database Active node 1 DB node Standby node 2 DB Manager J2EE Framework DB file system DB Manager J2EE Framework Automation Engine Automation Engine Figure 12. End-to-end high availability scenario with a shared database file system In this scenario, there are independent DB2 database managers on each node in the cluster. Only one of them is active at a particular time. Data sharing is accomplished by using a shared disk. Only the node where the active DB2 manager is running has the shared disk mounted. Chapter 3. Configuring 151

170 When you configure the System Automation Application Manager high availability policy for this scenario, select to include DB2 into the policy. Scenario with a remote DB2 database Active node 1 DB node Standby node 2 JDBC Driver DB Manager JDBC Driver J2EE Framework J2EE Framework Automation Engine Automation Engine DB file system Figure 13. End-to-end high availability scenario with a remote database file system In this scenario, the DB2 database manager is located outside the cluster. The System Automation Application Manager installation on each cluster node uses the same remote database. When you configure the System Automation Application Manager high availability policy for this scenario, select to not include DB2 into the policy for this scenario. Setting up the high availability policy Learn more about what is required to do to set up the high availability policy. Process the following steps to make System Automation Application Manager highly available: 1. Ensure that all prerequisites are met. For more information, see Planning for high availability on page Run the configuration dialog cfgeezdmn to configure: a. The end-to-end automation manager. b. The System Automation Application Manager hardware adapter, if used. c. The System Automation Application Manager agentless adapter, if used. 3. Ensure that System Automation Application Manager works correctly while it is running independently on each node. Start each application on one node only and verify that they work correctly. Then, stop all applications on this node and repeat on the other node. 4. Stop all applications on all nodes before you activate the System Automation Application Manager high availability policy the first time by using the configuration dialog "Define policy" task. 5. Run the configuration dialog cfgeezdmn to configure the automation policy for the end-to-end automation manager: a. Configure b. Replicate c. Set up domain only needed if no System Automation for Multiplatforms domain exists. d. Define policy 152 Tivoli System Automation Application Manager V : Installation and Configuration Guide

171 The System Automation Application Manager high availability policy is now activated on the System Automation for Multiplatforms domain. Configuring the high availability policy Configure the resources and settings of the System Automation Application Manager high availability policy. Click Configure on the High availability tab of the task launcher window to open the high availability policy configuration dialog. Domain Setup tab: Use the Domain Setup tab to configure the parameters that are required for setting up the System Automation for Multiplatforms domain. Use this domain to provide high availability for System Automation Application Manager. The specified parameters are used to create the System Automation for Multiplatforms domain in the setup domain task. Controls and fields on the Domain Setup tab: Domain name The name of the System Automation for Multiplatforms domain. To prime the field with the currently defined domain name, click Query domain. The domain status (Online or Offline) is displayed to the right of the field. Network tie breaker IP address The IP address that is used to set up a network tie breaker. Leave the field empty if you are setting up a three-node System Automation for Multiplatforms domain, or a different type of tie breaker for a two-node domain. In this case, no network tie breaker is defined. To prime the field with the currently defined value, click Query domain. If you use Query domain to fill this field, the first defined tiebreaker of type "EXEC" is chosen. Node list The table lists the nodes of the System Automation for Multiplatforms domain. If the domain is online, clicking Query domain populates the table with the nodes that are online in the domain. Table columns: Defined node The name of the node. Automate on node Indicates whether System Automation Application Manager is to be automated on the node, in which case it is included in the automation policy. Network interface The name of the network interface on this node. Possible actions on the tab: Chapter 3. Configuring 153

172 Determining the sequence in which automation selects the node on which System Automation Application Manager can run You specify the preferred failover sequence by changing the position of the nodes in the list. To move a node to a different position, select the node from the list and click Up or Down. Adding, changing, and removing nodes To change the list of nodes in the automation policy, use the corresponding buttons: Add Opens a window for specifying the settings for the node that is to be added to the automation policy. Modify To change the settings for a node, select the node, click Modify, and change the settings in the window that is displayed. Remove To remove a node from the automation policy, select the node, and click Remove. If you add or modify a node and you already defined a System Automation for Multiplatforms domain, specify a node name that is listed when you run the lsrpnode RSCT command. The result of the lsrpnode command is also used to prime the nodes list on the Domain Setup tab when you click the Query Domain button. Automation Manager tab: Use the Automation Manager tab to configure the resources that are used to automate the end-to-end automation manager. Controls and fields on the Automation Manager tab: Automated resources prefix The prefix that precedes the names of the resources and groups in the automation manager automation policy. The prefix is restricted to ASCII characters. If you defined the current automation policy by using the old prefix value, change the prefix as follows: 1. Remove the current automation policy. For more information, see Removing the domain on page Change the prefix on this tab. 3. Define the automation policy again. For more information, see Defining the automation policy on page 163. IP version Select which IP version you want to use for the virtual IP address in the end-to-end automation manager automation policy. v Select IPv4 and specify a valid version 4 IP address and a netmask. The IPv6 address and netprefix fields are disabled. v Select IPv6 and specify a valid version 6 or mixed mode IP address and a netprefix. The IPv4 address and netmask fields are disabled. v Select Both and specify a valid version 4 as well as a valid version 6 or mixed mode IP address. Specify also a netmask as well as a netprefix. 154 Tivoli System Automation Application Manager V : Installation and Configuration Guide

173 Note: The IP address that is used to make the automation manager highly available must be identical to the IP address that you specify on the Domain tab on page 106 in the System Automation Application Manager common configuration. v If you select IPv4 as IP version, you specify the version 4 IP address. Otherwise, it is the version 6 IP address. v If the automation manager is made highly available, use the corresponding IP address in the configuration of each first-level automation adapter as the IP address for the end-to-end automation management host. v If you are using remote Agentless Adapters, it is implicitly used as IP address for the end-to-end automation management host. If a version 6 IP address is used, each system where a first-level automation adapter or a remote agentless adapter runs, must provide IP version 6 communication capabilities. Click Query domain to automatically match the IP version with the defined IP address or addresses. IPv4 address The virtual IP version 4 address that is shared by all nodes in the IBM Tivoli System Automation domain and that is set for the version 4 IBM.ServiceIP resource in the end-to-end automation manager automation policy. The virtual IP address must be authorized by your network administrator. The IPv4 address is required if you select IPv4 or Both as IP version. Otherwise, this field is disabled. To prime the field with the currently defined value, click Query domain. IPv6 address The virtual IP version 6 address that is shared by all nodes in the IBM Tivoli System Automation domain and that is set for the version 6 IBM.ServiceIP resource in the automation manager automation policy. The virtual IP address must be authorized by your network administrator. The IPv6 address is required if you select IPv6 or Both as IP version. Otherwise, this field is disabled. To prime the field with the currently defined value, click Query domain. Netmask Enter the netmask that is set for the IBM.ServiceIP resource in the automation manager automation policy. Request the address from your network administrator. The netmask is required if you select IPv4 or Both as IP version. Otherwise, this field is disabled. To prime the field with the currently defined value, click Query domain. Netprefix Enter the netprefix that is used to define the IBM.ServiceIP resource in the automation manager automation policy. Specify a value in the range of to define how many bits of the IP address are portioned for the network part of that address. The netprefix is required if you selected IPv6 or Both as IP version. Otherwise, this field is disabled. To prime the field with the currently defined value, click Query domain. Policy Pools tab: Use the Policy Pool tab to configure the parameters that are required to automate the file system where the policy pools are located. The data is used to create the corresponding file system resources in the automation policy. The policy pools Chapter 3. Configuring 155

174 must be on a file system that is shared by all nodes in the System Automation for Multiplatforms domain. When the automation policy is active, they are mounted at the specified mount points. Controls and fields on the Policy Pools tab: Automation resources for the Application Manager policy pool: Specify the parameters to define the policy pool where the end-to-end automation policies of the Application Manager are stored. File system type The type of the policy pool file system to be automated, for example, jfs, jfsz, and ext2. To prime the field with the currently defined value, click Query domain. Mount point The mount point of the policy pool file system. Click Browse to select a directory. If the domain is online, you can click Query domain to prime the field with the currently defined value. Device name The device name of the policy pool file system. Click Browse to select a device. If the domain is online, you can click Query domain to prime the field with the currently defined value. Automation resources for the local agentless adapter policy pool: Specify the same set of parameters as for the Application Manager policy pool to define the policy pool where the agentless adapter policies are stored. The fields for the agentless adapter policy pool are only enabled if Enable agentless adapter configuration is checked on the Non-clustered Nodes tab of the task launcher window, see Configuring the Application Manager settings on page 100. Due to the AntiAffinity relationship in the high availability policy, the automation manager and the agentless adapter run on different nodes. Therefore, the policy pools of both components cannot be shared. In particular, the mount points for both policy pools must be different. WebSphere tab: Use the WebSphere tab to configure the parameters that are required for automating the instance of WebSphere Application Server that hosts the end-to-end automation manager. The data is used to create the corresponding resource in the automation policy and to monitor, start, and stop the WebSphere Application Server. Most of the parameters are set by the installer at installation time. Controls and fields on the WebSphere tab: Application server name The name of the WebSphere Application Server instance that hosts the end-to-end automation manager. Application server SOAP port The number of the WebSphere Application Server port that is used by the end-to-end automation manager. The name of this port in the administrative console is SOAP_CONNECTOR_PORT. 156 Tivoli System Automation Application Manager V : Installation and Configuration Guide

175 Profile directory The directory in which the WebSphere Application Server profile for System Automation Application Manager is located. Click Browse to navigate to the directory. User ID The WebSphere administrator user ID that is used to stop the WebSphere Application Server. Password The WebSphere administrator password that is used to stop the WebSphere Application Server. Click Change to change the password. The WebSphere administrator credentials are stored in the file properties/soap.client.props. This file is in the profile directory. DB2 tab: Use the DB2 tab to configure the parameters that are used for automating the DB2 instance that hosts the System Automation Application Manager database (EAUTODB). The parameters are set by the installer at installation time. Usually, you must not change any of the values. Note: Installation directory, instance owner user ID, and instance owner mount point must be identical on all nodes of the System Automation for Multiplatforms domain. Otherwise, the automation policy does not work. Controls and fields on the DB2 tab: Automate DB2 Select the check box to enable the entry fields on the tab. If you are using a remote DB2 database, do not select the check box. In this case, the DB2 instance must not be included in the automation policy. Installation directory Specify the DB2 installation directory. Click Browse to select a directory. Instance owner user ID Specify the user ID of the owner of the DB2 instance that hosts the System Automation Application Manager database. Instance owner mount point Specify the mount point of the DB2 instance that hosts the System Automation Application Manager database. Click Browse to select a directory. Hardware Adapter tab: The Hardware Adapter tab provides an indication of whether resources for the hardware adapter are included in the Application Manager high availability policy. Including the resources for the hardware adapter will also make the hardware adapter highly available when you save the configuration and start the define policy task the next time. Note: You cannot actively modify the selection states on the Hardware Adapter tab. They correspond to the current configuration status of the hardware adapter. v You can configure the hardware adapter to access the zenterprise HMC or for distributed disaster recovery with GDPS. The corresponding resource that represents the hardware adapter executable is included in the automation policy. Chapter 3. Configuring 157

176 v If you want to configure the hardware adapter for distributed disaster recovery with GDPS, a resource for the GDPS agent of the Application Manager is included in the automation policy. If you changed the configuration status of the hardware adapter, proceed as follows: Click Query domain. If the hardware adapter configuration status is not consistent with the resources that are defined in the currently active automation policy, a warning is shown. To correct the currently active automation policy by adding or removing hardware adapter resources, proceed as follows: Save the current configuration values. This task updates the configuration properties file that is used as input for generating the automation policy. For the hardware adapter, an indication which resources are required, is saved in the configuration properties file. Start the remove policy task. For more information, see Removing the automation policy on page 163. This task deactivates the currently active automation policy, which is inconsistent regarding the adapter configuration status. Start the define policy task. For more information, see Defining the automation policy on page 163. This task activates the new version of the automation policy, which contains the required hardware adapter resources. If you changed the configuration status of the hardware adapter, you need to take the following action. Click Query domain. If the hardware adapter configuration status is not consistent with the resources that are defined in the currently active automation policy, a warning is shown on this window. To correct the currently active automation policy by adding or removing hardware adapter resources, proceed as follows: v Save the current configuration values. This saves an indication which hardware adapter resources, if any, are required in the configuration properties file that is used as input for generating the automation policy. v Start the remove policy task. For more information, see Removing the automation policy on page 163. This deactivates the currently active automation policy which is inconsistent with respect to the adapter configuration status. v Start the define policy task. For more information, see Defining the automation policy on page 163. This activates the new version of the automation policy which contains the required hardware adapter resources. agentless adapter tab: The agentless adapter tab provides an indication of whether resources for the local agentless adapter are included in the Application Manager high availability policy. Including the resources for the agentless adapter will also make the local agentless adapter highly available when you save the configuration and process the define policy task the next time. Note: The selection states on the agentless adapter tab cannot be changed. They correspond to the current configuration status of the agentless adapter. If you checked Enable local agentless adapter configuration on the Non-clustered Nodes tab of the task launcher window, the corresponding agentless adapter resources are included in the automation policy. If you changed the configuration 158 Tivoli System Automation Application Manager V : Installation and Configuration Guide

177 status of the local agentless adapter, proceed as follows. Click Query domain. If the agentless adapter configuration status is not consistent with the resources that are defined in the currently active automation policy, a warning is shown on this pane. To correct the currently active automation policy by adding or removing agentless adapter resources, proceed as follows: Save the current configuration values. This task updates the configuration properties file that is used as input for generating the automation policy. For the agentless adapter, an indication whether resources are required, is saved in the configuration properties file. Start the remove policy task For more information, see Removing the automation policy on page 163. This task deactivates the currently active automation policy, which is inconsistent regarding the adapter configuration status. Start the define policy task For more information, see Defining the automation policy on page 163. This task activates the new version of the automation policy, which contains the required agentless adapter resources.. Saving the high availability configuration: To save your entries, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. To ensure that the configuration properties are set correctly on all nodes of the System Automation for Multiplatforms domain, you must replicate the configuration files as described in Replicating the configuration files on page 160. Retrieving information on an active high availability configuration: To restore a domain configuration from a defined System Automation Application Manager high availability policy, you can use the Query domain button on the configuration dialog. This function retrieves information from most fields in the configuration notebook: Domain tab v Domain name and status (online/offline) v List of nodes and network interfaces v IP address of the defined network tiebreaker. Even if it is not the currently active tie breaker. If more than one EXEC tiebreaker is defined, the address of first one. Automation Manager tab IP address and netmask or net prefix of the IBM.ServiceIP resource starts with resource name prefix. For example, eez-. Policy Pools tab v File system type, mount point, and device name of the IBM.AgFileSystem resource starts with resource name prefix. For example, eez-. Chapter 3. Configuring 159

178 v If the local agentless adapter is part of your high availability policy, the same information is displayed for the file system where the agentless adapter policy pool is located. This is the case, if you checked Enable local agentless adapter configuration on the Non-clustered Nodes tab of the task launcher window and the local agentless adapter is part of the currently active policy. Hardware Adapter tab If there is a mismatch between the current hardware adapter configuration status and the hardware adapter resources in the currently active policy, a warning is displayed on this tab. An example of such a mismatch is if the hardware adapter is not configured, but hardware adapter resources are defined in the active policy. agentless adapter tab If there is a mismatch between the current local agentless adapter configuration status and the agentless adapter resources in the currently active policy, a warning is displayed on this tab. An example of such a mismatch is if the local agentless adapter is configured, but no agentless adapter resource is defined in the active policy. Synchronizing virtual IP address and domain host name: If the Application Manager is configured to be highly available, the virtual IP address that you define for the automation manager must be identical to the value that you configure for the host name of the end-to-end automation manager. The host name is defined in the Host name or IP address field on the Domain tab of the Application Manager common configuration dialog. You can save the high availability configuration only if both values are identical. If you select IPv4 as IP version, the specified virtual version 4 IP address is used, otherwise the specified virtual version 6 IP address is used. Enforcing the virtual IP address being used also for the end-to-end automation manager host name makes sure that the end-to-end automation manager can be contacted by any first-level automation domain, no matter on which node in the cluster the automation manager currently running. The automation management host of each end-to-end automation adapter configuration must be the same virtual IP address. The end-to-end automation management host is defined in the Host name or IP address field on the Host Using Adapter tab of the adapter configuration dialogs. For the System Automation for z/os automation adapter, the host name is the value of the eif-send-to-host name parameter in the adapter properties configuration file. Replicating the configuration files If you configured high availability for System Automation Application Manager, replicate the configuration files to the other nodes in the System Automation for Multiplatforms domain. Replicate the files whenever you modified the configuration of any System Automation Application Manager component. 160 Tivoli System Automation Application Manager V : Installation and Configuration Guide

179 Click Replicate on the High Availability tab of the configuration task launcher. The Replicate Configuration Files window opens. Use this window to distribute (replicate) the configuration files to the remaining nodes in the System Automation for Multiplatforms domain: 1. Select the configuration files that you want to replicate or click Select all to select all configuration files in the list. 2. Select the nodes to which the files are to be propagated. If all nodes can be accessed with the same user credentials, click Select all to ensure that the configuration is identical on all nodes. 3. Under Target node login, type the user ID and password for the replication target nodes. 4. If you configured at least one remote agentless adapter instance, check the Include remote agentless adapter configurations for replication box. The configuration files of all currently configured remote agentless adapter instances are replicated as well, although they are not contained in the list of replication source files. 5. Start the replication by clicking Replicate. Replication can take a while. While the files are being replicated, the Replicate button is indented and grayed-out. When the replication is complete, the replication status of each configuration file is displayed. Setting up the domain Use this task to set up the domain in which System Automation Application Manager is to be automated. If you want to automate System Automation Application Manager in a new System Automation for Multiplatforms domain, set up the domain before you start the high availability configuration task Define policy. Click Set up domain on the High Availability tab of the configuration task launcher. The Set up Domain dialog opens, showing the nodes that set up the domain: the local node and the remote node or nodes, which are specified on the Domain setup tab. If you click Prepare in the Set Up Domain dialog, two actions are performed: 1. Prepare the remote node or nodes for joining the domain. If you configured the System Automation for Multiplatforms domain to consist of a single node, this action is skipped and only the domain definition is prepared. To prepare the nodes, specify the user credentials for accessing the nodes and click Prepare. 2. Define the domain To complete the domain setup, execute the following commands on the local node: v v v preprpnode - prepares the local node for joining the domain mkrpdomain - creates the domain definition by using the domain name and the nodes that were specified on the Domain setup tab startrpdomain - starts the domain (state online) Chapter 3. Configuring 161

180 Note: System Automation for Multiplatforms must be installed on all nodes that are to be included in the new domain. If other System Automation for Multiplatforms domains currently exist, they might be offline. Upon completion, a message box is displayed. Removing the domain To be able to remove the System Automation for Multiplatforms domain definition from all nodes, the domain must be online to the local node. To remove the domain definition from all nodes in the domain, click Remove domain on the High Availability tab of the task launcher. Then, the rmrpdomain command is started. Validating and storing the automation policy You can validate the System Automation Application Manager automation policy by clicking Validate&Store policy on the High Availability tab of the configuration dialog task launcher. This task also stores the automation policy in XML format in a file. Upon completion, the result of the validation is displayed, including the name of the file where the XML policy is stored. This task has the following main purposes: 1. Validating the policy. You can check whether the definitions that you made in the policy configuration window are valid and consistent. 2. Inspecting the generated file. You can check which resources are defined whether you use the Define policy task to activate the configured policy. If you are using System Automation for Multiplatforms to also automate your own applications, the automation policy elements are added as a delta to your currently active policy. You can therefore want to evaluate whether those additional policy elements might have any impact on your active policy. 3. Modifying the stored policy and manually activating it. Apply modifications to the policy or extend it beyond what you can define by using the policy configuration task. Each invocation of the Validate&Store policy or Define policy task overwrites the XML policy file. Copy or rename the file before you modify it. If you want to activate a modified policy, use the sampolicy command. You can use the update option -u in this case in order not to stop or remove any resource outside the scope of the System Automation Application Manager automation policy. The XML policy file contains inclusions of other XML policy files. These included files are not overwritten by an invocation of the Validate&Store policy or Define policy task. If you want to change an included file, copy and rename it and then change the corresponding include-tag to refer to the renamed file. Note: This function is only supported if System Automation for Multiplatforms version 3.1 or higher is used to make the end-to-end automation manager highly available. If earlier versions are used, thevalidate&store policy button is disabled. 162 Tivoli System Automation Application Manager V : Installation and Configuration Guide

181 Defining the automation policy Click Define policy on the High Availability tab of the configuration dialog task launcher. Then, resources with names as described in High availability policy of System Automation for Multiplatforms on page 164 are created. Note: If automated resources with the same name exist, their attributes are modified according to the currently configured values. If you specified for example, the resource or group prefix name eez- on the Automation Manager tab, the resource group eez-rg and the resources and relationships that are shown in the table of High availability policy of System Automation for Multiplatforms on page 164 are created. Note: 1. If you change one of the policy elements outside this dialog, a failure of the remove policy or the define policy task can be caused. 2. Activating or deactivating a policy for System Automation for Multiplatforms by using the sampolicy command can remove existing definitions for the System Automation Application Manager automation policy. For example, the definition of one of the resources in Table 37 on page 165 can be removed when a new policy for System Automation for Multiplatforms is activated. You can first save the currently active policy by using the sampolicy -s command, and then edit the XML output file. Use the command sampolicy -u to update the active policy with the changed XML output file. If you edit the policy, make sure that all definitions for System Automation Application Manager automation are preserved. Make sure that none of your changes has an undesired effect on the currently active System Automation Application Manager automation policy. For more information about the sampolicy command, see System Automation for Multiplatforms Reference and Problem Determination Guide. Removing the automation policy Click Remove policy on the High Availability tab of the configuration dialog task launcher to remove the resources that are described in High availability policy of System Automation for Multiplatforms on page 164. All resources are first stopped and then removed. Activating or deactivating a policy for System Automation for Multiplatforms by using the sampolicy command can remove existing definitions for the System Automation Application Manager automation policy. For example, the definition of one of the resources that are listed in Table 37 on page 165 can be removed when a new policy for System Automation for Multiplatforms is activated. You can save the currently active policy by using the sampolicy -s command. Then, edit the XML output file and use the command sampolicy -u to update the active policy with the changed XML output file. If you want to edit the policy, make sure that all definitions for System Automation Application Manager automation are preserved. Then, none of your changes has an undesired effect on the currently active System Automation Application Manager automation policy. For detailed information, see the description of the sampolicy command in the System Automation for Multiplatforms Reference. Chapter 3. Configuring 163

182 Configuring high availability in silent mode You can configure Application Manager high availability in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to process the following configuration task: v Configuring the automation policy for the automation manager Refer to Configuring in silent mode on page 203 for a detailed description of the silent mode configuration tasks. The following configuration tasks can be processed by using the configuration dialogs or manually: v Replicating the configuration files v Setting up and removing the domain v Validating and storing the automation policy v Defining and removing the automation policy If you do not want to use the configuration dialogs, see Processing tasks manually on page 204 for a detailed description of the tasks you can process manually. High availability policy of System Automation for Multiplatforms The following figure shows the System Automation for Multiplatforms high availability policy that makes System Automation Application Manager highly available. You can find all components, relationships, and dependencies in the following figure. 164 Tivoli System Automation Application Manager V : Installation and Configuration Guide

183 eez-ala-rg Agentless adapter StopAfter StartAfter StartAfter Policy pool AntiAffinity eez-rg eez-srv-rg eez-was-rg eez-engine-rg WebSphere Application Server Virtual IP address End-to-end automation manager StartAfter Policy pool Start After eez-db2-rg DependsOn DependsOn StartAfter DB2 server DependsOn DB2 mount point GDPS agent Hardware adapter Figure 14. Resource groups, resources, and their relationships The eez- prefix is the default value, but can be changed in the configuration dialog. After the top-level group eez-rg is activated by the operator, all applications are started in the correct sequence. All resources are automatically online. Note: Some of the listed resources can or cannot be part of the activated policy, depending on the settings that you defined in the high availability configuration. Table 37. Resources in the automation policy for the end-to-end automation manager Resource name Resource class Description eez-ala-rg IBM.ResourceGroup The resource group that comprises the agentless adapter resources. eez-rg IBM.ResourceGroup The top-level group that comprises all automated resources except for agentless adapter resources. This top-level group always exists. Chapter 3. Configuring 165

184 Table 37. Resources in the automation policy for the end-to-end automation manager (continued) Resource name Resource class Description eez-srv-rg IBM.ResourceGroup The group that comprises the automation manager and the WebSphere Application Server resource. eez-db2-rg IBM.ResourceGroup The group that comprises all DB2 resources. eez-was-rg IBM.ResourceGroup The group that comprises all WebSphere Application Server resources. eez-engine-rg IBM.ResourceGroup The group that comprises all automation manager resources. eez-hwa-rg IBM.ResourceGroup The resource group that comprises the hardware adapter resources. eez-gdpsagent-rg IBM.ResourceGroup The resource group that comprises the command receiver for distributed disaster recovery resources. eez-ip IBM.ServiceIP The virtual IP address that is used for the WebSphere Application Server. eez-ipv6 IBM.ServiceIP The virtual IPv6 address that is used for the WebSphere Application Server. eez-niequ IBM.Equivalency The available network interfaces on each node. eez-ala-rs IBM.Application agentless adapter eez-was-as IBM.Application WebSphere Application Server eez-engine IBM.Application End-to-end automation manager eez-db2-rs IBM.Application DB2 server eez-db2-rs_mount IBM.Application DB2 file system eez-hwa-rs IBM.Application End-to-end hardware adapter eez-gdpsagent-rs IBM.Application Command receiver for distributed disaster recovery. eez-ala-mount IBM.AgFileSystem The policy-pool for the agentless adapter; only defined when the policy pool is not harvested by the StorageRM. eez-shared-mount IBM.AgFileSystem The policy-pool for the automation manager; only defined when the policy pool is not harvested by the StorageRM eez-ala-mount-stopsafterala-rs eez-ala-rs-startsafterala-mount IBM.ManagedRelationship IBM.ManagedRelationship Dependency of the agentless adapter policy pool on the agentless adapter. Dependency of the agentless adapter on the agentless adapter policy pool. 166 Tivoli System Automation Application Manager V : Installation and Configuration Guide

185 Table 37. Resources in the automation policy for the end-to-end automation manager (continued) Resource name Resource class Description ala-rs-startsafter-eezwas-as ala-rs-antiaffinity-eezengine eez-engine-antiaffinityala-rs db2-rs-dependson-db2- rs_mount eez-was-as-dependson-db2- rs IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship Dependency of the agentless adapter on the WebSphere Application Server by using the startafter relationship. Dependency of the agentless adapter on the automation manager by using the AntiAffinity relationship. Dependency of the automation manager on the agentless adapter. Dependency of the DB2 server on the file system. Dependency of the WebSphere Application Server on DB2. Dependency of the policy pool on the automation manager. Dependency of the automation manager on the policy pool. Dependency of the automation manager on the WebSphere Application Server. eez-was-as-startsafter-ip IBM.ManagedRelationship Dependency of the WebSphere Application Server on the virtual IP address. eez-ip-dependson-niequ IBM.ManagedRelationship Dependency of the virtual IP address on the network interface. eez-shared-mountstopsafter-engine eez-engine-startsaftershared-mount eez-engine-startsafterwas-as hwa-startsafter-eezengine gdpsagent-dependson-eezengine IBM.ManagedRelationship IBM.ManagedRelationship Dependency of hardware adapter on the automation manager. Dependency of the command receiver on the automation manager. nettb IBM.TieBreaker Tie-Breaker defined, if IP address is specified on the domain setup page. Notes and restrictions v Do not manually change any of the resources, which are part of the System Automation Application Manager high availability policy, for example by using a command such as chrsrc or chrel. Otherwise, the Define policy or Remove policy task of the configuration dialog might not work. If you want to change any policy elements use the Validate&Store task of the configuration dialog, copy the created policy, and make your changes within the copied policy. You can then activate this changed policy by using the sampolicy command with the update option -u. Chapter 3. Configuring 167

186 v Requests for end-to-end resources are persistent and are therefore not lost when the end-to-end automation manager is moved to another node. v For each first-level automation domain that is connected to the highly available System Automation Application Manager, start the adapter configuration tool. Verify that on the Host Using Adapter page the Host name or IP address is set to the virtual IP address that is defined in the high availability policy. Then, the first-level automation adapter communicates properly with the System Automation Application Manager. v Test the System Automation Application Manager HA setup. For example, initiate a failover of the System Automation Application Manager and verify that all attached end-to-end and first-level domains can be operated from the operations console. Verify that events are received from each domain. v The automation engine and the agentless adapter are supposed to run on different nodes, which is implemented by an AntiAffinity relationship in the policy. Therefore, the policy pools of both components cannot be shared. The mount points for both policy pools must be different. v If you modify the configuration of the WebSphere Application Server, repeat the same configuration changes on both nodes in the high availability cluster. For example, changing security settings, trace settings, or deploying other applications. v Operator credentials that are used for authentication against first-level automation domains can be stored in the IBM Dashboard Application Services Hub credential vault. The credential vault is not shared between the nodes in the high availability cluster. Therefore, after a failover of the WebSphere Application Server, operators must enter their credentials again to access a first-level automation domain. v Operators can specify the number of visible rows that are displayed in the operations console. These preferences are stored in the directory <WAS_ROOT>/profiles/AppSrv01/Tivoli/EEZ, which is not shared between the nodes in the high availability cluster. Therefore, after a failover of the WebSphere Application Server, operators must specify preferences on the second system again if they are changed and differ from the default. High availability for a disaster recovery setup on two sites In a disaster recovery setup with two sites, you can configure a System Automation Application Manager high availability policy to control the site switch in a Geographically Dispersed Parallel Sysplex (GDPS) environment. Define a two-site disaster recovery setup with a System Automation Application Manager installed on each site. The active Application Manager is automatically moved by GDPS if the K-System master moves. For this setup, a special type of System Automation Application Manager high availability policy is required. The high availability policy enables GDPS to control the site switch of the System Automation Application Manager and keeps the EAUTODB database that is synchronized on both sites. If you define a two-site disaster recovery setup, you must also configure an alternative end-to-end automation host for the Application Manager. Configuring an alternative end-to-end automation host on page 114 describes how to define this setup. The configuration of the high availability policy for a disaster recovery setup differs from the regular high availability policy for the following characteristics: 168 Tivoli System Automation Application Manager V : Installation and Configuration Guide

187 Single Node The high availability policy for a disaster recovery setup is based on a one-node System Automation for Multiplatforms cluster. Only the host name of that node is required, instead of a list of up to three nodes that are needed for the regular high availability policy. A virtual IP address is not needed because the application manager cannot move to another node within the cluster. DB2 For the regular high availability policy, including DB2 is optional. The high availability policy for a disaster recovery setup requires the installation of DB2 on the Application Manager node. DB2 thus becomes an unconditional part of the policy. GDPS agent The GDPS agent is included in the regular high availability policy only if the hardware adapter is configured to manage hardware for distributed disaster recovery with GDPS. In the high availability policy for a disaster recovery setup, the GDPS agent is always included. In this configuration GDPS is used to control on which site the System Automation Application Manager is active. Shared file systems for policy pools No resources for shared file systems are included in the high availability policy for a disaster recovery setup. A shared policy pool is not required in a single-node cluster. For information about configuring the regular high availability policy, see High availability for System Automation Application Manager on page 150. Configuring the high availability policy for a disaster recovery setup Configure the resources and settings of the System Automation Application Manager high availability policy for a disaster recovery setup on two sites. Click Configure on the High Availability tab of the task launcher window to open the high availability policy configuration dialog. If you are running on a Linux for System z operating system platform, the Select Application Manager High-Availability Setup dialog opens. Select which type high availability policy you want to configure. The dialog offers two options: Configure the Application Manager high availability policy for a System Automation for Multiplatforms cluster. Select this option to configure the regular high availability policy. When you click OK, the dialog that is described in High availability for System Automation Application Manager on page 150 is displayed. Follow the procedure in that section to configure the policy. Configuring the Application Manager single node high availability policy for a disaster recovery setup Select this option to configure the high availability policy for a disaster recovery setup. Click OK to proceed with the configuration. This option requires the prerequisites that are listed as follows. If these prerequisites are not satisfied, this option is disabled. In this case, a message displays the missing configuration prerequisite is displayed in the dialog. Chapter 3. Configuring 169

188 1. You must configure an alternative end-to-end automation management host. Specify the host name of the other GDPS site as alternative host name in the Application Manager common configuration. If this prerequisite is listed as not satisfied, see Configuring an alternative end-to-end automation host on page Configuration of the local agentless adapter with the high availability policy for a disaster recovery setup is not supported. You must not configure the local agentless adapter. If this prerequisite is listed as not satisfied, clear the corresponding check box on the Non-clustered Nodes tab of the task launcher dialog. Domain Setup tab: Use the Domain Setup tab to configure the parameters that are required for setting up the System Automation for Multiplatforms domain, to provide high availability for System Automation Application Manager. The specified parameters are used to create the System Automation for Multiplatforms domain in the setup domain task. Controls and fields on the Domain Setup tab: Domain Name Specify the name of the System Automation for Multiplatforms domain. To add the currently defined domain name, click Query domain. The domain status (Online or Offline) is displayed to the right of the field. Node Name Specify the name of the System Automation for Multiplatforms node that identifies the single-node domain. If you already defined a System Automation for Multiplatforms domain, specify the node name that is listed as output of the lsrpnode command on that node. If the domain is online, click Query domain to fill in the field with the node of the domain. Automated resources prefix Specify the prefix that is used for the names of the resources and groups in the automation policy. Only ASCII characters are supported. If you defined the current automation policy by using the old prefix value, change the prefix: 1. Remove the current automation policy 2. Change the prefix on this tab 3. Define the automation policy again. WebSphere tab: Use the WebSphere tab to configure the parameters that are required for automating the instance of WebSphere Application Server that hosts the end-to-end automation manager. The data is used to create the corresponding resource in the automation policy and to monitor, start, and stop the WebSphere Application Server. Most of the parameters are set by the installer at installation time. This tab is identical to the WebSphere tab in the regular automation policy configuration. Refer to Configuring the high availability policy on page 153, WebSphere tab on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

189 DB2 tab: Use the DB2 tab to configure the parameters that are used for automating the DB2 instance that hosts the System Automation Application Manager database. These parameters are set at installation time. Usually, you are not required to change any of these values. Controls and fields on the DB2 tab: Installation directory The DB2 installation directory. Click Browse to select a directory. Instance owner user ID The user ID of the owner of the DB2 instance hosts the System Automation Application Manager database. Automation database name The name of the System Automation Application Manager database. Hardware Adapter tab: The Hardware Adapter tab provides an indication of whether resources for the hardware adapter are included in the Application Manager high availability policy. Including the resources for the hardware adapter will also make the hardware adapter highly available when you save the configuration and start the define policy task the next time. You cannot actively modify the Hardware Adapter tab settings. They correspond to the current configuration status of the hardware adapter. You can configure the hardware adapter to access the zenterprise HMC or for distributed disaster recovery with GDPS. The corresponding resource that represents the hardware adapter executable file is included in the automation policy. The GDPS agent is always included in the high availability policy for a disaster recovery setup, independent from the hardware adapter configuration state. If you changed the configuration status of the hardware adapter, proceed as described in Hardware Adapter tab on page 157. Saving the high availability configuration: To save your entries, click Save on the configuration dialog. Upon completion, the Configuration Update Status window is displayed. This window displays the list of updated configuration files. Retrieving information about an active high availability configuration: To retrieve information about a domain configuration from a defined System Automation Application Manager high availability policy, use the Query domain button on the configuration dialog. This function populates the fields in the configuration notebook with the following information: v On the Domain Setup tab: Domain name and status (online/offline) Node name v On the Hardware Adapter tab: If there is a mismatch between the current hardware adapter configuration status and the hardware adapter resources in the currently active policy, a warning is displayed in this tab. An example of such a mismatch is if the hardware adapter is not configured, but hardware adapter resources are defined in the active policy. Chapter 3. Configuring 171

190 High availability configuration tasks On the High Availability tab of the task launcher window, you can launch several other configuration tasks. For each task, see the referenced sections in High availability for System Automation Application Manager on page 150. Replicating the configuration files If you configured the automation policy for a disaster recovery setup, the Replicate button on the task launcher window is disabled. This task is not available for policies in a single-node cluster, because there is no other node to which the configuration can be replicated. Setting up the domain Set up the domain for a high availability policy in a disaster recovery setup. This set up includes the exception that no other cluster nodes must be prepared, because the policy is in a single-node cluster. For more information, see Setting up the domain on page 161. Removing the domain For more information, see Removing the domain on page 162. Validating and storing the automation policy For more information, see Validating and storing the automation policy on page 162. Defining the automation policy For more information, see Defining the automation policy on page 163. Removing the automation policy For more information, see Removing the automation policy on page 163. Configuring high availability for a disaster recovery setup in silent mode You can configure System Automation Application Manager high availability for a disaster recovery setup in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to configure the automation policy for a disaster recovery setup for the automation manager. For more information, see Configuring in silent mode on page 203. The following configuration tasks can be performed only by using the configuration dialogs or manually: v Setting up and removing the domain. v Validating and storing the automation policy. v Defining and removing the automation policy. If you do not want to use the configuration dialogs, refer to Processing tasks manually on page 204 for a detailed description of the tasks you can perform manually. 172 Tivoli System Automation Application Manager V : Installation and Configuration Guide

191 High availability policy using System Automation for Multiplatforms The following figure shows the System Automation for Multiplatforms high availability policy for a disaster recovery setup. System Automation Application Manager becomes highly available, including the disaster recovery setup components. eez-ala-rg Agentless adapter StopAfter StartAfter StartAfter Policy pool AntiAffinity eez-rg eez-srv-rg eez-was-rg eez-engine-rg WebSphere Application Server Virtual IP address End-to-end automation manager StartAfter Policy pool Start After eez-db2-rg DependsOn DependsOn StartAfter DB2 server DependsOn DB2 mount point GDPS agent Hardware adapter Figure 15. Resource groups, resources, and their relationships The resources of the single-node System Automation Application Manager high availability policy for a disaster recovery setup are described in the following table. The eez- prefix is the default value, but can be changed in the configuration dialog. Table 38. Resources in the high availability policy for a disaster recovery setup Resource Name Resource class Description Chapter 3. Configuring 173

192 Table 38. Resources in the high availability policy for a disaster recovery setup (continued) eez-rg IBM.ResourceGroup The resource group that comprises all System Automation Application Manager resources except DB2 eez-db2-rg IBM.ResourceGroup The resource group that comprises all DB2 resources eez-srv-rg IBM.ResourceGroup The resource group that comprises the automation manager and the WebSphere Application Server resources eez-engine-rg IBM.ResourceGroup The resource group that comprises all automation manager resources eez-was-rg IBM.ResourceGroup The resource group that comprises all WebSphere Application Server resources eez-gdpsagent-rg IBM.ResourceGroup The resource group that comprises the gdpsagent resources eez-hwa-rg IBM.ResourceGroup The resource group that comprises the hardware adapter resources eez-hadp-prim-equ IBM.Equivalency The resource controlling the DB2 HADR role eez-startam-equ IBM.Equivalency The resource controlling the System Automation Application Managerstate eez-was-as IBM.Application WebSphereApplication Server eez-engine IBM.Application System Automation Application Manager automation manager eez-db2-rs IBM.Application DB2 server eez-gdpsagent-rs IBM.Application gdpsagent eez-hwa-rs IBM.Application Hardware adapter eez-hadr-prim IBM.Application DB2 HADR role eez-startam IBM.Application System Automation Application Manager state eez-was-as-dependson-db2- rs eez-wasas_startsafter_eezstartam-equ IBM.ManagedRelationship IBM.ManagedRelationship Dependency of WebSphere Application Server on DB2 Dependency of WebSphere Application Server on the System Automation Application Manager state hwa-startsafter-eez-engine IBM.ManagedRelationship Dependency of the hardware adapter on the System Automation Application Manager 174 Tivoli System Automation Application Manager V : Installation and Configuration Guide

193 Table 38. Resources in the high availability policy for a disaster recovery setup (continued) eez-was-as_do_eez-hadrprim-equ eez-engine-startsafterwas-as gdpsagent-dependson-eezengine IBM.ManagedRelationship IBM.ManagedRelationship IBM.ManagedRelationship Dependency of WebSphere Application Server on DB2 HADR role Dependency of the System Automation Application Manageron WebSphere Application Server Dependency of the gdpsagent on the System Automation Application Manager Notes and restrictions When you configure high availability for a disaster recovery setup on two sites, the following notes and restrictions apply: v Do not manually change any of the resources, which are part of the System Automation Application Manager high availability policy by using chrsrc or chrel commands. Using these commands might cause errors in the Define or Remove policy tasks of the configuration dialog. If you must change any policy elements, use the Validate & Store task of the configuration dialog, copy the created policy, and make your changes within the copied policy. You can then activate this changed policy by using the sampolicy command with the update option -u. v Perform the configuration of the high availability policy for a disaster recovery setup also on the other GDPS site. v The high availability policy for a disaster recovery setup is only available on the Linux for System z operating system. v Every first-level automation adapter or remote agentless adapter must be able to switch its event target if the active System Automation Application Manager moves to the other site. In the configurations of all adapters, specify the System Automation Application Manager host names of both sites as the end-to-end automation management host and the alternative end-to-end automation management host. Specify the corresponding values on the Host Using Adapter tab in the configuration dialogs of the respective first-level automation adapter. v Configuration of the local agentless adapter with the high availability policy for a disaster recovery setup is not supported. You must not configure the local agentless adapter. Configuring Distributed Disaster Recovery To configure the Distributed Disaster Recovery feature, you need to configure the JMS destination for Geographically Dispersed Parallel Sysplex (GDPS) events, the hardware adapter, and the TPC-R domain. For more information about how to configure the hardware adapter, see Configuring virtual server & hardware management on page 139. For more information about how to configure TPC-R domains, see Configuring storage replication on page 146. Chapter 3. Configuring 175

194 Configuring the destination for GDPS events Configure a GDPS server connection or backup server connection if it is not already activated or configured during the installation of System Automation Application Manager. Start the configuration utility cfgeezdmn and click Configure on the Application Manager tab of the task launcher window to open the Application Manager common configuration. On the Event Publishing tab, configure the GDPS server location and event port number. Optionally, you can configure also a GDPS backup server and port. After you completed the configuration, restart WebSphere Application Server or refresh the end-to-end automation manager configuration by clicking Refresh on the Application Manager tab of the task launcher window. Configuring the GDPS agent Specify user credentials for the end-to-end automation manager command shell and set up logging and tracing for the GDPS agent. Start the configuration utility cfgeezdmn and click Configure on the Application Manager tab of the task launcher window to open the Application Manager common configuration. On the Command Shell tab, specify a user ID and password, independent from the selected authentication mode. Set up logging and tracing for the GDPS agent: 1. The GDPS agent uses the logger to make entries in the system log. 2. The priority that is used is user.error for error messages and user.debug for debug information. Make sure that these entries are logged at the right place by using the system log configuration syslog.conf or corresponding configuration file. Configuring synchronous communication with GDPS GDPS communicates with the end-to-end automation manager through synchronous calls that are received by the GPDS agent. As soon as commands are passed successfully to the automation engine they are acknowledged by the GPDS agent. To ensure that the communication between GDPS and the GDPS agent is encrypted without needing to configure a password in GDPS, Secure Shell (ssh) is used for secure communication. Ensure that the OpenSSH client is set up correctly in UNIX System Services (USS) of the GDPS K-System: 1. Set up the OpenSSH client configuration file. 2. Set up public key authentication to avoid the specification of a password in GDPS. 176 Tivoli System Automation Application Manager V : Installation and Configuration Guide

195 The host key of the System Automation Application Manager server must be appended to $home/.ssh/known_hosts for the GDPS USS operator (dcmuser2 as defined in GEOPLEX OPTIONS). On the end-to-end server system, the public key of the GDPS USS operator (dcmuser2) must be appended to the file <user>/.ssh/authorized_keys. For more information about how to set up OpenSSH in UNIX System Services, see IBM Ported Tools for z/os. Configuring the PowerHA adapter Configure the adapter for High Availability Cluster Multi-Processing (PowerHA ) to integrate resources that are managed by a PowerHA cluster into the System Automation Application Manager end-to-end automation environment. The following figure shows in which environments the PowerHA adapter works. WebSphere Application Server End-to-end management Event port 2002 Host name or service IP label Request port ip1 EIF 2001 PowerHA adapter RSCT/PowerHA PowerHA cluster nodes Node-1 RSCT/PowerHA Node-2 Figure 16. Configuration of the PowerHA adapter The GUI mode of the adapter configuration utility is an X Window System application and must be used from a workstation with X Window System server capabilities. On systems without X Window System Server capability, you can also configure the adapter in silent mode by using an input properties file. For more information, see Configuring the PowerHA adapter in silent mode on page 185. Chapter 3. Configuring 177

196 Starting the PowerHA adapter configuration dialog Use the cfghacadapter command to start the PowerHA adapter configuration dialog. To use the PowerHA adapter configuration dialog, you must either be logged in on the system with the user ID root or have write access to the directory /etc/opt/ibm/tsamp/eez/hac/cfg. After you entered the cfghacadapter command, the task launcher window of the dialog is displayed: Figure 17. Application Manager Adapter Configuration - Task Launcher for PowerHA You can process the following tasks: v Click Configure to open the configuration dialog for the PowerHA adapter. For more information, see Configuring the PowerHA adapter settings on page 179. v Click Replicate to replicate the PowerHA adapter configuration files to other nodes. For more information, see Replicating the configuration files to other nodes in the domain on page 184. v Click Define to define the PowerHA adapter automation policy to create the resources that are required to automate the adapter. For more information, see Defining the PowerHA adapter automation policy on page 185. v Click Remove to remove the PowerHA adapter automation policy. For more information, see Removing the PowerHA adapter automation policy on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

197 Configuring the PowerHA adapter settings Click Configure on the task launcher window of the configuration dialog to configure the PowerHA adapter settings. In the following description, the term 'Host using the adapter' is used to refer to the end-to-end automation manager host. Adapter tab Use the Adapter tab to configure the parameters of the automation adapter host. Controls and fields on the Adapter tab: Host name or IP address Host name or service IP label of the node where the adapter runs. On initial invocation, the field contains the host name of the system where the configuration utility is running. If you are automating the adapter, leave the value unchanged. The value is updated automatically with the value you specify in the field Service IP label on the Automation tab. For more information, see Automation tab on page 180. Request port number Specify the port number on which the adapter listens for requests from the end-to-end automation management host. The default port is Click Advanced to specify the adapter run time behavior: Adapter stop delay Define the time that is measured in seconds within which the adapter stop is delayed to allow the adapter to properly deliver the domain leave event. The default value is 5. You can increase the value on slow systems. The value ranges between 3 through 60 seconds. Remote contact activity interval Define the time that is measured in seconds after which the adapter stops if it was not contacted by the end-to-end automation management host. The host periodically contacts the adapter to check whether it is still running. The default value is 360. If a value other than 0 is specified, the interval must be a multiple of the check interval. When the value is set to 0, the adapter continuously runs and never stops. Initial contact retry interval Define the time that is measured in minutes, within which the adapter attempts to contact the end-to-end automation management host until it succeeds or the specified time elapsed. The default value is 0, which means that the adapter attempts to contact the end-to-end automation management host indefinitely. Enable EIF event caching Select this check box to activate event caching. EIF reconnect attempt interval Define the time that is measured in seconds, that the adapter waits before it attempts to reestablish the connection to the end-to-end automation management host after the connection was interrupted. The default value is 30 seconds. Chapter 3. Configuring 179

198 Host Using Adapter tab Use the Host Using Adapter tab to configure the end-to-end automation manager host the adapter connects to. Controls and fields on the Host Using Adapter tab: Host name or IP address The name or IP address of the host on which the end-to-end automation manager runs. Alternate host A value for this field is optional. If you configured a disaster recovery setup with two different sites for the System Automation Application Manager, the end-to-end automation manager might run on either site. To support such a setup, also specify the host name or IP address of the second site. If an Application Manager switches the site, then the adapter switches seamlessly to the new active end-to-end automation manager instance as the target for sending events. Event port number The port to which the end-to-end automation manager listens for events from the PowerHA adapter. The port number that is specified must match the port number that is specified as event port number when you configure domain of the end-to-end automation manager. The default port is Note: If the communication between the end-to-end automation adapter and the end-to-end automation management host uses IPv6, then the following restrictions apply. For the communication from the adapter to the host using the adapter: 1. If an IPv6 host name is specified in the configuration of the end-to-end automation management host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the end-to-end automation management host. For the communication from the end-to-end automation management host to the adapter: 1. If an IPv6 host name is specified in the configuration of the adapter host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the adapter host. Use the command host -n -a <ipv6_hostname> to check the DNS look-up records. Automation tab Use the Automation tab to configure the adapter automation policy and to make the end-to-end automation adapter highly available. If the node on which the adapter runs breaks down, the adapter is restarted on another node in the domain. Note: All nodes where the adapter can run must be accessible by using the same user ID and password. 180 Tivoli System Automation Application Manager V : Installation and Configuration Guide

199 Controls and fields and controls on the Automation tab: Automate adapter in first-level automation domain Select this check box if you want to make the adapter highly available in a PowerHA cluster. For more information, see Automating the PowerHA adapter on page 33. Query domain If the configuration dialog runs on a node in the PowerHA cluster, click Query domain to query the current automation policy from the PowerHA cluster. If the automation policy for the adapter is not yet defined but the cluster is up, at least all nodes that are online are shown in the Defined nodes table. This table provides the following information: v Defined node: The list of defined nodes. v Automate on node: Indicates whether the adapter is automated on this node. You can process the following tasks: v Up: Moves the selected node one position up in the node sequence. The position determines the order in which automation selects the node on which the adapter can run. v Down: Moves the selected node one position down in the node sequence. The position determines the order in which automation selects the node on which the adapter can run. v Add: Adds a node for adapter automation. Define the name of the node to be added and determine whether the node is to be added to automation of the adapter. v Remove: Removes the selected node from the list. The adapter must not be started on that node. v Change: Change the node for adapter automation. Change the name of the node and add or remove the node from automation of the adapter. PowerHA root directory Specify the root directory where PowerHA is installed. Automated resources prefix The prefix that is used to compose the names of the resource group, application, and application monitor in the automation policy. The resource names appear in the resource table on the operations console. The prefix can be changed. Use no more than a total of 28 alphanumeric characters and underscores. Do not use a leading numeric character. Reserved words are not allowed. For more information about reserved words, see List of reserved words. If the PowerHA adapter policy is defined by using the current prefix, remove this policy before you change the prefix. For more information about defining the adapter automation policy, see Defining the PowerHA adapter automation policy on page 185. Service IP label The Service IP label is an entry in /etc/hosts that represents a service IP label. It must be different from the host name of any node in the PowerHA cluster. The service IP is requested by the network administrator as a service IP label or alias for all nodes in the PowerHA cluster. The service IP must be created, for example by using the SMIT interface, before you start the configuration dialog. The PowerHA adapter listens on the service IP label for requests from the end-to-end automation management host, regardless on which node it runs. Chapter 3. Configuring 181

200 Security tab Use the Security tab to configure security settings for the interface between the PowerHA adapter and the System Automation Application Manager host. Controls and fields on the Security tab: Secure Sockets Layer (SSL) protocol for data transport: Enable SSL Check to enable the Secure Sockets Layer (SSL) protocol. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. The following entry fields are enabled: Truststore Enter the name of the truststore file that is used for SSL. The file name might contain multiple period characters. Click Browse to select a file. Keystore Enter the name of the keystore file that is used for SSL. The file name might contain multiple period characters. Click Browse to select a file. Keystore password Enter the password of the keystore file. The password is required if a keystore file was specified. Click Change to change the password. Note: Passwords must be identical if truststore and keystore are in two different files. Certificate alias Enter the alias name of the certificate to be used by the server. If not specified, the keystore file must contain only one entry, which is the one to be used. User authentication with Pluggable Access Module (PAM): Enforce user authentication Check to enable user authentication with Pluggable Access Module (PAM). If not checked, user authentication is bypassed. If checked, user authentication is enforced for the user ID on behalf of which the end-to-end automation management host requests operations from the PowerHA adapter. PAM service Specify an entry in the PAM service file /etc/pam.conf. This file determines which checks are made to authenticate the user. The default value is su, which checks users as if they were trying to run the command su. Logger tab Use the Logger tab to configure the settings for logging, tracing, and First Failure Data Capture. You can change the settings permanently or temporarily. Note: The Logger tab always displays the values that are currently set in the configuration file. On the Logger tab, you can perform the following tasks: Change the settings permanently Perform these steps: 1. Make the required changes on the tab. 182 Tivoli System Automation Application Manager V : Installation and Configuration Guide

201 2. Click Save. Results: The settings in the configuration file are updated. You must restart the adapter for the changes to take effect. Change the settings temporarily Perform these steps: 1. Make the required changes on the tab. 2. Click Apply. Results: The new settings take effect immediately. They are not stored in the configuration file. If the adapter is not running, you receive an error message. Revert to the permanent settings If you changed the settings temporarily, perform the following steps to revert to the permanent settings defined in the configuration file, or when you are unsure which settings are currently active for the adapter: 1. Invoke the configuration dialog and open the Logger tab. The Logger tab displays the values that are currently set in the configuration file. 2. Click Apply to activate the settings. Results: The settings take effect immediately. If the adapter is not running, you receive an error message. Controls and fields on the Logger tab: Maximum log/trace file size The maximum disk usage in KB that a log file can reach. If the limit is reached, another log file is created. The maximum number of log files is two, which means that the least recent file gets overwritten after both files are filled up. The default maximum file size is 1024 KB. Message logging level Select the Message logging level, depending on the severity of messages that you want to be logged. Trace logging level Select the Trace logging level, depending on the severity of the incidents that you want to be logged. First failure data capture (FFDC) recording level Select the FFDC recording level, depending on the severity of the incidents for which you want FFDC data to be collected. First failure data capture (FFDC) maximum disk space Specify the maximum disk space in bytes used by FFDC traces, which are written to the FFDC trace directory. The default space is bytes (10 MB). First failure data capture (FFDC) space exceeded policy Select one of the options: Ignore Issue a warning, but do not enforce the FFDC disk space limitation. Auto-delete Automatically delete FFDC files to enforce the FFDC disk space limitation. This is the default value of the space exceeded policy. Suspend Halt further FFDC actions until disk space is freed manually. Chapter 3. Configuring 183

202 First failure data capture (FFDC) message ID filter mode Select one of the options: Passthru All log events with messages that are specified in the message ID list will pass the filter and FFDC data is written. This is the default filter mode. Block All log events with messages that are specified in the message ID list are blocked. First failure data capture (FFDC) message ID list The message IDs that control for which log events FFDC data is written, depending on the filter mode. The comparison of message IDs is case-sensitive. Each message ID must occur in a new line. Wildcard characters, for example, *E (for all error messages), are allowed. Saving the PowerHA adapter configuration To save your changes to the adapter configuration files, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. Note: 1. If you edit the Automation tab, a message appears reminding you to start the Define automation policy task. 2. If not noted otherwise, restart the adapter for the changes to become effective. Replicating the configuration files to other nodes in the domain If your PowerHA adapter is highly available, replicate the configuration files to the other cluster nodes. Start the adapter configuration dialog and click Replicate. Use the Replication Configuration Files window to distribute the PowerHA adapter configuration files to the remaining nodes in the PowerHA cluster: 1. Select the configuration files that you want to replicate or click Select all to select all configuration files in the list. 2. If the user ID and password you specified are valid on all nodes, you can click Select all below the list of replication target nodes. Otherwise, process the replication separately for each target node. 3. Enter the user ID and password for the target nodes you want to replicate the files to. 4. Start the replication by clicking Replicate. Replication can take a while. While the files are being replicated, the Replicate button is indented and grayed-out. When the replication is complete, the replication status of each configuration file is displayed. 184 Tivoli System Automation Application Manager V : Installation and Configuration Guide

203 Defining the PowerHA adapter automation policy Use the Define task to activate the configured adapter automation policy. After the automation of the PowerHA adapter is defined, click Define on the main window of the configuration dialog. Resources with the resource name Resource-/group prefix are created as described in Automated resources prefix on page 181. If automated resources with the same name exist, they are removed before the new resources are created. If you used the default resource name prefix, the following resources are defined: Table 39. Resources in the PowerHA adapter automation policy Resource class Resource name Description IBM.HacmpResourceGroup hacadapter_rg The resource group that comprises all automated resources. IBM.HacmpApplication hacadapter Commands: hacadapter start, hacadapter stop IBM.HacmpAppMonitor hacadapter_mon Command: hacadapter status IBM.HacmpServiceIP <service_ip_label> value The label of the service IP on which the host using the adapter accesses the adapter. This value is not defined but queried and, therefore, not removed. When you click Define, the button can stay indented for minutes until the resources are removed. The cluster is synchronized, new resources are created, and the cluster is synchronized again. When processing is complete, the results of the commands are displayed in a pop-up window. Removing the PowerHA adapter automation policy Use the Remove task to deactivate the configured adapter automation policy if the policy is active. Use the Remove function before you change the name prefix of the automated resources. For more information, see Automated resources prefix on page 181. When the adapter is automated and you clear the check box Automate adapter in system automation domain on the Automation tab, you receive a message that reminds you to remove the automated resources for the adapter. Clicking Remove on the main window of the configuration dialog removes the resources that are shown in Table 39. If the PowerHA adapter is still running, it is stopped before the automated resources are removed. When you click Remove, the button can stay indented for minutes until resources are removed and the cluster is synchronized. Eventually, the results of the commands are displayed in a pop-up window. Configuring the PowerHA adapter in silent mode Configure the PowerHA adapter in silent mode as an alternative to the configuration dialogs. Chapter 3. Configuring 185

204 You can use the silent mode to configure the PowerHA adapter. For a detailed description of the silent mode configuration tasks, see Configuring in silent mode on page 203. The following configuration tasks can be processed only by using the configuration dialogs or manually: v Replicating the PowerHA adapter configuration files v Defining and removing the PowerHA adapter automation policy If you do not want to use the configuration dialogs, see Processing tasks manually on page 204 for a detailed description of the tasks you can process manually. Controlling the PowerHA adapter Use the hacadapter command to start, stop, and monitor the adapter. Configuring the FOC adapter For a description of the hacadapter command options, see System Automation Application Manager Reference and Problem Determination Guide. Configure the adapter for Microsoft Failover Cluster (FOC). Configure the FOC adapter to integrate resources that are managed by a Microsoft Failover Cluster into the System Automation Application Manager end-to-end automation environment. You can also configure the adapter in silent mode by using an input properties file. For more information, see Configuring the FOC adapter in silent mode on page 192. Starting the FOC adapter configuration dialog Use the cfgmscsadapter command to invoke the FOC adapter configuration dialog. Note: The configuration dialog must be started with administrator privileges. Otherwise, the configuration program is unable to write changed configuration files to the right location. Use the following procedure to obtain a command line with administrator privileges, which can be used to run the configuration dialog: 1. Log on with the domain user account prepared in Preparing the user account on page In the Windows Start menu, select All Programs > Accessories. 3. Right-click the entry that is named Command Prompt. 4. In the menu of the command line, select the entry Run as administrator. After you entered the cfgmscsadapter command, the task launcher window of the dialog is displayed: 186 Tivoli System Automation Application Manager V : Installation and Configuration Guide

205 Figure 18. Main window of the FOC Automation Adapter Configuration dialog Click Configure to open a configuration dialog. For more information, see Configuring the FOC adapter settings. Click Replicate to replicate the configuration files to the other nodes. For more information, see Replicating the configuration files to other nodes in the domain on page 192. Configuring the FOC adapter settings Click Configure on the task launcher window of the configuration dialog to configure the FOC adapter settings. In the following description, the term 'Host using the adapter' is used to refer to the end-to-end automation manager host. Adapter tab Use the Adapter tab to configure the parameters of the host system on which the adapter is running and the parameters that are required for the automation domain. Controls and fields on the Adapter tab: Automation adapter host Host name or IP address v If the FOC adapter is highly available, specify the network name or IP address you obtained as described in Planning and preparing for an highly available FOC adapter on page 37. v If the FOC adapter is not highly available, specify the IP address or host name of the system on which the adapter is running. On initial invocation, the field contains the host name of the system where the configuration utility is running. Request port number Specify the number of the port on which the adapter listens for requests from the end-to-end automation management host. The default port is Automation domain Chapter 3. Configuring 187

206 The domain name is the name by which the FOC cluster is known to the end-to-end automation management host. The domain name must be unique within the scope of automation domains that connect to an end-to-end automation manager or a System Automation operations console. You have the following options to specify the domain name: v You can use the FOC cluster name as domain name. This option is selected by default. Keep this setting if you want to use Tivoli Enterprise Portal launch-in-context support. Open the Tivoli Enterprise Portal workspaces from the System Automation operations console, because Tivoli Enterprise Portal does not recognize any other domain name. v If you cannot use the FOC cluster name as domain name, for example, because it would not be unique, you can specify a domain name for the FOC cluster. Click Advanced to specify the adapter run time behavior: Adapter stop delay Define the time period that is measured in seconds within which the adapter stop is delayed to allow the adapter to properly deliver the domain leave event. The default value is 5. You can increase the value on slow systems. The value ranges between 3 through 60 seconds. Remote contact activity interval Define the time period that is measured in seconds after which the adapter stops if it was not contacted by the end-to-end automation management host. The automation management host, periodically contacts the adapter to check whether it is still running. The default value is 360. If a value other than 0 is specified, the interval must be a multiple of the check interval. When the value is set to 0, the adapter continuously runs and never stops. Initial contact retry interval Define the time period that is measured in minutes, within which the adapter attempts to contact the end-to-end automation management host until it succeeds or the specified time elapsed. The default value is 0, which means that the adapter attempts to contact the end-to-end automation management host indefinitely. Enable EIF event caching Select this check box to activate event caching. EIF reconnect attempt interval Define the time that is measured in seconds that the adapter waits before it reestablishes the connection to the end-to-end automation management host after the connection was interrupted. The default value is 30 seconds. Host Using Adapter tab Use the Host Using Adapter tab to configure the end-to-end automation manager host the adapter connects to. Fields on the Host using adapter tab: Host name or IP address The name or IP address of the host on which the end-to-end automation manager runs. Alternate host A value for this field is optional. If you configured a disaster recovery setup with two different sites for the System Automation Application 188 Tivoli System Automation Application Manager V : Installation and Configuration Guide

207 Manager, the end-to-end automation manager can run on either site. To support such a setup, also specify the host name or IP address of the second site. An Application Manager site switch ensures that the adapter switches to the new active end-to-end automation manager instance as the target for sending events. Event port number The port on which the end-to-end automation manager listens for events from the FOC adapter. The port number that is specified here must match the port number that is specified as event port number when you configure the domain of the end-to-end automation manager. The default port is Note: If the communication between the end-to-end automation adapter and the end-to-end automation management host uses an IPv6 IP version, then the following restrictions apply. For the communication from the adapter to the host using the adapter: 1. If an IPv6 host name is specified in the configuration of the end-to-end automation management host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the end-to-end automation management host. For the communication from the end-to-end automation management host to the adapter: 1. If an IPv6 host name is specified in the configuration of the adapter host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the adapter host. Use the command nslookup <host name> [<dns server>] to check the DNS lookup records. Security tab Use the Security tab to configure security settings for the interface between the FOC adapter and the System Automation Application Manager host. Controls and fields on the Security tab: Secure Sockets Layer (SSL) protocol for data transport: Enable SSL Check to enable the Secure Sockets Layer (SSL) protocol. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. The following entry fields are enabled. Truststore Enter the name of the truststore file that is used for SSL. The file name can contain multiple period characters. Click Browse to select a file. Chapter 3. Configuring 189

208 Keystore Enter the name of the keystore file that is used for SSL. The file name can contain multiple period characters. Click Browse to select a file. Keystore password Enter the password of the keystore file. It is required if a keystore file was specified. Click Change to change the password. Note: If the truststore is in different file than keystore, the passwords for the files must be identical. Keystore alias Enter the alias name of the certificate to be used by the server. If not specified, the keystore file must contain only one entry, which is the one to be used. User authentication Check to enforce authentication of the user ID on behalf of which the end-to-end automation management host requests operations from the FOC adapter. Logger tab Use the Logger tab to configure the settings for logging, tracing, and First Failure Data Capture. You can change the settings permanently or temporarily. Note: The Logger tab always displays the values that are currently set in the configuration file. On the Logger tab, you can process the following tasks: Change the settings permanently Perform these steps: 1. Make the required changes on the tab. 2. Click Save. Results: The settings in the configuration file are updated. Restart the adapter for the changes to take effect. Change the settings temporarily Perform these steps after you ensured that the adapter is running: 1. Make the required changes on the tab. 2. Click Apply. Results: The new settings take effect immediately. They are not stored in the configuration file. If the adapter was not running, you receive an error message. Revert to the permanent settings If you changed the settings temporarily, process the following steps to revert to the permanent settings defined in the configuration file. If you are unsure which settings are currently active for the adapter, proceed as follows: 1. Start the configuration dialog and open the Logger tab. The Logger tab displays the values that are currently set in the configuration file. 2. Click Apply to activate the settings. Results: The settings take effect immediately. If the adapter is not running, you receive an error message. 190 Tivoli System Automation Application Manager V : Installation and Configuration Guide

209 Controls and fields on the Logger tab: Maximum log/trace file size The maximum disk usage in KB that a log file can reach. If the limit is reached, another log file is created. The maximum number of log files is two, which means that the least recent file gets overwritten after both files are filled up. The default maximum file size is 1024 KB. Message logging level Select the Message logging level, depending on the severity of messages that you want to be logged. Trace logging level Select the Trace logging level, depending on the severity of the incidents that you want to be logged. First failure data capture (FFDC) recording level Select the FFDC recording level, depending on the severity of the incidents for which you want FFDC data to be collected. First failure data capture (FFDC) maximum disk space Specify the maximum disk space in bytes used by FFDC traces, which are written to the FFDC trace directory. The default space is bytes (10 MB). First failure data capture (FFDC) space exceeded policy Select one of the options: Ignore Issue a warning, but do not enforce the FFDC disk space limitation. Auto-delete Automatically delete FFDC files to enforce the FFDC disk space limitation. This is the default value of the space exceeded policy. Suspend Halt further FFDC actions until disk space is freed manually. First failure data capture (FFDC) message ID filter mode Select one of the options: Passthru All log events with messages that are specified in the message ID list will pass the filter and FFDC data is written. This is the default filter mode. Block All log events with messages that are specified in the message ID list are blocked. First failure data capture (FFDC) message ID list The message IDs that control for which log events FFDC data is written, depending on the filter mode. The comparison of message IDs is case-sensitive. Each message ID must occur in a new line. Wildcard characters, for example, *E for all error messages, are allowed. Saving the FOC adapter configuration To save your changes to the adapter configuration files, click Save. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. Chapter 3. Configuring 191

210 Note: If not noted otherwise, you must restart the adapter for the changes to become effective. Replicating the configuration files to other nodes in the domain If your FOC adapter is highly available, you must replicate the configuration files to the other cluster nodes. Start the adapter configuration dialog and click Replicate. Use the Replicate Configuration Files window to distribute the FOC adapter configuration files to the remaining other nodes in the FOC cluster: 1. Select the configuration files that you want to replicate, or click Select all below the configuration file list to select all files in the list. 2. If the user ID and password you specified are valid on all nodes, you can click Select all below the list of replication target nodes. Otherwise, process the replication separately for each target node. 3. Enter a local or domain user ID and password for the target nodes that you want to replicate the files to. Domain user IDs must be specified in the form <user_id>@<domain_name>. 4. Click Replicate to start the replication. Replication can take a while. While the files are being replicated, the Replicate button is indented and grayed-out. When the replication is complete, the replication status of each configuration file is displayed. Configuring the FOC adapter in silent mode You can configure the FOC adapter in silent mode as an alternative to using the configuration dialogs. You can use the silent mode to configure the FOC adapter. For a detailed description of the silent mode configuration tasks, see Configuring in silent mode on page 203. If you are using the configuration dialogs or if you configure manually, you can replicate the FOC adapter configuration files. If you do not want to use the configuration dialogs, see Processing tasks manually on page 204 for a detailed description of the tasks you can process manually. Providing high availability for the FOC adapter To provide high availability for the Microsoft Failover Cluster (FOC) adapter, proceed as follows: 1. Open the Microsoft Failover Cluster Management console. In the tree view, select the failover cluster for which you want to configure high availability of the FOC adapter. Click Actions > Configure a Service or Application... The 192 Tivoli System Automation Application Manager V : Installation and Configuration Guide

211 Configuring the VCS adapter High Availability Wizard opens. Depending on your system's settings, the Before You Begin window can be displayed. If so click Next. 2. In the Select Service or Application window, select the Generic Service resource type and click Next. 3. On the Select Service window, select the SA AM MSCS Adapter service from the list of installed services. The FOC adapter must be installed successfully on all failover cluster nodes before. Click Next. 4. On the Client Access Point window, specify a valid new network name under which the FOC adapter is reachable. It must be ensured that the automation manager to which the FOC adapter connects is able to resolve this network name. If you do not want to use a network name for the FOC adapter, specify a dummy name here and remove it later. Specify a valid IP address on which the FOC adapter can be reached. You must ensure that the automation manager to which the FOC adapter connects is able to reach this virtual IP address. Use the network name or IP address you obtained as described in Planning and preparing for an highly available FOC adapter on page 37. Click Next. 5. On the Select Storage window do not select any storage volumes, as the FOC adapter does not require any. Click Next. 6. On the Replicate Registry Settings window do not specify any registry keys, as the FOC adapter does not require any. Click Next. 7. On the Confirmation window, check that all settings are correct. If so click Next. If not click Previous to correct the settings. 8. On the Summary window, click Finish. Configure the adapter for Veritas Cluster Server (VCS) for Solaris. Configure the VCS adapter to integrate resources that are managed by a VCS cluster on Solaris into the System Automation Application Manager end-to-end automation environment. The following figure shows the environment in which the VCS adapter works. Chapter 3. Configuring 193

212 WebSphere Application Server End-to-end management Event port 2002 Host name or service IP label Request port Ip EIF SSL 2001 VCS adapter VERITAS Cluster Server VCS cluster nodes Node-1 VERITAS Cluster Server Figure 19. Configuration of the VCS adapter The GUI mode of the adapter configuration utility is an X Window System server application and must be used from a workstation with X Window System server capabilities. On systems without X Window System server capability, you can also configure the adapter in silent mode by using an input properties file. For more information, see Configuring the VCS adapter in silent mode on page 203. Starting the VCS adapter configuration dialog Use the cfgvcsadapter command to start the VCS adapter configuration dialog. Node-2 To use the VCS adapter configuration dialog, you must either be logged in on the system with the user ID root or have write access to the directory /etc/opt/ibm/tsamp/eez/vcs/cfg. After you entered the r command, the task launcher window of the dialog is displayed: 194 Tivoli System Automation Application Manager V : Installation and Configuration Guide

213 Figure 20. VCS Automation Adapter Configuration dialog Click Configure to open the configuration dialog. For more information, see Configuring the VCS adapter settings Click Replicate to replicate the configuration files to other nodes. For more information, see Replicating the configuration files to other nodes in the domain on page 201 Click Define to define the VCS adapter automation policy. This automation policy creates the resources to automate the adapter. For more information, see Defining the VCS adapter automation policy on page 202 Click Remove to remove the VCS adapter automation policy. For more information, see Removing the VCS adapter automation policy on page 202 Configuring the VCS adapter settings Click Configure on the task launcher window of the configuration dialog to configure the VCS adapter settings. In the following description, the term Host using the adapter is used to refer to an end-to-end automation manager host. Adapter tab Use the Adapter tab to configure the parameters of the host system on which the adapter is running and the parameters that are required for the automation domain. Controls and field on the Adapter tab: Automation adapter host: Chapter 3. Configuring 195

214 Host name or IP address Host name or service IP label of the node where the adapter runs. On initial invocation, the field contains the host name of the system where the configuration utility is running. If you are automating the adapter, leave the value unchanged. The value is updated automatically with the value you specify in the field Adapter IP address on the Automation tab (see Automation tab on page 198). Request port number Specify the port number on which the adapter listens for requests from the end-to-end automation management host. The default port is Automation domain: The domain name is the name by which the VCS cluster is known to the end-to-end automation management host. The domain name must be unique within the scope of automation domains that connect to the end-to-end automation manager. You have the following options to specify the domain name: Use the VCS cluster name You can use the VCS cluster name as the domain name. This option is selected by default. Keep this setting if you want to use Tivoli Enterprise Portal launch-in-context support. You can open Tivoli Enterprise Portal workspaces from the System Automation operations console, because Tivoli Enterprise Portal does not recognize any other domain name. Specify a domain name If you cannot use the VCS cluster name as a domain name, for example, because it would not be unique, you can specify a domain name for the VCS cluster. Click Advanced. A dialog opens to specify the adapter runtime behavior: Adapter stop delay Define the time that is measured in seconds within which the adapter stop is delayed to allow the adapter to properly deliver the domain leave event. The default value is 5. You can increase the value on slow systems. The value ranges between 3 through 60 seconds. Remote contact activity interval Define the time that is measured in seconds after which the adapter stops if it was not contacted by the end-to-end automation management host. The management host periodically contacts the adapter to check whether it is still running. The default value is 360. If a value other than 0 is specified, the interval must be a multiple of the check interval. When the value is set to 0, the adapter continuously runs and never stops. Initial contact retry interval Define the time that is measured in minutes, within which the adapter attempts to contact the end-to-end automation management host until it succeeds or the specified time elapsed. The default value is 0, which means that the adapter attempts to contact the end-to-end automation management host indefinitely. Enable EIF event caching Select this check box to activate event caching. 196 Tivoli System Automation Application Manager V : Installation and Configuration Guide

215 EIF reconnect attempt interval Define the time that is measured in seconds, that the adapter waits before it attempts to reestablish the connection to the end-to-end automation management host after the connection is interrupted. The default value is 30 seconds. Host Using Adapter tab Use the Host Using Adapter tab to configure the end-to-end automation manager host the adapter connects to. Fields on the Host using adapter tab: Host name or IP address The name or IP address of the host on which the end-to-end automation manager runs. Alternate host A value for this field is optional. If you configure a disaster recovery setup with two different sites for the System Automation Application Manager, the end-to-end automation manager can run on either site. To support such a setup, also specify the host name or IP address of the second site. An Application Manager site switch ensures that the adapter switches seamlessly to the new active end-to-end automation manager instance as the target for sending events. Event port number The port on which the end-to-end automation manager listens for events from the VCS adapter. The port number that is specified here must match the port number that is specified as event port number when you configure the domain of the end-to-end automation manager. The default port is Note: If the communication between the end-to-end automation adapter and the end-to-end automation management host uses an IPv6 IP version, then the following restrictions apply. For the communication from the adapter to the host using the adapter: 1. If an IPv6 host name is specified in the configuration of the end-to-end automation management host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the end-to-end automation management host. For the communication from the end-to-end automation management host to the adapter: 1. If an IPv6 host name is specified in the configuration of the adapter host, the DNS server must be configured to return IPv6 records only. 2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4 address is used. In case you want to use IPv6, explicitly specify the IPv6 address instead of the host name in the configuration of the adapter host. Use the command nslookup <host name> [<dns server>] to check the DNS lookup records. Chapter 3. Configuring 197

216 Automation tab Use the Automation tab to configure the adapter automation policy to make the end-to-end automation adapter highly available. If the node on which the adapter runs breaks down, the adapter is restarted on another node in the domain. Note: All nodes where the adapter can run must be accessible by using the same user ID and password. Controls and fields on the Automation tab: Automate adapter in first-level automation domain Select this check box if you want to make the adapter highly available in a VCS cluster. For more information, see Automating the VCS adapter on page 40. Query domain If the configuration dialog runs on a node in the VCS cluster, click Query domain to query the current automation policy from the VCS cluster. If the automation policy for the adapter is not yet defined but the cluster is up, at least all nodes that are online are shown in the Defined nodes table. This table provides the following information: Defined node The list of defined nodes. Automate on node Indicates whether the adapter is automated on this node. You can find the following controls at the bottom of the table: Up Down Add Moves the selected node one position up in the node sequence. The position determines the order in which automation selects the node on which the adapter can run. Moves the selected node one position down in the node sequence. The position determines the order in which automation selects the node on which the adapter can run. Displays the Add node for adapter automation window to define the name of the node to be added. Determine whether the node is to be added to the automation of the adapter. Remove Removes the selected node from the list. The adapter must not be started on that node. Change Displays the Change node for adapter automation window to change the name of the node. Add or remove the node from the automation of the adapter. Automated resources prefix The prefix that is used to compose the names of the resource group, application, and application monitor in the automation policy. The resource name appears in the resource table on the operations console. The prefix can be changed. It is restricted to ASCII characters; the following characters cannot be used: " (double quotation mark), (single quotation mark), ; (semicolon), $ (dollar), / (slash). If the VCS adapter policy is defined by using the current prefix, remove this policy before you change the prefix. For more information about defining the adapter automation policy, see Defining the VCS adapter automation policy on page Tivoli System Automation Application Manager V : Installation and Configuration Guide

217 Adapter IP address Regardless on which node it runs, the end-to-end automation adapter uses this address to listen for requests and receive requests from the end-to-end automation management host. You must obtain this IP address from your network administrator. The IP address must not be an actual host address or localhost. Netmask The netmask that is used in the adapter automation policy. Request a value from your network administrator. Network interface The network interface that is used in the adapter automation policy. The adapter can be reached on this network interface through the specified IP address. Click Query to display the Select network interface dialog to select one of the network interfaces that are currently defined on the node where the configuration dialog runs. Security tab Use the Security tab to configure the security settings for the interface between the VCS adapter and the System Automation Application Manager host. Controls and fields on the Security tab: Enable SSL Check to enable the Secure Sockets Layer (SSL) protocol. For more information, see Securing the connection to end-to-end adapters using SSL on page 300. This enables the following entry fields. Truststore Enter the name of the truststore file used for SSL. The file name may contain multiple period characters. Click Browse to select a file. Keystore Enter the name of the keystore file used for SSL. The file name may contain multiple period characters. Click Browse to select a file. Keystore password Enter the password for the keystore file. The password is required if a keystore file was specified. Click Change to change the password. Note: Passwords must be identical if truststore and keystore are located in two different files. Certificate alias Enter the alias name of the certificate that is used by the server. If not specified, the keystore file must contain only one entry which is the one to be used. User authentication with Pluggable Access Module (PAM): Enforce user authentication Click to enable user authentication with Pluggable Access Module (PAM). If not checked, user authentication is bypassed. If checked, user authentication is enforced for the user ID on behalf of which the end-to-end automation management host requests operations from the VCS adapter. Chapter 3. Configuring 199

218 PAM service Specify an entry in the PAM service file /etc/pam.conf. This file determines which checks are made to perform user authentication. The default value is su, which checks users as if they were trying to execute the command su. Logger tab Use the Logger tab to configure the settings for logging, tracing, and First Failure Data Capture. You can change the settings permanently or temporarily. Note: The Logger tab always displays the values that are currently set in the configuration file. On the Logger tab, process the following tasks: Change the settings permanently 1. Enter the required changes. 2. Click Save. Results: The settings in the configuration file are updated. Restart the adapter for the changes to take effect. Change the settings temporarily Perform these steps: 1. Make the required changes on the tab. 2. Click Apply. Results: The new settings take effect immediately. They are not stored in the configuration file. If the adapter is not running, you receive an error message. Revert to the permanent settings If you changed the settings temporarily. Process the following steps to revert to the permanent settings defined in the configuration file, or when you are unsure which settings are currently active for the adapter: 1. Start the configuration dialog and open the Logger tab. The Logger tab displays the values that are currently set in the configuration file. 2. Click Apply to activate the settings. Results: The settings take effect immediately. If the adapter is not running, you receive an error message. Controls and fields on the Logger tab: Maximum log/trace file size The maximum disk usage in KB that a log file can reach. If the limit is reached, another log file is created. The maximum number of log files is two, which means that the least recent file gets overwritten after both files are filled up. The default maximum file size is 1024 KB. Message logging level Select the Message logging level, depending on the severity of messages that you want to be logged. Trace logging level Select the Trace logging level, depending on the severity of the incidents that you want to be logged. 200 Tivoli System Automation Application Manager V : Installation and Configuration Guide

219 First failure data capture (FFDC) recording level Select the FFDC recording level, depending on the severity of the incidents for which you want FFDC data to be collected. First failure data capture (FFDC) maximum disk space Specify the maximum disk space in bytes used by FFDC traces, which are written to the FFDC trace directory. The default space is bytes (10 MB). First failure data capture (FFDC) space exceeded policy Select one of the options: Ignore Issue a warning, but do not enforce the FFDC disk space limitation. Auto-delete Automatically delete FFDC files to enforce the FFDC disk space limitation. This is the default value of the space exceeded policy. Suspend Halt further FFDC actions until disk space is freed manually. First failure data capture (FFDC) message ID filter mode Select one of the options: Passthru All log events with messages that are specified in the message ID list will pass the filter and FFDC data is written. This is the default filter mode. Block All log events with messages that are specified in the message ID list are blocked. First failure data capture (FFDC) message ID list The message IDs that control for which log events FFDC data is written, depending on the filter mode. The comparison of message IDs is case-sensitive. Each message ID must occur in a new line. Wildcard characters, for example, *E for all error messages, are allowed. Saving the VCS adapter configuration To save your changes to the adapter configuration files, click Save on the configuration dialog. Upon completion, a configuration update status window is displayed, showing which configuration files were updated. If errors occurred during the update, the corresponding error messages are also displayed. Note: 1. If you edited the Automation tab, a message appears reminding you to start the Define automation policy task. 2. If not noted otherwise, restart the adapter for the changes to become effective. Replicating the configuration files to other nodes in the domain If your VCS adapter is highly available, replicate the configuration files to the other cluster nodes. Chapter 3. Configuring 201

220 Start the adapter configuration dialog and click Replicate. Use the Replicate Configuration Files window to distribute (replicate) the VCS adapter configuration files to the remaining nodes in the VCS cluster: 1. Select the configuration files that you want to replicate or click Select all to select all configuration files in the list. 2. If the user ID and password you specified are valid on all nodes, you can click Select all below the list of replication target nodes. Otherwise, replicate separately for each target node. 3. Enter the user ID and password for the target nodes you want to replicate the files to. 4. Start the replication by clicking Replicate. Replication can take a while. While the files are being replicated, the Replicate button is indented and grayed-out. When the replication is complete, the replication status of each configuration file is displayed. Defining the VCS adapter automation policy Use the Define task to activate the configured adapter automation policy. If definitions for the automation of the VCS adapter are made, click Define on the task launcher window of the configuration dialog. On this dialog window, you can create the resources with the resource name Resource-/group prefix as described in Automated resources prefix on page 198. If automated resources with the same name exist, they are removed before the new resources are created. If you used the default resource name prefix, the following resources are defined: Table 40. Resources in the VCS adapter automation policy Resource class Resource name Description IBM.VCS.ResourceGroup vcsadapter-rg The resource group that comprises all automated resources. Application vcsadapter-rs Commands: vcsadapter start, vcsadapter stop IP vcsadapter-ip The virtual IP address on which the host by using the adapter accesses the adapter. When you click Define, the button can stay indented for minutes until the resources are removed. The cluster is synchronized, new resources are created, and then the cluster is synchronized again. When processing is complete, the results of the commands are displayed in a pop-up window. Removing the VCS adapter automation policy Use the Remove task to deactivate the configured adapter automation policy if it is active. 202 Tivoli System Automation Application Manager V : Installation and Configuration Guide

221 Use the Remove function before you change the name prefix of the automated resources. For more information, see Automated resources prefix on page 198. When the adapter is automated and you clear the check box Automate adapter in system automation domain on the Automation tab, you receive a message to remind you to remove the automated resources for the adapter. Click Remove on the task launcher window of the configuration dialog removes the resources that are shown in Table 40 on page 202. If the VCS adapter is still running, it is stopped before the automated resources are removed. When you click Remove, the button can stay indented for minutes until resources are removed and the cluster is synchronized. The results of the commands are displayed in a pop-up window. Configuring the VCS adapter in silent mode You can configure the VCS adapter in silent mode as an alternative to use the configuration dialogs. You can use the silent mode to configure the VCS adapter. For a detailed description of the silent mode configuration tasks, see Configuring in silent mode The following configuration tasks can be processed only by using the configuration dialogs or manually: v Replicate the VCS adapter configuration files. v Define and remove the VCS adapter automation policy. For a detailed description of the tasks that you can process manually, see Processing tasks manually on page 204. Controlling the VCS adapter Configuring in silent mode Use the vcsadapter command to start, stop, and monitor the adapter. For a description of the vcsadapter command options, see System Automation Application Manager Reference and Problem Determination Guide. Configure System Automation Application Manager and the end-to-end automation adapters without starting the configuration dialogs by using the configuration tool in silent mode. If you use the silent configuration mode, you do not need to have an X Window session available. You can use the configuration tool in silent mode to configure the following components: v System Automation Application Manager, including agentless adapter, high availability, and distributed disaster recovery configuration. v The PowerHA end-to-end automation adapter. Chapter 3. Configuring 203

222 v The FOC end-to-end automation adapter. v The VCS end-to-end automation adapter. You configure these components by editing configuration parameter values in an associated properties file. The parameter values in each properties file correspond directly to the values that you enter in the configuration dialog. You must first start the configuration tool to generate silent mode input properties files before you process a configuration update. Working in silent mode This topic describes the major tasks that you must process when you work in silent configuration mode. To use the configuration tool in silent mode, you need to follow these steps for each component that you want to configure: 1. Generate or locate the silent mode input properties file, see Silent mode input properties file on page Edit the parameter values in the file, see Editing the input properties file on page Start the configuration tool in silent mode to update the target configuration files, see Starting silent configuration on page If the configuration tool does not complete successfully, deal with any errors that are reported (see Output in silent mode on page 209) and start the configuration tool again. For some tasks, no silent configuration support is available. If you do not want to use the configuration dialogs, you must process these tasks manually. For more information, see Processing tasks manually. Processing tasks manually For some tasks, no silent configuration support is available. If you do not want to use the configuration dialogs, you must process these tasks manually. After configuration completed successfully, you might need to manually process some tasks that are started in dialog mode. If you configured high availability for System Automation Application Manager, you might need to manually process the following tasks: 1. Replicate the configuration files. Replicate the configuration files to the other nodes in the System Automation for Multiplatforms cluster whenever you changed the configuration of one of the System Automation Application Manager components. Run the configuration tool in silent mode with identical input properties files on each system. 2. Some of the tasks that are described in High availability for System Automation Application Manager on page 150. You can also use scripts that are available to process these tasks. v Set up the domain. 204 Tivoli System Automation Application Manager V : Installation and Configuration Guide

223 v v v v a. Enter the preprpnode command on all nodes that you specified when you configured the System Automation Application Manager high availability. Do not enter preprpnode command on the node where you ran the configuration tool in silent mode. b. Start the script eezha -createdomain <EEZ_CONFIG_ROOT>/ eezautomate.properties on the local node to process all remaining actions to set up the cluster. Remove the domain. Start the script eezha -deletedomain <EEZ_CONFIG_ROOT>/ eezautomate.properties to remove the System Automation for Multiplatforms cluster that is used to make System Automation Application Manager highly available. Validate and store the automation policy for System Automation Application Manager. Start the script eezha -V -checkpolicy <EEZ_CONFIG_ROOT>/ eezautomate.properties to validate the System Automation Application Manager automation policy as you configured it. Define a configured automation policy. Start the script eezha -activatepolicy <EEZ_CONFIG_ROOT>/eezautomate.properties to define the resources of the System Automation Application Manager automation policy. Make sure that you use the values that you specified when you configured System Automation Application Manager high availability. Remove a configured automation policy. Start the script eezha -deactivatepolicy <EEZ_CONFIG_ROOT>/eezautomate.properties to remove the resources of the System Automation Application Manager automation policy. Make sure that you use the values that you specified when you configured System Automation Application Manager high availability. If one of the end-to-end automation adapters is highly available in an PowerHA, FOC, or VCS cluster, you might need to replicate the corresponding adapter configuration files to the other nodes in the cluster. Run the configuration tool in silent mode for the respective adapter with identical input properties files on each node of the cluster. If one of the end-to-end automation adapters is highly available in an PowerHA or VCS cluster, you might need to manually process one of the following tasks: 1. Define the automation policy. Start the PowerHA adapter script mkhacadapter -p and the VCS adapter script mkvcsadapter -p to define the resources according to the values that are configured in the adapter automation policy. 2. Remove the automation policy. Start the PowerHA adapter script mkhacadapter -r and the VCS adapter script mkvcsadapter -r to remove the resources that match the values that are configured in the adapter automation policy. Starting silent configuration Use command cfgeezdmn -s to start silent configuration. Chapter 3. Configuring 205

224 Because silent configuration is an alternative to the configuration dialog, silent mode is started by using the same command. For each component, you specify the option -s after the command to start the configuration tool. Start silent configuration for each component: System Automation Application Manager Process the following steps to start silent configuration: 1. Log in on the system where System Automation Application Manager is installed. 2. Enter the following commands: a. To process configuration tasks for the System Automation Application Manager common configuration: cfgeezdmn -s -e [-r] b. Configure the System Automation Application Manager local agentless adapter, enter: cfgeezdmn -s -eu c. Configure remote System Automation Application Manager Agentless Adapters, enter: cfgeezdmn -s -ru -o host [-ra [-w configdir ] -rr -rd -u userid d. To configure the hardware adapter: cfgeezdmn -s -eh [-r -t] e. To configure the TPC-R domain: cfgeezdmn -s -et [-r -t] -p password] f. To configure the automation policy to make System Automation Application Manager highly available: cfgeezdmn -s -ea [-ad] Use option -ad to configure the high availability policy for a two-site disaster recovery setup. If you do not specify -ad, the regular high availability policy is configured. The PowerHA end-to-end automation adapter Enter the following command to start the configuration tool in silent mode: cfghacadapter -s The FOC end-to-end automation adapter Enter the following command to start the configuration tool in silent mode: cfgmscsadapter.bat -s The file is in the adapter installation directory, in the subdirectory bin: C:\Program Files\IBM\tsamp\eez\mscs\bin The VCS end-to-end automation adapter Enter the following command to start the configuration tool in silent mode: cfgvcsadapter -s For more information about the cfgeezdmn, cfghacadapter, cfgmscsadapter, and cfgvcsadapter commands, see Tivoli System Automation Application Manager, Reference and Problem Determination Guide. 206 Tivoli System Automation Application Manager V : Installation and Configuration Guide

225 Silent mode input properties file Generate a silent mode input properties file from the values that are currently configured and use it to modify configuration settings in silent mode. Table 41. Generated input properties files Advantages of the silent input properties file: v You can generate properties files immediately after installation and before you process the customization. v If you customize with the configuration dialog and in silent mode, you can first generate an up-to-date input file before you apply changes in silent mode. v You can easily recover from the accidental deletion of the silent mode input properties file. To generate a silent mode input properties file, use one of the following options when you start silent configuration: -g Generate the input properties file only if it does not exist. -gr Generate the input properties file and replace it if it exists. -l location The input properties file for silent configuration is in the directory that is specified with location. If -l is omitted, the input properties file is in the default directory <EEZ_CONFIG_ROOT>. Depending on the target configuration, Table 41 shows the silent input properties files that are generated if the -g or -groption is specified. Component Target configuration Silent input properties file System Automation Application Manager (common) Local agentless adapter Remote agentless adapter Hardware adapter TPC-R domain cfgeezdmn -s -e -g -gr cfgeezdmn -s -e -g -gr -l location cfgeezdmn -s -eu -g -gr cfgeezdmn -s -eu -g -gr -l location cfgeezdmn -s -ru -o host -g -gr cfgeezdmn -s -ru -o host -g -gr -l location cfgeezdmn -s -eh cfgeezdmn -s -eh cfgeezdmn -s -et cfgeezdmn -s -et -g -gr -g -gr -l location -g -gr -g -gr -l location <EEZ_CONFIG_ROOT>/ silent.eezcommon.properties location/silent.eezcommon.properties <EEZ_CONFIG_ROOT>/ silent.eezaladapt.properties location/silent.eezaladapt.properties <EEZ_CONFIG_ROOT>/ silent.remotealadapt.properties location/ silent.remotealadapt.properties <EEZ_CONFIG_ROOT>/ silent.eezhwadapt.properties location/silent.eezhwadapt.properties <EEZ_CONFIG_ROOT>/ silent.eeztpcr.properties location/silent.eeztpcr.properties Chapter 3. Configuring 207

226 Table 41. Generated input properties files (continued) Component Target configuration Silent input properties file System Automation Application Manager high availability PowerHA adapter FOC adapter VCS adapter cfgeezdmn -s -ea cfgeezdmn -s -ea -g -gr -g -gr -l location cfgeezdmn -s -ea -ad -g -gr cfgeezdmn -s -ea -ad -l location cfghacadapter -s cfghacadapter -s cfgmscsadapter -s cfgmscsadapter -s cfgvcsadapter -s cfgvcsadapter -s -g -gr -g -gr -g -gr -l location -g -gr -g -gr -l location -g -gr -g -gr -l location <EEZ_CONFIG_ROOT>/ silent.eezauto.properties location/silent.eezauto.properties <EEZ_CONFIG_ROOT>/ silent.eezautodr.properties location/silent.eezautodr.properties <EEZ_CONFIG_ROOT>/ silent.hacadapter.properties location/silent.hacadapter.properties <EEZ_CONFIG_ROOT>\ silent.mscsadapter.properties location\silent.mscsadapter.properties <EEZ_CONFIG_ROOT>/ silent.vcsadapter.properties location/silent.vcsadapter.properties If you update configuration settings in silent mode, the silent properties file is used as input for the update task. If you want the configuration tool to retrieve the input file from a location other than in the <EEZ_CONFIG_ROOT> directory, use the -l location option. Editing the input properties file Modify the values in the input properties file to change the configuration in silent mode. The input properties files that are generated for each of the components contain configuration parameter keyword-value pairs. The structure, terminology, and wording of the properties content and the configuration dialog are identical. This fact makes it easy to switch between modes and minimizes errors when you edit the properties file The names of tabs, for example Domain, on the configuration dialog are used as identifiers in the properties file, for example: # ============================================================================== #... Domain Each field name on the configuration dialog, for example Domain name, is contained in the properties file, followed by a brief description and the keyword for that field, for example: # #... Domain name # The name of the end-to-end system automation domain. Ensure that this # domain name is unique in the set of all automation domains you are 208 Tivoli System Automation Application Manager V : Installation and Configuration Guide

227 # working with. The name has to match the DomainName attribute of all # policies which are intended to be activated on this end-to-end # automation domain. # The maximum length of the domainname is 64 characters. domain-name=friendlye2e # To edit the properties file, locate the keyword that is associated with the value, which you want to change and overwrite the value. If you set the value of a required keyword to blank or comment out the keyword, the value that is defined in the target configuration file remains unchanged. Note: 1. If a keyword is specified several times, the value of the last occurrence in the file is used. 2. Each value must be specified on one single line. Output in silent mode Inspect the output that is generated by the configuration too in silent mode. Start the configuration tool in silent mode and click Save. This task leads to output that closely matches the output that is displayed in interactive mode in the update status dialogs or in the message boxes. The silent mode output falls into one of the following categories: No update There are no configuration updates to be saved. All parameters in all target configuration files already match the specified silent input parameters. No errors were detected when the silent input parameters are checked. If additional information is available or any warning conditions are detected, the information and warnings are reported. If warnings are reported, the configuration tool issues return code "1" rather than "0". You might need to observe the return code when you start silent configuration, for example within a shell script. Successful completion At least one of the target configuration files is updated and all configuration files and their update status are listed. No errors are detected when you check the silent input parameters. If additional information is available or any warning conditions are detected, the information and warnings are reported. If warnings are reported, the configuration tool issues return code "1" rather than "0". You might need to observe the return code when you start silent configuration, for example within a shell script. Unsuccessful completion No target configuration file is updated. Any errors that are detected when you check the silent input parameters are reported. The configuration tool stops and issues return code "2". Tasks that do not update configuration files The output for all Refresh and Test configuration tasks is a corresponding task completion message. Silent input properties file generation Values from the target configuration files are used to generate the input file. No target configuration file is updated. Chapter 3. Configuring 209

228 Configuration properties files Unrecoverable error Error messages report the reason for the error. The configuration tool stops and issues a return code greater than "2". Configuration properties files are used to store the settings of System Automation Application Manager, and the PowerHA, FOC, and VCS adapter. Configuration properties files of the System Automation Application Manager During the installation of the System Automation Application Manager, the properties in the files are set to values to work with the sample end-to-end automation domain. For more information, see Tivoli System Automation Application Manager, Administrator s and User s Guide. To change the values of the properties, you use the cfgeezdmn configuration tool of the System Automation Application Manager. The cfgeezdmn command ensures that the files are not corrupted during manual editing and that the change history in the files is updated whenever a property is changed. It also ensures that dependencies between parameter values in different properties files are observed. The configuration properties files of the System Automation Application Manager are in the following directory: <EEZ_CONFIG_ROOT> For example, /etc/opt/ibm/tsamp/eez/cfg The following list describes the properties files that are changed when you modify a property value by using the cfgeezdmn configuration tool: eezautomate.properties The properties in this file are used to configure the end-to-end automation policy. This policy can be activated on a System Automation for Multiplatforms domain to make the System Automation Application Manager highly available. The configuration properties specify, for example, the name of the System Automation for Multiplatforms domain, the location of the WebSphere profiles and the DB2 installation directory. eez.automation.engine.properties The properties in this file are used to configure exactly one instance of the automation engine. The configuration properties specify, for example, the name of the end-to-end automation domain and the location of the policy pool directory. eez.automation.engine.dif.properties The domain identification file of the automation engine contains the user IDs and the passwords to authenticate to first-level automation domains and to the WebSphere Application Server JMS Provider. eez.publisher.omnibus.properties The properties in this file are used to configure settings to publish EIF events to Tivoli Netcool/OMNIbus. The configuration properties specify, for example, the server and port of the OMNIbus Probe for Tivoli EIF and event filters. 210 Tivoli System Automation Application Manager V : Installation and Configuration Guide

229 eez.publisher.gdps.properties The properties in this file are used to configure the GDPS event server and port. It is required to use the System Automation Application Manager hardware adapter to manage hardware for distributed disaster recovery with GDPS. eez.publisher.gdpsbackup.properties The properties in this file are used to optionally configure the GDPS backup event server and port. It is required to use the System Automation Application Manager hardware adapter to manage hardware for distributed disaster recovery with GDPS. eez.fla.ssl.properties This file contains the configuration properties for the SSL connection to the first-level automation domains. eezjlog.properties The properties in this file determine which information is written to the log and trace files of the automation engine. sas.eezcs.properties The properties in this file determine whether users of the end-to-end automation command shell must specify their user credentials to use the command shell. sas.eezdmn.properties The properties in this file determine how the end-to-end automation engine and the discovery library adapter access the WebSphere Application Server and the automation Java Platform, Enterprise Edition framework. eez.dla.properties The properties in this file determine where the IdML books created by the discovery library adapter are stored. eez.hwadapter.properties The properties in this file are used to configure the hardware adapter. The configuration properties include, for example, the host and port the hardware adapter listens on, and the host and port of the automation engine it communicates with. eez.hwadapter.plugin.properties The properties in this file are used to configure credentials for the hardware devices when you configure distributed disaster recovery with GDPS. eez.hwadapter.zent-1.plugin.properties The properties in this file are used to configure the settings to access the zenterprise Hardware Management Console (HMC) for virtual server management. eez.aladapter.properties The properties in this file are used to configure the local agentless adapter. For example, the host and port the agentless adapter listens on, or the host and port of the automation engine it communicates with. eez.aladapter.dif.properties The properties in this file are used to configure the user IDs and the corresponding passwords that the local agentless adapter uses to access remote non-clustered nodes. The resources that the agentless adapter starts, stops, and monitors are on remote nodes. Chapter 3. Configuring 211

230 eez.aladapter.ssh.properties The properties in this file are used to configure security settings that are related to SSH private keys. SSH keys can be configured for user authentication on remote non-clustered nodes as an alternative to configure credentials in the eez.aladapter.dif.properties file for the local agentless adapter. eez.aladapter.ssl.properties The properties in this file are used to configure Secure Sockets Layer (SSL) for transport between the automation manager and the local agentless adapter. eez.aladapter.jaas.properties This file contains the configuration of the LoginModule that is used for user authentication between the automation manager and the local agentless adapter. eez.aladapter.plugin.properties The properties in this file are used to configure settings that are unique for the local agentless adapter. For example, the location of the XML policy pool. eez.aladapter.plugin.<domain>.properties For each local agentless adapter domain, a domain-specific copy of eez.aladapter.plugin.properties is created. eez.tpcr.domain.properties The properties in this file are used to configure settings of the Tivoli Storage Productivity Center for Replication domain. TPC-R is used by the System Automation Application Manager to integrate storage replication sessions into end-to-end automation policies. <remote_node>/eez.aladapter.properties <remote_node>/eez.aladapter.dif.properties <remote_node>/eez.aladapter.ssh.properties <remote_node>/eez.aladapter.ssl.properties <remote_node>/eez.aladapter.jaas.properties <remote_node>/eez.aladapter.plugin.properties <remote_node>/eez.aladapter.plugin.<domain>.properties These files are stored for each remote agentless adapter instance in a subdirectory for the node on which the remote agentless adapter is installed. <remote_node>/eez.aladapter.jlog.properties The properties in this file determine which information is written to the log and trace files of an instance of the remote agentless adapter. Configuration properties files of the PowerHA adapter Configure the PowerHA adapter by setting the values in the configuration properties file. To change the values of the properties, use the cfghacadapter configuration tool of the PowerHA adapter. Use the configuration tool to make sure that the files are not corrupted during manual editing. The change history in the files is updated whenever a property is changed. It also ensures that dependencies between parameter values in different properties files are observed. The configuration properties files are in the following directory: <hacmp_adapter_conf_root> 212 Tivoli System Automation Application Manager V : Installation and Configuration Guide

231 For example: /etc/opt/ibm/tsamp/eez/hac/cfg The following list describes the properties files that are changed when you modify a property value by using the cfghacadapter configuration tool. hac.adapter.properties The properties in this file are used to configure the PowerHA adapter. For example, the host and port on which the PowerHA adapter listens or the host and port of the automation engine, with which the PowerHA adapter communicates. hac.adapter.jaas.properties This file contains the configuration of the LoginModule that is used for user authentication between the automation manager and the PowerHA adapter. hac.adapter.jlog.properties The properties in this file determine which information is written to the log and trace files of an instance of the PowerHA adapter. hac.adapter.plugin.properties The properties in this file are used to configure settings that are unique for the PowerHA adapter. hac.adapter.ssl.properties The properties in this file are used to configure Secure Sockets Layer (SSL) for transport between the automation manager and the PowerHA adapter. hac.adapter.conf This file describes the automation configuration to make the PowerHA adapter highly available. Configuration properties files for the VCS adapter Configure the VCS adapter by setting the values in the configuration properties file. To change the values of the properties, you use the cfgvcsadapter configuration tool of the VCS adapter. Use the configuration tool to make sure that the files are not corrupted during manual editing. The change history in the files is updated whenever a property is changed. It also ensures that dependencies between parameter values in different properties files are observed. The configuration properties files are in the following directory: <vcs_adapter_conf_root> For example, /etc/opt/ibm/tsamp/eez/vcs/cfg The following list describes the properties files that are changed when you modify a property value by using the cfgvcsadapter configuration tool: vcs.adapter.properties The properties in this file are used to configure the VCS adapter. For example, the host and port on which the VCS adapter listens or the host and port of the automation engine, with which the VCS adapter communicates. Chapter 3. Configuring 213

232 vcs.adapter.jaas.properties This file contains the configuration of the LoginModule that is used for user authentication between the automation manager and the VCS Solaris adapter. vcs.adapter.jlog.properties The properties in this file determine which information is written to the log and trace files of an instance of the VCS adapter. vcs.adapter.plugin.properties The properties in this file are used to configure settings that are unique for the VCS adapter. vcs.adapter.ssl.properties The properties in this file are used to configure Secure Sockets Layer (SSL) for transport between the automation manager and the VCS adapter. vcs.adapter.conf This file describes the automation configuration to make the VCS adapter highly available. Configuration properties files of the FOC adapter Configure the FOC adapter by setting the values in the configuration properties file. To change the values of the properties, you use the cfgmscsadapter configuration tool of the FOC adapter. Use the configuration tool to make sure that the files are not corrupted during manual editing. The change history in the files is updated whenever a property is changed. It also ensures that dependencies between parameter values in different properties files are observed. The configuration properties files are in the following directory: <mscs_adapter_conf_root> For example, C:\Program Files\IBM\tsamp\eez\mscs\cfg The following list describes the properties files that are changed when you modify a property value by using the cfgmscsadapter configuration tool: mscs.adapter.properties The properties in this file are used to configure the FOC adapter. For example, the host and port on which the FOC adapter listens or the host and port of the automation engine, with which the FOC adapter communicates. mscs.adapter.jlog.properties The properties in this file determine which information is written to the log and trace files of an instance of the FOC adapter. mscs.adapter.plugin.properties The properties in this file are used to configure settings that are unique for the FOC adapter. mscs.adapter.ssl.properties The properties in this file are used to configure Secure Sockets Layer (SSL) for transport between the automation manager and the FOC adapter. 214 Tivoli System Automation Application Manager V : Installation and Configuration Guide

233 Chapter 4. Integrating Event consoles System Automation Application Manager integrates with a set of Tivoli applications to extend its existing functionality. The integration scenarios require specific configurations to meet your infrastructure needs. Find out how to configure System Automation Application Manager to work together with other Tivoli applications. Integration scenarios: v Event Consoles Forwarding System Automation events to IBM Tivoli Netcool/OMNIbus Configuring launch-in-context from OMNIbus to the System Automation operations console Forwarding system automation events to IBM Tivoli Enterprise Console Configuring launch-in-context from Tivoli Enterprise Console to the System Automation operations console v Tivoli Business Service Manager (TBSM) Populating TBSM views with information from System Automation resources and events Import end-to-end automation management resources into TBSM using the System Automation Application Manager Library Adapter (DLA) Configuring launch-in-context from TBSM to the System Automation operations console and vice versa. v IBM Tivoli Monitoring, and Composite Application Manager Integrating applications which are monitored by ITM or ITCAM in an agentless adapter domain Automating ITM resources in an end-to-end context Configuring launch-in-context from the SA Operations console to the Tivoli Enterprise Portal (TEP). System Automation Application Manager sends EIF events to Tivoli Netcool/OMNIbus (OMNIbus). OMNIbus is a rule-based event management application that uses a central server to process incoming events. For compatibility reasons, alternatively a Tivoli Enterprise Console (TEC) server or any other server that is capable to process EIF events may also be configured. Event sources: v Tivoli applications v Tivoli partner applications v Customer applications v Network management v Relational database systems For System Automation Application Manager an event is generated and forwarded to the TEC or OMNIbus event console in the following cases: Copyright IBM Corp. 2006,

234 v The configuration of System Automation Application Manager or the state of an automated resource changes, which is contained in the end-to-end automation policy. v Problems are encountered If you want to use System Automation events with Tivoli Business Service Manager (TBSM), forward the events to OMNIbus. System Automation Application Manager can produce the following types of events: Table 42. System Automation Application Manager event class types Event Class / Alert Group SystemAutomation_Resource_Status_Change SystemAutomation_Resource_Configuration_Change SystemAutomation_Relationship_Configuration_Change SystemAutomation_Domain_Status_Change SystemAutomation_Request_Configuration_Change SystemAutomation_Request_Status_Change Description Status of an automated resource changed. A new automated resource is added or an existing resource is deleted or modified. A new relationship is added or an existing relationship is deleted or modified. The domain status changed. For example: v The automation manager or the automation adapter of the domain starts or stops. v A new automation policy is activated. A new request is issued against an automated resource or an existing request is canceled. A GDPS command is completed. Only used in the Distributed Disaster Recovery with GDPS feature. The following topics describe how to set up System Automation Application Manager and the event consoles to enable event forwarding to either TEC or OMNIbus. IBM Tivoli Netcool/OMNIbus This topic describes how to set up IBM Tivoli Netcool/OMNIbus to forward System Automation events to the OMNIbus event console and how to set up launch-in-context support for OMNIbus. This OMNIbus set up is also a prerequisite for the integration of System Automation Application Manager with Tivoli Business Service Manager. Prerequisites As System Automation Application Manager and IBM System Automation for Multiplatforms use Tivoli Event Integration Facility (EIF) events for communication, the following components are required: v IBM Tivoli Netcool/OMNIbus (OMNIbus) v OMNIbus Probes Library for Nonnative Base v OMNIbus Probe for Tivoli EIF (EIF Probe). This probe can receive EIF events sent from System Automation and forward them to the ObjectServer. The following minimum versions are required: v OMNIbus Probe for Tivoli EIF V.9.0 v IBM Tivoli Netcool/OMNIbus Tivoli System Automation Application Manager V : Installation and Configuration Guide

235 Note: If you are running IBM Tivoli Netcool/OMNIbus V7.2.1, install Interim Fix 3 ( IF0003). If you are running IBM Tivoli Netcool/OMNIbus V7.3 or higher, no additional fix packs are required. Install and set up these components. For more information, see Tivoli Netcool/OMNIbus Knowledge Center. Environment variables: $NCHOME Refers to the Netcool Home Directory into which the packages are installed. Default directory under Linux: /opt/ibm/tivoli/netcool. $OMNIHOME The $OMNIHOME variable is used to provide legacy support for scripts, third-party applications, and probes that continue to use the $OMNIHOME environment variable. $OMNIHOME refers to $NCHOME/omnibus. Event fields in OMNIbus database The OMNIbus alerts.status table is extended with the following new columns to hold System Automation specific information. They are filled in the System Automation specific OMNIbus rules file when an event is processed. Table 43. Common System Automation status attributes used in resource status change events (alerts.status) Attribute Name Type Description SADesiredState varchar(16) Desired State reflecting the automation goal of an automated resource. Possible values: v Online v Offline v NoChange The automation goal of the resource cannot be changed by an operator. SAObservedState varchar(16) Current Observed State of an automated resource Possible values: v Unknown v Online v Offline v Starting v Stopping v NotApplicable Note: Corresponds to c_status_observed in TEC event. SAOperationalState varchar(255) List of Operational State values giving more fine-grained information about the current state of the resource. For a list of possible values, see the SystemAutomation.baroc file. Note: Corresponds to c_status_operational in TEC event. SACompoundState varchar(16) Compound state indicating whether the resource is working as desired or has encountered an error. Possible values: v Ok v Warning v Error v Fatal Note: Corresponds to c_status_compound in TEC event. Chapter 4. Integrating 217

236 Table 44. alerts.status: Resource, domain, event identification SADomainName varchar(64) Name of the Automation Domain. Part of the resource key to identify a resource. Note: Corresponds to sa_domain_name in TEC events SAResourceName varchar(255) Name of the resource. This is a compound resource name consisting of the resource name itself concatenated with the resource class and optionally the resource node. The order of the name parts and the separator character depends on the sending System Automation product. For SAMP and SAAM: <class_name>:<resource_name>:<node_name> For SA z/os: <resource_name>:<class_name>:<node_name> Note: <node_name> is only set if it exists. For System Automation Application Manager resource references, the node name contains the name of the referenced first level automation domain. Corresponds to sa_resource_name in TEC events. SAEventReason varchar(255) Event reasons. One event can have multiple event reasons in TEC event. Examples for event reasons: v v v StatusCommonObservedChanged ConfigurationDeleted PreferredMemberChanged Note: Corresponds to sa_event_reason in TEC events. SAReferencedResource varchar(255) For end-to-end resource references, this contains the referenced resource key. Table 45. alerts.status: Other attributes used in resource status change events SAExludedFromAutomation varchar(16) Flag indicating if the resource is excluded from automation (i.e. automation is suspended). Used in resource status change events. Possible values: v NotExcluded v Excluded Note: Corresponds to sa_flag_excluded in TEC events. SADesiredRole varchar(16) Desired role. Used for replication references indicating the desired storage replication direction (SAAM only). Used in resource status change events. Note: Corresponds to sa_role_desired in TEC events. SAObservedRole varchar(16) Observed role. Used for replication references indicating the observed storage replication direction (SAAM only). Used in resource status change events. Note: Corresponds to sa_role_observed in TEC events. Table 46. alerts.status: Domain status change events SADomainState varchar(16) Status of Automation Domain. Possible values: v Online v Offline v Unknown Note: Corresponds to sa_domain_state in TEC events. 218 Tivoli System Automation Application Manager V : Installation and Configuration Guide

237 Table 46. alerts.status: Domain status change events (continued) SACommunicationState varchar(32) This state reflects the connection and availability state of the domain. Only sent by SAAM. Used in domain status change events. Possible values: v Ok v AsyncTimeout v AsyncMissedEvent v SyncFailed v SyncFailedAndAsyncMissedEvent v SyncFailedAndAsyncTimeout v DomainHasLeft Note: Corresponds to sa_communication_state in TEC events. Beside the new fields for System Automation events, the following existing fields will be set in the rules file for System Automation events during event processing. Table 47. Existing rules file fields for System Automation events Attribute Name Manager Description Descriptive name of the probe that collected and forwarded the alarm to the ObjectServer. Agent Node AlertGroup AlertKey Severity Summary Service Identifier Value for System Automation events: tivoli_eif on <host name>. Descriptive name of the manager that generated the event. Value for System Automation Application Manager events: IBM Tivoli System Automation Application Manager. Identifies the host name from which the event comes from. Identifies the type of event issued by System Automation. See Table 42 on page 216 for a list of possible event classes. Descriptive key that indicates the resource that triggered the event. For resource events, it contains the resource key formatted as System Automation source token, e.g. EEZResourceKey,DN={FriendlyE2E},NN={},RN={DB2},RC={ChoiceGroup}. For domain events, it contains the domain name formatted as System Automation Source Token, e.g. EEZDomain,DN={FriendlyE2E} Indicates the event severity level. For resource events, the compound state of the resource determines the severity level. The color of the event in the event list is controlled by the severity value: v 0: Clear v 1: Indeterminate v 2: Warning v 3: Minor v 4: Major v 5: Critical See Compound state to severity mapping on page 220. Text summary describing the event. Name of the service affected by this event. Corresponds to field SAResourceName. Identifier which uniquely identifies the problem source and controls ObjectServer deduplication. The ObjectServer uses deduplication to ensure that event information generated from the same source is not duplicated in the event list. Repeated events are identified using the Identifier attribute and stored as a single event to reduce the amount of data in the ObjectServer. For System Automation events, the Identifier field is set to AlertKey + ":" + AlertGroup. Therefore, the event console displays always the last event of the same resource and AlertGroup. Chapter 4. Integrating 219

238 Table 47. Existing rules file fields for System Automation events (continued) Attribute Name Class ExtendedAttr Description The unique class for System Automation events. Value is (Tivoli System Automation). Holds name-value pairs of additional internal System Automation specific attributes, for which no dedicated column exists in the alerts.status table. In addition to these attributes which are stored in the OMNIbus alerts.status table, extra information is written to the alerts.details table. For example, for domain events the product name and version of the automation product corresponding to the domain are stored in the alerts.details table. Compound state to severity mapping For events that contain a SACompoundState value, for example all resource state change events, the following table is used: Table 48. Compound state to OMNIbus severity mapping SACompoundState Fatal Error Warning OK OMNIbus Severity field 5 (Critical) 4 (Major) 3 (Minor) 1 (Indeterminate) For other events that do not contain the SACompoundState value, for example request events or domain events, the EIF severity field is used to determine the OMNIbus severity. Table 49. EIF severity to OMNIbus severity mapping EIF Severity 60 (FATAL) 5 (Critical) 50 (CRITICAL) 5 (Critical) 40 (MINOR) 4 (Major) 30 (WARNING) 3 (Minor) 20 (HARMLESS) 2 (Warning) Else OMNIbus Severity field 1 (Indeterminate) Note: The EIF Severity value of the original EIF event can be found in the ExtendedAttr field of an event. Configuring OMNIbus to process System Automation events Updating the OMNIbus database: The OMNIbus ObjectServer database includes the alerts.status table which contains all fields that are shown and selected by an event list. For System Automation events, the additional columns described in Event fields in OMNIbus database on page 217 have to be created in the alerts.status table. 220 Tivoli System Automation Application Manager V : Installation and Configuration Guide

239 The sa_db_update.sql file creates the new columns in the alert.status table. The event class used for events from Tivoli System Automation is created as well. Tivoli System Automation uses the event class for its events. The class is used to associate tools like the launch-in-context tool, to a specific type of event. Enter the following command on the OMNIbus server: UNIX $OMNIHOME/bin/nco_sql -server NCOMS -username root < sa_db_update.sql Windows: %NCHOME%\bin\redist\isql -S NCOMS -U root < sa_db_update.sql Enter your password when prompted. You can find the file sa_db_update.sql on the System Automation Application Manager product DVD in the directory /integration. Note: The event class is predefined in OMNIbus Version or higher. If you run the sa_db_update.sql script using OMNIbus Version 7.3.1, you receive the following error message: ERROR=Attempt to insert duplicate row on line 2 of statement insert into alerts.conversions values ( Class87725, Class,87725, Tivoli System Automation );... You can ignore this error message. Verify that the System Automation specific columns and event class has been successfully added to OMNIbus: 1. Open the Netcool/OMNIbus Administrator window using the nco_config command. 2. From the Netcool/OMNIbus Administrator window, select the System menu button. 3. Click Databases. The Databases pane opens. 4. Select the alerts.status table. The alerts.status table pane opens. 5. Verify that the following columns are listed: a. SACompoundState b. SADesiredState c. SAObservedState d. SAOperationalState e. SADomainName f. SAResourceName g. SAReferencedResource h. SAEventReason i. SAExludedFromAutomation j. SADesiredRole k. SAObservedRole l. SADomainState m. SACommunicationState 6. From the Netcool/OMNIbus Administrator window, select the Visual menu button. Chapter 4. Integrating 221

240 7. Click Classes. The Classes pane opens. 8. Verify that the class with ID and label Tivoli System Automation is listed in the table. Enable rules file for System Automation: An OMNIbus rules file defines how the probe processes event data to create an alert. For each alert, the rules file also creates an identifier that uniquely identifies the problem source. The probe for Tivoli EIF uses a standard rules file named tivoli_eif.rules. System Automation Application Manager ships the System Automation specific rules file tivoli_eif_sa.rules. This file needs to be included within the default tivoli_eif.rules using an include statement. The rules file tivoli_eif_sa.rules processes an EIF event received by the probe for Tivoli EIF if the event field source contains the value SystemAutomation. The default tivoli_eif.rules file is located on the system where the probe for Tivoli EIF is installed in the following directory: Windows: %OMNIHOME%\probes\<os_dir>\tivoli_eif.rules UNIX: $OMNIHOME/probes/<os_dir>/tivoli_eif.rules Perform the following steps to enable the tivoli_eif_sa.rules file: 1. Copy the file tivoli_eif_sa.rules, which is located in the /integration directory on the System Automation Application Manager product DVD to the system where the OMNIbus probe for Tivoli EIF is installed. As a target directory choose the directory where the tivoli_eif.rules file is located. 2. Enable the shipped rules file tivoli_eif_sa.rules. Edit the tivoli_eif.rules file that is used in the probe for Tivoli EIF and add an include statement for the tivoli_eif_sa.rules file. The content of the tivoli_eif.rules looks different depending on the type of OMNIbus installation you have: a. If you use a standalone OMNIbus installation: Open tivoli_eif.rules file in a text editor and add the include statement after the switch($source) block: : else { switch($source) { case "dummy case statement": ### This will prevent syntax errors in case no includes are added below. } include "tivoli_eif_tpc.rules" include "tivoli_eif_tsm.rules" # Uncomment the following line when using TADDM integration # This rules file is available in OMNIbus 7.3 and newer only # include "tivoli_eif_taddm.rules" default: # Comment out the following line when not receiving events from TEC include "tivoli_eif_default.rules" } include "tivoli_eif_sa.rules" b. If you integrate with Tivoli Business Service Manager (TBSM) and use the OMNIbus version packaged with TBSM: Open the tivoli_eif.rules file in a text editor and add the include statement in the block where the predefined rules files are included. Search 222 Tivoli System Automation Application Manager V : Installation and Configuration Guide

241 for the line # Include customer rules which would override any previous rules. and add the include statement for tivoli_eif_sa.rules before this line: : : ### ### Handle TEC Events ### include "tec_event.rules" ### ### Handle Z Events ### # include "zos_event.rules" ### ### Handle Z user defined events. ### # include "zos_event_user_defined.rules" ### ### Handle Z identity assignement. ### # include "zos_identity.rules" ### ### Handle EE( Event Enablement) events. ### # include "tivoli_eif_ee.rules" include "tivoli_eif_sa.rules" # Include customer rules which would override any previous rules. # include "customer_override.rules" : : 3. Stop the EIF probe. v v On Windows: Select Control Panel > Administrative Tools > Services. In the list of services, double-click the EIF probe, then click Stop. On UNIX: Enter the following command on the command line $OMNIHOME/bin/nco_pa_stop -process <probe_name> 4. Restart the EIF probe. v v Note: On Windows: In the list of services, double-click OMNIbus EIF Probe, then click Start On UNIX: Enter the following command on the command line: $OMNIHOME/bin/nco_pa_start -process <probe_name> 1. You can test your changes in the rules file using the syntax checking tool nco_p_syntax delivered with the OMNIbus server. Use the root rules file tivoli_eif.rules. Included files are checked automatically. Example: $OMNIHOME/probes/nco_p_syntax -rulesfile $OMNIHOME/probes/linux2x86/tivoli_eif.rules 2. If you want the Probe to be forced to read again the rules file without losing events, enter the following command: kill -HUP <pid> Chapter 4. Integrating 223

242 pid is the probe process ID. You can determine the pid using the nco_pa_status command. Configuring Tivoli Netcool/OMNIbus launch-in-context The launch-in-context support for System Automation Application Manager navigates from an event that is displayed in the OMNIbus active event list to the corresponding resource or domain in the System Automation operations console. Example usage scenario: 1. Application failure is detected by System Automation and a corresponding event is forwarded to OMNIbus. 2. An operator sees an error event in the OMNIbus active event list that indicates that an automated application has failed. 3. For further analysis, he selects the event and clicks on a menu entry to launch the operations console. 4. A new browser window is opened and connects to the IBM Dashboard Application Services Hub which automatically launches the operations console. 5. The System Automation operations console automatically navigates to the application that caused the error event and selects it. 6. The operator now sees all detailed status information, relationships, etc. as they are provided by System Automation. Creating a launch-in-context tool: Create a launch-in-context tool which launches the System Automation operations console from the event managed by the ObjectServer: 1. Login to the Tivoli Integrated Portal (TIP) hosting the OMNIbus web GUI as tipadmin. 2. Navigate to Administration -> Event Management Tools -> Tool Creation. 3. Select Create Tool. 4. Select CGI/URL as Type. 5. Enter the URL EEZIscUrlBuilderServlet. ISC_HOST is the system where the System Automation Application Manager operations console is running. ISC_PORT is the secure port for the IBM Dashboard Application Services Hub hosting the System Automation operations console. 6. Click the Fields: Show button and select the following fields that should be passed as context arguments to the URL: v SADomainName v SAResourceName v Summary 7. Select Method: GET 8. Select Open In -> Specific Window and type a window name, for example SystemAutomation. So that launches from OMNIbus always use the same window to open the System Automation operations console. 9. In the Access Criteria section, select the Class tab and choose the Tivoli System Automation class from the list of available event classes. This ensures that the launch-in-context tool is only available for events of System 224 Tivoli System Automation Application Manager V : Installation and Configuration Guide

243 Automation. Figure 21. Sample configuration of launch entry Note: If you have more than one System Automation Application Manager installation, define a launch-in-context tool for each installed instance. 10. Click Save to save the new launch-in-context tool. Defining the menu entry: After the launch-in-context tool has been defined, you can configure the menu entry to display the launch-in-context tool. To add the new launch-in-context tool to the active event list tools menu, perform the following steps: 1. Navigate to: Administration -> Event Management Tools -> Menu Configuration 2. Select a menu to contain the launch-in-context action (for example tools) and click Modify. 3. Select the new launch-in-context tool from the Available items list and add it to the list of Current items. 4. Click Save to store the modified configuration of the tools menu. Chapter 4. Integrating 225

244 Figure 22. Modifying menu entries that are displayed in the Tools menu Tivoli Enterprise Console This topic describes how to set up the Tivoli Enterprise Console to forward System Automation events to the TEC and how to set up launch-in-context support for the TEC. Prerequisites To install and use the IBM TEC Extension for System Automation Application Manager, the following prerequisites must be met: TEC version TEC 3.8 or later Web browser If you use the Java version of the TEC Event Console to launch to the System Automation operations console, make sure a web browser like Mozilla, Firefox, or Internet Explorer is installed on the system where the event console runs. Configuring TEC to process System Automation events The programming language Basic Recorder of Objects in C (BAROC) is used to define the structure of events and their properties. These definitions are stored in files with the extension.baroc. The baroc file for System Automation events is 226 Tivoli System Automation Application Manager V : Installation and Configuration Guide

245 called SystemAutomation.baroc and is located in directory <EEZ_CONFIG_ROOT> after the installation. To prepare TEC to use with System Automation Application Manager, perform the following step: 1. Import, compile, load, and activate the TEC baroc file SystemAutomation.baroc in the TEC server. For more information refer to IBM Tivoli Enterprise Console Rule Builder's Guide, GC Configuring Tivoli Enterprise Console launch-in-context support The IBM Tivoli Enterprise Console (TEC) extension for System Automation Application Manager (IBM TEC Extension) allows to navigate from an event that is displayed in the Event Console of Tivoli Enterprise Console (TEC Event Console) to the corresponding resource or domain in the System Automation operations console. Example usage scenario: 1. An operator sees an event in the TEC Event Console that shows that a Tivoli System Automation resource failed. 2. The operator selects the event and starts the System Automation operations console for this event. 3. The System Automation operations console automatically navigates to the resource specified in the event. 4. The operator analyzes the error by checking, for example, the resource status and dependencies. The IBM TEC Extension can be used for all TEC Event Console setups: v Java version of the TEC Event Console v TEC web console v TEC event viewer embedded in the Tivoli Event Portal (TEP) running using the desktop client interface running using the browser client interface Installing the TEC extension: For the TEC web console client, no installation steps are required. You can directly progress to the configuration steps described in Enabling launch-in-context feature on page 228. You only need to perform the installation steps described in this topic if you are using the Java version of the TEC Event Console or the TEC event viewer embedded in TEP: v When you are using the Java version of the TEC Event Console, the IBM TEC Extension for System Automation Application Manager needs to be installed on the system where the TEC Event Console runs. v When you are using the TEC event viewer embedded in the TEP and the TEP is started using the browser client interface, the IBM TEC Extension for System Automation Application Manager needs to be installed on the system where the browser runs. Chapter 4. Integrating 227

246 To install the IBM TEC Extension on AIX, Linux or Windows perform these steps: 1. Insert the System Automation Application Manager product DVD into the DVD drive of the system where the TEC server is running. 2. Open a command prompt (Windows) or a command shell (Linux, AIX). 3. Change to the directory ECExtension on the product DVD or in the electronic distribution directory structure. 4. Start the installation program, using this command: java jar setup.jar 5. Follow the installation instructions. Enabling launch-in-context feature: To enable the launch-in-context feature, complete the following steps: Java TEC Event Console Perform these steps: 1. Open the Java version of the TEC Event Console. 2. Select Windows > Configuration. Navigate to the console where you want to define the button. Right click Properties. 3. Select the Custom Button entry from the list on the left side of the window. 4. Click Create Button. 5. Enter a label for the button, for example, Launch SA Console, and the location of EEZLaunchSA. The syntax of the script is: For Windows: <path>eezlaunchsa.bat [<java home>] Example: "C:\Program Files\IBM\TECExtension\EEZLaunchSA.bat" C:\IBM\tec_console\jre\bin\ For AIX and Linux: <path>eezlaunchsa.sh [<java home>] where <path> is the directory in which the TEC Extension for System Automation was installed and the optional parameter <java home> is the Java home directory where the file java.exe can be found. This parameter must end with a / (slash). Java 1.3 or higher is required. If the path contains blanks it must be enclosed in quotes ( ). 6. Ensure that you have enabled Event selection required for button action. Web TEC Event Console For the definition of a web custom button, the Java version of the TEC Event Console is required. To define the button, do this: 1. Open the Java version of the TEC Event Console. 2. Select Windows > Configuration. Navigate to the console where you want to define the button. Right click Properties. 228 Tivoli System Automation Application Manager V : Installation and Configuration Guide

247 3. Select the Web Custom Button entry from the list on the left side of the window. 4. Click Create Button. 5. Enter a label for the button, for example, Launch SA Console, and the URL of the servlet: where <isc_server> is the name of the host where the IBM Dashboard Application Services Hub runs which hosts the operations console and <isc_port> is the port that is used to access the operations console. Example: 6. Ensure that you have enabled Event selection required for button action. Enabling event generation in System Automation Application Manager If you want to send System Automation events to OMNIbus, enable event forwarding in System Automation Application Manager. If you have not activated or configured the EIF event generation and forwarding function during the installation of System Automation Application Manager, you can do so by performing the following steps: 1. Start the end-to-end automation configuration tool (cfgeezdmn). On the Event Publishing tab within the Application Manager Common Configuration, proceed as follows: a. Select the check box Enable OMNIbus EIF event publishing. b. Enter the OMNIbus event server host name. c. Enter the OMNIbus event server port number. d. Save the configuration.. 2. Restart the WebSphere Application Server and the end-to-end automation engine (eezdmn) or click the Refresh button to refresh the active Application Manager common configuration. Enabling event filtering When you use the event console of the Tivoli Enterprise Console (TEC) or IBM Tivoli Netcool/OMNIbus products to display events, all end-to-end automation events are sent to the event console by default. To limit the scope of events that are forwarded to the event console, use the Event Publishing tab of the end-to-end automation configuration tool to achieve the following goals: v Controlling automation domain level events that are sent to the event console. v Controlling events for adding and removing automation requests that are sent to the event console. Chapter 4. Integrating 229

248 v Controlling resource status change events that are sent to the event console. There are three options for sending resource status change events: Send all resource state changes. Use this option if event correlation is used in the event console: If only events with a high severity value are sent, then the event console cannot automatically clear errors that are based on events that have been sent previously. Send only resource state changes with warning or fatal severity. Send only resource state changes with fatal severity. For more information about the Event Publishing tab of the end-to-end automation configuration tool, refer to Event Publishing tab on page 109. Tivoli Business Service Manager (TBSM) TBSM delivers real-time information that you need in order to respond to alerts effectively, to be in line with business requirements, and optionally to meet service-level agreements (SLAs). TBSM tools help you to build a service model that you integrate with IBM Tivoli Netcool /OMNIbus alerts or optionally with data from an SQL data source. The TBSM Data server analyzes IBM Netcool/OMNIbus ObjectServer events or SQL data for matches against the incoming-status rules you configured for your service models. If the matching data changes the service status, the status of the TBSM service model changes accordingly. When a services status changes, TBSM sends corresponding service events back to the ObjectServer. The Discovery Library Toolkit creates TBSM service objects which use data from Discovery Library Adapter (DLA) books or from the IBM Tivoli Application Dependency Discovery Manager. The TBSM console provides a graphical user interface (GUI). It runs in the Tivoli Integrated Portal (TIP) and logically links services and business requirements within the service model. The service model provides an operator with a view of how an enterprise performs at a certain moment in time or did perform over a certain time period. The following figure shows the basic architecture of TBSM: 230 Tivoli System Automation Application Manager V : Installation and Configuration Guide

249 Historical data Tivoli Intergrated Portal TBSM Dashboard Server Data for service models, custom charts, views, nearterm history metric, and marker data (Time Window Analyzer) Databases Sources for EIF events Event Pump for z/os OMNIbus Web GUI Service model data Discovery data Discovery Library Toolkit Tivoli Application Dependency Discovery Manager Discovery Library Books Tivoli Enterprise Console NetView Tivoli Data Warehouse TBSM Common Agent TBSM Data Server Events Netcool/OMNIbus ObjectServer Events EIF Probe EIF events IBM Tivoli Monitoring User data Event sources Events IBM Tivoli System Automation User Repository LDAP or ObjectServer Probes Monitors OMEGAMON TBSM components OMNIbus components Netcool/ Impact ITCAM for Internet Service Monitoring ITCAM Other components Figure 23. TBSM basic architecture Main components: Tivoli Integrated Portal Tivoli Integrated Portal enables the interaction and secure passing of data between Tivoli products through a common portal. You can launch various applications within the same dashboard view to investigate different aspects of your managed enterprise. Tivoli Netcool/OMNIbus TBSM monitors the Tivoli Netcool/OMNIbus ObjectServer for incoming events. The ObjectServer collects events from probes, monitors, and other applications such as IBM Tivoli Monitoring. You use TBSM to create service models that respond to the data received in the incoming events. For example, the incoming event data can change the status of a service or start the tracking of a potential SLA violation. Tivoli Netcool/Webtop (OMNIbus web GUI) Netcool/Webtop is the browser console for Netcool/OMNIbus and TBSM uses Netcool/Webtop components to display events that are related to service models. The Active Event List (AEL) and Service Details portlet in TBSM are Netcool/Webtop components, and are installed as part of TBSM. The Tivoli Integrated Portal also includes Netcool/Webtop components. TBSM dashboard server The TBSM dashboard server manages the display of the TBSM console and communicates with the TBSM data server. This interaction between the different TBSM components facilitates to create and visualize service models using connected TBSM consoles. Users working with the console view mainly only parts of the service model. Therefor the dashboard server acquires and maintains status of services from the data server. TBSM data server The TBSM data server monitors the ObjectServer and external databases Chapter 4. Integrating 231

250 for data that affect the status of the services. These services are configured in the TBSM console or with the RAD shell command-line tool. The server calculates the status of these services by applying rules to the external data. Your service models and the rules are stored in the TBSM database. Integrating with System Automation Application Manager Business applications typically consist of different middleware components, are multi-tiered, and run on heterogeneous platforms. Tivoli Business Service Manager (TBSM) provides health information about the multi-tiered application. TBSM also monitors service level agreements (SLA) based on information coming from numerous sources. Netcool/OMNIbus is used to collect all events that are related to the business application landscape and TBSM uses these events to determine the status of the business applications. System Automation Application Manager can be used to integrate with TBSM in the following ways: v Data from System Automation events can be used to enrich TBSM service views. System Automation Application Manager delivers a TBSM service template containing pre-configured rules how to map states from System Automation to TBSM service instances. v The integration of System Automation Application Manager resources with TBSM can be automated and simplified using the Discovery Library Adaptor (DLA). With this approach, System Automation Application Manager resources are automatically imported into a TBSM service model and related TBSM status rules are automatically assigned. System Automation Application Manager events are automatically matched with the right TBSM service instances without manual configuration. v Launch-in-context from a TBSM service view to the System Automation operations console and vice versa allows an operator to easily see the information about a specific application from both products. For example, with this capability TBSM can be used to monitor the health of a business application. An operator can use the launch-in-context capability to switch to the operations console to start or stop this business application. Prerequisites Before you begin, install and configure the following products and test your installation: v Configure and enable event forwarding to OMNIbus for System Automation Application Manager events. For more information, see Configuring OMNIbus to process System Automation events on page 220 and Enabling event generation in System Automation Application Manager on page 229. v If you want to include System Automation for Multiplatforms resources in TBSM service trees, enable event forwarding to OMNIbus for System Automation for Multiplatforms events. For more information, see Integrating System Automation resources and TBSM. v Tivoli Business Service Manager (TBSM) V4.2.1 or higher v Update the Netcool OMNIbus ObjectServer schema for TBSM. If you have an existing OMNIbus server, import the schema files tbsm_db_update.sql and ClearServiceDeps.auto. If OMNIbus is installed with TBSM, the TBSM installer performs the required schema updates. 232 Tivoli System Automation Application Manager V : Installation and Configuration Guide

251 For more TBSM specific product information, see Tivoli Business Service Manager Knowledge Center. Configuring TBSM In order to simplify the process for defining and configuring services in TBSM, service templates can be defined for services instances with common behavior. Rather than define each of the services and their dependencies individually, one template can be created for a type of service and then be assigned to applicable services. Service instances represent actual services that are assigned a template. The template defines how a service responds to incoming data and the status of other services. Services of the same type should be assigned to a common template. This allows to use the same template rules to evaluate the status of multiple services. When you assign a template to a service, you tag the service with the template. Templates eliminate the necessity of creating the same rules for a service type more than once. System Automation Service Template for TBSM System Automation Application Manager provides a TBSM Service Template that is used for System Automation resources which are displayed in a TBSM service tree. The Service Template is named EEZ_SystemAutomationResource. It provides v An Incoming Status Rule named SACompoundState which uses state change events coming from System Automation resources to determine the overall state of services. v Text-based Incoming Status Rules, which export the System Automation Observed State and other System Automation specific states of a resource, so that they can be used in TBSM Views. For more information, see Customizing TBSM views to add information from System Automation on page 242. v Additional properties that allow launch-in-context to the System Automation operations console. For more information, see Configuring Tivoli Business Service Manager launch-in-context support on page 246. The EEZ_SystemAutomationResource Service Template contains an incoming status rule named SACompoundState which determines the overall state of a service. If the Service Template has been assigned to a specific service instance, resource state change events coming from System Automation will influence the overall state of the service. Events are associated with a service instance if the AlertKey in the event matches the AlertKey defined as identifier for the service instance. TBSM has three available overall states: Bad, Marginal, and Good. The following mapping is defined in the SACompoundState rule to map resource state change events from System Automation to an overall TBSM state for a service instance: Table 50. Event Severity to TBSM State Mapping Event Severity TBSM State 5 (Critical) Bad (Red) 4 (Major) Bad (Red) 3 (Minor) Marginal (Yellow) 1 (Indeterminate) Good (Green) Chapter 4. Integrating 233

252 Since there is a one-to-one mapping from a resource s compound state to the event severity, the System Automation compound state directly determines the TBSM state. For more information about the mapping of compound state to event severity, refer to Compound state to severity mapping on page 220. Defining a System Automation service template in TBSM The EEZ_SystemAutomationResource template is required to use System Automation events in TBSM, import the EEZ_SystemAutomationResource template into TBSM as follows: 1. Copy the file EEZ_SystemAutomationResource.radsh from the /integration directory of the System Automation Application Manager product DVD to a temporary directory where the TBSM data server is installed. 2. Open a command prompt on the TBSM data server system. Change to the directory to which you have copied EEZ_SystemAutomationResource.radsh and issue the following command: v v UNIX: cat EEZ_SystemAutomationResource.radsh $TBSM_HOME/bin/rad_radshell Windows: type EEZ_SystemAutomationResource.radsh %TBSM_HOME%\bin\rad_radshell The service template provided by System Automation is now defined in TBSM. Defining trigger in Netcool/OMNIbus In the OMNIbus ObjectServer, a new state change event for a resource replaces the previous event. This is called event deduplication. By default, TBSM only processes a de-duplicated event when the value of the Severity field changed. In these cases, TBSM processes the de-duplicated events and updates the service status accordingly. A status change is possible for a System Automation resource which updates status fields used in the text-based incoming status rules which are contained in the EEZ_SystemAutomationResource service template. But the severity value does not change because the compound state of the resource does not change. Define a trigger in OMNIbus, to ensure that TBSM updates the services in these cases as well. The sa_db_tbsm_update.sql file is used to define the trigger named update_tbsm_service_on_sa_events in OMNIbus. This trigger ensures that TBSM reprocesses events if one of the states that are used in the text-based incoming status rules changes, even if the severity value does not change. Whenever you want to use the text-based incoming status rules included in the EEZ_SystemAutomationResource service template, create this trigger definition. Enter the following command on the OMNIbus server to define the trigger: UNIX: $OMNIHOME/bin/nco_sql -server NCOMS -username root < sa_db_tbsm_update.sql Windows: %NCHOME%\bin\redist\isql -S NCOMS -U root < sa_db_tbsm_update.sql 234 Tivoli System Automation Application Manager V : Installation and Configuration Guide

253 Enter password when prompted. sa_db_tbsm_update.sql is shipped with System Automation Application Manager and can be found in the directory /integration on the product DVD. Configuring the Discovery Library Toolkit System Automation Application Manager provides a Discovery Library Adapter (DLA) to export the currently active System Automation Application Manager resource topology to an Identity Markup Language (IdML) discovery book. For more information, refer to Working with the discovery library adapter on page 287. You can use the Discovery Library Toolkit of TBSM to create TBSM service models from such an IdML book. Using the Discovery Library Adapter automates the following tasks: v Import the System Automation Application Manager resources into the service model of TBSM. The new service instances show the grouping hierarchy defined in the end-to-end automation policy. v Assign the System Automation Service Template containing the incoming status rules to the TBSM services. v Match System Automation Application Manager events with the TBSM service instance without manual configuration. v Define the launch-in-context parameters of a service instance to enable launching to the System Automation operations console in context of the service instance. IdML books are XML files in the Identity Markup Language (IdML) format. These XML files conform to the IBM Common Data Model (CDM) and can be generated by a variety of systems and applications. They are used by the Discovery Library Toolkit to discover resources and relationships in a given environment. This topic describes how you can set up the Discovery Library Toolkit to enable TBSM to discover a service tree based on the active System Automation Application Manager resource topology. Make sure the following products are installed and configured, before an IdML book generated by System Automation Application Manager can be imported into TBSM: v Install the Discovery Library Toolkit of TBSM. v Configure TBSM to work with the Discovery Library Toolkit. Ensure that BSM_Templates.radsh and EEZ_SystemAutomationResource.radsh have been run and that the templates and policies have been added to your TBSM configuration. For more information, see IBM Tivoli Provisioning Manager for OS Deployment Version documentation. To correctly manage the data from System Automation Application Manager, modify the following XML control files on the TBSM server: v Define a template mapping for the EEZ_SystemAutomationResource template in the CDM_TO_TBSM4x_MAP_Templates.xml file. v Define an Event Identification Rule for System Automation events in the EventIdentifierRules.xml file. v Make sure that importing of relationships except of group relationships is disabled by specifying a rule in CDM_TO_TBSM4x_MAP.xml. Chapter 4. Integrating 235

254 You can find the three xml customization files in the directory $TBSM_HOME/XMLToolkit/xml. Defining template mapping To automatically assign the EEZ_SystemautomationResource template to the imported service instances while the IdML book is imported, perform the following configuration steps: 1. Open the CDM_TO_TBSM4x_MAP_Templates.xml file in an text editor. 2. Search for the line <template primary= BSM_BusinessService >. 3. Add <othertemplate name= EEZ_SystemAutomationResource /> to the XML element. The added line is marked in bold: <template primary= BSM_BusinessService > <othertemplate name= SCR_RetrieveDependentObjectsTemplate /> <othertemplate name= SCR_ServiceComponentRawStatusTemplate /> <othertemplate name= EEZ_SystemAutomationResource /> <cdmclass name= cdm:sys.businesssystem /> <cdmclass name= cdm:process.businessservice /> </template> This change will automatically assign the EEZ_SystemAutomationResource service template to all services of class cdm:sys.businesssystem that are imported using the DLA toolkit. Customizing TBSM dependency generation The System Automation Application Manager DLA toolkit stores group and other relationships like start or stop dependencies into the IdML book. Group relationship are stored using the relation type cdm:federates, whereas non-group relationships like start or stop dependencies are stored using the relation type cdm:uses. If you want to only import the group hierarchy but not the non-group relationships with the group relationships into the service model of TBSM, you have to disable the generation of dependencies for the relation type cdm:uses. This simplifies the graphical representation of the resulting service graph in TBSM. Perform the following steps to disable the generation of dependencies between service instances for non-group relations: 1. Open the CDM_TO_TBSM4x_MAP.xml file in an text editor. 2. Add the following line within the <RelationshipInfo> tag: <class type= cdm:uses isdependency= false priority= medium source= cdm:sys.businesssystem target= cdm:sys.businesssystem /> After you added this line, the DLA toolkit no longer generates dependencies between imported service instances for the non-group relationship type cdm:uses. Customizing event identification To associate any event with a service instance imported from an IdML book, identification fields are required. If an event is received that has a matching field name and value as the service instance, the event is applied to the instance. Status rules provided by System Automation use the AlertKey field for service identification. All System Automation events have an AlertKey field set with an 236 Tivoli System Automation Application Manager V : Installation and Configuration Guide

255 unique source token value which represents a resource key. The resources contained in a IdML book created by System Automation Application Manager contain a source token attribute as well. Define a policy to match System Automation events coming with the corresponding service instance by setting the AlertKey field to the source token value of the resource. The generation of TBSM services identification field value pairs is implemented by defining rules in the EventIdentifierRules.xml file. 1. Open the EventIdentifierRules.xml file in an text editor. 2. Add the following policy and mapping elements to this file: <Policy name="systemautomationapplicationmanager"> <Rule name="sourcetokenasalertkey" field="alertkey"> <Token keyword="sourcetoken" value= IBM Tivoli System Automation Application Manager /> </Rule> </Policy> <Mapping policy="systemautomationapplicationmanager" class="cdm:sys.businesssystem" /> When importing a resource of class cdm:sys.businesssystem this policy sets the AlertKey field for all status rules of the corresponding service to the System Automation Application Manager source token value. As a result, each TBSM service instance created from a System Automation Application Manager IdML book has a unique AlertKey field value. Whenever TBSM detects an event with this AlertKey field value, it checks the event for status information for the associated service. After you entered the changes to the XML control files, restart the TBSM Discovery Library Toolkit service to activate the changes. Integrating System Automation resources in TBSM This topic describes how you can add System Automation resources to a TBSM service tree. For resources which are contained in the end-to-end automation policy, you can make use of the DLA to automatically import these resources into TBSM. This is described in Importing resources automatically. If you want to add System Automation resources to TBSM which are not part of the end-to-end automation policy, for example resources managed by System Automation for Multiplatforms, you have to manually create a service instance in TBSM and then assign the System Automation Service Template. This is described in Assigning manually the service template to a service instance on page 240. You also do this if you want to enrich service instances which already exist in a TBSM service tree with information from System Automation events. Importing resources automatically Generating a System Automation Application Manager IdML book: Use the command eezdla to create IdML books for System Automation Application Manager. Perform the following steps: 1. Log on to the system on which the automation manager runs. 2. Enter eezdla. Chapter 4. Integrating 237

256 The created IdML book is stored at the location which you configured on the Discovery Library Adapter tab in the end-to-end configuration tool. On the same tab you can configure to copy the IdML book to a remote TBSM server. Naming conventions: Names of IdML books that are created by System Automation Application Manager start with the application code EEZ, followed by the host name of the system on which the automation manager is installed and an UTC timestamp. Example: EEZ3210.e2esrv1.friendly.com T Z.refresh.xml Importing a System Automation Application Manager IdML book into TBSM: If the Discovery Library Toolkit service is running, it automatically consumes IdML books available in a specific directory on the TBSM server. You can configure the specific directory using the Discovery Library Toolkit. The default directory for the location of IdML books is: $TBSM_HOME/discovery/dlbooks The System Automation Application Manager DLA can either be configured to automatically save its IdML books in that directory on the TBSM server or the resulting IdML book needs to be manually copied to that location. The Discovery Library Toolkit service consumes the IdML book from System Automation Application Manager and populates the service component registry with System Automation Application Manager resources. The processing of the IdML book can be validated by checking the msggtm_xt.log file for a message that is similar to the following: GTMCL5290I: Book EEZ3210.p720sa02.boeblingen.de.ibm.com T Z. refresh.xml processed successfully. The default directory for the location of the log file is: v UNIX: $TBSM_HOME/XMLtoolkit/log v Windows: %TBSM_HOME%\XMLtoolkit\log Note: The DLA Toolkit service can be started in the following way: v UNIX: Start the Discovery Library Toolkit daemon by running the tbsmrdr_start.sh script in the $TBSM_HOME/XMLtoolkit/bin directory. The daemon is added to the etc/init.d directory and is automatically restarted if you restart the TBSM host. v Windows: Start the Discovery Library Toolkit service from the Services window or by issuing the net start ASICRToolkitSvc command. Verifying imported services: You can use the following procedure to verify that the service instances are imported correctly into the Service Component Registry : 1. Select Administration > Service Administration in the Tivoli Integrated Portal console task list. 238 Tivoli System Automation Application Manager V : Installation and Configuration Guide

257 2. Select Service Component Repository from the pull-down menu in the Service Navigation portlet. 3. Expand Component Repository > Business Services. The imported end-to-end automation domains and resources are displayed below the Business Services entry. You can expand the domains and resource groups to verify that the group hierarchy has been created correctly. 4. Expand the end-to-end automation domain corresponding to the IdML book which has been imported. Select one of the contained top-level resources. 5. Select the Edit Service tab in the Service Editor portlet to edit the service. 6. Select the Templates tab and verify that the service template EEZ_SystemAutomationResource is listed in the Selected Templates list. 7. Select the Identification Fields tab and verify that for the incoming status rules of the EEZ_SystemAutomationResource template, the AlertKey field has a value corresponding to the resource s source token. For example EEZResourceKey,DN={E2E_Domain},NN={},RN={Online Trading Application},RC={ResourceGroup} 8. Select the Additional tab and verify that the sourcecontactinfo and sourcetoken attributes for System Automation Application Manager are set correctly. 9. If the services have been imported correctly, a resource status event of System Automation Application Manager influences the TBSM state displayed in the service tree. You can test this, for example by stopping a group member defined in the end-to-end automation domain using the operations console. The group should then show a Warning state in TBSM based on the compound state changes of the group. Adding imported services to a service model: Once the System Automation Application Manager IdML book is processed and the service component registry (SCR) is populated, the objects created in the SCR can be used to create a business service in TBSM depending upon the requirement of the service model: 1. Select Administration > Service Administration in the Tivoli Integrated Portal console task list. 2. In the Service Navigation portlet, create a new top-level service instance as container for the imported System Automation services. Or select an existing service instance as parent of the new System Automation resources. 3. Select the Edit Service tab in the Service Editor portlet to edit this service. 4. Select the Dependents tab and click the Add from Service Component Repository button. The Service Tree window opens. 5. Expand Component Registry > Business Services > <your end-to-end automation domain>. 6. Select the top-level resource groups that you want to add to your service model. They will be added as children of the container service that you created in step When you have finished adding services, close the Service Tree popup window and save the service instance. Chapter 4. Integrating 239

258 Assigning manually the service template to a service instance If you want to add System Automation resources to TBSM which are not part of the end-to-end automation policy, for example resources managed by System Automation for Multiplatforms, create manually a service instance in TBSM and then assign the System Automation Service Template. You also do this if you want to enrich service instances which already exist in a TBSM service tree with information from System Automation events. A service template consists of rules that can be applied for service instances. A template can be used for more than one instance. If you want to assign the EEZ_SystemAutomationResource template to a service, you can tag the service with the template. Proceed as follows: 1. Tag services using the EEZ_SystemAutomationResource template to make the defined incoming status rules available to these services. a. In the Service Navigation portlet, select the Service Name for which you want to assign the System Automation specific service template EEZ_SystemAutomationResource. b. Select the Edit Service tab in the Service Editor to edit the service. c. Select the Templates tab. You can see the following two lists: v Available Templates: Displays all templates which you have the permission to assign to the selected service instance. v Selected Templates: Displays all templates assigned to the service. d. To assign the System Automation template to a service, select the EEZ_SystemAutomationResource template from the Available Templates list. Click the arrow button >> to move the template to the Selected Templates list. 2. Configure the Identification Field values for this service. TBSM uses the Identification Fields to map incoming events to a service instance. a. Select the Edit Service tab. b. Select the Identification Fields tab which provides the rules defined in the EEZ_SystemAutomationResource template and the identification field values required to map an event to the selected service instance. 240 Tivoli System Automation Application Manager V : Installation and Configuration Guide

259 Figure 24. Identification Fields tab The rules contained in the EEZ_SystemAutomationResource template use the AlertKey event attribute as identifier. By default, the value for each identification field is the value entered in the Service Name field. c. Enter the correct AlertKey attribute value that corresponds to the selected service. The AlertKey must contain the unique System Automation resource key formatted as CDM SourceToken. The structure is defined like this: EEZResourceKey,DN={DomainName},NN={NodeName},RN={ResourceName}, RC={ResourceClass} You may consider to open one of the events of the resource and copy and paste the AlertKey value from the event to avoid typing errors. Examples for valid AlertKey values: 1) Resource: System Automation for Multiplatforms constituent or fixed resource Domain: DB2Cluster Displayed by lssam as: IBM.Application:db2-rs:saxb32c AlertKey: EEZResourceKey,DN={DB2Cluster},NN={saxb32c},RN={db2- rs}, RC={IBM.Application} 2) System Automation for Multiplatforms move group (floating resource) Domain: DB2Cluster Displayed by lssam as: IBM.Application:db2-rs AlertKey: EEZResourceKey,DN={DB2Cluster},NN={},RN={db2- rs},rc={ibm.application} 3) System Automation for Multiplatforms resource group Domain: DB2Cluster Displayed by lssam as: IBM.ResourceGroup:DB2 AlertKey: EEZResourceKey,DN={DB2Cluster},NN={},RN={DB2}, RC={IBM.ResourceGroup} Chapter 4. Integrating 241

260 4) Resource: System Automation Application Manager resource group Domain: E2E_Domain Displayed by the operations console as: Online Trading Application AlertKey: EEZResourceKey,DN={E2E_Domain},NN={},RN={Online Trading Application}, RC={ResourceGroup} 5) Resource: System Automation Application Manager resource reference Domain: E2E_Domain Displayed by the operations console as: DB2 and the referenced resource is located in the first-level automation domain DB2Cluster AlertKey: EEZResourceKey,DN={E2E_Domain},NN={DB2Cluster},RN={DB2}, RC={ResourceReference} Note: The referenced first-level automation domain must be used as node name of the AlertKey (NN={FLA-Domain}) 6) Resource: System Automation Application Manager choice group Domain: E2E_Domain Displayed by the operations console as: DB2 CG AlertKey: EEZResourceKey,DN={E2E_Domain},NN={},RN={DB2 CG},RC={ChoiceGroup} d. Click the Additional tab for the service instance. The tab shows the additional attributes defined for this service instance. The attribute IBM_Tivoli_System_Automation_Application_Manager_sourceToken is used for the launch-in-context action that supports launching from TBSM to the System Automation operations console. e. Overwrite the attribute value for IBM_Tivoli_System_Automation_Application_Manager_sourceToken to contain the System Automation source token that corresponds to this service instance. This is the same value that has been specified for the AlertKey attributes on the Identification tab. f. Click Save to apply your changes. Whenever new System Automation state change events are received for the service which match the specified AlertKey, TBSM will now process the incoming status rules and potentially change the overall state of the service based on the event severity. Customizing TBSM views to add information from System Automation The EEZ_SystemAutomationResource Service Template contains text-based Incoming Status Rules which retrieve the System Automation Observed State and other System Automation specific states of a resource. This information can be used in TBSM Views in order to enrich service instances with information coming from System Automation. The following text-based incoming status rules are available: 242 Tivoli System Automation Application Manager V : Installation and Configuration Guide

261 Table 51. Text-based incoming status rules for TBSM Rule Name SAObservedStateValue SADesiredStateValue SAOperationalStateValue SACompoundStateValue SAExcludedFromAutomationValue Description Retrieves the field SAObservedState from a resource status change event. Possible values: v v v v v v Unknown Online Offline Starting Stopping NotApplicable Retrieves the field SADesiredState from a resource status change event. Possible values: v v v Online Offline NoChange (i.e. the resource s automation goal cannot be changed by an operator) Retrieve the field SAOperationalStateValue from a resource status change event. List of Operational State values giving more fine-grained information about the current state of the resource. For a list of possible values, see the SystemAutomation.baroc file. Retrieve the field SACompoundStateValue from a resource status change event. Compound state indicating whether the resource is working as desired or has encountered an error. Possible values: v v v v Ok Warning Error Fatal Retrieve the field SAExcludedFromAutomationValue from a resource status change event. Flag indicating if the resource is excluded from automation (i.e. automation is suspended). Possible values: v NotExcluded v Excluded You can modify the columns of custom trees displayed in TBSM in the v Service Navigation portlet v Service Tree portlet The default Service Navigation portlet has three columns: v State v Time v Events Chapter 4. Integrating 243

262 You can modify, delete, and add tree columns with the Tree Template Editor. The Tree Template Editor is available from the Services toolbar in the Service Navigation portlet. You can add a new tree template to the Service Navigation portlet. For each custom column, use the Tree Template Editor to specify the rule data you want to display in the column. Adding columns: This capability can be used to add columns for any of the provided text-based incoming status rules defined by the EEZ_SystemAutomationResource template. For example, you can define a column which displays the current Observed State coming from System Automation for each service instance that has the EEZ_SystemAutomationResource template assigned. Perform the following steps: 1. Click the Tree Template Editor button in the toolbar of the Service Navigation portlet. 2. Select the tree template you want to modify in the Tree Template Name drop-down list. 3. Click the Add New Tree Column button in the Column Configuration section. 4. Type the name you want to use in the blank field for the new column, for example Availability State. 5. Adjust the column position and width as appropriate 6. In the Service Template Selection section, select the EEZ_SystemAutomationResource template. 7. In the Service Template Rule Mapping, select the EEZ_SystemAutomationResource template in the Active Template list. 8. For each rule that you want to display in a service tree column, select the Display check box and choose a column from the drop-down box to display the output value. In this example, select the Display check box for the and choose the Availability State column from the drop-down box of that row. 9. Click OK to save the changes to the tree template. The following figure shows a screen capture of the tree template editor. A new column Availability State is added showing the System Automation Observed State: 244 Tivoli System Automation Application Manager V : Installation and Configuration Guide

263 Figure 25. Tree template editor To view the updated Services Tree, refresh the Service Navigation portlet. The new column now occurs showing the output of the incoming status rule that you have selected. Note: You have to create new resource status change events in order to update the state information displayed in TBSM. Old events are not processed again. Using the TBSM policy editor: Optionally, you can format column values using the TBSM policy editor. For example, display the SAObservedState values in different colors. Proceed as follows: 1. Click the Tree Template Editor button in the toolbar of the Service Navigation portlet. 2. Choose the tree template you want to modify from the Tree Template Name drop-down list. Chapter 4. Integrating 245

264 3. Click on the Edit Policy... button to open the policy that displays column values. The policy named GetTreeColumnValue is opened in the policy editor: 4. Modify the policy. The following code snippet is as an example on how to change the color of the text-based output values. In this example, it is assumed that a column named Availability State has been defined showing the output of the SAObservedState Rule. Depending on the value of the observed state, the policy snippet returns the value in a different color: if (columnname = Availability State ) { if (value = Unknown ) { VALUE = <font color="blue"> <b>unknown</b></font> ; } if (value = Online ) { VALUE = <font color="green"> <b>online</b></font> ; } if (value = Offline ) { VALUE = <font color="red"> <b>offline</b></font> ; } if (value = Stopping ) { VALUE = <font color="blue"> <b>stopping</b></font> ; } if (value = Starting ) { VALUE = <font color="blue"> <b>starting</b></font> ; } } 5. Save the modified policy Configuring Tivoli Business Service Manager launch-in-context support You can define a launch-in-context entry for a TBSM service tree that enables you to launch the System Automation operations console in context of the currently selected service instance. Refer to From TBSM to System Automation on page 247 for more information. You can also set up launch-in-context support to launch from a resource displayed in the System Automation operations console to the TBSM Web user interface. Refer to From System Automation to TBSM for more information. From System Automation to TBSM You can set up launch-in-context support to launch from a resource displayed in the System Automation operations console to the TBSM web user interface. This launch-in-context support enables users to launch the Service Availability Workspace of the Tivoli Integrated Portal and automatically select the corresponding service instance in the TBSM Service Viewer with a single mouse click. When TBSM launch-in-context support is configured, a hyperlink becomes available in the System Automation operations console on the General page of those resources that are contained in an end-to-end automation domain. This hyperlink navigates to the corresponding service instance in the TBSM Service Viewer. 246 Tivoli System Automation Application Manager V : Installation and Configuration Guide

265 Note: The TBSM launch-in-context support is only available for resources which have been imported into TBSM using the Discovery Library Toolkit. Perform the following steps to configure TBSM launch-in-context support for the System Automation operations console: Procedure 1. Logon to the IBM Dashboard Application Services Hub on the system where System Automation Application Manager is installed. 2. Navigate to Tivoli System Automation -> Settings -> TBSM Launch-in-Context Configuration 3. Select to enable launch-in-context support in the Enable launch-in-context support for TBSM. 4. Specify the name of the server on which the Tivoli Integrated Portal runs, which hosts the TBSM web GUI, in the Server name used to connect to Tivoli Integrated Portal field. 5. Specify the secure port number of the server on which Tivoli Integrated Portal runs in the Port number used to connect to Tivoli Integrated Portal. The default port number is Click OK to save the configuration Results Note: If the operations console is displayed while the TBSM launch-in-context configuration is changed, select Menu -> Refresh all to pick up the changed settings in the current instance of the operations console. From TBSM to System Automation The launch-in-context action uses the following attributes of a service that must be stored in a service s additional attributes in order to be able to perform the launch: v IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo This attribute contains the launch URL including the host name and the port number of the System Automation Application Manager. v IBM_Tivoli_System_Automation_Application_Manager_sourceToken This attribute contains the unique source token attribute as defined by the System Automation Application Manager DLA. It represents the resource key identifying the System Automation resource corresponding to this service instance. For example: EEZResourceKey,DN={FriendlyE2E},NN={},RN={DR_Portal},RC={ResourceGroup} For System Automation Application Manager resources contained in an end-to-end automation policy which are imported using the Discovery Library Toolkit, both attributes are automatically filled with the right values when importing the DL book into TBSM. If the resource is manually created without the DLA Toolkit or for System Automation for Multiplatforms resources (for which no DLA exists), these attributes must be manually created in a service s additional attributes if Launch-in-Context to System Automation is to be exploited. Chapter 4. Integrating 247

266 Specify the sourcetoken field for each service instance that has not been imported via Discovery Library Toolkit. Refer to Assigning manually the service template to a service instance on page 240 for more information. The sourcecontactinfo field can be specified in the EEZ_SystemAutomationResource Service Template because it contains generic information which is valid for all System Automation resources. The additional attribute IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo contains the URL of the System Automation Application Manager host to which the launch-in-context action will connect. If you want to use launch-in-context for services which have been manually tagged with the EEZ_SystemAutomationResource template, you need to manually adapt the URL in the Service Template. This is not required if you only have services that are imported using the Discovery Library Toolkit. Follow these steps to adapt the EEZ_SystemAutomationResource template for Launch-in-Context: 1. Select Templates from the Service Navigation drop down menu. 2. Select the EEZ_SystemAutomationResource template in the Service Navigation portlet 3. Click the Edit Template tab in the Service Editor to edit the template 4. From the Edit Template tab, click the Additional tab. 5. The parameter IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo has the default value: Replace <SA_ISC_Hostname> with the correct host name of the system where the System Automation Application Manager operations console is running. Also change the port number if required. 6. Click Save to apply your changes Defining launch-in-context action: This topic describes how to define a new launch-in-context action for a custom service view in TBSM, which will appear in the context menu of a service instance. Create a new view definition. The View Definitions feature of TBSM allows you to change the visual content that is displayed in your Service Editor or Viewer portlet and change the values that appear in the visual elements. In addition it allows to define actions. Actions are the options available to you as the result of clicking, double clicking, or right-clicking a service in the Service Editor. You cannot modify the pre-defined View Definitions, therefore you have to create a new View Definition to be able to define a new action: 1. Select Services from the Service Navigation drop down menu. 2. Click a service in the Service Navigation portlet. The default view definition for the service model opens in the Service Editor or Viewer. 3. In the View Service tab, select the view definition you want to work with from the View Definition drop-down list. 248 Tivoli System Automation Application Manager V : Installation and Configuration Guide

267 4. Click the Edit View Definition button. The Edit View Definition window opens. 5. To create a view definition, click Save as New. The Save As window opens. 6. Type the name of your view definition in the Save as New field and click OK. A new launch-in-context action needs to be defined to the new view definition. Add the System Automation launch-in-context action to the System Automation specific service template EEZ_SystemAutomationResource, so that the launch-in-context action is only available to services tagged with this template: 1. In the View Definition drop-down list, select your View Definition and click the Edit View Definition button to reopen the Edit View Definition window. 2. Click the Actions tab in the Edit View Definition window. The Actions tab opens. 3. Select the EEZ_SystemAutomationResource template from the Service Template drop-down list. 4. To add a new action, click the Edit button next to the Edit Action selection list. The Edit Canvas Action window opens. 5. Define a new Action using the following parameters: Table 52. Launch-in-context action parameters Attribute Action Name Action Display Name Action Description Action URL Action Frame Value ShowSAResource Show Service in System Automation operations console Launch the service in the Tivoli System Automation operations console IBM_Tivoli_System_Automation_Application_Manager_ sourcecontactinfo?sourcetoken= URLEncode(IBM_Tivoli_ System_Automation_Application_Manager_sourceToken) SystemAutomation 6. Click OK 7. Add the new action to the context menu. You have two options: a. If you want the launch menu entry to be visible only for services that have the EEZ_SystemAutomationResource template assigned as primary template, select the EEZ_SystemAutomationResource template from the Service Template drop-down list. b. If you want the launch menu entry to be always visible for all kinds of services, click on the Set Defaults button. Note: If you have assigned the EEZ_SystemAutomationResource to services that have been tagged with a different primary template, you have to use option b) to be able to use the launch-in-context action for these services. 8. To add the new action as a right-click action, click the New button to add a new row to the right click menu options action list. A blank row is added to the Actions list. 9. Select the new action from the drop-down list. 10. Click Apply to save the action. 11. Click OK to close the Edit View Definition window. Exporting System Automation specific additional attributes for use in LiC Action: Chapter 4. Integrating 249

268 By default, TBSM provides a set of attributes to use for actions. The following attributes are not available to use for launch-in-context actions: v IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo v IBM_Tivoli_System_Automation_Application_Manager_sourceToken To make the actions available, you need to edit the.xml file for the view definition. Add an fieldtopasstomodelexpr tag for each attribute that you want to use in the action. Refer to the example for a fieldtopasstomodelexpr tag below. The following directory contains the xml files that configure view definitions: v UNIX: $TBSM_DATA_SERVER_HOME/av/xmlconfig v Windows: %TBSM_DATA_SERVER_HOME%\av\xmlconfig View definition xml files have the following format: ViewDefinition_<ViewDefName>.xml ViewDefName is the name of the view definition in the TBSM console. For example, the name of the file for a custom view definition called MyView is: ViewDefinition_MyView.xml To enable the launch-in-context action, add the following elements to the <datatypemapping> element in the view definition xml file: <fieldtopasstomodelexpr modelfield="ibm_tivoli_system_automation_application_manager_sourcecontactinfo"> IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo</fieldToPassToModelExpr> <fieldtopasstomodelexpr modelfield="ibm_tivoli_system_automation_application_manager_sourcetoken"> IBM_Tivoli_System_Automation_Application_Manager_sourceToken</fieldToPassToModelExpr> This will make the two attributes available to use in the launch-in-context action. Note: You have to restart the Tivoli Integrated Portal Server to activate this change in TBSM. Integration scenarios with Business Service Manager If you integrate System Automation Application Manager with Business Service Manager, you can exploit scenarios like "Automatic recovery of a DB2 failure" or "Planned maintenance of an online application". The integration solution of Tivoli System Automation Application Manager and Tivoli Business Service Manager (TBSM) allows you to: v Visualize service scorecards, key performance indicators, and service level agreements of business applications in TBSM. Use Tivoli System Automation Application Manager to control and automate these business applications, and to provide automatic recovery of failure situations. v Use data from System Automation events to enrich TBSM service views with information from System Automation. System Automation Application Manager delivers a TBSM service template containing pre-configured rules about how to map states from System Automation to TBSM service instances. For example, if a business application was made offline for planned maintenance purposes, TBSM is now aware that this is a scheduled downtime for the business application and not an unexpected failure situation. 250 Tivoli System Automation Application Manager V : Installation and Configuration Guide

269 v Use the Discovery Library Adapter (DLA) to simplify and automate the integration of System Automation Application Manager resources with TBSM. With this approach, System Automation Application Manager resources are automatically imported into a TBSM service model, the correct TBSM status rules are automatically assigned to those services, and System Automation Application Manager events are automatically matched with the correct TBSM service instances without manual configuration. v Launch in context from a TBSM service view to the SA Operations Console and vice-versa. The operator can easily view the information about a specific application from both products. For example, you can use TBSM to monitor the health of a business application. An operator can use the launch in context capability to jump to the SA Operations Console to start or stop this business application. System environment of the integration scenario A typical environment for these scenarios is a multitiered heterogeneous business application, such as the "Online Trading Application" shown in Installation and Configuration Guide. The online trading application consists of one or more web servers in the presentation tier, WebSphere Application Server in the business logic tier, and an IBM DB2 server in the data tier, which is made highly available. Each component runs on a different platform and operating system, and has dependencies with the others. For example, the DB2 server must be started first, followed by the WebSphere Application Server, and lastly, the web servers can be started. Another dependency example is that if the DB2 server must be restarted, then also the WebSphere Application Server and the web servers must be restarted so that the application can resynchronize with DB2. In the integration scenarios described in the following topics, the online trading application is automated and made highly available by using Tivoli System Automation and is monitored by using Business Service Manager. The following diagram illustrates the key products in this solution and how they are used: Chapter 4. Integrating 251

270 Figure 26. Integration of System Automation with Business Service Manager System Automation for Multiplatforms System Automation for Multiplatforms provides monitoring, automation, and high availability of application components. It also provides an availability state displaying whether the application components are online or offline. System Automation Application Manager System Automation Application Manager manages the dependencies between the components across platform borders, provides end-to-end automated operation of the business application, provides recovery in failure situations, and stores information about the aggregated availability state of the entire business application. Tivoli Netcool/OMNIbus Tivoli Netcool/OMNIbus is used to collect all events related to the business application landscape. System Automation provides a rules file which processes the events and prepares them for use in Business Service Manager. Business Service Manager Business Service Manager displays the business application as a service tree. TBSM uses the events from Netcool/OMNIbus to provide health information about the business application and to provide business impact analysis. The TBSM Service Availability page displays the online trading application" which is monitored and managed by System Automation Application Manager: 252 Tivoli System Automation Application Manager V : Installation and Configuration Guide

271 Figure 27. TBSM Service Availability Page The Service Tree displays at the top level the Online Trading Application" business application. The DB2, IHS (IBM HTTP Server) and WebSphere Application Server components are shown as children of the application. The DB2 component is made highly available in a High Availability Cluster managed by System Automation for Multiplatforms. Therefore, the DB2 service has two children that include the two DB2 instances in the HA Cluster: one that is currently online and the active DB2 instance, and one which is currently offline, which is the backup DB2 instance. The Service tree displays four status columns that present information from System Automation: State The overall state of the service, which can be Bad (red), Good (green), or Marginal (yellow). This information is derived from the SACompoundState of the corresponding System Automation resource. Availability State The currently observed run state of the service, which shows whether the service is currently online, offline, starting, or stopping. Desired State Represents the automation goal of the service, which can be either Online or Offline. This state is the status in which Tivoli System Automation tries to keep the service. If it matches the Availability State, the overall state is green. Automation Suspended Indicates whether the automation is suspended for the service. If the automation is suspended, Tivoli System Automation temporarily stops trying to reach the Desired State, but continues to monitor the Availability State. In the TBSM Service Availability Page, the overall state for the DB2 backup instance is green even if the service is not running. The backup instance is Chapter 4. Integrating 253

272 displayed as green because it is a cold standby that is started only if the primary DB2 instance has a failure. The backup instance state is intended to not be running and the operator is not required to take any action. The knowledge of planned versus unplanned offline state is a capability provided by System Automation events, which is displayed in the TBSM overall state of the service. The following sections describe two sample usage scenarios for this integration solution. For further information about configuring this integration, see System Automation Application Manager Installation and Configuration Guide. Scenario 1: Automatic recovery of a DB2 failure In this scenario, assume that the current DB2 instance has a failure. Tivoli System Automation detects the failure and attempts to restart the DB2 instance. If the restart attempt is not successful, a failover is initiated and the DB2 instance is started on the other node in the high availability cluster. You can monitor this situation in the TBSM Service Tree: Figure 28. TBSM Service Tree Note that the DB2 instance that previously was online on node saxb33e now shows a problem state and is Offline. The other DB2 instance on node saxb32c is currently being started by Tivoli System Automation. Due to the failover of DB2, System Automation Application Manager also restarts IHS and WebSphere Application Server because there is a "forceddownby" dependency defined in the System Automation Application Manager policy. As a result of this dependency, both IHS and WebSphere Application Server have a Desired State set to Offline. As part of the recovery action, IHS and WebSphere Application Server are stopped while DB2 is made Online on node saxb32c in the High Availability cluster. Then the automation starts WebSphere Application Server first, then starts IHS. All components are up and running again: 254 Tivoli System Automation Application Manager V : Installation and Configuration Guide

273 Figure 29. TBSM Service Tree Tivoli System Automation has automatically recovered the DB2 failure situation by performing a failover of DB2 and by restarting the dependent WebSphere Application Server and IHS. When the business application is running again, the administrator can fix the problem causing the DB2 instance failure on node saxb33e so that DB2 is highly available again. Scenario 2: Planned maintenance of an online application In this scenario an operator needs to shut down the Online Trading Application" for maintenance reasons. The operator can do this by starting from the Business Service Manager graphical user interface and performing the following steps: 1. In the Business Service Manager Service Viewer, the operator opens the context menu of the "Online Trading Application" service and selects the menu entry "Show Service in System Automation operations console" : Chapter 4. Integrating 255

274 Figure 30. TBSM Service Viewer 2. The System Automation operations console is launched: Figure 31. Tivoli System Automation operations console The System Automation operations console displays topology information (Clusters/Systems) and information about the automated service instances. It displays the same service "Online Trading Application", which is already selected with details about the service in the Information Area. The Information Area lists status information and gives operational control. 256 Tivoli System Automation Application Manager V : Installation and Configuration Guide

275 3. the operator now clicks the "Request Offline" button to shut down the entire "Online Trading Application". This request is processed by the System Automation Application Manager automation engine which stops all components in the correct sequence. 4. The operator switches back to the "Service Availability" workspace to monitor the shut down of the application components also from Business Service Manager. The operator uses the "Open Service in TBSM" link which opens the Service Availability workspace and selects the Online Trading Application in the TBSM Service Viewer. The automation stops WebSphere Application Server, and finally DB2, in accordance with the defined stop dependencies. Finally, everything is shut down: Figure 32. Tivoli System Automation Operations Console The state color of the "Online Trading Application" and its components is green even though the service is not running. This indicates that it was intentionally shut down by an operator and it is not an unplanned failure situation. This knowledge can be delivered by using the SACompoundState to determine the overall state of service instances. Tivoli Monitoring and Tivoli Composite Application Manager The Tivoli Monitoring (Tivoli Monitoring) and Tivoli Composite Application Manager (ITCAM) family provides availability and performance monitoring of essential system resources and applications on a wide variety of operating systems and platforms. System Automation Application Manager can be used to control and automate resources, which are monitored by Tivoli Monitoring or ITCAM. System Automation Application Manager integrates with Tivoli Monitoring and ITCAM by using existing Tivoli Monitoring resource instrumentation (Tivoli Monitoring agents). The System Automation Application Manager retrieves monitoring information from Tivoli Monitoring agents and executes start and stop operations using Tivoli Monitoring agents. Software components, which were only monitored by Tivoli Monitoring can be resources that are managed by System Chapter 4. Integrating 257

276 Automation Application Manager. Tivoli Monitoring resources can be automated members of complex business applications within System Automation Application Manager policies. Tivoli Monitoring delivers a wide variety of agents that can integrate with System Automation Application Manager: v Application agents (also referred to as non-os agents), including custom agents v OS agents System Automation Application Manager provides predefined templates for the integration of the following agents: v Apache web Server v WebSphere Application Server v DB2 v Custom agents, which are built by the Tivoli Monitoring Agent Builder v Linux OS agent v UNIX OS agent Use the policy editor to create resource definitions for Tivoli Monitoring resources based on these templates or for any other Tivoli Monitoring agent type using the generic Tivoli Monitoring resource support. For a complete overview, and about the advantages of the Tivoli Monitoring integration, see System Automation Application Manager Administrator's and User's Guide, Integrating with Tivoli Monitoring and Tivoli Composite Application Manager". Prerequisites Supported Tivoli Monitoring versions for this feature are: IBM Tivoli Monitoring 6.1, 6.2.1, and Tivoli Monitoring overview The following illustration gives an overview of a typical Tivoli Monitoring management infrastructure with all its components in order to introduce terms that are used later in this document. For a more detailed description of this infrastructure, see the Tivoli Monitoring Knowledge Center. 258 Tivoli System Automation Application Manager V : Installation and Configuration Guide

277 Figure 33. Overview of the IBM Tivoli Monitoring infrastructure The IBM Tivoli Monitoring architecture is a multi-tiered client/server environment consisting of the following four main components that monitor mission critical systems throughout the enterprise: v The Tivoli Enterprise Portal (TEP) Client is a presentation interface that is browser or desktop (thick client) based and is used to view and monitor the enterprise. v The Tivoli Enterprise Portal Server provides the core presentation layer for retrieval, manipulation, analysis, and pre-formatting of data. The portal server retrieves data from the hub Tivoli Enterprise Monitoring Server monitoring server in response to user actions at the portal client, and sends the data back to the portal client for presentation. The portal server also provides presentation information to the portal client so that it can render the user interface views suitably. v The Tivoli Enterprise Monitoring Server acts as a collection and control point for alerts received from the agents, and collects their performance and availability data. The monitoring server also manages the connection status of the agents. Large-scale environments usually include a number of monitoring servers to distribute the load. One of the monitoring servers is designated the hub monitoring server, and the remaining servers are termed remote monitoring servers, often called RTEMS. The hub monitoring server also provides a SOAP interface which can be used to query Tivoli Monitoring data and issue commands via Tivoli Monitoring agents on the endpoints. The SOAP interface is also used for the integration of System Automation Application Manager with Tivoli Monitoring to retrieve monitoring information from the agents and to perform start and stop commands on the endpoints. v The Tivoli Enterprise Monitoring Agents (TEMA) are installed on the systems or subsystems you want to monitor. These agents collect data from monitored, or managed, systems, and distribute this information to a monitoring server. v Tivoli Data Warehouse which is used for storing historical data collected from agents in the environment. To store data in this database, you must install the Warehouse Proxy agent. To perform aggregation and pruning functions on the Chapter 4. Integrating 259

278 data, you must also install the Summarization and Pruning agent. The Data Warehouse component is not required for the System Automation Application Manager integration. The Tivoli Enterprise Monitoring Agents (TEMA) can be of the following types: v Application agents (non-os agents) that monitor the availability and performance of systems, subsystems, and applications. Those agents often include predefined commands to start and stop the managed application. An example of an application agent is IBM Tivoli Composite Application Manager Agent for WebSphere Applications, which monitors WebSphere Application Server instances. You can also create your own application agents via the Agent Builder, a set of tools for creating custom agents. Using the Agent Builder, you can quickly create, modify, and test an agent to collect and analyze data about the state and performance of different resources, such as disks, memory, CPU, or applications. v Operating system (OS) agents that monitor the availability and performance of the operating systems (computers). An example of an OS agent is the Monitoring Agent for Linux OS, which monitors end points running a Linux operating system. Every Tivoli Monitoring agent has a two letter product code uniquely identifying the agent type. Some examples are: v HT IBM Tivoli Composite Application Manager Agent for web servers v UD IBM Tivoli Composite Application Manager Agent for DB2 v YN IBM Tivoli Composite Application Manager Agent for WebSphere Applications v LZ Linux Monitoring Agent v NT IBM Tivoli Monitoring for Windows Servers v UX UNIX OS Monitoring Agent Custom agents have a product code within the reserved range System Automation Application Manager uses the agentless adapter to integrate with the Tivoli Monitoring infrastructure. For more information about the agentless adapter, see System Automation Application Manager Administrator's and User's Guide, "Product Overview, Concepts and components, Using the agentless adapter to access Tivoli Monitoring Resources. For information about starting and stopping Tivoli Monitoring managed resources, see System Automation Application Manager Administrator's and User's Guide, " Starting and Stopping Tivoli Monitoring managed Resources". For information about monitoring resources managed by Tivoli Monitoring, see System Automation Application Manager Administrator's and User's Guide, "Administering, Defining Tivoli Monitoring (ITM) Resources". Integrating with System Automation Application Manager The integration of Tivoli Monitoring managed applications into System Automation end-to-end management: is a step by step process. The required steps are: 260 Tivoli System Automation Application Manager V : Installation and Configuration Guide

279 1. Use the configuration dialog cfgeezdmn to configure connectivity to the hub Tivoli Enterprise Monitoring Server, define a domain, and add users that can access the Tivoli Monitoring SOAP server. 2. Create a System Automation Tivoli Monitoring resource in the agentless adapter policy using the policy editor. v v For an application agent for which a template is provided, create a new Tivoli Monitoring resource based on this template directly from the context menu of the policy editor. Definitions are already made for the resource and only minimal modifications are required to adapt the resource to your environment, for example, modify the managed system name to match your target endpoint. For other agents, gather the following information to create a new System Automation Tivoli Monitoring resource definition in the agentless adapter policy: Managed System Name of the agent. Attribute group and name of the attribute that is used for monitoring. Mapping of the attribute values to the common System Automation observed state. The command that must be used for starting and stopping the managed application. 3. Activate the agentless adapter policy using the operations console. Test that the defined Tivoli Monitoring resource can be started and stopped and that it displays the correct observed state. 4. Add the Tivoli Monitoring resource to the Application Manager end-to-end automation policy by creating a resource reference. Use the resource harvesting wizard in the policy editor, which harvests the Tivoli Monitoring resources that are defined in the agentless adapter domain. 5. Activate the modified Application Manager end-to-end automation policy. These steps are explained in detail in Configuring the agentless adapter for Tivoli Monitoring Integration. Configuring the agentless adapter for Tivoli Monitoring Integration You must perform a sequence of configuration steps to enable the agentless adapter to access the Tivoli Monitoring Tivoli Enterprise Monitoring Server SOAP server to control and monitor Tivoli Monitoring resources. These resources are defined in the adapter automation policy. Use the cfgeezdmn configuration dialog. Log in to the system on which you installed the System Automation Application Manager, and perform the sequence of configuration steps described in the following topics: Procedure 1. Configuring the agentless adapter on page Creating agentless adapter domains for Tivoli Monitoring resources on page Configuring the properties to access the Tivoli Monitoring SOAP server on page Configuring user credentials to access the monitored resources on page 265 Chapter 4. Integrating 261

280 5. Activating the configuration changes on page 266 Configuring the agentless adapter: If you already configured an agentless adapter instance (local or remote) and you want to use it to monitor and control Tivoli Monitoring resources, you can skip this step. Otherwise refer to Configuring access to non-clustered nodes on page 127 for instructions on how to configure an agentless adapter. If you want to use multiple Agentless Adapter instances to control Tivoli Monitoring resources, you must perform the tasks that are described in the following sections for each of those agentless adapter instances. You can define multiple domains for one agentless adapter, which eliminates the need to use more than one agentless adapter instance. Use the cfgeezdmn configuration utility to perform the following steps: Procedure 1. Open the configuration dialog using the cfgeezdmn command. The task launcher of the configuration dialog is displayed. 2. Select the Non-clustered Nodes tab. 3. If you want to enable the integration of Tivoli Monitoring resources for the local agentless adapter, click the Configure button for the local agentless adapter. If you want to enable the integration of Tivoli Monitoring resources for a remote agentless adapter, click Configure for remote agentless adapters and select the remote agentless adapter instance that you want to configure. The agentless adapter configuration dialog opens: 262 Tivoli System Automation Application Manager V : Installation and Configuration Guide

281 Figure 34. Application Manager Local Agentless Adapter Configuration Creating agentless adapter domains for Tivoli Monitoring resources: To create agentless adapter domains for Tivoli Monitoring resources perform these steps: Procedure 1. Open the agentless adapter configuration as described in Configuring the agentless adapter on page On the Adapter tab of the configuration dialog, click Add. Choose a domain name in the dialog that is displayed, for example ITMDomain, and click OK. The new domain is displayed in the domain list of the configuration window. If you want to define multiple domains to contain Tivoli Monitoring resources, use this dialog to define them. Chapter 4. Integrating 263

282 Configuring the properties to access the Tivoli Monitoring SOAP server: Complete the following steps to configure the connection between the agentless adapter and the Tivoli Monitoring SOAP server. The configuration changes must be applied to the agentless adapter instance (local or remote) determined in the preceding tasks. Procedure 1. Open the agentless adapter configuration as described in Configuring the agentless adapter on page Click on the Tivoli Monitoring tab: 3. On the Tivoli Monitoring tab, select Enable integration of ITM/ITCAM resources and specify the values for the Tivoli Monitoring SOAP server configuration: 264 Tivoli System Automation Application Manager V : Installation and Configuration Guide

283 Host name or IP address Specify the name or the IP address of the host where the hub monitoring server that hosts the SOAP service is running. SOAP server port number Specify service point port number of the SOAP server hosted by the hub monitoring server. The default number for a non-ssl port is The default number for an SSL port is If you selected to use Secure Socket Layer (SSL) for communication with the SOAP server, you must specify a valid SSL port number. SOAP alias of hub Specify the alias name of the hub monitoring server to which a SOAP request is routed. The request is routed to the hub monitoring server which is on the same system as the SOAP server. In this configuration, you must specify SOAP as the alias. If you want to route the SOAP request to a remote hub, specify the alias name of the remote hub. This alias must be previously defined to the SOAP server in the Tivoli Monitoring SOAP server configuration. Use SSL for communication with the SOAP server Select this option if the agentless adapter uses Secure Socket Layer (SSL) for communication with the SOAP server. If you select this option, you must specify a valid SSL port number in the SOAP server port field. The https protocol is used for communication. Configuring user credentials to access the monitored resources: Any start / stop command or monitor query against an Tivoli Monitoring agent is translated into a SOAP request to the Tivoli Monitoring SOAP Server on the hub monitoring server. For each SOAP request, the agentless adapter authenticates against the SOAP server using a user name and password. You can define a generic user ID which is used for all Tivoli Monitoring resources for which no user ID is specified in the agentless adapter policy. You can also define specific user IDs if you want to use different users for Tivoli Monitoring resources. In this case, you must specify a user ID for the Tivoli Monitoring resource in the agentless adapter policy. You must also define the user credentials in the list of specific credentials for accessing the SOAP server for each user ID that is specified for a Tivoli Monitoring resource. Important: v All Tivoli Monitoring user IDs defined in the agentless adapter policy and in the configuration utility must be valid Tivoli Monitoring users that can access the Tivoli Monitoring SOAP server. The users are authenticated through the hub monitoring server. Depending on how the monitoring server is configured, user IDs can be authenticated either by the local system registry of the system on which the hub monitoring server runs or by an external LDAP-enabled central registry. v In the Tivoli Monitoring SOAP server configuration, you can define users to a SOAP Server and specify the access privileges for each user: Query or Update. The access privileges control what methods the user is allowed to use. Update access includes Query access. User IDs used by the Agentless Adapter to connect Chapter 4. Integrating 265

284 to the Tivoli Monitoring SOAP Server to start, stop, and monitor remote Tivoli Monitoring resources require the Query access. Complete the following steps to define one or more user credentials used by the agentless adapter when connecting to the hub Tivoli Enterprise Monitoring Server to control or monitor an Tivoli Monitoring resource. Procedure 1. Open the agentless adapter configuration as described in Configuring the agentless adapter on page Select the Tivoli Monitoring tab 3. On the Tivoli Monitoring tab, either specify a generic or a specific user ID or both: a. For specific user IDs, click Add and specify a new user ID and password in the dialog that is displayed. Click OK. The new user is displayed in the list of specific credentials. If you want to use a specific ID, you must specify it for a Tivoli Monitoring resource in the agentless adapter policy. b. For the generic user ID, enter the username in the corresponding entry field and click Change to specify a password for the generic user. This generic user is used for all Tivoli Monitoring resources in the Agentless Adapter policy for which no user ID is specified. If you decide to omit the user ID for at least one of the Tivoli Monitoring resources in the Agentless Adapter policy, you must define a generic user. c. Click Save to save the configuration changes that you applied in the preceding tasks. Activating the configuration changes: By completing the tasks described in the preceding sections, you modified the configuration of an agentless adapter instance and you enabled this adapter to monitor and control Tivoli Monitoring resources. You must now activate the configuration changes by performing these steps: 1. Distribute the changed configuration (only for remote Agentless Adapters) Configurations are generally stored on the system where the System Automation Application Manager is installed. If you decided to use a remote agentless adapter instance for Tivoli Monitoring resource automation, you must distribute the configuration from the system where the System Automation Application Manager is installed to the system where the corresponding agentless adapter is installed. Refer to Distributing a remote agentless adapter configuration on page 138 for a description of this task. 2. Start/restart the agentless adapter All configuration settings are stored in configuration properties files that the Agentless Adapter reads when it is started. If the agentless adapter is already running when you modify the configuration, the adapter must be stopped and restarted to load the new settings. agentless adapters are controlled by using the eezaladapter command. Use eezaladapter start to start the adapter. If the adapter is you must stop the adapter using eezaladapter stop, then start it. Refer to System Automation Application Manager Reference and Problem Determination Guide for details on the eezaladapter command. 266 Tivoli System Automation Application Manager V : Installation and Configuration Guide

285 Creating a Tivoli Monitoring resource in an agentless adapter policy To complete the steps to create the Tivoli Monitoring resource, retrieve information about your managed resources. These steps are described in Retrieving the required information about your Tivoli Monitoring managed resources on page 272 and subsequent topics. Creating an agentless adapter policy for Tivoli Monitoring resources: This topic describes how to create a policy for an Agentless Adapter domain which contains Tivoli Monitoring resources. The policy pool directory for the agentless adapter contains a template policy file which can be used to create a new Agentless Adapter policy automating Tivoli Monitoring resources. The policy template file is named SampleITMResourcePolicy.xml and is located in the agentless adapter policy pool directory. XML source of the policy template: <?xml version="1.0" encoding="utf-8"?> <AutomationPolicy version="1.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" EEZALPolicy.xsd"> <PolicyInformation> <PolicyName>Template For ITM Resource In agentless adapter Domain</PolicyName> <!-- Replace domain$ with agentless adapter Domain Name --> <AutomationDomainName> domain$</automationdomainname> <PolicyToken> 0.0 </PolicyToken> <PolicyAuthor>Author of this policy</policyauthor> <PolicyDescription>This is a template.</policydescription> </PolicyInformation> <!-- *********************************************************************************** --> <!-- Use this template to create a policy for an agentless adapter domain to use ITM --> <!-- monitored resources in SA management. --> <!-- --> <!-- It is recommended not to mix resources of type IBM.RemoteResource and --> <!-- IBM.ITMResource together in one policy. Policies only defining IBM.RemoteResources --> <!-- can be easier created using the built-in SA Application Manager Policy Editor. --> <!-- --> <!-- Use the following section to copy from. Paste the IBM.ITMResourceAttributes and --> <!-- Resource description fields below and adapt them to your needs. --> <!-- *********************************************************************************** --> <IBM.ITMResourceAttributes name="itmagentresourceattributes" > <Owner>John Doe</Owner> <InfoLink> <Description>Some short description for the operator</description> <!-- Replace user$ with the TEMS user to be used for this resource --> <UserName> user$</username> <StartCommand></StartCommand> <StopCommand></StopCommand> <StartCommandTimeout>30</StartCommandTimeout> <StopCommandTimeout>30</StopCommandTimeout> <!-- Replace group$ with the attribute group used for SA state monitoring --> <!-- Replace attribute$ with the name of the attribute used for SA state monitoring --> <MonitorAttribute>$group$.$attribute>$</MonitorAttribute> <!-- Replace online$ with the attribute value that maps to SA state Online --> Chapter 4. Integrating 267

286 <MonitorValueOnline> online$</monitorvalueonline> <!-- Replace offline$ with the attribute value that maps to SA state Offline --> <MonitorValueOffline> offline$</monitorvalueoffline> <MonitorCommandPeriod>10</MonitorCommandPeriod> </IBM.ITMResourceAttributes> <!-- Replace system$ with the ITM Managed System Name --> <Resource name="my SA ITM Resource Name" class="ibm.itmresource" node=" system$"> <ClassAttributesReference> <IBM.ITMResourceAttributes name="itmagentresourceattributes"/> </ClassAttributesReference> </Resource> <!-- *********************************************************************************** --> <!-- Add you resource definitions here. Use sample policy snippets if applicable. --> <!-- *********************************************************************************** --> </AutomationPolicy> Sample policy snippets for commonly used monitoring agents are included in the snippets/itm directory of the System Automation Application Manager policy pool. For example: /etc/opt/ibm/tsamp/eez/policypool/snippets/itm If you want to define a Tivoli Monitoring resource for one of these agents, copy the appropriate policy snippet into your agentless adapter policy and adjust the resource name and managed system name in order to suite your environment. Policy snippets of the agentless adapter policy pool snippets directory: v Snippet_DB2_agent.xml v Snippet_WebSphere_agent.xml v Snippet_Apache_agent.xml v Snippet_custom_agent.xml v Snippet_LinuxOS_agent.xml v Snippet_UNIXOS_agent.xml Refer to IBM Tivoli System Automation Application Manager Reference and Problem Determination Guide, for details about the properties used in the policy snippets. Use an XML editor to modify the provided policy template file and add new Tivoli Monitoring resources. Follow these steps: 1. Copy the file SampleITMResourcePolicy.xml. By default, the file is located in the following directory: /etc/opt/ibm/tsamp/eez/aladapterpolicypool. 2. Open the file in an XML editor. 3. Update the PolicyInformation section of the policy. It is required that you specify at least the domain name of the Agentless Adapter domain you have configured to interact with the TEMS correctly. It is recommended to also change the PolicyName and PolicyDescription of the policy. 4. Create a Tivoli Monitoring resource. As you can see in the policy template, you typically have to create the following for each new Tivoli Monitoring Resource: a. One XML fragment of type IBM.ITMResourceAttributes with all the Tivoli Monitoring agent specific properties. In this section you specify the Tivoli Monitoring agent attributes which are used to determine the observed state and how to map them to the System Automation Application Manager observed state. It also describes which actions are used to start or stop this resource. You can share one set of IBM.ITMResourceAttributes for multiple Tivoli Monitoring resources. 268 Tivoli System Automation Application Manager V : Installation and Configuration Guide

287 b. One XML fragment of type Resource with the corresponding instance of the IBM.ITMResourceAttributes as argument. Here you can define the name of your resource and identify which agent instance (managed system name) is used to monitor and control the application that is represented by this resource. The Tivoli Monitoring managed system name is specified in the node attribute of the Resource element. Depending on whether a predefined agent policy snippet exists or not, choose one of the following steps: 1) If your Tivoli Monitoring resource is monitored by a Tivoli Monitoring agent for which a predefined policy snippet exists, create a Tivoli Monitoring resource using a predefined template: a) Open one of the Snippet_*_agent.xml files in your editor. b) Copy the Resource and IBM.ITMResourceAttributes elements into your main policy document and adapt the attributes to match your environment. The resources attributes contain predefined Tivoli Monitoring agent specific settings such as the state mappings from the Tivoli Monitoring agent state values to System Automation state values. The Description attribute provides an overview of the properties that you need to adapt to match your environment. 2) If there is no predefined policy snippet for your Tivoli Monitoring resource, copy and modify the XML elements of the generic Tivoli Monitoring resource that is contained in the SampleITMResourcePolicy.xml template: Key attributes which have to be defined for a Tivoli Monitoring resource. All attributes are defined within the XML element IBM.ITMResourceAttributes. <StartCommand> and <StopCommand> These values contain the exact command and arguments run by the Tivoli Monitoring agent when the resource receives a start or stop request for the corresponding resource instance. The command can either be a predefined take action command supported by the Tivoli Monitoring agent or any remote system command. To use a predefined take action command of a specific Tivoli Monitoring agent, specify the name of the command and associated parameters. You do not need to specify a fully qualified file path. If you want to trigger a different command on the system, the fully qualified path to that command needs to be specified. The command is run on the managed system identified by the managed system name of the resource. <UserName> The value defines a user name which is used to connect to the Tivoli Monitoring SOAP server running on the hub monitoring server to submit the StartCommand and StopCommand and to query the Tivoli Monitoring agent for the attribute specified in the MonitorAttribute element. Specify one of the user IDs configured using cfgeezdmn as specific Tivoli Monitoring users. For more information, refer to Configuring user credentials to access the monitored resources on page 265. If you want to use the generic Tivoli Monitoring user configured in cfgeezdmn, leave this attribute blank. <MonitorAttribute> The value specifies the Tivoli Monitoring agent attribute that is Chapter 4. Integrating 269

288 queried to determine the observed state of the resource. The attribute consists of an attribute group and an attribute name within that group. The value of the specified agent attribute is queried periodically to determine or update the observed state of the resource. The attribute is specified as AttributeGroup.AttributeName. <MonitorValueOnline> and <MonitorValueOffline> Use these elements to specify which value of the Tivoli Monitoring attribute defined as MonitorAttribute is to be mapped to which System Automation observed state. A MonitorValue<observed_state_value> element exists for every available System Automation observed state. Specify the monitor attribute value which is mapped to this observed state as value of the XML element. You can map multiple Tivoli Monitoring States to the same System Automation observed state. If the monitor attribute has a value for which no mapping to a System Automation observed state exists, this value is ignored and the observed state of the Tivoli Monitoring resource remains unchanged. If you are unsure about which values to specify, refer to Retrieving the required information about your Tivoli Monitoring managed resources on page 272 to obtain the correct ones. For a full description of all properties available for Tivoli Monitoring resources, refer to IBM Tivoli System Automation Application Manager Administrator's and User's Guide. In addition, refer to IBM Tivoli System Automation Application Manager Reference and Problem Determination Guide for details about XML elements. 5. Save the policy file in the agentless adapter policy pool. Using attribute filters in a monitor query: The Tivoli Monitoring agent attribute group that was specified as part of the MonitorAttribute of the Tivoli Monitoring resource is queried periodically. The query is performed to determine or update the observed state of the resource. Agent attribute groups are returned as tables. For some agent attribute groups, more than one row of values can be returned. For example, when a table of running processes is displayed, or if the agent monitors multiple application instances. If you want to use an attribute of such an attribute group as monitor attribute, you must specify a filter to locate the row in the table which contains the state of your Tivoli Monitoring Resource. You use the MonitorQueryAttrFilter property to specify such a filter. You can specify the following filters: MonitorQueryAttrFilter This XML element is an optional element within the IBM.ITMResourceAttributes element. When querying the monitor attribute, this filter is applied to reduce the amount of returned data based on the filter criteria. In the filter, you can specify which attribute must meet which filter criteria. Only the matching rows of the attribute group that contain the attribute are returned. A filter criteria has the three components Attribute Name, Operator, and Attribute Value. 270 Tivoli System Automation Application Manager V : Installation and Configuration Guide

289 Attribute Name Is the name of the attribute on which the filter is applied. It must exist in the attribute group specified in the monitor attribute. Operator Can be: EQ, NE, GE, GT, LE, LT, or LIKE. You can select one of them from the list, where: EQ is equals NE is not equal GE is greater than or equal to LE is less than or equal to LT is less than LIKE can be used if pattern matching is required. Available pattern characters when using LIKE are: v v '%' matches any single character. ' * ' matches one to many characters. LIKE is only supported for character attributes. Attribute Value Is the value on which the operator is applied. The filter value is specified as follows attribute_name;operator;value. You can specify multiple filter criteria. Multiple filters are applied using a logical AND operation. Note: v Filter criteria are optional. However, you must make sure that the query result of the monitor attribute does not return more than one row. v If the monitor query returns an empty result set, the resource assumes Offline as observed state. This filter criteria is required if process monitoring via an OS agent is used, because the process table does not list the monitored process if the process is not running. Specifying additional properties for a Tivoli Monitoring resource: You can add multiple Tivoli Monitoring attributes with their current values to the list of additional properties of the corresponding Tivoli Monitoring resource. The attributes and values are then shown in the Additional tab of the Properties dialog of the selected Tivoli Monitoring resource in the System Automation operations console. Use the Property XML element that can be specified within the IBM.ITMResourceAttributes element to define the additional attributes which should be added to a resource. Additional Attributes specified as Property element. The attributes that you add as Property element must be part of the attribute group that is specified in the MonitorAttribute element. The attribute value is queried periodically with every monitor call. Do not specify attributes with frequently changing values, for example CPU utilization, because a resource Chapter 4. Integrating 271

290 modified event is triggered each time the attribute value changes. You can specify multiple Property elements if more than one agent attribute value should be added to the additional properties of a resource. The following screen capture shows parts of an attribute group as displayed in the Tivoli Enterprise Portal: Figure 35. Agent attributes which can be added as additional attributes If in this attribute group there is also the attribute chosen as monitor attribute, you can use the other attributes as additional properties for the resource. In this example, Status was chosen as monitor attribute. Good examples for attributes to be added as additional attributes are Version or Process ID. Since JVM Memory Free (bytes) is an attribute that changes frequently, it is not a good candidate to be added to the list of additional properties. Example: <IBM.ITMResourceAttributes>... <MonitorAttribute>Application_Server.Status</MonitorAttribute> <MonitorValueOnline>Connected</MonitorValueOnline> <MonitorValueOffline>Disconnected</MonitorValueOffline> <MonitorCommandPeriod>10</MonitorCommandPeriod> <Property>Version</Property> <Property>Process_ID</Property> </IBM.ITMResourceAttributes> Retrieving the required information about your Tivoli Monitoring managed resources Specify attributes in the XML elements IBM.ITMResourceAttributes and Resource to create a Tivoli Monitoring resource in an agentless adapter policy. This section describes the steps that you must perform to find the required information. Use the Tivoli Enterprise Portal (TEP) connected to an Tivoli Monitoring environment to perform the following steps: Procedure 1. Step 1: Find the correct Managed System Name that must be specified as node attribute of the Resource XML element. 2. Step 2: Find suitable take action commands provided by the Tivoli Monitoring agent to start and stop the Tivoli Monitoring managed application and specify them as StartCommand and StopCommand within the IBM.ITMResourceAttributes XML element. 3. Step 3: Find the available attribute and corresponding attribute values that can be used for determining the observed state. Specify the attribute as MonitorAttribute XML element for the Tivoli Monitoring resource and define state mappings for the attribute values using the corresponding MonitorValue XML elements. For example MonitorValueOnline or MonitorValueOffline. 272 Tivoli System Automation Application Manager V : Installation and Configuration Guide

291 The following tasks guide you through the process. Step 1: Managed system name: The managed system name identifies an Tivoli Monitoring agent on a specific remote endpoint that is used to monitor and control the application that you add to the agentless adapter policy. This managed system name must be specified in the ITM Resource section for an Tivoli Monitoring resource. Perform the following steps to determine the managed system name: Procedure 1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed system for which you want to determine the managed system name. Right-click on the navigator item and select Properties. 2. In the Navigator Item Properties dialog find the Assigned list box which displays the managed system name. The managed system name in the Assigned list must be specified in the ITM Resources section for the Tivoli Monitoring resource in the policy editor. Step 2: Take action commands: In the StartCommand and StopCommand properties you can either specify any remote command available on the remote endpoint or a predefined Take Action command which is provided by the Tivoli Monitoring agent. Use the following methods to display the available Take Action commands for an ITM agent. This information must be specified on the Start / Stop Properties notebook page for the Tivoli Monitoring resource. Perform the following steps to determine the Take Action commands: Procedure 1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed system for which you want to determine the available take action commands. 2. Right-click on the navigator item and select Take Action > Select. 3. A list box containing all available Take Action commands for the currently selected managed system is displayed. Select the appropriate command to start or stop the monitored application. If you are prompted to specify required parameter values, specify the correct values in that dialog. 4. The Take Action dialog now displays the completed Take Action details. Specify the value in the Command box in the StartCommand or StopCommand properties of the Tivoli Monitoring resource. The start and stop commands must be specified in the StartCommand and StopCommand properties on the Monitor page for the Tivoli Monitoring resource in the policy editor Chapter 4. Integrating 273

292 Step 3: Monitor attribute and valid attribute values: In this step, retrieve available attributes and attribute values that you need to specify in the MonitorAttribute element and the corresponding state mapping elements. A typical Tivoli Enterprise Portal workspace contains multiple views where each view displays data from an agent attribute group. If you want to use an attribute that is displayed in a workspace view as MonitorAttribute for System Automation, you first need to determine the corresponding attribute group name. Procedure 1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed system for which you want to determine the name of an attribute group corresponding to a workspace view. Open the workspace that contains the workspace view. 2. Select the workspace view that displays the status information that you want to use to define the availability state of the Tivoli Monitoring resource. right-click in this workspace view and select Properties. 3. In the "Properties" dialog, find the required Attribute Group by selecting Click here to assign a query. 4. In the Query Editor" dialog, find the matching Attribute Group in the tree on the left: 5. In this example, the matching Attribute Group is Application_Server. If the displayed name contains any spaces, replace them with the underscore character. Important: v v Application_Server is the displayed name of the attribute group name. Replacing spaces with underscore characters is an attempt to create the internal name of the attribute group as it is known to the Tivoli Monitoring agent. This internal name is also the name that must be specified in the policy. Nevertheless, in some cases the internal name is still different (for example, the DB2 agent uses different internal names). To ensure the right names for attribute group and attribute name, verify that the name exists in the agent's.atr file. For more information, see Determine attributes and attribute values from Tivoli Monitoring agent attribute files on page 276. The User's Guides of the corresponding Tivoli Monitoring agents, contain a detailed reference of all agent attributes. Refer to these documents to find a description of the attributes and their values. 6. Click Cancel close the Query Editor" dialog and return to the Properties dialog. 7. Select the Filters tab and find the attribute which you want to use for mapping as System Automation observed state. In the example below the attribute name is Status. As described for the attribute group in the previous steps, you may have to specify an internal attribute name which is different from the displayed name. When you click into an empty cell of this attribute row, a list which shows you all defined attribute values for this attribute is displayed. For each listed attribute value, decide to which System Automation observed state value it is mapped. This mapping is defined using the MonitorValueOnline, MonitorValueOffline, and other elements. 274 Tivoli System Automation Application Manager V : Installation and Configuration Guide

293 You now determined all required values for monitoring the availability state of the resource: v v v The attribute group name (in this example: Application_Server), The attribute name (in this example: Status) The attribute value mappings. 8. In the policy editor, specify the attribute group name and the attribute name in the Monitor Attribute section for the Tivoli Monitoring resource. 9. Define state mappings for the attribute values on the State Mappings page for the resource. Alternative ways to retrieve information for Tivoli Monitoring Resource policy values This section describes how you can use the Tivoli Enterprise Portal (TEP) or command line commands as an alternate source to retrieve managed system names, "Take Action" commands, and resource attributes. These values are required to create an agentless adapter policy to monitor and control Tivoli Monitoring resources. Also refer to the previous topics for a description of the preferred way to gather this information. Displaying a list of all Managed Systems: To open the Managed System Status workspace, perform these steps: Procedure 1. Click the Enterprise Navigator item to open its default workspace. 2. Either right-click the Enterprise Navigator or open the View menu, then select Workspace > Managed System Status The Managed System Status table view with a list of the monitoring agents in your managed network is displayed. Look for the agent which is used to monitor the application that you want to integrate in an agentless adapter policy. The Name column shows the managed system name that must be specified in the node attribute of the resource element. Using the Command Line To display a list of all available managed systems, run the following command on the hub Tivoli Enterprise Monitoring Server: tacmd listsystems Take Action commands: Procedure 1. Enter the following command to list all available Take Action commands for a specific agent product code: tacmd listaction t <pc> To list, for example, all actions for the Web Server Agent which has the product code HT, use the command: tacmd listaction t HT Chapter 4. Integrating 275

294 The output contains a NAME column which lists the names of the available Take Action commands. 2. Enter the following command to display the details for a selected Take Action command: tacmd viewaction -n <action_name> -t <pc> To view, for example, the details for the Start DB2 command: tacmd viewaction -n "Start DB2" -t UD The output contains the Command value that must be specified in the StartCommand and StopCommand properties for an Tivoli Monitoring resource. Determine attributes and attribute values from Tivoli Monitoring agent attribute files: The available attribute groups, attributes, and values for an Tivoli Monitoring agent can be determined from the *.atr file of the respective agent. Attribute files are available for every agent type and are on the hub Tivoli Enterprise Monitoring Server in the <ITM_Root>/tables/<TEMS_Name>/ATTRLIB directory. The file name for an attribute file is:k<pc>,atr, where pc is the two letter product code of an Tivoli Monitoring agent. For example, klz.atr is the attribute file for the Linux OS agent. Here is an example of an entry in such an attribute file: entr ATTR name Apache_Web_Server.Status affi G0000## colu STATUS type 4 mini maxi msid KHT0714 opgr 2048 atid vale Stopped vali 0 vale Running vali 1 vale Error vali 2 vale N/A vali -1 The highlighted lines are in particular of interest if you want to integrate a resource that is monitored by the respective Tivoli Monitoring agent into an agentless adapter policy. name vale Specifies the attribute group ( Apache_Web_Server ) and attribute name ( Status ) separated by a dot. You must specify this value for the MonitorAttribute XML policy element. These entries specify the value set for the Apache_Web_Server.Status attribute. You can use them to define state mappings for Tivoli Monitoring resources in the Agentless Adapter policy. For example, you could define for a resource that is monitored by this agent type that the value Running is mapped to an SAObservedState Online. 276 Tivoli System Automation Application Manager V : Installation and Configuration Guide

295 Activate and test the agentless adapter policy Activating the agentless adapter policy: After you created the agentless adapter domain policy as described in the previous sections and stored it in the Agentless Adapter policy pool, you can now activate it from the operations console. Open the Activate Automation Policies dashboard and select the Tivoli Monitoring domain. The available policies for the selected domain are listed. Select the new policy and click Activate. After the policy is activated, the agentless adapter connects to the configured Tivoli Enterprise Monitoring Server and attempts to retrieve the agent attributes which were specified as monitor attribute in the policy for all defined Tivoli Monitoring resources. After a few seconds, the resources displayed in the operations console change their observed state from Unknown into either Online or Offline. If the status does not change, you must check the log of this specific Tivoli Monitoring domain. You can view the log by selecting the Tivoli Monitoring domain and clicking View log in the context menu of the domain. This problem could occur if you did not specify the correct user credentials for accessing the Tivoli Enterprise Monitoring Server. In this case, you must now specify the credentials as described in Configuring user credentials to access the monitored resources on page 265 and restart the agentless adapter. Note: The last active policy of the Tivoli Monitoring domain is automatically reactivated only if you also configured valid First-level automation credentials for your Tivoli Monitoring domain using the cfgeezdmn configuration utility. Displaying Tivoli Monitoring resources in the operations console: After policy activation, you can open the domain page from the context menu of the Tivoli Monitoring domain in order to view the defined Tivoli Monitoring resources and corresponding nodes. In the Properties dialog of a Tivoli Monitoring resource you see the new resource class IBM.ITMResource together with the information about on which endpoint this resource is located. This information is also displayed in the Relationships graph. On the Additional tab of the resource's Properties dialog, you find the Tivoli Monitoring specific start/stop actions and also which attribute is being used to determine the availability state and the current value of this attribute. Start/Stop a Tivoli Monitoring Resource using the operations console: An Tivoli Monitoring resource offers the same start/stop behavior as standard remote resources of class IBM.RemoteResource which are also managed by the agentless adapter. Depending on the current observed state, an operator can either issue a Bring Online / Bring Offline or Restart command. Chapter 4. Integrating 277

296 The resource itself is in Starting state while the start action is running. The maximum time that the resource is allowed to be in the "Starting" state is defined for each start/stop action in the policy. After this action is performed, the observed state is set according to the availability state attribute of the Tivoli Monitoring resource. Since the agentless adapter offers no automation capabilities, there is no desired state and therefore also no indication that the current state does not reflect the desired state. Managing Tivoli Monitoring resources as part of a composite business application Create an end-to-end automation policy for Tivoli Monitoring resources: This section describes how to add Tivoli Monitoring resources as referenced resources of the end-to-end automation domain to achieve the following: v Define an automated startup or shutdown sequence of different Tivoli Monitoring monitored resources, hosted on different Tivoli Monitoring endpoints. An integrated startup or shutdown sequence can be defined for Tivoli Monitoring monitored resources and other automated resources that are controlled by another automation domain such as System Automation for Multiplatforms, System Automation z/os, or PowerHA. v Tivoli Monitoring resources in an agentless adapter domain have no desired availability state. By integrating them into the end-to-end automation domain it is possible to automatically react when undesired outages of these Tivoli Monitoring Resources occur. v The grouping concepts in the end-to-end automation policy allow you to create composite application groups of Tivoli Monitoring resources. These composite application groups can be managed as one entity in the System Automation operations console and provide an aggregated availability state. Create ResourceReferences referring to the Tivoli Monitoring resources as you would for any other first level resources. You can collect the required attributes, like resource name and resource class from the resource's Properties dialog. What to do next After having created the desired resource references to Tivoli Monitoring resources, your policy already serves one purpose: When it is activated on the end-to-end domain, the System Automation Application Manager ensures the defined desired state and restarts every Tivoli Monitoring resource if it is failing. Next, you can define a group in the end-to-end automation policy and add the resource references as group members. Give your new group a meaningful name, for example PortalGroup. With this configuration you can manage multiple Tivoli Monitoring resources as one composite group. You can also create relationships between the resource references thereby controlling the startup behavior of the Tivoli Monitoring resources. After you finished creating this first end-to-end policy, you must save it into the policy pool directory of the System Automation Application Manager. 278 Tivoli System Automation Application Manager V : Installation and Configuration Guide

297 Activate the end-to-end automation policy: Open the Activate Automation Policies dashboard and select the end-to-end automation domain. The available policies for the end-to-end automation domain are listed. Select the new policy and click Activate. Control a composite business application consisting of multiple Tivoli Monitoring and other clustered resources: This section describes how a Tivoli Monitoring resources defined in an active agentless adapter domain can be automated and controlled in the context of an end-to-end composite business application. After the end-to-end policy is activated, as described in the previous section, the composite application group PortalGroup is shown in the Resources widget on the domain page of the end-to-end automation domain. As displayed in the Relationships graph of a selected resource reference, the end-to-end automation domain now controls starting and stopping the individual referenced resource that is defined in the ITM domain. A composite business application, such as the PortalGroup, can be started by an operator start request that results in start commands being sent to all referenced Tivoli Monitoring resources. If you specified startafter relationships between the resource references, they are honored as well. In addition, the System Automation Application Manager enforces the defined desired state and restarts every Tivoli Monitoring resource in case it is failing. You can also use forceddownby relationships in order to automatically restart related components if a Tivoli Monitoring resource fails. Creating a Tivoli Monitoring situation to trigger an automated restart So far you learned how to instrument Tivoli Monitoring resources to be managed by the agentless adapter of System Automation Application Manager. You also know how you can create composite business applications by using the Tivoli Monitoring resources. The System Automation Application Manager takes over the responsibility to start these composite applications in a coordinated sequence on request by an operator. System Automation Application Manager can also restart the Tivoli Monitoring resources in unexpected outage situations. These integration scenarios are defined by using the instrumentation functions provided by Tivoli Monitoring. Chapter 4. Integrating 279

298 In this section, you find an example of how to trigger an automated System Automation action based on a defined Tivoli Monitoring situation. This scenario can be used, for example, to restart a WebSphere Application Server when a specific Tivoli Monitoring situation, such as average heap size too high, becomes true. All operator actions against System Automation Application Manager resources from the Operations Console can also be triggered by using the System Automation Application Manager command shell (eezcs command). You can issue such a command as System Command from the Tivoli Enterprise Monitoring Server as an Action that is defined for a situation. If the Tivoli Enterprise Monitoring Server and System Automation Application Manager are installed on different servers, you must run this command remotely on the System Automation Application Manager server using the ssh command. The following figure shows an example of how to define such a command. Figure 36. Perform an System Automation Application Manager command shell command as action for an Tivoli Monitoring situation Any System Automation resource (not only Tivoli Monitoring resources) can be the target of such a start/stop/restart request action. You can start resources which are, for example, automated by an System Automation for Multiplatforms, System Automation for z/os or PowerHA domain. Integrating with Tivoli Monitoring and Tivoli Composite Application Manager (ITCAM) The Tivoli Monitoring (Tivoli Monitoring) and Tivoli Composite Application Manager (ITCAM) family provides availability and performance monitoring of essential system resources and applications on a wide variety of operating systems and platforms. 280 Tivoli System Automation Application Manager V : Installation and Configuration Guide