Tivoli System Automation Application Manager V4.1.0.1 ......Edition Notices Befor e using this...

System Automation Application ManagerVersion 4.1

Installation and Configuration Guide

SC34-2702-01

IBM

System Automation Application ManagerVersion 4.1

Installation and Configuration Guide

SC34-2702-01

IBM

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 toVersion 4 Release 1, Modification 0 of IBM Tivoli System Automation Application Manager, program number5724–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 managementcomponent 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, oryou 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 anyway 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 Contractwith IBM Corp.

Contents

Figures . . . . . . . . . . . . . . vii

Tables . . . . . . . . . . . . . . . ix

About this book . . . . . . . . . . . xiWho should read this guide . . . . . . . . . xiWhere to find more information . . . . . . . xiConventions used in this guide. . . . . . . . xiiISO 9000 . . . . . . . . . . . . . . . xiiRelated information . . . . . . . . . . . xiiHow to obtain publications . . . . . . . . . xiiiHow to reach us by email . . . . . . . . . xiii

What's new in this release . . . . . . xv

Chapter 1. Planning. . . . . . . . . . 1Planning for System Automation ApplicationManager . . . . . . . . . . . . . . . . 1

Packaging . . . . . . . . . . . . . . 2Prerequisites . . . . . . . . . . . . . 3Preparing for installation . . . . . . . . . 11Planning for an LDAP user registry . . . . . 17

Planning for the agentless adapter . . . . . . . 17Packaging . . . . . . . . . . . . . . 18Prerequisites . . . . . . . . . . . . . 19

Planning for high availability . . . . . . . . 26Planning for Distributed Disaster Recovery . . . . 27

Packaging . . . . . . . . . . . . . . 27Prerequisites . . . . . . . . . . . . . 28Preparing for installation . . . . . . . . . 31

Planning for the PowerHA adapter . . . . . . 32Packaging . . . . . . . . . . . . . . 32Prerequisites . . . . . . . . . . . . . 32Automating the PowerHA adapter . . . . . 33Behavior of the PowerHA adapter . . . . . . 33

Planning for the FOC adapter . . . . . . . . 34Roadmap . . . . . . . . . . . . . . 34Packaging . . . . . . . . . . . . . . 35Prerequisites . . . . . . . . . . . . . 35Planning and preparing for an highly availableFOC adapter . . . . . . . . . . . . . 37Behavior of the FOC adapter . . . . . . . 38

Planning for the VCS adapter . . . . . . . . 39Packaging . . . . . . . . . . . . . . 39Prerequisites . . . . . . . . . . . . . 40Automating the VCS adapter . . . . . . . 40Behavior of the VCS adapter for Solaris/SPARC 40

Planning for an end-to-end automation policy . . . 41The scope of end-to-end automation policies . . 41Identifying cluster-spanning dependencies . . . 43

Default directories . . . . . . . . . . . . 46Disaster recovery policy definition worksheets. . . 46

Chapter 2. Installing . . . . . . . . . 51Installing the middleware software . . . . . . 51

Contents of the middleware software DVDs . . 51Installing a DB2 server . . . . . . . . . 51Installing Jazz for Service Management . . . . 55

Installing System Automation Application Manager 59Using the installation wizard . . . . . . . 59Installing in silent mode . . . . . . . . . 64Upgrading to release 4.1 . . . . . . . . . 65Verifying the installation . . . . . . . . . 71Post-installation tasks . . . . . . . . . . 73Upgrading from a Try and Buy version to a fullproduct version . . . . . . . . . . . . 75Uninstalling . . . . . . . . . . . . . 75

Installing on new operating systems . . . . . . 76Installing fix packs . . . . . . . . . . . . 78

Obtaining fix packs . . . . . . . . . . . 78Archive naming conventions . . . . . . . 78Naming conventions of the update installerlocation. . . . . . . . . . . . . . . 78Usage instructions for the platform-specificarchives . . . . . . . . . . . . . . 79Installing a product fix pack . . . . . . . . 79Installing fix packs in a high availability setup . 80Uninstalling fix packs . . . . . . . . . . 81

Installing for high availability . . . . . . . . 81Installing for Distributed Disaster Recovery . . . 82

Installing the prerequisite software on both sites 82Installing and configuring System Automationfor Multiplatforms . . . . . . . . . . . 82Installing System Automation ApplicationManager on the first site . . . . . . . . . 82Configuring System Automation ApplicationManager on the first site . . . . . . . . . 83Setting up DB2 HADR. . . . . . . . . . 83Installing System Automation ApplicationManager on the second site . . . . . . . . 85Configuring System Automation ApplicationManager on the second site . . . . . . . . 85Creating tools for the replication of policy andcredential files . . . . . . . . . . . . 86Configuring all end-to-end automation adapterswith two System Automation ApplicationManager hosts . . . . . . . . . . . . 86Configuring high availability and contact retryinterval of all end-to-end automation adapters. . 87

Installing the remote agentless adapter . . . . . 87Using the installation wizard to install the remoteagentless adapter . . . . . . . . . . . 87Installing the remote agentless adapter in silentmode . . . . . . . . . . . . . . . 88Uninstalling the remote agentless adapter . . . 89Installing and uninstalling service for the remoteagentless adapter . . . . . . . . . . . 90

Installing the IBM PowerHA adapter . . . . . . 92Using SMIT to install the adapter . . . . . . 92

© Copyright IBM Corp. 2006, 2015 iii

Verifying the PowerHA adapter installation. . . 92Uninstalling the PowerHA adapter . . . . . 93

Installing the Failover Cluster (FOC) adapter . . . 93Installing the Failover Cluster CommandInterface optional feature . . . . . . . . . 93Using the installation wizard to install the FOCadapter . . . . . . . . . . . . . . . 94Installing the FOC adapter in silent mode . . . 95Upgrading the FOC adapter . . . . . . . . 95Verifying the FOC adapter installation . . . . 95Uninstalling the FOC adapter . . . . . . . 95

Installing the Veritas Cluster Server (VCS) adapter 96HACMP . . . . . . . . . . . . . . 96Using the installation wizard to install the VCSadapter . . . . . . . . . . . . . . . 96Installing the VCS adapter in silent mode . . . 96Verifying the VCS adapter installation . . . . 96Uninstalling the VCS adapter . . . . . . . 97

Chapter 3. Configuring . . . . . . . . 99Configuring the Application Manager . . . . . 99

Starting the Application Manager configurationdialog . . . . . . . . . . . . . . . 99Configuring the Application Manager settings 100

Configuring the Application Manager commonsettings . . . . . . . . . . . . . . . 105

Domain tab . . . . . . . . . . . . . 106Command Shell tab . . . . . . . . . . 107Discovery Library Adapter tab . . . . . . 108OSLC tab. . . . . . . . . . . . . . 108Event Publishing tab . . . . . . . . . . 109User Credentials tab . . . . . . . . . . 111Security tab . . . . . . . . . . . . . 111Logger tab . . . . . . . . . . . . . 112Save the common configuration . . . . . . 113Refreshing the Application Manager commonconfiguration . . . . . . . . . . . . 114Configuring System Automation ApplicationManager in silent mode . . . . . . . . . 114Configuring an alternative end-to-endautomation host . . . . . . . . . . . 114

Configuring an LDAP user registry . . . . . . 115Adding the LDAP user registry as a federatedrepository . . . . . . . . . . . . . 116Configuring supported entity types . . . . . 120Porting from a file-based repository to an LDAPrepository in a post-defined setup . . . . . 121

Configuring access to non-clustered nodes. . . . 127Configuring the local agentless adapter. . . . 128Configuring remote agentless adapters . . . . 134Controlling Agentless Adapters . . . . . . 138Configuring agentless adapters in silent mode 138Tuning the number of domains and resources ofagentless adapters . . . . . . . . . . . 139

Configuring virtual server & hardwaremanagement . . . . . . . . . . . . . 139

Configuring the hardware adapter . . . . . 139Refreshing the active hardware adapterconfiguration . . . . . . . . . . . . 145Testing the active hardware adapter . . . . . 145

Configuring the hardware adapter in silentmode . . . . . . . . . . . . . . . 146

Configuring storage replication . . . . . . . 146Configuring the TPC-R domain . . . . . . 146Refreshing the TPC-R domain settings . . . . 149Testing the TPC-R domain configuration . . . 149Configuring the TPC-R domain in silent mode 150

Configuring high availability . . . . . . . . 150High availability for System AutomationApplication Manager . . . . . . . . . . 150High availability for a disaster recovery setupon two sites . . . . . . . . . . . . . 168

Configuring Distributed Disaster Recovery . . . 175Configuring the destination for GDPS events 176Configuring the GDPS agent . . . . . . . 176Configuring synchronous communication withGDPS . . . . . . . . . . . . . . . 176

Configuring the PowerHA adapter . . . . . . 177Starting the PowerHA adapter configurationdialog . . . . . . . . . . . . . . . 178Configuring the PowerHA adapter settings . . 179Replicating the configuration files to othernodes in the domain . . . . . . . . . . 184Defining the PowerHA adapter automationpolicy . . . . . . . . . . . . . . . 185Removing the PowerHA adapter automationpolicy . . . . . . . . . . . . . . . 185Configuring the PowerHA adapter in silentmode . . . . . . . . . . . . . . . 185Controlling the PowerHA adapter . . . . . 186

Configuring the FOC adapter . . . . . . . . 186Starting the FOC adapter configuration dialog 186Configuring the FOC adapter settings . . . . 187Replicating the configuration files to othernodes in the domain . . . . . . . . . . 192Configuring the FOC adapter in silent mode 192Providing high availability for the FOC adapter 192

Configuring the VCS adapter . . . . . . . . 193Starting the VCS adapter configuration dialog 194Configuring the VCS adapter settings . . . . 195Replicating the configuration files to othernodes in the domain . . . . . . . . . . 201Defining the VCS adapter automation policy 202Removing the VCS adapter automation policy 202Configuring the VCS adapter in silent mode . . 203Controlling the VCS adapter . . . . . . . 203

Configuring in silent mode . . . . . . . . . 203Working in silent mode . . . . . . . . . 204Processing tasks manually . . . . . . . . 204Starting silent configuration . . . . . . . 205Silent mode input properties file . . . . . . 207Editing the input properties file . . . . . . 208Output in silent mode . . . . . . . . . 209

Configuration properties files . . . . . . . . 210Configuration properties files of the SystemAutomation Application Manager . . . . . 210Configuration properties files of the PowerHAadapter . . . . . . . . . . . . . . 212Configuration properties files for the VCSadapter . . . . . . . . . . . . . . 213

iv Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

Configuration properties files of the FOCadapter . . . . . . . . . . . . . . 214

Chapter 4. Integrating . . . . . . . . 215Event consoles . . . . . . . . . . . . . 215

IBM Tivoli Netcool/OMNIbus. . . . . . . 216Tivoli Enterprise Console . . . . . . . . 226Enabling event generation in SystemAutomation Application Manager . . . . . 229Enabling event filtering . . . . . . . . . 229

Tivoli Business Service Manager (TBSM) . . . . 230Integrating with System AutomationApplication Manager . . . . . . . . . . 232Prerequisites. . . . . . . . . . . . . 232Configuring TBSM . . . . . . . . . . 233Configuring the Discovery Library Toolkit. . . 235Integrating System Automation resources inTBSM . . . . . . . . . . . . . . . 237Customizing TBSM views to add informationfrom System Automation . . . . . . . . 242Configuring Tivoli Business Service Managerlaunch-in-context support . . . . . . . . 246Integration scenarios with Business ServiceManager . . . . . . . . . . . . . . 250

Tivoli Monitoring and Tivoli CompositeApplication Manager . . . . . . . . . . . 257

Prerequisites. . . . . . . . . . . . . 258Tivoli Monitoring overview . . . . . . . 258Integrating with System AutomationApplication Manager . . . . . . . . . . 260Creating a Tivoli Monitoring situation to triggeran automated restart . . . . . . . . . . 279Integrating with Tivoli Monitoring and TivoliComposite Application Manager (ITCAM). . . 280Integration Scenarios with Tivoli Monitoringand IBM Tivoli Composite Application Manager(ITCAM) . . . . . . . . . . . . . . 283

zEnterprise Hardware Management Console . . . 283Setting up the Hardware Management Console 283Obtaining the Hardware Management Consolecertificate . . . . . . . . . . . . . . 285Firewall considerations . . . . . . . . . 286

Working with the discovery library adapter . . . 287

eezdla options quick reference. . . . . . . 288eezdla options . . . . . . . . . . . . 288

JazzSM Administration Services . . . . . . . 288JazzSM integration scenario . . . . . . . 289Configuring JazzSM Administration Servicesintegration . . . . . . . . . . . . . 290Administering registered JazzSM AdministrationServices resources . . . . . . . . . . . 292

Chapter 5. Securing . . . . . . . . 299Security concepts . . . . . . . . . . . . 299Security tab . . . . . . . . . . . . . . 299Securing the connection to end-to-end adaptersusing SSL . . . . . . . . . . . . . . 300

Generating Keystore and Truststore with SSLpublic and private keys . . . . . . . . . 300Enabling SSL security in the ApplicationManager configuration . . . . . . . . . 302Enabling SSL security in FLA adapterconfigurations . . . . . . . . . . . . 303Optional: Enforcing usage of SSL for all FLAdomains . . . . . . . . . . . . . . 304

Securing communication with the zEnterpriseHardware Management Console . . . . . . . 305Managing the security setup for AgentlessAdapters . . . . . . . . . . . . . . . 305

Managing user credentials to access singlenodes with Agentless Adapters . . . . . . 305Managing SSH public keys . . . . . . . . 308

Chapter 6. Tuning . . . . . . . . . 311Tuning the number of domains and resources ofagentless adapters . . . . . . . . . . . . 311

Using IBM Support Assistant . . . . 313Installing IBM Support Assistant and the TivoliSystem Automation for Multiplatforms plug-in . . 313

Notices . . . . . . . . . . . . . . 315Trademarks . . . . . . . . . . . . . . 316

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 22. Installation wizard: Required RAM

information dialog . . . . . . . . . . 103. Examples for resource references to resources

and resource groups. . . . . . . . . . 424. Example for end-to-end automation groups

that are distributed over different platforms. . 445. Application Manager tab of the Automation

Manager Configuration dialog . . . . . . 1006. Non-clustered Nodes tab of the Automation

Manager configuration dialog . . . . . . 1017. Virtual Server / HW Management tab of the

Application Manager Configuration dialog. . 1028. Storage Replication tab of the Application

Manager Configuration dialog . . . . . . 1039. High Availability tab of the Application

Manager Configuration dialog . . . . . . 10410. Change Passwords tab of the Application

Manager Configuration dialog . . . . . . 10511. Maintaining configurations for multiple

Agentless Adapters . . . . . . . . . 12812. End-to-end high availability scenario with a

shared database file system . . . . . . . 15113. End-to-end high availability scenario with a

remote database file system . . . . . . . 15214. Resource groups, resources, and their

relationships . . . . . . . . . . . . 16515. Resource groups, resources, and their

relationships . . . . . . . . . . . . 17316. Configuration of the PowerHA adapter 17717. Application Manager Adapter Configuration -

Task Launcher for PowerHA . . . . . . 17818. Main window of the FOC Automation

Adapter Configuration dialog . . . . . . 18719. Configuration of the VCS adapter. . . . . 19420. VCS Automation Adapter Configuration

dialog . . . . . . . . . . . . . . 195

21. Sample configuration of launch entry 22522. Modifying menu entries that are displayed in

the Tools menu . . . . . . . . . . . 22623. TBSM basic architecture . . . . . . . . 23124. Identification Fields tab . . . . . . . . 24125. Tree template editor . . . . . . . . . 24526. Integration of System Automation with

Business Service Manager . . . . . . . 25227. TBSM Service Availability Page . . . . . 25328. TBSM Service Tree . . . . . . . . . . 25429. TBSM Service Tree . . . . . . . . . . 25530. TBSM Service Viewer . . . . . . . . . 25631. Tivoli System Automation operations console 25632. Tivoli System Automation Operations

Console . . . . . . . . . . . . . 25733. Overview of the IBM Tivoli Monitoring

infrastructure . . . . . . . . . . . 25934. Application Manager Local Agentless Adapter

Configuration . . . . . . . . . . . 26335. Agent attributes which can be added as

additional attributes . . . . . . . . . 27236. Perform an System Automation Application

Manager command shell command as actionfor an Tivoli Monitoring situation . . . . . 280

37. Example of System Automation ApplicationManager managing Tivoli MonitoringEndpoints and HA clusters . . . . . . . 281

38. JazzSM Administration Services integrationscenario . . . . . . . . . . . . . 289

39. Registering resources for OSLC . . . . . 29040. Using OSLC web services interfaces . . . . 29341. Keystore and Truststore generation using SSL 30142. Authentication with the Agentless Adapter on

a remote node . . . . . . . . . . . 30643. SSH key exchange overview . . . . . . 308

© Copyright IBM Corp. 2006, 2015 vii

viii Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

Tables

1. System Automation Application Managerproduct DVDs . . . . . . . . . . . . 2

2. Archive files of the electronic deliverable 33. Supported operating systems for System

Automation Application Manager . . . . . 44. Disk space requirements . . . . . . . . 115. Installation directory and Tivoli Common

Directory . . . . . . . . . . . . . 126. DB2 data for local and remote DB2 setup 137. WebSphere Application Server installation

parameters . . . . . . . . . . . . . 148. Installation parameters . . . . . . . . . 159. End-to-end automation domain name . . . . 15

10. WebSphere Application Server user ID . . . 1511. System Automation Administrator user ID 1612. Directories on the product DVD. . . . . . 1613. Remote Agentless Adapter product DVD 1814. Archive files of the electronic deliverable 1815. Supported operating systems for remote

agentless adapters . . . . . . . . . . 1916. Supported operating systems for non-clustered

nodes managed by the agentless adapter. . . 2017. Supported operating systems for Distributed

Disaster Recovery . . . . . . . . . . 2818. Supported operating systems of managed

clusters using GDPS for storage replication . . 2819. Supported operating systems of managed

clusters using TPC-R for storage replication . . 2920. Supported environments Distributed Disaster

Recovery with GDPS . . . . . . . . . 3021. Supported environments Distributed Disaster

Recovery with TPC-R . . . . . . . . . 3022. Supported operating systems for the PowerHA

adapter . . . . . . . . . . . . . . 3323. Supported operating systems for the FOC

adapter . . . . . . . . . . . . . . 3624. Supported operating systems for the VCS

adapter . . . . . . . . . . . . . . 4025. Default directories . . . . . . . . . . 4626. Worksheet to define disaster recovery topology 4627. Worksheet to define disaster recovery

hardware . . . . . . . . . . . . . 4728. Worksheet to define disaster recovery

workload . . . . . . . . . . . . . 49

29. Archives for AIX platforms . . . . . . . 7930. Archives for Linux on System x . . . . . . 7931. Archives for Linux on System z . . . . . . 7932. Recommended end-to-end adapter and JEE

framework settings in a DR setup . . . . . 8733. Archives for applying service to remote

Agentless Adapter . . . . . . . . . . 9034. Default user IDs and groups of the System

Automation Application Manager. . . . . 12235. Role to group assignments: . . . . . . . 12436. Role to user ID assignment . . . . . . . 12537. Resources in the automation policy for the

end-to-end automation manager . . . . . 16538. Resources in the high availability policy for a

disaster recovery setup . . . . . . . . 17339. Resources in the PowerHA adapter

automation policy . . . . . . . . . . 18540. Resources in the VCS adapter automation

policy . . . . . . . . . . . . . . 20241. Generated input properties files . . . . . 20742. System Automation Application Manager

event class types . . . . . . . . . . 21643. Common System Automation status attributes

used in resource status change events(alerts.status). . . . . . . . . . . . 217

44. alerts.status: Resource, domain, eventidentification. . . . . . . . . . . . 218

45. alerts.status: Other attributes used in resourcestatus change events . . . . . . . . . 218

46. alerts.status: Domain status change events 21847. Existing rules file fields for System

Automation events. . . . . . . . . . 21948. Compound state to OMNIbus severity

mapping . . . . . . . . . . . . . 22049. EIF severity to OMNIbus severity mapping 22050. Event Severity to TBSM State Mapping 23351. Text-based incoming status rules for TBSM 24352. Launch-in-context action parameters . . . . 24953. eezdla return codes . . . . . . . . . 28754. Command line options for the discovery

library adapter . . . . . . . . . . . 28855. OSLC tab of the configuration utility 291

© Copyright IBM Corp. 2006, 2015 ix

x Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

About this book

This guide provides information needed to plan, install, configure, and upgradeSystem Automation Application Manager (from here on referred to as SystemAutomation Application Manager) and the automation adapters for the followingclustering 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 guideThis guide is for planners, installers, and administrators who plan to install andconfigure System Automation Application Manager.

Where to find more informationThe 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-00v System Automation Application Manager Installation and Configuration Guide,

SC34-2702-00v 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 inthe following books:v System Automation for Multiplatforms Administrator's and User's Guide,

SC34-2698-00v System Automation for Multiplatforms Installation and Configuration Guide,

SC34-2699-00v System Automation for Multiplatforms Reference, SC34-2700-00v 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:

© Copyright IBM Corp. 2006, 2015 xi

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.saam.doc_4.1/welcome.html

http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=%2Fcom.ibm.samp.doc_4.1%2FSAMP-homepage.html

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

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

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

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

Conventions used in this guideThis guide uses several conventions for special terms and actions and operatingsystem 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://<hostname.yourco.com>/index.html

v Frequently, variables are used to indicate a root installation directory:– Root installation directory of System Automation Application Manager:

<EEZ_INSTALL_ROOT> or EEZ_INSTALL_ROOT– WebSphere® Application Server root installation directory: <was_root> or

was_root– Runtime root directory of Integrated Solutions Console: <isc_runtime_root> or

isc_runtime_rootv Directories are shown with forward slashes (/), unless operating-system specific

information is provided. On Windows systems, you should use backwardslashes (\) 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 9000ISO 9000 registered quality systems were used in the development andmanufacturing of this product.

Related informationFind out where to find more information about products related to SystemAutomation Application Manager.

Knowledge Centers:

WebSphere Application Server publications:

The latest versions of all WebSphere Application Server publications can befound in the WebSphere Application Server Knowledge Center.

xii Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

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

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

http://www.ibm.com/support/knowledgecenter/SSEQTP/mapfiles/product_welcome_was.html?lang=en

IBM® DB2® publications:The latest versions of all DB2 publications can be found in the DB2 forLinux UNIX and Windows Knowledge Center.

IBM GDPS® publications:The latest versions of all GDPS publications can be found in the TivoliNetView 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 CommonReporting Knowledge Center.

IBM Tivoli Storage Productivity Center for Replication (TPC-R) publications:The latest versions of all publications can be found in the Tivoli StorageProductivity 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 publicationsThe 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 emailIf you would like to contact us by email, send your comments [email protected]

About this book xiii

http://www.ibm.com/support/knowledgecenter/SSEPGG/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSEPGG/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSDG28/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSDG28/welcome?lang=en

http://www.redbooks.ibm.com/

http://www.redbooks.ibm.com/redbooks/pdfs/sg246374.pdf

http://www.ibm.com/support/knowledgecenter/SSH2DF/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSH2DF/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSMN28/welcome?lang=en

http://www.ibm.com/support/knowledgecenter/SSMN28/welcome?lang=en

http://www.ibm.com/software/support/isa

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 ApplicationManager version 4.1.

New DASH user interface for the operations consoleThe System Automation operations console is completely redesigned, basedon 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 ApplicationServices Hub capabilities.

– Customize predefined dashboards, for example change widget layoutor configure displayed columns.

v The predefined dashboard Domain and Automation Health provides agraphical status overview and drill down capabilities for more details.

v Use the predefined dashboard Explore Automation Nodes to explore alldomains and nodes that are connected to System AutomationApplication Manager and drill down to the hosted resources.

v The predefined dashboard Operate End-to-End Resources displaysautomated resources and a graphical view of resource relationships.

v You can now allow user requests against multiple resources at a timev 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 groupThe server group is a new policy element, designed to group resourcestogether, which have to react to dynamic load requirements by addingmembers if needed. The server group introduces automatic failovercapabilities for its members and allows to dynamically start and stop sparemember 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 ApplicationManager, 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 Managerexploits new features of the middleware software. Therefore, upgrade themiddleware software, in particular the version of Jazz for ServiceManagement, if you upgrade System Automation Application Manager toservice level 4.1.0.1 or higher.

© Copyright IBM Corp. 2006, 2015 xv

xvi Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

Chapter 1. Planning

Planning for System Automation Application Manager before introducing itssoftware into your enterprise system helps ensure that the system you implementmeets your needs and adapts to your existing infrastructure. This topic describeshow to plan for System Automation Application Manager, including assessing yourcurrent infrastructure.

Planning for System Automation Application ManagerPrepare the installation of System Automation Application Manager on AIX andLinux systems. Check out first if you meet all required prerequisites, before youstart your installation.

System Automation Application Manager manages the system as a whole throughconnections to these other products. The products are linked together byautomation adapters. The adapters for System Automation for Multiplatforms andIBM Tivoli System Automation for z/OS are packaged with those products. Allother automation adapters are packaged with System Automation ApplicationManager.

© Copyright IBM Corp. 2006, 2015 1

PackagingYou can order System Automation Application Manager as a media pack ordownload the electronic deliverable from an IBM software distribution downloadsite. The URL for the electronic distribution is sent after purchasing the product.

Media shipmentThere is a separate DVD for each supported operating system. Thefollowing table lists the versions of the product DVDs that are available forSystem Automation Application Manager. To install the product, use theinstallation wizard file listed in the right column of the table.

Table 1. System Automation Application Manager product DVDs.

Operatingsystem Product DVD label Installation wizard file

AIX® Tivoli System Automation Application ManagerV4.1 for AIX

EEZ4100AIX/AIX/setup.bin

SA Application Managerhighly available installed

Systems

SA Application Managerremotely installed

Agentless Adapter Systems

MS Failover ClusterwithSA Application Manager“MSCS Adapter”

ITM / ITCAMTEMS

HACMP/ PowerHA ClusterwithSA Application Manager“HAC Adapter”

Veritas CS ClusterwithSA Application Manager“VCS Adapter”

SA z/OS SysplexwithSA Application Manager“ING Adapter”

SA for MultiplatformsCluster withSA Application Manager“SAM Adapter”

SAUser

Webbrowser

SA Application Manager componentor bundled Adapter

Other product component(with SA Application Manager Adapter)

1

2

3

4

5

Single Node Systemsattached as “RemoteEndpoints”to Agentless Adapter

Systems withITM / ITCAM agentsattached to TEMS

High Availability / Automation Clusters

Figure 1. Overview of System Automation product family

2 Tivoli System Automation Application Manager V4.1.0.1: Installation and Configuration Guide

Table 1. System Automation Application Manager product DVDs (continued).

Operatingsystem Product DVD label Installation wizard file

Linux onSystem x®

Tivoli System Automation Application ManagerV4.1 for Linux on System x

EEZ4100I386/i386/setup.bin

Linux onSystem z®

Tivoli System Automation Application ManagerV4.1 for Linux on System z

EEZ4100S390/s390/setup.bin

For information about the middleware software DVDs that are shippedwith System Automation Application Manager, see “Contents of themiddleware software DVDs” on page 51.

Electronic distributionEach supported operating system has a separate electronic deliverable. Thefollowing tables list the archives that you need to install SystemAutomation Application Manager.

Table 2. Archive files of the electronic deliverable

Operatingsystem Archive name Description

AIX® SA_AM_4.1_AIX.bin The archive isself-extracting.

Linux onSystem x®

SA_AM_4.1_LinSysX.tar To extract the archiveGNU tar 1.13 or later isrequired. Use the tar-xf command toextract the files to atemporary directory.

Linux onSystem z®

SA_AM_4.1_LinSysZ.tar To extract the archiveGNU tar 1.13 or later isrequired. Use the tar-xf command toextract the files to atemporary directory.

After extracting the archive, the directory structure is identical to thedirectory structure on the corresponding DVD.

PrerequisitesMake sure you fulfill the software and hardware requirements for SystemAutomation Application Manager.

Supported operating systemsSystem Automation Application Manager supports various versions of AIX andLinux operating systems.

The following table lists the operating systems that are supported for SystemAutomation Application Manager, including the local Agentless Adapter.

If you want to exploit the Distributed Disaster Recovery functionality, refer to thefollowing tables:v Table 17 on page 28, Supported operating systems for Distributed Disaster

Recoveryv 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 usingTPC-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 EnterpriseServer 10 (64 bit)

X X


X X

Red Hat Enterprise Linux5 (64 bit)3 X X

Red Hat RHEL Linux 6(64 bit)

X X

Red Hat RHEL Linux 7(64 bit)4 X X

AIX 6.12 X

AIX 7.12 X

The following Service Pack or technology levels are supported, unless one of thenotes 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 alsosupported.Systems with IA64 architecture are not supported.All supported operating systems are also supported when running underVMware.All listed Linux operating systems running under the Red Hat EnterpriseVirtualization Hypervisor (RHEV-H) KVM version 5.4 or higher are alsosupported. However, the live migration functionality provided by thishypervisor is not supported.

2. System Automation Application Manager does not support AIX WorkloadPartitions (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 prerequisitesBefore you start to install System Automation Application Manager, check if allprerequisites are installed or configured.

The following prerequisites must be satisfied before you can start the installationwizard 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


installed as described in “Installing Jazz for Service Management” on page 55.No other WebSphere Application Server product installation must exist on thesystem.

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 DB2Administration Guide: Implementation.

v A Korn shell must be installed and accessible using /usr/bin/ksh. A Korn shellis required for the system where the Application Manager server is installed aswell as for each system where a remote agentless adapter is installed.

v The local agentless adapter that is installed as part of System AutomationApplication Manager requires the 32-bit version of the pluggable authenticationmodule (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 SystemAutomation Application Manager to work properly.

v The user ID that is used to run the installer for System Automation ApplicationManager 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 ApplicationManager or a remote agentless adapter can be installed. These libraries arecontained 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 ApplicationManager or a remote agentless adapter can be installed. The required librariesare 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 byIBM Tivoli Monitoring or by Composite Application Manager. These TivoliMonitoring managed resources are integrated by using existing Tivoli Monitoringagents. The agentless adapter retrieves monitoring information from TivoliMonitoring Agents and performs start and stop operations via these agents.


The supported IBM Tivoli Monitoring versions for this feature are:v 6.2v 6.2.1v 6.2.2v 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 agentsv OS agents

System Automation Application Manager provides predefined templates for theintegration of the following agents:v Apache Web Serverv WebSphere Application Serverv DB2v Custom agents built with the Tivoli Monitoring Agent Builderv Linux OS Agentv UNIX OS Agent

Middleware software requirementsInstall all required middleware software before you start to install SystemAutomation Application Manager.

The following middleware software must be installed on the system on whichSystem Automation Application Manager runs before the component itself can beinstalled: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 Manageris DB2. There are different options how to set up DB2. When you plan toinstall System Automation Application Manager, decide which option youwant to choose. You have the following options:

Local DB2 setupThe DB2 server is installed and runs on the same node on whichSystem Automation Application Manager is installed.

Remote DB2 setupThe DB2 server is installed and runs on a node other than the nodeon which System Automation Application Manager is installed. Inthis case, you need to install a DB2 JDBC driver on the SystemAutomation Application Manager node.

DB2 software prerequisitesBefore you can install System Automation Application Manager, IBM DB2must be installed on the system where the database of System AutomationApplication 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 SystemAutomation Application Manager Version 4.1. If you order System


Automation Application Manager Version 4.1 after fix pack 4.1.0.1 isavailable, IBM DB2 Version 10.5 for Linux, UNIX, and Windows, LimitedUse edition is bundled with System Automation Application Manager. Inthis case, you can also install this DB2 version. Alternatively, you can usethe following database versions as well:v IBM DB2 for Linux, UNIX, and Window, Workgroup Server Edition,

Version 10.1 (64-bit) or higherv IBM DB2 10 for z/OS or higher

Note: You are not entitled to use the DB2 Enterprise Server Edition that isbundled with Jazz for Service Management for System AutomationApplication Manager purposes.

Local DB2 setupNo additional prerequisites are required for a local DB2 setup. Ifyou are using a local DB2 setup, the DB2 definitions are processedby the installation program. It creates the end-to-end automationmanagement database and the database tables during theinstallation of System Automation Application Manager.

Remote DB2 setupManual 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 ServerIBM Tivoli System Automation Application Manager supports the 32-bitversion of WebSphere Application Server only. Make sure that WebSphereApplication 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 notsupported.

Check the following publication to find out which requirements need to bemet 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 alsoreferred to as Installation Guide. Make sure that all requirements forinstalling and running WebSphere Application Server are met.Otherwise, System Automation Application Manager might not workproperly.

All versions of WebSphere Application Server publications can be found at:

http://www.ibm.com/software/webservers/appserv/was/library/

Jazz for Service ManagementThe versions of the Jazz for Service Management components listed below


http://www.ibm.com/software/webservers/appserv/was/library/

are those contained on the product DVDs and in the correspondingelectronic deliverables that you receive when you order SystemAutomation Application Manager 4.1. Starting with fix pack 4.1.0.1 theminimum versions of the Jazz for Service Management components havechanged to:v Jazz for Service Management, Version 1.1.2.0v IBM Dashboard Application Services Hub, Version 3.1.2.0v IBM WebSphere Application Server, Version 8.5.5.4

If you are planning to upgrade to System Automation ApplicationManager fix pack 4.1.0.1 or higher, you must also upgrade Jazz for ServiceManagement 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 issupported. You can choose to install WebSphere Application Serverwhen you install Jazz for Service Management, or you can use anexisting supported WebSphere Application Server instance.

Note: Only the 32-bit version of the IBM WebSphere SDK for Java issupported.

v Ensure that enough disk space is available for the installation. At least 3GBs are required. You can run the prerequisite scanner from the Jazz forService Management installation package to list the precise requirementsthat depend on your operating system. To run the prerequisite scanner,enter the following commands:

export JazzSM_FreshInstall=True <JazzSM_Image_Home>/PrereqScanner/prereq_checker.sh "ODP,DSH" detail

The prerequisite scanner prints the expected disk space and otherprerequisites.

v You can find the requirements report for IBM Dashboard ApplicationServices Hub on the following web page: System requirements report forIBM Dashboard Application Services Hub

v Jazz for Service Management Version documentationv Some extra features of Jazz for Service Management require a database

(for example, the registry services). If you plan to use one of thosefeatures, 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 browsersSystem Automation Application Manager has a web-based user interface. It isdisplayed in a web browser that connects to the Dashboard Application ServicesHub on which the System Automation Application Manager dashboards arerunning. The web browser can run on any system.

The following versions of web browsers are supported:


http://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProductByComponent?deliverableId=1315519207893&duComponent=Server_A7D380C0852011E2A2006CAA0925FE1B

http://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProductByComponent?deliverableId=1315519207893&duComponent=Server_A7D380C0852011E2A2006CAA0925FE1B

http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/psc_ic-homepage.html

v Microsoft Internet Explorer V9v Microsoft Internet Explorer V10v Firefox Extended Support Release (ESR) 17v Firefox Extended Support Release (ESR) 24

For updated information about the support of later browser versions, check theSoftware Product Compatibility Report for System Automation ApplicationManager.

Hardware requirementsMake sure your systems provide the required hardware requirements to installDB2.

The hardware requirements listed below refer to the installation of DB2. For moreinformation 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 SystemAutomation Application Manager.

The minimum required memory (RAM) is 4 GB or more to install WebSphereApplication Server and System Automation Application Manager on the sameserver. For large environments, it is recommended to have a system with 8 GBRAM. If you start to install System Automation Application Manager, a memorycheck is automatically processed. In case the server provides less than 4 GBoperational memory, a warning is displayed. In silent installation mode, thewarning 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.


http://www.ibm.com/software/reports/compatibility/clarity/index.jsp

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 ApplicationManager. Some of these products require TCP/IP connections.

You can install DB2, WebSphere Application Server and System AutomationApplication Manager on one server or on different servers, depending on yourarchitecture.

For example: Local DB2 setup: WebSphere Application Server, System AutomationApplication Manager, and the DB2 server run on the same system. Remote DB2setup: WebSphere Application Server and System Automation Application Managerrun 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 onanother system.

Provide TCP/IP connections between the following products and SystemAutomation Application Manager components:v WebSphere Application Server and the resource adaptersv WebSphere Application Server and the operations consolev 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 installSystem Automation Application Manager.

Figure 2. Installation wizard: Required RAM information dialog


The following disk space requirements must be met to install System AutomationApplication Manager.

Note: The table does not include the space required to install the middlewaresoftware.

Table 4. Disk space requirements

Description Default directory Disk space

Installation directory of SystemAutomation Application Manager

/opt/IBM/tsamp/eez/ 700 MB

WebSphere Application Server (whereautomation manager and operationsconsole are deployed)

AIX: /usr/IBM/WebSphere/AppServer/

Linux: /opt/IBM/WebSphere/AppServer/

100 MB

DB2 database ~db2inst1 120 MB

Temporary disk space needed forinstallation and installation log andresponse files

/tmp/Note: Make sure your /tmp directory has five times thesize of the installation file setup.bin.

1 GB

Configuration file directory and policypool directory of System AutomationApplication Manager

/etc/opt/IBM/tsamp/eez/cfg/

/etc/opt/IBM/tsamp/eez/policyPool/

1 MB

Tivoli Common Directory /var/ibm/tivoli/common/ 40 MB

Installer registry /var/ 1 MB

Preparing for installationCollect all the required information like configuration parameters and user IDs,before you start your installation.

Collecting the informationThe graphical installation of System Automation Application Manager iswizard-driven. Make sure that you specify all required parameters on theinstallation wizard panels and that your entries are correct.

About this task

The wizard guides you through the installation and prompts you for installationand configuration parameters. The following tables list the parameters you need tospecify on the installation wizard panels, in the order in which they must bespecified.

Installation directory and Tivoli Common Directory:

If you want to use different directory names other than the default names, makesure you are a aware of restrictions.

The parameters listed in the following table must always be specified.


Table 5. Installation directory and Tivoli Common Directory

Parameter Description Default

Installation directory name The directory to which the installablefeatures are installed.

In this guide, this directory is referred toas EEZ_INSTALL_ROOT.

When specifying a directory other than thedefault, observe the following restrictions:

/opt/IBM/tsamp/eez

v The directory name has to consist of theplatform-specific path separatorcharacter and alphanumeric characters(A..Z, a..z, 0..9).

v The underscore character (_) is allowed.

v The space and colon characters are notallowed.

Tivoli Common Directory The Tivoli directory for storingserviceability information.

During installation, you are only promptedfor input when no Tivoli CommonDirectory is found on the system.

In the Tivoli Common Directory, thesubdirectory eez is created for storingproduct-specific data.

In this guide, this directory is referred toas Tivoli_Common_Directory.

When specifying a directory other than thedefault (only possible if no Tivoli CommonDirectory already exists on the system),observe the following restrictions:

/var/ibm/tivoli/common

v The directory name has to consist of theplatform-specific path separatorcharacter and alphanumeric characters(A..Z, a..z, 0..9).

v The underscore character (_) is allowed.

v The space and colon characters are notallowed.

Installation parameters for DB2:

Make sure you have all required parameters available that are required to installDB2 on a local or remote server.

The parameters listed in the following table must be specified.


Table 6. DB2 data for local and remote DB2 setup


DB2 directory Local DB2 setup: The installation locationof the DB2 Database Manager.

If you are using a local DB2 setup, youuse the DB2 client that is part of the DB2server installation. In this case, you needto specify the DB2 server directory.

The location is detected on your systemand displayed as the default directory.

DB2 JDBC driver path onlocal system

For remote DB2 setup only: Path to thedirectory where the files DB2 JDBC arelocated.

DB2 instance host name Remote DB2 setup: The host name of theDB2 instance in which the automationmanager and operations consoledatabases are located.

DB2 instance port number The port number of the DB2 instance inwhich the automation manager andoperations console databases are located.Note: The installation wizard can retrievethe valid DB2 instance port numberautomatically. If you choose not to usethis function, the port number 50000 willbe displayed in the entry field on thecorresponding installation wizardwindow. This is the default port numberthat is assigned to DB2 during theinstallation of DB2. However, if this portis not free, a different port number isassigned automatically, which is why youneed to check if the default port numberis correct.

How you determine the correct portnumber is described in Tivoli SystemAutomation Application Manager, Referenceand Problem Determination Guide.

50001

Database instance ownername

The instance owner user ID of the DB2instance in which the automationmanager and operations consoledatabases are located.

In a local DB2 setup, this user ID will beused for creating the databases and tables.

In a remote DB2 setup, the database andthe tables must have already beencreated. The installation program does nochange to DB2 and neither creates a DBnor tables.

The user ID will be used by WebSphereApplication Server to connect to theautomation manager and operationsconsole databases and to select, insert,delete, and update rows in tables.

db2inst1


Table 6. DB2 data for local and remote DB2 setup (continued)


Database instance ownerpassword

The password for the instance owner userID of the DB2 instance in which theautomation manager and operationsconsole databases are located.

No default value is provided

Automation managerdatabase

Automation manager database for use byWebSphere Application Server.

In a local DB2 setup, a database with thisname will be created in the DB2 instancerelated to the specified instance owner.

In a remote DB2 setup, a database withthis name must already exist in theremote DB2 instance.

EAUTODB

Backend version Version of the back end DB2:

v ZOSUDB81: DB2 UDB V8.1 - running onz/OS

v ZOSUDB91: DB2 V9.1 - running on z/OS

v DIST: DB2 LUW- running ondistributed system

DB2_OPTN_UDB

WebSphere Application Server installation parameters:

The parameters listed in the following table are detected during the installation ofSystem Automation Application Manager.

Note: WebSphere Application Server administrative security must be enabledbefore you install System Automation Application Manager.

Table 7. WebSphere Application Server installation parameters


WebSphere Application Serverdirectory

The installation location ofWebSphere Application Server. Theremust be exactly one installation ofWebSphere Application Server onyour system.

The location is detected on yoursystem and displayed as the defaultdirectory.

WebSphere Application Server (WAS)profile name

The WebSphere Application Serverprofile to be used for the automationmanager and the operations console.

All existing profiles are detected onyour system and displayed in asingle-choice list.

WebSphere Application Server (WAS)server name

The server to be used for theautomation manager. The server name is detected on your

system and displayed as defaultvalue.

WAS Admin User ID The user ID of the WebSphereApplication Server administrator.

No default value is provided.

WAS Admin User Password The password of WebSphereApplication Server administrator userID.

No default value is provided.


Event console connection configuration data:

Make sure you have the required installation parameters available, if you want toutilize OMNIbus for end-to-end automation management events.

System Automation Application Manager can send EIF events about state changesof automated resources to IBM Tivoli Netcool/OMNIbus (OMNIbus).

Table 8. Installation parameters


Host Name The name of the host where the OMNIbus Probe for Tivoli EIF isinstalled.

localhost

Port Number The port number for the OMNIbus Probe for Tivoli EIF. 5529

For more information about utilizing OMNIbus for end-to-end automationmanagement, 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


Automation domainname

The domain name must be unique and may not be used for anyother automation domain.

The domain name must contain a maximum of 64 characters. Thecharacters used for the domain name are limited to the followingASCII characters: A–Z, a–z, 0–9, . (period), and _ (underscore).

FriendlyE2E

Obtaining the WebSphere Application Server user IDThe end-to-end automation engine requires a WebSphere Application Server userID to access the JEE framework. The user ID is created during the installation ofSystem 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


User ID WebSphere Application Server user ID for the end-to-endautomation engine.

eezdmn

Password Password of the user ID <none>

Obtaining the System Automation Administrator user IDDuring the installation of System Automation Application Manager, the initialTivoli System Automation administrator user is created in WebSphere ApplicationServer and authorized for all tasks and actions that can be performed from theSystem Automation operations console.


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


User ID User ID of the System Automation operations consoleadministrator

eezadmin

Password Password of the user ID <none>

Installation mediaSystem Automation Application Manager can be ordered from IBM as a mediapack or downloaded as an Electronic Software Distribution (ESD) image from anIBM software distribution download site.

There are multiple DVDs for each supported platform.

This is what the DVD labeled System Automation Application Manager V4.1 for<operating_system_name> contains:v The files for launching the installation wizardv The readme filev 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

<PLATFORM>¹ Product installer and files needed for installing the product

DOCS Documentation

INTEGRATION Assets that integrate System Automation Application Manager and other IBMproducts.

Note: <PLATFORM> is one of the following:– AIX– i386 (Linux on System x)– s390 (Linux on System z)

Supported languagesSystem Automation Application Manager supports English and a set of otherlanguages.

In addition to English, System Automation Application Manager supports thefollowing languages:v Germanv Spanishv French


v Italianv Japanesev Koreanv Brazilian Portuguesev Simplified Chinesev Traditional Chinese

Planning for an LDAP user registryInformation about users and groups is stored in a user registry. By default, theWebSphere Application Server that is installed with Jazz for Service Managementand is used by System Automation Application Manager is configured to use alocal file-based user repository.

Companies often use a central user registry that is based on the LightweightDirectory Access Protocol (LDAP) to manage users and groups company-wide andprovide single sign-on to every service. Examples for LDAP servers:v IBM Tivoli Directory Serverv Resource Access Control Facility (RACF®)v Windows Server Active Directoryv OpenLDAP

You can set up an LDAP server and create an LDAP user registry to use withSystem Automation Application Manager. The WebSphere Application Server usesthis registry for user authentication and the retrieval of information about usersand groups to run security-related functions.

There are two different setup types:

Pre-definedThe LDAP user repository is configured in the WebSphere ApplicationServer before the installation of System Automation Application Manager.

The installer of System Automation Application Manager can already usethe configured LDAP repository for user creation and role assignments.

Post-defined

The LDAP user repository is configured in the WebSphere ApplicationServer after the installation of the System Automation ApplicationManager.

If you reconfigure the user repository after you installed SystemAutomation Application Manager, you must complete extra steps to portfrom a file-based repository to an LDAP user repository.

Planning for the agentless adapterDecide if you want to install the agentless adapter local or remote.

Installation for the local agentless adapter and remote Agentless Adapters isperformed in different ways. The local agentless adapter is automatically installedtogether with the System Automation Application Manager product as described in“Installing System Automation Application Manager” on page 59. You can installremote agentless adapters on systems other than the system where the ApplicationManager is installed. Only one instance of the agentless adapter can be installed ona remote node.


For more information, refer to System Automation Application ManagerAdministrator's and User's Guide.

PackagingThe remote agentless adapter is shipped with System Automation ApplicationManager. You can order System Automation Application Manager as a media packor download the electronic deliverable from an IBM software distributiondownload site. The URL for the electronic distribution is sent after purchasing theproduct.

Media shipmentInstall the remote agentless adapter from the DVD Tivoli SystemAutomation Application Manager V4.1 - Remote Clients all platforms.This DVD contains the installation wizards for all supported platforms. Toinstall the adapter, use the installation wizard file listed in the right columnof 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 Systemx®

EEZ4100Remote/I386/ALAdapt/setup.bin

Linux on POWER® EEZ4100Remote/PPC/ALAdapt/setup.bin

Linux on Systemz®

EEZ4100Remote/S390/ALAdapt/setup.bin

Electronic distributionThere is a separate electronic deliverable for each supported operatingsystem. The following tables list the archives that you need to install theremote agentless adapter.

Table 14. Archive files of the electronic deliverable

Operating system Archive name Description

Windows SA AM 4.1 RemoteClientWindows.exe

The archive is self-extracting.

AIX® SA AM 4.1 RemoteClientAIX.bin

The archive is self-extracting.

Linux on System x® SA AM 4.1 RemoteClientLinSysX.tar

To extract the archive GNU tar1.13 or later is required. Usethe tar -xf command to extractthe files to a temporary directory.

Linux on POWER® SA AM 4.1 RemoteClientLinPower.tar


Linux on System z® SA AM 4.1 RemoteClientLinSysZ.tar


After extracting the archive, the directory structure is identical to thedirectory structure on the corresponding DVD.


PrerequisitesYou 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 remoteagentless adapters. For a list of operation systems where remote applications thatare managed by an agentless adapter may run, see “Supported operating systemsfor non-clustered nodes managed by the agentless adapter” on page 20.

The operating system versions that are supported by the local agentless adapterare identical to the operating systems versions that are supported by SystemAutomation Application Manager in general. Refer to “Supported operatingsystems” 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(64 bit)

X X X

SUSE Linux Enterprise Server 11(64 bit)

X X X

Red Hat Enterprise Linux 5 (64bit)2 X X X

Red Hat RHEL Linux 6 (64 bit) X X X

Red Hat RHEL Linux 7 (64 bit)3 X X X

AIX 6.1 X

AIX 7.1 X

Windows Server 2012 R1 X

Windows Server 2012 R2 X

Note:1. IBM System x with IA32, EM64T, or AMD64 architecture.

Any other systems with IA32, EM64T, or AMD64 architecture are alsosupported.Systems with IA64 architecture are not supported.All supported operating systems are also supported when running underVMware.All listed Linux operating systems running under the Red Hat EnterpriseVirtualization Hypervisor (RHEV-H) KVM version 5.4 or higher are alsosupported.

2. The supported minimum level is Red Hat Enterprise Linux 5.6 .3. Platform support is introduced with fix pack 4.1.0.1.

Note:

1. The agentless adapter requires the 32-bit version of the pluggableauthentication 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 withthe following minimum Service Refresh levels:v Java 6 SR9 FP1: AIX package Java6.sdk 6.0.0.265v Java 7.0 SR8: AIX package Java7.jre/Java7.sdk 7.0.0.145v Java 7.1 SR2: AIX package Java71.jre/Java71.sdk 7.1.0.25


Supported operating systems for non-clustered nodes managedby the agentless adapterThe agentless adapter manages non-clustered nodes on various versions ofWindows, AIX, Linux, Solaris, z/OS, and HP-UX operating systems.

Remote applications managed by the agentless adapter via remote protocols suchas SSH can be located on one of the following supported operating systems:

Table 16. Supported operating systems for non-clustered nodes managed by the agentlessadapter

Operating systemIBM System

x1, 2PowerSystems2

IBMSystem z2

Otherplatforms2

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




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 Desktop 5.0 x x

Red Hat Desktop 6.0 x x

SOLARIS 8 x x SPARC

SOLARIS 9 x x SPARC


Table 16. Supported operating systems for non-clustered nodes managed by the agentlessadapter (continued)

Operating systemIBM System

x1, 2PowerSystems2

IBMSystem z2

Otherplatforms2

32 bit 64 bit

SOLARIS 10 x x SPARC

z/OS V1.6, V1.7, V1.8, V1.9, V1.10,V1.11, V1.12, V1.133 x

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 alsosupported.All supported operating systems are also supported when running underVMware.

2. Secure communications with targets, using SSH Protocol (SSH version 2),requires the use ofv OpenSSH 3.6.1 or higherv AIX targets: OpenSSH 4.7v Sun targets: SSH 1.1v z/OS targets: OpenSSH 3.8.1 package provided by IBM Ported Tools for

z/OSv 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 Toolsfor z/OS (OpenSSH) to be installed.v Documentation for OpenSSH can be found here:

z/OS UNIX System Servicesv The IBM Ported Tools document is the authoritative source for information

describing how to set up OpenSSH on z/OS. OpenSSH is supported onz/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 ofUSER.PARMLIB(TCPPROF2)Add ”22 TCP SSHD5 ; SSH Server” to the PORT section ofUSER.PARMLIB(TCPPROF2)

v Edit /etc/ssh/sshd_config, uncomment the UsePrivilegeSeparationparameter 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 listeningon 0.0.0.0 port 22. to verify if the server is started.

Required settings for target machines that hostIBM.RemoteResource resourcesThe agentless adapter uses the IBM Remote Execution and Access (RXA)technology to start, stop, and monitor resources on remote nodes. This topicdescribes the RXA requirements that must be fulfilled by remote nodes that hostthe resources defined for an agentless adapter domain. These nodes are referred toas target-nodes.


http://www.ibm.com/servers/eserver/zseries/zos/unix/port_tools.html

Note: Many RXA operations require access to resources that are not generallyaccessible by ordinary user accounts. Therefore, for all target platforms, the accountnames that you use to log onto remote machines must have administrativeprivileges on each target machine.

Windows targets:

Some IBM Remote Execution and Access (RXA) operations rely on VBScript andWindows Management Instrumentation (WMI) calls to execute scripts on Windowstargets.

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, whichis 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 –> <someconnection> --> Properties –> Internet Protocol (TCP/IP) –> Advanced –>WINS –> Enable NetBIOS over TCP/IP.

Consult the documentation for your firewall to ensure that these ports are notblocked for inbound requests. To determine if security policies are blocking theseports, select: Start –>Settings –> Control Panel –> Administrative Tools.

Depending on whether your policies are stored locally or in Active Directory, thenext 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 DirectoryAdministrative Tools –> Default Domain Controller Security Settings –> IPSecurity Policies on Active Directory

Examine the IP security policies, and edit or remove filters that block the portslisted above. The following list contains the ports reserved for NetBIOS. Ensurethat all ports currently used by RXA are not blocked.PortNumber Use135 NetBIOS Remote procedure call. At this time, RXA does not use this port.137 NetBIOS Name service138 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 serverservice has been started: Select Control Panel –> Administrative Tools –> Services–> Server. RXA requires that Simple File Sharing is disabled.


For an example of a batch file to manage agentless adapter resources on aWindows target node, see System Automation Application ManagerAdministrator's andUser's Guide.

Windows XP

For Remote Execution and Access to work, Windows XP systems must have SimpleFile 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 2comes 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 youraccount is not a domain user account.

For details of how to disable User Account Control, refer to the relevantinformation provided in section Windows Vista.

Windows Vista

The new User Account Control feature of Windows Vista requires to run severalsteps before RXA applications can communicate with Vista targets.

If you have a domain user account, ensure that the local and the target machineare both members of a Windows domain.

If you are a member of a local administrators group and you use a local useraccount, complete the three steps to be able to run administrative tasks on thetarget machine.

Step 1.Enable the built-in Administrator account and use it to connect. To enablethe built-in Administrator account, open the Windows Control Panel andselect Administrative Tools –> Local Security Policy –> Security Settings–> Local Policies –> Security Options. Then double-click Accounts:Administrator account status and select Enable.


Step 2.Disable User Account Control if a different Administrator user account isused to connect to the Vista target. To disable User Account Control, openthe Windows Control Panel and select Administrative Tools –> LocalSecurity Policy –> Security Settings –> Local Policies –> SecurityOptions. Then double-click User Account Control: Run all administratorsin Admin Approval Mode and select Disable. Reboot your system.

Step 3.Disable User Account Control when you administer a workstation with alocal user account (Security Account Manager user account). Otherwise,you don't connect as a full administrator and are not able to performadministrative tasks. To disable User Account Control, run the followingtasks: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 thefollowing 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 servicestatus is started. If not, right-click Remote Registry and click Start. Toavoid problems with the manual start up, set the Remote Registry servicestart-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.


Windows Vista FDCC (Federal Desktop Core Configuration)

With Windows Vista FDCC custom security settings, it is impossible to connect tothis operating system using RXA.

Perform the following steps on Windows Vista FDCC to enable RXA to connect tothis 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 forthis 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 withFDCC.

2. RXA is tested with Windows Vista FDCC image that can be found on thewebsite of National Institute of Standards and Technology.

Unix and Linux targets:

IBM Remote Execution and Access (RXA) does not supply SSH code for UNIXmachines. Ensure SSH is installed and enabled on any target you want to accessusing SSH protocol.

OpenSSH 3.71 or higher contains security enhancements not available in earlierreleases. Remote Execution and Access cannot establish connections with anyUNIX 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 targetshell. On Solaris targets, the Korn shell (ksh) is used instead due to problemsencountered with sh.

In order for RXA to communicate with Linux and other SSH targets usingpassword authentication, you must1. 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 callingSSHProtocol.setUSESFTP(true), make sure that the SFTP server is enabled on thetarget machine. Note that the location of the sftp-server is OS dependent. It istypically found in the following locations:v Solaris: /usr/lib/ssh/sftp-server


http://nvd.nist.gov/fdcc/download_fdcc.cfm

v Linux: /usr/libexec/openssh/sftp-serverv HP-UX: /opt/ssh/libexec/sftp-serverv AIX: /usr/sbin/sftp-server

The sshd_config file contains a line similar to the one below. Make sure the linethat enables the sftp-server subsystem is not commented out, and that it points tothe 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 Toolsfor z/OS (OpenSSH) installed.

You can order IBM Ported Tools (OpenSSH) and download the documentationfrom 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 ofUSER.PARMLIB(TCPPROF2).

Step 3 Add "22 TCP SSHD5 ; SSH Server" to the PORT section ofUSER.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 bybrowsing /tmp/syslogd/auth.log and looking for a message stating "sshd16777233: Server listening on 0.0.0.0 port 22."

Planning for high availabilityProvide and configure the necessary prerequisites before you start to install thehigh availability setup.

The following prerequisites must be met, if you want your system to be highlyavailable: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 Recoveryfeature components are not part of the policy.

v Make sure all prerequisites of the respective System Automation forMultiplatforms version that you are using are met. Check the SystemAutomation for Multiplatforms documentation for further details.

v IBM.StorageRM must be installed on all nodes. On Linux, the default installationincludes IBM.StorageRM. If you use System Automation for Multiplatforms V2.3on AIX, IBM.StorageRM is optionally.



http://www-03.ibm.com/systems/resources/fot4os02.pdf

http://www-03.ibm.com/systems/resources/fot4os02.pdf

v A virtual IP address must be available for the WebSphere Application Server. Seethe Host name or IP address field on the Domain tab of the AutomationManager Common Configuration dialog. To start the dialog, enter cfgeezdmn onthe command prompt. For more information, see “Domain tab” on page 106.

v A shared volume must be available for the System Automation ApplicationManager policy pool. See the Policy pool location field on the Domain tab ofthe Automation Manager Common Configuration dialog. To start the dialog,enter cfgeezdmn on the command prompt. For more information, see “Domaintab” on page 106.

v If you want to include DB2 in your high availability policy, a shared volumemust be available for the DB2 database. See the DB2 tab in configuration dialogcfgeezdmn.

v If you want to include the System Automation Application Manager AgentlessAdapter in your high availability policy, provide a shared volume for its policypool. See the Policy pool location field in “Adapter tab” on page 128.

v Enable the following ports in the firewall software for the communicationbetween agentless adapter and target non-clustered nodes:– UNIX SSH protocol

ssh 22/TCP

– Windows WIN protocolDirect hosted "NetBIOS-less" SMB traffic uses portsmicrosoft-ds 445/TCPmicrosoft-ds 445/UDP

For NetBIOS over TCP (NBT) enable the following portsnbname 137/UDPnbname 137/TCPnbdatagram 138/UDPnbsession 139/TCP

v System Automation Application Manager must be installed on all nodesincluding the middleware (DB2, WebSphere Application Server).

v Installation parameters for DB2 and the WebSphere Application Server must bethe same on all nodes to allow these applications to move to another nodeseamlessly. These parameters are:1. WAS - Application server name2. WAS - Application server port3. WAS - Profile directory4. DB2 – installation directory5. DB2 – instance owner user ID6. DB2 – instance owner mount point

Planning for Distributed Disaster RecoveryDistributed Disaster Recovery is shipped with System Automation ApplicationManager.

PackagingThe Distributed Disaster Recovery functionality is installed as part of the SystemAutomation Application Manager installation.

If you wish to exploit the Distributed Disaster Recovery functionality, it is notrequired to install additional programs.


PrerequisitesThe supported operating systems depend on the storage replication technology,which you are planning to use.

The functionality provided by the Distributed Disaster Recovery feature isavailable on the operating systems listed in “Supported hardware and operatingsystems.”

Supported hardware and operating systemsHardware and operating system prerequisites vary depending on the storagereplication technology, that is used: Distributed Disaster Recovery with GDPS, orDistributed Disaster Recovery with TPC-R.

The following tables show the operating system platforms that are supported bythe Distributed Disaster Recovery feature.

Distributed Disaster Recovery The supported operating systems for Distributed Disaster Recovery arelisted in Table 17

Distributed Disaster Recovery with GDPSIf you use Geographically Dispersed Parallel Sysplex™ (GDPS) for storagereplication, the supported operating systems for clusters that are managedby the Distributed Disaster Recovery feature are listed in Table 18.

Distributed Disaster Recovery with TPC-RIf you use Tivoli Storage Productivity Center for Replication (TPC-R) forstorage replication, the supported operating systems for clusters that aremanaged by the Distributed Disaster Recovery feature are listed in Table 19on page 29.

Table 17. Supported operating systems for Distributed Disaster Recovery

Operating system: System x Power Systems System z


TPC-R GDPS


TPC-R GDPS

Red Hat RHEL 5.0 AS (64bit)

TPC-R GDPS


TPC-R GDPS

AIX 6.1 TPC-R GDPS

AIX 7.1 TPC-R GDPS

Table 18. Supported operating systems of managed clusters using GDPS for storagereplication



SAMP, agentlessadapter2


SA MP, agentlessdapter2




SA MP, agentlessadapter2






Table 18. Supported operating systems of managed clusters using GDPS for storagereplication (continued)






AIX 6.1 SAMP, agentlessadapter2,

PowerHA1

AIX 7.1 SAMP, agentlessadapter2,

PowerHA1

Note:

1. Non-stretched clusters: System Automation for MultiplatformsStretched clusters: PowerHA

2. Agentless adapter represents the non-clustered nodes managed by the agentlessadapter that is part of the System Automation Application Manager product.The operating systems listed in “Supported operating systems for non-clusterednodes managed by the agentless adapter” on page 20 are supported. However,GDPS storage replication is not generally supported for these additionaloperating systems (but this is dependent upon your own testing activities).

Table 19. Supported operating systems of managed clusters using TPC-R for storagereplication



SA MP SA MP


SA MP SA MP


SA MP SA MP


SA MP SA MP

AIX 6.1 SA MP, PowerHA

AIX 7.1 SA MP, PowerHA

The operating systems of managed clusters correlate with the operating systemsthat are supported by the end-to-end automation adapters. Automation adaptersare used to integrate the corresponding first level automation domains into theend-to-end automation environment.

In Table 18 on page 28 and Table 19, SA MP represents the end-to-end automationadapter that is part of the System Automation for Multiplatforms product. Formore specific information, see the operating system support table in Table 3 onpage 4.

PowerHA represents the High Availability Cluster Multi-Processing (PowerHA)end-to-end automation adapter that is part of System Automation ApplicationManager. For more specific information about the operating system details, see“Prerequisites” on page 32.


Supported GDPS environmentsYou can use only specific versions of the Distributed Disaster Recovery feature incombination with GDPS.

The following versions for Distributed Disaster Recovery with GDPS aresupported.

Table 20. Supported environments Distributed Disaster Recovery with GDPS

Characteristic Supported environment

Mirroring technique PPRC controlled by GDPS (for non-stretchedclusters)

AIX LVM (for stretched clusters)

Hardware Blade Center for System p® and System x®

with Management Module (MM) serviceprocessors.

Other hardware is supported by a scriptexit.

GDPS/PPRC is a software prerequisite for Distributed Disaster Recovery. For moreinformation about the prerequisites of GDPS/PPRC, see GDPS.

If you are planning to implement a setup with a System Automation ApplicationManager on both sites, additional prerequisites apply. To support this setup, aspecial type of System Automation Application Manager high availability policy isrequired. Refer to “Planning for high availability” on page 26 for detailed planninginformation regarding the Application Manager high availability policy, with thefollowing exceptions:v Only a single node in the high availability cluster is requiredv A virtual IP address is not requiredv A shared volume for the policy pool is not requiredv 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 forreplication.

v You must configure and activate the high availability policy on both sites.

Supported TotalStorage Productivity Center for Replication(TPC-R) environmentsYou can use only specific versions of the Distributed Disaster Recovery feature incombination with TPC-R.

The following environments for Distributed Disaster Recovery with TotalStorageProductivity 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 sessionscontrolled by TPC-R

System Automation Application Manager V3.2.2 supports the followingTotalStorage Productivity Center for Replication versions:v TotalStorage Productivity Center for Replication V3.4.1.8 and higher PTFsv TPC-R V4.1.1.1 or later (for example 4.1.2) and PTFs


http://www.ibm.com/systems/z/advantages/gdps/getstarted/gdpspprc.html

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 SystemAutomation Application Manager EEZI0063E, refer to the latest release notes todetermine which service level is required.

Preparing for installationProvide and configure the necessary prerequisites before you start to install yourDistributed 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 policythat requires DB2 HADR. For this setup you must have a corresponding DB2HADR 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 forz/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 apassword in GDPS

v The disaster recovery policy is available and activated, see System AutomationApplication Manager Administrator's and User's Guide.

v The GDPS agent must be configured, see “Configuring the GDPS agent” on page176.

v The GDPS agent must be started, see System Automation ApplicationManagerReference and Problem Determination Guide.

v The hardware adapter and credentials must be configured, see “Configuring thehardware adapter” on page 139.

v The hardware adapter must be started, see System Automation ApplicationManagerReference 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 defaultname for the address space is IHSAEVNT

– The TCP/IP definition contains the port used by the NetViewEvent/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 communicationv 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/.




http://www.ibm.com/systems/z/advantages/gdps/

http://www.ibm.com/systems/z/advantages/gdps/

Planning for the PowerHA adapterIf you are already using IBM High Availability Cluster Multiprocessing for anexisting high availability cluster, System Automation Application Managerprovides the HACMP adapter to integrate resources that are managed by HACMPinto an end-to-end automation environment.

PackagingThe PowerHA adapter is shipped with System Automation Application Manager.You can order System Automation Application Manager as a media pack ordownload the electronic deliverable from an IBM software distribution downloadsite. The URL for the electronic distribution is sent after purchasing the product.

Media shipmentYou install the PowerHA adapter from the DVD Tivoli SystemAutomation Application Manager V4.1 - Automation Adapters allplatforms. On the DVD, you can find the installation packagehac.adapter

in the installation source directoryEEZ4100Adapters/EEZ4100HACMP/AIX

Electronic distributionThe name of the archive file of the electronic deliverable for the PowerHAadapter isSA AM 4.1 Adapter AIX.bin

To extract the archive, run the executable. After extracting the archive, youcan find the installation packagehac.adapter

in the same directory as on the PowerHA adapter DVD.

PrerequisitesMake sure you provide the required prerequisites, before you install the PowerHAadapter.

The system on which you are installing the adapter must meet the followinginstallation prerequisites:v The PowerHA adapter must not run on a node in the RSCT peer domain. If the

node on which the adapter is to run previously was an RSCT peer domain node,the following actions must be taken prior to installing the adapter:1. The environment variable CT_MANAGEMENT_SCOPE, which may be set to 2 for

the RSCT peer domain, must be unset.2. The RSCT peer domain must be stopped using the command: stoprpdomain

<domain-name>.v The 32-bit version of Java 1.4 or Java 5 Service Release 5 or higher must be

installed.v SSL or SSH packages must be installed and the sshd subsystem must be running

to be able to complete the Replication task of the adapter configuration.v To install and operate the automation adapter on a PowerHA V7.1 system,

install the following service levels:


– For PowerHA V7.1.0: install the PowerHA V7.1 SP6 or higher. Refer to APARIV27249.

– For PowerHA V7.1.1: install the PowerHA V7.1.1 SP3 or higher. Refer toAPAR IV23376.

For more details, see technote TSAAM's HACMP Automation Adapter does notstart.

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 ofSystem Automation Application Manager.

Automating the PowerHA adapterIt is required to automate the PowerHA adapter, if your PowerHA cluster has morethan one node.

About this taskv 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 availablenode in the cluster to resume the connection with the host using the adapter.

For more information about automating PowerHA adapters using the adapterconfiguration dialog, see “Automation tab” on page 180.

Behavior of the PowerHA adapterMake sure you are familiar with the PowerHA adapter behavior to be able exploitthe features and advantages.

Before you install and use the PowerHA adapter, make sure you are familiar withthe 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 retainedas persistent goals. No list of previously issued commands is available, andcommands previously issued against a group or resource cannot be canceled.The latest command issued against a group or resource determines whether itshould be online or offline. Commands issued by operators have the samepriority as commands issued by the end-to-end automation manager.

v PowerHA resources and groups cannot be suspended from automation by anend-to-end automation operator.

v PowerHA groups have no "real" desired state. PowerHA performs online andoffline commands on PowerHA groups by propagating them to memberresources. PowerHA groups only act as containers and reflect the state of thecontained PowerHA resources. If some of the PowerHA resources in a groupwere brought online and others offline, the group is in a mixed state - it is notclear whether the desired state of the group is online or offline.


http://www-01.ibm.com/support/docview.wss?uid=swg21635537


v PowerHA clusters do not have a policy concept as known by end-to-endautomation. For this reason, the Policy Information page for PowerHA domainsdoes not show reasonable information.

v If PowerHA groups are referenced in a System Automation Application Managerstart dependency then the PowerHA application monitoring mode "startup" or"both" is required to ensure the correct System Automation Application Managerautomation behavior.

v If you configure dependencies between PowerHA resource groups in thePowerHA cluster, the applications in these PowerHA resource groups are startedsequentially. If the monitoring mode "startup" or "both" is used the sequentialstart sequence does not get affected. To ensure a smooth execution, you canconfigure several PowerHA application monitors. One of these PowerHAapplication monitors is configured to check the application startup for theapplication that is included in the PowerHA resource group with a referencefrom System Automation Application Manager. This ensures that the applicationin the PowerHA resource group starts successfully before other dependentSystem Automation Application Manager resources are started.

Planning for the FOC adapterIf you are already using Microsoft Failover Cluster (FOC) for an existing highavailability cluster, System Automation Application Manager provides the FOCadapter to integrate resources that are managed by FOC into an end-to-endautomation environment.

RoadmapBefore you install the FOC adapter, you must decide whether you want to makethe adapter highly available.

The roadmap provides an overview of the steps you need to perform to install andconfigure the adapter depending on your high availability decision.

Roadmap to install a highly available FOC adapterCheck 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 FOCadapter” on page 37.

2. Use the installation wizard to install the adapter on one node in the cluster andgenerate a response file. For more information, see “Using the installationwizard to install the FOC adapter” on page 94.

3. To ensure that uniform installation parameters are used, use the response file toinstall the adapters on the remaining nodes. Response-file driven installationcan be performed in silent mode. For more information, see “Installing the FOCadapter in silent mode” on page 95 or in interactive mode using the installationwizard, see “Using the installation wizard to install the FOC adapter” on page94).

4. Configure the adapter on one of the cluster nodes using the adapterconfiguration dialog (see “Configuring the FOC adapter” on page 186).

5. To ensure that uniform configuration parameters are used, replicate the adapterconfiguration files to the remaining nodes. For more information, see“Replicating the configuration files to other nodes in the domain” on page 192).


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 adapterCheck the roadmap to install and configure FOC adapters that are not highlyavailable.

To install and configure your FOC adapter without high availability, perform thefollowing 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).

PackagingThe FOC adapter is shipped with System Automation Application Manager. Youcan order System Automation Application Manager as a media pack or downloadthe electronic deliverable from an IBM software distribution download site. TheURL for the electronic distribution is sent after purchasing the product.

Media shipmentYou install the FOC adapter from the DVD Tivoli System AutomationApplication Manager V4.1 - Automation Adapters all platforms. On theDVD, you can find the installation wizardsetup.exe

in the installation source directoryEEZ4100Adapters/EEZ4100MSCS/Windows

Electronic distributionThe name of the archive file of the electronic deliverable for the FOCadapter isSA AM 4.1 Adapter Windows.exe

To extract the archive, run the executable. After extracting the archive, youcan find the installation wizardsetup.exe

in the same directory as on the FOC adapter DVD.

PrerequisitesMake sure you provide the required prerequisites, before you install the FOCadapter.

The Failover Cluster Command Interface feature is required to configure the FOCadapter. Starting with Windows Server 2012 system, this feature is not installedanymore per default as part of the Failover Cluster installation.


The system on which you are installing the adapter must meet the followinginstallation 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 (logfiles, FFDC files).

Supported operating systems for the FOC adapterFOC adapter run on Windows Server 2012 only.

Table 23. Supported operating systems for the FOC adapter

Operating System System x

Windows Server 2012 R1Enterprise Edition (64 bit)

x

Windows Server 2012 R2Enterprise Edition (64 bit)

x


Installation directories for the FOC adapterMake sure you install the FOC adapter into the right directory using the rightwording.

For the FOC adapter installation directory and the Tivoli Common Directory, thefollowing 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 followingrestrictions:– The directory name has to consist of the platform-specific path separator

character and alphanumeric characters (A..Z, a..z, 0..9).– The colon character is allowed only once, immediately following the drive

letter. For example, C:\<directory_name> is allowed, but C:\<directory_name>:<directory_name> is not allowed.

– The space character and the underscore character (_) are allowed.

Preparing the user accountFor the installation and operation of the FOC adapter, a domain user account withlocal administrative rights must be defined in the domain.

About this task

The domain user account must be a member of the local administrators group onall nodes of the cluster the adapter will manage. Use this user account for the FOCadapter only.


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 thePermissions for . . . list and click OK .

v Log into each system where you want to install the FOC adapter, using anaccount with administrative rights on the system. Use the local group policyeditor 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 viewa list of user rights is shown.

– Double-click on the right Log on as a service and select the Add User orGroup . . . 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 anaccount with administrative rights on the system. Use the local users and groupseditor to make the SAAMAdapter user account a member of the localAdministrators 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 Addto 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 adapterYou 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


– Microsoft FOC will make the virtual IP address available on the appropriateMicrosoft 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 adapterTo make sure your system runs well using an FOC adapter, more information isprovided to better understand the behavior of the FOC adapter in combinationwith 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 areperformed on behalf of this user account.

vIf authentication is enforced in the FOC adapter configuration you must specifyan arbitrary valid user account with credentials in order to establish a sessionwith the adapter. The user account and password combination is checked on thesystem 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 thispurpose. When being prompted for the user account name you must specify theuser account in a way which uniquely describes its scope, for example to showwhich domain the user account belongs to. For domain user accounts you canspecify the user account as domain\user or [email protected], the FOC adapter performs all operations on the Microsoft FOCcluster on behalf of the user account used by the System AutomationApplication Manager FOC adapter service to log on.

v Microsoft FOC clusters are not request- but command-driven. Commands forbringing resources and groups online or offline are performed but not retainedas persistent goals. No list of previously issued commands is available, andcommands previously issued against a group or resource cannot be canceled.The latest command issued against a group or resource determines whether itshould be online or offline. Commands issued by operators have the samepriority as commands issued by the end-to-end automation manager.

v Microsoft FOC resources and groups cannot be suspended from automation byan end-to-end automation operator.

v Microsoft FOC groups have no "real" desired state. Microsoft FOC performsonline and offline commands on Microsoft FOC groups by propagating them tomember resources. Microsoft FOC groups only act as containers and reflect thestate of the contained Microsoft FOC resources. If some of the Microsoft FOCresources in a group were brought online and others offline, the group is in amixed state - it is not clear whether the desired state of the group is online oroffline.

v Microsoft FOC clusters do not have a policy concept as known by end-to-endautomation. For this reason, the Policy Information page for Microsoft FOCdomains does not show reasonable information.

v Microsoft FOC does not monitor resources which are not expected to be online.


Example:

A file share resource has two different cluster nodes as possible owners. If thefile 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 clusternode. Microsoft FOC will not notice a manual definition of the file share on thesecond node.The FOC adapter does not work around this monitoring approach and is thusnot 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 orindirectly depends on the resource to be taken offline.

– The resource is the FOC adapter service resource (if the adapter is madehighly available).

– If the FOC adapter service resource directly or indirectly depends on theresource to be taken offline (if the adapter is made highly available).

v Microsoft FOC nodes reject exclude commands if the adapter is made highlyavailable and the group that contains the FOC adapter service resource islocated on the node. In this case, message EEZZ0012E appears indicating thatthe group in question cannot be taken offline without impacting the FOCadapter.

Planning for the VCS adapterIf you are already using Veritas Cluster Server (VCS) for an existing highavailability cluster, System Automation Application Manager provides the VCSadapter to integrate resources that are managed by VCS into an end-to-endautomation environment.

PackagingThe VCS adapter is shipped with System Automation Application Manager. Youcan order System Automation Application Manager as a media pack or downloadthe electronic deliverable from an IBM software distribution download site. TheURL for the electronic distribution is sent after purchasing the product.

Media shipmentYou install the VCS adapter from the DVD Tivoli System AutomationApplication Manager V4.1 - Automation Adapters all platforms. On theDVD, you can find the installation packageinstall.bin

in the installation source directoryEEZ4100Adapters/EEZEEZ4100VCS/Solaris

Electronic distributionThe name of the archive file of the electronic deliverable for the VCSadapter isSA AM 4.1 Adapter Solaris.zip


To extract the archive, run the executable. After extracting the archive, youcan find the installation packageinstall.bin

in the same directory as on the VCS adapter DVD.

PrerequisitesMake 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 followinginstallation prerequisites:v Solaris 10 on SPARC processors running VCS 4.1 or 5.0v 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


Automating the VCS adapterIf the VCS cluster consists of more than one node, the VCS adapter must beautomated.

About this task

It is required to automate the VCS adapter, if the VCS cluster consists of more thanone 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 thecluster to resume the connection with the host using the adapter.

For more information about automating VCS adapters using the adapterconfiguration dialog, see “Automation tab” on page 198.

Behavior of the VCS adapter for Solaris/SPARCTo make sure your system runs well using an VCS adapter, more information isprovided to better understand the behavior of the VCS adapter in combinationwith System Automation Application Manager.

Before you install and use the VCS adapter, make sure to be familiar with thebehavior 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


as persistent goals. No list of previously issued commands is available, andcommands that were previously issued against a group or resource cannot becanceled. The latest command that was issued against a group or resourcedetermines whether it should be online or offline. Commands issued byoperators have the same priority as commands issued by the end-to-endautomation manager.

v VCS resources and groups can be suspended from automation by an end-to-endautomation operator.

v VCS groups have no "real" desired state. VCS performs online and offlinecommands on VCS groups by propagating them to member resources. VCSgroups only act as containers and reflect the state of the contained VCSresources. If some of the VCS resources in a group were brought online andothers offline, the group is in a mixed state - it is not clear whether the desiredstate 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 showreasonable information.

Planning for an end-to-end automation policyBefore you define your own end-to-end automation policy, check the examples andidentify cluster-spanning dependencies.

The scope of end-to-end automation policiesEnd-to-end automation management versus first-level automation. Find out, whento use which concept.

As described in Tivoli System Automation Application Manager, Administrator’s andUser’s Guide, end-to-end automation management is not intended to take over therole of first-level automation products. The main focus of first-level automationproducts 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 highavailability is to be ensured.

The scope of end-to-end automation policies starts where local first-levelautomation capabilities end - on the border of a first-level automation cluster.Consequently, end-to-end automation policies should only define cluster-spanningrelationships and groups. The following examples provide some information onwhat you must consider when defining resource references for first-levelautomation resources.


The examples show three resource references that were created for resources orresource groups that are hosted by a first-level-automation domain. Theseexamples are described in the following topics.

Example 1This example illustrates why it is not desirable to create resource referencespointing to resources that are members of first-level automation groups if theintegrity 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 automationmanager issues an Online request against the first-level automation resource that isreferenced by "Ref 1". The first-level automation manager receives the request. Ifthe 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-endautomation 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-levelautomation manager because the request on the group member has a higherpriority 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" andthe first-level automation resource "Res X". The administrator who created thefirst-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 ascenario, however, this is not the case and the dependency will not be honored.

Example 2In example 2, resource reference "Ref 2" refers to "Grp A" which is hosted by thesame first-level automation domain.

This has the following two advantages for the constructs in Example 1:

Ref 1

Grp AGrp B

Res X

Example 1

Ref 1Ref 2

Grp AGrp B

Res X

Example 3

Ref 3

Grp AGrp B

Res X

Example 2

Figure 3. Examples for resource references to resources and resource groups.


1. All members of "Grp A" will be started or stopped in accordance with thedesired group behavior. After the completion of the request from theend-to-end automation manager, "Grp A" changes to a normal end state and noproblem 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 thefirst-level automation manager as defined by the administrator of the policy.

Only one problem remains: First-level automation cannot reach the desired statedefined 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-endautomation. In such a case, the operator must understand that "Grp B" is in aproblem state because end-to-end automation needed to start a member of thisgroup in order to accomplish an end-to-end business goal.

Example 3The two examples above cause undesired behavior. This is not the case in thisscenario, where "Ref 3" references the outermost (or top-level) resource groupdefined in the first-level automation policy.

In this scenario, "Ref 3" references the outermost (or top-level) resource groupdefined in the first-level automation policy. No matter what desired state has beendefined for "Ref 3", the first-level automation manager will act according to therequest it receives from the end-to-end automation manager and all of theconstructs defined in the first-level automation policy will remain in a satisfactorystate.

Identifying cluster-spanning dependenciesIdentify first-level automation resources that have cluster-spanning relationships.Such resources are candidates for being referenced in the end-to-end automationpolicy.

Two kinds of dependencies can be expressed in the constructs of an end-to-endautomation 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 amongautomated resources that are hosted by different first-level automation domains.

Grouping of resourcesAn enterprise application consists of multiple resources (for example applicationsand IP addresses) that can belong to different business tiers and areas ofresponsibility. In order to automate resources effectively, the grouping concept isintroduced in end-to-end and first-level automation. Resources need to berestructured 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 automationdomains can act as alternatives for other resources in case these fail?


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 bemonitored by the same operator even if the resources are hosted by differentfirst-level automation domains.These resources can also be grouped in collection groups, however this alsoimplies that these resources are started and stopped together and have the samedesired 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 structurecomplex environments into several layers.

v By encapsulating resources and nested groups within groups, you can organizeyour automated resources in a hierarchical structure that serves as the logicalbasis for an end-to-end automation policy.

Resources can be gathered in groups according to logical, technical, security, orresponsibility 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.

End-to-end automation groups can be platform-spanning. This means that resourcereferences for resources that are hosted by different first-level domains can begathered in one group. The resource references that refer to a DB2 group on afirst-level z/OS sysplex can be gathered in a group together with the application"App", which is physically hosted on an AIX cluster.

Figure 4. Example for end-to-end automation groups that are distributed over different platforms


RelationshipsRelationships represent dependencies between resources or groups.

About this task

A relationship exists between a source and a target. Source and target can be eitherresource references or groups. For example, a relationship A StartAfter B ensuresthat 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 describethe sequence in which applications need to be started or stopped?

v How does an operator apply maintenance to specific applications? Aredocuments available that describe in which sequence an operator must shutdown applications?

v In case of an unexpected failure of some critical applications on a first-levelautomation domain, do other applications on other automation domains need tobe stopped as well?

Before you define a policy, you need to identify the relationships between theresources. When you identify the relationships that need to be defined in thepolicy, you should list the relationship information in the following sequence:v Source resourcev First-level automation domain namev Target resourcev First-level automation domain namev Relationship type

The following example describes when a ForcedDownBy relationship between tworesources 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 resourceResource A and target resource Resource B (Resource A ForcedDownByResource 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 whenResource B fails while it is offline, Resource A must be bounced, that is, it hasto be stopped and restarted again, for example, to allow Resource A tosynchronize with Resource B.


Default directoriesDuring the installation, default directories are used to install System AutomationApplication Manager. Default directories are defined in variables. Check out allused variables and their related default directory.

The following table lists the default directory paths for which variables are used inthis guide. The paths in your environment may differ, for example, if you changedthe default path during the installation of the application or component.

Table 25. Default directories

Variable used in this guide Default path

<EEZ_CONFIG_ROOT>/etc/opt/IBM/tsamp/eez/cfg

<EEZ_INSTALL_ROOT>/opt/IBM/tsamp/eez

The configuration properties files are located in the directory<EEZ_CONFIG_ROOT>.

<hacmp_adapter_install_root>AIX: /opt/IBM/tsamp/eez/hac

<hacmp_adapter_conf_root>AIX: /etc/opt/IBM/tsamp/eez/hac/cfg

<mscs_adapter_install_root>Windows: C:\Program Files\IBM\tsamp\eez\mscs

<mscs_adapter_conf_root>Windows: C:\Program Files\IBM\tsamp\eez\mscs\cfg

<Tivoli_Common_Directory> /var/ibm/tivoli/common

The path to the Tivoli Common Directory is specified in the properties filelog.properties. The file log.properties is located in the following directory/etc/ibm/tivoli/common/cfg.

<was_root> AIX: /usr/IBM/WebSphere/AppServer

Linux: /opt/IBM/WebSphere/AppServer

<vcs_adapter_install_root>Solaris: /opt/IBM/tsamp/eez/vcs

<vcs_adapter_conf_root>Solaris: /etc/opt/IBM/tsamp/eez/vcs/cfg

Disaster recovery policy definition worksheetsPrint out and use these worksheets to collect the information required for creatinga disaster recovery policy.

If you need to define more cluster sets, hardware boxes, slots, or nodes print outmore copies of the appropriate worksheet.

Table 26. Worksheet to define disaster recovery topology

Site 1 Index 1

Name

Site 2 Index 2

Name


Table 26. Worksheet to define disaster recovery topology (continued)

Cluster set ClusterSetName

Domain Name Site 1

Domain Name Site 2

WorkloadSetup


Domain Name Site 1

Domain Name Site 2

WorkloadSetup


Domain Name Site 1

Domain Name Site 2

WorkloadSetup


Domain Name Site 1

Domain Name Site 2


Domain Name Site 1

Domain Name Site 2

WorkloadSetup


Domain Name Site 1

Domain Name Site 2

WorkloadSetup


Domain Name Site 1

Domain Name Site 2

WorkloadSetup


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


Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table foreach site.Name of Site1 /Site2:

Slot 1 Name

PowerOff mechanism Script / SNMP

PowerOn mechanism Script / SNMP

Slot 2 Name



Slot 3 Name



Slot 4 Name



SNMPAgent (Ifmechanism="SNMP")

Host

Port

AuthProtocol MD5 / SHA / None

PrivProtocol DES / AES / None

ServiceProcessorType MM

Hardware Box Name

Slot 1 Name



Slot 2 Name



Slot 3 Name



Slot 4 Name



SNMPAgent (Ifmechanism="SNMP")

Host

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


HardwareDevice Box

Slot

Node Name


Table 27. Worksheet to define disaster recovery hardware (continued). Reuse this table foreach site.Name of Site1 /Site2:

Site index 1 / 2

Domain name


HardwareDevice Box

Slot

Node Name

Site index 1 / 2

Domain name


HardwareDevice Box

Slot

Node Name

Site index 1 / 2

Domain name


HardwareDevice Box

Slot

Node Name

Site index 1 / 2

Domain name


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


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 donot need to collect an associated domain name with this worksheet.


Chapter 2. Installing

Installing System Automation Application Manager involves preparation to ensurethat your system meets the prerequisite requirements, then installing the requiredsoftware.

Installing the middleware softwareDepending on the setup type you choose, install the middleware software on oneor 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 DVDsThe middleware software DVDs that are shipped with the System AutomationApplication Manager product DVDs contain the following software products:v IBM DB2 Limited Use Version 10.1v IBM DB2 Limited Use Version 10.5v IBM WebSphere Application Server Base Version 8.5.0.1

Note:

1. IBM Tivoli System Automation Application Manager only supports the 32-bitVersion of WebSphere Application Server.

2. WebSphere Application Server Version 8.5 Network Deployment is notsupported.

3. Note that the IBM Tivoli Directory Server is not contained on themiddleware 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 productshave changed to:v Jazz for Service Management, Version 1.1.2.0v IBM WebSphere Application Server, Version 8.5.5.4

If you are planning to upgrade to System Automation Application Manager fixpack 4.1.0.1 or higher, you must also upgrade Jazz for Service Management to thenew minimum version. For more information, see “Installing a new Jazz forService Management version” on page 58.

Installing a DB2 serverAbout this task

DB2 server requirementsUse the following publications to find out which requirements need to be met forinstalling 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:


DB2 for Linux, UNIX and Windows

You will find the link to the PDF manuals in the Other resources section on theWeb page.

In addition, check for the latest system requirements: System requirements for IBMDB2 for Linux, UNIX, and Windows.

The DB2 release notes can also be found on the DVDs labeled IBM DB2 Databasefor 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 forinstalling and running a DB2 server are met. Otherwise, System AutomationApplication Manager may not install or work properly.

DB2 server installationYou 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 WindowsVersion 10.5 for your platform.

You can use the typical installation of a single-partition database environment. OnWindows, you may consider to set the startup type of the DB2 service toAutomatic.

On a Windows system, the following users must be local users:v DB2 administration server userv Fenced userv 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 “Middlewaresoftware requirements” on page 6).

On a 64-bit operating system, the following link must exist in the home directoryof the DB2 instance owner:/home/<db2 instance name>/sqllib/lib64/libdb2tsa.so

If this link does not exist, use the following command to create the link:ln -s /home/<db2 instance name>/sqllib/lib64/libdb2tsa.so.1

/home/<db2 instance name>/sqllib/lib64/libdb2tsa.so

Make a note of the following information for future reference:v Host name of the system where the DB2 server is installed.v Port number of the DB2 instance.

The port number is displayed on the summary window of the DB2 Setupwizard. The summary window appears immediately before the wizard copiesthe program files.

v Name of the directory to which the DB2 server is installed if a local DB2 setup isused.

v Name and password of the instance owner user or of a different user who isauthorized to drop and create databases and database tables, and to select,insert, delete, and update table rows.


http://www.ibm.com/support/entry/portal/Overview/Software/Information_Management/DB2_for_Linux,_UNIX_and_Windows



Note: For information about DB2 Version 10 server security concepts and on howto 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 Windowsdocumentation .

JDBC driver installation for a remote DB2 setupDepending on which operating system the remote DB2 is installed, you need thefollowing files:v DB2 for Linux, AIX, and Windows:

– db2jcc.jar

– db2jcc_license_cu.jar: License file for DB2 for Linux, AIX, and Windows

You can find these files in the <DB2_install_home>/sqllib/java directory.v DB2 for z/OS

– db2jcc.jar

– db2jcc_license_cisuz.jar: License file for DB2 for z/OS

You can find these files in the subdirectory classes or jcc/classes of the DB2JDBC 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 page59.

v Use the WebSphere JDBC driver: Copy the appropriate .jar files into thedirectory <was_home>/universalDriver/lib, if not already available. Point theinstaller to the directory as described in “Using the installation wizard” on page59.

v Use the DB2 runtime client JDBC driver: Point the installer to the directory withthe appropriate .jar files as described in “Using the installation wizard” onpage 59.

Preinstallation tasks for a remote DB2 setupThe 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, youmust 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 platformcontains 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

http://www.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.kc.doc/welcome.html

http://www.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.kc.doc/welcome.html

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.kc.doc/welcome.html

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.kc.doc/welcome.html

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\Script3. From this directory, run the following batch files:

db2_create_automgr_db.bat <db_name> <instance_owner> <instance_pw>db2_create_reporting_tables.bat <db_name> <instance_owner> <instance_pw><script_directory>

wherev

<db_name> is the desired name of the automation manager database(Example: EAUTODB)

v<instance_owner> is the instance owner user ID of the DB2 instance(Example: db2admin)

v <instance_pw> is the password of the instance owner user IDv <script_directory> is the directory where the DB2 scripts for Tivoli

System Automation are located on the DVD, which you changed toin 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 <db_name> <instance_owner> <instance_pwd> <script_directory>db2_create_reporting_tables.sh <db_name> <instance_owner> <instance_pwd><script_directory>

wherev

<db_name> is the desired name of the automation manager database.Example: EAUTODB

v<instance_owner> is the instance owner user ID of the DB2 instance.Example: db2inst1

v <instance_pwd> is the password of the instance owner user ID.v <script_directory> is the directory where the DB2 scripts for Tivoli

System Automation are located on the DVD, which you changed toin step 2 (DDL/Script).

z/OS

If you have a DB2 server system that runs on z/OS, adjust and run thefollowing jobs. They are provided on the DVD labeled System AutomationApplication Manager Version 4.1 for your operating system, in directoryDDL/DB2.

ATVED100This job creates a DB2 table space, tables, and index entries.

ATVED10CThis job deletes the objects created by job ATVED100.


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 managerdatabase and the database tables” on page 53, issue the following commands toverify that the remote database was created correctly:1. Log on as DB2 instance owner.2. db2 connect to <db_name>

3. db2 list tables for schema eautousr

4. db2 disconnect <db_name>

The output of the list tables command displays the following table names:EEZAUTOMATIONACCESSEEZCOMMONEVENTSEEZDOMAINSUBSCRIPTIONEEZOPERATORDOMAINFILTEREEZOPERATORDOMAINPREFERENCESEEZOPERATORHIDDENDOMAINEEZPERSISTENTREQUESTEEZRESOURCESUBSCRIPTIONEEZSAFOSEVENTSEEZNODE

Installing Jazz for Service Management

Before you install or update Jazz for Service Management, refer to the technotes forJazz for Service Management. Technotes provide information about late-breakingissues, limitations, and workarounds. Check technotes referring to issues in Jazzfor Service Management Version 1.1.0.2: Jazz for Service Management technotes.

Section “Jazz for Service Management installation” describes how to install theversion of Jazz for Service Management that you receive when you order SystemAutomation Application Manager 4.1. Starting with fix pack 4.1.0.1 the minimumversions of the Jazz for Service Management components have changed. Use thenew Jazz for Service Management version rather than the version described in thatsection.

For more information, see “Installing a new Jazz for Service Management version”on page 58.

Jazz for Service Management installationFollow the steps described in this topic to install Jazz for Service Management.

The following installation steps describe how to install the version of Jazz forService Management that you receive when you order System AutomationApplication Manager 4.1. Starting with fix pack 4.1.0.1 the minimum versions of


http://www.ibm.com/support/search.wss?q=jazzsm1102relnotes

the Jazz for Service Management components have changed. Use the new Jazz forService Management version rather than the version described below. For moreinformation, see “Installing a new Jazz for Service Management version” on page58.

To install Jazz for Service Management Version 1.1.0.2 and WebSphere ApplicationServer 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 containany 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 whetherall required libraries are installed as documented in “Middleware softwarerequirements” on page 6. For more information about JAZZ for ServiceManagement prerequisites, see Hardware and software requirements.

b. The Installation Manager window opens. Select the following packages tobe installed:1) IBM Installation Manager Version 1.6.12) IBM WebSphere Application Server Version 8.5.0.13) IBM WebSphere SDK Java Technology Edition Version 7.0.2.04) Jazz for Service Management extension for IBM WebSphere 8.5 Version

1.1.0.15) IBM Dashboard Application Services Hub Version 3.1.0.2

c. Click Next. The Installation Manager > Licenses window opens. Review andaccept the License Agreements.

d. Click Next and specify the directories that are used by the InstallationManager.

e. Click Next and specify the installation directories for WebSphereApplication Server and Jazz for Service Management.

f. Click Next. The Installation Manager > Features – languages windowopens.


http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0/com.ibm.psc.doc_1.1.0/install/psc_c_install_prereqs.html

g. Accept the default translated languages that are selected in the TranslationsSupported by All Packages window. Click Next. The Installation Manager> Features window opens.

h. Important: On the Features window, expand IBM WebSphere ApplicationServer 8.5.0.1 > IBM WebSphere SDK for Java Technology Edition 6 andselect IBM 32-bit WebSphere SDK for Java.

i. Click Next and specify the configuration for your WebSphere ApplicationServer installation. Define the WebSphere administrative user ID. ClickValidate.

j. Click Next. The Installation Manager > Summary window opens.k. Review the software packages to be installed and their installation

directories. Click Install to start the installation.l. When the installation successfully completed, a success window is displayed.

You can now click Finish to close the Installation Manager.4. Important: Activate the 32-bit version of Java 7 for the WebSphere Application

Server profile:<was_root>/bin/managesdk.sh -enableProfile -sdkName 1.7_32 -profileName JazzSMProfile -enableServers

JazzSMProfile is the profile name that is used for Jazz for Service Management.Default name: JazzSMProfile.

Note: More information about configuring Java 7 is provided at the followinglinks: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 ensurethat the fix matches to the installed Java version.

v The page Verify Java SDK version shipped with IBM WebSphere ApplicationServer fix packs describes which version of WebSphere Application Servercorresponds to which Java SDK level.

You are now ready to install System Automation Application Manager using itsown installer.

Post-installation tasks for Jazz for Service ManagementJazz for Service Management defines default values for the time intervals withinthe browser polls for new content. These default values are higher than the valuesthat are required by System Automation to ensure timely visualization when anautomation resource changes its state.

During initial installation of System Automation Application Manager, the timeoutvalues are adjusted automatically. But when service for Jazz for ServiceManagement is installed afterwards, the original default values are restored.

Perform the following steps after installing service for Jazz for ServiceManagement: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=5ActiveMQBroker.pollDelay=5ActiveMQBroker.pollErrorDelay=5

3. Save the file and restart WebSphere Application Server.


http://www.ibm.com/support/knowledgecenter/websphere_iea/websphere_iea_welcome.html

http://www.ibm.com/support/knowledgecenter/websphere_iea/websphere_iea_welcome.html

http://www.ibm.com/support/docview.wss?uid=swg21138332




Installing a new Jazz for Service Management versionStarting with fix pack 4.1.0.1 the minimum version of Jazz for Service Managementchanged. The version of Jazz for Service Management that you receive when youorder 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, includingthe following versions of Jazz for Service Management components:v IBM Installation Manager 1.8.2v IBM WebSphere Application Server Version 8.5.5.4v IBM WebSphere SDK for Java Technology Edition Version 7.0.8.0v Jazz for Service Management extension for IBM WebSphere 8.5 Version 1.1.0.2v 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 installedthe version of Jazz for Service Management that you received as part of SystemAutomation Application Manager 4.1.

2. You ordered System Automation Application Manager 4.1 before fix pack4.1.0.1 is available and you want to run a new installation. This includes thecase where you received version 4.1 already, but you want to install on anoperating system version that was not yet supported by System AutomationApplication Manager version 4.1. This case is described in “Installing on newoperating systems” on page 76.

3. You ordered System Automation Application Manager 4.1 after fix pack 4.1.0.1is available.

You already installed System Automation Application Manager 4.1In this case, you installed also the middleware components as described in“Middleware software requirements” on page 6. Upgrade the middlewarecomponents to the versions listed in this section. You can download thecorresponding archives from the IBM Installation Manager, IBMWebSphere, and Jazz for Service Management support sites and upgradeeach component separately. Alternatively, you can download Jazz forService Management 1.1.2.0 for your operating system platform fromPassport Advantage (PA / XL). In this case, the corresponding Jazz forService Management and WebSphere archives contain the requiredcomponents that you can install in one step as describe below.

You ordered System Automation Application Manager 4.1 before fix pack 4.1.0.1is 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 systemplatform from Passport Advantage (PA / XL). For more information, seehttp://www-01.ibm.com/support/docview.wss?uid=swg24039873. Thecorresponding Jazz for Service Management and WebSphere archivescontain the required components that you can install in one step.

For the download from Passport Advantage, use part numbers to locatethe required packages. You need the following packages:



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 ServiceManagement 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 ServiceManagement 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 ServiceManagement for Linux on System z, 64-bit, Multilingual

The Jazz for Service Management packages contain IBM InstallationManager Version 1.8.2 and IBM Dashboard Application Services HubVersion 3.1.2.0. The IBM WebSphere Application Server packages containIBM WebSphere SDK for Java Technology Edition Version 7.0.8.0.

You can use the packages that are downloaded from Passport Advantagefor an initial installation and for an update installation. In case of an initialinstallation, proceed as described in “Jazz for Service Managementinstallation” on page 55. Use the new versions instead of the ones that aredocumented in that section.

In case of an update installation, specify the JazzSMRepository and theWASRepository as new repositories in your installation managerconfiguration and select to update the corresponding components.

You ordered System Automation Application Manager 4.1 after fix pack 4.1.0.1 isavailable

If you order System Automation Application Manager 4.1 after fix pack4.1.0.1 is available, you receive already the new versions of the middlewaresoftware in addition to the versions that are delivered with SystemAutomation Application Manager 4.1.0.0. Proceed as described in “Jazz forService Management installation” on page 55. Use the new versions insteadof the ones that are documented in that section.

Installing System Automation Application ManagerIf you finalized your planning steps to install System Automation ApplicationManager, start with the installation. You have two options to install. You can eitheruse the wizard or install in silent mode.

One instance of the agentless adapter is installed as part of the System AutomationApplication Manager installation. For more information about how to install moreinstances of the agentless adapter on other systems, see “Installing the remoteagentless adapter” on page 87.

Using the installation wizardThis topic describes how to install System Automation Application Manager. Forthe installation, you use a graphical installation program, the installation wizard.The required steps are described in the following paragraphs.


About this task

When installing System Automation Application Manager to an AIX or Linuxsystem, you must ensure that an X Window session is available for displaying thegraphical installation wizard panels.

If the graphical installation program cannot be started, the installer automaticallyswitches to console mode. The console mode is not supported, and can't be usedfor the installation of the product. If the console mode is started, please checkwhether 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 listsprovided in “Collecting the information” on page 11. Make sure that you specifyall required parameters on the installation wizard panels and that your entries arecorrect.

Note:

1. The wizard panels that are displayed during the installation are similar ondifferent operating systems. Make sure to enter platform-specific informationwhen 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 becanceled at any time. The installation can be resumed by simply calling theinstaller again.

To install System Automation Application Manager, perform these steps:1. Make sure that all installation prerequisites are met (refer to “Installing

prerequisites” on page 4).2. Insert the following DVD into the DVD drive:

System Automation Application Manager v4.1 - <platform>

There are multiple DVDs. Be sure to use the one for your platform. If you areusing electronic distribution switch to the appropriate archive.

3. Change to the directory that contains the installation program. For the locationof the directory, refer to “Packaging” on page 2.

4. Start the installation by launching the installation wizard using setup.bin. Formore information about how to install in silent mode, see “Installing in silentmode” on page 64When 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 andclick OK. The language in which System Automation Application Manager isinstalled 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.


7. The Software License Agreement window is displayed. Carefully read theterms of the license agreement.To accept the terms of the license agreement, select I accept the terms in thelicense agreement and click Next.

8. On the Installation Directory window, specify the directory where you want toinstall 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 mustalso be used for System Automation Application Manager. In this case, theTivoli Common Directory window is not displayed.If the installation program does not detect a Tivoli Common Directory on yoursystem, accept the default location or specify the directory to which the Tivolilog files are to be written. Click Next.

10. On the High Availability window, select the high availability setup that yourequire.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 thechanges that are made to the end-to-end automation manager. The optionYes is automatically selected.

v Click I want to create a highly available SAAM setup with two or moreservers if you want a high availability scenario. No changes are made to theend-to-end automation manager database and the WebSphere ApplicationServer 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 youselected: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 alocal 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 droppedautomatically without warning

b. Specify the installation directory of your local DB2 installation and thename and password of the DB2 Instance owner, and then click Next.

c. In the field DB2 instance port number, the valid port number must bespecified: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,


depending on the DB2 setup that you configured. Ensure that yoursetting is correct before you proceed.

Click Next and proceed with step 15.

Note: After you click Next the installation program checks whether thedatabase can be accessed with the values you specified on the window. If youwant 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 youare 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 thedirectory (see “JDBC driver installation for a remote DB2 setup” on page53 and “Preinstallation tasks for a remote DB2 setup” on page 53), andspecify the name and password of the database instance owner. ClickNext.

Note: The installation wizard checks the contents of the defined directoryand displays an error message if it does not contain a JDBC driver with avalid license

c. In the field DB2 server host name, type the fully qualified host name ofthe system where the DB2 server is installed.In the field DB2 server port, the port number of the DB2 server must bespecified. 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 displayedonly 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 thedirectory, and specify the name and password of the database instanceowner. Click Next

c. In the DB2 server host name field, type the fully qualified host name ofthe 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 yourWebSphere has administrative access to users and groups.Typically, this is the case in setups with federated user repositories where youcan manage users and groups via the administrative console. If you click Yes,the installer creates users and groups in that repository to use with SystemAutomation Application Manager. If you click No, the installer does not makeany changes to users and groups. Click No, if you use a central LDAP userrepository and the users and groups exist in this repository. This is the case ifyou created them manually in the LDAP repository or if a previous SystemAutomation Application Manager installation created them in the same LDAPrepository.

16. The installation directory of WebSphere Application Server is detected on yoursystem and displayed on the WebSphere Application Server window.a. Click Next.


b. Specify a WebSphere Application Server administrative account andpassword. You can also choose another server. Select the profile you wantto use and click Next.

17. On the Automation Domain Name window, specify the end-to-endautomation domain name you want to use or accept the default name andclick Next.

Note: Accept the default domain name FriendlyE2E if you want to use thesample System Automation Application Manager environment to familiarizeyourself with end-to-end automation management and the operations console.You can change the settings once your are done with the installation. For moreinformation, see “Domain tab” on page 106.

18. If you want to use Tivoli Netcool/OMNIbus to display end-to-end automationmanagement 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 ApplicationServer administrative console after the installation of System AutomationApplication Manager is complete.

19. On the System Automation Functional user ID window, specify the functionaluser ID and password for the end-to-end automation manager. Do not use cutand paste to enter the password and the password confirmation. Type indirectly the password and the password confirmation. This functional user IDis 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 EEZEARapplication's “User RunAs role” mapping.

Note: Do not choose the same name for both the System Automationfunctional user ID and the WebSphere Application Server administrator userID, as this may lead to problems if you later uninstall System AutomationApplication Manager. For example, do not specify wasadmin for both users.

20. If System Automation Application Manager Distributed Disaster Recoverywith 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) addressspace 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.


v In the field GDPS server host name, specify the TCP/IP host name of yourbackup GDPS controlling system.

v In the field GDPS server port number, specify the TCP port numberconfigured for the NetView Event/Automation Service (E/AS) addressspace that is running on the backup GDPS controlling system.

Click Next.

Note: You can modify the GDPS connection after the installation of SystemAutomation 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 theuser ID and password of the System Automation administrator.Click Next.

22. When you specified all the required information on the wizard panels, thePre-Install Summary window is displayed. The installer checks for diskavailability. If the disk space requirements are not met, installation is notpossible.Click Install to start the installation. The installation can take up to two hoursto complete.

23. While the component is being installed and configured, information panelsdisplay 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 verifyingthe installation, refer to “Verifying the installation” on page 71.

Installing in silent modeAbout this task

You can install System Automation Application Manager Version 4.1.0 by using agraphical interface (Installation Shield wizard) or in silent mode. The silentinstallation is run by using a previously created silent input properties file. You cangenerate the install.properties input file in two ways:1.

Run a wizard-based graphical installation using setup.bin or setup.exe withthe -Dpreparesilent=true option. When the installation procedure completes,the install.properties file is created in the <EEZ_INSTALL_ROOT>/installsub-directory of the product installation path. When an update installation isperformed, the file is read to obtain the parameters and values needed for theupdate process. If this file is not found, the update installation fails.If you want to perform a silent installation of System Automation ApplicationManager on more than one system, you can take the install.properties filewhich was generated during a graphical installation, and use it on othersystems of the same type. You might need to replace system-specific parametersin the file to customize it for the target system.

2.

You can prepare an install.properties file without performing a completeinstallation on the target system. The first part of the installation proceduregathers all the necessary parameters needed to generate theinstall.properties file. You do this by starting the graphical installer on thetarget system with the options -Dpreparesilent=true and-Dpropertiesfileonly=true. With these options, the installation procedure


stops before the product files are copied to the product directory. Theinstall.properties file is created and stored in directory /tmp.If you want the file to be created in a specific path, you can optionally specify-Dpropertiesfilepath=<fully_qualified_path>. If the specified path isincorrect, 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 followingcommand:

setup.exe -Dpreparesilent=true -Dpropertiesfileonly=true-Dpropertiesfilepath=/var/mydir

Note: The option -Dpropertiesfilepath=<fully_qualified_path> can be usedonly 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 theplatform you use:setup.bin -f <fully_qualified_properties_file_name>

If the input file install.properties is found, silent installation starts. If the fileis not found, the wizard-driven installation starts.

Upgrading to release 4.1About 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 page67.

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 additionalinformation 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 or3.2.1” on page 69.

7. Install the middleware software required by System Automation ApplicationManager Version 4.1.


8. If high availability is configured for System Automation Application Manager,perform the additional preinstallation steps described in “Upgrading the highavailability 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 highavailability policy” on page 69.

11. Import your data. For more information, see “Exporting the content of theautomation database.”

Once the previous version of System Automation Application Manager isuninstalled, all configuration files are preserved in directory <EEZ_CONFIG_ROOT>,for example /etc/opt/IBM/tsamp/eez/cfg . After version 4.1 is installed, SystemAutomation Application Manager Version 4.1 uses the configuration files saved in<EEZ_CONFIG_ROOT>.

If you are using the cfgeezdmn configuration utility in silent mode to configure theApplication Manager common settings, make sure that you generate a new silentinput properties file on the new release level. The Application Manager commonsettings are configured in silent mode by launching the cfgeezdmn utility using theoptions -s -e. Before performing any silent configuration, generate a new inputproperties file by launching the cfgeezdmn utility using the options -s -e [ -g |-gr ].

Exporting the content of the automation databaseIf you decide to drop and recreate the automation database, use the scriptsdescribed in this topic. These scripts export the data from the automation databasebefore you drop the database, and import them back into the automation databaseonce it is recreated.

In addition, future upgrades of System Automation Application Manager canrequire changes of the layout of tables contained in the automation database. Inthis scenario, export the data contained in the automation database prior to theupgrade, and import the data back into the automation database after the upgradeto prevent data loss.

System Automation Application Manager provides scripts that assist you to exportand import data. These scripts are designed for local databases managed by DB2for distributed platforms. If you have a remote DB2 setup you must directly runthese scripts on the system where the automation database resides. If you use DB2for z/OS, the scripts cannot be used directly, but they can serve as a blueprint foryour database administrators in order to create export and import procedures thatare appropriate for your environment.

To export the data, perform the following steps:1. Stop the WebSphere Application Server to ensure that the automation manager

does not lock any data in the database.2. Change to the DDL/Script directory on the product DVD and run the following

script to export the data:./db2_export_automation_db.sh <db_name> <instance_owner><instance_pwd> <export_to_dir>

If you use a remote DB2 located on a Windows system, run the corresponding.bat file from the DDL/Script directory on that remote system:

db2_export_automation_db.bat <db_name> <instance_owner> <instance_pwd> <export_to_dir>


These are the required parameters:<db_name> - Name of the System Automation Application Manager database.

Typically, this is EAUTODB.<instance_owner> - Database instance owner userid.<instance_pwd> - Database instance owner password.<export_to_dir> - Absolute path name of the directory where the exported tables

should be stored.Ensure that the <instance_owner> user ID has write accessto this directory.

3. Review the messages created by the script, including the messages contained inthe export log file located in the logs sub-directory of the <export_to_dir>directory.

For more information about how to import the content of the automation database,refer to “Importing the content of the automation database” on page 70.

Note:

1. The export and import scripts are needed if an upgrade requires a change ofthe database layout. In this case, do not use the backup and restorefunctionality provided by DB2 to back up and restore the automation database,as this preserves the complete database layout. It is not generally required toexport and import the data when the System Automation Application Manageris upgraded. In most cases, changes of the automation database layout areperformed without the need to drop and recreate the database tables. For moreinformation, see “Upgrading to release 4.1” on page 65.

2. The DB2 export utility that is used by the automation data export script createsseveral warning messages with message ID SQL3100W. This warning messagecan be ignored. For further information about this message, refer to the DB2documentation.

3. For general information about the EXPORT and IMPORT commands providedby IBM DB2, refer to the DB2 documentation.

Storing the user role mappings for WebSphere applicationEEZEARStore the role mappings before you uninstall a previous version as part of theupgrade process to release 4.1, if the default role mappings for the user rolesdefined 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 WebSphereadministrator.

2. Navigate to Applications > Enterprise Applications > EEZEAR > Securityrole 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.sh3. Enter the wsadmin command ./wsadmin.sh

-username <wasadmin_id> -password<wasadmin_pwd> -lang jython -c


"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 AIXOn AIX, execute the following command after the automation engine (eezdmn) hasbeen stopped and before the installation is started:# /usr/sbin/slibclean

Upgrading from release 3.2.0 or 3.2.1This section describes what you must observe when migrating from release 3.2.0 or3.2.1 to release 4.1.

To upgrade from release 3.2.0 or 3.2.1 to release 4.1 of System AutomationApplication Manager, uninstall release 3.2.0 or 3.2.1 and install release 4.1 asdescribed 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, considerthe following questions:1. Are you using the agentless adapter?

Open the configuration utility using the cfgeezdmn command. If the Enableagentless adapter configuration check box on the configuration utilitylaunchpad window is selected, you are using the agentless adapter.

2. Did you configure to use SSL for the communication with all first-levelautomation domains?Click Configure for the Application Manager common configuration on theconfiguration utility launchpad window and select the Security tab. Check ifthe Enforce use of SSL for all first-level automation domains check box isselected.

Some modifications are introduced with release 3.2.2 that have to be consideredwhen migrating from release 3.2.0 or 3.2.1 directly to release 4.1. If the answer toboth questions is 'yes', perform the following migration steps after installingSystem Automation Application Manager Version 4.1:

Prior to release 4.1 of System Automation Application Manager, Agentless Adapterdomains were not included when SSL was enforced for communication betweenthe end-to-end automation manager and first-level automation domains. Startingwith release 4.1, this applies also for agentless adapter domains. In release 4.1, theconfiguration of the agentless adapter has been extended to configure also SSL fordata transport between the automation manager and the adapter. You can eitherconfigure SSL or deselect the Enforce use of SSL for all first-level automationdomains check box in the Application Manager common configuration.


Refer to “Configuring the Application Manager common settings” on page 105 fora description of the configuration utility. If you decide to configure SSL for datatransport 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 onlyone 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 AgentlessAdapters. The agentless adapter included with releases prior to SystemAutomation Application Manager Version 3.2.1.3 is now referred to as the localagentless adapter. The SSL enforcement option mentioned in the precedingparagraphs applies to both the local agentless adapter and the new remoteAgentless Adapters, but the migration action described in the previous topicsapplies only to the local agentless adapter.

If you configure remote agentless adapters on a system with System AutomationApplication Manager Version 4.1, you cannot distribute this configuration to asystem where a remote agentless adapter of version 3.2.1.3 is installed. You mustupgrade the remote agentless adapter system to version 4.1 before you distributethe configuration.

Upgrading the automation database from version 3.2.0 or 3.2.1About this task

Create a new database table EEZNODE in the automation database. Existing databasetables are not affected. To create the new table, run the appropriate script for yourenvironment as described below:

In a Windows environment:v In the <EEZ_INSTALL_ROOT>\install directory or in the DDL/Script directory on

the product DVD, run:db2_run_sql.bat <db_name> <instance_owner> <instance_pwd> createNodeTable.sql

In a UNIX environment:v In the <EEZ_INSTALL_ROOT>/install directory or in the DDL/Script directory on

the product DVD, run:db2_run_sql.sh <db_name> <instance_owner> <instance_pwd> createNodeTable.sql

Note: The db2_run_sql script searches for the SQL file in the ../DB2 directory.

If the automation database is located on a z/OS server, review ATVEM200 on how tocreate the EEZNODE table.

Upgrading the high availability policyIf 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 theautomation database from version 3.2.0 or 3.2.1.”

2. Exclude the node: samctrl -u a <node>.


3. Stop the first node in the cluster: stoprpnode <node>.

Use the installation wizard to install System Automation Application Manager onthis node. Specify that your are installing a high availability scenario. Select No, alldatabase installation steps have been performed prior to this installation inorder to prevent any database access during the upgrade process.

Postinstallation steps

1. Restart the node: startrpnode <node>.2. Include the node: samctrl -u d <node>.3. Run the configuration dialog cfgeezdmn on the upgraded node.4. Verify the values for configuring high availability are correct. Save your

changes in case you had any. Click Define policy in order to upgrade thepolicy.

Note: This does not affect any other resources defined in the end-to-end highavailability policy.

Repeat this procedure for all other nodes.

Importing the content of the automation databaseIf you decide to drop and recreate the automation database, use the scriptsdescribed in this topic. These scripts export the data from the automation databasebefore you drop the database, and import them back into the automation databaseonce it is recreated.

In addition, future upgrades of System Automation Application Manager canrequire changes of the layout of tables contained in the automation database. Inthis scenario, export the data contained in the automation database prior to theupgrade, and import the data back into the automation database after the upgradeto prevent data loss.

System Automation Application Manager provides scripts that assist you to exportand import data. These scripts are designed for local databases managed by DB2for distributed platforms. If you have a remote DB2 setup you must directly runthese scripts on the system where the automation database resides. If you use DB2for z/OS, the scripts can not be used directly, but they can serve as a blueprint foryour database administrators in order to create export and import procedures thatare appropriate for your environment.

For more information about how to export the content of the automation database,refer to “Exporting the content of the automation database” on page 66.

Import data

To import the data, perform the following steps:1. Stop the WebSphere Application Server to ensure that the automation manager

does not lock any data in the database.2. Change to the “DDL/Script” directory on the product DVD and run the

following script to import the data:./db2_import_automation_db.sh <db_name> <instance_owner> <instance_pwd> <import_from_dir>

If you use a remote DB2 located on a Windows system, run the corresponding.bat file from the DDL/Script directory on that remote system:

db2_import_automation_db.bat <db_name> <instance_owner> <instance_pwd> <import_from_dir>


These are the required parameters:<db_name> - Name of the System Automation Application Manager

database. Typically, this is EAUTODB.<instance_owner> - Database instance owner userid.<instance_pwd> - Database instance owner password.<import_from_dir>- Absolute path name of the directory where the tables to be imported are stored.

3. Review the messages created by the script, including the messages in that arecontained in the import log file that is contained in the "logs" sub-directory ofthe <import_from_dir> directory.

Note:

1. The export and import scripts are needed if an upgrade requires a change ofthe database layout. In this case, do not use the backup and restorefunctionality provided by DB2 to back up and restore the automation database,as this preserves the complete database layout. It is not generally required toexport and import the data when the System Automation Application Manageris upgraded. In most cases, changes of the automation database layout areperformed without the need to drop and recreate the database tables. For moreinformation, see “Upgrading to release 4.1” on page 65.

2. The DB2 export utility that is used by the automation data export script createsseveral warning messages with message ID SQL3100W. This warning messagecan be ignored. For further information about this message, refer to the DB2documentation.

3. For general information about the EXPORT and IMPORT commands providedby IBM DB2, refer to the DB2 documentation.

Verifying the installationAbout this task

This topic describes the tasks you should complete in order to verify that theautomation manager, automation engine, and operations console have beeninstalled successfully.

Verifying the automation managerAbout this task

To verify that the automation manager was installed successfully, complete thetasks 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 thedatabase tables were created successfully on AIX, Linux or Windows:

Procedure

1. Ensure that DB2 is running.2. db2 connect to <db_name>

3. db2 list tables for schema eautousr

4. db2 disconnect <db_name>

5. Click Tables. The table names, that are listed in “Verifying the creation of theremote database” on page 55 should be shown.


What to do next

Perform these steps to verify that the end-to-end automation database and thedatabase 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 orLinux:1. In a web browser window, specify the following address to display the Login

window of the WebSphere Application Server administrative console:http://<your_host_name>:<your_was_admin_port>/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 ApplicationServer requests:1. In a web browser window, specify the following address to display the Login

window of the WebSphere Application Server administrative console:http://<your_host_name>:<your_was_admin_port>/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.


Verifying the automation engineAbout 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 hasbeen successful the list of available command options is displayed.

Note: You can also use any of the other eezdmn command options to verify theinstallation 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 SystemAutomation Application Manager, Reference and Problem Determination Guide.

Verifying the operations consoleAbout this task

Perform the following steps to verify that the operations console was installedsuccessfully:1. In a web browser window, specify the following address to display the Login

window of the Dashboard Application Services Hub:http://<your_host_name>:<your_dash_port>/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 tasksAbout this task

When you have verified the installation of System Automation ApplicationManager, 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 AutomationApplication 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 usercredentials for the first-level domains on the User Credentials tab of theconfiguration dialog. “Starting the Application Manager configuration dialog”on page 99 describes how to start the configuration dialog. For detailedinformation about the User Credentials tab, see “User Credentials tab” onpage 111.


Modifying the Lightweight Third Party Authentication (LTPA)settingsAbout this task

After the installation of System Automation Application Manager, you shouldcheck whether the LTPA settings are appropriate for your environment.

During installation, the following LTPA parameters are automatically set inWebSphere Application Server:v LTPA Password is set to the password of the IBM Dashboard Application

Services Hub administrator user IDv LTPA Timeout for forwarded credentials between servers is set to 1440 minutes

LTPA Timeout is a security-related timeout. Because this timeout is absolute, auser will be logged out and forced to log in to the IBM Dashboard ApplicationServices Hub again when the LTPA timeout is reached even if the user isworking with the operations console at the time.

To change the LTPA settings (for example, password and timeout) you use theWebSphere Application Server administrative console. In the administrativeconsole, select Security > Global security. In the Authentication box, click on thelink associated to the LTPA radio button.

Configuring the number of usersAbout 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 theautomation manager using the System Automation operations console. You canchange the current setting by changing the Maximum connections value for theEEZTopicConnectionFactory in the WebSphere administrative console: Resources>JMS > Topic connection factories > EEZTopicConnectionFactory > Connectionpool properties.

If Maximum connections is set to 0, the number of concurrent connections that canbe established is allowed to grow infinitely. If the specified number of maximumconnections is reached, the next connection attempt using the operations consolewill display the following error message:EEZU0011E:Unable to set up the event path between the operations consoleand the management server:CWSIAD005E: The JCA runtime failed to allocate a connection.

Modifying available heap sizeAbout this task

After the installation of System Automation Application Manager, modify the heapsize settings of the WebSphere Application Server to the following recommendedvalues:v Minimum heap size: 768 MBv Maximum heap size: 2048 MB

Perform the following steps to increase the JVM heap size:1. Log on to the WebSphere administrative console.


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 toavoid OutOfMemoryErrors. Refer to the WebSphere Application Server onlinedocumentation for more information about how to determine the optimumvalue for the maximum heap size, depending on the available physicalmemory.

4. Save your changes. Restart WebSphere Application Server for the changes totake effect.

Upgrading from a Try and Buy version to a full productversion

If you have installed the Try and Buy version of System Automation ApplicationManager and decided to purchase the full product version, then you will receiveanother copy of the installation media.

The installation media contains the license file for the full license. The license file islocated in the license sub-directory. Extract the license file from the installationmedium and perform the license upgrade by issuing the following command:

eezdmn -instcert <fully qualified license_file_name>

After upgrading the license, check if any updates are already available and installthe latest service level.

UninstallingUse the uninstallation program to uninstall System Automation ApplicationManager.

About this task

This topic describes how to uninstall System Automation Application Manager. Anuninstallation program is provided that removes the components that are installedby the installation wizard.

Note: Uninstall System Automation Application Manager before uninstallingWebSphere Application Server.

Using the graphical uninstallation programAbout this task

Before you begin:

v During uninstallation, a number of panels are displayed, prompting you toconfirm that specific files are to be deleted. Check the files carefully beforeconfirming the deletion.

v If you changed the user repository settings of WebSphere Application Server toan external user repository after the installation of System AutomationApplication Manager, the following change is required:Change the variable EXTERNAL_USER_REP_ACTIVATE in file <EEZ_INSTALL_ROOT>/uninstall/installvariables.properties to false:EXTERNAL_USER_REP_ACTIVATE=false.

This prevents users and groups from being deleted in the WebSphereApplication Manager in a subsequent uninstallation process.


Perform the following steps to uninstall System Automation Application Manager:1. Launch the uninstallation program by entering the following command in a

shell:<EEZ_INSTALL_ROOT>/uninstall/uninstall

This starts the uninstallation wizard.2. Read the information on the first wizard window and click Next.3. Provide the requested information for the WebSphere Application Server:v WebSphere Application Server Admin user ID and passwordv WebSphere Application Server - server namev 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 startthe uninstallation.

5. Some information panels are displayed while the uninstallation program checksyour system for the information needed for the uninstall.

6. When the uninstallation is complete, a summary window is displayed. To exitthe installation program, click Done.

Note: If problems were encountered during the unconfiguration step, an errorwindow appears before the actual uninstallation step, in which the files areremoved 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 Cancelto perform corrective actions and then rerun the uninstallation.

Uninstallation in silent modeAbout this task

If you installed System Automation Application Manager in silent mode, theuninstallation must be silent too. The password parameter in the generatedinstallvariables.properties file in the uninstall subdirectory does not have acorresponding value. Before starting the uninstallation in silent mode, you mustenter this password manually, otherwise the silent uninstallation fails. Perform thefollowing steps:

Procedure1. 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 systemsNew operating system support can be introduced with a fix pack 4.1.0.<f>, where<f> is the respective fix pack number.


Installing the middleware software

The middleware versions that are bundled as part of System AutomationApplication Manager version 4.1 might not be sufficient for newly supportedoperating systems. Before you install System Automation Application Manager,check the DB2 service level that is required to support the new operating systemversions. If a service level higher than the one that you receive when you orderSystem Automation Application Manager 4.1 is required, download that versionfrom the respective download site. Install DB2 as described in “Installing a DB2server” on page 51 by using the new DB2 version.

Starting with fix pack 4.1.0.1 the minimum version of Jazz for Service Managementhas changed. Therefore, the version of Jazz for Service Management that youreceive when you order System Automation Application Manager 4.1 is notsufficient for any fix pack installation. For more information, see “Installing a newJazz for Service Management version” on page 58.

Installing System Automation Application Manager

An installation of System Automation Application Manager version 4.1.0.0 asdescribed in “Installing System Automation Application Manager” on page 59 isonly possible on the set of operating system versions that are initially supportedfor version 4.1.0.0. Support for other operating system versions can be added withfix packs at a later point in time. Newly added operating system versions arereferred as "new operating system support". If you want to install a fix pack on analready 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 isintroduced with a fix pack, this fix pack must be installed as an initial installationrather than an upgrade installation. Therefore, it is required to copy the 4.1 licensefile into the EEZ410<f><platform>/license directory before you start the fix packinstallation:1. Obtain a System Automation Application Manager license file that is contained

in one of the 4.1 release deliverables:

Product DVDUse one of the DVDs listed in “Packaging” on page 2 to obtain thelicense. You can find the license file that is named eez41.lic indirectory EEZ4100<platform>/license.

Electronic distributionUse one of the archive files that are listed in “Packaging” on page 2 toobtain the license. Extract the archive file. In the expanded directorytree, you can find the license file that is named eez41.lic in directoryEEZ4100<platform>/license.

2. Extract the 4.1.0.<f> fix pack archive file that contains the new operatingsystems support as described in “Packaging” on page 2. In the expandeddirectory tree, directory EEZ410<f><platform>/license is empty.

3. Copy the license file into the EEZ410<f><platform>/license directory of theexpanded 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 aninitial installation of the product on the new operating system.


Installing fix packsInstalling service means applying corrective service fix packs to release 4.1 of IBMTivoli System Automation Application Manager or upgrading the software releaselevel from release 4.1. In this documentation, the service fix packs that you use forupdating System Automation Application Manager are referred to as product fixpacks.

Product fix packs and interim fixes are delivered as:v Self-extracting archives for AIXv Archives in TAR-format for Linux

Note: Starting with fix pack 4.1.0.1 the minimum version of Jazz for ServiceManagement has changed. Before installing any fix pack, upgrade Jazz for ServiceManagement to the required level. For more information, see “Installing a newJazz for Service Management version” on page 58.

Obtaining fix packsRead the release notes to find out which fix packs are required for a releaseupdate.

The fix packs are available on the Tivoli System Automation Application Managersupport page.

Archive naming conventionsUse the DVDs and archives listed in “Packaging” on page 2 to upgrade SystemAutomation Application Manager from version 3.2 to version 4.1.0.

Naming convention for product fix pack archives:4.1.0-TIV-SAAM-<platform>-FP<fix_pack_number>.<archive_type>

Wherev <platform> represents the platform on which System Automation Application

Manager is installed.v <fix_pack_number> represents the fix pack number.v <archive_type> represents the platform-specific file extension of the archive.

Example: This is the tar archive that is used to install product fix pack 1 forSystem 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 locationThe location at which you find the update wizard program for installing theproduct fix pack after unpacking an archive has the following syntax:EEZ41<mf><platform>/<platform>/<update_wizard_file>

wherev <mf> represents modification level and fix level. For example, for fix pack 4.1.0.1,

the directory is named EEZ4101.v <platform> represents the platform on which System Automation Application

Manager is installed.


http://www.ibm.com/support/entry/portal/product/tivoli/tivoli_system_automation_application_manager?productContext=1050970698

v <update_wizard_file> represents the update wizard program you use to installthe product fix pack.

Example: This is where you find the update wizard after the Linux on System xarchive for fix pack 1 for System Automation Application Manager 4.1 isunpacked:EEZ4101I386/i386/

Usage instructions for the platform-specific archivesThese are the archives for applying service to System Automation ApplicationManager.

AIXTable 29. Archives for AIX platforms

Archive name Description

4.1.0-TIV-SAAM-AIX-FP<fix_pack_number>.bin The archive is self-extracting.

This is where you find the update installer programafter unpacking the product fix pack archive:

EEZ41<mf>AIX/AIX/setup.bin

Linux on System xTable 30. Archives for Linux on System x


4.1.0-TIV-SAAM-LinuxI386-FP<fix_pack_number>.tar For extracting the archive, GNU tar 1.13 or later isrequired. Use the tar -xf command to extract thefiles.

This is where you find the update installerprogram after unpacking the product fix packarchive:

EEZ41<mf>I386/i386/setup.bin

Linux on System zTable 31. Archives for Linux on System z


4.1.0-TIV-SAAM-LinuxS390-FP<fix_pack_number>.tar For extracting the archive, GNU tar 1.13 or lateris required. Use the tar -xf command to extractthe files.

This is where you find the update installerprogram after unpacking the product fix packarchive:

EEZ41<mf>S390/s390/setup.bin

Installing a product fix packAbout this task

Before you begin:

v Product fix packs are always cumulative.


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 archiveto a temporary directory.

3. Unpack the product fix pack archive to a temporary directory. For informationabout how to unpack the archive for your platform, refer to “Usage instructionsfor the platform-specific archives” on page 79.

4. Before performing the subsequent steps, check the release notes for additionalor deviating installation instructions.

5. Change to the directory in which the update wizard program is located. Forinformation on where to find the update wizard program, refer to “Usageinstructions for the platform-specific archives” on page 79.

6. Start the update wizard. When the wizard is launched successfully, theWelcome window opens.

7. Follow the instructions on the wizard panels to install the product fix pack.

Installing fix packs in a high availability setupAbout this task

If you made your installation of System Automation Application Manager highlyavailable by using System Automation for Multiplatforms as described in “Highavailability for System Automation Application Manager” on page 150, perform thefollowing steps to install service for System Automation Application Manager. Theinstructions assume that System Automation Application Manager is currentlyrunning on node 1 but not on node 2.

Procedure1. Exclude node 2, then stop node 2 within the System Automation for

Multiplatforms domain using the command stoprpnode. It is important to stopthe node and not just to exclude it. If you exclude node 2, the resources arestill monitored. If the resources on node 2 become online due to themaintenance 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 theJDBC driver directory on node 2 in the file system, so that the WebSphereApplication Server cannot find it. This ensures that there is no way forSystem Automation Application Manager on node 2 to connect to theremote database manager during update installation. You can determinethe JDBC driver directory in the WebSphere administrative console. OpenEnvironment > WebSphere Variables and inspect the variableDB2_JDBC_DRIVER_PATH.

b. On the window High Availability, select I want to create or update ahighly available System Automation Application Manager setup withtwo or more servers and No, all database installation steps have beenperformed prior to this installation in order to skip all steps related to theautomation database.


3. In case of remote DB2 setup, perform the following step: Rename the JDBCdriver 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 Manageroperations console, and in particular the version number on the Welcomepage).

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

Uninstalling service is only supported by uninstalling the complete SystemAutomation Application Manager as described in “Uninstalling” on page 75, andreinstalling to the level required.

Installing for high availabilityIf you want to make System Automation Application Manager highly availableusing System Automation for Multiplatforms, you need to install SystemAutomation 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 ina high availability cluster with System Automation for Multiplatforms.

2. You have two existing nodes in a high availability System Automation forMultiplatforms cluster. You want to install System Automation ApplicationManager on one additional node. All three nodes are located in a highavailability cluster.

To install System Automation Application Manager on an additional node, performthe 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 twoor more servers on the high availability window in the installation wizard.

2. Potentially, do an update installation to System Automation ApplicationManager V4.1.x in order to match the fix pack level of the System AutomationApplication Manager installation on node 1.

3. Configure high availability for the end-to-end automation manager as describedin “Setting up the high availability policy” on page 152.


Installing for Distributed Disaster RecoveryFind out what to do, if you plan to implement a setup with a System AutomationApplication Manager on two GDPS sites. In this configuration, System AutomationApplication Manager is moved automatically by GDPS if the K-System mastermoves.

Installing the prerequisite software on both sitesInstall all necessary System Automation Application Manager prerequisites on thenodes of both sites.

The order in which you install them is not important, but you must ensure that thesoftware versions, fix pack levels, and installation paths on both sites are the same.All configuration settings such as administrator ID and password, ports, DB2instance, must be identical on both sites. See also “Installing the middlewaresoftware” on page 51.

Installing and configuring System Automation forMultiplatforms

Install System Automation for Multiplatforms on both sites. When the installationcompletes, create a single-node domain which is used to automate SystemAutomation Application Manager, the WebSphere Application Server, and DB2HADR: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 forMultiplatforms Knowledge Center.

Installing System Automation Application Manager on the firstsite

You can select either of the two sites for your first System Automation ApplicationManager installation. The first site must be installed as an initial installation in ahigh availability setup with local EAUTODB created during installation. Run yourinstallation 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 moreservers, and Yes for the installation on the first node.

v Select IBM DB2 on same system (local) and complete the required fields for thissetup.

v In the GDPS configuration section of the installation wizard, select EnableGDPS server connection and Enable GDPS backup server connection andspecify the host name and port number of the GDPS K-Systems of both sites.

For more information, refer to “Installing System Automation ApplicationManager” on page 59.


http://www-01.ibm.com/support/knowledgecenter/SSRM2X/welcome

http://www-01.ibm.com/support/knowledgecenter/SSRM2X/welcome

Configuring System Automation Application Manager on thefirst site

Use the following settings to associate the System Automation ApplicationManager 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 theend-to-end automation manager site and select the correct GDPS site of thealternate host.

v On the High Availability tab of the launchpad window, select Enable the highavailability configuration tasks, and click Configure.

v In the Select Application Manager High Availability Setup window, clickConfigure the Applications Manager single node high availability policy for adisaster recovery setup, and click OK.

v In the Command shell tab, select Use specified user credentials and providethe user credentials.

v Specify all the required information for this type of high availability policy andsave 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 createdduring the installation of the first System Automation Application Manager. Stopthe System Automation Application Manager. Make the database available asPrimary at the site where the second System Automation Application Manager isgoing to be installed.

For more information about how to install the setup, see DB2 for Linux UNIX andWindows Knowledge Center.

Perform the following sequence of steps. The user ID performing these commandsmust be the DB2 instance owner.1. Stop the System Automation Application Manager on the first site. Ensure that

the DB2 instance is started on both sites.2. Configure log shipping on the EAUTODB using the following commands, and

substituting the values of the tags between < >:db2 update database configuration for <DB name> using LOGRETAIN recoverydb2 update database configuration for <DB name> using LOGINDEXBUILD ON

Where <DB name> is the name of the EAUTODB.3. Set up HADR using the following commands:

db2 update db cfg for <DB name> using HADR_LOCAL_HOST <Hostname 1>HADR_REMOTE_HOST <Hostname 2> HADR_LOCAL_SVC <Port 1>HADR_REMOTE_SVC <Port 2> HADR_REMOTE_INST <DB instance name>HADR_TIMEOUT 120 HADR_SYNCMODE <Sync mode> HADR_PEER_WINDOW 0


http://www-01.ibm.com/support/knowledgecenter/SSEPGG/welcome

http://www-01.ibm.com/support/knowledgecenter/SSEPGG/welcome

Where:<DB name> is the name of the EAUTODB.<Hostname 1> is the host name of the node where the EAUTODB wascreated.<Hostname 2> is the host name of the node at the other site where SystemAutomation Application Manager is going to be installed.<Port 1> the port that is used for transaction log shipping on the nodewhere the EAUTODB was created. The transmission protocol is HTTP andthe default port number is 5005<Port 2> is the port that is used for transaction log shipping on the node atthe other site (Site 2). The default is 5005.<DB instance name> is the instance name of EAUTODB on both sites.<Sync mode> choose between SYNC, NEARSYNC, and SUPERASYNC.

Note: The following steps are required during the initial installation of the DRsetup. They are also required if the EAUTODB cannot be automaticallyreintegrated after a disaster. This problem occurs after a System AutomationApplication Manager toggle in which the EAUTODBs on both sites weremodified without replicating the changes to the other site.

4. Transfer the database to the other site. Create a directory on both nodesowned by the DB2 instance owner that belongs to the DB2 administratorsgroup. This directory is for your backup.

5. Back up the database using the following command on the first site, replacingthe values of the tags as indicated:db2 backup <DB name> to <Backup folder>

Where:<DB name> is the name of the EAUTODB.<Backup folder> is the directory you created to store the backup.

6. Transfer the generated backup file to the DB2 host at the other site. On thatsite restore the backup by using the following command:db2 restore db <DB name> from <Backup folder> replace history file

Where:<DB name> is the name of the EAUTODB.<Backup folder> is the directory you created to store the backup.

7. On the second site, you must adjust the HADR settings accordingly. The localhost name must be exchanged with the remote host name. Use the followingcommand, replacing the tags as indicated:

db2 update db cfg for <DB name> using HADR_LOCAL_HOST <Hostname 1> HADR_REMOTE_HOST <Hostname 2>

Where:<DB name> is the name of the EAUTODB.<Hostname 1> is the DB2 host name on the second site where SystemAutomation Application Manager is going to be installed.<Hostname 2> is the DB2 host name on the first site.

8. Start HADR at the standby database first. This is the site where the SystemAutomation Application Manager remains offline. If you set up HADR thefirst time during System Automation Application Manager installation, thestandby site is the site where System Automation Application Manager isalready installed. Use the following command:


db2 start hadr on database <DB name> as standby

Where:<DB name> is the name of the EAUTODB.

9. Start HADR at the primary database. This is the site where SystemAutomation Application Manager is going to be installed:db2 start hadr on database <DB name> as primary


10. Verify that the DB2 HADR is set up correctly on both sites. Use the followingcommand on each site:db2pd -hadr -db <DB name>


Check the output and verify that the HADR role is Standby at the site whereSystem Automation Application Manager is already installed and Primary atthe site where it is going to be installed. The HADR state on both sides mustbe Peer.

Installing System Automation Application Manager on thesecond site

Install System Automation Application Manager on the second site with thefollowing 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 moreservers 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 thissetup.

v In the GDPS configuration section of the installation wizard, select EnableGDPS server connection and Enable GDPS backup server connection andspecify the host name and port number of the GDPS K-Systems of both sites.

For more information, see “Installing System Automation Application Manager” onpage 59.

Configuring System Automation Application Manager on thesecond site

Configure the second System Automation Application Manager in the same way asdescribed for the first site.

All settings must be identical for both System Automation Application Managerinstallations, except for the GDPS site of the alternate System AutomationApplication Manager host. You can configure either using the graphical mode orthe silent configuration utility. Refer to “Configuring the Application Managercommon settings” on page 105 for the graphical configuration. If you want to usethe 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 Managercommon configuration using the following command:


cfgeezdmn -s -e -gr

2. Transfer the silent properties input file from the first site to the host of thesecond site where you are now configuring System Automation ApplicationManager.

3. Adjust the settings for host name, alternate host name, and GDPS site locationof 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 mustalways be synchronized. Replication of configuration changes to the other site isnot performed automatically by System Automation Application Manager, but hasto be done manually by the operator each time the configuration on one site isupdated. To simplify this task, you can install or develop a tool that copies theSystem Automation Application Manager policy pool and the dif properties fileswith the FLA domain credentials to the other site. You can customize the followingexample script with your site-specific information:#!/bin/shscp –r /etc/opt/IBM/tsamp/eez/policyPool/ root@<hostname_at_other_site>:/etc/opt/IBM/tsamp/eez/policyPool/scp /etc/opt/IBM/tsamp/eez/cfg/eez.automation.engine.dif.propertiesroot@<hostname_at_other_site>:/etc/opt/IBM/tsamp/eez/cfg

Configuring all end-to-end automation adapters with twoSystem Automation Application Manager hosts

Every first-level automation adapter or remote agentless adapter connected toSystem Automation Application Manager must have the capability of switching itsevent target if the active System Automation Application Manager moves to theother site.

For this to be possible, you must ensure that the version of the adapters you installsupports the System Automation Application Manager site switch. Furthermore,both System Automation Application Manager host names should be defined asalternate 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, andspecify the alternate end-to-end automation management host name on the HostUsing Adapter tab of the configuration dialog. For more information, refer to thespecific sections on the adapter configurations in Chapter 3, “Configuring,” onpage 99.

The configuration for the System Automation for Multiplatforms adapter isdescribed in System Automation for Multiplatforms Installation and ConfigurationGuide, SC34-2584.


For the system Automation for z/OS adapter, there is no configuration utility.Refer to the System Automation for z/OS documentation for information abouthow to apply this configuration in this environment.

Configuring high availability and contact retry interval of allend-to-end automation adapters

If a disaster occurs, end-to-end adapters might fail and the two sites mightexperience protracted communication problems. In such a situation, the SystemAutomation Application Manager and the end-to-end adapters of the other sitecannot communicate. All adapters and the JEE framework must be configured sothat the adapters can try repeatedly to establish the connection to the JEEframework. The JEE framework must not remove previously connected domainsbefore they can be reached again. It is recommended to set up the adapters ashighly available resources.

The following table lists the recommended settings of the end-to-end adapters andthe JEE framework. See also System Automation Application Manager Reference andProblem Determination Guide, Chapter 4, "Modifying the environment variables for theautomation Java EE Framework. For details about configuring adapters, refer toChapter 3, “Configuring,” on page 99.

Table 32. Recommended end-to-end adapter and JEE framework settings in a DR setup

Configuration optionEnd-to-end adapter is highlyavailable

End-to-end adapter is nothighly available

JEE framework environmentvariable"com.ibm.eez.aab.domain-removal-hour"

48 (default) a value 300 - 1000

In the Advanced dialog inthe Adapter configurationtabs: "Remote contactactivity interval"

560 (default) 0 (retry forever)

In the Advanced dialog inthe Adapter configurationtabs: "initial contact retryinterval"

0 (default) 0 (retry forever)

Installing the remote agentless adapterYou can install the remote agentless adapter using the wizard or in silent mode.

Using the installation wizard to install the remote agentlessadapter

Use an installation wizard to install the remote agentless adapter on AIX, Linux, orWindows systems.

About this task

The installation wizard files are located either on the product DVD or in thedirectory that is created as a result of extracting the electronic deliverable archivefile for the respective operating system as listed in “Packaging” on page 18.


Run the following steps:

Procedure1. 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 andUsser Account Control: Detect application installations and prompt forelevation is enabled.

2. Change to the directory that contains the installation program. For the locationof the directory, see “Packaging” on page 18. Start the installation by launchingthe installation wizard using setup.bin. On the first window, click OK todisplay the Welcome window. The language is detected automatically on yourcomputer or you can select it on the Welcome window. To launch theinstallation wizard to generate a response file, use the following command:<installation_wizard> -Dpreparesilent=true. The following response file isgenerated: <install_root>\install\install.properties. When you launchedthe wizard, click Next on the Welcome window. Note: On a Windows system,you may get a Project Load Warning message indicating inconsistent installerversions. Ignore this message and press Enter to proceed with the installationprocess.

3. On Linux you can not change the default installation directory. On Windowsyou can specify a directory or leave the default value. Click Next to display theTivoli Common Directory window.

4. If the installation program did not detect a Tivoli Common Directory on yoursystem, accept the default location or specify a different directory. On Linux,the default directory can not be changed. If a Tivoli Common Directory wasdetected 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 installationprocess. While the adapter is being installed, a progress window is displayed.When the installation is complete, an installation summary window isdisplayed, on which you can verify the success of the installation. If problemsoccur, check the applicable installation log files for more information. ClickDone to close the installation wizard.

Related information:“Configuring remote agentless adapters” on page 134Configure remote System Automation Application Manager settings.

Installing the remote agentless adapter in silent modeUse a response file which is generated during the wizard-driven installation toinstall the remote agentless adapter in silent mode.

About this task

For information on how to generate a response file, refer to “Using the installationwizard to install the remote agentless adapter” on page 87. Copy the generatedresponse file to the system where you want to install the remote agentless adapterin silent mode. If you want to perform a silent installation, you need the sameauthorization as described for using the installation wizard in graphical mode. If


you want to perform the remote agentless adapter installation on multiple systemswith identical installation settings, copy the response file to each system and runthe installation wizard in silent mode.

Note: Response files contain password information. Delete the response files whenthey are no longer required.

Procedure

To install the remote agentless adapter in silent mode, use the following command:<installation_wizard> -i silent -f <response_file_name>

Uninstalling the remote agentless adapterAn uninstallation program is provided to remove the adapter that was installed bythe installation wizard.

About this task

If you want to uninstall the remote agentless adapter, you need the sameauthorization as described in “Using the installation wizard to install the remoteagentless adapter” on page 87 for an initial installation.

During uninstallation, you may be prompted to confirm that specific files are to bedeleted. Make sure the right files are listed before you confirm the deletion. Todetermine 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 SystemAutomation Application Manager, Reference and Problem Determination Guide.

Procedure1. To launch the uninstallation program, enter the following command in a shell:

<EEZ_INSTALL_ROOT>/uninstall/uninstall. This opens the initial window of theuninstallation program.

2. The uninstallation program is launched in the same language as used for theinstallation. After the uninstallation program is launched, the uninstallationwizard 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 theapplicable installation log files for more information. Click Done to close theuninstallation wizard.

3. To perform a silent uninstallation, no response file is necessary. To launch thesilent uninstallation, use the following command: <installation_wizard> -isilent.


Installing and uninstalling service for the remote agentlessadapter

Installing service means applying corrective service fix packs to release 4.1 of theSystem Automation Application Manager remote agentless adapter. The service fixpacks that you use for updating a remote agentless adapter are referred to asproduct fix packs.

Product fix packs and interim fixes are delivered as:v Self-extracting archives for AIX and Windowsv Archives in TAR-format for Linux

Where to obtain fixes

The fix packs are available at Tivoli System Automation Application Manager 4.1.0Support 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 thefollowing syntax:4.1.0-TIV-SAAMR-<platform>-FP<fix_pack_number>.<archive_type>

v <platform>: Represents the platform on which the remote agentless adapter isinstalled.

v <fix_pack_number>: Represents the fix pack number.v <archive_type>: Represents the platform-specific file extension of the archive.

This is the tar archive that is used to install product fix pack 1 for the remoteagentless adapter on Linux on POWER® platforms:4.1.0-TIV-SAAMR-PPC-FP0001.tar

Naming conventions of the update installer location

Naming conventions of the update installer location

After the Linux on POWER archive for fix pack 1 for the remote agentless adapter4.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


Windows 4.1.0-TIV-SAAMR-Windows-<fix_pack_number>.exe

The archive is self-extracting. This is where youfind the update installer program afterunpacking the product fix pack archive:

EEZ41<mf>Remote\Windows\ALAdapt\setup.exe




Table 33. Archives for applying service to remote Agentless Adapter (continued)


AIX 4.1.0-TIV-SAAMR-AIX-FP<fix_pack_number>.bin

The archive is self-extracting. This is where youfind the update installer program afterunpacking the product fix pack archive:

EEZ41<mf>Remote/AIX/ALAdapt/setup.bin

Linux onSystem x

4.1.0-TIV-SAAMR-LinuxI386-FP<fix_pack_number>.tar

For extracting the archive, GNU tar 1.13 orlater is required. Use the tar -xf command toextract the files. This is where you find theupdate installer program after unpacking theproduct fix pack archive:

EEZ41<mf>Remote/I386/ALAdapt/setup.bin

Linux onPOWER

4.1.0-TIV-SAAMR-LinuxPPC-FP<fix_pack_number>.tar


EEZ41<mf>Remote/PPC/ALAdapt/setup.bin

Linux onSystem z

4.1.0-TIV-SAAMR-LinuxS390-FP<fix_pack_number>.tar


EEZ41<mf>Remote/S390/ALAdapt/setup.bin

Installing a product fix pack

Before you begin, be aware of the following:v Product fix packs are always cumulative.v Release 4.1 must be installed before any product fix pack can be installed.v To install a product fix pack, you must have root authority.

To install a product fix pack, perform the following steps:1. Check the release notes to find out which archives are required.2. Download the archives for product fix packs from the System Automation

Application Manager support site to a temporary directory.3. Unpack the product fix pack archive to a temporary directory. For information

about how to unpack the archive for your platform, see “Usage instructions forthe platform-specific archives” on page 79.

4. Before performing the subsequent steps, check the release notes for additionalor deviating installation instructions.

5. Change to the directory in which the update wizard program is located. Forinformation on where to find the update wizard program, see “Usageinstructions 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 page87.

7. Follow the instructions on the wizard panels to install the product fix pack. Thesteps that you have to perform are the same as described for the initialinstallation.


Uninstalling service

If you want to uninstall service you need to uninstall the complete remoteagentless adapter as described in “Uninstalling the remote agentless adapter” onpage 89. Then you can reinstall to the level required.

Installing the IBM PowerHA adapterFind out how to install the PowerHA adapter using SMIT and how you can verifyyour installation.

Using SMIT to install the adapterAbout this task

You will find the package in the directory on the DVD or in the electronicdeliverable 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 berun because it relies on fixed paths.

After installing the adapter it must be configured as described in “Configuring thePowerHA adapter” on page 177.

Verifying the PowerHA adapter installationAbout 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 theservice IP label of the same name in State: UP


clstat - HACMP Cluster Status Monitor-------------------------------------

Cluster: hacp57067 (1137142142)Mon Feb 20 14:15:16 MET 2011

State: UP Nodes: 2SubState: STABLE

Node: p570sa06 State: UPInterface: p570sa06 (0) Address: 9.152.20.176

State: UPInterface: p57067ha (0) Address: 9.152.24.195

State: UPResource Group: hacadapter_rg State: On line

Node: p570sa07 State: UPInterface: p570sa07 (0) Address: 9.152.20.177

State: UP************************ f/forward, b/back, r/refresh, q/quit *********

Uninstalling the PowerHA adapterAbout 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) adapterYou can install the FOC adapter either using the wizard or in silent mode. Makesure you verify your installation.

Generate a response file when you use the installation wizard on a node. Installthe adapter in silent mode on the remaining nodes of the cluster if you are makingthe adapter highly available, in which case the values in the response file apply toall nodes.

Installing the Failover Cluster Command Interface optionalfeature

The Failover Cluster Command Interface feature is required to configure the FOCadapter.

Starting with Windows Server 2012 system, this feature is not installed anymoreper default as part of the Failover Cluster (FOC) installation.

The cluster.exe executable which is part of the feature is required by thecfgmscsadapter utility. If you are planning to use the FOC adapter, make sure thatthe Failover Cluster Command interface feature is installed on all nodes of thefailover cluster. The feature is located in the hierarchy of installable features asfollows:

> Remote Server Administration Tools

> Feature Administration Tools

> Failover Clustering Tools


> Failover Cluster Command Interface

Using the installation wizard to install the FOC adapterThis 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” onpage 95.

The installation wizard files are located either on the product DVD or in thedirectory that is created by extracting the archive file. You can find the archive filenames 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 onthe wizard panels are either default values or values that were detected onyour system.

v Launch the installation wizard to generate a response file. Enter thecommand:setup.exe -Dpreparesilent=true

You can find the response file in the following directory:<install_root>\install\install.properties

When you launched the wizard, click Next on the Welcome window.3. Specify the directory where you want to install the adapter or accept the

default location. Click Next to display the Tivoli Common Directory window.4. If the installation program did not detect a Tivoli Common Directory on your

system, accept the default location or specify a different directory. If a TivoliCommon Directory was detected on your system, the directory is displayedand cannot be changed.Click Next to display the Microsoft Failover Cluster adapter service userwindow.

5. Specify the domain user account prepared in “Preparing the user account” onpage 36 and the password.Click Next to display the summary window.

6. Check the values on the summary window and click Install to start theinstallation.

7. While the adapter is being installed, a progress window is displayed.When the installation is complete, an installation summary window isdisplayed, on which you can verify the success of the installation.If problems occur, check the applicable installation log files for moreinformation. Click Finish to close the installation wizard.


Installing the FOC adapter in silent modeAbout this task

This topic describes how you install the adapter in silent mode, using a responsefile you generated during wizard-driven installation. For information on how togenerate a response file and how to use it as input for a wizard-driven installation,see “Using the installation wizard to install the FOC adapter” on page 94.

To install the FOC adapter in silent mode, use the following command:setup.exe -i silent -f <response_file_name>

Note:

1. Response files contain password information and should be deleted when theyare no longer needed.

2. The silent installation will only be successful if the wizard-driven installationwhere the response file was generated completed successfully without errors.

Upgrading the FOC adapterAbout this task

You can upgrade an already installed FOC adapter to the current version byrunning the installation as described in “Installing the Failover Cluster (FOC)adapter” on page 93.

Verifying the FOC adapter installationAbout this task

Perform the following steps to verify that the adapter is installed and configuredcorrectly:

The adapter is highly available:

1. Start the FOC adapter using Microsoft FOC and check if the domainjoins.

2. Fail the adapter over to all Microsoft FOC nodes and check if thedomain joins.

The adapter is not highly available:Start the FOC adapter using the Services plug-in from the MicrosoftManagement Console and check if the domain joins.

Uninstalling the FOC adapterAbout 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 overto another Microsoft FOC node if you stop the service manually.If the FOC adapter service is highly available, you must take the FOC adaptergroup offline.

2. Open the Windows Control Panel and use Add or Remove Programs touninstall the adapter.


Installing the Veritas Cluster Server (VCS) adapterYou can install the VCS adapter using the wizard or in silent mode. Make sure youverify your installation.

HACMP

Using the installation wizard to install the VCS adapterAbout this task

You use an installation wizard to install the VCS adapter on Solaris/SPARCsystems.

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 detectedautomatically or you can select it on the first window.To launch the installation wizard, generating a response file, use the followingcommand:install.bin -Dpreparesilent=true

This is the response file that is generated:<install_root>\install\install.properties

After installing the adapter it must be configured as described in “Configuring theVCS adapter” on page 193.

Installing the VCS adapter in silent modeAbout this task

This topic describes how to install the adapter in silent mode, using a response filegenerated during wizard-driven installation. For information on how to generate aresponse file and how to use it as input for a wizard-driven installation, refer to“Using the installation wizard to install the VCS adapter.”

To install the VCS adapter in silent mode, use the following command:install.bin -i silent -f <response_file_name>

Note:

1. Response files contain password information. Delete the response files whenthey are no longer required.

2. The silent installation is successful if the wizard-driven installation completedsuccessfully without errors on the system where the response file wasgenerated.

Verifying the VCS adapter installationAbout 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 .


3. A status screen similar to the following is displayed, showing the status of themember resources of the resource group vcsadapter-rg:

sasun01:~ # hastatusattempting to connect....connectedgroup resource system message--------------- -------------------- -------------------- -------vcsadapter-rg sasun01 OFFLINEvcsadapter-rg sasun02 ONLINE----------------------------------------------------------------

vcsadapter-rs sasun01 OFFLINEvcsadapter-rs sasun02 ONLINEvcsadapter-ip sasun01 OFFLINEvcsadapter-ip sasun02 ONLINE

Uninstalling the VCS adapterAbout 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 3. Configuring

After you installed System Automation Application Manager and the componentsthat you require, complete the configuration tasks to fully prepare yourinfrastructure 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-levelautomation adapters that are part of System Automation Application Manager.

Note: You need an X11 server to use the dialogs of the configuration utilities. Youneed the 32-bit version of the X11 installation packages to run the configurationdialog. On some Linux operating system platforms, those packages are containedon the distribution media, but are not part of the standard installation. Make surethat the 32-bit version of the X11 installation packages is installed.

You can also configure the application manager in silent mode by using an inputproperties file. If an X11 server is not available, silent configuration is the onlysupported method on this system. For more information, see “Starting silentconfiguration” on page 205.

Configuring the Application ManagerConfigure the Application Manager by starting the Application ManagerConfiguration - Task Launcher dialog.

Starting the Application Manager configuration dialogThe cfgeezdmn command configures the settings of different System AutomationApplication Manager components that run on the Application Manager server andthe remote Agentless Adapters.

About this task

The command offers a graphical user interface to specify parameters, which arestored in various property files that are required by the System AutomationApplication Manager components. Most parameters that are configured with thiscommand control the behavior of the System Automation Application Managercomponents and do not need to be changed frequently.

In addition, the cfgeezdmn command is used to add or change user IDs andpasswords that are used to communicate with other automation domains andremote nodes.

The user ID you use to start the dialog must meet the following requirements:


v The user ID must be in same group as the user ID you used for installingSystem Automation Application Manager. The group permissions for thecfgeezdmn 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 settingsThe initial window of the configuration dialog is called task launcher and providesall configuration tasks.

The task launcher opens when you start the configuration dialog. For moreinformation, see “Starting the Application Manager configuration dialog” on page99.

More detailed information about all configuration tasks is available in the onlinehelp. To start the online help, click Help in the menu bar of the configurationdialog.

Application Manager tabUse the Application Manager tab for common configurations for the SystemAutomation Application Manager.

The Application Manager tab contains the following controls and fields:

Application Manager common configuration:

ConfigureClick Configure to open the Application Manager common settings dialog.

Figure 5. Application Manager tab of the Automation Manager Configuration dialog


You can specify configuration settings that are common for differentcomponents of System Automation Application Manager. For moreinformation, see “Configuring the Application Manager common settings”on page 105.

RefreshClick Refresh to update configuration settings of the active, runningApplication Manager application. For more information, see “Refreshingthe Application Manager common configuration” on page 114.

Non-clustered Nodes tabUse the Non-clustered Nodes tab to configure agentless adapters.

Controls and fields on the Non-clustered Nodes tab:

Local agentless adapter configuration:

Enable local agentless adapter configurationSelect this check box to enable the Local agentless adapter configurationwith 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 commonconfiguration.

v If you configure Application Manager high availability, thecorresponding resources are included into the Application Managerautomation policy. For more information about configuring highavailability of the Application Manager, see “High availability forSystem Automation Application Manager” on page 150.

The configuration dialog remembers the enable/disable status of the localagentless adapter configuration across multiple invocations.

Note: This check box applies only to the local agentless adapter, but not toany remote agentless adapter.

Figure 6. Non-clustered Nodes tab of the Automation Manager configuration dialog

Chapter 3. Configuring 101

ConfigureClick Configure in the Local Agentless Adapter configuration section ofthis tab to open the Application Manager agentless adapter configurationdialog. For more information, see “Configuring the local agentless adapter”on page 128.

Remote agentless adapter configuration:

ConfigureClick Configure in the Remote Agentless Adapter configuration section ofthis tab to open the Application Manager remote agentless adapterconfiguration dialog. For more information, see “Configuring remoteagentless adapters” on page 134.

Virtual Server / HW Management tabUse 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 page28.

Controls and fields on the Virtual Server / HW Management tab:

ConfigureClick Configure to open the hardware adapter configuration dialog. Usethis dialog to configure the hardware adapter host or the hardware accesscredentials that the hardware adapter uses or both. For more information,see “Configuring the hardware adapter” on page 139.

RefreshClick Refresh to trigger a reload of changed hardware access credentials

Figure 7. Virtual Server / HW Management tab of the Application Manager Configurationdialog


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 onor off the remote hardware systems and to test connectivity to thezEnterprise HMC. For more information, see “Testing the active hardwareadapter” on page 145.

Storage Replication tabUse the Storage Replication tab to configure the Tivoli Storage Productivity Centerfor 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 page28.

The Storage Replication tab contains the following controls and fields:

ConfigureClick Configure to open the TPC-R domain configuration dialog. Use thisdialog to configure the settings of the TPC-R domain and the usercredentials to access the corresponding TPC-R servers. For moreinformation, see “Configuring the TPC-R domain” on page 146.

RefreshClick Refresh to trigger a reload of the TPC-R domain settings by theactive, running Application Manager application. Refresh recycles anyactive session with a TPC-R server in order to pick up changed usercredentials. For more information, see “Refreshing the TPC-R domainsettings” on page 149.

Test Click Test to test the currently configured TPC-R domain properties. Formore information, see “Testing the TPC-R domain configuration” on page149.

High Availability tabUse the High Availability tab to configure the System Automation ApplicationManager high availability policy.

Figure 8. Storage Replication tab of the Application Manager Configuration dialog


Click a task button by enabling the Enable the high availability configurationtasks check box. The configuration dialog remembers the enable / disable status ofthe high availability configuration across multiple invocations.

The High Availability tab contains the following controls and fields:

ConfigureClick Configure on the High Availability tab of the task launcher windowto open the high availability policy configuration dialog. If you are runningon a Linux for System z® operating system platform, the Select ApplicationManager High-Availability Setup dialog opens. Select which type highavailability policy you want to configure. The dialog offers two options:1. “Configuring the high availability policy” on page 1532. “High availability for a disaster recovery setup on two sites” on page

168

ReplicateFor more information, see “Replicating the configuration files” on page160.

Set up domainFor more information, see “Setting up the domain” on page 161.

Remove domainFor more information, see “Removing the domain” on page 162.

Validate&Store policyFor more information, see “Validating and storing the automation policy”on page 162.

Define policyFor more information, see “Defining the automation policy” on page 163.

Remove policyFor more information, see “Removing the automation policy” on page 163.

Passwords Management tabUse the Passwords Management tab to change the passwords for any of the usercredentials that are defined in the System Automation Application Managerconfiguration.

Figure 9. High Availability tab of the Application Manager Configuration dialog


Use this tab as a shortcut to manage passwords rather than starting variousconfiguration tasks. Especially if you must change multiple or even all credentialsat the same time.

The table on this tab contains entries for all credentials that can be configured forSystem Automation Application Manager. The Change Passwords tab contains thefollowing controls and fields:

ComponentThis column shows all components that contain user credentials as part oftheir configuration. If multiple credentials can be configured for acomponent, one list entry shows the same component for each user ID.

User IDThis column shows the user IDs that are currently configured for therespective credentials. If <not configured> is shown, either the completecomponent is not configured or the corresponding credentials are currentlynot configured, because they are optional.

DescriptionThis column explains the purpose of the corresponding credentials.

Change passwordUse the Change password button to display a dialog that prompts you tospecify and confirm the new password for the selected user ID. Apassword change does not change any password on the affected system,but only in one of the configuration files. After you successfully changed apassword, the resulting message will indicate the updated configurationfile.

Configuring the Application Manager common settingsThe initial configuration of System Automation Application Manager is processedduring the installation of the product. To browse or change the properties, use theSystem Automation Application Manager configuration dialog or silentconfiguration. Do not manually edit the configuration properties files in which theconfiguration parameters are stored.

Figure 10. Change Passwords tab of the Application Manager Configuration dialog


About this task

The following topics describe the common configuration tabs of the SystemAutomation Application Manager configuration dialog. To open the configurationdialog, 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 forMultiplatforms 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 onthe Domain tab become effective, if the automation engine was restarted. Enter thecommands eezdmn -stop and eezdmn -start. If you are using the hardwareadapter of the Distributed Disaster Recovery feature, it must also be restarted byusing the commands eezhwadapter -stop and eezhwadapter -start.

Domain tabUse the Domain tab to configure the end-to-end automation domain and the hostwhere the end-to-end automation manager is running.

Controls and fields on the Domain tab:

Domain nameThe name of the end-to-end automation domain. The name in this fieldmust be the same as the XML element <AutomationDomainName> in each ofthe domain's automation policy files. Only the following ASCII characterscan be used for the domain name: A–Z, a-z, 0–9,. (period), and _(underscore). The maximum number of characters for a valid automationdomain name is 64.

Host name or IP addressName or IP address of the system that hosts the end-to-end automationmanager.

Alternate Host Click to configure an alternate end-to-end automation host, and follow theprocedure that is described in “Configuring an alternative end-to-endautomation host” on page 114.

WAS bootstrap port numberThe bootstrap port of the WebSphere Application Server instance that hoststhe end-to-end automation manager.

Command line request port numberThe port on which the automation engine receives command line interfacerequests.


Event port numberThe port on which the EIF message converter listens for events from thefirst-level automation domains. This port number must match the portnumber for the end-to-end automation manager host in all adapterconfigurations. You can configure the event port number for the end-to-endautomation manager host during the configuration of the automationadapters on first-level automation domains.

For the System Automation for z/OS adapter, the event port number is theevent port that is specified in the adapter configuration parametereif-send-to-port in the adapter plug-in properties file.

Policy poolThe fully qualified name of the directory that contains the XMLautomation policy files for the end-to-end automation domain. Onlyautomation policy files that are available in this directory can be activated.

Command Shell tabUse the Command Shell tab to configure authentication settings for using theApplication Manager command shell.

Controls and fields on the Command Shell tab:

User authentication for invoking the command shell: The end-to-end automationmanager requires authentication when a user starts the end-to-end automationmanager command shell by entering the eezcs command. By default, users arealways prompted for their user credentials. You have the choice between theseauthentication modes:

Read user credentials from stdinUsers must always specify their user credentials in the shell window byusing the -u and -p options.

Prompt for user authenticationUsers are always prompted for their credentials by an X11 dialog unlessthey specify them when they use the command shell.

Use specified user credentialsA shared user ID is used for authentication, which prevents users frombeing prompted for their credentials when they use the command shell.

Specify the shared user ID and the corresponding password in the fieldsUser ID and Password. Only the following ASCII characters can be usedfor 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 fordistributed disaster recovery with GDPS, specify the user credentialsindependent from the selected authentication mode. Correct authenticationis ensured when the hardware adapter internally uses the command shellin this setup.

User authentication for invoking commands against first-level automation (FLA)domains: If the command shell is used to run FLA domain commands, moreauthentication is required to access FLA domains. Choose between the followingauthentication modes:


Read FLA domain access credentials from stdinSpecify the FLA domain access credentials in the command shell windowby 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 ifcredentials are defined for the respective domain on the "User credentials"tab (see “User Credentials tab” on page 111).

Discovery Library Adapter tabUse the Discovery Library Adapter tab to configure the location where theDiscovery Library Adapter (DLA) stores IdML books. System AutomationApplication Manager provides a DLA to export the currently active SystemAutomation Application Manager resource topology to an Identity MarkupLanguage (IdML) discovery book.

Controls and fields on the Discovery Library Adapter tab:

IdML book directoryThe 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 ifyou select the local IdML book directory radio button.

Local/remote directorySelect whether the IdML book directory is on the computer where the DLAis running or on a remote system.

Local IdML book directoryThe IdML book directory is on the computer where the DLA isrunning.

Remote IdML book directoryThe IdML book directory is on a remote system.

HostnameThe host name of the remote system where the IdML book directory islocated. This field is only enabled if you select the Remote IdML bookdirectory radio button.

User IDThe logon user ID that is used by the DLA to store IdML books on theremote system. This field is only enabled if you select the Remote IdMLbook directory radio button.

PasswordThe logon password that is used by the DLA to store IdML books on theremote system. This field and the Change button are only enabled if youselect the remote IdML book directory radio button.

Click Change to change the password.

OSLC tabUse the OSLC tab to configure the settings to use the Open Services for LifecycleCollaboration (OSLC) services provided by System Automation ApplicationManager.

Controls and fields on the Event Publishing tab:


Enable resource registration using OSLC servicesSelect this check box if you want to use the Application Manager OSLCservices. If the check box is not selected, the other fields on this tab aredisabled.

Host name or IP addressThe host where the OSLC administration and registry server that is usedby the Application Manager is located.

Port numberThe port number used to communicate between the end-to-end automationmanagement server and the OSLC administration and registry server.

User IDThe user ID that is used to logon to the OSLC administration and registryserver.

PasswordThe password that is used to logon to the OSLC administration andregistry server. Click Change to change the password.

TruststoreThe name of the truststore file used for Secure Sockets Layer (SSL)communication with the OSLC server. Click Browse to select a file.

Truststore passwordThe password of the truststore file. Click Change to change the password.

Event Publishing tabUse the Event Publishing tab to configure settings to publish EIF events to TivoliNetcool/OMNIbus or to Geographically Dispersed Parallel Sysplex (GDPS).

Controls and fields on the Event Publishing tab:

OMNIbus event publishing

Enable OMNIbus EIF event publishingSelect this check box if you want EIF events to be sent to the host wherethe OMNIbus Probe for Tivoli EIF is running. If the check box is notselected, all fields for OMNIbus event publishing on this tab are disabled.

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

Event server

Host name or IP addressThe host name or IP address of the host where the OMNIbus Probe forTivoli EIF is running. You can specify up to eight values, which areseparated by commas. The first location is the primary event server. Allother locations are secondary servers that are used in the order that isspecified and when the primary server is down.

Port numberThe port number on which the OMNIbus Probe for Tivoli EIF is listeningto EIF events.

Event filter

Publish EIF events caused by:


Automation domain eventsSelect this check box if you want EIF events for Application Managerautomation domain events to be sent to the event server. Otherwise,domain events are filtered out.

Adding and removing requestsSelect this check box if you want EIF events for adding and removingrequests to be sent to the event server. Otherwise, events for adding andremoving requests are filtered out.

Resource status changesSelect this check box if you want EIF events that are related to resourcestatus changes to be sent to the event server. Otherwise, all resource statuschange events are filtered out. If you choose resource status change eventsto be published, select the status change severity for which events arepublished.

Defining more filters:

The event filters that you can enable or disable on this tab are the predefinedfilters that are included with System Automation Application Manager. If you wantto define more filters, modify manually the corresponding configuration propertiesfile:/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 apredefined filter, add a new filter and disable the predefined filter. If configurationchanges are applied by the cfgeezdmn configuration utility, any filters that youadded are preserved.

GDPS event publishing

Hardware management with GDPS is enabled

Note: If you have not enabled configuration of the hardware adapter fordistributed disaster recovery with GDPS, all fields to configure GDPS eventsettings are disabled.

Host name or IP addressIf you use the System Automation Application Manager hardware adapterto manage hardware for distributed disaster recovery with GDPS, definethe GDPS event server. Provide the host name or IP address of the GDPSevent server.

Port numberThe port number on which the GDPS event server is listening to EIFevents.

Enable a backup GDPS event server

Optionally, you can also configure a backup event server (Host name or IPaddress) and port. Select this check box if you want to configure a backupGDPS event server. Specify the backup server host name or IP address andport number in the entry fields that get enabled when you select the checkbox.

For more information about configuration of the hardware adapter for distributeddisaster recovery with GDPS, see “Configuring the hardware adapter” on page 139.


User Credentials tabUse the User Credentials tab to configure the user credentials of the end-to-endautomation manager. The automation manager uses these credentials toauthenticate itself. The characters that are used for all user IDs entered on this tabare limited to the following ASCII characters: A–Z, a-z, 0–9, and _ (underscore).

Controls and fields on the User Credentials tab:

Functional user IDThe end-to-end automation engine uses the functional user ID to access theautomation JEE framework that is running in WebSphere ApplicationServer. The automation JEE framework uses the same user ID to accessJMS and to run asynchronous tasks.

Functional passwordThe password for the functional user ID. Click Change to change thepassword.

Generic user IDThe user ID the automation manager uses to authenticate itself to afirst-level automation domain when no credentials are specified for thedomain in the Credentials for accessing specific FLA domains table.

Generic passwordThe password for the generic user ID. Click Change to change thepassword.

Credentials for accessing specific first-level automation domainsClick Add to specify a user ID that is valid for a specific domain. The userID is not required to be root, but to be authorized to run operations onresources in the first-level automation domain that are supported by theend-to-end automation manager. For example, bringing an automatedresource 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 isperformed on the system where the end-to-end automation adapter thatmanages the domain is running.

For more information, see Tivoli System Automation Application Manager,Administrator’s and User’s Guide.

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

TruststoreThe fully qualified file name of the truststore file that is used for SSL. ClickBrowse to select a file.

KeystoreThe fully qualified file name of the keystore file that is used for SSL. ClickBrowse to select a file.


Keystore passwordThe password of the keystore file. The password is required if a keystorefile was specified. Click Change to change the password.

Note: If the truststore is in a different file than the keystore, the passwordsfor the files must be identical.

Certificate aliasThe alias name of the certificate to be used by the server. The charactersthat are used for the certificate alias are limited to the following ASCIIcharacters: A – Z, a-z, 0–9, and _ (underscore).

Enforce use of SSL for all first-level automation domainsSelect this check box if you want to enforce that all first-level automationdomains are properly configured to use SSL at the transport layer. Then, allfirst-level automation domains can successfully connect to the end-to-endautomation manager. If not selected, first-level automation domains areconfigured 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 tabUse the Logger tab to configure message logging, tracing, and FFDC options fordifferent components of System Automation Application Manager.

The settings apply to the following components:v End-to-end automation enginev End-to-end automation manager command shellv Discovery library adapterv agentless adapter, if its configuration is enabledv 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 theproperties file. If the automation engine is not running on the system wherethis 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 settingsimmediately, click Apply and then Save.

3. Revert to the permanent settings.If you changed the settings temporarily, you can revert to the permanentsettings 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.


Result: The settings take effect immediately.

Controls and fields on the Logger tab:

Maximum log/trace file sizeThe maximum disk usage in KB that a log file can reach. If the limit isreached, another log file is created. The maximum number of log files istwo, which means that the least recent file gets overwritten after both filesare filled up. The default maximum file size is 1024 KB.

Message logging levelSelect the Message logging level, depending on the severity of messagesthat you want to be logged.

Trace logging levelSelect the Trace logging level, depending on the severity of the incidentsthat you want to be logged.

First failure data capture (FFDC) recording levelSelect the FFDC recording level, depending on the severity of the incidentsfor which you want FFDC data to be collected.

First failure data capture (FFDC) maximum disk spaceSpecify the maximum disk space in bytes used by FFDC traces, which arewritten to the FFDC trace directory. The default space is 10485760 bytes (10MB).

First failure data capture (FFDC) space exceeded policySelect one of the options:

Ignore Issue a warning, but do not enforce the FFDC disk spacelimitation.

Auto-deleteAutomatically delete FFDC files to enforce the FFDC disk spacelimitation. This is the default value of the space exceeded policy.

SuspendHalt further FFDC actions until disk space is freed manually.

First failure data capture (FFDC) message ID filter modeSelect one of the options:

PassthruAll log events with messages that are specified in the message IDlist will pass the filter and FFDC data is written. This is the defaultfilter mode.

Block All log events with messages that are specified in the message IDlist are blocked.

First failure data capture (FFDC) message ID listThe message IDs that control for which log events FFDC data is written,depending on the filter mode. The comparison of message IDs iscase-sensitive. Each message ID must occur in a new line. Wildcardcharacters, for example, *E for all error messages, are allowed.

Save the common configurationTo save your changes to the System Automation Application Manager commonconfiguration properties files, click Save on the configuration dialog. Uponcompletion, a configuration update status window is displayed, showing which


configuration files were updated. If errors occurred during the update, thecorresponding 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 forMultiplatforms cluster. For more information, see “Replicating the configurationfiles” on page 160).

Refreshing the Application Manager common configurationAbout this task

Click Refresh on the Application Manager tab of the configuration dialog tasklauncher to trigger configuration settings. The settings are reloaded by theend-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 AutomationApplication Manager common configuration.

v To clear the list of first-level automation domains that cannot be accessedanymore due to unrecoverable access errors. For more information, see TivoliSystem Automation Application Manager, Administrator’s and User’s Guide.

After you edited the System Automation Application Manager commonconfiguration, restart the automation engine by entering the commands eezdmn -stop and eezdmn -start.

Configuring System Automation Application Manager in silentmode

About this task

You can configure System Automation Application Manager in silent mode as analternative to using the configuration dialogs.

You can use the silent mode to perform the following configuration tasks:v Configuring Application Manager common settingsv Refreshing the Application Manager common configuration.

Refer to “Configuring in silent mode” on page 203 for a detailed description of thesilent mode configuration tasks.

Configuring an alternative end-to-end automation hostThe definition of an alternative end-to-end automation host is optional. If youwant to configure a disaster recovery setup by using two different sites for SystemAutomation Application Manager, the end-to-end automation manager can run oneither site. To enable such a setup, you must define the host of System AutomationApplication 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 hostingthe automation manager application on the alternative site. If you are running on aLinux for System z operating system, you can select to use GeographicallyDispersed Parallel Sysplex (GDPS) to control on which site the end-to-endautomation host is located. In this case, you must also select the GDPS site wherethe local and the alternative end-to-end automation hosts are located.


When you are configuring an alternative end-to-end automation host, proceed asfollows: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 youselected the alternative host to be on GDPS Site1, the local host is on GDPS site2 and vice versa.

3. Specify both the local and the alternative end-to-end automation host name onthe Host Using Adapter tab in the configuration of all end-to-end automationadapters. When an Application Manager site is switched, this setting ensuresthat the adapters smoothly switch to the new active end-to-end automationmanager instance as the target for sending events.

4. If there is an Application Manager site switch, there might be a relatively longperiod where end-to-end automation adapters cannot communicate with eitherend-to-end automation host. To ensure that adapters continue to contact theSystem Automation Application Manager, configure appropriate values forRemote contact activity interval and Initial contact retry interval. Specifythese values in the advanced settings in the configuration of all end-to-endautomation adapters, including all Agentless Adapters. Modify the advancedsettings by clicking Advanced on the Adapter tab in the adapter configurations.For information on these settings, see “Configuring high availability andcontact retry interval of all end-to-end automation adapters” on page 87.

Configuring an LDAP user registryConfigure 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 afederated repository. The WebSphere Application Server uses this registry for userauthentication and the retrieval of information about users and groups to runsecurity-related functions.

For more information about how to configure a federated user repository inWebSphere Application Server, see Managing the realm in a federated repositoryconfiguration.

Procedure for pre-defined LDAP setup

1. Install Jazz for Service Management including WebSphere ApplicationServer and Dashboard Application Services Hub (DASH).

2. LDAP configurationa. 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.


http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.iseries.doc/ae/twim_managing_realm.html

http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.iseries.doc/ae/twim_managing_realm.html

4. Optional: Configure the connection to the LDAP server for securecommunications. For more information, see Configuring an SSLconnection to an LDAP server.

Procedure for post-defined LDAP setup

1. Install Jazz for Service Management including WebSphere ApplicationServer 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 theWebSphere Application Server.

b. Configure the supported entity types so that new users and groupsare created in the LDAP user repository.

4. Port from a file-based repository to an LDAP repositorya. 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 securecommunications. For more information, see Configuring an SSLconnection to an LDAP server.

The core LDAP configuration is done in the same way for both pre-defined andpost-defined setup. This LDAP configuration is described in the next sections.

Adding the LDAP user registry as a federated repositoryFederated repositories can access and maintain user data in multiple repositories,and federate that data into a single federated repository. For example, use thedefault file-based repository and an LDAP repository that is combined under asingle realm.

Pre-requisites for this task:

Set up an LDAP server and create an LDAP user registry. Ensure that WebSphereApplication Server supports the LDAP user registry as a federated repository, forexample, IBM Tivoli Directory Server or Microsoft Active Directory Server.

Before you configure a central user registry, make sure that the user registry orregistries that you plan to identify are started. The user registry must be accessiblefrom the computer where you set up the Jazz for Service Management applicationserver.

Configuring an LDAP user repository

About this task

Configure the LDAP user repository by running the following steps:

Procedure1. Open your web browser and connect to the WebSphere administrative

console.2. Enter the WebSphere administrator user ID and password, and click Log in.


http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.3/com.ibm.psc.doc_1.1.0.3/config/psc_t_config_ssl_ldap.html




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. Forexample, LDAP1.

7. From the Directory type list, select the type of LDAP server. The type ofLDAP server determines the default filters that are used by WebSphereApplication Server. If you choose one of the predefined LDAP servers, you getdefault definitions for the mapping of entity types to corresponding objectclasses and for the attribute name that is used to determine groupmembership. If you choose Custom as directory type, you must specify thesedefinitions 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 theprimary LDAP server. The primary host name and the distinguished namemust contain no spaces. You can enter either the IP address or the domainname system (DNS) name.

9. In the Port field, enter the server port of the LDAP user registry. The defaultport 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 LDAPservers, 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 thebind distinguished name (DN) (for example, cn=root) and password. The bindDN is required for write operations or to obtain user and group information ifanonymous binds are not possible on the LDAP server. In most cases, a bindDN and bind password are needed, except when an anonymous bind cansatisfy all of the functions. Therefore, if the LDAP server is set up to useanonymous binds, leave these fields blank.

11. Optional: In the Login properties field, enter the property names used to login to the WebSphere Application Server. This field takes multiple loginproperties, delimited by a semicolon (;). For example, uid.

12. Optional: From the Certificate mapping list, select your preferred certificatemap mode. You can use the X.590 certificates for user authentication whenLDAP is selected as the repository. The Certificate mapping field is used toindicate whether to map the X.509 certificates to an LDAP directory user byEXACT_DN or CERTIFICATE_FILTER. If you select EXACT_DN, the DN in thecertificate must match the user entry in the LDAP server, including case andspaces.

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


servers, you must manually specify the object classes that are used in yourLDAP server for the entity types PersonAccount and Group. APersonAccount represents a user, whereas a Group represents a group ofusers.1. On the configuration page of your LDAP repository in the Additional

Properties area, click Federated repositories entity types to LDAPobject 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. Multipleobject classes are delimited by a semicolon (;). For example, enterPersonAccount in the Entity type field, and enter iNetOrgPerson in theObject classes field to define that LDAP entries that have the objectclass 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 objectclasses are delimited by a semicolon (;). For example, enter Group in theEntity type field, and enter groupOfNames in the Object classes field todefine that LDAP entries that have the object class groupOfNames aremapped to the Group entity type.


Define group membership attributeIf you chose Custom as directory type and not one of the predefined LDAPservers, you must manually configure how group membership is modeledin your LDAP server. Model the group membership in the Group attributedefinition 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, whichpoints to its members. The member attribute in this example iscalled the group member attribute. All LDAP serverimplementations 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 memberofattribute in this example is called the group membership attribute.Some LDAP servers support this kind of linking user objects to thegroups to which they belong, for example Microsoft® ActiveDirectory Server.

Use direct group membership if it is supported by the LDAPserver.

Configure the group membership depending on which group membershipdefinition is supported by your LDAP server:

Static group membership.If the group member attribute of the group is used, specify thename of the object class, and the attribute name that is used toindicate the group membership in Group attribute definition ->Member attributes. If the group objectclass for the user is


groupOfUniquePersons, and within that objectclass members arelisted as persons, then the static group Member attributes propertyis 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 togroupOfUniquePersons.


Direct group membership.If the group membership attribute in the PersonAccount entity isused, specify the group membership attribute in Group attributedefinition -> Name of group membership attribute. For example,if a PersonAccount entity (that is, a user) contains attributes calledingroup that contain each group membership, then you specify thedirect 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 tothe security realm

About this task

To add an already configured LDAP user repository as federated repository to thesecurity 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 Repositorylist.

b. In the field, enter the distinguished name (DN) of a base entry thatuniquely identifies this set of entries in the realm. This base entry mustuniquely identify the external repository in the realm.

Note: If multiple repositories are included in the realm, use the DN field todefine an extra distinguished name that uniquely identifies this set ofentries within the realm. For example, repositories LDAP1 and LDAP2might both use o=ibm,c=us as the base entry in the repository. Soo=ibm,c=us is used for LDAP1 and o=ibm2,c=us for LDAP2. The specifiedDN in this field maps to the LDAP DN of the base entry within therepository, such as o=ibm,c=us b. The base entry indicates the starting pointfor 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:


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 iscreated during installation of Jazz for Service Management is in the local fileregistry. If System Automation Application Manager is installed before the LDAPrepository is configured, also the users and groups that are generated during theinstallation are in the local file registry.

Configuring supported entity typesConfigure the supported entity types before you can create users and groups inyour 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 theseentities are created.

This configuration is also required if you install System Automation ApplicationManager after you configured an LDAP repository. The installer creates the defaultusers and user groups for you in the LDAP repository.

The supported entity types are Group, OrgContainer, and PersonAccount. A Groupentity represents a simple collection of entities that might not have any relationalcontext. An OrgContainer entity represents an organization, such as a company ora division. A PersonAccount entity represents a user that logs in. You cannot add ordelete 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 inthe repository where entities of this type are placed on write operations by userand group management.

6. Supply the relative distinguished name (RDN) properties for the specified entitytype in the Relative Distinguished Name properties field. Possible values arecn for Group, uid or cn for PersonAccount, and o, ou, dc, and cn forOrgContainer. Delimit multiple properties for the OrgContainer entity with asemicolon (;).

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 theUsers and Groups > Manage Users menu item.


Note: When you add a user, check that the user ID you specify does not exist inany of the user repositories. You can avoid difficulties when the new user attemptsto log in.

What to do next:

Pre-defined setup:

The LDAP repository is configured and connected to the WebSphereApplication Server. Next, install System Automation Application Manager.

On the User and Group Administration page of the installer click Yes. Thedefault users and groups for System Automation Application Manager arecreated in your configured LDAP user repository. If you already createdthe default user groups and users for System Automation ApplicationManager in the LDAP repository through a previous installation or byadding them manually, click No. In this case, the installer does not makechanges to users and groups.

Post-defined setup:

If you already installed System Automation Application Manager and youdid not define the default users and groups for System AutomationApplication Manager in the LDAP repository, create these users andgroups in your LDAP repository as the next step. Assign roles to the newLDAP groups and remove the old groups that are no longer used from thefile-based repository.

These steps are explained in “Porting from a file-based repository to anLDAP repository in a post-defined setup.”

Porting from a file-based repository to an LDAP repository ina post-defined setup

If you configured WebSphere Application Server to use an LDAP repository afteryou installed System Automation Application Manager, complete extra steps toport from a file-based repository to an LDAP user repository.

Run the following steps to port the users, groups, and roles that are created duringthe installation of System Automation Application Manager to an LDAP-basedconfiguration: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 DashboardApplication Services Hub” on page 124.

3. Remove duplicate users from the file-based user repository. For moreinformation, see “Removing duplicate users from the file-based user repository”on page 126.

Creating default users and groupsSystem Automation Application Manager requires a set of default users andgroups. These users and groups are created during the installation of SystemAutomation Application Manager.


About this task

If you configured a new LDAP user repository after System AutomationApplication Manager is installed, the default users and groups are created in thelocal file-based user repository by the installer. In this case, manually create thedefault users and groups also in the LDAP repository and later delete the olddefinitions from the file-based repository.

During installation, users and groups are created and mapped to a group roleautomatically. Table 1 lists these user IDs and user groups and shows to whichgroup 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'sand User's Guide.

The following steps describe how to set up the default users (for exampleeezadmin), and groups (for example EEZAdministratorGroup) in the LDAPrepository. If you choose to use different names for users and groups, adjust thedescribed steps.

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


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 sharedacross multiple System Automation Application Manager installations, the usersand groups must only be created once and can then be used by all SystemAutomation Application Manager installations that are configured for this LDAPrepository.

What to do nextv 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 theEEZEAR application.”

v Next, assign roles to these groups, so that users that belong to a group have theexpected access rights to work with System Automation dashboards in theDashboard Application Services Hub, see “Authorizing LDAP groups within theDashboard 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 bythe System Automation Application Manager must be adjusted to the groupnames. If your LDAP user repository uses the default group names, no furtheraction is required.

Procedure1. 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 * tosee all available groups.

7. Select the appropriate group and move it to the Selected list by using thearrow button >>.

8. Remove the groups that you don't use. Otherwise, errors can occur in theWebSphere logs.


9. Save the settings to the master configuration and restart the WebSphereApplication Server.

Adapting installation variablesIf you ported from a file-based user repository to a central LDAP user repositorythat is shared by multiple System Automation Application Manager installations,adapt an installation variable that defines whether a local or an external userrepository is used. Otherwise, a later uninstallation of this System AutomationApplication Manager installation deletes the default users and groups from theLDAP repository.

About this task

To adapt the installation variables, apply the following change:

Procedure

Change the variable EXTERNAL_USER_REP_ACTIVATE in file <EEZ_INSTALL_ROOT>/uninstall/installvariables.properties to false:EXTERNAL_USER_REP_ACTIVATE=false.

Results

Prevents that in a later uninstallation process the default users, and groups aredeleted from the LDAP user repository.

Authorizing LDAP groups within the Dashboard ApplicationServices Hub

About this task

Users must have specific roles to work with dashboards that are available in theDashboard Application Services Hub (DASH). This role assignment is configuredin the DASH. Assign the required roles on the user group level, so that all usersthat belong to a group inherit the same roles.

Roles are assigned to user groups and users during the installation of SystemAutomation Application Manager.

If you configured a new LDAP user repository after System AutomationApplication Manager is installed (see post-defined setup), assign the expected rolesto the groups and users that are available in the LDAP repository. At the time ofthe installation of System Automation Application Manager, the roles are assignedto 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


The iscadmins role is assigned to the default System Automation administrator (forexample eezadmin) and to the default WebSphere administrative user (for examplewasadmin):

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, seeSystem Automation Application ManagerReference and Problem Determination Guide.

Procedure1. Log in to the Dashboard Application Services Hub by using the WebSphere

administrative user that you specified during installation of Jazz for ServiceManagement (for example wasadmin). This user is in the file-based repositoryand 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 andgroups to which the EEZAdministrator role is assigned. If you configuredLDAP after System Automation Application Manager is installed (post-definedsetup), the Groups table displays the following entry:cn=EEZAdministratorGroup,o=defaultWIMFileBasedRealm This defaultconfiguration is made by the installer that assigns the EEZAdministrator role tothe EEZAdministratorGroup that is created in the file-based user repository.

4. Click + (Add Group) in the toolbar of the Groups table to add thecorresponding EEZAdministratorGroup that exists in the LDAP repository. TheAvailable Groups window opens.

5. Enter EEZ* in the Group ID field and click Search to list all groups that beginwith EEZ from the configured federated repositories. The results table lists allEEZ* groups from both the file-based repository and the LDAP repository.

6. Select the EEZAdministratorGroup that is defined in LDAP and click Add andthen Save.

Note: Ensure that you select the group that is defined in LDAP and not theone with the same name that still exists in the file-based repository byexamining the distinguished name. If you use other group names in LDAP thanyou previously used in the file-based repository, you can also assign theEEZ-roles to groups named differently. In this case also adjust the groupconfiguration 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 listedin the table.

8. Finally, assign the iscadmins role to either one of your LDAP groups or toindividual LDAP users. For example, if you want all your EEZAdministratorusers to modify existing dashboards or define new dashboards in the DASH,assign the iscadmins role to the LDAP-based EEZAdministratorGroup.


Removing duplicate users from the file-based user repositoryAbout this task

During the porting from a file-based user repository to an LDAP-based userrepository, you might have users and groups that have the same name in bothrepositories. This setting leads to problems when you try to log on with one of theusers that exists in both user repositories.

For example, if the functional user id used by the System Automation ApplicationManager (default: eezdmn) is in the file-based and in the LDAP repository, theEEZEAR application does not start. This prevents the EEZEAR application from beingstarted.

Therefore, you must remove the old System Automation users and groups from thefile-based repository.

Procedure1. 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=defaultWIMFileBasedRealmb. 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 theselected groups from the file-based repository.

8. Restart WebSphere Application Server and verify that you can log on with yourLDAP users into the DASH. See the dashboards for which they are enabledaccording to their role and group assignments. Also, verify that you can stilllog in to the WebSphere Application Server administrative console by usingyour administrative user. The administrative user (for example wasadmin bydefault) is still in the file-based repository.


Results

You now ported the default groups and users that are used by System AutomationApplication Manager to an LDAP user repository. You can continue to createfurther 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 anWebSphere administrative user. Assign the following administrative roles to any ofyour LDAP users by using the WebSphere Application Server administrativeconsole:1. Admin Security Manager2. Administrator3. ISC Admins

Go to Users and Groups > Administrative user roles to assign these roles to anew user.

Configuring access to non-clustered nodesUse the agentless adapter to access and integrate non-clustered nodes into anend-to-end automation environment.

Configure and use either the local agentless adapter or one or multiple remoteAgentless Adapters or a combination of both.

Configure the local and remote Agentless Adapters on the system where theSystem Automation Application Manager server is installed. Enter the cfgeezdmncommand to open the configuration utility. After the configuration for one instanceof the remote agentless adapter is completed, this configuration must bedistributed to the corresponding adapter host.

The topic Figure 11 on page 128 displays how configurations for AgentlessAdapters are maintained. Enter the cfgeezdmn command to open the configurationutility.


Configuring the local agentless adapterThe System Automation Application Manager local agentless adapter configurationdialog helps you to configure the local agentless adapter settings.

To open the configuration dialog, click Configure in the Local Agentless Adapterconfiguration section on the Non-Clustered Nodes tab of the task launcherwindow

Adapter tabUse the Adapter tab to configure the parameters of the host system on which theadapter is running and the parameters that are required for the agentless adapterpolicy.

Controls and fields on the Adapter tab:

Request port numberSpecify the number of the port on which the agentless adapter listens forrequests from the end-to-end management host. The default port is 2005. Ifyou configured the hardware adapter, make sure that the port numbers ofthe agentless adapter and the hardware adapter are different.

Policy pool locationSpecify the qualified path name of the directory that contains the agentless

System Automation Application Manager

remote.client2

cfgeezdmn configuration utility

Configuration files- Agentless Adapter- Remote clients- remote.client1- remote.client2

LocalAgentless Adapter

RemoteAgentless Adapter

Configuration files- Agentless Adapter

read

remote.client1

RemoteAgentless Adapter

Configuration files- Agentless Adapter

read

ALADomain3

ALADomain4

ALADomain5

ALADomain6

ALADomain7

ALADomain1

ALADomain2

read

distributedistribute

Figure 11. Maintaining configurations for multiple Agentless Adapters


adapter policies. These policies define resources on non-clustered nodes.The resources are managed by the agentless adapter. Click Browse to selecta directory.

Automation domain listThe table lists automation domain names. Each domain represents a set ofresources on nodes that are not clustered and managed by the agentlessadapter. A domain name must match the domain name value that isdefined in the policy file. This policy file defines the corresponding set ofresources.

Add, Remove or Rename domainsTo change the list of domains, click the corresponding tasks:

Add Click Add to open a dialog. Specify the domain name that youwant to add to the list.

RemoveSelect a domain from the list and click Remove.

RenameSelect the domain name that you want to rename and clickRename. A dialog opens. Enter the new name.

Click Advanced. A dialog opens to specify the adapter runtime behavior:

Adapter stop delayDefines the time that is measured in seconds within which the adapterstop is delayed to allow the adapter to properly deliver the domain leaveevent. The default value is 5. You can increase the value on slow systems.The value ranges between 3 through 60 seconds.

Remote contact activity intervalDefines the time after which the automation adapter stops if there is nocommunication with the end-to-end automation management host. Settingthis parameter to 0 means that the adapter continues to run and neverstops. The default value is 360 seconds. If you configured ApplicationManager high availability, you might specify a value greater than 0. In thiscase, the adapter is part of the high availability policy and it is restartedautomatically. The adapter contacts the end-to-end automationmanagement host again, with the value that is specified in the Initialcontact retry interval parameter.

If your adapter is not configured for high availability, specify 0 so that theadapter waits until it is contacted again by the end-to-end automationmanagement host.

Initial contact retry intervalDefines the time that is measured in minutes, within which the adapterattempts to contact the end-to-end automation management host until itsucceeds or the specified time elapses. The default value is 0, where 0means the adapter attempts to contact the end-to-end automationmanagement host indefinitely. The value range is 0 - 1440 minutes.

Enable EIF event cachingSelect this check box to activate event caching.

EIF reconnect attempt intervalDefines the time that the adapter waits before it attempts to reestablish the


connection to the end-to-end automation management host after theconnection is interrupted. The default value is 30 seconds. The valueranges 1 - 3600 seconds.

User Credentials tabUse the User Credentials tab to configure credentials of the agentless adapter.These credentials are used to access remote nodes, which host remote resourcesthat are managed by the agentless adapter.

These credentials are not required for IBM Tivoli Monitoring resources that aremanaged by the agentless adapter. Credentials for IBM Tivoli Monitoring resourcesare configured on the Tivoli Monitoring tab. For details about how to configurethese 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 accessremote nodes, which host resources that are managed by the agentless adapter. Formore information, see “Securing the connection to end-to-end adapters using SSL”on page 300.

Generic user IDEnter a generic user ID to access all non-clustered nodes for which nospecific credentials are defined in the list Credentials for accessing specificnon-clustered nodes. Generic credentials are optional. If you want toremove already configured generic credentials, leave the user ID fieldempty.

Generic passwordEnter your password for the generic user ID. Click Change to change thepassword.

Credentials for accessing specific non-clustered nodesDefine user credentials for each non-clustered node for which the genericcredentials do not apply. The list shows all currently defined usercredentials and their related node names.

Add Click Add to define a new user ID and password to access remotenodes. More than one user credential per node is allowed.

RemoveTo remove an entry from the list, select a user ID and clickRemove.

ModifyTo edit the node name, user ID, or password, select an entry fromthe list and click Modify.

Note:

1. If an IPv6 host name is specified as node name, the DNS server mustbe configured to return IPv6 records only.

2. If the DNS server is configured to return IPv4 and IPv6 records, onlythe IPv4 address is used. In case you want to use IPv6, explicitlyspecify the IPv6 address as node name instead of the host name.

Use the tools that are provided by the operating system to check the DNSlockup records. For example, on Linux use the command host -a <ipv6_hostname> to check the DNS lookuprecords.


You can decide to use SSH public and private keys for user authentication betweenthe agentless adapter and remote non-clustered nodes on the Security tab. In thiscase do not define specific credentials for any pair of node name and user ID forwhich you want to use the SSH key authentication approach.

Tivoli Monitoring tabUse the Tivoli Monitoring tab to configure the integration of Tivoli Monitoring andIBM Tivoli Composite Application Manager (ITCAM) resources by definingsettings and credentials to access the Tivoli Monitoring SOAP Server.

Controls and fields on the Monitoring tab:

Enable integration of ITM/ITCAM resourcesSelect this check box if you want to integrate ITM/ITCAM resources in apolicy 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 addressSpecify the name or the IP address of the host where the hub monitoringserver that hosts the SOAP service is running.

SOAP server port numberSpecify service point port number of the SOAP server hosted by the hubmonitoring server. The default number for a non-SSL port is 1920. Thedefault number for an SSL port is 3361. You must specify the number of anSSL port if you selected the check box to use Secure Socket Layer (SSL) forcommunication with the SOAP server.

SOAP alias of hubSpecify the alias name of the hub monitoring server to which a SOAPrequest is routed. The request is routed to the hub monitoring server,which is on the same system as the SOAP server. In this configuration, youmust specify SOAP as the alias. If you want to route the SOAP request to aremote hub, specify the alias name of this remote hub. This alias must bepreviously defined to the SOAP server in the ITM/ITCAM SOAP serverconfiguration.

Use SSL for communication with the SOAP serverSelect 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 portnumber 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 anagentless adapter policy the user credentials. You can define the user credentials inthe list of specific credentials for accessing the SOAP server. When no user ID forthe ITM/ITCAM resources is specified in the policy, the generic user credentialsare used.

Generic user IDSpecify the generic user ID that is used to access the ITM/ITCAMresources 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 agentlessadapter policies, this field is not used.


Generic PasswordSpecify the password of the generic user ID. This field is mandatory only ifyou supplied a generic user ID. Click Change to change the password.

Specific credentials for accessing the Tivoli Monitoring SOAP serverDefine each user ID that you specified for an ITM/ITCAM resource in anagentless adapter policy. Use the following tasks:

Add Click Add to define a new user ID and password to access theSOAP Server.

RemoveTo remove an entry from the list, select a user ID and clickRemove.

ModifyTo edit the user ID or password, select an entry from the list andclick Modify.

Note: You can define the SOAP server security setup to accept a user ID with anempty password. For example, if you want to use the agentless adapter in a testenvironment, you can specify the user ID for the corresponding ITM/ITCAMresource in the agentless adapter policy. It is not required to define the user ID inthe list of specific credentials to access the SOAP server. In this case, the agentlessadapter attempts to access the ITM/ITCAM resource with the user ID defined inthe policy and an empty password.

Security tabUse the Security tab to configure the settings for user authentication and securedata transport.

You can configure the following settings:

Secure Sockets Layer (SSL) for data transportConfigure SSL for data transport between the agentless adapter and theautomation manager host. If you configured Application Manager highavailability, the end-to-end automation manager and the agentless adapterrun on different systems. In this case, you might want to configure thecorresponding SSL settings to secure the data transport between thosesystems.

Usage of the Pluggable Access Module (PAM) for user authenticationConfigure user authentication between the automation manager and theagentless adapter with the Pluggable Access Module (PAM).

User authentication with SSH public and private keysConfigure user authentication between the agentless adapter and remotenon-clustered nodes with SSH public and private keys. This authenticationmethod applies only to remote resources, which are accessed by using aremote execution protocol. It does not apply to IBM Tivoli Monitoringresources defined in the agentless adapter policy because for IBM TivoliMonitoring resources an existing IBM Tivoli Monitoring securityinfrastructure is reused. The user ID that you specify for a remote resourcein an agentless adapter policy is used to authenticate on the remote nodewhere the resource is located. The agentless adapter separatelyauthenticates each user ID that is specified for a remote resource in theagentless adapter policy. The adapter authenticates those users on remotenodes in the following sequence:


1. The user ID that is specified for a remote resource in the agentlessadapter automation policy is defined in the Credentials for accessingspecific non-clustered nodes list on the User Credentials tab: Theagentless adapter uses the password that is associated with that specificuser ID.

2. The user ID that is specified for a remote resource in the agentlessadapter automation policy is defined as Generic user ID fornon-clustered nodes on the User Credentials tab: The agentlessadapter 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 agentlessadapter policy, user authentication is processed by using SSH publicand private keys. In this case, check Enable user authentication withSSH public and private keys and specify the SSH private key file andpassphrase.


Configure Secure Sockets Layer for transport:

Enable SSL for data transport between the automation manager and theagentless adapter

Check this check box to enable the Secure Sockets Layer (SSL) protocol. Formore information, see “Securing the connection to end-to-end adaptersusing SSL” on page 300. The following fields are enabled:

TruststoreEnter the fully qualified name of the truststore file that is used for SSL.Click Browse to select a file.

KeystoreEnter the fully qualified name of the keystore file that is used for SSL.Click Browse to select a file.

Keystore passwordEnter the password for the keystore file. The password is required if akeystore file was specified. Click Change to change the password.

Note: Passwords must be identical if truststore and keystore are in twodifferent files.

Certificate aliasEnter the alias name of the certificate that is used by the server. If notspecified, the keystore file must contain only one entry, which is the one tobe used.

Configure user authentication between the Automation Manager and the agentlessadapter with the Pluggable Access Module (PAM).

Enforce user authentication between the automation manager and the agentlessadapter

Click the check box to enable user authentication with Pluggable AccessModule (PAM). If not checked, user authentication is bypassed.

PAM serviceThe value of the PAM service depends on the operating system on whichthe agentless adapter runs:v For SUSE Linux distributions, specify a file in the directory /etc/pam


v For Red Hat Enterprise Linux distributions, specify an entry in the filepam.d

v For AIX, specify an entry in the file /etc/pam.conf

The PAM service determines which checks are made to process userauthentication. Examples for PAM service names are sshd for Linux, orlogin for AIX. You might also use any other value that is defined as aPAM service.

Configure security for the communication between the agentless adapter andremote non-clustered nodes.

Enable user authentication with SSH public and private keysCheck this check box to use SSH keys for authentication. Use SSH keys foruser IDs that have no generic or specific access credentials that are definedon the User Credentials tab.

SSH private key fileEnter the fully qualified name of the SSH private key file that is generatedby the ssh-keygen utility. The default names of files that are generated byssh-keygen are id_dsa or id_rsa. Ensure that the user ID under which theagentless adapter is running has read access for this file. Click Browse toselect a file.

SSH private key fileEnter the fully qualified name of the SSH private key file that is generatedby the ssh-keygen utility. The default names of files that are generated byssh-keygen are id_dsa or id_rsa. Ensure that the user ID under which theagentless adapter is running has read access for this file. Click Browse toselect a file.

Private key passphraseEnter the passphrase that you used to generate the SSH private key filewith the ssh-keygen utility. Click Change to change the passphrase. Thepassphrase is optional because you can omit the passphrase when you usethe ssh-keygen utility. Click Change to remove a passphrase. Leave allentry fields in the dialog empty and select OK.

Saving the local agentless adapter configurationTo save your changes to the System Automation Application Manager agentlessadapter configuration properties files, click Save on the configuration dialog. Uponcompletion, a configuration update status window is displayed, showing whichconfiguration files are updated. If errors occurred during the update, thecorresponding 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 forMultiplatforms cluster. For more information, see “Replicating the configurationfiles” on page 160.

Configuring remote agentless adaptersConfigure remote System Automation Application Manager settings.

To open the configuration dialog, click Configure in the Remote agentless adapterconfiguration section on the Non-clustered Nodes tab of the task launcherwindow.


Use the remote System Automation Application Manager configuration window tomaintain the configurations for one or multiple remote System AutomationApplication Manager instances.

The list of remote System Automation Application Manager configurations showsone entry for each currently configured remote System Automation ApplicationManager instance:

Remote agentless adapter HostThe host name of the node where the remote System AutomationApplication Manager is installed.

Configuration Directory

v UNIX: If the remote System Automation Application Manager isinstalled on a UNIX system, the configuration directory is/etc/opt/IBM/tsamp/eez/rala/cfg.

v Windows: If the remote System Automation Application Manager isinstalled on a Windows system, the configuration directory is<INSTALL_ROOT>\cfg. <INSTALL_ROOT> is the directory that youspecified during the installation of the System Automation ApplicationManager on the Windows system.

Configuration completeThe configuration complete value indicates whether the configuration forthe corresponding remote System Automation Application Managerinstance 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 AutomationApplication Manager instance. A dialog opens to specify the remote node name ofthe host and select whether the remote host is a Windows system or not. For aWindows system, specify also the configuration directory. After you completed thedialog, the new configuration is added to the list with the configuration completevalue "No".

Click Remove to remove the selected configuration from the list. All configurationfiles related to that configuration are deleted on the system where theconfiguration utility runs. If you distributed the configuration already, theconfiguration 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 aremostly the same as described in “Configuring the local agentless adapter” on page128. Below you can find the description of tabs or fields that are unique for a


remote agentless adapter configuration. To open the configuration dialog, select theentry that you want to configure and click Configure in the remote agentlessadapter configuration window.

Post-configuration tasks

Distribute the remote agentless adapter configuration to the corresponding remoteagentless adapter host. For more information, see “Distributing a remote agentlessadapter configuration” on page 138. If System Automation Application Manager isconfigured for high availability, replicate the configuration files to the highavailability 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 thesemantics of the fields on the tab. Two controls are different than the Adapter tabfor the local agentless adapter:

Host name or IP addressHost name or IP address of the node where the adapter runs. The defaultvalue is the remote agentless adapter host name that you specified for thisadapter instance in the remote agentless adapter configuration window. Ifyou want to change this value, for example to an IP address, make surethat the new value refers to the host where this adapter instance isinstalled.

Request port numberThe disclaimer regarding the hardware adapter does not apply to remoteAgentless Adapterss.

User Credentials tab

Refer to “User Credentials tab” on page 130 for a description of this tab contentand 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 contentand 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 thesemantics of the fields on the tab. The only difference between the Security tab forthe local and remote agentless adapter is the motivation to configure SSL for datatransport between the automation manager and the agentless adapter. Theend-to-end automation manager and the local agentless adapter run on differentsystems only if you configured Application Manager high availability. Remoteagentless adapters always run on different systems.

Logger tab

The Logger tab is only available for remote agentless adapters. The local agentlessadapter uses the logger settings that are defined in the Application Managercommon configuration.


Use the Logger tab to specify the settings for logging, tracing, and First FailureData Capture. You can change the settings permanently or temporarily.

Note: The Logger tab always displays the values that are currently set in theconfiguration file.Controls and fields on the Logger tab:








Auto-deleteAutomatically delete FFDC files to enforce the FFDC disk spacelimitation. This is the default space exceeded policy.





First failure data capture (FFDC) message ID listThe message IDs that control for which log events FFDC data is written,depending on the filter mode. The comparison of message IDs iscase-sensitive. Each message ID must occur in a new line. Wildcardcharacters, for example, *E (for all error messages), are allowed.


Saving the remote agentless adapter configuration

To save your changes to the System Automation Application Manager remoteagentless adapter configuration properties files, click Save in the configurationdialog. Upon completion, a configuration update status window is displayed,showing which configuration files were updated. If errors occurred during theupdate, the corresponding error messages are also displayed.

Note: The configuration files are in a subdirectory of the standard configurationdirectory. The name of the subdirectory is the remote agentless adapter host namethat you specified for this adapter instance in the remote agentless adapterconfiguration window.

Distributing a remote agentless adapter configurationUse the remote agentless adapter configuration distribution dialog to distribute theconfiguration files for a remote instance to the remote host where that adapterinstance is installed.

To open the configuration distribution dialog, select the entry that you want todistribute and click Distribute in the remote agentless adapter configurationwindow. Provide the following input in the Remote agentless adapterconfiguration distribution dialog

Remote host login user ID and passwordThe credentials that are used to access the remote agentless adapter host.The specified user ID must have write access to the configuration directoryon the remote host that you defined for this configuration.

Recycle remote agentless adapter after configuration distributionCheck whether you want the agentless adapter to be stopped and restartedon the remote host after the configuration distribution ran. Then, theremote agentless adapter runs with the changed configuration values. Theremote agentless adapter is recycled only if the distribution of allconfiguration files is completed successfully and if the adapter is running.

Click OK to distribute the configuration. Upon completion, the Configurationdistribution status window opens to show the list of configuration files that aredistributed. If you selected Recycle the remote agentless adapter afterconfiguration distribution, you are informed about the result of the recycleattempt and the status of the adapter on the remote host.

Controlling Agentless AdaptersUse the eezaladapter command to start, stop, and monitor Agentless Adapters. Tocontrol the local agentless adapter, run the command on the Application Managerserver system. To control the remote Agentless Adapters, run the command on therespective remote host.

For more information about the eezaladapter command, see Tivoli SystemAutomation Application Manager, Reference and Problem Determination Guide.

Configuring agentless adapters in silent modeYou can configure agentless adapters in silent mode as an alternative to using theconfiguration dialogs.


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.


Tuning the number of domains and resources of agentlessadapters

The amount of resources that can be managed by agentless adapters withoutperformance degradation depends on the hardware. Your performance dependsespecially on processor power and CPU cycles, that are available on the systemwhere agentless adapters run. Make sure that CPU and memory utilization is nothigher than 80% after policy activation.

Depending on your hardware capabilities, the numbers that are given in thefollowing recommendations may vary slightly. Adhering to those recommendationsprovides 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:


For each agentless adapter instance (local and remote), balance the number ofresources per domain by including a similar number of resources in each domain.

Configuring virtual server & hardware management

Configuring the hardware adapterConfigure the hardware adapter to access the zEnterprise Hardware ManagementConsole (HMC) or to manage hardware for distributed disaster recovery withGeographically Dispersed Parallel Sysplex™ (GDPS®).

About this task

To open the configuration dialog, click Configure on the Virtual Server/HWManagement 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.


3. Configuring the hardware adapter to manage hardware for distributed disasterrecovery 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 adapterconfiguration section on the High Availability tab of the task launcher window.


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 accesscredentials. Start the Refresh task in the hardware adapter section of the VirtualServer / HW Management tab of the task launcher. For more information, see“Refreshing the active hardware adapter configuration” on page 145. If youconfigured the hardware adapter to access the zEnterprise HMC for virtualserver management, reconnect to the HMC by starting the Refresh task. In bothcases, you can alternatively restart the hardware adapter by using the followingcommands:eezhwadapter -stop

Stop the adapter, andeezhwadapter -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 adaptersection 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 forMultiplatforms cluster that provides the high availability. For more information,see “Replicating the configuration files” on page 160.

Adapter tabUse the Adapter tab to configure the settings of the host where the hardwareadapter is running. This is the same host system on which the WebSphereApplication Server that hosts the end-to-end automation manager is located. Thusyou do not need to explicitly specify a host name or IP address on this tab.

Field on the Adapter tab:

Request port numberSpecify the number of the port to which the hardware adapter listens forrequests from the end-to-end management host. The default port is 2003.

zEnterprise HMC Access tabUse the zEnterprise HMC Access tab to configure the hardware adapter to accessthe zEnterprise Hardware Management Console (HMC) for virtual servermanagement.

Controls and fields on the zEnterprise HMC Access tab:


Manage virtual servers using the zEnterprise HMC Select this check box if you want to use the hardware adapter to managevirtual servers by using the zEnterprise HMC.

If you select this check box, the actions that are related to connecting to thezEnterprise HMC will be performed when you start the Test tasks in thehardware adapter section on the Virtual Server / HW Management tab ofthe task launcher.

If this check box is not selected, the refresh and test actions that establishthe connection to the zEnterprise HMC are not performed and all dialogelements on this pane are disabled.

Configure settings of the zEnterprise HMC:

Domain nameThe name of the zEnterprise HMC domain. The name that you specify inthis field must be unique in the set of all automation domains you areworking with.

HMC host name or IP addressThe host name (short name or fully qualified name) or the IP address (IPversion 4 or IP version 6) of the host where the zEnterprise HMC server isinstalled.

Configure functional user credentials to access the zEnterprise HMC:

The functional user credentials are used by the automation JEE framework toaccess the zEnterprise HMC server through the hardware adapter. If you select oneof the Use functional user credentials for authentication buttons, these credentialsare also used for each user request to access the zEnterprise HMC through thehardware adapter.

Functional user IDSpecify the functional user ID for the automation JEE framework.

Functional passwordSpecify the password of the functional user ID for the automation JEEframework. Click Change to change the current password.

Configure the mode of authentication for accessing the zEnterprise HMC:

Enforce user authentication for all user interfacesIf you select this button, credentials must be available or explicitly definedfor each user who wants access to the zEnterprise HMC through thehardware adapter. This applies for all user interfaces that support access tothe zEnterprise HMC through the hardware adapter.

Use functional user credentials for authentication in command shell, enforceuser authentication for all user interfaces

If you select this button, credentials of the functional user ID describedabove are used by the JEE automation framework and for each userrequest to access the zEnterprise HMC through the hardware adapterusing the eezcs command. Credentials must be available or explicitlydefined for each user who wants to access the zEnterprise HMC throughany other user interface, for example, the operations console.

Use functional user credentials for authentication for all other user interfacesIf you select this button, credentials of the functional user ID describedabove are used by the JEE automation framework and for each user


request to access the zEnterprise HMC through the hardware adapter. Thisapplies for all user interfaces that support access to the zEnterprise HMCthrough the hardware adapter.

Configure Secure Sockets Layer (SSL) for communication with the zEnterpriseHMC:

TruststoreSpecify the name of the truststore file that is used for SSL. Click Browse toselect the truststore file.

Truststore passwordSpecify the password of the truststore file. Click Change to change thecurrent password.

Note: The steps for creating a truststore and importing the zHMC certificate aredescribed in “zEnterprise Hardware Management Console” on page 283.

DR Hardware Credentials tabUse the DR Hardware Credentials tab to configure the hardware access credentialsthat 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 hardwarefor distributed disaster recovery with GDPS. The actions that are related tothe configured hardware access credentials are processed when you startthe Refresh or Test tasks. These tasks are in the hardware adapter sectionon the Virtual Server / HW Management tab of the task launcher.

If you do not select this check box, theRefresh or Test actions are notprocessed and all controls to modifying the contents of the hardware listson this pane are disabled.

Note: The configuration of hardware access credentials is available only ona subset of the supported operating systems for the hardware adapter. Ifyou run the configuration on an operating system that is not supported bythis configuration task, the check box is disabled.

Configured hardware access credentialsThis list shows all the hardware entities for which you currently definedcredentials that are used by the hardware adapter to access those hardwareunits.

A dash (" - ") in the Slot column indicates the hardware box itself.

Each hardware unit that is defined in a disaster recovery policy must alsobe specified in the credentials list. However, you can decide to explicitlyomit the actual credentials for selected hardware units. In this case, theuser 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 recoverypolicies, but do not yet have credentials that are defined.

Use the Add button to display the Add Hardware Access Credentialsdialog. Add a hardware unit with its credentials to the list of hardwareaccess credentials. For more information, see “Adding credentials” on page143.


Use the Remove button to remove the selected hardware unit from the listof hardware access credentials. Remove only hardware units that are notdefined in any disaster recovery policy.

Use the Change button to display the Change Hardware AccessCredentials dialog that to change the user ID and password for theselected 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 yetbeen 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 definecredentials. If the hardware box does not contain any slots or you want todefine credentials just to access the box itself, leave this field empty.

User IDThe user ID that is used by the end-to-end hardware adapter to access thespecified hardware unit.

PasswordThe password that is used by the end-to-end hardware adapter to accessthe specified hardware unit.

Password confirmationIdentical to the value specified in the Password field. Used to confirmpassword correctness.

SNMP Privacy passwordIf the hardware adapter uses SNMP to communicate to a hardware box,you need to add a privacy password to the credentials for that hardwarebox if SNMP is set up with encrypted communication.

Do not specify an SNMP privacy password if you are defining credentialsfor a slot in a hardware box.

Privacy password confirmationIdentical to the value specified in the SNMP Privacy password field. Usedto confirm password correctness.

Because the definition of access credentials for hardware units is optional, you canleave the user ID and password fields empty. Even if you define access credentialsfor a hardware box that is accessed by the hardware adapter via SNMP, you canstill choose to omit the SNMP privacy password.

Clicking the OK button adds the hardware unit and the credentials that you havespecified to the hardware access credentials list on the Hardware AdapterConfiguration tab and closes this dialog.

Clicking the Cancel button closes this dialog without adding the specifiedhardware unit and credentials.


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 hardwareunit. The name of the box and slot of the selected hardware unit are displayed inthe corresponding output fields.

Fields on the Change Hardware Access Credentials dialog that you can update:

User IDThe user ID that is used by the end-to-end hardware adapter to access theselected hardware unit.

PasswordThe password that is used by the end-to-end hardware adapter to accessthe selected hardware unit.

Password confirmationIdentical to the value specified in the Password field. Used to confirmpassword correctness.

SNMP Privacy passwordIf the hardware adapter uses SNMP to communicate to a hardware box,you need to add a privacy password to the credentials for that hardwarebox if SNMP is set up with encrypted communication.

Privacy password confirmationIdentical to the value specified in the SNMP Privacy password field. Usedto 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 arechanging credentials for a slot in a hardware box.

Because the definition of access credentials for hardware units is optional, you canleave the user ID and password fields empty. Even if you define access credentialsfor a hardware box that is accessed by the hardware adapter via SNMP, you canstill choose to omit the SNMP privacy password.

Use the Clear credentials button to easily remove all specified credentials for theselected hardware unit.

Clicking the OK button changes the credentials for the hardware unit that youselected in the hardware access credentials list on the Credentials tab and closesthis dialog.

Clicking the Cancel button closes this dialog without changing the selectedhardware unit credentials.

Saving the hardware adapter configurationTo save your changes to the hardware adapter configuration files, click Save on theconfiguration dialog. Upon completion, a configuration update status window isdisplayed, showing which configuration files were updated. If errors occurredduring the update, the corresponding error messages are also displayed.

If you have configured high availability for System Automation ApplicationManager, you must replicate the properties files to the other nodes in the SystemAutomation for Multiplatforms cluster (see “Replicating the configuration files” onpage 160).


Refreshing the active hardware adapter configurationAbout this task

Click Refresh on the Virtual Server / HW Management tab of the configurationdialog task launcher. The actions that are performed depend on the functionalityyou configured for the hardware adapter.

If you configured the adapter to manage hardware for distributed disaster recoverywith GDPS, new or changed hardware access credentials are automaticallyreloaded by the hardware adapter. It is not required to restart the hardwareadapter. If you apply any changes to the configuration of the hardware accesscredentials, you must always request a refresh.

If you configured the hardware adapter to manage virtual servers by using thezEnterprise HMC, no refresh function is available.

Note: If you changed any other settings of the System Automation ApplicationManager configuration, restart the hardware adapter by using the commandseezhwadapter -stop and eezhwadapter -start to activate the changes.

Testing the active hardware adapterAbout this task

Click Test on the Virtual Server / HW Management tab of the configuration dialogtask launcher. The actions that are processed depend on the functionality youconfigured for the hardware adapter.

If you configured the adapter to manage hardware for distributed disaster recoverywith GDPS, the hardware access credentials are tested without powering on or offthe target hardware systems. Use this task after you configure the hardware accesscredentials. The hardware adapter must be running and a disaster recovery policymust 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 andpresented in a dialog.

Note: Some aspects of the disaster recovery setup cannot be tested withoutpowering on and off systems. For example, for SNMP, the user ID might beauthorized to read the power status of the node, but not to change it. The –testoption of the scripts can succeed while normal operation might fail. For thisreason, real fire-drill tests are required for the hardware adapter.


If you configured the hardware adapter to manage virtual servers by using thezEnterprise HMC, the connectivity to the zEnterprise server is tested. Thefollowing 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 adapteris not up and running. You must always use the test function after you change thefunctional credentials that are used to access the zEnterprise HMC, or its hostname or IP address.

If you configured the hardware adapter to be used for both tasks, both testfunctions are processed in the sequence described.

Configuring the hardware adapter in silent modeAbout this task

You can configure the hardware adapter in silent mode as an alternative to usingthe configuration dialogs.

You can use the silent mode to configure the following tasks:v Configuring the hardware adapterv Refreshing the active hardware adapter configurationv Testing the hardware adapter


Configuring storage replicationConfigure storage replication by configuring TPC-R.

Configuring the TPC-R domainConfigure a Tivoli Storage Productivity Center for Replication (TPC-R) domain thatis used by the System Automation Application Manager to integrate storagereplication sessions into end-to-end automation policies.

About this task

To open the configuration dialog, click Configure on the Storage Replication tab ofthe task launcher window.

After you modified any of the configuration properties, you must activate new ormodified TPC-R domain settings. Start the Refresh task on the Storage Replicationtab of the task launcher.

TPC-R Domain configuration windowUse this window to configure the settings for the TPC-R domain and the usercredentials to access the corresponding TPC-R servers.


List of TPC-R domain settingsThis 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 andthe user credentials to access those servers. For more information, see“Adding a TPC-R domain.”

Note: With the current release of System Automation ApplicationManager, the configuration of only one TPC-R domain is supported.

v Use the Modify button to display the Change TPC-R Domain Settingsdialog. Change the settings of the TPC-R servers that are associated withthe domain and the user credentials to access those servers. For moreinformation, 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 usercredentials to access those servers.

About this task

Fields on the Add TPC-R Domain dialog:

Domain nameName of the TPC-R domain. The name that you specify in this field mustbe unique in the set of all automation domains with which you areworking.

TPC-R server one settings

Hostname or IP addressThe name or IP address of the TPC-R server one that is used for thisdomain.

Communication port numberThe port number that is used by System Automation Application Managerto communicate with the TPC-R server one. The default port number is5110.

Web-GUI port numberThe secure port number that is used to access the TPC-R web-GUI onserver one. It is used by System Automation Application Manager toprovide launch-in-context capabilities from the System Automationoperations console to the TPC-R GUI. The default port is 3443. Use thefollowing URL to verify the port number:https://<HOSTNAME_ONE>:<GUI_PORT_NUMBER>/CSM/

If the TPC-R server one is up and running, the welcome screen of TPC-Ropens.

TPC-R server two settings

Hostname or IP addressThe host name or IP address of the TPC-R server two that is used for thisdomain. The server two host name or IP address is optional.


Communication port numberThe port number that is used by System Automation Application Managerto communicate with TPC-R server two. The default port number is 5110.The server two port number is optional.

Web-GUI port numberThe secure port number that is used to access the TPC-R web-GUI onserver two. It is used by System Automation Application Manager toprovide launch-in-context capabilities from the System Automationoperations console to the TPC-R GUI. The default port is 3443. The servertwo GUI port number is optional. Use the following URL to verify the portnumber:https://<HOSTNAME_TWO>:<GUI_PORT_NUMBER>/CSM/

If the TPC-R server two is up and running, the welcome screen of TPC-Ropens.

Credentials for accessing TPC-R servers

User IDThe user ID that is used by System Automation Application Manager toaccess 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 userID role Operator for all replication sessions that are managed with SystemAutomation Application Manager by using replication references. You canassign this role in the Tivoli Storage Productivity Center for Replication.

PasswordThe password that is used by System Automation Application Manager toaccess the specified TPC-R server. If you specified also a server two, thesame password is used to access both servers.

Password confirmationIdentical value as specified in the password field to confirm passwordcorrectness.

Port numbers must match what you defined for the TPC-R configuration in:<TPC_R_INSTALL_DIR>/eWAS/profiles/CSM/properties/rmserver.properties

Parameters on the respective TPC-R server.communications.port = <PORT_NUMBER>

WC_defaulthost_secure = <GUI_PORT_NUMBER>

Because definition of a server two is optional, you can leave the correspondingserver host name and port fields empty. If you specify a server two host name orIP address, you must also specify the port numbers.

Click OK to add the domain and the settings that you specified to the domain listin 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 selectedTPC-R domain.


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 bechanged and is displayed as an output field, see “Adding a TPC-R domain” onpage 147.

Saving the TPC-R domain configurationAbout this task

To save your changes to the TPC-R configuration files, click Save in the TPC-Rdomain configuration window. Upon completion, a configuration update statuswindow is displayed, showing which configuration files were updated. If errorsoccurred 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 Automationfor Multiplatforms cluster. For more information, see “Replicating the configurationfiles” on page 160.

Refreshing the TPC-R domain settingsAbout this task

Click Refresh on the Storage Replication tab of the configuration dialog tasklauncher to trigger that the TPC-R domain configuration settings are reloaded intothe running system. Repeat this procedure after changing any of the TPC-Rdomain properties or credentials.

Domain properties are used to define the TPC-R server one and server two hostand ports that are currently stored in the end-to-end automation database. Thedomain properties are refreshed with the values that are stored in thecorresponding TPC-R configuration file. The currently active sessions with anyTPC-R server are recycled to pick up a fresh copy of the access credentials fromthe configuration file.

Testing the TPC-R domain configurationAbout this task

Click Test on the Storage Replication tab of the configuration dialog task launcherto trigger that the currently defined TPC-R domain configuration settings arevalidated. You can walk through the following steps, if you change any of theTPC-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 configurationsettings 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 thechanged 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.


Configuring the TPC-R domain in silent modeAbout this task

You can configure the TPC-R domain in silent mode as an alternative to using theconfiguration dialogs.

You can use the silent mode to configure the following tasks:v Configuring the TPC-R domainv Refreshing the active TPC-R domain configurationv Testing the TPC-R domain configuration

For a detailed description of the silent mode configuration tasks, see “Configuringin silent mode” on page 203.

Configuring high availability

If you configured System Automation Application Manager for a disaster recoverysetup on two sites, the high availability configuration is different. For moreinformation, see “High availability for a disaster recovery setup on two sites” onpage 168.

High availability for System Automation Application ManagerMake System Automation Application Manager highly available by using SystemAutomation for Multiplatforms.

The high availability policy makes all components that are required to run SystemAutomation Application Manager highly available. System Automation forMultiplatforms resources and corresponding relationships are defined for eachcomponent:v DB2, optional. For more information, see “High availability options with DB2”

on page 151.v WebSphere Application Serverv System Automation Application Manager end-to-end automation managerv System Automation Application Manager hardware adapter for the Distributed

Disaster Recovery feature, if usedv System Automation Application Manager GPDS agent for the Distributed

Disaster Recovery feature, if usedv System Automation Application Manager local agentless adapter, if used

For a detailed description of all involved resources and relationships, see “Highavailability 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 operationsconsole after the cluster is started and the policy is active. Use the service IPaddress as target address to configure end-to-end automation adapters as well.


The System Automation for Multiplatforms cluster might have one, two, or threenodes. The number of nodes that you configure has the following impact on thecapabilities of the high availability policy:

One nodeThere is no redundancy and failover capability if the node becomes offline.System Automation for Multiplatforms provides the correct start/stopsequence of all components and a restart only in case of an applicationfailure.

Two nodesIn addition to the capabilities available for the one-node setup, a completefailover of the Application Manager workload is processed in case of anode failure. If the local agentless adapterr is configured, the adapter andthe rest of the Application Manager workload initially run on differentnodes for workload balancing reasons. Only in case of a node failure, thecomplete workload moves to the remaining node.

Three nodesIn addition to the capabilities available for the two-node setup, the localagentless adapter is kept running on a different node in case of a nodefailure.

The topic “Configuring the high availability policy” on page 153 describes the highavailability configuration tabs of the System Automation Application Managerconfiguration dialog. To open the configuration dialog, click Configure on theHigh Availability tab f the task launcher.


Ensure that the high availability configuration properties are identical on all nodesof the System Automation for Multiplatforms domain. Replicate the configurationfiles to the other nodes in the cluster. For more information, see “Replicating theconfiguration files” on page 160.

High availability options with DB2Learn more about two scenarios that show how DB2 can be used and the impacton the System Automation Application Manager high availability policy.

Scenario with a shared DB2 database

In this scenario, there are independent DB2® database managers on eachnode in the cluster. Only one of them is active at a particular time. Datasharing is accomplished by using a shared disk. Only the node where theactive DB2 manager is running has the shared disk mounted.

DB Manager

Standby node 2

J2EE Framework

Automation Engine

DB file system

DB Manager

Active node 1

J2EE Framework

Automation Engine

DB node

Figure 12. End-to-end high availability scenario with a shared database file system


When you configure the System Automation Application Manager highavailability policy for this scenario, select to include DB2 into the policy.

Scenario with a remote DB2 database

In this scenario, the DB2® database manager is located outside the cluster.The System Automation Application Manager installation on each clusternode uses the same remote database.

When you configure the System Automation Application Manager highavailability policy for this scenario, select to not include DB2 into thepolicy for this scenario.

Setting up the high availability policyLearn 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 Managerhighly 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 itis running independently on each node. Start each application on one nodeonly and verify that they work correctly. Then, stop all applications on thisnode and repeat on the other node.

4. Stop all applications on all nodes before you activate the System AutomationApplication Manager high availability policy the first time by using theconfiguration dialog "Define policy" task.

5. Run the configuration dialog cfgeezdmn to configure the automation policy forthe end-to-end automation manager:a. Configureb. Replicatec. Set up domain – only needed if no System Automation for Multiplatforms

domain exists.d. Define policy

JDBC Driver

Standby node 2

J2EE Framework

Automation Engine

DB file system

JDBC Driver

Active node 1

J2EE Framework

Automation Engine

DB Manager

DB node

Figure 13. End-to-end high availability scenario with a remote database file system


The System Automation Application Manager high availability policy is nowactivated on the System Automation for Multiplatforms domain.

Configuring the high availability policyConfigure the resources and settings of the System Automation ApplicationManager high availability policy.

About this task

Click Configure on the High availability tab of the task launcher window to openthe high availability policy configuration dialog.

Domain Setup tab:

Use the Domain Setup tab to configure the parameters that are required for settingup the System Automation for Multiplatforms domain. Use this domain to providehigh availability for System Automation Application Manager. The specifiedparameters are used to create the System Automation for Multiplatforms domainin the setup domain task.

Controls and fields on the Domain Setup tab:

Domain name The name of the System Automation for Multiplatforms domain. To primethe 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 fieldempty if you are setting up a three-node System Automation forMultiplatforms domain, or a different type of tie breaker for a two-nodedomain. In this case, no network tie breaker is defined.

To prime the field with the currently defined value, click Query domain. Ifyou use Query domain to fill this field, the first defined tiebreaker of type"EXEC" is chosen.

Node listThe table lists the nodes of the System Automation for Multiplatformsdomain. If the domain is online, clicking Query domain populates thetable with the nodes that are online in the domain.

Table columns:

Defined nodeThe name of the node.

Automate on nodeIndicates whether System Automation Application Manager is tobe automated on the node, in which case it is included in theautomation policy.

Network interfaceThe name of the network interface on this node.

Possible actions on the tab:


Determining the sequence in which automation selects the node on whichSystem Automation Application Manager can run

You specify the preferred failover sequence by changing the position of thenodes in the list. To move a node to a different position, select the nodefrom the list and click Up or Down.

Adding, changing, and removing nodesTo change the list of nodes in the automation policy, use the correspondingbuttons:

Add Opens a window for specifying the settings for the node that is tobe added to the automation policy.

ModifyTo change the settings for a node, select the node, click Modify,and change the settings in the window that is displayed.

RemoveTo remove a node from the automation policy, select the node, andclick Remove.

If you add or modify a node and you already defined a System Automation forMultiplatforms domain, specify a node name that is listed when you run thelsrpnode RSCT command. The result of the lsrpnode command is also used toprime the nodes list on the Domain Setup tab when you click the Query Domainbutton.

Automation Manager tab:

Use the Automation Manager tab to configure the resources that are used toautomate the end-to-end automation manager.

Controls and fields on the Automation Manager tab:

Automated resources prefixThe prefix that precedes the names of the resources and groups in theautomation manager automation policy. The prefix is restricted to ASCIIcharacters.

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 versionSelect which IP version you want to use for the virtual IP address in theend-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.


Note: The IP address that is used to make the automation manager highlyavailable must be identical to the IP address that you specify on the“Domain tab” on page 106 in the System Automation Application Managercommon 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-levelautomation adapter as the IP address for the end-to-end automationmanagement host.

v If you are using remote Agentless Adapters, it is implicitly used as IPaddress for the end-to-end automation management host. If a version 6IP address is used, each system where a first-level automation adapter ora remote agentless adapter runs, must provide IP version 6communication capabilities.

Click Query domain to automatically match the IP version with thedefined IP address or addresses.

IPv4 addressThe virtual IP version 4 address that is shared by all nodes in the IBMTivoli System Automation domain and that is set for the version 4IBM.ServiceIP resource in the end-to-end automation manager automationpolicy. The virtual IP address must be authorized by your networkadministrator. The IPv4 address is required if you select IPv4 or Both as IPversion. Otherwise, this field is disabled. To prime the field with thecurrently defined value, click Query domain.

IPv6 addressThe virtual IP version 6 address that is shared by all nodes in the IBMTivoli System Automation domain and that is set for the version 6IBM.ServiceIP resource in the automation manager automation policy. Thevirtual IP address must be authorized by your network administrator. TheIPv6 address is required if you select IPv6 or Both as IP version.Otherwise, this field is disabled. To prime the field with the currentlydefined value, click Query domain.

NetmaskEnter the netmask that is set for the IBM.ServiceIP resource in theautomation manager automation policy. Request the address from yournetwork administrator. The netmask is required if you select IPv4 or Bothas IP version. Otherwise, this field is disabled. To prime the field with thecurrently defined value, click Query domain.

NetprefixEnter the netprefix that is used to define the IBM.ServiceIP resource in theautomation manager automation policy. Specify a value in the range of 0 -128 to define how many bits of the IP address are portioned for thenetwork part of that address. The netprefix is required if you selected IPv6or Both as IP version. Otherwise, this field is disabled. To prime the fieldwith the currently defined value, click Query domain.

Policy Pools tab:

Use the Policy Pool tab to configure the parameters that are required to automatethe file system where the policy pools are located. The data is used to create thecorresponding file system resources in the automation policy. The policy pools


must be on a file system that is shared by all nodes in the System Automation forMultiplatforms domain. When the automation policy is active, they are mounted atthe 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 automationpolicies of the Application Manager are stored.

File system typeThe 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, clickQuery domain.

Mount pointThe mount point of the policy pool file system. Click Browse to select adirectory. If the domain is online, you can click Query domain to primethe field with the currently defined value.

Device nameThe device name of the policy pool file system. Click Browse to select adevice. If the domain is online, you can click Query domain to prime thefield 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 todefine the policy pool where the agentless adapter policies are stored. The fieldsfor the agentless adapter policy pool are only enabled if Enable agentless adapterconfiguration is checked on the Non-clustered Nodes tab of the task launcherwindow, see “Configuring the Application Manager settings” on page 100.

Due to the AntiAffinity relationship in the high availability policy, the automationmanager and the agentless adapter run on different nodes. Therefore, the policypools of both components cannot be shared. In particular, the mount points forboth policy pools must be different.

WebSphere tab:

Use the WebSphere tab to configure the parameters that are required forautomating the instance of WebSphere Application Server that hosts the end-to-endautomation manager. The data is used to create the corresponding resource in theautomation policy and to monitor, start, and stop the WebSphere ApplicationServer. Most of the parameters are set by the installer at installation time.

Controls and fields on the WebSphere tab:

Application server nameThe name of the WebSphere Application Server instance that hosts theend-to-end automation manager.

Application server SOAP portThe number of the WebSphere Application Server port that is used by theend-to-end automation manager. The name of this port in theadministrative console is SOAP_CONNECTOR_PORT.


Profile directoryThe directory in which the WebSphere Application Server profile forSystem Automation Application Manager is located. Click Browse tonavigate to the directory.

User IDThe WebSphere administrator user ID that is used to stop the WebSphereApplication Server.

PasswordThe WebSphere administrator password that is used to stop the WebSphereApplication Server. Click Change to change the password.

The WebSphere administrator credentials are stored in the fileproperties/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 DB2instance 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 mountpoint must be identical on all nodes of the System Automation for Multiplatformsdomain. Otherwise, the automation policy does not work.

Controls and fields on the DB2 tab:

Automate DB2Select the check box to enable the entry fields on the tab. If you are using aremote DB2 database, do not select the check box. In this case, the DB2instance must not be included in the automation policy.

Installation directorySpecify the DB2 installation directory. Click Browse to select a directory.

Instance owner user IDSpecify the user ID of the owner of the DB2 instance that hosts the SystemAutomation Application Manager database.

Instance owner mount pointSpecify the mount point of the DB2 instance that hosts the SystemAutomation Application Manager database. Click Browse to select adirectory.

Hardware Adapter tab:

The Hardware Adapter tab provides an indication of whether resources for thehardware adapter are included in the Application Manager high availability policy.Including the resources for the hardware adapter will also make the hardwareadapter highly available when you save the configuration and start the definepolicy task the next time.

Note: You cannot actively modify the selection states on the Hardware Adaptertab. 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 thatrepresents the hardware adapter executable is included in the automation policy.


v If you want to configure the hardware adapter for distributed disaster recoverywith GDPS, a resource for the GDPS agent of the Application Manager isincluded in the automation policy.

If you changed the configuration status of the hardware adapter, proceed asfollows:

Click Query domain. If the hardware adapter configuration status is not consistentwith the resources that are defined in the currently active automation policy, awarning is shown. To correct the currently active automation policy by adding orremoving hardware adapter resources, proceed as follows:

Save the current configuration values.This task updates the configuration properties file that is used as input forgenerating the automation policy. For the hardware adapter, an indicationwhich 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 isinconsistent 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, whichcontains the required hardware adapter resources.

If you changed the configuration status of the hardware adapter, you need to takethe following action. Click Query domain. If the hardware adapter configurationstatus is not consistent with the resources that are defined in the currently activeautomation policy, a warning is shown on this window. To correct the currentlyactive 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 isused as input for generating the automation policy.

v Start the remove policy task. For more information, see “Removing theautomation policy” on page 163. This deactivates the currently active automationpolicy which is inconsistent with respect to the adapter configuration status.

v Start the define policy task. For more information, see “Defining the automationpolicy” on page 163. This activates the new version of the automation policywhich contains the required hardware adapter resources.

agentless adapter tab:

The agentless adapter tab provides an indication of whether resources for the localagentless adapter are included in the Application Manager high availability policy.

Including the resources for the agentless adapter will also make the local agentlessadapter highly available when you save the configuration and process the definepolicy task the next time.

Note: The selection states on the agentless adapter tab cannot be changed. Theycorrespond to the current configuration status of the agentless adapter.If you checked Enable local agentless adapter configuration on the Non-clusteredNodes tab of the task launcher window, the corresponding agentless adapterresources are included in the automation policy. If you changed the configuration


status of the local agentless adapter, proceed as follows. Click Query domain. Ifthe agentless adapter configuration status is not consistent with the resources thatare defined in the currently active automation policy, a warning is shown on thispane. To correct the currently active automation policy by adding or removingagentless adapter resources, proceed as follows:

Save the current configuration values.This task updates the configuration properties file that is used as input forgenerating the automation policy. For the agentless adapter, an indicationwhether resources are required, is saved in the configuration propertiesfile.

Start the remove policy taskFor more information, see “Removing the automation policy” on page 163.This task deactivates the currently active automation policy, which isinconsistent regarding the adapter configuration status.

Start the define policy taskFor more information, see “Defining the automation policy” on page 163.This task activates the new version of the automation policy, whichcontains 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, aconfiguration update status window is displayed, showing which configurationfiles were updated. If errors occurred during the update, the corresponding errormessages are also displayed.

To ensure that the configuration properties are set correctly on all nodes of theSystem Automation for Multiplatforms domain, you must replicate theconfiguration 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 ApplicationManager high availability policy, you can use the Query domain button on theconfiguration dialog. This function retrieves information from most fields in theconfiguration notebook:

Domain tab

v Domain name and status (online/offline)v List of nodes and network interfacesv 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 tabIP address and netmask or net prefix of the IBM.ServiceIP resource startswith resource name prefix. For example, eez-.

Policy Pools tab

v File system type, mount point, and device name of the IBM.AgFileSystemresource starts with resource name prefix. For example, eez-.


v If the local agentless adapter is part of your high availability policy, thesame information is displayed for the file system where the agentlessadapter policy pool is located. This is the case, if you checked Enablelocal agentless adapter configuration on the Non-clustered Nodes tab ofthe task launcher window and the local agentless adapter is part of thecurrently active policy.

Hardware Adapter tabIf there is a mismatch between the current hardware adapter configurationstatus and the hardware adapter resources in the currently active policy, awarning is displayed on this tab. An example of such a mismatch is if thehardware adapter is not configured, but hardware adapter resources aredefined in the active policy.

agentless adapter tabIf there is a mismatch between the current local agentless adapterconfiguration status and the agentless adapter resources in the currentlyactive policy, a warning is displayed on this tab. An example of such amismatch is if the local agentless adapter is configured, but no agentlessadapter 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 IPaddress that you define for the automation manager must be identical to the valuethat 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 tabof the Application Manager common configuration dialog.

You can save the high availability configuration only if both values are identical. Ifyou 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 automationmanager host name makes sure that the end-to-end automation manager can becontacted by any first-level automation domain, no matter on which node in thecluster the automation manager currently running.

The automation management host of each end-to-end automation adapterconfiguration must be the same virtual IP address. The end-to-end automationmanagement host is defined in the Host name or IP address field on the HostUsing Adapter tab of the adapter configuration dialogs. For the SystemAutomation for z/OS automation adapter, the host name is the value of theeif-send-to-host name parameter in the adapter properties configuration file.

Replicating the configuration filesIf you configured high availability for System Automation Application Manager,replicate the configuration files to the other nodes in the System Automation forMultiplatforms domain. Replicate the files whenever you modified theconfiguration of any System Automation Application Manager component.


About this task

Click Replicate on the High Availability tab of the configuration task launcher. TheReplicate Configuration Files window opens.

Use this window to distribute (replicate) the configuration files to the remainingnodes 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 theconfiguration is identical on all nodes.

3. Under Target node login, type the user ID and password for the replicationtarget nodes.

4. If you configured at least one remote agentless adapter instance, check theInclude remote agentless adapter configurations for replication box. Theconfiguration files of all currently configured remote agentless adapterinstances are replicated as well, although they are not contained in the list ofreplication source files.

5. Start the replication by clicking Replicate.

Replication can take a while. While the files are being replicated, the Replicatebutton is indented and grayed-out. When the replication is complete, thereplication status of each configuration file is displayed.

Setting up the domainUse this task to set up the domain in which System Automation ApplicationManager is to be automated. If you want to automate System AutomationApplication Manager in a new System Automation for Multiplatforms domain, setup the domain before you start the high availability configuration task Definepolicy.

About this task

Click Set up domain on the High Availability tab of the configuration tasklauncher. The Set up Domain dialog opens, showing the nodes that set up thedomain: the local node and the remote node or nodes, which are specified on theDomain 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, thisaction is skipped and only the domain definition is prepared. To prepare thenodes, specify the user credentials for accessing the nodes and click Prepare.

2. Define the domainTo complete the domain setup, execute the following commands on the localnode:v preprpnode - prepares the local node for joining the domainv mkrpdomain - creates the domain definition by using the domain name and

the nodes that were specified on the Domain setup tabv startrpdomain - starts the domain (state online)


Note: System Automation for Multiplatforms must be installed on all nodesthat are to be included in the new domain. If other System Automation forMultiplatforms domains currently exist, they might be offline.Upon completion, a message box is displayed.

Removing the domainTo be able to remove the System Automation for Multiplatforms domain definitionfrom 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 Removedomain on the High Availability tab of the task launcher. Then, the rmrpdomaincommand is started.

Validating and storing the automation policyAbout this task

You can validate the System Automation Application Manager automation policyby clicking Validate&Store policy on the High Availability tab of the configurationdialog task launcher. This task also stores the automation policy in XML format ina file. Upon completion, the result of the validation is displayed, including thename 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 youare using System Automation for Multiplatforms to also automate your ownapplications, the automation policy elements are added as a delta to yourcurrently active policy. You can therefore want to evaluate whether thoseadditional policy elements might have any impact on your active policy.

3. Modifying the stored policy and manually activating it. Apply modifications tothe policy or extend it beyond what you can define by using the policyconfiguration task. Each invocation of the Validate&Store policy or Definepolicy task overwrites the XML policy file. Copy or rename the file before youmodify it.If you want to activate a modified policy, use the sampolicy command. You canuse the update option -u in this case in order not to stop or remove anyresource outside the scope of the System Automation Application Managerautomation policy.The XML policy file contains inclusions of other XML policy files. Theseincluded files are not overwritten by an invocation of the Validate&Storepolicy or Define policy task. If you want to change an included file, copy andrename it and then change the corresponding include-tag to refer to therenamed file.

Note: This function is only supported if System Automation for Multiplatformsversion 3.1 or higher is used to make the end-to-end automation manager highlyavailable. If earlier versions are used, theValidate&Store policy button is disabled.


Defining the automation policyAbout this task

Click Define policy on the High Availability tab of the configuration dialog tasklauncher. Then, resources with names as described in “High availability policy ofSystem Automation for Multiplatforms” on page 164 are created.

Note: If automated resources with the same name exist, their attributes aremodified according to the currently configured values.

If you specified for example, the resource or group prefix name eez- on theAutomation Manager tab, the resource group eez-rg and the resources andrelationships that are shown in the table of “High availability policy of SystemAutomation for Multiplatforms” on page 164 are created.

Note:

1. If you change one of the policy elements outside this dialog, a failure of theremove policy or the define policy task can be caused.

2. Activating or deactivating a policy for System Automation for Multiplatformsby using the sampolicy command can remove existing definitions for theSystem Automation Application Manager automation policy. For example, thedefinition of one of the resources in Table 37 on page 165 can be removed whena new policy for System Automation for Multiplatforms is activated.You can first save the currently active policy by using the sampolicy -scommand, and then edit the XML output file. Use the command sampolicy -uto update the active policy with the changed XML output file. If you edit thepolicy, make sure that all definitions for System Automation ApplicationManager automation are preserved. Make sure that none of your changes hasan undesired effect on the currently active System Automation ApplicationManager automation policy. For more information about the sampolicycommand, see System Automation for Multiplatforms Reference and ProblemDetermination Guide.

Removing the automation policyAbout this task

Click Remove policy on the High Availability tab of the configuration dialog tasklauncher to remove the resources that are described in “High availability policy ofSystem Automation for Multiplatforms” on page 164. All resources are firststopped and then removed.

Activating or deactivating a policy for System Automation for Multiplatforms byusing the sampolicy command can remove existing definitions for the SystemAutomation Application Manager automation policy. For example, the definition ofone of the resources that are listed in Table 37 on page 165 can be removed when anew 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 theactive policy with the changed XML output file. If you want to edit the policy,make sure that all definitions for System Automation Application Managerautomation are preserved. Then, none of your changes has an undesired effect onthe currently active System Automation Application Manager automation policy.For detailed information, see the description of the sampolicy command in theSystem Automation for Multiplatforms Reference.


Configuring high availability in silent modeAbout this task

You can configure Application Manager high availability in silent mode as analternative 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


The following configuration tasks can be processed by using the configurationdialogs or manually:v Replicating the configuration filesv Setting up and removing the domainv Validating and storing the automation policyv Defining and removing the automation policy

If you do not want to use the configuration dialogs, see “Processing tasksmanually” on page 204 for a detailed description of the tasks you can processmanually.

High availability policy of System Automation for MultiplatformsThe following figure shows the System Automation for Multiplatforms highavailability policy that makes System Automation Application Manager highlyavailable. You can find all components, relationships, and dependencies in thefollowing figure.


The eez- prefix is the default value, but can be changed in the configurationdialog. After the top-level group eez-rg is activated by the operator, allapplications are started in the correct sequence. All resources are automaticallyonline.

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 thatcomprises the agentless adapterresources.

eez-rg IBM.ResourceGroup The top-level group thatcomprises all automatedresources except for agentlessadapter resources. This top-levelgroup always exists.

Virtual IPaddress

WebSphereApplicationServer

eez-was-rg

End-to-endautomationmanager

Policypool

eez-engine-rg

DB2server

DB2mountpoint

eez-db2-rg

GDPSagent

Hardwareadapter

eez-srv-rg

eez-ala-rg

Policypool

Agentlessadapter

StartAfter

Start AfterS

tartA

f ter

St o

pA

fter

StartAfter

AntiAffinity

DependsOn

eez-rg

StartAfter

DependsOnDependsOn

Figure 14. Resource groups, resources, and their relationships


Table 37. Resources in the automation policy for the end-to-end automationmanager (continued)


eez-srv-rg IBM.ResourceGroup The group that comprises theautomation manager and theWebSphere Application Serverresource.

eez-db2-rg IBM.ResourceGroup The group that comprises allDB2 resources.

eez-was-rg IBM.ResourceGroup The group that comprises allWebSphere Application Serverresources.

eez-engine-rg IBM.ResourceGroup The group that comprises allautomation manager resources.

eez-hwa-rg IBM.ResourceGroup The resource group thatcomprises the hardware adapterresources.

eez-gdpsagent-rg IBM.ResourceGroup The resource group thatcomprises the command receiverfor distributed disaster recoveryresources.

eez-ip IBM.ServiceIP The virtual IP address that isused for the WebSphereApplication Server.

eez-ipv6 IBM.ServiceIP The virtual IPv6 address that isused for the WebSphereApplication Server.

eez-niequ IBM.Equivalency The available network interfaceson 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 fordistributed disaster recovery.

eez-ala-mount IBM.AgFileSystem The policy-pool for the agentlessadapter; only defined when thepolicy pool is not harvested bythe StorageRM.

eez-shared-mount IBM.AgFileSystem The policy-pool for theautomation manager; onlydefined when the policy pool isnot harvested by the StorageRM

eez-ala-mount-stopsAfter-ala-rs

IBM.ManagedRelationship Dependency of the agentlessadapter policy pool on theagentless adapter.

eez-ala-rs-startsAfter-ala-mount

IBM.ManagedRelationship Dependency of the agentlessadapter on the agentless adapterpolicy pool.


Table 37. Resources in the automation policy for the end-to-end automationmanager (continued)


ala-rs-startsAfter-eez-was-as

IBM.ManagedRelationship Dependency of the agentlessadapter on the WebSphereApplication Server by using thestartAfter relationship.

ala-rs-AntiAffinity-eez-engine

IBM.ManagedRelationship Dependency of the agentlessadapter on the automationmanager by using theAntiAffinity relationship.

eez-engine-AntiAffinity-ala-rs

IBM.ManagedRelationship Dependency of the automationmanager on the agentlessadapter.

db2-rs-dependsOn-db2-rs_mount

IBM.ManagedRelationship Dependency of the DB2 serveron the file system.

eez-was-as-dependsOn-db2-rs

IBM.ManagedRelationship Dependency of the WebSphereApplication Server on DB2.

eez-shared-mount-stopsAfter-engine

IBM.ManagedRelationship Dependency of the policy poolon the automation manager.

eez-engine-startsAfter-shared-mount

IBM.ManagedRelationship Dependency of the automationmanager on the policy pool.

eez-engine-startsAfter-was-as

IBM.ManagedRelationship Dependency of the automationmanager on the WebSphereApplication Server.

eez-was-as-startsAfter-ip IBM.ManagedRelationship Dependency of the WebSphereApplication Server on the virtualIP address.

eez-ip-dependsOn-niequ IBM.ManagedRelationship Dependency of the virtual IPaddress on the networkinterface.

hwa-startsAfter-eez-engine

IBM.ManagedRelationship Dependency of hardwareadapter on the automationmanager.

gdpsagent-dependsOn-eez-engine

IBM.ManagedRelationship Dependency of the commandreceiver on the automationmanager.

nettb IBM.TieBreaker Tie-Breaker defined, if IPaddress is specified on thedomain setup page.

Notes and restrictionsAbout this taskv Do not manually change any of the resources, which are part of the System

Automation Application Manager high availability policy, for example by usinga command such as chrsrc or chrel. Otherwise, the Define policy or Removepolicy task of the configuration dialog might not work. If you want to changeany policy elements use the Validate&Store task of the configuration dialog,copy the created policy, and make your changes within the copied policy. Youcan then activate this changed policy by using the sampolicy command with theupdate option -u.


v Requests for end-to-end resources are persistent and are therefore not lost whenthe end-to-end automation manager is moved to another node.

v For each first-level automation domain that is connected to the highly availableSystem Automation Application Manager, start the adapter configuration tool.Verify that on the Host Using Adapter page the Host name or IP address is setto the virtual IP address that is defined in the high availability policy. Then, thefirst-level automation adapter communicates properly with the SystemAutomation Application Manager.

v Test the System Automation Application Manager HA setup. For example,initiate a failover of the System Automation Application Manager and verify thatall attached end-to-end and first-level domains can be operated from theoperations console. Verify that events are received from each domain.

v The automation engine and the agentless adapter are supposed to run ondifferent nodes, which is implemented by an AntiAffinity relationship in thepolicy. Therefore, the policy pools of both components cannot be shared. Themount points for both policy pools must be different.

v If you modify the configuration of the WebSphere Application Server, repeat thesame configuration changes on both nodes in the high availability cluster. Forexample, changing security settings, trace settings, or deploying otherapplications.

v Operator credentials that are used for authentication against first-levelautomation domains can be stored in the IBM Dashboard Application ServicesHub credential vault. The credential vault is not shared between the nodes inthe high availability cluster. Therefore, after a failover of the WebSphereApplication Server, operators must enter their credentials again to access afirst-level automation domain.

v Operators can specify the number of visible rows that are displayed in theoperations console. These preferences are stored in the directory<WAS_ROOT>/profiles/AppSrv01/Tivoli/EEZ, which is not shared between thenodes in the high availability cluster. Therefore, after a failover of the WebSphereApplication Server, operators must specify preferences on the second systemagain if they are changed and differ from the default.

High availability for a disaster recovery setup on two sitesIn a disaster recovery setup with two sites, you can configure a SystemAutomation Application Manager high availability policy to control the site switchin a Geographically Dispersed Parallel Sysplex (GDPS) environment.

Define a two-site disaster recovery setup with a System Automation ApplicationManager installed on each site. The active Application Manager is automaticallymoved by GDPS if the K-System master moves. For this setup, a special type ofSystem Automation Application Manager high availability policy is required. Thehigh availability policy enables GDPS to control the site switch of the SystemAutomation Application Manager and keeps the EAUTODB database that issynchronized on both sites.

If you define a two-site disaster recovery setup, you must also configure analternative end-to-end automation host for the Application Manager. “Configuringan alternative end-to-end automation host” on page 114 describes how to definethis setup.

The configuration of the high availability policy for a disaster recovery setupdiffers from the regular high availability policy for the following characteristics:


Single NodeThe high availability policy for a disaster recovery setup is based on aone-node System Automation for Multiplatforms cluster. Only the hostname of that node is required, instead of a list of up to three nodes that areneeded for the regular high availability policy. A virtual IP address is notneeded because the application manager cannot move to another nodewithin the cluster.

DB2 For the regular high availability policy, including DB2 is optional. The highavailability policy for a disaster recovery setup requires the installation ofDB2 on the Application Manager node. DB2 thus becomes anunconditional part of the policy.

GDPS agentThe GDPS agent is included in the regular high availability policy only ifthe hardware adapter is configured to manage hardware for distributeddisaster recovery with GDPS. In the high availability policy for a disasterrecovery setup, the GDPS agent is always included. In this configurationGDPS is used to control on which site the System Automation ApplicationManager is active.

Shared file systems for policy pools

No resources for shared file systems are included in the high availabilitypolicy for a disaster recovery setup. A shared policy pool is not required ina single-node cluster.

For information about configuring the regular high availability policy, see“High availability for System Automation Application Manager” on page150.

Configuring the high availability policy for a disaster recoverysetupConfigure the resources and settings of the System Automation ApplicationManager 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 openthe high availability policy configuration dialog. If you are running on a Linux forSystem z® operating system platform, the Select Application ManagerHigh-Availability Setup dialog opens. Select which type high availability policyyou want to configure. The dialog offers two options:

Configure the Application Manager high availability policy for a SystemAutomation for Multiplatforms cluster.

Select this option to configure the regular high availability policy. Whenyou click OK, the dialog that is described in “High availability for SystemAutomation Application Manager” on page 150 is displayed. Follow theprocedure in that section to configure the policy.

Configuring the Application Manager single node high availability policy for adisaster recovery setup

Select this option to configure the high availability policy for a disasterrecovery setup. Click OK to proceed with the configuration.

This option requires the prerequisites that are listed as follows. If theseprerequisites are not satisfied, this option is disabled. In this case, amessage displays the missing configuration prerequisite is displayed in thedialog.


1. You must configure an alternative end-to-end automation managementhost. Specify the host name of the other GDPS site as alternative hostname in the Application Manager common configuration. If thisprerequisite is listed as not satisfied, see “Configuring an alternativeend-to-end automation host” on page 114.

2. Configuration of the local agentless adapter with the high availabilitypolicy for a disaster recovery setup is not supported. You must notconfigure the local agentless adapter. If this prerequisite is listed as notsatisfied, clear the corresponding check box on the Non-clusteredNodes tab of the task launcher dialog.

Domain Setup tab:

Use the Domain Setup tab to configure the parameters that are required for settingup the System Automation for Multiplatforms domain, to provide high availabilityfor System Automation Application Manager. The specified parameters are used tocreate the System Automation for Multiplatforms domain in the setup domain task.

Controls and fields on the Domain Setup tab:

Domain NameSpecify the name of the System Automation for Multiplatforms domain. Toadd the currently defined domain name, click Query domain . The domainstatus (Online or Offline) is displayed to the right of the field.

Node NameSpecify the name of the System Automation for Multiplatforms node thatidentifies the single-node domain. If you already defined a SystemAutomation for Multiplatforms domain, specify the node name that islisted as output of the lsrpnode command on that node. If the domain isonline, click Query domain to fill in the field with the node of the domain.

Automated resources prefixSpecify the prefix that is used for the names of the resources and groups inthe automation policy. Only ASCII characters are supported. If you definedthe current automation policy by using the old prefix value, change theprefix:1. Remove the current automation policy2. Change the prefix on this tab3. Define the automation policy again.

WebSphere tab:

Use the WebSphere tab to configure the parameters that are required forautomating the instance of WebSphere Application Server that hosts the end-to-endautomation manager. The data is used to create the corresponding resource in theautomation policy and to monitor, start, and stop the WebSphere ApplicationServer. Most of the parameters are set by the installer at installation time.

This tab is identical to the WebSphere tab in the regular automation policyconfiguration. Refer to “Configuring the high availability policy” on page 153,“WebSphere tab” on page 156.


DB2 tab:

Use the DB2 tab to configure the parameters that are used for automating the DB2instance that hosts the System Automation Application Manager database. Theseparameters are set at installation time. Usually, you are not required to change anyof these values.

Controls and fields on the DB2 tab:

Installation directoryThe DB2 installation directory. Click Browse to select a directory.

Instance owner user IDThe user ID of the owner of the DB2 instance hosts the System AutomationApplication Manager database.

Automation database nameThe name of the System Automation Application Manager database.

Hardware Adapter tab:

The Hardware Adapter tab provides an indication of whether resources for thehardware adapter are included in the Application Manager high availability policy.Including the resources for the hardware adapter will also make the hardwareadapter highly available when you save the configuration and start the definepolicy task the next time.

You cannot actively modify the Hardware Adapter tab settings. They correspond tothe current configuration status of the hardware adapter. You can configure thehardware adapter to access the zEnterprise® HMC or for distributed disasterrecovery with GDPS®. The corresponding resource that represents the hardwareadapter executable file is included in the automation policy. The GDPS agent isalways 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 asdescribed in “Hardware Adapter tab” on page 157.

Saving the high availability configuration: To save your entries, click Save onthe configuration dialog. Upon completion, the Configuration Update Statuswindow is displayed. This window displays the list of updated configuration files.

Retrieving information about an active high availability configuration: Toretrieve information about a domain configuration from a defined SystemAutomation Application Manager high availability policy, use the Query domainbutton on the configuration dialog. This function populates the fields in theconfiguration 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, awarning is displayed in this tab. An example of such a mismatch is if thehardware adapter is not configured, but hardware adapter resources aredefined in the active policy.


High availability configuration tasksOn the High Availability tab of the task launcher window, you can launch severalother configuration tasks.

For each task, see the referenced sections in “High availability for SystemAutomation Application Manager” on page 150.

Replicating the configuration filesIf you configured the automation policy for a disaster recovery setup, theReplicate button on the task launcher window is disabled. This task is notavailable for policies in a single-node cluster, because there is no othernode to which the configuration can be replicated.

Setting up the domainSet up the domain for a high availability policy in a disaster recoverysetup. This set up includes the exception that no other cluster nodes mustbe prepared, because the policy is in a single-node cluster. For moreinformation, see “Setting up the domain” on page 161.

Removing the domainFor more information, see “Removing the domain” on page 162.

Validating and storing the automation policyFor more information, see “Validating and storing the automation policy”on page 162.

Defining the automation policyFor more information, see “Defining the automation policy” on page 163.

Removing the automation policyFor more information, see “Removing the automation policy” on page 163.

Configuring high availability for a disaster recovery setup insilent modeYou can configure System Automation Application Manager high availability for adisaster recovery setup in silent mode as an alternative to using the configurationdialogs.

You can use the silent mode to configure the automation policy for a disasterrecovery 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 theconfiguration 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 tasksmanually” on page 204 for a detailed description of the tasks you can performmanually.


High availability policy using System Automation forMultiplatforms

About this task

The following figure shows the System Automation for Multiplatforms highavailability policy for a disaster recovery setup. System Automation ApplicationManager becomes highly available, including the disaster recovery setupcomponents.

The resources of the single-node System Automation Application Manager highavailability 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 configurationdialog.

Table 38. Resources in the high availability policy for a disaster recovery setup

Resource Name Resource class Description

Virtual IPaddress

WebSphereApplicationServer

eez-was-rg

End-to-endautomationmanager

Policypool

eez-engine-rg

DB2server

DB2mountpoint

eez-db2-rg

GDPSagent

Hardwareadapter

eez-srv-rg

eez-ala-rg

Policypool

Agentlessadapter

StartAfter

Start After

Sta

rtAf te

r

St o

pA

fter

StartAfter

AntiAffinity

DependsOn

eez-rg

StartAfter

DependsOnDependsOn

Figure 15. Resource groups, resources, and their relationships


Table 38. Resources in the high availability policy for a disaster recovery setup (continued)

eez-rg IBM.ResourceGroup The resource group thatcomprises all SystemAutomation ApplicationManager resources exceptDB2

eez-db2-rg IBM.ResourceGroup The resource group thatcomprises all DB2 resources

eez-srv-rg IBM.ResourceGroup The resource group thatcomprises the automationmanager and the WebSphereApplication Server resources

eez-engine-rg IBM.ResourceGroup The resource group thatcomprises all automationmanager resources

eez-was-rg IBM.ResourceGroup The resource group thatcomprises all WebSphereApplication Server resources

eez-gdpsagent-rg IBM.ResourceGroup The resource group thatcomprises the gdpsagentresources

eez-hwa-rg IBM.ResourceGroup The resource group thatcomprises the hardwareadapter resources

eez-hadp-prim-equ IBM.Equivalency The resource controlling theDB2 HADR role

eez-startam-equ IBM.Equivalency The resource controlling theSystem AutomationApplication Managerstate

eez-was-as IBM.Application WebSphereApplicationServer

eez-engine IBM.Application System AutomationApplication Managerautomation 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 AutomationApplication Manager state

eez-was-as-dependsOn-db2-rs

IBM.ManagedRelationship Dependency of WebSphereApplication Server on DB2

eez-was-as_startsAfter_eez-startam-equ

IBM.ManagedRelationship Dependency of WebSphereApplication Server on theSystem AutomationApplication Manager state

hwa-startsAfter-eez-engine IBM.ManagedRelationship Dependency of the hardwareadapter on the SystemAutomation ApplicationManager


Table 38. Resources in the high availability policy for a disaster recovery setup (continued)

eez-was-as_DO_eez-hadr-prim-equ

IBM.ManagedRelationship Dependency of WebSphereApplication Server on DB2HADR role

eez-engine-startsAfter-was-as

IBM.ManagedRelationship Dependency of the SystemAutomation ApplicationManageron WebSphereApplication Server

gdpsagent-dependsOn-eez-engine

IBM.ManagedRelationship Dependency of the gdpsagenton the System AutomationApplication Manager

Notes and restrictionsWhen you configure high availability for a disaster recovery setup on two sites, thefollowing 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 orchrel commands. Using these commands might cause errors in the Define orRemove policy tasks of the configuration dialog. If you must change any policyelements, use the Validate & Store task of the configuration dialog, copy thecreated policy, and make your changes within the copied policy. You can thenactivate this changed policy by using the sampolicy command with the updateoption -u.

v Perform the configuration of the high availability policy for a disaster recoverysetup also on the other GDPS site.

v The high availability policy for a disaster recovery setup is only available on theLinux for System z® operating system.

v Every first-level automation adapter or remote agentless adapter must be able toswitch its event target if the active System Automation Application Managermoves to the other site. In the configurations of all adapters, specify the SystemAutomation Application Manager host names of both sites as the end-to-endautomation management host and the alternative end-to-end automationmanagement host. Specify the corresponding values on the Host Using Adaptertab in the configuration dialogs of the respective first-level automation adapter.

v Configuration of the local agentless adapter with the high availability policy fora disaster recovery setup is not supported. You must not configure the localagentless adapter.

Configuring Distributed Disaster RecoveryTo configure the Distributed Disaster Recovery feature, you need to configure theJMS destination for Geographically Dispersed Parallel Sysplex (GDPS) events, thehardware 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 “Configuringstorage replication” on page 146.


Configuring the destination for GDPS eventsConfigure a GDPS® server connection or backup server connection if it is notalready activated or configured during the installation of System AutomationApplication Manager.

About this task

Start the configuration utility cfgeezdmn and click Configure on the ApplicationManager tab of the task launcher window to open the Application Managercommon configuration. On the Event Publishing tab, configure the GDPS serverlocation and event port number. Optionally, you can configure also a GDPS backupserver and port.

After you completed the configuration, restart WebSphere Application Server orrefresh the end-to-end automation manager configuration by clicking Refresh onthe Application Manager tab of the task launcher window.

Configuring the GDPS agentSpecify user credentials for the end-to-end automation manager command shelland set up logging and tracing for the GDPS agent.

About this task

Start the configuration utility cfgeezdmn and click Configure on the ApplicationManager tab of the task launcher window to open the Application Managercommon configuration. On the Command Shell tab, specify a user ID andpassword, 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 byusing the system log configuration syslog.conf or corresponding configurationfile.

Configuring synchronous communication with GDPSGDPS communicates with the end-to-end automation manager throughsynchronous calls that are received by the GPDS agent. As soon as commands arepassed successfully to the automation engine they are acknowledged by the GPDSagent.

About this task

To ensure that the communication between GDPS and the GDPS agent isencrypted without needing to configure a password in GDPS, Secure Shell (ssh) isused 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.


The host key of the System Automation Application Manager server must beappended to $home/.ssh/known_hosts for the GDPS USS operator (dcmuser2 asdefined in GEOPLEX OPTIONS).On the end-to-end server system, the public key of the GDPS USS operator(dcmuser2) must be appended to the file <user>/.ssh/authorized_keys.

For more information about how to set up OpenSSH in UNIX System Services, seeIBM Ported Tools for z/OS.

Configuring the PowerHA adapterConfigure the adapter for High Availability Cluster Multi-Processing (PowerHA™)to integrate resources that are managed by a PowerHA cluster into the SystemAutomation Application Manager end-to-end automation environment.

The following figure shows in which environments the PowerHA adapter works.

The GUI mode of the adapter configuration utility is an X Window Systemapplication and must be used from a workstation with X Window System servercapabilities. On systems without X Window System Server capability, you can alsoconfigure the adapter in silent mode by using an input properties file. For moreinformation, see “Configuring the PowerHA adapter in silent mode” on page 185.

PowerHA adapter

RSCT/PowerHA

Node-1

Node-2

EIF

ip1

2001

Host name or service IP label

Request port

RSCT/PowerHA

PowerHAclusternodes

WebSphere Application Server

End-to-endmanagement

Event port 2002

Figure 16. Configuration of the PowerHA adapter


http://www.ibm.com/systems/z/os/zos/features/unix/port_tools.html

Starting the PowerHA adapter configuration dialogUse the cfghacadapter command to start the PowerHA adapter configurationdialog.

About this task

To use the PowerHA adapter configuration dialog, you must either be logged in onthe 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:

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 othernodes in the domain” on page 184.

v Click Define to define the PowerHA adapter automation policy to create theresources that are required to automate the adapter. For more information, see“Defining the PowerHA adapter automation policy” on page 185.

vClick Remove to remove the PowerHA adapter automation policy. For moreinformation, see “Removing the PowerHA adapter automation policy” on page185.

Figure 17. Application Manager Adapter Configuration - Task Launcher for PowerHA


Configuring the PowerHA adapter settingsClick Configure on the task launcher window of the configuration dialog toconfigure the PowerHA adapter settings.

About this task

In the following description, the term 'Host using the adapter' is used to refer tothe end-to-end automation manager host.

Adapter tabUse the Adapter tab to configure the parameters of the automation adapter host.


Host name or IP addressHost name or service IP label of the node where the adapter runs.

On initial invocation, the field contains the host name of the system wherethe configuration utility is running.

If you are automating the adapter, leave the value unchanged. The value isupdated automatically with the value you specify in the field Service IPlabel on the Automation tab. For more information, see “Automation tab”on page 180.

Request port numberSpecify the port number on which the adapter listens for requests from theend-to-end automation management host. The default port is 2001.

Click Advanced to specify the adapter run time behavior:

Adapter stop delayDefine the time that is measured in seconds within which the adapter stopis 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. Thevalue ranges between 3 through 60 seconds.

Remote contact activity intervalDefine the time that is measured in seconds after which the adapter stopsif it was not contacted by the end-to-end automation management host.The host periodically contacts the adapter to check whether it is stillrunning. The default value is 360. If a value other than 0 is specified, theinterval 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 intervalDefine the time that is measured in minutes, within which the adapterattempts to contact the end-to-end automation management host until itsucceeds or the specified time elapsed. The default value is 0, which meansthat the adapter attempts to contact the end-to-end automationmanagement host indefinitely.

Enable EIF event cachingSelect this check box to activate event caching.

EIF reconnect attempt intervalDefine the time that is measured in seconds, that the adapter waits beforeit attempts to reestablish the connection to the end-to-end automationmanagement host after the connection was interrupted. The default valueis 30 seconds.


Host Using Adapter tabUse the Host Using Adapter tab to configure the end-to-end automation managerhost the adapter connects to.

Controls and fields on the Host Using Adapter tab:

Host name or IP addressThe name or IP address of the host on which the end-to-end automationmanager runs.

Alternate hostA value for this field is optional. If you configured a disaster recoverysetup with two different sites for the System Automation ApplicationManager, the end-to-end automation manager might run on either site. Tosupport such a setup, also specify the host name or IP address of thesecond site. If an Application Manager switches the site, then the adapterswitches seamlessly to the new active end-to-end automation managerinstance as the target for sending events.

Event port numberThe port to which the end-to-end automation manager listens for eventsfrom the PowerHA adapter. The port number that is specified must matchthe port number that is specified as event port number when youconfigure domain of the end-to-end automation manager. The default portis 2002.

Note: If the communication between the end-to-end automation adapter and theend-to-end automation management host uses IPv6, then the following restrictionsapply.

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 returnIPv6 records only.

2. If the DNS server is configured to return IPv4 and IPv6 records, only the IPv4address is used. In case you want to use IPv6, explicitly specify the IPv6address instead of the host name in the configuration of the end-to-endautomation management host.

For the communication from the end-to-end automation management host to theadapter: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 IPv6address instead of the host name in the configuration of the adapter host.

Use the command host -n -a <ipv6_hostname> to check the DNS look-up records.

Automation tabUse the Automation tab to configure the adapter automation policy and to makethe end-to-end automation adapter highly available. If the node on which theadapter 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 sameuser ID and password.


Controls and fields and controls on the Automation tab:

Automate adapter in first-level automation domainSelect this check box if you want to make the adapter highly available in aPowerHA cluster. For more information, see “Automating the PowerHAadapter” on page 33.

Query domainIf the configuration dialog runs on a node in the PowerHA cluster, clickQuery domain to query the current automation policy from the PowerHAcluster. If the automation policy for the adapter is not yet defined but thecluster is up, at least all nodes that are online are shown in the Definednodes 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 onwhich the adapter can run.

v Down: Moves the selected node one position down in the nodesequence. The position determines the order in which automation selectsthe node on which the adapter can run.

v Add: Adds a node for adapter automation. Define the name of the nodeto be added and determine whether the node is to be added toautomation of the adapter.

v Remove: Removes the selected node from the list. The adapter must notbe started on that node.

v Change: Change the node for adapter automation. Change the name ofthe node and add or remove the node from automation of the adapter.

PowerHA root directorySpecify the root directory where PowerHA is installed.

Automated resources prefixThe prefix that is used to compose the names of the resource group,application, and application monitor in the automation policy. The resourcenames appear in the resource table on the operations console. The prefixcan be changed. Use no more than a total of 28 alphanumeric charactersand underscores. Do not use a leading numeric character. Reserved wordsare not allowed. For more information about reserved words, see List ofreserved words. If the PowerHA adapter policy is defined by using thecurrent prefix, remove this policy before you change the prefix. For moreinformation about defining the adapter automation policy, see “Definingthe PowerHA adapter automation policy” on page 185.

Service IP labelThe Service IP label is an entry in /etc/hosts that represents a service IPlabel. It must be different from the host name of any node in the PowerHAcluster. The service IP is requested by the network administrator as aservice IP label or alias for all nodes in the PowerHA cluster. The serviceIP must be created, for example by using the SMIT interface, before youstart the configuration dialog.

The PowerHA adapter listens on the service IP label for requests from theend-to-end automation management host, regardless on which node itruns.


http://www.ibm.com/support/knowledgecenter/?lang=en#!/SSPHQG_7.1.0/com.ibm.powerha.admngd/ha_admin_reserved_words.htm

http://www.ibm.com/support/knowledgecenter/?lang=en#!/SSPHQG_7.1.0/com.ibm.powerha.admngd/ha_admin_reserved_words.htm

Security tabUse the Security tab to configure security settings for the interface between thePowerHA adapter and the System Automation Application Manager host.


Secure Sockets Layer (SSL) protocol for data transport:

Enable SSLCheck to enable the Secure Sockets Layer (SSL) protocol. For moreinformation, see “Securing the connection to end-to-end adapters usingSSL” on page 300. The following entry fields are enabled:

TruststoreEnter the name of the truststore file that is used for SSL. The file namemight contain multiple period characters. Click Browse to select a file.

KeystoreEnter the name of the keystore file that is used for SSL. The file namemight contain multiple period characters. Click Browse to select a file.

Keystore passwordEnter the password of the keystore file. The password is required if akeystore file was specified. Click Change to change the password.

Note: Passwords must be identical if truststore and keystore are in twodifferent files.

Certificate aliasEnter the alias name of the certificate to be used by the server. If notspecified, the keystore file must contain only one entry, which is the one tobe used.

User authentication with Pluggable Access Module (PAM):

Enforce user authenticationCheck to enable user authentication with Pluggable Access Module (PAM).If not checked, user authentication is bypassed. If checked, userauthentication is enforced for the user ID on behalf of which theend-to-end automation management host requests operations from thePowerHA adapter.

PAM serviceSpecify an entry in the PAM service file /etc/pam.conf. This filedetermines which checks are made to authenticate the user. The defaultvalue is su, which checks users as if they were trying to run the commandsu.

Logger tabUse the Logger tab to configure the settings for logging, tracing, and First FailureData Capture. You can change the settings permanently or temporarily.

Note: The Logger tab always displays the values that are currently set in theconfiguration file.

On the Logger tab, you can perform the following tasks:

Change the settings permanentlyPerform these steps:1. Make the required changes on the tab.


2. Click Save.

Results: The settings in the configuration file are updated. You must restartthe adapter for the changes to take effect.

Change the settings temporarilyPerform these steps:1. Make the required changes on the tab.2. Click Apply.

Results: The new settings take effect immediately. They are not stored inthe configuration file. If the adapter is not running, you receive an errormessage.

Revert to the permanent settings If you changed the settings temporarily, perform the following steps torevert to the permanent settings defined in the configuration file, or whenyou 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.















First failure data capture (FFDC) message ID listThe message IDs that control for which log events FFDC data is written,depending on the filter mode. The comparison of message IDs iscase-sensitive. Each message ID must occur in a new line. Wildcardcharacters, for example, *E (for all error messages), are allowed.

Saving the PowerHA adapter configurationAbout this task

To save your changes to the adapter configuration files, click Save on theconfiguration dialog. Upon completion, a configuration update status window isdisplayed, showing which configuration files were updated. If errors occurredduring the update, the corresponding error messages are also displayed.

Note:

1. If you edit the Automation tab, a message appears reminding you to start theDefine 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 thedomain

If your PowerHA adapter is highly available, replicate the configuration files to theother cluster nodes.

About this task

Start the adapter configuration dialog and click Replicate.

Use the Replication Configuration Files window to distribute the PowerHA adapterconfiguration 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 thereplication separately for each target node.

3. Enter the user ID and password for the target nodes you want to replicate thefiles to.




Defining the PowerHA adapter automation policyUse 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 mainwindow of the configuration dialog. Resources with the resource nameResource-/group prefix are created as described in “Automated resources prefix”on page 181. If automated resources with the same name exist, they are removedbefore 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 automatedresources.

IBM.HacmpApplication hacadapter Commands: hacadapter start, hacadapter stop

IBM.HacmpAppMonitor hacadapter_mon Command: hacadapter status

IBM.HacmpServiceIP <service_ip_label> value The label of the service IP on which the host usingthe adapter accesses the adapter. This value is notdefined but queried and, therefore, not removed.

When you click Define, the button can stay indented for minutes until theresources are removed. The cluster is synchronized, new resources are created, andthe cluster is synchronized again. When processing is complete, the results of thecommands are displayed in a pop-up window.

Removing the PowerHA adapter automation policyUse the Remove task to deactivate the configured adapter automation policy if thepolicy is active.

About this task

Use the Remove function before you change the name prefix of the automatedresources. For more information, see “Automated resources prefix” on page 181.When the adapter is automated and you clear the check box Automate adapter insystem automation domain on the Automation tab, you receive a message thatreminds you to remove the automated resources for the adapter.

Clicking Remove on the main window of the configuration dialog removes theresources that are shown in Table 39. If the PowerHA adapter is still running, it isstopped before the automated resources are removed.

When you click Remove, the button can stay indented for minutes until resourcesare removed and the cluster is synchronized. Eventually, the results of thecommands are displayed in a pop-up window.

Configuring the PowerHA adapter in silent modeConfigure the PowerHA adapter in silent mode as an alternative to theconfiguration dialogs.


About this task

You can use the silent mode to configure the PowerHA adapter. For a detaileddescription of the silent mode configuration tasks, see “Configuring in silentmode” on page 203.

The following configuration tasks can be processed only by using the configurationdialogs or manually:v Replicating the PowerHA adapter configuration filesv Defining and removing the PowerHA adapter automation policy


Controlling the PowerHA adapterUse the hacadapter command to start, stop, and monitor the adapter.

About this task

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

Configuring the FOC adapterConfigure the adapter for Microsoft Failover Cluster (FOC).

Configure the FOC adapter to integrate resources that are managed by a MicrosoftFailover Cluster into the System Automation Application Manager end-to-endautomation environment. You can also configure the adapter in silent mode byusing an input properties file. For more information, see “Configuring the FOCadapter in silent mode” on page 192.

Starting the FOC adapter configuration dialogUse 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 configurationfiles to the right location. Use the following procedure to obtain a command linewith 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 thedialog is displayed:


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 moreinformation, see “Replicating the configuration files to other nodes in the domain”on page 192.

Configuring the FOC adapter settingsClick Configure on the task launcher window of the configuration dialog toconfigure the FOC adapter settings.

About this task

In the following description, the term 'Host using the adapter' is used to refer tothe end-to-end automation manager host.

Adapter tabUse the Adapter tab to configure the parameters of the host system on which theadapter is running and the parameters that are required for the automationdomain.


Automation adapter host

Host name or IP address

v If the FOC adapter is highly available, specify the network name or IPaddress you obtained as described in “Planning and preparing for anhighly available FOC adapter” on page 37.

v If the FOC adapter is not highly available, specify the IP address or hostname of the system on which the adapter is running.


Request port numberSpecify the number of the port on which the adapter listens for requestsfrom the end-to-end automation management host. The default port is2001.

Automation domain

Figure 18. Main window of the FOC Automation Adapter Configuration dialog


The domain name is the name by which the FOC cluster is known to theend-to-end automation management host. The domain name must be uniquewithin the scope of automation domains that connect to an end-to-end automationmanager 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 Portallaunch-in-context support. Open the Tivoli Enterprise Portal workspaces fromthe System Automation operations console, because Tivoli Enterprise Portal doesnot recognize any other domain name.

v If you cannot use the FOC cluster name as domain name, for example, becauseit 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 delayDefine the time period that is measured in seconds within which theadapter stop is delayed to allow the adapter to properly deliver thedomain leave event. The default value is 5. You can increase the value onslow systems. The value ranges between 3 through 60 seconds.

Remote contact activity intervalDefine the time period that is measured in seconds after which the adapterstops if it was not contacted by the end-to-end automation managementhost. The automation management host, periodically contacts the adapterto check whether it is still running. The default value is 360. If a valueother than 0 is specified, the interval must be a multiple of the checkinterval.


Initial contact retry intervalDefine the time period that is measured in minutes, within which theadapter attempts to contact the end-to-end automation management hostuntil it succeeds or the specified time elapsed. The default value is 0,which means that the adapter attempts to contact the end-to-endautomation management host indefinitely.

Enable EIF event caching Select this check box to activate event caching.

EIF reconnect attempt intervalDefine the time that is measured in seconds that the adapter waits before itreestablishes the connection to the end-to-end automation managementhost after the connection was interrupted. The default value is 30 seconds.


Fields on the Host using adapter tab:


Alternate hostA value for this field is optional. If you configured a disaster recoverysetup with two different sites for the System Automation Application


Manager, the end-to-end automation manager can run on either site. Tosupport such a setup, also specify the host name or IP address of thesecond site. An Application Manager site switch ensures that the adapterswitches to the new active end-to-end automation manager instance as thetarget for sending events.

Event port numberThe port on which the end-to-end automation manager listens for eventsfrom the FOC adapter. The port number that is specified here must matchthe port number that is specified as event port number when youconfigure the domain of the end-to-end automation manager. The defaultport is 2002.

Note: If the communication between the end-to-end automation adapter and theend-to-end automation management host uses an IPv6 IP version, then thefollowing restrictions apply.







Use the command nslookup <host name> [<dns server>] to check the DNS lookuprecords.

Security tabUse the Security tab to configure security settings for the interface between theFOC adapter and the System Automation Application Manager host.


Secure Sockets Layer (SSL) protocol for data transport:

Enable SSLCheck to enable the Secure Sockets Layer (SSL) protocol. For moreinformation, see “Securing the connection to end-to-end adaptersusing SSL” on page 300. The following entry fields are enabled.

TruststoreEnter the name of the truststore file that is used for SSL. The filename can contain multiple period characters. Click Browse toselect a file.


KeystoreEnter the name of the keystore file that is used for SSL. The filename can contain multiple period characters. Click Browse toselect a file.

Keystore passwordEnter the password of the keystore file. It is required if a keystorefile was specified. Click Change to change the password.

Note: If the truststore is in different file than keystore, thepasswords for the files must be identical.

Keystore aliasEnter the alias name of the certificate to be used by the server. Ifnot specified, the keystore file must contain only one entry, whichis the one to be used.

User authenticationCheck to enforce authentication of the user ID on behalf of which theend-to-end automation management host requests operations from theFOC adapter.



On the Logger tab, you can process the following tasks:

Change the settings permanentlyPerform these steps:1. Make the required changes on the tab.2. Click Save.

Results: The settings in the configuration file are updated. Restart theadapter for the changes to take effect.

Change the settings temporarilyPerform 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 inthe configuration file. If the adapter was not running, you receive an errormessage.

Revert to the permanent settings If you changed the settings temporarily, process the following steps torevert to the permanent settings defined in the configuration file. If you areunsure which settings are currently active for the adapter, proceed asfollows: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.

















Saving the FOC adapter configurationAbout this task

To save your changes to the adapter configuration files, click Save. Uponcompletion, a configuration update status window is displayed, showing whichconfiguration files were updated. If errors occurred during the update, thecorresponding error messages are also displayed.


Note: If not noted otherwise, you must restart the adapter for the changes tobecome effective.


If your FOC adapter is highly available, you must replicate the configuration filesto the other cluster nodes.

About this task


Use the Replicate Configuration Files window to distribute the FOC adapterconfiguration 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 thereplication separately for each target node.

3. Enter a local or domain user ID and password for the target nodes that youwant to replicate the files to. Domain user IDs must be specified in the form<user_ID>@<domain_name>.

4. Click Replicate to start the replication.


Configuring the FOC adapter in silent modeYou can configure the FOC adapter in silent mode as an alternative to using theconfiguration dialogs.

About this task

You can use the silent mode to configure the FOC adapter. For a detaileddescription of the silent mode configuration tasks, see “Configuring in silentmode” on page 203.

If you are using the configuration dialogs or if you configure manually, you canreplicate the FOC adapter configuration files.


Providing high availability for the FOC adapterAbout 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 ofthe FOC adapter. Click Actions > Configure a Service or Application .... The


High Availability Wizard opens. Depending on your system's settings, theBefore You Begin window can be displayed. If so click Next.

2. In the Select Service or Application window, select the Generic Serviceresource type and click Next.

3. On the Select Service window, select the SA AM MSCS Adapter service fromthe list of installed services. The FOC adapter must be installed successfully onall failover cluster nodes before. Click Next.

4. On the Client Access Point window, specify a valid new network name underwhich the FOC adapter is reachable. It must be ensured that the automationmanager to which the FOC adapter connects is able to resolve this networkname.If you do not want to use a network name for the FOC adapter, specify adummy name here and remove it later.Specify a valid IP address on which the FOC adapter can be reached. You mustensure that the automation manager to which the FOC adapter connects is ableto reach this virtual IP address.Use the network name or IP address you obtained as described in “Planningand 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 FOCadapter does not require any. Click Next.

6. On the Replicate Registry Settings window do not specify any registry keys, asthe FOC adapter does not require any. Click Next.

7. On the Confirmation window, check that all settings are correct. If so clickNext. If not click Previous to correct the settings.

8. On the Summary window, click Finish.

Configuring the VCS adapterConfigure the adapter for Veritas Cluster Server (VCS) for Solaris.

Configure the VCS adapter to integrate resources that are managed by a VCScluster on Solaris into the System Automation Application Manager end-to-endautomation environment.

The following figure shows the environment in which the VCS adapter works.


The GUI mode of the adapter configuration utility is an X Window System serverapplication and must be used from a workstation with X Window System servercapabilities. On systems without X Window System server capability, you can alsoconfigure the adapter in silent mode by using an input properties file. For moreinformation, see “Configuring the VCS adapter in silent mode” on page 203.

Starting the VCS adapter configuration dialogUse 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 thesystem 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 tasklauncher window of the dialog is displayed:

VCS adapter

Node-1

Node-2

EIF

Ip

2001

Host name or service IP label

Request port

VERITAS Cluster Server

VCSclusternodes

WebSphere Application Server

End-to-endmanagement

Event port 2002

SSL

VERITAS Cluster Server

Figure 19. Configuration of the VCS adapter


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 moreinformation, 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 policycreates the resources to automate the adapter. For more information, see “Definingthe VCS adapter automation policy” on page 202

Click Remove to remove the VCS adapter automation policy. For moreinformation, see “Removing the VCS adapter automation policy” on page 202

Configuring the VCS adapter settingsClick Configure on the task launcher window of the configuration dialog toconfigure the VCS adapter settings.

About this task

In the following description, the term Host using the adapter is used to refer to anend-to-end automation manager host.

Adapter tabUse the Adapter tab to configure the parameters of the host system on which theadapter is running and the parameters that are required for the automationdomain.

Controls and field on the Adapter tab:

Automation adapter host:

Figure 20. VCS Automation Adapter Configuration dialog


Host name or IP addressHost name or service IP label of the node where the adapter runs.


If you are automating the adapter, leave the value unchanged. The value isupdated automatically with the value you specify in the field Adapter IPaddress on the Automation tab (see “Automation tab” on page 198).

Request port numberSpecify the port number on which the adapter listens for requests from theend-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 theend-to-end automation management host. The domain name must be uniquewithin the scope of automation domains that connect to the end-to-end automationmanager.

You have the following options to specify the domain name:

Use the VCS cluster nameYou can use the VCS cluster name as the domain name. This option isselected by default. Keep this setting if you want to use Tivoli EnterprisePortal launch-in-context support. You can open Tivoli Enterprise Portalworkspaces from the System Automation operations console, because TivoliEnterprise Portal does not recognize any other domain name.

Specify a domain nameIf 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 theVCS cluster.

Click Advanced. A dialog opens to specify the adapter runtime behavior:

Adapter stop delayDefine the time that is measured in seconds within which the adapter stopis 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. Thevalue ranges between 3 through 60 seconds.

Remote contact activity intervalDefine the time that is measured in seconds after which the adapter stopsif it was not contacted by the end-to-end automation management host.The management host periodically contacts the adapter to check whether itis still running. The default value is 360. If a value other than 0 isspecified, the interval must be a multiple of the check interval.


Initial contact retry intervalDefine the time that is measured in minutes, within which the adapterattempts to contact the end-to-end automation management host until itsucceeds or the specified time elapsed. The default value is 0, which meansthat the adapter attempts to contact the end-to-end automationmanagement host indefinitely.

Enable EIF event caching Select this check box to activate event caching.


EIF reconnect attempt intervalDefine the time that is measured in seconds, that the adapter waits beforeit attempts to reestablish the connection to the end-to-end automationmanagement host after the connection is interrupted. The default value is30 seconds.


Fields on the Host using adapter tab:


Alternate hostA value for this field is optional. If you configure a disaster recovery setupwith two different sites for the System Automation Application Manager,the end-to-end automation manager can run on either site. To support sucha setup, also specify the host name or IP address of the second site. AnApplication Manager site switch ensures that the adapter switchesseamlessly to the new active end-to-end automation manager instance asthe target for sending events.

Event port numberThe port on which the end-to-end automation manager listens for eventsfrom the VCS adapter. The port number that is specified here must matchthe port number that is specified as event port number when youconfigure the domain of the end-to-end automation manager. The defaultport is 2002.

Note: If the communication between the end-to-end automation adapter and theend-to-end automation management host uses an IPv6 IP version, then thefollowing restrictions apply.







Use the command nslookup <host name> [<dns server>] to check the DNS lookuprecords.


Automation tabUse the Automation tab to configure the adapter automation policy to make theend-to-end automation adapter highly available. If the node on which the adapterruns 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 sameuser ID and password.

Controls and fields on the Automation tab:

Automate adapter in first-level automation domainSelect this check box if you want to make the adapter highly available in aVCS cluster. For more information, see “Automating the VCS adapter” onpage 40.

Query domainIf the configuration dialog runs on a node in the VCS cluster, click Querydomain to query the current automation policy from the VCS cluster. If theautomation 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. Thistable provides the following information:

Defined nodeThe list of defined nodes.

Automate on nodeIndicates 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 thenode 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 thenode on which the adapter can run.

Add Displays the Add node for adapter automation window to definethe name of the node to be added. Determine whether the node isto be added to the automation of the adapter.

RemoveRemoves the selected node from the list. The adapter must not bestarted on that node.

ChangeDisplays the Change node for adapter automation window tochange the name of the node. Add or remove the node from theautomation of the adapter.

Automated resources prefixThe prefix that is used to compose the names of the resource group,application, and application monitor in the automation policy. The resourcename appears in the resource table on the operations console. The prefixcan be changed. It is restricted to ASCII characters; the following characterscannot be used: " (double quotation mark), ’ (single quotation mark), ;(semicolon), $ (dollar), / (slash). If the VCS adapter policy is defined byusing 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.


Adapter IP addressRegardless on which node it runs, the end-to-end automation adapter usesthis address to listen for requests and receive requests from the end-to-endautomation management host. You must obtain this IP address from yournetwork administrator. The IP address must not be an actual host addressor localhost.

NetmaskThe netmask that is used in the adapter automation policy. Request a valuefrom your network administrator.

Network interfaceThe network interface that is used in the adapter automation policy. Theadapter can be reached on this network interface through the specified IPaddress.

Click Query to display the Select network interface dialog to select one ofthe network interfaces that are currently defined on the node where theconfiguration dialog runs.

Security tabUse the Security tab to configure the security settings for the interface between theVCS adapter and the System Automation Application Manager host.


Enable SSLCheck to enable the Secure Sockets Layer (SSL) protocol. For moreinformation, see “Securing the connection to end-to-end adapters usingSSL” on page 300. This enables the following entry fields.

TruststoreEnter the name of the truststore file used for SSL. The file name maycontain multiple period characters. Click Browse to select a file.

KeystoreEnter the name of the keystore file used for SSL. The file name maycontain multiple period characters. Click Browse to select a file.

Keystore passwordEnter the password for the keystore file. The password is required if akeystore file was specified. Click Change to change the password.

Note: Passwords must be identical if truststore and keystore are located intwo different files.

Certificate aliasEnter the alias name of the certificate that is used by the server. If notspecified, the keystore file must contain only one entry which is the one tobe used.

User authentication with Pluggable Access Module (PAM):

Enforce user authenticationClick to enable user authentication with Pluggable Access Module (PAM).If not checked, user authentication is bypassed. If checked, userauthentication is enforced for the user ID on behalf of which theend-to-end automation management host requests operations from the VCSadapter.


PAM serviceSpecify an entry in the PAM service file /etc/pam.conf. This filedetermines which checks are made to perform user authentication. Thedefault value is su, which checks users as if they were trying to execute thecommand su.



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 theadapter for the changes to take effect.

Change the settings temporarilyPerform these steps:1. Make the required changes on the tab.2. Click Apply.

Results: The new settings take effect immediately. They are not stored inthe configuration file. If the adapter is not running, you receive an errormessage.

Revert to the permanent settings If you changed the settings temporarily. Process the following steps torevert to the permanent settings defined in the configuration file, or whenyou 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.

















Saving the VCS adapter configurationAbout this task

To save your changes to the adapter configuration files, click Save on theconfiguration dialog. Upon completion, a configuration update status window isdisplayed, showing which configuration files were updated. If errors occurredduring the update, the corresponding error messages are also displayed.

Note:

1. If you edited the Automation tab, a message appears reminding you to start theDefine automation policy task.

2. If not noted otherwise, restart the adapter for the changes to become effective.


If your VCS adapter is highly available, replicate the configuration files to theother cluster nodes.


About this task


Use the Replicate Configuration Files window to distribute (replicate) the VCSadapter 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, replicateseparately for each target node.

3. Enter the user ID and password for the target nodes you want to replicate thefiles to.



Defining the VCS adapter automation policyUse 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 thetask launcher window of the configuration dialog. On this dialog window, you cancreate the resources with the resource name Resource-/group prefix as described in“Automated resources prefix” on page 198. If automated resources with the samename 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 allautomated resources.

Application vcsadapter-rs Commands: vcsadapter start,vcsadapter stop

IP vcsadapter-ip The virtual IP address on which thehost by using the adapter accessesthe adapter.

When you click Define, the button can stay indented for minutes until theresources are removed. The cluster is synchronized, new resources are created, andthen the cluster is synchronized again. When processing is complete, the results ofthe commands are displayed in a pop-up window.

Removing the VCS adapter automation policyUse the Remove task to deactivate the configured adapter automation policy if it isactive.


About this task

Use the Remove function before you change the name prefix of the automatedresources. For more information, see “Automated resources prefix” on page 198.When the adapter is automated and you clear the check box Automate adapter insystem automation domain on the Automation tab, you receive a message toremind you to remove the automated resources for the adapter.

Click Remove on the task launcher window of the configuration dialog removesthe resources that are shown in Table 40 on page 202. If the VCS adapter is stillrunning, it is stopped before the automated resources are removed.

When you click Remove, the button can stay indented for minutes until resourcesare removed and the cluster is synchronized. The results of the commands aredisplayed in a pop-up window.

Configuring the VCS adapter in silent modeYou can configure the VCS adapter in silent mode as an alternative to use theconfiguration 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 “Configuringin silent mode”

The following configuration tasks can be processed only by using the configurationdialogs 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 adapterAbout this task

Use the vcsadapter command to start, stop, and monitor the adapter. For adescription of the vcsadapter command options, see System Automation ApplicationManager Reference and Problem Determination Guide.

Configuring in silent modeConfigure System Automation Application Manager and the end-to-endautomation adapters without starting the configuration dialogs by using theconfiguration tool in silent mode. If you use the silent configuration mode, you donot need to have an X Window session available.

You can use the configuration tool in silent mode to configure the followingcomponents:v System Automation Application Manager, including agentless adapter, high

availability, and distributed disaster recovery configuration.v The PowerHA end-to-end automation adapter.


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 anassociated properties file. The parameter values in each properties file corresponddirectly to the values that you enter in the configuration dialog. You must firststart the configuration tool to generate silent mode input properties files beforeyou process a configuration update.

Working in silent modeThis topic describes the major tasks that you must process when you work in silentconfiguration mode.

About this task

To use the configuration tool in silent mode, you need to follow these steps foreach 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 theconfiguration tool again.

For some tasks, no silent configuration support is available. If you do not want touse the configuration dialogs, you must process these tasks manually. For moreinformation, see “Processing tasks manually.”

Processing tasks manuallyFor some tasks, no silent configuration support is available. If you do not want touse the configuration dialogs, you must process these tasks manually.

About this task

After configuration completed successfully, you might need to manually processsome 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 Automationfor Multiplatforms cluster whenever you changed the configuration of one ofthe System Automation Application Manager components. Run theconfiguration tool in silent mode with identical input properties files on eachsystem.

2. Some of the tasks that are described in “High availability for SystemAutomation Application Manager” on page 150. You can also use scripts thatare available to process these tasks.v Set up the domain.


a. Enter the preprpnode command on all nodes that you specified when youconfigured the System Automation Application Manager high availability.Do not enter preprpnode command on the node where you ran theconfiguration tool in silent mode.

b. Start the script eezha -createDomain <EEZ_CONFIG_ROOT>/eezautomate.properties on the local node to process all remainingactions to set up the cluster.

v Remove the domain.Start the script eezha -deleteDomain <EEZ_CONFIG_ROOT>/eezautomate.properties to remove the System Automation forMultiplatforms cluster that is used to make System Automation ApplicationManager highly available.

v Validate and store the automation policy for System Automation ApplicationManager.Start the script eezha -V -checkPolicy <EEZ_CONFIG_ROOT>/eezautomate.properties to validate the System Automation ApplicationManager automation policy as you configured it.

v Define a configured automation policy.Start the script eezha -activatePolicy <EEZ_CONFIG_ROOT>/eezautomate.properties to define the resources of theSystem Automation Application Manager automation policy. Make sure thatyou use the values that you specified when you configured SystemAutomation Application Manager high availability.

v Remove a configured automation policy.Start the script eezha -deactivatePolicy<EEZ_CONFIG_ROOT>/eezautomate.properties to remove the resources of theSystem Automation Application Manager automation policy. Make sure thatyou use the values that you specified when you configured SystemAutomation 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 adapterconfiguration files to the other nodes in the cluster. Run the configuration tool insilent mode for the respective adapter with identical input properties files on eachnode of the cluster.

If one of the end-to-end automation adapters is highly available in an PowerHA orVCS 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 theVCS adapter script mkvcsadapter -p to define the resources according to thevalues that are configured in the adapter automation policy.

2. Remove the automation policy.Start the PowerHA adapter script mkhacadapter -r and theVCS adapter script mkvcsadapter -r to remove the resources that match thevalues that are configured in the adapter automation policy.

Starting silent configurationUse command cfgeezdmn -s to start silent configuration.


About this task

Because silent configuration is an alternative to the configuration dialog, silentmode is started by using the same command. For each component, you specify theoption -s after the command to start the configuration tool.

Start silent configuration for each component:


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 AutomationApplication Manager common configuration:cfgeezdmn -s -e [-r]

b. Configure the System Automation Application Manager localagentless adapter, enter:cfgeezdmn -s -eu

c. Configure remote System Automation Application ManagerAgentless 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 AutomationApplication Manager highly available:cfgeezdmn -s -ea [-ad]

Use option -ad to configure the high availability policy for a two-sitedisaster recovery setup. If you do not specify -ad, the regular highavailability policy is configured.

The PowerHA end-to-end automation adapterEnter the following command to start the configuration tool in silent mode:cfghacadapter -s

The FOC end-to-end automation adapterEnter 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 adapterEnter the following command to start the configuration tool in silent mode:cfgvcsadapter -s

For more information about the cfgeezdmn, cfghacadapter, cfgmscsadapter, andcfgvcsadapter commands, see Tivoli System Automation Application Manager,Reference and Problem Determination Guide.


Silent mode input properties fileGenerate a silent mode input properties file from the values that are currentlyconfigured 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 optionswhen you start silent configuration:

-g Generate the input properties file only if it does not exist.

-grGenerate the input properties file and replace it if it exists.

-l locationThe input properties file for silent configuration is in the directory that isspecified with location. If -l is omitted, the input properties file is in the defaultdirectory <EEZ_CONFIG_ROOT>.

Depending on the target configuration, Table 41 shows the silent input propertiesfiles that are generated if the -g or -groption is specified.

Table 41. Generated input properties files

Component Target configuration Silent input properties file

System AutomationApplication Manager(common)

cfgeezdmn -s -e -g | -gr<EEZ_CONFIG_ROOT>/silent.eezcommon.properties

cfgeezdmn -s -e -g | -gr -l locationlocation/silent.eezcommon.properties

Local agentless adaptercfgeezdmn -s -eu -g | -gr

<EEZ_CONFIG_ROOT>/silent.eezaladapt.properties

cfgeezdmn -s -eu -g | -gr -l locationlocation/silent.eezaladapt.properties

Remote agentlessadapter cfgeezdmn -s -ru -o host -g | -gr

<EEZ_CONFIG_ROOT>/silent.remotealadapt.properties

cfgeezdmn -s -ru -o host -g | -gr-l location

location/silent.remotealadapt.properties

Hardware adaptercfgeezdmn -s -eh -g | -gr

<EEZ_CONFIG_ROOT>/silent.eezhwadapt.properties

cfgeezdmn -s -eh -g | -gr -l locationlocation/silent.eezhwadapt.properties

TPC-R domaincfgeezdmn -s -et -g | -gr

<EEZ_CONFIG_ROOT>/silent.eeztpcr.properties

cfgeezdmn -s -et -g | -gr -l locationlocation/silent.eeztpcr.properties


Table 41. Generated input properties files (continued)

Component Target configuration Silent input properties file

System AutomationApplication Managerhigh availability

cfgeezdmn -s -ea -g | -gr<EEZ_CONFIG_ROOT>/silent.eezauto.properties

cfgeezdmn -s -ea -g | -gr -l locationlocation/silent.eezauto.properties

cfgeezdmn -s -ea -ad -g | -gr<EEZ_CONFIG_ROOT>/silent.eezautodr.properties

cfgeezdmn -s -ea -ad -g | -gr-l location

location/silent.eezautodr.properties

PowerHA adaptercfghacadapter -s -g | -gr

<EEZ_CONFIG_ROOT>/silent.hacadapter.properties

cfghacadapter -s -g | -gr -l locationlocation/silent.hacadapter.properties

FOC adaptercfgmscsadapter -s -g | -gr

<EEZ_CONFIG_ROOT>\silent.mscsadapter.properties

cfgmscsadapter -s -g | -gr -l locationlocation\silent.mscsadapter.properties

VCS adaptercfgvcsadapter -s -g | -gr

<EEZ_CONFIG_ROOT>/silent.vcsadapter.properties

cfgvcsadapter -s -g | -gr -l locationlocation/silent.vcsadapter.properties

If you update configuration settings in silent mode, the silent properties file is usedas input for the update task. If you want the configuration tool to retrieve theinput file from a location other than in the <EEZ_CONFIG_ROOT> directory, use the -llocation option.

Editing the input properties fileModify the values in the input properties file to change the configuration in silentmode.

About this task

The input properties files that are generated for each of the components containconfiguration parameter keyword-value pairs. The structure, terminology, andwording of the properties content and the configuration dialog are identical. Thisfact makes it easy to switch between modes and minimizes errors when you editthe properties file

The names of tabs, for example Domain, on the configuration dialog are used asidentifiers in the properties file, for example:# ==============================================================================# ... Domain

Each field name on the configuration dialog, for example Domain name, iscontained in the properties file, followed by a brief description and the keywordfor 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


# 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 thefile is used.

2. Each value must be specified on one single line.

Output in silent modeInspect 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 outputthat closely matches the output that is displayed in interactive mode in the updatestatus dialogs or in the message boxes. The silent mode output falls into one of thefollowing categories:

No updateThere are no configuration updates to be saved. All parameters in all targetconfiguration files already match the specified silent input parameters. Noerrors were detected when the silent input parameters are checked. Ifadditional information is available or any warning conditions are detected,the information and warnings are reported. If warnings are reported, theconfiguration tool issues return code "1" rather than "0". You might need toobserve the return code when you start silent configuration, for examplewithin a shell script.

Successful completionAt least one of the target configuration files is updated and allconfiguration files and their update status are listed. No errors are detectedwhen you check the silent input parameters. If additional information isavailable or any warning conditions are detected, the information andwarnings are reported. If warnings are reported, the configuration toolissues return code "1" rather than "0". You might need to observe the returncode when you start silent configuration, for example within a shell script.

Unsuccessful completionNo target configuration file is updated. Any errors that are detected whenyou check the silent input parameters are reported. The configuration toolstops and issues return code "2".

Tasks that do not update configuration filesThe output for all Refresh and Test configuration tasks is a correspondingtask completion message.

Silent input properties file generationValues from the target configuration files are used to generate the inputfile. No target configuration file is updated.


Unrecoverable errorError messages report the reason for the error. The configuration tool stopsand issues a return code greater than "2".

Configuration properties filesConfiguration properties files are used to store the settings of System AutomationApplication Manager, and the PowerHA, FOC, and VCS adapter.

Configuration properties files of the System AutomationApplication Manager

During the installation of the System Automation Application Manager, theproperties in the files are set to values to work with the sample end-to-endautomation 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 ofthe System Automation Application Manager. The cfgeezdmn command ensuresthat the files are not corrupted during manual editing and that the change historyin the files is updated whenever a property is changed. It also ensures thatdependencies between parameter values in different properties files are observed.

The configuration properties files of the System Automation Application Managerare in the following directory:<EEZ_CONFIG_ROOT>

For example, /etc/opt/IBM/tsamp/eez/cfg

The following list describes the properties files that are changed when you modifya property value by using the cfgeezdmn configuration tool:

eezautomate.propertiesThe properties in this file are used to configure the end-to-end automationpolicy. This policy can be activated on a System Automation forMultiplatforms domain to make the System Automation ApplicationManager highly available. The configuration properties specify, forexample, 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 theautomation engine. The configuration properties specify, for example, thename of the end-to-end automation domain and the location of the policypool directory.

eez.automation.engine.dif.propertiesThe domain identification file of the automation engine contains the userIDs and the passwords to authenticate to first-level automation domainsand to the WebSphere Application Server JMS Provider.

eez.publisher.omnibus.propertiesThe properties in this file are used to configure settings to publish EIFevents to Tivoli Netcool/OMNIbus. The configuration properties specify,for example, the server and port of the OMNIbus Probe for Tivoli EIF andevent filters.


eez.publisher.gdps.propertiesThe properties in this file are used to configure the GDPS event server andport. It is required to use the System Automation Application Managerhardware adapter to manage hardware for distributed disaster recoverywith GDPS.

eez.publisher.gdpsbackup.propertiesThe properties in this file are used to optionally configure the GDPSbackup event server and port. It is required to use the System AutomationApplication Manager hardware adapter to manage hardware fordistributed disaster recovery with GDPS.

eez.fla.ssl.propertiesThis file contains the configuration properties for the SSL connection to thefirst-level automation domains.

eezjlog.propertiesThe properties in this file determine which information is written to thelog and trace files of the automation engine.

sas.eezcs.propertiesThe properties in this file determine whether users of the end-to-endautomation command shell must specify their user credentials to use thecommand shell.

sas.eezdmn.propertiesThe properties in this file determine how the end-to-end automationengine and the discovery library adapter access the WebSphere ApplicationServer and the automation Java Platform, Enterprise Edition framework.

eez.dla.propertiesThe properties in this file determine where the IdML books created by thediscovery library adapter are stored.

eez.hwadapter.propertiesThe properties in this file are used to configure the hardware adapter. Theconfiguration properties include, for example, the host and port thehardware adapter listens on, and the host and port of the automationengine it communicates with.

eez.hwadapter.plugin.propertiesThe properties in this file are used to configure credentials for thehardware devices when you configure distributed disaster recovery withGDPS.

eez.hwadapter.zent-1.plugin.propertiesThe properties in this file are used to configure the settings to access thezEnterprise Hardware Management Console (HMC) for virtual servermanagement.

eez.aladapter.propertiesThe 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 hostand port of the automation engine it communicates with.

eez.aladapter.dif.propertiesThe properties in this file are used to configure the user IDs and thecorresponding passwords that the local agentless adapter uses to accessremote non-clustered nodes. The resources that the agentless adapter starts,stops, and monitors are on remote nodes.


eez.aladapter.ssh.properties The properties in this file are used to configure security settings that arerelated to SSH private keys. SSH keys can be configured for userauthentication on remote non-clustered nodes as an alternative to configurecredentials in the eez.aladapter.dif.properties file for the local agentlessadapter.

eez.aladapter.ssl.propertiesThe properties in this file are used to configure Secure Sockets Layer (SSL)for transport between the automation manager and the local agentlessadapter.

eez.aladapter.jaas.propertiesThis file contains the configuration of the LoginModule that is used foruser authentication between the automation manager and the localagentless adapter.

eez.aladapter.plugin.propertiesThe properties in this file are used to configure settings that are unique forthe local agentless adapter. For example, the location of the XML policypool.

eez.aladapter.plugin.<domain>.propertiesFor each local agentless adapter domain, a domain-specific copy ofeez.aladapter.plugin.properties is created.

eez.tpcr.domain.propertiesThe properties in this file are used to configure settings of the TivoliStorage Productivity Center for Replication domain. TPC-R is used by theSystem Automation Application Manager to integrate storage replicationsessions into end-to-end automation policies.

<remote_node>/eez.aladapter.properties<remote_node>/eez.aladapter.dif.properties<remote_node>/eez.aladapter.ssh.properties<remote_node>/eez.aladapter.ssl.properties<remote_node>/eez.aladapter.jaas.properties<remote_node>/eez.aladapter.plugin.properties<remote_node>/eez.aladapter.plugin.<domain>.properties

These files are stored for each remote agentless adapter instance in asubdirectory for the node on which the remote agentless adapter isinstalled.

<remote_node>/eez.aladapter.jlog.propertiesThe properties in this file determine which information is written to thelog and trace files of an instance of the remote agentless adapter.

Configuration properties files of the PowerHA adapterConfigure the PowerHA adapter by setting the values in the configurationproperties file.

To change the values of the properties, use the cfghacadapter configuration tool ofthe PowerHA adapter. Use the configuration tool to make sure that the files are notcorrupted during manual editing. The change history in the files is updatedwhenever a property is changed. It also ensures that dependencies betweenparameter values in different properties files are observed.

The configuration properties files are in the following directory:<hacmp_adapter_conf_root>


For example:/etc/opt/IBM/tsamp/eez/hac/cfg

The following list describes the properties files that are changed when you modifya property value by using the cfghacadapter configuration tool.

hac.adapter.propertiesThe properties in this file are used to configure the PowerHA adapter. Forexample, the host and port on which the PowerHA adapter listens or thehost and port of the automation engine, with which the PowerHA adaptercommunicates.

hac.adapter.jaas.propertiesThis file contains the configuration of the LoginModule that is used foruser authentication between the automation manager and the PowerHAadapter.

hac.adapter.jlog.propertiesThe properties in this file determine which information is written to thelog and trace files of an instance of the PowerHA adapter.

hac.adapter.plugin.propertiesThe properties in this file are used to configure settings that are unique forthe PowerHA adapter.

hac.adapter.ssl.propertiesThe properties in this file are used to configure Secure Sockets Layer (SSL)for transport between the automation manager and the PowerHA adapter.

hac.adapter.confThis file describes the automation configuration to make the PowerHAadapter highly available.

Configuration properties files for the VCS adapterConfigure the VCS adapter by setting the values in the configuration propertiesfile.

To change the values of the properties, you use the cfgvcsadapter configurationtool of the VCS adapter. Use the configuration tool to make sure that the files arenot corrupted during manual editing. The change history in the files is updatedwhenever a property is changed. It also ensures that dependencies betweenparameter values in different properties files are observed.

The configuration properties files are in the following directory:<vcs_adapter_conf_root>

For example,/etc/opt/IBM/tsamp/eez/vcs/cfg

The following list describes the properties files that are changed when you modifya property value by using the cfgvcsadapter configuration tool:

vcs.adapter.propertiesThe properties in this file are used to configure the VCS adapter. Forexample, the host and port on which the VCS adapter listens or the hostand port of the automation engine, with which the VCS adaptercommunicates.


vcs.adapter.jaas.propertiesThis file contains the configuration of the LoginModule that is used foruser authentication between the automation manager and the VCS Solarisadapter.

vcs.adapter.jlog.propertiesThe properties in this file determine which information is written to thelog and trace files of an instance of the VCS adapter.

vcs.adapter.plugin.propertiesThe properties in this file are used to configure settings that are unique forthe VCS adapter.

vcs.adapter.ssl.propertiesThe properties in this file are used to configure Secure Sockets Layer (SSL)for transport between the automation manager and the VCS adapter.

vcs.adapter.confThis file describes the automation configuration to make the VCS adapterhighly available.

Configuration properties files of the FOC adapterConfigure the FOC adapter by setting the values in the configuration propertiesfile.

To change the values of the properties, you use the cfgmscsadapter configurationtool of the FOC adapter. Use the configuration tool to make sure that the files arenot corrupted during manual editing. The change history in the files is updatedwhenever a property is changed. It also ensures that dependencies betweenparameter values in different properties files are observed.

The configuration properties files are in the following directory:<mscs_adapter_conf_root>

For example,C:\Program Files\IBM\tsamp\eez\mscs\cfg

The following list describes the properties files that are changed when you modifya property value by using the cfgmscsadapter configuration tool:

mscs.adapter.propertiesThe properties in this file are used to configure the FOC adapter. Forexample, the host and port on which the FOC adapter listens or the hostand port of the automation engine, with which the FOC adaptercommunicates.

mscs.adapter.jlog.propertiesThe properties in this file determine which information is written to thelog and trace files of an instance of the FOC adapter.

mscs.adapter.plugin.propertiesThe properties in this file are used to configure settings that are unique forthe FOC adapter.

mscs.adapter.ssl.propertiesThe properties in this file are used to configure Secure Sockets Layer (SSL)for transport between the automation manager and the FOC adapter.


Chapter 4. Integrating

System Automation Application Manager integrates with a set of Tivoliapplications to extend its existing functionality. The integration scenarios requirespecific configurations to meet your infrastructure needs.

Find out how to configure System Automation Application Manager to worktogether 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 SystemAutomation 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 anagentless 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 consolesSystem Automation Application Manager sends EIF events to Tivoli®

Netcool/OMNIbus (OMNIbus). OMNIbus is a rule-based event managementapplication that uses a central server to process incoming events. For compatibilityreasons, alternatively a Tivoli Enterprise Console® (TEC) server or any other serverthat is capable to process EIF events may also be configured.

Event sources:v Tivoli applicationsv Tivoli partner applicationsv Customer applicationsv Network managementv Relational database systems

For System Automation Application Manager an event is generated and forwardedto the TEC or OMNIbus event console in the following cases:


v The configuration of System Automation Application Manager or the state of anautomated resource changes, which is contained in the end-to-end automationpolicy.

v Problems are encountered

If you want to use System Automation events with Tivoli Business ServiceManager (TBSM), forward the events to OMNIbus.

System Automation Application Manager can produce the following types ofevents:

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 existingresource is deleted or modified.

SystemAutomation_Relationship_Configuration_Change A new relationship is added or an existingrelationship is deleted or modified.

SystemAutomation_Domain_Status_Change The domain status changed. For example:

v The automation manager or the automationadapter of the domain starts or stops.

v A new automation policy is activated.

SystemAutomation_Request_Configuration_Change A new request is issued against an automatedresource or an existing request is canceled.

SystemAutomation_Request_Status_Change A GDPS command is completed. Only used in theDistributed Disaster Recovery with GDPS feature.

The following topics describe how to set up System Automation ApplicationManager and the event consoles to enable event forwarding to either TEC orOMNIbus.

IBM Tivoli Netcool/OMNIbusThis topic describes how to set up IBM Tivoli Netcool/OMNIbus to forwardSystem Automation events to the OMNIbus event console and how to set uplaunch-in-context support for OMNIbus. This OMNIbus set up is also aprerequisite for the integration of System Automation Application Manager withTivoli Business Service Manager.

PrerequisitesAs System Automation Application Manager and IBM System Automation forMultiplatforms use Tivoli Event Integration Facility (EIF) events forcommunication, the following components are required:v IBM Tivoli Netcool/OMNIbus (OMNIbus)v OMNIbus Probes Library for Nonnative Basev 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.0v IBM Tivoli Netcool/OMNIbus 7.2.1


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 TivoliNetcool/OMNIbus Knowledge Center.

Environment variables:

$NCHOMERefers to the Netcool® Home Directory into which the packages areinstalled. Default directory under Linux: /opt/IBM/tivoli/netcool.

$OMNIHOMEThe $OMNIHOME variable is used to provide legacy support for scripts,third-party applications, and probes that continue to use the $OMNIHOMEenvironment variable. $OMNIHOME refers to $NCHOME/omnibus.

Event fields in OMNIbus databaseThe OMNIbus alerts.status table is extended with the following new columns tohold System Automation specific information. They are filled in the SystemAutomation 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 anoperator.

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

http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html

http://www.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html

Table 44. alerts.status: Resource, domain, event identification

SADomainName varchar(64) Name of the Automation Domain. Part of the resource key to identifya resource.Note: Corresponds to sa_domain_name in TEC events

SAResourceName varchar(255) Name of the resource. This is a compound resource name consisting ofthe resource name itself concatenated with the resource class andoptionally the resource node. The order of the name parts and theseparator character depends on the sending System Automationproduct.

For SAMP and SAAM:

<class_name>:<resource_name>:<node_name>

For SA z/OS:

<resource_name>:<class_name>:<node_name>

Note: <node_name> is only set if it exists. For System AutomationApplication Manager resource references, the node name contains thename of the referenced first level automation domain. Corresponds tosa_resource_name in TEC events.

SAEventReason varchar(255) Event reasons. One event can have multiple event reasons in TECevent. 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 referencedresource 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 desiredstorage replication direction (SAAM only). Used in resource statuschange events.Note: Corresponds to sa_role_desired in TEC events.

SAObservedRole varchar(16) Observed role. Used for replication references indicating theobserved storage replication direction (SAAM only). Used inresource 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.


Table 46. alerts.status: Domain status change events (continued)

SACommunicationState varchar(32) This state reflects the connection and availability state of thedomain. 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 fieldswill 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 <host name>.

Agent Descriptive name of the manager that generated the event.

Value for System Automation Application Manager events: IBM Tivoli SystemAutomation 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 alist of possible event classes.

AlertKey Descriptive key that indicates the resource that triggered the event. For resource events, itcontains 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 resourcedetermines the severity level. The color of the event in the event list is controlled by theseverity 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 ObjectServerdeduplication. The ObjectServer uses deduplication to ensure that event informationgenerated from the same source is not duplicated in the event list. Repeated events areidentified using the Identifier attribute and stored as a single event to reduce the amountof data in the ObjectServer. For System Automation events, the Identifier field is set toAlertKey + ":" + AlertGroup. Therefore, the event console displays always the last eventof the same resource and AlertGroup.


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

ExtendedAttr Holds name-value pairs of additional internal System Automation specific attributes, forwhich no dedicated column exists in the alerts.status table.

In addition to these attributes which are stored in the OMNIbus alerts.statustable, extra information is written to the alerts.details table. For example, fordomain events the product name and version of the automation productcorresponding to the domain are stored in the alerts.details table.

Compound state to severity mappingFor events that contain a SACompoundState value, for example all resource statechange 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 examplerequest events or domain events, the EIF severity field is used to determine theOMNIbus 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 theExtendedAttr field of an event.

Configuring OMNIbus to process System Automation eventsAbout this task

Updating the OMNIbus database:

The OMNIbus ObjectServer database includes the alerts.status table whichcontains all fields that are shown and selected by an event list.

About this task

For System Automation events, the additional columns described in “Event fieldsin OMNIbus database” on page 217 have to be created in the alerts.status table.


The sa_db_update.sql file creates the new columns in the alert.status table. Theevent 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 isused 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 ApplicationManager product DVD in the directory /integration.

Note: The event class 87725 is predefined in OMNIbus Version 7.3.1 or higher. Ifyou run the sa_db_update.sql script using OMNIbus Version 7.3.1, you receive thefollowing error message:ERROR=Attempt to insert duplicate row on line 2 of statement ’insert intoalerts.conversions values ( ’Class87725’,’Class’,87725,’Tivoli SystemAutomation’ );...’

You can ignore this error message.

Verify that the System Automation specific columns and event class has beensuccessfully 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. SACompoundStateb. SADesiredStatec. SAObservedStated. SAOperationalStatee. SADomainNamef. SAResourceNameg. SAReferencedResourceh. SAEventReasoni. SAExludedFromAutomationj. SADesiredRolek. SAObservedRolel. SADomainStatem. SACommunicationState

6. From the Netcool/OMNIbus Administrator window, select the Visual menubutton.


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 analert. For each alert, the rules file also creates an identifier that uniquely identifiesthe problem source. The probe for Tivoli EIF uses a standard rules file namedtivoli_eif.rules. System Automation Application Manager ships the SystemAutomation specific rules file tivoli_eif_sa.rules. This file needs to be includedwithin the default tivoli_eif.rules using an include statement. The rules filetivoli_eif_sa.rules processes an EIF event received by the probe for Tivoli EIF ifthe event field source contains the value SystemAutomation.

The default tivoli_eif.rules file is located on the system where the probe forTivoli EIF is installed in the following directory:Windows: %OMNIHOME%\probes\<os_dir>\tivoli_eif.rulesUNIX: $OMNIHOME/probes/<os_dir>/tivoli_eif.rules

Perform the following steps to enable the tivoli_eif_sa.rules file:1. Copy the file tivoli_eif_sa.rules, which is located in the /integration

directory on the System Automation Application Manager product DVD to thesystem where the OMNIbus probe for Tivoli EIF is installed. As a targetdirectory 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.rulesfile that is used in the probe for Tivoli EIF and add an include statement for thetivoli_eif_sa.rules file.The content of the tivoli_eif.rules looks different depending on the type ofOMNIbus installation you have:a. If you use a standalone OMNIbus installation:

Open tivoli_eif.rules file in a text editor and add the include statementafter the switch($source) block::else{

switch($source){

case "dummy case statement": ### This will prevent syntax errors in caseno 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 TECinclude "tivoli_eif_default.rules"

}include "tivoli_eif_sa.rules"

}

b. If you integrate with Tivoli Business Service Manager (TBSM) and use theOMNIbus version packaged with TBSM:Open the tivoli_eif.rules file in a text editor and add the includestatement in the block where the predefined rules files are included. Search


for the line # Include customer rules which would override any previousrules. and add the include statement for tivoli_eif_sa.rules before thisline:::###### 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 <probe_name>

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

Note:

1. You can test your changes in the rules file using the syntax checking toolnco_p_syntax delivered with the OMNIbus server. Use the root rules filetivoli_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 losingevents, enter the following command:kill -HUP <pid>


pid is the probe process ID. You can determine the pid using the nco_pa_statuscommand.

Configuring Tivoli Netcool/OMNIbus launch-in-contextThe launch-in-context support for System Automation Application Managernavigates from an event that is displayed in the OMNIbus active event list to thecorresponding 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 correspondingevent is forwarded to OMNIbus.

2. An operator sees an error event in the OMNIbus active event list that indicatesthat an automated application has failed.

3. For further analysis, he selects the event and clicks on a menu entry to launchthe operations console.

4. A new browser window is opened and connects to the IBM DashboardApplication Services Hub which automatically launches the operations console.

5. The System Automation operations console automatically navigates to theapplication that caused the error event and selects it.

6. The operator now sees all detailed status information, relationships, etc. as theyare provided by System Automation.

Creating a launch-in-context tool:About this task

Create a launch-in-context tool which launches the System Automation operationsconsole 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://<ISC_HOST>:<ISC_PORT>/ibm/EEZUIWebClient/

EEZIscUrlBuilderServlet. ISC_HOST is the system where the SystemAutomation Application Manager operations console is running. ISC_PORT isthe secure port for the IBM Dashboard Application Services Hub hosting theSystem Automation operations console.

6. Click the Fields: Show button and select the following fields that should bepassed as context arguments to the URL:v SADomainNamev SAResourceNamev Summary

7. Select Method: GET

8. Select Open In -> Specific Window and type a window name, for exampleSystemAutomation. So that launches from OMNIbus always use the samewindow to open the System Automation operations console.

9. In the Access Criteria section, select the Class tab and choose the TivoliSystem Automation class from the list of available event classes. This ensuresthat the launch-in-context tool is only available for events of System


Automation.

Note: If you have more than one System Automation Application Managerinstallation, 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 menuentry to display the launch-in-context tool.

To add the new launch-in-context tool to the active event list tools menu, performthe 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) andclick Modify.

3. Select the new launch-in-context tool from the Available items list and add itto the list of Current items.

4. Click Save to store the modified configuration of the tools menu.

Figure 21. Sample configuration of launch entry


Tivoli Enterprise ConsoleThis topic describes how to set up the Tivoli Enterprise Console to forward SystemAutomation events to the TEC and how to set up launch-in-context support for theTEC.

PrerequisitesTo install and use the IBM TEC Extension for System Automation ApplicationManager, the following prerequisites must be met:

TEC versionTEC 3.8 or later

Web browserIf you use the Java version of the TEC Event Console to launch to theSystem Automation operations console, make sure a web browser likeMozilla, Firefox, or Internet Explorer is installed on the system where theevent console runs.

Configuring TEC to process System Automation eventsAbout this task

The programming language Basic Recorder of Objects in C (BAROC) is used todefine the structure of events and their properties. These definitions are stored infiles with the extension .baroc. The baroc file for System Automation events is

Figure 22. Modifying menu entries that are displayed in the Tools menu


called SystemAutomation.baroc and is located in directory <EEZ_CONFIG_ROOT> afterthe installation. To prepare TEC to use with System Automation ApplicationManager, 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 supportThe IBM Tivoli Enterprise Console (TEC) extension for System AutomationApplication Manager (IBM TEC Extension) allows to navigate from an event that isdisplayed in the Event Console of Tivoli Enterprise Console (TEC Event Console)to the corresponding resource or domain in the System Automation operationsconsole.

About this task

Example usage scenario:

1. An operator sees an event in the TEC Event Console that shows that a TivoliSystem Automation resource failed.

2. The operator selects the event and starts the System Automation operationsconsole for this event.

3. The System Automation operations console automatically navigates to theresource specified in the event.

4. The operator analyzes the error by checking, for example, the resource statusand dependencies.

The IBM TEC Extension can be used for all TEC Event Console setups:v Java version of the TEC Event Consolev TEC web consolev 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 “Enablinglaunch-in-context feature” on page 228.

You only need to perform the installation steps described in this topic if you areusing the Java version of the TEC Event Console or the TEC event viewerembedded 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 onthe system where the TEC Event Console runs.

v When you are using the TEC event viewer embedded in the TEP and the TEP isstarted using the browser client interface, the IBM TEC Extension for SystemAutomation Application Manager needs to be installed on the system where thebrowser runs.


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

Example:"C:\Program Files\IBM\TECExtension\EEZLaunchSA.bat" C:\IBM\tec_console\jre\bin\

For AIX and Linux:<path>EEZLaunchSA.sh [<java home>]

where <path> is the directory in which the TEC Extension for SystemAutomation was installed and the optional parameter <java home> isthe Java home directory where the file java.exe can be found. Thisparameter must end with a / (slash).Java 1.3 or higher is required. If the path contains blanks it must beenclosed in quotes (“).

6. Ensure that you have enabled “Event selection required for buttonaction”.

Web TEC Event Console

For the definition of a web custom button, the Java version of the TECEvent 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.


3. Select the Web Custom Button entry from the list on the left side of thewindow.

4. Click Create Button.5. Enter a label for the button, for example, “Launch SA Console”, and the

URL of the servlet:http://<isc_server>:<isc_port>s/ibm/EEZUIWebClient/EEZIscUrlBuilderServlet

where <isc_server> is the name of the host where the IBM DashboardApplication Services Hub runs which hosts the operations console and<isc_port> 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 buttonaction.

Enabling event generation in System Automation ApplicationManager

If you want to send System Automation events to OMNIbus, enable eventforwarding in System Automation Application Manager.

About this task

If you have not activated or configured the EIF event generation and forwardingfunction during the installation of System Automation Application Manager, youcan 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 ApplicationManager common configuration.

Enabling event filteringWhen you use the event console of the Tivoli Enterprise Console (TEC) or IBMTivoli Netcool/OMNIbus products to display events, all end-to-end automationevents 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 EventPublishing tab of the end-to-end automation configuration tool to achieve thefollowing 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.


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 theevent console cannot automatically clear errors that are based on events thathave 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-endautomation 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 alertseffectively, to be in line with business requirements, and optionally to meetservice-level agreements (SLAs).

TBSM tools help you to build a service model that you integrate with IBM TivoliNetcool®/OMNIbus™ alerts or optionally with data from an SQL data source.

The TBSM Data server analyzes IBM Netcool/OMNIbus ObjectServer events orSQL data for matches against the incoming-status rules you configured for yourservice models. If the matching data changes the service status, the status of theTBSM service model changes accordingly. When a services status changes, TBSMsends corresponding service events back to the ObjectServer.

The Discovery Library Toolkit creates TBSM service objects which use data fromDiscovery Library Adapter (DLA) books or from the IBM Tivoli ApplicationDependency Discovery Manager.

The TBSM console provides a graphical user interface (GUI). It runs in the TivoliIntegrated Portal (TIP) and logically links services and business requirementswithin the service model. The service model provides an operator with a view ofhow an enterprise performs at a certain moment in time or did perform over acertain time period.

The following figure shows the basic architecture of TBSM:


Main components:

Tivoli Integrated PortalTivoli Integrated Portal enables the interaction and secure passing of databetween Tivoli products through a common portal. You can launch variousapplications within the same dashboard view to investigate differentaspects of your managed enterprise.

Tivoli Netcool/OMNIbusTBSM monitors the Tivoli Netcool/OMNIbus ObjectServer for incomingevents. The ObjectServer collects events from probes, monitors, and otherapplications such as IBM Tivoli Monitoring. You use TBSM to createservice models that respond to the data received in the incoming events.For example, the incoming event data can change the status of a service orstart the tracking of a potential SLA violation.

Tivoli Netcool/Webtop (OMNIbus web GUI)Netcool/Webtop is the browser console for Netcool/OMNIbus and TBSMuses Netcool/Webtop components to display events that are related toservice models. The Active Event List (AEL) and Service Details portlet inTBSM are Netcool/Webtop components, and are installed as part of TBSM.The Tivoli Integrated Portal also includes Netcool/Webtop components.

TBSM dashboard serverThe TBSM dashboard server manages the display of the TBSM console andcommunicates with the TBSM data server. This interaction between thedifferent TBSM components facilitates to create and visualize servicemodels using connected TBSM consoles. Users working with the consoleview mainly only parts of the service model. Therefor the dashboard serveracquires and maintains status of services from the data server.

TBSM data serverThe TBSM data server monitors the ObjectServer and external databases

Databases

Event sources

Tivoli ApplicationDependencyDiscovery Manager

DiscoveryLibrary Books

Netcool/OMNIbusObjectServer

EIF Probe

User RepositoryLDAP orObjectServer

Netcool/Impact

Probes Monitors

ITCAM forInternet ServiceMonitoring

Event Pumpfor z/OS

Tivoli EnterpriseConsole

NetView

IBM TivoliMonitoring

OMEGAMON

ITCAM

Tivoli Intergrated Portal

Historical data

Servicemodeldata

Discovery data

Events

Events

Events EIF events

User data

Data for service models,custom charts, views,nearterm history metric,and marker data(Time Window Analyzer)TBSM Dashboard

Server

Tivoli DataWarehouse

OMNIbusWeb GUI

TBSMData Server

TBSMCommonAgent

Discovery Library Toolkit

Sources for EIF events

IBM TivoliSystemAutomation

Other components

OMNIbus components

TBSM components

Figure 23. TBSM basic architecture


for data that affect the status of the services. These services are configuredin the TBSM console or with the RAD shell command-line tool. The servercalculates the status of these services by applying rules to the externaldata. Your service models and the rules are stored in the TBSM database.

Integrating with System Automation Application ManagerAbout this task

Business applications typically consist of different middleware components, aremulti-tiered, and run on heterogeneous platforms. Tivoli Business Service Manager(TBSM) provides health information about the multi-tiered application. TBSM alsomonitors service level agreements (SLA) based on information coming fromnumerous sources. Netcool/OMNIbus is used to collect all events that are relatedto the business application landscape and TBSM uses these events to determine thestatus of the business applications.

System Automation Application Manager can be used to integrate with TBSM inthe following ways:v Data from System Automation events can be used to enrich TBSM service views.

System Automation Application Manager delivers a TBSM service templatecontaining pre-configured rules how to map states from System Automation toTBSM service instances.

v The integration of System Automation Application Manager resources withTBSM can be automated and simplified using the Discovery Library Adaptor(DLA). With this approach, System Automation Application Manager resourcesare automatically imported into a TBSM service model and related TBSM statusrules are automatically assigned. System Automation Application Managerevents are automatically matched with the right TBSM service instances withoutmanual configuration.

v Launch-in-context from a TBSM service view to the System Automationoperations console and vice versa allows an operator to easily see theinformation about a specific application from both products. For example, withthis 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 operationsconsole to start or stop this business application.

PrerequisitesBefore you begin, install and configure the following products and test yourinstallation:v Configure and enable event forwarding to OMNIbus for System Automation

Application Manager events. For more information, see “Configuring OMNIbusto process System Automation events” on page 220 and “Enabling eventgeneration in System Automation Application Manager” on page 229.

v If you want to include System Automation for Multiplatforms resources inTBSM service trees, enable event forwarding to OMNIbus for SystemAutomation for Multiplatforms events. For more information, see IntegratingSystem Automation resources and TBSM.

v Tivoli Business Service Manager (TBSM) V4.2.1 or higherv Update the Netcool OMNIbus ObjectServer schema for TBSM.

– If you have an existing OMNIbus server, import the schema filestbsm_db_update.sql and ClearServiceDeps.auto.

– If OMNIbus is installed with TBSM, the TBSM installer performs the requiredschema updates.


http://www.ibm.com/support/knowledgecenter/SSRM2X_4.1.0.1/com.ibm.samp.doc_4.1.0.1/sampicintegrating_sa_resources.html?lang=en

http://www.ibm.com/support/knowledgecenter/SSRM2X_4.1.0.1/com.ibm.samp.doc_4.1.0.1/sampicintegrating_sa_resources.html?lang=en

For more TBSM specific product information, see Tivoli Business Service ManagerKnowledge Center.

Configuring TBSMAbout 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, onetemplate can be created for a type of service and then be assigned to applicableservices.

Service instances represent actual services that are assigned a template. Thetemplate defines how a service responds to incoming data and the status of otherservices. Services of the same type should be assigned to a common template. Thisallows 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 morethan once.

System Automation Service Template for TBSMSystem Automation Application Manager provides a TBSM Service Template thatis used for System Automation resources which are displayed in a TBSM servicetree. The Service Template is named EEZ_SystemAutomationResource. It providesv An Incoming Status Rule named SACompoundState which uses state change

events coming from System Automation resources to determine the overall stateof services.

v Text-based Incoming Status Rules, which export the System AutomationObserved State and other System Automation specific states of a resource, sothat they can be used in TBSM Views. For more information, see “CustomizingTBSM views to add information from System Automation” on page 242.

v Additional properties that allow launch-in-context to the System Automationoperations console. For more information, see “Configuring Tivoli BusinessService Manager launch-in-context support” on page 246.

The EEZ_SystemAutomationResource Service Template contains an incoming statusrule named SACompoundState which determines the overall state of a service. Ifthe Service Template has been assigned to a specific service instance, resource statechange events coming from System Automation will influence the overall state ofthe service. Events are associated with a service instance if the AlertKey in theevent matches the AlertKey defined as identifier for the service instance.

TBSM has three available overall states: Bad, Marginal, and Good. The followingmapping is defined in the SACompoundState rule to map resource state changeevents 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)


http://www.ibm.com/support/knowledgecenter/SSSPFK/welcome

Since there is a one-to-one mapping from a resource’s compound state to the eventseverity, the System Automation compound state directly determines the TBSMstate. For more information about the mapping of compound state to eventseverity, refer to “Compound state to severity mapping” on page 220.

Defining a System Automation service template in TBSMAbout this task

The EEZ_SystemAutomationResource template is required to use System Automationevents in TBSM, import the EEZ_SystemAutomationResource template into TBSM asfollows:1. Copy the file EEZ_SystemAutomationResource.radsh from the /integration

directory of the System Automation Application Manager product DVD to atemporary directory where the TBSM data server is installed.

2. Open a command prompt on the TBSM data server system. Change to thedirectory to which you have copied EEZ_SystemAutomationResource.radsh andissue 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/OMNIbusAbout this task

In the OMNIbus ObjectServer, a new state change event for a resource replaces theprevious event. This is called event deduplication.

By default, TBSM only processes a de-duplicated event when the value of theSeverity field changed. In these cases, TBSM processes the de-duplicated eventsand updates the service status accordingly. A status change is possible for a SystemAutomation resource which updates status fields used in the text-based incomingstatus rules which are contained in the EEZ_SystemAutomationResource servicetemplate. But the severity value does not change because the compound state ofthe resource does not change. Define a trigger in OMNIbus, to ensure that TBSMupdates the services in these cases as well.

The sa_db_tbsm_update.sql file is used to define the trigger namedupdate_tbsm_service_on_sa_events in OMNIbus. This trigger ensures that TBSMreprocesses events if one of the states that are used in the text-based incomingstatus rules changes, even if the severity value does not change. Whenever youwant to use the text-based incoming status rules included in theEEZ_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


Enter password when prompted.

sa_db_tbsm_update.sql is shipped with System Automation Application Managerand can be found in the directory /integration on the product DVD.

Configuring the Discovery Library ToolkitAbout this task

System Automation Application Manager provides a Discovery Library Adapter(DLA) to export the currently active System Automation Application Managerresource topology to an Identity Markup Language (IdML) discovery book. Formore information, refer to “Working with the discovery library adapter” on page287. You can use the Discovery Library Toolkit of TBSM to create TBSM servicemodels 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 definedin the end-to-end automation policy.

v Assign the System Automation Service Template containing the incoming statusrules to the TBSM services.

v Match System Automation Application Manager events with the TBSM serviceinstance without manual configuration.

v Define the launch-in-context parameters of a service instance to enable launchingto the System Automation operations console in context of the service instance.

IdML books are XML files in the Identity Markup Language (IdML) format. TheseXML files conform to the IBM Common Data Model (CDM) and can be generatedby a variety of systems and applications. They are used by the Discovery LibraryToolkit to discover resources and relationships in a given environment.

This topic describes how you can set up the Discovery Library Toolkit to enableTBSM to discover a service tree based on the active System AutomationApplication Manager resource topology.

Make sure the following products are installed and configured, before an IdMLbook generated by System Automation Application Manager can be imported intoTBSM: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 runand that the templates and policies have been added to your TBSMconfiguration. For more information, see IBM Tivoli Provisioning Manager forOS 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.


http://www.ibm.com/support/knowledgecenter/SS3HLM_7.1.1.16/com.ibm.tivoli.tpm.osd.doc_7.1.1.16/welcome/osdlanding.html

http://www.ibm.com/support/knowledgecenter/SS3HLM_7.1.1.16/com.ibm.tivoli.tpm.osd.doc_7.1.1.16/welcome/osdlanding.html

You can find the three xml customization files in the directory$TBSM_HOME/XMLToolkit/xml.

Defining template mappingAbout this task

To automatically assign the EEZ_SystemautomationResource template to theimported service instances while the IdML book is imported, perform thefollowing configuration steps:1. Open the CDM_TO_TBSM4x_MAP_Templates.xml file in an text editor.2. Search for the line <template primary=’BSM_BusinessService’>.3. Add <othertemplate name=’EEZ_SystemAutomationResource’/> to the XML

element. The added line is marked in bold:<template primary=’BSM_BusinessService’>

<othertemplate name=’SCR_RetrieveDependentObjectsTemplate’/><othertemplate name=’SCR_ServiceComponentRawStatusTemplate’/><othertemplate name=’EEZ_SystemAutomationResource’/><cdmclass name=’cdm:sys.BusinessSystem’/><cdmclass name=’cdm:process.BusinessService’/>

</template>

This change will automatically assign the EEZ_SystemAutomationResource servicetemplate to all services of class cdm:sys.BusinessSystem that are imported usingthe DLA toolkit .

Customizing TBSM dependency generationAbout this task

The System Automation Application Manager DLA toolkit stores group and otherrelationships like start or stop dependencies into the IdML book. Grouprelationship are stored using the relation type cdm:federates, whereas non-grouprelationships like start or stop dependencies are stored using the relation typecdm:uses. If you want to only import the group hierarchy but not the non-grouprelationships with the group relationships into the service model of TBSM , youhave to disable the generation of dependencies for the relation type cdm:uses. Thissimplifies the graphical representation of the resulting service graph in TBSM.

Perform the following steps to disable the generation of dependencies betweenservice instances for non-group relations:1. Open the CDM_TO_TBSM4x_MAP.xml file in an text editor.2. Add the following line within the <RelationshipInfo> tag:

<class type=’cdm:uses’ isDependency=’false’ priority=’medium’source=’cdm:sys.BusinessSystem’target=’cdm:sys.BusinessSystem’ />

After you added this line, the DLA toolkit no longer generates dependenciesbetween imported service instances for the non-group relationship type cdm:uses.

Customizing event identificationAbout this task

To associate any event with a service instance imported from an IdML book,identification fields are required. If an event is received that has a matching fieldname and value as the service instance, the event is applied to the instance.

Status rules provided by System Automation use the AlertKey field for serviceidentification. All System Automation events have an AlertKey field set with an


unique source token value which represents a resource key. The resourcescontained in a IdML book created by System Automation Application Managercontain a source token attribute as well.

Define a policy to match System Automation events coming with thecorresponding service instance by setting the AlertKey field to the source tokenvalue of the resource.

The generation of TBSM services identification field value pairs is implemented bydefining rules in the EventIdentifierRules.xml file.1. Open the EventIdentifierRules.xml file in an text editor.2. Add the following policy and mapping elements to this file:

<Policy name="SystemAutomationApplicationManager"><Rule name="SourceTokenAsAlertKey" field="AlertKey"><Token keyword="SOURCETOKEN" value=’IBM Tivoli System Automation Application Manager’ /></Rule>

</Policy><Mapping policy="SystemAutomationApplicationManager" class="cdm:sys.BusinessSystem" />

When importing a resource of class cdm:sys.BusinessSystem this policy sets theAlertKey field for all status rules of the corresponding service to the SystemAutomation Application Manager source token value.

As a result, each TBSM service instance created from a System AutomationApplication Manager IdML book has a unique AlertKey field value. WheneverTBSM detects an event with this AlertKey field value, it checks the event for statusinformation for the associated service.

After you entered the changes to the XML control files, restart the TBSM DiscoveryLibrary Toolkit service to activate the changes.

Integrating System Automation resources in TBSMThis topic describes how you can add System Automation resources to a TBSMservice tree.

For resources which are contained in the end-to-end automation policy, you canmake use of the DLA to automatically import these resources into TBSM. This isdescribed in “Importing resources automatically.”

If you want to add System Automation resources to TBSM which are not part ofthe end-to-end automation policy, for example resources managed by SystemAutomation for Multiplatforms, you have to manually create a service instance inTBSM and then assign the System Automation Service Template. This is describedin “Assigning manually the service template to a service instance” on page 240.You also do this if you want to enrich service instances which already exist in aTBSM service tree with information from System Automation events.

Importing resources automaticallyAbout this task

Generating a System Automation Application Manager IdML book:About this task

Use the command eezdla to create IdML books for System Automation ApplicationManager. Perform the following steps:1. Log on to the system on which the automation manager runs.2. Enter eezdla.


The created IdML book is stored at the location which you configured on theDiscovery Library Adapter tab in the end-to-end configuration tool. On the sametab you can configure to copy the IdML book to a remote TBSM server.

Naming conventions:

Names of IdML books that are created by System Automation ApplicationManager start with the application code EEZ, followed by the host name of thesystem on which the automation manager is installed and an UTC timestamp.

Example:EEZ3210.e2esrv1.friendly.com.2010-02-15T14.57.47.093Z.refresh.xml

Importing a System Automation Application Manager IdML book into TBSM:About this task

If the Discovery Library Toolkit service is running, it automatically consumes IdMLbooks available in a specific directory on the TBSM server. You can configure thespecific directory using the Discovery Library Toolkit.

The default directory for the location of IdML books is:$TBSM_HOME/discovery/dlbooks

The System Automation Application Manager DLA can either be configured toautomatically save its IdML books in that directory on the TBSM server or theresulting IdML book needs to be manually copied to that location.

The Discovery Library Toolkit service consumes the IdML book from SystemAutomation Application Manager and populates the service component registrywith System Automation Application Manager resources. The processing of theIdML book can be validated by checking the msgGTM_XT.log file for a message thatis similar to the following:GTMCL5290I: Book EEZ3210.p720sa02.boeblingen.de.ibm.com.2010-07-22T15.01.47.711Z.refresh.xml processed successfully.

The default directory for the location of the log file is:v UNIX: $TBSM_HOME/XMLtoolkit/log

v Windows: %TBSM_HOME%\XMLtoolkit\log

Note: The DLA Toolkit service can be started in the following way:v UNIX: Start the Discovery Library Toolkit daemon by running the

tbsmrdr_start.sh script in the $TBSM_HOME/XMLtoolkit/bin directory. Thedaemon is added to the etc/init.d directory and is automatically restarted ifyou restart the TBSM host.

v Windows: Start the Discovery Library Toolkit service from the Services windowor by issuing the net start ASICRToolkitSvc command.

Verifying imported services:About this task

You can use the following procedure to verify that the service instances areimported correctly into the Service Component Registry :1. Select Administration > Service Administration in the Tivoli Integrated Portal

console task list.


2. Select Service Component Repository from the pull-down menu in the ServiceNavigation portlet.

3. Expand Component Repository > Business Services. The imported end-to-endautomation domains and resources are displayed below the Business Servicesentry. You can expand the domains and resource groups to verify that thegroup hierarchy has been created correctly .

4. Expand the end-to-end automation domain corresponding to the IdML bookwhich has been imported. Select one of the contained top-level resources.

5. Select the Edit Service tab in the Service Editor portlet to edit the service.6. Select the Templates tab and verify that the service template

EEZ_SystemAutomationResource is listed in the Selected Templates list.7. Select the Identification Fields tab and verify that for the incoming status rules

of the EEZ_SystemAutomationResource template, the AlertKey field has a valuecorresponding to the resource’s source token. For exampleEEZResourceKey,DN={E2E_Domain},NN={},RN={Online TradingApplication},RC={ResourceGroup}

8. Select the Additional tab and verify that the sourceContactInfo andsourceToken attributes for System Automation Application Manager are setcorrectly.

9. If the services have been imported correctly, a resource status event of SystemAutomation Application Manager influences the TBSM state displayed in theservice tree. You can test this, for example by stopping a group memberdefined in the end-to-end automation domain using the operations console. Thegroup should then show a Warning state in TBSM based on the compoundstate changes of the group.

Adding imported services to a service model:About this task

Once the System Automation Application Manager IdML book is processed andthe service component registry (SCR) is populated, the objects created in the SCRcan be used to create a business service in TBSM depending upon the requirementof the service model:1. Select Administration > Service Administration in the Tivoli Integrated Portal

console task list.2. In the Service Navigation portlet, create a new top-level service instance as

container for the imported System Automation services. Or select an existingservice instance as parent of the new System Automation resources.

3. Select the Edit Service tab in the Service Editor portlet to edit this service.4. Select the Dependents tab and click the Add from Service Component

Repository button. The Service Tree window opens.5. Expand Component Registry > Business Services > <your end-to-end

automation domain>.6. Select the top-level resource groups that you want to add to your service

model. They will be added as children of the container service that you createdin step 2.

7. When you have finished adding services, close the Service Tree popup windowand save the service instance.


Assigning manually the service template to a service instanceAbout this task

If you want to add System Automation resources to TBSM which are not part ofthe end-to-end automation policy, for example resources managed by SystemAutomation for Multiplatforms, create manually a service instance in TBSM andthen assign the System Automation Service Template. You also do this if you wantto enrich service instances which already exist in a TBSM service tree withinformation from System Automation events.

A service template consists of rules that can be applied for service instances. Atemplate can be used for more than one instance. If you want to assign theEEZ_SystemAutomationResource template to a service, you can tag the service withthe template. Proceed as follows:1. Tag services using the EEZ_SystemAutomationResource template to make the

defined incoming status rules available to these services.a. In the Service Navigation portlet, select the Service Name for which you

want to assign the System Automation specific service templateEEZ_SystemAutomationResource.

b. Select the Edit Service tab in the Service Editor to edit the service.c. Select the Templates tab. You can see the following two lists:v Available Templates: Displays all templates which you have the

permission to assign to the selected service instance.v Selected Templates: Displays all templates assigned to the service.

d. To assign the System Automation template to a service, select theEEZ_SystemAutomationResource template from the Available Templates list.Click the arrow button >> to move the template to the Selected Templateslist.

2. Configure the Identification Field values for this service. TBSM uses theIdentification Fields to map incoming events to a service instance.a. Select the Edit Service tab.b. Select the Identification Fields tab which provides the rules defined in the

EEZ_SystemAutomationResource template and the identification field valuesrequired to map an event to the selected service instance.


The rules contained in the EEZ_SystemAutomationResource template use theAlertKey event attribute as identifier. By default, the value for eachidentification field is the value entered in the Service Name field.

c. Enter the correct AlertKey attribute value that corresponds to the selectedservice. The AlertKey must contain the unique System Automation resourcekey formatted as CDM SourceToken. The structure is defined like this:EEZResourceKey,DN={DomainName},NN={NodeName},RN={ResourceName},RC={ResourceClass}

You may consider to open one of the events of the resource and copy andpaste the AlertKey value from the event to avoid typing errors. Examplesfor valid AlertKey values:1) Resource: System Automation for Multiplatforms constituent or fixed

resourceDomain: DB2ClusterDisplayed by lssam as: IBM.Application:db2-rs:saxb32cAlertKey:EEZResourceKey,DN={DB2Cluster},NN={saxb32c},RN={db2- rs},RC={IBM.Application}

2) System Automation for Multiplatforms move group (floating resource)Domain: DB2ClusterDisplayed by lssam as: IBM.Application:db2-rsAlertKey:EEZResourceKey,DN={DB2Cluster},NN={},RN={db2- rs},RC={IBM.Application}

3) System Automation for Multiplatforms resource groupDomain: DB2ClusterDisplayed by lssam as: IBM.ResourceGroup:DB2AlertKey:EEZResourceKey,DN={DB2Cluster},NN={},RN={DB2},RC={IBM.ResourceGroup}

Figure 24. Identification Fields tab


4) Resource: System Automation Application Manager resource groupDomain: E2E_DomainDisplayed by the operations console as: Online Trading ApplicationAlertKey:EEZResourceKey,DN={E2E_Domain},NN={},RN={Online Trading Application},RC={ResourceGroup}

5) Resource: System Automation Application Manager resource referenceDomain: E2E_DomainDisplayed by the operations console as: DB2 and the referenced resourceis located in the first-level automation domain DB2ClusterAlertKey:EEZResourceKey,DN={E2E_Domain},NN={DB2Cluster},RN={DB2},RC={ResourceReference}

Note: The referenced first-level automation domain must be used asnode name of the AlertKey (NN={FLA-Domain})

6) Resource: System Automation Application Manager choice groupDomain: E2E_DomainDisplayed by the operations console as: DB2 CGAlertKey:EEZResourceKey,DN={E2E_Domain},NN={},RN={DB2 CG},RC={ChoiceGroup}

d. Click the Additional tab for the service instance. The tab shows theadditional attributes defined for this service instance. The attributeIBM_Tivoli_System_Automation_Application_Manager_sourceToken is usedfor the launch-in-context action that supports launching from TBSM to theSystem Automation operations console.

e. Overwrite the attribute value forIBM_Tivoli_System_Automation_Application_Manager_sourceToken tocontain the System Automation source token that corresponds to this serviceinstance. This is the same value that has been specified for the AlertKeyattributes on the Identification tab.

f. Click Save to apply your changes.

Whenever new System Automation state change events are received for the servicewhich match the specified AlertKey, TBSM will now process the incoming statusrules and potentially change the overall state of the service based on the eventseverity.

Customizing TBSM views to add information from SystemAutomation

About this task

The EEZ_SystemAutomationResource Service Template contains text-basedIncoming Status Rules which retrieve the System Automation Observed State andother System Automation specific states of a resource. This information can beused in TBSM Views in order to enrich service instances with information comingfrom System Automation.

The following text-based incoming status rules are available:


Table 51. Text-based incoming status rules for TBSM

Rule Name Description

SAObservedStateValue Retrieves the field SAObservedState from a resourcestatus change event.

Possible values:

v Unknown

v Online

v Offline

v Starting

v Stopping

v NotApplicable

SADesiredStateValue Retrieves the field SADesiredState from a resourcestatus change event.

Possible values:

v Online

v Offline

v NoChange (i.e. the resource’s automation goalcannot be changed by an operator)

SAOperationalStateValue Retrieve the field SAOperationalStateValue from aresource status change event. List of Operational Statevalues giving more fine-grained information about thecurrent state of the resource. For a list of possiblevalues, see the SystemAutomation.baroc file.

SACompoundStateValue Retrieve the field SACompoundStateValue from aresource status change event. Compound stateindicating whether the resource is working as desiredor has encountered an error. Possible values:

v Ok

v Warning

v Error

v Fatal

SAExcludedFromAutomationValue Retrieve the field SAExcludedFromAutomationValuefrom a resource status change event. Flag indicating ifthe resource is excluded from automation (i.e.automation is suspended).

Possible values:

v NotExcluded

v Excluded

You can modify the columns of custom trees displayed in TBSM in thev Service Navigation portletv Service Tree portlet

The default Service Navigation portlet has three columns:v Statev Timev Events


You can modify, delete, and add tree columns with the Tree Template Editor. TheTree Template Editor is available from the Services toolbar in the ServiceNavigation portlet. You can add a new tree template to the Service Navigationportlet. For each custom column, use the Tree Template Editor to specify the ruledata you want to display in the column.

Adding columns:

This capability can be used to add columns for any of the provided text-basedincoming status rules defined by the EEZ_SystemAutomationResource template. Forexample, you can define a column which displays the current Observed Statecoming from System Automation for each service instance that has theEEZ_SystemAutomationResource template assigned. Perform the following steps:1. Click the Tree Template Editor button in the toolbar of the Service Navigation

portlet.2. Select the tree template you want to modify in the Tree Template Name

drop-down list.3. Click the Add New Tree Column button in the Column Configuration section.4. Type the name you want to use in the blank field for the new column, for

example “Availability State”.5. Adjust the column position and width as appropriate6. In the Service Template Selection section, select the

EEZ_SystemAutomationResource template.7. In the Service Template Rule Mapping, select the

EEZ_SystemAutomationResource template in the Active Template list.8. For each rule that you want to display in a service tree column, select the

Display check box and choose a column from the drop-down box to displaythe output value. In this example, select the Display check box for the attribute@SAObservedStateValue and choose the Availability State column from thedrop-down box of that row.

9. Click OK to save the changes to the tree template.

The following figure shows a screen capture of the tree template editor. A newcolumn Availability State is added showing the System Automation ObservedState:


To view the updated Services Tree, refresh the Service Navigation portlet. The newcolumn now occurs showing the output of the incoming status rule that you haveselected.

Note: You have to create new resource status change events in order to update thestate information displayed in TBSM. Old events are not processed again.

Using the TBSM policy editor:

Optionally, you can format column values using the TBSM policy editor. Forexample, display the SAObservedState values in different colors. Proceed asfollows:1. Click the Tree Template Editor button in the toolbar of the Service Navigation

portlet.2. Choose the tree template you want to modify from the Tree Template Name

drop-down list.

Figure 25. Tree template editor


3. Click on the Edit Policy... button to open the policy that displays columnvalues. The policy named GetTreeColumnValue is opened in the policy editor:

4. Modify the policy. The following code snippet is as an example on how tochange the color of the text-based output values. In this example, it is assumedthat a column named “Availability State” has been defined showing the outputof the SAObservedState Rule. Depending on the value of the observed state, thepolicy snippet returns the value in a different color:

if (columnName = ’Availability State’) {if (value = ’Unknown’) {

VALUE = ’ Unknown’;}if (value = ’Online’) {

VALUE = ’ Online’;}if (value = ’Offline’) {

VALUE = ’ Offline’;}if (value = ’Stopping’) {

VALUE = ’ Stopping’;}if (value = ’Starting’) {

VALUE = ’ Starting’;}

}

5. Save the modified policy

Configuring Tivoli Business Service Managerlaunch-in-context support

You can define a launch-in-context entry for a TBSM service tree that enables youto launch the System Automation operations console in context of the currentlyselected service instance.

About this task

Refer to “From TBSM to System Automation” on page 247 for more information.

You can also set up launch-in-context support to launch from a resource displayedin the System Automation operations console to the TBSM Web user interface.Refer to “From System Automation to TBSM” for more information.

From System Automation to TBSMAbout this task

You can set up launch-in-context support to launch from a resource displayed inthe System Automation operations console to the TBSM web user interface. Thislaunch-in-context support enables users to launch the Service AvailabilityWorkspace of the Tivoli Integrated Portal and automatically select thecorresponding service instance in the TBSM Service Viewer with a single mouseclick.

When TBSM launch-in-context support is configured, a hyperlink becomesavailable in the System Automation operations console on the General page ofthose resources that are contained in an end-to-end automation domain. Thishyperlink navigates to the corresponding service instance in the TBSM ServiceViewer.


Note: The TBSM launch-in-context support is only available for resources whichhave been imported into TBSM using the Discovery Library Toolkit.

Perform the following steps to configure TBSM launch-in-context support for theSystem Automation operations console:

Procedure1. Logon to the IBM Dashboard Application Services Hub on the system where

System Automation Application Manager is installed.2. Navigate to Tivoli System Automation -> Settings -> TBSM

Launch-in-Context Configuration

3. Select to enable launch-in-context support in the Enable launch-in-contextsupport for TBSM .

4. Specify the name of the server on which the Tivoli Integrated Portal runs,which hosts the TBSM web GUI, in the Server name used to connect to TivoliIntegrated Portal field.

5. Specify the secure port number of the server on which Tivoli Integrated Portalruns in the Port number used to connect to Tivoli Integrated Portal . Thedefault port number is 16316.

6. Click OK to save the configuration

Results

Note: If the operations console is displayed while the TBSM launch-in-contextconfiguration is changed, select Menu -> Refresh all to pick up the changedsettings in the current instance of the operations console.

From TBSM to System AutomationAbout this task

The launch-in-context action uses the following attributes of a service that must bestored in a service’s additional attributes in order to be able to perform the launch:v IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo

This attribute contains the launch URL including the host name and the portnumber of the System Automation Application Manager.

v IBM_Tivoli_System_Automation_Application_Manager_sourceToken

This attribute contains the unique source token attribute as defined by theSystem Automation Application Manager DLA. It represents the resource keyidentifying the System Automation resource corresponding to this serviceinstance. For example:EEZResourceKey,DN={FriendlyE2E},NN={},RN={DR_Portal},RC={ResourceGroup}

For System Automation Application Manager resources contained in an end-to-endautomation policy which are imported using the Discovery Library Toolkit, bothattributes are automatically filled with the right values when importing the DLbook into TBSM.

If the resource is manually created without the DLA Toolkit or for SystemAutomation for Multiplatforms resources (for which no DLA exists), theseattributes must be manually created in a service’s additional attributes ifLaunch-in-Context to System Automation is to be exploited.


Specify the sourceToken field for each service instance that has not been importedvia Discovery Library Toolkit. Refer to “Assigning manually the service template toa service instance” on page 240 for more information.

The sourceContactInfo field can be specified in the EEZ_SystemAutomationResourceService Template because it contains generic information which is valid for allSystem Automation resources.

The additional attributeIBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo containsthe URL of the System Automation Application Manager host to which thelaunch-in-context action will connect. If you want to use launch-in-context forservices which have been manually tagged with the EEZ_SystemAutomationResourcetemplate, you need to manually adapt the URL in the Service Template. This is notrequired if you only have services that are imported using the Discovery LibraryToolkit.

Follow these steps to adapt the EEZ_SystemAutomationResource template forLaunch-in-Context:1. Select Templates from the Service Navigation drop down menu.2. Select the EEZ_SystemAutomationResource template in the Service Navigation

portlet3. Click the Edit Template tab in the Service Editor to edit the template4. From the Edit Template tab, click the Additional tab.5. The parameter

IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo hasthe default value:http://<SA_ISC_Hostname>:16310/ibm/EEZUIWebClient/EEZIscUrlBuilderServlet

Replace <SA_ISC_Hostname> with the correct host name of the system where theSystem Automation Application Manager operations console is running. Alsochange the port number if required.

6. Click Save to apply your changes

Defining launch-in-context action:About this task

This topic describes how to define a new launch-in-context action for a customservice view in TBSM, which will appear in the context menu of a service instance.

Create a new view definition. The View Definitions feature of TBSM allows you tochange the visual content that is displayed in your Service Editor or Viewer portletand change the values that appear in the visual elements. In addition it allows todefine actions. Actions are the options available to you as the result of clicking,double clicking, or right-clicking a service in the Service Editor.

You cannot modify the pre-defined View Definitions, therefore you have to create anew View Definition to be able to define a new action:1. Select Services from the Service Navigation drop down menu.2. Click a service in the Service Navigation portlet. The default view definition

for the service model opens in the Service Editor or Viewer.3. In the View Service tab, select the view definition you want to work with from

the View Definition drop-down list.


4. Click the Edit View Definition button. The Edit View Definition windowopens.

5. To create a view definition, click Save as New. The Save As window opens.6. Type the name of your view definition in the Save as New field and click OK.

A new launch-in-context action needs to be defined to the new view definition.Add the System Automation launch-in-context action to the System Automationspecific service template EEZ_SystemAutomationResource, so that thelaunch-in-context action is only available to services tagged with this template:1. In the View Definition drop-down list, select your View Definition and click

the Edit View Definition button to reopen the Edit View Definition window.2. Click the Actions tab in the Edit View Definition window. The Actions tab

opens.3. Select the EEZ_SystemAutomationResource template from the Service Template

drop-down list.4. To add a new action, click the Edit button next to the Edit Action selection

list. The Edit Canvas Action window opens.5. Define a new Action using the following parameters:

Table 52. Launch-in-context action parameters

Attribute Value

Action Name ShowSAResource

Action DisplayName

Show Service in System Automation operations console

ActionDescription

Launch the service in the Tivoli System Automation operations console

Action URL __IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo__?SourceToken=__URLEncode(IBM_Tivoli_System_Automation_Application_Manager_sourceToken)__

Action Frame SystemAutomation

6. Click OK

7. Add the new action to the context menu. You have two options:a. If you want the launch menu entry to be visible only for services that have

the EEZ_SystemAutomationResource template assigned as primary template,select the EEZ_SystemAutomationResource template from the ServiceTemplate drop-down list.

b. If you want the launch menu entry to be always visible for all kinds ofservices, click on the Set Defaults button.

Note: If you have assigned the EEZ_SystemAutomationResource to services thathave been tagged with a different primary template, you have to use option b)to be able to use the launch-in-context action for these services.

8. To add the new action as a right-click action, click the New button to add anew row to the right click menu options action list. A blank row is added tothe Actions list.

9. Select the new action from the drop-down list.10. Click Apply to save the action.11. Click OK to close the Edit View Definition window.

Exporting System Automation specific additional attributes for use in LiCAction:


About this task

By default, TBSM provides a set of attributes to use for actions. The followingattributes are not available to use for launch-in-context actions:v IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo

v IBM_Tivoli_System_Automation_Application_Manager_sourceToken

To make the actions available, you need to edit the .xml file for the viewdefinition. Add an fieldToPassToModelExpr tag for each attribute that you want touse in the action. Refer to the example for a fieldToPassToModelExpr tag below.

The following directory contains the xml files that configure view definitions:v UNIX:

$TBSM_DATA_SERVER_HOME/av/xmlconfig

v Windows:%TBSM_DATA_SERVER_HOME%\av\xmlconfig

View definition xml files have the following format:ViewDefinition_<ViewDefName>.xml

ViewDefName is the name of the view definition in the TBSM console. For example,the name of the file for a custom view definition called MyView is:ViewDefinition_MyView.xml

To enable the launch-in-context action, add the following elements to the<dataTypeMapping> element in the view definition xml file:

<fieldToPassToModelExpr modelField="IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo">IBM_Tivoli_System_Automation_Application_Manager_sourceContactInfo</fieldToPassToModelExpr><fieldToPassToModelExpr modelField="IBM_Tivoli_System_Automation_Application_Manager_sourceToken">IBM_Tivoli_System_Automation_Application_Manager_sourceToken</fieldToPassToModelExpr>

This will make the two attributes available to use in the launch-in-context action.

Note: You have to restart the Tivoli Integrated Portal Server to activate this changein TBSM.

Integration scenarios with Business Service ManagerIf you integrate System Automation Application Manager with Business ServiceManager, you can exploit scenarios like "Automatic recovery of a DB2 failure" or"Planned maintenance of an online application".

The integration solution of Tivoli System Automation Application Manager andTivoli Business Service Manager (TBSM) allows you to:v Visualize service scorecards, key performance indicators, and service level

agreements of business applications in TBSM. Use Tivoli System AutomationApplication Manager to control and automate these business applications, and toprovide automatic recovery of failure situations.

v Use data from System Automation events to enrich TBSM service views withinformation from System Automation. System Automation Application Managerdelivers a TBSM service template containing pre-configured rules about how tomap states from System Automation to TBSM service instances. For example, if abusiness application was made offline for planned maintenance purposes, TBSMis now aware that this is a scheduled downtime for the business application andnot an unexpected failure situation.


v Use the Discovery Library Adapter (DLA) to simplify and automate theintegration of System Automation Application Manager resources with TBSM.With this approach, System Automation Application Manager resources areautomatically imported into a TBSM service model, the correct TBSM statusrules are automatically assigned to those services, and System AutomationApplication Manager events are automatically matched with the correct TBSMservice instances without manual configuration.

v Launch in context from a TBSM service view to the SA Operations Console andvice-versa. The operator can easily view the information about a specificapplication from both products. For example, you can use TBSM to monitor thehealth of a business application. An operator can use the launch in contextcapability to jump to the SA Operations Console to start or stop this businessapplication.

System environment of the integration scenario

A typical environment for these scenarios is a multitiered heterogeneous businessapplication, such as the "Online Trading Application" shown in Installation andConfiguration Guide. The online trading application consists of one or more webservers in the presentation tier, WebSphere Application Server in the business logictier, and an IBM DB2 server in the data tier, which is made highly available. Eachcomponent runs on a different platform and operating system, and hasdependencies with the others. For example, the DB2 server must be started first,followed by the WebSphere Application Server , and lastly, the web servers can bestarted. Another dependency example is that if the DB2 server must be restarted,then also the WebSphere Application Server and the web servers must be restartedso that the application can resynchronize with DB2.

In the integration scenarios described in the following topics, the online tradingapplication is automated and made highly available by using Tivoli SystemAutomation and is monitored by using Business Service Manager.

The following diagram illustrates the key products in this solution and how theyare used:


System Automation for MultiplatformsSystem Automation for Multiplatforms provides monitoring, automation,and high availability of application components. It also provides anavailability state displaying whether the application components are onlineor offline.

System Automation Application ManagerSystem Automation Application Manager manages the dependenciesbetween the components across platform borders , provides end-to-endautomated operation of the business application, provides recovery infailure situations, and stores information about the aggregated availabilitystate of the entire business application.

Tivoli Netcool/OMNIbusTivoli Netcool/OMNIbus is used to collect all events related to thebusiness application landscape. System Automation provides a rules filewhich processes the events and prepares them for use in Business ServiceManager.

Business Service ManagerBusiness Service Manager displays the business application as a servicetree. TBSM uses the events from Netcool/OMNIbus to provide healthinformation about the business application and to provide business impactanalysis.

The TBSM Service Availability page displays the online trading application" whichis monitored and managed by System Automation Application Manager:

Figure 26. Integration of System Automation with Business Service Manager


The Service Tree displays at the top level the Online Trading Application" businessapplication. The DB2, IHS (IBM HTTP Server) and WebSphere Application Servercomponents are shown as children of the application. The DB2 component is madehighly available in a High Availability Cluster managed by System Automation forMultiplatforms. Therefore, the DB2 service has two children that include the twoDB2 instances in the HA Cluster: one that is currently online and the active DB2instance, and one which is currently offline, which is the backup DB2 instance.

The Service tree displays four status columns that present information from SystemAutomation:

State The overall state of the service, which can be Bad (red), Good (green), orMarginal (yellow). This information is derived from the SACompoundState ofthe corresponding System Automation resource.

Availability StateThe currently observed run state of the service, which shows whether theservice is currently online, offline, starting, or stopping.

Desired StateRepresents the automation goal of the service, which can be either Onlineor Offline. This state is the status in which Tivoli System Automation triesto keep the service. If it matches the Availability State, the overall state isgreen.

Automation SuspendedIndicates whether the automation is suspended for the service. If theautomation is suspended, Tivoli System Automation temporarily stopstrying to reach the Desired State, but continues to monitor the AvailabilityState.

In the TBSM Service Availability Page, the overall state for the DB2 backupinstance is green even if the service is not running. The backup instance is

Figure 27. TBSM Service Availability Page


displayed as green because it is a cold standby that is started only if the primaryDB2 instance has a failure. The backup instance state is intended to not be runningand the operator is not required to take any action. The knowledge of plannedversus unplanned offline state is a capability provided by System Automationevents, which is displayed in the TBSM overall state of the service.

The following sections describe two sample usage scenarios for this integrationsolution. For further information about configuring this integration, see SystemAutomation Application Manager Installation and Configuration Guide.

Scenario 1: Automatic recovery of a DB2 failureIn this scenario, assume that the current DB2 instance has a failure. Tivoli SystemAutomation detects the failure and attempts to restart the DB2 instance. If therestart attempt is not successful, a failover is initiated and the DB2 instance isstarted on the other node in the high availability cluster. You can monitor thissituation in the TBSM Service Tree:

Note that the DB2 instance that previously was online on node saxb33e now showsa problem state and is Offline. The other DB2 instance on node saxb32c is currentlybeing started by Tivoli System Automation.

Due to the failover of DB2, System Automation Application Manager also restartsIHS and WebSphere Application Server because there is a "forcedDownBy"dependency defined in the System Automation Application Manager policy. As aresult of this dependency, both IHS and WebSphere Application Server have aDesired State set to Offline. As part of the recovery action, IHS and WebSphereApplication Server are stopped while DB2 is made Online on node saxb32c in theHigh Availability cluster. Then the automation starts WebSphere Application Serverfirst, then starts IHS.

All components are up and running again:

Figure 28. TBSM Service Tree


Tivoli System Automation has automatically recovered the DB2 failure situation byperforming a failover of DB2 and by restarting the dependent WebSphereApplication Server and IHS. When the business application is running again, theadministrator can fix the problem causing the DB2 instance failure on nodesaxb33e so that DB2 is highly available again.

Scenario 2: Planned maintenance of an online applicationIn this scenario an operator needs to shut down the “Online Trading Application"for maintenance reasons. The operator can do this by starting from the BusinessService Manager graphical user interface and performing the following steps:1. In the Business Service Manager Service Viewer, the operator opens the context

menu of the "Online Trading Application" service and selects the menu entry"Show Service in System Automation operations console" :

Figure 29. TBSM Service Tree


2. The System Automation operations console is launched:

The System Automation operations console displays topology information(Clusters/Systems) and information about the automated service instances. Itdisplays the same service "Online Trading Application", which is alreadyselected with details about the service in the Information Area. The InformationArea lists status information and gives operational control.

Figure 30. TBSM Service Viewer

Figure 31. Tivoli System Automation operations console


3. the operator now clicks the "Request Offline" button to shut down the entire"Online Trading Application". This request is processed by the SystemAutomation Application Manager automation engine which stops allcomponents in the correct sequence.

4. The operator switches back to the "Service Availability" workspace to monitorthe shut down of the application components also from Business ServiceManager. The operator uses the "Open Service in TBSM" link which opens theService Availability workspace and selects the Online Trading Application inthe TBSM Service Viewer.

The automation stops WebSphere Application Server , and finally DB2, inaccordance with the defined stop dependencies. Finally, everything is shut down:

The state color of the "Online Trading Application" and its components is greeneven though the service is not running. This indicates that it was intentionally shutdown by an operator and it is not an unplanned failure situation. This knowledgecan be delivered by using the SACompoundState to determine the overall state ofservice instances.

Tivoli Monitoring and Tivoli Composite Application ManagerThe Tivoli Monitoring (Tivoli Monitoring) and Tivoli Composite ApplicationManager (ITCAM) family provides availability and performance monitoring ofessential system resources and applications on a wide variety of operating systemsand platforms.

System Automation Application Manager can be used to control and automateresources, which are monitored by Tivoli Monitoring or ITCAM.

System Automation Application Manager integrates with Tivoli Monitoring andITCAM by using existing Tivoli Monitoring resource instrumentation (TivoliMonitoring agents). The System Automation Application Manager retrievesmonitoring information from Tivoli Monitoring agents and executes start and stopoperations using Tivoli Monitoring agents. Software components, which were onlymonitored by Tivoli Monitoring can be resources that are managed by System

Figure 32. Tivoli System Automation Operations Console


Automation Application Manager. Tivoli Monitoring resources can be automatedmembers of complex business applications within System Automation ApplicationManager policies.

Tivoli Monitoring delivers a wide variety of agents that can integrate with SystemAutomation Application Manager:v Application agents (also referred to as non-OS agents), including custom agentsv OS agents

System Automation Application Manager provides predefined templates for theintegration of the following agents:v Apache web Serverv WebSphere Application Serverv DB2v Custom agents, which are built by the Tivoli Monitoring Agent Builderv Linux OS agentv UNIX OS agent

Use the policy editor to create resource definitions for Tivoli Monitoring resourcesbased on these templates or for any other Tivoli Monitoring agent type using thegeneric Tivoli Monitoring resource support.

For a complete overview, and about the advantages of the Tivoli Monitoringintegration, see System Automation Application Manager Administrator's and User'sGuide, Integrating with Tivoli Monitoring and Tivoli Composite Application Manager".

Prerequisites

Supported Tivoli Monitoring versions for this feature are:

IBM Tivoli Monitoring 6.1, 6.2.1, 6.2.2 and 6.2.3

Tivoli Monitoring overview

The following illustration gives an overview of a typical Tivoli Monitoringmanagement infrastructure with all its components in order to introduce terms thatare used later in this document. For a more detailed description of thisinfrastructure, see the Tivoli Monitoring Knowledge Center.


http://www.ibm.com/support/knowledgecenter/SSTFXA/welcome?lang=en

The IBM Tivoli Monitoring architecture is a multi-tiered client/server environmentconsisting of the following four main components that monitor mission criticalsystems throughout the enterprise:v The Tivoli Enterprise Portal (TEP) Client is a presentation interface that is

browser or desktop (thick client) based and is used to view and monitor theenterprise.

v The Tivoli Enterprise Portal Server provides the core presentation layer forretrieval, manipulation, analysis, and pre-formatting of data. The portal serverretrieves data from the hub Tivoli Enterprise Monitoring Server monitoringserver in response to user actions at the portal client, and sends the data back tothe portal client for presentation. The portal server also provides presentationinformation to the portal client so that it can render the user interface viewssuitably.

v The Tivoli Enterprise Monitoring Server acts as a collection and control pointfor alerts received from the agents, and collects their performance andavailability data. The monitoring server also manages the connection status ofthe agents.Large-scale environments usually include a number of monitoring servers todistribute the load. One of the monitoring servers is designated the hubmonitoring server, and the remaining servers are termed remote monitoringservers, often called RTEMS.The hub monitoring server also provides a SOAP interface which can be used toquery Tivoli Monitoring data and issue commands via Tivoli Monitoring agentson the endpoints. The SOAP interface is also used for the integration of SystemAutomation Application Manager with Tivoli Monitoring to retrieve monitoringinformation from the agents and to perform start and stop commands on theendpoints.

v The Tivoli Enterprise Monitoring Agents (TEMA) are installed on the systemsor subsystems you want to monitor. These agents collect data from monitored,or managed, systems, and distribute this information to a monitoring server.

v Tivoli Data Warehouse which is used for storing historical data collected fromagents in the environment. To store data in this database, you must install theWarehouse Proxy agent. To perform aggregation and pruning functions on the

Figure 33. Overview of the IBM Tivoli Monitoring infrastructure


data, you must also install the Summarization and Pruning agent. The DataWarehouse component is not required for the System Automation ApplicationManager integration.

The Tivoli Enterprise Monitoring Agents (TEMA) can be of the following types:v Application agents (non-OS agents) that monitor the availability and

performance of systems, subsystems, and applications. Those agents ofteninclude predefined commands to start and stop the managed application. Anexample of an application agent is IBM Tivoli Composite Application ManagerAgent for WebSphere Applications, which monitors WebSphere ApplicationServer instances.You can also create your own application agents via the Agent Builder, a set oftools for creating custom agents. Using the Agent Builder, you can quicklycreate, modify, and test an agent to collect and analyze data about the state andperformance of different resources, such as disks, memory, CPU, or applications.

v Operating system (OS) agents that monitor the availability and performance ofthe operating systems (computers). An example of an OS agent is theMonitoring Agent for Linux OS, which monitors end points running a Linuxoperating system.

Every Tivoli Monitoring agent has a two letter product code uniquely identifyingthe agent type. Some examples are:v HT IBM Tivoli Composite Application Manager Agent for web serversv UD IBM Tivoli Composite Application Manager Agent for DB2v YN IBM Tivoli Composite Application Manager Agent for WebSphere

Applicationsv LZ Linux Monitoring Agentv NT IBM Tivoli Monitoring for Windows Serversv UX UNIX OS Monitoring Agent

Custom agents have a product code within the reserved range 00 – 99.

System Automation Application Manager uses the agentless adapter to integratewith the Tivoli Monitoring infrastructure. For more information about the agentlessadapter, see System Automation Application Manager Administrator's and User's Guide,"Product Overview, Concepts and components, Using the agentless adapter to access TivoliMonitoring Resources.

For information about starting and stopping Tivoli Monitoring managed resources,see System Automation Application Manager Administrator's and User's Guide, "Starting and Stopping Tivoli Monitoring managed Resources".

For information about monitoring resources managed by Tivoli Monitoring, seeSystem Automation Application Manager Administrator's and User's Guide,"Administering, Defining Tivoli Monitoring (ITM) Resources".

Integrating with System Automation Application ManagerAbout this task

The integration of Tivoli Monitoring managed applications into SystemAutomation end-to-end management: is a step by step process. The required stepsare:


1. Use the configuration dialog cfgeezdmn to configure connectivity to the hubTivoli Enterprise Monitoring Server, define a domain, and add users that canaccess the Tivoli Monitoring SOAP server.

2. Create a System Automation Tivoli Monitoring resource in the agentlessadapter policy using the policy editor.v For an application agent for which a template is provided, create a new

Tivoli Monitoring resource based on this template directly from the contextmenu of the policy editor. Definitions are already made for the resource andonly minimal modifications are required to adapt the resource to yourenvironment, for example, modify the managed system name to match yourtarget endpoint.

v For other agents, gather the following information to create a new SystemAutomation Tivoli Monitoring resource definition in the agentless adapterpolicy:– Managed System Name of the agent.– Attribute group and name of the attribute that is used for monitoring.– Mapping of the attribute values to the common System Automation

observed state.– The command that must be used for starting and stopping the managed

application.3. Activate the agentless adapter policy using the operations console. Test that the

defined Tivoli Monitoring resource can be started and stopped and that itdisplays the correct observed state.

4. Add the Tivoli Monitoring resource to the Application Manager end-to-endautomation policy by creating a resource reference. Use the resource harvestingwizard in the policy editor, which harvests the Tivoli Monitoring resources thatare defined in the agentless adapter domain.

5. Activate the modified Application Manager end-to-end automation policy.

These steps are explained in detail in “Configuring the agentless adapter for TivoliMonitoring Integration.”

Configuring the agentless adapter for Tivoli MonitoringIntegration

About this task

You must perform a sequence of configuration steps to enable the agentlessadapter to access the Tivoli Monitoring Tivoli Enterprise Monitoring Server SOAPserver to control and monitor Tivoli Monitoring resources. These resources aredefined in the adapter automation policy. Use the cfgeezdmn configuration dialog.

Log in to the system on which you installed the System Automation ApplicationManager, and perform the sequence of configuration steps described in thefollowing topics:

Procedure1. “Configuring the agentless adapter” on page 2622. “Creating agentless adapter domains for Tivoli Monitoring resources” on page

2633. “Configuring the properties to access the Tivoli Monitoring SOAP server” on

page 2644. “Configuring user credentials to access the monitored resources” on page 265


5. “Activating the configuration changes” on page 266

Configuring the agentless adapter:

About this task

If you already configured an agentless adapter instance (local or remote) and youwant to use it to monitor and control Tivoli Monitoring resources, you can skipthis step. Otherwise refer to “Configuring access to non-clustered nodes” on page127 for instructions on how to configure an agentless adapter.

If you want to use multiple Agentless Adapter instances to control TivoliMonitoring resources, you must perform the tasks that are described in thefollowing sections for each of those agentless adapter instances. You can definemultiple domains for one agentless adapter, which eliminates the need to use morethan one agentless adapter instance.

Use the cfgeezdmn configuration utility to perform the following steps:

Procedure

1. Open the configuration dialog using the cfgeezdmn command. The tasklauncher of the configuration dialog is displayed.

2. Select the Non-clustered Nodes tab.3. If you want to enable the integration of Tivoli Monitoring resources for the

local agentless adapter, click the Configure button for the local agentlessadapter. If you want to enable the integration of Tivoli Monitoring resources fora remote agentless adapter, click Configure for remote agentless adapters andselect the remote agentless adapter instance that you want to configure.The agentless adapter configuration dialog opens:


Creating agentless adapter domains for Tivoli Monitoring resources:

About this task

To create agentless adapter domains for Tivoli Monitoring resources perform thesesteps:

Procedure

1. Open the agentless adapter configuration as described in “Configuring theagentless adapter” on page 262.

2. On the Adapter tab of the configuration dialog, click Add. Choose a domainname in the dialog that is displayed, for example ITMDomain, and click OK. Thenew domain is displayed in the domain list of the configuration window. If youwant to define multiple domains to contain Tivoli Monitoring resources, usethis dialog to define them.

Figure 34. Application Manager Local Agentless Adapter Configuration


Configuring the properties to access the Tivoli Monitoring SOAP server:

About this task

Complete the following steps to configure the connection between the agentlessadapter and the Tivoli Monitoring SOAP server. The configuration changes mustbe applied to the agentless adapter instance (local or remote) determined in thepreceding tasks.

Procedure

1. Open the agentless adapter configuration as described in “Configuring theagentless adapter” on page 262

2. Click on the Tivoli Monitoring tab:

3. On the Tivoli Monitoring tab, select Enable integration of ITM/ITCAMresources and specify the values for the Tivoli Monitoring SOAP serverconfiguration:


Host name or IP addressSpecify the name or the IP address of the host where the hubmonitoring server that hosts the SOAP service is running.

SOAP server port numberSpecify service point port number of the SOAP server hosted by thehub monitoring server. The default number for a non-SSL port is 1920.The default number for an SSL port is 3361. If you selected to useSecure Socket Layer (SSL) for communication with the SOAP server,you must specify a valid SSL port number.

SOAP alias of hubSpecify the alias name of the hub monitoring server to which a SOAPrequest is routed. The request is routed to the hub monitoring serverwhich 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 SOAPrequest to a remote hub, specify the alias name of the remote hub. Thisalias must be previously defined to the SOAP server in the TivoliMonitoring SOAP server configuration.

Use SSL for communication with the SOAP serverSelect this option if the agentless adapter uses Secure Socket Layer(SSL) for communication with the SOAP server. If you select thisoption, you must specify a valid SSL port number in the SOAP serverport field. The https protocol is used for communication.

Configuring user credentials to access the monitored resources:

About this task

Any start / stop command or monitor query against an Tivoli Monitoring agent istranslated into a SOAP request to the Tivoli Monitoring SOAP Server on the hubmonitoring server. For each SOAP request, the agentless adapter authenticatesagainst the SOAP server using a user name and password.

You can define a generic user ID which is used for all Tivoli Monitoring resourcesfor which no user ID is specified in the agentless adapter policy.

You can also define specific user IDs if you want to use different users for TivoliMonitoring resources. In this case, you must specify a user ID for the TivoliMonitoring resource in the agentless adapter policy. You must also define the usercredentials in the list of specific credentials for accessing the SOAP server for eachuser ID that is specified for a Tivoli Monitoring resource.

Important:

v All Tivoli Monitoring user IDs defined in the agentless adapter policy and in theconfiguration utility must be valid Tivoli Monitoring users that can access theTivoli Monitoring SOAP server. The users are authenticated through the hubmonitoring server. Depending on how the monitoring server is configured, userIDs can be authenticated either by the local system registry of the system onwhich the hub monitoring server runs or by an external LDAP-enabled centralregistry.

v In the Tivoli Monitoring SOAP server configuration, you can define users to aSOAP Server and specify the access privileges for each user: Query or Update.The access privileges control what methods the user is allowed to use. Updateaccess includes Query access. User IDs used by the Agentless Adapter to connect


to the Tivoli Monitoring SOAP Server to start, stop, and monitor remote TivoliMonitoring resources require the “Query” access.

Complete the following steps to define one or more user credentials used by theagentless adapter when connecting to the hub Tivoli Enterprise Monitoring Serverto control or monitor an Tivoli Monitoring resource.

Procedure

1. Open the agentless adapter configuration as described in “Configuring theagentless adapter” on page 262

2. Select the Tivoli Monitoring tab3. On the Tivoli Monitoring tab, either specify a generic or a specific user ID or

both:a. For specific user IDs, click Add and specify a new user ID and password in

the dialog that is displayed. Click OK. The new user is displayed in the listof specific credentials. If you want to use a specific ID, you must specify itfor a Tivoli Monitoring resource in the agentless adapter policy.

b. For the generic user ID, enter the username in the corresponding entry fieldand click Change to specify a password for the generic user. This genericuser is used for all Tivoli Monitoring resources in the Agentless Adapterpolicy for which no user ID is specified. If you decide to omit the user IDfor at least one of the Tivoli Monitoring resources in the Agentless Adapterpolicy, you must define a generic user.

c. Click Save to save the configuration changes that you applied in thepreceding tasks.

Activating the configuration changes:

About this task

By completing the tasks described in the preceding sections, you modified theconfiguration of an agentless adapter instance and you enabled this adapter tomonitor and control Tivoli Monitoring resources. You must now activate theconfiguration changes by performing these steps:1. Distribute the changed configuration (only for remote Agentless Adapters)

Configurations are generally stored on the system where the SystemAutomation Application Manager is installed. If you decided to use a remoteagentless adapter instance for Tivoli Monitoring resource automation, you mustdistribute the configuration from the system where the System AutomationApplication Manager is installed to the system where the correspondingagentless adapter is installed.Refer to“Distributing a remote agentless adapter configuration” on page 138 fora description of this task.

2. Start/restart the agentless adapter

All configuration settings are stored in configuration properties files that theAgentless Adapter reads when it is started. If the agentless adapter is alreadyrunning when you modify the configuration, the adapter must be stopped andrestarted to load the new settings.agentless adapters are controlled by using the eezaladapter command. Useeezaladapter start to start the adapter. If the adapter is you must stop theadapter using eezaladapter stop, then start it. Refer to System AutomationApplication Manager Reference and Problem Determination Guide for details on theeezaladapter command.


Creating a Tivoli Monitoring resource in an agentless adapterpolicy

About this task

To complete the steps to create the Tivoli Monitoring resource, retrieve informationabout your managed resources. These steps are described in “Retrieving therequired information about your Tivoli Monitoring managed resources” on page272 and subsequent topics.

Creating an agentless adapter policy for Tivoli Monitoring resources:

This topic describes how to create a policy for an Agentless Adapter domain whichcontains Tivoli Monitoring resources.

About this task

The policy pool directory for the agentless adapter contains a template policy filewhich can be used to create a new Agentless Adapter policy automating TivoliMonitoring resources. The policy template file is namedSampleITMResourcePolicy.xml and is located in the agentless adapter policy pooldirectory.

XML source of the policy template:<?xml version="1.0" encoding="UTF-8"?><AutomationPolicy version="1.0" xmlns="http://www.ibm.com/TSA/Policy.xsd"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.ibm.com/TSA/Policy.xsd EEZALPolicy.xsd">

<PolicyInformation><PolicyName>Template For ITM Resource In agentless adapter Domain</PolicyName><AutomationDomainName>§domain$</AutomationDomainName><PolicyToken> 0.0 </PolicyToken><PolicyAuthor>Author of this policy</PolicyAuthor><PolicyDescription>This is a template.</PolicyDescription>

</PolicyInformation>

<IBM.ITMResourceAttributes name="ITMAgentResourceAttributes" ><Owner>John Doe</Owner><InfoLink>http://your_link_for_operator_instructions.html</InfoLink><Description>Some short description for the operator</Description><UserName>§user$</UserName><StartCommand></StartCommand><StopCommand></StopCommand><StartCommandTimeout>30</StartCommandTimeout><StopCommandTimeout>30</StopCommandTimeout><MonitorAttribute>$group$.$attribute>$</MonitorAttribute>


<MonitorValueOnline>§online$</MonitorValueOnline><MonitorValueOffline>§offline$</MonitorValueOffline><MonitorCommandPeriod>10</MonitorCommandPeriod></IBM.ITMResourceAttributes><Resource name="My SA ITM Resource Name" class="IBM.ITMResource" node="§system$"><ClassAttributesReference><IBM.ITMResourceAttributes name="ITMAgentResourceAttributes"/>

</ClassAttributesReference></Resource></AutomationPolicy>

Sample policy snippets for commonly used monitoring agents are included in thesnippets/itm directory of the System Automation Application Manager policypool. For example:/etc/opt/IBM/tsamp/eez/policyPool/snippets/itm

If you want to define a Tivoli Monitoring resource for one of these agents, copy theappropriate policy snippet into your agentless adapter policy and adjust theresource name and managed system name in order to suite your environment.

Policy snippets of the agentless adapter policy pool snippets directory:v Snippet_DB2_agent.xml

v Snippet_WebSphere_agent.xml

v Snippet_Apache_agent.xml

v Snippet_custom_agent.xml

v Snippet_LinuxOS_agent.xml

v Snippet_UNIXOS_agent.xml

Refer to IBM Tivoli System Automation Application Manager Reference andProblem Determination Guide, for details about the properties used in the policysnippets.

Use an XML editor to modify the provided policy template file and add new TivoliMonitoring resources. Follow these steps:1. Copy the file SampleITMResourcePolicy.xml. By default, the file is located in the

following directory: /etc/opt/IBM/tsamp/eez/aladapterPolicyPool.2. Open the file in an XML editor.3. Update the PolicyInformation section of the policy. It is required that you

specify at least the domain name of the Agentless Adapter domain you haveconfigured to interact with the TEMS correctly. It is recommended to alsochange the PolicyName and PolicyDescription of the policy.

4. Create a Tivoli Monitoring resource. As you can see in the policy template, youtypically have to create the following for each new Tivoli Monitoring Resource:a. One XML fragment of type IBM.ITMResourceAttributes with all the Tivoli

Monitoring agent specific properties. In this section you specify the TivoliMonitoring agent attributes which are used to determine the observed stateand how to map them to the System Automation Application Managerobserved state. It also describes which actions are used to start or stop thisresource. You can share one set of IBM.ITMResourceAttributes for multipleTivoli Monitoring resources.


b. One XML fragment of type Resource with the corresponding instance of theIBM.ITMResourceAttributes as argument. Here you can define the name ofyour resource and identify which agent instance (managed system name) isused to monitor and control the application that is represented by thisresource. The Tivoli Monitoring managed system name is specified in thenode attribute of the Resource element.Depending on whether a predefined agent policy snippet exists or not,choose one of the following steps:1) If your Tivoli Monitoring resource is monitored by a Tivoli Monitoring

agent for which a predefined policy snippet exists, create a TivoliMonitoring resource using a predefined template:a) Open one of the Snippet_*_agent.xml files in your editor.b) Copy the Resource and IBM.ITMResourceAttributes elements into

your main policy document and adapt the attributes to match yourenvironment.

The resources attributes contain predefined Tivoli Monitoring agentspecific settings such as the state mappings from the Tivoli Monitoringagent state values to System Automation state values. The Descriptionattribute provides an overview of the properties that you need to adaptto match your environment.

2) If there is no predefined policy snippet for your Tivoli Monitoringresource, copy and modify the XML elements of the generic TivoliMonitoring resource that is contained in theSampleITMResourcePolicy.xml template:

Key attributes which have to be defined for a Tivoli Monitoring resource.All attributes are defined within the XML elementIBM.ITMResourceAttributes.

<StartCommand> and <StopCommand>These values contain the exact command and arguments run by theTivoli Monitoring agent when the resource receives a start or stoprequest for the corresponding resource instance. The command caneither be a predefined take action command supported by the TivoliMonitoring agent or any remote system command. To use apredefined take action command of a specific Tivoli Monitoringagent, specify the name of the command and associated parameters.You do not need to specify a fully qualified file path. If you want totrigger a different command on the system, the fully qualified pathto that command needs to be specified. The command is run on themanaged system identified by the managed system name of theresource.

<UserName>The value defines a user name which is used to connect to theTivoli Monitoring SOAP server running on the hub monitoringserver to submit the StartCommand and StopCommand and to querythe Tivoli Monitoring agent for the attribute specified in theMonitorAttribute element. Specify one of the user IDs configuredusing cfgeezdmn as specific Tivoli Monitoring users. For moreinformation, refer to “Configuring user credentials to access themonitored resources” on page 265. If you want to use the genericTivoli Monitoring user configured in cfgeezdmn, leave this attributeblank.

<MonitorAttribute>The value specifies the Tivoli Monitoring agent attribute that is


queried to determine the observed state of the resource. Theattribute consists of an attribute group and an attribute name withinthat group. The value of the specified agent attribute is queriedperiodically to determine or update the observed state of theresource. The attribute is specified asAttributeGroup.AttributeName.

<MonitorValueOnline> and <MonitorValueOffline>Use these elements to specify which value of the Tivoli Monitoringattribute defined as MonitorAttribute is to be mapped to whichSystem Automation observed state. AMonitorValue<observed_state_value> element exists for everyavailable System Automation observed state. Specify the monitorattribute value which is mapped to this observed state as value ofthe XML element.

You can map multiple Tivoli Monitoring States to the same SystemAutomation observed state. If the monitor attribute has a value forwhich no mapping to a System Automation observed state exists,this value is ignored and the observed state of the Tivoli Monitoringresource remains unchanged.

If you are unsure about which values to specify, refer to “Retrieving therequired information about your Tivoli Monitoring managed resources” onpage 272 to obtain the correct ones.For a full description of all properties available for Tivoli Monitoringresources, refer to IBM Tivoli System Automation Application ManagerAdministrator's and User's Guide. In addition, refer to IBM Tivoli SystemAutomation Application Manager Reference and Problem DeterminationGuide for details about XML elements.

5. Save the policy file in the agentless adapter policy pool.

Using attribute filters in a monitor query:

About this task

The Tivoli Monitoring agent attribute group that was specified as part of theMonitorAttribute of the Tivoli Monitoring resource is queried periodically. Thequery is performed to determine or update the observed state of the resource.Agent attribute groups are returned as tables. For some agent attribute groups,more than one row of values can be returned. For example, when a table ofrunning processes is displayed, or if the agent monitors multiple applicationinstances. If you want to use an attribute of such an attribute group as monitorattribute, you must specify a filter to locate the row in the table which contains thestate of your Tivoli Monitoring Resource. You use the MonitorQueryAttrFilterproperty to specify such a filter. You can specify the following filters:

MonitorQueryAttrFilterThis XML element is an optional element within theIBM.ITMResourceAttributes element. When querying the monitor attribute,this filter is applied to reduce the amount of returned data based on thefilter criteria. In the filter, you can specify which attribute must meet whichfilter criteria. Only the matching rows of the attribute group that containthe attribute are returned. A filter criteria has the three components“Attribute Name”, “Operator”, and “Attribute Value”.


Attribute NameIs the name of the attribute on which the filter is applied. It mustexist in the attribute group specified in the monitor attribute.

Operator Can be: EQ, NE, GE, GT, LE, LT, or LIKE. You can select one ofthem from the list, where:

EQ is “equals”

NE is “not equal”

GE is “greater than or equal to”

LE is “less than or equal to”

LT is “less than”

LIKE can be used if pattern matching is required. Available patterncharacters when using LIKE are:v '%' matches any single character.v ' * ' matches one to many characters.

LIKE is only supported for character attributes.

Attribute ValueIs the value on which the operator is applied.

The filter value is specified as follows attribute_name;operator;value. You canspecify multiple filter criteria. Multiple filters are applied using a logical ANDoperation.

Note:

v Filter criteria are optional. However, you must make sure that the query result ofthe monitor attribute does not return more than one row.

v If the monitor query returns an empty result set, the resource assumes Offlineas observed state. This filter criteria is required if process monitoring via an OSagent is used, because the process table does not list the monitored process if theprocess is not running.

Specifying additional properties for a Tivoli Monitoring resource:

About this task

You can add multiple Tivoli Monitoring attributes with their current values to thelist of additional properties of the corresponding Tivoli Monitoring resource. Theattributes and values are then shown in the Additional tab of the Properties dialogof the selected Tivoli Monitoring resource in the System Automation operationsconsole. Use the Property XML element that can be specified within theIBM.ITMResourceAttributes element to define the additional attributes whichshould be added to a resource.

Additional Attributes specified as Property element.

The attributes that you add as Property element must be part of the attributegroup that is specified in the MonitorAttribute element. The attribute value isqueried periodically with every monitor call. Do not specify attributes withfrequently changing values, for example CPU utilization, because a resource


modified event is triggered each time the attribute value changes. You can specifymultiple Property elements if more than one agent attribute value should be addedto the additional properties of a resource.

The following screen capture shows parts of an attribute group as displayed in theTivoli Enterprise Portal:

If in this attribute group there is also the attribute chosen as monitor attribute, youcan use the other attributes as additional properties for the resource. In thisexample, “Status” was chosen as monitor attribute. Good examples for attributes tobe added as additional attributes are “Version” or “Process ID”. Since “JVMMemory Free (bytes)” is an attribute that changes frequently, it is not a goodcandidate to be added to the list of additional properties.

Example:<IBM.ITMResourceAttributes> ...<MonitorAttribute>Application_Server.Status</MonitorAttribute><MonitorValueOnline>Connected</MonitorValueOnline><MonitorValueOffline>Disconnected</MonitorValueOffline><MonitorCommandPeriod>10</MonitorCommandPeriod><Property>Version</Property><Property>Process_ID</Property></IBM.ITMResourceAttributes>

Retrieving the required information about your Tivoli Monitoringmanaged resourcesSpecify attributes in the XML elements IBM.ITMResourceAttributes and Resourceto create a Tivoli Monitoring resource in an agentless adapter policy. This sectiondescribes the steps that you must perform to find the required information.

About this task

Use the Tivoli Enterprise Portal (TEP) connected to an Tivoli Monitoringenvironment to perform the following steps:

Procedure1. Step 1: Find the correct Managed System Name that must be specified as node

attribute of the Resource XML element.2. Step 2: Find suitable take action commands provided by the Tivoli Monitoring

agent to start and stop the Tivoli Monitoring managed application and specifythem as StartCommand and StopCommand within the IBM.ITMResourceAttributesXML element.

3. Step 3: Find the available attribute and corresponding attribute values that canbe used for determining the observed state. Specify the attribute asMonitorAttribute XML element for the Tivoli Monitoring resource and definestate mappings for the attribute values using the corresponding MonitorValueXML elements. For example MonitorValueOnline or MonitorValueOffline.

Figure 35. Agent attributes which can be added as additional attributes


The following tasks guide you through the process.

Step 1: Managed system name:

The managed system name identifies an Tivoli Monitoring agent on a specificremote endpoint that is used to monitor and control the application that you addto the agentless adapter policy.

About this task

This managed system name must be specified in the ITM Resource section for anTivoli Monitoring resource.

Perform the following steps to determine the managed system name:

Procedure

1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed systemfor which you want to determine the managed system name. Right-click on thenavigator item and select Properties.

2. In the Navigator Item Properties dialog find the Assigned list box whichdisplays the managed system name. The managed system name in theAssigned list must be specified in the ITM Resources section for the TivoliMonitoring resource in the policy editor.

Step 2: Take action commands:

About this task

In the StartCommand and StopCommand properties you can either specify any remotecommand available on the remote endpoint or a predefined Take Action commandwhich is provided by the Tivoli Monitoring agent. Use the following methods todisplay the available Take Action commands for an ITM agent. This informationmust be specified on the Start / Stop Properties notebook page for the TivoliMonitoring resource.

Perform the following steps to determine the Take Action commands:

Procedure

1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed systemfor which you want to determine the available take action commands.

2. Right-click on the navigator item and select Take Action > Select.3. A list box containing all available Take Action commands for the currently

selected managed system is displayed. Select the appropriate command to startor stop the monitored application. If you are prompted to specify requiredparameter values, specify the correct values in that dialog.

4. The Take Action dialog now displays the completed Take Action details.Specify the value in the Command box in the StartCommand or StopCommandproperties of the Tivoli Monitoring resource. The start and stop commandsmust be specified in the StartCommand and StopCommand properties on theMonitor page for the Tivoli Monitoring resource in the policy editor


Step 3: Monitor attribute and valid attribute values:

In this step, retrieve available attributes and attribute values that you need tospecify in the MonitorAttribute element and the corresponding state mappingelements.

About this task

A typical Tivoli Enterprise Portal workspace contains multiple views where eachview displays data from an agent attribute group. If you want to use an attributethat is displayed in a workspace view as MonitorAttribute for System Automation,you first need to determine the corresponding attribute group name.

Procedure

1. Use the Tivoli Enterprise Portal Navigator to navigate to the managed systemfor which you want to determine the name of an attribute group correspondingto a workspace view. Open the workspace that contains the workspace view.

2. Select the workspace view that displays the status information that you want touse to define the availability state of the Tivoli Monitoring resource. right-clickin this workspace view and select “Properties”.

3. In the "Properties" dialog, find the required Attribute Group by selecting Clickhere to assign a query .

4. In the “Query Editor" dialog, find the matching Attribute Group in the tree onthe left:

5. In this example, the matching Attribute Group is Application_Server. If thedisplayed name contains any spaces, replace them with the underscorecharacter.

Important:

v Application_Server is the displayed name of the attribute group name.Replacing spaces with underscore characters is an attempt to create theinternal name of the attribute group as it is known to the Tivoli Monitoringagent. This internal name is also the name that must be specified in thepolicy. Nevertheless, in some cases the internal name is still different (forexample, the DB2 agent uses different internal names). To ensure the rightnames for attribute group and attribute name, verify that the name exists inthe agent's .atr file. For more information, see “Determine attributes andattribute values from Tivoli Monitoring agent attribute files” on page 276.

v The User's Guides of the corresponding Tivoli Monitoring agents, contain adetailed reference of all agent attributes. Refer to these documents to find adescription of the attributes and their values.

6. Click Cancel close the “Query Editor" dialog and return to the “Properties”dialog.

7. Select the Filters tab and find the attribute which you want to use for mappingas System Automation observed state. In the example below the attribute nameis “Status”.As described for the attribute group in the previous steps, you may have tospecify an internal attribute name which is different from the displayed name.When you click into an empty cell of this attribute row, a list which shows youall defined attribute values for this attribute is displayed. For each listedattribute value, decide to which System Automation observed state value it ismapped. This mapping is defined using the MonitorValueOnline,MonitorValueOffline, and other elements.


You now determined all required values for monitoring the availability state ofthe resource:v The attribute group name (in this example: Application_Server),v The attribute name (in this example: Status)v The attribute value mappings.

8. In the policy editor, specify the attribute group name and the attribute name inthe Monitor Attribute section for the Tivoli Monitoring resource.

9. Define state mappings for the attribute values on the State Mappings page forthe resource.

Alternative ways to retrieve information for Tivoli MonitoringResource policy values

About this task

This section describes how you can use the Tivoli Enterprise Portal (TEP) orcommand line commands as an alternate source to retrieve managed systemnames, "Take Action" commands, and resource attributes. These values are requiredto create an agentless adapter policy to monitor and control Tivoli Monitoringresources. Also refer to the previous topics for a description of the preferred wayto gather this information.

Displaying a list of all Managed Systems:

About this task

To open the Managed System Status workspace, perform these steps:

Procedure

1. Click the Enterprise Navigator item to open its default workspace.2. Either right-click the Enterprise Navigator or open the View menu, then select

Workspace > Managed System Status The Managed System Status table viewwith a list of the monitoring agents in your managed network is displayed.Look for the agent which is used to monitor the application that you want tointegrate in an agentless adapter policy. The “Name” column shows themanaged system name that must be specified in the node attribute of theresource element.Using the Command Line

To display a list of all available managed systems, run the following commandon the hub Tivoli Enterprise Monitoring Server:tacmd listSystems

Take Action commands:

About this task

Procedure

1. Enter the following command to list all available Take Action commands for aspecific agent product code:tacmd listAction –t <pc>

To list, for example, all actions for the Web Server Agent which has the productcode HT, use the command:tacmd listAction –t HT


The output contains a NAME column which lists the names of the availableTake Action commands.

2. Enter the following command to display the details for a selected Take Actioncommand:tacmd viewAction -n <action_name> -t <pc>

To view, for example, the details for the “Start DB2” command:tacmd viewAction -n "Start DB2" -t UD

The output contains the Command value that must be specified in theStartCommand and StopCommand properties for an Tivoli Monitoring resource.

Determine attributes and attribute values from Tivoli Monitoring agent attributefiles:

About this task

The available attribute groups, attributes, and values for an Tivoli Monitoringagent can be determined from the *.atr file of the respective agent. Attribute filesare available for every agent type and are on the hub Tivoli Enterprise MonitoringServer in the <ITM_Root>/tables/<TEMS_Name>/ATTRLIB directory. The file name foran attribute file is:k<pc>,atr, where pc is the two letter product code of an TivoliMonitoring agent. For example, klz.atr is the attribute file for the Linux OS agent.

Here is an example of an entry in such an attribute file:entr ATTRname Apache_Web_Server.Statusaffi 000000000000000000000000000G0000##000000000colu STATUStype 4mini -2147483648maxi 2147483647msid KHT0714opgr 2048atid 00030088vale Stoppedvali 0vale Runningvali 1vale Errorvali 2vale N/Avali -1

The highlighted lines are in particular of interest if you want to integrate aresource that is monitored by the respective Tivoli Monitoring agent into anagentless adapter policy.

name Specifies the attribute group (“Apache_Web_Server”) and attribute name(“Status”) separated by a dot. You must specify this value for the“MonitorAttribute” XML policy element.

vale These entries specify the value set for the “Apache_Web_Server.Status”attribute. You can use them to define state mappings for Tivoli Monitoringresources in the Agentless Adapter policy. For example, you could definefor a resource that is monitored by this agent type that the value“Running” is mapped to an SAObservedState “Online”.


Activate and test the agentless adapter policy

Activating the agentless adapter policy:

About this task

After you created the agentless adapter domain policy as described in the previoussections and stored it in the Agentless Adapter policy pool, you can now activate itfrom the operations console. Open the Activate Automation Policies dashboardand select the Tivoli Monitoring domain.

The available policies for the selected domain are listed. Select the new policy andclick Activate.

After the policy is activated, the agentless adapter connects to the configured TivoliEnterprise Monitoring Server and attempts to retrieve the agent attributes whichwere specified as monitor attribute in the policy for all defined Tivoli Monitoringresources. After a few seconds, the resources displayed in the operations consolechange their observed state from “Unknown” into either “Online” or “Offline”.

If the status does not change, you must check the log of this specific TivoliMonitoring domain. You can view the log by selecting the Tivoli Monitoringdomain and clicking View log in the context menu of the domain. This problemcould occur if you did not specify the correct user credentials for accessing theTivoli Enterprise Monitoring Server. In this case, you must now specify thecredentials as described in “Configuring user credentials to access the monitoredresources” on page 265 and restart the agentless adapter.

Note: The last active policy of the Tivoli Monitoring domain is automaticallyreactivated only if you also configured valid First-level automation credentials foryour Tivoli Monitoring domain using the cfgeezdmn configuration utility.

Displaying Tivoli Monitoring resources in the operations console:

After policy activation, you can open the domain page from the context menu ofthe Tivoli Monitoring domain in order to view the defined Tivoli Monitoringresources and corresponding nodes.

About this task

In the Properties dialog of a Tivoli Monitoring resource you see the new resourceclass IBM.ITMResource together with the information about on which endpoint thisresource is located. This information is also displayed in the Relationships graph.

On the Additional tab of the resource's Properties dialog, you find the TivoliMonitoring specific start/stop actions and also which attribute is being used todetermine the availability state and the current value of this attribute.

Start/Stop a Tivoli Monitoring Resource using the operations console:

About this task

An Tivoli Monitoring resource offers the same start/stop behavior as standardremote resources of class IBM.RemoteResource which are also managed by theagentless adapter. Depending on the current observed state, an operator can eitherissue a “Bring Online / Bring Offline” or “Restart” command.


The resource itself is in “Starting” state while the start action is running. Themaximum time that the resource is allowed to be in the "Starting" state is definedfor each start/stop action in the policy. After this action is performed, the observedstate is set according to the availability state attribute of the Tivoli Monitoringresource. Since the agentless adapter offers no automation capabilities, there is nodesired state and therefore also no indication that the current state does not reflectthe desired state.

Managing Tivoli Monitoring resources as part of a compositebusiness application

Create an end-to-end automation policy for Tivoli Monitoring resources:

About this task

This section describes how to add Tivoli Monitoring resources as referencedresources of the end-to-end automation domain to achieve the following:v Define an automated startup or shutdown sequence of different Tivoli

Monitoring monitored resources, hosted on different Tivoli Monitoringendpoints. An integrated startup or shutdown sequence can be defined for TivoliMonitoring monitored resources and other automated resources that arecontrolled by another automation domain such as System Automation forMultiplatforms, System Automation z/OS, or PowerHA.

v Tivoli Monitoring resources in an agentless adapter domain have no desiredavailability state. By integrating them into the end-to-end automation domain itis possible to automatically react when undesired outages of these TivoliMonitoring Resources occur.

v The grouping concepts in the end-to-end automation policy allow you to createcomposite application groups of Tivoli Monitoring resources. These compositeapplication groups can be managed as one entity in the System Automationoperations console and provide an aggregated availability state.

Create ResourceReferences referring to the Tivoli Monitoring resources as youwould for any other first level resources. You can collect the required attributes,like resource name and resource class from the resource's Properties dialog.

What to do next

After having created the desired resource references to Tivoli Monitoring resources,your policy already serves one purpose: When it is activated on the end-to-enddomain, the System Automation Application Manager ensures the defined desiredstate and restarts every Tivoli Monitoring resource if it is failing.

Next, you can define a group in the end-to-end automation policy and add theresource references as group members. Give your new group a meaningful name,for example PortalGroup. With this configuration you can manage multiple TivoliMonitoring resources as one composite group.

You can also create relationships between the resource references therebycontrolling the startup behavior of the Tivoli Monitoring resources.

After you finished creating this first end-to-end policy, you must save it into thepolicy pool directory of the System Automation Application Manager.


Activate the end-to-end automation policy:

About this task

Open the Activate Automation Policies dashboard and select the end-to-endautomation domain.

The available policies for the end-to-end automation domain are listed. Select thenew policy and click Activate.

Control a composite business application consisting of multiple TivoliMonitoring and other clustered resources:

About this task

This section describes how a Tivoli Monitoring resources defined in an activeagentless adapter domain can be automated and controlled in the context of anend-to-end composite business application.

After the end-to-end policy is activated, as described in the previous section, thecomposite application group “PortalGroup” is shown in the Resources widget onthe domain page of the end-to-end automation domain.

As displayed in the Relationships graph of a selected resource reference, theend-to-end automation domain now controls starting and stopping the individualreferenced resource that is defined in the ITM domain.

A composite business application, such as the PortalGroup, can be started by anoperator start request that results in start commands being sent to all referencedTivoli Monitoring resources.

If you specified startAfter relationships between the resource references, they arehonored as well.

In addition, the System Automation Application Manager enforces the defineddesired state and restarts every Tivoli Monitoring resource in case it is failing. Youcan also use forcedDownBy relationships in order to automatically restart relatedcomponents if a Tivoli Monitoring resource fails.

Creating a Tivoli Monitoring situation to trigger an automatedrestart

About this task

So far you learned how to instrument Tivoli Monitoring resources to be managedby the agentless adapter of System Automation Application Manager. You alsoknow how you can create composite business applications by using the TivoliMonitoring resources. The System Automation Application Manager takes over theresponsibility to start these composite applications in a coordinated sequence onrequest by an operator. System Automation Application Manager can also restartthe Tivoli Monitoring resources in unexpected outage situations. These integrationscenarios are defined by using the instrumentation functions provided by TivoliMonitoring.


In this section, you find an example of how to trigger an automated SystemAutomation action based on a defined Tivoli Monitoring situation. This scenariocan be used, for example, to restart a WebSphere Application Server when aspecific Tivoli Monitoring situation, such as average heap size too high, becomestrue.

All operator actions against System Automation Application Manager resourcesfrom the Operations Console can also be triggered by using the SystemAutomation Application Manager command shell (eezcs command). You can issuesuch a command as “System Command” from the Tivoli Enterprise MonitoringServer as an “Action” that is defined for a situation. If the Tivoli EnterpriseMonitoring Server and System Automation Application Manager are installed ondifferent servers, you must run this command remotely on the System AutomationApplication Manager server using the “ssh” command. The following figure showsan example of how to define such a command.

Any System Automation resource (not only Tivoli Monitoring resources) can be thetarget of such a start/stop/restart request action. You can start resources which are,for example, automated by an System Automation for Multiplatforms, SystemAutomation for z/OS or PowerHA domain.

Integrating with Tivoli Monitoring and Tivoli CompositeApplication Manager (ITCAM)

The Tivoli Monitoring (Tivoli Monitoring) and Tivoli Composite ApplicationManager (ITCAM) family provides availability and performance monitoring ofessential system resources and applications on a wide variety of operating systemsand platforms.

Figure 36. Perform an System Automation Application Manager command shell command asaction for an Tivoli Monitoring situation


System Automation Application Manager can be used to control and automateresources which are monitored by Tivoli Monitoring or ITCAM.

The System Automation Application Manager provides simplified control ofmulti-tiered business application landscapes found in data centers today. Forinstance, an “Online Trading Application” consisting of a set of web servers,several WebSphere (Java Platform, Enterprise Edition) servers, and a back-enddatabase can be managed as a singe entity. As a result, an operator can restart theOnline Trading Application in a single step.

System Automation Application Manager provides a broad set of adapters withwhich to perform the automation steps on the endpoints where the softwarecomponents of the business applications are running. For example, adapters forendpoints runningSystem Automation for Multiplatforms, Tivoli SystemAutomation for z/OS, PowerHA® (PowerHA), Microsoft Failover Cluster (FOC)and Veritas Cluster Server (VCS) are available. Additionally, the agentless adapterallows you to remotely control software components on endpoints where no agentis installed.

Furthermore, the agentless adapter can be used to integrate software componentsvia the Tivoli Monitoring agent technology as shown in the illustration. You canuse a combination of different adapter technologies to manage a multi-tieredbusiness application.

The Following illustration shows an example configuration with SystemAutomation Application Manager managing Tivoli Monitoring Managed Endpointsand HA Clusters as composite applications.

System Automation Application Manager integrates with Tivoli Monitoring andITCAM by using existing Tivoli Monitoring resource instrumentation (Tivoli

Figure 37. Example of System Automation Application Manager managing Tivoli Monitoring Endpoints and HA clusters


Monitoring agents). This means that the System Automation Application Managerretrieves monitoring information from Tivoli Monitoring agents and is capable toperform start and stop operations through them. Software components which wereuntil now only monitored by Tivoli Monitoring, now become resources managedby System Automation Application Manager.

Tivoli Monitoring resources can even become automated members of complexbusiness applications within System Automation Application Manager automationpolicies.

The integration between Tivoli Monitoring and System Automation ApplicationManager is bidirectional. System Automation Application Manager receivesmonitoring information from Tivoli Monitoring agents, and invokes start/stopoperations through those agents. Tivoli Monitoring delivers a huge variety ofagents. The integration of System Automation Application Manager with TivoliMonitoring allows you to integrate every type of Tivoli Monitoring agent:v Application agents (also referred to as non-OS agents), including custom agentsv OS agents

System Automation Application Manager provides predefined templates for theintegration of the following agents:v Apache Web Serverv WebSphere Application Serverv DB2v Custom agents built using the Tivoli Monitoring Agent Builderv Linux OS agentv UNIX OS agent

These templates can be used to easily create resource definitions for TivoliMonitoring resources.

Integration benefits for existing System Automation ApplicationManager customers

From the System Automation Application Manager composite automation featurepoint of view, this integration allows you to:v Integrate Tivoli Monitoring resources in System Automation Application

Manager end-to-end automation scenarios to control and automate composite,heterogeneous business applications

v Use existing Tivoli Monitoring agents to monitor and control applicationcomponents through System Automation Application Manager instead of usingalternative adapter technologies

v Integrate resources managed by high availability clusters (System Automationfor Multiplatforms, System Automation for z/OS, PowerHA, FOC, VCS) andremote System Automation resources which are monitored using the agentlessadapter with Tivoli Monitoring monitored resources to have a single point-ofcontrol.

Integration benefits for existing Tivoli Monitoring customers

Adding System Automation Application Manager to an existingTivoli Monitoringmonitored infrastructure has the following benefits:


v Extends the visualization solution to an application automation solution bydefining business applications and their dependencies.

v Provides consistent and automated start and stop of business applications andtheir components.

v Increases the availability of the Tivoli Monitoring managed systems andapplications through automatic recovery in failure situations.

v Provides a solution which is based on the existing Tivoli Monitoringinfrastructure without the need to install additional agents.

Integration Scenarios with Tivoli Monitoring and IBM TivoliComposite Application Manager (ITCAM)

The Tivoli Monitoring (Tivoli Monitoring) and Tivoli Composite ApplicationManager (ITCAM) product families provide availability and performancemonitoring of essential system resources and applications on a wide variety ofoperating systems and platforms.

The integration solution of System Automation Application Manager and TivoliMonitoring brings the following advantages:v Integration of Tivoli Monitoring resources in System Automation Application

Manager end-to-end automation configurations to control and automatecomposite, heterogeneous business applications.

v Increased availability of the Tivoli Monitoring managed systems andapplications through automatic recovery in failure situations.

v A single-point-of control for resources managed by high availability clusters, forexample System Automation for Multiplatforms, System Automation for z/OS,all remote resources which are monitored and controlled using the agentlessadapter, and Tivoli Monitoring managed resources.

v Launch-in context from System Automation Application Manager to thecorresponding resource displayed in the Tivoli Enterprise Portal.

v Use Tivoli Monitoring situations to trigger an automated restart by the SystemAutomation Application Manager.

For more information, see System Automation Application Manager Installation andConfiguration Guide, Integrating, Tivoli Monitoring and Tivoli Composite ApplicationManager.

zEnterprise Hardware Management ConsoleThis topic describes how to set up the zEnterprise Hardware Management console(HMC) to use with System Automation Application Manager.

Setting up the Hardware Management ConsoleTo use the web services API of the zEnterprise System Hardware ManagementConsole (HMC), perform the following steps:1. Define a user with the appropriate management scope and task roles to access

objects and perform actions using the HMC.2. Enable the web services API in general, and enable the user you defined in the

first step to access this interface.3. Deploy and enable the Guest Platform Provider (GPMP) on the virtual servers.

System Automation Application Manager requires operating system-specificinformation such as OS name and host name for these servers.


These steps are described in detail in the following sections. For a comprehensivereference about management scope and task roles, and for information aboutconsole actions to administer the Hardware Management Console environment, seeTivoli Composite Application Manager.

Defining a userAbout this task

The following steps describe how to define a new user to the HMC:1. Login to the HMC with the predefined user ACSADMIN or with a user having

authorization to define new users.2. Select the User Profiles task3. Add a new user with these characteristics:

a. Select the type Authentication. For Local Authentication, you must specify apassword. If you select LDAP Server as the means for authentication , theserver managing the directory that lists the user must be selected or definedfirst.

b. Select the Managed Resource Roles that determine to what objects the useris permitted access. For systems management functions such as monitoring,and discovery and availability management, the user should have access toall resources within the scope of the ensemble managed by this HMC. Togrant this permission, select the following predefined roles:v BladeCenter Objectsv DPXI50z Blade Objectsv Defined zCPC Managed Objectsv Ensemble Objectv IBM Blade Objectsv IBM Blade Virtual Server Objectsv ISAOPT Blade Objectsv Workload Objects

If you want to limit access to certain resources only, you must define thecorresponding roles.

c. Select the Task Roles that determine what tasks are permitted on theManaged Resources selected above. Select the following predefined roles orequivalent roles that you have created for this HMC:

Required task permissions

v Activate Taskv Deactivate Task (Daily task group)

Applicable predefined HMC task roleOperator Tasks

d. Select other User Properties. Select Allow Access to management interfaces toenable the user to use the Web Services API.

Enabling Web Services APIAbout this task

To enable the Web Services API, do the following:1. Login to the HMC with the predefined user ACSADMIN or with a user with

authorization to customize API settings.2. Select the Customize API Settings task.


http://www.ibm.com/support/knowledgecenter/SS3JRN/welcome?lang=en

3. Select Web Services and either enable ALL or just the specific IP addresses thatare allowed to connect to this HMC.

4. Check that the user through which System Automation Application Managerlogs on to the HMC is selected under User Access Control. Users are selectedautomatically if the Allow Access to management interfaces user property was setfor this user. (See “Defining a user” on page 284, Step 2d.)

Deploying and enabling the Guest Platform ManagementProviderAbout this task

The Guest Platform Management Provider (GPMP) is an optional component thatmust be deployed and enabled becauseSystem Automation Application Managerrequires information such as the operating system name, or the host name tocorrelate a virtual server with similar information obtained from other sources.

Note: For z/OS environments, you need only to configure and start the GPMP,because this component is already part of the z/OS Version 1.12 operating system.

For detailed instructions on how to deploy GPMP, refer to zEnterprise EnsemblePerformance Management Guide, “Installing and configuring guest platformmanagement providers” (GC27-2607-04).

Obtaining the Hardware Management Console certificateAbout this task

The communication over secure HTTP requires that all data is encrypted using asecret key. For key exchange, the HMC sends its certificate to the client who canthen validate it and once trusted, the keys can be exchanged

To allow System Automation Application Manager to validate the certificate, thetruststore for the hardware adapter for zEnterprise HMC access must contain acopy of the public part of the server certificate or it must have a copy of the publicpart of the Certificate Authority's (CA) certificate. If a server certificate is not foundin the truststore but the certificate of the CA that signed the server's certificate isfound, the validation can still be performed.

For self-signed certificates, or for certificates that are signed by a CA that is not inSystem Automation Application Manager's hardware adapter truststore it isnecessary to first obtain a copy of the public part of the certificate. You can do thisby typing in the web address of the HMC into the address field of your browser.

If this is the first access of the HMC for the current web browser session, you canreceive a certificate error. In this case, follow the instructions provided by thebrowser to view and export the certificate. You might have to authenticate with anadministrator userid and password before the browser allows you to export thecertificate. A sample process for the Firefox browser is described for your reference:1. Access the HMC by entering the host name or IP address of the HMC in the

URL input field.2. If the certificate cannot be validated, a warning window with the title “This

Connection is Untrusted”. Click I Understand the Risks and click AddException.

3. The Add Security Exception dialog is displayed.


4. Click Get Certificate. This allows the browser to get the certificate andtheView... button is enabled.

5. Click View... to open the Certificate Viewer dialog.6. Verify who issued the certificate and to whom it was issued. If correct, Click

Details and Export to save the certificate on your disk.7. The certificate is stored in text format and can now be copied to the machine

where System Automation Application Manager is running and imported intothe truststore.

Creating a truststore for the hardware adapterAbout this task

Use the Java tool keytool to create the truststore for the hardware adapter:1. Go to the Java installation directory. You can use the Java bundled with

WebSphere Application Server in the <WAS_INSTALL_ROOT>/java directory.2. Create a truststore using keytool and add the certificate to the truststore:

<WAS_INSTALL_ROOT>/java/jre/bin/keytool -import -alias <anyAlias>-file <path to your HMC certificate> -keystore <YourTruststoreFile>

Where:

<anyAlias>Is the name you use as an alias for your HMC certificate

<path to your HMC certificate>Is the fully qualified path of the HMC certificate you retrieved using theprocedure described in “Obtaining the Hardware Management Consolecertificate” on page 285.

<yourTruststoreFile>Is the name of an existing or a new truststore.

When you run the command, you are prompted to specify a password for thetruststore. To verify that the HMC certificate was successfully added, use thefollowing command:<WAS_INSTALL_ROOT>/java/jre/bin/keytool -list - keystore <yourTrustStoreFile>

Firewall considerationsWhen the web services API is enabled, the HMC API HTTP Server listens for SSLbased socket connections on TCP port 6794. The HMC is enabled for both SSLVersion 3 and TLS Version 1 protocols on this SSL port. It does not acceptconnections that are not SSL.

As part of the web services API, the HMC provides an integrated JMS brokerbased on Apache ActiveMQ Version 5.2.0. This message broker is active on theHMC whenever the web services API is enabled.

When active, the integrated broker listens for client connections using thefollowing transports supported by ActiveMQ:v OpenWire flowing over SSL connections, listening port 61617.

The broker is enabled for SSL Version 3 and TLS Version 1 protocols on these SSLports.

The listening ports listed above for the API and for the message broker are fixedport numbers and are not configurable. If you have firewalls between System


Automation Application Manager and the HMC, contact your system administratorto set up firewall rules that enable communication over these ports across firewalls,

Working with the discovery library adapterSystem Automation Application Manager provides a Discovery Library Adapter(DLA) to export the currently active System Automation Application Managerresource topology to an Identity Markup Language (IdML) discovery book.

About this task

The resulting IdML book can be loaded into IBM Tivoli Application DependencyDiscovery Manager (TADDM). The loaded IdML book replaces any previousconfiguration items that are related to this System Automation ApplicationManager instance. For more information about TADDM, see http://www.ibm.com/software/tivoli/products/taddm.

For information about the configuration of the DLA, refer to “Discovery LibraryAdapter tab” on page 108.

You use the command eezdla to create IdML books for System AutomationApplication Manager. Proceed as follow:1. Log on to the system on which the automation manager is running.

Note: While the end-to-end manager is kept highly available, the end-to-endmanager moves from one system to another.

2. Enter the command eezdla3. When the command is completed, check its return code using the command

echo $?.The following table lists the return codes that are returned by the commandeezdla.

Table 53. eezdla return codes

Code Description

0 an IdML book was created successfully.

1 the usage statement was displayed as the eezdla script was started with aparameter; no IdML book was created.

2 an error occurred; no IdML book was created.

If the return code is 2, check the message log of the end-to-end automation enginefor indications why the DLA failed. You can either use the "View log" function forthe end-to-end domain in the operations console, or open the message log filedirectly (msgEngine.log or msgFlatEngine.log). Log files are stored in thesubdirectory eez/logs of the Tivoli Common Directory.

Alternatively, set up a scheduling tool to regularly start the eezdla script.

The resulting IdML book is stored at the location that is configured on theDiscovery Library Adapter tab in the end-to-end configuration tool.

Following the guidelines for naming IdML books, the names of IdML bookscreated by System Automation Application Manager start with the application code"EEZ", followed by the host name of the system on which the automation manageris installed and an Coordinated Universal Time timestamp. For example:


http://www.ibm.com/software/tivoli/products/taddm

http://www.ibm.com/software/tivoli/products/taddm

EEZ3210.e2esrv1.friendly.com.2010-02-15T14.57.47.093Z.refresh.xml

eezdla options quick referenceThe following table presents an overview of the options that are available for thecommand.

Table 54. Command line options for the discovery library adapter

Option Short form Description

-help -? Displays a help text that lists the command options.

eezdla optionsThis topic provides a detailed description of the options you can use with theeezdla command.

Note: Options can be entered in either lowercase or uppercase.

Use this option to display the following help text:

IBM Tivoli System Automation discovery library adapter

Usage:eezdla

Purpose:Use this utility to discover the System Automation Application Manager resource topology.The discovery is based on the active end-to-end automation policy.The resulting discovery book is an IdML file.It may be loaded into IBM Tivoli Application Dependency Discovery Manager.

JazzSM Administration ServicesSystem Automation Application Manager version 4.1 provides the capability toregister resources through Administration Services of another JazzSM installation.This allows users to control resources from remote and get status information forSystem Automation Application Manager resources, which are defined in theend-to-end automation policy.

The Administration Services provides an interface to register and control resourcesand stores the data in the Registry Services. This data is compliant with the OpenServices Lifecycle Collaboration (OSLC) standard. OSLC Open Services forLifecycle Collaboration is an open standard by the OASIS consortium.

If the integration with JazzSM Administration Services is configured, the resourcesof the end-to-end automation policy are automatically registered. After registrationthese resources can be viewed and controlled by sending requests using a RESTinterface.

System Automation Application Manager supports the following actions forregistered resources:v List resources from the end-to-end automation policy.v Get the status of a resource from the end-to-end automation policy.v Send a start request to a resource of the end-to-end automation policy.v Send a stop request to a resource of the end-to-end automation policy.

Benefits of the OSLC integration:


http://open-services.net/

http://open-services.net/

v Any program or script can be extended with code that is building the httpsconnection and sending the REST calls.

v By calling the REST interface it is not necessary for a user to have the authorityto log on to the operating system running the System Automation ApplicationManager.

v A REST call does not need to start a JVM, multiple single actions can sendrequests faster.

JazzSM integration scenario

If you want to integrate with JazzSM Administration Services, a setup of twoWebSphere installations is required:1. WebSphere Application Servers hosting System Automation Application

Manager components, running with a 32 Bit JDK.2. WebSphere Application Server hosting the Administration Services and Registry

Services components, running with a 64 Bit JDK.

Both servers needs access to a DB2 database, which may be on any system. Thisdatabase can be the same for both components.

Note: Registry Services and System Automation Application Manager do not needto share a DB2 database.For installing the Administration and Registry Services, see Installing Jazz forService Management.

Registering resources

Resource can only be created or deleted if an end-to-end automation policy isactivated or deactivated. Then the new state of the end-to-end resource topology isregistered within the Registry Services by calling the Administration Services.Following this pattern ensures, that the resource registry and the end-to-endautomation policy resources stay synchronized.

To activate resource registration, provide the necessary configuration parameters inthe OSLC tab of the configuration utility, see “Registering resources.”

If you want to administer registered resources, an Administration Services taskbundle has to be deployed. These task bundles are plug-ins that define actions forresources of a specific type and contain the business logic of the action. Task

with 32bit JDK

WebSphere ApplicationServer V8.5

DASH

System AutomationApplication Manager


AdministrationServices

RegistryServices

with 64bit JDK

Automationdatabase

Figure 38. JazzSM Administration Services integration scenario


http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/install/psc_c_install.html

http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/install/psc_c_install.html

bundles have to be installed manually (see “Installing the task bundle tsaControl”on page 291) and are associated to registered resources if their target type matchesthe resource type of a resource.

1. A new end-to-end policy gets activated, for example end-to-end resourceschange.

2. The automation engine automatically registers the resources at theAdministration Services using REST.

3. For each resource a task bundle is deployed to allow status retrieval and tosend start and stop requests.

Using REST web services

After the registration, end-to-end automation resources can be instrumented usingeither one of the following interfaces provided by Administration Services:v Administration page in DASH: Administration Services UIv Command line interface: Administration Services clientv REST web service

The following actions are available to administer end-to-end automation resources:v Get statusv Send start requestv Send stop requestv List end-to-end resources

Configuring JazzSM Administration Services integration

Configuring the automation engine to register resources

The configuration of the automation engine is necessary to activate the JazzSMAdministration Services integration. You can also define the parameter of theconnection to the other WebSphere Application Server, for example the location,port, or which authority is required to register.

Configure the automation engine for resource registration, by invoking theconfiguration utility with the cfgeezdmn command. The tab OSLC contains therelevant configuration parameters. For silent configuration the parameters areconfigured as part of the common configuration settings. The parameters names,their type and function are listed in the following table:

1

2 3

with 32bit JDK


DASH




RegistryServices

with 64bit JDK

EEZ administrator

Figure 39. Registering resources for OSLC


http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/admin/as_c_ui_oview.html

http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/config/as_c_config_client_cli.html

Table 55. OSLC tab of the configuration utility

Parameter name Type Description

oslc-enable boolean Decides whether resources will beregistered at Administration Services.

oslc-server-name String, host nameor IP

The host name or IP of the systemhosting the Administration Services.

oslc-server-port Integer, port The WC_DEFAULTHOST_SECURE port ofWebSphere Application Server hostingthe Administration Services.

oslc-registry-userid String userID The WebSphere Application ServeruserID which executes the registry call.The RegistryAdminRole is required.

oslc-registry-password String, password The password of the user defined bythe oslc-registry-userid.

oslc-ssl-truststore String, filename Filename of a truststore file of typeJKS which contains the certificate ofthe WebSphere Application Serverhosting the Administration Services.

oslc-ssl-truststore-password

String, password Password to access the file defined byoslc-ssl-truststore.

The truststore can be created by importing the certificate and defining a newfilename by using the Java Keytool with the following command:keytool -import -alias oslc -file $certificateFile -keystore oslcKeystore.jks

After configuration restart or refresh the automation engine.

Installing the task bundle tsaControl

Upon registration, resources in the Registry Services do not have any associatedactions. Installing the appropriate task bundle associates the resources of a specifictype to the actions defined the task bundle.

Since the application logic of the task bundles needs to establish anhttps-connection to the WebSphere Application Server hosting System AutomationApplication Manager, it is required to provide the certificate to the local opensslinstallation.

System Automation Application Manager provides the task bundle tsaControl as aZIP archive, located in the subfolder integration on the installation medium.

To install tsaControl, execute the following steps:1. Install openssl, if not already installed.2. Copy the ZIP archive to the machine where Administration Services is installed.3. Install the task bundle using the Administration Services CLI using the

following command:$jazzSMInstallDir/admin/bin/adminservices.sh -installTasks $pathOfTaskBundle/tsaControl.zip

4. Add the certificate of the WebSphere Application Server hosting SystemAutomation Application Manager to the OPENSSLDIR of the openssl installation.This information can be retrieved by executing the command:openssl version -a


Administering registered JazzSM Administration Servicesresources

Calculating the ResourceID from the ResourceKey

The Administration Services Resource Registry needs an unique identifier todistinguish resources. The Administration Services do not allow characters likeblanks or slashes in their ID. For System Automation Application Manager, theResourceKey serves as the unique identifier. As characters like blanks or slashesare allowed in System Automation Application Manager, the ResoruceKey cannotbe used as identifier in the Administration Services Resource Registry.

Perform the following steps to transfer the ResourceKey into a ResourceID for theAdministration Services Resource Registry:1. Calculate the SHA-1 checksum of the ResourceKey (String literal, UTF-8

encoded).2. Execute a base16 (hexadecimal) encoding of the SHA-1 checksum.3. If the base16 encoder produced lower case letters, convert to uppercase letters.

The result is a String containing exactly 40 characters of the character class[0-9A-F].

Administering the tsaControl Task Bundle

The tsaControl task bundle associates itself automatically to any resource of thetype TSAResource registered via Admin Services. Since the automation engineregisters all resources from the end-to-end automation policy with this resourcetype, the association will always be established.

When called the action requires the following parameters:

host nameHostname or IP of the WebSphere Application Server hosting SystemAutomation Application Manager.

port Default host secure port of the WebSphere Application Server hostingSystem Automation Application Manager.

user EEZ user that has the authority to perform the actions.

passwordPassword of the EEZ user.

action One action from the list:v statusv startv stop

resourceKeyEEZResourceKey in this format:$domainName:$resourceClass:$resourceName[:$flaDomain]

For example, FriendlyE2E:ResourceReference:Ref2:cluster1 orFriendlyE2E:ResourceGroup:RG1

commentA comment (optional). If the performed action is 'status', the comment willbe discarded


Operating the Administration Services user and command lineinterface

If you want to find out how to operate the Administration Services user interface,see Administration Services UI .

If you want to find out how to operate the Administration Services command lineinterface, see Administration Services client

Operating the Administration Services REST web service

A client sends a REST call to the Administration Services using his REST interfaces.If the call is a request, the Administration Services will send a reply to indicatewhether the request has been accepted. If the call is a request to invoke thetsaControl task bundle, the application logic of the task bundle contacts the DASHof the System Automation Application Manager and executes the desired action.

A second call by the client is made to retrieve the result. The answer fromAdministration Services will contain the data returned by the tsaControl taskbundle.

1. An OSLC compatible client polls for the available resources of typeTSAResource.

2. Administration Services returns a list of resources from the registry.3. OSLC client determines the available actions for the resource.4. OSLC enters an action status, start, or stop against the TSAResource using

the task bundle.5. The task bundle issues an appropriate call to the data provide registered in

DASH.

If you want to use the REST interface, execute the following steps:1. Select the tool to send the REST call. This may be a Java® program, a PERL

script or a browser plug-in. Many programming or scripting languages providemethods and modules to generate http requests of any kind.

2. Create an HTTP request with the appropriate method GET or POST. Listingresources and retrieving results requires GET, invoking an action requires POST.

1 2

3 4

5

OSCL client

with 32bit JDK


DASH




RegistryServices

with 64bit JDK

Figure 40. Using OSLC web services interfaces


http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/admin/as_c_ui_oview.html

http://www.ibm.com/support/knowledgecenter/SSEKCU_1.1.0.2/com.ibm.psc.doc_1.1.0.2/config/as_c_config_client_cli.html

3. Attach basic authorization to the HTTP request, using OSLC username andOSLC password. In order to successfully execute the call the user must haveproper authorization in die JazzSM Administration Services context.

4. Configure the client to accept the certificate of the WebSphere AdministrationServer running the Administration Services. Methods include using a KeyStoreor leveraging the openssl configuration.

5. The documentation of the JazzSM Administration Services REST interfacesshows the URLs, methods, expected parameters, and necessary authentication.For more information, see Administration Services Provider REST Interfaces .

6. If the HTTP request is a POST request the content needs to be defined. For taskbundle invocation the parameters listed in “Administering the tsaControl TaskBundle” on page 292 need to be added to the RDF/XML document to be sent.Each parameter requires a section like the following:<rdf:Description rdf:nodeID=\"A7\"><rdf:value>$variableValue</rdf:value><$oslc:name>variableName</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description>

7. Build the REST call and send it. If the call was a request, the immediate answerwill confirm the acceptance of the request only. A second call to retrieve theresult must be made to access the results of the executed action.

Example: Get the status information of an end-to-end resource using a PERLscript:

1. Get the following input:v System Automation Application Manager: host name, port, user, passwordv OSLC: host name, port, user, password, ResourceKey

2. Calculate the ResourceID from the ResourceKey. For more information, refer to“Calculating the ResourceID from the ResourceKey” on page 292.

3. Build the HTTP Request with the following parameters:a. URL:

my $url = https://$oslcHost:$oslcPort/admin/services/tasks/request/tsaControl/$resourceID

b. Create a HTTP POST Request object:my $request = HTTP::Request->new(POST => $url);

c. Define application/rdf+xml as the content type:$request->header(’Content-Type’ => ’application/rdf+xml’);

d. Authorization with $oslcUser and $oslcPassword:$request->authorization_basic($oslcUser, $oslcPass);

e. Create the user agent:my $ua = LWP::UserAgent->new( (...) );

f. Define content:my $postData = "<rdf:RDF #

xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\"xmlns:dcterms=\"http://purl.org/dc/terms/\"xmlns:rdfs=\"http://www.w3.org/2000/01/rdf-schema#\"xmlns:oslc=\"http://open-services.net/ns/core#\"xmlns:j.0=\"http://open-services.net/ns/auto#\" >

<rdf:Description rdf:nodeID=\"A0\"><rdf:value>$saamHost</rdf:value><oslc:name>host name</oslc:name><rdf:type rdf:resource=\"http://open- services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A1\"><rdf:value>$saamPort</rdf:value>


https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W8b1151be2b42_4819_998e_f7de7db7bfa2/page/Administration%20Services%20Provider%20REST%20Interfaces

<oslc:name>port</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A2\">

<rdf:value>$saamUser</rdf:value><oslc:name>user</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A3\"><rdf:value>$saamPass</rdf:value><oslc:name>password</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A5\">

<rdf:value>status</rdf:value><oslc:name>action</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A7\"><rdf:value>$resourceKey</rdf:value><oslc:name>resourceKey</oslc:name><rdf:type rdf:resource=\"http://open-services.net/ns/auto#ParameterInstance\"/>

</rdf:Description><rdf:Description rdf:nodeID=\"A6\"><j.0:executesAutomationPlan rdf:resource=\"https://$oslcHost:$oslcPort/admin/

services/tasks/actions/tsaControl/automation\"/><j.0:inputParameter rdf:nodeID=\"A0\"/><j.0:inputParameter rdf:nodeID=\"A1\"/><j.0:inputParameter rdf:nodeID=\"A2\"/><j.0:inputParameter rdf:nodeID=\"A3\"/><j.0:inputParameter rdf:nodeID=\"A4\"/><j.0:inputParameter rdf:nodeID=\"A5\"/><j.0:inputParameter rdf:nodeID=\"A7\"/><rdf:type rdf:resource=\"http://open-services.net/ns/auto#AutomationRequest\"/></rdf:Description>

</rdf:RDF>";

g. Attach the content to the request:$request->content($postData);

h. Send the requestmy $rsp = $ua->request($request);

i. After the request has been processed by Administration Services the resultcan be retrieved by sending a GET request to the URL:

https://$oslcHost:$oslcPort/admin/services/tasks/result/tsaControl/$resourceID

Building a REST call to get all ResourceIDs:

Use the following code:URL url = new URL("https://" + host name + ":" + port + "/admin/services/adminresources/collection");HttpsURLConnection.setDefaultHostnameVerifier(hv);HttpsURLConnection urlConn = (HttpsURLConnection) url.openConnection();FileInputStream fisKeyStore = new FileInputStream(keyStoreLocation);keyStore.load(fisKeyStore, keyStorePassword);// Setup a SSL socket factory via SSLContext and TrustManagerFactoryString userCredentials = user + ":" + password;String basicAuth = "Basic " + new String(DatatypeConverter.printBase64Binary(userCredentials.getBytes()));urlConn.setRequestProperty ("Authorization", basicAuth);urlConn.setRequestMethod("GET");urlConn.setAllowUserInteraction(false); // no user interactionurlConn.setRequestProperty("Content-type", "application/rdf+xml");urlConn.setRequestProperty("charset", "UTF-8");urlConn.setRequestProperty("Content-Length", Integer.toString(rdf.getBytes().length));urlConn.setRequestProperty("Content-Language", "en-US");urlConn.setUseCaches(false);


urlConn.setDoOutput(true); // want to sendurlConn.setDoInput(true); // want to receive

//Send requestDataOutputStream wr = new DataOutputStream (urlConn.getOutputStream ());wr.writeBytes(rdf);wr.flush ();wr.close ();

Parsing the status information

You can retrieve the status information using the GET command in the RDF of theresult. The output appears twice, in a j.o:messageDetails section and inrdf:Description/rdf:value and will be formatted depending on the performedaction and whether the action was a success or a failure:

Output, if an error occurred:--- SA AM Status Error BEGIN ---ResourceKey: $resourceKeyError: $messageHTTP Response: $httpResponseCode $httpResponseMessage--- SA AM Status Error END ---

HTTP response codes and messages are defined in RFC 2616 of the IETF.

Output for status information:--- SA AM Status Information BEGIN ---ResourceKey: $resourceKeyDesiredState: $desiredStateObservedState: $observedStateOperationalState: $displayStringOfOperationalStateCompoundState: $compoundState--- SA AM Status Information END ---

If the action was start or stop and no failure occurred, then no additionalinformation is printed.

Any parsing should look for the header line and then parse the following linesuntil the footer line has been reached. The ResourceKey is shown again for easierparsing and matching or building data structures. The header and footer lines canwork as eye catcher for a parser to start and stop its work. All output before theheader or after the footer can possibly be discarded and all important informationis between those two.

Examples:

1. In PERL use the regular expression /^(.+):\s+(.+)$/ and save $1 as key and$2 as value into a hashmap. This method works even if the order changes.

2. Use awk ’{ print $2; }’ to print the status information.

Parsing the resource details information

Viewing one resource with details via AdminServices REST API will return thefollowing RDF. Highlighted is the section with details about the resource:

Sample Answer<?xml version="1.0" encoding="UTF-8"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:oslc="http://open-services.net/ns/core#"xmlns:crtv="http://open-services.net/ns/crtv#"


http://www.ietf.org/rfc/rfc2616.txt

xmlns:art="http://jazz.net/ns/ism/admin#"xmlns:dcterms="http://purl.org/dc/terms/"xmlns:foaf="http://xmlns.com/foaf/0.1/"><art:AdministrableResourcerdf:about="https://saxb56e.boeblingen.de.ibm.com:16311/admin/services/adminresources/

resource/362E96078B8A8F33E462D4848097BBD10ED088B3"><oslc:domain rdf:resource="http://jazz.net/ns/ism/admin/1.0/"/><rdf:type rdf:resource="http://jazz.net/ns/ism/admin#AdministrableResource"/><rdf:type rdf:resource="http://jazz.net/ns/ism/admin#TSAResource"/><rdf:type rdf:resource="http://open-services.net/ns/crtv#ServiceInstance"/>

<dcterms:identifier>362E96078B8A8F33E462D4848097BBD10ED088B3</dcterms:identifier><dcterms:description>This is the reference with the name Enterprise DB2</dcterms:description><crtv:name>DailyE2E:ResourceReference:Enterprise DB2:FEPLEX2</crtv:name><crtv:version>1.0</crtv:version><crtv:parentServiceInstance rdf:resource="http://open-services.net/ns/crtv#NULL"/><dcterms:subject>AdminServices</dcterms:subject><art:healthStatusrdf:resource="https://saxb56e.boeblingen.de.ibm.com:16311/admin/services/adminresources/

status/362E96078B8A8F33E462D4848097BBD10ED088B3"/><oslc:serviceProvider rdf:resource="https://saxb56e.boeblingen.de.ibm.com:16311/oslc/

providers/1390919364264"/><art:relatedJobsrdf:resource="https://saxb56e.boeblingen.de.ibm.com:16311/admin/services/tasks/collection/

362E96078B8A8F33E462D4848097BBD10ED088B3"/></art:AdministrableResource>

</rdf:RDF>



Chapter 5. Securing

Security of System Automation Application Manager depends on securing theconnection used for the adapters.

Security conceptsDepending on your setup, it is required to secure the connections using SSL.

Secure external connections which are established between components using SSL.Especially for external components which are running in different securitydomains, separated by a firewall.

External connections are established between the following components :v The connection between the web browsers in which the IBM Dashboard

Application Services Hub is displayed (HTTP default port 16310, HTTPS defaultport 16311).

v The connection from the automation manager to the automation adapters(default port 2001).

v The connection from the automation adapters to the automation manager(default port 2002). Note that SSL is not supported for this connection.

Note: For information on how user IDs and passwords for end-to-end automationmanagement are managed, refer to Tivoli System Automation Application Manager,Administrator’s and User’s Guide.

Security tabUse the Security tab to configure the properties for the Secure Sockets Layer (SSL)connection to the first-level automation domains.


TruststoreThe fully qualified file name of the truststore file that is used for SSL. ClickBrowse to select a file.

KeystoreThe fully qualified file name of the keystore file that is used for SSL. ClickBrowse to select a file.

Keystore passwordThe password of the keystore file. The password is required if a keystorefile was specified. Click Change to change the password.

Note: If the truststore is in a different file than the keystore, the passwordsfor the files must be identical.

Certificate aliasThe alias name of the certificate to be used by the server. The charactersthat are used for the certificate alias are limited to the following ASCIIcharacters: A – Z, a-z, 0–9, and _ (underscore).


Enforce use of SSL for all first-level automation domainsSelect this check box if you want to enforce that all first-level automationdomains are properly configured to use SSL at the transport layer. Then, allfirst-level automation domains can successfully connect to the end-to-endautomation manager. If not selected, first-level automation domains areconfigured to use SSL on an individual basis. For more information, see“Securing the connection to end-to-end adapters using SSL.”

Securing the connection to end-to-end adapters using SSLSecuring the connection between the end-to-end automation management serverand first-level automation (FLA) adapters.

About this task

The connection between the Application Manager and FLA adapters is a two-waycommunication and all queries and actions are secured with SSL encryption.Sending EIF events from FLA adapters to the Application Manager is not secured.

Note: The term FLA adapter is not limited to adapters that are used tocommunicate with other automation products. It includes the local agentlessadapter as well as remote agentless adapters.

Generating Keystore and Truststore with SSL public andprivate keys

About this task

Generate the following files:v Truststore: Contains the public keys for Application Manager and the FLA

adapters.v Application Manager Keystore: Contains the private key for Application

Manager.v Adapter Keystore : Generate one per adapter. Contains the private key for a

FLA adapter.

Figure 41 on page 301 shows an overview of the involved components, files andsteps to generate the files.


Generate the truststore and the keystore performing the following steps. The keysexpire after 25 years with the default validity set to 9125. Make sure that thepassphrase is at least 6 characters long. The numbers of the steps relate to thenumbers in Figure 41. The values that are used are sample or default values.1. Set variables:

# java keytool from the Application Manager installation directoryJAVA_KEYTOOL=/opt/IBM/tsamp/eez/jre/bin/keytool# Application Manager config file directoryEEZ_CONFIG_DIR=/etc/opt/IBM/tsamp/eez/cfg# keys will expire in 25 yearsKEY_VALIDITY_DAYS=9125# passphrase at least 6 charactersPASSPHRASE=passphrase

2. Generate keystore with public and private keys for FLA adapter:${JAVA_KEYTOOL} -genkey -keyalg RSA -validity ${KEY_VALIDITY_DAYS} \

-alias eezadapter -keypass ${PASSPHRASE} -storepass ${PASSPHRASE} \-dname "cn=SAAM Adapter, ou=Tivoli System Automation, o=IBM, c=US" \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.adapter.keystore.jks"

3. Generate keystore with public and private keys for Application Manager:

Public Keys

FLAAdapter/ApplicationManager

Truststore Private KeyFLAAdapter

Keystore

2376

eez.fla.ssl.properties

Private KeyApplicationManager

Public Keys


Private KeyFLAAdapter

Keystore KeystoreTruststore

Domain A

System Automation Application Manager Server

Domain B


TruststorePrivate KeyFLAAdapter

Keystore

Public Keys


SSL SSL

copy

copy

copy

keytool

FLA adapter

xyz.adapter.ssl.properties

FLA adapter

xyz.adapter.ssl.properties

copy

Figure 41. Keystore and Truststore generation using SSL

Chapter 5. Securing 301

${JAVA_KEYTOOL} -genkey -keyalg RSA -validity ${KEY_VALIDITY_DAYS} \-alias eezapplicationmanager -keypass ${PASSPHRASE} -storepass ${PASSPHRASE} \-dname "cn=SAAM Server, ou=Tivoli System Automation, o=IBM, c=US" \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.applicationmanager.keystore.jks"

4. Export certificate file with public key for FLA adapter:${JAVA_KEYTOOL} -export -alias eezadapter \

-file "${EEZ_CONFIG_DIR}/ssl/eezadapter.cer" -storepass ${PASSPHRASE} \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.adapter.keystore.jks"

5. Export certificate file with public key for System Automation ApplicationManager server:

${JAVA_KEYTOOL} -export -alias eezapplicationmanager \-file "${EEZ_CONFIG_DIR}/ssl/eezapplicationmanager.cer" -storepass ${PASSPHRASE} \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.applicationmanager.keystore.jks"

6. Generate authorized keys truststore and import certificate with public keyfor FLA adapter:

${JAVA_KEYTOOL} -import -noprompt -alias eezadapter \-file "${EEZ_CONFIG_DIR}/ssl/eezadapter.cer" -storepass ${PASSPHRASE} \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.authorizedkeys.truststore.jks"

7. Generate authorized keys truststore and import certificate with public keyfor System Automation Application Manager server:

${JAVA_KEYTOOL} -import -noprompt -alias eezapplicationmanager \-file "${EEZ_CONFIG_DIR}/ssl/eezapplicationmanager.cer" -storepass ${PASSPHRASE} \-keystore "${EEZ_CONFIG_DIR}/ssl/eez.ssl.authorizedkeys.truststore.jks"

8. Delete certificate file for FLA adapter. The certificate file is not neededanymore at runtime:

rm ${EEZ_CONFIG_DIR}/ssl/eezadapter.cer

9. Delete certificate file for Application Manager. The certificate file is notneeded anymore at runtime:

rm ${EEZ_CONFIG_DIR}/ssl/eezapplicationmanager.cer

Enabling SSL security in the Application Managerconfiguration

About this task

Perform the following steps to enable SSL security in the Application Managerconfiguration:1. Start the Application Manager configuration utility cfgeezdmn.2. On the main window of the configuration dialog, click Configure in the

common configuration section of the Application Manager tab. Specify thefollowing parameters on the Security tab. Values provided here are samplevalues:v Truststore: /etc/opt/IBM/tsamp/eez/cfg/ssl/

eez.ssl.authorizedkeys.truststore.jks

v Keystore: /etc/opt/IBM/tsamp/eez/cfg/ssl/eez.ssl.applicationmanager.keystore.jks

v Keystore password: passphrasev Certificate alias: eezapplicationmanager

Click Save to store the configuration changes.3. If the Application Manager is highly available, proceed as follows: On the main

window of the configuration dialog, click Replicate on the High Availabilitytab. Replicate the configuration files to the other nodes in the high availabilitycluster, including the SSL configuration.


4. Restart the WebSphere Application Server as described in Tivoli SystemAutomation Application Manager, Administrator’s and User’s Guide. This activatesthe SSL configuration.

Note: Do not select the Enforce use of SSL for all first-level automation domainscheck box before you completed the SSL setup for all FLA adapters.

Enabling SSL security in FLA adapter configurationsAbout this task

Perform the following steps to enable SSL security for FLA adapter or remoteagentless adapter configurations. Replace <adapter> withv sam for the System Automation for Multiplatforms adapterv eez/hac for the PowerHA adapterv eez\mscs for the FOC adapterv eez/vcs for the VCS on Solaris adapterv eez for the local agentless adapterv eez/rala for a remote agentless adapter1. Copy the authorized keys truststore file to the nodes in the cluster of the FLA

or remote agentless adapter domain:scp ${EEZ_CONFIG_DIR}/ssl/eez.ssl.authorizedkeys.truststore.jks \root@<adapter-nodename>:/etc/opt/IBM/tsamp/<adapter>\/cfg/ssl/eez.ssl.authorizedkeys.truststore.jks

Copy the file to the node on which you will start the configuration utility, seestep 3. The file will be replicated as part of the SSL configuration replication,see step 5.

Note: For adapters running on Windows use the appropriate copy filecommand.

2. Copy the adapter keystore file to the nodes in the cluster of the FLA or remoteagentless adapter domain:scp ${EEZ_CONFIG_DIR}/ssl/eez.ssl.adapter.keystore.jks \root@<adapter-nodename>:/etc/opt/IBM/tsamp/<adapter>\/cfg/ssl/eez.ssl.adapter.keystore.jks

Copy the file to the node on which you will start the configuration utility, seestep 3. The file will be replicated as part of the SSL configuration replication,see step 5.

Note: For adapters running on Windows use the appropriate copy filecommand.

3. Start the configuration utility of the respective FLA adapter. Use the followingcommands to start the configuration utility:v cfgsamadapter for the System Automation for Multiplatforms adapterv cfghacadapter for the PowerHA adapterv cfgmscsadapter for the FOC adapterv cfgvcsadapter for the VCS on Solaris adapterv cfgeezdmn for the local or any remote agentless adapter

4. Specify the parameters:

On the main window of the configuration dialog, click Configure. Specify thefollowing parameters on the Security tab. Values below are sample values.


v Truststore: /etc/opt/IBM/tsamp/<adapter>/cfg/ssl/eez.ssl.authorizedkeys.truststore.jks

v Keystore: /etc/opt/IBM/tsamp/<adapter>/cfg/ssl/eez.ssl.adapter.keystore.jks

v Keystore password: passphrasev Certificate alias: eezadapter

Click Save to store the configuration changes.5. On the main window of the configuration dialog, click Replicate. Replicate the

configuration files to the other nodes in the cluster of the FLA domainincluding the SSL configuration.For a remote agentless adapter, click Distribute on the window that shows thelist of remote agentless adapter configurations. Distribute the configuration tothe remote agentless adapter host including the SSL configuration.

6. Restart the FLA adapter to activate the SSL configuration. Use the followingcommands to restart the respective adapter:v samadapter for the System Automation for Multiplatforms adapterv hacadapter for the PowerHA adapterv Start the FOC adapter as described in System Automation Application

Manager Administrator's and User's Guide.v vcsadapter for the VCS on Solaris adapterv eezaladapter for the local or any remote agentless adapter

Optional: Enforcing usage of SSL for all FLA domainsAbout this task

If you want to enforce usage of SSL for all FLA domains, activate thecorresponding option as described in this topic. Perform these steps after youcompleted the SSL setup for all FLA adapters only. If there are still adaptersrunning without SSL setup, then these domains go offline and can not getreconnected after you activated this option.

Perform the following steps to enforce usage of SSL for all FLA domains.1. Check if all adapters run with SSL. Otherwise perform the steps described in

“Enabling SSL security in FLA adapter configurations” on page 303.2. Start the Application Manager configuration utility using cfgeezdmn.3. On the main window of the configuration dialog, click Configure in the

common configuration section of the Application Manager tab. Select theEnforce use of SSL for all first-level automation domains check box on theSecurity tab. Click Save to store the configuration change

4. If the Application Manager is highly available, proceed as follows: On the mainwindow of the configuration dialog, click Replicate on the High Availabilitytab. Replicate the configuration files to the other nodes in the high availabilitycluster including the SSL configuration.

5. On the main window of the configuration dialog, click Refresh in the commonconfiguration section of the Application Manager tab. This activates thechanged SSL configuration of the Application Manager.


Securing communication with the zEnterprise Hardware ManagementConsole

If you installed setup includes zEnterprise HMC, make sure the communication issecured.

About this task

You can configure the mode of authentication to access the zEnterprise HMC onthe “zEnterprise HMC Access tab” on page 140. For Information about securingthe communication with the zEnterprise Hardware Management Console and therequired user IDs, refer to “zEnterprise Hardware Management Console” on page283.

Managing the security setup for Agentless AdaptersAbout this task

The tasks in the following sections describe how to specify user credentials anduser authentication for Agentless Adapters.

Managing user credentials to access single nodes withAgentless Adapters

About this task

An agentless adapter separately authenticates each user ID that is specified for aresource in the agentless adapter policy. Depending on the type of managedresource, the adapter authenticates each user on the remote nodes (if the resourceis a remote application), or against the hub Tivoli Enterprise Monitoring Server (ifthe managed resource is an ITM resource). This is a different authentication thanthe user authentication between end-to-end manager and adapter.


Authentication for remote applicationsAbout this task

The following sequence is used to authenticate a user ID on a remote node. Notethat the description applies for the local agentless adapter as well as for remoteagentless adapters.

Procedure1. Specific user ID and password for one node: For the user ID that is specified

for a resource in an agentless adapter automation policy, user authentication isperformed, if Credentials for accessing specific non-clustered nodes ischecked on the User Credentials tab. An agentless adapter uses the passwordthat is associated with that specific user ID to access the specified remote node.The password is stored encrypted in the eez.aladapter.dif.properties file inthe end-to-end Application Manager configuration path.a. AIX and Linux: The user ID must be a valid SSH user ID. SSH can be

configured to use local operating system or LDAP security using PAMauthentication.

b. Windows: The user ID must be a valid local operating system or domainuser ID.

2. Generic user ID and password for all nodes: For the user ID that is specifiedfor a resource in an agentless adapter automation policy user authentication isperformed, if Generic user ID is defined on the User Credentials tab. Anagentless adapter uses the password that is associated with that generic user IDto access the remote nodes. The password is stored encrypted in theeez.aladapter.dif.properties file in the end-to-end Application Managerconfiguration path. The generic user ID is only used if no specific user ID isspecified for that node.a. AIX and Linux: The user ID must be a valid SSH user ID. SSH can be

configured to use local operating system or LDAP security using PAMauthentication.

System A

User is definedas valid user.

System B

User is definedas valid user.

System C

User andSSH public keydefined.

End-to-endApplication Manager

Agentless Adapter

userid or password

eez.aladapter.dif.properties

SSH private key

id_rsa or id_dsa

SSH keyauthentication

Specificuser ID

Genericuser ID

Figure 42. Authentication with the Agentless Adapter on a remote node


b. Windows: The user ID must be a valid local operating system or domainuser ID.

3. SSH public key authentication (not available for Windows target nodes): Forthe user ID that is specified for a resource in an agentless adapter automationpolicy user authentication is performed using SSH public and private keys ifEnable user authentication between agentless adapter and remotenon-clustered nodes is enabled on the "Security tab. Click Browse... to selectthe SSH private key file and specify the optional Private key passphrase, ifneeded. The SSH public key authentication is only used if no specific or genericuser ID is specified.

Authentication for Tivoli Monitoring resourcesAbout this task

Any start or stop command, or any monitor query against an Tivoli Monitoringagent is done via a SOAP request against the Tivoli Monitoring SOAP Server onthe hub monitoring server. For each SOAP request, the Agentless Adapterauthenticates against the SOAP server using a user name and password. Thecriteria used to determine which user name is described in the following steps:

Procedure1. If no UserName is defined in the agentless adapter policy for an Tivoli

Monitoring resource, the agentless adapter submits all commands for thisresource using the generic Tivoli Monitoring user ID defined in theconfiguration utility cfgeezdmn.

2. If a UserName is defined in the agentless adapter policy for an TivoliMonitoring resource, the agentless adapter submits all commands for thisresource using the specified user ID.a. If the user ID was defined in the configuration utility cfgeezdmn, the

corresponding password is loaded from the eez.aladapter.dif.propertiesfile, where it is stored encrypted.

b. If the user ID was not defined in the configuration utility, the agentlessadapter submits all commands for this resource using the specified user IDand tries to access the SOAP server with an empty password. This optionmust be used only in test environments.

Note:

v All Tivoli Monitoring user IDs defined in the agentless adapter policy and inthe configuration utility must be valid Tivoli Monitoring users that canaccess the Tivoli Monitoring SOAP server. The users are authenticatedthrough the hub monitoring server. Depending on how the monitoring serveris configured, user IDs can be authenticated either by the local systemregistry of the system on which the hub monitoring server runs or by anexternal LDAP-enabled central registry.

v In the Tivoli Monitoring SOAP server configuration you can define users andspecify the following access privileges for each: Query or Update. The accessprivileges determine what methods the user is allowed to use. Update accessincludes Query access. User IDs used by the agentless adapter to connect tothe Tivoli Monitoring SOAP Server require the Query access privileges tostart, stop, and monitor remote Tivoli Monitoring resources.


Managing SSH public keysAbout this task

For remote applications, SSH keys can be used for authentication of the agentlessadapter with remote systems. This does not apply if the agentless adapter is usedto manage Tivoli Monitoring resources only. The SSH private key is stored on thesystem where the Agentless Adapter is installed, protected by a pass phrase. Forthe local Agentless Adapter, the system where the agentless adapter is installed isthe System Automation Application Manager server. For a remote agentlessadapter, the system where the agentless adapter is installed is a remote clientsystem. The SSH public keys are stored on the remote systems in the SSHconfiguration of the remote user.

The term remote system refers to the systems where the resources are located thatare managed by agentless adapters.

Perform the following steps to use public key authentication of the eezaladapterwith the remote system:1. Generate a SSH key pair (public and private key) on a system

<ssh-keygen-nodename> where ssh-keygen is installed. For example:<ssh-keygen-nodename># ssh-keygen -q -f ~/id_rsa -t rsa -C <aladapter_userid>@<aladatper-nodename>Enter passphrase (empty for no passphrase):Enter same passphrase again:

Note: Do not use your account password, nor an empty passphrase.2. Distribute the public key to all target nodes and target user IDs where SSH

public key authentication is used.<ssh-keygen-nodename># scp ~/id_rsa.pub <target_userid>@<target-nodename>:~/id_rsa.pubssh <target_userid>@<target-nodename><target-nodename># mkdir -p ~/.ssh<target-nodename># chmod 700 ~/.ssh<target-nodename># cat ~/id_rsa.pub >> ~/.ssh/authorized_keys<target-nodename># chmod 600 ~/.ssh/authorized_keys<target-nodename># rm ~/id_rsa.pub

3. Distribute the private key to the node where the agentless adapter runs.

WebSphereApplication Server

Agentless Adapter

/etc/opt/IBM/tsamp/eez/cfg/ssl/id_rsa

id_rsa.pub

read append


~/.ssh/authorized_keys

sshd Publickeys

Publickeys

Target Node

read

Privatekeys

Figure 43. SSH key exchange overview


<ssh-keygen-nodename># scp ~/id_rsa <aladapter_userid>@<aladapter-nodename>:~/id_rsassh <aladapter_userid>@<aladapter-nodename><aladapter-nodename># mv ~/id_rsa /etc/opt/IBM/tsamp/eez/cfg/ssl/id_rsa<aladapter-nodename># chmod 600 /etc/opt/IBM/tsamp/eez/cfg/ssl/id_rsa

4. Configure the SSH private key file and passphrase in the end-to-endautomation manager configuration dialog.Launch the end-to-end automation manager configuration dialog, enter<application_manager-nodename># cfgeezdmn

On the main window, select the option to configure the local or a remoteagentless adapter.v Local agentless adapter: Click Configure in the Local Agentless Adapter

Configuration sectionv Remote agentless adapters: Click Configure in the Remote Agentless Adapter

Configuration section.

In the following window, select the corresponding remote Agentless Adapterhost system and click Configure. In the Application Manager AgentlessAdapter Configuration dialog, select the Security tab. Enable the check boxEnable user authentication between agentless adapter and remotenon-clustered nodes.Enter the private SSH key file name: /etc/opt/IBM/tsamp/eez/cfg/ssl/id_rsaEnter private SSH key passphrase: <ssh-keygen passphrase>

5. Make sure that no credentials are explicitly defined for user IDs for which SSHkey authentication should be used. Select the User credentials tab. Select theentries for all node and user ID pairs in the Credentials for accessing specificnon-clustered nodes table for which you want to use SSH key authenticationand click Remove. For example, in order to activate SSH public keyauthentication for the user ID hugo on node lnxcm10a, you need to remove theexisting entry in the Credentials for accessing specific non-clustered nodestable. Select the entry with node name lnxcm10a and user ID hugo and clickRemove.

6. Restart eezaladapter.Perform the following two commands to stop and start the agentless adapter:<aladapter-nodename># eezaladapter stop<aladapter-nodename># eezaladapter start

If you have changed the configuration for a remote Agentless Adapter, clickDistribute to distribute the changed configuration files to the correspondingremote adapter host before restarting the adapter on that host. In the configurationdistribution dialog, you can select to let the configuration utility restart the adapterautomatically after the distribution completed. This saves you from logging on tothe remote adapter host and restarting the adapter manually.



Chapter 6. Tuning

Tuning the number of domains and resources of agentless adaptersThe amount of resources that can be managed by agentless adapters withoutperformance degradation depends on the hardware. Your performance dependsespecially on processor power and CPU cycles, that are available on the systemwhere agentless adapters run. Make sure that CPU and memory utilization is nothigher than 80% after policy activation.

Depending on your hardware capabilities, the numbers that are given in thefollowing recommendations may vary slightly. Adhering to those recommendationsprovides a good performance using agentless adapters.

Recommendations for the local agentless adapter:


Recommendations for one remote agentless adapter instance:


For each agentless adapter instance (local and remote), balance the number ofresources per domain by including a similar number of resources in each domain.



Using IBM Support Assistant

IBM Support Assistant is a free, standalone application that you can install on anyworkstation. IBM Support Assistant saves you time searching product, support,and educational resources and helps you gather support information when youneed to open a problem management record (PMR) or Electronic Tracking Record(ETR), which you can then use to track the problem.

You can then enhance the application by installing product-specific plug-inmodules for the IBM products you use. The product-specific plug-in for TivoliSystem Automation for Multiplatforms provides you with the following resources:v Support linksv Education linksv Ability to submit problem management reportsv Capability to collect traces

Installing IBM Support Assistant and the Tivoli System Automation forMultiplatforms plug-in

To install the IBM Support Assistant V4.1, complete these steps:v Go to the IBM Support Assistant Web site:

www.ibm.com/software/support/isa/

v Download the installation package for your platform. Note that you will need tosign in with an IBM user ID and password (for example, a MySupport ordeveloperWorks® user ID). If you do not already have an IBM user ID, you maycomplete the free registration process to obtain one.

v Uncompress the installation package to a temporary directory.v Follow the instructions in the Installation and Configuration Guide, included in

the installation package, to install the IBM Support Assistant.

To install the plug-in for System Automation for Multiplatforms, complete thesesteps:1. Start the IBM Support Assistant application. IBM Support Assistant is a web

application that is displayed in the default, system configured web browser.2. Click the Updater tab within IBM Support Assistant.3. Click the New Products and Tools tab. The plug-in modules are listed by

product family.4. Select Tivoli > Tivoli System Automation for Multiplatforms.5. Select the features you want to install and click Install. Be sure to read the

license information and the usage instructions.6. Restart IBM Support Assistant.


http://www.ibm.com/software/support/isa/


Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationMail Station P3002455 South RoadPoughkeepsie New York 12601-5400U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law: INTERNATIONAL


BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS"WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFNON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE. Some states do not allow disclaimer of express or implied warranties incertain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM web sites are provided forconvenience only and do not in any manner serve as an endorsement of those websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those web sites is at your own risk.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksIBM, the IBM logo, ibm.com®, are trademarks or registered trademarks ofInternational Business Machines Corporation in the United States, other countries,or both. If these and other IBM trademarked terms are marked on their firstoccurrence in this information with a trademark symbol (® or ™), these symbolsindicate U.S. registered or common law trademarks owned by IBM at the time thisinformation was published. Such trademarks may also be registered or commonlaw trademarks in other countries.

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registeredtrademarks or trademarks of Adobe Systems Incorporated in the United States,and/or other countries.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Oracle and/or its affiliates.

UNIX is a registered trademark of The Open Group in the United States and othercountries.


Index

Aadministrator

System Automation user ID 16agentless adapter

accesssingle nodes 305single remote nodes 306

IBM.RemoteResource 22manage

security 305save configuration 138supported operating systems 20

agentless adapter policycreating 267

agentless adaptersconfiguring 127controlling 138

Application Managerconfiguring 99high availability 172high availability configuration 170,

171, 175high availability silent

configuration 172Application Manager configuration

enable SSL security 302automation adapters

securing using SSL 300automation database

exporting 66, 70importing 66, 70

automation managermaximum number of connections 74

automation policydefining 163example 42removing 163scope 41storing 162validating 162

Automation policy for PowerHAadapters 204

Automation policy for VCSadapters 204

available heap sizemodifying 74

Bbenefits for System Automation

Application Manager customers 280,282

Business Service Managerintegration scenarios 250, 254, 255

Ccluster

dependenciesidentify 43

cluster-spanningdependencies

identify 43common configuration

refreshing 114saving 113System Automation Application

Manager 106configuration

properties files 210configuration dialog

end-to-end automation manager 99task launcher 100

configuration in silent modeAgentless Adapters 139Disaster Recovery

TPC-R domain 150Distributed disaster Recovery

hardware adapter 146FOC adapter

configuration 192high availability 164PowerHA adapter

configuration 186System Automation Application

Manager 114VCS adapter

configuration 203configuration properties files

FOC adapter 214PowerHA adapter 212System Automation Application

Manager 210VCS Solaris adapter 213

configuration tasks 172configuring

agentless adapters 127alternate host 114Distributed Disaster Recovery 175hardware adapter 139high availability 150high availability for a disaster

recovery setup 168OSLC tab 108PowerHA adapter 179TPC-R domain 146

Configuringagentless adapter

Adapter tab 128Security tab 132Tivoli Monitoring tab 131User Credentials tab 130

Agentless Adapter tab 158Application Manager 99Automation Manager

Application Manager tab 100Change Password tab 105High Availability tab 104Non-clustered Nodes tab 101Storage Replication tab 103

Configuring (continued)Automation Manager (continued)

Virtual Server / HW Managementtab 102

Automation Manager tab 154configuration files 161DB2 tab 157disaster recovery setup

DB2 tab 171Domain Setup tab 170

distributed disaster recoveryAdapter tab 140adding credentials 143changing credentials 144DR Hardware Credentials tab 142zEnterprise HMC Access tab 140

domain 161Domain Setup tab 153FOC adapter

Adapter tab 187Host Using Adapter tab 188Logger tab 190Security tab 189

Hardware Adapter tab 157high availability policy 153, 154, 156,

157, 158, 161disaster recovery 169

Policy Pool tab 156PowerHA adapter

Adapter tab 179Automation tab 180Host Using Adapter tab 180Logger tab 182Security tab 182

remote agentless adapterinstance 135

System Automation ApplicationManager

Command Shell tab 107Discovery Library Adapter

tab 108Domain tab 106Event Publishing tab 109Logger tab 112Security tab 111, 299User Credentials tab 111

TPC-Radding domain 147

TPC-R domainconfiguration window 147

VCS adapterAdapter tab 195Automation tab 198Host Using Adapter tab 197Logger tab 200Security tab 199

VCS adapter settings 195WebSphere tab 156

Configuring for a disaster recovery setupsilent configuration 172


Configuring the local agentlessadapter 128

Creating a truststoreHardware Management Console 286

DDB2

automation manager databasecreating 53

installation parameters 12server installation 51WebSphere Application Server

requests 72default directories 46Defining a user

Hardware Management Console 284destination

GDPS events 176directories

default paths 46disaster recovery setup

high availability policy 169disaster recovery setup on two sites 168discovery library adapter

using 287Discovery Library Toolkit

configuring 235customize TBSM 236event identification 236template mapping 236

disk space requirementsAIX 11Linux 11

Distributed disaster Recoveryinstallation 82

Distributed Disaster Recoveryconfiguring 175GDPS 30operating systems 28Planning 27prerequisites 28supported hardware 28supported operating systems 28

domainremoving 162

domain identification file 210duplicated users

remove 126

Ee-mail address xiiieezdla command

options-? 288

quick reference 288EEZEAR

role mapping 123user mapping 123

Enabling GPMP 285Enabling Web Services API 284end-to-end automation domain

name 15

end-to-end automation engineWebSphere Application Server user

ID 15end-to-end automation manager

configuration dialog 99silent configuration 206

event consolesTivoli Enterprise Console

Tivoli Netcool/OMNIbus 215event filtering 229example

automation policy 42

Ffix packs

installing 78FLA adapter configurations

enable SSL security 303FLA domains

enforce usage of SSL 304FOC 186FOC adapter

configuration 191configuring 34, 186, 187high availability

planning 37, 93providing 192

installation directories 36installation wizard 94installing 34, 93packaging 35prerequisites 35properties files 214replicating configuration files 192silent mode installation 95special considerations 38supported operating systems 36uninstalling 95upgrading 95user account 36verifying the installation 95

GGDPS

operating systems 28GDPS agent 176GDPS events

destination 176

Hhardware adapter

configuring 139Hardware Adapter tab 171hardware management

configuring 139high availability

configuring 150DB2 scenarios 151FOC adapter 192installation 81installing service 80prerequisites 26

high availability policyconfiguring 153restrictions 167set up 152System Automation for

Multiplatforms 164highly available adapters

roadmap 34, 35home page

IBM Tivoli System Automation 78

IIBM HMC setup 283IBM TEC extension

configuring 226enabling launch-in-context 228installing 226, 227prerequisites 226, 227

IBM Tivoli Enterprise Consoleinstallation parameters 15

IBM.RemoteResourcewindows targets 22

input properties filesediting 208silent mode 207

installationDB2 server 51Distributed Disaster Recovery 82high availability 81IBM TEC extension 226JDBC driver

remote DB2 53middleware software 51on an additional node 81on two GDPS sites 82planning 1post-installation tasks 73PowerHA adapter 92preparing 31product DVD 2product fix pack 79service fix packs 78service in highly available setup 80silent mode 64, 76System Automation Application

Managerinstallation wizard 60preparing 11

Tivoli Common Directory 11verifying 71Veritas adapter 39

installation directoryTivoli Common Directory 11

installation variables 124installation wizard 87

System Automation ApplicationManager 60

InstallingInstalling fix packs

Archive naming conventions 78Integrating 257

IBM Tivoli Monitoring 282IBM Tivoli Monitoring and Tivoli

Composite ApplicationManager 280


integrationTivoli Business Service Manager 232Tivoli products 215

ISO 9000 xii

Jjazz

post-installation 57Jazz for Service Management

installation 55installing 55

JazzSM Administration Services 289administering 292administering tsaControl 292building a REST call 295command line interface 293configuring 290

automation engine 290example 294installing tsaControl 291integrating 288operating 293registering resources 289resource details information 296ResourceID 292ResourceKey 292REST web serivces 293REST web services 290status information 296

KKeystore and Truststore 300

Llanguages

supported 16launch-in-context

create tool 224define menu entry 225Tivoli Netcool/OMNIbus 224

LDAPconfigure 116entity types 120

LDAP groupsauthorize 124

LDAP repositorymigrating 121security realm 119

LDAP server 117LDAP user registry

configuring 115federated repository 116planning 17

local agentless adaptersaving 134

localessupported 16

LTPA settingsLTPA password 74LTPA timeout 74

MMicrosoft Failover Cluster

configuring 186middleware software DVDs

contents 51mkhacadapter script 204mkvcsadapter script 204modifying

available heap size 74

Nnaming conventions

archive 78update installer location 78

Netcool/OMNIbusdefining trigger 234

Notes and restrictions 175notices 315

OObtaining the HMC certificate

Hardware Management Console 285operating system

new 77operating systems

Distributed Disaster Recovery 28FOC adapter 36GPDS 28PowerHA adapter 33TPC-R 29

OSLC tabconfiguring 108

Ppackaging 18

product DVD 2Planning 1

TPC-R Environments 30policies

worksheet 46post-installation tasks

modifying the LTPA settings 74overview 73

PowerHA adapterautomating 33automation policy

defining 185removing 185

configurationverifying 92

configuration dialoginvoking 178

configuration directory 92configuring 177, 179controlling 186installation directory 92installation source directory 32installing 92

prerequisites 32using SMIT 92

packaging 32properties files 212

PowerHA adapter (continued)replicating configuration files 184saving the configuration 184special considerations 33uninstallation 93

prerequisitesDistributed Disaster Recovery 28high availability 26IBM TEC extension 226memorey 9PowerHA adapter 32System Automation Application

Manager 4Veritas adapter 40

product DVDcontents 16directories 16

product prerequisites 3properties files

FOC adapter 214PowerHA adapter 212System Automation Application

Manager 210VCS Solaris adapter 213

public and private keys 300

Rrelationships 45release notes 78remote agentless adapter 18, 19, 87

distribute configuration 138service 90silent mode 88uninstalling 89

remote databaseverify 55

ReplicatingVCS adapter 202

requirementsDB2 server 51disk space

AIX, Linux 11hardware 9middleware software 6TCP/IP connectivity 10Tivoli Monitoring versions 6web browsers 8

resourcegrouping 43

Retrieving information about highavailability configuration 171

SSaving the high availability

configuration 171security

accesssingle nodes 305, 306, 307

agentless adapter 305security concepts

SSL 299service

installing 78

Index 319

service (continued)installing in highly available

setup 80service template

defining 234Tivoli Business Service Manager 233

silent configurationend-to-end automation manager 203,

206invoking 206

Silent configuration 114, 139, 146, 150,164, 186, 192, 203

silent modeFOC adapter 95input properties files 207installation 64, 76output 209Veritas adapter 96working 204

SSH public keysmanage 308

SSLautomation adapters 300enable security 302public and private keys 300security concepts 299

storage replicationconfiguring 146

supported operating systemsagentless adapter

non-clustered nodes 20System Automation Application

Manager 3supported platforms 19synchronizing 160synchronous communication

configuring with GDPS 176System Automation Application

Manager 1properties files 210supported operating systems 3uninstalling 75

System Automation operations consoleinitial user ID 16

Ttarget

Linux 25Unix 25z/OS 26

task launcher 100TBSM service tree

adding columns 242TBSM views

customizing 242TCP/IP connectivity

hardware requirements 10testing

connection between WebSphereApplication Server and DB2 72

timeoutsLTPA timeout 74

Tivoli Business Service Manager 230configuring 233integrating resources 237

Tivoli Business Service Manager(continued)

integration with System AutomationApplication Manager 232

launch-in-context 246prerequisites 232service template 233

manual assign 240Tivoli Common Directory

installation directory 11Tivoli Enterprise Console

configuring 229event consoles 215

Tivoli Monitoringaccess

ITM resources 307Tivoli Monitoring and Tivoli composite

Application Managerintegration scenarios 283

Tivoli Monitoring and Tivoli CompositeApplication Manager 257

Tivoli Monitoring resourcesagentless adapter policy 267

Tivoli Netcool/OMNIbus 216configuring 220enable rules file 222event consoles 215event fields 217launch-in-context 224prerequisites 216severity mapping 220update database 220

TPC-Roperating systems 29

TPC-R domainconfiguring 146

TPC-R domain configurationtesting 149

TPC-R domain settingsrefreshing 149

trademarks 316

Uuninstallation

service 81System Automation Application

Manager 75using the uninstallation graphical

program 75upgrade

3.2.0 or 3.2.1 68try and buy 75

upgrading 65Upgrading

AIX 68automation policy 69

Upgrading from 3.2 or 3.2.1Automation database 69

user IDSystem Automation administrator 16WebSphere Application Server 15

user role mappingsEEZEAR 67

users and groupscreate 122

Vvcs adapter

special considerations 40VCS adapter

automation policydefining 202

configuration dialoginvoking 194

configuring 194, 195installation wizard 96uninstallation 97

VCS Solaris adapterproperties files 213

Veritas adapterautomating 40automation policy

removing 203configuration

verifying 96configuring 193controlling 203installation source directory 39installing 39packaging 39prerequisites 40saving the configuration 201silent mode 96supported operating systems 40

virtual serverconfiguring 139

Wweb browsers

requirements 8WebSphere Application Server

connection to DB2test 72

installation parameters 14interim fixes 78

WebSphere tab 170what's new

4.1 xvworksheet

for disaster recovery policydefinition 46

ZzEnterprise HMC

Firewall Considerations 286integration 283, 284, 285, 286integration setup 283


Readers’ Comments — We'd Like to Hear from You

System Automation Application ManagerInstallation and Configuration GuideVersion 4.1

Publication No. SC34-2702-01

We appreciate your comments about this publication. Please comment on specific errors or omissions, accuracy,organization, subject matter, or completeness of this book. The comments you send should pertain to only theinformation in this manual or product and the way in which the information is presented.

For technical questions and information about products and prices, please contact your IBM branch office, yourIBM business partner, or your authorized remarketer.

When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in anyway it believes appropriate without incurring any obligation to you. IBM or any other organizations will only usethe personal information that you supply to contact you about the issues that you state on this form.

Comments:

Thank you for your support.

Submit your comments using one of these channels:v Send your comments to the address on the reverse side of this form.v Send a fax to the following number: (+49)+7031-16-3456v Send your comments via email to: [email protected] Send a note from the web page: http://www.ibm.com/support/knowledgecenter/SSPQ7D/welcome

If you would like a response from IBM, please fill in the following information:

Name Address

Company or Organization

Phone No. Email address

Readers’ Comments — We'd Like to Hear from YouSC34-2702-01

SC34-2702-01

IBM®Cut or FoldAlong Line

Cut or FoldAlong Line

Fold and Tape Please do not staple Fold and Tape

Fold and Tape Please do not staple Fold and Tape

NO POSTAGENECESSARYIF MAILED IN THEUNITED STATES

BUSINESS REPLY MAILFIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK

POSTAGE WILL BE PAID BY ADDRESSEE

IBM Deutschland Research and Development GmbHDepartment 3248Schoenaicher Str. 22071032 BoeblingenGermany

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

_

IBM®

Product Number: 5724-S92

Printed in USA

SC34-2702-01

Date post:	06-Apr-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Tivoli System Automation Application Manager V4.1.0.1 ......Edition Notices Befor e using this...

Documents