cloud & smarter infrastructure professional certification program · pdf...

This information is IBM Copyrighted and may not be distributed without the approval of IBM.

Cloud & Smarter Infrastructure Professional Certification Program

Study Guide Series

Exam C2010-654 - IBM Tivoli Application Dependency Discovery Manager V7.2.1.3 Implementation


Purpose of Exam Objectives .................................................................. 3

High-level Exam Objectives .................................................................... 4

Detailed Exam Objectives ........................................................................ 9

Section 1 - Planning .............................................................................................. 9

Section 2 - Installation ........................................................................................ 15

Section 3 - Configuration ................................................................................... 18

Section 4 - Administration ................................................................................. 25

Section 5 - Performance Tuning and Problem Determination ................. 31

Next Steps .................................................................................................. 35


Purpose of Exam Objectives

When an exam is being developed, the Subject Matter Experts work together to define the role the certified individual will fill. They define all of the tasks and knowledge that an individual would need to have in order to successfully implement the product. This creates the foundation for the objectives and measurement criteria, which are the basis for the certification exam. The Tivoli Certification item writers use these objectives to develop the questions that they write and which will appear on the exam. It is recommended that you review these objectives. Do you know how to complete the task in the objective? Do you know why that task needs to be done? Do you know what will happen if you do it incorrectly? If you are not familiar with a task, then go through the objective and perform that task in your own environment. Read more information on the task. If there is an objective on a task there is about a 95% chance that you WILL see a question about it on the actual exam. After you have reviewed the objectives and completed your own research, then take the assessment exam. While the assessment exam will not tell you which question you answered incorrectly, it will tell you how you did by section. This will give you a good indication as to whether you are ready to take the actual exam or if you need to further review the materials. Note: This is the high-level list of objectives. As you review these objectives, click for a more detailed level of how to perform the task.


High-level Exam Objectives

Section 1 - Planning

1.1

Given a list of initial business applications to be discovered, the list of servers the application runs on, and the approved project plan, determine the order, plan and methodology for discovery so that discovery scopes have been defined for discovering the servers and its components that the initial business applications run on.

1.2 Given a customer's environment, design the architecture so that the initial architecture plan for the solution has been created.

1.3 Given a customer's environment, determine the best estimate of the number of TADDM components required so that the initial architecture plan for the deployment has been created.

1.4 Given the customer's network configuration / diagrams and TADDM solution architecture, define firewall requirements so that list of ports to be opened on firewalls is delivered.

1.5

Given the list of technologies to be discovered and list of sensors that require credentials to run correctly, gather proper information from TADDM documentation, communicate to customer, implement and refine so that requirements for credentials are communicated and implemented in the environment

1.6 Given SME(s) and/or documentation, determine and document the customer’s existing environments that will be discovered and managed with TADDM so that an implementation plan is developed.

1.7 Given server with operating System installed for TADDM Installation, verify OS configuration and required S/W or Libraries are installed on that server so that the server is available for TADDM installation.

1.8 Given a list of computer systems/components/applications that will be discovered, create a list of TADDM sensors that will be run so that a list of sensors and any required credentials has been created.

1.9

Given that TADDM defines the different levels of discovery, analyze data needs and explain to customers the different levels and the options that are available so that the customer understands the 3 levels of discovery available within TADDM.

1.10

Given the customer’s data source requirements, analyze the requirements to determine if Discovery Library Adapters (DLA) are necessary and a means to import and export data to/from TADDM so that the customer’s environment has been evaluated for DLA requirements.

Section 2 - Installation

2.1 Given a system ready for database creation, prepare the database for IBM Tivoli Application Dependency Discovery Manager (TADDM) using different operating system so that database preparation is completed.

2.2 Given the TADDM architecture document and installation binaries, install TADDM and set up the environment so that TADDM is installed, initially configured, and up and running.


2.3 Given a running TADDM environment, database backed up and binaries backed up, Install TADDM fix pack so that TADDM fix pack installation is completed successfully.

2.4 Given an installed TADDM host, validate and complete the post installation configuration so that TADDM server will be ready for configuring the discovery.

2.5 Given the proper access administrator authority for a designated anchor server, configure anchor servers so that a service account has been created that will be used by the anchor server for discovery behind the firewall.

Section 3 - Configuration

3.1

Given target systems prepared for Anchor installation, list of anchors to be deployed with SSH servers installed, configure Anchors so that Anchor objects are created in IBM Tivoli Application Dependency Discovery Manager (TADDM) GUI and tested to be running.

3.2

Given a running TADDM environment and a list of Windows Gateways to be configured, perform SSH server installation and configuration on target systems, create Windows Gateway objects in TADDM GUI so that Windows Gateways are configured properly and ready to be used during discovery.

3.3 Given customer’s need for the 3 levels of discover and a running TADDM system, create different levels of discovery profiles and enable the options that are available so that Configuration Items can be discovered.

3.4

Given the list of extended attributes to be discovered by TADDM for chosen operating system, create and configure extended attributes by creating them, configuring templates and running a discovery so that extended attribute successfully populated with desired value.

3.5

Given Target server(s), a working TADDM server and access to the Discovery Management Console, using either the UI or command line add a Scope Set with the machine(s) configured so that the machine(s) can be discovered.

3.6

Given a list of servers / images and components/applications to be discovered, define the user privileges required for TADDM scans so that users with proper credentials are deployed to targets to be discovered and TADDM Access Lists are configured properly.

3.7

Given the user name and password for access to machines, a working TADDM server, and access to the Discovery Management Console, navigate to the Discovery Management Console and add an access credential so that Configuration Items can be discovered.

3.8 Given the need to debug Sensors more efficiently and effectively, set the SplitSensor option so that a clear view of each sensor is available.

3.9 Given a custom design file, configure the customBusiness Intelligence and Reporting Tool ( BIRT) report so that custom BIRT report is generated for the collected data.

3.10 Given a running TADDM environment and a database connection, generate a report so that a report is generated.


3.11

Given the list of Windows systems that will be discovered with a non-admin account and the account name to be created, configure the windows target for non-admin discovery so that Windows system is discovered Level2 using non-admin account.

3.12 Given the discovery schedule, configure TADDM scheduling so that discovery starts at a given time.

3.13

Given an installed TADDM server, create the snapshots to take a point-in-time copy of basic information about computer systems, discovery events and server applications running on computer systems so that the snapshots are available to take a point-in-time copy of basic information

3.14 Given a list of locations to be configured in TADDM, make necessary decisions and modifications in collation.properties and anchor properties files so that discovered components have location tag attribute set properly.

3.15

Given the information required to create a custom server template, a running TADDM, server and access to the Discovery Management Console, define custom server templates and build custom server templates from the UI so that the custom applications have been discovered properly.

3.16 Given that TADDM and IBM Tivoli Monitoring (ITM) are installed, prepare ITM and TADDM environment so that discovery can be performed by using ITM agent.

3.17

Given a business application and the list of servers/components/applications that compose the business application, create the appropriate application descriptor files and deploy them to the appropriate directories on the servers where discovery will be done so that discoveries have been run and it has been verified that the business application has been built correctly.

3.18 Given a list of users to be created and Admin access to Data Management Portal, create users so that TADDM user IDs have been configured for use.

