Tivoli System Automation Application Manager V4.1.0.1

System Automation Application Manager Version 4.1

Installation and Configuration Guide

IBM

SC34-2702-01

System Automation Application Manager Version 4.1

Installation and Configuration Guide

IBM

SC34-2702-01 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 SC34-2588-03. 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-71032 Boeblingen Federal Republic of Germany FAX (Germany): 07031+16-3456 FAX (Other Countries): (+49)+7031-16-3456 Internet e-mail: [email protected] 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, 2015. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents

Figures ...... vii Chapter 2. Installing ...... 51 Installing the middleware software ...... 51 Tables ...... ix Contents of the middleware software DVDs .. 51 Installing a DB2 server ...... 51 About this book ...... xi Installing Jazz for Service Management .... 55 Installing System Automation Application Manager 59 Who should read this guide ...... xi Using the installation wizard ...... 59 Where to find more information ...... xi Installing in silent mode ...... 64 Conventions used in this guide...... xii Upgrading to release 4.1 ...... 65 ISO 9000 ...... xii Verifying the installation ...... 71 Related information ...... xii Post-installation tasks ...... 73 How to obtain publications ...... xiii Upgrading from a Try and Buy version to a full How to reach us by email ...... xiii product version ...... 75 Uninstalling ...... 75 What's new in this release ...... xv Installing on new operating systems ...... 76 Installing fix packs ...... 78 Chapter 1. Planning...... 1 Obtaining fix packs...... 78 Planning for System Automation Application Archive naming conventions ...... 78 Manager...... 1 Naming conventions of the update installer Packaging ...... 2 location...... 78 Prerequisites ...... 3 Usage instructions for the platform-specific Preparing for installation ...... 11 archives ...... 79 Planning for an LDAP user registry ..... 17 Installing a product fix pack ...... 79 Planning for the agentless adapter ...... 17 Installing fix packs in a high availability setup . 80 Packaging ...... 18 Uninstalling fix packs ...... 81 Prerequisites ...... 19 Installing for high availability ...... 81 Planning for high availability ...... 26 Installing for Distributed Disaster Recovery ... 82 Planning for Distributed Disaster Recovery .... 27 Installing the prerequisite software on both sites 82 Packaging ...... 27 Installing and configuring System Automation Prerequisites ...... 28 for Multiplatforms ...... 82 Preparing for installation ...... 31 Installing System Automation Application Planning for the PowerHA adapter ...... 32 Manager on the first site ...... 82 Packaging ...... 32 Configuring System Automation Application Prerequisites ...... 32 Manager on the first site ...... 83 Automating the PowerHA adapter ..... 33 Setting up DB2 HADR...... 83 Behavior of the PowerHA adapter ...... 33 Installing System Automation Application Planning for the FOC adapter ...... 34 Manager on the second site ...... 85 Roadmap ...... 34 Configuring System Automation Application Packaging ...... 35 Manager on the second site ...... 85 Prerequisites ...... 35 Creating tools for the replication of policy and Planning and preparing for an highly available credential files ...... 86 FOC adapter ...... 37 Configuring all end-to-end automation adapters Behavior of the FOC adapter ...... 38 with two System Automation Application Planning for the VCS adapter ...... 39 Manager hosts ...... 86 Packaging ...... 39 Configuring high availability and contact retry Prerequisites ...... 40 interval of all end-to-end automation adapters.. 87 Automating the VCS adapter ...... 40 Installing the remote agentless adapter ..... 87 Behavior of the VCS adapter for Solaris/SPARC 40 Using the installation wizard to install the remote Planning for an end-to-end automation policy ... 41 agentless adapter ...... 87 The scope of end-to-end automation policies .. 41 Installing the remote agentless adapter in silent Identifying cluster-spanning dependencies ... 43 mode ...... 88 Default directories ...... 46 Uninstalling the remote agentless adapter ... 89 Disaster recovery policy definition worksheets... 46 Installing and uninstalling service for the remote agentless adapter ...... 90 Installing the IBM PowerHA adapter ...... 92 Using SMIT to install the adapter ...... 92

© Copyright IBM Corp. 2006, 2015 iii Verifying the PowerHA adapter installation... 92 Configuring the hardware adapter in silent Uninstalling the PowerHA adapter ..... 93 mode ...... 146 Installing the Failover Cluster (FOC) adapter ... 93 Configuring storage replication ...... 146 Installing the Failover Cluster Command Configuring the TPC-R domain ...... 146 Interface optional feature ...... 93 Refreshing the TPC-R domain settings .... 149 Using the installation wizard to install the FOC Testing the TPC-R domain configuration ... 149 adapter ...... 94 Configuring the TPC-R domain in silent mode 150 Installing the FOC adapter in silent mode ... 95 Configuring high availability ...... 150 Upgrading the FOC adapter ...... 95 High availability for System Automation Verifying the FOC adapter installation .... 95 Application Manager ...... 150 Uninstalling the FOC adapter ...... 95 High availability for a disaster recovery setup Installing the Veritas Cluster Server (VCS) adapter 96 on two sites ...... 168 HACMP ...... 96 Configuring Distributed Disaster Recovery ... 175 Using the installation wizard to install the VCS Configuring the destination for GDPS events 176 adapter ...... 96 Configuring the GDPS agent ...... 176 Installing the VCS adapter in silent mode ... 96 Configuring synchronous communication with Verifying the VCS adapter installation .... 96 GDPS ...... 176 Uninstalling the VCS adapter ...... 97 Configuring the PowerHA adapter ...... 177 Starting the PowerHA adapter configuration Chapter 3. Configuring ...... 99 dialog ...... 178 Configuring the Application Manager ..... 99 Configuring the PowerHA adapter settings .. 179 Starting the Application Manager configuration Replicating the configuration files to other dialog ...... 99 nodes in the domain ...... 184 Configuring the Application Manager settings 100 Defining the PowerHA adapter automation Configuring the Application Manager common policy ...... 185 settings ...... 105 Removing the PowerHA adapter automation Domain tab ...... 106 policy ...... 185 Command Shell tab ...... 107 Configuring the PowerHA adapter in silent Discovery Library Adapter tab ...... 108 mode ...... 185 OSLC tab...... 108 Controlling the PowerHA adapter ..... 186 Event Publishing tab ...... 109 Configuring the FOC adapter ...... 186 User Credentials tab ...... 111 Starting the FOC adapter configuration dialog 186 Security tab ...... 111 Configuring the FOC adapter settings .... 187 Logger tab ...... 112 Replicating the configuration files to other Save the common configuration ...... 113 nodes in the domain ...... 192 Refreshing the Application Manager common Configuring the FOC adapter in silent mode 192 configuration ...... 114 Providing high availability for the FOC adapter 192 Configuring System Automation Application Configuring the VCS adapter ...... 193 Manager in silent mode ...... 114 Starting the VCS adapter configuration dialog 194 Configuring an alternative end-to-end Configuring the VCS adapter settings .... 195 automation host ...... 114 Replicating the configuration files to other Configuring an LDAP user registry ...... 115 nodes in the domain ...... 201 Adding the LDAP user registry as a federated Defining the VCS adapter automation policy 202 repository ...... 116 Removing the VCS adapter automation policy 202 Configuring supported entity types ..... 120 Configuring the VCS adapter in silent mode .. 203 Porting from a file-based repository to an LDAP Controlling the VCS adapter ...... 203 repository in a post-defined setup ..... 121 Configuring in silent mode ...... 203 Configuring access to non-clustered nodes.... 127 Working in silent mode ...... 204 Configuring the local agentless adapter.... 128 Processing tasks manually ...... 204 Configuring remote agentless adapters .... 134 Starting silent configuration ...... 205 Controlling Agentless Adapters ...... 138 Silent mode input properties file ...... 207 Configuring agentless adapters in silent mode 138 Editing the input properties file ...... 208 Tuning the number of domains and resources of Output in silent mode ...... 209 agentless adapters ...... 139 Configuration properties files ...... 210 Configuring virtual server & hardware Configuration properties files of the System management ...... 139 Automation Application Manager ..... 210 Configuring the hardware adapter ..... 139 Configuration properties files of the PowerHA Refreshing the active hardware adapter adapter ...... 212 configuration ...... 145 Configuration properties files for the VCS Testing the active hardware adapter ..... 145 adapter ...... 213 iv Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Configuration properties files of the FOC eezdla options quick reference...... 288 adapter ...... 214 eezdla options ...... 288 JazzSM Administration Services ...... 288 Chapter 4. Integrating ...... 215 JazzSM integration scenario ...... 289 Event consoles ...... 215 Configuring JazzSM Administration Services IBM Tivoli Netcool/OMNIbus...... 216 integration ...... 290 Tivoli Enterprise Console ...... 226 Administering registered JazzSM Administration Enabling event generation in System Services resources ...... 292 Automation Application Manager ..... 229 Enabling event filtering ...... 229 Chapter 5. Securing ...... 299 Tivoli Business Service Manager (TBSM) .... 230 Security concepts ...... 299 Integrating with System Automation Security tab ...... 299 Application Manager ...... 232 Securing the connection to end-to-end adapters Prerequisites...... 232 using SSL ...... 300 Configuring TBSM ...... 233 Generating Keystore and Truststore with SSL Configuring the Discovery Library Toolkit... 235 public and private keys ...... 300 Integrating System Automation resources in Enabling SSL security in the Application TBSM ...... 237 Manager configuration ...... 302 Customizing TBSM views to add information Enabling SSL security in FLA adapter from System Automation ...... 242 configurations ...... 303 Configuring Tivoli Business Service Manager Optional: Enforcing usage of SSL for all FLA launch-in-context support ...... 246 domains ...... 304 Integration scenarios with Business Service Securing communication with the zEnterprise Manager ...... 250 Hardware Management Console ...... 305 Tivoli Monitoring and Tivoli Composite Managing the security setup for Agentless Application Manager ...... 257 Adapters ...... 305 Prerequisites...... 258 Managing user credentials to access single Tivoli Monitoring overview ...... 258 nodes with Agentless Adapters ...... 305 Integrating with System Automation Managing SSH public keys ...... 308 Application Manager ...... 260 Creating a Tivoli Monitoring situation to trigger Chapter 6. Tuning ...... 311 an automated restart ...... 279 Tuning the number of domains and resources of Integrating with Tivoli Monitoring and Tivoli agentless adapters ...... 311 Composite Application Manager (ITCAM)... 280 Integration Scenarios with Tivoli Monitoring Using IBM Support Assistant .... 313 and IBM Tivoli Composite Application Manager Installing IBM Support Assistant and the Tivoli (ITCAM) ...... 283 System Automation for Multiplatforms plug-in .. 313 zEnterprise Hardware Management Console ... 283 Setting up the Hardware Management Console 283 Obtaining the Hardware Management Console Notices ...... 315 certificate...... 285 Trademarks ...... 316 Firewall considerations ...... 286 Working with the discovery library adapter ... 287 Index ...... 317

