Application Dependency Discovery Manager: Sensors · PDF fileT ivoli A pplica tion Dependenc y...

Tivoli Application Dependency Discovery ManagerVersion 7.3

Sensor Reference

IBM

NoteBefore using this information and the product it supports, read the information in “Notices” on page 475.

Edition notice

This edition applies to version 7, release 3 of IBM Tivoli Application Dependency Discovery Manager (productnumber 5724-N55) and to all subsequent releases and modifications until otherwise indicated in new editions.

© Copyright IBM Corporation 2008, 2016.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . ix

Tables . . . . . . . . . . . . . . . xi

About this information. . . . . . . . xiiiConventions used in this information center . . . xiiiTerms and definitions. . . . . . . . . . . xiii

Chapter 1. Sensor reference . . . . . . 1Overview . . . . . . . . . . . . . . . 1

Sensors that are enabled by default . . . . . . 1Sensors that support a non-admin discovery onWindows operating system . . . . . . . . 8Sensors that support script-based andasynchronous discovery . . . . . . . . . 10Sensors that support discovery using IBM TivoliMonitoring (old method) . . . . . . . . . 12Sensors that support discovery using OSLCAutomation . . . . . . . . . . . . . 14Sensor setup problems. . . . . . . . . . 15

Application sensors. . . . . . . . . . . . 16Active Directory sensor . . . . . . . . . 16Apache sensor . . . . . . . . . . . . 1820

Model objects with associated attributes . . . . . 21Troubleshooting the sensor . . . . . . . . . 23Citrix 7 server sensor . . . . . . . . . . . 23

Chapter 2. Docker Host sensor . . . . 29

Chapter 3. Docker Swarm Clustersensor . . . . . . . . . . . . . . . 37

Chapter 4. DNS sensor . . . . . . . . 41Troubleshooting the sensor . . . . . . . . . 41

Chapter 5. HIS sensor . . . . . . . . 43Model objects with associated attributes . . . . . 43Configuring the access list . . . . . . . . . 47Troubleshooting the sensor . . . . . . . . . 47

Chapter 6. IBM Cluster SystemsManagement sensor . . . . . . . . . 49Configuring the sensor . . . . . . . . . . 49

Configuring the discovery profile . . . . . . 49Configuring the access list . . . . . . . . 51

Chapter 7. IBM High-Availability ClusterMulti-Processing sensor . . . . . . . 53Model objects with associated attributes . . . . . 53Configuring the sensor . . . . . . . . . . 55

Configuring the access list . . . . . . . . 55Configuring the collation.properties file entries 55

Troubleshooting the sensor . . . . . . . . . 56

Chapter 8. IBM Lotus Domino serversensor . . . . . . . . . . . . . . . 57Asynchronous and script-based discovery support 58Configuring the access list . . . . . . . . . 59Troubleshooting the sensor . . . . . . . . . 59

Chapter 9. IBM Tivoli Monitoring Scopesensor . . . . . . . . . . . . . . . 61Model objects with associated attributes . . . . . 62Configuring the sensor . . . . . . . . . . 62

Copying necessary files from the TivoliEnterprise Portal Server to the TADDM server. . 63Distributing the discovery target support bundle 63Installing custom queries on the Tivoli EnterprisePortal Server . . . . . . . . . . . . . 65Configuring the discovery profile . . . . . . 66Discovering endpoints behind firewalls . . . . 67Configuring the access list . . . . . . . . 67

Uninstalling the sensor . . . . . . . . . . 68Deleting access list entries . . . . . . . . 68Deleting discovery profiles . . . . . . . . 68Uninstalling custom queries on the TivoliEnterprise Portal Server . . . . . . . . . 68Removing the discovery target support bundle 69Deleting the Tivoli Enterprise Portal Server filesfrom the TADDM server . . . . . . . . . 69


Chapter 10. IBM WebSphere sensor . . 77Asynchronous and script-based discovery support 79Configuring the sensor . . . . . . . . . . 81

Enabling JDBC driver discovery . . . . . . 81Configuring the discovery profile . . . . . . 81Configuring the access list . . . . . . . . 83Configuring the collation.properties file entries 87

Using the WebSphere seed sensor for z/OS. . . . 88Preparing to run the WebSphere seed sensor . . 88Running the WebSphere seed sensor . . . . . 90


Chapter 11. IBM WebSphere eXtremeScale cache sensor . . . . . . . . . 99Model objects with associated attributes . . . . 100Configuring the sensor . . . . . . . . . . 100

Chapter 12. IBM WebSphere MessageBroker sensor . . . . . . . . . . . 101Configuring the sensor . . . . . . . . . . 101

Configuring the discovery profile. . . . . . 102Configuring the access list . . . . . . . . 102Configuring the collation.properties file entries 102


© Copyright IBM Corp. 2008, 2016 iii

Chapter 13. IBM WebSphere MQServer sensor . . . . . . . . . . . 105Asynchronous and script-based discovery support 105Configuring the sensor . . . . . . . . . . 105



Chapter 14. iPlanet server sensor. . . 109

Chapter 15. JBoss server sensor . . . 111Configuring the sensor . . . . . . . . . . 112



Chapter 16. JBoss Application Server7 sensor . . . . . . . . . . . . . 115Configuring the sensor . . . . . . . . . . 115

Configuring the collation.properties fileentries . . . . . . . . . . . . . . . 116Configuring for asynchronous discovery . . . 117


Chapter 17. Kernel-based virtualmachine sensor . . . . . . . . . . 119Configuring the sensor . . . . . . . . . . 119

Configuring the collation.properties file. . . . 119Configuring the discovery profile. . . . . . 120

Chapter 18. Microsoft Cluster sensor 121Model objects with associated attributes . . . . 121Configuring the sensor . . . . . . . . . . 123



Chapter 19. Microsoft Exchangesensor . . . . . . . . . . . . . . 125Model objects with associated attributes . . . . 125Configuring the sensor . . . . . . . . . . 134



Chapter 20. Microsoft Exchange 2003sensor . . . . . . . . . . . . . . 137Configuring the sensor . . . . . . . . . . 137



Chapter 21. Microsoft HyperV sensor 143Model objects with associated attributes . . . . 143Configuring the sensor . . . . . . . . . . 144Troubleshooting the sensor . . . . . . . . . 144

Chapter 22. Microsoft IIS Web serversensor . . . . . . . . . . . . . . 145Configuring the sensor . . . . . . . . . . 146

Configuring the access list . . . . . . . . 146Configuring the discovery profile. . . . . . 146Configuring for a non-admin IIS discovery . . 147

Differences between IISServerSensor andIIsWebServiceSensor . . . . . . . . . . . 148Troubleshooting the sensor . . . . . . . . . 149

Chapter 23. NFS sensor . . . . . . . 153

Chapter 24. Oracle Application Serversensor . . . . . . . . . . . . . . 155Configuring the sensor . . . . . . . . . . 157



Chapter 25. Oracle VM sensor . . . . 161Configuring the Oracle VM sensor . . . . . . 162

Configuring the access list . . . . . . . . 162Configuring the discovery profile. . . . . . 162

Model objects with associated attributes . . . . 162

Chapter 26. SAP CCMS server sensor 165Configuring the sensor . . . . . . . . . . 165

Installing the SAP Java Connector (JCo) libraries 165Configuring the access list . . . . . . . . 166Configuring the collation.properties file entries 167


Chapter 27. SAP SLD server sensor 171Model objects with associated attributes . . . . 171Configuring the sensor . . . . . . . . . . 174



Chapter 28. SMB server sensor. . . . 177Troubleshooting the sensor . . . . . . . . . 177

Chapter 29. SMS server sensor. . . . 179Configuring the collation.properties file entries . . 179

Chapter 30. SysImager sensor . . . . 181Configuring the sensor . . . . . . . . . . 181

Configuring the discovery profile. . . . . . 181Configuring the access list . . . . . . . . 182

Chapter 31. Veritas cluster sensor . . 183Configuring the sensor . . . . . . . . . . 184

Configuring the discovery profile. . . . . . 184Configuring the access list . . . . . . . . 184Configuring the collation.properties file entries 184


iv Application Dependency Discovery Manager: Sensors

Chapter 32. VMware Virtual Centerserver sensor . . . . . . . . . . . 187Model objects with associated attributes . . . . 190Configuring the sensor . . . . . . . . . . 194

Configuring non-administrator users to run thesensor . . . . . . . . . . . . . . . 194Configuring the discovery profile. . . . . . 194Configuring the access list . . . . . . . . 195


Chapter 33. WebLogic sensor . . . . 199Configuring the sensor . . . . . . . . . . 200

Copying JAR files to the TADDM server . . . 200Creating a wlfullclient.jar for the WebLogicsensor . . . . . . . . . . . . . . . 201Editing the WeblogicVersionSensor.xml file . . 201Editing the WeblogicSensor2.xml file . . . . 202Copying JAR files to discover older versions ofWebLogic application servers . . . . . . . 203Configuring the access list . . . . . . . . 203Configuring the collation.properties file entries 203


Chapter 34. WebLogic SSH sensor 209Resources that the sensor discovers . . . . . . 211Asynchronous and script-based discovery support 213Configuring the sensor . . . . . . . . . . 213

Configuring the collation.properties file entries 215Troubleshooting the sensor . . . . . . . . . 215

Chapter 35. Database sensors . . . . 219IBM DB2 sensor . . . . . . . . . . . . 219

Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 220Configuring the sensor . . . . . . . . . 220Troubleshooting the sensor . . . . . . . . 222

IBM Informix sensor . . . . . . . . . . . 224Model objects with associated attributes . . . 225Configuring the access list . . . . . . . . 226Troubleshooting the sensor . . . . . . . . 227

Microsoft SQL Server sensor . . . . . . . . 227Configuring the sensor . . . . . . . . . 229Troubleshooting the sensor . . . . . . . . 231

Oracle sensor . . . . . . . . . . . . . 232Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 233Model objects with associated attributes . . . 234Configuring the sensor . . . . . . . . . 237Troubleshooting the sensor . . . . . . . . 238

Sybase sensor . . . . . . . . . . . . . 239Model objects with associated attributes . . . 241Configuring the access list . . . . . . . . 245Configuring the discovery profile. . . . . . 245

Sybase IQ sensor . . . . . . . . . . . . 246Configuring the access list . . . . . . . . 247

Chapter 36. Generic sensors . . . . . 249Anchor sensor . . . . . . . . . . . . . 249

Configuring the sensor . . . . . . . . . 249Asynchronous discovery sensor . . . . . . . 250

Troubleshooting the sensor . . . . . . . . 251Asynchronous discovery ping sensor . . . . . 251Custom application server sensor. . . . . . . 252Custom MIB2 computer system sensor . . . . . 253Custom template sensor . . . . . . . . . . 253

Configuring the sensor . . . . . . . . . 253Troubleshooting the sensor . . . . . . . . 256

Generic computer system sensor . . . . . . . 257Generic server sensor. . . . . . . . . . . 257

Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 258Configuring the collation.properties file entries 259Troubleshooting the sensor . . . . . . . . 260

IBM Tivoli Utilization sensor . . . . . . . . 261Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 262Model objects with associated attributes . . . 263Configuring the sensor . . . . . . . . . 263Troubleshooting the sensor . . . . . . . . 267

IP device sensor . . . . . . . . . . . . 268Configuring the collation.properties file entries 268

IP interface sensor . . . . . . . . . . . . 268Ping sensor . . . . . . . . . . . . . . 269


Port sensor . . . . . . . . . . . . . . 272Troubleshooting the sensor . . . . . . . . 272

Session sensor . . . . . . . . . . . . . 272Troubleshooting . . . . . . . . . . . 273Configuring the collation.properties file entries 275

Solaris zones generic sensor . . . . . . . . 276Troubleshooting the sensor . . . . . . . . 277

Stack Scan sensor . . . . . . . . . . . . 277Configuring the sensor . . . . . . . . . 278Troubleshooting the sensor . . . . . . . . 281

WPAR generic sensor. . . . . . . . . . . 285zEnterprise sensor . . . . . . . . . . . . 286

Sharing a common ECC instance amongmultiple applications . . . . . . . . . . 287Model objects with associated attributes . . . 288Configuring the sensor . . . . . . . . . 290Troubleshooting the sensor . . . . . . . . 291

Chapter 37. Network sensors . . . . 295Overview of SNMP sensors . . . . . . . . 295

Calling sequence for SNMP sensors . . . . . 295SNMP MIB walking and debugging SNMPsensors . . . . . . . . . . . . . . 296Maintaining SNMP computer system templatesand configuration files . . . . . . . . . 297SNMP sensors properties . . . . . . . . 300

Alteon port sensor. . . . . . . . . . . . 300Configuring the access list . . . . . . . . 300

Alteon SNMP sensor . . . . . . . . . . . 301Configuring the access list . . . . . . . . 302

Alteon VLAN sensor . . . . . . . . . . . 302Configuring the access list . . . . . . . . 303

BIG-IP port sensor. . . . . . . . . . . . 303Configuring the access list . . . . . . . . 304

BIG-IP SNMP sensor . . . . . . . . . . . 304Configuring the access list . . . . . . . . 305

Contents v

BIG-IP VLAN sensor . . . . . . . . . . . 306Configuring the access list . . . . . . . . 306

Bridge SNMP sensor . . . . . . . . . . . 307Configuring the access list . . . . . . . . 308Configuring the collation.properties fileentries . . . . . . . . . . . . . . . 309

Bridge SNMP 2 sensor . . . . . . . . . . 310Configuring the access list . . . . . . . . 310Configuring the collation.properties fileentries . . . . . . . . . . . . . . . 311

Check Point sensor . . . . . . . . . . . 312Configuring the collation.properties file entries 312Troubleshooting the sensor . . . . . . . . 313

Check Point SNMP sensor . . . . . . . . . 313Configuring the access list . . . . . . . . 313

Cisco Adaptive Security Appliance sensor . . . . 314Configuring the sensor . . . . . . . . . 314

Cisco Discovery Protocol sensor . . . . . . . 315Configuring the access list . . . . . . . . 316Troubleshooting the sensor . . . . . . . . 316

Cisco IOS sensor . . . . . . . . . . . . 316Configuring the sensor . . . . . . . . . 317

Cisco port sensor . . . . . . . . . . . . 317Configuring the access list . . . . . . . . 318

Cisco UCS SNMP sensor . . . . . . . . . 318Model objects with associated attributes . . . 319Configuring the sensor . . . . . . . . . 320Troubleshooting the sensor . . . . . . . . 321

Cisco VLAN sensor . . . . . . . . . . . 322Configuring the access list . . . . . . . . 322

CiscoWorks sensor . . . . . . . . . . . 323Model objects with associated attributes . . . 323Configuring the access list . . . . . . . . 324Troubleshooting the sensor . . . . . . . . 324

Entity MIB sensor . . . . . . . . . . . . 324Configuring the access list . . . . . . . . 326

Extreme VLAN sensor . . . . . . . . . . 326Configuring the access list . . . . . . . . 327

IBM BladeCenter SNMP sensor . . . . . . . 327Configuring the sensor . . . . . . . . . 329Troubleshooting the sensor . . . . . . . . 330

LAN Manager SNMP sensor . . . . . . . . 330Configuring the access list . . . . . . . . 331

LDAP sensor . . . . . . . . . . . . . 331Configuring the sensor . . . . . . . . . 331Troubleshooting the sensor . . . . . . . . 333

Link Layer Discovery Protocol sensor . . . . . 334NetScreen SNMP sensor . . . . . . . . . . 334

Configuring the access list . . . . . . . . 335Nokia SNMP sensor . . . . . . . . . . . 336

Configuring the access list . . . . . . . . 337PIX sensor . . . . . . . . . . . . . . 337


SNMP Light sensor . . . . . . . . . . . 338Configuring the access list . . . . . . . . 339

SNMP MIB2 sensor . . . . . . . . . . . 340Configuring the sensor . . . . . . . . . 342Troubleshooting the sensor . . . . . . . . 343

Chapter 38. Operating system sensors 345Citrix XenServer sensor . . . . . . . . . . 345

Troubleshooting the sensor . . . . . . . . 346DataPower sensor . . . . . . . . . . . . 346


FreeBSD computer system sensor. . . . . . . 349Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 350Model objects with associated attributes . . . 351Configuring the sensor . . . . . . . . . 352Troubleshooting the sensor . . . . . . . . 353

HP BladeSystem SNMP sensor . . . . . . . 353Configuring the sensor . . . . . . . . . 354Troubleshooting the sensor . . . . . . . . 355

HP NonStop computer system sensor . . . . . 355Asynchronous discovery support . . . . . . 356Troubleshooting the sensor . . . . . . . . 356

HP-UX computer system sensor . . . . . . . 356Model objects with associated attributes . . . 358Configuring the sensor . . . . . . . . . 360Troubleshooting the sensor . . . . . . . . 361

IBM AIX computer system sensor . . . . . . 362Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 363Model objects with associated attributes . . . 364Configuring the sensor . . . . . . . . . 366Troubleshooting the sensor . . . . . . . . 368

IBM Hardware Management Console sensor . . . 368Model objects with associated attributes . . . 369Configuring the sensor . . . . . . . . . 374

IBM Integrated Virtualization Manager sensor . . 375Configuring the sensor . . . . . . . . . 376

IBM i computer system sensor. . . . . . . . 377Configuring the access list . . . . . . . . 378

IPSO computer system sensor . . . . . . . . 378Configuring the access list . . . . . . . . 379

Linux computer system sensor . . . . . . . 379Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 380Model objects with associated attributes . . . 380Configuring the sensor . . . . . . . . . 383Troubleshooting the sensor . . . . . . . . 386

OpenVMS computer system sensor . . . . . . 387Configuring the access list . . . . . . . . 388Troubleshooting the sensor . . . . . . . . 388

Solaris computer system sensor . . . . . . . 389Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 390Model objects with associated attributes . . . 391Configuring the sensor . . . . . . . . . 393Troubleshooting the sensor . . . . . . . . 394

Sun Sparc Virtualization sensor . . . . . . . 395Model objects with associated attributes . . . 396

Sun Fire SysControl sensor . . . . . . . . . 397Model objects with associated attributes . . . 398Configuring the sensor . . . . . . . . . 398Troubleshooting the sensor . . . . . . . . 399

Tru64 computer system sensor. . . . . . . . 400Configuring the sensor . . . . . . . . . 401Troubleshooting the sensor . . . . . . . . 401

vi Application Dependency Discovery Manager: Sensors

VMware ESX computer system sensor . . . . . 402Configuring the sensor . . . . . . . . . 404Troubleshooting the sensor . . . . . . . . 405

VMware ESXi computer system sensor . . . . . 408Configuring the sensor . . . . . . . . . 410Troubleshooting the sensor . . . . . . . . 411

Windows computer system sensor . . . . . . 411⌂Asynchronous and script-based discoverysupport . . . . . . . . . . . . . . 413Model objects with associated attributes . . . 413Configuring the sensor . . . . . . . . . 415Troubleshooting the sensor . . . . . . . . 426

Chapter 39. Storage sensors . . . . . 433EMC Storage Scope sensor . . . . . . . . . 433

Model objects with associated attributes . . . 434Configuring the sensor . . . . . . . . . 437Troubleshooting the sensor . . . . . . . . 438

Fibre Channel switch sensor . . . . . . . . 439Model objects with associated attributes . . . 439Configuring the sensor . . . . . . . . . 439Troubleshooting the sensor . . . . . . . . 440

Host resources sensor . . . . . . . . . . 441Configuring the access list . . . . . . . . 441

Host storage sensor . . . . . . . . . . . 442Model objects with associated attributes . . . 443


IBM Tivoli Storage Productivity Center sensor . . 450Model objects with associated attributes . . . 451Configuring the sensor . . . . . . . . . 456Troubleshooting the sensor . . . . . . . . 459

NetApp sensor . . . . . . . . . . . . . 463Configuring the access list . . . . . . . . 464

Snap Drive sensor . . . . . . . . . . . . 464Configuring the access list . . . . . . . . 465

Storage sensor . . . . . . . . . . . . . 465Configuring the sensor . . . . . . . . . 466Troubleshooting the sensor . . . . . . . . 466

SVC Storage sensor . . . . . . . . . . . 467Model objects with associated attributes . . . 467Configuring the access list . . . . . . . . 469

Veritas Storage Foundation sensor . . . . . . 469Configuring the collation.properties file entries 470Troubleshooting the sensor . . . . . . . . 471

XIV Storage sensor . . . . . . . . . . . 471Configuring the sensor . . . . . . . . . 472Model objects with associated attributes . . . 472Troubleshooting the sensor . . . . . . . . 474

Notices . . . . . . . . . . . . . . 475Trademarks . . . . . . . . . . . . . . 476

Contents vii

viii Application Dependency Discovery Manager: Sensors

Figures

1. Calling sequence for SNMP Light sensor andSNMP MIB2 sensor . . . . . . . . . 296

2. Calling sequence for SNMP sensors, startingafter the SNMP Light sensor or the SNMPMIB2 sensor is called . . . . . . . . . 296

© Copyright IBM Corp. 2008, 2016 ix

x Application Dependency Discovery Manager: Sensors

Tables

1. Sensors that are enabled by default for a Level1 discovery . . . . . . . . . . . . . 2



4. Sensors that are enabled by default for autilization discovery . . . . . . . . . . 8

5. Application sensors that support a non-admindiscovery on Windows operating system. . . . 8

6. Database sensors that support a non-admindiscovery on Windows operating system. . . . 9

7. Generic sensors that support a non-admindiscovery on Windows operating system. . . . 9

8. Operating system sensors that support anon-admin discovery on Windows operatingsystem. . . . . . . . . . . . . . . 9

9. List of script-based sensors. . . . . . . . 1010. Sensors that support discovery using IBM

Tivoli Monitoring . . . . . . . . . . 1311. Sensors that support discovery using OSLC

Automation. . . . . . . . . . . . . 1412. . . . . . . . . . . . . . . . . 2413. Package names of the SAP JCo 2.x library

files . . . . . . . . . . . . . . . 16514. Required WebLogic JAR files . . . . . . 20115. Configuration parameters . . . . . . . 26416. Foundry OID mapping example . . . . . 29717. Level 2 bridge topology data . . . . . . 30718. SNMP V3 credential mapping. . . . . . . 32119. SNMP V3 credential mapping. . . . . . . 35520. . . . . . . . . . . . . . . . . 396

© Copyright IBM Corp. 2008, 2016 xi

xii Application Dependency Discovery Manager: Sensors

About this information

The purpose of this PDF document version is to provide the related topics fromthe information center in a printable format.

Conventions used in this information centerIn the IBM® Tivoli Application Dependency Discovery Manager (TADDM)documentation certain conventions are used. They are used to refer to theoperating system-dependent variables and paths, the COLLATION_HOME directory, andthe location of the collation.properties file, which is referenced throughout theTADDM documentation, including in the messages.

Operating system-dependent variables and paths

In this information center, the UNIX conventions are used for specifyingenvironment variables and for directory notation.

When using the Windows command line, replace $variable with %variable% forenvironment variables, and replace each forward slash (/) with a backslash (\) indirectory paths.

If you are using the bash shell on a Windows system, you can use the UNIXconventions.

COLLATION_HOME directory

TADDM root directory is also referred to as the COLLATION_HOME directory.

On operating systems such as AIX® or Linux, the default location for installingTADDM is the /opt/IBM/taddm directory. Therefore, in this case, the$COLLATION_HOME directory is /opt/IBM/taddm/dist.

On Windows operating systems, the default location for installing TADDM is thec:\IBM\taddm directory. Therefore, in this case, the %COLLATION_HOME% directory isc:\IBM\taddm\dist.

Location of collation.properties file

The collation.properties file contains TADDM server properties and includescomments about each of the properties. It is located in the $COLLATION_HOME/etcdirectory.

Terms and definitionsRefer to the following list of terms and definitions to learn about importantconcepts in the IBM Tivoli Application Dependency Discovery Manager (TADDM).

access collectionA collection that is used to control the access to configuration items andpermissions to modify configuration items. You can create accesscollections only when data-level security is enabled.

© Copyright IBM Corp. 2008, 2016 xiii

asynchronous discoveryIn TADDM, the running of a discovery script on a target system todiscover systems that cannot be accessed directly by the TADDM server.Because this discovery is performed manually, and separately from atypical credentialed discovery, it is called “asynchronous”.

business applicationA collection of components that provides a business functionality that youcan use internally, externally, or with other business applications.

CI See configuration item.

collectionIn TADDM, a group of configuration items.

configuration item (CI)A component of IT infrastructure that is under the control of configurationmanagement and is therefore subject to formal change control. Each CI inthe TADDM database has a persistent object and change history associatedwith it. Examples of a CI are an operating system, an L2 interface, and adatabase buffer pool size.

credentialed discoveryTADDM sensor scanning that discovers detailed information about thefollowing items:v Each operating system in the runtime environment. This scanning is also

known as Level 2 discovery, and it requires operating system credentials.v The application infrastructure, deployed software components, physical

servers, network devices, virtual systems, and host data that are used inthe runtime environment. This scanning is also known as Level 3discovery, and it requires both operating system credentials andapplication credentials.

credential-less discoveryTADDM sensor scanning that discovers basic information about the activecomputer systems in the runtime environment. This scanning is alsoknown as Level 1 discovery, and it requires no credentials.

Data Management PortalThe TADDM web-based user interface for viewing and manipulating thedata in a TADDM database. This user interface is applicable to a domainserver deployment, to a synchronization server deployment, and to eachstorage server in a streaming server deployment. The user interface is verysimilar in all deployments, although in a synchronization serverdeployment, it has a few additional functions for adding andsynchronizing domains.

discover worker threadIn TADDM, a thread that runs sensors.

Discovery Management ConsoleThe TADDM client user interface for managing discoveries. This console isalso known as the Product Console. It is applicable to a domain serverdeployment and to discovery servers in a streaming server deployment.The function of the console is the same in both of these deployments.

discovery serverA TADDM server that runs sensors in a streaming server deployment butdoes not have its own database.

xiv Application Dependency Discovery Manager: Sensors

domainIn TADDM, a logical subset of the infrastructure of a company or otherorganization. Domains can delineate organizational, functional, orgeographical boundaries.

domain serverA TADDM server that runs sensors in a domain server deployment andhas its own database.

domain server deploymentA TADDM deployment with one domain server. A domain serverdeployment can be part of a synchronization server deployment.

In a domain server deployment, the following TADDM server propertymust be set to the following value:com.collation.cmdbmode=domain

launch in contextThe concept of moving seamlessly from one Tivoli® product UI to anotherTivoli product UI (either in a different console or in the same console orportal interface) with single sign-on and with the target UI in position atthe proper point for users to continue with their task.

Level 1 discoveryTADDM sensor scanning that discovers basic information about the activecomputer systems in the runtime environment. This scanning is alsoknown as credential-less discovery because it requires no credentials. Ituses the Stack Scan sensor and the IBM® Tivoli® Monitoring Scope sensor.Level 1 discovery is very shallow. It collects only the host name, operatingsystem name, IP address, fully qualified domain name, and Media AccessControl (MAC) address of each discovered interface. Also, the MACaddress discovery is limited to Linux on System z® and Windows systems.Level 1 discovery does not discover subnets. For any discovered IPinterfaces that do not belong to an existing subnet that is discoveredduring Level 2 or Level 3 discovery, new subnets are created based on thevalue of the com.collation.IpNetworkAssignmentAgent.defaultNetmaskproperty in the collation.properties file.

Level 2 discoveryTADDM sensor scanning that discovers detailed information about eachoperating system in the runtime environment. This scanning is also knownas credentialed discovery, and it requires operating system credentials.Level 2 discovery collects application names and the operating systemnames and port numbers that are associated with each running application.If an application has established a TCP/IP connection to anotherapplication, this information is collected as a dependency.

Level 3 discoveryTADDM sensor scanning that discovers detailed information about theapplication infrastructure, deployed software components, physical servers,network devices, virtual systems, and host data that are used in theruntime environment. This scanning is also known as credentialeddiscovery, and it requires both operating system credentials and applicationcredentials.

multitenancyIn TADDM, the use by a service provider or IT vendor of one TADDMinstallation to discover multiple customer environments. Also, the serviceprovider or IT vendor can see the data from all customer environments,but within each customer environment, only the data that is specific to the

About this information xv

respective customer can be displayed in the user interface or viewed inreports within that customer environment.

Product ConsoleSee Discovery Management Console.

script-based discoveryIn TADDM, the use, in a credentialed discovery, of the same sensor scriptsthat sensors provide in support of asynchronous discovery.

SE See server equivalent.

server equivalent (SE)A representative unit of IT infrastructure, defined as a computer system(with standard configurations, operating systems, network interfaces, andstorage interfaces) with installed server software (such as a database, a webserver, or an application server). The concept of a server equivalent alsoincludes the network, storage, and other subsystems that provide servicesto the optimal functioning of the server. A server equivalent depends onthe operating system:

Operating system Approximate number of CIs

Windows 500

AIX 1000

Linux 1000

HP-UX 500

Network devices 1000

storage serverA TADDM server that processes discovery data that is received from thediscovery servers and stores it in the TADDM database. The primarystorage server both coordinates the discovery servers and all other storageservers and serves as a storage server. All storage servers that are not theprimary are called secondary storage servers.

streaming server deploymentA TADDM deployment with a primary storage server and at least onediscovery server. This type of deployment can also include one or moreoptional secondary storage servers. The primary storage server andsecondary storage servers share a database. The discovery servers have nodatabase.

In this type of deployment, discovery data flows in parallel from multiplediscovery servers to the TADDM database.

In a streaming server deployment, the following TADDM server propertymust be set to one of the following values:v com.collation.taddm.mode=DiscoveryServer

v com.collation.taddm.mode=StorageServer

For all servers except for the primary storage server, the followingproperties (for the host name and port number of the primary storageserver) must also be set:v com.collation.PrimaryStorageServer.host

v com.collation.PrimaryStorageServer.port

xvi Application Dependency Discovery Manager: Sensors

If the com.collation.taddm.mode property is set, thecom.collation.cmdbmode property must not be set or must be commentedout.

synchronization serverA TADDM server that synchronizes discovery data from all domain serversin the enterprise and has its own database. This server does not discoverdata directly.

synchronization server deploymentA TADDM deployment with a synchronization server and two or moredomain server deployments, each of which has its own local database.

In this type of deployment, the synchronization server copies discoverydata from multiple domain servers one domain at a time in a batchedsynchronization process.

In a synchronization server deployment, the following TADDM serverproperty must be set to the following value:com.collation.cmdbmode=enterprise

This type of deployment is obsolete. Therefore, in a new TADDMdeployment where more than one server is needed, use the streamingserver deployment. A synchronization server can be converted to become aprimary storage server for a streaming server deployment.

TADDM databaseIn TADDM, the database where configuration data, dependencies, andchange history are stored.

Each TADDM server, except for discovery servers and secondary storageservers, has its own database. Discovery servers have no database. Storageservers share the database of the primary storage server.

TADDM serverA generic term that can represent any of the following terms:v domain server in a domain server deploymentv synchronization server in a synchronization server deploymentv discovery server in a streaming server deploymentv storage server (including the primary storage server) in a streaming

server deployment

target systemIn the TADDM discovery process, the system to be discovered.

utilization discoveryTADDM sensor scanning that discovers utilization information for the hostsystem. A utilization discovery requires operating system credentials.

About this information xvii

xviii Application Dependency Discovery Manager: Sensors

Chapter 1. Sensor reference

OverviewFor each sensor, this reference includes overview information, and if applicable forthe respective sensor, also includes configuration and troubleshooting information.For some sensors, information about the attributes that are associated with themodel objects is also included. Where attributes are included, the attributes areavailable in the IBM Tivoli Common Data Model (CDM) but are not necessarilyshown in the IBM Tivoli Application Dependency Discovery Manager (TADDM)UI.

Sensors and supported target systems

For the list of the TADDM sensors and the supported versions of target systemsthat they can discover, see Sensors and supported target systems in the TADDMWiki.

Discovery process overview

The TADDM Administrator's Guide contains an overview of the discovery process,including information about how a sensor discovers configuration items (CIs) andhow an application sensor is started.

Late-breaking updates

For late-breaking updates about TADDM 7.3.0 sensor support issues, see Releasenotes in the TADDM documentation.

Sensor extensions

If you want to discover additional software that is not discovered by TADDM bydefault, you can create custom server templates. You can create your owntemplates or use predefined templates. For details, see the Creating and managingcustom server templates topic in the TADDM User's Guide.

Sensors that are enabled by defaultThese listings indicate which sensors are enabled by default in each of thefollowing four discovery profiles: Level 1, Level 2, Level 3, and utilization.

For more information about levels of discovery, see the Levels of discovery topic inthe TADDM Administrator's Guide.

Level 1 discovery profileThese sensors are enabled by default in a Level 1 discovery profile.

Table 1 on page 2 lists the sensors that are enabled by default for a Level 1discovery.

Sensors are listed in the order in which they are shown in the Discovery Profileswindow in the TADDM UI.

© Copyright IBM Corp. 2008, 2016 1

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/Sensors%20and%20supported%20target%20systems

Table 1. Sensors that are enabled by default for a Level 1 discovery

SensorSensor name that is used in the UI andlogs

“Anchor sensor” on page 249 AnchorSensor

“SNMP Light sensor” on page 338 SnmpLightSensor

“Stack Scan sensor” on page 277 StackScanSensor


Table 2 lists the sensors that are enabled by default for a Level 2 discovery.




“Alteon port sensor” on page 300 AlteonPortSensor

“Alteon SNMP sensor” on page 301 AlteonSnmpSensor

“Alteon VLAN sensor” on page 302 AlteonVlanSensor


“Asynchronous discovery sensor” on page250

ASDSensor

“BIG-IP port sensor” on page 303 BigIPPortSensor

“BIG-IP SNMP sensor” on page 304 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 306 BigIPVlanSensor

“Bridge SNMP sensor” on page 307 BridgeSnmpSensor

“Bridge SNMP 2 sensor” on page 310 BridgeSnmpSensor2

“Check Point SNMP sensor” on page 313 CheckpointSnmpSensor

“Cisco Discovery Protocol sensor” on page315

CdpSensor

“Cisco IOS sensor” on page 316 CiscoIOSSensor

“Cisco port sensor” on page 317 CiscoPortSensor

“Cisco VLAN sensor” on page 322 CiscoVlanSensor

“Custom application server sensor” on page252

CustomAppServerSensor

“Custom MIB2 computer system sensor” onpage 253

CustomMib2ComputerSystemSensor

“Entity MIB sensor” on page 324 EntityMIBSensor

“Extreme VLAN sensor” on page 326 ExtremeVlanSensor

“FreeBSD computer system sensor” on page349

FreeBSDComputerSystemSensor

“Generic computer system sensor” on page257

GenericComputerSystemSensor

“Generic server sensor” on page 257 GenericServerSensor

2 Application Dependency Discovery Manager: Sensors

Table 2. Sensors that are enabled by default for a Level 2 discovery (continued)


“IBM AIX computer system sensor” on page362

AixComputerSystemSensor

“IBM BladeCenter SNMP sensor” on page327

BladeCenterSnmpSensor

“IBM Hardware Management Consolesensor” on page 368

HmcSensor

“IBM i computer system sensor” on page377

I5OSComputerSystemSensor

“IBM Integrated Virtualization Managersensor” on page 375

IvmSensor

“Host resources sensor” on page 441 HostResourcesSensor

“HP BladeSystem SNMP sensor” on page353

HPBladeSystemSnmpSensor

“HP NonStop computer system sensor” onpage 355

HPNonStopComputerSystemSensor

“HP-UX computer system sensor” on page356

HpUxComputerSystemSensor

“IP device sensor” on page 268 IpDeviceSensor

“IPSO computer system sensor” on page 378 IPSOComputerSystemSensor

“LAN Manager SNMP sensor” on page 330 LanManagerSnmpSensor

“Linux computer system sensor” on page379

LinuxComputerSystemSensor

“NetApp sensor” on page 463 NetAppSensor

“NetScreen SNMP sensor” on page 334 NetscreenSnmpSensor

“Nokia SNMP sensor” on page 336 NokiaSnmpSensor

“OpenVMS computer system sensor” onpage 387

OpenVmsComputerSystemSensor

“Ping sensor” on page 269 PingSensor

“Port sensor” on page 272 PortSensor

“Session sensor” on page 272 SessionSensor

“Snap Drive sensor” on page 464 SnapDriveSensor

“SNMP MIB2 sensor” on page 340 SnmpMib2Sensor

“Solaris computer system sensor” on page389

SunSparcComputerSystemSensor

“Solaris zones generic sensor” on page 276 ZonesGenericSensor

“Sun Fire SysControl sensor” on page 397 SysControlSensor

Fix Pack 2 Sun Sparc Virtualization sensor SunSparcVirtualizationSensor

Fix Pack 1 SVC Storage sensor SVCStorageSensor

“Tru64 computer system sensor” on page400

Tru64ComputerSystemSensor

“VMware ESX computer system sensor” onpage 402

VmwareComputerSystemSensor

Chapter 1. Sensor reference 3



“VMware ESXi computer system sensor” onpage 408

VmwareEsxiComputerSystemSensor

“Windows computer system sensor” on page411

WindowsComputerSystemSensor

“WPAR generic sensor” on page 285 WparGenericSensor

Fix Pack 1 XIV Storage sensor XIVStorageSensor

“zEnterprise sensor” on page 286 ZEnterpriseSensor


Table 3 lists the sensors that are enabled by default for a Level 3 discovery.




“Active Directory sensor” on page 16 ActiveDirectorySensor

“Alteon port sensor” on page 300 AlteonPortSensor

“Alteon SNMP sensor” on page 301 AlteonSnmpSensor

“Alteon VLAN sensor” on page 302 AlteonVlanSensor


“Apache sensor” on page 18 ApacheServerSensor

“Asynchronous discovery sensor” on page250

ASDSensor

“BIG-IP port sensor” on page 303 BigIPPortSensor

“BIG-IP SNMP sensor” on page 304 BigIPSnmpSensor

“BIG-IP VLAN sensor” on page 306 BigIPVlanSensor

“Bridge SNMP sensor” on page 307 BridgeSnmpSensor

“Bridge SNMP 2 sensor” on page 310 BridgeSnmpSensor2

“Check Point sensor” on page 312 CheckpointSensor

“Check Point SNMP sensor” on page 313 CheckpointSnmpSensor

“Cisco Adaptive Security Appliance sensor”on page 314

v ASASensor

v CiscoApplianceVersionSensor

“Cisco Discovery Protocol sensor” on page315

CdpSensor

“Cisco IOS sensor” on page 316 CiscoIOSSensor

“Cisco port sensor” on page 317 CiscoPortSensor

Fix Pack 2 “Cisco UCS SNMP sensor” onpage 318

CiscoUCSSensor

“Cisco VLAN sensor” on page 322 CiscoVlanSensor




“CiscoWorks sensor” on page 323 v CiscoWorks405FileUDS

v CiscoWorks405UDS

v CiscoWorksFileUDS

v CiscoWorksSensor

v CiscoWorksUDS

“” on page 20 CitrixServerSensor

“Citrix XenServer sensor” on page 345 XenServerSensor

“Custom application server sensor” on page252


“Custom MIB2 computer system sensor” onpage 253


Chapter 4, “DNS sensor,” on page 41 DnsSensor

“EMC Storage Scope sensor” on page 433 v EMCStorageScopeSensor

v EMCStorageScopeDetailSensor

“Entity MIB sensor” on page 324 EntityMIBSensor

“Extreme VLAN sensor” on page 326 ExtremeVlanSensor

“FreeBSD computer system sensor” on page349





Chapter 5, “HIS sensor,” on page 43 HISServerSensor

“Host resources sensor” on page 441 HostResourcesSensor

“HP BladeSystem SNMP sensor” on page353


“HP NonStop computer system sensor” onpage 355

HPNonStopComputerSystemSensor

“HP-UX computer system sensor” on page356




“IBM BladeCenter SNMP sensor” on page327


“IBM DB2 sensor” on page 219 v Db2Sensor

v Db2WindowsSensor

“IBM Hardware Management Consolesensor” on page 368

HmcSensor

Chapter 7, “IBM High-Availability ClusterMulti-Processing sensor,” on page 53

HACMPSensor

“IBM i computer system sensor” on page377


“IBM Informix sensor” on page 224 Informix®




“IBM Integrated Virtualization Managersensor” on page 375

IvmSensor

Chapter 8, “IBM Lotus Domino serversensor,” on page 57

v DominoDomainSensor

v DominoServerDetailSensor

v DominoInitialSensor

“IBM Tivoli Storage Productivity Centersensor” on page 450

TPCStorageSensor

Chapter 11, “IBM WebSphere eXtreme Scalecache sensor,” on page 99

WebSphereXSCacheSensor

Chapter 12, “IBM WebSphere MessageBroker sensor,” on page 101

MBServerSensor

Chapter 13, “IBM WebSphere MQ Serversensor,” on page 105

MQServerSensor

Chapter 10, “IBM WebSphere sensor,” onpage 77

v WebSphereCellSensor

v WebSphereNodeSensor

v WebSphereVersionSensor

“IP device sensor” on page 268 IpDeviceSensor

Chapter 14, “iPlanet server sensor,” on page109

IPlanetServerSensor

“IPSO computer system sensor” on page 378 IPSOComputerSystemSensor

Chapter 16, “JBoss Application Server 7sensor,” on page 115

JBoss7Sensor

Chapter 15, “JBoss server sensor,” on page111

v JBossSensor

v JBossVersionSensor

Chapter 17, “Kernel-based virtual machinesensor,” on page 119

KvmSensor

“LAN Manager SNMP sensor” on page 330 LanManagerSnmpSensor

“LDAP sensor” on page 331 LdapSensor



Chapter 18, “Microsoft Cluster sensor,” onpage 121

MSClusterSensor

Chapter 20, “Microsoft Exchange 2003sensor,” on page 137

Exchange2003Sensor

Chapter 19, “Microsoft Exchange sensor,” onpage 125

ExchangeSensor

Chapter 21, “Microsoft HyperV sensor,” onpage 143

Microsoft HyperV Sensor

Chapter 22, “Microsoft IIS Web serversensor,” on page 145

v IISWebServiceSensor

v IISServerSensor

“Microsoft SQL Server sensor” on page 227 SqlServerSensor

“NetApp sensor” on page 463 NetAppSensor

“NetScreen SNMP sensor” on page 334 NetscreenSnmpSensor




Chapter 23, “NFS sensor,” on page 153 NFSServerSensor

“Nokia SNMP sensor” on page 336 NokiaSnmpSensor

“OpenVMS computer system sensor” onpage 387


Chapter 24, “Oracle Application Serversensor,” on page 155

v OracleAppOpmnSensor

v OracleAppSensor

“Oracle sensor” on page 232 OracleSensor


“PIX sensor” on page 337 PixSensor


Chapter 26, “SAP CCMS server sensor,” onpage 165

CCMSServerSensor

Chapter 27, “SAP SLD server sensor,” onpage 171

SLDServerSensor


Chapter 28, “SMB server sensor,” on page177

SMBServerSensor

Chapter 29, “SMS server sensor,” on page179

SMSServerSensor

“Snap Drive sensor” on page 464 SnapDriveSensor

“SNMP MIB2 sensor” on page 340 SnmpMib2Sensor



“Solaris zones generic sensor” on page 276 ZonesGenericSensor

“Storage sensor” on page 465 StorageSensor

“Sybase IQ sensor” on page 246 SybaseIQSensor

“Sybase sensor” on page 239 SybaseSensor

“Sun Fire SysControl sensor” on page 397 SysControlSensor

Fix Pack 2 Sun Sparc Virtualization sensor SunSparcVirtualizationSensor

Fix Pack 1 SVC Storage sensor SVCStorageSensor

“Tru64 computer system sensor” on page400


Chapter 31, “Veritas cluster sensor,” on page183

VeritasClusterSensor

“Veritas Storage Foundation sensor” on page469

VeritasStorageSensor

“VMware ESX computer system sensor” onpage 402


“VMware ESXi computer system sensor” onpage 408

VmwareEsxiComputerSystemSensor

Chapter 32, “VMware Virtual Center serversensor,” on page 187

VirtualCenterSensor




Chapter 34, “WebLogic SSH sensor,” on page209

v WeblogicLauncherSensor

v WeblogicApplicationSensor

v WeblogicDomainSensor

v WeblogicServerSensor



“WPAR generic sensor” on page 285 WparGenericSensor

Fix Pack 1 XIV Storage sensor XIVStorageSensor

“zEnterprise sensor” on page 286 ZEnterpriseSensor

Utilization discovery profileThese sensors are enabled by default in a Utilization discovery profile.

Table 4 lists the sensors that are enabled by default for a utilization discovery.


Table 4. Sensors that are enabled by default for a utilization discovery



“IBM Tivoli Utilization sensor” on page 261 OperatingSystemUtilizationSensor




Sensors that support a non-admin discovery on Windowsoperating system

These sensors support discovery on the Windows operating system withoutproviding user credentials with the administrator role.

The following sensors now support discovery on Windows without providing usercredentials with the administrator role:

Application sensors

Table 5. Application sensors that support a non-admin discovery on Windows operatingsystem.


Chapter 4, “DNS sensor,” on page 41 DnsSensor

Chapter 23, “NFS sensor,” on page 153 NFSServerSensor

Chapter 28, “SMB server sensor,” on page177

SMBServerSensor


Database sensors

Table 6. Database sensors that support a non-admin discovery on Windows operatingsystem.


“Microsoft SQL Server sensor” on page 227 SqlServerSensor

Generic sensors

Table 7. Generic sensors that support a non-admin discovery on Windows operatingsystem.


“Custom application server sensor” on page252 (with restrictions)




“Generic server sensor” on page 257 (withrestrictions)

GenericServerSensor



“Session sensor” on page 272 (withrestrictions)

SessionSensor

Operating system sensors

Table 8. Operating system sensors that support a non-admin discovery on Windowsoperating system.




Restrictions:

v Session sensor does not support automatic deployment of TADDM WMIprovider files. See “Copying the TaddmWmi files” on page 422.

v Generic server sensor does not discover runtime process command-linearguments. Therefore, the Custom application server sensor does notstart for the templates that are based on the Argument type conditions.Also, any application sensors that use such templates might not start.

A user with valid credentials and access rights still must be provided.

The rest of the application sensors still require the user to have an administratorrole for successful discovery.

Note: Windows User Access Control (UAC) settings do not affect non-admindiscovery because they cannot be disabled for standard users.


Configuring the sensors to run a non-admin discovery

To configure the sensors to run a non-admin discovery on the Windows operatingsystem, see the “Configuring for a non-admin Windows discovery” on page 420topic.

Sensors that support script-based and asynchronousdiscovery

Some sensors can be run as script-based sensors. These sensors are more apparent,which means that all commands that the sensor uses are in one script, which youcan view. Script-based sensors also support asynchronous discovery.

The following table lists all script-based sensors, and the operating systems, onwhich they are supported.

The “Asynchronous discovery sensor” on page 250 is required for asynchronousdiscovery. See also the Configuring for asynchronous discovery topic in the TADDMAdministrator's Guide.

Notes:

v Some of the following sensors are script-based by default, but some of themmust be configured for script-based discovery. See the Configuring for script-baseddiscovery topic in the TADDM Administrator's Guide.

v If the target computer system is running the Solaris operating system,script-based discovery might not work if SunSSH 1.0 is used.

Table 9. List of script-based sensors..

SensorSensor name that isused in the UI and logs

The operating systems,on which the sensor issupported

Script-based bydefault

“Apache sensor” on page18

ApacheServerSensor v AIX

v Linux

v Solaris

No

“Asynchronous discoverysensor” on page 250

ASDSensor v AIX

v FreeBSD

v Linux

v HP NonStop

v Solaris

v Windows

Yes

“Citrix XenServersensor” on page 345

XenServerSensor v Linux Yes

“FreeBSD computersystem sensor” on page349


v FreeBSD No

“Generic server sensor”on page 257

GenericServerSensor v AIX

v Linux

v Solaris

v Windows

No


Table 9. List of script-based sensors. (continued).




“HP NonStop computersystem sensor” on page355

HpNonStopComputerSystemSensor

v HP NonStop Yes

“IBM AIX computersystem sensor” on page362


v AIX No

“IBM DB2 sensor” onpage 219

Db2Sensor v AIX

v Linux

v Solaris

No

Chapter 8, “IBM LotusDomino server sensor,”on page 57

DominoInitialSensor v AIX

v Linux

v Solaris

No

“IBM Tivoli Utilizationsensor” on page 261

OperatingSystemUtilizationSensor

v AIX

v FreeBSD

v Linux

v Solaris

No

Chapter 13, “IBMWebSphere MQ Serversensor,” on page 105

MQServerSensor v AIX

v Linux

v Solaris

v Windows

Yes

Chapter 10, “IBMWebSphere sensor,” onpage 77

WebSphereScriptSensor

v AIX

v Linux

v Solaris

v Fix Pack 2 Windows

Yes

Chapter 16, “JBossApplication Server 7sensor,” on page 115

JBoss7Sensor v AIX

v Linux

v Solaris

v Windows

Yes

Chapter 17,“Kernel-based virtualmachine sensor,” onpage 119

KVMSensor v Linux Yes

“Linux computer systemsensor” on page 379


v Linux No

Chapter 19, “MicrosoftExchange sensor,” onpage 125

ExchangeSensor v Windows Yes

Chapter 22, “MicrosoftIIS Web server sensor,”on page 145

IISServerSensor v Windows Yes


Table 9. List of script-based sensors. (continued).




Fix Pack 2 “MicrosoftSQL Server sensor” onpage 227 (withrestrictions)

SqlServerSensor v Windows No

“Oracle sensor” on page232

OracleSensor v AIX

v Linux

v Solaris

No

“Solaris computer systemsensor” on page 389


v Solaris No

Fix Pack 2 “Sun SparcVirtualization sensor” onpage 395

SunSparcVirtualizationSensor

v Solaris Yes

Chapter 34, “WebLogicSSH sensor,” on page 209

WeblogicLauncherSensor

v AIX

v Linux

v Solaris

No

“Windows computersystem sensor” on page411


v Windows No

Restrictions

v Fix Pack 2 The script-based discovery mode of the Microsoft SQL Serversensor relies on the sqlps module, which is available in Microsoft SQLServer 2008, and later. Therefore, if you want to discover Microsoft SQLServer 2005, you must have other instances like Microsoft SQL Server2008, 2008 R2, or 2012 installed as well.

Sensors that support discovery using IBM Tivoli Monitoring(old method)

These sensors support discovery using IBM Tivoli Monitoring.

New integration method

Important: Starting with the TADDM 7.3.0, it is advised to integrate with IBMTivoli Monitoring 6.3 using OSLC Automation. The old method of integration withthe use of IBM Tivoli Monitoring Scope sensor is deprecated and will be removedfrom future releases.

Learn more about TADDM integration with ITM by using OSLC Automation fromthe Integrating TADDM with IBM Tivoli Monitoring via OSLC Automation topic of theTADDM Administrator's Guide and about sensors that support discovery usingOSLC Automation at “Sensors that support discovery using OSLC Automation” onpage 14.

The Chapter 9, “IBM Tivoli Monitoring Scope sensor,” on page 61 is required fordiscovery using IBM Tivoli Monitoring. This sensor must be run at least once tocreate the necessary scope sets.


The IBM Tivoli Monitoring Scope sensor creates scope sets for all active computersystems in a Tivoli Monitoring environment. After these scope sets are created, youcan run Level 2 and Level 3 discovery of those computer systems using a TivoliMonitoring session, without including the IBM Tivoli Monitoring Scope sensor inthe Level 2 and Level 3 discovery profiles.

Note: If your IBM Tivoli Monitoring managed computer systems are behind afirewall (are not reachable from TADDM discovery server), you might need toinclude the IBM Tivoli Monitoring Scope sensor in your profile withstartSessionOnly option enabled. For details, see Configuring the discovery profilein IBM Tivoli Monitoring Scope sensor documentation.

For Level 2 and Level 3 discovery of the systems that are monitored by IBM TivoliMonitoring, the following features must be installed on the target system:v On Windows target systems, Microsoft .NET Framework must be installed. For

more information, see the Configuring for discovery of Windows systems topic in theTADDM Administrator's Guide.

v On Linux and UNIX target systems, uuencode and uudecode commands that arecompliant with the Portable Operating System Interface (POSIX) must beinstalled.On Linux operating systems, these commands are typically included with thesharutils package.On AIX, Solaris, and HP-UX operating systems, these commands are installed bydefault.

Not all sensors in a Level 2 or Level 3 discovery profile support discovery usingTivoli Monitoring. Table 10 lists the sensors that support discovery using TivoliMonitoring. When a sensor runs within the Tivoli Monitoring session, it uses theTivoli Monitoring access credentials rather than the access credentials that areconfigured for the sensor. The Tivoli Monitoring user account must have necessaryauthorization to access the application that is being discovered. For example, todiscover IBM DB2 Universal Database™ (UDB) servers, the Tivoli Monitoring useraccount on the target DB2® server must be a member of the DB2 administrationgroup.

Table 10. Sensors that support discovery using IBM Tivoli Monitoring






“IBM DB2 sensor” on page 219 Db2Sensor


MQServerSensor









Table 10. Sensors that support discovery using IBM Tivoli Monitoring (continued)


Fix Pack 2 “Sun Sparc Virtualization sensor”on page 395







Sensors that support discovery using OSLC AutomationThese sensors support discovery using IBM Tivoli Monitoring.

To run a discovery using OSLC Automation, OSLCAutomationAgent must createthe necessary scope sets. When these scope sets are created, you can run Level 2and Level 3 discovery of the computer systems that use the OSLC Automationsession.

To learn more about configuring the discovery, see the Configuring for discovery overOSLC Automation Session topic in the TADDM Administrator's Guide.

For Level 2 and Level 3 discovery of the systems that are monitored by IBM TivoliMonitoring, the Microsoft .NET Framework must be installed on the Windowstarget systems.

For information about supported versions of .NET Framework, see the Configuringfor discovery of Windows systems topic in the TADDM Administrator's Guide.

The sensors that support discovery using OSLC Automation are the same as theones that support discovery using IBM Tivoli Monitoring.

Table 11. Sensors that support discovery using OSLC Automation.






“IBM DB2 sensor” on page 219 Db2Sensor


MQServerSensor









Table 11. Sensors that support discovery using OSLC Automation. (continued)


“Sun Sparc Virtualization sensor” on page395







Sensor setup problemsThis information covers common problems that occur with sensor setup inTADDM.

A Linux, Solaris, AIX, or Linux on System z® operating systemcannot be discovered

ProblemA Linux, Solaris, AIX, or Linux on System z operating system cannot bediscovered.

SolutionEnsure that the following prerequisites for discovering Linux, Solaris, AIX,and Linux on System z operating systems have been met:v Create a service account. Configure the account to be a member of the

sys group, and use /bin/sh as the shell for this account.v Install and test the Secure Shell (SSH) protocol from the TADDM server.

If you are using key-based authentication, install public keys on all thehosts. To verify that the login and password or the key and passphrasework properly, enter the ssh command from the command prompt onthe computer where the TADDM server is installed.

v Install the LiSt Open Files (lsof) program on all host computersaccording to the requirements in lsof requirements in the TADDM Wiki athttps://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/TADDM%20lsof%20requirements.

On Linux, AIX, and Linux on System z operating systems,discovery never ends

ProblemOn a Linux, AIX, or Linux on System z operating system, discovery neverends. Running the ps -ef command shows instances of thestop-local-anchor.sh process that remain for more than 5 minutes.

SolutionAccess to the sudo command must be configured so that the TADDM user,which is the user that starts the TADDM server, can run sudo commandswithout having the password prompt displayed. To configure the sudoaccess in this way, complete the following steps:1. Login to the TADDM server as the root user.2. Enter the visudo command.


https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/TADDM%20lsof%20requirements



3. Type the following line in the /etc/sudoers file, where TADDM_USERis the user that starts the TADDM server:<TADDM_USER> ALL=NOPASSWD:ALL

To verify that the sudo access is configured correctly, enter the followingcommands:cd $COLLATION_HOME/binsh ./stop-local-anchors.sh

If a password prompt opens, the NOPASSWD access has not been configuredcorrectly for the TADDM user.

A discovery of application servers that are running on theSolaris 10 operating system returns incorrect port numbers

ProblemIncorrect port numbers are returned when you run a discovery ofapplication servers that are running on the Solaris 10 operating system.

SolutionEnsure that lsof 4.77, or later, is installed on every system that is runningon the Solaris 10 operating system. Versions of lsof prior to 4.77 do notsupport Solaris 10 6/06 or later. Additionally, there are two version of lsof4.77. One is for the pre 6/06 Solaris 10 release, and the other is for the6/06 Solaris 10 release, and later versions. Make sure that you install theversion of lsof 4.77 that matches the version of the Solaris 10 OperatingSystem that is installed.

Application sensorsApplication sensors discover the applications that are running in the environment.

Active Directory sensorThe Active Directory sensor discovers Microsoft Active Directory servers.

Sensor name that is used in the GUI and logs

ActiveDirectorySensor

Security issues

The sensor uses the command ntdsutil.exe during the discovery and thiscommand requires elevated security privileges. To verify that the discovery accounthas adequate privileges, enter the following command on one line:

On Windows 2000 and Windows Server 2003:ntdsutil "domain management" connections "connect to server localhost"q "list" q q

On Windows Sever 2008:ntdsutil "partition management" connections "connect to server localhost"q "list" q q

Model objects with associated attributesThe Active Directory sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about MicrosoftActive Directory servers in your IT environment.


The sensor creates the following model objects. The attributes that are associatedwith each model object are shown below the model object name.

sys.ActiveDirectory

v Hostv InitRecvTimeoutv MaxConnIdleTimev MaxConnectionsv MaxDatagramRecvv MaxNotificationPerConnv MaxPageSizev MaxPoolThreadsv MaxQueryDurationv MaxReceiveBufferv MaxResultSetSizev MaxTempTableSizev MaxValRangev NamingContextsv Namev RootDomainv SchemaVersionv ServiceXMLv WorkingDirectory

sys.ServiceAccessPoint

v ContextIpv BindAddressv Namev ProductNamev ProductVersionv VendorName

sys.NamingContext

v Indexv Value

Configuring the sensorBefore running a discovery, you must configure the sensor.

Configuring the scope

The Active Directory server must be included in the discovery scope.

Configuring the access list

You must add the computer system (for example, Windows) to the access list, andthe user ID for accessing the system must belong to the administrators group.


Configuring the discovery profile

The sensor is enabled by default in a Level 3 discovery profile. Alternatively, youcan create a custom profile and enable the Active Directory sensor and theWindows computer system sensor from the new profile.

Apache sensorThe Apache sensor discovers Apache Web servers.


ApacheServerSensor

Prerequisites

The TADDM service account requires:v Execute permissions on the httpd binary filev Read access to the httpd.conf filev Discovery user shall have Read and execute permissions for all the required

Apache libraries/modules/files/folders to run httpd command successfully (fore.g: /oracle/product/iasgrm/librarypath and /oracle/product/iasgrm/Apache,and so on).

Limitations

The Apache sensor cannot discover the Apache server if the Apache server instanceis configured or started in such a way that it rewrites its command line (forexample, rewrites the argv array), causing the Apache server instance to show in aprocess listing as httpd, without any path or command-line options.

Model objects created

The sensor creates the following model objects:v app.AppConfigv app.CertificateFilev app.ConfigFilev app.PrivateKeyFilev app.web.ServerAliasv app.web.apache.ApacheGlobalSSLSettingsv app.web.apache.ApacheModulev app.web.apache.ApacheSSLSettingsv app.web.apache.ApacheServerv app.web.apache.ApacheVirtualHostv app.web.apache.ApacheWebContainerv app.web.ibm.IBMHTTPServerv app.web.oracleapp.OracleAppHTTPServerv app.web.WebConnectionv app.web.WebVirtualHostConfigDirective

Asynchronous and script-based discovery supportThe Apache sensor supports asynchronous and script-based discovery.


Sensor configuration requirements

For asynchronous discovery, the sensor requires no configuration.

For information about configuring for script-based discovery, see the Configuring forscript-based discovery topic in the TADDM Administrator's Guide.

Access list configuration requirements

For asynchronous discovery, the access list is not used.

For script-based discovery, the access list configuration is the same as fornonscript-based discovery.

Limitations

Some function that is provided by the Apache sensor during a nonscript-baseddiscovery is not supported in an asynchronous or script-based discovery.

Application descriptor discovery is not supported.

The following attributes are not supported for a configuration file:v Last modifiedv Ownerv Groupv Permissions

Only running applications are discovered.


Configuring the access list:

This topic describes the access details that you require, depending on yourconfiguration.

This sensor can be run using the ComputerSystem access credentials used todiscover the client.

Configuring the collation.properties file entries:

This topic lists the collation.properties file entries that the sensor uses.

The sensor uses the following entries in the collation.properties file:

com.collation.discover.agent.ApacheServerAgent.UseListenningIp=falseThe sensor discovers Apache Web servers and assigns the same nameinstead of reporting one for each Web server host name. When thisproperty is set to true, the display name for the ApacheServer object is setto:

HOSTNAME:LISTENINGIP:PORT

The default value of this property is false.

You must manually delete the HOSTNAME:PORT instances.


com.collation.discover.agent.ApacheServerAgent.CmdPrefixAdds a command or script that must be run before the httpd -V command.This property can be configured for the operating system name, IP addressor both.

The Apache sensor attempts to use the property if the first (standard)command fails. For example:

com.collation.discover.agent.ApacheServerAgent.CmdPrefix.AIX.9.156.47.172=LIBPATH=/usr/local/apache2/build:/usr/local/apache2/lib:/usr/lib:/lib/;export LIBPATH

Troubleshooting the sensorThis topic describes common problems that occur with the Apache sensor andpresents solutions for those problems.

Discovery error with “cannot execute httpd”

ProblemA discovery error states cannot execute httpd, but the TADDM serviceaccount can run the httpd process manually.

The session sensor tries each appropriate access list credential until oneworks. When one access list credential works, the session sensor stopstrying. Therefore, the first access list credential that works must be able torun the httpd process.

SolutionTry using scope restrictions with a reordered access list to force the correctaccount to be used to discover the Apache server.

Apache sensor fails with error CTJTD0072E

ProblemThe Apache sensor uses the httpd -V command to get the root directory,configuration file, and other information related to the Apache server. Ifthe httpd -V command fails, the sensor also fails.

SolutionUse the com.collation.discover.agent.ApacheServerAgent.CmdPrefixproperty to specify a command to run before the httpd -V command isrun.

Many fields in the Details panel are empty

ProblemA number of fields in the Details panel are empty.

SolutionThe service account cannot read the http.conf file. Make the http.conf filepublicly readable, or add the service account to a group that has readaccess to the http.conf file.

Fix Pack 4

The Citrix server sensor discovers a Citrix Presentation Server (Citrix PresentationServer Enterprise 3 and 4) or XenApp server (Citrix XenApp Enterprise version 5and version 6).



CitrixServerSensor

Security issues

The discovery user must have read permissions (defined in the Citrix Productconsole) for the Citrix configuration. To discover the Citrix Presentation Serverconfiguration, you must have permission to query the Citrix WMI Provider. Thisprovider must be running in order to be discovered.

The Citrix WMI Provider is on your discovered system where the CitrixPresentation Server is installed. It is a part of the Citrix product.

To grant this permission, complete the following steps:1. Log in to the Management Console for Metaframe Presentation Server.2. From the menu, select Actions > Permissions.3. Edit the user and group permissions.4. Ensure that the View farm management permission is granted. This

permission is the minimal permission that must be granted to query the CitrixWMI provider.a. Select a user or group.b. Click Edit

c. Select the appropriate permission:v View only: works for the Citrix sensorv Full administration: works for the Citrix sensorv Custom: the administrator can define their own access level

Model objects with associated attributes

The Citrix server sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about CitrixPresentation Server and XenApp server in your IT environment.

Troubleshooting the sensor

This topic describes common problems that occur with the Citrix server sensor andpresents solutions for those problems.

Citrix XenApp 7.6 Discovery

This topic describes the details about the discovery of Citrix XenApp 7.6 software.

Model objects with associated attributesThe Citrix server sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about CitrixPresentation Server and XenApp server in your IT environment.


CitrixAccountAuthority

v AuthorityName


v AuthorityTypev Group

CitrixAppFolder

v Applicationsv Farm

CitrixApplication

v AppFolderv ApplicationIDv CitrixFarmv CitrixGroupsv Serversv Users

CitrixFarm

v AppFoldersv DSDriverv DSODBCv FarmNamev LicensePoolv LocalIpv SNMPDisconnectTrapv SNMPLogoffTrapv SNMPLogonTrapv SNMPThresholdExceededTrapv SNMPThresholdValuev ServerFoldersv Zones

CitrixFolder

v FolderDNv FolderNamev Foldersv Parent

CitrixGroup

v AccountAuthorityv CitrixApplications

CitrixLicense

v Poolv SerialNumber

CitrixLicensePool

v DupGroupv Farmv FloatOkv HostBasedv HostID


v Licensesv PLDv Platformsv SubscriptionDatev UserBasedv VendorString

CitrixServer

v Applicationsv Folderv IsFarmServerv LocalPrimarySAPv Processesv Zone

CitrixServerFolder

v Farmv Servers

CitrixUser

v AccountAuthorityv Applications

CitrixZone

v DataCollectorv Farmv Serversv ZoneName

Troubleshooting the sensorThis topic describes common problems that occur with the Citrix server sensor andpresents solutions for those problems.

The Citrix sensor runs slowly

ProblemThe Citrix sensor runs slowly on systems that are overloaded with manypublished Citrix applications (WMI queries take a long time).

SolutionIncrease the sensor timeout by setting the following properties in thecollation.properties file:v com.collation.discover.agent.CitrixServerAgent.

sessiontimeout=600000

v com.collation.discover.agent.CitrixServerAgent.timeout=600000

These properties must be set to a value that is at least equal to the value ofthe com.collation.discover.DefaultAgentTimeout property.

Citrix 7 server sensor

Fix Pack 4


The Citrix 7 server sensor discovers a XenApp server (Citrix XenApp Enterpriseversion 7.6) and it uses Citrix powershell SDK interface for discovery purpose.


Citrix7Sensor

Elements discovered by the sensor

The sensor discovers the following elements that are associated with CitrixXenApp application virtualization software environment:

Delivery Site(s) - Highest level item. Sites offer applications to group of users.

Machine Catalogs – Can be used to manage machines hosting applications.

Machine(s) – Citrix machines which hosts Citrix XenApp 7.6

Citrix Users – set of users authorized to access the specified virtualizedapplications.

Citrix Applications – Virtualized Applications that are available to a given set ofusers.

Licensing Information – Citrix License pools and individual license details.

Prerequisites

The following prerequisites are required:v This script-based sensor uses the same discovery user that is used for Windows

logon.v The Windows discovery user must have “administrator read only” permissions

(defined in the Citrix console) for the Citrix configuration on any deliverycontroller for each site. Citrix requires that the discovery user be an activedirectory account and not a local account.

v Citrix Powershell snap-ins shall be installed and available on DeliveryController.


Citrix 7 introduces an architecture change from Citrix 6, but the TADDM datamodel is based on Citrix 6 architecture. In order to preserve backwardscompatibility for business application mapping, the Citrix 7 architecturecomponents are stored as Citrix 6 data model components. The table below showsthe old and new concepts and how they map to the TADDM data model.

Table 12.

Citrix 7 Citrix 6 Comments

Site CitrixFarm/CitrixZone For each Citrix Site there willbe a one-to-one Farm/Zonecombination with the samename.

Admin Folder CitrixAppFolder Organizes theCitrixApplicationcomponents.


Table 12. (continued)

Citrix 7 Citrix 6 Comments

Desktop Catalog CitrixServerFolder NA

Desktop Group NA Desktop Groups are used toassign CitrixApplications toCitrixServers.

The Citrix 7 server sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about CitrixPresentation Server and XenApp server in youran IT environment.

Some of the attributes in Citrix model objects are not relevant or not used in CitrixXenApp 7.6 architecture and hence they will not get populated and thus may getdisplayed with no value (“Blank") in TADDM Data Management Portal, sinceTADDM Data model is based on Citrix 6 architecture.


CitrixAccountAuthority

v AuthorityNamev Group

CitrixAppFolder

v Applicationsv Farm

CitrixApplication

v AppFolderv ApplicationIDv CitrixFarmv CitrixGroupsv Serversv Users

CitrixFarm

v AppFoldersv FarmNamev LicensePoolv LocalIpv ServerFoldersv Zones

CitrixFolder

v FolderDNv FolderNamev Foldersv Parent


CitrixGroup

v AccountAuthorityv CitrixApplications

CitrixLicense

v Poolv SerialNumber

CitrixLicensePool

v DupGroupv Farmv FloatOkv HostBasedv HostIDv Licensesv PLDv Platformsv SubscriptionDatev UserBasedv VendorString

CitrixServer

v Applicationsv Folderv LocalPrimarySAPv Processesv Zone

CitrixServerFolder

v Farmv Servers

CitrixUser

v AccountAuthorityv Applications

CitrixZone

v DataCollectorv Farmv Serversv ZoneName

Limitationsv Site names are assumed to be global. We cannot have two sites with the exact

same name or this will cause over-merging.v Asynchronous Discovery mode is not supported.


Note: For Anchor based discovery of Citrix XenApp 7.6, script discovery needs tobe enabled in collation.properties file:com.ibm.cdb.discover.PreferScriptDiscovery=true


Chapter 2. Docker Host sensor

Fix Pack 4

The Docker Host Sensor (DHS) discovers Docker Hosts, host attributes, containers,networking, image and storage related information.


DockerHostSensor


The sensor discovers the following elements:v Docker Hostsv Docker Containersv Docker Volumesv Docker Networksv Dockers Images

In the Discovery Management Console and Data Management Portal, a DockerHost is represented by a blue-colored Docker whale design icon, and, Dockercontainer using square shaped four-stacked shipping containers.

The Docker Host Sensor uses REST APIs to retrieve the discovery relatedinformation from the Docker host machine running the 'dockerd' daemonprocess/application. The retrieved data primarily comprises of attribute data thatis required to match naming rules and create valid model objects.

Prerequisitesv The Docker daemon/application is running on a target Linux machine.v For successful discovery of Docker Host, REST support must be enabled on the

target machine.v Ports for web service communication must be defined. By default, port value

resulting from GenericServerSensor processing is used. If your Docker Host usesport-mapping, or, non-standard port, modify the value of the portList property inthe discovery profile. For details, see 'Configuring the discovery profile'.

v Single set of TLS certificate is applicable for TADDMs communication to all theDocker Host.

v Enable or Disable of TLS for discovery will have a uniform behavior across ALLDocker hosts defined within the scope– Either applicable to ALL, or, NONE Docker Hosts.

In the Discovery Management Console and Data Management Portal, a DockerHost is represented by a blue-colored Docker whale design icon, and, Dockercontainer using square shaped four-stacked shipping containers.

The Docker Host Sensor uses REST APIs to retrieve the discovery relatedinformation from the Docker host machine running the 'dockerd' daemonprocess/application. The retrieved data primarily comprises of attribute data that


is required to match naming rules and create valid model objects.

Security issues

No specific access-list entry is required. For TLS based security details, seeConnection to Docker Host below:

Connection to Docker Host

The Docker Host Sensor can discover data from Docker Host through 2 modes:non-TLS mode, and, TLS mode.

Non-TLS mode

The non-TLS mode is the default mode. It retrieves data via web services anddoesn’t require authentication. This mode is recommended in private network, or,private cloud deployments in customer premises.

TLS mode

The TLS mode is secure mode of communicating with the Docker Host. It verifiesthe TLS certificates installed in TADDM and target Docker Host. To use this mode,you must set the enableTLS property to true, along with configuring the certificatepaths defined in discovery profile. For details, see 'Configuring the discoveryprofile'. For manually generating the TLS certificates for TADDM and Docker host,see 'Manual TLS certificate generation'.


The Docker Host Sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about DockerHost resources in your IT environment.


app.docker.dockerhost.DockerHost

v Namev VersionStringv DockerContainersv DockerImagesv DockerNetworksv DockerVolumesv Hostv XA

o Architectureo KernelVersiono OperatingSystemo OSTypeo RunningContainerso StoppedContainerso TotalContainers


app.docker.dockerhost.DockerContainer

v Namev Parentv RuntimeProcessesv DockerContainerStatusv DockerImagesv DockerNetworksv DockerVolumes

app.docker.dockerhost.DockerImage

v DockerHostv ImageNamev DockerContainer

app.docker.dockerhost.DockerNetwork

v Namev SubnetAddressv DockerHostv DockerContainer

app.docker.dockerhost.DockerVolume

v Namev DockerHostv DockerContainer

sys.RuntimeProcess (applicable to processes within a container)

v PIDv Commandv PPIDv Userv CmdLine (refers to the full command)

Configuring the sensor

Before using the Docker Host Sensor, you must configure it.

Configuring the discovery profile:

By default, the Docker Host Sensor is enabled for a Level 3 discovery. Onceenabled, it runs in a non-TLS mode by default. The sensor discovers all DockerHost containers, including the ones which are not running. To discover onlycontainers which are running, or, for switching to TLS mode, create a discoveryprofile for the Docker Host sensor, and customize the sensor settings.

To create the discovery profile, complete the following steps:

Example:

1. In the Discovery drawer of the Discovery Management Console, clickDiscovery Profiles.

2. In the Discovery Profiles window, click New.

Chapter 2. Docker Host sensor 31

3. In the Create New Profile window, type the profile name anddescription. From the Clone existing profile list, select Level 3Discovery and click OK

4. On the Sensor Configuration tab, select the DockerHostSensor sensorand click New.

5. In the Create Configuration window, type the name and description foryour configuration, and select the Enable Configuration check box.

6. In the Configuration section of the Create Configuration window, clickdiscoverNonRunningContainers. Then, double-click the Value field inthe row, and type false.

7. Click OK to return to the Discovery Profiles window.8. In the Discovery Profiles window, click Save.

Properties

You can modify the following properties and attributes:

portList

It refers to the port(s) to be used for web service communication on Docker Host.By default, port value returned by GenericServerSensor processing is used. If yourDocker Host uses port-mapping, or, non-standard port (or, comma-separated list ofports), specify the value accordingly.

enableTLS

It refers to the connection mode between TADDM and Docker Host.

The default value is false.

pathStore

Local path on TADDM discovery server where all the TLS/security certificates areplaced.

caFileName

Certificate Authority file name.

cerFileName

Client certificate file name

keyFileName

Client key file name

Enable REST support on Docker Host

On a Docker Host following configuration changes need to be done:1. Enable the REST APIs on Docker host.v Login to the Docker host machine using 'root' credentials.v Create/Update the following file on Docker Host:

vim /etc/systemd/system/docker.service.d/remote-api.conf


with following content:[Service]

ExecStart=

ExecStart=/usr/bin/dockerd -H tcp://<DockerHost-IP>:2376 -H unix:///var/run/docker.sock

2. Restart the 'dockerd' daemon and validate status via command line:service docker restart

ps -aef | grep -i dockerd

Manual TLS certificate generation

In case TLS-mode is enabled and certificates are not available, you can manuallygenerate these certificates in a Linux machine as below.

A. Docker Host:

On Docker host machine, generate CA private and public keys per the stepwiseprocedure mentioned below. Remember the key sample below is for example, andyou must provision per your security standards.1. Login to the Docker Host machine using 'root', or, another user having

'super-user' privileges.2. Make a local directory via commands.

mkdir docker_certificates

cd docker_certificates

3. Execute command:a. openssl genrsa -aes256 -out ca-key.pem 4096

v 1. Enter any pass phrase for generating ca-key.pem and store it safely.b. openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

v 1. Enter the password entered in step (3.a.1)v 2. Enter the values askedv 3. Enter Docker Host 'domain.com' in Fqdn

4. Using the CA, create a server key and certificate signing request (CSR) viacommandsa. openssl genrsa -out server-key.pem 4096

b. openssl req -subj ’/CN=$HOST’ -sha256 -new -key server-key.pem -out server.csr

v 1. Where, $HOST is hostname of the Docker Host.5. TLS connections can be made via IP address or DNS name, the IP addresses

need to be specified when creating the certificate via command:a. echo subjectAltName = DNS:$HOST,IP:<DockerHost-IP> > extfile.cnf

v 1. where, $HOST is hostname of the Docker Host.a.echo extendedKeyUsage = serverAuth >> extfile.cnf

6. Now, generate the key via command:a.openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \

-CAcreateserial -out server-cert.pem -extfile extfile.cnf

v 1. Enter the password provided in step (3.a.1).7. Remove un-necessary files and set the permissions correctly:

rm -v server.csr

chmod -v 0400 ca-key.pem server-key.pem

chmod -v 0444 ca.pem server-cert.pem

8. Start the Docker daemon using TLS verfication:


a.dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:2376

Note: In case of TLS support for multiple Docker Hosts, execute steps 1-3ONLY once, and steps 4-8 need to be executed separately for each host togenerate the necessary TLS certificates for the hosts.

B. TADDM Machine:

TLS client certificates for TADDM machine (corresponding to the ones generatedfor Docker Host) can be generated manually. On the TADDM host machine,generate CA private and public keys by following the stepwise procedurementioned below:1. Login to the TADDM machine using 'root' user credentials2. Make a local directory via commands

a. mkdir taddm_certificates

b. cd taddm_certificates

3. Using the CA, create a server key and certificate signing request (CSR) viacommands:a. openssl genrsa -out key.pem 4096

b. openssl req -subj ’/CN=client’ -new -key key.pem -out client.csr

c. echo extendedKeyUsage = clientAuth >> extfile.cnf

4. Sign the private key via command:a. openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

v 1. provide ca.pem and ca-key.pem generated in section A: step (3.a, 3.b)v 2. Enter the password provided in section A: step (3.a.1)

5. Remove un-necessary files and set the permissions correctly:a. rm -v client.csr

b. chmod -v 0400 ca-key.pem key.pem

c. chmod -v 0444 ca.pem cert.pem

d. cd ../

e. chown -R taddmusr:taddmusr taddm_certificates

f. chown -R taddmusr:taddmusr taddm_certificates

6. Validate the TLS connection with DockerHost machine using the followingcommands:curl https://<Dockerhost-IP>:<Docker-Port>/_ping --cert ./cert.pem --key key.pem --cacert ca.pem

e.g. curl https://<Dockerhost-IP>:<2376>/_ping --cert ./cert.pem --key key.pem --cacert ca.pem


This topic describes common problems that occur with the Docker Host sensor andpresents solutions for those problems.

The sensor fails with description ` CTJTD1585E Error – Docker host is notreachable on any of these ports:`

Problem : Remote web API may not be enabled on Docker host.

SolutionValidate using 'ps - eaf | grep dockerd' to see which port is used by'dockerd' daemon process. The output should look something like below:/usr/bin/dockerd -H tcp://9.158.143.51:2376 -H unix:///var/run/docker.sock

To enable remote API support, see 'Enable REST support' on Docker Host.


The sensor fails with description `CTJTD1587E/ CTJTD1590E Error – TLSconfiguration mismatch between Docker Host sensor and remote node:’

Problem : The problem occurs because of mismatch in configuration for DockerHost sensor and the Docker Host remote node. TLS may be enabled on one, and,disabled for the other.

Solution : Validate and configure the enableTLS property for Docker Host sensorcorrectly.

The sensor fails with description ` CTJTD1589E Error – Issue with TLSpath-store directory`

Problem : Either, the pathstore directory configured in the Docker Host sensorconfiguration is invalid, or, is lacking the correct permissions.

Solution : Check for existence of the configured pathstore directory on theTADDM discovery server. If the directory exists, validate that it has been grantedcorrect permissions.drwxr-xr-x. 2 taddmusr taddmusr 4096 Nov 24 08:28 taddm_certificates

The sensor fails with description ` Failed: HTTP error code : 503`

Problem : In case TADDM is unable to connect via REST to Dockerdaemon/application on target node, the sensor can fail with an error message.

Solution : If dockerd process/application is running good, it becomes important tovalidate the specific port on which the daemon/process is listening using thecommand ps - Aef | grep dockerd. The port obtained from output must match withthe one TADDM is trying to connect.

The sensor fails with a `CTJTD3520E Error – A storage error has occurred. Serverid:`

Problem : In case there are any missing dependencies of java jars on character setconversion the sensor can fail with a storage error message shown above.

Solution : Validate for any missing Java jars and place the corresponding one inthe below directory:/opt/IBM/taddm/dist/lib/jdbc

Run discovery again.


Chapter 3. Docker Swarm Cluster sensor

Fix Pack 4

Docker Swarm Cluster sensor

The Docker Swarm Cluster Sensor (DSHS) discovers Docker Swarm, attributes,swarm nodes, swarm network and swarm services related information.


DockerSwarmClusterSensor


The sensor discovers the following elements:v Docker Swarmv Docker Nodes (referred as Docker Host)v Docker Servicesv Docker Network

In the Discovery Management Console and Data Management Portal, a DockerSwarm cluster is represented by a blue-colored Docker whale design icon.

The Docker Swarm cluster sensor uses REST APIs to retrieve the discovery relatedinformation from the Docker host ‘Manager’ node running the 'dockerd' daemonprocess/application in ‘Manager’ role. The retrieved data primarily comprises ofattribute data that is required to match naming rules and create valid modelobjects.

Prerequisitesv The Docker daemon/application is running on a target Linux machine.v For successful discovery of Docker Swarm, REST support must be enabled on

the target Docker host machine.v To trigger DSCS, at-least ONE Docker Host in 'Manager' role must be included

in the discovery scope.v At any given time, a given Docker Host may belong to a single swarm cluster

ONLY, i.e. it cannot be part of multiple Docker swarm clusters simultaneously.v Docker swarm cluster sensor is in turn dependent on the discovery performed

by Docker Host sensor. Vis-a-vis, configuration for Docker Swarm Cluster sensoris implicitly derived from Docker Host sensor. For details, see 'Docker HostSensor'Chapter 2, “Docker Host sensor,” on page 29.

v Single set of TLS certificate is applicable for TADDMs communication to all theDocker Host.

v Enable or Disable of TLS for discovery will have a uniform behavior across ALLDocker hosts defined within the scope.o Either applicable to ALL, or, NONE Docker Hosts.


Security issuesv No specific access-list entry is required. For TLS based security details, see

“Connection to Docker Swarm” below:

Connection to Docker Swarm

The Docker Swarm Cluster Sensor discovers data from Docker Host (working in‘Manager’ role) through 2 modes: non-TLS mode, and, TLS mode.

Non-TLS mode

The non-TLS mode is the default mode. It retrieves data via web services anddoesn’t require authentication. This mode is recommended in private network, or,private cloud deployments in customer premises.

TLS mode

The TLS mode is secure mode of communicating with the Docker Host. It verifiesthe TLS certificates installed in TADDM and target Docker Host. To use this mode,you must set the enableTLS property to true, along with configuring the certificatepaths defined in discovery profile. For details, see “Docker Host Sensor:Configuring the discovery profile” . For manually generating the TLS certificatesfor TADDM and Docker host, see Chapter 2, “Docker Host sensor,” on page 29'Configuring the discovery profile'. For manually generating the TLS certificates forTADDM and Docker host, see Chapter 2, “Docker Host sensor,” on page 29 ':Manual TLS certificate generation'.


The Docker Swarm Cluster Sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects aboutDocker Swarm resources in your IT environment.


app.docker.dockerswarm.DockerSwarm

v app.docker.dockerswarm.DockerSwarmv Serversv SwarmServicesv IPv Portv DockerNetwork

app.docker.dockerswarm.SwarmService

v Namev DockerSwarm

app.docker.dockerhost.DockerContainer

v Taskv SwarmService

app.docker.dockerhost.DockerNetwork


v Namev SubnetAddressv DockerHostv DockerContainer

Note: All the Docker Host Sensor model objects are also applicable here, sinceDocker Swarm is a cluster of Docker Host nodes.


Before using the Docker Swarm Cluster Sensor, you must configure it.

Configuring the discovery profile:

Docker swarm cluster sensor is in turn dependent on the discovery performed byDocker Host sensor. Vis-a-vis, configuration for Docker Swarm Cluster sensor isimplicitly derived from Docker Host sensor. For details, see Chapter 2, “DockerHost sensor,” on page 29 :'Configuring the Sensor Profile'.


This topic describes common problems that occur with the Docker Swarm Clustersensor and presents solutions for those problems.

Docker Swarm Cluster Sensor is not invoked on a Docker Host node

Problem : Docker Swarm cluster sensor may not be invoked on a Docker hostnode, in case that node is not currently not having the ‘manager’ role for thatcluster.

Solution : Validate via logfile (DiscoverManager.log) that we are seeing thefollowing traces:

“Either swarm mode is not enabled, or, the Docker host is not currently having managerrole”.

To trigger DSCS, at-least ONE Docker Host in “Manager” role must be included inthe discovery scope.

Chapter 3. Docker Swarm Cluster sensor 39

Chapter 4. DNS sensor

The DNS sensor discovers Domain Name System (DNS) servers.


DnsSensor


The sensor creates the following model object:v Sys.DNSSAP

Troubleshooting the sensorThis topic describes common problems that occur with the DNS sensor andpresents solutions for those problems.

Sensor fails to discover a DNS server

ProblemThe sensor is unable to discover a running DNS server.

SolutionIf the sensor fails to discover a DNS server, verify that the DNS server canresolve IP address 127.0.0.1. The DNS sensor requires the DNS server toresolve 127.0.0.1 and, if the DNS server does not return a value, the sensorfails to recognize the particular DNS server.


Chapter 5. HIS sensor

The HIS sensor discovers a Microsoft Host Integration Server.


HISServerSensor

Prerequisites

Before you run this sensor, the following prerequisites must be met:v The discovery of the Windows Computer System must succeed.v The SNABase service must be running.v Using the TADDM Windows Management Instrumentation (WMI) provider,

WMI read access to the root/microsoftHis namespace must be granted. If thediscovery of the Windows Computer System succeeded, this WMI read access isgranted by default. Administrative-level access is preferable.

Model objects with associated attributesThe HIS sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about Microsoft HostIntegration Server resources in your IT environment.


app.his.HISDomain

v APPCModesv AuditLevelv BroadcastMeanTimev BroadcastProtocolIpxSpxv BroadcastProtocolNamedPipesv BroadcastProtocolTcpIpv ClientBackupDomainNamesv ClientBackupSponsorNamesv ClientDomainBackupTypev ConfigServerv DisplayNamev DisplayVerbConnectionv DomainNamev EventLogServerNamev NetViewConnectionv PopupServerNamev RTMEndOfSessionv RTMOverflowv RTMThreshold


v RTMTimerUntilv Security3270v SecurityAPPCv SecurityLUAv Serversv Status

app.his.HostIntegrationServer

v DisplayNamev Domainv LinkServicesv Namev ProductNamev ProductVersionv ServerRolev Servicesv TransportStringv VendorName

app.his.IPDLCService

v BackupNetworkNameServersv CMDMaxRetryv CPNamev DeviceDriverv DisplayNamev DllNamev IsRemotablev LENNodev LocalAddressAdapterv LocalAddressIPv MaxActivationAttemptsv MaxBTUReceivev MaxBTUSendv Namev Networkv NodeIDv Parentv PrimaryNetworkNameServerv ReceiveAckTimeoutv ResolvedIPv UseDynamicPUDefinition

app.his.APPCMode

v AllowLZandRLEv AutoActivatev DisplayNamev EndPointOnly


v IsPriorityv MaxReceiveCompressionv MaxSendCompressionv MinimumContentionWinnerLimitv Namev Parentv PartnerMinimumContentionWinnerLimitv ReceivePacingv ReceiveRuSizev SessionLimitv TransmitPacingv TransmitRuSize

app.his.HISConnection

v Activationv AllowIncomingv BlockIdv CompressionLevelv DisplayNamev DynamicLuDefv LUsv LinkServicev Namev NodeIdv Parentv PartnerConnectionNamev PeerRolev RemoteBlockIdv RemoteControlPointv RemoteEndv RemoteNetNamev RemoteNodeIdv RetryDelayv RetryLimitv XIDFormat

app.his.HISLUA

v Compressionv DisplayNamev HighPriorityModev Namev Numberv Parentv Protocolv UserWksSecure

app.his.HISLUDisplay

Chapter 5. HIS sensor 45

v AssociatedLUv Compressionv DisplayModelv DisplayModelOverridev DisplayNamev HISServicev Namev Numberv Parentv Protocolv UserWksSecure

app.his.HISLUPrint

v AssociatedLUv Compressionv HISServicev Namev Numberv Parentv Protocolv UserWksSecure

app.his.PrintService

v Accountv ActivationRetryIntervalv ActivationRetryLimitv AlwaysDoNLv CanBePausedv CanBeStoppedv DelayPrintStartv Descriptionv DesktopInteractv DisplayNamev DoAllFFv ErrorControlv ExitCodev FlushFinalFFv IgnoreCharsUnder3Fv Namev NoEventLogOnSkippingTransparentSectionv NoSpaceAfterFFv OperatingStatev Parentv PathNamev Serverv ServiceName


v ServiceSpecificCodev ServiceTypev SoftwareVersionv StartModev Startedv UseFixedTabsv UseProportionalFontChange

app.his.SNAService

v ControlPointv HISConnectionsv Namev NetworkNamev Parentv Server

Configuring the access listThis topic describes the access details that you require, depending on yourconfiguration.

There are no access requirements for this sensor. This sensor can be run using theComputerSystem access credentials that are used to discover the client.

Troubleshooting the sensorThis topic describes common problems that occur with the HIS sensor and presentssolutions for those problems.

WMI service fails on a target during discovery

ProblemThe Windows Management Instrumentation (WMI) service fails on a targetsystem during discovery.

SolutionEnsure that all WMI-related fixes, including fix KB933061, are applied onthe target system. If the problem persists, run the WMI diagnostic toolsfrom Microsoft.

Chapter 5. HIS sensor 47

Chapter 6. IBM Cluster Systems Management sensor

The IBM Cluster Systems Management sensor discovers IBM Cluster SystemsManagement (CSM) High Performance Computing (HPC) clusters.


CSMServerSensor and CSMNodeSensor

Prerequisites

GenericComputerSystemSensor, along with prerequisite sensors, must be enabledin the discovery profile used for discovering the CSM cluster.


The sensor creates the following model objects:v sys.hpc.cm.ConfigurationManagementClusterv sys.hpc.cm.ConfigurationManagementNodev sys.hpc.cm.ConfigurationMangementNodeGroupv sys.hpc.cm.ConfigurationManagementClusterConfigFilev sys.hpc.CSMNode


Configuring the discovery profileThis topic describes how to configure the discovery profile.

To configure the CSMServerSensor, complete the following steps:1. Create a discovery profile and select agent configuration of type

CSMServerAgentConfiguration.2. Set the following required attributes:

masterServerNamesThe IP addresses or host names of CSM master nodes. This propertymust be set to start the CSM server sensor.

3. If appropriate, set the following parameters or accept the default values.

lsNodeCommandThe command used to determine CSM nodes. The default value islsnode.

nodeGrpCommandThe command used to determine CSM nodes in the group. The defaultvalue is nodegrp.

nodeGrpCommandDelimiterThe delimiter between nodes in the nodeGrpCommand. The defaultvalue is ",".


CFMDirectoryLocationThe location of the CFM root directory. The default is /cfmroot.

CFMDiscoveryModeThe depth of file capture of the files and scripts in the CSMconfiguration directories. The valid values are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content is captured.

The default value is 1.

CFMDiscoveryPatternThe file name pattern for files under the CFM root directory. Thedefault value is "*".

preRebootScriptsLocationThe location of the scripts that are run before reboot. The default valueis /csminstall/csm/scripts/installprereboot/.

preRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/installprereboot/ directory.

The default value is "*".

postRebootScriptsLocationThe location of the scripts that are run after reboot. The default value is/csminstall/csm/scripts/installpostreboot/.

postRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/installpostreboot/ directory.


osUpgradePreRebootScriptsLocationThe location of the scripts that are run after the OS is upgraded, butbefore reboot. The default value is /csminstall/csm/scripts/osupgradeprerboot/.

osUpgradePreRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/osupgradeprereboot/ directory.


osUpgradePostRebootScriptsLocationThe location of the scripts that are run after the OS is upgraded, andafter reboot. The default value is /csminstall/csm/scripts/osupgreadepostreboot/.

osUpgradePostRebootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/osupgradepostreboot/ directory.


disklessBootScriptsLocationThe location of the boot scripts for diskless nodes. The default value is/csminstall/csm/scripts/disklessboot/.


disklessBootScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/disklessboot/ directory.


disklessPreBuildScriptsLocationThe location of the pre-build scripts that are run for diskless nodes.

The default value is /csminstall/csm/scripts/disklessprebuild/.

disklessPreBuildScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/disklessprebuild/ directory.


dataScriptsLocationThe location of any additional scripts or data files referenced by thescripts.

The default value is /csminstall/csm/scripts/data/.

dataScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/data/ directory.


updateScriptsLocationThe location of the scripts that are run after any CSM updates havecompleted.

The default value is /csminstall/csm/scripts/update/.

updateScriptsDiscoveryPatternThe file name pattern for files under the /csminstall/csm/scripts/update/ directory.


nodesScopeThe scope of the IP addresses to which the CSM node sensors arerestricted.

doPingNodesSpecifies whether ping sensors are run against discovered CSM nodes.

There are no specific sensor setup requirements associated with theCSMNodeSensor.


CSMServerSensor uses CSM Server access entry. If this access entry is notavailable, the sensor uses ComputerSystem access entry to access the CSM server.

CSMNodeSensor uses ComputerSystem access entry to access CSM nodes.

Chapter 6. IBM Cluster Systems Management sensor 51

Chapter 7. IBM High-Availability Cluster Multi-Processingsensor

The IBM High-Availability Cluster Multi-Processing (HACMP™) sensor discoversHACMP clusters and associated components. The sensor discovers informationabout the cluster, nodes, resource groups, local resource groups, applicationresources, cluster manager, service IP label, shared file system, node networkaddresses, and site information.


HACMPSensor

Prerequisites

The HACMP service and the cluster manager daemon must be running on thetarget computers.

Security issues

Privileges to execute the following commands on the discovered systems arerequired: lssrc, clstat, cltopinfo, clRGinfo, cllsserv, cllsif, cllsfs,clshowres, cllsgrp, get_local_nodename, cllssite.

Limitations

The following limitations apply:v TADDM supports only Apache servers that are running on the HACMP cluster.v Only one application server can run on the HACMP resource group.v When the clstat command, which is used by TADDM to check the status of the

HACMP cluster, fails, the sensor runs the odmget command. However, the scopeof data that is discovered by the odmget command is limited because it does notinclude the state and substate attributes of the HACMP cluster object.

Model objects with associated attributesThe IBM HACMP sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects aboutconfiguration items in the IBM HACMP environment.


HACMPAppResource

v AppServerv LocalAppResourcesv Namev Parent

HACMPCluster

v ClusterID


v ComputerSystemsv ConnAuthModev HeartbeatNetworksv MessageAuthModev MessageEncryptionv Nodesv ResourceGroupsv Statev Substatev UsePersistentLabel

HACMPClusterHeartbeatNetwork

v Namev Netmaskv NetworkElementsv Parentv PrefixLengthv Type

HACMPClusterHeartbeatNetworkElement

v L2Interfacev Namev NetworkAddressv Parentv StorageVolumev Type

HACMPClusterManager

v CurrentStatev HacmpNode

HACMPLocalAppResource

v Nodev Parentv StartScriptv StopScript

HACMPLocalResourceGroup

v LocalStatev Nodev Parent

HACMPNode

v ClusterManagerv LocalAppResourcesv LocalResourceGroupsv Namev NetworkElementsv Parentv SiteInfo


v Statev System

HACMPResourceGroup

v AppResourcesv FallbackPolicyv FalloverPolicyv FileSystemsv GlobalStatev LocalResourceGroupsv Nodesv Parentv PrimaryNodev ServiceIpLabelsv SitePolicyv StartupPolicyv StorageVolumes

ServiceIPLabel

v IpAddressv Namev Parent

SiteInfo

v Name


Configuring the access listThis topic describes the access details that you require.

To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must

use for authentication to the target computer system.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM HACMP sensoruses.

The sensor uses the following entry in the collation.properties file:

com.collation.platform.os.UnixOs.forcedServerList=clstrmgr You must add the attribute clstrmgr to this entry to ensure that the sensorstarts. For example,com.collation.platform.os.UnixOs.forcedServerList=vxconfigd;clstrmgr

Chapter 7. IBM High-Availability Cluster Multi-Processing sensor 55

Troubleshooting the sensorThis topic describes common problems that occur with the IBM HACMP sensorand presents solutions for those problems.

HACMP cluster is duplicated

ProblemA duplicate HACMP cluster might be created in the following scenario:1. A HACMP cluster is discovered.2. The HACMP cluster name is changed in the cluster configuration.3. The HACMP cluster is discovered again.

SolutionTo resolve a situation where a HACMP cluster has been duplicated, usingthe Data Management Portal, delete the copy of the cluster that has the oldcluster name.

Incorrect HACMP version returned

ProblemWhen discovering a HACMP cluster with the IBM HACMP sensor, theproduct version of the HACMP cluster might be incorrectly discovered as"0".

SolutionBecause of an issue in the HACMP, the incorrect cluster version issometimes returned.

To manually check the cluster version, run the following command on oneof the HACMP cluster nodes:ssrc -ls clstrmgrES

In the command output, check the version of the HACMP cluster, forexamplelocal node vrmf is 0

If the correct cluster version is displayed, rediscover the HACMP.

Clstat and cldump commands do not work on nodes directlyinstalled on AIX 6.1

ProblemWhen a HACMP cluster is installed on nodes that are directly installed onAIX 6.1, the clstat and cldump commands do not work.

SolutionDownload the fix for this problem at http://www-01.ibm.com/support/docview.wss?uid=isg1IZ45540.


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

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

Chapter 8. IBM Lotus Domino server sensor

The IBM Lotus® Domino® server sensor discovers Lotus Domino servers.


DominoDomainSensor, DominoServerDetailSensor, and DominoInitialSensor

Prerequisites

On the Lotus Domino system, a user account must be configured with the correctaccess to the resources being discovered. Ensure that the following requirementsare met:v The Internet Inter-ORB Protocol (IIOP) server must be running on at least one

Domino server for each Domino domain.v Add the IP address or the fully qualified domain name (FQDN) of the IIOP

servers to the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.5.0/plugin.xml file. You can append the port number of the Domino IIOP server tothe server name. Adding the port number is optional. Typically, the default portnumber is 63148 for Domino Internet Inter-ORB Protocol (DIIOP). If anonymousaccess is required, the port number is 80 for HTTP.The following example illustrates how to add an IIOP server name:<IIOPServers>

<item><name>example1-server.ibm.com[:Port_number]</name><SSL>false</SSL>

</item><item>

<name>example2-server.ibm.com[:Port_number]</name><SSL>false</SSL>

</item></IIOPServers>

v For each of the IIOP servers, you must have a valid user ID and password.v The user ID on the IIOP server must have read permission to the names.nsf file.v You must specify a discovery scope containing all the server nodes, to obtain

complete information about Domino clusters.v Check the server document in the Domino directory, and ensure that the user ID

has access enabled for the security settings:– Access Server– Run restricted LotusScript/Java agents

On the Lotus Domino system, a user account must be configured with thecorrect access to the resources being discovered, for example, files and databases.

v For TADDM to connect to a Domino IIOP server using SSL, you must set theosgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.5.0/plugin.xml file to true. Then, you must copy the TrustedCerts.class file to the$COLLATION_HOME/etc/domino_trusted directory on the TADDM server. TheTrustedCerts.class file is located in the domino data folder/domino/javafolder.


v Issue the show task command in the Domino console to determine if the DIIOPtask is running.

v If the DIIOP task is not running, issue the load diiop command using theDomino console to load the DIIOP task.

v Issue the tell diiop show config command to check the configuration.

If you update the plugin.xml file, you must restart the TADDM server for thechanges to take effect.


The sensor creates the following model objects:v app.lotus.AgentManagerv app.lotus.AdminProcessv app.lotus.DirectoryAssistancev app.lotus.DirectoryCatalogerv app.lotus.DomainCatalogv app.lotus.DominoClusterv app.lotus.DominoConnectionv app.lotus.DominoDatabasev app.lotus.DominoDomainv app.lotus.DominoNamingContextv app.lotus.DominoReplicasv app.lotus.DominoSecurityv app.lotus.DominoServerv app.lotus.DominoTransactionLoggingv app.lotus.HTTPFilterSpecialtyServerv app.lotus.IIOPConfigv app.lotus.IMAPConfigv app.lotus.InternetClusterManagerv app.lotus.LDAPConfigv app.lotus.OtherDatabasev app.lotus.POPConfigv app.lotus.RemoteDebugManagerv app.lotus.SMTPConfigv app.lotus.SpecialityServerv app.lotus.WebConfigv app.lotus.WebRetriever

Asynchronous and script-based discovery supportThe IBM Lotus Domino server sensor supports asynchronous and script-baseddiscovery. Also, in a nonscript-based discovery, the Lotus Domino server sensor isnot supported on the Solaris operating system, but in an asynchronous or ascript-based discovery, the sensor is supported on the Solaris operating system.







For script-based discovery, the computer system access list entry is used to readthe Lotus Domino configuration file. An application access list entry for the LotusDomino server is not needed.

Limitations

Most function that is provided by the Lotus Domino server sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

In an asynchronous or script-based discovery, only the Version attribute issupported.


Configuring the access listTo give the IBM Lotus Domino server sensor access to the Lotus Domino server,you must configure the access list.

To configure the access list, complete the following steps:1. From the Discovery Management Console, create a discovery scope set that

contains the IP address of the Lotus Domino server.2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click Messaging

servers.5. In the Vendor field of the Access Details window, click Domino.6. Type the credentials to access the target Lotus Domino server.

You must also have an access list entry and credentials for Windows systems. TheSession sensor creates a session between the TADDM server and the targetcomputer systems before the IBM® Lotus® Domino® server sensor discovery run.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Lotus Dominoserver sensor and presents solutions for those problems.

The sensor does not start

ProblemIf the Domino Internet Inter-ORB Protocol (DIIOP) is not running or theplugin.xml file is not correctly configured, the sensor does not start or itfails.

Solution

Chapter 8. IBM Lotus Domino server sensor 59

v Check the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.lotus.dominoserverinitial_7.5.0/plugin.xml file to ensure that it is configured correctly. If you update theplugin.xml file, you must restart the TADDM server for the changes totake effect.

v Using the Domino Console, run the following commands:– load diiop

– show tasks

The sensor does not start if the notes.ini file cannot be accessed

ProblemFor AIX operating systems, if the notes.ini file is not found in theprocessing environment the sensor does not start.

SolutionThe user ID carrying out the discovery does not have access to the processenvironment due to security issues. Check the following entry in thecollation.properties file:com.collation.platform.os.command.psEnv.AIX

If required, add the sudo command to set the file access permissions.


Chapter 9. IBM Tivoli Monitoring Scope sensor

Using the credentials for the Tivoli Enterprise Portal Server rather than thecredentials for each computer that the portal server monitors, the IBM TivoliMonitoring Scope sensor discovers configuration items in the IBM TivoliMonitoring environment.

The IBM Tivoli Monitoring Scope sensor provides the following discoverycapability:v Provides basic discovery of Tivoli Monitoring endpoints, similar to a standard

TADDM Level 1 discovery. The sensor discovers IP addresses, MAC addresses,and the operating system type for each computer system that is managed byTivoli Monitoring.

v Creates special scope sets for all Tivoli Monitoring endpoints that it discovers sothat all future TADDM Level 2 (and some Level 3) discoveries can be runwithout needing access credentials for the Tivoli Monitoring endpoints.

Also see the TADDM Administrator's Guide for information about configuring fordiscovery using IBM Tivoli Monitoring.


ITMScopeSensor and ITMScopeSensor-x.xx.xxx.xxx.log, where x.xx.xxx.xxxrepresents the IP address of the discovered system.

The IBM Tivoli Monitoring Scope sensor also logs information tolocal-anchor.hostname.ITMScopeSensor.log, where hostname represents the hostname of the TADDM server.

Prerequisites

For a monitored computer system to be stored in the TADDM database, IBM TivoliMonitoring must provide the computer system IP and MAC addresses in responseto queries from the sensor.

Limitations

Discovery using the Tivoli Monitoring Scope sensor causes the followingperformance impacts in the Tivoli Monitoring environment:v An increase in CPU usage on the Tivoli Enterprise Portal Server and the Tivoli

Enterprise Monitoring Serverv An increase in network utilizationv If two or more TADDM servers simultaneously perform discovery against one

Tivoli Monitoring server, Tivoli Monitoring discovery is not successful.

These performance impacts are present for the duration of the discovery and mightalso affect the performance of the Tivoli Monitoring functions, depending on theTivoli Monitoring hardware that is used.

The sensor does not discover hosts on a private network that uses network addresstranslation (NAT).


Model objects with associated attributesThe IBM Tivoli Monitoring Scope sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout configuration items in the IBM Tivoli Monitoring environment.


net.IpInterface

v IpAddress

Multiple computer systems, with the following model objects:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystem

sys.linux.LinuxUnitaryComputerSystem sys.sun.Solaris sys.sun.SunSPARCUnitaryComputerSystem sys.UnitaryComputerSystem

sys.windows.WindowsComputerSystemsys.zOS.ZSeriesComputerSystem

The following attributes are associated with these model objects:v Fqdnv Ipinterfacev Namev OSInstalledv OSRunningv Signaturev Type

Multiple operating systems, with the following model objects:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.sun.Solarissys.zOS.Sysplexsys.unix.Unixsys.windows.WindowsOperatingSystemsys.zOS.ZOS

The following attributes are associated with these model objects:v Namev ManagedSystemNamev OSVersion

Configuring the sensorBefore running a discovery of the IBM Tivoli Monitoring environment, you mustconfigure the IBM Tivoli Monitoring Scope sensor.


Copying necessary files from the Tivoli Enterprise PortalServer to the TADDM server

You must copy some files from the Tivoli Enterprise Portal Server to the TADDMserver.

In a streaming server deployment, perform these steps on the discovery server, ifyou are configuring the sensor for the first time. You do not complete thisprocedure if you already copied the files from the Tivoli Enterprise Portal Server tothe TADDM server in version 7.2.1.x and you upgraded to version 7.2.2 or later.1. On the TADDM server, verify that the $COLLATION_HOME/lib/itm directory

exists.2. Copy the following files from the Tivoli Enterprise Portal Server into the

$COLLATION_HOME/lib/itm directory on the TADDM server:v browser.jar

v cnp.jar

v cnp_vbjorball.jar

v kjrall.jar

v util.jar

v tap_cli.jar

On Windows systems, copy the files from the ITM_INSTALLATION_DIR\CNB\classes directory.On Linux and UNIX systems, copy the files from the ITM_INSTALLATION_DIR/classes directory.

3.

Note: Skip this step if you're integrating with ITM 6.3 or later.Copy the cfwk.zip from the Tivoli Enterprise Portal Server into the$COLLATION_HOME/lib/itm directory on the TADDM server.On Windows systems, copy the file from the ITM_INSTALLATION_DIR\GSK7\classes directory.On Linux and UNIX systems, copy the file from the ITM_INSTALLATION_DIR/ARCH/gs/classes directory.

4. On Linux and UNIX systems, use the following command to set the user andgroup of the previously copied files to the user and group that is used to runthe TADDM server:chown -R taddmuser:taddmuser $COLLATION_HOME/lib/itm

5. Restart the TADDM server.

Distributing the discovery target support bundleDuring the discovery process, TADDM must copy binary file data between itselfand the discovery target using IBM Tivoli Monitoring as an intermediary. ForWindows discovery targets, the discovery target support enables binary files to becopied from TADDM to the discovery target as part of the discovery process. Thediscovery target support bundle also provides part of the Windows gateway on thetarget so that the gateway is available during discovery. This method prevents youfrom having to deploy a separate Windows discovery gateway within your TivoliMonitoring environment. The discovery target support bundle is not required onLinux, AIX, Solaris, and HP-UX operating systems.

Before the first discovery from TADDM, the discovery target support bundle mustbe deployed onto each Tivoli Monitoring Windows operating system endpoint. The

Chapter 9. IBM Tivoli Monitoring Scope sensor 63

bundle has a small footprint and is designed to be non-intrusive and used onlyduring a TADDM discovery. If you are performing a Level 1 discovery, this task isnot required.

You must distribute the support bundle to the Windows discovery targets throughthe Tivoli Enterprise Monitoring Server depot. The support bundle must also beloaded into any remote Tivoli Enterprise Monitoring Server depots that exist inyour Tivoli Monitoring environment.

In addition to deploying the discovery target support bundle, you must ensure thateach Tivoli Monitoring endpoint is configured for discovery. For example, eachUNIX-based endpoint must have the LiSt Open Files (lsof) program installed. Formore information, see the TADDM Administrator's Guide.

On the TADDM DVD, the support bundle is in the KD7.zip or KD7_621.zip file inthe /itm-discovery-support directory. Depending on the version of TivoliEnterprise Monitoring Server, distribute the appropriate support bundle. For IBMTivoli Monitoring Version 6.2.1-TIV-ITM-FP0001 or later, distribute the supportbundle in KD7_621.zip. For IBM Tivoli Monitoring Version 6.2.2-TIV-ITM-FP0002 orlater, distribute the support bundle in the KD7.zip.

To distribute the support bundle to the discovery targets, complete the followingsteps:1. Extract the appropriate support bundle file KD7.zip or KD7_621.zip file into a

directory on the Tivoli Enterprise Monitoring Server. For example, the C:\TEMPdirectory on Windows and /tmp on Linux or UNIX system.

2. To add the support bundle to the Tivoli Enterprise Monitoring Server depot,run the tacmd command, as shown in the following sample. To suppress theconfirmation, use the -f option.

On Windows operating system:C:\IBM\ITM\bin>tacmd login -u sysadmin -p mypassword -s localhost

Validating user...

KUIC00007I: User sysadmin logged into server on https://localhost:3102.C:\IBM\ITM\bin>tacmd addBundles -i C:\TEMP\KD7\072200000

KUICAB023I: Are you sure you want to add the following bundlesto the C:\IBM\ITM\CMS\depot\ depot?

Type : ComponentProduct Code : d7Deployable : trueVersion : 072200000Description : TADDM Discovery through ITM enablementHost Type : WINNTHost Version : WINNTPrerequisites:

KUICAB024I: Enter Y for yes or N for no: y

KUICAB020I: Adding bundles to the C:\IBM\ITM\CMS\depot\ depot.The time required to complete this operation depends on the numberand size of the added bundles.

KUICAB022I: The following bundles were successfully added to the C:\IBM\ITM\CMS

On Linux or UNIX operating system:[root@localhost bin]# /opt/IBM/ITM/bin/tacmd login -s localhost -u sysadmin -p "mypassword"

Validating user...

KUIC00007I: User sysadmin logged into server on https://localhost:3661.[root@localhost bin]# /opt/IBM/ITM/bin/tacmd addBundles -i /tmp/KD7/072200000/

KUICAB023I: Are you sure you want to add the following bundlesto the /opt/IBM/ITM/tables/TEMS/depot depot?

Type : ComponentProduct Code : d7Deployable : true


Version : 072200000Description : TADDM Discovery through ITM enablementHost Type : WINNTHost Version : WINNTPrerequisites:

KUICAB024I: Enter Y for yes or N for no: y

KUICAB020I: Adding bundles to the /opt/IBM/ITM/tables/TEMS/depotdepot. The time required to complete this operation dependson the number and size of the added bundles.

KUICAB022I: The following bundles were successfully added to the/opt/IBM/ITM/tables/TEMS/depot depot:

3. To obtain the managed system names for the Windows operating systems, usethe tacmd listSystems -t NT command. For more information about the tacmdlistSystems -t NT command, see tacmd CLI commands at:http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.2/com.ibm.itm.doc_6.2.2fp2/tacmd.htm.

4. To distribute the support bundle from the Tivoli Enterprise Monitoring Serverto the discovery targets, log in to the Tivoli Enterprise Monitoring Server, andrun the tacmd command, as shown in the following sample:

On Windows operating system:C:\IBM\ITM\bin>tacmd login -u sysadmin -p mypassword -s localhostValidating user...KUIC00007I: User sysadmin logged into server on https://localhost:3102.C:\IBM\ITM\bin>tacmd addsystem -t d7 -n Primary:OMPDEV2:NTKUICAR010I: The agent type d7 is being deployed.KUICAR028I: The operation has been successfully queued for deployment, the transactionid is 121969167781300000018467, use the getDeployStatus CLI to view the status.

On Linux or UNIX operating system:[root@localhost bin]# /opt/IBM/ITM/bin/tacmd login -s localhost -u sysadmin -p "mypassword"

Validating user...

KUIC00007I: User sysadmin logged into server on https://localhost:3661.[root@blueronin bin]# /opt/IBM/ITM/bin/tacmd addsystem -t d7 -n Primary:OMPDEV2:NT

KUICAR010I: The agent type d7 is being deployed.

KUICAR028I: The operation has been successfully queued for deployment,the transaction id is 1255360658461460000354687074,use the getDeployStatus CLI to view the status.

5. Check the status of deployment by entering the tacmd getDeployStatuscommand. For example:C:\IBM\ITM\bin>tacmd getdeploystatus -g 121969167781300000018467

Transaction ID : 121969167781300000018467Command : INSTALLStatus : SUCCESSRetries : 0TEMS Name : HUB_TEMSTarget Hostname: Primary:OMPDEV2:NTPlatform : WINNTProduct : D7Version : 072200000Error Message : KDY0028I: Request completed successfully. Deploymentrequest was processed successfully and is now completed.

Installing custom queries on the Tivoli Enterprise PortalServer

For both Level 1 and Level 2 discovery through IBM Tivoli Monitoring, you mustinstall custom queries on the Tivoli Enterprise Portal Server to support the lookupof managed system MAC addresses and agent versions by the IBM TivoliMonitoring Scope sensor.

On the TADDM DVD, the custom queries are in the TEPS_Query.zip file in the/itm-discovery-support directory. The custom queries are defined in theinstall_zkd7.sql file.


http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.2/com.ibm.itm.doc_6.2.2fp2/tacmd.htm

http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.2/com.ibm.itm.doc_6.2.2fp2/tacmd.htm

These queries return the following information:v Version number of the agent on each endpointv MAC address of each Linux endpointv Operating system name and version of each endpoint

To install the custom queries on the Tivoli Enterprise Monitoring Server, completethe following steps:

Installing on Linux operating system:

1. Log in to the Tivoli Enterprise Portal Server, and copy theTEPS_Query.zip file to a local directory.In these instructions, the TEPS_Query.zip file is copied to the /tmp/tepsdirectory and extracted. The install_zkd7.sql and uninstall_zkd7.sqlfiles are then located in the /tmp/teps directory.

2. Install the custom queries:/opt/IBM/ITM/bin/itmcmd execute cq"/opt/IBM/ITM/li6263/cq/bin/KfwSQLClient -d KFW_DSN–f /tmp/teps/install_zkd7.sql"

3. Stop the Tivoli Enterprise Portal Server:/opt/IBM/ITM/bin/itmcmd agent stop cq

4. Start the Tivoli Enterprise Portal Server:/opt/IBM/ITM/bin/itmcmd agent start cq

Installing on Windows operating system:

1. Log in to the Tivoli Enterprise Portal Server, and copy theTEPS_Query.zip file to a local directory.In these instructions, the TEPS_Query.zip file is copied to thec:\TEMP\TEPS directory and extracted. The install_zkd7.sql anduninstall_zkd7.sql files are then located in the c:\TEMP\TEPS directory.

2. Change to the directory where the Tivoli Enterprise Portal Server isinstalled:cd c:\IBM\ITM\CNPS

3. Install the custom queries:.\kfwsqlclient.exe /d KFW_DSN /f c:\TEMP\TEPS\install_zkd7.sql

4. From the Tivoli Monitoring Services window, restart the TivoliEnterprise Portal Server.

Configuring the discovery profileBy default, the IBM Tivoli Monitoring Scope sensor is not enabled. After youenable it, TADDM discovers Tivoli Monitoring endpoints and creates a scope set.The scope set contains the discovered endpoints and uses the default TivoliEnterprise Portal Server ports 1920 and 15001. However, by default, computersystem objects are not created for the Tivoli Monitoring endpoints. If you want tocreate computer system objects for each discovered endpoint or to use TivoliEnterprise Portal Server ports other than the default ports, create a new Level 1 orLevel 2 discovery profile for the IBM Tivoli Monitoring Scope sensor, andcustomize the sensor settings.

To create the discovery profile, complete the following steps:1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, click New.


3. In the Create New Profile window, type the profile name and description. Inthe Clone existing profile field, click Level 1 Discovery or Level 2 Discovery,and click OK.

4. In the list of sensors, click ITMScopeSensor, and click New.5. In the Create Configuration window, type the name and description for your

configuration of the ITMScopeSensor, and select the Enable Configurationcheck box.

6. In the Configuration section of the Create Configuration window, to define aset of ports to look for the Tivoli Enterprise Portal Server, click portList. Thendouble-click the Value field in the row, and type each port number value,separating each value with a comma.

7. To configure the sensor not to use port 1920, click useDefaultPortList. Thendouble-click the Value field in the row, and type false.The default value for useDefaultPortList is true. If a port list is provided anduseDefaultPortList is set to true, port 1920 is added to the list of ports tolook for the Tivoli Enterprise Portal Server.

8. To create computer system objects that display in the discovered componentstree during a discovery, click discoverITMEndpoints. Then double-click theValue field in the row, and type true.If you do not want to create computer system objects during a discovery,either do not type anything in the field, or type false.


Discovering endpoints behind firewallsThe IBM Tivoli Monitoring Scope sensor supports the Tivoli Monitoring endpointsthat are behind a firewall.

Procedure1. Run a Level 1 discovery of your ITM environment to create the

itmserver.properties file.2. Include the sensor in your profile and set the startSessionOnly parameter to

true in the configuration options.

Results

The sensor checks whether the IP address from the original scope is managed byITM, and runs a session sensor. The sensor uses the ITM session only if it isallowed and preferred for the host.

Restriction: The startSessionOnly parameter has a priority over all otherconfiguration options. If enabled, the sensor does not start any other operations.

Configuring the access listTo give the IBM Tivoli Monitoring Scope sensor access to the Tivoli EnterprisePortal Server application, you must configure the access list.


contains your Tivoli Enterprise Portal Server, or use an existing scope thatcontains your Tivoli Enterprise Portal Server.

2. To create an access list, click the Access List icon.


3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click Integration.5. In the Vendor field of the Access Details window, click IBM Tivoli Monitoring.6. Type the credentials for the Tivoli Enterprise Portal Server. Use the credentials

that are required to log in to the Tivoli Enterprise Portal Server rather than thecredentials for the computer on which the Tivoli Enterprise Portal Serverresides.

Uninstalling the sensorTo uninstall the IBM Tivoli Monitoring Scope sensor configuration components,you must complete several steps.

Deleting access list entriesFrom the Discovery Management Console, delete each IBM Tivoli Monitoringaccess list entry.

To delete an access list entry, complete the following steps:1. From the Discovery Management Console, delete any discovery scope sets that

contain your Tivoli Enterprise Portal Server.2. To delete an access list, click the Access List icon.3. In the Access List window, select each IBM Tivoli Monitoring access list, and

click Delete for each one.

Deleting discovery profilesFrom the Discovery Management Console, delete each IBM Tivoli Monitoringdiscovery profile.

To delete a discovery profile, complete the following steps:1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, select each of the discovery profiles created

for the IBM Tivoli Monitoring, and click Delete.

Uninstalling custom queries on the Tivoli Enterprise PortalServer

To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you mustuninstall custom queries on the Tivoli Enterprise Portal Server.

The custom queries can be removed by running the uninstall query,uninstall_zkd7.sql. On the TADDM DVD, this query is in the TEPS_Query.zip filein the /itm-discovery-support directory.

To uninstall the custom queries on the Tivoli Enterprise Portal Server, complete thefollowing steps:

Uninstall on Linux operating system:

1. Log in to the Tivoli Enterprise Portal Server, and copy theTEPS_Query.zip file to a local directory.In these instructions, the TEPS_Query.zip file is copied to the /tmp/tepsdirectory and extracted. The uninstall_zkd7.sql file is then located inthe /tmp/teps directory.

2. Run the uninstall query:


/opt/IBM/ITM/bin/itmcmd execute cq"/opt/IBM/ITM/li6263/cq/bin/KfwSQLClient -d KFW_DSN–f /tmp/teps/uninstall_zkd7.sql"

3. Stop the Tivoli Enterprise Portal Server:/opt/IBM/ITM/bin/itmcmd agent stop cq

4. Start the Tivoli Enterprise Portal Server:/opt/IBM/ITM/bin/itmcmd agent start cq

Uninstall on Windows operating system:

1. Log in to the Tivoli Enterprise Portal Server, and copy theTEPS_Query.zip file to a local directory.In these instructions, the TEPS_Query.zip file is copied to thec:\TEMP\TEPS directory and extracted. The uninstall_zkd7.sql file isthen located in the c:\TEMP\TEPS directory.

2. Change to the directory where the Tivoli Enterprise Portal Server isinstalled:cd c:\IBM\ITM\CNPS

3. Run the uninstall query (supports all platforms):.\kfwsqlclient.exe /d KFW_DSN /f c:\TEMP\TEPS\uninstall_zkd7.sql

4. From the Tivoli Monitoring Services window, restart the TivoliEnterprise Portal Server.

Removing the discovery target support bundleTo uninstall the IBM Tivoli Monitoring Scope sensor configuration, you mustremove the target support bundle on the Tivoli Enterprise Monitoring Serverdepots.

On the TADDM DVD, the support bundle is in the KD7.zip file in the/itm-discovery-support directory.

To remove the support bundle from the agent depot, follow these steps:1. Extract the KD7.zip file into a directory on the Tivoli Enterprise Monitoring

Server (for example, the C:\TEMP directory).2. To remove the support bundle from the discovery targets, log in to the Tivoli

Enterprise Monitoring Server. Run the tacmd command, as shown in thefollowing sample. Provide the product code (D7) using the -t option, and themanaged system where the bundles are to be removed using the -n option.tacmd removesystem -t D7 -n Primary:Sirius:NT

3. To remove the support bundle from the Tivoli Enterprise Monitoring Serverdepot, run the tacmd command, as shown in the following sample. Provide thepath to the directory where the installable bundles are located, using the -ioption.tacmd removeBundles -i C:\TEMP\KD7\072200000

Deleting the Tivoli Enterprise Portal Server files from theTADDM server

To uninstall the IBM Tivoli Monitoring Scope sensor configuration, you must deletethe files that were copied from the Tivoli Enterprise Portal Server to the TADDMserver.

To delete the files copied from the Tivoli Enterprise Portal Server, complete thefollowing steps:


1. On the TADDM server, delete the $COLLATION_HOME/lib/itm directory.2. Restart the TADDM server.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Tivoli MonitoringScope sensor and presents solutions for those problems.

Computer systems that are outside of the defined scope arecreated

ProblemDuring a discovery, some computer systems that are outside of the definedscope are created.

SolutionIf the discoverITMEndpoints attribute in the discovery profile for thissensor is set to true, the sensor, during a discovery, creates a computersystem for each Tivoli Monitoring endpoint that is known to the TivoliEnterprise Portal Server. This creation occurs even if an endpoint is outsideof the initial discovery scope that included the portal server.

Updates made to the generated Tivoli Monitoring scope usingthe Discovery Management Console are overwritten

ProblemUpdates that have been made to the generated Tivoli Monitoring scope inthe previous discovery using the Discovery Management Console areoverwritten.

SolutionDuring a Level 1 discovery, a new scope is created based on the name ofthe Tivoli Enterprise Portal Server. This scope is overwritten the next timethat the portal server is discovered during a Level 1 or Level 2 discovery.

To change the generated Tivoli Monitoring scope, create a scope with adifferent name that contains the elements of the generated scope.

In a large Tivoli Monitoring environment, the sensor fails with atimeout error

ProblemIn a large Tivoli Monitoring environment, the Tivoli Monitoring Scopesensor fails with a timeout error.

SolutionIn the etc/collation.properties file, edit the following property, wherevalue is the number of milliseconds allowed for the sensor to run (forexample, 60000 is 1 minute):com.collation.discover.agent.ITMScopeSensor.timeout=value

The sensor fails with a timeout error when slow network links ormany router hops exist between the target systems and theTivoli Enterprise Portal Server or TADDM

ProblemThe Tivoli Monitoring Scope sensor fails with a timeout error. Slow


network links or many router hops exist between the target systems andthe Tivoli Enterprise Portal Server or TADDM. The environment includesWindows, Linux, and UNIX systems.

SolutionThis problem is caused by TCP buffer settings. Because the buffer sizes aresometimes too small, poor performance occurs with the TADDM sensorsand the Tivoli Enterprise Portal Server.

To solve this problem, complete the following steps, depending on theoperating system:

On AIX systems:

1. Run the following commands:/usr/sbin/no -o tcp_sendspace=32768/usr/sbin/no -o tcp_recvspace=32768


On Linux systems:

1. Edit the /etc/sysctl.conf file with the following settings:# increase TCP maximum buffer size

net.core.rmem_max = 16777216net.core.wmem_max = 16777216

# increase Linux autotuning TCP buffer limits

# min, default, and maximum number of bytes to usenet.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216

2. Run sysctl -p to read in and set the new values.3. Restart the TADDM server.

On Solaris systems:

1. Run the following commands:/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768


Error message results from running the tacmd getDeployStatuscommand after deploying the discovery target support bundle

ProblemOne or more of the following messages result from running the tacmdgetDeployStatus command after deploying the discovery target supportbundle:v Error Message: KDY1024E: The command /opt/IBM/ITM/bin/CandleAgent

-h /opt/IBM/ITM start d7 did not start or stop agent.The command returned a return code.

v Error Message: KDY1008E: The agent action INSTALL failed witha return code of for product code d7. The command/opt/IBM/ITM/tmaitm6/aix526/bin/kdy_xa -setCMS d7 produced thefollowing error text: <Variable formatSpec="{4}">stdErrText</Variable>. The specified return code was received fromthe two-way translator.

v Error Message: KDY1024E: The agent failed to respond to thecommand C:\itmagent\installITM\Batch\kincli -startagent -akd7did not start or stop agent. The command returned afailure return code.

SolutionThese messages do not indicate actual errors, because the discovery target


support bundle is not intended to respond to the agent start or stopcommand. The Tivoli Monitoring cinfo command also does not list thesupport bundle, because the support bundle is an addition to the existingOS agent.

Verify that the discovery target support bundle is correctly installed on thediscovery target. From the Tivoli Monitoring directory on the targetcomputer, run the directory command as shown in the following example:C:\Documents and Settings\Administrator>cd %CANDLEHOME%

C:\IBM\ITM>dir taddmVolume in drive C has no label.Volume Serial Number is B81D-9114

Directory of C:\IBM\ITM\taddm

09/24/2010 06:38 PM <DIR> .09/24/2010 06:38 PM <DIR> ..09/24/2010 06:38 PM 6,656 Base64.exe09/24/2010 06:38 PM 1,960 KD7WINNT.dsc09/24/2010 06:38 PM 1,363 post.bat09/24/2010 06:38 PM 4,280 pre.bat09/24/2010 06:38 PM 249,856 TaddmTool.exe09/24/2010 06:38 PM 474,624 TaddmTool.pdb09/24/2010 06:38 PM 569,344 TaddmWmi.dll09/24/2010 06:38 PM 106,496 TaddmWmi.exe09/24/2010 06:38 PM 1,424 TaddmWmi.mof09/24/2010 06:38 PM 2,968,576 TaddmWmi.pdb

10 File(s) 4,384,579 bytes2 Dir(s) 10,931,712,000 bytes free

The discovery support bundle files must be present in the%CANDLE_HOME%\taddm directory.

When running the sensor for a Level 2 discovery on Windowstarget systems, multiple command windows open on thecomputer where the Tivoli Enterprise Portal Server is running

ProblemWhen you run the IBM Tivoli Monitoring Scope sensor for a Level 2discovery on Windows target systems, multiple command windows openon the computer where the Tivoli Enterprise Portal Server is running.

SolutionThe IBM Tivoli Monitoring Windows OS Agent is probably configured torun as a system service, and the option Allow Service to Interact withDesktop is enabled. Complete the following steps to correct this problem:1. Right-click the agent in the Manage Tivoli Monitoring Services

program.2. Click Change Startup.3. In the “Log on As” pane of the window that opens, clear the Allow

Service to Interact with Desktop check box.4. Click OK.5. Again, right-click the agent in the Manage Tivoli Monitoring Services

program.6. Click Recycle.


Temporary files are in the log directory of the target system

ProblemDuring a Level 2 discovery through IBM Tivoli Monitoring, somecommands fail on endpoints, which causes multiple KD7* files orsession_script*.bat files to be in the log directory of the target system.These files might also be present for other reasons, such as a discovery thatended prematurely or a problem with the Tivoli Monitoring agentconnection to the Tivoli Enterprise Monitoring Server.

SolutionThe administrator can remove these files manually at any time thatdiscovery is not running. Removing these files during a discovery cancause discovery to fail.

Trailing white spaces exist in the output from discovery targets

ProblemIf you create custom server templates that run under the IBM TivoliMonitoring Scope sensor, trailing white spaces (such as newline charactersor carriage returns) might exist in the output from discovery targets.

SolutionTo ensure that custom server templates provide the same output whenused with the Tivoli Monitoring Scope sensor, remove white spaces in theserver-side logic of the custom server template.

After upgrading IBM Tivoli Monitoring, errors occur duringdiscovery

ProblemAfter upgrading IBM Tivoli Monitoring, errors might occur duringdiscovery for the following reasons:v A result of updates to the Tivoli Monitoring libraries or agent tablesv A result of updates to the TADDM discovery logic

SolutionIf the errors result from updates to the Tivoli Monitoring libraries or agenttables, redo the following tasks:v “Copying necessary files from the Tivoli Enterprise Portal Server to the

TADDM server” on page 63v “Installing custom queries on the Tivoli Enterprise Portal Server” on

page 65

If the errors result from updates to the TADDM discovery logic, redo thefollowing tasks:v “Copying necessary files from the Tivoli Enterprise Portal Server to the

TADDM server” on page 63v “Distributing the discovery target support bundle” on page 63v “Installing custom queries on the Tivoli Enterprise Portal Server” on

page 65v “Configuring the discovery profile” on page 66v “Configuring the access list” on page 67

If none of the above solutions works, make sure that thecom.ibm.cdb.discover.ITM.https.strictChecking property in thecollation.properties file is set to false. By default, this property is notadded to the collation.properties file, which means that its default value


is false. This property is used only with the SSL session. If you set it totrue, the connection host name must match the certificate host name.Otherwise, the discovery fails.

Errors occur during discovery of a Tivoli Monitoring 6.2.2environment

ProblemDuring the discovery of a Tivoli Monitoring Version 6.2.2 environment, theTivoli Enterprise Monitoring Server might shut down unexpectedly,resulting in the following TADDM error messages:v CTJTD0203E The Computer System agent cannot retrieve the host

and IP information for the following computer systemv CTJTD3000E Starting - An error occurs and the sensor timed out

SolutionVerify that the Tivoli Enterprise Monitoring Server process on the TivoliMonitoring server is running, and if necessary, restart the Tivoli EnterpriseMonitoring Server. This process might shut down unexpectedly due to toomany proxy requests, which is related to a known problem with TivoliMonitoring 6.2.2. For more information, see Tivoli Monitoring APARIZ52960.2.

Tivoli Monitoring scope does not include all endpoints definedon the Tivoli Enterprise Portal Server

ProblemThe Tivoli Monitoring scope created during a discovery does not includeall the endpoints that are defined on the Tivoli Enterprise Portal Server.

SolutionInactive endpoints and endpoints for which MAC addresses cannot beresolved are not included in a created scope set.

Targets are discovered by IBM Tivoli Monitoring session but notby SSH or WMI during a Level 2 discovery

ProblemWhen an endpoint is discovered by the IBM Tivoli Monitoring Scopesensor, future Level 2 discoveries use Tivoli Monitoring for discovery bydefault. A direct connection (SSH or WMI) is not used. This method isused even if the IBM Tivoli Monitoring Scope sensor is not included in thediscovery profile.

SolutionTo discover the endpoint through SSH or WMI, define the followingproperty in the collation.properties file:com.ibm.cdb.session.allow.ITM.endpoint_ip_address=false.

See the TADDM Administrator's Guide for information about how to modifyproperties that affect how TADDM discovers Tivoli Monitoring endpoints.

Too many active report queries on the Tivoli Enterprise PortalServer

ProblemThe following informational message is generated in theSessionSensor.log file:KFWITM460E: Too many active report queries from client IPAddress;exceeding limit at number requests.


SolutionIncrease the maximum number of pending requests. Edit the configurationsettings on the Tivoli Enterprise Portal Server, on Windows operatingsystems edit the KFWENV file, and on Linux or UNIX operating systems editthe cq.ini file with the following settings:KFW_REPORT_REQUEST_LIMIT_MAX=100KFW_REPORT_REQUEST_LIMIT=30KFW_REPORT_REQUEST_LIMIT_DURATION=300

The KFW_REPORT_REQUEST_LIMIT property specifies the normal limit ofpending requests to the Tivoli Enterprise Portal Server from a single client.The KFW_REPORT_REQUEST_LIMIT_MAX specifies a temporary maximum limitof pending requests that can exceed the KFW_REPORT_REQUEST_LIMIT, onlyallowable during a burst of time defined by theKFW_REPORT_REQUEST_LIMIT_DURATION (in seconds).


Chapter 10. IBM WebSphere sensor

The IBM WebSphere® sensor discovers IBM WebSphere Application Server nodeinformation, cell information, and version information.

TADDM captures all the configuration files and configuration information from theWebSphere Network Deployment Manager system. If changes are made to the fileson the Deployment Manager System, they might not be the same on the actualdistributed node system. This difference can be caused by the time taken to updatethe file changes on the distributed node system. Therefore, a configuration changethat is flagged on a distributed node might not reflect what is actually on thedistributed node.

The WebSphere Application Server sensor runs in its own Java™ virtual machine(JVM). Therefore, the sensor can customize the runtime path to prevent a conflictwith other TADDM processes.


WebSphereCellSensor, WebSphereJDBCDriverSensor, WebSphereNodeSensor,WebSphereVersionSensor, and WebSphereScriptSensor.

Prerequisites

For IBM WebSphere JDBC driver discoveries, ensure that the followingprerequisites are met:v You must have permission to run the JVM embedded in the WebSphere

Application Server installation.v You must have permission to run the setupCmdLine script that is embedded in

the WebSphere Application Server installation.v You must have permission to read the JDBC driver JAR files.

Limitations

The following limitations apply:v For discovery using IBM Tivoli Monitoring, TADDM supports only script-based

discovery for the WebSphere sensor.v JDBC connections that use native DB aliases configured in native DB clients are

not supported.v Distributed WebSphere servers cannot be discovered on their own. The

discovery is done from the dmgr (cell manager). To discover this machine, itmust be in the discovery scope. If it is not in the discovery scope, thelocal-anchor log shows the following messages:CTJTD1121W verifyStandaloneServer() determined cell to be distributed(DISTRIBUTED), terminating discoveryCTJTD1116W Terminating discovery of managed server/nodeagent <SERVER NAME>- discovery will be handled at cell level

v The JVM runtime information that is the Java version and publisher name isdiscovered for each server that is running. The discovery of the runtimeinformation is dependent on cell and node agent synchronization.Synchronization must be enabled for every node within a cell. The


synchronization interval determines how up to date the discovery is. The mostcurrent information is gathered from the cell after the JVM information ispropagated from the node agent.

v The JDBC driver version for JDBC providers is not discovered for WebSphereApplication Servers running on z/OS®

v Due to a known problem with the WebSphere Application Server, interim fixinformation is not collected for some versions of the WebSphere ApplicationServer (such as WebSphere Application Server 8.0.0.0 and 8.0.0.1).

v When you discover JDBC drivers from WebSphere Application Server, the datais not populated. It happens because JDBC data sources do not use IP addressesbut host names (FQDNs), while TADDM relies on DNS. When the dependenciesbetween WebSphere Application Server and database servers are created, the/etc/hosts file is not read.


The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.SoftwareContainerv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.JDBCDriverv app.j2ee.websphere.WebSphereAuthMappingModulev app.j2ee.websphere.WebSphereCellv app.j2ee.websphere.WebSphereClusterv app.j2ee.websphere.WebSphereConfiguredConnectionv app.j2ee.websphere.WebSphereConnectorv app.j2ee.websphere.WebSphereConnectorModulev app.j2ee.websphere.WebSphereCustomUserRegistryv app.j2ee.websphere.WebSphereDeploymentManagerv app.j2ee.websphere.WebSphereDynamicCachev app.j2ee.websphere.WebSphereEFixInfov app.j2ee.websphere.WebSphereEJBv app.j2ee.websphere.WebSphereEJBModulev app.j2ee.websphere.WebSphereGlobalSecuritySettingsv app.j2ee.websphere.WebSphereJ2EEApplicationv app.j2ee.websphere.WebSphereJ2EEResourcev app.j2ee.websphere.WebSphereJ2EEResourcePropertyv app.j2ee.websphere.WebSphereJDBCConnectionPoolv app.j2ee.websphere.WebSphereJDBCDataSourcev app.j2ee.websphere.WebSphereJDBCProviderv app.j2ee.websphere.WebSphereJMSDestinationv app.j2ee.websphere.WebSphereJMSProvider


v app.j2ee.websphere.WebSphereJMSQueuev app.j2ee.websphere.WebSphereJMSTopicv app.j2ee.websphere.WebSphereLDAPUserRegistryv app.j2ee.websphere.WebSphereLibraryRefv app.j2ee.websphere.WebSphereMQJMSDestinationv app.j2ee.websphere.WebSphereMQJMSQueuev app.j2ee.websphere.WebSphereMQJMSTopicv app.j2ee.websphere.WebSphereNamedEndpointv app.j2ee.websphere.WebSphereNodev app.j2ee.websphere.WebSphereNodeAgentv app.j2ee.websphere.WebSphereServletv app.j2ee.websphere.WebSphereServerv app.j2ee.websphere.WebSphereSessionTuningParamsv app.j2ee.websphere.WebSphereSharedLibraryv app.j2ee.websphere.WebSphereSSLSettingsv app.j2ee.websphere.WebSphereUserRegistryv app.j2ee.websphere.WebSphereVariablev app.j2ee.websphere.WebSphereVirtualHostv app.j2ee.websphere.WebSphereWebModulev app.JVM

Asynchronous and script-based discovery supportThe IBM WebSphere sensor supports asynchronous and script-based discovery.



To perform a script-based discovery, you must create a discovery profile with onlyWebSphereScriptSensor enabled and the rest of WebSphere family sensors disabled.

Note: WebSphereScriptSensor is meant solely for asynchronous and script-baseddiscovery, and does not collect any data when used in regular discovery mode.




For script-based discovery, the computer system access list entry is used to readthe WebSphere configuration files. An application access list entry for theWebSphere server is not needed.

Running discoveries

When discovering a distributed WebSphere cell, most of its configuration iscollected from its master repository, which is stored in the DMGR's node. However,

Chapter 10. IBM WebSphere sensor 79

other hosts that belong to the cell must also be discovered to create relationshipsbetween WebSphere servers and computer systems that they run on.

Important: The script-based discovery of WAS varies from the regular mode, inwhich a host of a deployment manager is the only required discovery target.

Limitations

Some function that is provided by the WebSphere sensor during a nonscript-baseddiscovery is not supported in an asynchronous or script-based discovery.


The following model objects are not supported:v app.j2ee.JDBCDriverv app.j2ee.websphere.WebSphereConnectorv app.j2ee.websphere.WebSphereEFixInfov app.j2ee.websphere.WebSphereLibraryRefv app.j2ee.websphere.WebSphereServletv app.j2ee.websphere.WebSphereSessionTuningParamsv app.j2ee.websphere.WebSphereSharedLibraryv app.JVM

Only the following configuration files are stored in the TADDM database:v From <PROFILE_HOME>/config/cells/<CELL_NAME>/:

– cell.xml

– resources.xml

– virtualhosts.xml

– variables.xml

– security.xml

v From <PROFILE_HOME>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/:– node.xml

– variables.xml

– resources.xml

– serverindex.xml

– spi.policy

– app.policy

– library.policy

v From <PROFILE_HOME>/config/cells/<CELL_NAME>/nodes/<NODE_NAME>/servers/<SERVER_NAME>/:– server.xml

– variables.xml

– resources.xml

Note: The following limitation applies only to 7.3.0 version of TADDM, it does notapply to version 7.3.0.1, and later.The app.ProcessPool objects are discovered only for the servers that run on aDMGR's host.


Configuring the sensorBefore running a discovery, depending on the type environment you might have toconfigure the IBM WebSphere sensor.

Enabling JDBC driver discoveryIf you want to discover JDBC driver information, you must enable the WebSphereJDBC driver sensor.

To enable the WebSphere JDBC driver sensor, complete the following steps:1. Create a Level 3 discovery profile.2. For the WebSphere cell sensor, enable the deepDiscoveryLevel configuration

item.3. Enable the WebSphere JDBC driver sensor in the new discovery profile.4. Set the appropriate configuration options for the WebSphere JDBC driver

sensor. The following configuration options are available:v You can configure for a prefix to be added to every command run by the

WebSphere JDBC driver sensor on the target host. You can configure adifferent prefix for UNIX and Windows systems. By default, a prefix is notdefined.

v You can configure for the sensor to remove the OracleUtility file afterdiscovery completes. The OracleUtility file is an auxiliary file used byTADDM on target hosts to discover JDBC driver information for Oracledatabases. By default, the OracleUtility file is not removed.

Configuring the discovery profileIf you want to change the discovery level, update the discovery profile for the IBMWebSphere sensor.

Note: Changing the discovery level does not apply to the script-based orasynchronous discovery mode, because WebSphereScriptSensor has noconfiguration properties.

To change the default the discovery level for this sensor, complete the followingsteps:1. In the Discovery Profiles window, click New.2. In the Create New Profile window, type the profile name, description, and

click OK.3. In the list of sensors, click the WebSphereCellSensor, and click New.4. In the Create Configuration window, type the name and description for your

configuration of the WebSphereCellSensor, and select the EnableConfiguration check box.

5. In the Configuration section of the Create Configuration window, to changethe discovery level value, select one of the following choices:v To enable medium discovery, double-click the value for

mediumDiscoveryLevel and change from false to true

v To enable deep discovery, double-click the value for deepDiscoveryLeveland change from false to true

If deepDiscoveryLevel is set to true, it runs a deep discovery regardless ifshallow and medium discoveries are set to true or false.


6. Optional: To configure the sensor to discover only servers that are running,click discoverStoppedServers. Then double-click the Value field in the row,and type false.

7. Click OK to return to the Discovery Profiles window.8. Ensure the WebSphereVersionSensor and WebSphereNodeSensor are selected

along with the new WebSphereCellSensor configuration you created.9. In the Discovery Profiles window, click Save.

10. Choose this discovery profile when running a discovery.

For more information about Discovery Profiles, see the Using discovery profiles topicin the TADDM User's Guide.

Sensor properties

shallowDiscoveryLevel, mediumDiscoveryLevel, deepDiscoveryLevel

The WebSphere sensor has three discovery levels, shallow, medium, anddeep. By default the shallow discovery level is enabled. To modify thediscovery level value, select one of the following choices:v To enable medium discovery, double-click the value of

mediumDiscoveryLevel and change false to true.v To enable deep discovery, double-click the value of deepDiscoveryLevel

and change from false to true.

If the deepDiscoveryLevel is set to true, it runs a deep discovery regardlessof whether shallow and medium discoveries are set to true or false.v The following list contains the information that is captured at each

discovery level.– Shallow discovery discovers the following components:

- Application descriptor files- Cell, node, server names- Cell, node, server type- Host system- JVM runtime version for every running server- Product name and version- Root directory

– Medium discovery discovers the following components:- Clusters- Configuration files- Connections- Deployed connector modules- Deployed EJB modules- Deployed Java EE applications- Deployed web modules- Efixes- EJB containers- End points- JVM settings- Ports- Process definition


- Process monitoring policy- Process pools- Security, SSL settings, and user registries- Virtual hosts- Web containers

– Deep discovery discovers the following components:- Cell, node, server, cluster JDBC providers, JDBC data sources, and

JDBC dependencies- Custom properties- Deployment descriptors for Java EE applications and modules- JMS providers and JMS destinations- Shared libraries- Variables- Web services- Dynamic cache service settings for servers and dynamic clusters

traceSpecification

Sets the trace specification string for enabling trace logging of theWebSphere client code called by the TADDM WebSphere sensor. samplevalue - Admin=all=enabled

Caution: The preceding value generates verbose trace logging. Not settingany value prevents trace logging.

traceOutputFile

Allows you to specify the full path name of the output file to be used forlogging trace output. Leave this property blank if tracing is not required.

TADDM user must have permission to create the output file.

ffdcLogDirectory

Enables FFDC logs of the WebSphere client code called by the WebSpheresensor for troubleshooting purposes. FFDC logs capture the failure paththrough the WebSphere client code in a subdirectory named ffdc in thedirectory specified in this property.

Not setting a value ensures that FFDC is not enabled. The directory mustexist and the TADDM user must have write access.

Configuring the access listThis topic describes the access details that you require depending on type ofconfiguration that you are using.

Note: Configuring the access list does not apply to the script-based orasynchronous discovery mode, because WebSphereScriptSensor requires only anOS-level user in the TADDM access list.

To configure the access list, complete the following steps:1. If security is disabled, no user accounts are needed.2. If security is enabled, specify the following details:

a. For the component type, specify Application Server.b. For the vendor, specify WebSphere.


c. Specify the username and password of WebSphere Application Server.d. In SSL Settings, upload two certificates, trust, and keystores, with their

passphrases. The default passphrase is WebAS.3. For the WebSphere JDBC driver sensor, complete the following steps:

a. For the component type, specify Application Server.b. For the vendor, specify WebSphere SSH.c. Specify the username and password of a system account with appropriate

privileges. If the WebSphere SSH access list is not specified, the WebSphereJDBC driver sensor will try to log in with ComputerSystem credentials.

4. The WebSphere Application Server user can have monitor, operator,configurator, or administrator role. Any of these roles can discover all theinformation. Only the administrator role discovers security configurationinformation for WebSphere Application Server.

5. Disabling security does not mean that you are not using SSL. Check whetheryou are prompted for a password when you connect to the WebSphereApplication Server Admin Console.v If you need only a user name to log on to the Admin Console, security is

disabled.v If you need a user name and password to log on to the Admin Console,

security is enabled.v If the connection to the Admin Console is through https (look at the URL in

your web browser), you need the certificates.

Access to Configuration Filesv In general, the WebSphere Application Server sensor captures the following

configuration files:– WebSphere Application Server cell– WebSphere Application Server node– WebSphere Application Server serverThis information is made available for the change history over time. It is alsomade visible in the Discovery Management Console (Configuration files tab ofthe Details panel) for each of the preceding configuration items.

v When the sensor starts, it also uses the following two files to make key decisionsabout the discovery of WebSphere Application Server:– $WAS_ROOT/config/cells/cell_name/cell.xml

This helps to determine if the system is ND or stand-alone WebSphereApplication Server. If read access to this file is not available, the sensorcontinues and uses JMX to determine whether it is an ND or stand-aloneWebSphere Application Server.

– $WAS_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml (forND, node_name is the dmgr's node, for stand-alone mode, there is only onenode)This helps to determine the port on which the JMX SOAP connector islistening. If read access to this file is not available, the sensor attempts to setup a JMX connection by cycling through all the listen ports of the WebSphereApplication Server server/dmgr being discovered. The ports are tried inascending order since this method results in quicker identification of the JMXport.


Certificate setupIf security is enabled when you discover WebSphere Application Server, you mustset the SSL certificates in the access list entries. TADDM supports PKCS12 and JKScertificate store types. The truststore and keystore files must be present on thecomputer that runs the TADDM console, not on the TADDM server.

Note: Setting up certificates does not apply to the script-based or asynchronousdiscovery mode, because WebSphereScriptSensor requires only an OS-level user inthe TADDM access list.

Truststore and keystore files are typically in the $PROFILE_HOME/etc directory onthe system on which WebSphere Application Server is installed. By default, thefollowing files are certificate stores:v PKCS12

– $PROFILE_HOME/etc/trust.p12

– $PROFILE_HOME/etc/key.p12

v JKS– $PROFILE_HOME/etc/DummyClientTrustFile.jks

– $PROFILE_HOME/etc/DummyClientKeyFile.jks

The default passphrase for these files is WebAS. You can also create truststore andkeystore files by downloading certificates with the WebSphere Application Serverconsole.

TADDM requires a truststore with signer certificate only for connecting withDMGR, in the case of WebSphere Application Server Network Deployment (ND),and server1, in the case of a stand-alone server.

Because of the restrictions of the JMX protocol, which is used to retrieve data fromWebSphere Deployment Manager or from a stand-alone server, TADDM canhandle only one truststore file for a single discovery. The certificates that are storedin the truststore file are loaded when the connection with WebSphere ApplicationServer is established. Only those certificates can be used by TADDM during theentire discovery, so if certificates from several truststores are required, do notattach them separately into the access list. You must export the original truststoresto a single file, either manually or through a collectwascerts script that isbundled with TADDM. When all necessary entries for each WebSphere server arein the TADDM access list, the first one must have the exported truststore andkeystore files attached. There is always one entry for each different login andpassword combination for the discovered WebSphere servers.

Creating a single truststore with the collectwascerts script:

TADDM can use only one truststore file for a single discovery. If you want to usecertificates from several truststores, you must export those truststores to a singlefile. You can use the collectwascerts script that downloads the certificates toexport them.

Procedure

1. Edit the $COLLATION_HOME/bin/collectwascerts.config file.Add a line for each WebSphere server from which you want to download thecertificates. For distributed cells, you need only certificates from thedeployment manager (DMGR) to run a successful discovery. If you start a linewith a number sign (#), it is treated as a comment and is not processed.


Each line must have the following format:<Server IP/HOSTNAME/FQDN><SOAP port number><username><password>

156.24.24.11 8879 wasadmin waspassword

You can find the value of the SOAP port number in the Ports section of DMGRor server panel in the WAS administration console. The exact name isSOAP_CONNECTOR_ADDRESS.

2. Run $COLLATION_HOME/bin/collectwascerts.sh (or $COLLATION_HOME/bin/collectwascerts.bat) on your TADDM host, even if thecollectwascerts.config file has no entries. The file might not have any entriesbecause all the WAS servers can be reached from the anchor servers only.All retrieved certificates are stored in $COLLATION_HOME/bin/collectedwascerts.jks. The passphrase is written by the tool to the standardoutput. You can also read it from the com.collation.sslpassphrase property in$COLLATION_HOME/etc/collation.properties.Complete the optional steps only if your WAS environments are not accessibledirectly from your TADDM server.

3. Optional: Copy the collectedwascerts.jks file from the TADDM host to yourfirst anchor.Copy the file to the bin directory that contains the collectwascerts.config,collectwascerts.bat, and collectwascerts.sh files.

4. Optional: Run collectwascerts.sh (or collectwascerts.bat) on the anchorhost.

5. Optional: Copy collectedwascerts.jks from the anchor host to the nextanchor.Copy the file to the bin directory that contains the collectwascerts.config,collectwascerts.bat, and collectwascerts.sh files.

6. Optional: Run collectwascerts.sh (or collectwascerts.bat) on the nextanchor host.

7. Optional: Repeat steps 5 and 6 for all your anchors.8. Attach the collectedwascerts.jks file from the last anchor, or from your

TADDM host if you do not use the script on anchors, to your WebSphere accesslist entry as a truststore. The SSL type of this file is JKS. Use the passphrasedescribed in step 2.

Creating a single truststore manually:

TADDM can use only one truststore file for a single discovery. If you want to usecertificates from several truststores, you must export those truststores to a singlefile. You can extract the certificates and add them to the keystore and truststorefiles manually.

About this task

Procedure

1. Extract all certificates from the common keystore or truststore for each serverby completing the following steps:a. In the WebSphere Application Server Admin Console, click Security > SSL

certificate and key management.b. Click Key stores and certificates.c. Click NodeDefaultTrustStore.d. Click Signer certificates.


e. Select a signer certificate, and click Extract.f. Enter a unique path and file name for the signer certificate. For example,

enter C:\temp\signer1.arm.g. Click OK.h. Repeat this procedure for each signer certificate in the truststore.i. Repeat this procedure for all servers that are to be discovered.

2. If you use the JKS truststores, add the exported signer certificates to the .jksfiles. To add them to the default DummyServerTrustFile.jks andDummyClientTrustFile.jks files, complete the following steps. If you usePKCS12 truststores, follow the same procedure for key.p12 and trust.p12 files:a. To open iKeyman, from the WebSphere_Root/profiles/dmgr_profile/bin

directory, run ikeyman.sh, or ikeyman.bat.b. Click Key Database File > Open.c. Select the DummyServerTrustFile.jks file from one of the following

directories:v WebSphere_Root/profiles/dmgr_profile/etc

v WebSphere_Root/profiles/stand-alone_server_profile/etc

d. When prompted for a password, type WebAS.e. Click Add, and select one of the signer certificates that you extracted in step

1.f. Repeat the previous step for each signer certificate that you must add.g. Repeat this procedure to add the exported signer certificates to the

WebSphere_Root/profiles/dmgr_profile/etc/DummyClientTrustFile.jks file.3. Retrieve the client side SSL certificates from the WebSphere Application Server.

If new certificates are not generated, the default ones,DummyClientTrustFile.jks and DummyClientKeyFile.jks, or trust.p12 andkey.p12, are typically in one of the following directories:v WebSphere_Root/profiles/dmgr_profile/etc

v WebSphere_Root/profiles/stand-alone_server_profile/etc

The default passphrase for dummy files is WebAS.4. If you want to use different certificates, do not attempt to edit the certificates.

Delete the old access list entry and create a new one.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM WebSpheresensor uses.

Note: The following properties do not apply to the script-based or asynchronousdiscovery mode, because WebSphereScriptSensor does not use them.

com.collation.discover.localanchor.timeout=7200000com.collation.discover.agent.WebSphereNodeSensor.timeout=7200000com.collation.discover.agent.WebSphereCellSensor.timeout=7200000

The default value is 7200000, which means 7,200,000 milliseconds (or 2hours).

These properties set the time allowed for the WebSphere sensor to run.

If you have a large WebSphere environment and require medium or deepdiscovery levels, you might need to increase the value so that the sensorhas enough time to discover the environment.


com.collation.discover.websphere.jmx.timeout=This property sets the time allowed for opening a JMX connection toWebSphere. By default, the value is 600000 milliseconds (10 Minutes)

com.collation.discover.agent.WebSphereVersionAgent.versionscript=sudoThis property can be enabled for access to the WebSphere versionInfo.shfile if the discovery user does not have access on the target WebSphereApplication Server system.

Using the WebSphere seed sensor for z/OSTADDM does not support an operating system sensor for a z/OS system. Todiscover WebSphere resources on a z/OS system, the WebSphere sensor isenhanced to support discovery initiated from user-created seed files.

Because there is no z/OS system sensor, you must use the WebSphere ApplicationServer seed utility for the z/OS DLA. This utility creates an XML seed file from az/OS IdML book. This file contains information about the WebSphere resourcesthat you are trying to discover on the z/OS system.

After this seed file is created, on the next discovery, the WebsphereIdmlSeedSensorlooks for z/OS WebSphere seed files on the TADDM server. If there are, it parsesthat seed file and create a real discovery seed file that is used to kick off theWebSphere sensor. The WebSphere sensor then does a deeper discovery ofWebSphere on this z/OS system.

To install and configure the WebSphere Application Server seed utility for thez/OS DLA, see the corresponding section.

Preparing to run the WebSphere seed sensorBefore running the WebSphere seed sensor, you must create a seed file.

Before running the WebSphere seed sensor, complete the following steps:1. Choose the appropriate method to create the WebSphere seed file:v To discover WebSphere on a z/OS system using the Discovery Library

Adapter, use the WebSphere Application Server seed utility that generatesthe seed files automatically from the IdML books created from the z/OSDLA. The utility is provided as a part of the z/OS DLA package.For information about this utility, see the WebSphere Application Serverdiscovery section of the DLA for z/OS information center.

v To discover WebSphere on a non-mainframe system by manually creating theseed file, use the following file naming conventions when creating the seedfile:– If you want the file to be included as part of the discovery, the file name

must end with a .xml extension.– The file name must adhere to the following format:

<cellname>_<fqdn>_<port>.xml

An example is c1_0.0.0.0_2809.xml.The following example shows the file format:<IDML_WAS_SEED>

<WAS_ROOT_DIR>/opt/WebSphere/AppServer</WAS_ROOT_DIR><WAS_VERSION>6.0.2.7</WAS_VERSION><SOAP_CONNECTOR_PORT>8880</SOAP_CONNECTOR_PORT>


http://www-01.ibm.com/support/knowledgecenter/SSBH2C_7.2.2/com.ibm.taddm.doc_zosdla/c236521231.htm

http://www-01.ibm.com/support/knowledgecenter/SSBH2C_7.2.2/com.ibm.taddm.doc_zosdla/c236521231.htm

<RMI_CONNECTOR_PORT>2809</RMI_CONNECTOR_PORT><JMX_LISTEN_IP_ADDRESS>0.0.0.0</JMX_LISTEN_IP_ADDRESS><HOST_MAPPINGS><HOST_MAPPING>

<HOST_NAME>wasserver.company.com</HOST_NAME><PRIMARY_IP_ADDRESS>0.0.0.0</PRIMARY_IP_ADDRESS><IP_ADDRESS>0.0.0.0</IP_ADDRESS>

</HOST_MAPPING></HOST_MAPPINGS>

</IDML_WAS_SEED>

WAS_ROOT_DIRThe directory path where the WebSphere Application Server isinstalled.

WAS_VERSIONThe version of the WebSphere Application Server, which can befound in the product file in the <WebSphere RootDirectory>/properties/version directory.

SOAP_CONNECTOR_PORTThe port number is retrieved from the serverindex.xml file for theSOAP_CONNECTOR_ADDRESS endpoint name. For example,<WebSphere Root Directory>/profiles/<app server ordmgr>/conf/cells/<cell name>/nodes/<node name>

If the resource is a deployment manager, use the serverindex.xmlfile with the following value specified:serverType="DEPLOYMENT_MANAGER".

If the resource is stand-alone component, use the serverindex.xmlfile with the following value specified:serverType="APPLICATION_SERVER"

RMI_CONNECTOR_PORTThe port number is retrieved from the same serverindex.xml fileused to find the soap port, where the endpoint name isBOOTSTRAP_ADDRESS.

JMX_LISTEN_IP_ADDRESSThe IP address that is used to connect through JMX. Typically thisaddress is the same IP address as the WebSphere server.

HOST_MAPPINGSA list of mappings between the host name and IP address for theWebSphere Application Server or Deployment Manager and eachdistributed Node Agent.

HOST_MAPPINGOne host mapping consisting of a host name, primary IP address,and IP address.

HOST_NAMEThe fully qualified domain name.

PRIMARY_IP_ADDRESSThe primary IP address that the host name resolves to.

IP_ADDRESSThe IP address that the host name resolves to, if different from theprimary IP address.

2. Place the .xml files in the $COLLATION_HOME/var/dla/zos/was directory. If thedirectory does not exist, create the directory. The scope of discovery is


controlled by the files in this directory. If discovery of a particular WebSphereserver is no longer needed, the file must be removed from this directory orrenamed without the .xml extension.

3. Create a new sensor configuration file when you run the WebSphere seedsensor. Change the location of the XML seed file using the following two tags:

<fileName>Set this tag to the directory where the WebSphere XML seed files arelocated.

<scope>Set this tag to the IP address of the TADDM server where theWebSphere XML seed files are located.

Running the WebSphere seed sensorThis topic describes how to run the WebSphere seed sensor.

To run the WebSphere seed sensor, complete the following steps:1. Start the TADDM server.2. Open the Discovery Management Console.3. Add the IP address of the server where the WebSphere seed file is located to a

scope.4. In the Access List, add the access credentials of the server where the

WebSphere seed file is located.5. If security is enabled for the WebSphere server being discovered, add the

credential entry for the WebSphere server. If you want to use the entry with ascope restriction, you must include the IP address of your WebSphere server inthe discovery scope in addition to the IP address of the host, where theWebSphere seed file is located.You also need the client-side SSL certificate when creating the Access List entry.This certificate must be exported from the mainframe security product forexample, Resource Access Control Facility (RACF®) and transferred to a tool formaintaining digital certificates. Use this tool for example iKeyman, to generatea JKS or PKCS12 file. This file contains the client-side SSL certificate in a formatthat can be used by TADDM. The JKS or PKCS12 file must then be used for theSSL settings in the TADDM WebSphere Access List entry for both keystore andtruststore certificates.

6. Complete the following steps:a. Configure the IdmlFileUDS sensor using the Discovery Management

Console:1) In the Discovery Profiles window, click IdmlFileUDS.2) Click New.3) Type the sensor configuration name and description.4) Select Enable Configuration.

5) Double-click /data/latest/dist/var/dla/zos/was and type the location of theWebSphere XML seed files. This location is the server where theWebSphere seed file is located.

6) Double-click 0.0.0.0 and type the IP address of the machine on whichthe seed file is located.

b. Create a discovery profile that includes the following sensors:v Anchor Sensor


v Sensor name entered in step a. (The modified IdmlFileUDS sensor createdpreviously.)

v PortSensorv PingSensorv SessionSensorv GenericServerSensorv WebSphereIdmlSeedSensorv WebSphereCellSensorv WebSphereNodeSensorv WebSphereSensor (select this sensor instead of WebSphereCellSensor and

WebSphereNodeSensor only ifcom.collation.websphere.performance.setting=false)

The sensors can require additional sensors to be enabled in the profile bydefault, enable all additional sensors.

c. Save the configuration file.7. Run the discovery and select the scope to include the server and the discovery

profile that you created.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM WebSphere sensorand presents solutions for those problems.

Sensor does not start

ProblemThe WebSphere Application Server sensor does not start.

Solution

To determine why the WebSphere Application Server sensor does not start,validate the following criteria on your WebSphere server:v The WebSphere process is running.v The command line is not truncated (the process that is running must

match the template for the WebSphere Application Server).For Windows 2003/2008, Linux, Solaris, AIX, and Linux on System zoperating systems, the command line must contain the word WsServer.

v The WebSphere Application Server was started as a service (on Windows2000), or as a service or from the command line (Windows 2003 orWindows 2008).

If none of the preceding items appear to be the cause, check the system logand the WebSphere Application Server start logs for error messages.

WebSphere servers or nodes cannot be discovered

ProblemSome WebSphere servers or nodes cannot be discovered.

SolutionWhen the WebSphere server or node to be discovered is configured to useFQDN instead of plain IP address as its bootstrap address, the TADDMserver must have access to a DNS server that is able to resolve that FQDN.Otherwise the information about this particular server or node cannot bediscovered, even if the target scope is defined using the IP address.


Discovery of WebSphere Application Server is not logged

ProblemThe discovery of the WebSphere Application Server is not logged in theDiscoverManager.log file. Because a local anchor is used for the discovery,the log messages are placed in to a separate file.

SolutionThe log messages are placed in the following log files, where hostname isthe fully qualified domain name of the TADDM server:v local-anchor*.hostname.WebSphereAgent.log

v local-anchor*.hostname.WebSphereNodeSensor.log

Errors when security is enabled on WebSphere ApplicationServer

ProblemThe following types of error messages are displayed:v ERROR cdb.WebSphereAgentDelegate - [WebSphereAgentDelegate.E.1]

discover() failed with exception : java.lang.Exception:Unable to connect to the WebSphere server at9.48.158.37:8,880 - ADMC0016E:The system cannot create a SOAP connectorto connect to host 9.48.158.37 at port 8880...

v ERROR cdb.WebSphereJMXUtils - An error occurred,unable to establish a repository connectionusing the credentials raleigh-was60:com.ibm.websphere.management.exception.AdminException:javax.management.JMRuntimeException: ADMN0022E:Access is denied for the getServerConfig operation onFileTransferServer MBean because of insufficientor empty credentials.

These errors can occur for any of the following reasons:v No credentials exist in the access list for the WebSphere Application

Server.v In the credentials for the WebSphere Application Server, the certificates

are not correct or have not been entered through the access list.v In the credentials for the WebSphere Application Server, the password is

incorrect.

SolutionAdd the credentials in the access list for the WebSphere Application Server.Correct the certificates, enter the certificates through the access list, orprovide the correct password.

Failure to make a JMX connection

ProblemThe following type of error occurs:Sensor failed in remote server:Unable to connect to WebSphere server at 10.0.1.69:8880 - ADMC0016E:Could not create SOAP Connector to connect to host 10.0.1.69 at port 8880

This type of error indicates the following problems:v A missing or incorrect certificate or an incorrect user ID and password.

The following example shows a sample root cause:[SOAPException: faultCode=SOAP-ENV:Client;msg=Error opening socket:javax.net.ssl.SSLHandshakeException: certificate expired;


targetException=java.lang.IllegalArgumentException:Error opening socket:javax.net.ssl.SSLHandshakeException: certificate expired]

v A firewall that is preventing a connection to the WebSphere ApplicationServer through the SOAP port.

v The WebSphere Application Server might not be in a good state, eventhough the process shows up in the process table or Windows serviceslist. To test the state of the WebSphere Application Server, try to connectto it using the wsadmin WebSphere administrative utility. If thewsadmin utility fails, the sensor has problems also.

SolutionUse either of the following solutions:v Run one of the following programs, which tests the JMX connection to

verify credentials and connectivity:– For Linux, AIX, and Linux on System z operating systems:

$COLLATION_HOME/bin/testwasconnection.sh. Instructions for runningthis program are in the testwasconnection.sh file.

– For Windows systems: %COLLATION_HOME%\bin\testwasconnection.bat.Instructions for running this program are in thetestwasconnection.bat file.

v Make sure that your access list is defined correctly. If you discover WASon z/OS and you want to use an access list entry with a scoperestriction, you must include the IP address of your WebSphere server inthe discovery scope in addition to the IP address of the host where theWebSphere seed file is located.

Sensor fails on a JMX query

ProblemThe sensor fails on a JMX query with the following message:failed on JMX query--check server health and retry

This error indicates that the configuration setup might be corrupted.

SolutionCheck the logs to see what is being queried and whether that value isreadable in the WebSphere Application Server console. This error usuallyoccurs because discovery is run overnight, and WebSphere ApplicationServers are down for maintenance reasons. In this case, restart the server,and try the discovery again.

Data store error - storage of data taking too long to collect

ProblemStorage of data collected from a WebSphere discovery is taking too long.

SolutionThe database tuning script was not run before TADDM schema creation.Before creating the TADDM schema, run the following database tuningscript:v For non-Windows systems:

$COLLATION_HOME/bin/gen_db_stats.jy

v For Windows systems:%COLLATION_HOME%\bin\gen_db_stats.bat


WebSphere Application Server is down

ProblemThe WebSphere Application Server is down for one of the followingreasons:v TADDM runs when a WebSphere Application Server is in maintenance,

and a discovery does not complete. The local-anchor*.hostname.WebSphereAgent.log file or local-anchor*.hostname.WebSphereNodeSensor.log file might display thefollowing error message:INFO cdb.AnchorServer[main] - [AnchorServer.I.0] server no longeraccepting new connections

v An error message states that the query cannot be completed.

SolutionVerify that the WebSphere Application Server is functioning properly.

Sensor does not show as much data as it did in previousreleases of TADDM

ProblemThe Details window for WebSphere cells, nodes, and servers does not showas much detail as it did in previous TADDM releases, and many of thetabs in the window have no data.

SolutionTADDM implements the following discovery levels:v Shallowv Mediumv Deep

The default discovery level for the WebSphere Application Server sensor isshallow.

To obtain more detail about the WebSphere Application Server, create adiscovery sensor configuration for the WebSphereCellSensor sensor, and inthe Sensor Configuration window. Set the value of themediumDiscoveryLevel property or the deepDiscoveryLevel property totrue.

WebSphere sensor fails during WebSphere discovery on an AIXoperating system due to problems with the AIX ps command

ProblemOn some AIX operating systems, running the UNIX ps command returnstruncated Java CLASSPATH strings. The strings are not recognized by theTADDM WebSphere sensor, resulting in a failed discovery.

SolutionUpgrade to at least the AIX 5.3. FP5 (5.3.0.50) version. This version andlater versions of AIX return the full Java CLASSPATH strings.

Message CTJDT0736W is shown

ProblemInsufficient credentials exist in the access list for the Secure Shell (SSH)protocol or Windows Management Instrumentation (WMI) on the hostsystem where the distributed node is running.


The computer system credentials for this host system are used to retrieveinformation to populate the host for the node and server configurationitems on that system.

SolutionIf you want this information to be populated, you must add theappropriate computer system credentials for the host system.

WebSphere sensor fails and the following message is displayed:CTJTD0692E

ProblemWhile attempting to discover a distributed WebSphere cell, the WebSpheresensor fails with the following message:CTJTD0692E The distributed cell deployment manager bind address is notfound for the following cell:etabsap1TCell

SolutionDiscoveries involving the sensors related to WebSphere DeploymentManager must have a working DNS. As a workaround, changecom.collation.platform.os.disableRemoteHostDNSLookups to true, andensure that the TADDM server always has the correct DNS search path.

WebSphere sensor fails and the following message is displayed:CTJTD3021E

ProblemThe WebSphere sensor fails with the following message:CTJTD3021E The sensor fails in a remote server :CTJTD2120E An error has occurred in the discovery process.:CTJTD0775E A connection to the WebSphere server is notavailable: << ip address of IBM WebSphere application server >>- ADMC0016E: The system cannot create a SOAP connector to connect to host<< ip address of IBM WebSphere application server >>

SolutionVerify that the problem is with the SSL support in the WebSphere clientcode. To verify, ensure that the WebSphere access list entry for thisWebSphere Server is first in the access list (before any other WebSpherecredentials). If the discovery is successful, import all the WebSpherecertificates from the different servers into one truststore. Having multipleaccess list entries with different user IDs and passwords is acceptable.However, all the access list entries must specify the same truststore, whichcontains all the certificates.

For additional information, see “Configuring the access list” on page 83.

WebSphere JDBC driver sensor does not start

ProblemThe WebSphere JDBC driver sensor does not start.

SolutionTo establish why the WebSphere JDBC driver sensor does not start, ensurethat the following conditions have been met:v A user profile for Level 3 discovery has been created and the WebSphere

JDBC driver sensor is enabled.v Deep discovery is enabled for the WebSphere cell sensor.


WebSphere JDBC driver sensor cannot connect to the targethost and the following message is displayed: CTJTD0796E

ProblemDuring the discovery, the WebSphere JDBC driver sensor cannot establish aconnection with target host and the CTJTD0796E error message isdisplayed.

SolutionThe following situations are possible reasons for this error:v SSH connection could not be established with the host.v A connection with the host was established, but the user did not have

the appropriate privileges to run the WebSphere setupCmdLine script.v A connection with the host was established, but the user did not have

the appropriate privileges to run the Java command.

You must check the sensor logs files to determine which of these situationshas occurred.

If the sensor fails and the warning CTJTD0798W is displayed in the logfiles, ensure that the user specified in the WebSphere SSH access list entryhas the appropriate privileges to run the WebSphere setupCmdLine script.

If the sensor fails and the warning CTJTD0799W is displayed in the logfiles, ensure that the user specified in the WebSphere SSH access list entryhas the appropriate privileges to run the Java command.

Some JDBC dependencies are not created between a WebSphereserver and database servers

ProblemTADDM discovers both the WebSphere server and a related databaseserver but does not create a relation between them. Such a relation is basedon the JDBC connection properties that are defined on the applicationserver.

Solution

The problem might be a result of one of the following issues:v JDBC connectivity details are gathered by deep level discoveries only.

Ensure that the discovery profile for the WebSphere sensor is configuredfor that level of discovery.

v The dependencies are created by the JDBCDependencyAgent that runsin the Dependency topology agent group. Ensure that the agent is runafter the discovery of the WebSphere servers.

v The JDBCDependencyAgent processes only the recently discoveredapplication servers. If some dependencies are still missing after the agenthas run, rediscover the WebSphere servers, and wait for the topologyagents to run again.

v Ensure that the database server is one of those that supports the creationof transactional dependencies between it and the WebSphere applicationserver. The following databases are supported:– Oracle– IBM DB2– Microsoft SQL Server– Sybase


WebSphere sensor fails when the TADDM server is running RedHat Enterprise Linux 6

ProblemWebSphere sensor fails when the TADDM server is running Red HatEnterprise Linux 6. The following errors might be displayed:CTJTD3021E The sensor fails in a remote server

CTJTD2015E There is a local anchor sensor failure

SolutionIn the /etc/security/limits.d/90-nproc.conf configuration file, commentout the following line:* soft nproc 1024

After you have updated the configuration file, you must restart theTADDM server.

Only placeholder objects are stored after a script-baseddiscovery

ProblemAfter you run a successful WebSphereScriptSensor discovery, all storedobjects are marked as placeholders and contain few details.

SolutionPlaceholder objects are created by the WebSphereScriptSensor when adiscovery target is a WebSphere Application Server node in a distributedcell other than the management cell (a DMGR's node). To obtain moredetailed information about the placeholder model objects, run a discoveryof the host with the DMGR.


Chapter 11. IBM WebSphere eXtreme Scale cache sensor

The IBM WebSphere eXtreme Scale cache sensor discovers IBM WebSphereeXtreme Scale caches and some of their components.

The sensor discovers the following elements for the eXtreme Scale cache:v The name of the cachev A list of nodes on which the cache resides

The sensor discovers the following elements for each eXtreme Scale node:v The name of the nodev The host name of the nodev The contents of the main configuration filev The contents of the orb.properties configuration file for the JVM that runs this

node and version of this JVMv The contents of .xml, .sh, .props, and .properties files that are in the same

directory as main configuration file


WebSphereXSCacheSensor

Prerequisites

IBM WebSphere eXtreme Scale must be running on the target computers.

The path to the configuration file, specified by the -objectgridfile parameter,must be absolute.

Security issues

The user must have permission to perform the following tasks:v Get the complete list of processes, including Java virtual machine (JVM)

processes, running on the target system.v Read the configuration file specified by the -objectgridfile parameter, typically

objectGrid.xml.v Read any XML files, script files or properties files in the same directory as the

configuration file specified by the -objectgridfile parameter, if this informationis to be captured.

v Run the JVM that runs the eXtreme Scale node with the -version parameter, toget runtime environment version information.

v Read the orb.properties configuration file, which is in the lib directory of theJVM.

Limitations

The following limitations apply:v Only those eXtreme Scale nodes that are using separate JVMs as containers for

eXtreme Scale caches are discovered. Caches that use special web applications ascontainers for eXtreme Scale nodes are not discovered.


v JVMs that provide catalog services for eXtreme Scale nodes are not discovered.v If more than one JVM process is started with the same node name and the same

copy of the configuration file specified by the -objectgridfile parameter, thesensor does not recognize that they are separate nodes, and the nodes aremerged.

v The sensor looks for configuration files only in the same directory as theconfiguration file specified by the -objectgridfile parameter, and itssubdirectories. Only files with one of the following extensions are recognized:– .xml

– .sh

– .props

– .properties

You cannot configure the file extension recognized.v The sensor does not parse the configuration files, but captures the entire

contents of each file.v When checking the -objectgridfile parameter, the sensor ignores case.

Model objects with associated attributesThe IBM WebSphere eXtreme Scale cache sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about configuration items in the IBM WebSphere environment.


app.JVMExecutableName

JVMVersion

Publisher

SoftwareVersion

websphere.WebSphereXSCache

v Name

websphere.WebSphereXSCacheNode

v Namev Host



use for authentication to the target computer system.


Chapter 12. IBM WebSphere Message Broker sensor

The IBM WebSphere Message Broker sensor discovers WebSphere Message Brokerattribution at broker instance, configuration, and application levels for Windowsand UNIX.


MBServerSensor

Prerequisites

The TADDM server requires the following login information:

System login with ability to discover the target computer.

You must be authorized to run mqsiprofile command.

Limitations

After a discovery using the IBM WebSphere Message Broker sensor, some attributevalues in the Details pane remain empty because the sensor does not populate allof the Message Broker elements. You can find the full list of discovered classes andattributes in the sensor data dictionary. To populate the missing attribute values,you can use other data producers, such as Discovery Library Adapters (DLAs), orcustom server extensions that extend the TADDM discovery capabilities.


The sensor creates the following model objects:v messaging.mb.MBBrokerv messaging.mq.MQQueueManagerv messaging.mb.MBExecutionGroupv messaging.mb.MBHTTPListenerPropertiesv messaging.mb.MBHTTPConnectorPropertyv messaging.mb.MBHTTPSConnectorPropertyv messaging.mb.MBHTTPListenerPropertyv messaging.mb.MBBrokerSecurityv messaging.mb.MBBrokerProfilev messaging.mb.MBMessageFlowv messaging.mb.MBMessageFlowNodev messaging.mb.MBBarFilev messaging.mb.MBProperty



Configuring the discovery profileIf you want to change the discovery level, update the discovery profile for the IBMWebSphere Message Broker sensor.

To change the default the discovery level for this sensor, complete the followingsteps:1. In the Discovery Profiles window, click New.2. In the Create New Profile window, type the profile name, description, and click

OK.3. In the list of sensors, click the MBServerSensor, and click New.4. In the Create Configuration window, type the name and description for your

configuration of the MBServerSensor.5. In the Configuration section of the Create Configuration window, to change the

discovery options, select one of the following choices:v To use OS credentials to conduct discovery, double-click the value for

useHostAuth and change from false to true

v To discover WebSphere message flow nodes attributes, double-click the valuefor useNodeLevel and change from false to true

6. Click OK to return to the Discovery Profiles window.7. In the Discovery Profiles window, click Save.8. Choose this discovery profile when running a discovery.

For more information about Discovery Profiles, see the Using discovery profiles topicin the TADDM User's Guide.

Configuring the access listThis topic describes the access details you require to configure the access list.

To configure the access list, complete the following steps:1. Select Messaging Servers as the Component Type.2. Select WebSphere Message Broker as the Vendor.3. Specify the following required information:v User namev Password

You must be authorized to run mqsiprofile command.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the sensor uses.


com.collation.platform.os.UnixOs.forcedServerList=bipbrokerThis property forces the bipbroker process to start the sensor on UNIXplatform.

com.collation.platform.os.WindowsOs.forcedServerList=bipserviceThis property forces the bipservice process to start the sensor on Windowsplatform.

Fix Pack 4 com.collation.platform.os.AixOs.forcedServerList=bipbroker


This property forces the bipbroker process to start the sensor on AIXplatform.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM WebSphereMessage Broker sensor and presents solutions for those problems.


ProblemThe WebSphere Message Broker sensor does not start.

SolutionMake sure that the bipbroker process name is added to thecom.collation.platform.os.UnixOs.forcedServerList property in thecollation.properties file.

Chapter 12. IBM WebSphere Message Broker sensor 103

Chapter 13. IBM WebSphere MQ Server sensor

The IBM WebSphere MQ Server sensor discovers IBM WebSphere MQ servers.


MQServerSensor

Security issues

The TADDM server requires the following login information:v System login with ability to discover the target computer.v For the WebSphere MQ server on a UNIX system, the WebSphere MQ user login

and password used to log on to the MQSC console.


The sensor creates the following model objects:v app.messaging.mq.MQChannelv app.messaging.mq.MQClientConnectionChannelv app.messaging.mq.MQClusterv app.messaging.mq.MQClusterReceiverChannelv app.messaging.mq.MQClusterSenderChannelv app.messaging.mq.MQInstallationv app.messaging.mq.MQListenerv app.messaging.mq.MQNameListv app.messaging.mq.MQQueueManagerv app.messaging.mq.MQRequesterChannelv app.messaging.mq.MQServerChannelv app.messaging.mq.MQTCPListenerv app.ProcessPool

Asynchronous and script-based discovery supportThe IBM WebSphere MQ Server sensor supports only script-based andasynchronous discovery. It does not run in regular discoveries.


For script-based and asynchronous discovery, the sensor requires no configuration.

Limitations




Configuring the access listDescribes the access details required for both UNIX and Windows installations.

Prerequisites

For Windows systems, the user must be a member of the Windows Admin Groupto run the runmqsc command.

For UNIX systems, the WebSphere MQ user has privileges to run the runmqsccommand.

Configure the access list as follows:1. Select Messaging Servers as the Component Type.2. Select WebSphere MQ as the Vendor.

Windows systems require the following information:v User namev Password



com.collation.platform.os.UnixOs.forcedServerList=amqzxma0This property forces the aqmzxma0 process to start the sensor.

com.collation.topobuilder.mq.clusterrelations=trueThis property enables the building of dependencies based on clustermembership. Every Queue Manager in the cluster has two dependencies(one as a source and one as a target) to every other Queue Manager in thesame cluster.

If not set, the default value is false.

com.collation.topobuilder.mq.channelrelations=trueThis property enables the building of dependencies based onsender-receiver channel names. If not set, the default value is false.

Limitation: This capability is available only if the channel names containboth the name of the source manager and the target manager. Otherwise, itis not possible to build a regular expression for thecom.collation.topobuilder.mq.channelnaming property.

com.collation.topobuilder.mq.checkreceiverchannelname=trueIf set to true, the dependency is set only if there is a receiver channel witha name matching the sender channel name on the target manager. Thedefault value is false.

com.collation.topobuilder.mq.channelnaming=<REGULAR EXPRESSION>Allows you to specify custom channel naming rules for creating channeldependencies. REGULAR_EXPRESSION must return two named groups:v The first matches the source manager name.v The second matches the target queue manager name.

If the custom channel naming does not contain the source queue managername, for example, TO.TARGET_MANAGER, the first group can be set to


an empty value, for instance, ()TO.(.*). The source queue manager name isnot compared with the sender channel parent queue manager name in thatcase.

If not set, the default value for the <REGULAR_EXPRESSION) isCH\\.(.*?)\\.TO\\.(.*

The following properties are used for generating display names for theQueueManager.

com.collation.discover.agent.MQQueueManager.Use ListenningIp=true Sets the QueueManager name; the default value is false.

<FQDN>:<QUEUE_MANAGER_NAME> - First non-empty Fully QualifiedDomain Name (FQDN) or IP from the first listening MQListener is used

com.collation.discover.agent.MQQueueManager.UseIpFromConnections=trueThe default value is false.

<FQDN>:<QUEUE_MANAGER_NAME> - First non-empty FQDN (or IP)taken from LOCLADDR attribute of the ServerConnection is used.

com.collation.discover.agent.MQQueueManager.UseEmptyHostName=trueIf the FQDN is not present, the first non-empty FQDN (or IP) taken fromthe LOCLADDR attribute of the ClientConnection is used. The defaultvalue is false.

<QUEUE_MANAGER_NAME> - The QueueManager name without theFQDN is used.

com.collation.topobuilder.mq.removerelationsIf not set, the default value is false. If set to true, dependencies for theWebSphere MQ queue manager are removed if the state is other thanrunning.

If none of the preceding properties are set to true (UseListenningIp orUseIpFromConnections did not resolve the FQDN), the parent host FDQN is used.

<HOST_FQDN>:<QUEUE_MANAGER_NAME>

The following properties are used to specify that the sensor should use the sudocommand when running MQ commands on the server.

com.collation.discover.agent.MqServerAgent.versionCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ version command.

com.collation.discover.agent.MqServerAgent.statusCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ dspmq command.

com.collation.discover.agent.MqServerAgent.mqscCommand=sudo -u userSpecifies that the sensor should use sudo with the specified user namewhen running the MQ runmqsc command.

Each of the preceding properties can be scoped to a particular operating systemtype, IP address, or both, as in the following example:com.collation.discover.agent.MqServerAgent.mqscCommand.Linux.1.2.3.4=sudo -u mqm

Chapter 13. IBM WebSphere MQ Server sensor 107

Troubleshooting the sensorThis topic describes common problems that occur with the IBM WebSphere MQServer sensor and presents solutions for those problems.


ProblemThe WebSphere MQ Server sensor does not start.

SolutionEnsure that the amqzxma0 process name is added to thecom.collation.platform.os.UnixOs.forcedServerList property in thecollation.properties file.

⌂Sensor starts, but it does not discover all of the informationthrough IBM Tivoli Monitoring discovery

ProblemDiscovery of the WebSphere MQ Server sensor through IBM TivoliMonitoring ends successfully, but not all of the information is discovered.

SolutionMake sure that on target host, the user, under which the IBM TivoliMonitoring agent is running, is added to the mqm group.


Chapter 14. iPlanet server sensor

The iPlanet server sensor discovers iPlanet Web servers.


IPlanetServerSensor

Prerequisites

The TADDM service account should have:v Execute permissions on the iPlant binary, either ns-httpd or webserd.v Read access to the iPlanet configuration files


The sensor creates the following model objects:v app.AppConfigv app.SoftwareContainerv app.SoftwareModulev app.StaticContentModulev app.web.CGIScriptv app.web.iplanet.IPlanetJSPv app.web.iplanet.IPlanetJVMSettingsv app.web.iplanet.NSAPIPluginv app.web.iplanet.IPlanetServerv app.web.iplanet.IPlanetServletv app.web.iplanet.IPlanetSSLSettingsv app.web.iplanet.IPlanetVirtualHostv app.web.iplanet.IPlanetWebContainerv app.web.iplanet.WebLogicConnectionv app.web.WebConnectionv sys.DataFile sys.Directory


Chapter 15. JBoss server sensor

JBoss sensor discovers version of a JBoss installation and collects data for theserver. It can be used to discover JBoss AS versions 4, 5, and 6.


JBossVersionSensor, JBossSensor

Prerequisites

The following prerequisites must be met:v Discovery of the computer system must succeed.v JMX must be enabled on the JBoss server.v If the JMX is protected by password, the credentials must be entered in the

access list.

The JBoss sensor requires JAR files that are part of the JBoss Server installation.You must copy the JAR files to the following directories ($COLLATION_HOME) on theTADDM server.

For JBoss AS 4:v lib/jboss/402/jbossall-client.jar, lib/jboss/402/jnpserver.jar

v lib/jboss/402/jboss-jmx.jar

For JBoss AS 5:v lib/jboss/5/jboss-client.jar

v lib/jboss/5/jnp-client.jar

v lib/jboss/5/jboss-logging-spi.jar

v lib/jboss/5/jboss-security-spi.jar

v lib/jboss/5/jboss-common-core.jar

v lib/jboss/5/jboss-javaee.jar

v lib/jboss/5/jmx-invoker-adaptor-client.jar

v lib/jboss/5/jbosssx-client.jar

v lib/jboss/5/jboss-integration.jar

v lib/jboss/5/jboss-serialization.jar

v lib/jboss/5/jboss-remoting.jar

v lib/jboss/5/jboss-jca.jar

For JBoss AS 6:v lib/jboss/6/jboss-client.jar

v lib/jboss/6/jnp-client.jar

v lib/jboss/6/jboss-logging.jar

v lib/jboss/6/jboss-security-spi.jar

v lib/jboss/6/jboss-common-core.jar

v lib/jboss/6/jmx-invoker-adaptor-client.jar

v lib/jboss/6/jbosssx-client.jar


v lib/jboss/6/jboss-integration.jar

v lib/jboss/6/jboss-serialization.jar

v lib/jboss/6/jboss-remoting.jar

v lib/jboss/6/jboss-jca.jar

Limitations

Important: JBoss AS 6 is supported from TADDM 7.2.2 Fix Pack 1.

If a discovery of a JBoss version via a JMX connection fails, JBossVersionSensoruses the SSH session for discovery. The sensor does not discover the content ofJBoss and the model objects are not created.

For JBoss ManagedConnectionFactories, the JDBC XA data source properties arenot discovered by the sensor. As a result, the transactional dependencies betweenJBoss server and the database servers that are denoted by such data sources are notcreated.


The sensor creates the following model objects:v app.AppServerv app.j2ee.J2EEServerv app.j2ee.jboss.JBossClusterv app.j2ee.jboss.JBossDomainv app.j2ee.jboss.JBossJMSServerv app.j2ee.jboss.JBossServer

Configuring the sensorBefore you run a discovery of the JBoss installation, you must configure the JBossserver sensor.


You need the following information:v The access list entry for the computer system running the JBoss server.v The access list entry for the JBoss server JMX console, if password protected.



com.ibm.cdb.discover.jbossversion.sockettimeoutThis property specifies a socket timeout value (in milliseconds) forJBossVersionSensor.


Troubleshooting the sensorThis topic describes common problems that occur with the JBoss sensor andpresents solutions for those problems.

JBossVersionSensor does not start

ProblemThe JBossVersionSensor does not start.

Solution

v Go to http://ipaddress:webport/jmx-console and scroll through theconsole to see if the JBoss server JMX console is enabled.

v Ensure that lsof works properly.

JBoss libraries not found

ProblemWhen you run the sensor, the JBoss libraries not found message isdisplayed.

SolutionEnsure that the JBoss JAR files for your JBoss server version are in the distdirectory, and that read access is enabled for User.

Some JDBC dependencies are not created between a JBossserver and database servers

ProblemTADDM discovers both the JBoss server and a related database server butdoes not create a relation between them. Such a relation is based on theJDBC connection properties that are defined on the application server.

Solution

The problem might be a result of one of the following issues:v The dependencies are created by the JDBCDependencyAgent that runs

in the Dependency topology agent group. Ensure that the agent is runafter the discovery of the JBoss servers.

v The JDBCDependencyAgent processes only the recently discoveredapplication servers. If some dependencies are still missing after the agenthas run, rediscover the JBoss servers, and wait for the topology agents torun again.

v Ensure that the database server is one of those that supports the creationof transactional dependencies between it and the JBoss applicationserver. The following databases are supported:– Oracle– IBM DB2– Microsoft SQL Server– Sybase

JBossVersionSensor fails with the error message "CTJTD0030EAn error occurred while executing ./run.bat -V".

ProblemJBossVersionSensor fails and the following error message can be found inlogs:

Chapter 15. JBoss server sensor 113

v For JBoss AS on Windows:ERROR sensor.JBossVersionSensor - CTJTD1573E An error occurred whileexecuting ./run.bat -V: com.collation.platform.os.OsException:’.’ is not recognized as an internal or external command,.

v For JBoss AS on Linux:ERROR sensor.JBossVersionSensor - CTJTD1573E An error occurred whileexecuting ./run.sh -V: com.collation.platform.os.OsException:’.’ is not recognized as an internal or external command,.

SolutionJBossVersionSensor was unable to detect the version of JBoss AS becausethe full path to the run.bat or run.sh script was not provided before theapplication server was started. Copy the required JBoss libraries (JAR files)to the $COLLATION_HOME/lib/jboss directory to enable a version detectionvia JMX. Without these libraries, the JBoss server sensor does not store anymodel objects. See the “Prerequisites” on page 111 section to learn whichlibraries must be copied.


Chapter 16. JBoss Application Server 7 sensor

The JBoss Application Server 7 sensor discovers JBoss AS configuration for JBossAS 7.0 and later.

The sensor discovers JBoss servers that are run both as stand-alone servers and ina managed domain. Every host that belongs to a managed domain is discoveredindependently, so to get a full picture of a JBoss topology, a discovery must be runagainst each of the hosts. When an environment is discovered for the first time, itis advised to start with the discovery of a host, which acts as a JBoss domaincontroller, and then run a discovery of domain members.


JBoss7Sensor

Prerequisites

An OS user that runs a discovery must have the read access to JBoss configurationfiles and deployment content. The user must also be able to run java, otherwisethe deployment descriptors are not discovered.

Limitationsv Applications and modules that are deployed to a stand-alone server by placing

the deployment content in the deployments folder (file system deployments) arenot discovered by the sensor. Only applications and modules that are deployedby using the JBoss AS management APIs (the command line or web interface)are supported.

v The deployment type recognition relies on searching for specific descriptor filesin the deployment content. If none of these descriptors is found, a general typeJ2EEDeployedObject is assigned to a model object that is stored by the sensor.


The sensor creates model objects of the following types:v app.j2ee.jboss.JBossDomainv app.j2ee.jboss.JBossHost (only for managed domains)v app.j2ee.jboss.JBossCluster (representing server groups in a JBoss managed

domain)v app.j2ee.jboss.JBossServerv app.ConfigFilev app.j2ee.J2EEDeployedObject (and its subtypes)

JDBC data sources are stored as extended data of JBossClusters (for a manageddomain) or JBossServer (for a stand-alone server). Deployment descriptors arestored as extended data of J2EEDeployedObjects.

Configuring the sensorBefore running a discovery, you must configure the JBoss Application Server 7sensor.


The JBoss Application Server 7 sensor has the following configuration options. Ifyou want to change these options, create a custom sensor configuration. See theCreating discovery profiles topic in the TADDM User's Guide.

extractAllXmlDescriptorsThe default value of this property is true.

If this property is set to true, the sensor discovers all files with the .xmlextension from the META-INF and WEB-INF directories of applications ormodules that are deployed on JBoss. If this property is set to false, thedescriptorsToExtract property is used.

descriptorsToExtractThis property specifies a space-separated list of files, which are to bediscovered for JBoss deployments when the extractAllXmlDescriptorsproperty is set to false. For example, META-INF/application.xmlWEB-INF/web.xml. Wildcard characters are not allowed.

extractSubmodulesThe default value of this property is false.

If this property is set to true and if a deployment is a Java PlatformEnterprise Edition application in a form of an enterprise archive (EAR), thesensor discovers descriptors from this deployment and its modules, forexample from JAR or WAR files. If this property is set to false, thedescriptors from the submodules of the deployment are not discovered.

Note: To discover modules of an enterprise archive (EAR), itsMETA-INF/application.xml must be extracted. It means that either theextractAllXmlDescriptors property must be set to true, or the value of thedescriptorsToExtract property must include META-INF/application.xml.

Fix Pack 1 tagsToMaskThe default value of this property is 'password'.

This property specifies a space-separated list of XML tags. Any text contentof these tags in files which are discovered is masked with asterisks.

Configuring the collation.properties file entriesYou can configure the collation.properties file entries to adjust commands thatthe JBoss Application Server 7 sensor uses.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.java orcom.collation.discover.agent.command.java

is a java executable file. If this command is not set, the sensor uses thedefault java on a discovered host (the one, which is present in the system$PATH). If it fails, java, which runs the discovered JBoss AS, is used instead.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.pwdx orcom.collation.discover.agent.command.pwdx

reports current working directory of a process (for UNIX systems only).

The default value is pwdx.

com.ibm.cdb.discover.sensor.app.j2ee.jboss7.ps.full orcom.collation.discover.agent.command.ps.full

lists all running processes in a full format (for UNIX systems only).

The default value is ps -ef, except for the Solaris operating system, forwhich the default value is /usr/ucb/ps auxww.


Configuring for asynchronous discoveryYou can modify the default settings if you want to run the JBoss ApplicationServer 7 sensor in the asynchronous discovery mode.

Custom sensor configurations are not read when an asynchronous discoverypackage is prepared. If you need to use a configuration other than the default one,modify the configuration in the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.j2ee.jboss7_<version>/plugin.xml file.

Troubleshooting the sensorThis topic describes common problems that occur with the JBoss ApplicationServer 7 sensor and presents solutions for those problems.

A managed domain is duplicated

ProblemWhen many hosts that belong to the same JBoss managed domain arediscovered simultaneously for the first time, duplicates might be created inthe TADDM database.

SolutionRun a discovery of the JBoss domain again. Duplicates are merged.

To avoid such problem in future, discover a host, which acts as a JBossdomain controller first, and then run a discovery of domain members.

Deployments, or JDBC data sources, or both, are not discovered

ProblemNot all deployments, or JDBC data sources, or both, are present in theTADDM database after some hosts that belong to a managed JBoss domainare discovered.

SolutionAlthough JBoss AS propagates deployments and JDBC data sources acrossa managed domain automatically, the comprehensive information aboutthem might be available only on a host that acts as a JBoss domaincontroller. To get a complete picture of a JBoss environment, all hosts,which constitute the domain must be discovered, especially the domaincontroller.

Modules of an EAR deployment are not discovered

ProblemA Java Platform, Enterprise Edition application in a form of an enterprisearchive (EAR) is deployed to JBoss AS, but the sensor does not discovermodules of the application.

SolutionConfigure the sensor so that the META-INF/application.xml descriptor iscollected. See “Configuring the sensor” on page 115.

Some JDBC dependencies are not created between a JBossserver or server group and database servers

ProblemTADDM discovers both the JBoss server or server group and a related

Chapter 16. JBoss Application Server 7 sensor 117

database server but it does not create a relation between them. Suchrelation is based on JDBC connection properties that are defined on theapplication server.

SolutionThe problem might be a result of one of the following issues:v The dependencies are created by the JDBCDependencyAgent that runs

in the Dependency topology agent group. Ensure that the agent is runafter the discovery of the JBoss AS.

v The JDBCDependencyAgent processes only the recently discoveredapplication servers. If some dependencies are still missing after the agenthas run, rediscover the JBoss environment, and wait for the topologyagents to run again.

The JBoss Application Server 7 sensor does not start

ProblemAlthough JBoss AS is started, the JBoss 7 Application Server sensor is nottriggered.

SolutionIf a JBoss stand-alone server, or a JBoss host controller listens only on aloopback address and thecom.collation.platform.os.ignoreLoopbackProcesses=true property is setin TADDM, the server process is ignored, and the sensor does not start.Change the value of the property to false for the JBoss host, which wasnot discovered, in the following way:com.collation.platform.os.ignoreLoopbackProcesses.x.x.x.x=false

where x.x.x.x is the IP address of the discovery target.


Chapter 17. Kernel-based virtual machine sensor

The Kernel-based virtual machine sensor uses the libvirt library to discover theKVM supervisor with the list of managed virtual machines.


KvmSensor

Prerequisites

The libvirt daemon must be running on a target KVM host.

To avoid duplicates that are created by the Linux computer system sensor and theKVM sensor, you must install DMI decode on each of guest computer systems.


The sensor creates the following model objects:v KVMv L2Interfacev ComputerSystemv StoragePoolv StorageVolumev CPU


Configuring the collation.properties fileThis topic lists the collation.properties file entries that the sensor uses.

The following property specifies that the sensor uses sudo to elevate privilegeswhen it runs the KVM virsh command:v com.collation.discover.agent.kvm.systemcommand.Linux=sudo

You can scope this property to a specific IP address, as in the following example:com.collation.discover.agent.kvm.systemcommand.Linux.192.168.1.1=sudo

Specify the sudo option for an operating system only if it is required for all systemsthat use that operating system. Otherwise, specify the option only for the specificIP addresses where the sudo command is configured.

On the target systems that require the privilege escalation, configure the sudocommand with the NOPASSWD option. Otherwise, the discovery hangs until theTADDM server times out.


Configuring the discovery profileTo change the discovery level, update the discovery profile for the KVM sensor.You can disable the discovery of non-running guests to discover only those serversthat are running.

Procedure1. From the Discovery Management Console, click the Discovery Profiles icon.2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name, description, and click

OK.4. In the list of sensors, click KVMSensor, and click New.5. In the Create Configuration window, type the name and description for your

configuration of the KVM sensor, and select the Enable Configuration checkbox.

6. In the Configuration section of the Create Configuration window, to configurethe sensor to discover only the servers that are running, clickdiscoverNonRunningGuests. Then double-click the Value field in the row, andtype false.



Chapter 18. Microsoft Cluster sensor

The Microsoft Cluster sensor discovers a Microsoft Windows Server clusterinstallation. The sensor discovers only server clusters (includes a process known asfailover) and not Network Load Balancing clusters. The sensor discovers the nodes,resources, and resource groups on the cluster.


MSClusterSensor

Prerequisites

The MS Cluster sensor requires:v Successful discovery of Windows computer systemsv The Cluster Server ClusSvc service, must be runningv Using the TADDM Windows Management Instrumentation (WMI) provider,

WMI read access to the root/mscluster namespace must be granted. If thediscovery of the Windows computer systems succeeded, this WMI read access isgranted by default. Administrative-level access is preferable.

Limitations

The scope of discovery must contain the IP address of at least one of the MSCluster nodes or mention the cluster IP address. A node is any computer that ispart of the cluster.

Model objects with associated attributesThe MS Cluster sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about MicrosoftServer clusters in your IT environment.


app.MsFailoverCluster.MsCluster

v CrossSubnetDelayv CrossSubnetThresholdv DefaultNetworkRolev Descriptionv DisableGroupPreferredOwnerRandomizationv Domainv EnableEventLogReplicationv HangRecoveryActionv HangTimeoutv InternalNetworkv LogLevelv LogSize


v MaintenanceFilev MaxNumberofNodesv MaxQuorumArbitrationTimev MinQuorumArbitrationTimev Namev Nodesv PlumbAllCrossSubnetRoutesv PublicNetworksv QuorumLogFileSizev QuorumPathv QuorumTypev RegroupOpeningTimeoutv RegroupPruningTimeoutv RegroupStageTimeoutv RegroupTickv RequestReplyTimeoutv ResourceDllDeadlockPeriodv ResourceGroupsv Resourcesv SameSubnetDelayv SameSubnetThresholdv SecurityLevelv WitnessDatabaseWriteTimeoutv WitnessRestartInterval

app.MsFailoverCluster.MsClusterNode

v Descriptionv EnableEventLogReplicationv InitialLoadInfov LastLoadInfov Namev NodeHighestVersionv NodeLowestVersionv System

app.MsFailoverCluster.MsClusterResource

v AppServersv CryptoCheckpointsv DeadlockTimeoutv DebugPrefixv DeleteRequiresAllNodesv DependsOnResourcesv Descriptionv HasSeparateMonitorv IpAddressesv IsAlivePollInterval


v IsCoreResourcev IsLocalQuorumCapablev IsPersistentStatev IsQuorumCapablev LooksAlivePollIntervalv Namev PendingTimeoutv RegistryCheckpointsv RestartActionv RestartDelayv RestartPeriodv RestartThresholdv RetryPeriodOnFailurev Type

app.MsFailoverCluster.MsClusterResourceGroup

v AntiAffinityClassNamesv AutoFailbackTypev Descriptionv FailbackWindowEndv FailbackWindowStartv FailoverPeriodv FailoverThresholdv IsPersistentStatev Namev Parentv Resources



A domain level account that is a member of the administrators group is required.To configure the access list, complete the following steps:1. Select ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password).

An account with administrator privileges must be used.



Chapter 18. Microsoft Cluster sensor 123

Fix Pack 2

com.ibm.cdb.topomgr.topobuilder.agents.MSClusterAgent.setComputer

SystemMSClusterRel=falseThis property specifies whether MS Cluster Topology Builder Agent setsthe relationship between ComputerSystem and MSCluster. If this property isset to true, the relationship is set.


Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft Clustersensor and presents solutions for those problems.

WMI service crashes

ProblemWMI service crashes on target during discovery.

SolutionEnsure that all WMI-related fixes, including fix KB933061, are applied onthe target system. If problems persist, use the following Microsoft utilitiesto troubleshoot WMI problems:

WMIDiagThe WMIDiag utility is available at the following Web site:http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en

Follow the instructions to install and run the utility, and verify thatWMI is working correctly.


http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en



Chapter 19. Microsoft Exchange sensor

The Microsoft Exchange sensor discovers Microsoft Exchange servers.

For the supported versions of Microsoft Exchange servers, see Sensors andsupported target systems document.

Notes:

v In TADDM releases prior to TADDM 7.2.2, this sensor was named MicrosoftExchange 2007 Server sensor.

v The Microsoft Exchange sensor supports only script-based and asynchronousdiscovery. It does not support regular discoveries.


ExchangeSensor

Prerequisites

The sensor uses the Exchange Management Tools that are included with MicrosoftExchange Server 2007 and Microsoft Exchange Server 2010.

If you are using Microsoft Exchange Server 2007 to verify that the user accountpermissions are correct, run the following command on the Exchange Server whilelogged in as the TADDM discovery account:C:\> powershell Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin;Get-ExchangeServer

If you are using Microsoft Exchange Server 2010 to verify that the user accountpermissions are correct, run the following command on the Exchange Server whilelogged in as the TADDM discovery account:C:\> powershell Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010;Get-ExchangeServer

Limitations

In the Exchange Server cluster environment, the sensor discovers only the activemailbox server.

Model objects with associated attributesThe Microsoft Exchange sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects aboutMicrosoft Exchange Server resources in your IT environment.


app.messaging.exchange.AcceptedDomain

v AcceptedDomainNamev Defaultv DistinguishedNamev DomainName


https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d5ebce8-2dd8-449c-a58e-4676134e3eb8#fullpageWidgetId=Wea1cb2531f10_4ccd_99d7_6ab0334cb21f&file=e70bf323-31f1-45ba-8992-4cb491feab4a


v DomainTypev Parent

app.messaging.exchange.ActiveSyncVirtualDirectory

v BasicAuthenticationEnabledv ClientAccessServerv ClientCertEnabledv DistinguishedNamev ExternalURLv InternalURLv Pathv RemoteDocumentsActionForUnknownServersv VirtualDirectoryNamev WebSiteNamev WebSiteSSLEnabled

app.messaging.exchange.ClientAccess

v ClientAuthenticationMethodv ExchangeProtocolsv ExternalHostNamev Hostv Namev OutlookAnywhereEnabledv PrimarySAPv ProductNamev ProductVersionv RoleNamev SSLOffloadingv VersionString

The ClientAuthenticationMethod, ExternalHostName, and SSLOffloadingattributes apply only when the Outlook Anywhere feature is enabled.

app.messaging.exchange.EdgeTransport

v AcceptedDomainsv AntiSpamUpdatesEnabledv ConnectivityLogEnabledv ConnectivityLogPathv DelayNotificationTimeoutv ExternalDNSAdapterEnabledv Hostv InternalDNSAdapterEnabledv MaxOutboundConnectionsv MaxPerDomainOutboundConnectionsv MessageExpirationTimeoutv MessageTrackingLogEnabledv MessageTrackingLogPathv ObjectType


v OutboundConnectionFailureRetryIntervalv PrimarySAPv ProductNamev ProductVersionv Queuesv ReceiveConnectorsv ReceiveProtocolLogPathv RoleNamev SendConnectorsv SendProtocolLogPathv TransientFailureRetryCountv TransientFailureRetryIntervalv TransportRulesv VersionString

app.messaging.exchange.HubTransport

v AntiSpamUpdatesEnabledv ConnectivityLogEnabledv ConnectivityLogPathv DelayNotificationTimeoutv ExternalDNSAdapterEnabledv Hostv InternalDNSAdapterEnabledv Journalsv MaxOutboundConnectionsv MaxPerDomainOutboundConnectionsv MessageClassificationsv MessageExpirationTimeoutv MessageTrackingLogEnabledv MessageTrackingLogPathv ObjectTypev OutboundConnectionFailureRetryIntervalv PrimarySAPv ProductNamev ProductVersionv Queuesv ReceiveConnectorsv ReceiveProtocolLogPathv RoleNamev SendConnectorsv SendProtocolLogPathv TransientFailureRetryCountv TransientFailureRetryIntervalv TransportRulesv VersionString

Chapter 19. Microsoft Exchange sensor 127

app.messaging.exchange.TransportServer

v AntiSpamUpdatesEnabledv ConnectivityLogEnabledv ConnectivityLogPathv DelayNotificationTimeoutv ExternalDNSAdapterEnabledv Hostv InternalDNSAdapterEnabledv MaxOutboundConnectionsv MaxPerDomainOutboundConnectionsv MessageExpirationTimeoutv MessageTrackingLogEnabledv MessageTrackingLogPathv ObjectTypev OutboundConnectionFailureRetryIntervalv PrimarySAPv ProductNamev ProductVersionv Queuesv ReceiveConnectorsv ReceiveProtocolLogPathv RoleNamev SendConnectorsv SendProtocolLogPathv TransientFailureRetryCountv TransientFailureRetryIntervalv TransportRulesv VersionString

app.messaging.exchange.ExchangeConnector

v Enabledv Fqdnv ProtocolLoggingLevel

This class is extended by the ReceiveConnector and SendConnector whichare direct subclasses of this class.

app.messaging.exchange.ExchangeJournalRule

v EmailAddressv JournalRuleIdentityv Parentv Recipientv Scope

app.messaging.exchange.ExchangeMailbox

v ActiveDirectoryGUIDv Aliasv Enabled


v LegacyDNv MailboxDisplayNamev OrganizationalUnitv Parentv PrimarySmtpAddressv RecipientTypeDetailsv UserDistinguishedName

app.messaging.exchange.ExchangeMailboxStore

v AllowFileRestorev CopyEdbFilePathv DatabaseNamev DatabasePathv DeletedItemRetentionv DistinguishedNamev IssueWarningQuotav JournalRecipientv LastFullBackupv LastIncrementalBackupv MailboxRetentionv MailboxStoreNamev Mailboxesv MaintenanceSchedulesv MountAtStartupv ProhibitSendQuotav ProhibitSendReceiveQuotav PublicFolderStorev QuotaNotificationSchedulesv RetainDeletedItemsUntilBackup

app.messaging.exchange.ExchangeProtocol

v AuthenticatedConnectionTimeoutv Bannerv DistinguishedNamev LoginTypev MaxCommandSizev MaxConnectionsv MaxConnectionsFromSingleIPv MaxConnectionsPerUserv PreAuthenticatedConnectionTimeoutv ProtocolNamev ProxyTargetPortv SSLBindingsv UnencryptedOrTLSBindingsv X509CertificateName

app.messaging.exchange.ExchangePublicFolder


v AgeLimitv Childrenv DeletedItemLifetimev MailEnabledv MaximumItemSizev Parentv Pathv PerUserReadDisabledv ProhibitPostLimitv PublicFolderNamev ReplicaAgeLimitv URLv UseDatabaseQuotaDefaultsv UseDatabaseReplicationSchedulev UsePublicStoreAgeLimitsv UsePublicStoreDeletedLifetimev WarningLimit

app.messaging.exchange.ExchangePublicFolderStore

v AllowFileRestorev CopyEdbFilePathv CustomReferralServerListv DatabaseNamev DatabasePathv DeletedItemRetentionv DistinguishedNamev IssueWarningQuotav ItemRetentionPeriodv LastFullBackupv LastIncrementalBackupv MaintenanceSchedulesv MaxItemSizev MountAtStartupv ProhibitPostQuotav PublicFolderHierarchyv PublicFolderStoreNamev PublicFoldersv QuotaNotificationSchedulesv ReplicationMessageSizev ReplicationPeriodv ReplicationSchedulesv RetainDeletedItemsUntilBackupv StorageGroupv UseCustomReferralList

app.messaging.exchange.ExchangeServer


v Accepteddomainv ActiveDirectoryDomainNamev ActiveDirectoryGUIDv AdministrativeGroupv CreationTimev DistinguishedNamev Domainv Editionv ErrorReportingEnabledv ExchangeArchitecturev ExchangeGroupv Hostv Journalsv MessageClassificationsv Namev ObjectTypev PrimarySAPv ProductIDv ProductNamev ProductVersionv Protocolsv ServerRolesv Sitev VendorNamev VersionStringv VirtualDirectories

app.messaging.exchange.ExchangeServerRole

v Namev ProductNamev ProductVersionv RoleNamev VersionString

This class is extended by the ClientAccess, TransportServer (EdgeTransportand HubTransport), and UnifiedMessagingServer which are directsubclasses of this class.

app.messaging.exchange.ExchangeVirtualDirectory

v ClientAccessServerv DistinguishedNamev ExternalURLv InternalURLv Pathv VirtualDirectoryName

This class is extended by the ActiveSyncVirtualDirectory,OABVirtualDirectory, and OwaVirtualDirectory which are direct subclassesof this class.


app.messaging.exchange.MailboxServer

v AutoDatabaseMountDialv ClusteredStorageTypev ForcedDatabaseMountAfterv Hostv Namev PrimarySAPv ProductNamev ProductVersionv RedundantMachinesv RoleNamev StorageGroupsv VersionStringv VirtualDirectories

app.messaging.exchange.OABVirtualDirectory

v PollIntervalv VirtualDirectoryName

This class extends the ExchangeVirtualDirectory class.

app.messaging.exchange.OwaVirtualDirectory

v ActiveSyncIntegrationEnabledv AllAddressListsEnabledv BasicAuthenticationv CalendarEnabledv ChangePasswordEnabledv ContactsEnabledv DefaultDomainv Descriptionv DigestAuthenticationv FormsAuthenticationv JournalEnabledv JunkEmailEnabledv LogonFormatv MailboxServerv NotesEnabledv OwaVersionv PremiumClientEnabledv PublicFoldersEnabledv RecoverDeletedItemsEnabledv RemindersAndNotificationsEnabledv RulesEnabledv SMimeEnabledv SearchFolderEnabledv SignatureEnabledv SpellCheckerEnabled


v TasksEnabledv ThemeSelectionEnabledv UMIntegrationEnabledv VirtualDirectoryNamev WebSiteNamev WindowsAuthentication

app.messaging.exchange.ReceiveConnector

v AnonymousUsersPermissionv BasicAuthRequiresTLSv BasicAuthenticationv BindAddressesv ConnectorNamev DistinguishedNamev Enabledv ExchangeAuthenticationv ExchangeLegacyServersPermissionv ExchangeServersPermissionv ExchangeUsersPermissionv ExternalAuthoritativev Fqdnv MaxMessageSizev MutualAuthTLSv PartnersPermissionv ProtocolLoggingLevelv RemoteIPRangesv TLSv WindowsAuthentication

app.messaging.exchange.SendConnector

v AddressSpacesv ConnectorNamev DistinguishedNamev DNSRoutingEnabledv DomainSecureEnabledv Enabledv Fqdnv IsScopedv MaxMessageSizev ProtocolLoggingLevelv SmartHostsv UseExternalDNSRoutersEnabled

app.messaging.exchange.TransportRule

v Commentsv Enabledv Parent


v RulePriorityv TransportRuleName

app.messaging.exchange.UMDialPlan

v DigitsInExtensionv DistinguishedNamev UMDialPlanName

app.messaging.exchange.UnifiedMessagingServer

v Hostv Languagesv MaxCallsAllowedv MaxFaxCallsAllowedv ProductNamev ProductVersionv RoleNamev StorageGroupsv UMDialPlansv VersionString



The sensor requires the credentials (user name and password) for the computersystem on which the Exchange Server is running ComputerSystem (Windows).

To configure the access list, complete the following steps:1. Select ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password) that TADDM must

use to access the Active Directory domain on which the Exchange Server isrunning. The user must be a member of the local administrators group, andmust be assigned Exchange View Only Administrator permissions on theExchange Server 2007.

3. Specify the access information (user name and password) that TADDM mustuse to access the Edge Transport server role. The Edge Transport server role ishosted on a dedicated computer and requires separate access information.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Microsoft Exchangesensor uses.

com.collation.discover.agent.ExchangeServerAgent.capturePublicFolders=trueThe default value is true, which means that the sensor discovers MicrosoftExchange public folders.

This property specifies whether public folders are discovered and stored inthe TADDM database. Depending upon the size of the environment andthe number of folders that need to be discovered, you can change the


default value to improve performance. If you set the value to false a deepdiscovery of the public folders is not performed.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft Exchangesensor and presents solutions for those problems.

The Exchange sensor does not start

ProblemThe Exchange sensor is not started.

SolutionFor Microsoft Exchange Server 2007, ensure that the following services arestarted:v Microsoft Exchange Information Store (store.exe)v Microsoft Exchange Service Host (Microsoft.Exchange.ServiceHost.exe)v Microsoft Exchange Transport (MSExchangeTransport.exe)v Microsoft Exchange Unified Messaging (umservice.exe)

Run the services.msc program to check the status of the service or checkthe status by using Windows Task Manager.

Discovery returns a Stored-0 Exchange Server in the databasemessage

ProblemThe Exchange sensor completes successfully with the following message:Stored-0 Exchange Server in the database.

SolutionNo active Exchange Server is running on the target computer system. Thepossible causes for no Exchange Server running are:v The Exchange Server is installed as a cluster node, but it is currently

inactive. For Microsoft Exchange Server 2007, start the clusteradministration program on the computer where the Exchange Server isinstalled as a cluster node. Then verify that the node is active.

v The Server is acting as a provisioning volume and is not hosting any ofthe server roles.

v Check the log file for the cause of the failure and verify that the gatewayis configured correctly.

Invalid domain credentials used

ProblemThe sensor ends with the following error message:CTJTD0835E Invalid domain credentials.

SolutionVerify that in the Access List configuration, that the access information(user name and password) is correct. Access permission to the ActiveDirectory domain on which the Exchange server is running, and not thelocal computer, must be granted.


Chapter 20. Microsoft Exchange 2003 sensor

The Microsoft Exchange 2003 sensor discovers Microsoft Exchange Server 2003.

Note: In TADDM releases prior to TADDM 7.2.2, this sensor was named MicrosoftExchange Server sensor.


Exchange2003Sensor

Prerequisites

The account TADDM uses to access the windows gateway must have an ActiveDirectory account and not a local account on the gateway.

Limitations

Note the following limitations:v In an Exchange Server clustering environment, the sensor discovers only the

active cluster node.v The sensor discovers the virtual servers for only the SMTP and X400 protocols.


The sensor creates the following model objects:v app.messaging.exchange.ExchangeAdministrativeGroupv app.messaging.exchange.ExchangeConnectorv app.messaging.exchange.ExchangeDSAccessDomainControllerv app.messaging.exchange.ExchangeFolderTreev app.messaging.exchange.ExchangeLinkv app.messaging.exchange.ExchangeMailboxv app.messaging.exchange.ExchangeMailboxStorev app.messaging.exchange.ExchangeProtocolVirtualServerv app.messaging.exchange.ExchangePublicFolderv app.messaging.exchange.ExchangePublicFolderStorev app.messaging.exchange.ExchangeQueuev app.messaging.exchange.ExchangeRoutingGroupv app.messaging.exchange.ExchangeScheduleIntervalv app.messaging.exchange.ExchangeServerv app.messaging.exchange.ExchangeStorageGroup




To configure the access list, complete the following steps:1. Select Messaging servers as the Component Type.2. Select Microsoft Exchange Server for the Vendor.3. Specify the following required information:

a. User nameb. Password

The sensor uses credentials from the access list in the following sequence:1. The sensor attempts to connect to the Microsoft Exchange Server, using

Microsoft Exchange Server user credentials from the access list.2. If step 1 fails, the sensor attempts to connect to Microsoft Exchange Server

using the Computer System (Windows) user credentials from the access list.


com.collation.discover.agent.exchange.command.timeout=600000

The default value is 600000 (in milliseconds), which is 10 minutes. Thevalue must be an integer.

This property specifies the timeout (in milliseconds) for the WMI call to getthe Exchange Server information.

If the WMI call takes a long time (which might occur in largeenvironments), you can increase this value.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft Exchange2003 sensor and presents solutions for those problems.

Sensor is not started

ProblemThe Exchange 2003 sensor is not started.

SolutionFor Microsoft Exchange Server 2003, ensure that the Microsoft ExchangeManagement service is started on the target Windows system. Run theservices.msc program to check the status of the service.

Discovery does not find any systems

ProblemThe Exchange 2003 sensor completes successfully with the followingmessage: “There was nothing to be discovered.”

SolutionNo active Exchange Server is running on the target computer system. Thefollowing lists the possible causes:


v The Exchange Management Tool is installed, but the Exchange Server isnot installed. For Microsoft Exchange Server 2003, ensure the followingthings are done:1. Start the Exchange System Manager on the computer where the

Exchange Server is installed.2. In the list of servers, verify that the local Exchange Server is

displayed.3. If the local Exchange Server is not displayed, verify that the

Microsoft Exchange Server is installed and running correctly.v The Exchange Server is installed as a cluster node, but it is currently

inactive. For Microsoft Exchange Server 2003, complete the followingsteps:1. Start the cluster administration program on the computer where the

Exchange Server is installed as a cluster node.2. Check which Exchange resource is assigned to the Exchange virtual

server.

Sensor cannot retrieve server information

ProblemThe Exchange 2003 sensor terminates with the following error message:CTDTD0811E The Exchange Server Agent is unable to retrieveinformation from the Microsoft Exchange Server

SolutionThis error message means that no output was retrieved through theWindows Management Instrumentation (WMI). For Microsoft ExchangeServer 2003, complete the following steps:1. Run the services.msc program on the target Windows system.2. Restart the Microsoft Exchange Management service.3. Run the discovery again.4. If the problem persists, see the sensors/ ExchangeServerSensor-*.log

file to determine if the problem is WMI related.

Microsoft Exchange Server 2007, 2000, and 5.5 are notdiscovered

ProblemThe Exchange 2003 sensor terminates with the following error message:CTDTD0812E No Microsoft Exchange Server is found.

SolutionThis error message means that no Exchange Server object exists in theoutput that was retrieved through the Windows ManagementInstrumentation (WMI). For Microsoft Exchange Server 2003, complete thefollowing steps:1. Run the services.msc program on the target Windows system.2. Restart the Microsoft Exchange Management service.3. Run the discovery again.4. If the problem still persists, see the sensors/ ExchangeServerSensor-

*.log file to determine if the problem is WMI related.

Chapter 20. Microsoft Exchange 2003 sensor 139

Sensor cannot access Windows Management Instrumentation(WMI) namespace

ProblemThe following message is in the sensors/ExchangeServerSensor-*.log file:System.UnauthorizedAccessException: Access denied

SolutionThe message typically means that the TADDM service account does nothave the appropriate permission to access the required WMI namespace.For Microsoft Exchange Server 2003, complete the following steps:1. Ensure that the TADDM service account has full permission for the

following WMI namespaces:Root\CIMV2Root\CIMV2\Applications\ExchangeRoot\MicrosoftExchangeV2

To configure the permission, complete the following steps:a. Click Start > Run > Open wmimgmt.msc.b. Right-click WMI Control (Local), and click Properties.c. In the WMI Control (Local) Properties window, click the Security

tab.d. Click WMI namespace, and click Security.e. In the Security window, select the following permissions to allow

the user or group:v Execute Methods

v Full Write

v Partial Write

v Provider Write

v Enable Account

v Remote Enable

v Read Security

v Edit Security

2. Ensure that the TADDM service account has enough permission for theExchange Server and Folder Tree objects. To configure the permission,complete the following steps:a. Click Start > All Programs > Microsoft Exchange > System

Manager

b. In the Exchange System Manager, expand Servers tree and find theserver object to be discovered.

c. Right-click the server and select Properties.d. In the Properties window, click the Security tab.e. Click Add, and select the user for the TADDM service account, and

click OK.f. In the Permissions for Administrator field, make sure Allow check

boxes next to the following permissions is turned on:v Read

v Execute

v Read permissions

v List contents


v Read properties

v List object

v View information store status

g. In the Exchange System Manager, expand Folders tree and find thefolder tree object to be discovered.

h. Do the same operation as described above for the server.

WMI class does not exist

ProblemThe following message appears in the sensors/ ExchangeServerSensor-*.log file:System.Management. ManagementException: Invalid class

SolutionThe message typically means that the sensor tried to refer to a WMI classthat does not exist. Possible causes include that the Exchange Server is notinstalled correctly, or the version of Exchange Server is not supported.

Only Microsoft Exchange Server 2003 is supported. Microsoft ExchangeServer 2007, 2000, and 5.5 are not discovered because these versions are notsupported.

Unexpected discovery result

ProblemThe virtual servers for the following protocols are not discovered:v HTTPv IMAP4v NNTPv POP3

SolutionFor Microsoft Exchange Server 2003, the sensor supports virtual servers foronly SMTP and X400 protocols.

Chapter 20. Microsoft Exchange 2003 sensor 141

Chapter 21. Microsoft HyperV sensor

The Microsoft HyperV sensor discovers Microsoft Windows based computersystems with the Hyper-V server. The discovery includes the host (also known asparent or root partition) and the virtualized guest computer systems (also knownas child partitions) in a Hyper-V environment.


Microsoft HyperV Sensor

Security issues

The TADDM service account on the target Hyper-V system, must be able to runthe wmic command to query the Windows Management Instrumentation (WMI)interface.

Enter the following command on one line, from the command-line interface of thetarget host system (parent partition) to verify:wmic /namespace:’\\root\virtualization’ path Msvm_VirtualSystemSettingDataget SystemName, BaseBoardSerialNumber, ElementName

Model objects with associated attributesThe Microsoft HyperV sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about MicrosoftWindows based computer systems with Microsoft Hyper-V server in your ITenvironment.


sys.ComputerSystemThe following attribute is associated with the host running the Hyper-Vsoftware:v ChildSystem (host)

sys.ComputerSystemThe following attributes are associated with the discovered objects that arevirtualized on the host:v HostSystemv IsVMIDanLPARv Manufacturerv MemorySizev Modelv Namev NumCPUsv SerialNumberv UUIDv Virtualv VirtualMachineState


app.AppServer

v Hostv MajorVersionv ProductNamev ProductVersionv VendorNamev VersionString


The Microsoft HyperV sensor uses the same Computer System (Windows) accesscredentials that are required to discover the target host (parent partition). Noadditional configuration is necessary.

Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft HyperVsensor and presents solutions for those problems.

Guest computer systems are not displayed

ProblemThe HyperV sensor ran, but where are the guests located in the DataManagement Portal after a discovery?

Solution

In the Discovered Components pane go to Inventory Summary >Computer Systems > Other Computer Systems, to find the Hyper-V guestsystems (child partitions).


Chapter 22. Microsoft IIS Web server sensor

The Microsoft IIS Web server sensor discovers Microsoft Internet InformationServices (IIS) servers.

IIsWebServiceSensor supports discovery of IIS 6.0, IISServerSensor supportsdiscovery of IIS 7.0, and later.

Restriction: The Microsoft IIS Web server sensor no longer sets theIIsParametersRow attribute for the IIsWebServer, IIsWebService, andIIsWebVirtualDir classes. Use the IIsParameters attribute instead.

Fix Pack 2

IISServerSensor discovers connection strings, which are then stored in the XMLformat in the XD attribute of the IISModule class. Basing on these connectionstrings, topology agents create dependencies between IIS module and the Oracledatabases that the module uses.

The Microsoft IIS Web server sensor discovers the tnsnames.ora file, which is usedfor setting connection strings information when the Oracle database is used. Thesensor discovers the file on the target system in the following locations in thespecified order:1. The <path entry>\..\network\admin\ directory for each path entry that is

specified in the %PATH% variable.2. The location that is specified by the com.ibm.cdb.tnsNamesLocation property.3. The Oracle client installation directory that is specified in the %PATH% variable.4. %TNSNAMES_PATH%\tnsnames.ora.5. %ORACLE_HOME%\network\admin\tnsnames.ora.

Fix Pack 4

In TADDM 7.3.0.4, and later, TADDM supports non-admin discovery of

IIS servers. For details, see “Configuring for a non-admin IIS discovery” on page147.


IIsWebServiceSensor, IISServerSensor

Prerequisites

Ensure that the following requirements are met.

Requirements for discovery of all versions of IIS

v Discovery of the computer system must succeed.

Requirements for discovery of IIS 6.0

Note: The operating systems on which IIS 6.0 targets are running werewithdrawn from support. Therefore, as the sensor has been maintained andupdated to discover new releases of the targets, the IIS 6.0 discovery mayfail.v The gateway must have the IIS Manager installed. This method ensures

that the COM classes are installed. These classes are required by theTaddmTool AdsiDump and AdsiEnum commands


v If IIS Manager is not present, install it using Add/Remove Programs inthe Windows Control Panel. Select Windows components > ApplicationServer > IIS > Install IIS Manager.

.

Requirements for discovery of IIS 7.0, and laterTo discover IIS 7.0 servers, the IIS PowerShell Snap-In must be installed onthe target server. The IIS PowerShell Snap-In is included in IISManagement Scripts and Tools. You can also download it with theappropriate package from Microsoft Download Center and install itmanually.


The sensor creates the following model objects:v app.ProcessPoolv app.web.iis.IIsModulev app.web.iis.IIsParameterv app.web.iis.IIsWebServerv app.web.iis.IIsWebServicev app.web.iis.IIsWebVirtualDirv sys.RuntimeProcess

Note: The modules that are discovered by the sensor are of the IIsWebVirtualDirclass. The sensor does not discover IIS modules and the IIsModule class is notused for IIS modules.

Configuring the sensorBefore running a discovery, you must configure the Microsoft IIS Web serversensor.


There are no specific access requirements. This sensor can be run using theComputerSystem access credentials used to discover the client.

Configuring the discovery profileYou can customize the setting for the Microsoft IIS Web server sensor byconfiguring the sensor configuration in Discovery Management Console.

If you want to customize the IIsWebServiceSensor, and IISServerSensor, create anew discovery profile in Discovery Management Console. In that profile, create anew sensor configuration, and select the Enable this configuration and disableselected configuration check box.

You can modify the following discovery profile properties:

discoverIISParametersThis property specifies whether IIS Parameters are discovered. By default,the property is set to true, which means that the parameters arediscovered.


The IIS parameters might be large and might cause performancedegradation, or out of memory errors. If you do not want to discover theseparameters, set this property to false.

Fix Pack 2 tagsToMaskThis property specifies a comma-separated list of properties in connectionstrings. Any text content of these properties in connection strings that arediscovered is masked with asterisks.

The default value of this property is password,pwd.

Note: This property is available only for IISServerSensor.

Configuring for a non-admin IIS discoveryFix Pack 4

You can configure the Microsoft IIS Web server sensor to run non-admin discoveryof IIS servers. Such discovery does not require a user with administrator rights. Inthis mode, the User Account Control (UAC) option can be enabled.

Note: Non-admin discovery is supported only with IISServerSensor, whichsupports IIS 7.0, and later.

With non-admin discovery, the User Account Control (UAC) option can beenabled. Depending on whether you use WMI or PowerShell session, you cancreate the following types of users:v For WMI session, users that are not administrators but belong to the

administrators group are supported.v For PowerShell session, users that are not administrators and do not belong to

the administrators group are supported.

ProcedureTo configure TADDM to run non-admin discovery of IIS servers, completethe following steps:1. Copy the following files to the target system:v From the $COLLATION_HOME/dist/support/bin directory:

– copyFiles.ps1

– dcomConfiguration.ps1

– iisConfiguration.ps1

– nonadmin.properties

– psSessionConfiguration.ps1

– scriptsRunner.bat

– scriptsRunner.ps1

– wmiConfiguration.ps1

– wrmConfiguration.ps1

v From the $COLLATION_HOME/dist/lib/ms/gateway directory:– TaddmWmi.pdb

– TaddmWmi.exe

– TaddmWmi.mof

– TaddmWmi.dll

2. Configure the nonadmin.properties file by updating the nonadmin.user,and nonadmin.files.path properties:

Chapter 22. Microsoft IIS Web server sensor 147

nonadmin.user=usernonadmin.wmi.namespace=rootnonadmin.files.path=pathnonadmin.permissions=Enable,MethodExecute,RemoteAccessnonadmin.components.iis7=yes

The user value is the user that you want to use for non-admindiscovery. If you specify the local user, you need to add only the username. Otherwise, provide also the domain name, for example,domain\user. The path value is the path to the directory where youcopied files in step 1. Do not modify the values of the remainingproperties.

3. Run the scriptsRunner.bat file as administrator with one of thefollowing options:v scriptsRunner.bat set -wmi - sets permissions for WMI session.v scriptsRunner.bat set -ps - sets permissions for PowerShell

session.v scriptsRunner.bat set -wmi -ps - sets permissions for both WMI

and PowerShell sessions.

If you decide not to run non-admin discoveries any longer, you can revert to theoriginal configuration. Run the scriptsRunner.bat with one of the followingoptions:v scriptsRunner.bat revert -wmi

v scriptsRunner.bat revert -ps

v scriptsRunner.bat revert -wmi -ps

Related tasks:“Configuring for a non-admin Windows discovery” on page 420You can configure the sensor to run discoveries without providing user credentialswith the administrator role.

Differences between IISServerSensor and IIsWebServiceSensorIISServerSensor and IisWebServiceSensor discover various versions of IIS. Whenthey are combined in one discovery profile, all versions of IIS that are supportedby TADDM can be discovered by using this profile.

IISServerSensorIISServerSensor is a separate sensor that supports discovery of IIS 7 andlater by using PowerShell IIS Snap-in cmdlets. This sensor supports onlyscript-based or asynchronous discovery. It uses new naming of IISmetabase properties and configuration settings. Changed attributes arestored in the existing model.

IIsWebServiceSensorIIsWebServiceSensor is an earlier sensor that supports discovery of IIS 6.0or earlier. It runs regular discovery by using the TaddmTool AdsiDump andAdsiEnum commands.

Note: For all non-default profiles, which have IIsWebServiceSensorenabled, IIsWebServiceSensor is also enabled after the migration.


Troubleshooting the sensorThis topic describes common problems that occur with the Microsoft IIS Webserver sensor and presents solutions for those problems.

Fix Pack 2

IIS module dependencies are not included in businessapplications

ProblemEven when IIS module dependencies are created, they are not included inbusiness applications.

SolutionThe IIS module dependencies are not included in business applicationsbecause the default grouping pattern configuration excludes such relations.To solve the issue, complete the following steps:1. Export the default configuration by running the bizappscli tool:

$COLLATION_HOME/sdk/bin/bizappscli.sh exportDefaultConfiguration -fconf.xml

2. Open the conf.xml file and remove the following lines:<exclude relation="{any}" source="app.web.iis.IIsModule"target="{any}"/><exclude relation="{any}" source="{any}"target="app.web.iis.IIsModule"/>

3. Import the modified configuration by running the bizappscli tool:$COLLATION_HOME/sdk/bin/bizappscli.sh importDefaultConfiguration -fconf.xml

No Web server information discovered

ProblemThe sensor does not discover any Web server information.

SolutionIf the Web server information is missing, check the logs to determine if theTaddmTool program AdsiDump and AdsiEnum commands succeeded orfailed.

Check whether the TaddmTool program QueryRegistry commandssucceeded. Two registry paths are queried.v HKLM\SOFTWARE\Microsoft\W3SVC

v HKLM\SYSTEM\CurrentControlSet\Services\W3SVC

The first key provides general software information for IIS and thesecond provides service-related information.

Web server is duplicated

ProblemDuring discovery, duplicate IIS Web servers are found. This problem canoccur when the IIS Web servers have been discovered with an earlierversion of TADDM. Earlier releases of TADDM used port 0 as the defaultlistening port. If the same servers are discovered using a different listeningport, these servers are duplicated and they cannot be automaticallymerged.


SolutionUse an SQL statement to identify duplicate IIS Web servers in the database.The following statement can be run on one line, on DB2 or Oracledatabases:selectcast(APPZ.contextip_x as VARCHAR(100)) as CONTEXT_IP, APPZ.guid_x as OLD_GUID,APPZ.displayname_x as OLD_DISPLAYNAME,APPN.guid_x as NEW_GUID, APPN.displayname_x as NEW_DISPLAYNAMEfromAPPSRVR APPZ INNER JOIN APPSRVR APPN ON APPZ.contextip_x = APPN.contextip_x ANDAPPZ.jdoclassx = APPN.jdoclassxwhereAPPZ.jdoclassx=’com.collation.topomgr.jdo.topology.app.web.iis.IIsWebServiceJdo’and APPZ.displayname_x like ’%:0’ and APPN.displayname_x not like ’%:0’

Use one of the following methods to remove the duplicates:v Merge the duplicates in the Data Management Portal.v Manually delete the old configuration items.

For more information about merging and deleting discovered configurationitems, see the Discovery tasks topic in the TADDM User's Guide.

System fails with an unknown error (0x80005000)

ProblemWhile discovering IIS8 on the Windows Server 2012 with User AccountControl turned on, the following error occurs:System.Runtime.InteropServices.COMException (0x80005000):Unknown error (0x80005000)

SolutionTo fix the problem, complete the following steps:1. On the target machine, run the Registry Editor, Regedit.exe.2. Set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\

CurrentVersion\Policies\System LocalAccountTokenFilterPolicyvalue to 1.

3. In the Control Panel window, click the Administrative Tools tab andopen Local Security Policy.

4. Expand Local Policies and click Security Options.5. Change the following policies:v Set the Behavior of the elevation prompt for administrators in

Admin Approval Mode policy to Elevate without Prompting.v Set the User Account Control: Detect application installations and

prompt for elevation policy to Disabled.

In order to configure policies on the system with Active Directory,complete the following steps:1. In the Control Panel window, click the Administrative Tools tab and

open Group Policy Management.2. Choose forest and domain and select Default Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security

Settings/Local Policies/Security options.5. Change the following policies:v Set the Behavior of the elevation prompt for administrators in

Admin Approval Mode policy to Elevate without Prompting.


v Set the User Account Control: Detect application installations andprompt for elevation policy to Disabled.

After you upgrade to 7.3, out of memory errors occur when yourun the Microsoft IIS Web server sensor

ProblemWhen you run the discovery by using the Microsoft IIS Web server sensorafter you upgraded to TADDM 7.3, out of memory errors occur.

SolutionIf in TADDM 7.2.2 you set thecom.collation.discover.agent.IIsWebServiceAgent.discoverIISParameters property to false in the collation.properties file,this is the cause of the problem. In TADDM 7.3, this property is no longerin the collation.properties file. Therefore, after the upgrade, its value isset to true.

To modify its value, open the sensor configuration in DiscoveryManagement Portal, and search for the discoverIISParameters. Set thevalue to false.


Chapter 23. NFS sensor

The NFS sensor discovers Network File System (NFS) servers.


NFSServerSensor


The sensor creates the following model objects:v sys.NFSExportv sys.NFSSAPv sys.NFSServicev sys.ServiceAccessPoint


Chapter 24. Oracle Application Server sensor

The Oracle Application Server sensor discovers Oracle Application Server servers.


OracleAppSensor and OracleAppOpmnSensor

Prerequisites

Note the following prerequisites:v Discovery of the computer system must succeed.v An Oracle Application Server account must be entered in the access list.v An account with admin privilege is required (read-only ID can work).v Oracle Application Server libraries must be made available on the TADDM

server.v Relative paths are relative to $COLLATION_HOME.v Requires two subdirectories:

– j2ee– opmn

These files can be copied or NFS mounted from an existing OracleApplication Server installation.

The required JAR files on the TADDM server are:– j2ee/home/lib/ejb.jar

– j2ee/home/lib/adminclient.jar

– j2ee/home/lib/javax77.jar

– j2ee/home/lib/jmxcluster.jar

– j2ee/home/lib/jmx_remote_api.jar

– j2ee/home/lib/jmxri.jar

– j2ee/home/oc4jclient.jar

– opmn/lib/argus.jar

– opmn/lib/ons.jar

– opmn/lib/opmnconfig.jar

– opmn/lib/optic.jar

– opmn/lib/repositorycheck.jar

v Specify the location of the files in the com.collation.oracleapp.root.dir entryin the collation.properties file.

v These files must have read privileges for the collation user.


The OracleAppAgent creates the following model objects:v app.AppConfigv app.ConfigFile.SoftwareContainerv app.j2ee.EJBv app.j2ee.EntityBean


v app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.JSPv app.j2ee.MessageDrivenBeanv app.j2ee.oracleapp.OracleAppClusterv app.j2ee.oracleapp.OracleAppConnectorModulev app.j2ee.oracleapp.OracleAppDomainv app.j2ee.oracleapp.OracleAppEJBModulev app.j2ee.oracleapp.OracleAppJ2EEApplicationv app.j2ee.oracleapp.OracleAppJ2EEServerv app.j2ee.oracleapp.OracleAppJ2EEWebSitev app.j2ee.oracleapp.OracleAppJDBCConnectionPoolv app.j2ee.oracleapp.OracleAppJDBCDataSourcev app.j2ee.oracleapp.OracleAppJDBCDriverv app.j2ee.oracleapp.OracleAppJMSDestinationv app.j2ee.oracleapp.OracleAppJMSServerv app.j2ee.oracleapp.OracleAppJSPContainerv app.j2ee.oracleapp.OracleAppJTAResourcev app.j2ee.oracleapp.OracleAppProcessManagerv app.j2ee.oracleapp.OracleAppResourceAdapterv app.j2ee.oracleapp.OracleAppServletv app.j2ee.oracleapp.OracleAppWebModulev app.j2ee.StatefulSessionBeanv app.j2ee.StatelessSessionBeanv core.LogicalContentv enums.StatusEnumv net.BindAddressv net.IpAddressv sys.ComputerSystem

The OracleAppOpmn creates the following model objects:v app.AppConfigv app.ConfigFilev app.j2ee.oracleapp.OracleAppClusterv app.j2ee.oracleapp.OracleAppProcessManagerv app.web.oracleapp.OracleAppHTTPServerv core.LogicalContentv enums.StatusEnumv net.BindAddressv net.IpAddressv sys.ComputerSystem




Add an entry to the access list for the system running the Oracle ApplicationServer.


com.collation.oracleapp.root.dir=lib/oracleappThe default value is lib/oracleapp.

This property specifies the location of the Oracle Application Serverlibraries on the TADDM server.

You can specify an absolute or relative path for the directory location. Ifthe value for this property is a relative path directory, the relative path isappended to the $COLLATION_HOME path.

com.collation.platform.os.ignoreLoopbackProcesses=trueThe default value is true, which means that the processes that are listeningon loopback interfaces are ignored. Therefore, if a server is listening onlyon the loopback IP address (127.0.0.1), and not on any other externallyavailable IP address, that server will not be discovered.

This property controls the discovery of external IP addresses.

If the value of this property is set to false, all processes with listeningports are considered for discovery.

You must set this property to true if you want to discover an OracleApplication Server or the WebLogic sensors. For example, if theWeblogicServerVersionSensor sensor tries to start using a local hostaddress, this property must be set to true.

Troubleshooting the sensorThis topic describes common problems that occur with the Oracle ApplicationServer sensor and presents solutions for those problems.


ProblemThe lsof program is not properly set up to return information about allprocesses.

SolutionEnsure that you discover a supported version of Oracle Application Server.

The Oracle Application Sensor runs the opmnctl status command. Verifythat the system user that is used for discovery has privileges to run thiscommand.

The following list describes other possible reasons why the sensor does notstart:

Chapter 24. Oracle Application Server sensor 157

v The LiSt Open Files (lsof) program is not correctly set up to returninformation about all processes. One of the following requirements forrunning the lsof program must be met:– The setuid (set user ID) access right flag must be set for the lsof

program file.– The user must use the sudo command to run the lsof program.

v The value of the com.collation.platform.os.ignoreLoopbackProcessesproperty in the $COLLATION_HOME/etc/collation.properties file is set tofalse. The value must be set to true for the sensor to start. A value oftrue specifies that the processes that are listening on loopback interfacesare to be ignored.

v The Oracle Application Server libraries are not available on the TADDMserver. Oracle Application Server libraries must be made available on theTADDM server. Use the following property to specify the location ofthese libraries:com.collation.oracleapp.root.dir=lib/oracleapp

The default value for this property is lib/oracleapp. If the value for thisproperty is a relative directory, the directory is relative to$COLLATION_HOME, as shown in the following example:$COLLATION_HOME/lib/oracleapp.Whether the path is relative or absolute, the path must contain thefollowing two subdirectories:– j2ee– opmnThe Oracle Application Server libraries can be copied, or mounted usingthe Network File System (NFS), from an existing Oracle ApplicationServer installation. The following list identifies the required jar files:– j2ee/home/lib/ejb.jar– j2ee/home/lib/adminclient.jar– j2ee/home/lib/javax77.jar– j2ee/home/lib/jmxcluster.jar– j2ee/home/lib/jmx_remote_api.jar– j2ee/home/lib/jmxri.jar– j2ee/home/oc4jclient.jar– opmn/lib/argus.jar– opmn/lib/ons.jar– opmn/lib/opmnconfig.jar– opmn/lib/optic.jar– opmn/lib/repositorycheck.jar

The Oracle Application Server sensor fails

ProblemOracle Application Server discovery is not supported on all platforms.

SolutionEnsure that TADDM supports discovery of the Oracle Application Serveron your operating system.


Sensor fails in remote server

ProblemThe sensor fails in the remote server with an Agent terminated afterexceeding time limitnull error.

TADDM cannot find the Oracle Application Server libraries.

SolutionCheck the setting of the com.collation.oracleapp.root.dir property.

Sensor fails when trying to run discoverOpmnctl() method

ProblemThe sensor fails when it tries to run the discoverOpmnctl() method. Thepath of the TADDM service account on the Oracle Application Serversystem does not include the bin directory of the Oracle Application Serveror the user has no read/execute privileges to run the opmnctl statuscommand.

SolutionAdd the bin directory of the Oracle Application Server to the path of theTADDM service account on the Oracle Application Server system.

Sensor fails in remote server with Name not found errormessage in log file

ProblemThe sensor fails and the following error is displayed in the log file:javax.naming.NameNotFoundException: oc4j:internal/ResourceFinder not found

SolutionAdd the IP address and host name of the Oracle Application Server to the/etc/hosts file on the TADDM server.

Chapter 24. Oracle Application Server sensor 159

Chapter 25. Oracle VM sensor

Fix Pack 4

The Oracle VM sensor discovers major elements of the Oracle VM server, whichare server pools, VM servers, and VM virtual machines.

The sensor is started after the Port sensor.

Supported target systems

For the list of target systems that this sensor supports, see the TADDM 7.3 Sensorsand supported target systems PDF.


OracleVMSensor

Prerequisitesv Create a discovery user. Set the read-only permission for this user.v Open a port for communication between the TADDM server and Oracle VM

Manager. By default, it is port 7002. If you use a different port, specify itsnumber in the httpsPort property in the discovery profile of the sensor.

v Make sure that the Oracle VM Manager is running.

Connection to servers with SSL certificates

The Oracle VM sensor can connect to Oracle VM Manager server with SSL in twomodes - the default mode and the strict mode.

The default modeThe default mode does not fully verify the certificate of a server. Thismode allows connection even if the certificate is self-signed, expired orwith an invalid host name. It rejects connection when other problems arefound, like certificate chaining error. The default mode can be used withthe default Oracle VM certificates.

The strict modeThe strict mode fully verifies the certificate of a server. You can enable thismode by setting the strictCertificateCheck configuration property totrue in the discovery profile of the sensor.

When this mode is enabled, only valid certificates that are signed bytrusted certificate authorities are accepted. Before you can connect by usingsuch certificate, you must import it to TADDM. Though self-signedcertificates are trusted certificates, their validity is still verified.To import such certificates, complete the following steps:1. Go to the taddm/dist/osgi/plugins/

com.ibm.cdb.discover.sys.vmware.vmwarecommon_* directory, where * isthe version number of the sensor.

2. From the specified directory, run the following command:java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector OracleVM IP:port




where IP is the IP address of the Oracle VM Manager server host, andport is the SSL port of that host. For example:java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector OracleVM 12.234.255.4:7002

Discovering more detailed data

The Oracle VM sensor discovers basic information about Oracle VM serverinfrastructure. If you want to discover more detailed information, for exampleabout VM virtual machines, you can run the appropriate computer system sensors.For example, if the virtual machines run Linux operating system, you can runLinux computer system sensor. After the discovery, the objects created by bothsensors are merged into one object which contains complete data for thediscovered virtual machine.

Configuring the Oracle VM sensorBefore running a discovery, you must configure the Oracle VM sensor.

Configuring the access listYou must specify the correct access details for the Oracle VM sensor.

To configure the access list, complete the following steps:1. Select Oracle VM as the Component Type.2. Specify the access information (user name and password) of the discovery user

that you created for this sensor. For details, see “Prerequisites” on page 161.

Configuring the discovery profileYou can configure the Oracle VM sensor by modifying attributes in the discoveryprofile.

You can configure the Oracle VM sensor in the Discovery Management Console bysetting the following attributes:

strictCertificateCheckIf set to true, the sensor fully verifies the certificates of the Oracle VMManager servers. The certificates must be valid and signed by trustedcertificate authorities.


httpsPortThis property specifies a port number used for communication between theTADDM server and the Oracle VM Manager.


Model objects with associated attributesThe Oracle VM sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about the OracleVM infrastructure.


app.AppServer


v PrimarySAP

dev.StorageVolume

v Capacityv ManagedSystemNamev Namev Typev XAv XD

net.IpInterface

v IpAddressv L2Interfacev Parent

net.L2Interface (for VM Network)

v HwAddressv Namev Parent

net.L2Interface (for VM Server)

v HwAddressv Mtuv Name

phys.physcomp.CPUCore

v IndexOrderv MasterCPUv State

simple.SLogicalGroup

v Descriptionv HierarchyDomainv HierarchyTypev Namev OpenId

storage.StoragePool

v Descriptionv GroupMembersv HierarchyDomainv HierarchyTypev Membersv Namev OpenId

sys.linux.LinuxUnitaryComputerSystem (for the Oracle VM Server)

v Descriptionv Manufacturerv Modelv Name

Chapter 25. Oracle VM sensor 163

v OSNamev OSVersionv SerialNumberv UUID

Multiple Oracle virtual machines, such as the following systems:

sys.ComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.windows.WindowsComputerSystem

The following attributes are associated with these model objects:v Hostv MemorySizev Namev NumCPUsv SystemBoardUUIDv UUIDv VirtualMachineStatev Virtual


Chapter 26. SAP CCMS server sensor

The SAP CCMS server sensor discovers SAP systems, SAP servers (ABAP andJava), and SAP components.


CCMSServerSensor

Prerequisites

The SAP CCMS server sensor requires JCo libraries to function. For informationabout JCo libraries, see “Installing the SAP Java Connector (JCo) libraries.”

Depending on the specific application of SAP NetWeaver systems, you can use theSAP CCMS server sensor, the SAP SLD server sensor, or both to discover thissystem. SAP applications are installed on two different database schemasdepending on the application, and each are accessed by their respective runtimeenvironments. There is a runtime environment for Java instances (Java stack) andone for the Advanced Business Application Programming (ABAP) instances (ABAPstack):v Use the SAP CCMS server sensor to discover information where the SAP

NetWeaver system has applications based only on the ABAP stack.v Use the SAP SLD server sensor to discover information where the SAP

NetWeaver system has applications based only on the Java stack.v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to

discover information where the SAP NetWeaver system has applications basedon both the ABAP and Java stacks.


Installing the SAP Java Connector (JCo) librariesYou must install the SAP Java Connector (JCo) 2.x libraries for the specificoperating systems of the TADDM servers and/or anchors in the TADDMenvironment.

To install the JCo library files, complete the following steps, where operating_systemrepresents AIX, Linux, Linuxs390x, or Windows:1. Choose the appropriate SAP JCo libraries that are shipped with TADDM. The

only version shipped with TADDM is 2.1 32bit.The following table lists the typical name format of the SAP JCo librarypackages, listed by operating system.

Table 13. Package names of the SAP JCo 2.x library files

Operating system Package name

AIX (32-bit) sapjco21P_10-10002239.zip

AIX (64-bit) sapjco21P_10-10002882.zip


Table 13. Package names of the SAP JCo 2.x library files (continued)

Operating system Package name

Windows Server on x86_32 (32-bit) sapjco21P_10-10002243.zip

Windows on x86_64(64-bit) sapjco21P_10-20001730.zip

Linux on x86_32 (32-bit) sapjco21P_10-20007301.zip

Linux on x86_64 (64-bit) sapjco21P_10-20007300.zip

Linux on zSeries (64-bit) sapjco21P_10-10002245.zip

Linux on Power® (64-bit) sapjco21P_10-20007302.zip

2. Back up the following directory: $COLLATION_HOME/lib/JCo/operating_system.3. Copy the following files from the package to the following directories:

For UNIX or Linux operating systems:v librfccm.* to $COLLATION_HOME/lib/JCo/operating_systemv libsapjcorfc.so to $COLLATION_HOME/lib/JCo/operating_systemv sapjco.jar to $COLLATION_HOME/lib/JCo/operating_system/libFor Windows operating systems:v librf32.dll to $COLLATION_HOME/lib/JCo/operating_systemv sapjcorfc.dll to $COLLATION_HOME/lib/JCo/operating_systemv sapjco.jar to $COLLATION_HOME/lib/JCo/operating_system/lib


Run the ldd command against the libraries to see the dependencies, and ensurethat the dependencies are supported. The base operating system supports most ofthe dependencies.

On the Linux operating system, the libstdc++-libc6.2-2.so.3 library might not beinstalled by default. In that case, you must install the Red Hat packagecompat-libstdc++-296 to get the libstdc++-libc6.2-2.so.3 library files.

If the library dependencies are not supported, the following message is shown:Sensor failed in remote server: JCO.classInitialize (): Could not load middleware layer’com.sap.mw.jco.rfc.MiddlewareRFC’ JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc[Can’t find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.path or java.library.path sun.boot.library.path={full-path-list}


To configure the access list, complete the following steps:1. Select Computing Center Management System (CCMS) as the Component

Type.2. Specify the following required information:

a. User name (The user name must have at least all the authorizationsmentioned in the following list)

b. Passwordc. Client ID


The following lists the authorizations that are required by the SAP user being usedfor CCMS sensor discovery. Grant all (*) privileges to the following authorizationobjects:

S_RFCAuthorization Check for RFC Access

S_ADMI_FCDSystem Authorizations

S_DATASETAuthorization for file access.

The minimum permissions are:v READv READ with FILTER

Important: Do not grant all (*) permissions.

S_LOG_COMAuthorization to Execute Logical Operating System Commands

S_RZL_ADMCC Control Station: System Administration

The minimum permissions are:v DISPLAY

Important: Do not grant all (*) permissions.

S_XMI_LOGInternal Access Authorization for XMI Log

S_XMI_PRODAuthorization for External Management Interfaces (XMI)






Troubleshooting the sensorThis topic describes common problems that occur with the SAP CCMS serversensor and presents solutions for those problems.

Chapter 26. SAP CCMS server sensor 167


ProblemThe following errors occur, which means that the class path does notcontain the path for the sapjco.jar file:Sensor failed in remote server: com/sap/mw/jco/JCOMSG_ERROR: java.lang.NoClassDefFoundError: com/sap/mw/jco/JCO

SolutionThe sapjco.jar file should be in the $COLLATION_HOME/lib/JCo/libdirectory, this file path should be in the class path.

Look for the following message in the DiscoverManager.log file:adding this jar file to the list: {jar-file-path}

The jar-file-path should be $COLLATION_HOME/lib/JCo/lib/sapjco.jar.

Sensor cannot find library file

ProblemThe following errors occur, which means that the sensor cannot find thelibsapjcorfc.so library file in sun.boot.library.path or injava.library.path:Sensor failed in remote server:JCO.classInitialize (): Could not load middleware layer’com.sap.mw.jco.rfc.MiddlewareRFC’JCO.nativeInit (): Could not initialize dynamic link library sapjcorfc[Can’t find library sapjcorfc (libsapjcorfc.so) in sun.boot.library.pathor java.library.path sun.boot.library.path={full-path-list}

SolutionEnsure that the libsapjcorfc.so library file is in the $COLLATION_HOME/lib/JCo/operating system path.

This library file must be of the 64-bit version, because the TADDM servers,or anchors, or both, in the TADDM environment are running a 64-bitoperating system.

Also ensure that this path is present in the full-path-list forsun.boot.library.path that is mentioned in the error message. If the pathis present, the problem might be due to library dependencies that have notbeen met. Run the ldd command against the libsapjcorfc.so library file toget a list of the library dependencies, and verify that your environmentsupports these dependencies.

No CCMS access list is provided for an IP address

ProblemThe following error occurs:ERROR collation. AnchorClient - No CCMS access list provided for:{ip-address}

This error can occur for one of the following reasons:v No access list is provided for the sensor.v The sensor cannot successfully connect to the IP address using the access

list information that is provided by the user.

SolutionIf you provided the necessary access list credentials, verify the followingitems:


v Ensure that the user ID meets the specified minimum authorizationrequirements.

v Ensure that the SAP ABAP server is accessible.v Look for the following message in the local-anchor*.log, and ensure

that the username and client-id that are specified are the ones that you set:Checking connection with username: {username} and clientID: {clientid}

You can also provide SAP_ALL authorization to the user and try toconnect to the SAP ABAP server directly through the SAP GUI, if it isavailable.

Chapter 26. SAP CCMS server sensor 169

Chapter 27. SAP SLD server sensor

The SAP SLD server sensor discovers SAP systems, SAP servers (ABAP and Java),and SAP components.


SLDServerSensor

Prerequisites

The SAP System Landscape Directory (SLD) server must be running.

Depending on the specific application of SAP NetWeaver systems, you can use theSAP CCMS server sensor, the SAP SLD server sensor, or both to discover thissystem. SAP applications are installed on two different database schemasdepending on the application, and each are accessed by their respective runtimeenvironments. There is a runtime environment for Java instances (Java stack) andone for the Advanced Business Application Programming (ABAP) instances (ABAPstack):v Use the SAP CCMS server sensor to discover information where the SAP

NetWeaver system has applications based only on the ABAP stack.v Use the SAP SLD server sensor to discover information where the SAP

NetWeaver system has applications based only on the Java stack.v Use the SAP CCMS server sensor, the SAP SLD server, or both sensors to

discover information where the SAP NetWeaver system has applications basedon both the ABAP and Java stacks.

Model objects with associated attributesThe SAP SLD server sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about the SAPsystems, SAP servers (ABAP and Java), and SAP components in your ITenvironment.


AppConfig

v Contentv Parent

Fix Pack 2 DatabaseServer

v HierarchyDomainv HierarchyTypev Hostv OpenIdv ProductVersionv VendorName


In TADDM 7.3.0.2, and later, the SAP SLD server sensor discovers alsoother databases than Oracle, DB2, and MS SQL Server databases. Forexample, it discovers the SAP HANA database. The sensor creates a newtype of model object for them, DatabaseServer. To distinguish thedatabases inside this class, the hierarchyDomain and hierarchyTypeattributes are set for each object. For example, the attributes are set to thefollowing values for the HDB object:hierarchyDomain="app.db.hdb.mysap"hierarchyType="HDBDatabaseServer"

FunctionalGroup

v Appv GroupNamev Members

MySAPABAPApplicationServer

v BasisAppSystemNumberv Hostv KeyNamev MySAPKernelReleasev PrimarySAPv ProcessPoolsv ProductNamev SAPSystemSIDv Statusv SystemHome

MySAPCluster

v SAPSystemSIDv Serversv Statusv SystemHome

MySAPClusterNode

v ClusterNodeIDv Parentv Type

MySAPDb2Instance

v Hostv Ownerv ProductVersionv SAPSystemSIDv SIDv SystemHomev VendorName

MySAPJ2EEEngineInstance

v ClusterNodesv ConfigContents - this attribute is available only for the

MySAPJ2EEEngineInstance object for which the sensor was started


v Hostv JavaInstanceIdv IsSDMv PrimarySAP - this attribute is available only for the

MySAPJ2EEEngineInstance object for which the sensor was startedv ProcessPools - this attribute is available only if the

MySAPJ2EEEngineInstance object is a member of the SAPSystem objectv SAPSystemSIDv Status - this attribute is available only if the MySAPJ2EEEngineInstance

object is a member of the SAPSystem objectv SystemHomev VersioningAndPatchInfo

MySAPJavaCentralSystem

v ClusterNodesv Hostv JavaInstanceIdv IsSDMv ProcessPools - this attribute is available only if the

MySAPJavaCentralSystem object is a member of the SAPSystem objectv SAPSystemSIDv Status - this attribute is available only if the MySAPJavaCentralSystem

object is a member of the SAPSystem objectv SystemHomev VersioningAndPatchInfo

MySAPOracleInstance

v Homev Hostv HostNamev Ownerv ProductVersionv SAPSystemSIDv SIDv SystemHomev VendorName

MySAPSqlServer

v Hostv KeyNamev Ownerv ProductNamev ProductVersionv SAPSystemSIDv SIDv SystemHomev VendorName

ProcessPool

Chapter 27. SAP SLD server sensor 173

v Namev Parentv RuntimeProcesses

RuntimeProcess

SAPComponent

v Descriptionv HighestSupportPackagev Namev Parentv PatchLevelv Release

SAPSystem

v AppVersionv BasisVersionv Contactv DeployedComponentsv Descriptionv Groupsv InstallationNumberv LicenseExpiryDatev Namev SAPSystemSIDv SystemHomev Vendor



To configure the access list, complete the following steps:1. Select System Landscape Directory Server as the Component Type.2. Enter the following required information, User name and Password.

You must assign the SAP_SLD_GUEST and the SAP_J2EE_GUEST roles to the SAPaccount, and depending on your configuration, you might also need to assign theSAP_J2EE_ADMIN role to the SAP account.


com.collation.discover.agent.SLDServerAgent.connectionTimeout=30The default value is 30, which means 30 seconds. The value must be aninteger.


This property specifies the maximum amount of time (in seconds) to waitfor the initial SLD connection test.

Connection timeouts are recorded in the DiscoveryManager.log file. If thesetimeouts occur, increase the value of this property.

The property can be scoped to a specific host name or IP address, asshown in the following examples:com.collation.discover.agent.SLDServerAgent.connectionTimeout.Linux.1.2.3.4=60

com.collation.discover.agent.SLDServerAgent.connectionTimeout.SunOS=45





com.collation.discover.agent.SLD.PoolSizeThis property specifies the maximum number of connection pools to bemaintained alive to an SLD server. These connections can be reused foradditional requests. The default value is 16.

com.collation.sudoCommandThis property specifies the sudo command name. The default value is sudo.

Troubleshooting the sensorThis topic describes common problems that occur with the SAP SLD server sensorand presents solutions for those problems.

SLDServerAgent connection timeout errors

ProblemSLDServerAgent connection timeout errors are found in theDiscoverManager.log file.

SolutionIn the $COLLATION_HOME/etc/collation.properties file, increase the valueof the com.collation.discover.agent.SLDServerAgent.connectionTimeoutproperty until the connection is successful.

Chapter 27. SAP SLD server sensor 175

Chapter 28. SMB server sensor

The SMB server sensor discovers Server Message Block (SMB) file servers.


SMBServerSensor


The sensor creates the following model objects:v sys.ServiceAccessPointv sys.SMBExportv sys.SMBSAPv sys.SMBService

Troubleshooting the sensorThis topic describes common problems that occur with the SMB server sensor andpresents solutions for those problems.

Error message uncaught exception results when running adiscovery

ProblemThe following message is displayed when running a discovery:Uncaught exception invoking GetSystemInfo: System.NullReferenceException:Object reference not set to an instance of an object

SolutionThis message indicates that there is a problem with Windows ManagementInstrumentation (WMI) service. For information about WMI problems andsolutions, see the Windows computer system sensor “Troubleshooting thesensor” on page 426 topic.


Chapter 29. SMS server sensor

The SMS server sensor discovers the Microsoft Systems Management Server (SMS).


SMSServerSensor

Limitations

The sensor does not discover information about SMS Server client computersystems as CDM ComputerSystem instances but instead as CDMSMSCollectionClients instances.

Therefore, the discovery of an SMS Server cannot be used in place of directdiscovery of the hosts that are part of the SMS Server infrastructure.


The sensor creates the following model objects:v app.sms.SMSAdvertizementsv app.sms.SMSCollectionsv app.sms.SMSCollectionClientsv app.sms.SMSHierarchyv app.sms.SMSPackagev app.sms.SMSProgramv app.sms.SMSQueryv app.sms.SMSReportsv app.sms.SMSResourcev app.sms.SMSServerProcessv app.sms.SMSSiteBoundariesv app.sms.SMSSiteComponentsv app.sms.SMSSiteServer



com.collation.discover.agent.SMSServerAgent.GetReportsIf set to true, SMS Report information is captured by the sensor and storedas instances of the CDM SMSReports class. The default value is false.

com.collation.discover.agent.SMSServerAgent.GetQueriesIf set to true, SMS predefined queries are captured by the sensor andstored as instances of the CDM SMSQuery class. The default value is false.


com.collation.discover.agent.SMSServerAgent.GetClientsIf set to true, information about SMS collection clients is captured by thesensor and stored as instances of the CSM SMSCollectionClients class. Thedefault value is false.

com.collation.discover.agent.SMSServerAgent.MaxNrClientsThe maximum number of clients about which information is captured bythe sensor. The default value is 100.


Chapter 30. SysImager sensor

The SysImager sensor discovers SystemImager High Performance Computing(HPC) clusters.


SysImagerServerSensor and SysImagerNodeSensor

Prerequisites

The GenericComputerSystemSensor, along with prerequisite sensors, must beenabled in the discovery profile used for discovering the SysImager cluster.


The sensor creates the following model objects:v sys.hpc.cm.ConfigurationManagementClusterv sys.hpc.cm.ConfigurationManagementNodev sys.hpc.cm.ConfigurationMangementNodeGroupv sys.hpc.cm.ConfigurationManagementClusterConfigFilev sys.hpc.cm.SysImagerNodev sys.hpc.cm.SysImagerNodeImagev sys.hpc.cm.SysImagerOverride



To configure the discovery profile, complete the following steps:1. Create a discovery profile and select agent configuration of type

SysImagerServerAgentConfiguration.2. Set the following required attributes:

masterServerNamesThe IP addresses or host names of SysImager master nodes. Thisproperty must be set to start the SysImager server sensor.

3. If appropriate, set some of the following attributes, or accept the default values.

configFileLocationThe location of the SysImager configuration file. The default value is/etc/systemimager/systemimager.conf.

clusterXMLFileLocationThe location of the SysImager cluster configuration file. The defaultvalue is /etc/systemimager/cluster.xml.


clusterConfigCommandThe command to display configuration information about theSysImager cluster. The default value is si_clusterconfig -g.

lsImageCommandThe command to display images of the SysImager cluster. The defaultvalue is si_lsimage -v.

imagesDiscoveryModeThis property is not used.

overridesDiscoveryModeThe depth of file capture for overrides. The valid values are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


overridesDiscoveryPatternThe filename pattern for files under the overrides directory. The defaultvalue is "*".

preInstallScriptsContentThe depth of file capture of the scripts executed before install. Thevalid values are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


postInstallScriptsContentThe depth of file capture of the scripts executed after install. The validvalues are as follows:v 0: No file information is captured.v 1: Only the file name and file information are captured.v 2: All file information and content are captured.


nodesScopeThe scope of the IP addresses to which the SysImager node sensors arerestricted.

doPingNodesSpecifies whether ping sensors are run against discovered SysImagernodes.


SysImagerServerSensor uses SysImager Server access entry. If this is not available,the sensor uses ComputerSystem access entry to access the SysImager server.

SysImagerNodeSensor uses ComputerSystem access entry to access SysImagernodes.


Chapter 31. Veritas cluster sensor

The Veritas cluster sensor discovers Veritas Cluster Servers.

The sensor collects general information about the Veritas Cluster Server and theservices that are installed on it. Services are organized in service groups andcontain information about the resources that are used.

The sensor can create relationships between the services and applications installedon a cluster.


VeritasClusterSensor

Security issues

The user account for discovering Computer Systems is also used for runningVeritas commands. By default, execute permission on the Veritas Cluster directoryand commands is required. The sensor uses the following commands:v hastatus

v haclus

v hasys

v hares

v hagrp

v hatype

v hauser

Before running Veritas commands, a login to the cluster is performed on systemsthat support the Veritas halogin command. These are UNIX systems with VCSversion 4.1 and higher. The sensor logs in using the user name and password fromthe High Availability Solutions access list entry.

To specify that the sensor should use sudo when running Veritas Cluster Servercommands on Linux or UNIX systems, configure the appropriate parameters in thecollation.properties file.

To run the commands without using the sudo command, the TADDM serviceaccount must be a member of the Veritas Admin Group on the target.

You must configure sudo ndd with NOPASSWORD for the access user.


The sensor creates the following model objects:v app.ConfigFilev app.SoftwareInstallationv app.veritas.cluster.VCSClusterv app.veritas.cluster.VCSHADServerv app.veritas.cluster.VCSLocalServiceGroup


v app.veritas.cluster.VCSResourceConfigurationv app.veritas.cluster.VCSServiceGroupv app.veritas.cluster.VCSSystem



The following VeritasClusterSensor attribute can be modified:

discoveryModeThe default value for the discoveryMode attribute is 1 (the sensor runs inlightweight mode).

To generate more configuration items and store them in the database,specify 0.

Alternatively, open the $COLLATION_HOME/etc/discover-sensors/VeritasClusterSensor.xml and modify the attribute.

When you use both Veritas cluster sensor and Oracle sensor to discover an Oracleinstance, duplicates might occur. This happens because Veritas cluster sensor usesthe upper case for the instance SID and Oracle sensor uses the lower case for thesame SID. To avoid this problem, modify the dist/etc/discover-sensors/VeritasClusterSensor.xml file by changing the following line:<source>Sid</source>

into the following line:<source>%{Sid}</source>

After the change, Veritas cluster sensor creates Oracle instances with the lower caseSID.

Note: If you change the line after running discoveries where no duplicatesoccurred, new duplicates might occur.


To configure the access list, complete the following steps:1. Select High Availability Solutions as the Component Type.2. Enter the following required information, User name and Password.


The following properties specify that the sensor uses sudo to elevate privilegeswhen running Veritas Cluster Server commands:v com.collation.discover.agent.command.hastatus.Linux=sudo

/opt/VRTSvcs/bin/hastatus


v com.collation.discover.agent.command.haclus.Linux=sudo/opt/VRTSvcs/bin/haclus

v com.collation.discover.agent.command.hasys.Linux=sudo /opt/VRTSvcs/bin/hasys

v com.collation.discover.agent.command.hares.Linux=sudo /opt/VRTSvcs/bin/hares

v com.collation.discover.agent.command.hagrp.Linux=sudo /opt/VRTSvcs/bin/hagrp

v com.collation.discover.agent.command.hatype.Linux=sudo/opt/VRTSvcs/bin/hatype

v com.collation.discover.agent.command.hauser.Linux=sudo/opt/VRTSvcs/bin/hauser

You can scope each property to a specific operating system or IP address, as in thefollowing examples:v com.collation.discover.agent.command.hastatus =sudo /opt/VRTSvcs/bin/

hastatus

v com.collation.discover.agent.command.hastatus.Linux=sudo/opt/VRTSvcs/bin/hastatus

v com.collation.discover.agent.command.hastatus.Linux.192.168.1.1=sudo/opt/VRTSvcs/bin/hastatus

Specify the sudo option for an operating system only if it required for all systemsrunning that operating system; otherwise, specify the option only for the specificIP addresses where the sudo command is configured. You must configure sudo nddwith NOPASSWORD for the access user.

On each target system for which privilege escalation is needed, configure the sudocommand with the NOPASSWD option. Otherwise, your discovery hangs until theTADDM server times out.

Troubleshooting the sensorThis topic describes common problems that occur with the Veritas cluster sensorand presents solutions for those problems.

The sensor fails

ProblemThe VeritasClusterSensor sensor fails.

SolutionIf the sensor fails and the logs point to some of the commands timing out,this error could indicate a failed login to the cluster. Verify that the correctuser name and password for the Veritas Cluster is used.

Chapter 31. Veritas cluster sensor 185

Chapter 32. VMware Virtual Center server sensor

The VMware Virtual Center server sensor discovers VMware Virtual Center serversand the elements that are managed by the servers. VMware Virtual Center is nowknown as VMware vCenter Server.


VirtualCenterSensor


The sensor discovers the following elements that are managed by the VirtualCenter server:v CPU resource poolsv Data centers in a virtual centerv Data store extents for VMware vSphere 4v Data stores that are created in each data centerv Distributed virtual switches, uplinks, and port groups in each distributed virtual

switchv Memory resource poolsv Serial number of ESX serversv Virtual switches and port groups in each virtual switchv VMware clusters that are created in each data centerv VMware ESX servers that are managed by a virtual centerv IP Addresses for Virtual Machines

VMware ESX servers, which are discovered by the VMware ESX and VirtualCenter server sensors, are merged after the discovery.

In the Discovery Management Console, a VM (virtual machine) is represented by acomputer system icon that is blue and transparent.

The Virtual Center server sensor uses the VMware API to discover data, and theVMware API collects the following data:v Attribute data that is required to match naming rules and to create a valid

stand-alone VM instancev Certain basic information that the VMware ESX server provides through the

vmware-cmd commandv The attribute primaryMACAddress, which is required to reconcile the shallow

virtual instance with any physical instance that can be discoveredv The attribute vmwareUUID, which is required to reconcile the virtual computer

instances that are discovered before and after migrations using VMotion.

There are four user scenarios for a Virtual Center and ESX server discovery:v All-inclusive: The discovery scope contains ESX and Virtual Center servers.

The result displays the ESX and Virtual Center servers. ESX servers that aremanaged by the Virtual Center servers are displayed in one of the data centers


or clusters in the virtual center. All virtual and physical instances, discovered bythe Virtual Center and ESX sensors are reconciled. The physical instances have avirtual attribute set to true.

v ESX server Only: The discovery scope contains ESX servers.The result displays the ESX servers that are discovered by the ESX sensor. ESXservers with typical attributes for example, model are displayed. The VirtualCenter sensor is not started.

v Virtual Center Server Only: The discovery scope contains Virtual Center servers.The result displays the ESX servers and virtual computers that are discovered bythe Virtual Center sensor.

v Virtual Center and VM: The discovery scope contains Virtual Center servers andall virtual computers.The results display all the virtual computers, with all the physical, and virtualattributes set to true. The virtual computers are displayed in the Virtual Systemstab of the respective ESX server.

Prerequisites

The VMware Virtual Center server service is running on the target windowscomputer. The VMware Virtual Centre server sensor may be started by listeningport, by process template match or both. By default, sensor is started by processtemplate match.

Restriction: This prerequisite does not apply to vCSA (Virtual Center ServerAppliance). vCSA is based on Linux technology and will be detected by TADDMusing standard permissions, without the need for further prerequisites.

Fix Pack 3

For successful discovery of VMware vCenter Server Appliance 6, ports

for Web Services communication must be defined. By default, ports 80 and 443 aredefined. If your VMware vCenter Server Appliance 6 uses non-standard ports,modify the value of the portList property in the discovery profile. For details, see“Configuring the discovery profile” on page 194.

Support discovery of Virtual Center System Appliance throughweb ports

This enhancement can allow you to discover VCSA using web interfaces. There is anew configuration option in PortScan sensor to allow the specification of VCSAlistening ports (vcsaListeningPortList) to be used to trigger seeding ofVirtualCenterSensor.

Limitationsv If port mentioned in `vcsaListeningPortList` is opened by some process other

than VCSA, the VMware Virtual Center server sensor will show error.

Security issues

To discover the VMware Virtual Center server, you must set read-only permissionsfor the TADDM service account. The service account must have administratorprivileges.


Connection to servers with SSL

The VMware Virtual Center server sensor can connect to servers with SSL in twomodes - the default mode and a new mode.

The default modeThe default mode does not fully verify the certificate of a server. Thismode allows connection even if the certificate is self-signed, expired orwith an invalid host name. It rejects connection when other problems arefound, like certificate chaining error. The default mode can be used withthe default VMware certificates.

The new modeThe new mode fully verifies the certificate of a server. You can enable thismode by setting the strictCertificateCheck configuration property totrue. When this mode is enabled, only valid certificates signed by trustedcertificate authorities are accepted.

Importing self-signed certificates to TADDMBy setting the strictCertificateCheck property to true, you can connectwith self-signed certificates. You must first import such a certificate toTADDM. Though self-signed certificates are trusted certificates, theirvalidity is still verified.

To import such certificates, complete the following steps:1. Open the taddm/dist/osgi/plugins/


2. Run the following command:java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector ip:port

where ip is the IP address of the VMware Virtual Center server sensorhost, and port is the SSL port of that host.

Recommended Configuration

You should select the configuration port logically to avoid any false seeding of theVirtualCenterSensor (VCSA). It works best if these ports are acknowledged to aunique virtual center. If there is a specific list of ports, the listed ports shall specifythe same listeners. These ports take account of the configuration changes oninstances to avoid the collision.

Example:

1. Example: 80 TCP vCenter Server requires port 80 for direct HTTPconnections. Port 80 redirects request to HTTPS port 443. Thisredirection is useful if you unintentionally use http://server instead ofhttps://server.

2. 443 TCP Default port that the vCenter Server system uses to listen forconnections from the vSphere Web Client. To enable the vCenter Serversystem to receive data from the vSphere Web Client, open port 443 inthe Firewall.

Ports 80,443 are ubiquitous ports and may appear a bad choice for seedingthe VirtualCenterSensor, since they can cause many false positives forsensor invocations. It is recommended to provision more unique port (orlists of that port's possible values in a customer deployment) that shall beused in PortScanSensors `vcsaListeningPortList`.

Chapter 32. VMware Virtual Center server sensor 189

1. 514 TCP/UDP vSphere Syslog Collector port for vCenter Server onWindows and vSphere Syslog Service port for vCenter ServerAppliance.

2. 902 TCP/UDP Default port that the vCenter Server system uses to senddata to managed hosts. Managed hosts also send a regular heartbeatover UDP port 902 to the vCenter Server system. This port must not beblocked by firewalls between the server and the hosts or between hosts.

Model objects with associated attributesThe VMware Virtual Center server sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout VMware Virtual Center resources in your IT environment.


dev.StorageExtent

v ManagedSystemNamev Name

net.IpInterface

v Name (for ESX server only)v IpAddress

net.L2Interface

v Name (for ESX server only)v HwAddress

process.CPUResourcePool

v Namev Labelv Limitv Reservationv SharesLevelv SharesValue

process.MemoryResourcePool

v Namev Labelv Limitv Reservationv SharesLevelv SharesValue

relation.AllocatedTo

v Source (MemoryResourcePool or CPUResourcePool)v Target (Memory or CPU)

relation.DonatedTo

v Source (for ESX server only)v Target (MemoryResourcePool or CPUResourcePool)

sys.CPU


v NumCPUsv Parent

sys.DNSResolveEntry (for ESX server only)

v ServerIPv Parent

sys.Memory

v MemorySizev Parent

sys.NFSFileSystem

v serverNamev MountPointv Typev Capacityv AvailableSpacev MaxFileSizev StorageExtentv FileSystemBlockSizev MaxBlocks

sys.unix.UnixFileSystem (for Virtual Machine File System)

v MountPointv Typev Capacityv AvailableSpacev MaxFileSizev StorageExtentv FileSystemBlockSizev MaxBlocks

sys.vmware.DataCenter

v Namev Labelv Parentv Systemsv Clustersv VirtualSwitches

sys.vmware.VirtualCenter

v Namev Hostv UIDv VersionStringv ApiVersionv Vendorv BuildLevelv VirtualCenterPortv MaxDBConnections


v ClientTimeoutNormalv ClientTimeoutLongv WebServiceHttpPortv WebServiceHttpsPort

sys.vmware.VMWareCluster

v Namev Labelv DPMEnabledv DRSEnabledv HAEnabledv Parentv RootMemoryResourcePoolv RootCPUResourcePool

sys.vmware.VMWareDataStore

v Namev Labelv Typev DataStoreURLv Capacityv FreeSpacev IsAccessiblev AccessModev IsMultipleHostsAccessv BasedOnv DataCenter

sys.vmware.VmwareESX

v OSNamev OSVersion

sys.vmware.VMWarePortGroup

v ActiveUplinksv L2Interfacesv Namev Parentv StandbyUplinksv Uplinks

sys.vmware.VmwareUnitaryComputerSystem

v Namev Fqdnv ObjectTypev Manufacturerv Modelv CPUSpeedv CPUTypev LifecycleState


v NumCPUsv MemorySizev AvailableMemoryForAllVMsv CurrentMemoryForAllVMsv SwapMemorySizev ServiceConsoleMemorySizev VmotionEnabled

sys.vmware.VMWareVirtualSwitch

v DataCenterv Namev MTUv NumPortsv NumPortsAvailablev ObjectTypev PortGroupsv Parentv UplinkPortGroupsv Interfaces

sys.vmware.VMWareDVUplink

v L2Interfacesv Name

Multiple virtual machines, such as the following operating systems and virtualsystems:

sys.darwin.Darwinsys.darwin.DarwinUnitaryComputerSystemsys.dos.Dossys.dos.DosUnitaryComputerSystemsys.freebsd.FreeBSDsys.freebsd.FreeBSDUnitaryComputerSystemsys.linux.Linuxsys.linux.LinuxUnitaryComputerSystemsys.netware.Netwaresys.netware.NetwareUnitaryComputerSystemsys.sun.Solarissys.sun.SunSPARCUnitaryComputerSystemsys.windows.WindowsComputerSystemsys.windows.WindowsOperatingSystem

The following attributes are associated with these model objects:v uuidv VMIDv OSNamev Fqdn (if VMware Tools are running on virtual machine)v MemorySizev NumCPUs


v FaultTolerance

Configuring the sensorBefore using the VMware Virtual Center server sensor, you must configure it.

Configuring non-administrator users to run the sensorNon-administrator user accounts must have permission to run the VMware VirtualCenter server sensor. You can assign the required permissions using the VMwareInfrastructure Client.

Note: Administrator accounts have the necessary permission by default and do notrequire this procedure.

To assign the required permissions to a non-administrator user account, completethe following steps:1. From the VMware Infrastructure Client, log on to the VMware Virtual Center

server using an administrator account.2. Click the Permissions tab.3. Assign the Read-Only role to the non-administrator user account you want to

have permission to run the sensor. For more information about how to assignroles to users, see the VMware documentation.

Configuring the discovery profileBy default, the VMware Virtual Center server sensor is enabled for a Level 3discovery. The sensor discovers all guests including guest systems that arepowered off. To discover only guest systems that are running, create a Level 3discovery profile for the VMware Virtual Center server sensor, and customize thesensor settings.

To create the discovery profile, complete the following steps:1. In the Discovery drawer of the Discovery Management Console, click

Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name and description. From

the Clone existing profile list, select Level 3 Discovery and click OK.4. On the Sensor Configuration tab, select the VirtualCenterSensor sensor and

click New.5. In the Create Configuration window, type the name and description for your

configuration, and select the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click

discoverNonRunningGuests. Then, double-click the Value field in the row, andtype false.


Properties

You can modify the following properties:

ordinalESXviaVCserialDiscoveryIt discovers a serial number by using VMware API. This is a standard way


to discover the serial number, it is faster than by using CIM API, it requiresfewer privileges, but is also more prone to errors.


directESXserialDiscoveryIt discovers a serial number by using CIM API. This method alwaysdiscovers the serial number, but is slower and the following requirementsapply:v The discovery user must have the Host > CIM > CIMInteraction

privilege.v The connection between TADDM and the ESX server is required.

For more information, see also a technote at http://www-01.ibm.com/support/docview.wss?uid=swg21638454.

Important: If you run the ESX server on virtualized hardware like CiscoUCS, you must discover the serial number by using CIM API, not VMwareAPI, because otherwise over merges might occur.


shallowVMdiscoveryIt discovers limited data for Virtual Machine.


discoverNonRunningGuestsIt discovers not running Virtual Machines.

The default value is true.

strictCertificateCheckIt forces the sensor to connect to VirtualCenter servers that are securedwith valid, CA signed certificates.


enableVMDiscoveryIt enables the discovery of Virtual Machines.


shallowESXDiscoveryIt enables shallow ESX discovery. ESX servers are discovered only with aname, datastore information, and relations to datacenter. It can be usedwith ESXi sensor for faster discovery of the whole environment.


Fix Pack 3 portListIt contains a comma-separated list of ports that are used by VMwarevCenter Server Appliance 6 for Web Services communication. Modify thevalue of this property if your VMware vCenter Server Appliance 6 usesnon-standard ports.

The default value is 80,443.


To configure the access list, enter the following information:


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


v To access the VMware Virtual Center server using an account with administratorprivileges:1. Use ComputerSystem (Windows) as the Component Type.2. Specify the access information (user name and password).

Use this method to grant access to the host computer system and theVMware Virtual Center server.

v To access the VMware Virtual Center server using an account with read-onlyprivileges:1. Use Virtual Center Server as the Component Type.2. Specify the access information (user name and password).

Use this method to discover VMware Virtual Center servers in an IBM TivoliMonitoring environment. This method grants access to the Virtual Centerserver only and does not grant access to the host computer system. In thediscovery profile include the VMware Virtual Center server sensor and theIBM Tivoli Monitoring Scope sensor.

Troubleshooting the sensorThis topic describes common problems that occur with the VMware Virtual Centerserver sensor and presents solutions for those problems.

Serial number and System ID are blank in the Details panel ofthe VMware ESX server

ProblemThe attributes Serial number and System ID are blank in the Details panelof the VMware ESX server. The attributes for the file system are notdiscovered.

SolutionTADDM uses SMASH API to connect directly to the ESX server. Make surethat the connection is open for the port that is specified in thecom.collation.discover.vmware.cimport property (by default, it is 5989),or use an anchor instead. ESX must support SMASH API.

Verify that the ESX server and Virtual Center server are included in thediscovery scope. Check the credentials, to ensure that the correctpermissions are used for accessing the ESX server and Virtual Centerserver, and run the discovery again. For the L2Interface layer, the sensoronly collects the name and hardware addresses.

The sensor fails with a timeout error

ProblemIf the Virtual Center server is managing many ESX hosts and virtualcomputers then the sensor can fail with a timeout error message, An erroroccurred. Sensor timed out.

SolutionIn the etc/collation.properties file, increase the value for the sensor torun, where value is the number of milliseconds allowed for the sensor torun:com.collation.discover.agent.VirtualCenterSensor.timeout=value

The default value is 3600000 .


Elements managed by the VMware Virtual Center server are notdiscovered

ProblemElements are not discovered on VMware vCenter Server Version 4.1running on Microsoft Windows Server 2003. The following error messagesexist:v The VirtualCenterServer log contains:

AxisFaultfaultCode: {http://xml.apache.org/axis/}HTTPfaultSubcode:faultString: (503)Service UnavailablefaultActor:faultNode:faultDetail:{}:return code: 503503 Service Unavailable {http://xml.apache.org/axis/}HttpErrorCode:503

(503)Service Unavailable )

v The VMware Virtual Center server vpxd log contains:Connection to localhost:8085 failed with error class Vmacore::SystemException(Normally allowed each socket address (protocol / network address / port)is used only once.

v Running a netstat -ban | findstr 8085 command from the VMwareVirtual Center server shows many TCP/IP Ports are left open in aLAST_ACK state.

SolutionThe behavior occurs because ephemeral ports, temporary ports that areused for client server communications, are not closed upon use. Ephemeralports are limited to a range of ports and are only valid for the duration ofthe connection. In this case, on certain Microsoft Windows operatingsystems, certain connections leave the ports in a LAST_ACK state on theVirtual Center server. The range of ports can be exhausted after a time andwhen this situation happens, connectivity can fail until a port is freed.

To prevent this event occurring, go to the Microsoft website athttp://support.microsoft.com and search for KB979230. You can thendownload and install the fix.


http://support.microsoft.com

Chapter 33. WebLogic sensor

The WebLogic sensor discovers Oracle WebLogic Server application servers andWebLogic Server version information.

The JAR files of all releases of WebLogic 9 can be used to discover all releases ofWebLogic 9 and 10.

Sensor name that is used in the GUI and logsv WeblogicSensorv WeblogicSensor2v WeblogicServerVersionSensor

Prerequisites

The WeblogicSensor sensor requires additional JAR files that are part of the OracleWebLogic Server installation. You must copy these JAR files to the followingdirectories on the TADDM server:v For Linux, AIX, and Linux on System z operating systems:

– $COLLATION_HOME/lib/weblogic/9.0

– $COLLATION_HOME/lib/weblogic/10.0

v For Windows operating systems:– %COLLATION_HOME%\lib\weblogic\9.0

– %COLLATION_HOME%\lib\weblogic\10.0

You must configure the specific name of the $COLLATION_HOME/lib/weblogic/$VERSION_DIR directory in the $COLLATION_HOME/etc/discover-sensors/WeblogicVersionSensor.xml file.

There is no limit to the number of $VERSION_DIR directories that you can createin the $COLLATION_HOME/lib/weblogic/ directory. However, each directory must beconfigured in the WeblogicVersionSensor.xml file.

Security issues

The TADDM server requires the WebLogic system login name and the passwordthat is used to log in to the WebLogic Product Console.

Limitations

TADDM does not support WebLogic discovery with the WebLogic sensor whenusing SSL.

The WebLogic sensor must not be run with the WebLogic SSH pluggable sensors inthe same discovery. Do not enable the WebLogic sensor and the WebLogic SSHpluggable sensors in the same discovery profile.



The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.j2ee.weblogic.WebLogicServerv app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEDomainv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.weblogic.WebLogicClusterv app.j2ee.weblogic.WebLogicConnectorv app.j2ee.weblogic.WebLogicConnectorModulev app.j2ee.weblogic.WebLogicDomainv app.j2ee.weblogic.WebLogicEJBModulev app.j2ee.weblogic.WebLogicJ2EEApplicationv app.j2ee.weblogic.WebLogicJDBCConnectionPoolv app.j2ee.weblogic.WebLogicJDBCDataSourcev app.j2ee.weblogic.WebLogicJDBCDriverv app.j2ee.weblogic.WebLogicJDBCMultiPoolv app.j2ee.weblogic.WebLogicJDBCTxDataSourcev app.j2ee.weblogic.WebLogicJMSServerv app.j2ee.weblogic.WebLogicJMSStorev app.j2ee.weblogic.WebLogicJTAv app.j2ee.weblogic.WebLogicMachinev app.j2ee.weblogic.WebLogicSSLSettingsv app.j2ee.weblogic.WebLogicServerv app.j2ee.weblogic.WebLogicServletv app.j2ee.weblogic.WebLogicVirtualHostv app.j2ee.weblogic.WebLogicWebContainerv app.j2ee.weblogic.WebLogicWebModulev app.ProcessPoolv app.SoftwareContainerv app.web.WebVirtualHost

Configuring the sensorBefore using the WebLogic sensor, you must configure it.

Copying JAR files to the TADDM serverYou must copy additional JAR files that are part of the Oracle WebLogic Serverinstallation to the TADDM server.

Before starting a discovery, copy the required JAR files for your WebLogic versionto the $COLLATION_HOME/lib/weblogic/$VERSION_DIR/ directory:


Table 14. Required WebLogic JAR files

WebLogic version Required JAR files

WebLogic version 9 (allreleases)

v $WEBLOGIC_HOME/server/lib/weblogic.jarv $WEBLOGIC_HOME/server/lib/webservices.jarv $WEBLOGIC_HOME/server/lib/wljmxclient.jarWebLogic version 10.0

through 10.2

WebLogic version 10.3 v $WEBLOGIC_HOME/server/lib/wlfullclient.jar

Make sure the user used to run TADDM has read access to the copied JAR files.

Creating a wlfullclient.jar for the WebLogic sensorYou must create a wlfullclient.jar file for a client application. This JAR file isrequired for WebLogic version 10.3, or later.

To create a wlfullclient.jar file for the WebLogic sensor, complete the followingsteps:1. Change to the directory where the WebLogic Server is installed:

cd WL_HOME/server/lib

2. Create the wlfullclient.jar file:java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar

where X.X.X.X is the version number of the JarBuilder module in theWL_HOME/server/lib directory. For example:java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar

3. Copy and bundle the wlfullclient.jar file with the client application.4. Add the wlfullclient.jar file to your Java class path.

Editing the WeblogicVersionSensor.xml fileYou must edit the WeblogicVersionSensor.xml file.

The configuration file is located in the following directories:v On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in

the $COLLATION_HOME/etc/discover-sensors/ directory.v On Windows operating systems, the file is in the %COLLATION_HOME%\etc\

discover-sensors\ directory.

The code sample in this section shows how to configure the directories and Javaruntime environment (JRE) using XML tags. In this example, the followingdirectories and JRE pairs are configured:v The JAR files from the lib/weblogic/10.0 directory are paired with the Java

SDK version 1.5.0 JRE.v The JAR files from the lib/weblogic/9.0 directory are paired with the Java SDK

version 1.5.0 JRE.

The <entry> tag configures the directory name used to store the WebLogic JARfiles. The WebLogic JAR files must be located in the lib/weblogic directory.

Similarly, the <jdk> tag configures the version of the Java SDK in use. The onlyvalid value is 1.5.0. If the WeblogicServerVersionSensor sensor does not recognize

Chapter 33. WebLogic sensor 201

the BEA WebLogic server that is running, you can use the<WeblogicClassPathDefault> tag to force a configuration.<SensorPlugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://www.ibm.com/xml/schemas/taddm/FixedSensorSchema.xsd">

<name>WeblogicServerVersionSensor</name><osgiId>com.ibm.cdb.discover.sensor.app.j2ee.weblogicserverversion_7.1.0</osgiId>

<sensorClassName>com.collation.discover.agent.app.j2ee.WeblogicServerVersionAgent</sensorClassName><seedClassName>com.collation.discover.seed.app.j2ee.WeblogicVersionSeed</seedClassName><resultClassName>com.collation.discover.result.app.j2ee.WeblogicVersionResult</resultClassName><convertorClassName>com.collation.discover.engine.seedfactory.WeblogicVersionConvertor</convertorClassName>

<defaultProfiles><profile>Level 3 Discovery</profile>

</defaultProfiles>

<configuration className="com.ibm.cdb.discover.sensor.configuration.WeblogicServerVersionAgentConfiguration"><weblogicClassPath>

<item><entry>10.0</entry><jdk>1.5.0</jdk>

</item><item>

<entry>9.0</entry><jdk>1.5.0</jdk>

</item></weblogicClassPath>

</configuration></SensorPlugin>

In the sample, the WeblogicServerVersionSensor sensor uses JAR files from thelib/weblogic/10.0 directory with the JRE from the Java SDK version 1.5.0 andassumes that WebLogic Server 10.x is running.

Editing the WeblogicSensor2.xml fileYou must edit the WeblogicSensor2.xml file.

The configuration file is located in the following directories:v On Linux, Solaris, AIX, and Linux on System z operating systems, the file is in

the $COLLATION_HOME/etc/discover-sensors/ directory.v On Windows operating systems, the file is in the %COLLATION_HOME%\etc\

discover-sensors\ directory.

Use the following tags to edit the WeblogicSensor2.xml file:<SensorPlugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://www.ibm.com/xml/schemas/taddm/FixedSensorSchema.xsd">

<name>WeblogicSensor2</name><osgiId>com.ibm.cdb.discover.sensor.app.j2ee.weblogic2_7.1.0</osgiId>

<sensorClassName>com.collation.discover.agent.app.j2ee.WeblogicAgent2</sensorClassName><seedClassName>com.collation.discover.seed.app.j2ee.WeblogicSeed2</seedClassName><resultClassName>com.collation.discover.result.app.j2ee.WeblogicServerResult2</resultClassName><convertorClassName>com.collation.discover.engine.seedfactory.SoftwareConvertor</convertorClassName>

<defaultProfiles><profile>Level 3 Discovery</profile>

</defaultProfiles>

<configuration className="com.ibm.cdb.discover.sensor.configuration.WeblogicServerAgent2Configuration"><allowSensorToBePooledInJVM>true</allowSensorToBePooledInJVM><domains>

<item><domainAddress>

<address>DOMAIN_IP</address><port>DOMAIN_PORT</port>

</domainAddress><addresses>

<item><address>IP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING</address><port>PORT_ ADMIN_SERVER_IS_USING </port>

</item><item>

<address>IP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING</address>

<port>PORT_ ADMIN_SERVER_IS_USING </port></item>

</addresses></item>

</domains></configuration>

</SensorPlugin>

You can use this configuration when the WebLogic server is using multipleinterfaces on the Domain Admin Server.

In this case, the value of DOMAIN_IP and DOMAIN_PORT is used instead ofIP_OF_FIRST_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING andIP_OF_SECOND_INTERFACE_ADMIN_SERVER_IS_USING:PORT_ ADMIN_SERVER_IS_USING.

Copying JAR files to discover older versions of WebLogicapplication servers

To discover servers running older versions of WebLogic, copy the JAR files to theTADDM server.

In most cases, if you have the JAR files from the current version of WebLogic, youcan also discover servers running older versions of WebLogic. When this methoddoes not work, complete the following steps:1. Run a discovery with the current set of JAR files.2. Stop the TADDM server.3. Copy the JAR files for the older or different version of the WebLogic server to

the corresponding directories.4. Start the TADDM server.5. Run the discovery for the WebLogic server.


To configure the access list, complete the following steps:1. Select Application Servers as the Component Type.2. Select Weblogic as the Vendor.3. Specify the following required information:


Ensure the WebLogic user you add to the access list has the following information:v Administrator privilegesv Password

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the WebLogic sensoruses.

Fix Pack 3

com.collation.discover.agent.WeblogicSensor.UseDomainForClusterName=falseThis property is used to customize the displayName attribute for Weblogicclusters. By default, displayName is set by using WeblogicCluster name.


Two Weblogic clusters can have the same name, but they can belong todifferent Weblogic domains. In such cases, the customization is necessary.

When this property is set to true, the ObjectDisplayNameAgentrecalculates the displayName attribute for WeblogicCluster to incorporatethe name of its WeblogicDomain. For example, if WeblogicDomain iswebl-dom-dr.mycompany.com:9111, and the cluster is webl_c1, thedisplayName for this cluster is webl-dom-dr.mycompany.com:9111:webl_c1.


After you change the value of the property, you must restart TADDM.

com.collation.agent.weblogic.domainsconfigurationUsed when the WebLogic server uses multiple interfaces on the DomainAdmin Server (domain_ipX:domain_portX is used instead oflisten_ipN:listen_portN).

The syntax of the property is as follows:com.collation.agent.weblogic.domainsconfigurationdomain_ipA:domain_portA listen_ip1:listen_port1,listen_ip2:listen_port2;domain_ipB:domain_portB ...

For example:com.collation.agent.weblogic.domainsconfiguration=

9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7001;9.158.143.20:7001-9.158.143.20:7002,9.158.143.50:7003

com.collation.agent.weblogic.protocolsBy default, this property is disabled, and the T3 protocol is used. If youuncomment this property, you can specify the list of protocols (separatedby commas) to be used by the WebLogic sensors, as shown in thefollowing example:com.collation.agent.weblogic.protocols=t3,http

In this example, the T3 protocol is the first protocol that is tried. If thisprotocol fails, the HTTP protocol is used. If you want to use the HTTPprotocol to connect to a WebLogic server instance, you must enable HTTPtunneling for that instance using the WebLogic Console.

The only valid values are t3 and http. If you code an incorrect value, suchas a value with typographical errors, the WebLogic server cannot processthe request properly and might stop.






Troubleshooting the sensorThis topic describes common problems that occur with the WebLogic sensor andpresents solutions for those problems.

Duplicate WebLogic domains might be created

ProblemDuplicate WebLogic domains might be created when a host of an adminserver of a WebLogic domain has many IP addresses.

SolutionFix Pack 3 To remove the duplicates, make sure that the

WebLogicDomainConsolidationAgent is run after the discovery ofWebLogic domains.

WebLogic sensor does not start

ProblemThe WebLogic sensor does not start.

SolutionPerform the following actions:v For each version of the WebLogic server, copy the JAR files from the

WebLogic installation to the $COLLATION_HOME/lib/weblogic/VERSIONdirectory. Verify the sensor configuration in the $COLLATION_HOME/etc/discover-sensors/WeblogicVersionSensor.xml file.

v Verify that the WebLogic Server port and IP address are reachable andthat the WebLogic server uses the Java Management Extensions (JMX)communication protocol that is supported by TADDM. Configure thecom.collation.agent.weblogic.protocols property in thecollation.properties file.

v If the WebLogic Sensor starts when using the local host address(127.0.0.1) and fails or discovers nothing, set the value of the followingproperty in the collation.properties file to true:com.collation.platform.os.ignoreLoopbackProcesses=true

WebLogic sensor fails

ProblemThe WeblogicServerVersion sensor fails.

SolutionCopy the required WebLogic JAR files to the TADDM installation (seeConfiguring the sensor for details). Alternatively, the authenticationinformation is missing or incorrect.


ProblemThe following error is in the local-anchor*.log, which typically meansthat the WebLogic security authentication information is missing orincorrect:Sensor failed in remote server:An error occurred in the null sensor.

SolutionEnsure that you have the correct security authentication information. The


TADDM server requires the WebLogic system login name and thepassword that is used to log in to the WebLogic Product Console.

Message states that nothing exists to be discovered

ProblemThe WebLogic sensor runs and completes successfully with the followingmessage:There was nothing to be discovered.

SolutionThis message occurs when you are discovering a WebLogic ApplicationServer. Although this situation is not a problem, ensure that the WebLogicsensor runs against the WebLogic Admin Server.

Sensor fails with WebLogic 10.x

ProblemThe WeblogicServerVersion sensor fails only with WebLogic 10.x.

SolutionWeblogicVersionSensor uses an external command to identify the versionof WebLogic. On some WebLogic 10.x installations, this command returnsan unexpected empty string which causes the WeblogicVersionSensor tofail.

As a workaround, use the JAR files from a WebLogic 9.x installation.WebLogic 9.x JAR files work with WebLogic 10.x.

WebLogic sensor fails to discover WebLogic AdministrationServer

ProblemWhile attempting discovery of a WebLogic Administration Server, theWebLogic sensor fails as a result of a non-functioning DNS.

SolutionDiscoveries involving the sensors related to WebLogic AdministrationServers must have working DNS. As a workaround, changecom.collation.platform.os.disableRemoteHostDNSLookups to true, andensure that the TADDM server always has the correct DNS search path.

WebLogic sensor fails due to timeout

ProblemThe WebLogic sensor fails due to timeout.

SolutionIncrease value of the com.collation.discover.agent.NAME timeout propertyin the collation.properties file, where NAME represents the name of thesensor that is configured in the XML file in the $COLLATION_HOME/etc/discover-sensors directory. The following examples show how to code thisproperty:com.collation.discover.agent.WeblogicSensor2.timeout=7200000com.collation.discover.agent.WeblogicSensor.timeout=7200000

WebLogic sensor fails after migration

ProblemThe WebLogic sensor fails after migration.


SolutionEnsure that you run the $COLLATION_HOME/bin/template-upgrade.sh script.

Sensor fails due to T3 problem

ProblemThe WeblogicServerVersion sensor fails due to inaccessible T3 protocol.

SolutionIn some installations, the T3 protocol might be blocked. In this case,configure the WebLogic Servers to use the http protocol, and configure theWeblogicSensors to use http as well.

For example:com.collation.agent.weblogic.protocols=t3,http

WeblogicServerVersion fails due to timeout when issuing aversion command

ProblemThe weblogicServerVersion times out while issuing the version command.The problem can be due to the port being blocked by the firewall. Thefollowing example shows port number 6079 is blocked by a firewall:2009-09-09 12:29:38,802 DiscoverManagerDiscoverWorker-11 WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - Executing command: -cp/opt/IBM/taddm/dist/lib/weblogic/10.0/weblogic.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/webservices.jar:/opt/IBM/taddm/dist/lib/weblogic/10.0/wljmxclient.jar -Duser.language=en -Duser.region=US weblogic.Admin -urlt3://169.70.70.100:6079 -username confadmin -password XXX VERSION 2009-09-0912:29:39,133 DiscoverManager DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUG util.OsCommand - Commandexecuted, capturing output 2009-09-09 12:33:03,526 DiscoverManagerDISCOVER_SENSOR_CLEANUP_DiscoverWorker-11WeblogicServerVersionSensor-169.70.70.100-6079 DEBUGj2ee.WeblogicServerVersionAgent - JavaCommand errorjava.lang.InterruptedException at java.lang.Object.wait(Native Method) atjava.lang.Object.wait(Object.java:231) at java.lang.Thread.join(Thread.java:680)at com.collation.platform.util.OsCommand.execute(OsCommand.java:411)

SolutionThis sensor uses a protocol other than SSH for host access, the appropriateport needs to be open between the TADDM server and the target. In caseswhen a firewall prevents direct access from the discovery server to certainhosts or devices, you can specify a computer system that does have accessto the hosts or devices to be an anchor host.

Some JDBC dependencies are not created between a WebLogicserver and database servers

ProblemTADDM discovers both the WebLogic server and a related database serverbut does not create a relation between them. Such a relation is based onthe JDBC connection properties that are defined on the application server.

Solution

The problem might be a result of one of the following issues:v The dependencies are created by the JDBCDependencyAgent that runs

in the Dependency topology agent group. Ensure that the agent is runafter the discovery of the WebLogic servers.


v The JDBCDependencyAgent processes only the recently discoveredapplication servers. If some dependencies are still missing after the agenthas run, rediscover the WebLogic servers, and wait for the topologyagents to run again.

v Ensure that the database server is one of those that supports the creationof transactional dependencies between it and the WebLogic applicationserver. The following databases are supported:– Oracle– IBM DB2– Microsoft SQL Server– Sybase


Chapter 34. WebLogic SSH sensor

The WebLogic SSH sensor parses WebLogic Server configuration files and uses thatinformation to discover WebLogic Server components and their configuration. Theset of pluggable sensors can connect to the target system using SSH, WMI, andother protocols that are supported by the generic computer system sensor.

Sensor name that is used in the GUI and logsv WeblogicLauncherSensorv WeblogicApplicationSensorv WeblogicDomainSensorv WeblogicServerSensor

Security issues

The WebLogic pluggable sensors require computer system credentials or WebLogiccredentials.

Limitations

For a discovery to run, the WebLogic pluggable sensors must have access to thedomain configuration files. The location of the domain configuration directory canbe determined by the sensor in the following specific situations:v The WebLogic server is started as a Windows service.v The WebLogic server is started as a Windows or UNIX process, and it is started

with the following argument:-Dpredefined.domain.config.dir=domain_directory

v The WebLogic server is started as a Windows or UNIX process, and it is startedwith the following argument:-Dweblogic.RootDirectory=domain_directory

v The WebLogic server is started as a UNIX process, and the location of thedomain configuration directory is set as one of the following processenvironment variables:– DOMAIN_HOME– LONG_DOMAIN_HOME– PWD– OLD_PWD– OLDPWD

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the domains subdirectory. All domains are inthe user_project_directory/domains/domain_name directory. A search for theconfiguration file is carried out in the directory and all sub directories defined inthe path for the domains.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/aaa/boot.properties, the following paths are searched for theconfig_file_name:– /home/weblogic/bea/my_user_projects/domains/domain92/


– /home/weblogic/bea/my_user_projects/domains/domain92/config/

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the servers subdirectory. The serversdirectory is located in the Domain home directory. A search for the configurationfile is carried out in the directory and all sub directories defined in the path forthe servers.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths aresearched for the config_file_name:– /home/weblogic/bea/my_user_projects/domains/domain92/

– /home/weblogic/bea/my_user_projects/domains/domain92/config/

v The WebLogic server is started as a Windows or UNIX process, and the processcontains a variable with the path to the user_project subdirectory. Theuser_projects directory is the default directory containing WebLogic projects. Asearch for the configuration file is carried out in the directory and all subdirectories defined in the path for the user_projects.For example, if a WebLogic process contains the variable-Dweblogic.system.BootIdentityFile=/home/weblogic/bea/my_user_projects/domains/domain92/servers/MS92_1/data/nodemanager/boot.properties, the following paths aresearched for the config_file_name:– /home/weblogic/bea/user_projects/domains/domain92/

– /home/weblogic/bea/user_projects/domains/domain92/config/

v The WebLogic launcher sensor configuration contains the following information:– The domain configuration directory.– The IP address on which the WebLogic administration console is listening.– The port number on which the WebLogic administration console is listening.For details, see “Configuring the sensor” on page 213.

On Windows, the WebLogic launcher sensor normally does not start if theWebLogic process is not started as a Windows service. It might start correctly if therequired environment variables have been set up.

On UNIX, when a non-typical installation has been performed, it might benecessary to set configuration information in the WebLogic launcher sensorconfiguration file.

For the WebLogic managed server, the WebLogic process name must be called withthe following argument:-Dweblogic.management.server=server_name

The WebLogic SSH pluggable sensors must not be run with the WebLogic sensor inthe same discovery, so you must not enable the WebLogic SSH pluggable sensorsand the WebLogic sensor in the same discovery profile.


The sensor creates the following model objects:v app.AppConfigv app.AppServerv app.ConfigFilev app.j2ee.weblogic.WebLogicServer


v app.j2ee.J2EEComponentv app.j2ee.J2EEDeployedObjectv app.j2ee.J2EEDomainv app.j2ee.J2EEModulev app.j2ee.J2EEResourcev app.j2ee.weblogic.WebLogicClusterv app.j2ee.weblogic.WebLogicConnectorv app.j2ee.weblogic.WebLogicConnectorModulev app.j2ee.weblogic.WebLogicDomainv app.j2ee.weblogic.WebLogicEJBModulev app.j2ee.weblogic.WebLogicJ2EEApplicationv app.j2ee.weblogic.WebLogicJDBCConnectionPoolv app.j2ee.weblogic.WebLogicJDBCDataSourcev app.j2ee.weblogic.WebLogicJDBCDriverv app.j2ee.weblogic.WebLogicJDBCMultiPoolv app.j2ee.weblogic.WebLogicJDBCTxDataSourcev app.j2ee.weblogic.WebLogicJMSServerv app.j2ee.weblogic.WebLogicJMSStorev app.j2ee.weblogic.WebLogicJTAv app.j2ee.weblogic.WebLogicMachinev app.j2ee.weblogic.WebLogicSSLSettingsv app.j2ee.weblogic.WebLogicServerv app.j2ee.weblogic.WebLogicServletv app.j2ee.weblogic.WebLogicVirtualHostv app.j2ee.weblogic.WebLogicWebContainerv app.j2ee.weblogic.WebLogicWebModulev app.ProcessPoolv app.SoftwareContainerv app.web.WebVirtualHost

Resources that the sensor discoversThis topic describes the resources that can be discovered by the WebLogicpluggable sensors, and how those discoveries work.

Information is gathered from XML configuration files on the target machine.WebLogic default properties are stored in an XSD schema, rather than XMLconfiguration files.

WebLogic launcher sensor

The WebLogic launcher sensor is started, after the generic server sensor, using apluggable template, configured in plugin.xml. It discovers most typical WebLogicinstallations, and can be manually configured if necessary.

It discovers the following information:v The path to the directory containing configuration files for the domain.v The version of WebLogic installed on the target machine.

Chapter 34. WebLogic SSH sensor 211

v Whether the target is an administration server or a managed server.v The listen IP and port of the administration server.v Basic information about the structure of the WebLogic domain and servers.

The WebLogic launcher sensor creates the following objects:v The WebLogic domain model object with only the attributes that are included in

the naming rule.v The WebLogic server model objects with only the attributes that are included in

the naming rule.

The WebLogic launcher sensor starts the following sensors:v WebLogic domain sensor for administration serverv WebLogic server sensor for administration server

WebLogic domain sensor

The WebLogic domain sensor discovers information about the full WebLogicdomain.

The following information (available in XML configuration files), is discovered:v Domain detailsv Machine detailsv Cluster detailsv SSL settingsv JTAv JDBC connection poolv JDBC data sourcev JDBC multi poolv JMS serverv Node manager settings

The WebLogic domain sensor creates the WebLogic domain object.

WebLogic server sensor

The WebLogic server sensor discovers information about the full WebLogic serverand basic information about the WebLogic domain.

The following information (available in XML configuration files), is discovered:v Server detailsv JDBC connection poolv JDBC data sourcev JDBC multi poolv JMS server

The WebLogic server sensor creates the WebLogic server model object.

The WebLogic server sensor starts the WebLogic application sensor.


WebLogic application sensor

The WebLogic application sensor discovers the WebLogic applications deployed onthe WebLogic server and the WebLogic applications deployed on the WebLogicdomain.

The following information about the deployment is stored:v Application or module, for example, J2EEApplication, EJBModule, WebModule,

or ConnectorModule.v Application or module details, including J2EEDeployedObjects, for example

WebLogicEntityEJB, WebLogicServlet, and WebLogicConnector.v Application subdeployment information.

Asynchronous and script-based discovery supportThe WebLogic SSH sensor supports asynchronous and script-based discovery.




The following sensors, which are descendants of the WeblogicLauncherSensorsensor, require no configuration:v WeblogicApplicationSensorv WeblogicDomainSensorv WeblogicServerSensor

Limitations

The last modification dates of collected configuration files are not available.


Configuring the sensorThe WebLogic pluggable sensors can be configured by editing the plugin.xmlconfiguration file.

You can perform WebLogic-specific configuration by editing the <configuration>element for the following WebLogic pluggable sensors:v WebLogic launcher sensorv WebLogic server sensorv WebLogic application sensor

WebLogic launcher sensor configuration

The plugin.xml file for the WebLogic launcher sensor is located in the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogiclaunchersensor_1.2.0directory.


Within the <configuration> element, you can configure information about theconfiguration directory for each domain. Place the information for each domain ina separate <item> element. For each domain, you can configure the followingelements:

<configDirectory>The domain configuration directory.

<adminServer>Contains information about the IP address and port number on which theWebLogic administration console is listening. The following elements areused to specify this information:

<listenAddress>The IP address on which the WebLogic administration console islistening.

<listenPort>The port number on which the WebLogic administration console islistening.

The following sample configuration file displays the typical usage of the<configuration> element, and its child elements:<configuration className="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicLauncherConfigurationItem"><domain><item><configDirectory>/opt/bea10/wl_10.0/domains/medrec/config</configDirectory><adminServer><listenAddress>127.0.0.1</listenAddress><listenPort>7011</listenPort></adminServer></item><item><configDirectory>/opt/bea/user_projects2</configDirectory><adminServer><listenAddress>127.0.0.1</listenAddress><listenPort>7002</listenPort></adminServer></item></domain></configuration>

You can also specify the location of the domain configuration directory by startingthe WebLogic server with the following argument:-Dpredefined.domain.config.dir=domain_directory

WebLogic server sensor configuration

The plugin.xml file for the WebLogic server sensor is located in the$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicserversensor_1.2.0directory.

In the plugin.xml configuration file, you can configure the following elements:

<discoverAppDescriptors>Specifies if the discovery of application descriptors is enabled. Thediscovery of application descriptors can be time consuming because thedescriptors are defined in additional configuration files on the remotemachine where WebLogic is installed.

<discoverJdbcDetails>Specifies if the discovery of JDBC descriptors is enabled. The discovery of


JDBC descriptors can be time consuming because the descriptors aredefined in additional configuration files on the remote machine whereWebLogic is installed.

The following sample configuration file displays the typical usage of the<discoverAppDescriptors> and <discoverJdbcDetails> elements:<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicServerConfigurationItem"><discoverAppDescriptors>true</discoverAppDescriptors><discoverJdbcDetails>true</discoverJdbcDetails></configuration>

WebLogic application sensor configuration

The plugin.xml file for the WebLogic application sensor is located in the followingdirectory:$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.app.j2ee.weblogic.sensor.weblogicapplicationsensor_1.2.0

In the plugin.xml configuration file, you can configure the following elements:

<discoverApplicationDetails>Specifies if the discovery of application/module details is enabled. Thediscovery of application/module descriptors (J2EE descriptors) can be timeconsuming because the descriptors are defined in additional configurationfiles on the remote machine where WebLogic is installed.

The following sample configuration file displays the typical usage of the<discoverApplicationDetails> element:<configurationclassName="com.ibm.cdb.discover.app.j2ee.weblogic.configuration.WeblogicApplicationConfigurationItem"><discoverApplicationDetails>true</discoverApplicationDetails></configuration>

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the WebLogic SSH sensoruses.

Fix Pack 3

com.collation.discover.agent.WeblogicSensor.UseDomainForClusterName=falseThis property is used to customize the displayName attribute for Weblogicclusters. By default, displayName is set by using WeblogicCluster name.Two Weblogic clusters can have the same name, but they can belong todifferent Weblogic domains. In such cases, the customization is necessary.

When this property is set to true, the ObjectDisplayNameAgentrecalculates the displayName attribute for WeblogicCluster to incorporatethe name of its WeblogicDomain. For example, if WeblogicDomain iswebl-dom-dr.mycompany.com:9111, and the cluster is webl_c1, thedisplayName for this cluster is webl-dom-dr.mycompany.com:9111:webl_c1.


After you change the value of the property, you must restart TADDM.

Troubleshooting the sensorThis topic describes common problems that occur with the WebLogic SSH sensorand presents solutions for those problems.


Duplicate WebLogic domains might be created

ProblemDuplicate WebLogic domains might be created when a host of an adminserver of a WebLogic domain has many IP addresses.

SolutionFix Pack 3 To remove the duplicates, make sure that the

WebLogicDomainConsolidationAgent is run after the discovery ofWebLogic domains.

The sensor fails with a Domain config dir not found error

ProblemThe Domain configuration directory cannot be found. Check the ps outputfor the process and verify in the limitations section that the configuration issupported.

SolutionUse one of the following methods:v Run the WebLogic server using the argument

-Dpredefined.domain.config.dir=domain_directory or–Dweblogic.RootDirectory=domain_directory

v Configure the path to the domain administrator server in the WebLogiclauncher sensor configuration. For details, see “Configuring the sensor”on page 213.

WeblogicLauncherSensor fails because the ps output is cut onHP-UX

ProblemWeblogicLauncherSensor fails when trying to discover WebLogic onHP-UX and the following error message can be found in the sensor logfile: "Cannot find server name in command line: <COMMAND LINE>". Apossible reason of this failure is the cut of a ps command output, which isa documented behavior of HP-UX.

Solution

1. Setcom.ibm.cdb.discover.WeblogicLauncherSensor.parseConfigXml=truein collation.properties.

2. Restart TADDM and run the discovery again.

If extracting the server name from the command line fails,WeblogicLauncherSensor reads it from the local configuration file(config.xml).

Some JDBC dependencies are not created between a WebLogicserver and database servers

ProblemTADDM discovers both the WebLogic server and a related database serverbut does not create a relation between them. Such a relation is based onthe JDBC connection properties that are defined on the application server.

Solution

The problem might be a result of one of the following issues:


v The dependencies are created by the JDBCDependencyAgent that runsin the Dependency topology agent group. Ensure that the agent is runafter the discovery of the WebLogic servers.

v The JDBCDependencyAgent processes only the recently discoveredapplication servers. If some dependencies are still missing after the agenthas run, rediscover the WebLogic servers, and wait for the topologyagents to run again.

v Ensure that the database server is one of those that supports the creationof transactional dependencies between it and the WebLogic applicationserver. The following databases are supported:– Oracle– IBM DB2– Microsoft SQL Server– Sybase


Chapter 35. Database sensors

Database sensors discover the databases that are used in the environment.

IBM DB2 sensorThe IBM DB2 sensor discovers IBM DB2 Universal Database (UDB) servers.


Db2Sensor and Db2WindowsSensor

Prerequisites

The sensor assumes the following prerequisites:v Discovery of the computer system must succeed.v DB2 must be installed in the instance owner's home directory.

Security issues

The DB2 user credentials must belong to the DB2 administration group.

Discovery is performed by using shell scripts that run the following DB2commands:

db2 Command line processor invocation command

db2ilistList instances command

db2set DB2 profile registry command

db2licmLicense management tool command

db2levelShow DB2 service level command

db2 get dbm cfg

Limitations

Incorrect characters can be discovered if you are using a 32-bit DB2 on a 64-bitWindows operating system. This character encoding problem is due to a limitationof the 64-bit Windows operating system, which hides commands such as chcp from32-bit applications such as the db2cmd.exe program.

If more than one version of DB2 is installed on the same Windows computersystem, the sensor cannot discover the IBM DB2 Universal Database (UDB) server.

TADDM runs the topology building process on a periodic basis. Until the topologybuilding process has completed after a discovery, the database names that aredisplayed for remote systems might not be unique. After the topology buildprocess has completed, the database name contains both the port number and theIP address of the remote database.



The sensor creates the following model objects:v app.db.db2.Db2AdminServerv app.db.db2.Db2Aliasv app.db.db2.Db2BufferPoolv app.db.db2.Db2ConfigValuev app.db.db2.Db2Containerv app.db.db2.Db2Databasev app.db.db2.Db2DatabaseConfigValuev app.db.db2.Db2Instancev app.db.db2.Db2InstanceConfigValuev app.db.db2.Db2Modulev app.db.db2.Db2Schemav app.db.db2.Db2Serverv app.db.db2.Db2ServerProcessv app.db.db2.Db2Systemv app.db.db2.Db2SystemConfigValuev app.db.db2.Db2TableSpace

Asynchronous and script-based discovery supportThe IBM DB2 sensor supports asynchronous and script-based discovery.




Limitations

The following limitations apply:v For script-based discovery, the sensor requires database credentials. If these

credentials are not provided, the sensor completes with the following error:No system detected

v Discovery of application descriptors is not supported.



To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select DB2 as the Vendor.3. Specify the following required information:



The DB2 UNIX sensor uses credentials from the access list in the followingsequence:1. The sensor searches the access list looking for the DB2 user credentials.

This is the owner of the current DB2 instance.2. If step 1 fails, the sensor attempts to connect to DB2 using each DB2 user

credential from the access list.3. If step 2 fails, the sensor attempts to connect using the Computer System user

credentials (using user credentials from the Computer System access list).

For discovery of multiple DB2 installations on a single machine: DB2, the usercredentials from the access list must belong to the DB2 administration group for allDB2 installations.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM DB2 sensor uses.

The DB2 sensor that is running on a Windows system (Db2WindowsSensor) usesthe following property:

com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout=300000

The default value is 300000. The value must be an integer.

This property specifies the maximum amount of time (in milliseconds) thatthe DB2 sensor can run the db2dfind command on a Windows system.

To be effective, the value of this property should be:v Greater than the value of the com.collation.SshSessionCommandTimeout

property, which controls the time that is allowed for the SSH commandto run on the Windows gateway. If the value of theDb2WindowsAgent.sshSessionCommandTimeout property is less than thevalue of the com.collation.SshSessionCommandTimout property, thecom.collation.SshSessionCommandTimout value is used.

v Less than the value of thecom.collation.discover.agent.Db2Sensor.timeout property (orcom.collation.discover.DefaultAgentTimeout if the DB2-specifictimeout is not set). Because the sensor can stop before it finishescollecting information, the value of the Db2Sensor timeout propertyshould be greater than thecom.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property.

If needed, you can change the values of thecom.collation.SshSessionCommandTimeout andcom.collation.discover.agent.Db2Sensor.timeout properties. Thecom.collation.discover.agent.Db2Sensor.timeout property is specific tothe DB2 sensor, and overrides the value of thecom.collation.discover.DefaultAgentTimeout property.

For the following properties, you can also specify an IP address, as shown in thefollowing example:com.collation.discover.agent.DB2Agent.db2findscript.1.2.3.4=sudo

Chapter 35. Database sensors 221

com.collation.discover.agent.DB2Agent.db2findscript=sudoThis value enables access to the db2find.sh script executed during thediscovery using the sudo command.

com.collation.discover.agent.DB2Agent.db2findschemascript=sudoThis value enables access to the db2findschema.sh script executed duringthe discovery using the sudo command.

com.collation.discover.agent.DB2Agent.systemcommand=sudoThis value enables access to the system command executed during thediscovery using the sudo command.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM DB2 sensor andpresents solutions for those problems.

The DB2 sensor fails during discovery

ProblemThe DB2 sensor is timing out during the discovery run.

SolutionIncrease the com.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property in the collation.properties file. Also, youcould increase the com.collation.discover.agent.Db2Sensor.timeoutproperty to ensure that it is always larger than thecom.collation.discover.agent.Db2WindowsAgent.sshSessionCommandTimeout property.

Dependencies exist between a database and a businessapplication but are not detected

ProblemAlthough dependencies exist between a database and a businessapplication, no dependency is detected because the user that is defined inthe discovery access list for DB2 is not the instance owner.

SolutionFor discovery processes to find the DB2 commands to list databases, theuser that is defined in the discovery access list for DB2 must source theDB2 profile in the user profile.

The Details panel for a discovered DB2 component is blank

ProblemWhen performing a discovery, the Details panel under the License tab for adiscovered DB2 component is blank. This problem affects all levels ofTADDM, on all platforms.

SolutionOn UNIX and Linux, the db2licm executable routine must have the properpermissions for the user specified in the Discovery Management Consoleas connecting to the database. To retrieve the license information, theDiscovery user must also have the primary group of the DB2 instanceowner in its group list.


CTJTP1127E The copy command fails during a DB2 discovery

ProblemThe following error message is displayed in the Discovery ManagementConsole during a discovery of DB2:CTJDT0234E The following error occurred:CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh):sh coll/bin/db2-db2find.sh.

Additionally, the following information is displayed in the DB2 sensor log:com.collation.discover.agent.AgentException: CTJDT0235E The following erroroccurred when running the DB2 discovery script (db2find.sh): sh coll/bin/db2-db2find.sh.at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:414)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.findSystems(Db2Sensor.java:275)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.discover(Db2Sensor.java:212)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:131)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1247)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:816)Caused by:com.collation.platform.session.SessionClientException: CTJTP1127E The copycommand failed for java.io.EOFException: SSHSCP1: premature EOF.at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:441)at com.collation.platform.session.Ssh2SessionClient.copyToRemote(Ssh2SessionClient.java:397)at com.collation.platform.session.SessionClientPool.copyToRemote(SessionClientPool.java:236)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.prepareScript(Db2Sensor.java:726)at com.ibm.cdb.discover.sensor.app.db.db2.Db2Sensor.runDb2Find(Db2Sensor.java:383)... 5 more

SolutionThis error message appears because the secure copy (scp) command is notin the PATH of the user ID that is being used by the remote computersystem to discover DB2.

To correct this problem, edit or create a file called environment in<taddmusr>/.ssh on the remote computer system that is being discovered.Define the <taddmusr> PATH environment variable in this file. Make surethat you include the full path to the scp command in the PATHenvironment variable.

The DB2 sensor fails with error CTJTD0234E

ProblemThe DB2 sensor fails with error CTJTD0234E and the following errormessage:Attribute not set: instances

SolutionThis message is displayed because the PATH variable does not include theDB2 commands needed by the db2find.sh script.


To correct this problem, add the required paths to the following entry inthe collation.properties file:com.collation.discover.agent.path.system_uname

If the problem still exists, you can run the sensor scripts via sudo, forwhich you must have access to such commands as db2licm and db2set. Torun the script via sudo, use the following property:com.collation.discover.agent.DB2Agent.db2findscript.1.2.3.4=sudocom.collation.discover.agent.DB2Agent.db2findschemascript.1.2.3.4=sudocom.collation.discover.agent.DB2Agent.systemcommand1.2.3.4=sudo

Warning occurs during a DB2 sensor script-based discovery

ProblemDuring the script-based discovery, the following warning message isdisplayed:CTJTD1006E Invalid data in output file in section: db2findschema

SolutionVerify that the DB2 user credentials (owners of all the DB2 instances) areadded to the access list. If the problem still exists, verify that the db2ilistcommand is working correctly on the discovered systems. For informationabout this command, see the technote that is titled “DB2ilist does notreturn the instance” at: https://www.ibm.com/support/docview.wss?uid=swg21420898.

The discovery of DB2 that runs on a non-English-languagesystem fails

ProblemWhen you want to discover non-English-language targets, for exampleJapanese DB2 servers, the discovery fails. The log files contain thefollowing message:2016-06-08 21:27:49,778 DiscoverManager

[DiscoverWorker-3]2016060821265731#Db2Sensor-37.53.105.24-60012DEBUGsession.SessionClientPool - PoolEncoding=IBM-943

ClientEncoding=IBM-943

Additionally, the output of the db2find command contains question marks,for example ?gp?: db2set -g, instead of the tilde characters, for example~gp~: db2set -g.

SolutionThe cause of the issue is that the encoding on your discovery targets isdifferent than on the TADDM server. To solve the issue, add the followingproperty to the collation.properties file:com.collation.platform.session.EncodingOverRide=UTF-8

For details, see the Discovery properties topic in the TADDM Administrator'sGuide.

IBM Informix sensorThe IBM Informix sensor discovers IBM Informix Dynamic Servers.


Informix


https://www.ibm.com/support/docview.wss?uid=swg21420898

https://www.ibm.com/support/docview.wss?uid=swg21420898

Prerequisites

The IBM Informix JDBC driver must be installed on the IBM Informix DynamicServer.

Limitations

The Informix Dynamic Server must be configured with the minimum requirementfor discovery. Add the discovery service account to the group Informix on theInformix Dynamic Server.

Model objects with associated attributesThe IBM Informix sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about IBMInformix Dynamic Server resources in your IT environment.


app.db.ids.IDSAlias

v AliasNamev Parentv Protocolv ServiceName

app.db.ids.IDSBufferPool

v BufferPoolIDv NumBuffersv Size

app.db.ids.IDSChunk

v ChunkNumberv FreeSpacev Offsetv Sizev MirrorOffsetv Parent

app.db.ids.IDSConfigValue

v ConfigIDv ConfigNamev DefaultValuev EffectiveValuev OriginalValue

app.db.ids.IDSDatabase

v DatabaseLocalev LoggingTypev Name

app.db.ids.IDSInstance

v BitSizev ConnectOption


v Homev Hostv Namev ProductNamev ProductVersionv OnConfigv Protocolv SQLHostFilev Statusv VersionString

app.db.ids.IDSSegment

v OS_SHM_ADDRv OS_SHM_IDv OS_SHM_KEYv SegmentClassv Size

app.db.ids.IDSServerProcess

v OSProcessNamev PIDv VpClassv VpID

app.db.ids.IDSSpace

v Chunksv ObjectTypev PageSizev SpaceNamev SpaceNumber

app.db.ids.IDSStartupEnvironmentVar

v StartupEnvVarNamev StartupEnvVarValue

Configuring the access listTo give the IBM Informix sensor access to the Informix Dynamic Server, you mustconfigure the access list.


contains the IP address of the Informix Dynamic Server.2. To create an access list, click the Access List icon.3. In the Access List window, click Add.4. In the Component Type field of the Access Details window, click

ComputerSystem.5. Type the credentials to access the target Informix Dynamic Server. TADDM uses

JDBC to connect to the Dynamic Server.


Troubleshooting the sensorThis topic describes common problems that occur with the IBM Informix sensorand presents solutions for those problems.

Sensor cannot retrieve server information

ProblemThe sensor cannot retrieve information as the Informix Dynamic Server isnot started.

SolutionEnter the oninit command to start the database server.

Message states that nothing exists to be discovered

ProblemThe sensor runs and completes successfully with the following message:There was nothing to be discovered.

SolutionNo active Informix instance is running on the target computer system.

TADDM cannot connect to an Informix database

ProblemThe following error is displayed in the logs:encountered error :: com.informix.asf.IfxASFException:Attempt to connect to database server database_name failed

SolutionEnsure that the connection from the TADDM server to the Informix porton the database server is open.

Microsoft SQL Server sensorThe Microsoft SQL Server sensor discovers Microsoft SQL Servers. In TADDM7.3.0.2, and later, you can use the sensor in the script-based mode.


SqlServerSensor


The sensor creates the following model objects:v db.mssql.SqlServerv db.mssql.SqlServerConfigv db.mssql.SqlServerDatabasev db.mssql.SqlServerDataFilev db.mssql.SqlServerModulev db.mssql.SqlServerProcess

Prerequisites

You must complete the following prerequisite tasks to successfully discoverMicrosoft SQL Servers.


Note: The following prerequisites are the same for regular and script-baseddiscovery.

Account configurationYou can run the discovery in the Windows or SQL authentication mode.

Windows authentication mode

v Create a new login on SQL Server for Windows domain account,which is used for the discovery of Windows operating system.The discovery is then run in the Windows authentication mode.

v Map the Windows domain account to the login that you createdin the previous step.

v On the SQL master database, assign the following roles andpermissions to the login that you created for Windows domainaccount:– public - open the Login Properties window, go to the User

Mapping page, and select public database role.– db_datareader - open the Login Properties window, go to the

User Mapping page, and select db_datareader database role.– Connect SQL - open the Login Properties window, go to the

Securables page, and grant the Connect SQL permission.– View any definition - open the Login Properties window, go

to the Securables page, and grant the View any definitionpermission.

These roles and permissions are required to access the followingtables:– sysdatabases– syscurconfigs– sysprocesses– sysobjects– syscolumns

v Open the Login Properties window and go to the Status page. Inthe setting section, for the Permission to connect to databaseengine setting, select Grant, and for the Login setting, selectEnabled.

v Ensure that the Local Administrators group has SQL access (partof the SQL authorization and configuration).

SQL authentication mode

v Create a new login on the SQL Server. Select the SQL Serverauthentication option. The discovery is then run in the SQLauthentication mode.

v On the SQL master database, assign the following roles andpermissions to the login that you created for SQL domainaccount:– public - open the Login Properties window, go to the User

Mapping page, and select public database role.– db_datareader - open the Login Properties window, go to the

User Mapping page, and select db_datareader database role.– Connect SQL - open the Login Properties window, go to the

Securables page, and grant the Connect SQL permission.


v Open the Login Properties window and go to the Status page. Inthe setting section, for the Permission to connect to databaseengine setting, select Grant, and for the Login setting, selectEnabled.

Network requirements

v Depending on the operating system, Level 2 Network Requirementsmust be met. The application is discovered by using an operating systemaccount, therefore TADDM Level 2 discovery of the server, where theapplication is installed must be successful.

v Microsoft SQL listening ports must be opened on firewalls betweenTADDM Windows gateways and the servers, where Microsoft SQL isinstalled.

Fix Pack 2 Script-based discovery requirementsIn the script-based discovery mode, install either the sqlps WindowsPowerShell module, or SqlServerProviderSnapin100 andSqlServerCmdletSnapin100 Windows PowerShell snap-ins.

Limitations

The transactional dependencies between supported application servers, IBMWebSphere, JBoss, Oracle Weblogic, and the SQL Server are only created for thelisten port that is stored in the SQL Server's primarySap attribute.

If the SQL Server uses general TCP/IP configuration, the ListenAll flag is set totrue, then the first static port is taken as its primarySAP. The rest of the ports arenot captured and thus some of the dependencies cannot be created.

If the SQL Server uses specific TCP/IP configuration for each IP interface, theListenAll flag is set to false, then the first non-loopback, Active, and Enabled IP'sfirst static port is taken as the SQL Server primarySAP. The rest of the ports and theports that are configured for other IP interfaces are not captured. Thus some of thedependencies cannot be created.

If the SQL Server uses only dynamic port configuration, the current runtime listenport, which is subject to change, is not stored in the primarySAP attribute. Instead,a dynamicPortAllocation flag is set to true to indicate it.

The dependencies that are based on the SQL Server instance name, instead of itslistening port, are always created.

Fix Pack 2

The script-based discovery mode of the Microsoft SQL Server sensor

relies on the sqlps module, which is available in Microsoft SQL Server 2008, andlater. Therefore, if you want to discover Microsoft SQL Server 2005, you must haveother instances like Microsoft SQL Server 2008, 2008 R2, or 2012 installed as well.


Configuring authentication methodsThere are two modes of authentication that TADDM can use to discover an SQLServer.

Windows integrated security authentication.


v Install SSH on the TADDM gateway as required.v For discovery that uses a gateway, enable WMI on all target Windows systems.

WMI is enabled by default.

By default, discovery using a gateway automatically installs the TADDM WMIProvider on all target Windows systems during the discovery process.

Discovering a SQL Server requires that the Windows Server must be discoverable,but also requires that additional access is granted to TADDM.

There are two modes of authentication that TADDM can use to discover an SQLServer:

Windows authenticationFor Windows authentication, you must meet the following requirements:v The Windows user used for the discovery of the SQL Server must have

the Allow Log on Locally user right on the gateway server.v The user must have privileges to log on to the SQL Server system.

Preferably the user is a domain user and the server system trusts thedomain of the gateway server.

v Add the Windows user and password to the access list for the SQLServer.

SQL Server authenticationFor SQL Server authentication, add the SQL Server user to the access listfor the SQL Server.

To determine the type of authentication you need to use, verify with your SQLServer administrator which mode the SQL Server is running. Mixed mode supportsboth types of authentication.

Configuring the access listDescribes the access details that you require, depending on your configuration.

To configure the access list, complete the following steps:1. Use Database as the Component Type.2. Use Microsoft SQL Server as the Vendor.3. Specify the following required information:


The TADDM SQL Server access list applies only to the SQL Server authorization.Always provide a separate WindowsComputer System access entry for the serverto be discoverable.

For integrated security, the Windows user ID that is used to access the gatewaydoes not need to be the same as the one that is used to connect to SQL Server.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Microsoft® SQLServer sensor uses.

Microsoft® SQL Server sensor uses the following sensor settings:


com.collation.discover.agent.SqlServerAgent.UseListeningIpThis value specifies how the display names for SQL Server instance objectsare generated.

When the property value is false, the display names for the SQL Serverinstance objects take the following form: host_fqdn + ":" +sql_server_instance_name

When the property value is true, the display names for the SQL Serverinstance objects take the following form: sql_server_listening_fqdn + ":" +sql_server_instance_name


Restriction: You must rediscover the SQL Server to make the changesvisible.

com.collation.discover.agent.SqlServerAgent.timeoutThis value specifies the length of time, in milliseconds, that the sensor runsbefore it times out.

If this property is not set, the sensor uses the default timeout that isspecified in the com.collation.discover.DefaultAgentTimeout property.

Troubleshooting the sensorProblems with the sensor might include unsuccessful authorization or discovery,and so on. However, you can recover from these problems.

Fix Pack 2

The script-based discovery of the Microsoft SQL Server sensorfails

ProblemWhen you run the Microsoft SQL Server sensor in the script-based mode,the discovery fails with the following message:There was an error while Snapins adding...

SolutionVerify that the sqlps module of Windows PowerShell is installed correctly.The script-based discovery mode of the Microsoft SQL Server sensor relieson this module. However, the module is available only in Microsoft SQLServer 2008, and later. Therefore, if you want to discover Microsoft SQLServer 2005, you must have other instances like Microsoft SQL Server 2008,2008 R2, or 2012 installed as well.

No details available for SQL Server after discovery

ProblemSQL Server is discovered but there are no details provided.

SolutionCheck that the SQL Server authorization has access to the following tables:v sysdatabasesv sys.master_filesv syscurconfigsv sysprocesses

If an SQL Server authorization is not used, check the Windowsauthorization.


Microsoft SQL discovery without datareader authority

ProblemIs it possible to discover a Microsoft SQL database without having to grantthe required db_datareader role to the entire database.

SolutionTo discover a Microsoft SQL database, without having to grant authority tothe entire database, use the following steps:v Create a user using the storage procedure from the SQL Server.v Use the sp_addlogin command to create a login that allows users to

connect to the SQL Server using SQL Server authentication.v Use the sp_grantlogin command to allow a Windows user account or

group to connect to the SQL Server using Windows authentication.v After the user is created, grant access to the following tables which are

used by SQL server sensor:sysdatabases, sys.master_files, syscurconfigs, sysprocesses

In the following example the user is taddmusr:GRANT SELECT on sysdatabases to taddmusr;GRANT SELECT on sys.master_files to taddmusr;GRANT SELECT on syscurconfigs to taddmusr;GRANT SELECT on sysprocesses to taddmusr;

ProductName attribute is not clear

ProblemThe ProductName attribute does not present enough information about theproduct.

SolutionIf you recently migrated from the previous TADDM version, you mustrediscover the Microsoft SQL Servers. The attribute includes the SQLServer version number, the ServicePack level, and the SQL Server edition.

The ProductName attribute has the following form:v Microsoft SQL Server 2008 R2 SP1 (Enterprise Edition)

Oracle sensorThe Oracle sensor discovers Oracle Database servers.


OracleSensor

Prerequisites

The following requirements must be met:v Discovery of the computer system must succeed.v Network connectivity between the TADDM server and the Oracle Listener must

be functioning.


Security issues

The Oracle user credentials used to discover an Oracle database from TADDM,must have execute privileges. To ensure that the correct privileges are granted tothe Oracle user, run the following command: grant execute on dbms_system tooracle_user;

The Oracle database account requires CONNECT privileges.

The Oracle access list user must have the following role:SELECT_CATALOG_ROLE.

To discover Oracle Automatic Storage Management (ASM), the read access must begranted to the following tables and views: dba_clusters, dba_constraints,dba_data_files, dba_db_links, dba_dimensions, dba_indexes, dba_mviews,dba_profiles, dba_role_privs, dba_roles, dba_rollback_segs, dba_segments,dba_sequences, dba_source, dba_synonyms, dba_sys_privs, dba_tab_privs,dba_tables, dba_tablespaces, dba_ts_quotas, dba_users, dba_views, global_name,gv$asm_client, gv$instance, sys.dba_tables, v$asm_diskgroup, v$backup,v$bgprocess, v$controlfile, v$database, v$datafile, v$log, v$logfile,v$parameter, v$pgastat, v$process, v$session, v$sga, v$sys_optimizer_env, andv$version.

Asynchronous and script-based discovery supportThe Oracle sensor supports asynchronous and script-based discovery.






For script-based discovery, the owner of the Oracle_home directory must be definedin the access list as the Oracle user credential. The script sensor specifically locatesthis user to run the Oracle database queries. If this user is not defined in the accesslist, the sensor returns the error “CTJTP1186E The entries in the access list are notapplicable”.

Note: The operating system user which starts the sensor by using the computersystem credentials must have the read access to the /etc/oratab or/var/opt/oracle/oratab files to become the owner of the Oracle_home directory.Complete the following steps:1. Select Database as the component type.2. Select Oracle as the vendor.3. Specify the following required information:v The operating system user name for the Oracle userv The operating system password for the Oracle user


Limitations

Some function that is provided by the Oracle sensor during a non-script-baseddiscovery is not supported in an asynchronous or script-based discovery.

The following functions are not supported:v Application descriptor discoveryv Oracle RAC discoveryv Oracle ASM discoveryv Raw schema discovery (the list of tables in the database is limited)v OracleDBLink model object discoveryv OracleListener model object discovery

Model objects with associated attributesThe Oracle sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about configuration itemsin the Oracle environment.


OracleASMAsmInstances

DiskGroups

Name

Node

Rac

OracleASMDiskAsmDiskGroup

State

Name

OracleASMDiskGroupAsm

AsmDisks

Name

State

OracleASMInstanceBackgroundProcesses

Database

Host

Hostname

OracleInstanceStatus

Parameters

Parent

Port


RacDatabase

SGAValues

SID

ServerProcesses

OracleBackgroundProcessDescription

Name

Pid

OracleControlFileName

OracleDBLinkIpAddress

Port

ServiceName

OracleDataFileName

Size

TableSpace

OracleDatabaseControlFiles

DBName

DBVersion

DataFiles

InitValues

Name

RedoLogFiles

SchemaRawData

Schemas

TableSpaces

OracleInitValueDescription

Name

Value

OracleInstanceBackgroundProcesses

ConfigContents

Database

Host

KeyName

Modules


Name

Port

PrimarySAP

ProcessPools

ProductName

ProductVersion

SGAValues

SID

ServerProcesses

Status

OracleListenerBindAddresses

Name

OracleModuleFileName

Name

Schema

OracleRACAsm

HomePath

Name

OCRLocation

PrimaryNode

RacDatabases

VoteDiskPath

OracleRedoLogFileName

Size

OracleSGAValueName

Value

OracleSchemaName

Owner

OracleServerConfigFile

Listeners

OracleServerProcessConnections

Name


PID

Ports

OracleTableSpaceName

Size

ProcessPoolName

RuntimeProcesses


Copying the JDBC driverThis topic describes how to copy a JDBC driver for the Oracle sensor.

Important: If you use TADDM 7.3.0, or 7.3.0.1, the Oracle sensor requires theclasses12.jar file to be copied. Optionally, in addition to this file, you can alsocopy later versions of the driver, for example ojdbc7.jar, as described in thefollowing procedure.

Fix Pack 2

If you use TADDM 7.3.0.2, or later, only one file is required. Copy the

driver that is compatible with the latest version of the Oracle that you discover, forexample ojdbc7.jar. Optionally, you can copy more versions of the driver.

To copy the JDBC driver, complete the following steps:1. Get the JDBC driver file, for example classes12.jar, or ojdbc7.jar file from

the Oracle website or from the Oracle installation media.2. Copy the file to the following location:

$COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.db.oracle.oraclecommon_1.0.0/lib/oracle

3. Add the name of the JDBC driver file to the Bundle-ClassPath entry in theMANIFEST.MF file of the OracleCommon sensor.a. Go to the $COLLATION_HOME/osgi/plugins/

com.ibm.cdb.discover.sensor.app.db.oracle.oraclecommon_1.0.0/META-INFdirectory and open the MANIFEST.MF file in a text editor.

b. Check whether the Bundle-ClassPath entry contains the name of the JDBCdriver that you want to copy. The following example shows the correctentry for the ojdbc7.jar file:Bundle-ClassPath: lib/oracle/ojdbc7.jar,lib/oracle/ojdbc6.jar,lib/oracle/ojdbc5.jar,lib/oracle/classes12.jar

c. If the entry does not contain the name of the driver that you want to copy,add the name manually as the first entry.



To configure the access list, complete the following steps:1. Select Database as the Component Type.


2. Select Oracle as the Vendor.3. Specify the following required information:

a. User nameb. PasswordTo discover Oracle Automatic Storage Management (ASM) file systems, typethe user name sys and password.


com.collation.discovery.oracle.extendedThis property specifies whether additional configuration values aboutOracle database links are stored.

The default value is N (No).

If you set the property to Y (Yes), the sensor stores additional configurationvalues about Oracle database links.





com.collation.discovery.oracle.tablelimitThis property controls the quantity of tables that are discovered by Oraclesensor.

The default value is 1000. The property supports only positive values.

Troubleshooting the sensorThis topic describes common problems that occur with the Oracle sensor andpresents solutions for those problems.

Oracle sensor does not start

ProblemThe Oracle signature is not matching because either you have renamed theOracle binaries or you are running a version of the Oracle server thatTADDM does not support (Express Edition, for instance).

SolutionDo not change the names of the binaries and ensure you are using asupported version of Oracle. Also make sure that the TNSListener serviceis started for the Oracle database.


Sensor fails with “Unable to find the servers” error

ProblemThe Oracle database account is not functioning because of one of thefollowing reasons:v The password is not correct.v The account is locked.v The account does not have connect privileges.

SolutionUpdate the access list, unlock the account, or add the connect privilege.

From the command prompt, test the account by running the sqlpluscommand, as shown in the following example:bash-2.05b$ sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 12 08:15:23 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.Enter user-name: systemEnter password:ERROR:ORA-28000: the account is locked

Oracle duplicates occur when instances are discovered by bothVeritas cluster sensor and Oracle sensor

ProblemWhen you use both Veritas cluster sensor and Oracle sensor to discover anOracle instance, duplicates might occur. This happens because Veritascluster sensor uses the upper case for the instance SID and Oracle sensoruses the lower case for the same SID.

SolutionTo avoid this problem, modify the dist/etc/discover-sensors/VeritasClusterSensor.xml file by changing the following line:<source>Sid</source>

into the following line:<source>%{Sid}</source>

After the change, Veritas cluster sensor creates Oracle instances with thelower case SID.

Note: If you change the line after running discoveries where no duplicatesoccurred, new duplicates might occur.

Sybase sensorThe Sybase sensor discovers Sybase Adaptive Server Enterprise (ASE) databaseservers.

Fix Pack 2

To discover the Sybase database, the sensor uses JDBC protocol with the

ENCRYPT_PASSWORD and RETRY_WITH_NO_ENCRYPTION flags set to true by default. Itmeans that the password is encrypted and that if you fail to authenticate in yourfirst attempt, the passwords provided during next attempts are not encrypted. Theconnection is secure if the access list entry contains a trust store file.



SybaseSensor

Security issues

To assign the minimum privileges to the Sybase discovery user, run the followingcommand:grant select on sysengines from public

The following tables are queried:v versionv master..sysconfiguresv master..sysusagesv master..syssegmentsv master..sysprocessesv master..sysenginesv master..sysdatabasesv master..sysdevicesv master..syscurconfigsv master..sysserversv master..syssrvrolesv master..sysloginsv master..sysloginrolesv master..syspartitionsv master..systhresholdsv master..sysresourcelimitsv master..systimeranges

The previous query discovers only the information for the master database. If youwant to discover information about users and tables from other databases, create auser id on these databases. During the discovery, TADDM runs the followingquery:select t.segment, u.name from database_name..systhresholds t,database_name..sysusers u where t.suid=u.suid

Examples:v The following query is run for the tempdb database:

select t.segment, u.name from tempdb..systhresholds t,tempdb..sysusers u wheret.suid=u.suid

v The following query is run for the sybsystemprocs database:select t.segment, u.name from sybsystemprocs..systhresholds t,sybsystemprocs..sysusers u where t.suid=u.suid

Limitationsv The Sybase sensor does not collect information about schemas owned by the dbo

user.

v Fix Pack 1 The limitation in SAP Sybase ASE software identified by CR# 751110affects TADDM. Database connection configured to use secure socket layer (SSL)


hangs while connecting to servers that have SSL mode disabled. The avoid suchproblem in TADDM, set a value of the following scoped property:com.collation.sybasesensor.jdbclogin.timeout

The default value is 15000 ms (15 seconds). After that time, attempts to log infail and sensor tries to establish a plain unsecured connection.

v Fix Pack 3 In TADDM 7.3.0.3, and later, the following configuration elements arenot discovered by default:– logins

– roles

– rawSchema

– tables

– thresholds

If you want these elements to be discovered, create a sensor configuration inDiscovery Management Console, and set the following properties to true:– discoverLogins

– discoverRoles

– discoverRawSchema

– discoverTables

– discoverThresholds

Model objects with associated attributesThe Sybase sensor creates model objects with associated attributes. The attributesindicate the type of information that the sensor collects about storage resources inyour IT environment.


AppConfig

v Contentv Parent

ConfigFile

v FixedPathv RealFilev URI

LogicalContentFixedPath

ProcessPool

v CmdLinev Envv Namev Parentv RuntimeProcesses

SybaseConfigValue

v ConfigUnitv Name


v Parentv RunValuev Typev Value

SybaseDatabase

v Namev Optionsv Ownerv Parent (SybaseServer)v SchemasRawDatav Segmentsv Tablesv Thresholdsv Users

SybaseDevice

v Descriptionv FirstVirtualPageNumberv FixedPathv IsDefaultDiskv IsDeviceMirroredv IsDsyncEnabledv IsDumpDevicev IsMasterDeviceMirroredv IsMirrorEnabledv IsPhysicalDiskv IsReadsMirroredv IsSecondaryMirrorSideOnlyv IsSerialWritesv IsSkipHeaderv LastVirtualPageNumberv MirrorPathv Parent (SybaseServer)v RealFilev URI

SybaseEngineProcess

v CmdLinev Namev PIDv Parentv Ports

SybaseLogin

v AccumulatedDatev FailedLoginCountv FullName


v IsAccountLockedv IsPasswordExpiredv Languagev Namev Parent(SybaseServer)v PasswordDatev SybaseRolesv TotalCPUUsedv TotalIOUsed

SybaseModule

v Databasev FileNamev Namev Parent

SybaseRemoteServer

v IsMessageConfidentialv IsMessageIntegrityv IsMutualAuthenticationv IsNetworkPasswordEncryptedv IsReadOnlyv IsRPCSecurityModelBv IsTimeoutEnabledv Namev NetworkNamev RemoteNetworkCostv RemoteServerClassv SybaseServer

SybaseResourceLimitation

v AppNamev IsEnforcedDuringExecutionv IsEnforcedPriorToExecutionv LimitationExceededActionv LimitationScopev LimitTypev LimitValuev Loginv Namev Parent (SybaseServer)v TimeRange

SybaseRole

v FailedLoginCountv Namev Parentv PasswordDate


v Status

SybaseSegment

v Namev Parentv Size

SybaseServer

v BindAddressesv ConfigContentsv ConfigFilev ConfigValuesv Databasesv Devicesv EngineProcessesv FullVersionv Homev Hostv KeyNamev Loginsv Modulesv Namev PrimarySAPv ProcessPoolsv ProductNamev ProductVersionv RemoteServersv ResourceLimitationsv ServerProcessesv Statusv SybaseRolesv TimeRanges

SybaseServerProcess

v Namev PIDv Parent

SybaseTable

v CreationDatev Namev Parent(SybaseDatabase)v Partitions

SybaseTablePartition

v FirstPagev NumPagesv Parent (SybaseTable)v PartitionID


SybaseThreshold

v IsLastChancev Namev Parent (SybaseDatabase)v Segmentv ThresholdExeededProcedurev ThresholdSizev User

SybaseTimeRange

v EndDayv EndTimev Namev Parent (SybaseServer)v StartDayv StartTime

SybaseUser

v Loginv Namev Parent (SybaseDatabase)


To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should

use to establish a JDBC connect to the Sybase server.

4. Fix Pack 1 Depending on your server configuration, specify the SSL truststorefile with the pass phrase in the SSL Settings. This applies only to the discoverythat uses the SSL connection.

Note: Due to a Sybase JDBC driver and JVM limitation, only one truststore filecan be used during a discovery. Therefore, if you want to discover manySybase targets over the SSL protocol, you must add only one truststore file thatcontains all required certificates. This file must be added to the first access listentry of the Sybase sensor in TADDM. Other entries cannot contain any SSLSettings. You can use the keytool and ikeyman tools to create the truststore file.Both tools are in the $COLLATION_HOME/external/jdk-os-platform/jre/bindirectory.

Configuring the discovery profileYou can customize the settings of the Sybase sensor, if the default ones do notmeet your requirements.

To customize Sybase sensor settings, you must create a sensor configuration.Complete the following steps:


1. In the Discovery drawer of the Discovery Management Console, clickDiscovery Profiles.

2. In the Discovery Profiles window, click New.3. In the Create New Profile window, type the profile name and description. From

the Clone existing profile list, select Level 3 Discovery and click OK.4. On the Sensor Configuration tab, select the SybaseSensor sensor and click

New.5. In the Create Configuration window, type the name and description for your

configuration, and select the Enable this configuration and disable selectedconfiguration check box.

6. In the Configuration section of the Create Configuration window, modify anyor all of the properties.


Properties

You can modify the following properties:

Fix Pack 3 discoverLoginsSpecifies whether the logins data is discovered during a Sybase databasediscovery.

The default value is false, which means that the data is not discovered. Todiscover logins, set this property to true.

Fix Pack 3 discoverRolesSpecifies whether the roles data is discovered during a Sybase databasediscovery.

The default value is false, which means that the data is not discovered. Todiscover roles, set this property to true.

Fix Pack 3 discoverRawSchemaSpecifies whether the rawSchema data is discovered during a Sybasedatabase discovery.

The default value is false, which means that the data is not discovered. Todiscover rawSchema, set this property to true.

Fix Pack 3 discoverTablesSpecifies whether the tables data is discovered during a Sybase databasediscovery.

The default value is false, which means that the data is not discovered. Todiscover tables, set this property to true.

Fix Pack 3 discoverThresholdsSpecifies whether the thresholds data is discovered during a Sybasedatabase discovery.

The default value is false, which means that the data is not discovered. Todiscover thresholds, set this property to true.

Sybase IQ sensorThe Sybase IQ sensor discovers Sybase IQ database servers.



SybaseIQSensor

Security issues

To assign the minimum privileges to the Sybase discovery user, run the followingcommand:grant execute on sp_iqdbsize


The sensor creates the following model objects:v app.AppConfigv app.ConfigFilev app.db.sybase.SybaseConfigValuev app.db.sybase.SybaseDatabasev app.db.sybase.SybaseDevicev app.db.sybase.SybaseEngineProcessv app.db.sybase.SybaseModulev app.db.sybase.SybaseServerv app.ProcessPoolv core.LogicalContent


To configure the access list, complete the following steps:1. Select Database as the Component Type.2. Select Sybase as the Vendor.3. Specify the access information (user name and password) that TADDM should

use to establish a JDBC connect to the Sybase server.


Chapter 36. Generic sensors

Generic sensors are used by other sensors to discover configuration items.

Anchor sensorThe Anchor sensor is used for discovery behind a firewall.


AnchorSensor

Prerequisites

All software components that are needed for discovery from the remote anchor areautomatically deployed to the anchor during the discovery process. To exchangedata, you must use the Secure Shell (SSH) version 2 protocol.

If anchor is deployed on 64-bit Linux systems, JBossSensor and StackScanSensorrequire also 32-bit version of the libgcc and glibc libraries.



The TADDM server uses SSH to communicate with the remote anchor server. Toconfigure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must

use for either SSH key-based authentication or SSH login-based authenticationto the remote anchor server.

Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation (typically done using the sudo command).

For more information, see the Commands that might require elevated privilege topic inthe TADDM Administrator's Guide.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Anchor sensor uses.


Fix Pack 3 com.collation.discover.anchor.zone.fromContextIPSpecifies whether the anchor zones can be set from the context IP, which isthe IP that is used for the discovery. Valid values are true and false. Thedefault is false.


When an IP address is not included in the anchor scope, the anchor zone isnot set. As a result, the address space is not set for a particular IP addressor IP network. If you set this property to true, the anchor zones are setfrom the context IP.

com.collation.discover.agent.AnchorSensor.timeout=3600000Specifies the time allowed to start a new anchor server.

com.collation.discover.anchor.forceDeployment=trueThe default value is true.

This property specifies whether the anchors for the discovered scope are tobe deployed during discovery startup.

If you set the value to false, the anchors are deployed only if either of thefollowing conditions are met:v If any IP address from the scope cannot be pingedv If port 22 cannot be reached on any of the discovered IP addresses

If chained anchors exist, this condition applies to all anchors in the chain.If an anchor in the chain is restricted with a condition, the prior anchorsmust meet the condition before all the anchors can be deployed.

com.collation.discover.anchor.lazyDeployment=falseSpecifies if files must be copied during anchor deployment, or when thesensor requiring the files is going to be launched. In both cases onlydifferent files are copied. Valid values are true and false. The default isfalse.

The following example provides some insight to how this property affectsTADDM functionality:

The WebSphere Application Server sensor has dependencies in thedist/lib/websphere directory which are 130 MB in size. If the flag is set tofalse, this data is copied to the target host when the anchor is deployed. Ifthe flag is set to true, the data is copied when the WebSphere ApplicationServer sensor is about to be run on the anchor. If no WebSphereApplication Server sensor is run through the anchor, 130 MB is not sent tothe remote host.

com.collation.discover.anchor.connectType=sshSpecifies whether to connect to the anchor using an ssh tunnel or a directsocket. Valid values are ssh and direct. The default is ssh. To specify theconnection type for a particular address, usecom.collation.discover.anchor.connectType.1.2.3.4=ssh, where 1.2.3.4 isthe address for which you want to specify the connection type.

com.collation.platform.session.GatewayForceSshSpecifies whether to force the gateway to act independently of the anchor.Valid values are true and false. Set the value to true to resolve Cygwinissues when both the gateway and anchor are on the same system. Whenthe value is set to true, an SSH session is used to transfer traffic betweenthe gateway and anchor rather than a local session.

Asynchronous discovery sensorThe asynchronous discovery sensor is required for asynchronous discovery. IPaddresses that are unreachable (cannot be pinged) are candidates for asynchronousdiscovery. The asynchronous discovery sensor attempts to determine which of theunreachable IP addresses are valid.


For information about asynchronous discovery, see the Asynchronous discovery topicin the TADDM Administrator's Guide.

In asynchronous discovery, the output of the discovery script is an archive file thatcontains the discovery results and is stored in a directory on the TADDM server.An unreachable IP address is considered valid if an archive file exists on theTADDM server for that IP address. Based on the content of the archive file, theappropriate sensors are scheduled to process their discovery script output. Sensorsthen perform discovery by parsing the script output instead of directly accessingthe target system, as is done in a nonscript-based discovery.


ASDSensor


The asynchronous discovery sensor does not use the access list.

The asynchronous discovery sensor uses the following entries in thecollation.properties file:v com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectoryv com.ibm.cdb.discover.asd.ProcessUnreachableIPsv com.ibm.cdb.tarpath

Troubleshooting the sensorThis topic describes common problems that occur with the asynchronous discoverysensor and presents solutions for those problems.

The sensor does not discover any objects and fails with errorCTJTD3078E

ProblemThe ASDSensor finishes with no objects discovered and the following erroris issued:CTJTD3075E Unable to execute command: tar -xf <asdfile> commandexit code: 1.In addition in the logs following erorr appears:tar: can’t create ././@LongLink: Permission denied

Solution⌂Your tar program must support long file paths. GNU Tar 1.13 is notsupported because it might truncate long file names.

Asynchronous discovery ping sensorThe asynchronous discovery ping sensor retrieves the first valid IP address from adiscovery archive file. This IP address is used to seed the asynchronous discoverysensor. If you cannot define a discovery scope and you want to run anasynchronous discovery, you can use this sensor.


ASDPingSensor

Chapter 36. Generic sensors 251

Prerequisites

In a discovery profile, if you are using the asynchronous discovery ping sensor,you must disable the ping sensor because you cannot enable both of these sensorsin a discovery profile.

Custom application server sensorThe custom application server sensor creates a custom application server that isbased on template and runtime process information that is discovered by thegeneric server sensor. The sensor also collects configuration files or applicationdescriptors if these are specified in the template and performs extension processingto collect additional information.



Prerequisites

To discover configuration files, the sensor requires that the cksum program andassociated libraries are installed on the target operating system.

Limitations

The following limitations apply:v The sensor cannot be run in script-based discovery.v The same limitations as for the “Generic server sensor” on page 257 apply.


The following model objects are used to create generic AppServers:v app.AppServerv app.db.DatabaseServerv app.j2ee.J2EESeverv app.web.WebServer

The following model objects are used to extend TADDM application sensors:v app.db.db2.Db2Serverv app.db.mssql.SqlServerv app.j2ee.jboss.JBossServerv app.j2ee.weblogic.WebLogicServerv app.j2ee.websphere.WebSphereServerv app.messaging.exchange.ExchangeServerv app.messaging.mq.MQQueueManagerv app.sms.SMSiteServerv app.veritas.cluster.VCSClusterv app.web.apache.ApacheServerv app.web.iis.IIsWebServerv app.web.iplanet.IPlanetServer


Custom MIB2 computer system sensorThe custom MIB2 computer system sensor creates a custom computer system thatis based on template information.

This template information is matched for one or more of the following items:v system OID (SNMPv2-MIB::sysObjectID - .1.3.6.1.2.1.1.2)v system Description (SNMPv2-MIB::sysDescr - .1.3.6.1.2.1.1.1) discovered by the

SNMP MIB2 sensor

The custom MIB2 computer system sensor performs extension processing to collectadditional information.



Limitations

See the limitations for the SNMP MIB2 sensor.


The sensor creates the following model objects:v sys.ComputerSystem hierarchy

Custom template sensorThe custom template sensor can be used with custom scripts to analyze andenhance the information that is collected by other sensors.


CustomTemplateSensor

Limitations

The sensor cannot be run in script-based discovery.

Configuring the sensorBefore running a discovery, you must configure the custom template sensor.

The custom template sensor is not enabled by default. To enable the sensor, youmust create a discovery profile and then enable the sensor in the new profile. Youmust also enable in this profile any additional sensors that you want to analyze theresults from.

You must create a template for the custom template sensor. This template consistsof the following files:

template.xml This file contains the configuration data. In this file, you specify theTADDM result class object that you want to analyze.


matcher-script.pyThis script extracts the specified model objects that are then processed bythe sensor-script.py file.

sensor-script.pyThis script can modify objects, create model objects, and store modelobjects.

You must place these files in the $COLLATION_HOME/etc/templates/cts/template_name directory. The name of the directory template_name must matchexactly the name as specified in the template.xml file.

To run the discovery, read access rights to the templates directory and itsassociated files are required.

The scripts are Jython scripts. See the SDK Developer’s Guide for information aboutthe custom server extensions API. General script-related information in this guidecan be applied to the custom template sensor scripts. Detailed information aboutcode related to initializing the environment, importing TADDM sensor tools, andlogging errors can be used when defining the sensor scripts. All script files mustbe placed in the $COLLATION_HOME/etc/templates/cts/template_name directory.

Template.xml

The template.xml file has the following structure:<CTSTemplate><name>template_name</name><result-class>com.ibm.cdb.discover.app.db.db2.result.Db2Result</result-class><plugin-id>com.ibm.cdb.discover.sensor.app.db.db2.db2_7.6.0</plugin-id><engine-id>com.ibm.cdb.core.jython253_2.5.3</engine-id><matcher-script>matcher.py</matcher-script><sensor-script>sensor.py</sensor-script></CTSTemplate>

Important: You must arrange the elements of the template.xml file exactly like inthe preceding example. Otherwise, errors are generated.

name The template name. For example, if the template name is example_template,then you must have the directory structure: $COLLATION_HOME/etc/templates/cts/example_template.

result-classThe fully qualified name of the TADDM result class that you want toanalyze.

plugin-idThis plugin-id specifies the ID of the plug-in that provides the results. ThisID is required for pluggable sensors only.

engine-idThis engine-id specifies the IP of the plug-in that provides the Jython engineto be used, for example com.ibm.cdb.core.jython253_2.5.3. If notspecified, the default engine is used.

matcher-scriptThe name of the Jython script (.py extension) that lists all of the objectsthat meet the criteria defined in the script.

sensor-scriptThe name of the Jython script that processes the list of objects generated


from the result-matcher script. Depending on the object returned the scriptmodifies the objects or creates new objects. These objects can then bestored.

Matcher script

This script is run when the result object of the class specified in the template isdiscovered. The following information is provided to the script from thesensorhelper code:v The ResultMap is a map of the model objects, their arrays, or collections. These

objects are the shared properties of the result object that are matched by thetemplate. The map is indexed by property name.

v The ReturnList contains a list of elements that require further processing. Eachelement is associated with the name that is displayed as the sensor starts for thatelement.

When the result matcher script completes successfully, this information is used toseed the custom template sensor.

This script example shows the steps that extract objects from the discovery resultsof the generic server sensor.# Initialising the environmentimport sysimport java

from java.lang import Systemcoll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")System.setProperty("python.home",coll_home + "/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib")

jython_home = System.getProperty("jython.home")sys.path.append(jython_home + "/Lib")sys.path.append(coll_home + "/lib/sensor-tools")sys.prefix = jython_home + "/Lib"

import traceback

# Importing sensorhelperimport sensorhelper

# Initialising script input(resultMap,returnList,log) = sensorhelper.init(targets)log.debug("CTS result matcher script running")

try:# get runtime processes list from the resultruntimeProcesses = resultMap[’runtimeProcesses’]# get first of the processesrtp = runtimeProcesses[0][0]# add it to the list of elements that need further processingreturnList.add("dummyName",rtp)

except:log.error("Error occurred")

You can use an XPath query when using the JXPath library to determine which ofthe objects are returned. The findElementsForXPath function can be used to queryand return a collection of objects resulting from the query. The following example


finds and prints an IP address using the findElementsForXPath function. See theSDK Developer’s Guide for information about this utility function.result = IpListResult();ip1 = IpAddressImpl();ip1.setStringNotation("9.0.0.1");ip2 = IpAddressImpl();ip2.setStringNotation("9.0.0.2");result.list.add(ip2)result.list.add(ip1)

elements = sensorhelper.findElementsForXPath(result,"/list[stringNotation=’9.0.0.2’]")for e in elements:

print e

Sensor script

This script starts separately for each of the extracted objects returned from theresult-matcher script. Depending on the objects returned, the script modifies,creates, and populates the model objects. These objects can then be stored. Thefollowing information is provided to the script from the sensorhelper code:v The CTSSeed object that contains the ResultMap and the name value pair returned

by the result matcher script.v The CTSResult object is a custom template result object that is populated by the

sensor script with the model objects that can be stored.

This script example shows the steps that populate and store model objects.import sysimport java

from java.lang import Systemcoll_home = System.getProperty("com.collation.home")

System.setProperty("jython.home",coll_home +"/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")System.setProperty("python.home",coll_home +"/osgi/plugins/com.ibm.cdb.core.jython_1.0.0/lib/jython-2.1")

jython_home = System.getProperty("jython.home")sys.path.append(jython_home + "/Lib")sys.path.append(coll_home + "/lib/sensor-tools")sys.prefix = jython_home + "/Lib"

import tracebackimport sensorhelper

(ctsResult,ctsSeed,log) = sensorhelper.init(targets)

log.debug("CTS Sensor script running")# get value passed by result matcherruntime_process = ctsSeed.getSeedInitiator().getValue()# get name passed by result matchername = ctsSeed.getSeedInitiator().getKey()templateName = ctsSeed.getTemplate().getName();log.debug("CTS Sensor script running for template " +templateName + “/” + name)# process runtime process with user defined functionresult = processRuntimeProcess(runtime_process)# return resulting model objectctsResult.addExtendedResult(result)

Troubleshooting the sensorThis topic describes common problems that occur with the custom template sensorand presents solutions for those problems.


The custom template sensor does not start or fails

ProblemThere are a number of potential situations that can prevent the sensor fromstarting or cause it to fail.

SolutionVerify that the following conditions exist:v The custom template sensor is enabled in the discovery profile.v The custom template sensor template and scripts are located in the

correct directory.v The name of the directory that stores the template matches the name

that is specified in the template.xml file.v The format of the template.xml file is valid.v The result-class that is specified in the template.xml file exists and, if

required, the plugin-id is specified.v The scripts (matcher-script.py and sensor-script.py) are in the correct

directory and are defined correctly in the template.xml file.v The scripts contain no syntax errors. Unhandled errors for the

matcher-script.py script are recorded in the log file but no seed file iscreated. Unhandled errors for the sensor-script.py script are recordedin the log file and displayed in the Discovery Management Console.

v The templates directory and associated files must have the correct accessrights. You require read access rights to the directory and associatedfiles.

v The sensor that collects the data must complete its discovery with noerrors.

v The syntax of the matcher and sensor scripts must comply with theversion of Jython used, as defined by the engine-id tag in thetemplate.xml.

Generic computer system sensorThe generic computer system sensor discovers the type of a computer system. Theresults of this sensor are used to start a specific computer system sensor, such asthe Linux computer system sensor.



Generic server sensorThe generic server sensor discovers the application servers that are running on ahost computer system.

The sensor first discovers listening ports (IP address and ports), establishedconnections, and processes that are running on targeted computer systems.Templates are used to match runtime process information. When specified criteriaare matched, the information is used to seed specific application sensors, such asthe Apache sensor or a custom application server sensor.


The processes can be running on IPv4 or IPv6 addresses. For processes that arerunning on IPv6 only, the processes are discovered, but a seed that starts a morespecific sensor is not created.

Custom server templates are used to discover application servers that TADDMdoes not automatically categorize. You can create custom server templates usingthe Discovery Management Console. If multiple custom server templates match theapplication runtime process information, only the first custom server template thatis matched causes the custom application server sensor to run.


GenericServerSensor

Limitations

A sensor that requires credentials and a generic custom sensor can both discoverthe same target system during multiple discoveries. Depending on the nature ofthe data discovered without credentials, the system cannot guarantee that objectsthat are created by the custom server template are reconciled with sensor-createdartifacts.


The sensor creates the following model object:v sys.RuntimeProcess

netstat command instead of lsof command for AIX operatingsystem

The generic server sensor by default uses the netstat command instead of thelsof command on the AIX operating systems. Thanks to this, the LPAR and WPARprocesses are separated and WPAR generic sensor is run to discover applicationsthat are installed on WPARs.For details, see “WPAR generic sensor” on page 285.

Asynchronous and script-based discovery supportThe generic server sensor supports asynchronous and script-based discovery.








Limitations

Some function that is provided by the generic server sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

On Solaris operating systems that support virtualization, from the global zone, thegeneric server sensor does not support the discovery of runtime processes in localzones.






com.collation.discover.agent.command.netstat.Windows

You can use this property to specify a custom command to use instead ofthe netstat -nao command on a Windows target.

You must ensure that any alternative command you specify returnsinformation in the same format as the netstat -nao command.

For example,com.collation.discover.agent.command.netstat.Windows.ip_address=type c:\\\\folder\\\\mynetstat.txt

where mynetstat.txt contains the output of the netstat -nao command,and the type command is used to print the contents of the file.

com.collation.netstatoverlsof.AIX=true

This property specifies which command (netstat or lsof) is used to collectthe process information on AIX operating systems, and it is applicablemainly for deciding the command to build port map and open TCP port toprocess map.

By default, the property is set to true, and netstat command will be used.

If the property is set to false, then lsof command will be used, but insome scenarios, netstat can be still used, e.g. in case where we need todetermine whether the privileges for isof are sufficient or not.

Note: There is a dependency on the commands of netstat and kdb evenwith false value of this property. Point to note is that netstat getsexecuted in the OS layer and is a requirement for not only GenericServersensor.


Troubleshooting the sensorThis topic describes common problems that occur with the generic server sensorand presents solutions for those problems.

The generic server sensor does not discover open sockets

ProblemThe generic server sensor fails to discover open sockets. You might find thefollowing message in the error logs:CTJTD2522E Sensor is not able to discover processes pids for open sockets.

SolutionSee the DEBUG-level logs of the sensor to find a detailed reason of thisfailure. Depending on the reason, complete the following tasks:v If a command timeout occurred, increase the timeout by setting the

value of the com.collation.discover.agent.command.pidsInfoTimeoutproperty. This property can be scoped to a specific IP. For example, thecom.collation.discover.agent.command.pidsInfoTimeout.192.168.2.1=1800000 property specifies a 30-minute timeout for the IP 192.168.2.1.Remember to increase timeout values for the Generic server sensor andthe IBM AIX computer system sensor as well.

v If the logs contain either of the following messages:– “os.AixOs - Unable to get pids for open sockets

com.collation.platform.os.OsException: Unable to find<sctp_pcb_hash_table>” (for a regular discovery),

– “sensor.GenericServerScriptSensor - Unable to find<sctp_pcb_hash_table>” (for a script-based discovery),

apply a fix for APAR IZ98746, IZ98842, IV04783, or IV05965 on adiscovered AIX host.

v If the logs contain a message similar to the following one:for i in `netstat -Aan| grep tcp|awk ’{print $1}’`;do echo \"sockinfo$itcpcb\"|kdb|grep ACTIVE; echo $i$’\n####’;doneopen: Permission deniedf100020000060bb0####open: Permission deniedf10002000004ebb0####...

complete one of the following procedures:– Install the netstat, sockinfo, and kdb commands. Grant the TADDM

user the execution permissions to run them.– If you have the kdb command installed, define sudo for it by setting

the following property:com.collation.discover.agent.command.kdb = sudo kdb

– Set the com.collation.netstatoverlsof.AIX property to false toenable the lsof command to collect the process information instead ofthe netstat command.


IBM Tivoli Utilization sensorThe IBM Tivoli Utilization sensor gathers basic metrics from a target system. Thesensor uses the TADDM discovery infrastructure to deploy scripts that runsystem-level performance monitoring commands on the target system. At specifiedintervals, the sensor gathers data from the target system and provides it to theTADDM server, where operating system metric objects are created.

The IBM Tivoli Utilization sensor provides metrics and a utilization report. You canuse this information with the System Connection Topology Report to identifyservers that are not used to capacity and do not provide services to other servers.


OperatingSystemUtilizationSensor

Prerequisites

For the sensor to discover a target system, the target system must have thefollowing commands installed in the default location for the respective operatingsystem:v compress commandv netstat commandv sadc commandv sar command

On target systems that are running the following operating systems, the followingrespective prerequisites must be met:v Linux

– The compress command must be available.– The netstat command must be available.– The sar command must be available.– The sadc command must be available.

v Solaris– The compress command must be available.– The netstat command must be available.– The sar command must be available.

v AIX– The compress command must be available.– The netstat command must be available.– The sar command must be available.– To run the sar command, the TADDM service account must be part of the

adm group.v HP-UX

– The compress command must be available.– The netstat command must be available.– The sar command must be available.– To schedule cron and at jobs, the TADDM service account must be added to

the cron.allow and at.allow files.


You must copy the following JAR files to the $COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.sys.utilization_version/lib directory:v db2jcc.jar

v oracle-jdbc-9.2.jar

Limitations

The sensor is intended for short-term use (for example, a maximum of one monthof use) to analyze servers and identify consolidation targets. The sensor can beused only for the firewall zone in which the TADDM server resides. The use of ananchor server is not supported.

Over a longer period of time, for determining server availability, performance, andutilization, or for discovering applications that span firewall zones, use the IBMTivoli Monitoring product.

Asynchronous and script-based discovery supportThe IBM Tivoli Utilization sensor supports asynchronous and script-baseddiscovery. All function that is provided by the sensor during a nonscript-baseddiscovery is supported in an asynchronous or script-based discovery.


For asynchronous discovery, first complete the steps that are described in theConfiguring for asynchronous discovery topic in the TADDM Administrator's Guide.Before running an asynchronous discovery, you must start the Utilization sensor onthe target system to collect utilization data. The discovery script package that isgenerated for an asynchronous discovery must be extracted on the target system.After the discovery script package is extracted, complete the following steps:1. Change to the taddmasd/

com.ibm.cdb.discover.sensor.sys.utilization_version directory.2. Change the file permissions according to the following command:

chmod 700 *.sh

3. To start the Utilization sensor, run the following command:./utilizationDeployer.sh -c

Specify the time interval and duration for collecting data. Before starting tocollect data, you must wait until after the time interval has elapsed.

4. Periodically collect data by running the taddmasd/scriptsRunner.sh script. Thisscript generates an archive file that contains the utilization data.

5. Move the resulting archive file to the TADDM server.6. Create a new asynchronous discovery profile for the Utilization sensor, enable

the sensor, and run an asynchronous discovery.7. When the collection of utilization data is complete, to stop the Utilization

sensor, change to the taddmasd/com.ibm.cdb.discover.sensor.sys.utilization_version directory, and run thefollowing command:./utilizationDeployer.sh -u

For information about configuring for script-based discovery, see the Configuring forscript-based discoveryin the TADDM Administrator's Guide.





Model objects with associated attributesThe IBM Tivoli Utilization sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects about theutilization of your Computer Systems in your IT environment.


metric.OperatingSystemMetric

v Labelv MetricNamev MetricUnitOfMeasurev MetricValuev StatisticName

net.IpInterface

v IpAddress

relation.Gauges

v Source (OperatingSystemMetric)v Target (OperatingSystem)

The following computer system types are discovered:

sys.aix.AixUnitaryComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.windows.WindowsComputerSystem

The following attribute is associated with these model objects:v signature

The following operating system types are discovered:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.sun.Solarissys.windows.WindowsOperatingSystem

The following attribute is associated with these model objects:v OSName

Configuring the sensorBefore running the IBM Tivoli Utilization sensor to gather data from a targetmachine, you must configure the sensor.


Setting configuration parametersYou can configure the behavior of the IBM Tivoli Utilization sensor by setting theconfiguration parameters.

The following table lists the configuration parameters of the IBM Tivoli Utilizationsensor.

Table 15. Configuration parameters

Parameter name Description

operatingMode The mode of operation for the sensor. The following values are valid:

ONCE Specifies that the collection scripts run once for the intervaland numDays, or maxFileSize, specified, whichever comes first.When the collection scripts have finished, the data is collectedby the sensor the next time that it runs. The data collected isparsed and stored on the TADDM database. All output files onthe target machine are cleaned up.

RESTARTSpecifies that when the collection scripts finish as normal, thecollection scripts are started again.

CLEANUPSpecifies that any collection currently running on the system isimmediately stopped and cleaned up. Once a cleanupoperation is called, collection can only be restarted on thismachine by setting the operatingMode value to RESTART.

collectionMode The mode of collection for the sensor. The following values are valid:

ALWAYSSpecifies that data is collected each time the sensor is run onthe target system, regardless of whether the collection scriptshave completed or not.

END Specifies that data is collected when the sensor is run on thetarget system, only if the collection scripts have completed.Except in situations where operatingMode is set to CLEANUP,any discovery performed before the collection scripts havecompleted results in no data collection.

interval The collection interval, in minutes, for collection scripts running on thetarget. Valid values are between 3 minutes and 60 minutes.

numDays The number of days that the collection scripts run on the target. Validvalues are between 1 day and 35 days.

maxFileSize The maximum size, in MB, for the output files created by the collectionscripts. Valid values are between 1 MB and 100 MB.

Configuring cleanup optionsThe IBM Tivoli Utilization sensor has a function that automatically cleans up andremoves the collection scripts and data stored on the target machine. It is alsopossible to perform the cleanup manually, if required.

Configuring automatic cleanup during discovery

To use the automatic cleanup function, complete the following steps:1. Create a profile configuration for the IBM Tivoli Utilization sensor that has the

operatingMode parameter set to CLEANUP.2. Run a discovery using the profile that has the CLEANUP option set.


After the cleanup has been performed on the target discovery machine, to start thecollection scripts again carry out a RESTART operation.

Performing manual cleanup

To perform a manual cleanup on a UNIX target machine, complete the followingsteps:1. Navigate to the /var/tmp/ directory.2. Run the following command:

./scmd_perf.sh -k -c -r

3. Remove the IBM Tivoli Utilization sensor lock file.

To perform a manual cleanup on a Windows target machine, complete thefollowing steps:1. Navigate to the C:\ directory.2. Remove the WINTEL-MAN-PERF.VBS script.3. Remove the PerformanceData_hostname.out file.4. Remove the IBM Tivoli Utilization sensor lock file.

Configuring the BIRT reportYou can use Utilization BIRT report to generate reports based on the data collectedby the IBM Tivoli Utilization sensor.

About this task

Important: Configuring the Utilization BIRT report is only possible if you haveBIRT Report Viewer enabled. BIRT Report Viewer is disabled because of securityissues. The alternative way to view the BIRT reports is by using the TivoliCommon Reporting (TCR) after you import the TADDM reports to TCR. If you areaware of the risks, you can restore BIRT Report Viewer.

To see how to restore BIRT Report Viewer, see the Restoring BIRT Report Viewertopic in the TADDM Administrator's Guide.

The steps 1, 2 and 4 are specific to BIRT Report Viewer. If you are viewing reportsby using TCR, you must specify values for the parameters as in the step 3.

Procedure

To configure the Utilization BIRT report complete the following steps in the DataManagement Portal:1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is

displayed.2. Select TADDM_SERVER_UTILIZATION report and click Run Report.3. In the Parameter window, a value for each of the following parameters must be

specified:

Scope From the list of available TADDM scopes, select a scope.

Metric From the list of available metrics, select the metric for which you wantto view data, or select ALL to display data for all metrics.


OperatorOperators are used to restrict the data displayed in the report. From thelist of available operators, select an operator, or select N/A to displayall data for the selected metric.

Value If you specified an operator, you must specify a corresponding value.Otherwise, select N/A to display all data for the selected metric.

Another valueIf you specified an operator, and it requires two values, you mustspecify a corresponding value for the second value. Otherwise, selectN/A to display all data for the selected metric.

Number of application dependenciesThe number of application dependencies is used to restrict the datadisplayed in the report. Specify the number of applicationdependencies, or select N/A to display all data for the selected metric.

4. Click OK. The report output is displayed in the BIRT Report Viewer.

What to do next

To configure the Hourly Peak Server Utilization BIRT report complete thefollowing steps in the Data Management Portal:1. Click Analytics > BIRT Reports. The TADDM BIRT Reports window is

displayed.2. Select TADDM_SERVER_UTILIZATION_HOURLY_PEAK report and click

Run Report.3. In the Parameter window, a value for each of the following parameters must be

specified:

Scope From the list of available TADDM scopes, select a scope.

Date From the list of available dates, select a date.4. Click OK. The report output is displayed in the BIRT Report Viewer.

Configuring the discovery profileThe IBM Tivoli Utilization sensor is configured through the use of discoveryprofiles. A default discovery profile, named Utilization Discovery, is provided outof the box. It can be used to perform discoveries as is, or a new profile withcustomized configuration parameter values can be created.

The out-of-the-box Utilization Discovery profile has the following default propertyvalues:v operatingMode: ONCEv collectionMode: ALWAYSv interval: 15v numDays: 35v maxFileSize: 100

It contains the following default sensors:v Ping sensorv Port sensorv Session sensorv Anchor sensorv Operating system utilization sensor


If the default discovery profile is not sufficient for your needs, you can create aprofile with customized configuration parameters. To create a customizeddiscovery profile, complete the following steps:1. In the Discovery drawer of the Discovery Management Console, click

Discovery Profiles.2. In the Discovery Profiles window, click New.3. In the Profile Name field, type the name of the new profile.4. In the Description field, type a description of the new profile.5. From the Clone existing profile list, select Utilization Discovery.6. Click OK.7. In the Discovery Profiles window, select the new profile, and on the Sensor

Configuration tab, select the OperatingSystemUtilizationSensor sensor.8. To create a sensor configuration based on the

OperatingSystemUtilizationSensor default configuration, click New. TheCreate Configuration window is displayed.

9. In the Name field, type the name of the new sensor configuration.10. In the Description field, type a description of the new sensor configuration.11. Click Enable this configuration and disable selected configuration to ensure

that this configuration is used, by default, by the discovery profile.12. For each configuration parameter you want to update, complete the following

tasks:a. In the Configuration section, double click the configuration parameter you

want to change.b. Enter a new value for the configuration parameter.

13. Click OK.14. In the Discovery Profiles window, click Save.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Tivoli Utilizationsensor and presents solutions for those problems.

Discovery using cleanup fails when using non-root credentials

ProblemA Utilization sensor discovery using the CLEANUP option fails for anendpoint when using non-root credentials.

SolutionIf the endpoint was last discovered by a TADDM server using rootcredentials, the Utilization sensor scripts deployed to /var/temp have rootsystem access. These scripts cannot be removed by the non-root user ID. Toensure that the cleanup completes correctly, run the Utilization sensordiscovery, using the CLEANUP option, on that endpoint, using rootcredentials. Any existing Utilization sensor scripts are removed.

Metrics data not discovered from a target machine when runningan asynchronous discovery

ProblemAn asynchronous discovery is run, but the IBM Tivoli Utilization sensordoes not discover metrics data on the Solaris operating system.


SolutionYou must start the IBM Tivoli Utilization sensor from the extracted scriptpackage on the target system.

IP device sensorThe IP device sensor creates a lightweight computer system that represents an IPdevice on the network.


IpDeviceSensor


The sensor creates the following model objects:v net.IpInterfacev sys.ComputerSystem

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IP device sensor uses.

com.ibm.cdb.topomgr.reconciliation.compsys.CompSysReconcilatior.disableLMTupdate=false

Specifies whether to update the last modified time of a computer systemthat is discovered by the IP device sensor, when such computer systemexists in the TADDM database and was discovered by other sensors.

To disable the last modified time update, set this property to true. Bydefault, this property is set to false.

IP interface sensorThe IP interface sensor discovers IP interfaces.


IpInterfaceSensor

Limitations

For IPv6 and IPv4 Router Details, the IP forwarding attribute is set to falseregardless of the setting on the discovered Windows system. Do not enable the IPinterface sensor. The function that the IP interface sensor provides is now providedby the appropriate computer system sensor. Enabling the IP interface sensor cancause performance issues.


The sensor creates the following model objects:v net.IpInterfacev net.IpV4Routerv net.IpV6Routerv sys.ComputerSystem


Ping sensorThe ping sensor discovers reachable IP addresses. It gathers information fromdevices and systems that support TCP/IP.


PingSensor

Limitationsv Because of the performance issues, when discovering ping over UDP, the Ping

sensor always uses all defined SNMPv1 and SNMPv3 access list entries,regardless of their scope restrictions.


Configuring the discovery profileYou can configure PingSensor to start a session on IP addresses that are accessiblethrough OSLC Execute Automation session.

The behavior for target systems that are accessible through OSLC ExecuteAutomation session can be changed by setting the following property:com.ibm.cdb.discovery.StartOSLCSessionDirectly

If the property is set to true, the sensor does not ping the ports and the targetsystems that are accessible through OSLC Execute Automation session are notscanned. The Session sensor is started directly after PingSensor for such systems.

If the property is set to false, PingSensor pings all target systems.

The default value of the property is true.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the ping sensor uses.

com.collation.discover.agent.PingSensor.timeout=600000This value specifies the time interval in milliseconds before a timeoutoccurs during a discovery.

com.collation.pingagent.ports=xx,yy,...This property is not defined in the collation.properties file and must bemanually added if needed. Valid values are non-negative numbers thatrepresent ports for the ping sensor to use.

By default, the ping sensor uses port 22, and if it cannot make a connectionto port 22, it uses port 135. To override the default set of the TCP portsthat the ping sensor uses, add this property to the collation.propertiesfile, and specify the TCP port numbers as a comma-separated list.

com.ibm.cdb.discover.enablePingDiscoveryOverUdp=falseIf set to true, the sensor runs additional ping over UDP.

You can also access the property through the Product Console PlatformProperties tab for customized discovery profiles.

Restriction: The scope restrictions for this property are not supported.


com.ibm.cdb.discover.pingUDPPorts=161The valid values are non-negative numbers.

This property specifies which ports are to be scanned during the UDP pingdiscover. By default, the Ping sensor uses port 161. You can also access theproperty through the Product Console Platform Properties tab forcustomized discovery profiles.

Restriction: The scope restrictions for this property are not supported.

com.ibm.cdb.discover.SNMPPingWaitTime=2000This property specifies the time value (in milliseconds) for the Ping sensorto wait for a single ping request sent via the SNMP protocol with a specificSNMP authentication credentials.

Troubleshooting the sensorThis topic describes common problems that occur with the Ping sensor andpresents solutions for those problems.

Ping sensor discovery ends with an unable to establishloopback connection message

ProblemThe sensor fails when the scope of discovery is large, due to a timeouterror, and the following message is displayed:Unable to establish loopback connection

View the log file for a detailed description of the message, for example:<log start>java.io.IOException: Unable to establish loopback connectionat sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:172)at java.security.AccessController.doPrivileged(AccessController.java:246)at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:188)at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:45)at java.nio.channels.Pipe.open(Pipe.java:148)at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:192)at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:53)at java.nio.channels.Selector.open(Selector.java:224)at com.collation.platform.session.Ping$Connector.<init>(Ping.java:303)at com.collation.platform.session.Ping.pingArray(Ping.java:656)at com.collation.platform.session.Ping.pingLoop(Ping.java:574)at com.collation.platform.session.Ping.ping(Ping.java:557)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.do_ping(PingSensor.java:75)at com.ibm.cdb.discover.sensor.net.ping.PingSensor.discover(PingSensor.java:92)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:214)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:1184)at com.collation.discover.engine.DiscoverEngine$DiscoverWorker.run(DiscoverEngine.java:867)Caused by: java.nio.channels.ClosedByInterruptExceptionat java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:216)at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:543)at java.nio.channels.SocketChannel.open(SocketChannel.java:161)at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:120)... 16 more<log end>

SolutionUse one of the following methods to resolve the problems:v Perform the discovery on a smaller scope.v In the collation.properties file, increase the timeout value for a longer

discover time for the following property:com.collation.discover.agent.PingSensor.timeout=600000


Ping sensor discovery ends with error CTJTD0510E

ProblemIf you enable the ping discovery over UDP, it is possible that, whendiscovering large scopes, the sensor ends with the following error becauseit exceeds the limit of open sockets:CTJTD0510E The following error occurred in the ping sensor:Too many open files.

View the log file for a detailed description of the message, for example:<log start>sensor.PingSensor - Exception in Ping Broadcast Agentjava.io.IOException: Too many open files

at sun.nio.ch.IOUtil.makePipe(Native Method)at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:77)at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:48)at java.nio.channels.Selector.open(Selector.java:238)at com.collation.platform.session.Ping$TcpConnector.<init>(Ping.java:354)at com.collation.platform.session.Ping$TcpConnector.<init>(Ping.java:349)at com.collation.platform.session.Ping.pingArray(Ping.java:926)at com.collation.platform.session.Ping.pingLoop(Ping.java:840)at com.collation.platform.session.Ping.ping(Ping.java:821)at com.ibm.cdb.discover.net.ping.sensor.PingSensor.do_ping(PingSensor.java:81)at com.ibm.cdb.discover.net.ping.sensor.PingSensor.discover(PingSensor.java:114)at com.collation.discover.engine.AgentRunner.doRegularDiscovery(AgentRunner.java:349)at com.collation.discover.engine.AgentRunner.run(AgentRunner.java:271)at com.collation.discover.engine.DiscoverEngine.processWorkItem(DiscoverEngine.java:736)at com.collation.discover.engine.worker.DiscoverWorker.processWorkItemWithMetrics

(DiscoverWorker.java:100)at com.collation.discover.engine.worker.DiscoverWorker.run(DiscoverWorker.java:146)

2012-09-12 16:48:29,076 DiscoverManager [DiscoverWorker-5]PingSensor-9.156.46.6⌂9.156.46.254 WARN engine.AgentRunner -[AgentRunner.W.1] AgentException thrown in agentcom.collation.discover.agent.AgentException:CTJTD0510E The following error occurred in the ping sensor: Too many open files .<log end>

SolutionUse one of the following methods to resolve the problems:v Perform the discovery on a smaller scope.v On UNIX systems, increase the open file limit on the discovery server.

For more information about the open file limit, see TADDM serversoftware requirements.

Ping sensor fails with a timeout error

ProblemFor large scopes, the sensor fails with a timeout error.

All the actions of the Ping sensor that are visible in UI are run in asequence. The timeout value that is specified in the collation.propertiesfile defines the total time that is needed to finish those actions.

SolutionUse one of the following methods to resolve the problems:v Perform the discovery on a smaller scope.v In the collation.properties file, increase the timeout value for a longer

discover time for the following property:com.collation.discover.agent.PingSensor.timeout=600000

The sensor does not discover endpoints over the UDP protocol

ProblemWhen discovering endpoints that are accessible only over the UDPprotocol, some of them are missing.


SolutionYou must configure the properties that are responsible for the discoveryover the UDP protocol. For more information about those properties, seeConfiguring the collation.properties file.

To retrieve information about open UDP ports, the Ping sensor uses theSNMP protocol to query the discovery endpoints. Make sure that theproper SNMP or SNMPv3 authentication credentials are provided in theTADDM access list. You can also verify if your firewall passes the networktraffic through the ports that are specified in thecom.ibm.cdb.discover.pingUDPPorts property.

Port sensorThe port sensor discovers open ports on a host system.

You can change certain aspects of the port sensor using the sensor configurationfile. You must create a custom discovery profile to change the port sensorconfiguration. Before changing the configuration file, contact IBM SoftwareSupport.


PortSensor

Troubleshooting the sensorThis topic describes common problems that occur with the Port sensor andpresents solutions for those problems.

The sensor does not discover any open UDP ports

ProblemWhen discovering the endpoint ports, the sensor does not find any openUDP ports.

SolutionYou must configure the properties that are responsible for the discoveryover the UDP protocol. For more information about those properties, seeConfiguring the collation.properties file. The Ping sensor and the Portsensor use the same properties for discovery over the UDP protocol.

To retrieve information about open UDP ports, the Port sensor uses theSNMP protocol to query the discovery endpoints. Make sure that theproper SNMP or SNMPv3 authentication credentials are provided in theTADDM access list. You can also verify if your firewall passes the networktraffic through the ports that are specified in thecom.ibm.cdb.discover.pingUDPPorts property.

Session sensorThe session sensor creates a session between the TADDM server and the targetcomputer system. Typically, the session is either a Secure Shell (SSH) session or aWindows Management Instrumentation (WMI) session.


SessionSensor



Access list entries with type Computer System are tried sequentially until a sessionis established. For Windows targets, access list entries with type Computer System(Windows) are used.

TroubleshootingThis topic describes common problems that occur with the session sensor andpresents solutions for those problems.

Fix Pack 2

CTJTD0591W Session IP not found within discovered IPinterfaces

ProblemThe IP being discovered does not actually exist in the interface list of theobject.

Usually this means the object being discovered is a load balancer.Discovering load balancers can lead to over-merges. For example, if youhave three computers behind the load balancer, the ssh requests from thesensor may go to different targets each time. This would result in all threecomputers merging over time.

SolutionA new property has been added to the session sensor:com.collation.discover.agent.sys.SessionSensor.loadBalancerIp

The default is false.

If set to true, then this property stops the session sensor if it senses thiscondition.

Note: After the failure of the session sensor, the SnmpSensor will not betriggered either.

Sensors fails with access denied error message

ProblemDuring a discovery of Windows Server 2012 with User Account Controlturned on, the following error message is displayed:CTJTP1163E The following WMI session and SSH sessions cannot be established(WMI: SELECT BuildVersion FROM Win32_WMISetting failed: Access is denied.

SolutionThis message indicates that User Account Control settings are toorestrictive. To fix the problem, complete the following steps:1. On the target machine, run the Registry Editor, Regedit.exe.2. Set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\

CurrentVersion\Policies\System LocalAccountTokenFilterPolicyvalue to 1.

3. In the Control Panel window, click the Administrative Tools tab andopen Local Security Policy.

4. Expand Local Policies and click Security Options.5. Change the following policies:v Set the Behavior of the elevation prompt for administrators in

Admin Approval Mode policy to Elevate without Prompting.


v Set the User Account Control: Detect application installations andprompt for elevation policy to Disabled.

In order to configure policies on the system with Active Directory,complete the following steps:1. In the Control Panel window, click the Administrative Tools tab and

open Group Policy Management.2. Choose forest and domain and select Default Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security

Settings/Local Policies/Security options.5. Change the following policies:v Set the Behavior of the elevation prompt for administrators in

Admin Approval Mode policy to Elevate without Prompting.v Set the User Account Control: Detect application installations and

prompt for elevation policy to Disabled.

⌂SSH discovery of Windows target with Tectia SSH Server failswith the invalid virtual path error

ProblemThe SSH discovery of a Windows system fails, and the log files contain thefollowing message:java.io.IOException: SSHSCP1.readResponse, error: scp: invalid virtual path

SolutionTectia SSH Server supports virtual folders. It is possible to remove alldefault virtual folders named C:, D:, E:, and so on, and to define virtualfolders named C, D, E, and so on. In such case, full paths with colons inname, for example /C:/folder/example.txt, are not accepted by the server.To solve this problem, complete one of the following steps:v Modify Tectia SSH Server configuration by defining virtual folders with

colons.v Add the following scoped property to the collation.properties file:

com.ibm.cdb.session.tectia.filepath.removeColon=true

You can define the preceding flag only for the selected IPs and scopesets. For example:com.ibm.cdb.session.tectia.filepath.removeColon.10.11.12.13=truecom.ibm.cdb.session.tectia.filepath.removeColon.scopesetA=true

The application cannot establish the WMI session

ProblemThe following warning message can be found in the SessionSensor logs:SessionSensor-10.4.112.196-[445,135] WARN engine.AgentRunner -[AgentRunner.W.1] AgentException thrown in agentcom.collation.discover.agent.AgentException: CTJTP1161E The applicationcannot establish the following WMI session: SessionClientException:Uncaught exception invoking InstallProvider: System.NullReferenceException: Object reference not set to an instance of anobject.

SolutionTo define the cause of the problem, complete the following steps:


1. Test WMI locally by running simple queries, to see whether it returnsany data.

2. Run the following WMI verifyrepository command:Winmgmt /verifyrepository

If simple queries do not return any results, or if the verifyrepositorycommand is corrupted, the cause of the problem is WMI repository. If theverifyrepository command fails, a local server administrator must rebuildthe local WMI repository or recompile it completely from files on theserver. If it does not resolve the problem, further investigation is necessary.

“The RPC server is unavailable” error occurs during discoverywith the session sensor

ProblemWhen you run a discovery by using the session sensor, the following erroroccurs:The RPC server is unavailable. (Exception from HRESULT:0x800706BA>

SolutionCheck whether the reverse DNS lookup function works properly for thefailing target. Run the following command from the TADDM discoveryserver, or the anchor server:nslookup target-IP-address

Check if the IP address of the target is correctly mapped to its FQDNname.

Configuring the collation.properties file entriesYou can configure the session sensor by modifying the collation.properties fileentries

Fix Pack 4 com.collation.discover.agent.sys.SessionSensor.timeout.snmp=falseThis property specifies whether SNMP MIB2 sensor starts after the sessionsensor times out.


By default, when the session sensor times out, the SNMP MIB2 sensor isnot started. At the same time, when the session sensor fails for otherreason than a timeout, or the CTJTD0591W error, the SNMP MIB2 sensor isstarted. If you want the SNMP MIB2 sensor to be started also when thesession sensor times out, set the value of this property to true.

Fix Pack 2 com.collation.discover.agent.sys.SessionSensor.loadBalancerIp=falseThis property specifies whether the session sensor is stopped when thediscovered object is a load balancer.

The default value is false, which means that the sensor is not stopped.

Discovering load balancers might lead to over merges. If the error“CTJTD0591W Session IP not found within discovered IP interfaces”occurs, change the value of this property to true.

Note: When this property is set to true, and the session sensor is stopped,the SNMP MIB2 sensor is not started.


Solaris zones generic sensorThe Solaris zones generic sensor discovers applications running on Solaris localzone systems.

The sensor results are used to start specific application sensors, such asIplanetServerSensor, WeblogicServerSensor, or CustomServerSensor, which discoverapplication servers that TADDM does not automatically categorize.

This sensor uses a discovery approach that is different from other UNIX systems.Rather than running a discovery against local zone systems directly, a global zonesystem is used to start the ZonesGenericSensor. This is because the lsof tool isunavailable on local zones. To retrieve all operating system details of the localzone, you must include the IP address of the local zone in the discovery scope.


ZonesGenericSensor

Prerequisites

The credentials for local and global zones must be entered in the access list (eitherusing SSH key-based authentication or SSH login-based authentication).

Security issues

To correctly discover applications running on a local zone, the TADDM serviceaccount in the local and global zones must have access to the ps command withfull command-line arguments.

Use the following method, to ensure access when the root account or the setuidbit are not used. Modify the following properties in the $COLLATION_HOME/etc/collation.properties file to configure the ps command to use sudo:v com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps axww

v com.collation.platform.os.command.psEnv.SunOS=sudo /usr/ucb/ps axwweee

v com.collation.platform.os.command.psUsers.SunOS=sudo /usr/ucb/ps auxw

Limitations

Note the following limitations:v The sensor does not create ProcessFileSystemMapping objects for local zones.

When a process running on a local zone uses an NFS share, the dependencybetween the application server and the NFS Server is not created.

v When WebLogic 8 (all releases) managed and admin servers are running on localzones, the runtime information is stored using the CustomAppServerSensor. TheCustomAppServerSensor is started by the WeblogicVersionSensor. You mustinclude all local and global zone IP addresses in the discovery scope. Inaddition, ensure that the custom server list contains at least one template tomatch the WebLogic command line and that the custom server is enabled.

v When running a discovery through an anchor server, include the IP addresses ofthe local and global zones in the same scope set as the anchor.

v Internet Protocol version 6 (IPv6) is not supported when running a discovery ona local zone.




Troubleshooting the sensorThis topic describes common problems that occur with the Solaris zones genericsensor and presents solutions for those problems.

Solaris zones generic sensor is not started because of anincorrect IP address of a zone

ProblemSolaris zones generic sensor is not started. In the error log files, you canfind the information that a zone has an incorrect IP address. The logsindicate that the IP address is generated by the host zoneName command.

Fix Pack 2 Solution

If you use TADDM 7.3.0.2, or later, go to the collation.properties file,and set the com.collation.hostnameforzoneip property to false.

Stack Scan sensorThe Stack Scan sensor provides credential-less discovery (less intrusive discovery)of the installed operating system and open ports on a computer system.

In addition to Nmap, discovery sensor can use Tivoli Remote Execution and Access(RXA) for Windows discovery. It can discover MAC address of L2Interface.


StackScanSensor

Prerequisites

The sensor requires the following software:v Nmap tool. See “Configuring Nmap” on page 278 for details.v WinPcap tool for Windows operating systems. Although this tool is available on

the TADDM DVD, you must install it manually because it is not installed duringthe TADDM installation.

v Sudo tool for non-Windows operating systems.

For TADDM on AIX operating systems: For the TADDM user to use the nmaptool through sudo, you must install and configure sudo version 1.6.7p5. This isbecause TADDM has problems with the most recent sudo version, which isversion 1.6.9p15.

Security issues

To configure sudo access for the TADDM user, you need to set a nopasswd optionin the /etc/sudoers file for the TADDM user.


Limitations

Firewalls between targeted scopes and the TADDM server or remote anchors canseverely degrade Stack Scan reliability and performance. In this situation, useremote anchors behind the firewall to improve performance. The version of theoperating system might not be discovered properly depending on what the StackScan sensor receives from Nmap. For example, Windows Server 2008 is classifiedas Windows Vista, AIX 6.x as AIX 5.x, Linux for System z as Other ComputerSystem. The discovery of computer systems running the Tru64 UNIX operatingsystem is not supported by Nmap. Use the following command to check theoperating system version returned by Nmap:nmap -T Normal -O -sS -sU -oX - IPaddress

Application servers and services discovered using a credential-less (Level 1)discovery are reconciled with the application servers and services using a Level 2or Level 3 discovery, only if the binding TCP ports are the same. All applicationservers and services discovered using a Level 1 discovery remain following a Level2 or Level 3 discovery, but applications and services matching on the binding portsare merged.


The sensor creates the following model objects:v net.IpAddressv net.IpInterfacev net.L2Interfacev sys.aix.Aixv sys.aix.AixUnitaryComputerSystemv sys.ComputerSystemv sys.hpux.HpUxv sys.hpux.HpUxUnitaryComputerSystemv sys.i5OS.I5OperatingSystemv sys.linux.Linuxv sys.linux.LinuxUnitaryComputerSystemv sys.OperatingSystemv sys.sun.Solarisv sys.sun.SunSPARCUnitaryComputerSystemv sys.tru64.Tru64v sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystemv sys.zOS.ZOSv sys.zOS.ZSeriesComputerSystem

Configuring the sensorBefore running a discovery of the installed operating system and open ports, youmust configure the Stack Scan sensor.

Configuring NmapThe Stack Scan sensor uses Nmap to gather data about the targets forcredential-less discovery.


Installing Nmap

Before installing Nmap for any operating system, see the TADDM support site athttps://www-947.ibm.com/support/entry/portal/product/tivoli/tivoli_application_dependency_discovery_manager?productContext=267282604 forrecent news about your specific operating system and Nmap versions.

Nmap is not installed during the TADDM installation. The Nmap tool is availableon TADDM DVD #2, and you must install it manually. Install Nmap on theTADDM server and all anchor servers. For more information, see the readme file inthe Nmap directory on the DVD.

Configuring root authority

For non-Windows platforms, give root authority for all commands to the TADDMuser ID that starts the TADDM server.

If you are using a TADDM anchor server, give root authority to the discoveryservice account on the anchor server.

As root user, add the following line in the /etc/sudoers configuration file, usingthe visudo command:TADDM_userid ALL=(ALL) NOPASSWD:ALL

wherev TADDM_userid is the user ID that starts the TADDM server, or the discovery

service account on an anchor.

If the sudoers file contains a Defaults requiretty line, comment it out or deletethe line.

When the Stack Scan sensor is running with Nmap, the TADDM server user IDcan be given root execution permission only for the Nmap command. Add thefollowing line in the /etc/sudoers configuration file:TADDM_userid ALL=(ALL) NOPASSWD:nmap_path

wherev TADDM_userid is the user ID that starts the TADDM server, or the discovery

service account on an anchor.v nmap_path is the full path to the location of the nmap command.

If the sudoers file contains a Defaults requiretty line, comment it out or deletethe line.

Configuring the Path environment variable

Nmap must be installed on your TADDM server and on all anchor servers. TheNmap command must be in the $PATH environment variable for the TADDM userID that starts the TADDM server. If you are using a TADDM anchor server, theNmap command must be in the $PATH environment variable for the discoveryservice account.

On Windows platforms, take the following steps to set the Path systemenvironment variable to include the directory where Nmap is installed:1. Click Start > Control Panel > System


https://www-947.ibm.com/support/entry/portal/product/tivoli/tivoli_application_dependency_discovery_manager?productContext=267282604

https://www-947.ibm.com/support/entry/portal/product/tivoli/tivoli_application_dependency_discovery_manager?productContext=267282604

2. Click the Advanced tab, and select Environment Variables.3. Edit the Path system variable and add the directory where Nmap is installed.4. Restart the computer.

This task makes Nmap available to services on the computer.

Verifying that Nmap is working

To verify that Nmap is working complete the following steps:1. Log in to the system using one of the following TADDM user IDs:v The user ID that starts the TADDM server.v The user ID that starts the discovery service account on the anchor server.

2. Run the following command:sudo nmap -T Normal -O -sS -oX - IPaddress/32

wherev IPaddress is a valid host system that is up and running on your network.The output produces an XML document that shows the ports and operatingsystems on that computer system.

Limitation

Because of a limitation on AIX, only four active Nmap commands can be run atthe same instance. To ensure that this limit of Nmap commands is not exceeded,complete the following steps:1. Create a discovery profile.2. In the new discovery profile, create a StackScanSensor configuration, and

enable the configuration.3. Set the values of the following properties to 1:v nmapMaxOsScanTreadsv nmapMaxPingScanTreads

4. To save the configuration, click OK.5. To save the discovery profile, click Save. Use this discovery profile for

StackScan discoveries.6. If the number of computer systems in the scope being discovered exceeds 2048,

set the following property in the collation.properties file:com.collation.discover.dwcount=4

Configuring the discovery profileIf you want to create application servers based on the active TCP/IP portsdiscovered, update the discovery profile for the Stack Scan sensor.

To configure the sensor to create application servers, complete the following steps:1. Create a new discovery profile based on a TADDM Level 1 profile.2. Create a new sensor configuration in the new profile based on the Stack Scan

sensor configuration.3. In the new sensor configuration, set the enableNmapPortApplicationCreation

property to true.

To configure the sensor to use winscanner, complete the following steps:1. Create a new discovery profile based on a TADDM Level 1 profile.


2. Create a new sensor configuration in the new profile based on the Stack Scansensor configuration.

3. In the new sensor configuration, set the scanners property to nmap,winscanner.

You can further configure which application servers are to be created based on thediscovered ports using the PortAppScanSensor.properties file located in theosgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory.Specific instructions for modifying the association between ports and applicationservers appear at the top of the PortAppScanSensor.properties file.

Configuration errors in the PortAppScanSensor.properties file are reported in thePortAppScanSensor.errors file, located in the osgi\plugins\com.ibm.cdb.discover.sensor.idd.stackscan_7.1.2\etc directory.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Stack Scan sensoruses.

The Stack Scan sensor uses the following entries in the collation.properties file:

com.collation.sudoCommand=sudoThis value specifies the sudo location.

com.collation.discover.agent.StackScanSensor.timeout=7200000This value specifies the time interval in milliseconds before a timeoutoccurs during a discovery.

Troubleshooting the sensorThis topic describes common problems that occur with the Stack Scan sensor andpresents solutions for those problems.

The Stack Scan sensor completes successfully, but no ComputerSystems are stored

ProblemDoing a Level 1 discovery, the Stack Scan sensor finishes without errors,but it does not store any computer system information. In theservices/DiscoveryManager.log, you see the following message:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed:sudo: sorry, you must have a tty to run sudoFrom the TADDM server command line you can successfully do ansu - <run as user>and thensudo "nmap -0 10.1.2.3

Solution

For non-windows platforms, give root authority for all commands to theTADDM user ID that starts the TADDM server. In addition, if you areusing a TADDM anchor server, give root authority to the discovery serviceaccount on the anchor server. See “Configuring Nmap” on page 278 fordetails.


The Stack Scan sensor does not discover Computer Systems ona Linux system

Problem On a Linux server, when performing a Level 1 discovery, the Stack Scansensor completes successfully, however, there are no Computer Systemsstored.

In the services/DiscoveryManager.log, the following message can be seen:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]WARN cdb.STDERR - Mar 26, 2008 11:05:26 AM invocation failed: sudo: sorry,you must have a tty to run sudo

You see this error even though the sudo command works successfully forthe run_as user from the command line.

SolutionComplete the following steps:1. Type the OS command visudo to edit the /etc/sudoers file2. Once the file opens, comment out the line Defaults requiretty.3. Save and close the file.

The network configuration on Linux for System z systems doesnot create packets that Nmap can read

Linux for System z supports both OSA and VSWICH network interfaces operatingin Layer 3 (Network Layer) or Layer 2 (Link Layer) mode. If operating in Layer 2mode, TCP packets contain a valid ethernet Link Layer header required by Nmap.However, systems using OSA or VSWITCH operating in Layer 3 mode requireadding the QETH_OPTIONS=’fake_ll=1’ to the hardware configuration file for theinterface. The following section describes how to modify the hardwareconfiguration file enabling Nmap to operate with Layer 3 network interfaces.

For more information about OSA and VSWITCH and their operating modes, seeChapter 7 “qeth device driver for OSA-Express (QDIO) and HiperSockets™” in theLinux on System z Device Drivers, Features, and Commands at: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf.

ProblemThe network configuration on Linux for System z systems does not createpackets that Nmap can read.

The Stack Scan sensor uses Nmap to gather data about the targets forcredential-less discovery. If Nmap is not working properly, the Stack Scansensor does not store any computer systems.

Although the sensor runs without errors, the Linux for System z systemthat is running the Stack Scan sensor returns the following message:stored - 0 ComputerSystems in the database

If you type the nmap <hostname> command for any system other than thelocal host, the following message is displayed:Note: Host seems down. If it is really up,but blocking our ping probes, try -P0...

SolutionDepending on your operating system, perform the following actions:


http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/lk31dd03.pdf



On SUSE Linux for System z systemsThe network must run with the following option:QETH_OPTIONS=’fake_ll=1’

Add this option to the configuration file for the NIC. Dependingon the NIC that is used, the name of the file changes. Contact yoursystem administrator for the name of the configuration file thatyour system uses.

The configuration file must be in the /etc/sysconfig/hardwaredirectory. The file name might be hwcfg-qeth-bus-ccw-0.0.5000.

On RedHat Linux for System z systemsThe network must run with the following option:OPTIONS=’fake_ll=1’

Add this option to the configuration file for the NIC. Dependingon the NIC that is used, the name of the file changes. Contact yoursystem administrator for the name of the configuration file thatyour system uses.

The configuration file must be in the /etc/sysconfig/network-scripts directory. The file name might be ifcfg-eth0.

Verify that the alias in the /etc/modprobe.conf file includes thefollowing information:alias eth0 qeth

Computer system displays in the incorrect category

ProblemThe computer system displays under the OtherComputerSystem category.

SolutionCheck the OS type. If it is correct, check the confidence. If the confidence isbelow the confidence threshold value (the default is 40), then what you areseeing is expected.

You can change the confidence threshold to have the computer systemappear under the correct category. The threshold is configured 0 - 100. Thethreshold can be set using the sensor configuration attribute:confidenceThreshold.

Need enhanced Stack Scan sensor debugging

ProblemNeed to enable enhanced debugging of the Stack Scan sensor.

SolutionComplete the following steps:1. Check the local-anchor-<machine>.log file to see if Nmap was used by

the sensor.2. Enable further debugging by doing the following:

In the collation.properties file, set one of the following:v com.collation.log.level.StackScanSensor=TRACE

v com.collation.log.StackScanSensor=TRACE

v com.collation.log.level=TRACE


This method produces a verbose trace of what the sensor is doing, theresults, the configurations used, and more.

Stack Scan sensor fails with a message: sudo: sorry, you musthave a tty to run sudo

ProblemDuring a discovery, if the Discovery Management Console where theTADDM server was started is closed, the sensor fails. The message:sudo:sorry, you must have a tty to run sudo is displayed. If you startthe Discovery Management Console and leave it open the sensor works.

Solution

Comment out or delete the Defaults requiretty line from the/etc/sudoers configuration file on the TADDM server.

Stack Scan sensor is unable to run the sudo nmap command

ProblemThe Stack Scan sensor fails with the following error message: "Sorry, sudohas been configured to not allow root to run it." However, you cansuccessfully run sudo nmap at a command line.

SolutionThis problem occurs when the system is configured not to allow the rootuser to run the sudo command. To fix the problem, edit thecollation.properties file and set thecom.ibm.cdb.discover.sensor.idd.stackscan.alwaysUseLocalAnchor propertyto true. Then restart the TADDM server.

The Stack Scan sensor does not discover Computer Systems onan AIX system

ProblemOn an AIX server, when performing a Level 1 discovery, the Stack Scansensor completes successfully, however, there are no Computer Systemsstored.

In the services/DiscoveryManager.log, the following message can be seen:2008-03-26 11:05:26,845 DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])]DiscoverManager [nmap-ping[0] (i1|s[9.42.36.223])] DEBUG stackscan.ExecCmd - standard err:/taddm/cmdb/dist/nmap/nmap-4.76/nmap[25]: 708778 Segmentation fault(coredump)

In the Nmap folder a core file is created during the discovery.

SolutionCreate a discovery profile or edit an existing profile for the Stack Scansensor. In the Configuration section of the Create Configuration window,click nmapExec. Then double-click the Value field in the row, and append-d to the value nmap. For example, the new value is nmap -d.

After you enable winscanner some of the discoveredComputerSystems have the signature with no MAC address.

ProblemA custom Level 1 discovery is run with only the nmap scanner enabled.Then, another discovery is run on the same scope with both nmap andwinscanner enabled. Discovered computer systems have signatures with noMAC addresses.


SolutionThe Stack Scan sensor stores information only about those target systemsthat are not discovered yet. Computer systems that are already present inthe TADDM database are not updated. Delete the computer systemsmanually and run discovery again.

Stack Scan sensor never updates CI objects already stored intoTADDM DB during Level 1 discovery

Problem During a Level 1 discovery, the Stack Scan sensor stores informationexclusively (bold) for those new IP objects systems that are not discoveredyet and this is as per the way the Level 1 Discovery is designed inTADDM. Thus, the CI Computer systems that are already present in theTADDM database, are not updated by the StackScan sensor in case of anychanges. Until now, the only possible action for TADDM to be able toupdate the stored CI objects, that were discovered and stored as fake"shallow" objects initially during first time Level 1 discovery is to deletethe computer systems manually and then run the discovery again, or evenrun a Level 3 discovery.

SolutionA new feature has been introduced into FP4 to avoid the TADDM creationof fake "shallow" objects that usually occurs when you got pingable IPaddresses without a corresponding system (creation of low OS confidenceshallow ComputerSystems).

com.ibm.idd.stackscanner.confidence.skip=default 0

WPAR generic sensor⌂The WPAR generic sensor discovers applications that run on WPAR systems.

The sensor results are used to start specific application sensors, such asJBossSensor, WebSphere Sensor, and so on.

The discovery process of this sensor is different than of other UNIX systems.Rather than running a discovery against WPAR systems directly, an LPAR systemis used to start the WPARGenericSensor. This is because the kdb command isunavailable on WPARs and the sensor is not able to convert open sockets toprocess PIDs. The whole discovery process is based on the netstat command. Thelsof command is not used.


WPARGenericSensor

Prerequisites

You must add the credentials for LPAR and WPAR to the access list.

Limitations

The sensor does not create ProcessFileSystemMapping objects for LPAR andWPARs.




zEnterprise sensorTo discover the zEnterprise® environment, the sensor uses the Enterprise CommonCollector (ECC). The ECC is a single entry point for querying all inventory dataabout the zEnterprise components, both hardware and software.

The TADDM zEnterprise sensor establishes a secure connection with the ECC andgathers all necessary data to create a tree of CDM objects. Then, the sensor storesthem into TADDM and thus no entry into each of the components is necessary.The ECC is a web application that is deployed on a web server. Therefore, thezEnterprise sensor depends on the Port sensor to identify the port that the ECClistens on. The zEnterprise sensor stores objects that describe the physical andvirtual structure of zEnterprise, zBladeExtension, and computer systems.

If you want to discover a virtual computer system, you must install and start theGuest Platform Management Provider agents that deliver information about theoperating systems to the ECC.

The sensor stores the following objects that describe the physical, virtual, andlogical components:v zEnterprise: physical packages, appliancesv zEnterprise BladeCenter Extension: BladeCenters, chasises, racks, bladesv Computer systems: System z, z/VM® LPARs, PR/SM™ LPARsv Logical Components: Ensemble, Workload Resource Groupsv Virtual Components: Virtual Servers, Virtual Networks, Virtual Storage

Resources

Note: For virtual computer systems, the objects are placeholders.


com.ibm.cdb.discover.sensor.sys.zenterprise_1.0.0.

Prerequisites

For the zEnterprise discoveries, ensure that the following prerequisites are met:v The Enterprise Common Collector (ECC) version 1.1.0.2

The ECC is shipped as a distinct component. You must install and configure itseparately. However, the sensor can use an ECC instance that is already installedand configured for use by another application, such as the zEnterpriseMonitoring Agent shipped with IBM Tivoli Monitoring. For more informationabout installing and configuring the ECC, see the Enterprise Common CollectorConfiguration Guide and Reference.

v The Guest Platform Management Provider agentsYou must install, configure, and run the GPMP agents on each of the virtualcomputer systems. Without those agents, the sensor is unable to detect theoperating system and the unique identification of the discovered computersystems.


Security issues

The zEnterprise sensor needs an IP address and port to communicate with theECC. This information is required because the sensor calls the ECC RESTful API,receives the data, and then puts it into a data object structure which is then passedto TADDM to be stored.

Limitations

Virtual computer systemsReconciliation of objects that are stored by the zEnterprise sensor andoperating system sensors, such as the Linux computer system sensor, AIXcomputer system sensor, and Windows computer system sensor, is notalways possible because there are cases when the ECC cannot recognizethe type of a virtual computer system or its identification data if a GuestPlatform Management Provider agent is not running there.

By default, the sensor stores only known virtual computer systems withcorrect identification set. Any virtual computer system that does not fulfillthis requirement is skipped and an appropriate warning message isdisplayed.

You can, however, enable storing all discovered virtual computer systems,even the ones of an unknown type. Such computer systems are visible inthe Other Computer Systems section. If possible, reconciliation matchesthe MAC address from the unknown computer system that is discoveredby the zEnterprise sensor with the L2Interfaces MAC addresses of thecomputer systems discovered by the platform sensors, and merges them.To make the computer systems merge automatically, you must first run theplatform sensors, and then the zEnterprise sensor. The reverse sequence ofdiscovery, that is launching the zEnterprise sensor first, does not assure theautomatic merging.

LPARsBefore you discover the zEnterprise environment with the zEnterprisesensor for the first time, check if any previously discovered LPARs becamea part of the zEnterprise environment, and thus are visible through Systemz Hardware Management Console or the ECC. In such case, run adiscovery of those LPARs with the Linux computer system sensor to avoidduplicates.

Sharing a common ECC instance among multiple applicationsThe Enterprise Common Collector is a common component that is designed to beused by multiple applications and thus it is possible to have a single ECC instancethat serves multiple IBM products. If you want to share an ECC instance, you mustensure that its version is compatible with those of other applications.

About this task

Each version of the ECC has an API major version and an API minor version thatis associated with it. You cannot connect an instance of an application, such as thezEnterprise sensor, with an ECC instance that does not have a compatible APIversion. In such a situation, an error message shows both the detected and theexpected API versions.

The zEnterprise sensor version 1.0.0 requires:v The ECC API major version 1


v The ECC API minor version 2 or higher

Procedure1. Use the following URL to determine the API major and minor versions of an

ECC instance. You can enter the URL into a web browser of any system thathas a network connection to the system that the ECC is installed on:https://ecc_hostname:ecc_port_number/eccapi/version

By default, the port number is 8443.2. Continue to the website even if it displays a warning that the certificate was

not issued by a trusted certificate authority.3. Determine the api-major-version and api-minor-version from a JSON or XML

string from the website. The following is an example of this string:{"class":"ecc-version","self":"/eccapi/version","name":"ECC version","description":"Information about the ECC and ECC API version","api-major-version":1,"api-minor-version":2,"ecc-version":"1.1"

}

4. Depending on the API major and minor versions, complete one of thefollowing actions:v Major version is 1, minor version is 1. This version of the ECC is

incompatible with the zEnterprise sensor. You must upgrade the ECC toversion 1.1.0.2, which is provided with TADDM. For more information aboutupgrading the ECC, see the Enterprise Common Collector Configuration Guideand Reference.

Note: After upgrading the ECC, you might need to upgrade otherapplications, such as zEnterprise Monitoring Agent of IBM Tivoli Monitoring,that use the ECC.

v Major version is 1, minor version is 2 or higher. This version of the ECC iscompatible with the zEnterprise sensor. You can use both the sensor and theECC.

v Major version is 2 or higher: This version of the ECC is incompatible withthe zEnterprise sensor. You can use this instance of the ECC, but you mustupgrade the zEnterprise sensor to a newer version.

Model objects with associated attributesThe zEnterprise sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about thezEnterprise environment.

The sensor creates the following model objects:

Hardware Management Console (HMC) application (Console)

v phys.physpkg.PhysicalPackagev sys.appliance.Appliancev sys.zOS.ZHMCv sys.OperatingSystemv net.L2Interfacev net.IpV4Address


v net.IpV6Addressv net.IpInterfacev net.IpNetwork

Ensemble

v core.Ensemble

Central Processor Complex (CPC)

v phys.physpkg.PhysicalPackagev sys.zOS.ZSeriesComputerSystem

zEnterprise BladeCenter Extension (zBX)

v sys.zOS.ZBXFeature

Rack

v phys.physpkg.Rack

BladeCenter

v phys.physpkg.Chassisv sys.ComputerSystem

Blade

v phys.physconn.Slotv phys.physpkg.Boardv sys.ComputerSystemv sys.appliance.SmartAnalyticsOptimizerv sys.appliance.DataPowerv sys.OperatingSystemv net.L2Interfacev net.IpV4Addressv net.IpV6Addressv net.IpInterfacev net.IpNetwork

zVM Virtualization Host

v sys.zOS.ZVM

Virtual Server

v sys.ComputerSystemv sys.zOS.ZVMGuestv sys.OperatingSystemv net.L2Interfacev sys.zOS.ChannelSubSystem

Logical Partition (LPAR)

v sys.zOS.LPARv sys.OperatingSystem

Virtual Network

v net.Vlan

Workload Resource Group

v sys.zOS.WorkoadResourceGroupv service.ServiceInfrastructurePerformancePolicy


v service.ServiceInfrastructureServiceClass

Virtualization Host Storage Resource

v dev.StorageVolume


The following configurations are required:v Access list entry with user ID and password for the ECC, and certificate for

HTTPSv The zEnterprise sensor discovery configurationv Scope

The following configurations are optional:v Timeout configurationv Full discovery configuration

Configuring the access listUse the following access details to configure the access list.

About this task

Before querying the restful API, the sensor must authenticate with the ECC byusing a user name, a password, and certificate. Those credentials are supplied toTADDM by using a new component type in Access List: Data Collectors. One ofthe supplied entries in the access details is a truststore with the ECC certificate.

The sensor uses the truststore to establish a secure, encrypted session with theECC. It is created with the use of keytool, the Java key, and certificate managementutility. Any computer system that has Java installed can be used to create suchtruststore. If such a computer system is not available, use the Java RuntimeEnvironment (JRE) that is installed with the ECC.

You can find the ECC certificate in the following location, where key_alias is thekey alias that is specified during ECC installation:ecc_install_path/certificates/key_alias.cert

Procedure1. To create the truststore and import the certificate, run the following command.

Enter the command on one line.jre_path/bin/keytool -import -noprompt -alias key_alias-file certificate_path/key_alias.cert-keystore truststore_name -storepass truststore_passphrase -storetype JKS

The following example shows a command that is run to create a truststore withthe ze_sensor_truststore name and the Fa8asTek passphrase by using the ECCJRE.ecc_install_path/jre/jre/bin/keytool -import -noprompt-alias key_alias -file <ECC install path>/certificates/key_alias.cert-keystore ze_sensor_truststore -storepass Fa8asTek -storetype JKS

2. Copy the truststore to the system where you configure the access list.3. In the Access Details window, select Data Collectors as the Component Type.4. Specify the access information of an ECC client with the Explorer role.


5. Click SSL settings to import the ECC truststore file into TADDM.a. In the Upload truststore Certificate field, specify the truststore file.b. In the Passphrase field, specify the passphrase.c. Specify the SSL Type as JKS.d. Leave the Key Store fields empty.

6. Click OK.

Configuring the discovery profileYou can use the following options to configure the zEnterprise sensor discovery.

Port sensor configuration

You must add the ECC port to the Portlist option of the Port sensor configurationand specify it in the enterpriseCCPortList option. The enterpriseCCPortList optionis used to establish which port that is listed in the Portlist is the one that the ECClistens on. The sensor uses this option also to establish the list of ports that aresubject to additional actions, such as execution of the zEnterprise sensor. The samelist of ports must be specified in the portList option for the sensor to run.

ZEnterprise sensor configuration

You can use this configuration to extend timeout and retry counts to tune theconnection to the ECC, or to change any URL for queries if any alterations of thosequeries are made in the future ECC versions.

If you want to capture the entire zEnterprise landscape, you can set thestoreUnknownComputerSystems flag to true. This parameter forces the sensor tostore a computer system of an unknown type or the one without properidentification set.

Configuring the scopeScope must contain both the IP address of the host on which the ECC is deployedand its fully qualified domain name. This information is required for positiveverification of the certificates that are used in the authentication process.

Troubleshooting the sensorThis topic describes common problems that occur with the zEnterprise sensor andpresents solutions for those problems.

Error during sensor authentication

ProblemThe sensor fails when it tries to authenticate with the ECC, and the sensorstatus information contains the following error message:CTJTD1541E Error during sensor authentication

Solution

v If the problem is related to Secure Socket Layer (SSL) configuration, thezEnterprise sensor log contains the stack trace for ajavax.net.ssl.SSLHandshakeException. Configure the SSL settings in theaccess details again. It is possible that a truststore was not uploadedpreviously, or that the truststore does not contain the right certificate forthe ECC, or the truststore passphrase is incorrect.

v If the problem is related to the ECC logon, the ECC logs contain one ofthe following messages:


CTGEZ0701E Authentication failed due to unknown user ID user_id.CTGEZ0702E Authentication failed due to invalid password for user ID user_id.CTGEZ0703E Authentication failed due to disabled user ID user_id.CTGEZ0704E Authentication failed due to too many invalid logon attempts by user ID user_id.CTGEZ0705E Authentication failed due expired password for user ID user_id.

The solution varies depending on the ECC log message found:– Update the Data Collector access details by correcting the incorrect

user name or password.– Update the client configuration on the ECC:

- Create a client- Enable the disabled client- Resume the client that has too many invalid logon attempts- Change the expired client password

v If the problem is not related to SSL configuration or the ECC logon,verify that the Data Collector access details exist and that are not limitedby scope. Create access details or change the scope on existing accessdetails.

Error during parsing the ECC data

ProblemThe sensor fails when it tries to parse data that is returned from the ECC,and the sensor status information contains the following error message:CTJTD1542E The sensor failed when trying to parse data returned from the ECC

SolutionThe ECC encountered an error. Check the ECC log files to determine thesolution.

Cannot connect to the ECC because the ECC API version is notsupported

ProblemThe version of the ECC API is not supported by this version of thezEnterprise sensor. The sensor status information contains the followingerror message:CTJTD1581E Could not connect to Enterprise Common Collector withhostname hostname because the Collector API version is not supported;supported api-major-version: supported_major_version;minimum supported api-minor-version: supported_minor_version;actual api-major-version: actual_major_version;actual api-minor-version: actual_minor_version

SolutionUpgrade the ECC or the zEnterprise sensor to a newer version.

The zEnterprise sensor does not run

ProblemThe sensor cannot connect to the ECC, and the Ping sensor statusinformation indicates that it stored 0 IP addresses in the database. Also, thePort sensor and the zEnterprise sensor do not run, or the Ping sensor andthe Port sensor both run but the zEnterprise sensor does not.

SolutionIf the Ping sensor indicates that it stored 0 IP addresses in the database, theECC system cannot be reached. Verify that the host name and IP addressthat is provided for the ECC are correct. Also, ensure that there is nofirewall between the sensor and the ECC.


If the Ping sensor and Port sensor both run, the ECC does not listen on theexpected port. Verify that an ECC instance is installed and runs on thespecified system, and that the portList and enterpriseCCPortListattributes of the Port sensor both contain the ECC port number. By default,the ECC listens on port 8443 but this port number can be changed duringthe ECC installation.

The zEnterprise sensor fails to complete

ProblemThe sensor experienced an unexpected unrecoverable error. The sensorstatus information contains the following error message:CTJTD1544E Enterprise sensor failed to complete. Check log file for additional details

SolutionCheck the log file for more information.

The sensor skips unknown computer systems

ProblemThe sensor cannot determine the type of the operating system that isrunning on a virtual server. The sensor status information contains thefollowing warning message:CTJTD1567E Skipping unknown computer system: computer

SolutionThis message occurs when a virtual server is inactive or when the GuestPlatform Management Provider (GPMP) is not running on the virtualserver. Activate the virtual server, install, and run the GPMP.

Alternatively, you can change the storeUnknownComputerSystems flag totrue to discover all such virtual servers. In such case, the systems arestored as ComputerSystem objects. You can access them from the OtherComputer Systems section of the Data Management Portal.

The sensor skips unknown computer systems without properidentifiers

ProblemThe sensor cannot store a PowerVM® virtual server in TADDM. The sensorstatus information contains the following warning message:CTJTD1568E Skipping computer system that has no proper identificators set: computer

SolutionThe zEnterprise HMC does not provide values for all of the attributes thatare required to uniquely identify a PowerVM virtual server in the TADDMdatabase. The only way to discover PowerVM virtual servers is to changethe zEnterprise sensor configuration storeUnknownComputerSystems flag totrue. In such a case, all the PowerVM virtual servers and all virtual serversfor which the sensor cannot determine the operating system type arediscovered.


Chapter 37. Network sensors

Network sensors discover network devices.

Overview of SNMP sensorsTADDM provides SNMP sensors for discovering SNMP network devices.

Calling sequence for SNMP sensorsThe calling sequence for SNMP sensors is dependent on which sensors are enabledin the discovery profile and on what data is discovered.

In Level 1 discovery profiles, use the SNMP Light sensor with the Stack Scansensor to improve the accuracy of the discovery. In Level 2 or Level 3 discoveryprofiles, use the SNMP MIB2 sensor, which discovers additional data for buildingdetailed Level 2 topologies.

Figure 1 on page 296 illustrates the calling sequence for the SNMP Light sensorand the SNMP MIB2 sensor.

The ping sensor calls the port sensor.

If the SNMP Light sensor is enabled, the port sensor calls the SNMP Light sensor.If the port sensor discovers WMI or SSH ports and if the session sensor is enabled,the port sensor launches the session sensor. If the port sensor does not discoverWMI or SSH ports or if the session sensor cannot establish a connection to theremote host, the port sensor calls the SNMP MIB2 sensor.

Figure 2 on page 296 illustrates the calling sequence for SNMP sensors, startingafter the SNMP Light sensor or the SNMP MIB2 sensor is called.

Depending on the data that the SNMP Light sensor or the SNMP MIB2 sensordiscovers from the devices, the following sensors are called:v If a Cisco device is discovered, the Cisco port sensor and the Cisco VLAN sensor

are called.v If a Fibre Channel switch is discovered, the Fibre Channel switch sensor is

called.v If no Fibre Channel switch is discovered, the Entity MIB sensor and the Bridge

SNMP sensor are called. However, these sensors must be enabled in thediscovery profile.

v If the discovered device matches a custom MIB computer system template, theCustom MIB2 computer system sensor is called.


SNMP MIB walking and debugging SNMP sensorsYou can log SNMP get requests that are sent by the sensors.

To do so, add the following property to the collation.properties file:com.collation.Discover.jvmargs=-Xmx2048M-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider-Dcom.collation.platform.snmp.SnmpPackedPDU.trace=true

You can then compare entries in the log file output with direct SNMP queries yourun against the devices using snmpwalk. You can download SNMP query toolsthat support snmpwalk from http://www.net-snmp.org/download.html.

If SNMP V3 authentication is used with encryption, you must also downloadOpenSSL from http://www.openssl.org/.

The following example shows identical queries, with the first using V3authentication (although the keys have been removed) and the second usingcommunity string authentication:

PingSensor

PortSensor

SnmpLightSensor

SessionSensor

Connectionmade

SnmpMib2Sensor

WMI or SSHavailable

No

No Yes

Figure 1. Calling sequence for SNMP Light sensor and SNMP MIB2 sensor

SnmpMib2SensorSnmpLightSensor

Yes

CiscoVlanSensorCiscoPortSensorCustomMib2ComputerSystemSensor

Is CustomCS?

Is Ciscodevice?

Yes

BridgeSnmpSensorEntityMIBSensorFCSwitchSensor

Is FCswitch?

Yes No

Figure 2. Calling sequence for SNMP sensors, starting after the SNMP Light sensor or the SNMP MIB2 sensor iscalled


http://www.net-snmp.org/download.html

http://www.openssl.org/

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "my authentication password"-x DES -X "my encryption key" 10.199.250.9 .1.3.6.1.2.1.4.20.1

snmpwalk -v 1 -c 5FFGkFaFNs 10.199.250.9 .1.3.6.1.2.1.4.20.1

Maintaining SNMP computer system templates andconfiguration files

You can use the Computer Systems view to maintain a list of templates that can beused to discover network devices.

You can partially define a device, link this definition to a template and then usethe template to discover more information about the device.

An OID is assigned to a device by the manufacturer and is unique to the makeand model of the device. Similar devices of the same model have the same OID.You can typically determine the type of device you have found by searching theWeb. This value can also be obtained for the device by querying the SNMPv2-MIBtables for values under the sysObjectID 1.3.6.1.2.1.1.2.

The SNMP templates and their configuration files are loaded dynamically duringeach discovery. It is not necessary to restart the TADDM server after modifying theSNMP templates and their configuration files. It is important to use the correctsyntax and enter the correct values when editing templates and configuration files.

If your devices are not correctly classified after a discovery, review theSnmpMib2Sensor log or the DiscoveryManager log file.

For more information, see the Adding a computer system template for a network topicin the TADDM User's Guide.

The following results show different OIDs discovered through SNMP scans of fourFoundry devices. In scanning a test environment, the OIDs outlined in Table 16were discovered. You can perform an Internet search to determine the type ofdevices. Alternatively, you can ask your network team to identify the specificdevice types.

Table 16. Foundry OID mapping example

Foundry device OID Description

Foundry FESX448-PREM .1.3.6.1.4.1.1991.1.3.34.2.1.1.2 Router

Foundry FastIron SX .1.3.6.1.4.1.1991.1.3.36.6.2 Unknown (classified as aswitch for our testing)

Foundry BigIron RX .1.3.6.1.4.1.1991.1.3.40.1.2 Unknown (classified as aswitch for our testing)

Foundry NetIron MLX .1.3.6.1.4.1.1991.1.3.44.2.2 Unknown (classified as arouter for our testing)

You can create templates to classify discovered Foundry devices.

Foundry switch exampleThis example shows how to create the SNMP computer system template for aFoundry switch.

Procedure1. In the Discovery Management Console, click Discovery > Computer Systems.

Chapter 37. Network sensors 297

2. In the Computer Systems view, click Add. The Computer System Detailswindow opens.

3. In the Name field, type Foundry Switch.4. In the Action field, select Discover.5. Select Enabled.6. Optional: In the Icon field, click Browse to choose an icon for the device. This

icon is used only to distinguish the template in the Computer Systems view.(The icon is not used during or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.1

Then click Add Criterion.10. For the second criterion, specify the following values:

Sys OID starts-with .1.3.6.1.4.1.1991.1.3.36

Then click Add Criterion.11. For the third criterion, specify the following values:


Then click Add Criterion.12. Click OK. The new template is added to the end of the list.13. To add an action class file for the template, create a file named Foundry

Switch.xml in the $COLLATION_HOME/etc/templates/action directory. Add thefollowing content to the file:<?xml version="1.0" encoding="UTF-8"?>

<resultsxmlns="urn:www-collation-com:1.0"xmlns:coll="urn:www-collation-com:1.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:www-collation-com:1.0urn:www-collation-com:1.0/results.xsd">

<UnitaryComputerSystem array="1" xsi:type="coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem">

<type>Bridge</type><manufacturer>Foundry Networks</manufacturer>

</UnitaryComputerSystem></results>

This XML file specifies that all discovered SNMP computer system devicesmatching the Foundry Switch template use thecom.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Bridge and the manufacturer attribute set toFoundry Networks.

Note: The name of the action class file (without the .xml extension) mustmatch the name of the SNMP computer system template.


What to do next

The new template can be used immediately (you do not need to restart theTADDM server).

Foundry router exampleThis example shows how to create the SNMP computer system template for aFoundry router.

Procedure1. In the Discovery Management Console, click Discovery > Computer Systems.2. In the Computer Systems view, click Add. The Computer System Details

window opens.3. In the Name field, type Foundry Router.4. In the Action field, select Discover.5. Select Enabled.6. Optional: In the Icon field, click Browse to choose an icon for the device. This

icon is used to distinguish the template in the Computer Systems view. (Theicon is not used during or after discovery.)

7. Select MIB.8. In the Identifying Criteria field, select Any Criteria.9. For the first criterion, specify the following values:

Sys OID is .1.3.6.1.4.1.1991.1.3.34.2.1.1.2

Then click Add Criterion.10. For the second criterion, specify the following values:


Then click Add Criterion.11. Click OK. The new template is added to the end of the list.12. To add an action class file for the template, create a file named Foundry

Router.xml in the $COLLATION_HOME/etc/templates/action directory. Add thefollowing content to the file:<?xml version="1.0" encoding="UTF-8"?>

<resultsxmlns="urn:www-collation-com:1.0"xmlns:coll="urn:www-collation-com:1.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:www-collation-com:1.0urn:www-collation-com:1.0/results.xsd">

<UnitaryComputerSystem array="1" xsi:type="coll:com.collation.platform.model.topology.sys.UnitaryComputerSystem">

<type>Router</type><manufacturer>Foundry Networks</manufacturer>

</UnitaryComputerSystem></results>

This XML file specifies that all discovered SNMP computer system devicesmatching the Foundry Router template use thecom.collation.platform.model.topology.sys.UnitaryComputerSystem modelclass, have the type attribute set to Router and the manufacturer attribute set toFoundry Networks.


Note: The name of the action class file (without the .xml extension) mustmatch the name of the SNMP computer system template.

What to do next

The new template can be used immediately (you do not need to restart theTADDM server).

SNMP sensors propertiesYou can control the usage of SNMP sensors by modifying properties in thecollation.properties file.

Fix Pack 2 com.ibm.cdb.discover.snmp.login.timeout=5000This property specifies how long it takes before a login attempt fails.

The default value is 5000 (milliseconds).

Alteon port sensorThe Alteon port sensor discovers Alteon switch port information, including portsthat operate in auto negotiation mode and duplex mode.

The ports are stored in L2Interface with the auto negotiation (enabled or disabled)information. The duplex mode (half duplex or full duplex) is also stored.


AlteonPortSensor

Object identifiers (OIDs) that are used

The sensor uses the following OIDs:v curCfgTable: .1.3.6.1.4.1.1872.2.1.2.3.2.1v portInfoTable: .1.3.6.1.4.1.1872.2.1.9.1.1.1


The sensor creates the following model objects:v net.L2Interfacev sys.ComputerSystem


To configure the access list, enter the following information:v For SNMP V1 and V2 discovery, complete the following steps:

1. Select Network Element (SNMP) as the Component Type.2. Specify the correct Community String.

v For SNMP V3 discovery, complete the following steps:1. Select Network Element (SNMPV3) as the Component Type.


2. Specify the correct user name, password, and authentication protocol,according to the SNMP V3 credential mapping information in the followingtable:

Map from this: To this:

Authentication type (MD5, for example) Authentication Protocol

MD5 Secret Key Password and Confirm Password

Private Authentication Description or Key Private Password

Restriction: To make an initial connection, the sensor requires SNMP version 1.

Alteon SNMP sensorThe Alteon SNMP sensor discovers Alteon load balancer devices.

The sensor discovers the following items:v Real servers and real server groups. Real servers are partitioned into the

respective real server groups. Additional information, such as theLoadBalancingAlgorithm, is also discovered and stored with the real servergroup.

v Virtual ports, real ports, and virtual servers used to create and store virtualservices.


AlteonSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.1872.2.1.5.5.1.1v .1.3.6.1.4.1.1872.2.1.5.5.1.2v .1.3.6.1.4.1.1872.2.1.5.5.1.4v .1.3.6.1.4.1.1872.2.1.5.2.1.1v .1.3.6.1.4.1.1872.2.1.5.2.1.2v .1.3.6.1.4.1.1872.2.1.5.2.1.3v .1.3.6.1.4.1.1872.2.1.5.2.1.10v .1.3.6.1.4.1.1872.2.1.5.10.1.1v .1.3.6.1.4.1.1872.2.1.5.10.1.2v .1.3.6.1.4.1.1872.2.1.5.10.1.3v .1.3.6.1.4.1.1872.2.1.5.10.1.7v .1.3.6.1.4.1.1872.2.1.5.8.1.1v .1.3.6.1.4.1.1872.2.1.5.8.1.2v .1.3.6.1.4.1.1872.2.1.5.8.1.3v .1.3.6.1.4.1.1872.2.1.5.8.1.4v .1.3.6.1.4.1.1872.2.1.5.8.1.5v .1.3.6.1.4.1.1872.2.1.5.8.1.6



The sensor creates the following model objects:v net.vip.RealServerGroupv net.vip.Vipv net.vip.VipFunctionv net.vip.Virtualservicev sys.UnitaryComputerSystemv sys.Function net.vip.RealServer




v For SNMP V3 discovery, complete the following steps:1. Select Network Element (SNMPV3) as the Component Type.2. Specify the correct user name, password, and authentication protocol,

according to the SNMP V3 credential mapping information in the followingtable:






Alteon VLAN sensorThe Alteon VLAN sensor discovers Alteon virtual LANs. This sensor uses theAlteon VLAN Membership MIB to discover VLAN contents.

The SnmpMib2Sensor invokes the AlteonVlanSensor when VLANs are configuredfor Alteon devices. AlteonVlanSensor then invokes BridgeSnmpSensor2 for eachVLAN discovered.

The sensor discovers the VLAN membership table, creates L2Interfaces, andattaches them to the VLAN bridge.


AlteonVlanSensor



The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.1872.2.1.4.2.1v .1.3.6.1.4.1.1872.2.1.2.3.2.1


The sensor creates the following model objects:v net.L2Interfacev net.Vlanv net.VlanInterfacev sys.UnitaryComputerSystem











BIG-IP port sensorThe BIG-IP port sensor discovers F5 BIG-IP port interfaces.

The SnmpMib2Sensor invokes the BigIPPortSensor. The BigIPPortSensor gathersports from the MIB, for example, the interface through which known ports can beaddressed. This allows L2 topology views to be built.


BigIPPortSensor


The sensor follows the standards documented in RFC 1212 to retrieve ports fromthe MIB. Specifically, OID .1.3.6.1.4.1.3375.1.1.5.2.1 is queried to get the interface


through which the port from the MIB can be discovered.


The sensor creates the following model objects:v net.L2Interfacev sys.UnitaryComputerSystem











BIG-IP SNMP sensorThe BIG-IP SNMP sensor discovers F5 BIG-IP load balancers.

The SnmpMib2Sensor invokes the BigIPSnmpSensor if the latter one matches oneof the following OIDs:v .1.3.6.1.4.1.3375v .1.3.6.1.4.1.2021.250.255

The BigIPSnmpSensor collects information about virtual IPs and real server groups.


BigIPSnmpSensor


The sensor follows the standards that are documented in RFC 1212 to get the RealServer Database (RSD) and the Virtual Server Database (VSD) table entries.

The sensor uses the following OIDs:

F5 BIG-IP version 4:


v Pool member table: 1.3.6.1.4.1.3375.1.1.8.2.1v Pool table: 1.3.6.1.4.1.3375.1.1.7.2.1v Virtual Server table: 1.3.6.1.4.1.3375.1.1.3.2.1


v Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2v Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2v Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2v Virtual Server Pool table: 1.3.6.1.4.1.3375.2.2.10.6.2v Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2v sysGeneralChassisSerialNum: 1.3.6.1.4.1.3375.2.1.3.3.3


v Pool member table: 1.3.6.1.4.1.3375.2.2.5.3.2v Pool table: 1.3.6.1.4.1.3375.2.2.5.1.2v Virtual Server table: 1.3.6.1.4.1.3375.2.2.10.1.2v Virtual Server Rule table: 1.3.6.1.4.1.3375.2.2.10.8.2v Virtual Address table: 1.3.6.1.4.1.3375.2.2.10.10.2v sysGeneralChassisSerialNum: 1.3.6.1.4.1.3375.2.1.3.3.3


The sensor creates the following model objects:v bigip.BigIPRealServerv bigip.BigIPRealServerGroupv bigip.BigIPVipv bigip.BigIPVipFunctionv bigip.BigIPVirtualServicev sys.UnitaryComputerSystem












BIG-IP VLAN sensorThe BIG-IP VLAN sensor discovers F5 BIG-IP virtual LANs.

The SnmpMib2Sensor invokes the BigIPVlanSensor. A VlanInterface model object iscreated for each VLAN in the VLAN map (for example, the interface throughwhich known VLANs can be addressed). This allows L2 topology views to bebuilt.


BigIPVlanSensor


The BigIPVlanSensor follows the standards documented in RFC 1212 to get theVLAN Interface. Specifically, OID .1.3.6.1.4.1.3375.1.1.10.2.1 is queried to get theVLAN interface through which the VLAN from the MIB can be discovered.

The BigIPVlanSensor runs the agent's discovery step and discovers Vlans andVlanInterfaces and throws an AgentException if the discovery fails.


The sensor creates the following model objects:v bigip.BigIPVlanv net.L2Interfacev net.VlanInterface












Bridge SNMP sensorThe Bridge SNMP sensor expands and updates the port data that is discovered bythe SNMP MIB2 sensor (which is the data that is shown in the Ports tab of theDetails pane).

The SNMP MIB2 sensor invokes the Bridge SNMP sensor. The Bridge SNMPsensor gathers the MAC address data of attached devices (specifically, the interfacenumber through which known MAC-addressed devices can be reached), which isneeded to build the Level 2 topology views.

The sensor follows the standards documented in RFC 1286 to retrieve some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1

v .1.3.6.1.2.1.17.4.3.1.2

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses, asshown in the following example. These OIDs are then queried to determine theinterface through which the MAC device can be accessed.snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1

.1.3.6.1.2.1.17.4.3.1.1SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.50.0.0 = Hex-STRING: 00 12 F2 32 00 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.51.88.0 = Hex-STRING: 00 12 F2 33 58 00SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.218.128.177 = Hex-STRING: 00 12 F2 DA 80 B1SNMPv2-SMI::mib-2.17.4.3.1.1.0.208.4.45.228.10 = Hex-STRING: 00 D0 04 2D E4 0A

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1.1.3.6.1.2.1.17.4.3.1.1.0.18.242.42.208.0

SNMPv2-SMI::mib-2.17.4.3.1.1.0.18.242.42.208.0 = Hex-STRING: 00 12 F2 2A D0 00

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.189.255.1.1.3.6.1.2.1.17.4.3.1.2.0.18.242.42.208.0

SNMPv2-SMI::mib-2.17.4.3.1.2.0.18.242.42.208.0 = INTEGER: 282

The Bridge SNMP sensor also provides specific details about the Computer SystemL2 Interfaces that are attached to the switch. The SNMP MIB2 sensor providesgeneric information about the existence of the device interfaces, and the BridgeSNMP sensor provides detailed information about the MAC addresses that areaccessible through the device interfaces.

For example, Table 17 shows the names of MAC devices that have been discoveredby the Bridge SNMP sensor. TADDM can determine the names because thecomputer system that owns that MAC device has been discovered. If the name ofthe device is unknown, the MAC address is used.

Table 17. Level 2 bridge topology data

Name Computer System L2 Interfaces

ethernet 1/9 NC84CDRS1LDPC02

ethernet 1/10 00040DFDE53



ethernet 10/2 000CDBF90C19


The sensor also follows the standards that are documented in RFC 1286 to retrievesome of the port table information. The following OIDs are queried:v .1.3.6.1.2.1.17.1.4.1.1

v .1.3.6.1.2.1.17.1.4.1.2


BridgeSnmpSensor


The sensor follows the standards documented in RFC 1286 to get some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1v .1.3.6.1.2.1.17.4.3.1.2

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. TheseOIDs are then queried to retrieve the interface through which the MAC device canbe accessed.


The sensor creates the following model objects:v net.L2Interfacev net.Segmentv sys.ComputerSystem














Fix Pack 3 com.ibm.cdb.discover.sensor.net.BridgeSnmpSensor.dot1dTpFdbStatusThis property specifies the values of the dot1dTpFdbStatus object.

By default, TADDM supports values 1, 3, and 5.

If you use network switches that support other values than the defaultones, add this property to the collation.property file with the specifiedvalues.

com.collation.discover.agent.net.BridgeSnmpAgent.filterCiscoTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the trunk ports of Cisco devices.

In TADDM 7.3.0.2 and earlier, the default value is false, which means thatMAC addresses are discovered. If you want to disable it, add this propertyto the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the CDPProtocol for the discovery switches, and you must enable the CdpSensor inthe discovery profile.

Fix Pack 3

In TADDM 7.3.0.3, and later, the default value is true. To enable

the discovery of MAC addresses on trunk ports, add this property to thecollation.properties file and set it to false.

Fix Pack 2

com.collation.discover.agent.net.BridgeSnmpAgent.filterLLDPTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the FDB switch trunk ports.

In TADDM 7.3.0.2, the default value is false, which means that MACaddresses are discovered. If you want to disable it, add this property to thecollation.properties file and set it to true.

Important: If you set this property to true, you must also enable the LLDPProtocol for the discovery switches, and you must enable the LldpSensorin the discovery profile.

Fix Pack 3



Fix Pack 2

com.collation.discover.agent.net.BridgeSnmpAgent.filterExtremeTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the trunk ports of Extreme devices.


Important: If you set this property to true, you must also enable the EDPProtocol for the discovery switches, and you must enable theExtremeVlanSensor in the discovery profile.


Fix Pack 3 In TADDM 7.3.0.3, and later, the default value is true. To enablethe discovery of MAC addresses on trunk ports, add this property to thecollation.properties file and set it to false.

Bridge SNMP 2 sensorThe Bridge SNMP 2 sensor expands and updates the port data that is discoveredby the SNMP MIB2 sensor for all virtual local area networks (VLANs).

The Bridge SNMP 2 sensor is invoked when VLANs are configured for the device.The Cisco VLAN sensor invokes the Bridge SNMP 2 sensor for each VLAN that isdiscovered. The data that is discovered is the same as for the Bridge SNMP sensor,but it is discovered for all VLANs.


BridgeSnmpSensor2


The sensor follows the standards documented in RFC 1286 to get some of theMAC Forwarding Database (fdb) table entries. The following OIDs are queried:v .1.3.6.1.2.1.17.4.3.1.1v .1.3.6.1.2.1.17.4.3.1.2.

OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs for known MAC addresses. TheseOIDs are then queried to retrieve the interface through which the MAC device canbe accessed.

















Fix Pack 3 com.ibm.cdb.discover.sensor.net.BridgeSnmpSensor.dot1dTpFdbStatusThis property specifies the values of the dot1dTpFdbStatus object.

By default, TADDM supports values 1, 3, and 5.

If you use network switches that support other values than the defaultones, add this property to the collation.property file with the specifiedvalues.

com.collation.discover.agent.net.BridgeSnmpAgent.filterCiscoTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the trunk ports of Cisco devices.

In TADDM 7.3.0.2 and earlier, the default value is false, which means thatMAC addresses are discovered. If you want to disable it, add this propertyto the collation.properties file and set it to true.

Important: If you set this property to true, you must also enable the CDPProtocol for the discovery switches, and you must enable the CdpSensor inthe discovery profile.

Fix Pack 3



Fix Pack 2

com.collation.discover.agent.net.BridgeSnmpAgent.filterLLDPTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the FDB switch trunk ports.


Important: If you set this property to true, you must also enable the LLDPProtocol for the discovery switches, and you must enable the LldpSensorin the discovery profile.

Fix Pack 3



Fix Pack 2

com.collation.discover.agent.net.BridgeSnmpAgent.filterExtremeTrunkPortThis property specifies whether the sensor ignores the discovery of MACaddresses on the trunk ports of Extreme devices.



Important: If you set this property to true, you must also enable the EDPProtocol for the discovery switches, and you must enable theExtremeVlanSensor in the discovery profile.

Fix Pack 3



Fix Pack 2

com.collation.discover.agent.BridgeSnmpAgent.MACAddressPrefixSkipListThis property skips MAC addresses from a network device. Use thisproperty to filter desktops and any other physical devices, when TADDMscans network devices.

The value of this property is a list of comma-separated MAC addressprefixes that are matched with the entries that the sensor finds in theForwarding Database table. When a MAC address and an entry from thetable match, the device is ignored.

Check Point sensorThe Check Point sensor discovers Check Point FireWall-1 running on non-Windowsplatforms, such as Solaris or Check Point IPSO.


CheckpointSensor

Prerequisites

You must have the following access:v SSH access that can run lsofv Read permission to the $CPMDIR/conf/objects.C directory on the system where

the Check Point FireWall-1 is runningv Execute permission for the $CPMDIR/bin/fw commandv Read permission to the $CPMDIR/conf/*.W files, which contain the editable

versions of the rule sets

The CPMDIR environment variable must be set for the TADDM user.


collation.properties file entries

The following properties can require elevated privilege:v com.collation.discover.agent.command.cat.SunOS=catv com.collation.discover.agent.command.cat.SunOS.1.2.3.4=sudo cat


Troubleshooting the sensorThis topic describes common problems that occur with the Check Point sensor andpresents solutions for those problems.

Unable to retrieve information from the Check Point server hostmachine

ProblemThe Check Point sensor fails during discovery.

SolutionVerify that you have the following permissions:v Read permission to the $CPMDIR/conf/objects.C directory on the system

where the Check Point FireWall-1 is runningv Execute permission for the $CPMDIR/bin/fw commandv Read permission to the $CPMDIR/conf/*.W files, which contain the

editable versions of the rule sets

Check Point SNMP sensorThe Check Point SNMP sensor discovers SNMP information that is associated withCheck Point FireWall-1 firewalls.


CheckpointSnmpSensor

Prerequisites

The system object ID (sysObjectID) must return one of the following OIDs:v OID = .1.3.6.1.4.1.1919.v OID = .1.3.6.1.4.1.2620.v OID.startsWith(.1.3.6.1.4.1.42.2.1.1.)

Limitations

The sensor collects the module, filter name, filter installation date, product name,major name, and minor name information.












Cisco Adaptive Security Appliance sensorThe Cisco Adaptive Security Appliance (ASA) sensor discovers ASA devices thatare used as IP firewall and network address translation appliances.

The Cisco ASA sensor gathers data about ASA devices. In addition, the sensordiscovers the following information:v All real servers and virtual services running. Real servers are grouped into the

real servers group.v The virtualIp, realIp, virtualPort, and realPort. The sensor also derives virtual

IPs using the virtualIp, realIp, virtualPort, and realPort. Virtual IPs are stored inthe Vip table.

Sensor name that is used in the GUI and logsv ASASensorv CiscoApplianceVersionSensor

Limitations

In TADDM Change History reports, the Cisco ASA device is displayed as a PIXdevice.


The sensor creates the following model objects:v cisco.CiscoPixComputerSystemv core.LogicalContentv net.L2Interfacev sys.OperatingSystemv vip.RealServerv vip.RealServerGroupv vip.Vipv vip.VipFunctionv vip.VirtualService



To configure the access list, complete the following steps:


1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target ASA device.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Cisco ASA sensoruses.


com.collation.asa.pager.command=terminal pager 0Add this property and value if the user specified in the access list does nothave access to the configure terminal command.

The terminal pager 0 value instructs the pager command to force the ASAdevice to return responses in one batch.

com.collation.CiscoSshTimeout=9000Increase the CiscoSshTimeout value (in milliseconds) if the target system isavailable and running, but the following error is displayed:The ssh login did not work correctly

com.collation.CiscoExpectTimeout=60000Increase the CiscoExpectTimeout value (in milliseconds) if the targetsystem is available and running, but the following error is displayed:The ssh login did not work correctly

Cisco Discovery Protocol sensorThe Cisco Discovery Protocol sensor uses the Cisco Discovery Protocol MIB todiscover Layer 2 segments on the network.

The CdpSensor discovers cdpCacheDeviceId and cdpCacheDevicePort informationand builds the local interface for the peer devices which is used to build thesegment.


CdpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v Global Device Id : 1.3.6.1.4.1.9.9.23.1.3.4.0v Cache Device Id : .1.3.6.1.4.1.9.9.23.1.2.1.1.6v Cache Device Port : .1.3.6.1.4.1.9.9.23.1.2.1.1.7













v For TADDM to run a complete discovery, SNMP and Telnet must be enabled.You must configure Telnet access with a user name and password, and you mustenable the password.

Troubleshooting the sensorThis topic describes common problems that occur with the Cisco DiscoveryProtocol sensor and presents solutions for those problems.

After TADDM completes the discovery, the sensor name appearsin the GUI, but the Config files tab does not appear as expected

ProblemTelnet access is not configured correctly.

SolutionConfigure Telnet access with a user name and password, and make surethat the password is enabled.

Cisco IOS sensorThe Cisco Internetwork Operating System (Cisco IOS) sensor discovers Cisconetwork equipment using an SSH1, SSH2, or Telnet protocol.

The Cisco IOS sensor supports two-stage authentication:v Create the appropriate session client for SSH1, SSH2, or Telnet protocol.v Log on to the host.


CiscoIOSSensor



The sensor creates the following model objects:v agent.CiscoIOSAgentConfigurationv core.LogicalContentv sys.ComputerSystem



The following sensor attributes can be modified from the discovery profile:

useSshFirstThe default value for this attribute is false. The protocols are probed inthe order: Telnet protocol, SSH2, and SSH1. If the value is true: theprotocols are probed in the order: SSH2, SSH1, and Telnet protocol.

commandsThe default values for this attribute are show running-config;showstartup-config, if no value is entered. The output for each command issaved as a configuration file. To add additional commands, type thedefault commands show running-config;show startup-config and addadditional commands to the list. Separate each command with a semicolon.Alternatively, type the commands you want to run.


To configure the access list, complete the following steps:1. Select CiscoDeviceAuth as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target computer system. Leavethe enable password blank if not required.

3. If your Cisco IOS sensor is using a Telnet protocol and does not prompt for auser name, type default in the user name field.

Cisco port sensorThe Cisco port sensor discovers Cisco switch port information.

The CiscoPortSensor discovers the interface index and duplex state for the port. Italso determines the auto negotiation status.


CiscoPortSensor


The sensor uses OID .1.3.6.1.4.1.9.9.87.1.4.1.1 for 2900 series Cisco devices.Otherwise OID .1.3.6.1.4.1.9.5.1.4.1.1 is used.














Cisco UCS SNMP sensor

Fix Pack 2

The Cisco UCS SNMP sensor discovers and collects configuration informationabout Cisco UCS device. It uses SNMP (Simple Network Management Protocol) todiscover and query Cisco UCS infrastructure components.


CiscoUCSSensor

Limitationsv The sensor does not discover certain types of data. See the following list for

details.

Note: Fix Pack 3 In TADDM 7.3.0.3, and later, these limitations do not apply.– Fabric Interconnect information is not available in the UI. You can view it

only through the CLI interface.– The relationship between Fabric Interconnect and Chassis is not created.– IO Modules are not discovered.


– Blade CPU model object and Memory Information attribute are notdiscovered.

v Sensor does not discover Cisco UCS Cluster and Cisco UCS Pool objects.

Model objects with associated attributesFix Pack 2

The Cisco UCS SNMP sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about Cisco UCSdevices.


CiscoUCSBladeServer

v AdminStatev DistinguishedNamev Modelv Presencev RelativePositionv SerialNumberv SystemBoardUUID

CiscoUCSChassis

v DistinguishedNamev HWRevisionv Modelv OperationalStatev SerialNumber

CiscoUCSFabricInterconnect

v DistinguishedNamev HWRevisionv Modelv OperationalStatev SerialNumberv Thermal

CiscoUCSServiceProfile

v AssignedStatev AssocStatev DistinguishedNamev Labelv ProfileTypev OperationalStatev OriginNode

enums.PhysTypeEnum

enums.SlotStateEnum

net.Fqdn


phys.physconn.PhysicalConnector

phys.physconn.Slot

v HWRevisionv Namev Parentv PhysicalFramev RelativePositionv SlotStatev Type

phys.physpkg.Board

v DistinguishedNamev Modelv ModuleSidev Namev OperationalStatev PhysicalPackagev Presencev RelativePositionv RunningVersionv SerialNumberv StartupVersionv Thermalv Type

phys.physpkg.Fan

v Namev HWRevisionv RelativePositionv SerialNumber

phys.physpkg.PhysicalFrame

phys.physpkg.PowerSupply

v Namev HWRevisionv RelativePositionv SerialNumber

sys.ComputerSystem

Configuring the sensorFix Pack 2

Before running a discovery, you must configure the sensor.

Configuring the access listFix Pack 2



To configure the access list, enter the following information:v For SNMP V1 and V2 discovery, enter the correct Community String into the

access list.You can do this by using the Network Template (SNMP) Component Type in theAccess List window in the Discovery Management Console.

v For SNMP V3 discovery, enter the correct user name, password, andauthentication protocol into the access list, according to the SNMP V3 credentialmapping information in the following table.

Table 18. SNMP V3 credential mapping.


Authentication type (for example MD5) Authentication Protocol



You can do this by using the Network Template (SNMPV3) Component Type inthe Access List window in the Discovery Management Console.

Configuring the discovery profileFix Pack 2

This topic describes how to configure the discovery profile.

You can configure the discovery profile of CiscoUCSSensor in the DiscoveryManagement Console by setting the following attributes:

snmpPortThe port number that is used for SNMP communication. The default valueis 161.

snmpTimeoutThe timeout that is used for a single SNMP query. The default value is20000 (seconds).

locale The locale that is used for SNMP queries.

characterEncodingThe character encoding that is used for SNMP queries.

When the CiscoUCSSensor is enabled, you must also enable the SnmpLightSensoror SnmpMIB2Sensor for the CiscoUCSSensor to function correctly.

For more information about discovery profiles, see the Creating discovery profilestopic in the TADDM User's Guide.

Troubleshooting the sensorFix Pack 2

This topic describes common problems that occur with the Cisco UCS SNMPsensor and presents solutions for those problems.


An SNMP timeout error occurs

ProblemThe sensor generates an SNMP timeout error during discovery.

SolutionIncrease the snmpTimeout parameter for the CiscoUCSSensor by using theDiscovery Management Console.

Cisco VLAN sensorThe Cisco VLAN sensor uses the Cisco VLAN Membership MIB to discover VLANcontents.

The SnmpMib2Sensor invokes CiscoVlanSensor when VLANs are configured forCisco devices. The CiscoVlanSensor then invokes BridgeSnmpSensor2 for eachVLAN discovered. The sensor discovers the VLAN membership table, createsL2Interfaces, and attaches them to the VLAN bridge.


CiscoVlanSensor


The sensor follows the standards documented in RFC 1286 to get the VLANinterface. The high level OIDs queried are:v OID .1.3.6.1.4.1.9.9.68.1.2.2.1.2 to get the VLAN membership tablev OID .1.3.6.1.4.1.9.9.46.1.2.1.1 to get the management domain tablev OID .1.3.6.1.4.1.9.9.46.1.3.1.1 to get the vtp VLAN tablev OID .1.3.6.1.4.1.9.9.46.1.6.1.1 to get the VLAN trunk port information.


The sensor creates the following model objects:v net.L2Interfacev net.Vlanv net.VlanInterfacev sys.UnitaryComputerSystem












CiscoWorks sensorThe CiscoWorks sensor collects data from CiscoWorks servers.

The sensor works by invoking the RME servlet.


CiscoWorksSensor, CiscoWorks405FileSensor, CiscoWorks405FileUDS,CiscoWorks405UDS, CiscoWorksFileSensor, CiscoWorksFileUDS, andCiscoWorksUDS

Limitations

CiscoWorks sensor does not discover CiscoWorks LMS or Cisco Prime LMS, whenthe secure (HTTPS) mode is enabled for CiscoWorks server or Cisco Prime server.

Commands that the sensor runs

The sensor sends the HTTP POST request method to the following URL:http://<Cisco Works IP>:1741/rme/cwcli

The payload contains the cwcli export inventory command.

Model objects with associated attributesThe CiscoWorks sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects aboutconfiguration items from CiscoWorks servers.


net.IpAdress

v DotNotation

net.IpInterface

v IpAddressv L2Interface

net.L2Interface

v Descriptionv Encapsulationv HwAddressv Name


net.Router

v Forwardingv Name

sys.OperatingSystem

v Descriptionv Namev OSNamev OSVersion

sys.UnitaryComputerSystem

v Functionsv Manufacturerv Modelv Namev OSRunningv SerialNumberv Type


To configure the access list, complete the following steps:1. Use CiscoWorks as the Component Type.2. Specify the following required information:


Troubleshooting the sensorFind out what common problems might occur with the CiscoWorks sensor andhow to solve them.

Invalid XML format

ProblemWhen trying to create model objects, the following error occurs:CTJTD0652E The following transformation did not complete successfully:CTJTP2203E The server cannot create model objects: [PLATFORM.XML.E.1]The application is unable to parse the xml input.. .

SolutionThe cause of this problem is the opening quotation mark (") found in theCiscoWorks configuration. This character is unsupported. To solve theproblem, remove the opening quotation mark from the configuration.

Entity MIB sensorThe Entity MIB sensor can discover only known devices. It follows the standardsthat are documented in RFC 2737 to retrieve some of the physical configurationinformation for the device.


The Entity MIB sensor gathers the data that is shown in the PhysicalPackage tab ofthe Details pane. This data is used to store information about physical parts of thedevice such as slot, fan, physical frame, sensors, physical connectors, chassis, rack,and power supply.

The sensor queries the following OIDs:.1.3.6.1.2.1.47.1.1.1.1.2, .1.3.6.1.2.1.47.1.1.1.1.3, .1.3.6.1.2.1.47.1.1.1.1.4,.1.3.6.1.2.1.47.1.1.1.1.5, .1.3.6.1.2.1.47.1.1.1.1.6, .1.3.6.1.2.1.47.1.1.1.1.7,.1.3.6.1.2.1.47.1.1.1.1.8, .1.3.6.1.2.1.47.1.1.1.1.9, .1.3.6.1.2.1.47.1.1.1.1.10,.1.3.6.1.2.1.47.1.1.1.1.11, .1.3.6.1.2.1.47.1.1.1.1.12, .1.3.6.1.2.1.47.1.1.1.1.13.

The sensor also gathers .1.3.6.1.2.1.55.1.1.0., which contains IPv6 informationaccording to RFC 2466. OID .1.3.6.1.2.1.17.4.3.1.1 returns a list of OIDs forknown MAC addresses. These OIDs are then queried to determine the interfacethrough which the MAC device can be accessed.

If the SNMP MIB2 sensor also runs, additional information is gathered and shownin the Router Details, Bridge Details, IP, and Ports tabs.


EntityMIBSensor


The sensor uses the following OIDs:v .1.3.6.1.2.1.47.1.1.1.1.2v .1.3.6.1.2.1.47.1.1.1.1.3v .1.3.6.1.2.1.47.1.1.1.1.4v .1.3.6.1.2.1.47.1.1.1.1.5v .1.3.6.1.2.1.47.1.1.1.1.6v .1.3.6.1.2.1.47.1.1.1.1.7v .1.3.6.1.2.1.47.1.1.1.1.8v .1.3.6.1.2.1.47.1.1.1.1.9v .1.3.6.1.2.1.47.1.1.1.1.10v .1.3.6.1.2.1.47.1.1.1.1.11v .1.3.6.1.2.1.47.1.1.1.1.12v .1.3.6.1.2.1.47.1.1.1.1.13

The sensor queries OID .1.3.6.1.2.1.55.1.1.0. which contains the IPV6 informationper RFC 2466. The sensor also queries OID .3.6.1.2.1.17.4.3.1.1. which returns a listcontaining OIDs for known MAC addresses. These OIDs are then queried to getthe interface through which the MAC device can be accessed.


The sensor creates the following model objects:v phys.physconn.Slotv physconn.PhysicalConnectorv physpkg.Chassisv physpkg.Fanv physpkg.PhysicalFrame


v physpkg.PhysicalPackagev physpkg.otherPhysicalPackagev physpkg.PowerSupplyv physpkg.Sensorv sys.ComputerSystem











Extreme VLAN sensorThe Extreme VLAN sensor extracts VLAN information from Extreme Networksswitches.

The SnmpMib2Sensor invokes the ExtremeVlanSensor when VLANs are configuredfor the device.


ExtremeVlanSensor


The sensor uses the following OIDs:v OID .1.3.6.1.4.1.1916.1.2.1.2.1 is used to query the extremeVlanInterface

Information.v OID .1.3.6.1.4.1.1916.1.2.3.1.1 is used to query the Encapsulation (Trunk) Interface

information.v OID .1.3.6.1.2.1.31.1.2.1 is used to query the Interface Stack information.














IBM BladeCenter SNMP sensorThe IBM BladeCenter SNMP sensor discovers and collects configurationinformation about IBM BladeCenter chassis. In TADDM 7.3.0.3, and later, it alsodiscovers and collects configuration information about IBM PureFlex Systemchassis.

The sensor uses SNMP (Simple Network Management Protocol) to discover andquery BladeCenter infrastructure components. The Management Module (MM) andthe Advanced Management Module (AMM) are the central points of managementfor the IBM BladeCenter chassis.

Fix Pack 3

The Chassis Management Module (CMM) is the central point of

management for the PureFlex® chassis.



Limitations

The following limitations apply to discovery of both IBM BladeCenter chassis andIBM PureFlex System chassis:


v The sensor cannot discover chassis if the any of the Management Modules is notresponsive.

v The sensor cannot discover BladeCenters that have two configured networkinterfaces (eth0 and eth1).

v You cannot start the first BladeCenter discovery against an empty database.Computer system sensors that discover operating systems that run on blades(such as Linux and Windows) must be run first. This limitation applies only tothe first BladeCenter discovery.

v The sensor might not obtain sufficient Vital Product Data (VPD) againstRedundant Management Modules to create certain model objects. Instances ofthe ComputerSystem and BladeCenterManagementModule classes that representRedundant Management Modules, for example, might not be created. In thiscase, instances of the Board class represent the module.

v After you discover one or more BladeCenters by using the BladeCenter sensor,the components BladeCenter and BladeCenter Management Module are notpresent in the list of component types available for use with custom queries.Therefore, you cannot run a custom query for these types of components. Thisissue applies only to the TADDM Data Management Portal and not to theDiscovery Management Console.

v The BladeCenter does not have L2 interfaces but has Management Modules thathave L2 interfaces. To view the L2 interfaces of the Management Modulescontained in the BladeCenter, complete the following steps:1. In the Details pane, click the Chassis tab to open the Chassis notebook.2. Click the MMs tab to open the Management Module notebook.3. In the Computer System column, click BladeCenter Management Module.4. Click the IP tab to view the L2 interface details.

Fix Pack 3

The following limitations apply to discovery of IBM PureFlex System

chassis only:v When IBM PureFlex System chassis contains IBM Storwize® v7000 storage, the

sensor discovers placeholders for the storage enclosures. To fully discoverinformation about this storage, you must also run the SVC Storage sensor. Thedata that is discovered by the SVC Storage sensor is reconciled with theseplaceholders.

v When you discover IBM PureFlex System chassis, the sys.blade.Alert modelobject is not created.


The sensor creates the following model objects:v core.LogicalContentv enums.AlertLevelEnumv enums.PhysTypeEnumv enums.SlotStateEnumv IpAddress netv L2Interfacev net.BindAddressv net.Fqdn netv phys.physconn.PhysicalConnectorv phys.physconn.Slot


v phys.physpkg.Boardv phys.physpkg.Chassisv phys.physpkg.Fanv phys.physpkg.PhysicalFramev phys.physpkg.PowerSupplyv sys.blade.Alertv sys.blade.BladeCenterManagementModulev sys.blade.LoginProfilev sys.ComputerSystemv sysControlSoftwarev sys.DNSServicev sys.LDAPServicev sys.ServiceAccessPointv sys.SMTPService



You can configure the BladeCenterSnmpSensor using the Discovery ManagementConsole by setting the following attributes:

snmpPortThe port number used for SNMP communication. The default value is 161.

snmpTimeoutThe timeout used for a single SNMP query. The default value is 20000.

locale The locale used for SNMP queries.

characterEncodingThe character encoding used for SNMP queries.

scanL2InterfacesGet L2 interfaces for the chassis, when enabled.

For more information, see the Creating discovery profiles topic in the TADDM User'sGuide.

When the BladeCenterSnmpSensor is enabled, you must also enable theSnmpLightSensor or SnmpMIB2Sensor for the BladeCenterSnmpSensor to functioncorrectly.




v For SNMP V3 discovery, complete the following steps:


1. Select Network Element (SNMPV3) as the Component Type.2. Specify the correct user name, password, and authentication protocol,







Troubleshooting the sensorThis topic describes common problems that occur with the IBM BladeCenter SNMPsensor and presents solutions for those problems.

An SNMP time out error occurs

ProblemThe sensor generates an SNMP time out error during discovery.

SolutionIncrease the snmpTimeout parameter for the BladeCenterSnmpSensor usingthe Discovery Management Console.

LAN Manager SNMP sensorThe LAN Manager SNMP sensor discovers LAN Manager and retrievesinformation contained in LAN Manager SNMP MIBs.


LanManagerSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.77.1.1.1.0v .1.3.6.1.4.1.77.1.1.2.0v .1.3.6.1.4.1.77.1.2.3.1.1v .1.3.6.1.4.1.77.1.2.3.1.2v .1.3.6.1.4.1.77.1.2.3.1.3v .1.3.6.1.4.1.77.1.2.3.1.4v .1.3.6.1.4.1.77.1.2.3.1.5


The sensor creates the following model objects:v sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystemv sys.windows.WindowsService












LDAP sensorThe LDAP sensor discovers LDAP servers.

The LDAP sensor always discovers one LDAP instance per host.


LdapSensor


The sensor creates the model object sys.LDAPSAP.

To discover all attributes, the user specified in the access list must have an accessto the cn=monitor subtree on the LDAP server and the cn=monitor subtree mustexist.

Configuring the sensorBefore you run a discovery, you must configure the LDAP sensor.

Setting sensor configuration parametersYou can configure the behavior of the LDAP sensor by setting the configurationparameters.

To modify the sensor configuration, you can configure the following parameters:

tryInsecureConnectionSpecifies whether to use insecure connection. The default value of thisproperty is true.


If this parameter is set to true, in case when the sensor connects by usingthe LDAPS or StartTLS protocols and fails, the sensor tries to connect toLDAP by using a plain protocol. If this property is set to false, the sensortries to connect by using the LDAPS or StartTLS protocols only.

To learn where to configure LDAP ports, see “Configuring thecollation.properties file entries.”

bypassHostVerificationSpecifies whether to bypass the host verification procedure. The defaultvalue of this property is true.

If this property is set to true and LDAP is discovered by using theStartTLS protocol, the TLS negotiation step bypasses the host verificationprocedure. The sensor accepts the certificates that are signed for a differenthost name or IP address of the target server that was provided in the scopeused for the discovery. If this property is set to false, the sensor tries torun the TLS negotiation step by using IP address of the target host.

Configuring the access listDepending on your configuration, you must provide required access details.

To configure the access list, complete the following steps:1. Use LDAP Service as the Component Type.2. Specify the access information (a user name and password) that TADDM uses

to authenticate with the LDAP server.3. Optionally, in case of LDAP secured by the LDAPS or StartTLS protocols,

provide the SSL settings, that is truststore certificate and its password.

Using SSLThe LDAP sensor uses the first access entry to connect to the LDAPservice. To enforce using SSL, either put the SSL access entry for LDAPbefore entries with plain credentials or set the tryInsecureConnectionproperty to false.

The installation could fail if SSL is enforced. By default http is used (httpis hardcoded in DownloadFilesDeomPrimaryServerAction).

Trust store files limitationDue to a limitation in Java, TADDM can handle only one truststore file fora single discovery of LDAP service. The certificates that are stored in thetruststore file are loaded when the connection with LDAP service isestablished. Only those certificates can be used by TADDM during theentire discovery, so if certificates from several truststore files are required,do not attach them separately into the access list. You must export theoriginal truststore files to a single file. When all necessary entries for eachLDAP server are in the TADDM access list, the first one must have theexported truststore file attached. There is always one entry for eachdifferent login and password combination for the discovered LDAPservers.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the LDAP sensor uses.

The LDAP sensor uses the following sensor settings:

com.collation.ldapsensor.ports.ldaps=636Specifies a comma separated list of ports, on which LDAP is running byusing the LDAPS protocol.


com.collation.ldapsensor.ports.starttls=389Specifies a comma separated list of ports, on which LDAP is running byusing the StartTLS protocol.

Note:

v If the tryInsecureConnection property is set to true in the sensor configuration,sensor tries to connect to the preceding ports also by using a plain LDAPprotocol, starting with StartTLS ports.

v The values of both properties are also used by PortSensor to determine whichports are open.

v Both values can be also set in the Platform Properties tab in profiles.v These properties are scoped properties and can be set for a specific IP of target

machines, for examplecom.collation.ldapsensor.ports.ldaps.192.168.5.4=755,234,524.

Troubleshooting the sensorThis topic describes common problems that occur with the LDAP sensor andpresents solutions for those problems.

Error occurs during a discovery

ProblemThe sensor discovery finishes with the following error message:CTJTD0421E The LDAP server contains the following unexpected attributes:javax.naming.AuthenticationNotSupportedException: [LDAP: error code 13 - confidentiality required]

SolutionThe LADP server requires encryption. The LADP sensor cannot carry out adiscovery if the LADP server requires encryption, disable the encryptionon the LADP server.

Sensor cannot display all attribute information

ProblemThe following attribute information is not displayed after running adiscovery: LDAP Version, Threads, and Total Connections.

SolutionEnable the LDAP application monitor to discover LDAP Version, Threads,and Total Connections.

Duplicates of LDAPService instances

ProblemWhen the LDAP server listening port changes between two discoveries,duplicates of LDAPService instances might occur after each discovery.

SolutionAdd target server's session credentials to the access list. Check whether theComputerSystem sensors, such as LinuxComputerSystemSensor, areenabled in the discovery profile. After LDAPServiceAgent run,LDAPService instances are merged, if discovered on the same host.


Link Layer Discovery Protocol sensorThe Link Layer Discovery Protocol sensor uses the LLDP MIB to discover Layer 2segments on the network. The LldpSensor discovers lldpLocalSystemData ,lldpLocPortTable and lldpRemTable information and builds the local interface forthe peer devices. This interface is used to build the segment.



LldpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v lldpLocChassisIdSubtype : .1.0.8802.1.1.2.1.3.1v lldpLocChassisId : .1.0.8802.1.1.2.1.3.2v lldpLocSysName : .1.0.8802.1.1.2.1.3.3v lldpLocPortNum: .1.0.8802.1.1.2.1.3.7.1.1v lldpLocPortIdSubtype: .1.0.8802.1.1.2.1.3.7.1.2v lldpLocPortId: .1.0.8802.1.1.2.1.3.7.1.3v lldpLocPortDesc: .1.0.8802.1.1.2.1.3.7.1.4v lldpRemTableIdx: .1.0.8802.1.1.2.1.4.1.1.1v lldpRemChassisIdSubtype: .1.0.8802.1.1.2.1.4.1.1.4v lldpRemChassisId: .1.0.8802.1.1.2.1.4.1.1.5v lldpRemPortIdSubtype: .1.0.8802.1.1.2.1.4.1.1.6v lldpRemPortId: .1.0.8802.1.1.2.1.4.1.1.7v lldpRemPortDesc: .1.0.8802.1.1.2.1.4.1.1.8



NetScreen SNMP sensorThe NetScreen SNMP sensor discovers the NAT configuration from JuniperNetworks NetScreen devices and retrieves service values such as ServiceIndex,serviceName, and ServiceTransProto from NetScreen and looks up thevirtualservice.

The NetScreenSNMPSensor uses the Netscreen SNMP MIBs.


NetscreenSnmpSensor



The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.3224.11.1.1.1v .1.3.6.1.4.1.3224.11.1.1.2v .1.3.6.1.4.1.3224.11.1.1.3v .1.3.6.1.4.1.3224.11.1.1.4v .1.3.6.1.4.1.3224.11.1.1.5v .1.3.6.1.4.1.3224.11.1.1.6v .1.3.6.1.4.1.3224.13.1.1.1v .1.3.6.1.4.1.3224.13.1.1.2v .1.3.6.1.4.1.3224.13.1.1.4v .1.3.6.1.4.1.3224.13.1.1.5v .1.3.6.1.4.1.3224.13.1.1.6v .1.3.6.1.4.1.3224.13.1.1.7v .1.3.6.1.4.1.3224.13.1.1.8v .1.3.6.1.4.1.3224.11.3.1.1.1v .1.3.6.1.4.1.3224.11.3.1.1.2v .1.3.6.1.4.1.3224.11.3.1.1.3v .1.3.6.1.4.1.3224.11.3.1.1.4v .1.3.6.1.4.1.3224.11.3.1.1.5v .1.3.6.1.4.1.3224.11.3.1.1.6v .1.3.6.1.4.1.3224.11.3.2.1.1v .1.3.6.1.4.1.3224.11.3.2.1.2v .1.3.6.1.4.1.3224.11.3.2.1.3v .1.3.6.1.4.1.3224.11.3.2.1.5v .1.3.6.1.4.1.3224.11.3.2.1.6


The sensor creates the following model objects:v net.vip.RealServerv net.vip.RealServerGroupv net.vip.Vipv net.vip.VipFunctionv net.vip.VirtualServicev sys.ComputerSystem




v For SNMP V3 discovery, complete the following steps:


1. Select Network Element (SNMPV3) as the Component Type.2. Specify the correct user name, password, and authentication protocol,







Nokia SNMP sensorThe Nokia SNMP sensor discovers information contained in Nokia SNMP MIBs.

The NokiaSNMPSensor discovers Access Control List (ACL) configurations (ACLrules) and mapped interfaces for Nokia SNMP devices based on the FQDN,signature, and Object_ID.


NokiaSnmpSensor


The sensor uses the following high-level OIDs to retrieve the attributes:v .1.3.6.1.4.1.94.1.16.4.1.1.1.1v .1.3.6.1.4.1.94.1.16.4.1.1.1.2v .1.3.6.1.4.1.94.1.16.4.1.1.1.3v .1.3.6.1.4.1.94.1.16.4.1.1.1.4v .1.3.6.1.4.1.94.1.16.4.1.1.1.5v .1.3.6.1.4.1.94.1.16.4.2.1.1.1v .1.3.6.1.4.1.94.1.16.4.2.1.1.2v .1.3.6.1.4.1.94.1.16.4.2.1.1.3v .1.3.6.1.4.1.94.1.16.4.2.1.1.4v .1.3.6.1.4.1.94.1.16.4.2.1.1.5v .1.3.6.1.4.1.94.1.16.4.2.1.1.6v .1.3.6.1.4.1.94.1.16.4.2.1.1.7v .1.3.6.1.4.1.94.1.16.4.2.1.1.8v .1.3.6.1.4.1.94.1.16.4.2.1.1.9v .1.3.6.1.4.1.94.1.16.4.2.1.1.10v .1.3.6.1.4.1.94.1.16.4.2.1.1.11v .1.3.6.1.4.1.94.1.16.4.2.1.1.12v .1.3.6.1.4.1.94.1.16.4.2.1.1.13v .1.3.6.1.4.1.94.1.16.4.2.1.1.14v .1.3.6.1.4.1.94.1.16.4.2.1.1.15v .1.3.6.1.4.1.94.1.16.4.2.1.1.16



The sensor creates the following model objects:v net.acl.Aclv net.acl.AclFunctionv net.acl.Rulev net.L2Interfacev sys.ComputerSystem











PIX sensorThe PIX sensor discovers Cisco PIX devices that are used as IP firewall andnetwork address translation appliances.

The PIX sensor gathers data about the CiscoPIX operating system running on PIXdevices. In addition the sensor does the following:v Discovers all real servers and virtual services running. Real servers are grouped

into the real servers group.v Discovers the virtualIp, realIp, virtualPort, and realPort, and derives virtual IPs

using them. Virtual IPs are stored in the Vip table.

Sensor name that is used in the GUI and logsv CiscoApplianceVersionSensorv PixSensor

Prerequisite

For configurations that have multiple context configurations, specify in thediscovery scope the IP address of the “admin context.”


Limitations

When topologies are displayed, the following limitations apply:v For context configurations, the virtual and admin contexts are represented by the

same icon.v In the physical infrastructure topology view, the connection between the “admin

context” and the “virtual context” is not displayed. This connection is displayedin the contextual topology view.


The sensor creates the following model objects:v cisco.CiscoPixComputerSystemv core.LogicalContentv net.L2Interfacev sys.OperatingSystemv vip.RealServerv vip.RealServerGroupv vip.Vipv vip.VipFunctionv vip.VirtualService


To configure the access list, complete the following steps:1. Select Cisco Device as the Component Type.2. Specify the access information (user name, password, and enable password)

that TADDM must use for authentication to the target PIX device.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the PIX sensor uses.

com.collation.pix.pager.commandThis value specifies to use the pager command to force the PIX to returnthe entire response at once, rather than one screen at a time. Add thisentry, if it is not possible to run the configure terminal command.

SNMP Light sensorThe SNMP Light sensor supports Level 1 discovery of SNMP network devices.


The SNMP Light sensor gathers the data that is shown in the following tabs of theDetails pane:v Generalv SNMP Info


The SNMP Light sensor and the SNMP MIB2 sensor gather generic informationfrom the following object identifiers (OIDs):snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9

.1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11,

RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "Y1UN9;4b/1tz9l#"10.199.250.9 .1.3.6.1.2.1.1.2.0

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.400


SNMPv2-MIB::sysContact.0 = STRING: Network Support - CH

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.5.0

SNMPv2-MIB::sysName.0 = STRING: NC89ZNC01TSL302

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A “" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01


SnmpLightSensor


The sensor creates the following model objects:v sys.UnitaryComputerSystemv sys.OperatingSystemv sys.SnmpSystemGroup












SNMP MIB2 sensorThe SNMP MIB2 sensor supports Level 2 discovery of SNMP network devices.


The SNMP MIB2 sensor discovers basic SNMP information about the device andother information such as router details, bridge details, IP data (both IPv4 andIPv6), and port data. The SNMP MIB2 sensor calls the Entity MIB sensor and theBridge SNMP sensor if they are enabled in the discovery profile.

Other sensors are called as the SNMP MIB2 sensor detects the devices thatTADDM supports (for example, the Cisco port sensor and the Cisco VLAN sensorare called if a Cisco device is detected).

The SNMP MIB2 sensor gathers the data that is shown in the following tabs of theDetails pane:v Generalv SNMP Infov IPv6 Router Detailsv IPv4 Router Detailsv IPv Interfaces

The SNMP Light sensor and the SNMP MIB2 sensor gather generic informationfrom the following object identifiers (OIDs):snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9

.1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System SoftwareIOS (tm) s72033_rp Software (s72033_rp-JK9SV-M), Version 12.2(17d)SXB11,

RELEASE SOFTWARE (fc1)Technical Support: http://www.cisco.com/techsupportCopyright (c) 1986-2005 by cisco Systems, Inc.Compiled T


SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.400


SNMPv2-MIB::sysContact.0 = STRING: Network Support - CH

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A "" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.5.0

SNMPv2-MIB::sysName.0 = STRING: NC89ZNC01TSL302

snmpwalk -v 3 -u cmdbadmin -l authPriv -a MD5 -A “" -x DES -X "" 10.199.250.9.1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: NC89ACB01


The SNMP MIB2 sensor discovers IPv4 and IPv6 information. Using the IP-MIBand IP-FORWARD-MIB modules (updated in RFC 4293 and RFC 4292), the sensorcollects IP interface, forwarding, and routing information. The following OIDs arequeried:1.3.6.1.2.1.4.34 IP-MIB (ipAddressTable)1.3.6.1.2.1.4.32 IP-MIB (ipAddressPrefixTable)1.3.6.1.2.1.4.25 IP-MIB (ipv6IpForwarding)1.3.6.1.2.1.4.1 IP-MIB (ipForwarding)1.3.6.1.2.1.4.24.7 IP-FORWARD-MIB (inetCidrRouteTable)

ipAddressTableThis table lists the IPv4 and IPv6 addresses.

ipAddressPrefixTableThis table lists the prefix information for all addresses.

ipv6IpForwardingThis flag indicates whether the target device is acting as a router toforward IPv6 packets.

ipForwardingThis flag indicates whether the target device is acting as a router toforward IPv4 packets.

inetCidrRouteTableThis IP routing table lists the routes for both IPv4 and IPv6 interfaces.

If the target device supports the necessary versions of the IP-MIB andIP-FORWARD-MIB modules, the SNMP MIB2 sensor collects all the requiredinformation, and discovery completes. If the target device does not support thenecessary versions of these modules, the older versions (RFC 2011 and RFC 1213),which gather only IPv4 information, are used, and the following OIDs are queried:1.3.6.1.2.1.4.20 IP-MIB (ipAddrTable)1.3.6.1.2.1.4.1 IP-MIB (ipForwarding)1.3.6.1.2.1.4.21 RFC1213-MIB (ipRouteTable)

In addition, if the target device is a Cisco device, the CISCO-IETF-IP-MIB andCISCO-IETF-IP-FORWARDING-MIB modules are used to gather just the IPv6information, and the following OIDs are queried:1.3.6.1.4.1.9.10.86.1.1.2 CISCO-IETF-IP-MIB (cIpAddressTable)1.3.6.1.4.1.9.10.86.1.1.1 CISCO-IETF-IP-MIB (cIpAddressPfxTable)1.3.6.1.4.1.9.10.86.1.2.1 CISCO-IETF-IP-MIB (cIpv6Forwarding)1.3.5.1.4.9.10.85.7 CISCO-IETF-IP-FORWARD-MIB (cInetCidrRouteTable)


SnmpMib2Sensor

Limitations

TADDM currently supports a limited number of network devices. In addition,TADDM L2 switches are switches and L3 switches are routers. So, L3 switches aredisplayed as a Router in the Physical Infrastructure tree and in the Topology.

All computer system sensors and the SNMP MIB2 sensor ignore network interfacesthat are configured to be down. TADDM does not populate the net.IpNetworkattribute on the following types of IP interfaces:v loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1v link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1


v multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1v unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0

Therefore, IP networks are not populated in the TADDM user interface.


The sensor creates the following model objects:v net.Bridgev net.IpInterfacev net.IpRoutev net.IpV4Addressv net.IpV6Addressv net.IpV4Routerv net.IpV6Routerv net.L2Interfacev sys.UnitaryComputerSystemv sys.OperatingSystemv sys.SnmpSystemGroup












Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the SNMP MIB2 sensoruses.


com.collation.discover.agent.net.SnmpMib2Agent.useEntitySerialWhen you set this property to true, it allows TADDM to collect the SerialNumber from EntityMIB.

TADDM does not support the allowed Cisco configuration for the chassisId1.3.6.1.4.1.9.3.6.3. As a result, an invalid information is set to theSerialNumber attribute for the Network Devices. To avoid this problem,add thecom.collation.discover.agent.net.SnmpMib2Agent.useEntitySerial=trueproperty to the collation.properties file.

com.ibm.cdb.discover.sensor.net.snmpmib2.SnmpMib2Sensor.ifTypeThis property is used to create relationships to network devices that usevirtual interfaces and are discovered by the SNMP MIB2 sensor. By default,the sensor does not store virtual interfaces for processing. If you want therelationships to virtual interfaces to be displayed in TADDM, add thisproperty to the collation.properties file.

The value of this property is the type of the interface of the virtualinterface, which is specified by the ifType attribute. For example, if aninterface has the attribute ifType=135, you must add the followingproperty:com.ibm.cdb.discover.sensor.net.snmpmib2.SnmpMib2Sensor.ifType=135

You can specify a comma-separated list of the types of the interface as thevalue of this property.

As a result, the ifType attribute value is treated as a physical port, and therelationship is created.

The default value is 6, 62, 69, 117.

Troubleshooting the sensorThis topic describes common problems that occur with the SNMP MIB2 sensor andpresents solutions for those problems.

The SNMP MIB2 sensor is not started, when the session sensortimes out

ProblemWhen the session sensor fails because of a timeout, the SNMP MIB2 sensoris not started.

Fix Pack 4 SolutionIf the session sensor times out, the SNMP MIB2 sensor is not started bydefault. If you want to change this behavior, set thecom.collation.discover.agent.sys.SessionSensor.timeout.snmp propertyto true in the collation.properties file. For details, see “Configuring thecollation.properties file entries” on page 275.

The sensor incorrectly identifies L3 switches as routers

ProblemFor SNMP devices that TADDM does not already know about, TADDMoccasionally misidentifies L3 switches as routers.

SolutionUse the SNMP templates to provide TADDM with hints to correctly


identify the switches and routers. For information about how to use SNMPtemplates to assist TADDM with correct switch, router categorization, seethe TADDM User's Guide.

The sensor fails doing an OS discovery

ProblemThe sensor fails doing an OS discovery.

SolutionVerify the credentials provided in the access list and check to ensure thatSNMP is running on the TADDM client.

DataPower device discovered with SnmpMib2Sensor does notmerge with data discovered by other sensors

ProblemDataPower device that is discovered with SnmpMib2Sensor does notmerge with the data that is discovered by other sensors.

SolutionWhen DataPower device is configured to use the SNMP protocol, it can bediscovered by using SnmpMib2Sensor. However, DataPower uses a customset of SNMP OIDs that SnmpMib2Sensor does not query. These OIDs areread only by the CustomMib2ComputerSystem sensor with the use ofJython extension script.

For more information, see step 6 in the Adding a computer system templatefor a network device topic in the TADDM User's Guide.

To secure proper reconciliation with data stored by DataPower, VMWareand ZEnterprise sensors in Discovery Management Console, check thefollowing prerequisites:v Make sure that DataPowerComputerSystem template is enabled in

Computer Systems templates (which is the default setting).v Make sure that CustomMib2ComputerSystem sensor is enabled in the

discovery profile that is used to discover DataPower devices.v Make sure that the following files are in the TADDM installation:

– etc/templates/commands/DataPowerComputerSystem

– etc/templates/commands/extension-scripts/DataPowerComputerSystem.py


Chapter 38. Operating system sensors

Operating system sensors discover the operating systems that are running in theenvironment.

Citrix XenServer sensorThe Citrix XenServer sensor discovers Citrix XenServers. It is script based sensor.


The Citrix XenServer sensor is a script-based sensor. It starts afterGenericServerSensor. The sensor discovers a host with the list of virtual machines.Domain 0 is discovered as a virtual machine and it contains the serial number andUUID that is inherited from servers hardware. Other virtual machines have serialnumber and UUID generated by Xen hypervisor.

XenServerSensor


The Citrix XenServer sensor discovers server pools, hosts in a pool, and virtualmachines (VM) located on all hosts in a pool.v The sensor discovers the following elements for pools:

– list of hosts– name

v The sensor discovers the following elements for hosts:– list of VMs including Domain 0– memory information– CPU information– name– description– running state– UUID

v The sensor discovers the following elements for virtual machines:– name– memory information– number of CPUs– power state– PV/HVM– networking information– boot type

Prerequisites

The following prerequisites are required:v lsof must be installed in Domain 0


v xapi must be running in Domain 0v For Linux-based VM, guest tools must be running in Paravirtualized DomainU

to discover such virtual machine.v For Windows-based VM, guest tools must be running in Hardware Virtual

Machine to discover network and OS information.


The sensor creates the following model objects:v simple.SLogicalGroupv sys.ComputerSystemv sys.linux.Linuxv sys.linux.LinuxUnitaryComputerSystemv sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystem

Troubleshooting the sensorThis topic describes common problems that occur with the Citrix XenServer sensorand presents solutions for those problems.

Windows virtual machine is discovered as Other Computersystem with no OS information

ProblemWindows virtual machine is discovered as Other Computer system and noOS information is provided.

SolutionCheck whether the guest tools are running in the virtual machine. Thetools are required for discovery.

Linux virtual machine is not discovered.

ProblemLinux virtual machine is not discovered and a warning is displayed.

SolutionCheck whether the guest tools are running in the virtual machine. Thetools are required for discovery.

DataPower sensorThe DataPower sensor discovers IBM WebSphere DataPower SOA Appliances,which support SOAP Configuration Management interface.

Fix Pack 3

In TADDM 7.3.0.3, and later, the sensor discovers DataPower domains and thefollowing types of proxies:v SSL Proxyv TCP Proxyv XSL Proxyv WS Proxyv Multi-Protocol Gateway (MPG)v XML Firewall


v HTTP Service

The discovered data is stored as extended instances. For each new discoveredcategory, a separate tab is created in Data Management Portal, for example theDomains, or SSL Proxy tabs. The data is displayed in the XML format.


DataPowerSensor

Prerequisites

The discovered DataPower appliances must have SOAP ConfigurationManagement service enabled.


The sensor creates the following model objects:v sys.appliance.DataPowerv net.L2Interfacev net.IpInterface


Configuring port numbersYou must set a port number of the DataPower SOAP Configuration Managementinterface in the port sensor configuration.

Procedure1. Create a discovery profile.2. Select PortSensor from the sensor list and click New.3. In the dataPowerXmlManagementPorts field, enter a comma-separated list of

port numbers, which are to be treated as DataPower SOAP ConfigurationManagement interface ports. Specify other required information, enable theconfiguration, and save it.

4. Add DataPowerSensor to your discovery profile and save it.

Results

When you run a discovery by using the profile that you created, the DataPowersensor is started for each server, which listens on any of the ports that areprovided in the dataPowerXmlManagementPorts list.

Configuring the access list and certificatesThe DataPower sensor requires the appropriate entry of the "DataPower"component type in the access list. The user name and password must be the sameas when logging to your DataPower appliance with WebGUI or SSH.

Chapter 38. Operating system sensors 347

Certificate setup

The DataPower sensor uses HTTPS protocol and requires a truststore file with yourappliance certificate, which must be attached to the access list entry. Each accesslist entry uses its own truststore file and is independent of other entries from theaccess list.

You can use the iKeyman utility (ikeyman.exe on Windows) to create a truststorefile. The utility is included in the TADDM installation. Certificates from yourDataPower appliance or appliances must be added to your truststore file as signercertificates.

Ignoring certificates validation:

If your environment is fully trusted, you can configure the DataPower sensor toignore the certificates validation.

Procedure

1. Choose the discovery profile used for your DataPower appliances discovery.2. Select DataPowerSensor from the sensor list and click New.3. Change the value of the validateCertificates property to false, enable the

configuration, and save it.4. Save the discovery profile.

Results

When you run a discovery by using the profile that you created, the DataPowersensor does not validate certificates, so you do not have to attach any truststorefiles to your DataPower access list entries.

Enabling host name verification:

When you use FQDN-based certificates, the host name verification step of SSLprotocol is bypassed due to TADDM scope definition restrictions. When you useIP-based certificates, you can enable the host name verification to fully secure theSSL connection.

About this task

TADDM scope definition is IP-address-based, not FQDN-based. Any FQDN valuethat is provided during the scope creation is immediately resolved to the IPaddress. The FQDN is not passed to the sensor when running the discovery. Thesensor must use the IP address when trying to connect to the Data Powerappliance. When the Data Power appliance certificate is FQDN-based, normally theSSL protocol error is raised to indicate a possible mismatch between the providedIP address and the FQDN of the service read from the certificate. To avoid thisproblem, the host name verification step is disabled by default.

When you use IP-based certificates, you can enable the host name verification stepto fully secure the SSL connection.

Procedure

1. Choose the discovery profile used for your DataPower appliances discovery.2. Select DataPowerSensor from the sensor list and click New.


3. Change the value of the bypassHostnameVerification property to false, enablethe configuration, and save it.

4. Save the discovery profile.

Results

When you run a discovery by using the profile that you created, the DataPowersensor is strictly compliant with SSL protocol. The IP address provided on theTADDM scope must exactly match the IP address stated in the certificate of theData Power appliance for the discovery to be successful.

Troubleshooting the sensorThis topic describes common problems that occur with the DataPower sensor andpresents solutions for those problems.

DataPower device discovered with SnmpMib2Sensor does notmerge with data discovered by other sensors

ProblemDataPower device that is discovered with SnmpMib2Sensor does notmerge with the data that is discovered by other sensors.

SolutionWhen DataPower device is configured to use the SNMP protocol, it can bediscovered by using SnmpMib2Sensor. However, DataPower uses a customset of SNMP OIDs that SnmpMib2Sensor does not query. These OIDs areread only by the CustomMib2ComputerSystem sensor with the use ofJython extension script.

For more information, see step 6 in the Adding a computer system templatefor a network device topic in the TADDM User's Guide.

To secure proper reconciliation with data stored by DataPower, VMWareand ZEnterprise sensors in Discovery Management Console, check thefollowing prerequisites:v Make sure that DataPowerComputerSystem template is enabled in

Computer Systems templates (which is the default setting).v Make sure that CustomMib2ComputerSystem sensor is enabled in the

discovery profile that is used to discover DataPower devices.v Make sure that the following files are in the TADDM installation:

– etc/templates/commands/DataPowerComputerSystem

– etc/templates/commands/extension-scripts/DataPowerComputerSystem.py

FreeBSD computer system sensorThe FreeBSD computer system sensor discovers computer systems that run theFreeBSD operating system, which is based on BSD UNIX.




Prerequisites

For the sensor to discover the operating system, the /bin/sh script must beconfigured as a default shell.

To successfully merge with data that is discovered by the VMware ESX computersystem sensor, the dmidecode command is required on the targets where you havethe FreeBSD operating system installed.

Limitations

All computer system sensors and the SNMP MIB2 sensor ignore network interfacesthat are configured to be down. TADDM does not populate the net.IpNetworkattribute on the following types of IP interfaces:v loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1v link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1v multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1v unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0


If the following command is present on the target system, the sensor discovers thelocal file systems:df -kTP

Discovery of IPv6 interfaces and IPv6 routing and forwardinginformation

The sensor discovers IPv6 interfaces and IPv6 routing and forwarding informationabout target systems that are configured to support IPv6. TADDM runs discoveriesagainst only IPv4 addresses. TADDM does not start a sensor against IPv6addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6 addresses.TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if theprefix length value is unspecified or equals zero.

The discovered IPv6 addresses are displayed in the TADDM user interfacesimilarly to IPv4 addresses and are accessible using the TADDM API. Because IPv6addresses use a prefix length value instead of an IPv4 netmask, only one of thesevalues is populated for an IP address. The value depends on the address type.

Asynchronous and script-based discovery supportThe FreeBSD computer system sensor supports script-based discovery.






Model objects with associated attributesThe FreeBSD computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the FreeBSD operating system in your ITenvironment.


core.LogicalContent

v Checksumv Contentv FixedPathv URI

net.L2Interface

v Promisciousv Namev HwAddressv Mtuv Speedv Duplexv AutoNegotiationv Broadcastv Loopbackv InterfaceMTUv InterfaceName

net.IpInterface

v IpAddressv L2Interfacev IpNetwork

sys.DNSResolveEntry

v ServerIpv SearchOrder

sys.freebsd.FreeBSD

v FQDNv Namev OSNamev OSVersionv BootTimev KernelArchitecturev KernelVersionv WordSizev Charsetv OsIdv OSModev OSConfidence


v VersionStringv KernelModulesRawData

sys.freebsd.FreeBSDUnitaryComputerSystem

v UUIDv Namev Typev SystemIdv Signaturev Fqdnv SerialNumberv Manufacturerv Modelv MemorySizev BIOSManufacturerv BIOSDatev BIOSNamev NumCPUsv CPUTypev CPUSpeedv Architecturev TimeZonev VirtualMachineState

sys.SoftwareComponent

v SoftwareVersionv Name

sys.unix.UnixFileSystem

v MountPointv Typev Capacityv AvailableSpacev Ownerv Groupv Permissions



To configure the access list, complete the following steps:1. Select ComputerSystem as the component type.2. Specify the access information (user name and password) that TADDM must

use for either SSH key-based authentication or SSH login-based authenticationto the target computer system.


Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process might require privilegeescalation, which can be done using the sudo command.

For more information, see the Commands that might require elevated privilege topic inthe Administrator's Guide.



Fix Pack 3 com.ibm.cdb.discover.sys.freebsd.pkg_info=pkg_infoThis property specifies the path to the pkg_info command on the FreeBSDoperating system versions 9.x, or earlier. The command provides theinformation about all installed packages on the FreeBSD operating system.

The default value is pkg_info.

Fix Pack 3 com.ibm.cdb.discover.sys.freebsd.pkg_info_10=pkg infoThis property specifies the path to the pkg info command on the FreeBSDoperating system versions 10.x, or later. The command provides theinformation about all installed packages on the FreeBSD operating system.

The default value is pkg info.

Troubleshooting the sensorThis topic describes common problems that occur with the FreeBSD computersystem sensor and presents solutions for those problems.

Duplicate FreeBSD guests are created

ProblemWhen the same guest that has the FreeBSD operating system installed isdiscovered by the FreeBSD computer system sensor and the VMware ESXcomputer system sensor, the data is not merged and duplicates are created.

SolutionInstall the dmidecode command on the targets where you have the FreeBSDoperating system installed. This command is required to successfullymerge with data that is discovered by the VMware ESX computer systemsensor.

HP BladeSystem SNMP sensorThe HP BladeSystem SNMP sensor discovers and collects configurationinformation about HP BladeSystem chassis.

The sensor uses SNMP (Simple Network Management Protocol) to discover andquery BladeSystem infrastructure components. HP BladeSystem OnboardAdministrator SNMP component is used to collect the data.





The sensor creates the following model objects:v enums.PhysTypeEnumv enums.SlotStateEnumv enums.BladeCenterManagementModuleTypeEnumv net.Fqdnv phys.physconn.PhysicalConnectorv phys.physconn.Slotv phys.physpkg.Boardv phys.physpkg.Chassisv phys.physpkg.Fanv phys.physpkg.PhysicalFramev phys.physpkg.PowerSupplyv sys.blade.BladeCenterManagementModulev sys.ComputerSystemv storage.FCSwitch



You can configure the HP BladeSystem SNMP sensor in the DiscoveryManagement Console by setting the following attributes:

snmpPort The port number used for SNMP communication. The default value is 161.

snmpTimeout The timeout used for a single SNMP query. The default value is 20000.

locale The locale used for SNMP queries.

characterEncoding The character encoding used for SNMP queries.

When the HP BladeSystem SNMP sensor is enabled, you must also enable theSNMP Light sensor or SNMP MIB2 sensor for the HP BladeSystem SNMP sensorto function correctly.


To configure the access list, enter the following information:v For SNMP V1 and V2 discovery, enter the correct Community String into the

access list.You can do this by using the Network Template (SNMP) Component Type in theAccess List window in the Discovery Management Console.


v For SNMP V3 discovery, enter the correct user name, password, andauthentication protocol into the access list, according to the SNMP V3 credentialmapping information in the following table.

Table 19. SNMP V3 credential mapping.


Authentication type (for example MD5) Authentication Protocol



You can do this by using the Network Template (SNMPV3) Component Type inthe Access List window in the Discovery Management Console.

Troubleshooting the sensorThis topic describes common problems that occur with the HP BladeSystem SNMPsensor and presents solutions for those problems.

An SNMP time out error occurs

ProblemThe sensor generates an SNMP time out error during a discovery.

SolutionIncrease the value of the snmpTimeout parameter for the HP BladeSystemSNMP sensor by using the Discovery Management Console.

HP Blade System objects do not reconcile with Level 2 discoverydata

ProblemDiscovery of HP Blade System creates Computer Systems that do notreconcile with the Level 2 discovery data when Virtual Connect has logicalserver profiles enabled.

SolutionTADDM inspects objects that come from HP Blade System discovery, whenthe default attributes manufacturer, model and serialNumber do not match.The logic inside reconciliation plug-in requires that the manufacturer,model, and FQDN attributes are the same as the data found during the Level2 discovery to enable reconciliation of both objects. If FQDN is notavailable, two instances of the same object appear in the database.

HP NonStop computer system sensorThe HP NonStop computer system sensor discovers the computer system that runsthe HP NonStop OSS operating system. The sensor works only in Asynchronousdiscovery mode.


HpNonStopComputerSystemSensor

Prerequisites

A discovery user needs to have access to both OSS and Guardian environment. AnASD script is executed from OSS environment.


You can create an ASD package with following command:$COLLATION_HOME/bin/makeASDScriptPackage.sh --outputDir output dir--uname NONSTOP_KERNEL --ipAddress ip_address--packingMethod tar --sensors computersystem

Limitations

The sensor is supported only in the Asynchronous discovery mode (ASD).

The sensor discovers the limited set of Computer System details. The GenericServer Sensor that starts Level 3 sensors is not supported on the HP NonStopplatform.


The sensor creates the following model objects:v core.LogicalContentv sys.hpnonstop.HpNonStopv sys.hpnonstop.HpNonStopComputerSystem

Asynchronous discovery supportThe HP NonStop computer system sensor supports asynchronous discovery.





Troubleshooting the sensorProblems with the sensor might include unsuccessful discovery or incorrectlydefined properties. However, you can recover from these problems.

General problems

Verify that the following sensors are enabled in the profile:v ASDPingSensorv ASDSensorv GenericComputerSystemSensorv HpNonStopComputerSystemSensor

Verify that the ASD packages are available for a discovery in a directory definedby property com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory.

HP-UX computer system sensorThe HP-UX computer system sensor discovers a computer system that is runningthe HP-UX operating system. If a system is running HP-UX on an Itaniumplatform with virtualization support (HP Integrity Virtual Machines), the sensordiscovers elements that are managed by the server.




Prerequisites

For a VM Host system on an Itanium platform, the TADDM service account musthave Execute permissions on the hpvmstatus and hpvminfo binary files.

For a guest system on an Itanium platform, the TADDM service account must haveExecute permissions on the hpvminfo binary files.

The TADDM service account must have Execute permissions on the machinfobinary files.

Limitations



The following limitations when discovering CPU information through the HP-UXComputer System sensor apply:v The sensor doesn't discover 'CPUCoresInstalled' for PA-RISC architecture.v The sensor doesn't discover threads number for CPU - HyperThreading

configuration.v The sensor doesn't discover 'CPUDiesInstalled' if command 'mpsched -K' is

unavailable.v The sensor doesn't discover 'CPUCoresInstalled' if command 'icapstatus' is

unavailable.v The sensor doesn't discover cpu/cores configuration if command 'mpsched -K' is

unavailable.

Discovery of IPv6 address of a guest system through a VM Host is not availablefor HP-UX on an Itanium platform. Discovery of IPv6 address of a VM Hostthrough a guest system is not available for HP-UX on an Itanium platform.

Guest systems that are running non-HP-UX operating systems are not createdduring discovery of the VM host systems.

TADDM is unable to discover CPU cores information of IVM guest, which isdirectly discovered by the sensor. This happens because the icapstatus commandis not supported on the IVM guest.






The sensor creates the following model objects:v core.LogicalContentv sys.hpux.HpUxv sys.HpUxUnitaryComputerSystemv sys.OperatingSystemv sys.SoftwareComponent

Model objects with associated attributesThe HP-UX computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout HP-UX computer system resources in your IT environment.


sys.hpux.HpUxUnitaryComputerSystem

v Namev UUIDv Typev SystemIdv VirtualMachineStatev Signaturev Fqdnv Manufacturerv Modelv MemorySizev NumCPUsv CPUTypev CPUSpeedv Architecturev Virtualv CPUDiesInstalledv CPUCoresInstalled


v ChildSystemv VMID

sys.CPU

v IndexOrderv CPUTypev NumCPUsv CPUSpeedv CPUCoresEnabledv CPUCorev Virtual

sys.hpux.HpUx

v Fqdnv Namev OSNamev OSVersionv BootTimev PatchesInstalledRawDatav KernelVersionv OsIdv KernelModulesRawDatav OSConfidencev VersionString

core.LogicalContent

v Checksumv Contentv URIv fixedPath


v Namev SoftwareVersion


v AvailableSpacev Capacityv MountPoint

net.L2Interface

v IANAInterfaceTypev interfaceMTUv interfaceSpeedv interfaceNamev HwAddressv Mtuv Namev Speedv Loopback


v Broadcastv Encapsulation

net.IpInterface




The HP-UX computer system sensor can be run using the ComputerSystem accesscredentials. To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM must


Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation. Typically, this escalation is done using the sudo command.




com.collation.platform.os.command.machinfoThis property specifies the path to the machinfo command. If this propertyis not set, the default value of /usr/contrib/bin/machinfo is used.

com.collation.discover.agent.command.kcmoduleThis property specifies the path to the kcmodule command.

com.collation.platform.os.HpUxItanium.ModelUsed as a starting point for HpUx on Itanium. The default value is ia64.Change this property when the model command on HP-UX Itaniumsystems does not contain ia64 in the output.

com.collation.discover.agent.command.hpvminfoThis property specifies the path to the hpvminfo command. If this propertyis not set, the default value of /opt/hpvm/bin/hpvminfo is used.

com.collation.discover.agent.command.hpvmstatusThis property specified the path to the hpvmstatus command. If thisproperty is not set, the default value of /opt/hpvm/bin/hpvmstatus is used.

com.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:


com.collation.platform.os.command.crontabEntriesCommand.HP-UX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.HP-UX=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.HP-UX.1.2.3.4=root,build

com.collation.discover.agent.sys.ComputerSystem.serialNumberSanityChecks="⌂(?!null);⌂(?!not );⌂(?!n/a);⌂(?!permission);⌂(?!to be );⌂(?!undef); ⌂[-:\.\w]{4,80}$; ^(?!.{8}(\-.{4}){3}\-.{12}_.{2}(:.{2}){5});^(?!none);^(?!x{7});^(?!\.{9});^(?!0123456789);^(?!0+$)";

This property is used to validate the serialNumber property that isdiscovered by the operating system sensors, except Solaris, to avoid storinggeneric values, such as Not Defined, To be set by OEM, or PermissionDenied.

The main default rule is that a serial number must contain from 4 to 80characters and not begin with one of the following strings:v null : regular expression ^(?!null)

v not : regular expression ^(?!not)

v n/a : regular expression ^(?!n/a)

v permission : regular expression ^(?!permission)

v to be : regular expression ^(?!to be)

v undef : regular expression ^(?!undef)

v string in form : 098D8710-E623-3C3B-9F9B-FCBAFF1BF3B6_5C:F3:FC:E8:89:FC : regular expression^(?!.{8}(\-.{4}){3}\-.{12}_.{2}(:.{2}){5})

v none : regular expression ^(?!none)

v xxxxxxx : regular expression ^(?!x{7})

v ......... : regular expression ^(?!\.{9})

v 0123456789 : regular expression ^(?!0123456789)

v 0000 : regular expression ^(?!0+$)

If a serial number does not follow this rule, it is not set. The regularexpression syntax is defined in the Java SDK for classjava.util.regex.Pattern. Regular expressions must be separated bysemicolons. Candidate serial numbers are always converted to alllowercase before they are matched against the regular expressions.Therefore, when you customize the property, use lowercase characters only.

Troubleshooting the sensorThis topic describes common problems that occur with the HP-UX computersystem sensor and presents solutions for those problems.

General problems

Verify that the attributes, such as Architecture, processor type, processor speed,Memory size, or Serial number, are not populated.

Verify that the output of the model command contains ia64, and if it does not,verify that the target is HP-UX 11.23 on Itanium. Change the


com.collation.platform.os.HpUxItanium.Model property to include the uniqueidentifier from the model command output.

The Serial number attribute is not populated on Itanium by default. To enable theSerial number attribute, add the following entry in the collation.properties fileon the TADDM server:com.collation.discover.agent.sys.HpUxComputerSystemItaniumAgent.setSerialNumber=true

Hardware details are not displayed

ProblemDuring a discovery through IBM Tivoli Monitoring, certain detailedinformation is not displayed for computer systems running the HP-UXoperating system.

SolutionIn the collation.properties file, add the |.*machinfo.* pattern to theend of the property:com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*machinfo.*

IBM AIX computer system sensorThe IBM AIX computer system sensor discovers computer systems that run theIBM AIX operating system. In addition, workload partitioning (WPAR) in the IBMAIX 6.1 operating system is discovered by the sensor.



Prerequisites

The TADDM user must have an access to the entstat command on AIX targetsystems.

In a system P or a system Z computer system environment, the LPAR ID should besaved in the VM ID attribute, to avoid the incorrect merging of different LPARs toa single object.

For AIX, the VMID attribute has been changed from LPAR ID (numeric) to LPARname (text). VMID and LPAR must be set as True.

Limitations



The sensor discovers WPARs by using the WPAR name and IP address. Afterrunning a discovery, if the IP address or name of WPAR has changed then clear


the topology data before running the discovery again. This task avoids thesituation, where duplicate WPARs with the same name exist in the database. Thislimitation does not apply to WPARs where the IP address is not configured.

The fully qualified domain name (FQDN) can be obtained for the WPAR from thehost name. In this case, TADDM does not request the host name from the DNSserver and the name is not displayed.

Information about the attributes virtual memory size and page space for the WPARis not discovered.

The WPAR mobility function that allows you to move running WPAR instancesbetween physical systems is not supported.

Fix Pack 1

Live Partition Mobility (LPM) is not supported in TADDM 7.3.0. It is

supported in 7.3 Fix Pack 1, and later.




Asynchronous and script-based discovery supportThe IBM AIX computer system sensor supports asynchronous and script-baseddiscovery.



For information about configuring for script-based discovery, see the Configuring forscript-based discoveryin the TADDM Administrator's Guide.




Limitations

Computer system templates and extensions are not supported by the AIXcomputer system sensor during asynchronous or script-based discovery.


Model objects with associated attributesThe IBM AIX computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the IBM AIX operating system and workloadpartitioning (WPAR) resources in your IT environment.


core.LogicalContent

v Checksumv Configfilev Contentv ContentTypev FixedPathv URI

net.L2Interface

v AlternativeNamev AutoNegotiationv Broadcastv Duplexv Encapsulationv HwAddressv InterfaceMTUv InterfaceNamev Loopbackv Mtuv Namev Promisciousv Speedv IANAInterfaceTypev Index

net.IpInterface


sys.aix.Aix

v BootTimev Charsetv FQDNv KernelModulesRawDatav KernelVersionv Namev OSConfidencev OsIdv OSMode


v OSNamev OSVersionv PatchesInstalledRawDatav VirtualMemorySizev WordSizev VersionStringv Levelv BuildLevelv ServicePack

sys.aix.AixUnitaryComputerSystem

v Architecturev BIOSManufacturerv CPUSpeedv CPUTypev DesiredProcessingUnitsv Fqdnv IsVMIDanLPARv Manufacturerv MaxProcessingUnitsv MemorySizev MinProcessingUnitsv Modelv Namev NumCPUsv SerialNumberv Signaturev SystemIdv TimeZonev Typev Virtualv VMIDv VirtualMachineStatev ChildSystem

sys.AixSoftwareComponent

v InstallStatev Namev SoftwareVersionv Type

sys.CPU

v IndexOrderv CPUTypev NumCPUsv CPUSpeedv Virtual


sys.DNSResolveEntry

v SearchOrderv ServerIp


v AvailableSpacev Capacityv Groupv MountPointv Ownerv Permissionsv Type

sys.PageSpace

v IsActivev Namev Sizev Type

sys.WPARComputerSystem

v AssignedIpv IsWparActivev IsWparAutostartv IsWparCheckpointablev WparCPULimitsv WparCPUSharesv WparInstalledDirectoryv WparMemoryLimitsv WparMemorySharesv WparOwnerv WparPerProcessVirtualMemoryLimitv WparTypev Namev Typev Virtual


Edit the /etc/sudoers file on the AIX server and add the following line:<TADDM_USER> ALL=NOPASSWD: ALL


To configure the access list, complete the following steps:1. Use ComputerSystem as the Component Type.


2. Specify the access information (user name, password) that TADDM must usefor either SSH key-based authentication or SSH login-based authentication tothe target computer system.

Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation. This escalation, can be done using the sudo command.


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the IBM AIX computersystem sensor uses.


com.collation.discover.agent.command.lswpar.AIX=sudo lswparThe lswpar command requires administration privileges.

com.collation.platform.os.command.crontabEntriesCommand.AIX=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.AIX.1.2.3.4=crontab -l

com.collation.platform.os.command.crontabEntriesUsers.AIX=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.AIX.1.2.3.4=root,build

















Troubleshooting the sensorThis topic describes common problems that occur with the IBM AIX computersystem sensor and presents solutions for those problems.

Sensor does not discover WPARs

ProblemThe sensor is not able to discover WPAR.

SolutionTo check the status of the WPAR:1. Run the sudo lswpar command using the <TADDM_User> credentials.

If a list of WPARs is not displayed, assign to the <TADDM_User>administrator credentials to run the lswpar command.

2. Modify the sudo specific command in the collation.properties file.

Discovered WPARs do not display attribute values

ProblemSome of the discovered WPARs do not display attribute values.

SolutionVerify if the WPARs present are in an active or defined state. For WPARsthat are in a defined state, a limited number of attribute values aredisplayed.

IBM Hardware Management Console sensorThe IBM Hardware Management Console sensor discovers the IBM HardwareManagement Console (HMC) and its managed systems.


HmcSensor

Resources discovered by the sensor

The process for discovering an HMC is like discovering a standard computersystem. The most important issues that impact discovery is connectivity andauthentication. If the account configured in the TADDM access list can connect tothe HMC, the discovery is successful.

Through the HMC, the following resources can be discovered:v HMC, the hardware management console.v The systems managed by the HMC (System p and System i® computer systems).


v The logical partitions (LPARs) defined within each managed system.v If an LPAR is installed with the Virtual I/O Server (VIOS), the VIOS is

discovered.

Depending on the discovery scope, discovering a computer system (LPAR) candiscover two instances of the computer system:v The computer system (LPAR) discovered by the HMC sensor.v The computer system discovered by the normal TADDM sensor for the

particular operating system, such as Linux or AIX, among others.This instance is discovered just as a physical Linux or AIX computer system.There are no special TADDM sensors to discover these virtual computer systemsany differently than the physical computer systems they emulate.

The computer system (LPAR) discovered by the HMC is a shallow computersystem. The following key attributes, which form the naming rule, are discovered:v Manufacturerv Modelv Serial numberv LPAR ID

After discovery, TADDM merges the two instances into a single computer system.

VIOS is discovered with the following storage mapping information:v Virtual SCSI adaptersv Virtual NPIV adaptersv Virtual target devicesv Physical volumesv MPIO pathsv HBAs

You must use the Hmcoperator user to discover storage mapping information.

VIOS is discovered with the following network mapping information:v Virtual adaptersv Physical adaptersv Shared ethernet adapters

With the discovery of HMC and the storage sensor discovery of LPARs, you cansee a mapping between the LPAR disk and the virtual target device of a VIOS.

Limitations

Fix Pack 1 Live Partition Mobility (LPM) is not supported in TADDM 7.3.0. It issupported in 7.3 Fix Pack 1, and later.

Model objects with associated attributesThe IBM Hardware Management Console sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about IBM Hardware Management Console (HMC) and its managedsystems in your IT environment.



app.SoftwareFix

v ControlSoftware

dev.FCPort

v DeviceIDv TotalNpivPortsv AvailableNpivPortsv Parentv Descriptionv PhysicalLocationCodev Statusv PermanentAddressv ChildPortsv SecondaryAddress

dev.BasedOnExtent

v Sourcev Target

dev.MediaAccessDevice

v Manufacturerv Modelv Namev SerialNumberv Statusv Type

dev.SCSIProtocolController

v Namev Parentv PhysicalLocationCodev Clientv ServerSlotNumberv TargetDevicesv ClientSlotNumberv ObjectTypev Descriptionv EndPoints

dev.SCSIProtocolEndPoint

v Namev Parentv Description

dev.StorageVolume

v Namev Parentv Type


v IeeeUniqueVolumeNamev Capacityv LUNv Pvidv NumStalePartitionsv SerialNumberv SystemPStatev ViosUDIDv VolumeGroupNamev BasedOnv MpioPaths

dev.vios.MpioPath

v Controllerv Volumev Connectionv Status

dev.vios.NpivViosVirtualAdapter

v ClientStatusv FcPorts

dev.vios.VirtualTargetDevice

v BackingDevicev Status

net.L2Interface

v AlternativeNamev DefaultVlanv HaModev HwAddressv Indexv IsIEEE8021QCompatiblev IsTrunkv Namev NetworkedFromVlanv Parentv SwitchPortModev TrunkPriorityv ViosType

net.Vlan

v Interfacesv MgmtDomainNamev VlanIdv VlanName

sys.ComputerSystem

v CPUCoresEnabledv CPUCoresInstalled


v CPULimitv CPUSpeedv CPUTypev ChildSystemv ContextIpv Descriptionv DesiredHugePagesv DesiredMemorySizev DesiredProcessingUnitsv DesiredProcessorsv Devicesv DisplayNamev FileSystemsv Fqdnv Functionsv Guidv HostSystemv IpInterfacesv IsVMIDanLPARv L2Interfacesv Labelv ManagedSystemNamev Manufacturerv MaxHugePagesv Memoryv MemoryLimitv MemorySizev MinHugePagesv Modelv Namev NumCPUsv OSInstalledv OSRunningv ObjectTypev PrimaryMACAddressv SerialNumberv Signaturev StorageExtentv SystemIdv Typev UncappedWeightv VMIDv Virtual

sys.ControlSoftware

v BuildLevel


v ContextIpv DisplayNamev Fixesv Levelv MajorVersionv Modifierv Namev Releasev VersionString

sys.FileSystem

v Parentv MountPoint

sys.Function

v Namev Parent

sys.HMC

v Systemp

sys.LocalFileSystem

v StorageExtent

sys.SystemPComputerSystem

v Architecturev AvailableSysProcUnitsv CPUCoresEnabledv CPUCoresInstalledv CPUSpeedv CPUTypev ConfigurableNumSysHugePagesv ConfigurableSysProcUnitsv ConfigurableSystemMemoryv DeconfiguredSysProcUnitsv DeconfiguredSystemMemoryv HugePageSizev Is5250ApplicationCapablev IsCoDMemoryCapablev IsCoDProcessorCapablev IsI5OSCapablev IsLHCACapablev IsLHEACapablev IsMicroPartitioningCapablev IsSNIMsgPassingCapablev IsVIOSCapablev Manufacturerv MaxNumProcessorsPerLPARv MaxsSharedProcessorPools


v MemoryAvailableForPartitionsv MemorySizev MinProcessingUnitsPerVirtualProcessorv Modelv SerialNumber


Configuring the discovery profileBy default, the IBM Hardware Management Console (HMC) sensor is enabled for aLevel 2 or Level 3 discovery. The sensor discovers all logical partitions (LPARs)regardless of whether the system is running. To discovery LPARs only when thesystem is running, create a Level 2 or Level 3 discovery profile for the IBMHardware Management Console (HMC) sensor, and customize the sensor settings.



the Clone existing profile list, select Level 2 Discovery, or Level 3 Discovery,and click OK.

4. On the Sensor Configuration tab, select the HmcSensor sensor.5. In the Create Configuration window, type the name and description for your

configuration, and select the Enable Configuration check box.6. In the Configuration section of the Create Configuration window, click

discoverNonRunningLpars. Then double-click the Value field in the row, andtype false.



To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. Username.This username should have (at a minimum) the authorizations mentionedbelow.

b. Password

From the HMC management console, create a user account for the TADDMdiscovery user. The user account must be based on the hmcoperator role.

In addition, the following command line tasks must be assigned to the useraccount:

Managed SystemRequired to use the lshwres and lssyscfg commands


Logical PartitionRequired to use the lshwres, lssyscfg, and viosvrcmd commands

HMC ConfigurationRequired to use the lshmc command

Configuring the collation.properties entriesThis topic lists the collation.properties file entries that the sensor uses.

You can set the following entries in the collation.properties file:

com.collation.discover.agent.HmcSensor.timeoutThis property specifies the time, during which the sensor is allowed to runthe discovery. If the amount of the retrieved data about the storage is toogreat, the sensor might not complete within the specified time. To collectall the details, increase the value of this property.

The value of this property is expressed in milliseconds.

com.collation.discover.agent.HMC.discoverStorageMapping=trueThis property is used to provide all the details regarding the retrieveddata. If you are not interested in collecting all the details, set this propertyto false, and decrease the value of thecom.collation.discover.agent.HmcSensor.timeout property.

The default value of this property is true.

This property is a scoped property, you can append the IP address or nameof the scope to this property.

Examples

The following examples show the retrieved information, when thecom.collation.discover.agent.HMC.discoverStorageMapping=true property is setin the collation.properties file. The examples apply to the AIX operating system.

discoverDevicesThe command to get the information:viosvrcmd -m ’{0}’ --id ’{1}’ -c ’lsdev -field name status physlocdescription parent -state 1 -fmt ::’

discoverPhysicalVolumesThe command to get the information:viosvrcmd -m ’{0}’ --id ’{1}’ -c ’lspv -size -fmt ::’

discoverVirtualScsiServerAdaptersThe command to get the information:viosvrcmd -m ’{0}’ --id ’{1}’ -c ’lsmap -all -field svsa physlocclientid vtd status lun backing -fmt ::’

IBM Integrated Virtualization Manager sensorThe IBM Integrated Virtualization Manager sensor discovers IBM POWER®

processor-based systems managed by an Integrated Virtualization Manager (IVM).


IvmSensor


Resources discovered by the sensor

The process for discovering an IVM is like a standard computer system. The mostimportant issues that impact discovery is connectivity and authentication. If theaccount configured in the TADDM access list can connect to the IVM, thediscovery is successful.

Through the IVM, the following resources can be discovered:v The integrated management console.v The system managed by the IVM (System p or System i computer systems).v The logical partitions (LPARs) defined within the managed system.

Depending on the discovery scope, discovering a computer system (LPAR) canactually discover two instances of the computer system:v The computer system (LPAR) discovered by the IVM sensor.v The computer system discovered by the normal TADDM sensor for the

particular operating system, such as Linux or AIX, among others.

This instance is discovered just like a physical Linux or AIX computer system.There are no special TADDM sensors created to discover these virtual computersystems any differently than the physical computer systems they emulate.

The computer system (LPAR) discovered by the IVM is a shallow computersystem. The following key attributes, which form the naming rule, are discovered:v Manufacturerv Modelv Serial numberv LPAR ID, which are naming rule attributes.

After discovery, TADDM merges the two instances into a single computer system.


The sensor creates the following model objects:v sys.ComputerSystemv sys.ControlSoftwarev sys.IVMv sys.SystemPComputerSystemv sys.VIOS



To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the following required information:

a. User name.


b. Password

From the IVM management console, create a user account for the TADDMdiscovery user with the View Only role.

IBM i computer system sensorThe sensor discovers the IBM i operating system, which is used on the IBM PowerSystems™ family of servers and is the next generation of the IBM i5/OS operatingsystem and the IBM OS/400® operating system.



Prerequisites

The sensor requires the following software to be installed and operational:v IBM Portable Utilities for i, which provides OpenSSH and OpenSSL for IBM i.v Qshell, which is a standards-based command interpreter that enables a common

development environment.v Portable Application Solutions Environment (PASE), which includes three shells

(Korn, Bourne, and C Shell) and over 200 utilities that run as IBM i PASEprograms.

v The IBM Toolbox for Java, which is a library of Java classes that give Javaprograms easy access to the IBM i data and resources.

For IBM i 7.1, you need the following versions of the required software:v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V7R1M0)v Qshell: 5770SS1 option 30v PASE: 5770SS1 option 33

Note: In IBM i 7.1, the licensed program product JC1 (IBM Toolbox for Java) is nolonger provided as a separate product. Instead, it is included as part of 5770SS1option 3.

For IBM i 6.1, you need the following versions of the required software:v IBM Portable Utilities for i: 5733SC1 *BASE and option 1 (V6R1M0)v Qshell: 5761SS1 option 30v PASE: 5761SS1 option 33v IBM Toolbox for Java: 5761JC1

For IBM i 5.4 and i5/OS V5R3, you need the following versions of the requiredsoftware:v IBM Portable Utilities for i5/OS: 5733SC1 *BASE and option 1v Qshell: 5722SS1 option 30v PASE: 5722SS1 option 33v IBM Toolbox for Java: 5722JC1


Limitations



TADDM does not support the discovery of IBM i systems when using public keyinfrastructure (PKI) authentication. To initialize a connection between the TADDMserver and an IBM i system, you must use a user name and a password.


The sensor creates the following model objects:v core.LogicalContentv dev.MediaAccessDevicev sys.i5OS.I5OperatingSystemv sys.i5OS.I5OSSoftwareComponentv sys.i5OS.I5Profile


Sufficient access privileges are required that allow users to discover the system:v Privilege class: Userv System privileges:

– All object access is required to discover all user profiles on the system.– Save/restore

IPSO computer system sensorThe IPSO computer system sensor discovers Nokia firewall devices running theIPSO operating system.


IPSOComputerSystemSensor

Limitations

All computer system sensors and the SNMP MIB2 sensor ignore network interfacesthat are configured to be down. TADDM does not populate the net.IpNetworkattribute on the following types of IP interfaces:v loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1v link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1v multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1


v unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0



The sensor creates the following model objects:v core.LogicalContent net.Firewallv sys.Functionv sys.ipso.ipsov sys.ipso.IPSOUnitaryComputerSystem


To configure the access list, complete the following steps:1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password) that TADDM should

use for either SSH key-based authentication or SSH login-based authenticationto the target system.

Linux computer system sensorThe Linux computer system sensor discovers computer systems running the Linuxoperating system.



Prerequisites

If you discover Red Hat Enterprise Linux 7, or CentOS Linux 7 with the Linuxcomputer system sensor, you must install the ifconfig command on the targets.This command is included in the net-tools package.

Limitations




The sensor discovers IPv6 interfaces and IPv6 routing and forwarding informationabout target systems that are configured to support IPv6. TADDM runs discoveries


against only IPv4 addresses. TADDM does not start a sensor against IPv6addresses. For DNS lookups, TADDM uses either the IPv4 or the IPv6 addresses.TADDM does not populate the net.IpNetwork attribute on an IPv6 interface if theprefix length value is unspecified or equals zero.


Asynchronous and script-based discovery supportThe Linux computer system sensor supports asynchronous and script-baseddiscovery.







Limitations

Some function that is provided by the Linux computer system sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

The following functions are not supported:v Computer system templates and extensionsv Deep Level 2 discoveryv Discovery on Linux systems that are not x86 systems

The following attributes are not supported for the L2Interface model object:v AutoNegotiationv Speedv Duplex

Model objects with associated attributesThe Linux computer system sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects aboutcomputer systems running the Linux operating system.


core.LogicalContent

v Checksum


v Configfilev Contentv ContentTypev FixedPathv URI

sys.linux.LinuxUnitaryComputerSystem

v Architecturev BIOSDatev BIOSManufacturerv BIOSNamev CPUCoresInstalledv CPUDiesInstalledv CPUSpeedv CPUTypev Fqdnv Manufacturerv MemorySizev Modelv Namev NumCPUsv SerialNumberv Signaturev SystemIdv TimeZonev Typev UUIDv VirtualMachineState

net.L2Interface

v AutoNegotiationv Broadcastv Duplexv Encapsulationv HwAddressv InterfaceMTUv InterfaceNamev Loopbackv Mtuv Namev Promisciousv Speedv IANAInterfaceType

net.IpInterface

v IpAddressv L2Interface


v IpNetwork

sys.CPU

v IndexOrderv CPUTypev NumCPUsv CPUSpeedv CPUCoresInstalledv Virtualv CPUCore

sys.DNSResolveEntry




sys.linux.Linux

v BootTimev Charsetv FQDNv KernelArchitecturev KernelModulesRawDatav KernelVersionv Localev Namev OSConfidencev OSModev OSNamev OSVersionv OsIdv VirtualMemorySizev WordSize

sys.PageSpace

v Namev PageSpacePriorityv Sizev Type


v Namev Publisher


v Releasev SoftwareVersion

sys.zOS.LPAR

sys.zOS.ZSeriesComputerSystem

sys.zOS.ZVMGuest

Configuring the sensorBefore running a discovery, you must configure the Linux computer system sensor.




Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process may require privilegeescalation (typically done using the sudo command).



You can configure the Linux computer system sensor in the DiscoveryManagement Console by setting the following attributes:

ignoreVMCPCommand=falseThis property is used when the vmcp command fails, which might lead toover merges of multiple Linux systems.

The default value of this property is false. If the value is set to true, thevmcp command is ignored.

The true value can be used, for example, when you have Linux installedon LPAR. To change the value to true, you must create a new sensorconfiguration in the Discovery Profiles tab. In the Create Configurationwindow, change the value of the property from false to true, and selectthe Enable this configuration and disable selected configurationoption.

Note: This property is ignored when thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled property is setto true. For more information, see the description of this property in the“Configuring the collation.properties file entries” section of the Linuxcomputer system sensor.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Linux computersystem sensor uses.


The sensor uses the control program vmcp command to discover a Linux virtualsystem running on a z/VM operating system. For each Linux virtual system,specify the path for the vmcp command in the collation.properties file.

Fix Pack 4 com.collation.platform.os.command.ifconfig=This property specifies a path to a command that is used to configurenetwork interfaces. The example of such command is ifconfig. However,you can provide any other command that has the same function, forexample the ip command. Network interfaces are required for thediscovery to be successful.

Fix Pack 3 com.collation.platform.os.command.CPUSpeed=cat /proc/cpuinfo |grep 'cpu MHz'|awk '{print $4}'| tail -1

This property specifies the command that is used to retrieve the value ofthe CPUSpeed attribute that is expressed in MHz. The default value of thisproperty is cat /proc/cpuinfo | grep 'cpu MHz'|awk '{print $4}'| tail-1.

Fix Pack 2 com.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled=falseThis property specifies whether the ignoreVMCPCommand attribute, or thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand property is used. If thisproperty is set to false, the ignoreVMCPCommand attribute is used. If thisproperty is set to true, thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand property is used, whichenables all sensors to discover the VMID and MMS attributes of Linux onSystem z targets.


Important: Use this property only when you have problems withsignatures that change when you discover Linux on System z targets. Ifyou decide to set this property to true, you must set it to this value in alldiscovery profiles, where the ignoreVMCPCommand attribute is set. Similarly,if this property is set to false, it must be set to this value in all discoveryprofiles.

For more information about the ignoreVMCPCommand attribute, see“Configuring the discovery profile” on page 383 section of the Linuxcomputer system sensor.

Fix Pack 2 com.ibm.cdb.discover.zlinux.ignoreVMCPCommand=falseThis property is used only when thecom.ibm.cdb.discover.zlinux.ignoreVMCPCommand.enabled property is setto true.

This property is used in the same way as the ignoreVMCPCommand attribute,only it is relevant to all sensors that discover Linux on System z targets,not just LinuxComputerSystemSensor. It provides the value of theignoreVMCPCommand attribute for all such sensors to prevent over mergesthat are caused by a wrong value of the VMID attribute, or no value at all.


Important: Use this property only when you have problems withsignatures that change when you discover Linux on System z targets. Ifyou decide to set this property to true, you must set it to this value in alldiscovery profiles, where the ignoreVMCPCommand attribute is set to true.Similarly, if this property is set to false, it must be set to this value in alldiscovery profiles.


com.collation.discover.agent.command.vmcp.Linux.1.2.3.4={command path}This value specifies the path name of the vmcp command for differentLinux virtual systems with different IP addresses. For example, to specifythe path of the vmcp command in the /sbin directory, on a Linux host withIP address 192.168.1.2, add the following entry to thecollation.properties file:com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=sudo /sbin/vmcp

com.collation.platform.os.command.crontabEntriesCommand.Linux=crontab -l-u This property is used to discover crontab entries. You can specify this

property as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.Linux.1.2.3.4=crontab -l -u

com.collation.platform.os.command.crontabEntriesUsers.Linux=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.Linux.1.2.3.4=root,build

















com.collation.discover.agent.ignoreVirtualMAC=trueThis property specifies whether the discovery of hardware addresses forvirtual interfaces on Linux targets is enabled. If you set this property totrue, hardware addresses are discovered.

The default value of this property is true.Related reference:“Troubleshooting the sensor”This topic describes common problems that occur with the Linux computer systemsensor and presents solutions for those problems.

Troubleshooting the sensorThis topic describes common problems that occur with the Linux computer systemsensor and presents solutions for those problems.

Host Signature error occurs on Red Hat Enterprise Linux 7 andCentOS Linux 7 targets

ProblemWhen you discover target systems that run Red Hat Enterprise Linux 7, orCentOS Linux 7, the following error occurs:2016-03-31 15:46:31,759 DiscoverManager [DiscoverWorker-7]SessionSensor-9.1.146.78-[22] DEBUG session.SshSessionClient - Command[LC_ALL=en_US.UTF-8;LANG=en_US.UTF-8;export LANG LC_ALL;ifconfig -a]failed in sessionssh2:/HostAuthcom.collation.platform.security.auth.HostAuth[taddmcfm][XXXXX]/[email protected]: exit status 127 (no stdout)

SolutionTo solve the problem, you must install the ifconfig command on thetargets. This command is included in the net-tools package.

Fix Pack 4

In TADDM 7.3.0.4, and later, you do not have to use the

ifconfig command. You can choose any other command that can managenetwork interfaces. You must specify its name and path in thecom.collation.platform.os.command.ifconfig property in thecollation.properties file. For details, see “Configuring thecollation.properties file entries” on page 383.

The sensor fails with a command failed to run error

ProblemThe following message is displayed:Error Message: CTJTD0431E: The following command failed to run or returnsa blank value: sudo /sbin/vmcp q userid | awk ’print{3}’.

The command vmcp q userid has failed to run or returns a blank value onthe target Linux virtual system running on a z/VM operating system.

SolutionThis problem is caused by one of the following conditions:v An incorrect path for the vmcp command on the target Linux virtual

system.v The vmcp tool is not installed on the target Linux virtual system.v The sudo command is not configured to run the vmcp command.v The system name is not configured on the z/VM system.

To solve this problem, complete the following steps:


v Verify that the correct path for the vmcp command is entered in thecollation.properties file. For details, see “Configuring thecollation.properties file entries” on page 383.

v Verify that the system name is configured on the z/VM system, thesystem name cannot be blank.

v If the vmcp tool is not installed on the Linux virtual system, you mustload it. To load the vmcp device driver, issue the modprobe vmcpcommand on the Linux guest.

v Verify that the sudo command is available. To verify run the followingcommand on the Linux guest where the monitoring agent is installed:sudo vmcp q userid

If sudo is active and loaded, this command sends the q userid commandto the hosting virtual machine, which queries the user ID for the guest.If there is not a requirement to reconcile the Linux virtual system to thehost system on the z/VM operating system, it is not necessary to run thevmcp command. You can use the externalized command property(com.collation.discover.agent.command.vmcp.Linux=) in thecollation.properties file to set the host system value to a “dummy” value.You must be able to parse the externalized command with the followingcommand appended to it:q userid | awk ’{ print $3 }’

For example, you might use:com.collation.discover.agent.command.vmcp.Linux.192.168.1.2=echo A B zVMHost

This produces the echo A B zVMHost q userid | awk ’{print $3 }’which returns the zVMHost name. The host attribute for your virtualsystems is set to “zVMHost” instead of the actual host system name.

v You can disable the vmcp command by setting the ignoreVMCPCommandcommand to true. For instructions, see “Configuring thecollation.properties file entries” on page 383.

z/VM guests can be duplicated after multiple discoveries of thesame Linux virtual system

ProblemDuplicates can occur if the command vmcp q userid returns a blank valueon the target Linux virtual system running on a z/VM operating system.

SolutionYou must manually merge these duplicates.

OpenVMS computer system sensorThe OpenVMS computer system sensor discovers computer systems running theOpenVMS operating system.




Prerequisites

To run a successful discovery with the OpenVMS computer system sensor, youmust complete the following prerequisite tasks:v Grant the discovery user the following privileges:

– CMKRNL– NETMBX– SYSLCK– TMPMBX– WORLD

v Set the PGFLQUOTA parameter to 327680.

Limitations




The sensor creates the following model objects:v core.LogicalContentv sys.openvms.OpenVmsv sys.openvms.OpenVmsUnitaryComputerSystem




Troubleshooting the sensorThis topic describes common problems that occur with the OpenVMS computersystem sensor and presents solutions for those problems.

Sensor fails without any errors

ProblemThe OpenVMS computer system sensor fails during the discovery, but itdoes not report any error. The discovery status is done, as if the discoverywas successful.


SolutionGrant the discovery user the SYSLCK privilege.

INSVIRMEM error displayed on Software Licenses tab

ProblemThe Software Licenses tab contains the following message:?%LIB-F-INSVIRMEM, insufficient virtual memory

SolutionTo solve the problem, set the PGFLQUOTA parameter to 327680.

Solaris computer system sensorThe Solaris computer system sensor discovers computer systems that are runningthe Solaris operating system.

Fix Pack 2

If you want to discover the Solaris Virtualization systems, run the Sun

Sparc Virtualization sensor. For more information, see “Sun Sparc Virtualizationsensor” on page 395.



Limitations



The sensor discovers the number of physical processors if one of the followingcommands are present on the target system:v psrinfo -p

v prtconf and kstat -m cpu_info. The kstat command must returnimplementation statistics.

The sensor discovers the number of processor cores when the command kstat -mcpu_info is present on the target system. The kstat command must return core_idstatistics.

For the sensor to discover information about promiscuous mode on the Solarisoperating system, the following command must be available for the networkinterface on the target system:kstat network_interface_name | grep promisc

The sensor does not discover the ZFS file systems.


If you want to discover Solaris operating system by running generic server sensor,you must have the /usr/ucb/ps command on the Solaris server. To install thecommand, install one of the following packages on the Solaris targets:v Solaris versions earlier than 10: install one, or both of the following packages:

– Solaris 32 bit: the SUNWscpu package– Solaris 64 bit: the SUNWscpux package

v Solaris 10: the SUNWscpu packagev Solaris 11: the compatibility/ucb package




Asynchronous and script-based discovery supportThe Solaris computer system sensor supports asynchronous and script-baseddiscovery.






For script-based discovery, the access list configuration is the same as for anonscript-based discovery.

Limitations

Some function that is provided by the Solaris computer system sensor during anonscript-based discovery is not supported in an asynchronous or script-baseddiscovery.

The following functions are not supported:v Computer system templates and extensionsv Deep Level 2 discoveryv Zone discovery


The following attributes are not supported:v L2Interface

– AutoNegotiation– Speed– Duplex

v ComputerSystem (global zone)– Virtual– ChildSystem– VMID– CPUCoresInstalled– CPUDiesInstalled

v ComputerSystem (local zone)– Virtual– HostSystem– VMID– CPUCoresInstalled– CPUDiesInstalled

Model objects with associated attributesThe Solaris computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the Solaris operating system.


sys.sun.SunSPARCUnitaryComputerSystem

v Namev Typev SystemIdv VirtualMachineStatev Signaturev Fqdnv Manufacturerv Modelv MemorySizev BIOSDatev BIOSNamev NumCPUsv CPUTypev CPUSpeedv Architecturev Virtualv TimeZonev CPUDiesInstalledv CPUCoresInstalledv ChildSystem


sys.CPU

v IndexOrderv CPUTypev NumCPUsv CPUSpeedv CPUCoresInstalledv Virtualv CPUCore

sys.sun.Solaris

v Fqdnv Namev OSNamev OSVersionv BootTimev PatchesInstalledRawDatav KernelArchitecturev KernelVersionv WordSizev Charsetv OsIdv KernelModulesRawDatav OSModev OSConfidencev VersionString

sys.DNSResolveEntry


core.LogicalContent



v Namev SoftwareVersion

net.L2Interface

v AutoNegotiationv Broadcastv Duplexv Encapsulationv HwAddressv InterfaceMTUv InterfaceNamev Loopback


v Mtuv Namev Promisciousv Speedv IANAInterfaceType

net.IpInterface




Configuring the sensorBefore running a discovery, you must configure the Solaris computer systemsensor.




Typically, an account with non-root privilege can be used. However, somecommands that TADDM uses during the discovery process can require privilegeescalation (typically done using sudo command).


Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Solaris computer systemsensor uses.


com.collation.platform.os.command.crontabEntriesCommand.SunOS=crontab -lThis property is used to discover crontab entries. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesCommand.SunOS.1.2.3.4=crontab -l


com.collation.platform.os.command.crontabEntriesUsers.SunOS=rootThis property is used to discover crontab entries for a specified user, use acomma-separated list to specify more than one user. You can specify thisproperty as a scoped property by appending an IP address or a scope setname to the property. The following example uses an appended IP address:com.collation.platform.os.command.crontabEntriesUsers.SunOS.1.2.3.4=root,build

com.collation.discover.agent.useSolarisPfiles=falseThe default value is false.

When set to true, this property causes the GenericServerSensor to use theptree and pfiles commands on Solaris target systems to discover the listof IP sockets and ports that are associated with the running processes. Theproperty replaces the use of lsof which might not be available in a Solarisenvironment.

Troubleshooting the sensorThis topic describes common problems that occur with the Solaris computersystem sensor and presents solutions for those problems.


ProblemThe TADDM discovery user does not have authority to run the pscommand with the full command-line arguments required to start thesensor.

SolutionComplete one of the following tasks:v Set the sticky bit for the ps command, by using the following command:

chmod u+s /usr/ucb/ps

Note: The sticky bit might be overwritten by the operating system if apatch is applied that updates the ps command.

v Configure the ps command to run with sudo access for the TADDMdiscovery user by completing the following steps:1. Set the following properties in the $COLLATION_HOME/etc/

collation.properties file:– com.collation.platform.os.command.ps.SunOS=sudo /usr/ucb/ps

axww

– com.collation.platform.os.command.psEnv.SunOS=sudo/usr/ucb/ps axwweee

– com.collation.platform.os.command.psParent.SunOS=sudo ps-elf -o ruser,pid,ppid,comm

– com.collation.platform.os.command.psUsers.SunOS=sudo/usr/ucb/ps auxw

2. Ensure that sudo access was granted to the TADDM discovery userby running the following command on the target system:sudo ps

Discovery fails during a discovery through IBM Tivoli Monitoring

ProblemDuring a discovery through IBM Tivoli Monitoring, the discovery failsbecause of a problem with running the command cd $HOME;LANG=Czonecfg -z s8-zone info.


SolutionIn the collation.properties file, add the |.*zonecfg.* pattern to theend of the property:com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=|.*zonecfg.*

A local zone is discovered without an IP address

ProblemAfter discovery of a global zone, a local zone is discovered without an IPaddress.

Solution

For some local zones that use an exclusive Ethernet adapter, a zone IPaddress cannot be determined from the global zone level. You must run adirect discovery of such zone to obtain full information about it.

To obtain a local zone IP configuration manually, run the followingcommand from the global zone level:zlogin <zonename> ifconfig -a inet

When you run the generic server sensor to discover Solaristargets, CTJTD0317E and CTJTP1135E errors occur

ProblemWhen you run the generic server sensor to discover Solaris operatingsystem targets, the following error and exception occur in DiscoveryManagement Console:CTJTD0317E An error occurred. CTJTP1135E The following text is the exitstatus: 1

SolutionThe error indicates that the /usr/ucb/ps command is not installed on theSolaris server. To solve the problem, install one of the following packageson your Solaris targets:v Solaris versions earlier than 10: install one, or both of the following

packages:– Solaris 32 bit: the SUNWscpu package– Solaris 64 bit: the SUNWscpux package

v Solaris 10: the SUNWscpu packagev Solaris 11: the compatibility/ucb package

Sun Sparc Virtualization sensor

Fix Pack 2

The Sun Sparc Virtualization sensor discovers both types of Solaris Virtualization:Zones and Logical Domains on a Solaris operating system.



Sun Sparc Virtualization sensor discovery scopeThe sensor discovers whether the guest domains are active, and thenretrieves all information about the guest domains.


The sensor also discovers whether the non-global zones are running, andthen retrieves all information about the non-global zones.

Sun Sparc Virtualization sensor dependencyThe sensor depends on the Solaris computer system sensor, which runs justbefore the Sun Sparc Virtualization sensor.

The Solaris computer system sensor discovers the Solaris system withdetailed information and passes the SunSPARCUnitaryComputerSystemobject to the Sun Sparc Virtualization sensor.

For this SunSPARCUnitaryComputerSystem object, the Sun SparcVirtualization sensor:v discovers all available guest domains and non-global zones, andv for each of these creates the shallow SunSPARCUnitaryComputerSystem

object.

The Sun Sparc Virtualization sensor can be run on Solaris systems that are ofvirtualization type:

Table 20.

Solaris Virtualization Type Discovers

Global zone Global zones and non-global zones

Non-Global zone* Non-global zone

Control Domain Control Domain (with name primary) andguest domains

Guest Domain* Guest domain

Note: *To retrieve operating system details for the 'non-global zones' and 'guestdomains', you must add the IP address of the zones and domains to the discoveryscope and rerun the Solaris computer system sensor.


The Sun Sparc Virtualization sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the Solaris operating system with the availablezones and logical domains.

The sensor creates the following model objects for the discovered zones and logicaldomains. The attributes that are associated with each model object are shownbelow the model object name.

For logical domainssys.sun.SunSPARCUnitaryComputerSystem

SystemId

Type

Functions

PrimaryMACAddress

MemorySize

NumCPUs


For non-global zonessys.sun.SunSPARCUnitaryComputerSystem

Virtual

Type

VMID

Functions

SystemId

Devices

ConfigContents

Fqdn

HostSystem

IsVMIDanLPAR

IpInterfaces

sys.FunctionNamev For logical domains: 'Guest domain' or 'Control domain'v For zones: 'Zone'

net.IpInterfaceIpAddress

Sun Fire SysControl sensorThe Sun Fire SysControl (SC) sensor discovers domains that are configured on SunFire systems.

The following information is obtained from the system controller on the Sun Firesystem:v Remote configuration administration operationsv Board assignments and board statusv Current usage statistics for Capacity on Demand (COD) resourcesv System board devices and resource usage informationv System controller (SC) failover status or rolev Platform type, board available component list, the domain state for each domain,

and Capacity on Demand (COD) information


SysControlSensor

Security issues

The TADDM service account must have platform administrator privileges, whichmeans that the account is a member of the UNIX group platadmn. Any user whois a member of the platadmn group has privileges to run the following SystemManagement Services (SMS) commands:v rcfgadm

v showboards


v showcodusage

v showdevices

v showfailover

v showplatform

Model objects with associated attributesThe Sun Fire SysControl (SC) sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout domains that are configured on Sun Fire systems in your IT environment.


phys.physpkg.Board

v DisplayNamev Namev PhysicalPackagev RelativePosition

sys.sun.DynamicSystemDomain

v Boardv DisplayNamev Fqdnv HostSystemv IsVMIDanLPARv Modelv Namev NumCPUsv SerialNumberv Typev Virtual

sys.sun.SunFireComputerSystem

v ChildSystemv Devicesv DisplayNamev Manufacturerv Modelv Namev SerialNumberv Type



To configure the access list, complete the following steps:


1. Select ComputerSystem as the Component Type.2. Specify the access information (user name and password), that TADDM must


An account with platform administrator privileges must be used.



com.collation.discover.agent.path.SunOSThis value specifies the path configuration for running commands.

The following commands are the System Management Services (SMS)commands that run:v rcfgadm

v showboards

v showcodusage

v showdevices

v showfailover

v showplatform

If the commands are in the opt/SUNWSMS/bin directory, for example, enterthe following command on one line:com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

com.collation.discover.agent.SysControlAgent.timeout=1200000This value specifies the time interval in milliseconds to allow the commandto run.

Troubleshooting the sensorThis topic describes common problems that occur with the Sun Fire SysControl(SC) sensor and presents solutions for those problems.

Sensor fails with a timeout error

ProblemDuring a discovery, the sensor fails with a timeout error.

SolutionIn the etc/collation.properties file, add the following property, wherevalue is the number of milliseconds allowed for the sensor to run:com.collation.discover.agent.SyscontrolAgent.timeout=1200000

Increase the value, until the sensor no longer fails with a timeout error.

The sensor fails with a getModelObject error

ProblemThe following message is displayed:Error Message: CTJTD3021E: The sensor fails in a remote server:discoverSystemController: getModelObject failure


SolutionIn the etc/collation.properties file, add the path configuration forcommand execution (for example, /opt/SUNWSMS/bin):com.collation.discover.agent.path.SunOS=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin:/opt/SUNWSMS/bin

Tru64 computer system sensorThe Tru64 computer system sensor discovers computer systems running the Tru64UNIX operating system.



Prerequisites

The sensor requires the following software:v sudo command toolv lsof diagnostic tool

Install both tools in the same path as defined in the access list for accessing theTru64 UNIX computer system. This installation must be done on each Tru64 UNIXcomputer system to be discovered. The most tested versions are sudo-1.6.8p9 andlsof-4.78, however, other versions are likely to work, except in the case where thespecific package does not support Tru64 UNIX. To get sudo-1.6.8p9 andlsof-4.78, go to the following Web sites:v For sudo-1.6.8p9: http://www.gratisoft.us/sudo/download.htmlv For lsof-4.78: http://freecode.com/projects/lsof/?branch%20id=6029&release

%20id=19567

Refer to the distributor Web sites or software readme files for a list of restrictions,such as the addition or removal of support for a platform or function. If aparticular package has restrictions, TADDM is affected by those restrictions.

Limitations




The sensor creates the following model objects:v core.LogicalContentv sys.ComputerSystemv sys.tru64.Tru64


http://www.gratisoft.us/sudo/download.html

http://freecode.com/projects/lsof/?branch%20id=6029&release%20id=19567

http://freecode.com/projects/lsof/?branch%20id=6029&release%20id=19567


Configuring non-root user to run the sensorYou must add the users credentials for non-root users.

Edit the /etc/sudoers file on the Tru64 UNIX computer system and add thefollowing line, where non-rootuser is the user that runs the command:<non-rootuser> ANY = NOPASSWD: /sbin/hwmgr

The /etc/sudoers must reside on the Tru64 UNIX computer system that is beingdiscovered.

For example, to enable the user taddmusr to run the command on any Tru64 UNIXcomputer system, enter the following line:taddmusr ANY = NOPASSWD: /sbin/hwmgr

For example, to enable the user taddmusr to run the /sbin/hwmgr command on aspecific target system named target, enter the following line:taddmusr target = NOPASSWD: /sbin/hwmgr

Two commands must be located in the default location on the Tru64 UNIXcomputer system: /sbin/hwmgr and /usr/sbin/ifconfig.




Typically, an account with non-root privilege can be used. The commands that areused by the Tru64 computer system sensor carrying out the discovery can requireprivilege escalation. Typically, this escalation is done by setting the file accesspermissions using the sudo command.


Troubleshooting the sensorThis topic describes common problems that occur with the Tru64 computer systemsensor and presents solutions for those problems.

Storage error messages displayed

ProblemStorage error messages.

SolutionIn this case, the Tru64 UNIX system issues a message with an Other IPDevice status. Check the locations and permissions on the dependenciesand run the discovery again.


VMware ESX computer system sensorThe VMware ESX computer system sensor discovers VMware ESX servers.




Discovering the VMware ESX server (host machine) runs as it does for any otheroperating system. The most important issues that impact discovery is connectivityand authentication. If the account configured in the TADDM access list can connectto the VMware ESX server target, the discovery is successful.

Discoveries are launched using commands run over SSH.

Discovering the Virtual Machines (guest machines) actually discovers two instancesof a VM, a physical instance and a virtual instance. After discovery, TADDMmerges these two instances. The result is a single instance with all the attributes ofa physical machine, but with the indication that it is virtual. In the XML output ofthe database, this output is represented by an attribute such as:<virtual>true</virtual>

In the Discovery Management Console, a VM (virtual machine) is represented by acomputer system icon that is blue and transparent.

The physical instance is discovered by the normal TADDM sensor for theparticular guest operating system, such as Linux. It is discovered just like aphysical machine, which includes finding typical devices and attributes. No specialTADDM sensors are required to discover these virtual machines any differentlythan the physical machines they emulate.

The virtual instance is discovered by the VMware ESX sensor. It primarily usesconfiguration files (.vmx) and commands on the VMware ESX server to discover ashallow instance with data that can be described as the following:v Attribute data required to match naming rules and create a valid stand-alone

VM instancev Certain basic information that the VMware ESX server provides through the

vmware-cmd command.v An attribute (primaryMACAddress) that is used to reconcile the shallow virtual

instance with any physical instance that can be discovered.

There are two user scenarios for a VM discovery:v All-inclusive: When discovering a scope that includes the server and physical

instances, everything works as expected.The result is a virtual instance that shows up in the appropriate domain tomatch its domain name. This virtual instance is populated with all the attributesthat a similar physical machine would have.In addition, it has data and relationships regarding the host ESX server, a virtualattribute that gets set to true, and a VMID attribute that gets set to the onespecified in the .vmx configuration file. As long as the TADDM server hasconnectivity and authentication to the VM, this scenario does not present anyproblems.


v VM-only: When discovering a scope that contains only the VM, it shows up as aphysical machine with typical attributes, except that VMware intentionallyoverrides some model and manufacturer data.Therefore, it is possible to determine if a machine is virtual by examining someattributes. However, the icon is the one used for physical computers, and thevirtual attribute is not set to true.

To ensure all FQDN information about a VM is collected, you must have VMwareTools installed on the VM.

Limitations

VMware vCenter servers are not discovered by the VMware ESX computer systemsensor. If you must discover these servers, use the VMware Virtual Center serversensor.



For VMware ESX server version 2.5 (all releases), you can discover virtual systemsonly that are running.


The sensor creates the following model objects:v core.LogicalContentv net.IpInterfacev net.L2Interfacev process.CPUResourcePoolv process.MemoryResourcePoolv process.NetworkAdapterResourcePoolv relation.AllocatedTov relation.DonatedTov sys.CPUv sys.darwin.Darwinv sys.darwin.DarwinUnitaryComputerSystemv sys.dos.Dosv sys.dos.DosUnitaryComputerSystemv sys.DNSResolveEntryv sys.FileSystemv sys.freebsd.FreeBSDv sys.freebsd.FreeBSDUnitaryComputerSystemv sys.linux.Linux


v sys.linux.LinuxUnitaryComputerSystemv sys.Memoryv sys.netware.Netwarev sys.netware.NetwareUnitaryComputerSystemv sys.OperatingSystemv sys.sun.Solarisv sys.sun.SunSPARCUnitaryComputerSystemv sys.UnitaryComputerSystemv sys.vmware.VmwareESXv sys.vmware.VmwareUnitaryComputerSystemv sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystem


Configuring the discovery profileBy default, the VMware ESX computer system sensor is enabled for a Level 2 orLevel 3 discovery. The sensor discovers only guest systems that are running. Todiscovery all guests, create a Level 2 or Level 3 discovery profile for the VMwareESX computer system sensor, and customize the sensor settings.



the Clone existing profile list, select Level 2 Discovery, or Level 3 Discovery,and click OK.

4. On the Sensor Configuration tab, select the VmwareComputerSystemSensorsensor.

5. In the Create Configuration window, type the name and description for yourconfiguration, and select the Enable Configuration check box.

6. In the Configuration section of the Create Configuration window, clickdiscoverNonRunningGuests. Then double-click the Value field in the row, andtype true.








com.collation.platform.os.command.osVersion.Vmware=/usr/bin/vmware –vThe default value is /usr/bin/vmware –v.

The command used to determine the version of VMware.

com.collation.platform.os.command.vmwareCmd=/usr/bin/vmware-cmdThe default value is /usr/bin/vmware-cmd.

The command used to perform operations on the virtual machine.

Troubleshooting the sensorThis topic describes common problems that occur with the VMware ESX computersystem sensor and presents solutions for those problems.

Duplicate VMs are created

ProblemAfter discovery, certain VMs seem to have duplicates.

SolutionTADDM discovers two instances of a VM, one physical and one virtual. Ifthey cannot be reconciled to the same specific machine, two instances canexist in the database with similar attributes. These are not duplicates, buttwo separately discovered instances of the same VM.

This distinction is key to troubleshooting the problem, and there areseveral things to check, starting with TADDM, moving into the VMwareenvironment, and then finally troubleshooting the general networkenvironment.

Issues related to a pre-existing instance or databaseThe first item to check when troubleshooting a reconciliationproblem is the database. If the VM has made the transition to anew VM, the old VM might not be able to reconcile.

The old instance can be deleted, preferably before restarting thediscovery. If multiple runs are necessary to try different solutions,remember to delete all instances of the existing VM in advance.

It can also help to delete the instance of the host ESX server. If it isfeasible in the environment, it can be helpful to drop and re-createthe TADDM database between discovery runs. Then run a newdiscovery and see if the duplicates still exist.

<primaryMACAddress> attributeThe main reason that two instances of a VM cannot be reconciledis that they have different values in the <primaryMACAddress>attributes. To determine this value for each instance, it is necessaryto export the objects of type ComputerSystem from the TADDMdatabase with the following command run on the TADDM server:

Non-Windows:$COLLATION_HOME/sdk/bin/api.sh -u <username> -p <password>

find --depth 1 ComputerSystem > <filename>.xml


Windows:%COLLATION_HOME%\sdk\bin\api -u <username> -p <password>

find --depth 1 ComputerSystem > <filename>.xml

An XML file that lists the first-level attributes for allinstances of the ComputerSystem class is generated. Lookfor the short name of the duplicate instances and scrolldown to the attribute named <primaryMACAddress>.

If the value is different for the two instances, it is necessaryto troubleshoot the MAC address assignments in theconfiguration file on the server, on the VM itself, or both.

VM configurationIf a VM is configured in NAT or 'host only' mode, the VMwareESXsensor discovers the virtual instance, but the physical instance isnot discovered.

VM configuration files on the ESX host serverThe TADDM VMwareESX sensor gathers information fromconfiguration files for each VM to be discovered. Theseconfiguration files can be located with the following ESXcommand:vmware-cmd –l (this is a lower-case ’L’)

This command lists the configuration file for each VM known tothe ESX server, indicated by the .vmx extension.

These files are in XML format and are not case-sensitive. View theinformation in the configuration file for the VM that has duplicateinstances.

Validate the information for each interface to ensure that the MACaddress for each line corresponds to an interface on the VM itself.ethernet0.present = "true"ethernet0.networkName ="VM Network"ethernet0.addressType = "generated"ethernet0.generatedAddress="00:0c:29:c1:a5:ee"ethernet0.generatedAddressOffset = "0"ethernet1.present = "true"ethernet1.networkName = "VM Network"ethernet1.addressType = "generated"ethernet1.generatedAddress="00:0c:29:c1:a5:f8"ethernet1.generatedAddressOffset = "10"

If the values are different in the configuration file or on the VM,correct them and try the discovery again.

Configuration on the VM itselfOn the VM, there is a command that displays the information foreach networking interface.

On non-Windows systems, the command is ifconfig. On Windowsthe command is ipconfig.

Examine the output and validate the interface/MAC pairingsagainst the ESX configuration file. You can also verify that eachinterface is working by pinging the associated IP address. Try thediscovery again.


Recent changes in a VM or movement from one ESX server to anotherIf a VM has been migrated from one ESX server to another, it ispossible that the configuration file was changed and that can affectdiscoveries.

If the lines that contain generatedAddress get deleted it can affectdiscoveries.

When migrating VMs in a VirtualCenter environment, any VMwith a generated MAC address is going to change it. If there is anexisting VM on the ESX server that can be successfully discovered,use the configuration file for that VM as an example and look forany lines that might have been deleted.

The ESX server where the VM originated can also be specified as atarget in a scope to see if the VM discovers correctly on that ESXserver. If there are lines that have been deleted or modified duringmigration, add or correct them and run the discovery again.

Name resolutionIf the VM cannot resolve to a single machine on the network, it canend up in TADDM as two separate instances. If the VM hasmultiple interfaces, and all interfaces are visible on the network,multiple valid instances can be found. It might not be possible tomerge all instances into a single instance.

This is typically caused by a mismatch between hosts files, DNS,NIS, or any other name resolution service.

The remedy is to test the name resolution by the machine shortname a few times from the VM itself, the ESX server, and theTADDM server. All the responses must match. If they returndifferent responses, modify the name service or hosts files until theresults are consistent. Try the discovery again.

General network connectivity & routingThere are global networking factors to consider in troubleshootingTADDM discoveries. As it relates to VMware discoveries, a firewallor other networking consideration such as SSH might partiallyobscure discovery of either the ESX server or the VM.

If the VM is discovered correctly by the VMware sensor, it isdisplayed with only a short name label under the PhysicalInfrastructure: Overview > Systems Tier > Virtual Systems >VMware ESX

The VM itself appears only as an object under the heading ofOther Ip Device or Other Computer System.

In the case where only the VM is discovered correctly by the OSsensor, it is displayed as the appropriate type of Computer System.The virtual instance is not displayed, and the ESX server might notbe displayed either.

Correct the routing and firewall configuration until the TADDMserver can ping and SSH to the ESX server and directly to each ofthe VMs, then try the discovery again.

Duplicate VMware ESX servers are created

ProblemVMware ESX servers (Version 2.5 (all releases)) seem to be duplicated. This


problem occurs when a sequential discovery is run by using the VMwareESX computer system sensor followed by the VMware Virtual Centerserver sensor.

SolutionYou must manually merge duplicated VMware ESX servers.

The TADDM User's Guide contains information about using the DataManagement Portal, including information about discovery tasks, and howto manually merge discovered configuration items.

VMware ESXi computer system sensorThe VMware ESXi computer system sensor discovers VMware ESXi servers.

The VMware ESXi computer system sensor discovers VMware ESX servers, whichsupport VMware API.

Sensor uses VMware API for discovery. VMware API is available on all ESXiservers and on ESX 3.x, ESX 4.x versions. Sensor is not using ssh console.


VmwareESXiComputerSystemSensor


For Virtual Machines and for ESX server, the sensor discovers the same data asVirtualCenter sensor. It cannot discover objects, which are higher in configurationtree than ESX, for example Clusters, Datacenters. Datastores are discovered withvery limited data, with name only.

ESX Serial number can be discovered in two ways, either via VMware API like allother data or via CIM API.

Prerequisites

VMware API must be present and enabled on ESX server.

Security issues

To discover the ESX server, you must set read-only permissions for the TADDMservice account.

Connection to servers with SSL

The VMware ESXi computer system sensor can connect to servers with SSL in twomodes - the default mode and a new mode.

The default modeThe default mode does not fully verify the certificate of a server. Thismode allows connection even if the certificate is self-signed, expired orwith an invalid host name. It rejects connection when other problems arefound, like certificate chaining error. The default mode can be used withthe default VMware certificates.

The new modeThe new mode fully verifies the certificate of a server. You can enable this


mode by setting the strictCertificateCheck configuration property totrue. When this mode is enabled, only valid certificates signed by trustedcertificate authorities are accepted.

Importing self-signed certificates to TADDMBy setting the strictCertificateCheck property to true, you can connectwith self-signed certificates. You must first import such a certificate toTADDM. Though self-signed certificates are trusted certificates, theirvalidity is still verified.

To import such certificates, complete the following steps:1. Open the taddm/dist/osgi/plugins/


2. Run the following command:java -cp lib/vmwarecommon.jar com.ibm.cdb.discover.sys.vmware.VmCertificateCollector ip:port

where ip is the IP address of the VMware ESXi computer system sensorhost, and port is the SSL port of that host.


The sensor creates the following model objects:v net.IpInterfacev net.L2Interfacev process.CPUResourcePoolv process.MemoryResourcePoolv process.NetworkAdapterResourcePoolv relation.AllocatedTov relation.DonatedTov sys.CPUv sys.vmware.VMWareDataStorev sys.unix.UnixFileSystemv sys.NFSFileSystemv sys.Memoryv sys.vmware.VMWareVirtualSwitchv sys.vmware.VMWarePortGroupv sys.darwin.Darwinv sys.darwin.DarwinUnitaryComputerSystemv sys.dos.Dosv sys.dos.DosUnitaryComputerSystemv sys.DNSResolveEntryv sys.FileSystemv sys.freebsd.FreeBSDv sys.freebsd.FreeBSDUnitaryComputerSystemv sys.linux.Linuxv sys.linux.LinuxUnitaryComputerSystemv sys.Memoryv sys.netware.Netware


v sys.netware.NetwareUnitaryComputerSystemv sys.OperatingSystemv sys.sun.Solarisv sys.sun.SunSPARCUnitaryComputerSystemv sys.UnitaryComputerSystemv sys.vmware.VmwareESXv sys.vmware.VmwareUnitaryComputerSystemv sys.windows.WindowsComputerSystemv sys.windows.WindowsOperatingSystem


Configuring the discovery profileBy default, the VMware ESXi computer system sensor is enabled for a Level 2 orLevel 3 discovery. The sensor discovers only guest systems that are running anddoes not discover ESX serial number. To change this behavior create new profileand customize sensor configuration.

Configuration items correspond to VirtualCenter sensor configuration.

The following properties can be set to true or false:

ordinalESXviaVCserialDiscoveryIt discovers a serial number by using VMware API. This is a standard wayto discover the serial number, it is faster than by using CIM API, it requiresfewer privileges, but is also more prone to errors.


directESXserialDiscoveryIt discovers a serial number by using CIM API. This method alwaysdiscovers the serial number, but is slower and the following requirementsapply:v The discovery user must have the Host > CIM > CIMInteraction

privilege.v The connection between TADDM and the ESX server is required.

For more information, see also a technote at http://www-01.ibm.com/support/docview.wss?uid=swg21638454.

Important: If you run the ESX server on virtualized hardware like CiscoUCS, you must discover the serial number by using CIM API, not VMwareAPI, because otherwise over merges might occur.


shallowVMdiscoveryIt discovers limited data for Virtual Machine.


discoverNonRunningGuestsIt discovers not running Virtual Machines.





strictCertificateCheckIt forces the sensor to connect to ESX servers that are secured with valid,CA signed certificates.


enableVMDiscoveryIt enables the discovery of Virtual Machines.


Configuring the access listFind out what access detailed are required, depending on your configuration.

Sensor uses Computer System credentials to log into VMware API. VMware Usermust have read-only permissions for discovery.

Troubleshooting the sensorSome problems might occur with theVMware ESXi computer system sensor. Findout how to solve the common problems.

Ping sensor cannot find reachable ip

ProblemThe ping sensor scans port 22 and 135. If these ports are not found, thediscovery ends. ESXi sensor by default has these ports blocked.

SolutionTo enable the discovery, configure the ports to scan in thecollation.properties file in the com.collation.pingagent.ports propertyor add an exception on ESX firewall.

ESXi sensor does not start

ProblemTo enable the ESXi sensor start after Port sensor, Port sensor must discoverESXi ports. If the ports are configured differently, the ESXi sensor does notstart.

SolutionDefault port values are 902, 80, 443. If ESXi sensor has different portsconfigured, reconfigure Port sensor.

Windows computer system sensorThe Windows computer system sensor discovers computer systems runningMicrosoft Windows operating systems.



Prerequisites

For discovery using a gateway, the gateway must be accessible through SSH.

To discover Windows systems without using a gateway:v The Windows systems must be accessible through SSH.


v Microsoft .NET Framework must be installed on Windows target systems. Formore information, see the Configuring for discovery of Windows systems topic in theTADDM Administrator's Guide.

v Windows Scripting Host (WSH) 5.6 or higher must be installed on the targetWindows systems. Windows Scripting Host is installed with Internet Explorer 6Service Pack 1 or higher.

v

Windows Server 2016Due to a Powershell 5 issue, you must contact your IBM Supportrepresentative and request that a Powershell 5 eFix be applied, beforeattempting the discovery of a Windows Server 2016 without a gateway.Once this has been done, discovery of the Windows 2016 server viadirect SSH will function normally.

Limitationsv If you provide user credentials without the administrator role, the Windows

computer system sensor is not able to collect the list of services and devices thatare related to Windows Server 2003. In result, the related tables in DataManagement Portal are empty.

v All computer system sensors and the SNMP MIB2 sensor ignore networkinterfaces that are configured to be down. TADDM does not populate thenet.IpNetwork attribute on the following types of IP interfaces:– loopback, for example, 127.0.0.1, 0:0:0:0:0:0:0:1– link-local, for example, 169.254.1.1, FE80:0:0:0:0:0:0:1– multicast, for example, 224.0.0.1, FF00:0:0:0:0:0:0:1– unspecified, for example, 0.0.0.0, 0:0:0:0:0:0:0:0





Discovery of CPU information

The NumCPUs attribute value is set to the number of logical CPUs on thecomputer system. If hyperthreading is enabled on the Windows target system, theNumCPUs attribute also includes the hyperthreads. For example, on dual coresystem with hyperthreading enabled, the value of the NumCPUs attribute is 4. Ifhyperthreading is not enabled, the value of the NumCPUs attribute is 2.


⌂Asynchronous and script-based discovery supportThe Windows computer system sensor supports asynchronous and script-baseddiscovery.






Limitations

The sensor requires powershell environment on target system for asynchronousand script-based discovery. The powershell version must be 2 or higher.

Script-based discovery is supported for following target systems:v Windows 7v Windows 8v Windows Server 2008v Windows Server 2012v Windows Server 2016 Standard Editionv Windows Server 2016 Datacentre Edition

Model objects with associated attributesThe Windows computer system sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout computer systems running the Windows operating system.


core.LogicalContent


dev.MediaAccessDevice

v Namev Typev Status

sys.DNSResolveEntry


net.L2Interface


v Encapsulationv HwAddressv InterfaceNamev Loopbackv Namev Indexv IANAInterfaceTypev InterfaceSpeedv Speed

net.IpInterface


sys.CPU

v IndexOrderv NumCPUsv CPUTypev CPUSpeedv CPUCoresInstalledv Virtualv CPUCore

sys.FileSystem



v Namev SoftwareVersionv Publisher

sys.windows.WindowsService

v ServiceNamev CanBePausedv CanBeStoppedv DesktopInteractv ErrorControlv OperatingStatev Startedv StartModev Accountv PathName


v ExitCodev ServiceSpecificCodev ServiceTypev Descriptionv Namev SoftwareVersionv ProcessId

sys.windows.WindowsComputerSystem

v UUIDv Namev Typev SystemIdv SystemBoardUUIDv VirtualMachineStatev Signaturev Fqdnv SerialNumberv Manufacturerv Modelv MemorySizev NumCPUsv CPUTypev CPUSpeedv Architecturev CPUDiesInstalledv CPUCoresInstalled

sys.windows.WindowsOperatingSystem

v Fqdnv Namev OSNamev OSVersionv BootTimev KernelArchitecturev KernelVersionv Charsetv Localev OsIdv OSConfidencev ServicePackv VersionString

Configuring the sensorBefore using the Windows computer system sensor, you must configure it.

Complete the following setup:


v Install all required software.v For discovery using a gateway, WMI must be enabled on all target Windows

systems. WMI is enabled by default.By default, discovery using a gateway automatically installs the TADDM WMIProvider on all target Windows systems during the discovery process.


To configure the access list, complete the following steps:1. For full discovery of Windows hosts and software, each Windows machine

requires a service account in the local admin group with WMI access to allWMI objects on that machine. This account can be a local account or a domainaccount.The service account must be created on the Windows gateway and all targetWindows computer systems.

2. Access list entries must be created for the Windows computer systems (gatewayand the target Windows systems).When specifying a Windows domain user account for an access list entry, thedomain name and user name must be separated by a backslash (\) as shown inthe following example: DOMAIN\username.

3. TADDM also supports SNMP-based discovery of Windows systems. To supportSNMP-based discovery, complete the following steps:a. Enable SNMP.b. Ensure that the SNMP MIB2 GET Community string has access permission

for MIB2 System, IP, Interfaces, Extended Interfaces, and Host Resources.

Configuring the collation.properties file entriesThis topic lists the collation.properties file entries that the Windows computersystem sensor uses.


Fix Pack 1 com.ibm.cdb.skipWindowsSoftware=false

Note: This property affects only script-based mode of the discovery.This property specifies whether the installed software on the Windowsoperating system is discovered.

The default value is false, which means that the software is discovered.

If the amount of the discovered data is very large and it slows down thediscovery process, set this property to true to disable the discovery of thistype of data.

















Gateway-based or SSH-based discovery properties

com.collation.AllowPrivateGateways=trueThe default value is true.

This property specifies whether a Windows computer system can bediscovered using SSH or IBM Tivoli Monitoring connections withoutrequiring an intermediate gateway. The default is to allow SSH or IBMTivoli Monitoring connections to Windows systems. If the value is set tofalse, Windows targets are only discovered if they are listed in theTADDM gateway list. If they are not included in the gateway list, theWindows session sensor fails with the CTJTP1100E error.

com.collation.PreferWindowsSshOverGateway=falseThe default value is false.

This property specifies whether to use SSH rather than gateway-baseddiscovery if a Windows computer system supports SSH. Even if aWindows computer system supports SSH, the default value for thisproperty indicates that gateway-based discovery is used. This property isignored if com.collation.AllowPrivateGateways=false.

WMI-related properties

TADDM relies on Windows Management Instrumentation (WMI) to discoverWindows computer systems. TADDM can be configured to restart the WMI serviceif a problem occurs with WMI. If the WMI service is restarted, all WMI-dependentservices that were running before the restart are also restarted.

Fix Pack 4 com.collation.discover.agent.windows.useIpAsDomain=falseThe default value is false.


This property specifies the format of credentials that is used to establishWMI session. By default, credentials in the user format are used.

If you set this property to true, credentials in the IP/user format are usedin addition to the default format.

This property is a scoped property, you can append the IP address or nameof the scope to this property. For example:com.collation.discover.agent.windows.useIpAsDomain.9.100.100.200=falsecom.collation.discover.agent.windows.useIpAsDomain.scope_name1=false

com.collation.WmiAccessEnabled=trueThe default value is true, which indicates that TADDM attempts toestablish the WMI session.

This is a discovery profile property. You can configure it with the highestpriority on the Platform Properties tab of the Discovery Profiles pane inDiscovery Management Console. You can also define it for a specific scopeset, or IP, in the collation.properties file.

com.collation.platform.os.WindowsOs.AutoDeploy=trueThe default value is true, which indicates that TADDM can automaticallyinstall the WMI provider.

Setting the value to false indicates that you can manually deploy the WMIprovider. Manual deployment is not supported but can be used fortroubleshooting.

The following TADDM server properties control the restarting of WMI.

Note: The default value for WMI restart is false. Setting the values of thefollowing properties to true might provide more reliable Windows discovery, butyou must also consider the potential negative impact of the WMI service beingtemporarily stopped and restarted.

com.collation.RestartWmiOnAutoDeploy=falseRestart WMI if a WMI error occurs during automatic deployment of theTADDM WMI Provider.

com.collation.RestartWmiOnAutoDeploy.1.2.3.4=falseRestart WMI if a WMI error occurs during automatic deployment of theTADDM WMI Provider.

com.collation.RestartWmiOnFailure=false

Restart WMI if a WMI error occurs, except during automatic deployment.

com.collation.RestartWmiOnFailure.1.2.3.4=false

Restart WMI if a WMI error occurs, except during automatic deployment.

Fix Pack 2

PowerShell-related properties

Fix Pack 3 com.ibm.cdb.session.ps.urlPrefix=wsmanThe default value is wsman.

This property specifies the value of the URLPrefix property of a WinRMlistener on the discovered Windows system. The value of this property andthe URLPrefix property on the Windows targets must be the same.

This is a scope-based property. You can override the global value for aspecific scope set or IP in the collation.properties file.


com.collation.PowerShellAccessEnabled=falseThe default value is false.

This property specifies whether TADDM attempts to establish thePowerShell session. By default, the PowerShell access is disabled. If youwant to enable the PowerShell session, set this property to true.


com.collation.PreferPowerShellOverWMI=trueThe default value is true.

This property specifies whether to use the PowerShell or the WMI session,if both of them are enabled. By default, the PowerShell session is preferred.

This is a scope-based property. You can override the global value for aspecific scope set or IP in the collation.properties file. For example:com.collation.PreferPowerShellOverWMI.myScopeABC=falsecom.collation.PreferPowerShellOverWMI.10.100.27.8=true

com.collation.PowerShellPorts=5985,5986The default value is 5985,5986.

This property specifies the PowerShell ports. By default, ports 5985 and5986 are specified. The PortSensor checks whether these ports are active. Ifthe ports are active, the PowerShell session can be established. If the portsare not active, the WMI session is used instead, unless you disabled it. Insuch case, error messages are displayed.


com.ibm.cdb.session.ps.useSSL=falseThe default value is false.

This property specifies whether the PowerShell script uses the SSL protocolto connect to the remote host. By default, the SSL protocol is not used.


com.ibm.cdb.session.ps.allowDNS=true

Note: You can use this property only when thecom.ibm.cdb.session.ps.useSSL property is set to true.


This property specifies whether the PowerShell script uses DNS on thegateway to resolve the IP of the remote host. By default, the usage of DNSis allowed.


com.ibm.cdb.session.ps.fallbackToIP=true


Note: You can use this property only when thecom.ibm.cdb.session.ps.useSSL and com.ibm.cdb.session.ps.allowDNSproperties are set to true.


This property specifies whether the PowerShell script falls back to IP whena secure session cannot be established by using FQDN. By default, thePowerShell script falls back to IP.


com.collation.PowerShellTimeoutFudge=10000The default value is 10000 (milliseconds).

This property specifies the time after which SSH protocol times out,starting with the timeout of the PowerShell script. By default, when thePowerShell script times out, the SSH protocol times out 10000 millisecondslater.

Configuring for a non-admin Windows discoveryYou can configure the sensor to run discoveries without providing user credentialswith the administrator role.

About this task

Depending on which type of session you enable, the following steps are required:

WMI session

v “Creating a discovery user account”v “Setting up the WMI configuration” on page 422v “Copying the TaddmWmi files” on page 422v “Setting up the DCOM Access for ibmcol” on page 423

Fix Pack 2 PowerShell session

v “Creating a discovery user account”v “Setting up the WMI configuration” on page 422v “Setting up the PowerShell configuration” on page 422

Fix Pack 2 Both WMI and PowerShell sessions

v “Creating a discovery user account”v “Setting up the WMI configuration” on page 422v “Setting up the PowerShell configuration” on page 422v “Copying the TaddmWmi files” on page 422v “Setting up the DCOM Access for ibmcol” on page 423

See also the Configuring for discovery of Windows systems topic in the TADDMAdministrator's Guide.

Creating a discovery user account:

When you create an account, you are able to choose the right permissions andprovide information that is needed for a non-admin Windows discovery.


About this task

You can create a discovery user account on the stand-alone Windows server andon the Active Directory domain server. Use either of the following instructions tocomplete this task.

Creating a discovery user account on the stand-alone Windows server:

Create a discovery user account on the stand-alone Windows server.

Procedure

1. Open Computer Management Console by running the compmgmt.msc command.2. In the navigation tree, expand System Tools > Local Users and Groups >

Users.3. From the Action menu, click New User.4. Provide the following information:

a. User name: ibmcol

b. Full name: TADDM discovery userc. Description: TADDM discovery userd. Password

5. Clear the User must change password at next logon check box.6. Select the Password never expires check box.7. Click Create.8. To verify whether the new user is a standard user by default, right-click the

user name, and then click Properties. In the Properties window, go to theMember Of tab. If the user is a standard user, Administrators group is not onthe list.

Creating a discovery user account on the Active Directory domain server:

Create a discovery user account on the Active Directory domain server.

Procedure

1. Open Active Directory Users and Computers by running the dsa.msccommand.

2. In the navigation tree, select domain_name and then select the Users folder.3. Right click the menu and choose New > User.4. Provide the following information:

a. First name:ibmcolb. Logon name:ibmcol

5. Click Next and provide password.6. Clear the User must change password at next logon check box.7. Select the Password never expires check box.8. Click Create.9. To verify whether the new user is a standard user by default, right-click the

user name, and then click Properties. In the Properties window, go to theMember Of tab. If the user is a standard user, Administrators group is not onthe list.


Setting up the WMI configuration:

When you set up the WMI configuration, you can add the user to the access list toenable permissions that are required for the discovery.

Procedure

1. In the navigation tree of the Computer Management Console, expand Servicesand Applications > WMI Control.

2. From the Action menu, click Properties.3. Click the Security tab, select Root namespace, and click Security.4. Add the ibmcol user to the list. The following permissions must be allowed:

a. Execute Methodsb. Enable Accountc. Remote Enable

5. Click Advanced and choose the ibmcol user from the list6. Change the Apply to property to This namespace and subnamespaces.7. Click OK.

Note: For the Active Directory domain setup, this procedure must be repeatedfor each computer that is a part of the domain. Microsoft does not provide anydomain-wide WMI configuration tool.

Setting up the PowerShell configuration: Fix Pack 2

If you enabled the PowerShell session, you must configure the target systems toenable the non-admin discovery.

Procedure

1. On the target system, run the following command:Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI-Force

With the -Force option, you are not prompted to confirm this action.2. In the new window that is displayed, select the ibmcol user.

If the user is not on the list, click Add... and search for it.3. From the permissions list, select Read(Get,Enumerate,Subscribe) and

Execute(Invoke) in the Allow column.4. Click OK.

Copying the TaddmWmi files:

The files are used for agentless discovery. They are required to enable additionalmethods to be called via WMI.

Procedure

1. Copy the following TaddmWmi files to the C:\Windows\system32\wbem directoryon a 32-bit system and to the C:\Windows\SysWOW64\wbem directory on a 64-bitsystem:v TaddmWmi.pdb

v TaddmWmi.exe

v TaddmWmi.mof


v TaddmWmi.dll

2. Compile and register TaddmWMI.dll by running the following commands:v On the 32-bit Windows operating system:

%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof%SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

v On the 64-bit Windows operating system:%SystemRoot%\SysWOW64\wbem\mofcomp.exe %SystemRoot%\SysWOW64\wbem\TaddmWmi.mof%SystemRoot%\SysWOW64\regsvr32 /s %SystemRoot%\SysWOW64\wbem\TaddmWmi.dll

Note: You can also deploy the WMI files automatically by running a standardadministrator discovery.

Setting up the DCOM Access for ibmcol:

You must set up the DCOM Access for the user to enable permissions that arerequired for the discovery.

About this task

To set up the DCOM Access for the user on the stand-alone Windows server or theActive Directory domain server, use either of the following instructions.

Setting up the DCOM Access for ibmcol on the stand-alone Windows server:

Complete the following steps to set up the DCOM Access for the user on thestand-alone Windows server.

Procedure

1. Open the Component Services Administrative Tool by running the dcomcnfgcommand.

2. In the navigation tree, expand Component Services > Computers > MyComputer.

3. From the Action menu, click Properties, and go to the COM Security tab.4. In the Access Permissions section, click Edit Default.5. Add the ibmcol user to the list and ensure that it has the Local Access and

Remote Access permissions enabled, and click OK.6. In the Access Permissions section, click Edit Limits.7. If the button is grayed out, complete the following steps:

a. Open Local Security Policy by running the secpol.msc command.b. Expand Local Policies and click Security Options.c. Select the following policy: DCOM: Machine Access Restrictions in

Security Descriptor Definition Language (SDDL) syntax.d. Right-click the policy and choose Properties from the menu. Then, click

Edit Security.8. Add the ibmcol user to the list and ensure that the Local Access and Remote

Access permissions are enabled, and click OK.9. In the Launch and Activation Permissions section, click Edit Default.

10. Add the ibmcol user to the list and ensure that it has the Local Launch andRemote Launch permissions enabled, and click OK.

11. In the Launch and Activation Permissions section, click Edit Limits.12. If the button is grayed out, complete the following steps:


a. Open Local Security Policy by running the secpol.msc command.b. Expand Local Policies and click Security Options.c. Select the following policy: DCOM: Machine Launch Restrictions in

Security Descriptor Definition Language (SDDL) syntax.d. Right-click the policy and choose Properties from the menu. Then, click

Edit Security.13. Add the ibmcol user to the list and ensure that the Local Launch, Remote

Launch, Local Activation, and Remote Activation permissions are enabled,and click OK.

14. Restart the Windows server.

Setting up the DCOM Access for ibmcol on the Active Directory domain server:

Complete the following steps to set up the DCOM Access for the user on theActive Directory domain server.

Procedure

1. Open Group Policy Management by running the gpmc.msc command.2. Choose forest and domain and select a domain policy, for example Default

Domain Policy.3. Click Action > Edit.4. Open Computer Configuration/Policies/Windows Settings/Security

Settings/Local Policies/Security options.5. Select the following policy: DCOM: Machine Access Restrictions in Security

Descriptor Definition Language (SDDL) syntax.6. Right-click the policy and choose Properties from the menu. Then, click Edit

Security.7. Add the ibmcol user to the list and ensure that the Local Access and Remote

Access permissions are enabled, and click OK.8. Select the following policy: DCOM: Machine Launch Restrictions in

Security Descriptor Definition Language (SDDL) syntax.9. Right-click the policy and choose Properties from the menu. Then, click Edit

Security.10. Add the ibmcol user to the list and ensure that the Local Launch, Remote

Launch, Local Activation, and Remote Activation permissions are enabled, andclick OK.

11. Run the gpupdate command to refresh the policy settings.

Automatic configuration:

The steps setting up the WMI configuration, ⌂copying the TaddmWmi files, and⌂setting up the DCOM Access for ibmcol can be replaced with the automaticconfiguration. If you use TADDM 7.3.0.3, or later, the setting up the PowerShellconfiguration step can be also automated.

Procedure

1. Copy the following files to the target system.a. The following script files can be found in the $COLLATION_HOME/dist/

support/bin directory.v copyFiles.ps1

v dcomConfiguration.ps1


v nonadmin.properties

v Fix Pack 3 psSessionConfiguration.ps1

v scriptsRunner.bat

v Fix Pack 3 scriptsRunner.ps1

v wmiConfiguration.ps1

v Fix Pack 4 wrmConfiguration.ps1

b. The following TaddmTool Provider files can be found in$COLLATION_HOME/dist/lib/ms/gateway directory.v TaddmWmi.pdb

v TaddmWmi.exe

v TaddmWmi.mof

v TaddmWmi.dll

2. Configure the nonadmin.properties file by updating the nonadmin.user, andnonadmin.files.path properties:nonadmin.user=usernonadmin.wmi.namespace=rootnonadmin.files.path=pathnonadmin.permissions=Enable,MethodExecute,RemoteAccess

The user value is the user that you want to use for non-admin discovery. If youspecify the local user, you need to add only the user name. Otherwise, providealso the domain name, for example, domain\user. The path value is the path tothe directory where you copied files in step 1. Do not modify the values of theremaining properties.

3. By using command prompt, run the scriptsRunner.bat file.

Fix Pack 3

In TADDM 7.3.0.3, and later, the scriptsRunner.bat file requires the

-wmi, or the -ps parameters, or both.v scriptsRunner.bat -wmi - executes the steps setting up the WMI

configuration, copying the TaddmWmi files, and setting up the DCOMAccess.

v scriptsRunner.bat -ps - executes the steps setting up the WMIconfiguration, and setting up the PowerShell configuration.

v scriptsRunner.bat -wmi -ps - executes the steps of both -wmi, and -psparameters.

Fix Pack 4

In TADDM 7.3.0.4, and later, you must use the set command and at

least one of the following parameters:v scriptsRunner.bat set -wmi - executes the steps setting up the WMI

configuration, copying the TaddmWmi files, and setting up the DCOMAccess.

v scriptsRunner.bat set -ps - executes the steps setting up the WMIconfiguration, and setting up the PowerShell configuration.

v scriptsRunner.bat set -wmi -ps - executes the steps of both -wmi, and -psparameters.

4. Restart the system.

What to do next

Fix Pack 4 If you decide not to run non-admin discoveries any longer, you canrevert to the original configuration. Run the scriptsRunner.bat with one of thefollowing options:


v scriptsRunner.bat revert -wmi

v scriptsRunner.bat revert -ps

v scriptsRunner.bat revert -wmi -ps

Restart the system.Related reference:“Configuring for a non-admin IIS discovery” on page 147You can configure the Microsoft IIS Web server sensor to run non-admin discoveryof IIS servers. Such discovery does not require a user with administrator rights. Inthis mode, the User Account Control (UAC) option can be enabled.

Troubleshooting:

Some errors might occur while you run a non-admin Windows discovery. You canfind here the descriptions of the most common errors and see how to fix them.

The session sensor ends with the CTJTP1163E error

ProblemThe following error might occur if the DCOM configuration and WMIconfiguration for the non-admin user is not correct:CTJTP1163E The following WMI session cannot be established(WMI: SELECT BuildVersion FROM Win32_WMISetting failed: Access is denied.(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))System.UnauthorizedAccessException: Access is denied.(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED));

SolutionFollow the instructions from the following sections: “Setting up the WMIconfiguration” on page 422 and “Setting up the DCOM Access for ibmcol”on page 423.

The session sensor ends with the CTJTP1161E error

ProblemThe following error might occur if the non-admin user is configuredcorrectly, but the TADDM WMI files were not deployed:CTJTP1161E The application cannot establish the following WMI session:SessionClientException: InstallProvider failed: could not copy filesto remote host: System.Exception: WNetAddConnection2: Access is denied.

SolutionFollow the instruction from the following section: “Copying theTaddmWmi files” on page 422.

Troubleshooting the sensorThis topic describes common problems that occur with the Windows computersystem sensor and presents solutions for those problems.

Problem with WMI

ProblemWindows Management Instrumentation (WMI) fails on the system that isto be discovered, which causes discovery to fail.

SolutionRestarting WMI might correct the problem. Use the following commandsto restart WMI:


net stop winmgmtnet start winmgmt

If restarting WMI does not correct the problem, use the following Microsoftutilities to troubleshoot WMI problems. These utilities are available athttps://technet.microsoft.com/en-us/scriptcenter/dd772288.aspx.

WMIDiagFollow the instructions to install and run the utility, and verify thatWMI is working correctly.

ScriptomaticThe Scriptomatic utility can be used to generate WMI queries thatare similar to those used by TADDM. The following WMI classesare some that TADDM queries:v Win32_Processv Win32_OperatingSystemv Win32_WMISettingv Win32_ComputerSystem

Verify that these classes can be queried using the Scriptomaticutility locally on the target system and remotely from the gateway.

Problem with deployment of WMI provider

ProblemFor discovery of Windows systems, TADDM deploys a WMI provider toeach target system to enable agentless discovery. Sometimes, problemsoccur with this deployment.

SolutionThe following files comprise the WMI provider and are located on theTADDM server in the $COLLATION_HOME/lib/ms/gateway directory:

TaddmWmi.dllThe WMI provider, which runs TaddmWmi.exe for functionality

TaddmWmi.mof Specifies the new WMI methods that are provided by the WMIprovider (TaddmWmi.dll)

TaddmWmi.exeCalled by the WMI provider (TaddmWmi.dll) to run a command

TaddmWmi.pdbContains debugging information for the TaddmWmi.dll file

The TADDM WMI installation provider performs the following tasks:1. As applicable, copies the files in the preceding list to the following

directory on each target system that is in the discovery scope (it useseither the Admin$ or C$ directory to do this): %SystemRoot%\System32\wbem

2. Runs the following commands on each target system:

On 32-bit Windows operating systems:%SystemRoot%\System32\wbem\mofcomp.exe %SystemRoot%\System32\wbem\TaddmWmi.mof%SystemRoot%\System32\regsvr32 /s %SystemRoot%\System32\wbem\TaddmWmi.dll

On 64-bit Windows operating systems:%SystemRoot%\SysWOW64\wbem\mofcomp.exe %SystemRoot%\SysWOW64\wbem\TaddmWmi.mof%SystemRoot%\SysWOW64\regsvr32 /s %SystemRoot%\SysWOW64\wbem\TaddmWmi.dll


https://technet.microsoft.com/en-us/scriptcenter/dd772288.aspx

To troubleshoot WMI or access-related problems, you can run the TADDMWMI installation provider manually. To manually install the provider usingthe TaddmTool program on the Windows gateway, enter the followingcommands:1. cd WINDOWS\temp\taddm.nnnn, where nnnn is a string that identifies the

TADDM gateway directory. If fixes have been applied to the TADDMserver, more than one gateway directory might be present. Theidentifier string can be found in the DiscoveryManager.log file after thefollowing item: DTADDM_ID=

2. set TADDM_USERNAME=domain\userid

3. set TADDM_PASSWORD=password_for_userid

4. set TADDM_INTERACTIVE=1

5. TaddmTool InstallProvider -AutoDeploy @ipaddress, where ipaddress isthe IP address of the target system

WMI access denied errors

ProblemYou have WMI access denied errors.

SolutionRefer to Appendix F of the Deployment Guide Series: IBM Tivoli Change andConfiguration Management Database Configuration Discovery and Tracking v1.1,an IBM Redbooks® publication, at http://www.redbooks.ibm.com/abstracts/SG247264.html.

WMI process creation errors

ProblemWMI process creation fails with an access error during providerinstallation. There might be a problem with the Windows Replace aProcess Level Token privilege not being granted to the required accounts.

Solution

v This privilege should be granted to the LOCAL SERVICE andNETWORK SERVICE accounts. To verify this, complete the followingsteps:1. Log onto the target machine using the console or the Terminal Server

Client.2. Click Start.3. Select Run.4. Enter gpedit.msc to start the Group Policy editor.5. Descend down the tree of privileges under Local Computer Policy >

Computer Configuration > Windows Settings > Security Settings >Local Policies > User Rights Assignment.

v If you cannot change the accounts assigned to the Replace a ProcessLevel Token privilege, try to add the discovery account to a group thathas that privilege.Check to see if the Tivoli_Admin_Privileges group has the privilege. Ifit does, make the discovery account a member of that group.

The specified network name is no longer available

ProblemIf this error occurs, or if there is a problem copying files to the target


during provider installation, there might be a problem connecting to theSMB (file sharing) service on the target machine.

Solution

Complete the following steps:1. Check to see if an SMB port is listening.v Windows 2003 will listen on port 445.v Windows 2000 may listen on either 445 or 139.

2. On the gateway, check to see if a connection is allowed or refused byopening a command window and running the following command:telnet <target machine name> 445

3. If it is refused, repeat step b using port 139. If both fail, you have oneof the following issues:v There is a firewall preventing the gateway from connecting to the

target SMB service.v The SMB service is not running or otherwise not functional.

To determine whether the cause is a firewall or the SMB service, completethe following steps:1. Log onto the target machine through the console or the Terminal Server

Client.2. Run the telnet commands in steps 2and 3 above, where this time

<target machine name> is the local machine.If telnet succeeds, a firewall is causing the problem. Otherwise, there isa problem with the SMB service.

Do the following:v View the control panel, services, and check if the Server service is

running.v Run the following command at the command line:

net share

One of the shares: c$ or admin$ must exist.

Slow discovery of Windows 2003 SP1 systems, or applicationsrunning on those systems

ProblemThe slow discovery of Windows 2003 SP1 systems, or applications runningon those systems, might be a result of a memory leak in the WMI service.

SolutionEnsure that the following hotfix, available from Microsoft, is installed:http://support.microsoft.com/kb/911262

Windows 2000 systems are not discovered

ProblemIf Windows 2000 systems are not discovered, the problem might bebecause an unsupported version of the netstat program installed on thetarget system. The netstat program is used to get TCP port informationduring discovery. Windows 2000 systems use a different version of thenetstat program from the one installed on systems running later versionsof Windows.


http://support.microsoft.com/kb/911262

SolutionEnsure that the following hotfix, available from Microsoft, is installed:http://support.microsoft.com/kb/907980

TADDM Discovery of Windows XP targets when local firewall isenabled.

ProblemWindows XP-based targets generally have the local firewall that is enabledfor added security.

The TADDM discovery on these computers fails with following error if thefirewall blocks the discovery:

CTJTP1161E The application cannot establish the following WMIsession: SessionClientException: SELECT BuildVersion FROMWin32_WMISetting failed (0x800706ba: The RPC server isunavailable.): 0x800706ba: System.Runtime.InteropServices.COMException (0x800706BA): The RPC server isunavailable.

SolutionTo discover a Windows target when there is a Local firewall that isenabled, restrict the RPC ports on Windows XP target to a narrow range,and then open those ports on the firewall.

Follow these steps to restrict the DCOM ports:1. Goto Control Panel.2. Select Administrative Tools.3. Select Component Services.4. Select Computers.5. Right click My Computerand open Properties.6. Select Default Protocolstab.7. Double-click Connection-oriented TCP/IP.8. Select Add in COM internet services window.9. Add a port range, for example, 5000-5050. Click OK.

10. Restart the computer.

Add the DCOM ports to the firewall exception list.

Follow these steps to allow the ports in local firewall:1. Goto Control Panel.2. Click Windows Firewall.3. Click Exceptions.4. Click Add Port .5. Add each of the DCOM ports one by one to the restrictions.

Sensor fails on targets with Tectia SSH Server because of the'failed to copy file' error

ProblemSensor fails on targets with Tectia SSH Server, and the log files contain thefollowing message:session.Ssh2SessionClient - failed to copy file: AAAA to: BBBB with retray 0java.io.EOFException: SSHSCP1: premature EOF


http://support.microsoft.com/kb/907980

SolutionTo solve the problem, complete the following steps:1. Install Tectia SSH Client on the TADDM server.2. Configure TADDM to use external Tectia scp command. Set the

com.collation.platform.os.scp.command property in thecollation.properties file to point to the Tectia scp command. Forexample:com.collation.platform.os.scp.command=C:\\SshTectia\\SSH Tectia Client\\scp2.exe

You can define the preceding flag only for the selected IPs and scopesets. For example:com.collation.platform.os.scp.command.10.11.12.13=C:\\SshTectia\\SSH Tectia Client\\scp2.execom.collation.platform.os.scp.command.scopesetA=C:\\SshTectia\\SSH Tectia Client\\scp2.exe

Note: When TADDM is in FIPS 140-2 compliant mode, using theexternal scp command might affect security. In such case, you mustmake sure that the used SCP program is FIPS-compliant.


Chapter 39. Storage sensors

Storage sensors discover the storage that is used in the environment.

EMC Storage Scope sensorThe EMC Storage Scope sensor discovers storage resources that are related tostorage area network (SAN) by extracting data from an EMC Storage Scopedatabase.

The sensor discovers such storage resources as storage arrays, hosts, switches,fabrics, zones, storage volumes, switch ports, file systems, and disk drives. Some ofthose resources, like data that is related to hosts or to switches, can also bediscovered by the Host storage sensor or the Fibre Channel switch sensor.

The EMC discovery is performed by two sensors, the EMC Storage Scope sensorand the EMC Storage Scope Detail sensor. The first one discovers general attributesof StorageSubSystem and full details of FC Switch, Fabric, Zone and ZoneSet.Then, the sensor starts the Detail sensor that discovers details of EMC arrays andhosts. You can specify the number of arrays discovered by each of the Detailsensors by editing the arraysDiscoveryChunk parameter.


EMCStorageScopeSensor, EMCStorageScopeDetailSensor

Prerequisitesv You must copy the following Oracle JAR files from the discovery endpoint to the

dist/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.emccommon_1.0.0/lib/oracle directory:– ojdbc14.jar

– oraclepki.jar

– ojpse.jar

Limitationsv To avoid duplicates, you must run the Level 2 discovery of endpoints that are

discovered by EMC Storage Scope sensor.v To reduce the number of discovered objects that might result in the Out of

Memory errors, the EMC Storage Scope Detail sensor discovers only one SCSIPath for each Volume, even if more are available. TADDM uses the SCSI Pathsto create relationship between a computer system and a Storage SubSystem. ThePaths are retrieved from the SRMHostArrayPath table.

v When you run a discovery, StoragePools are not discovered.

Security issuesv If you enable SSL on the EMC Oracle database, you must add the cwallet.sso

file to the access list.


Model objects with associated attributesThe EMC Storage Scope sensor creates model objects with associated attributes.The attributes indicate the type of information that the sensor collects aboutstorage resources that are stored in EMC Storage Scope database.


dev.BasedOnExtent

v Sourcev Target

storage.HostBusAdaptor

v Namev Parentv WordlWideName

dev.DiskDrive

v DiskSizev Namev Parentv SerialNumberv Typev Vendorv Revisionv Statusv DiskSpeed

dev.FCPort

v Descriptionv Parentv PermanentAddressv PortNumberv PortTypev Status

dev.FCVolume

v Capacityv Namev Parentv BasedOnv FreeSpace

net.IpAddress

v DotNotationv StringNotation

net.IpInterface

v IpAddressv Parent

relation.ConnectedTo


v Sourcev Targetv Type

storage.Fabric

v Fcswitchv Namev SourceTokenv ZoneSetsv Zones

storage.FCSwitch

v FCPortsv ManagementURLv Manufacturerv Modelv Namev ROMVersionv SerialNumberv Typev WorldWideName

storage.StorageSubSystem

v AllocatedCapacityv AvailabilityStatev AvailableCapacityv CacheSizev FCPortsv Fqdnv Manufacturerv Membersv Modelv ROMVersionv SerialNumberv Typev VolumeGroupCapacityv VolumeGroupFreeSpace

storage.StorageVolume

v Capacityv Namev Parentv RedundancyMethodv SourceToken

storage.Zone

v Activev Namev Parent

Chapter 39. Storage sensors 435

storage.ZoneSet

v Activev Namev Parentv Zones

Multiple operating systems:sys.aix.Aix

sys.hpux.HpUx

sys.linux.Linux

sys.OperatingSystem

sys.sun.Solaris

sys.vmware.VmwareESX


These model objects are associated with the following attributes:v FQDNv OSConfidencev OSNamev Parent

Multiple computer environments:sys.aix.AixUnitaryComputerSystem

sys.ComputerSystem

sys.hpux.HpUxUnitaryComputerSystem

sys.linux.LinuxUnitaryComputerSystem

sys.sun.SunSPARCUnitaryComputerSystem

sys.vmware.VmwareUnitaryComputerSystem

sys.windows.WindowsComputerSystem

These model objects are associated with the following attributes:v Devicesv FCPortsv FileSystemsv FQDNv IpInterfacesv Modelv OSInstalledv OSRunningv Signaturev Typev Name

Multiple file systems:sys.LocalFileSystem

sys.sun.SolarisFileSystem



sys.windows.WindowsFileSystem

These model objects are associated with the following attributes:v AvailableInodesv AvailableSpacev Capacityv MountPointv Parentv StorageExtentv TotalInodesv Type

Configuring the sensorBefore you run a discovery, you must configure the sensor.


The sensor requires the following credentials for a successful discovery:v Windows computer system credentials for the EMC Storage Scope serverv Oracle credentials for the EMC database. If you enable SSL for the JDBC

connection, you must also add the cwallet.sso file to the access list.

Configuring the discovery profileThe EMC Storage Scope sensor is enabled by default in the Level 3 discoveryprofile.

Restriction: The Host storage sensor and the Fibre Channel switch sensor alsodiscover hosts and switches. If both of them are enabled, the resources might bediscovered twice.

Create a new profile to modify the following attributes:

discoverHostsThe default value for the discoverHosts attribute is true. The sensordiscovers host-related data, for example, ComputerSystem, disks, FC ports,FC volumes, storage volumes, local file systems, and file system services.

If the value is false, host-related data is not discovered by the sensor.

discoverSwitchThe default value for the discoverSwitch attribute is true. The sensordiscovers switch related data, for example, switch, switch ports, and FCports.

If the value is false, switch related data is not discovered by the sensor.

discoverArraySerialNumberStartsWithBy default, the sensor discovers all of the arrays found. You can specifythis attribute to limit their number. For example, if you want to discoverarrays with a serial number that starts with APM, use the followingparameter:discoverArraySerialNumberStartsWith=APM


arraysDiscoveryChunkThe default value for the arraysDiscoveryChunk attribute is 10. Thisattribute specifies the number of arrays that are processed by each EMCStorage Scope Details sensor.

Restriction: If the value is to high, the discovery might result in the Out ofMemory errors.

Troubleshooting the sensorThis topic describes common problems that occur with the EMC Storage Scopesensor and presents solutions for those problems.

The sensor cannot connect to the EMC database

ProblemThe sensor fails because it cannot connect to the EMC database.

SolutionMake sure that your credentials to the EMC database are correct, and thatyou copied all required JAR files. If you enable SSL, you must also add thecwallet.sso file to the access list.

The sensor does not discover the host computer systems

ProblemThe sensor does not discover the host computer systems.

SolutionThe sensor can discover only the host systems that are managed by theEMC Control Center and that are synchronized with EMC Storage Scopedatabase. The hosts must also have a relationship to FC Switch or StorageSubSystem.

The discovery takes too long to complete

ProblemThe discovery takes too long to complete.

SolutionThe Host storage sensor and the Fibre Channel switch sensor also discoverhosts and switches. If both of them are enabled, the resources might bediscovered twice. Check your discovery.

The discovery finishes with the CTJTD2312E error

ProblemThe discovery finishes with the CTJTD2312E error.

SolutionIn the sensor log file, find the targetDb.HOSTNAME property and ensure thatthe host can be resolved from the TADDM server.

The database lock occurs

ProblemThe database lock occurs when two sensors try to store similar data in thedatabase at the same time.


SolutionBy default, all Detail sensors store their data at the same time. You canchange the following property to make them do it one by one:com.collation.discover.observer.topopumpdeadlockstrategy=avoid

Restriction: The discovery time might increase if the sensors store theirdata in a sequence.

Fibre Channel switch sensorThe Fibre Channel switch sensor discovers Fibre Channel (FC) switches andinformation about FC ports.


FCSwitchSensor

Model objects with associated attributesThe Fibre Channel (FC) switch sensor creates model objects with associatedattributes. The attributes indicate the type of information that the sensor collectsabout Fibre Channel switch resources in your IT environment.


dev.FCPort

v DisplayNamev PortNumberv DeviceIDv PermanentAddressv PortTypev Speed


v Sourcev Target

storage.FCSwitch

v Namev Descriptionv WorldWideNamev Modelv Manufacturerv SerialNumberv Version

sys.ControlSoftware

v Namev VersionString




The sensor is not enabled by default. To enable the sensor, you must create adiscovery profile, and then enable the sensor from the new profile. The sensorrequires, additional sensors to be enabled in the profile:v AnchorSensor

v PingSensor

v PortSensor

v SessionSensor

v SnmpMib2Sensor











Troubleshooting the sensorThis topic describes common problems that occur with the Fibre Channel switchsensor and presents solutions for those problems.

Incomplete switch information discovered

ProblemThe sensor completes the discovery but does not collect all the detailsabout the switches.

SolutionVerify that the following data is available:v Fibre Alliance MIB (FC-MGMT MIB)v Cisco MIB (CISCO-FC-FE MIB)v Brocade switch model information (switch.html)


Host resources sensorThe host resources sensor uses the host resources MIB to discover operating systemdetails such as memory size, file system, installed software with date and type,Media Access Device, and logical storage areas.

Details about the logical storage areas can be useful for troubleshooting “out ofmemory” and “out of buffers” problems.


HostResourcesSensor

Limitations

File systems discovered by the sensor are not displayed in the user interface. Thisrestriction applies to computer systems running on operating systems other thanWindows operating system. Run the api.sh script to see the file systemsdiscovered by this sensor.


The sensor uses the following high-level OIDs to retrieve the attributes:v Memory Size: .1.3.6.1.2.1.25.2.2.0v Storage Table: .1.3.6.1.2.1.25.2.1.2v Device Type: .1.3.6.1.2.1.25.3.1.1v Media Access Device: .1.3.6.1.2.1.25.3.2.1.1v Installed Software: .1.3.6.1.2.1.25.6.3.1.1


The sensor creates the following model objects:v dev.MediaAccessDevicev sys.ComputerSystem sys.OperatingSystemv sys.FileSystemv sys.SoftwareComponent












Host storage sensorThe host storage sensor discovers the storage that is attached to a host computersystem, including storage area network (SAN) storage. This sensor extends thestorage discovery that is provided by the storage sensor.

The host storage and storage sensors discover the same storage resources, forexample, disks, partitions, logical volumes, physical volumes, and file systems. Thehost storage sensor also discovers the following storage resources:v Fibre Channel (FC) volumesv FC portsv Host bus adapters


HostStorageSensor

Prerequisites

For 64-bit Linux targetsThe 32-bit glibc library is required

Limitations

When you discover storage attached to a target computer using the storage sensor,do not carry out a discovery on the same system using this sensor.

You must install Vendor's host bus adapter (HBA) API library files (32-bits).

The sensor does not discover the ZFS file systems on the Solaris target systems.

Do not run the sensor on AIX LPARs, where the LPAR's configuration is attachedto the BR8470 FCoE switch that runs FOS v6.4.3_dcb in Access Gateway mode. Itleads to an unexpected behavior of systems that are connected to that FC Switch.Use FOS7.0.2e, or later.

Security issues

By default, root user privileges are required to discover SAN resources in UNIXenvironments. Typically, this escalation is done by setting the file accesspermissions using the setuid (set-user-ID mode bit) term or by using the sudocommand.


Model objects with associated attributesThe Host storage sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about storageresources in your IT environment.


dev.BasedOnExtent

v Sourcev Target

dev.ControlledBy

v Controllerv Device

dev.Controller

v Name

dev.DiskDrive

v Descriptionv DiskSizev Namev Type

dev.DiskPartition

v BlockSizev Namev NumOfBlocks

dev.FCPort

v PermanentAddressv PortTypev Speed

dev.FCVolume

v BlockSizev Controllerv DeviceIDv FCPLunv Namev NodeWWNv NumOfBlocksv PortWWNv RealizedByv SCSIBusv SCSILunv SCSITargetv Type

dev.RealizesExtent

v Source


v Target

dev.SCSIProtocolController

v EndPointsv FCPortsv Name


v Namev WorldWideName

dev.SCSIVolume

v BlockSizev DeviceIDv Namev NumOfBlocksv RealizedByv SCSIBusv SCSILunv SCSITargetv Type

dev.StorageExtent

v BlockSizev DeviceIDv Namev NumOfBlocks

dev.StorageVolume

v BlockSizev DeviceIDv Namev NumOfBlocksv RealizedByv Type

phys.physpkg.Card

v FWRevisionv Manufacturerv Modelv SerialNumber

storage.HostBusAdaptor

v Namev PhysicalPackagev SCSIProtocolControllersv WorldWideName

sys.LocalFileSystem

v AvailableSpacev Capacity


v Labelv MountPointv StorageExtentv Type

sys.NFSFileSystem

v AvailableSpacev Capacityv ExportNamev MountPointv ServerName


v AvailableSpacev Capacityv Descriptionv MountPointv Type

sys.windows.WindowsFileSystem

v AvailableSpacev Capacityv Descriptionv MountPointv Type


Copying the collection engine file to a location accessible to thetarget host systemThe Host storage sensor uses an executable program, the collection engine file todiscover storage data. By default, the Host storage sensor copies the collectionengine file, to a location on the target host system. After the discovery is complete,the collection engine file is deleted from the host. Root privileges are required torun the collection engine program. Copying an application to a host system thatrequires root privileges can introduce a security risk. To avoid this risk, the sensorsupports a configuration that allows the collection engine to be deployed to, andaccessed from, a secure location.

To run the collection engine from a secure location, copy the collection engine fileto a location that is accessible to the target host system.

To copy and configure the collection engine file, complete the following steps:1. From the taddm_home/dist/osgi/plugins/

com.ibm.cdb.discover.sensor.dev.hoststorage_7.2.0/bin/collection-enginedirectory on the TADDM server, copy the file to a location that is accessible tothe target host system.

2. Restrict ownership and access to the directory to user root.3. Specify the location of the collection engine file. The location must be accessible

from the target host system. To specify the location of the collection engine file,use one of the following options:


v For Windows systems, edit the System PATH environment variable on thehost system, and type the location of the collection engine directory.

v For all other systems, edit the com.collation.discover.agent.path in thecollation.properties file on the TADDM server, and type the location of thecollection engine directory. Specify the location of the collection enginedirectory for the appropriate target operating system.

v Modify the discovery profile for the Host storage sensor on the TADDMserver. Type the path to the collection engine directory in theCollectionEnginePath or the CollectionEngineWindowsPath attribute or both, ifrequired.

4. Modify the discovery profile for the Host storage sensor on the TADDM server.Set the deployCollectionEngine attribute value to false.

5. Verify that correct user permissions are granted.The commands that are used by the Host storage sensor carrying out thediscovery can require privilege escalation. Typically, this escalation is done bysetting the file access permissions using the setuid (set-user-ID mode bit) termor by using the sudo command. For Windows operating systems, the discoveryuser must be a member of the Administrators group.

Configuring the discovery profileThe Host storage sensor, is not enabled by default. To enable the sensor, you mustcreate a discovery profile and then enable the sensor from the new profile.

The collection engine uses the HBA (host bus adapter) API to discover the HBAsand FC volumes that are configured on the host system. For a successful discovery,the vendor's HBA API library must be installed and configured correctly on thehost system.

The following attributes can be modified:

Fix Pack 4 deployCollectionEngineWindowsThe default value for the deployCollectionEngineWindows attribute istrue. The sensor copies the collection engine file to a location on theWindows target host system. After the discovery is complete, the collectionengine file is deleted from the host. The location is entered in thecollectionEngineWindowsPath attribute. If no path is specified onWindows systems, the collection engine file is copied to the TEMP directory.

If the value is false, the collection engine file is not copied.

deployCollectionEngineThe default value for the deployCollectionEngine attribute is true. Thesensor copies the collection engine file to a location on the target hostsystem. After the discovery is complete, the collection engine file is deletedfrom the host. The location is entered in the collectionEnginePath, or thecollectionEngineWindowsPath attribute. If no path is specified onWindows systems, the collection engine file is copied to the TEMP directory.For all other systems, the collection engine file is copied to the homedirectory of the user (running the discovery) on the target host system.

If the value is false the collection engine file is not copied.

Important: Fix Pack 4 In TADDM 7.3.0.4, and later, this attribute does notapply to the Windows targets. Instead, use thedeployCollectionEngineWindows attribute.


collectionEnginePathThere is no default value for the collectionEnginePath attribute. Enter theabsolute path to the UNIX collection engine directory, if required.

collectionEngineWindowsPathThere is no default value for the collectionEngineWindowsPath attribute.Enter the absolute path to the Windows collection engine directory, ifrequired.

Entering the Windows path when the directory is on a network drive(created by using the net use command), might not work. Instead, enterthe Windows path by using the UNC (Universal Naming Convention)method. For example, \\hostname\share\CollectionEngine.

collectionEngineSudoCommandThere is no default value for the collectionEngineSudoCommand attribute.Enter the command to use for privilege escalation on UNIX systems.

collectionEngineTimeoutThe default value for the collectionEngineTimeout attribute is 30. Thisvalue specifies the time interval in minutes before a timeout occurs duringa discovery.

collectionEngineForceUniqueNameThe default value for the collectionEngineForceUniqueName attribute isfalse. If the value is false, the collection engine is not renamed when thecollection engine is copied to the target system. If the value is true, a timestamp is added to the name of the collection engine before it is copied tothe target system.

If you want to use sudo to give the discovery user permission to run thecollection engine, then the collection engine name cannot be changed. Inthis case, the default value of false must be used.

In environments that use concurrent discovery, if multiple discoveries arerun at the same time, against the same target systems, collisions can occurwhen deploying the collection engine. In situations like this, thecollectionEngineForceUniqueName attribute can be set to true to force thename of the collection engine to be unique on the target system. If thisattribute is set to true, sudo cannot be used.

If the Host storage sensor is enabled, do not enable the Storage sensor. If bothsensors are enabled, some of the storages resources are discovered twice.




Typically, an account with non-root privilege can be used. The commands that areused by the Host storage sensor carrying out the discovery can require privilegeescalation. Typically, this escalation is done by setting the file access permissionsusing the setuid (set-user-ID mode bit) term or by using the sudo command.



The sensor uses the following entries, which explicitly specify the location of thecollection engine directory, in the collation.properties file:

com.collation.discover.agent.path.Linux

com.collation.discover.agent.path.SunOS

com.collation.discover.agent.path.HP-UX

com.collation.discover.agent.path.AIX

com.collation.discover.agent.path.Vmnix

You can specify each of these properties as a scoped property by appending an IPaddress or a scope set name to the property, for examplecom.collation.discover.agent.path.Linux.1.2.3.4.

If the collection engine exits on multiple target computers that have the sameoperating system, but the collection engines reside in different paths, enter thepaths in the collation.properties file. Separate each unique path with a colon.

Troubleshooting the sensorThis topic describes common problems that occur with the Host storage sensor andpresents solutions for those problems.

Commands fail because of insufficient privileges

ProblemCommand failures occurred due to permissions denied errors and arerecorded in the log files.

SolutionVerify that the commands that require privilege escalation are configuredcorrectly.

Discovery takes a long time to run

ProblemThe discovery takes a long time to run.

SolutionCheck whether the StorageSensor sensor is enabled and disable it. If bothsensors are enabled, some of the storages resources are discovered twice.

Host storage data is not discovered

ProblemHost storage data is not discovered.

SolutionVerify that the vendor's host bus adapter (HBA) API library files areinstalled and configured correctly on the host system. Missing library filesmight be identified in the HostStorageSensor log file.


WWPN and WWNN information are not displayed

ProblemThe worldwide port name (WWPN) and worldwide node name (WWNN)for an FC volume are not displayed.

SolutionTADDM uses the HBA API for FC volume discovery. The HBA APIprovides a mapping from the OS identification of a SCSI volume to the FCrepresentation of the volume. The FC representation includes the WWPNof the port from the HBA that finds the volume. On multiport HBAs, thereis no way to determine which port a SCSI volume applies to. Thislimitation is in the HBA API. The HBA API specification was updated toaddress this issue, but the change might not be implemented in all HBAAPI libraries. Ensure that the latest version of the HBA vendor's HBA APIlibrary is installed on the target host system. In summary, if the HBA APIis unable to provide the mapping of a SCSI volume to its FCrepresentation, then the WWPN and WWNN cannot be determined.

Expected number of HBAs are not displayed

ProblemTADDM does not display the expected number of HBAs.

SolutionTADDM uses the HBA API for HBA discovery. For each adapter that theHBA API returns, TADDM creates an HBA model object. The adaptersWWNN is used by TADDM to name the HBA. The number of adaptersmight not match the number of physical HBA cards that are installed inthe host computer system, or the number of WWNNs returned by thebasic system commands.

How the HBA API library interprets adapters and WWNNs are determinedby the HBA vendor's, HBA API library implementation. For example, somevendors might represent a multiport HBA card that uses one adapter withone WWNN. Other vendors can represent a multiport HBA card that usesone adapter per port, with each adapter having its own unique WWNN.

Port type and port speed are not displayed

ProblemThe port type and port speed for an FC port are not displayed.

SolutionTADDM uses the HBA API for FC Port discovery. However, some HBAAPI libraries might not support these attributes, or the HBA vendor's HBAAPI library might need to be updated. Ensure that the latest version of theHBA API library is installed on the target host system. If the HBA APIlibrary cannot determine the port type and port speed, then theseattributes are not displayed.

SCSI bus, SCSI target, and SCSI LUN are not displayed correctly

ProblemThe SCSI bus, SCSI target, and SCSI LUN for an FC volume are notdisplayed or the correct values are not displayed.

SolutionTADDM uses the HBA API to discover SCSI information about an FCvolume. However, some HBA API libraries might not support these


attributes, or might not return the correct values for these attributes. Toresolve this problem, the HBA vendor's HBA API library might need to beupdated. Ensure that the latest version of the HBA API library is installedon the target host system. If the HBA API library cannot determine theSCSI information, then these attributes are not displayed or might displayincorrect values.

FC volume information is not displayed correctly

ProblemThe FC volume information is not displayed or does not display correctvalues.

SolutionTADDM uses the HBA API to discover information about an FC volume.However, if there is a problem with the HBA API library, TADDM mightdisplay incorrect values for some FC volume attributes. For example, blocksize. To resolve this problem, ensure that the latest version of the HBA APIlibrary is installed on the target host system and configured correctly. If theHBA API library is not configured correctly, FC volume attributes mightnot display or might display incorrect values.

BR8470 FCoE switch causes HostStorageSensor to negativelyimpact systems that are connected to the switch

ProblemWhen you are running HostStorageSensor on AIX LPARs, where theLPAR's configuration is attached to the BR8470 FCoE switch that runs FOSv6.4.3_dcb in Access Gateway mode, it leads to an unexpected behavior ofsystems that are connected to that FC switch.

SolutionIt is a known FOS issue. To solve it, upgrade to FOS7.0.2e, or later.

IBM Tivoli Storage Productivity Center sensorThe IBM Tivoli Storage Productivity Center sensor discovers storage resources thatare related to a storage area network (SAN) and Network Attached Storage (NAS).The sensor extracts data from a Tivoli Storage Productivity Center database.

The following resources are examples of what the sensor discovers:v Storage arraysv Switchesv Hostsv Fabricsv Zonesv Storage volumesv Array and switch portsv File systemsv Disk partitionsv NAS-related data

Some of these resources can also be discovered by the host storage sensor (forexample, data that is related to hosts) and the Fibre Channel switch sensor (forexample, data that is related to switches).



TPCStorageSensor

Model objects with associated attributesThe IBM Tivoli Storage Productivity Center sensor creates model objects withassociated attributes. The attributes indicate the type of information that the sensorcollects about storage resources that are stored in Tivoli Storage ProductivityCenter database.


dev.BasedOnExtent


dev.Controller

v Namev Parent

dev.DiskDrive

v DiskSizev Modelv Namev Parentv SerialNumberv Typev Vendor

dev.DiskPartition

v Capacityv Namev Parentv PartitionTypev RealizedBy

dev.FCPort

v Labelv Parentv PermanentAddressv PortNumberv PortTypev Speed

dev.FCVolume

v Capacityv FCPLunv Namev Parent


v Typev PortWWNv HostPathsv BasedOn

dev.RealizesExtent


dev.SCSIPath

v ArrayVolumev HostEndPointv LUNv Parentv Volume


v WorldWideName

dev.TapeDrive

v Labelv Typev WorldWideName

net.IpAddress


net.IpInterface

v IpAddressv Parent



storage.Fabric

v Fcswitchv Labelv Namev SourceTokenv Virtualv ZoneSetsv Zones

storage.FCSwitch

v FCPortsv FCSwitchStatusv Fcportv ManagementURL


v Manufacturerv Modelv Namev ROMVersionv SerialNumberv Typev WorldWideNamev IpInterfaces

storage.StoragePool

v AnsiT10Idv Capacityv Labelv Membersv Raid Levelv RemainingManagedSpacev StorageSubSystemv TotalAvailableSpacev TotalManagedSpace


v AllocatedCapacityv AnsiT10Idv AvailabilityStatev AvailableCapacityv CacheSizev FCPortsv Fqdnv IpInterfacesv IsNetworkAttachedv Manufacturerv Membersv MemorySizev Modelv NumCPUsv ROMVersionv SerialNumberv StoragePoolsv Typev VolumeGroupCapacityv VolumeGroupFreeSpace


v BlockSizev Capacityv FreeSpacev Name


v Parentv RealizedByv RedundancyMethodv SourceTokenv Typev Virtualv Paths

storage.TapeLibrary

v AnsiT10Idv Descriptionv Devicesv Manufacturerv Modelv ROMVersionv SerialNumberv TapeMediaChangersv Type

storage.TapeMediaChanger

v Captionv Descriptionv Fqdnv Labelv ROMVersionv Typev WorldWideName

storage.Zone

v Activev Descriptionv Namev Parent

storage.ZoneSet

v Activev Labelv Namev Parentv Zones

Multiple operating systems:

sys.aix.Aixsys.hpux.HpUxsys.linux.Linuxsys.netware.Netwaresys.OperatingSystemsys.sun.Solarissys.vmware.VmwareESX



The following attributes are associated with these model objects:v FQDNv OSConfidencev OSNamev OSVersionv Parentv SoftwareComponentsv SystemGuid

Multiple Computer Environments:

sys.aix.AixUnitaryComputerSystemsys.ComputerSystemsys.hpux.HpUxUnitaryComputerSystemsys.linux.LinuxUnitaryComputerSystemsys.sun.SunSPARCUnitaryComputerSystemsys.vmware.VmwareUnitaryComputerSystemsys.windows.WindowsComputerSystem

The following attributes are associated with these model objects:v CPUSpeedv CPUTypev Devicesv FCPortsv FileSystemsv Fqdnv IpInterfacesv Manufacturerv MemorySizev Modelv NumCPUsv OSInstalledv OSRunningv SerialNumberv Signaturev Typev Namev UUIDv MacAddressv VMID

sys.FileSystemExport

v Namev Parent

sys.FileSystemService

v Exportsv Host


v Name

sys.NFSExport

v Namev Parent

sys.NFSService

v Exportsv Hostv Name

Multiple file systems:

sys.LocalFileSystemsys.sun.SolarisFileSystemsys.unix.UnixFileSystemsys.windows.WindowsFileSystem

The following attributes are associated with these model objects:v AvailableInodesv AvailableSpacev Capacityv MountPointv Parentv StorageExtentv TotalInodesv Type

sys.SMBExport

v Namev Parentv Pathv Type

sys.SMBService

v Exportsv Hostv Name


v Namev Parentv SoftwareVersion


Configuring the Tivoli Storage Productivity Center properties fileThe Tivoli Storage Productivity Center sensor uses SQL queries to extract datafrom the Tivoli Storage Productivity Center database. The SQL queries are definedin the tpc.config file and the execution of these queries is controlled by theproperties defined in tpc.properties file.


The tpc.config and the tpc.properties are located in: COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_xxx, where xxx is the sensorplugin version.

The sensor uses the following entries in the tpc.properties file to determinewhich queries to run:

com.ibm.cdb.discover.app.srm.tpc.sensor.ArrayQueriesThis property is related to array resources. By default, the followingqueries are enabled:ARRAY,ARRAY_SUM_SOURCE,ARRAY_VOLUME_GROUP,ARRAY_DRIVE,ARRAY_PORT,ARRAY_VOLUME.

com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueriesThis property is related to host resources. By default, the following queriesare enabled:HOST,HOST_PORT,HOST_DEVICE_GROUP,HOST_DEVICE,HOST_DEVICE_PARTITION,HOST_DEVICE_PARTITION_DEVICE,HOST_FS,HOST_FS_EXPORT,HOST_AGENT,HOST_SCSI_PATH,HOST_SCSI_AGENT_LESS.

HOST_SCSI_PATH queryThis query is used to create an end-to-end storage mapping fromFC volumes on a host to the volumes on a storage array. Thisquery is enabled by default. Depending on how large the storageenvironment is, running this query can increase the discovery timeof the sensor significantly. Hence, when discovering large storageenvironments, it is better to enable the HOST_SCSI_PATH query onlyoccasionally. To disable this query, do not include theHOST_SCSI_PATH in the property:com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries.

For more information about editing the property, see“Out-of-memory error when HOST_SCSI_PATH orHOST_SCSI_AGENT_LESS query is enabled” on page 461.

HOST_SCSI_AGENT_LESS queryThis query is used to create an end-to-end storage mapping fromFC volumes on a host to the volumes on a storage array, whenTPC SRA agents are not deployed to the endpoints. This query isenabled by default. Depending on how large the storageenvironment is, running this query can increase the discovery timeof the sensor significantly. Hence, when discovering large storageenvironments, it is better to enable the HOST_SCSI_PATH query onlyoccasionally. To disable this query, do not include theHOST_SCSI_PATH in the property:com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries.

For more information about editing the property, see“Out-of-memory error when HOST_SCSI_PATH orHOST_SCSI_AGENT_LESS query is enabled” on page 461.

The following example shows thecom.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries property with theHOST_SCSI_PATH and HOST_SCSI_AGENT_LESS queries disabled:com.ibm.cdb.discover.app.srm.tpc.sensor.HostQueries=HOST,HOST_PORT,HOST_DEVICE_GROUP,HOST_DEVICE,HOST_DEVICE_PARTITION,HOST_DEVICE_PARTITION_DEVICE,HOST_FS,HOST_FS_EXPORT,HOST_AGENT.


com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_PATH.maxrowsThis property specifies the maximum number of rows that the sensorprocesses, when the HOST_SCSI_PATH query is enabled.


If the HOST_SCSI_PATH query causes out-of-memory exceptions, decrease thedefault value. If you want to collect all the paths in one discovery run,depending on the storage environment, increase the default value.

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_AGENT_LESS.maxrowsThis property specifies the maximum number of rows that the sensorprocesses, when the HOST_SCSI_AGENT_LESS query is enabled.


If the HOST_SCSI_PATH query causes out-of-memory exceptions, decrease thedefault value. If you want to collect all the paths in one discovery run,depending on the storage environment, increase the default value.

com.ibm.cdb.discover.app.srm.tpc.sensor.FabricQueriesThis property is related to fabric resources. By default, the followingqueries are enabled: FABRIC,ZONE_SET,ZONE.

com.ibm.cdb.discover.app.srm.tpc.sensor.SwitchQueriesThis property is related to switch resources. By default, the followingqueries are enabled: SWITCH,SWITCH_PORT.

com.ibm.cdb.discover.app.srm.tpc.sensor.NASQueriesThis property is related to NAS resources. By default, the following queriesare enabled:NAS_FILER,NAS_CONTROLLER,NAS_VOLUME,NAS_FS,NAS_DEVICE,NAS_FS_EXPORT.

com.ibm.cdb.discover.app.srm.tpc.sensor.TapeQueriesThis property is related to TAPE resources. By default, the followingqueries are enabled: TAPE_LIBRARY,TAPE_MEDIA_CHANGER,TAPE_DRIVE.

com.ibm.cdb.discover.app.srm.tpc.sensor.SummaryQueriesThis property is related to SUMMARY resources. By default, the followingquery is enabled: PORT_CONNECTIVITY.

The following properties are used to control the discovery of certain types ofcomputer systems by the IBM Tivoli Storage Productivity Center sensor:

com.ibm.cdb.discover.app.srm.tpc.sensor.ignoreAixCompSys=trueThis property determines whether the IBM Tivoli Storage ProductivityCenter sensor discovers computer systems on AIX operating systems ornot. By default, it is set to true which means that the sensor does notdiscover computer systems on AIX operating systems.

com.ibm.cdb.discover.app.srm.tpc.sensor.IgnoreCSWithoutMacaddr=trueThis property determines whether the IBM Tivoli Storage ProductivityCenter sensor discovers computer systems without a MAC address. Bydefault, it is set to true which means that the sensor does not discovercomputer systems without a MAC address.

Configuring the discovery profileThe TPCStorageSensor is enabled by default in the discovery profile.

Create a new profile to modify the following attributes:

discoverHostsThe default value for the discoverHosts attribute is true. The sensor


discovers host-related data, for example, ComputerSystem, disks, FC ports,FC volumes, storage volumes, disk partitions, local file systems, and filesystem services.

If the value is false, host-related data is not discovered by the sensor.

discoverSwitchThe default value for the discoverSwitch attribute is true. The sensordiscovers switch related data, for example, switch, switch ports, and FCports.

If the value is false, switch related data is not discovered by the sensor.

restrictByScopeThe default value for the restrictByScope attribute is false. The sensordiscovers all the hosts that the Tivoli Storage Productivity Center serverhas already discovered.

If the value is true, the sensor discovers the hosts within the discoveryscope range of the sensor.

Fix Pack 3 discoverManagedDisksThe default value for the discoverManagedDisks attribute is false.

If the value is true, the sensor discovers Managed Disks for SVC (storagevirtualization layer) with their relationships to the back-end storage.

Note: If you set this attribute to true, the time of discovery and storing ofthe IBM® Tivoli® Storage Productivity Center sensor is longer, becausemore data is discovered.

The Host storage sensor and the Fibre Channel switch sensor also discover datarelated to hosts and switches. When discoverHosts and discoverSwitch areenabled, consider disabling the Host storage sensor and the Fibre Channel switchsensor to prevent resources being discovered twice.



use for authentication to the Tivoli Storage Productivity Center server.3. Select Database as the Component Type and DB2 as the Vendor.4. Specify the access information (user name and password) that TADDM must

use for authentication to the Tivoli Storage Productivity Center database.

Troubleshooting the sensorThis topic describes common problems that occur with the IBM Tivoli StorageProductivity Center sensor and presents solutions for those problems.

Problems connecting to the Tivoli Storage Productivity Centerdatabase cause sensor failure

ProblemThe sensor fails due to problems connecting to the Tivoli StorageProductivity Center database.


SolutionVerify that the DB2 credentials of the Tivoli Storage Productivity Centerdatabase have been entered.

Host computers are not discovered

ProblemHost computers are not discovered.

SolutionThe sensor only discovers host systems that are managed by the TivoliStorage Productivity Center agent. In addition, verify that the attributediscoverHosts is true for the sensor.

Discovery takes a long time to run

ProblemThe discovery takes a long time to run.

SolutionIf the attribute discoverHosts is true, check if the HostStorageSensorsensor is enabled and disable it. If both sensors are enabled, some of thestorages resources are discovered twice.

If the attribute discoverSwitch is true, check if the FCSwitchSensor sensoris enabled and disable it. If both sensors are enabled, some of the storagesresources are discovered twice.

This problem can also happen if some of the queries that are enabled,generate a large volume of data. For example, some of the queries that cangenerate large volumes of data are: ARRAY_VOLUME, HOST_SCSI_PATH, andSWITCH_PORT. By default, these queries are enabled.

Computer systems are not reconciled

ProblemComputer systems discovered by the TPCStorageSensor do not reconcilewith the same computer systems discovered by the computer systemsensors.

Solution

Computer systems in a storage environment can be physically partitionedor virtualized. If these systems are discovered by the TPCStorageSensor,and also by a computer system sensor, the two sets of discovered resourcesare not reconciled with each other. For example:v Logical partitions (LPARs) on pSystems discovered by TPCStorageSensor

and AixComputerSystemSensorv Virtual I/O Server (VIOS) discovered by TPCStorageSensor and HMC

sensorv Node partitions (NPARs) on HP systems discovered by

TPCStorageSensor and HpUxComputerSystemSensorv Zones on Solaris systems discovered by TPCStorageSensor and


To ensure that there is no duplication of computer systems, in the TADDMUI you must select the duplicate computer systems and merge themmanually.


Out-of-memory error when HOST_SCSI_PATH orHOST_SCSI_AGENT_LESS query is enabled

ProblemDepending on the storage environment, the HOST_SCSI_PATH andHOST_SCSI_AGENT_LESS queries can return a large result set, which mightlead to an out-of-memory error.

SolutionThe sensor caps the number of rows it processes for the HOST_SCSI_PATHand HOST_SCSI_AGENT_LESS queries to a default value of 20,000 in order toprevent out-of-memory errors. The value is based on:v Default heap size of the discover JVM (which is 1024 MB)v Default agent timeout value (which is 600000 ms)

In addition, you can configure the sensor to prevent out-of-memorymessages, when the HOST_SCSI_PATH or HOST_SCSI_AGENT_LESS query isenabled by using one of the following methods:

Modify the default number of rows processed by the sensorEdit the COLLATION_HOME/osgi/plugins/com.ibm.cdb.discover.sensor.app.srm.tpc_7.2.0/tpc.propertiesfile and add the following property:com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_PATH.maxrows=Xcom.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_AGENT_LESS.maxrows=X

where X is the maximum number of rows the sensor processes forthis query.

If this value is greater than 20,000:v Increase the heap size allocated for the Discover JVM. Edit the

$COLLATION_HOME/etc/collation.properties and change thecom.collation.Discover.jvmargs.ibm property.For example, to set the heap size to 1824 MB, add the followingline:com.collation.Discover.jvmargs.ibm=-Xdisableexplicitgc -Xmx1824m

v Increase the agent timeout for the Discover JVM. In the$COLLATION_HOME/etc/collation.properties file, add thefollowing property, where value is the number of millisecondsallowed for the sensor to run:com.collation.discover.agent.TPCStorageSensor.timeout=value

If you do not specify a value, the default value of 600000 isused.

v Restart TADDM.

Restrict the scope of storage arrays and Computer systems discoveredThe number of rows returned by the HOST_SCSI_PATH andHOST_SCSI_AGENT_LESS queries can be reduced by restricting thescope of the arrays and computer systems discovered.1. From the Discovery Management Console, click the Scope

icon. Select the Scope Set that contains the Tivoli StorageProductivity Center server to be discovered. Include the IPaddress, Range, or Subnet information of the arrays andcomputers system to be discovered. The IP address of thestorage arrays and IP address of the computer system must be


in the same scope set as the Tivoli Storage Productivity Centerserver for the discovery. These values enable the SCSI pathdata to be included in the results of the discovery.

2. From the Discovery Management Console, click the DiscoveryProfiles icon.

3. In the Discovery Profiles window, click New.4. In the Create New Profile window, type the profile name and

description. In the Clone existing profile field, click Level 3Discovery , and click OK.

5. In the list of sensors, click TPCStorageSensor, and click New.6. In the Create Configuration window, type the name and

description for your configuration of the TPCStorageSensor,and select the Enable Configuration check box.

7. In the Configuration section of the Create Configurationwindow, to restrict the scope of discovery, clickrestrictByScope. Then double-click the Value field in the row,and type true.


10. Start a discovery using the new profile.

After a discovery using the sensor, review the$COLLATION_HOME/log/sensors/runId/TPCStorageSensor-IP-PORT.log(.N) to see the number of SCSI paths that exist perstorage array IP address and per host IP address. The followingtext is an example of the contents of the log file:SCSI PATH statistics by host ip address :ip#1/4 with ipAddress 10.3.41.230 has 160 valid scsi pathsip#2/4 with ipAddress 10.3.41.289 has 527 valid scsi pathsip#3/4 with ipAddress 10.3.43.19 has 108 valid scsi pathsip#4/4 with ipAddress 10.3.42.211 has 160 valid scsi paths

SCSI PATH statistics by array ip address:ip#1/2 with ipAddress 10.0.15.201 has 693 valid scsi pathsip#2/2 with ipAddress 10.0.17.2 has 736 valid scsi paths

Run a discovery with the Tivoli Storage Productivity Center server in ascope of its own

To get the complete result set of the HOST_SCSI_PATH andHOST_SCSI_AGENT_LESS queries and prevent out-of-memory errors:1. Create a Scope Set containing only the Tivoli Storage

Productivity Center server (with no other targets).2. Create a discovery profile with only the TPCStorageSensor and

its dependent sensors enabled.3. Start the discovery of the scope set containing the Tivoli

Storage Productivity Center server using the new profile.

The sensor does not discover any objects due to DNS lookupproblems

ProblemThe IBM Tivoli Storage Productivity Center sensor finishes with no objectsdiscovered and the following warning is issued:CTJTD0952W None of the DB2 access list entries are able to connect tothe TPC database at URL: jdbc:db2://<host>:<port>/<database>.


SolutionIf <host>, which is read from the data/config/server.config file on yourdiscovery target, is an FQDN or a host name (not a plain IP address),TADDM must be able to resolve it. Configure your DNS in such a waythat the nslookup <host> command executed on your TADDM discoveryserver returns a resolved IP.

NetApp sensorThe NetApp sensor discovers storage resources that are related tonetwork-attached storage (NAS) by extracting the data from Data ONTAPoperating system with the SNMP protocol.

The sensor discovers such storage resources as storage filers, clusters, diskvolumes, FC ports, physical disk drives, aggregates (represented as storage pools),NFS and SMB Services.

NetApp discovery is run by CustomMib2ComputerSystem that calls extension scripts.Additionally, the Snap Drive sensor is used on the host side to discover definediSCSI disks. When data is discovered from both sources and it matches, arelationship between the host and array is created.

Object identifiers (OIDs)

The sensor uses the following high-level OIDs to retrieve the attributes:v General Information: .1.3.6.1.4.1.789.1.1v Virtual Filers: .1.3.6.1.4.1.789.1.16v Volumes: .1.3.6.1.4.1.789.1.5.8.1v Disk Drives: .1.3.6.1.4.1.789.1.6.10.1v Spare Disk Drives: .1.3.6.1.4.1.789.1.6.3.1v Cluster Disk Drives: .1.3.6.1.4.1.789.1.6.2.1v Qtree's : .1.3.6.1.4.1.789.1.5.10.1v Clusters: .1.3.6.1.4.1.789.1.25.1v Nodes: .1.3.6.1.4.1.789.1.25.2.1v Storage Pools: .1.3.6.1.4.1.789.1.5.11.1v FC Cards: .1.3.6.1.4.1.789.1.17.17.1.1


The sensor creates the following model objects:v dev.StorageVolumev dev.DiskDrivev dev.FCPortv net.BindAddressv net.IpInterfacev net.IpAddressv net.Fqdnv sys.NFSExportv sys.SMBExportv sys.function.StorageSubSystemFunction


v sys.ComputerSystemClusterv sys.NFSSAPv sys.SMBSAPv sys.NFSServicev sys.SMBServicev storage.StorageSubSystemv storage.StoragePool


For SNMP V2 discovery, enter the correct Community String into the access list.You can use the Network Template (SNMP) Component Type in the Access Listwindow in the Discovery Management Console.

Snap Drive sensorThe Snap Drive sensor discovers storage resources that are related to NetAppSnapDrive software for Windows.

The sensor discovers such storage resources as file system, SCSI Volumes, Host BusAdaptors and SCSI Protocol Endpoints.

This sensor is a part of the NetApp storage resources discovery. It is required fordiscovering storage resources like iSCSI on Windows system. Additionally, itprovides data to create a relationship with an array.


SnapDriveSensor

Security issues

The user account for discovering Computer Systems is also used for runningSnapDrive commands.

The sensor uses the following commands:v sdcli disk list

v iscsicli listpersistenttargets

v sdcli iscsi_target list -f <target IP>

v sdcli sysconfig list


The sensor creates the following model objects:v dev.SCSIVolumev dev.StorageVolumev dev.BasedOnExtentv dev.SCSIProtocolEndPointv dev.SCSIPath


v storage.HostBusAdaptorv sys.LocalFileSystem


The Snap Drive sensor can be run by using the ComputerSystem access credentialsthat are used to discover the client.

Storage sensorThe storage sensor discovers the storage that is attached to a computer system.

The following resources are examples of what the sensor discovers:v Disksv Partitionsv Logical volumesv Physical volumesv File systems


StorageSensor

Prerequisites

For 64-bit Linux targetsThe 32-bit glibc library is required

Limitations

Access to the /dev/dsk directory is not available on Solaris local or branded zonetarget systems. Therefore, not all storage information is retrieved.

When you discover storage attached to a target computer using the host storagesensor, do not carry out a discovery on the same system using this sensor.

The sensor does not discover the ZFS file systems on the Solaris target systems.


The sensor creates the following model objects:v dev.BasedOnExtentv dev.ControlledByv dev.Controllerv dev.DiskDrivev dev.DiskPartitionv dev.FCVolumev dev.RealizesExtentv dev.SCSIVolumev dev.StorageExtent


v dev.StorageVolumev sys.NFSFileSystemv sys.unix.UnixFileSystemv sys.LocalFileSystem








The following TADDM server properties specify operating system commands thatTADDM uses to retrieve storage information:v com.collation.platform.os.command.lvm.lvdisplayv com.collation.platform.os.command.lvm.vgdisplayv com.collation.platform.os.command.lvm.pvdisplayv com.collation.platform.os.command.lputil.SunOS

These commands require elevated privilege to run on the target system, and theymust be configured to use the sudo command.


Troubleshooting the sensorThis topic describes common problems that occur with the Storage sensor andpresents solutions for those problems.

General problems

Determine whether information is missing, and identify any command failures dueto permissions denied errors. Verify that commands that require privilegeescalation are properly configured. See Configuring the collation.properties fileentries for details.


SVC Storage sensorFix Pack 1

The SVC Storage sensor discovers storage resources that are related to SAN(Storage Area Network). The sensor extracts data from IBM Storage VolumeController.

The storage resources that are discovered by the SVC Storage sensor includestorage array, storage volumes, FC ports, storage pools and disk drives. The sensoruses the SSH connection to retrieve such data.

The SVC Storage sensor discovers world wide port name (WWPN) of the hosts forcreating relationship to host volumes, which requires HostStorageSensor to run onhosts.

It is not advisable to run SVC Storage sensor along with TPC sensor for the sameendpoint. It can lead to minor differences in the discovered data like RAID or SCSIPaths, which generates additional entries in change history.

Fix Pack 3

You can use SVC Storage sensor to discover configuration details of IBM

Storwize® v7000 storage enclosed in the IBM PureFlex System chassis. See “IBMBladeCenter SNMP sensor” on page 327.

The SVC Storage sensor is enabled by default in the Level 2 and Level 3 discoveryprofile.

Sensor name used in the GUI and logs

SVCStorageSensor

Limitations

The sensor does not discover Raid Level attribute for Storage Pools and StorageVolume objects because the attribute is discovered by TPCStorageSensor for thesame objects.


The SVC Storage sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about storageresources that are stored in SVC.


dev.DiskDrive

v AdminStatev AnsiT10Idv DiskSizev Namev Parentv Status


dev.FCPort

v Parentv PermanentAddressv PortNumberv PortTypev Speed

net.IpAddress


net.IpInterface

v IpAddressv Parent

storage.StoragePool

v AdminStatev AnsiT10Idv Capacityv Labelv StorageSubSystemv TotalAvailableSpace


v AllocatedCapacityv AvailabilityStatev AvailableCapacityv FCPortsv Fqdnv Manufacturerv Membersv Modelv ROMVersionv SerialNumberv StoragePoolsv Typev VolumeGroupCapacityv VolumeGroupFreeSpace


v AdminStatev BlockSizev Capacityv DeviceIDv IeeeUniqueVolumeNamev IOGroupv ManagedSystemNamev Namev Parent


v Pathsv RedundancyMethod

dev.SCSIPath

v arrayVolumev HostEndPointv LUNv Parent

physpkg.PhysicalFrame

v AdminStatev Labelv Manufacturerv Modelv Namev Parentv PhysicalPackagev RelativePosition

sys.CPU

v CPUSpeedv IdentifyingNumberv Manufacturerv Parentv VersionString

sys.OperatingSystem

v Namev OSNamev Parent



The SVC Storage sensor requires the Computer System credentials of the SVCsensor to run a successful discovery.

The users created on SVC must have a monitor role assigned to run discoveries.The role enables them to run commands like lssystem, lsmdisk, lsmdiskgrp,lsportfc, lsvdisk, lsnode, lsnodevpd, lsnodecanister, lsenclosure,lsvdiskhostmap, or lsfabric.

Veritas Storage Foundation sensorThe Veritas Storage Foundation sensor discovers Veritas Storage Foundationsystems.

The Veritas Storage Foundation sensor combines the following principalcomponents and provides a solution for online storage management:


v VERITAS Volume Managerv VERITAS File System

Physical disks are grouped into logical volumes to improve disk utilization andreduce wasted space. VERITAS Volume Manager allows administrators to workwith logical names (volumes) rather than through direct access to physical devices.

The VERITAS File System also provides an enterprise journaling file systemincreasing performance and reliability.

The Veritas Storage Foundation sensor is responsible for discovering the followinggeneral Volume Manager configurations:v Versionv Installation directoryv Objects under the control of VxVM (for example, Volumes and Disk Groups) and

relationships between them.

The second component, VERITAS File System, is recognized as a local file systemand the disk layout version is collected.


VeritasStorageSensor

Security issues

The default user to discover Computer System is used.

Limitations

The licenses are not supported. There are no application descriptors.


The sensor creates the following model objects:v app.ConfigFilev app.SoftwareInstallationv dev.MediaAccessDevicev dev.veritas.VeritasDiskGroupv dev.veritas.VeritasPlexv dev.veritas.VeritasSubdiskv dev.veritas.VeritasVMDiskv dev.veritas.VeritasVolumev sys.LocalFileSystemv sys.veritasVeritasStorageService


The following properties may require elevated privilege.v com.collation.discover.agent.command.vxdisk=vxdisk


v com.collation.discover.agent.command.vxdg=vxdg

v com.collation.discover.agent.command.vxprint=vxprint

v com.collation.discover.agent.command.vxupgrade=vxupgrade

v com.collation.discover.agent.command.vxdf=df

Troubleshooting the sensorThis topic describes common problems that occur with the Veritas StorageFoundation sensor and presents solutions for those problems.

The sensor fails with a timeout error on a Windows platform

ProblemThe Veritas Storage Foundation sensor fails with a timeout error on aWindows platform

SolutionIn the configuration file, change the liteDiscoveryMode to true if thesensor times out on a Windows platform. The following example showsthe attributes within a predefined configuration file:<results xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<VeritasStorageAgentConfigurationxsi:type="coll:com.collation.platform.model.discovery.agent.

VeritasStorageAgentConfiguration"><enabled>true</enabled><familyName>DiscoverSensor</familyName><name>VeritasStorageSensor</name><seedClassName>com.collation.discover.seed.app.vsf.VeritasSFSeed

</seedClassName><agentClassName>com.collation.discover.agent.app.vsf.VeritasSFAgent

</agentClassName><liteDiscoveryMode>false</liteDiscoveryMode>

</VeritasStorageAgentConfiguration></results>

XIV Storage sensorFix Pack 1

The XIVStorageSensor discovers storage resources related to SAN (Storage AreaNetwork) by extracting data from IBM XIV Storage System.

The storage resources discovered by the XIVStorageSensor include storage array,storage volumes, FC ports, storage pools and disk drives. The sensor uses XCLIconnection to retrieve the data.

The XIVStorageSensor discovers world wide port name (WWPN) of the hosts forcreating relationship to host volumes, which requires HostStorageSensor to run onhosts.

The XIVStorageSensor is enabled by default in the Level 2 and Level 3 discoveryprofile.

Sensor name used in the GUI and logs

XIVStorageSensor


Limitations

Sensor does not discover FC Port Type because it is discovered byTPCStorageSensor for the same objects.

Sensor setup requirements

You must have XCLI application installed on the host. It must be able to reach XIVStorage System through XCLI native protocol. Configure IP address and path ofthe host, where the XCLI application is installed.

Requirement: XIV Storage System version 4.5 is required.

XIV endpoint might not have SSH enabled and, as a result, Ping sensor returns noobjects. In such case, create a new profile and enable the following platformproperty:com.collation.pingagent.ports=7778,22,135

Configuring the sensorFix Pack 1

Before running a discovery, you must configure the sensor.



The XIVStorageSensor requires the following credentials to run a successfuldiscovery:v XIVStorage credentials of the XIV Storage System (users with read only

permission).v Computer System credentials of the host, where XCLI application is installed.

Configuring the collation.properties file entriesFix Pack 1

This topic lists the collation.properties file entries that the sensor uses.

When the SSH protocol is not available, set the following property in thecollation.properties file:com.collation.pingagent.ports=port_numbers


The XIV storage sensor creates model objects with associated attributes. Theattributes indicate the type of information that the sensor collects about storageresources that are stored in XIV.



dev.DiskDrive

v Modelv Namev Parentv Revisionv SerialNumberv Statusv Typev Vendor

dev.FCPort

v AdminStatev Labelv Parentv PermanentAddressv PortNumberv PortTypev Speedv Status

dev.SCSIPath

v arrayVolumev HostEndPointv LUNv Parent

net.IpAddress


net.IpInterface

v IpAddressv Parent

physpkg.PhysicalPackage

v FWRevisionv Manufacturerv Modelv Namev Parentv PartNumberv RelativePositionv SerialNumber

storage.StoragePool

v AdminStatev AnsiT10Idv Capacityv Labelv Name


v RaidLevelv StorageSubSystemv TotalAvailableSpace


v AnsiT10Idv AvailabilityStatev FCPortsv Fqdnv Manufacturerv Membersv Modelv SerialNumberv StoragePoolsv SystemIdv Type


v BlockSizev Capacityv ManagedSystemNamev Namev Parentv Pathsv RedundancyMethodv Typev Virtual

Troubleshooting the sensorFix Pack 1

This topic describes common problems that occur with the XIV Storage sensor andpresents solutions for those problems.

Running XCLI commands takes a long time

Problem

Note: The following problem does not apply to XIV Storage Systemversion 4.5 and later.XCLI is required for XIVStorageSensor to successfully discover XIV. Whenboth TADDM server and XCLI are installed on the Windows operatingsystem, running each XCLI commands might last more than 2 minutes.

SolutionTo solve the problem, go to the XIVGUI\properties directory, open thexiv-constants.properties file, and change the value of the followingproperty from the default one to 0:xcliServerTimeout


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-1785 U.S.A.

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 THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, therefore, this statement might 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.


IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

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 Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.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.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

If you are viewing this information in softcopy form, the photographs and colorillustrations might not be displayed.

TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks ofInternational Business Machines Corp., registered in many jurisdictions worldwide.Other product and service names might be trademarks of IBM or other companies.A current list of IBM trademarks is available on the Web at “Copyright andtrademark information” at http://www.ibm.com/legal/copytrade.shtml.


http://www.ibm.com/legal/copytrade.shtml

Itanium is a trademark or registered trademark of Intel Corporation or itssubsidiaries in the United States and other countries.

Java and all Java-based trademarks andlogos are trademarks or registeredtrademarks of Oracle and/or itsaffiliates.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the UnitedStates, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Other company, product, and service names may be trademarks or service marksof others.

Notices 477

IBM®

Printed in USA

Application Dependency Discovery Manager: Sensors · PDF fileT ivoli A pplica tion Dependenc y...

Documents

Transcript of Application Dependency Discovery Manager: Sensors · PDF fileT ivoli A pplica tion Dependenc y...