Section 4 - Administration

4.1

Given the need to categorize application components into business applications and services, create business application and services using the Data Management Portal that combines large collections of individual components into logical groups.

4.2

Given a properly installed and operating IBM Tivoli Application Dependency Discovery Manager (TADDM) system and access credentials, execute API query so that XML data is extracted and available via STDOUT (Standard Output).

4.3 Given the timespan for keeping the historical changes of attributes values, perform a cleanup of the database by running proper SQLs so that TADDM database is cleaned up from old change history data

4.4

Given TADDM is up and running, max size of the file system to be used for logs, configure collation.properties settings for logs maintenance and optionally implement removing sensor logs mechanism so that log files are maintained automatically.

4.5 Given a customer’s need for TADDM, prepare, install, and execute TADDM so that the customer’s environment is fully discovered and validated.


4.6 Given a list of servers/images and components/applications to be discovered, manage and obtain credentials so that credentials are created on the requested servers/images/components/applications.

4.7

Given an existing scope and discovery profile to use, run a TADDM discovery using the Discovery Management Console and the API so that a discovery has been run by using the API and Discovery Management Console.

4.8

Given a valid IDML file for loading, a running TADDM server and access to the server running TADDM, use the loadidml script to populate the TADDM database so that the information contained in the IDML file is loaded into the TADDM database.

4.9 Given a TADDM Server, Discovery Management Console and User ID and password, review the types of status messages that occur during discovery and viewing history so that the status messages are understood.

4.10

Given an installed TADDM server, access to the server running TADDM and the new database user password, update the collation.properties file and encrypt the database access passwords so that the collation.properties file is updated with the new encrypted passwords.

4.11 Given an installed TADDM server and terminal access to the server running TADDM, start and stop the TADDM server processes so that the TADDM server has been stopped or started.

4.12 Given the TADDM server is running, run the analytics from the Data Management Portal so that the necessary information is available to be analyzed.

4.13

Given a working TADDM server, and access to the Data Management Portal, navigate to the Data Management Portal and create Configuration Items, and dependencies so that a new Configuration Item (CI) or dependency is created.

4.14 Given that the present roles do not suffice for an access requirement to TADDM, create a new role with unique permissions to fulfill the request so that a new TADDM role is configured for use.

4.15

Given supported hardware, operating system and running database, command-line access to the TADDM server, the password for the root, create backups and perform restores so that a backup and restore are available when needed.

Section 5 - Performance Tuning and Problem Determination

5.1 Given a running IBM Tivoli Application Dependency Discovery Manager (TADDM) environment and database connectivity, tune the Discovery parameter so that the discovery parameters are tuned appropriately.

5.2

Given list of Java Virtual Machines to set extended logging for, edit collation.properties file and set proper values for logging level so that logging level is set to desired value and logs contain desired information for problem diagnosis


5.3

Given that a problem has occurred within the TADDM environment and error levels need to be modified to ensure the correct messaging is captured for remediation enable/disable advanced logging for TADDM so that the environment is set for debug mode so that when problem occurring the correct messaging is captured and resolved.

5.4 Given the need to diagnose a problem within the TADDM environment, utilize the support bin tools so that problem can be debugged.

5.5

Given TADDM is installed and user IDs are created and problems occur with Discover, Topology, Discovery Admin, Proxy or Gigaspace processes, review the jvmarg settings in the collation.properites file and determine if more memory is required so that performance is enhanced and/or service is not interrupted.

5.6 Given the need to define common parameters in the collation.properties files, review the most common parameters that are located in the collation.properties file so that the common parameters have been defined.

5.7 Given a TADDM server, Identify points of failure regarding NMAP on L1 discoveries so that points of failure regarding NMAP on L1 discoveries are identified and corrected.

5.8 Given an application sensor failure, conduct an L3 Scan and troubleshoot application sensor failures so that the problems are resolved for a successful L3 collection.


Detailed Exam Objectives

Section 1 - Planning

1.1. Given a list of initial business applications to be discovered, the list of servers the application runs on, and the approved project plan, determine the order, plan and methodology for discovery so that discovery scopes have been defined for discovering the servers and its components that the initial business applications run on.

SUBTASK(S): 1.1.1. Gather and document the customer requirements. 1.1.2. Obtain the current environment details. 1.1.3. Review the customer input and requirements. 1.1.4. Determine how the environment will be discovered. 1.1.5. Compare list of initial business applications and their servers to be

discovered as defined in the approved project plan. If the requirements and listing of servers match proceed; otherwise, work with customer to redefine the scope.

1.1.6. Develop phased approach for discovering the application servers listed. 1.1.7. Develop scopes to implement the phased approach for discovering the

servers. 1.2. Given a customer's environment, design the architecture so that the

initial architecture plan for the solution has been created. SUBTASK(S): 1.2.1. Determine which authentication and security protocols are in use. 1.2.2. Determine if machines exist behind firewalls to determine need for anchor

servers and windows gateways. 1.2.3. Determine the number of assets to be managed. 1.2.4. Estimate the number of configuration items to be created. 1.2.5. Estimate the number of computer systems to be discovered. 1.2.6. Determine the architecture for IBM Tivoli Application Dependency

Discovery Manager (TADDM) (streaming or synchronized). 1.2.7. Determine the number of TADDM components to be implemented. 1.2.8. Analyze the authentication methods for LDAP integration. 1.3. Given a customer's environment, determine the best estimate of the

number of TADDM components required so that the initial architecture plan for the deployment has been created.

SUBTASK(S): 1.3.1. Determine if this is an Enterprise or Domain deployment. 1.3.2. Establish the customers preference in TADDMs architectural components.

1.3.2.1. AIX, Linux, or Windows 1.3.2.2. DB2 vs Oracle


1.3.2.3. Reuse or Greenfield for Gateways/Anchors systems (if required) 1.3.3. Determine logical and/or physical architectural boundaries.

1.3.3.1. Determine the number of physical locations for the deployment. 1.3.3.2. Determine if systems exist behind firewalls. 1.3.3.3. LDAP Domains & Security policies.

1.3.4. Estimate the connectivity bandwidth between boundaries (if applicable). 1.3.5. Estimate the number of systems to be discovered (L1) per boundary. 1.3.6. Allocate managed system types to each boundary.

1.3.6.1. Unix/Linux 1.3.6.2. Windows

1.3.7. Determine the CI’s that will be utilized (L2 and/or L3) per boundary. 1.3.8. Determine the number of Sever Equivalent’s to be managed per boundary.

Estimate the number of configuration items to be created per boundary. 1.3.9. Determine expected collection samples per system per day/mo per

boundary. 1.4. Given the customer's network configuration / diagrams and TADDM

solution architecture, define firewall requirements so that list of ports to be opened on firewalls is delivered.

SUBTASK(S): 1.4.1. Determine if there are firewalls in customer's environment. 1.4.2. Determine which level of discovery will be performed on systems behind

firewalls. 1.4.3. Determine if systems and applications to be discovered are behind the

firewalls. 1.4.4. Determine if Anchors will be deployed.

1.4.4.1. Determine whether chained anchors will be used. 1.4.5. Determine if other discovery techniques in firewalled environments will be