Contents v vi Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Figures

1. Overview of System Automation product family 2 21. Sample configuration of launch entry 225 2. Installation wizard: Required RAM 22. Modifying menu entries that are displayed in information dialog ...... 10 the Tools menu ...... 226 3. Examples for resource references to resources 23. TBSM basic architecture ...... 231 and resource groups...... 42 24. Identification Fields tab ...... 241 4. Example for end-to-end automation groups 25. Tree template editor ...... 245 that are distributed over different platforms.. 44 26. Integration of System Automation with 5. Application Manager tab of the Automation Business Service Manager ...... 252 Manager Configuration dialog ...... 100 27. TBSM Service Availability Page ..... 253 6. Non-clustered Nodes tab of the Automation 28. TBSM Service Tree ...... 254 Manager configuration dialog ...... 101 29. TBSM Service Tree ...... 255 7. Virtual Server / HW Management tab of the 30. TBSM Service Viewer ...... 256 Application Manager Configuration dialog.. 102 31. Tivoli System Automation operations console 256 8. Storage Replication tab of the Application 32. Tivoli System Automation Operations Manager Configuration dialog ...... 103 Console ...... 257 9. High Availability tab of the Application 33. Overview of the IBM Tivoli Monitoring Manager Configuration dialog ...... 104 infrastructure ...... 259 10. Change Passwords tab of the Application 34. Application Manager Local Agentless Adapter Manager Configuration dialog ...... 105 Configuration ...... 263 11. Maintaining configurations for multiple 35. Agent attributes which can be added as Agentless Adapters ...... 128 additional attributes ...... 272 12. End-to-end high availability scenario with a 36. Perform an System Automation Application shared database file system ...... 151 Manager command shell command as action 13. End-to-end high availability scenario with a for an Tivoli Monitoring situation ..... 280 remote database file system ...... 152 37. Example of System Automation Application 14. Resource groups, resources, and their Manager managing Tivoli Monitoring relationships ...... 165 Endpoints and HA clusters ...... 281 15. Resource groups, resources, and their 38. JazzSM Administration Services integration relationships ...... 173 scenario ...... 289 16. Configuration of the PowerHA adapter 177 39. Registering resources for OSLC ..... 290 17. Application Manager Adapter Configuration - 40. Using OSLC web services interfaces .... 293 Task Launcher for PowerHA ...... 178 41. Keystore and Truststore generation using SSL 301 18. Main window of the FOC Automation 42. Authentication with the Agentless Adapter on Adapter Configuration dialog ...... 187 a remote node ...... 306 19. Configuration of the VCS adapter..... 194 43. SSH key exchange overview ...... 308 20. VCS Automation Adapter Configuration dialog ...... 195

1. System Automation Application Manager 29. Archives for AIX platforms ...... 79 product DVDs ...... 2 30. Archives for Linux on System x ...... 79 2. Archive files of the electronic deliverable 3 31. Archives for Linux on System z ...... 79 3. Supported operating systems for System 32. Recommended end-to-end adapter and JEE Automation Application Manager ..... 4 framework settings in a DR setup ..... 87 4. Disk space requirements ...... 11 33. Archives for applying service to remote 5. Installation directory and Tivoli Common Agentless Adapter ...... 90 Directory ...... 12 34. Default user IDs and groups of the System 6. DB2 data for local and remote DB2 setup 13 Automation Application Manager..... 122 7. WebSphere Application Server installation 35. Role to group assignments: ...... 124 parameters ...... 14 36. Role to user ID assignment ...... 125 8. Installation parameters ...... 15 37. Resources in the automation policy for the 9. End-to-end automation domain name .... 15 end-to-end automation manager ..... 165 10. WebSphere Application Server user ID ... 15 38. Resources in the high availability policy for a 11. System Automation Administrator user ID 16 disaster recovery setup ...... 173 12. Directories on the product DVD...... 16 39. Resources in the PowerHA adapter 13. Remote Agentless Adapter product DVD 18 automation policy ...... 185 14. Archive files of the electronic deliverable 18 40. Resources in the VCS adapter automation 15. Supported operating systems for remote policy ...... 202 agentless adapters ...... 19 41. Generated input properties files ..... 207 16. Supported operating systems for non-clustered 42. System Automation Application Manager nodes managed by the agentless adapter... 20 event class types ...... 216 17. Supported operating systems for Distributed 43. Common System Automation status attributes Disaster Recovery ...... 28 used in resource status change events 18. Supported operating systems of managed (alerts.status)...... 217 clusters using GDPS for storage replication .. 28 44. alerts.status: Resource, domain, event 19. Supported operating systems of managed identification...... 218 clusters using TPC-R for storage replication .. 29 45. alerts.status: Other attributes used in resource 20. Supported environments Distributed Disaster status change events ...... 218 Recovery with GDPS ...... 30 46. alerts.status: Domain status change events 218 21. Supported environments Distributed Disaster 47. Existing rules file fields for System Recovery with TPC-R ...... 30 Automation events...... 219 22. Supported operating systems for the PowerHA 48. Compound state to OMNIbus severity adapter ...... 33 mapping ...... 220 23. Supported operating systems for the FOC 49. EIF severity to OMNIbus severity mapping 220 adapter ...... 36 50. Event Severity to TBSM State Mapping 233 24. Supported operating systems for the VCS 51. Text-based incoming status rules for TBSM 243 adapter ...... 40 52. Launch-in-context action parameters .... 249 25. Default directories ...... 46 53. eezdla return codes ...... 287 26. Worksheet to define disaster recovery topology 46 54. Command line options for the discovery 27. Worksheet to define disaster recovery library adapter ...... 288 hardware ...... 47 55. OSLC tab of the configuration utility 291 28. Worksheet to define disaster recovery workload ...... 49

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.

Who should read this guide 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, SC34-2701-00 v System Automation Application Manager Installation and Configuration Guide, SC34-2702-00 v System Automation Application Manager Reference and Problem Determination Guide, SC34-2703-00

You can download the books at: http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.saam.doc_4.1/welcome.html

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, SC34-2698-00 v System Automation for Multiplatforms Installation and Configuration Guide, SC34-2699-00 v System Automation for Multiplatforms Reference, SC34-2700-00 v System Automation for Multiplatforms High Availability Policies Guide, SC34-2660-00

You can download the books at: http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.samp.doc_4.1/welcome.html

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:

http://www.ibm.com/software/tivoli/products/sys-auto-app-mgr

The System Automation for Multiplatforms home page is:

The System Automation for z/OS® home page is:

http://www.ibm.com/software/tivoli/products/system-automation-zos