used (script-based / Asynchronous discovery). 1.4.6. Determine if script-based discovery will be used.

1.4.6.1. Present which technologies can be discovered with script-based discovery.

1.4.7. Determine if Asynchronous discovery will be used. 1.4.7.1. Present which technologies can be discovered with script-based

discovery. 1.4.8. Determine whether there will be a firewall between TADDM servers and

TADDM consoles. 1.4.9. Create the list of ports to be opened in customer's firewalls. 1.5. Given the list of technologies to be discovered and list of sensors that

require credentials to run correctly, gather proper information from TADDM documentation, communicate to customer, implement and refine so that requirements for credentials are communicated and implemented in the environment


SUBTASK(S): 1.5.1. After creating the list of sensors (that require elevated credentials on

target systems) necessary to successfully run discovery, go to product documentation and prepare a list of credentials needed. 1.5.1.1. Go to Sensors and supported systems matrix document to see list

of all sensors and technologies supported. 1.5.1.2. Go to Sensors reference and to see the details for credentials

requirements per technology. 1.5.2. Communicate created list of requirements to the customer and ask to

implement them on test environment. 1.5.3. Make necessary changes to collation.properties file on TADDM server(s). 1.5.4. Run the discovery to see if every technology from initial list is discovered

properly. 1.5.5. If there are still problems with discovery due to missing credentials.

requirements, go to sensor logs for each particular problem and analyze the root cause.

1.5.6. Refine requirements. 1.5.7. Ask the customer to implement changes 1.5.8. If necessary – change collation.properties file. 1.5.9. Run discovery on failing technologies. 1.5.10. Continue refining requirements until discovery runs successfully on all

technologies in test environment. 1.5.11. After completing refining the requirements, move to production

environment. 1.6. Given SME(s) and/or documentation, determine and document the

customer’s existing environments that will be discovered and managed with TADDM so that an implementation plan is developed.

SUBTASK(S): 1.6.1. Discuss with System Administrator:

1.6.1.1. Determine and document the different operating system types (OS) that are in the customer’s environment.

1.6.1.2. Determine and document the number of servers for each OS type that will be discovered in each environment (e.g., test, production) where discoveries will be run.

1.6.1.3. Discuss how TADDM works, what the credential requirements for computer systems are, and begin the process to manage and obtain credentials.

1.6.1.4. Discuss requirement for lsof. 1.6.1.5. Discuss WMI requirements for Windows discovery.

1.6.2. Discuss with Network SME(s): 1.6.2.1. Determine and document the types of network equipment that are

in the customer’s environment.


1.6.2.2. Determine and document the number of each type of network equipment that will be discovered in each environment (e.g., test, production) where discoveries will be run.

1.6.2.3. Determine and document firewalls in the customer’s environment. 1.6.2.4. Discuss how TADDM works, what the credential requirements for

network equipment are, and begin the process to manage and obtain credentials.

1.6.3. Discuss with Business Application SME(s): 1.6.3.1. For each business application to be managed via TADDM,

determine the various servers/components/applications that compose the business application.

1.6.3.2. Discuss how TADDM works, what the credential requirements for components/applications are, and begin the process to manage and obtain credentials.

1.6.3.3. If system diagrams, network diagrams, and/or application architectural documents/diagrams are available.

1.6.3.4. Review the available documents and determine and document: OS types and number of each OS type in the environments to be discovered, types of network equipment and number of each type in the environments to be discovered, business applications and servers/components/applications that compose each business application.

1.6.4. Note: The creation of credentials should be started as soon as possible, so they are available prior to discoveries being run.

1.7. Given server with operating System installed for TADDM Installation,

verify OS configuration and required S/W or Libraries are installed on that server so that the server is available for TADDM installation.

SUBTASK(S): 1.7.1. Log in to the server and Validate Operating System version which is

supported for TADDM 1.7.2. Validate TADDM user for the read/Write/execute permission which is used

for the TADDM installation. 1.7.3. Review the server hosts file for the IP address and host name of the local

system. 1.7.3.1. Windows systems: c:\Windows\system32\drivers\etc\hosts 1.7.3.2. Linux® and UNIX® systems: /etc/hosts

1.7.4. Validate the Java Runtime Environment (JRE) installation on the server. 1.7.5. On UNIX systems, the user ID under which the TADDM server runs must

have an open file limit of at least 8192 files. 1.7.6. On Linux and UNIX systems, the TADDM server user ID must also have

root execution permission for the nmap command. 1.7.7. Validate all required Shared library files are installed on UNIX and Linux

servers.


1.7.8. The Security-Enhanced Linux (SELinux) security system must be disabled (SELINUX=disabled in the /etc/sysconfig/selinux configuration file).

1.8. Given a list of computer systems/components/applications that will be

discovered, create a list of TADDM sensors that will be run so that a list of sensors and any required credentials has been created.

SUBTASK(S): 1.8.1. Review the list of computer systems/components/applications to be

discovered and document which ones TADDM uses sensors to discover. 1.8.2. Of the sensors in the list, document which ones require credentials to run. 1.8.3. Work with the customer to get the process to manage and obtain

credentials started. 1.9. Given that TADDM defines the different levels of discovery, analyze

data needs and explain to customers the different levels and the options that are available so that the customer understands the 3 levels of discovery available within TADDM.

SUBTASK(S): 1.9.1. Analyze the customer needs for discovery and explain the discovery levels

available and how it can be matched by creating different discovery profiles.

1.9.2. Describe Level 1 Profile/Discovery: 1.9.2.1. Level 1 profile is designed to perform credential-free discoveries. 1.9.2.2. The default purpose is to discover and create Computer Systems

inventory from a defined set of host, range, and/or subnet of IP addresses scope.

1.9.2.3. The main senor that is run is the StackScanSensor. This will gather very basic information from the discovered Computer Systems. 1.9.2.3.1. Unix: For StackScanSensor to execute, must include

the user id into the sudoers file, example for the TADDM Domain/Anchor Server owner id of taddm: taddm ALL= (ALL) NOPASSWD: ALL.

1.9.2.4. When used with Nmap (must be installed separately on the TADDM and Anchor Servers), much more detailed information will be retrieved with a higher discovered OS confidence level.

1.9.3. Describe Level 2 Discovery: 1.9.3.1. This Level 2 profile is only used to discover host with credentials. 1.9.3.2. This Level 2 profile includes the Level 1 profile with the OS

credentials which are entered in the Access List for all the targeted machines (Solaris, Linux, Windows, etc) along with a number of additional Computer System Sensors that will run. This is still a more of an inventory discovery with minimum discovered dependencies (TCP only connections).


1.9.4. Describe Level 2 Discovery with shallow application discovery : 1.9.4.1. This is an enhanced Level 2 discovery scan that will also capture

shallow application objects without application credentials. With this variable set to true, a CustomAppServer object representing the application running on the target machine will be received. This will also build limited application dependencies as they are discovered.

1.9.4.2. Set this variable: com.collation.internalITemplatesEnabled to true in the collation.propreties file.

1.9.5. Describe Level 3 Discovery: 1.9.5.1. This Level 3 profile is used for deep-dive discovery (includes all of

Level 2). 1.9.5.2. This profile can be used to discover the entire application