Conventions used in this guide 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: – http:///index.html v Frequently, variables are used to indicate a root installation directory: – Root installation directory of System Automation Application Manager: or EEZ_INSTALL_ROOT – WebSphere® Application Server root installation directory: or was_root – Runtime root directory of Integrated Solutions Console: 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 ISO 9000 registered quality systems were used in the development and manufacturing of this product.

Related information 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 V4.1.0.1: Installation and Configuration Guide 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: http://www.redbooks.ibm.com/ 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: http://www.ibm.com/software/support/isa

How to obtain publications The System Automation publications are also available (valid at the time of release) at these Web sites: www.ibm.com/servers/eserver/clusters/library/ www.ibm.com/servers/eserver/zseries/software/sa/ www.ibm.com/software/sysmgmt/products/support/

How to reach us by email If you would like to contact us by email, send your comments to [email protected]

About this book xiii xiv Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 – Create your own dashboards based on Dashboard Application Services Hub capabilities. – Customize predefined dashboards, for example change widget layout or configure displayed columns. v 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 4.1.0.1) 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 4.1.0.1) Starting with fix pack 4.1.0.1, 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 4.1.0.1 or higher.

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.

SA Otherproductcomponent User (withSA ApplicationManager Adapter) Web browser SA ApplicationManager highlyavailableinstalled 3 Systems MSFailoverCluster with SA ApplicationManager “MSCS Adapter”

4 HACMP/PowerHA Cluster with SA ApplicationManager “HAC Adapter”

2 5 VeritasCSCluster with SA ApplicationManager “VCS Adapter”

SA ApplicationManager remotelyinstalled SA forMultiplatforms Agentless AdapterSystems Clusterwith SA ApplicationManager SingleNodeSystems “SAM Adapter” attachedas “Remote Endpoints” to Agentless Adapter SA z/OSSysplex with SA ApplicationManager “ING Adapter”

High Availability/ AutomationClusters

ITM/ITCAM TEMS Systemswith ITM/ITCAMagents attachedto 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 EEZ4100AIX/AIX/ V4.1 for AIX setup.bin

2 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Table 1. System Automation Application Manager product DVDs (continued). Operating system Product DVD label Installation wizard file Linux on Tivoli System Automation Application Manager EEZ4100I386/i386/ System x® V4.1 for Linux on System x setup.bin Linux on Tivoli System Automation Application Manager EEZ4100S390/s390/ System z® V4.1 for Linux on System z 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 SA_AM_4.1_LinSysX.tar To extract the archive System x® GNU tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. Linux on SA_AM_4.1_LinSysZ.tar To extract the archive System z® 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 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 x1 Power Systems™ IBM System z® SUSE Linux Enterprise X X Server 10 (64 bit) SUSE Linux Enterprise X X Server 11 (64 bit) Red Hat Enterprise Linux X X 5 (64 bit)3 Red Hat RHEL Linux 6 X X (64 bit) Red Hat RHEL Linux 7 X X (64 bit)4 AIX 6.12 X AIX 7.12 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 5.6 . 4. Platform support is introduced with fix pack 4.1.0.1. 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 V4.1.0.1: Installation and Configuration Guide 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++33-32bit (SLES 10.3) – libstdc++43-32bit (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 The supported IBM Tivoli Monitoring versions for this feature are: v 6.2 v 6.2.1 v 6.2.2 v 6.2.3

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 V4.1.0.1: Installation and Configuration Guide Automation Application Manager Version 4.1 after fix pack 4.1.0.1 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 8.5.0.1 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: http://www.ibm.com/software/webservers/appserv/was/library/ Jazz for Service Management The versions of the Jazz for Service Management components listed below

Chapter 1. Planning 7 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 4.1.0.1 the minimum versions of the Jazz for Service Management components have changed to: v Jazz for Service Management, Version 1.1.2.0 v IBM Dashboard Application Services Hub, Version 3.1.2.0 v IBM WebSphere Application Server, Version 8.5.5.4 If you are planning to upgrade to System Automation Application Manager fix pack 4.1.0.1 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 1.1.0.2 – IBM Dashboard Application Services Hub, Version 3.1.0.2 v IBM WebSphere Application Server Version 8.5.0.1 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 /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 1.1.0.2 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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. Table 4. Disk space requirements Description Default directory Disk space Installation directory of System /opt/IBM/tsamp/eez/ 700 MB Automation Application Manager WebSphere Application Server (where 100 MB automation manager and operations AIX: /usr/IBM/WebSphere/AppServer/ console are deployed) Linux: /opt/IBM/WebSphere/AppServer/ DB2 database ~db2inst1 120 MB Temporary disk space needed for /tmp/ 1 GB installation and installation log and Note: Make sure your /tmp directory has five times the response files size of the installation file setup.bin. Configuration file directory and policy 1 MB pool directory of System Automation /etc/opt/IBM/tsamp/eez/cfg/ Application Manager /etc/opt/IBM/tsamp/eez/policyPool/ Tivoli Common Directory /var/ibm/tivoli/common/ 40 MB Installer registry /var/ 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.

About this task

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 Table 5. Installation directory and Tivoli Common Directory Parameter Description Default Installation directory name The directory to which the installable /opt/IBM/tsamp/eez 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:

v The directory name has to consist of the platform-specific path separator character and alphanumeric characters (A..Z, a..z, 0..9). v The underscore character (_) is allowed. v The space and colon characters are not allowed. Tivoli Common Directory The Tivoli directory for storing /var/ibm/tivoli/common 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:

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 V4.1.0.1: Installation and Configuration Guide Table 6. DB2 data for local and remote DB2 setup Parameter Description Default DB2 directory Local DB2 setup: The installation location The location is detected on your system of the DB2 Database Manager. and displayed as the default directory.

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. DB2 JDBC driver path on For remote DB2 setup only: Path to the local system directory where the files DB2 JDBC are located. DB2 instance host name Remote DB2 setup: The host name of the DB2 instance in which the automation manager and operations console databases are located. DB2 instance port number The port number of the DB2 instance in 50001 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 50000 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. Database instance owner The instance owner user ID of the DB2 db2inst1 name 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.

Chapter 1. Planning 13 Table 6. DB2 data for local and remote DB2 setup (continued) Parameter Description Default Database instance owner The password for the instance owner user No default value is provided password ID of the DB2 instance in which the automation manager and operations console databases are located. Automation manager Automation manager database for use by EAUTODB database 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.

In a remote DB2 setup, a database with this name must already exist in the remote DB2 instance. Backend version Version of the back end DB2: DB2_OPTN_UDB v ZOSUDB81: DB2 UDB V8.1 - running on z/OS v ZOSUDB91: DB2 V9.1 - running on z/OS v DIST: DB2 LUW- running on distributed system

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 The installation location of directory WebSphere Application Server. There The location is detected on your must be exactly one installation of system and displayed as the default WebSphere Application Server on directory. your system. WebSphere Application Server (WAS) The WebSphere Application Server profile name profile to be used for the automation All existing profiles are detected on manager and the operations console. your system and displayed in a single-choice list. WebSphere Application Server (WAS) The server to be used for the server name automation manager. The server name is detected on your system and displayed as default value. WAS Admin User ID The user ID of the WebSphere No default value is provided. Application Server administrator. WAS Admin User Password The password of WebSphere No default value is provided. Application Server administrator user ID.

14 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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). Table 8. Installation parameters Parameter Description Default Host Name The name of the host where the OMNIbus Probe for Tivoli EIF is localhost installed. Port Number The port number for the OMNIbus Probe for Tivoli EIF. 5529

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. Table 9. End-to-end automation domain name Parameter Description Default Automation domain The domain name must be unique and may not be used for any FriendlyE2E name 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).

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.

About this task

In the installation wizard you need to specify the user ID and the password. Table 10. WebSphere Application Server user ID Parameter Description Default User ID WebSphere Application Server user ID for the end-to-end eezdmn automation engine. Password Password of the user ID

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 About this task

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 eezadmin administrator Password Password of the user ID

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 contains: v The files for launching the installation wizard v The readme file v Directories containing the files required to install components that are embedded into the System Automation Application Manager installation. These are: Table 12. Directories on the product DVD Directory Content README For example, copyright notices and license agreements license License key DDL Scripts for creating DB2 databases and tables when remote DB2 setup is used ECExtension setup.jar ¹ Product installer and files needed for installing the product DOCS Documentation INTEGRATION Assets that integrate System Automation Application Manager and other IBM products.

Note: is one of the following: – AIX – 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 V4.1.0.1: Installation and Configuration Guide 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. The installer of System Automation Application Manager can already use the configured LDAP repository for user creation and role assignments. Post-defined 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.

Planning for the agentless adapter 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 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 Installation wizard file Windows EEZ4100Remote\Windows\ALAdapt\setup.exe AIX® EEZ4100Remote/AIX/ALAdapt/setup.bin Linux on System EEZ4100Remote/I386/ALAdapt/setup.bin x® Linux on POWER® EEZ4100Remote/PPC/ALAdapt/setup.bin Linux on System EEZ4100Remote/S390/ALAdapt/setup.bin z®

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 SA AM 4.1 RemoteClient The archive is self-extracting. Windows.exe AIX® SA AM 4.1 RemoteClient The archive is self-extracting. AIX.bin Linux on System x® SA AM 4.1 RemoteClient To extract the archive GNU tar LinSysX.tar 1.13 or later is required. Use the tar -xf command to extract the files to a temporary directory. Linux on POWER® SA AM 4.1 RemoteClient To extract the archive GNU tar LinPower.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 RemoteClient To extract the archive GNU tar LinSysZ.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 V4.1.0.1: Installation and Configuration Guide 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 x1 Power Systems IBM System z SUSE Linux Enterprise Server 10 X X X (64 bit) SUSE Linux Enterprise Server 11 X X X (64 bit) Red Hat Enterprise Linux 5 (64 X X X bit)2 Red Hat RHEL Linux 6 (64 bit) X X X Red Hat RHEL Linux 7 (64 bit)3 X X X AIX 6.1 X AIX 7.1 X Windows Server 2012 R1 X Windows Server 2012 R2 X

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 6.0.0.265 v Java 7.0 SR8: AIX package Java7.jre/Java7.sdk 7.0.0.145 v Java 7.1 SR2: AIX package Java71.jre/Java71.sdk 7.1.0.25

Chapter 1. Planning 19 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 IBM System Power IBM Other Operating system x1, 2 Systems2 System z2 platforms2 32 bit 64 bit Windows Server 2000 x 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 x Windows Server 2012 x Windows Embedded POSReady x x Windows Embedded Standard x x Windows Embedded Enterprise x x AIX 5.2 x AIX 5.3 (AIX 5L™ Version 5.3) ML 4 x AIX 6.1 x AIX 7.1 x 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

20 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Table 16. Supported operating systems for non-clustered nodes managed by the agentless adapter (continued) IBM System Power IBM Other Operating system x1, 2 Systems2 System z2 platforms2 32 bit 64 bit SOLARIS 10 x x SPARC z/OS V1.6, V1.7, V1.8, V1.9, V1.10, x V1.11, V1.12, V1.133 HP-UX 11i (32 bit) 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 3.6.1 or higher v AIX targets: OpenSSH 4.7 v Sun targets: SSH 1.1 v z/OS targets: OpenSSH 3.8.1 package provided by IBM Ported Tools for z/OS v 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 Documentation for OpenSSH can be found here: z/OS UNIX System Services v 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) v Edit /etc/ssh/sshd_config, uncomment the UsePrivilegeSeparation parameter and change it to no. v Re-IPL, the server should be started by TCP/IP. Browse /tmp/syslogd/ auth.log and check for a message stating sshd 16777233: Server listening on 0.0.0.0 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 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 –> --> 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 V4.1.0.1: Installation and Configuration Guide 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 Step 2. 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. Step 3. 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 V4.1.0.1: Installation and Configuration Guide 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 2.3.0.3 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 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). 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 16777233: Server listening on 0.0.0.0 port 22."

Planning for high availability 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 V4.1.0.1: Installation and Configuration Guide 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 445/TCP microsoft-ds 445/UDP For NetBIOS over TCP (NBT) enable the following ports nbname 137/UDP nbname 137/TCP nbdatagram 138/UDP nbsession 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 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 TPC-R GDPS Server 10 (64 bit) SUSE Linux Enterprise TPC-R GDPS Server 11 (64 bit) Red Hat RHEL 5.0 AS (64 TPC-R GDPS bit) Red Hat RHEL 6.0 AS (64 TPC-R GDPS bit) 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 SAMP, agentless SAMP, agentless SA MP, agentless Server 10 (64 bit) adapter2 adapter2 dapter2 SUSE Linux Enterprise SAMP, agentless SAMP, agentless SA MP, agentless Server 11 (64 bit) adapter2 adapter2 adapter2 Red Hat RHEL 5.0 AS (64 SAMP, agentless SAMP, agentless SA MP, agentless bit) adapter2 adapter2 adapter2

28 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 SAMP, agentless SAMP, agentless SA MP, agentless bit) adapter2 adapter2 adapter2 AIX 6.1 SAMP, agentless adapter2, PowerHA1 AIX 7.1 SAMP, agentless adapter2, PowerHA1

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 SA MP SA MP Server 10 (64 bit) SUSE Linux Enterprise SA MP SA MP Server 11 (64 bit) Red Hat RHEL 5.0 AS (64 SA MP SA MP bit) Red Hat RHEL 6.0 AS (64 SA MP SA MP bit) AIX 6.1 SA MP, PowerHA AIX 7.1 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 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 Supported environment Mirroring technique 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 Supported environment Mirroring technique 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 V3.4.1.8 and higher PTFs v TPC-R V4.1.1.1 or later (for example 4.1.2) and PTFs

30 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Note: 1. TotalStorage Productivity Center for Replication 4.1.0 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, SA22-7985, which is available at http://www-03.ibm.com/ 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 (SG24-6374) and the GDPS web site at http://www.ibm.com/systems/ z/advantages/gdps/.

Chapter 1. Planning 31 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 . 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 V4.1.0.1: Installation and Configuration Guide – For PowerHA V7.1.0: install the PowerHA V7.1 SP6 or higher. Refer to APAR IV27249. – For PowerHA V7.1.1: install the PowerHA V7.1.1 SP3 or higher. Refer to APAR IV23376. 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 x AIX 7.1 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. About this task 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 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.

Planning for the FOC adapter 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 37. 2. 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 94. 3. 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 V4.1.0.1: Installation and Configuration Guide 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 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 System x Windows Server 2012 R1 x Enterprise Edition (64 bit) Windows Server 2012 R2 x Enterprise Edition (64 bit)

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:\ is allowed, but C:\ : 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.

About this task

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 V4.1.0.1: Installation and Configuration Guide 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. About this task

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 – 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 V4.1.0.1: Installation and Configuration Guide Example: 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.

Planning for the VCS 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 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 Sun SPARC Solaris 10 (64 bit) 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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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 Example1 Example2 Example3

Ref1 Ref2 Ref3

GrpB GrpB GrpB Grp A Grp A ResX Grp A ResX ResX

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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide Relationships Relationships represent dependencies between resources or groups.

About this task

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 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 Default path /etc/opt/IBM/tsamp/eez/cfg /opt/IBM/tsamp/eez

The configuration properties files are located in the directory . 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 V4.1.0.1: Installation and Configuration Guide Table 26. Worksheet to define disaster recovery topology (continued)

Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set ClusterSetName Domain Name Site 1 Domain Name Site 2 WorkloadSetup Cluster set 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 Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table for each site. Name of Site1 / Site2: Slot 1 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 2 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 3 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 4 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP SNMPAgent (If Host mechanism="SNMP") Port AuthProtocol MD5 / SHA / None PrivProtocol DES / AES / None ServiceProcessorType MM Hardware Box Name Slot 1 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 2 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 3 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP Slot 4 Name PowerOff mechanism Script / SNMP PowerOn mechanism Script / SNMP SNMPAgent (If Host mechanism="SNMP") Port AuthProtocol MD5 / SHA / None PrivProtocol DES / AES / None ServiceProcessorType MM Node Name Site index 1 / 2 Domain name

Class SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node HardwareDevice Box Slot Node Name Site index 1 / 2 Domain name

Class SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node HardwareDevice Box Slot Node Name

48 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table for each site. Name of Site1 / Site2: Site index 1 / 2 Domain name

Class SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node HardwareDevice Box Slot Node Name Site index 1 / 2 Domain name

Class SYS / IBM.HacmpNode / IBM.PeerNode / VCS.System / MSCS.Node HardwareDevice Box Slot

Table 28. Worksheet to define disaster recovery workload Business-critical workload: Resource name Cluster set name 1 1 2 3 4 5 6 7 8 Discretionary workload: Resource name Cluster set name Site index 1 2 3 4 5 6

Chapter 1. Planning 49 Table 28. Worksheet to define disaster recovery workload (continued) 7 8

1. 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 V4.1.0.1: Installation and Configuration Guide 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 8.5.0.1

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 1.1.0.2

Note: Starting with fix pack 4.1.0.1 the minimum versions of middleware products have changed to: v Jazz for Service Management, Version 1.1.2.0 v IBM WebSphere Application Server, Version 8.5.5.4 If you are planning to upgrade to System Automation Application Manager fix pack 4.1.0.1 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 About this task 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 (GC09-4836) v IBM DB2 - Release Notes® - Version 10

The latest versions of these publications are available on the IBM DB2 web site:

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//sqllib/lib64/libdb2tsa.so