infrastructure, deployed software components, physical servers, network devices, virtual LAN, and host data used in a runtime environment. This discovery requires credentials for all deep dive discoveries sensors that are delivered with TADDM product. This level will also discover applications that do not require credentials for custom templates that are also delivered with TADDM product. This will build dependencies of all applications as they are discovered and have sensors for.

1.9.6. Other Discovery Profiles: 1.9.6.1. Any of these profiles (Level 1-3) can be cloned and modified

according to your needs. New profiles can be created 1.9.6.2. These new profiles can clone sensors with the ability of modifying

parameters and/or remove sensors for discoveries via the Discovery Management Console.

1.10. Given the customer’s data source requirements, analyze the

requirements to determine if Discovery Library Adapters (DLA) are necessary and a means to import and export data to/from TADDM so that the customer’s environment has been evaluated for DLA requirements.

SUBTASK(S): 1.10.1. Review TADDM functionality with Environment Owner. 1.10.2. Identify data gaps. 1.10.3. Determine which data sources have data to be exchanged with TADDM. 1.10.4. Determine which database types are being used. 1.10.5. Determine which data sources already have DLA written. 1.10.6. Determine requirements for frequency of data loads via the DLA. 1.10.7. Determine means for developing a new DLA if one does not exist.


Section 2 - Installation

2.1. Given a system ready for database creation, prepare the database for IBM Tivoli Application Dependency Discovery Manager (TADDM) using different operating system so that database preparation is completed.

SUBTASK(S): 2.1.1. Identify the database server and instance. 2.1.2. Create TADDM database. 2.1.3. Adjust the database configuration parameters. 2.1.4. Adjust the default bufferpool size to accommodate data volume. 2.1.5. Update the database configuration for TADDM. 2.1.6. Verify database has appropriate changes. 2.1.7. Verify data base connection with TADDM server. 2.2. Given the TADDM architecture document and installation binaries,

install TADDM and set up the environment so that TADDM is installed, initially configured, and up and running.

SUBTASK(S): 2.2.1. Verify OS prerequisites and database creation. 2.2.2. Prepare (download) installation binaries from proper place (PA / XL / etc). 2.2.3. Unzip the binaries to a directory on TADDM server. 2.2.4. Run the installer from unzipped binaries by executing a proper script. 2.2.5. Determine the method of installation (silent, GUI). 2.2.6. Perform step by step procedure during the installation providing