If this link does not exist, use the following command to create the link: ln -s /home//sqllib/lib64/libdb2tsa.so.1 /home//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 V4.1.0.1: Installation and Configuration Guide Note: For information about DB2 Version 10 server security concepts and on how to authorize users to perform certain tasks, go to IBM DB2 10.1 for Linux, UNIX, and Windows documentation or IBM DB2 10.5 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 /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 /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: About this task Windows Perform the following steps if your DB2 server runs on a Windows system:

Chapter 2. Installing 53 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 db2_create_reporting_tables.bat

where v is the desired name of the automation manager database (Example: EAUTODB) v is the instance owner user ID of the DB2 instance (Example: db2admin) v is the password of the instance owner user ID v 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) AIX or Linux 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 db2_create_reporting_tables.sh

where v is the desired name of the automation manager database. Example: EAUTODB v is the instance owner user ID of the DB2 instance. Example: db2inst1 v is the password of the instance owner user ID. v 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). z/OS 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 ATVED100.

54 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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: About this task

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 3. db2 list tables for schema eautousr 4. db2 disconnect

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 1.1.0.2: 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 4.1.0.1 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 4.1.0.1 the minimum versions of

Chapter 2. Installing 55 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 1.1.0.2 and WebSphere Application Server Version 8.5.0.1, 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 1.1.0.2 including Installation Manager: v AIX: JAZZ_FOR_SM_1.1.0.2_FOR_AIX_ML.zip (CISZ2ML.zip) v Linux: JAZZ_FOR_SM_1.1.0.2_FOR_LINUX_ML.zip (CISZ3ML.zip) v Linux on System z: JAZZ_FOR_SM_1.1.0.2_LINUX_SYS_Z.zip (CISZ4ML.zip) WebSphere Application Server Version 8.5.0.1: v AIX: WAS_V8.5.0.1_FOR_JAZZSM_AIX_ML.zip (CIES5ML.zip) v Linux: WAS_V8.5.0.1_FOR_JAZZSM_LINUX_ML.zip (CIES6ML.zip) v Linux on System z: WAS_V8.5.0.1_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 1.6.1 2) IBM WebSphere Application Server Version 8.5.0.1 3) IBM WebSphere SDK Java Technology Edition Version 7.0.2.0 4) Jazz for Service Management extension for IBM WebSphere 8.5 Version 1.1.0.1 5) IBM Dashboard Application Services Hub Version 3.1.0.2 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 V4.1.0.1: Installation and Configuration Guide 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 8.5.0.1 > 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: /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: More information about configuring Java 7 is provided at the following links: v Find out how to install and configure Java 7 at the IBM Education Assistant -WebSphere software. v 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. v 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 Installing a new Jazz for Service Management version Starting with fix pack 4.1.0.1 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 1.1.2.0, including the following versions of Jazz for Service Management components: v IBM Installation Manager 1.8.2 v IBM WebSphere Application Server Version 8.5.5.4 v IBM WebSphere SDK for Java Technology Edition Version 7.0.8.0 v Jazz for Service Management extension for IBM WebSphere 8.5 Version 1.1.0.2 v IBM Dashboard Application Services Hub Version 3.1.2.0

About this task

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 4.1. 2. You ordered System Automation Application Manager 4.1 before fix pack 4.1.0.1 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 76. 3. You ordered System Automation Application Manager 4.1 after fix pack 4.1.0.1 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 1.1.2.0 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 4.1.0.1 is available and want to run a new installation Install the middleware components by using the versions listed above. Download Jazz for Service Management 1.1.2.0 for your operating system platform from Passport Advantage (PA / XL). For more information, see http://www-01.ibm.com/support/docview.wss?uid=swg24039873. 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 V4.1.0.1: Installation and Configuration Guide v CN54UML: Jazz for Service Management 1.1.2.0 for AIX, 64-bit, Multilingual v CN552ML: IBM WebSphere Application Server 8.5.5.4 for Jazz for Service Management for AIX, 64-bit, Multilingual v CN54VML: Jazz for Service Management 1.1.2.0 for Linux, 64-bit, Multilingual v CN553ML: IBM WebSphere Application Server 8.5.5.4 for Jazz for Service Management for Linux, 64-bit, Multilingual v CN54WML: Jazz for Service Management 1.1.2.0 for Linux on System z, 64-bit, Multilingual v CN554ML: IBM WebSphere Application Server 8.5.5.4 for Jazz for Service Management for Linux on System z, 64-bit, Multilingual The Jazz for Service Management packages contain IBM Installation Manager Version 1.8.2 and IBM Dashboard Application Services Hub Version 3.1.2.0. The IBM WebSphere Application Server packages contain IBM WebSphere SDK for Java Technology Edition Version 7.0.8.0. 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 4.1.0.1 is available If you order System Automation Application Manager 4.1 after fix pack 4.1.0.1 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 4.1.0.0. 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 About this task

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 - 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 2. 4. 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 V4.1.0.1: Installation and Configuration Guide 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 62. 12. 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 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 15. 13. 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 446. 15. 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 V4.1.0.1: Installation and Configuration Guide 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 106. 18. 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 5529. 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 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 176. 21. 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 About this task

You can install System Automation Application Manager Version 4.1.0 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: 1. 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 /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. 2. 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 V4.1.0.1: Installation and Configuration Guide 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=. 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= 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 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 About this task

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 66. 2. Store the customized user role mappings. For more information, refer to “Storing the user role mappings for WebSphere application EEZEAR” on page 67. 3. On AIX only: Run the slibclean command. For more information, refer to “Upgrading on AIX” on page 68. 4. If you are upgrading from release 3.2.0 or 3.2.1, review the additional information in “Upgrading from release 3.2.0 or 3.2.1” on page 68. 5. 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 3.2.0 or 3.2.1, review the additional information in “Upgrading the automation database from version 3.2.0 or 3.2.1” on page 69. 7. Install the middleware software required by System Automation Application Manager Version 4.1.

Chapter 2. Installing 65 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 69. 9. Install System Automation Application Manager Version 4.1. 10. If high availability is configured for System Automation Application Manager, perform the additional postinstallation steps described in “Upgrading the high availability policy” on page 69. 11. 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 , 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 .

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

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

66 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide These are the required parameters: - Name of the System Automation Application Manager database. Typically, this is EAUTODB. - Database instance owner userid. - Database instance owner password. - Absolute path name of the directory where the exported tables should be stored. Ensure that the 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 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 65. 2. 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.

About this task

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 -password -lang jython -c

Chapter 2. Installing 67 "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 3.2.0 or 3.2.1 This section describes what you must observe when migrating from release 3.2.0 or 3.2.1 to release 4.1.

To upgrade from release 3.2.0 or 3.2.1 to release 4.1 of System Automation Application Manager, uninstall release 3.2.0 or 3.2.1 and install release 4.1 as described in “Upgrading to release 4.1” on page 65.

Additional installation steps

Before you uninstall release 3.2.0 or 3.2.1 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 3.2.2 that have to be considered when migrating from release 3.2.0 or 3.2.1 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 V4.1.0.1: Installation and Configuration Guide 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 3.2.1.3 there was only one agentless adapter that was installed on the Application Manager server host. Fix pack 3.2.1.3, and specifically release 3.2.2, introduces the remote Agentless Adapters. The agentless adapter included with releases prior to System Automation Application Manager Version 3.2.1.3 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 3.2.1.3 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 3.2.0 or 3.2.1 About this task

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 \install directory or in the DDL/Script directory on the product DVD, run: db2_run_sql.bat createNodeTable.sql

In a UNIX environment: v In the /install directory or in the DDL/Script directory on the product DVD, run: db2_run_sql.sh 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 3.2.0 or 3.2.1.” 2. Exclude the node: samctrl -u a .

Chapter 2. Installing 69 3. Stop the first node in the cluster: stoprpnode .

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 . 2. Include the node: samctrl -u d . 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.

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

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

70 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide These are the required parameters: - Name of the System Automation Application Manager database. Typically, this is EAUTODB. - Database instance owner userid. - Database instance owner password. - 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 directory.

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 About this task

To verify that the automation manager was installed successfully, complete the tasks described in the following topics.

Verifying the end-to-end automation database: About this task

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 3. db2 list tables for schema eautousr 4. db2 disconnect 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 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: About this task

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: http://:/ibm/console

The default WebSphere Application Server administrative console port is 16315. 2. 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: About this task

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: http://:/ibm/console

The default WebSphere Application Server administrative console port is 16315. 2. 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 V4.1.0.1: Installation and Configuration Guide Verifying the automation engine About this task

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 About this task

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: http://:/ibm/console

The default IBM Dashboard Application Services Hub port is 16310. 2. 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 About this task

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 Modifying the Lightweight Third Party Authentication (LTPA) settings About this task

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 About this task

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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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

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. About this task

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 About this task

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 / 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 Perform the following steps to uninstall System Automation Application Manager: 1. Launch the uninstallation program by entering the following command in a shell: /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 WebSphere Application Server Admin user ID and password v WebSphere Application Server - server name v 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 About this task

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 4.1.0., where is the respective fix pack number.

76 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 4.1.0.1 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 4.1.0.0 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 4.1.0.0. 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/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/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/license. 2. Extract the 4.1.0. 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/license is empty. 3. Copy the license file into the EEZ410/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 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 4.1.0.1 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 4.1.0.

Naming convention for product fix pack archives: 4.1.0-TIV-SAAM--FP.

Where v represents the platform on which System Automation Application Manager is installed. v represents the fix pack number. v 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 4.1.0 on Linux on System x platforms: 4.1.0-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//

where v represents modification level and fix level. For example, for fix pack 4.1.0.1, the directory is named EEZ4101. v represents the platform on which System Automation Application Manager is installed.

78 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide v 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 Description 4.1.0-TIV-SAAM-AIX-FP.bin The archive is self-extracting.

This is where you find the update installer program after unpacking the product fix pack archive: EEZ41AIX/AIX/setup.bin

Linux on System x Table 30. Archives for Linux on System x Archive name Description 4.1.0-TIV-SAAM-LinuxI386-FP.tar 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: EEZ41I386/i386/setup.bin

Linux on System z Table 31. Archives for Linux on System z Archive name Description 4.1.0-TIV-SAAM-LinuxS390-FP.tar 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: EEZ41S390/s390/setup.bin

Installing a product fix pack About this task

Before you begin: v Product fix packs are always cumulative.

Chapter 2. Installing 79 v Release 4.1.0 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 79. 4. 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 79. 6. 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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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 2. 9. 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 About this task

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.

Installing for high availability 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 1. 3. 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 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 59.

82 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 using LOGRETAIN recovery db2 update database configuration for using LOGINDEXBUILD ON

Where is the name of the EAUTODB. 3. Set up HADR using the following commands: db2 update db cfg for using HADR_LOCAL_HOST HADR_REMOTE_HOST HADR_LOCAL_SVC HADR_REMOTE_SVC HADR_REMOTE_INST HADR_TIMEOUT 120 HADR_SYNCMODE HADR_PEER_WINDOW 0

Chapter 2. Installing 83 Where: is the name of the EAUTODB. is the host name of the node where the EAUTODB was created. is the host name of the node at the other site where System Automation Application Manager is going to be installed. 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 is the port that is used for transaction log shipping on the node at the other site (Site 2). The default is 5005. is the instance name of EAUTODB on both sites. 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 to

Where: is the name of the EAUTODB. 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 from replace history file

Where: is the name of the EAUTODB. 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 using HADR_LOCAL_HOST HADR_REMOTE_HOST Where: is the name of the EAUTODB. is the DB2 host name on the second site where System Automation Application Manager is going to be installed. 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 V4.1.0.1: Installation and Configuration Guide db2 start hadr on database as standby

Where: 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 as primary

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

Where: 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 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@: /etc/opt/IBM/tsamp/eez/policyPool/ scp /etc/opt/IBM/tsamp/eez/cfg/eez.automation.engine.dif.properties root@:/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 3.2.2 or higher for all adapters that are part of the System Automation Application Manager product. v System Automation for Multiplatforms version 3.2.2.2 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, SC34-2584.

86 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 End-to-end adapter is highly End-to-end adapter is not Configuration option available highly available JEE framework environment 48 (default) a value 300 - 1000 variable "com.ibm.eez.aab.domain- removal-hour" In the Advanced dialog in 560 (default) 0 (retry forever) the Adapter configuration tabs: "Remote contact activity interval" In the Advanced dialog in 0 (default) 0 (retry forever) the Adapter configuration tabs: "initial contact retry interval"

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. About this task

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 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: -Dpreparesilent=true. The following response file is generated: \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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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: -i silent -f Uninstalling the remote agentless adapter An uninstallation program is provided to remove the adapter that was installed by the installation wizard. About this task

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: /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: -i silent.

Chapter 2. Installing 89 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 4.1.0 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: 4.1.0-TIV-SAAMR--FP. v : Represents the platform on which the remote agentless adapter is installed. v : Represents the fix pack number. v : 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: 4.1.0-TIV-SAAMR-PPC-FP0001.tar

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 4.1.0-TIV-SAAMR-Windows- The archive is self-extracting. This is where you .exe find the update installer program after unpacking the product fix pack archive: EEZ41Remote\Windows\ALAdapt\setup.exe

90 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Table 33. Archives for applying service to remote Agentless Adapter (continued) Operating system Archive name Description AIX 4.1.0-TIV-SAAMR-AIX- The archive is self-extracting. This is where you FP.bin find the update installer program after unpacking the product fix pack archive: EEZ41Remote/AIX/ALAdapt/setup.bin Linux on 4.1.0-TIV-SAAMR- For extracting the archive, GNU tar 1.13 or System x LinuxI386- later is required. Use the tar -xf command to FP.tar extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41Remote/I386/ALAdapt/setup.bin Linux on 4.1.0-TIV-SAAMR-LinuxPPC- For extracting the archive, GNU tar 1.13 or POWER FP.tar 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: EEZ41Remote/PPC/ALAdapt/setup.bin Linux on 4.1.0-TIV-SAAMR- For extracting the archive, GNU tar 1.13 or System z LinuxS390- later is required. Use the tar -xf command to FP.tar extract the files. This is where you find the update installer program after unpacking the product fix pack archive: EEZ41Remote/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 79. 4. 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 79. 6. Launch the update wizard. The same authorization is required as described in “Using the installation wizard to install the remote agentless adapter” on page 87. 7. 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 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 About this task

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 About this task

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 Resource Group: hacadapter_rg (if the prefix is ‘hacadapter’) in State: On line v 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 V4.1.0.1: Installation and Configuration Guide clstat - HACMP Cluster Status Monitor ------

Cluster: hacp57067 (1137142142) Mon Feb 20 14:15:16 MET 2011 State: UP Nodes: 2 SubState: STABLE

Node: p570sa06 State: UP Interface: p570sa06 (0) Address: 9.152.20.176 State: UP Interface: p57067ha (0) Address: 9.152.24.195 State: UP Resource Group: hacadapter_rg State: On line

Node: p570sa07 State: UP Interface: p570sa07 (0) Address: 9.152.20.177 State: UP ************************ f/forward, b/back, r/refresh, q/quit *********

Uninstalling the PowerHA adapter About this task

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 > 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. About this task

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 36. 2. Launch the installation wizard. You have the following options: 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. v 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\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 V4.1.0.1: Installation and Configuration Guide Installing the FOC adapter in silent mode About this task

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

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 About this task

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 About this task

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 About this task

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 Installing the Veritas Cluster Server (VCS) adapter You can install the VCS adapter using the wizard or in silent mode. Make sure you verify your installation. HACMP

Using the installation wizard to install the VCS adapter About this task

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\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 About this task

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

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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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 About this task

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 98 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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. About this task

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, 2015 99 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide into an active, running hardware adapter. For more information, see “Refreshing the active hardware adapter configuration” on page 145. Test 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 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 153 2. “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 V4.1.0.1: Installation and Configuration Guide 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 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 About this task

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 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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.

Note: For compatibility reasons, alternatively a Tivoli Enterprise Console server and port can still be configured.

Event server 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 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 139.

110 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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 10485760 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 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 About this task

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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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 Specify the local end-to-end automation host name of this configuration as alternative host name for the configuration on the alternative site. v 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 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

About this task

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 V4.1.0.1: Installation and Configuration Guide 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

About this task

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 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 V4.1.0.1: Installation and Configuration Guide 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

About this task

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).... 2. 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 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 V4.1.0.1: Installation and Configuration Guide 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 124. 3. 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 About this task

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 EEZOperator EEZConfiguratorGroup EEZConfigurator EEZMonitorGroup 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 . . . 11. Enter the user name eezadmin into the Search field or enter * to see all users.

122 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 . . .. 18. 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

About this task

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

About this task

To adapt the installation variables, apply the following change:

Procedure

Change the variable EXTERNAL_USER_REP_ACTIVATE in file / 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

About this task

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 Group name EEZMonitor EEZMonitorGroup EEZOperator EEZOperatorGroup EEZConfigurator EEZConfiguratorGroup EEZAdministrator EEZAdministratorGroup EEZEndToEndAccess EEZEndToEndAccessGroup

124 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 User ID iscadmins 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 Removing duplicate users from the file-based user repository About this task

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 V4.1.0.1: Installation and Configuration Guide 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 System Automation ApplicationManager

cfgeezdmnconfigurationutility

Configurationfiles read Local - Agentless Adapter Agentless Adapter -Remoteclients -remote.client1 -remote.client2

distribute distribute

remote.client2 remote.client1

Configurationfiles Configurationfiles - Agentless Adapter - Agentless Adapter

read read ALA ALA Domain1 Domain2