information from Architecture document. 2.2.7. After installation is finished, start TADDM from the command line (if not

started automatically after installation). 2.2.8. Run a TADDM script to validate the installation. 2.2.9. Verify that TADDM is up and running (JVM's status). 2.2.10. Open DMP and DMC consoles and verify ability to log in. 2.3. Given a running TADDM environment, database backed up and

binaries backed up, Install TADDM fix pack so that TADDM fix pack installation is completed successfully.

SUBTASK(S): 2.3.1. Download the latest fix pack from FixCentral porta.l 2.3.2. Unzip fix pack on the TADDM server. 2.3.3. Verify backups of TADDM DB and TADDM binaries are done. 2.3.4. Run fix pack installer from command line (console / silent or GUI).

2.3.4.1. Perform steps required by the installer. 2.3.5. Observe installation logs content to see if any errors occurred. 2.3.6. After fix pack installation verify that TADDM JVMs are up and running. 2.3.7. Rollback database backup and binaries backup to the previous state if the

fix pack installation fails.


2.4. Given an installed TADDM host, validate and complete the post

installation configuration so that TADDM server will be ready for configuring the discovery.

SUBTASK(S): 2.4.1. Log in to the TADDM server by using the TADDM user. 2.4.2. Validate the collation.properties file for the database connection related

parameters. 2.4.2.1. Primary database connections 2.4.2.2. Archive database connection

2.4.3. Check the status of the TADDM server. Go to the installation directory of the TADDM server: 2.4.3.1. For Linux®, and UNIX® systems: $COLLATION_HOME/bin 2.4.3.2. For Windows® systems: %COLLATION_HOME%\bin

Enter one of the following commands: For Linux and UNIX systems: ./control status For Windows systems: control status

2.4.3.2.1. If TADDM is running on a domain server, the Discover, GigaSpaces,DbInit, Tomcat, Topology, DiscoverAdmin, Proxy and EventsCore services should be started.

2.4.3.2.2. If TADDM is running on a synchronization server, the GigaSpaces, DbInit, Tomcat, EcmdbCore services should be started and displayed.

2.4.3.2.3. If TADDM is running on a storage server, the GigaSpaces, DbInit, Tomcat, StorageService services should be started and displayed.

2.4.3.2.4. If TADDM is running on a discovery server, the GigaSpaces, DbInit, Tomcat, DiscoveryService services should be started and displayed.

2.4.4. Complete the configuration for the secure access to the Discovery Management Console. 2.4.4.1. In a Web browser on the client system, open the TADDM launch

page by entering the hostname and port of the TADDM server. The default URL is as follows: http://hostname:9430 (where hostname is the TCP/IP hostname or numeric IP address of the system where the TADDM server is installed)

2.4.4.2. On the TADDM launch page, click Show SSL options. 2.4.4.3. Click Download Trust Store. 2.4.4.4. Click Save. Make sure to record the location where file is saved. 2.4.4.5. In the text field next to Download Trust Store, type the path to the

directory where the truststore file is saved. Do not include the file name.

2.4.5. After installation, clear the Java™ Web Start cache on each client system where the Discovery Management Console is logged in to.

http://hostname:9430/


2.5. Given the proper access administrator authority for a designated

anchor server, configure anchor servers so that a service account has been created that will be used by the anchor server for discovery behind the firewall.

SUBTASK(S): 2.5.1. For UNIX/Linux - log in to the designated anchor server with root user

authority. 2.5.1.1. Create the service account. 2.5.1.2. Open the port for anchor server.

2.5.2. For Windows - log in to the designated anchor server with administrator user authority. 2.5.2.1. Create the local service account with a local administrator’s group.

2.5.3. Verify supported version of SSH Service is installed on the anchor server.


Section 3 - Configuration

3.1. Given target systems prepared for Anchor installation, list of anchors to be deployed with SSH servers installed, configure Anchors so that Anchor objects are created in IBM Tivoli Application Dependency Discovery Manager (TADDM) GUI and tested to be running.

SUBTASK(S): 3.1.1. Verify supported version of SSH server installation on anchor systems. 3.1.2. Log in to TADDM Discovery Management Console. 3.1.3. In Scopes section create scopes for Anchors restrictions. 3.1.4. In Anchors section create new anchors. 3.1.5. Create discovery profile with Anchor Sensor enabled. 3.1.6. Test anchor deployment by running a discovery on created Anchor

Servers using discovery profile with Anchor Sensor enabled. 3.2. Given a running TADDM environment and a list of Windows Gateways

to be configured, perform SSH server installation and configuration on target systems, create Windows Gateway objects in TADDM GUI so that Windows Gateways are configured properly and ready to be used during discovery.

SUBTASK(S): 3.2.1. On each target selected to act as a Windows Gateway, install a supported

version of SSH server. 3.2.2. On each target selected to act as a Windows gateway, configure freshly

installed SSH server so it is possible to log in from TADDM server to this host.

3.2.3. In TADDM, create scopes that will be used to limit Windows gateways. 3.2.4. In TADDM Discovery Management Console, go to Anchors/gateways

section and create Windows gateways as per given list, providing IP address of each gateway.

3.2.5. Limit (if necessary) created gateway to a previously created scope. 3.2.6. If necessary, create Access List entry for Windows computer system to

instruct TADDM which account/password to use when logging in via SSH to Windows gateway.

3.2.7. Run a test discovery of a Windows computer system to verify the created Windows gates operates as expected.

3.3. Given customer’s need for the 3 levels of discover and a running

TADDM system, create different levels of discovery profiles and enable the options that are available so that Configuration Items can be discovered.

SUBTASK(S): 3.3.1. Navigate to the Discovery Management Console user interface. 3.3.2. Open the Discovery Profile tab.


3.3.3. Select the Existing Profile and clone it. 3.3.4. Select the new profile and select the sensors as per the customer

requirement. 3.3.5. Select the OK button at the bottom to complete. 3.4. Given the list of extended attributes to be discovered by TADDM for

chosen operating system, create and configure extended attributes by creating them, configuring templates and running a discovery so that extended attribute successfully populated with desired value.

SUBTASK(S): 3.4.1. Create extended attributes (EA) from TADDM UI.

3.4.1.1. Choose a proper class of operating system to create EA for. 3.4.1.2. Choose type of EA to be created. 3.4.1.3. Save changes.

3.4.2. Create views for extended attributes bu running a extattr_views.sh script from dist/bin. 3.4.2.1. Follow the guidance for giving parameters to this script in order

to create views properly. 3.4.3. Edit Computer System template from Discovery Management Portal.

3.4.3.1. Enable the template. 3.4.3.2. Ensure that identyfying criteria are correct for your OS.

3.4.4. Make necessary modifications in OS template under /dist/etc/templates/commands. 3.4.4.1. Edit file adding proper directive (CMD, NOP, SCRIPT, etc). 3.4.4.2. If necessary develop jython script for SCRIPT directive.

3.4.5. Run discovery Level 2 to the OS that has been configured for extended attributes.

3.4.6. Wait for the @0.5 topology agents group to complete. 3.4.6.1. Verify from the UI the content of created extended attribute(s).

3.5. Given Target server(s), a working TADDM server and access to the

Discovery Management Console, using either the UI or command line add a Scope Set with the machine(s) configured so that the machine(s) can be discovered.

SUBTASK(S): 3.5.1. Identify the list of server names available for discovery. 3.5.2. Add a scope set and a server by using the TADDM console or the CLI

method. 3.5.3. Repeat the steps to add a scope set and individual host IP addresses for

each scope set. 3.6. Given a list of servers / images and components/applications to be

discovered, define the user privileges required for TADDM scans so


that users with proper credentials are deployed to targets to be discovered and TADDM Access Lists are configured properly.

SUBTASK(S): 3.6.1. From the list of servers/images/components/applications that need to be

discovered, determine which sensors need credentials to run successfully. 3.6.2. For each sensor that requires credentials, document the credential

requirements. 3.6.3. Work with customer’s process for requesting credentials; document each

credential request and delivery owner as the request is submitted. Include in the document when the request is scheduled to be completed.

3.6.4. As credential requests are completed, update credential requirements document and enter the credentials in the product.

3.6.5. If the documented completion date for any credential request expires, use the customer’s process to escalate the request.

3.6.6. In TADDM console create appropriate Access List entries that will correspond to prepared list of users.

3.6.7. Ask the customer to create users with appropriate rights on target systems to be used.

3.7. Given the user name and password for access to machines, a working

TADDM server, and access to the Discovery Management Console, navigate to the Discovery Management Console and add an access credential so that Configuration Items can be discovered.

SUBTASK(S): 3.7.1. Navigate to the Discovery Management Console. 3.7.2. Open the Discovery tab. 3.7.3. Select the Access List icon. 3.7.4. Select the Add button at the bottom. 3.7.5. Select the Computer System option in the Component Type pull down.

3.7.5.1. Other options include: Windows Servers, Application Servers, Database Servers, LDAP, SNMP, SAP, etc.

3.7.6. Input the name of your Access List, user name, password and confirm password in Access Details dialog box.

3.7.7. Select the Scope Limitation folder and select your scope options if necessary.

3.7.8. Select the OK button at the bottom to complete. 3.8. Given the need to debug Sensors more efficiently and effectively, set

the SplitSensor option so that a clear view of each sensor is available. SUBTASK(S): 3.8.1. Log in to the TADDM server. 3.8.2. In the $COLLATION_HOME/etc/collation.properties file the parameter

com.collation.discover.engine.SplitSensorLog=true must be set to true.


3.8.3. Restart TADDM if the file is changed. 3.9. Given a custom design file, configure the customBusiness Intelligence

and Reporting Tool ( BIRT) report so that custom BIRT report is generated for the collected data.

SUBTASK(S): 3.9.1. Go to Discovery Management Console and click Start Data Management

Portal. 3.9.2. Click Analytics->BIRT Reports from the Data Management Portal 3.9.3. Click New and fill details when it prompts and locate the design file in the

GUI client m/c through the browse option. Then click Add Report. 3.9.4. Finally click OK to load the file into TADDM 7.2.1 server and check report

in the BIRT report list on the console and TADDM server. 3.10. Given a running TADDM environment and a database connection,

generate a report so that a report is generated. SUBTASK(S): 3.10.1. Generate a pre-defined BIRT report:

3.10.1.1. In the Functions pane of the Data Management Portal window, click Analytics.

3.10.1.2. In the Analytics section, click BIRT Reports. The TADDM BIRT Reports list opens, displaying all of the available BIRT reports.

3.10.1.3. In the TADDM BIRT Reports list, click to highlight the report you want to run.

3.10.1.4. Click Run Report. If the report has any parameters, you are then prompted to specify the parameter values. When you have finished specifying parameter values, click OK.

3.10.2. Run a Tivoli Common Reporting or Cognos report: 3.10.2.1. Copy the appropriate zip file to Tivoli Common Reporting or

Cognos. 3.10.2.2. Import the file. 3.10.2.3. Verify the report works.

3.11. Given the list of Windows systems that will be discovered with a non-

admin account and the account name to be created, configure the windows target for non-admin discovery so that Windows system is discovered Level2 using non-admin account.

SUBTASK(S): 3.11.1. Create a discovery user account.

3.11.1.1. Create user on the target system. 3.11.1.2. Unset changing password requirement. 3.11.1.3. Select password never expires.

3.11.2. Set up the WMI configuration.


3.11.2.1. Configure for created user proper rights in WMI Control for Root Namespace. 3.11.2.1.1. Execute Methods. 3.11.2.1.2. Enable Account.

3.11.3. Remote Enable 3.11.4. Copy the TaddmWmi files to target systems.

3.11.4.1. Copy the following TaddmWmi files to %SystemRoot%\system32\wbem (on 32bit systems).

3.11.4.2. Copy the following TaddmWmi files to %SystemRoot%\syswow64\wbem (on 64bit systems).

3.11.4.3. Register TaddmWMI.dll using mofcomp and regsvr32 commands.

3.11.5. Set up the DCOM Access for ibmcol. 3.11.5.1. Using dcomcnfg configure

3.11.5.1.1. Access Permissions for created user (Local Access and Remote Access).

3.11.6. Launch and Activation Permissions for created user (Local Launch and Remote Launch).

3.11.7. Restart Windows server. 3.11.8. Configure Access List in TADDM GUI. 3.11.9. Run Level2 discovery to configured target. 3.11.10. Observe results to see if the Level 2 discovery runs with no errors. 3.12. Given the discovery schedule, configure TADDM scheduling so that

discovery starts at a given time. SUBTASK(S): 3.12.1. Decide whether to use TADDM built-in scheduler in the GUI or use

CRONTAB on Unix systems with API invocation. 3.12.2. If using GUI method- in the GUI go to Schedule.r

3.12.2.1. Fill in the information about the time of discovery, scopes to be discovered, discovery profile to be used.

3.12.3. If using API method – make modifications in system crontab. 3.12.3.1. create api.sh command that will start a discovery against a

given scope, using given discovery profile at a certain time. 3.12.4. Verify correctness of configuration in TADDM GUI – observe if the

discovery happened. 3.13. Given an installed TADDM server, create the snapshots to take a

point-in-time copy of basic information about computer systems, discovery events and server applications running on computer systems so that the snapshots are available to take a point-in-time copy of basic information

SUBTASK(S): 3.13.1. Log on to TADDM server by using TADDM user.


3.13.2. Run the snapshot tool with “take” Switch or the API. 3.13.3. Validate the BIRT reports in the Data Management Console. 3.14. Given a list of locations to be configured in TADDM, make necessary

decisions and modifications in collation.properties and anchor properties files so that discovered components have location tag attribute set properly.

SUBTASK(S): 3.14.1. Enable location tagging in TADDM by modifying collation.properties entry

com.collation.locationTaggingEnabled 3.14.2. Decide whether to enable static location tagging per TADDM Server or

per anchor. 3.14.2.1. Configure static location tagging in collation.properties (location

tagging per TADDM Server). 3.14.2.2. Configure static location tagging in anchor properties file

(location tagging per anchor). 3.14.3. Decide whether dynamic location tagging will be used.

3.14.3.1. include -l parameter when starting discovery from CLI (api.sh, invokejob.sh).

3.14.3.2. include -l parameter when loadin IdML book. 3.14.4. Create scopes adding location tag information to enable filtering and

usage per location. 3.14.5. When running BIRT reports use filtering by location. 3.15. Given the information required to create a custom server template, a

running TADDM, server and access to the Discovery Management Console, define custom server templates and build custom server templates from the UI so that the custom applications have been discovered properly.

SUBTASK(S): 3.15.1. Identify need for custom server template. 3.15.2. View the unknown servers list from TADDM GUI. 3.15.3. Define the custom server templates basing on the information from

unknown servers list or manually if information is not available. 3.15.4. Configure the defined custom server templates from the UI.

3.15.4.1. Configure the identification criteria. 3.15.4.2. Configure configFiles to be discovered by TADDM.

3.15.5. Run a discovery to validate if created Custom Server Template works properly.

3.16. Given that TADDM and IBM Tivoli Monitoring (ITM) are installed,

prepare ITM and TADDM environment so that discovery can be performed by using ITM agent.


SUBTASK(S): 3.16.1. Set up TADDM discovery agent installation package on Tivoli Enterprise

Monitoring Server. 3.16.2. Deploy TADDM discovery agent package to IBM Tivoli Monitoring

operating system agents. 3.16.3. Copy ITM libraries to TADDM discovery manager. 3.16.4. Verify that TADDM and ITM are connected and the data collection is

working. 3.17. Given a business application and the list of

servers/components/applications that compose the business application, create the appropriate application descriptor files and deploy them to the appropriate directories on the servers where discovery will be done so that discoveries have been run and it has been verified that the business application has been built correctly.

SUBTASK(S): 3.17.1. Create the base XML application descriptor for the business application if

you need to define general information about the business application: For each component/application that is part of the business application, create the descriptor file.

3.17.2. Put created XML files in proper directories on target systems (follow sensor documentation guidelines for placing application descriptor files properly).

3.17.3. Run discovery and view the results to verify that the application descriptors are setup correctly and business applications are filled correctly (according to XML files content).

3.18. Given a list of users to be created and Admin access to Data

Management Portal, create users so that TADDM user IDs have been configured for use.

SUBTASK(S): 3.18.1. Log in to the Data Management Portal with an admin ID. 3.18.2. Under the Administration tab on left, select Users. 3.18.3. In the Users Dialog box, select Create User.. 3.18.4. Provide the appropriate information. 3.18.5. Select the proper role assignment under the Role Assignment dialog box. 3.18.6. Select the proper Access Collection under the Role Assignment dialog

box. 3.18.7. Select the OK button at the bottom to complete.


Section 4 - Administration

4.1. Given the need to categorize application components into business applications and services, create business application and services using the Data Management Portal that combines large collections of individual components into logical groups.

SUBTASK(S): 4.1.1. Log into the Data Management Portal to build a business application and

business services. 4.1.2. Creating a business application and business services can be executed

from the menu bar under Grouping Composer function tab. 4.1.2.1. General Information Screen; Name, Description, URL 4.1.2.2. Create business application and business services Components

Screen: Include the available components. 4.1.2.2.1. BA Component is available for business application. 4.1.2.2.2. Business application has an optional to create a new

Functional Group. 4.1.2.3. Application Admin Information Screen.

4.1.3. Business application topologies can be viewed under the Topology functional tag.

4.1.4. Business application and business services: Edit, Delete, show Details, and display physical and logical topology. 4.1.4.1. Under the Discovered Components function, select either

business application or business services and right click on the mouse to view the selections.

4.1.4.2. For business applications under the Topology functional tab, select a displayed application and, then right click on the mouse to view the selections.

4.2. Given a properly installed and operating IBM Tivoli Application

Dependency Discovery Manager (TADDM) system and access credentials, execute API query so that XML data is extracted and available via STDOUT (Standard Output).

SUBTASK(S): 4.2.1. Log in to the TADDM server. 4.2.2. Execute the API with a valid user name and password and valid switches. 4.3. Given the timespan for keeping the historical changes of attributes

values, perform a cleanup of the database by running proper SQLs so that TADDM database is cleaned up from old change history data

SUBTASK(S): 4.3.1. Perform a database backup. 4.3.2. Determine the date up to which data is to be removed. 4.3.3. Convert the date to java timestamp.


4.3.4. Determine the type of TADDM installation. 4.3.5. For single domain installation perform cleanup tasks. 4.3.6. Run SQL query that will remove unwanted data from change_history_table.

4.3.6.1. Run SQL query that will remove unwanted data from change_cause_table.

4.3.7. For synchronization installation perform cleanup tasks in a proper order. 4.3.7.1. Wait for synchronization. 4.3.7.2. Remove unwanted data from domain DB first. 4.3.7.3. Keep the timespan the same on all TADDM domain servers.

4.3.8. Verify the correctness of data after cleanup 4.4. Given TADDM is up and running, max size of the file system to be

used for logs, configure collation.properties settings for logs maintenance and optionally implement removing sensor logs mechanism so that log files are maintained automatically.

SUBTASK(S): 4.4.1. Edit collation.properties file to set the proper logging level to save

filesystem space. 4.4.1.1. Set to DEBUG / TRACE when resolving problems. 4.4.1.2. Set to INFO for everyday maintenance.

4.4.2. Edit collation.properties file to configure log files maintenance settings taking into consideration the size of filesystem for logs. 4.4.2.1. Set the max size of each log file. 4.4.2.2. Set the max number of log files to be kept befor rolling.

4.4.3. For sensor logs maintenance, create a script or a crontab entry (on unix systems) that will remove old logs because sensor logs are not mainteined automatically by TADDM and have to be removed manually.

4.5. Given a customer’s need for TADDM, prepare, install, and execute

TADDM so that the customer’s environment is fully discovered and validated.

SUBTASK(S): 4.5.1. Execute the plan for data collection approach, server & network

requirements. 4.5.2. Execute Change Control. 4.5.3. Deploy TADDM Enterprise (if planned), Domains, Anchors and/or

Gateways. 4.5.4. Modify network routing and firewall rules. 4.5.5. Prepare servers, gateways routers for scans. 4.5.6. Set up TADDM. 4.5.7. Define a test and/or pilot TADDM scope. 4.5.8. Test and/or pilot TADDM scope. 4.5.9. Load TADDM scope. 4.5.10. Execute TADDM scope.


4.5.11. Validate results. 4.6. Given a list of servers/images and components/applications to be

discovered, manage and obtain credentials so that credentials are created on the requested servers/images/components/applications.

SUBTASK(S): 4.6.1. From the list of servers/images/components/applications that need to be

discovered, determine which sensors need credentials to run successfully. 4.6.2. For each sensor that requires credentials, document the credential

requirements. 4.6.3. Work with customer’s process for requesting credentials; document each

credential request and delivery owner as the request is submitted. Include in the document when the request is scheduled to be completed.

4.6.4. As credential requests are completed, update credential requirements document and enter the credentials in the product.

4.6.5. If the documented completion date for any credential request expires, use the customer’s process to escalate the request.

4.7. Given an existing scope and discovery profile to use, run a TADDM

discovery using the Discovery Management Console and the API so that a discovery has been run by using the API and Discovery Management Console.

SUBTASK(S): 4.7.1. Determine the scope of each discovery to be executed. 4.7.2. Execute a discovery by using the UI:

4.7.2.1. Run the parallel scan. 4.7.3. Execute a discovery is using the API or invokejob. 4.7.4. Check discovery progress logs. 4.7.5. Validate success. 4.8. Given a valid IDML file for loading, a running TADDM server and

access to the server running TADDM, use the loadidml script to populate the TADDM database so that the information contained in the IDML file is loaded into the TADDM database.

SUBTASK(S): 4.8.1. Transfer the file to the TADDM server or make it available through a

network share or other means. 4.8.2. Log in as the user that starts and stops the TADDM server. 4.8.3. Perform the necessary steps to load the IDML file. 4.8.4. Confirm the load through the Data Management Portal. 4.9. Given a TADDM Server, Discovery Management Console and User ID

and password, review the types of status messages that occur during


discovery and viewing history so that the status messages are understood.

SUBTASK(S): 4.9.1. Log in to the Discovery Management Console. 4.9.2. Run a discovery. 4.9.3. View the Discovery Overview, or after discovery completion, view History. 4.9.4. View the current status of the sensor. Values that can be displayed are:

4.9.4.1. Done is a successful sensor completion. 4.9.4.2. In progress is the sensor is still analyzing the target application,

computer system or network devices. 4.9.4.3. Error is an unsuccessful sensor completion, it can also indicate

that previous sensors did not run for one reason or another and caused this sensor to run and fail.

4.9.4.4. Warning is all critical functions in the sensor completed successfully. Warnings would include things like certain configuration files were not located or did not have permission to open files or run commands.

4.9.4.5. Description and Information is a light status description of what the sensor is doing and final description result.

4.10. Given an installed TADDM server, access to the server running

TADDM and the new database user password, update the collation.properties file and encrypt the database access passwords so that the collation.properties file is updated with the new encrypted passwords.

SUBTASK(S): 4.10.1. Identify that the credentials for the tool need to be changed. 4.10.2. Log in as user that starts and stops the TADDM server. 4.10.3. Update the credentials in collation.properties. 4.10.4. Save the file. 4.10.5. Issue the command to encrypt the passwords: 4.10.6. Check the collation.properties file the passwords are no longer plain text. 4.10.7. Restart the TADDM server. 4.11. Given an installed TADDM server and terminal access to the server

running TADDM, start and stop the TADDM server processes so that the TADDM server has been stopped or started.

SUBTASK(S): 4.11.1. Log in as the non-administrator that was defined during installation for

starting, viewing and stopping TADDM. 4.11.2. View the status of TADDM. 4.11.3. Start TADDM. 4.11.4. Stop TADDM.


4.11.5. Restart TADDM 4.11.6. View the status of TADDM

4.11.6.1. UNIX: $COLLATION_HOME/bin/control status 4.11.6.2. Windows: %COLLATION_HOME%\bin\control.bat status

4.12. Given the TADDM server is running, run the analytics from the Data

Management Portal so that the necessary information is available to be analyzed.

SUBTASK(S): 4.12.1. Access the analytic function in the Data Management Portal. 4.12.2. Select the appropriate report in the analytic function. 4.12.3. Define the type of query required. 4.12.4. Run the query. 4.12.5. Examine the results. 4.12.6. Save the results in the appropriate format. 4.13. Given a working TADDM server, and access to the Data Management

Portal, navigate to the Data Management Portal and create Configuration Items, and dependencies so that a new Configuration Item (CI) or dependency is created.

SUBTASK(S): 4.13.1. Navigate the Data Management Portal. 4.13.2. Create a component (CI) with the appropriate type, name and other

relevant attributes 4.13.3. Define component dependencies from the Discovered Components

section. Dependency can be created for either Dependent or Provider. Multiple CIs can be added by repeating the process.

4.14. Given that the present roles do not suffice for an access requirement

to TADDM, create a new role with unique permissions to fulfill the request so that a new TADDM role is configured for use.

SUBTASK(S): 4.14.1. Note the requirements for the request and their uniqueness from what

exists already. 4.14.2. Log in to the Data Management Portal with an Admin ID. 4.14.3. Define the role name, value in the Create Role dialog box. 4.14.4. Select the proper permission for the new role. 4.14.5. Create role to complete. 4.14.6. Validate that the permissions are adequate to fulfill the need. 4.15. Given supported hardware, operating system and running database,

command-line access to the TADDM server, the password for the root,


create backups and perform restores so that a backup and restore are available when needed.

SUBTASK(S): 4.15.1. Perform back up:

4.15.1.1. Stop TADDM. 4.15.1.2. Verify all processes related to TADDM are killed. 4.15.1.3. Zip TADDM into a file. 4.15.1.4. Take the backup of installshield. 4.15.1.5. Perform a database backup. 4.15.1.6. Save the zip file and the database backup.

4.15.2. Perform restore: 4.15.2.1. Stop TADDM. 4.15.2.2. Verify all processes related to TADDM are killed. 4.15.2.3. Use the backup copy of TADDM and the database to restore

the files. 4.15.2.4. Unzip into the appropriate directories.

4.15.3. Restore the database backup using the appropriate tools.


Section 5 - Performance Tuning and Problem Determination

5.1. Given a running IBM Tivoli Application Dependency Discovery Manager (TADDM) environment and database connectivity, tune the Discovery parameter so that the discovery parameters are tuned appropriately.

SUBTASK(S): Analyze the customer environment to understand which parameters required to be tuned. 5.1.1. TADDM parameters that can be modified are contained in

the collation.properties file. 5.1.2. The two major areas for tuning are attribute discovery rate and storage.

5.1.2.1. Attribute discovery rate: In this file, the property with the most impact on performance is the number of discover worker threads. A discover worker thread is a thread that runs sensors.

5.1.2.2. #Max number of discover worker threads 5.1.2.3. com.collation.discover.dwcount=16

5.1.3. The server must be restarted for the change to take effect. 5.1.4. Storage of the discovery results is the discovery performance bottleneck, if

the number of sensors in the storing state is approximately the value of the property: 5.1.4.1. com.collation.discover.observer.topopumpcount

5.1.5. Increase the maximum heap size setting for the following Java Virtual Machines (JVMs): 5.1.5.1. Discovery 5.1.5.2. Topology 5.1.5.3. StorageServer

5.2. Given list of Java Virtual Machines to set extended logging for, edit

collation.properties file and set proper values for logging level so that logging level is set to desired value and logs contain desired information for problem diagnosis

SUBTASK(S): 5.2.1. Get the list of JVMs to change logging level or decide to change logging

level for all JVMs (global setting). 5.2.2. Choose logging level that has to be set in order to allow problem

determination (FATAL, ERROR, WARN, INFO, DEBUG, TRACE). 5.2.3. Edit collation.properties file in order to change logging level. 5.2.4. If changing all JVMs setting - edit value com.collation.log.level and set it to

one of the available logging levels. 5.2.5. If changing particular JVM, change one of the following settings:

com.collation.log.level.vm.Topology= com.collation.log.level.vm.Discover= com.collation.log.level.vm.EventsCore= com.collation.log.level.vm.Proxy=


com.collation.log.level.vm.EcmdbCore= com.collation.log.level.vm.DiscoverAdmin= com.collation.log.level.vm.StorageService= com.collation.log.level.vm.DiscoveryService= com.collation.log.level.vm.Anchor=

5.2.6. Analyze logs for problem determination. 5.3. Given that a problem has occurred within the TADDM environment

and error levels need to be modified to ensure the correct messaging is captured for remediation enable/disable advanced logging for TADDM so that the environment is set for debug mode so that when problem occurring the correct messaging is captured and resolved.

SUBTASK(S): 5.3.1. Identify that an error has occurred. 5.3.2. Set up logging in TADDM to gather diagnostic information. 5.3.3. Take steps to determine the root cause by setting the operate level of

verbosity by changing the overall log level. 5.3.4. Adjust the setting to suitable level. 5.3.5. Recreate the error. 5.3.6. Review the logs. 5.3.7. Enable more logging for proper components (if required). 5.3.8. Search the knowledge base. 5.3.9. Get and apply fixes (if applicable). 5.3.10. Contact support (if applicable) with the problem detected with full logging

enabled. 5.3.11. Once the issue is resolved reset log levels to appropriate settings for

environment. 5.4. Given the need to diagnose a problem within the TADDM environment,

utilize the support bin tools so that problem can be debugged. SUBTASK(S): 5.4.1. Identify the problem that exists. 5.4.2. Identify the appropriate support tool. 5.4.3. Execute the support tool with the appropriate switches. 5.4.4. Quantify the results. 5.4.5. Verify the problem has been resolved. 5.5. Given TADDM is installed and user IDs are created and problems

occur with Discover, Topology, Discovery Admin, Proxy or Gigaspace processes, review the jvmarg settings in the collation.properites file and determine if more memory is required so that performance is enhanced and/or service is not interrupted.

SUBTASK(S):


5.5.1. Identity performances that are not as expected. 5.5.2. Check the present configuration settings for the JVM. 5.5.3. Modify the settings. 5.5.4. Restart TADDM. 5.5.5. Conduct a test to verify if performance has improved. 5.5.6. Repeat as necessary until optimal performance is achieved. 5.6. Given the need to define common parameters in the

collation.properties files, review the most common parameters that are located in the collation.properties file so that the common parameters have been defined.

SUBTASK(S): 5.6.1. Set overall logging level. 5.6.2. View cache optimization. 5.6.3. Review primary database connection related parameters. 5.6.4. Review archive database connection related parameters. 5.6.5. Review individual tool directory paths. 5.6.6. Review connection and pool parameters. 5.6.7. Review port assignments. 5.6.8. Review SSL parameter. 5.6.9. Review agent command assignment. 5.6.10. Review RMI client proxy. 5.6.11. Review all timeout parameters. 5.6.12. Modify any discrepancies in the configuration. 5.6.13. Restart TADDM. 5.7. Given a TADDM server, Identify points of failure regarding NMAP on

L1 discoveries so that points of failure regarding NMAP on L1 discoveries are identified and corrected.

SUBTASK(S): 5.7.1. Run the L1 discovery. 5.7.2. Verify the appropriate version of NMAP is installed on the TADDM server. 5.7.3. Verify the settings of StackScanSensor in Discovery Profile using TADDM

UI. 5.7.4. Verify sudo permission and settings in the sudoers file on the TADDM

server. 5.7.5. Check the TADDM log for NMAP failures. 5.7.6. Issue appropriate command to troubleshoot NMAP failure. 5.7.7. Check permission and availability of NMAP on TADDM server. 5.7.8. Modify TADDM or NMAP configuration. 5.7.9. Run discovery again.


5.8. Given an application sensor failure, conduct an L3 Scan and troubleshoot application sensor failures so that the problems are resolved for a successful L3 collection.

SUBTASK(S): 5.8.1. Identify the scope and/or source system to conduct L3 scans against. 5.8.2. Identify the products that require credentials for L3 from that scope. 5.8.3. Enter those application credentials into the Access List. 5.8.4. Conduct the scan. 5.8.5. Validate successful collection or failure. 5.8.6. Analyze logs if failure occurred. 5.8.7. Ensure that application product is supported with an out of the box sensor 5.8.8. Ensure that the application product is running on a supported platform for

the out of the box sensor. 5.8.9. Ensure appropriate level of credentials were used. 5.8.10. Ensure security settings are correct. 5.8.11. Ensure path settings are correct. 5.8.12. Modify sensor settings if required. 5.8.13. Modify collation.properties configuration if applicable for the failing

sensor. 5.8.14. Execute L3 scan again.

cloud & smarter infrastructure professional certification program · pdf...

Documents