Remote Remote Agentless Adapter Agentless Adapter

ALA ALA ALA ALA ALA Domain3 Domain4 Domain5 Domain6 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 2005. 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 V4.1.0.1: Installation and Configuration Guide 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 0 - 1440 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 connection to the end-to-end automation management host after the connection is interrupted. The default value is 30 seconds. The value ranges 1 - 3600 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 to check the DNS lookup records.

130 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 1920. The default number for an SSL port is 3361. 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 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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 \cfg. 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 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 V4.1.0.1: Installation and Configuration Guide 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 10485760 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 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 V4.1.0.1: Installation and Configuration Guide About this task

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®). About this task

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 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 2003. 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 V4.1.0.1: Installation and Configuration Guide 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 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 143.

142 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 The name of the hardware box for which you want to define credentials. The name of the hardware box is mandatory. Slot 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 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.

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 V4.1.0.1: Installation and Configuration Guide Refreshing the active hardware adapter configuration About this task

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 About this task

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 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 About this task

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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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.

About this task

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 5110. 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 3443. Use the following URL to verify the port number: https://:/CSM/

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 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 5110. 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 3443. The server two GUI port number is optional. Use the following URL to verify the port number: https://:/CSM/

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: /eWAS/profiles/CSM/properties/rmserver.properties

Parameters on the respective TPC-R server. communications.port = WC_defaulthost_secure =

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 V4.1.0.1: Installation and Configuration Guide About this task

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 About this task

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 About this task

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 About this task

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 Configuring the TPC-R domain in silent mode About this task

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

Configuring high availability

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 V4.1.0.1: Installation and Configuration Guide 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

Activenode1 DBnode Standbynode2

DBManager DBManager

DBfilesystem J2EEFramework J2EEFramework

AutomationEngine AutomationEngine

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

Activenode1 DBnode Standbynode2

JDBCDriver DBManager JDBCDriver

J2EEFramework J2EEFramework

AutomationEngine AutomationEngine

DBfilesystem

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.

About this task

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 26. 2. 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 V4.1.0.1: Installation and Configuration Guide 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.

About this task

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 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 162. 2. 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 V4.1.0.1: Installation and Configuration Guide 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 0 - 128 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 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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: About this task

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: About this task

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

About this task

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 V4.1.0.1: Installation and Configuration Guide About this task

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.

About this task

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 preprpnode - prepares the local node for joining the domain v mkrpdomain - creates the domain definition by using the domain name and the nodes that were specified on the Domain setup tab v startrpdomain - starts the domain (state online)

Chapter 3. Configuring 161 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.

About this task

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 About this task

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 V4.1.0.1: Installation and Configuration Guide Defining the automation policy About this task

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 About this task

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 Configuring high availability in silent mode About this task

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 V4.1.0.1: Installation and Configuration Guide eez-ala-rg

Agentless adapter S S t t a o r p t A A f f t t e e r r

StartAfter Policy AntiAffinity pool

eez-rg

eez-srv-rg eez-was-rg eez-engine-rg

StartAfter WebSphere End-to-end Policy Application VirtualIP address automation pool Server manager

Start After

DependsOn DependsOn eez-db2-rg StartAfter

DB2 GDPS Hardware DB2 DependsOn mount agent adapter server point

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 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-stopsAfter- IBM.ManagedRelationship Dependency of the agentless ala-rs adapter policy pool on the agentless adapter. eez-ala-rs-startsAfter- IBM.ManagedRelationship Dependency of the agentless ala-mount adapter on the agentless adapter policy pool.

166 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Table 37. Resources in the automation policy for the end-to-end automation manager (continued) Resource name Resource class Description ala-rs-startsAfter-eez- IBM.ManagedRelationship Dependency of the agentless was-as adapter on the WebSphere Application Server by using the startAfter relationship. ala-rs-AntiAffinity-eez- IBM.ManagedRelationship Dependency of the agentless engine adapter on the automation manager by using the AntiAffinity relationship. eez-engine-AntiAffinity- IBM.ManagedRelationship Dependency of the automation ala-rs manager on the agentless adapter. db2-rs-dependsOn-db2- IBM.ManagedRelationship Dependency of the DB2 server rs_mount on the file system. eez-was-as-dependsOn-db2- IBM.ManagedRelationship Dependency of the WebSphere rs Application Server on DB2. eez-shared-mount- IBM.ManagedRelationship Dependency of the policy pool stopsAfter-engine on the automation manager. eez-engine-startsAfter- IBM.ManagedRelationship Dependency of the automation shared-mount manager on the policy pool. eez-engine-startsAfter- IBM.ManagedRelationship Dependency of the automation was-as 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. hwa-startsAfter-eez- IBM.ManagedRelationship Dependency of hardware engine adapter on the automation manager. gdpsagent-dependsOn-eez- IBM.ManagedRelationship Dependency of the command engine receiver on the automation manager. nettb IBM.TieBreaker Tie-Breaker defined, if IP address is specified on the domain setup page.

Notes and restrictions About this task 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 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 /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 V4.1.0.1: Installation and Configuration Guide 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.

About this task

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 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 114. 2. 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:

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

170 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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:

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 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 V4.1.0.1: Installation and Configuration Guide High availability policy using System Automation for Multiplatforms

About this task

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 S S t t a o r p t A A f f t t e e r r

StartAfter Policy AntiAffinity pool

eez-rg

eez-srv-rg eez-was-rg eez-engine-rg

StartAfter WebSphere End-to-end Policy Application VirtualIP address automation pool Server manager

Start After

DependsOn DependsOn eez-db2-rg StartAfter

DB2 GDPS Hardware DB2 DependsOn mount agent adapter server point

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 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- IBM.ManagedRelationship Dependency of WebSphere rs Application Server on DB2 eez-was- IBM.ManagedRelationship Dependency of WebSphere as_startsAfter_eez- Application Server on the startam-equ 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 V4.1.0.1: Installation and Configuration Guide Table 38. Resources in the high availability policy for a disaster recovery setup (continued) eez-was-as_DO_eez-hadr- IBM.ManagedRelationship Dependency of WebSphere prim-equ Application Server on DB2 HADR role eez-engine-startsAfter- IBM.ManagedRelationship Dependency of the System was-as Automation Application Manageron WebSphere Application Server gdpsagent-dependsOn-eez- IBM.ManagedRelationship Dependency of the gdpsagent engine 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 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. About this task

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. About this task

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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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 /.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 ApplicationServer

End-to-end management

Eventport 2002

HostnameorserviceIP label ip1 EIF Requestport 2001

PowerHA adapter

RSCT/PowerHA

PowerHA Node-1 cluster nodes

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 Starting the PowerHA adapter configuration dialog Use the cfghacadapter command to start the PowerHA adapter configuration dialog. About this task

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

178 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Configuring the PowerHA adapter settings Click Configure on the task launcher window of the configuration dialog to configure the PowerHA adapter settings. About this task

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

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

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 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 V4.1.0.1: Installation and Configuration Guide 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 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 V4.1.0.1: Installation and Configuration Guide 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.

Chapter 3. Configuring 183 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 About this task

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. About this task

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.

184 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Defining the PowerHA adapter automation policy Use the Define task to activate the configured adapter automation policy. About this task

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 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. About this task

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 About this task

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. About this task

For a description of the hacadapter command options, see System Automation Application Manager Reference and Problem Determination Guide.

Configuring the FOC adapter 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. About this task

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 36. 2. 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 V4.1.0.1: Installation and Configuration Guide 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. About this task

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

Automation domain

Chapter 3. Configuring 187 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.

188 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 2002.

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 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 [] 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 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 V4.1.0.1: Installation and Configuration Guide 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 10485760 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 About this task

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 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. About this task

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 @. 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. About this task

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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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.

Configuring the VCS adapter 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 WebSphere ApplicationServer

End-to-end management

Eventport 2002

HostnameorserviceIP label Ip SSL EIF Requestport 2001

VCSadapter

VERITASClusterServer

VCS Node-1 cluster nodes

VERITASClusterServer

Node-2

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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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. About this task

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

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 V4.1.0.1: Installation and Configuration Guide 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 2002.

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.

Chapter 3. Configuring 197 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 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. 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. Add 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 202.

198 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 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.

200 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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 10485760 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 About this task

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 About this task

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. About this task

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 V4.1.0.1: Installation and Configuration Guide About this task

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. About this task

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 About this task

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.

Configuring in silent mode 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 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. About this task

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 207. 2. Edit the parameter values in the file, see “Editing the input properties file” on page 208. 3. Start the configuration tool in silent mode to update the target configuration files, see “Starting silent configuration” on page 205. 4. 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. About this task

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 V4.1.0.1: Installation and Configuration Guide 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 / eezautomate.properties on the local node to process all remaining actions to set up the cluster. v Remove the domain. Start the script eezha -deleteDomain / eezautomate.properties to remove the System Automation for Multiplatforms cluster that is used to make System Automation Application Manager highly available. v Validate and store the automation policy for System Automation Application Manager. Start the script eezha -V -checkPolicy / eezautomate.properties to validate the System Automation Application Manager automation policy as you configured it. v Define a configured automation policy. Start the script eezha -activatePolicy /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. v Remove a configured automation policy. Start the script eezha -deactivatePolicy /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 About this task

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 -p password] d. To configure the hardware adapter: cfgeezdmn -s -eh [-r | -t] e. To configure the TPC-R domain: cfgeezdmn -s -et [-r | -t] 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 V4.1.0.1: Installation and Configuration Guide 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.

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 .

Depending on the target configuration, Table 41 shows the silent input properties files that are generated if the -g or -groption is specified. Table 41. Generated input properties files Component Target configuration Silent input properties file System Automation / Application Manager cfgeezdmn -s -e -g | -gr silent.eezcommon.properties (common) location/silent.eezcommon.properties cfgeezdmn -s -e -g | -gr -l location Local agentless adapter / cfgeezdmn -s -eu -g | -gr silent.eezaladapt.properties location/silent.eezaladapt.properties cfgeezdmn -s -eu -g | -gr -l location Remote agentless / adapter cfgeezdmn -s -ru -o host -g | -gr silent.remotealadapt.properties location/ cfgeezdmn -s -ru -o host -g | -gr silent.remotealadapt.properties -l location Hardware adapter / cfgeezdmn -s -eh -g | -gr silent.eezhwadapt.properties location/silent.eezhwadapt.properties cfgeezdmn -s -eh -g | -gr -l location TPC-R domain / cfgeezdmn -s -et -g | -gr silent.eeztpcr.properties location/silent.eeztpcr.properties cfgeezdmn -s -et -g | -gr -l location

Chapter 3. Configuring 207 Table 41. Generated input properties files (continued) Component Target configuration Silent input properties file System Automation / Application Manager cfgeezdmn -s -ea -g | -gr silent.eezauto.properties high availability location/silent.eezauto.properties cfgeezdmn -s -ea -g | -gr -l location / cfgeezdmn -s -ea -ad -g | -gr silent.eezautodr.properties location/silent.eezautodr.properties cfgeezdmn -s -ea -ad -g | -gr -l location PowerHA adapter / cfghacadapter -s -g | -gr silent.hacadapter.properties location/silent.hacadapter.properties cfghacadapter -s -g | -gr -l location FOC adapter \ cfgmscsadapter -s -g | -gr silent.mscsadapter.properties location\silent.mscsadapter.properties cfgmscsadapter -s -g | -gr -l location VCS adapter / cfgvcsadapter -s -g | -gr silent.vcsadapter.properties location/silent.vcsadapter.properties cfgvcsadapter -s -g | -gr -l location

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 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. About this task

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 V4.1.0.1: Installation and Configuration Guide # 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 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 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:

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 V4.1.0.1: Installation and Configuration Guide 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 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..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. /eez.aladapter.properties /eez.aladapter.dif.properties /eez.aladapter.ssh.properties /eez.aladapter.ssl.properties /eez.aladapter.jaas.properties /eez.aladapter.plugin.properties /eez.aladapter.plugin..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. /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:

212 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide 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:

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

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 V4.1.0.1: Installation and Configuration Guide Chapter 4. Integrating

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

Event consoles 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, 2015 215 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 Description SystemAutomation_Resource_Status_Change Status of an automated resource changed. SystemAutomation_Resource_Configuration_Change A new automated resource is added or an existing resource is deleted or modified. SystemAutomation_Relationship_Configuration_Change A new relationship is added or an existing relationship is deleted or modified. SystemAutomation_Domain_Status_Change 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. SystemAutomation_Request_Configuration_Change A new request is issued against an automated resource or an existing request is canceled. SystemAutomation_Request_Status_Change 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 7.2.1

216 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide Note: If you are running IBM Tivoli Netcool/OMNIbus V7.2.1, install Interim Fix 3 (7.2.1.5-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 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: ::

For SA z/OS: ::

Note: 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 StatusCommonObservedChanged v ConfigurationDeleted v 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 V4.1.0.1: Installation and Configuration Guide 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 Description Manager Descriptive name of the probe that collected and forwarded the alarm to the ObjectServer.

Value for System Automation events: tivoli_eif on . Agent Descriptive name of the manager that generated the event.

Value for System Automation Application Manager events: IBM Tivoli System Automation Application Manager. Node Identifies the host name from which the event comes from. AlertGroup Identifies the type of event issued by System Automation. See Table 42 on page 216 for a list of possible event classes. AlertKey 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} Severity 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. Summary Text summary describing the event. Service Name of the service affected by this event. Corresponds to field SAResourceName. Identifier 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 Table 47. Existing rules file fields for System Automation events (continued) Attribute Name Description Class The unique class for System Automation events. Value is 87725 (Tivoli System Automation). ExtendedAttr 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 OMNIbus „Severity“ field Fatal 5 (Critical) Error 4 (Major) Warning 3 (Minor) OK 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 OMNIbus „Severity“ field 60 (FATAL) 5 (Critical) 50 (CRITICAL) 5 (Critical) 40 (MINOR) 4 (Major) 30 (WARNING) 3 (Minor) 20 (HARMLESS) 2 (Warning) Else 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 About this task

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.

About this task

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 V4.1.0.1: Installation and Configuration Guide 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 87725 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 87725 is predefined in OMNIbus Version 7.3.1 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 7. Click Classes. The Classes pane opens. 8. Verify that the class with ID 87725 and label Tivoli System Automation is listed in the table.

Enable rules file for System Automation: About this task

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\\tivoli_eif.rules UNIX: $OMNIHOME/probes//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 V4.1.0.1: Installation and Configuration Guide 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 On Windows: Select Control Panel > Administrative Tools > Services. In the list of services, double-click the EIF probe, then click Stop. v On UNIX: Enter the following command on the command line $OMNIHOME/bin/nco_pa_stop -process 4. Restart the EIF probe. v On Windows: In the list of services, double-click OMNIbus EIF Probe, then click Start v On UNIX: Enter the following command on the command line: $OMNIHOME/bin/nco_pa_start -process

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

Chapter 4. Integrating 223 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.

About this task

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: About this task

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 https://:/ibm/EEZUIWebClient/ 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 V4.1.0.1: Installation and Configuration Guide 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: About this task

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 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 About this task

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 V4.1.0.1: Installation and Configuration Guide called SystemAutomation.baroc and is located in directory 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 , GC32–0669. 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.

About this task

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.

About this task

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 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: About this task

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: EEZLaunchSA.bat []

Example: "C:\Program Files\IBM\TECExtension\EEZLaunchSA.bat" C:\IBM\tec_console\jre\bin\ For AIX and Linux: EEZLaunchSA.sh []

where is the directory in which the TEC Extension for System Automation was installed and the optional parameter 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 V4.1.0.1: Installation and Configuration Guide 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: http://:s/ibm/EEZUIWebClient/EEZIscUrlBuilderServlet

where is the name of the host where the IBM Dashboard Application Services Hub runs which hosts the operations console and is the port that is used to access the operations console. Example: http://e2etest:16310/ibm/EEZUIWebClient/EEZIscUrlBuilderServlet 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. About this task

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. About this task

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 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 V4.1.0.1: Installation and Configuration Guide TivoliIntergratedPortal Dataforservicemodels, SourcesforEIFevents customcharts,views, neartermhistorymetric, andmarkerdata EventPump TBSMDashboard (TimeWindow Analyzer) Databases forz/OS Server Historicaldata

DiscoveryLibraryToolkit TivoliEnterprise OMNIbus Console WebGUI Tivoli Application Discoverydata Discovery Dependency LibraryBooks DiscoveryManager Service NetView model data

IBM Tivoli TBSM TBSM TivoliData Events Netcool/OMNIbus Events EIFevents Monitoring Common DataServer EIFProbe Warehouse Agent ObjectServer

IBM Tivoli Events Userdata System Eventsources Automation

UserRepository Probes Monitors LDAP or OMEGAMON ObjectServer

TBSMcomponents ITCAMfor Netcool/ InternetService Impact ITCAM OMNIbuscomponents Monitoring

Othercomponents

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 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 About this task

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 V4.1.0.1: Installation and Configuration Guide For more TBSM specific product information, see Tivoli Business Service Manager Knowledge Center. Configuring TBSM About this task

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 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 About this task

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 UNIX: cat EEZ_SystemAutomationResource.radsh | $TBSM_HOME/bin/rad_radshell v 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 About this task

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 V4.1.0.1: Installation and Configuration Guide 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 About this task

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 7.1.1.16 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 You can find the three xml customization files in the directory $TBSM_HOME/XMLToolkit/xml. Defining template mapping About this task

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